The Effects of Individual XP Practices on Software Development Effort S. Kuppuswami, Dept. of Computer Science Pondicherry University Pondicherry – 605 014 India
[email protected]
K.Vivekanandan, and Prakash Ramaswamy, Paul Rodrigues Dept. of Computer Science & Engg. Nature Soft and Information Technology Chennai Pondicherry Engineering College India Pondicherry India
[email protected],
[email protected]
Abstract Traditional heavyweight software development methodologies are rigid, heavily documentation oriented and process oriented. In the present E-Business dominated environment, the above methodologies are hard to follow. In response to this, a new generation of lightweight methodologies such as Extreme Programming (XP) has evolved which has only a few simple rules to adopt, and insist on less documentation. XP proposes four values, a development process and twelve practices. One of the significant benefits among those claimed by the inventors of XP is the reduction of effort in the software development. However, the extent of fulfillment of this claim remains unanswered by empirical and quantitative evidences. Hence, the effects of XP on software development effort are to be investigated. In this study, we developed a process simulation model to analyze the effects of individual XP practices on development effort. System dynamics based simulation, an effective modeling technique for software development process was chosen. This model has accounted for all the twelve practices and processes of XP. We have also introduced a measurement scale for measuring the level of usage of individual XP practices. The factors that affect the cost are collected from literature and a few XP project managers. The process model was simulated for a case study of a typical XP project to investigate the effects of individual XP practices on development effort by varying their usage levels. The decrease in percentage of the development effort for each XP practice when its usage level is varied from minimum to maximum during which all the other practices were maintained at a constant usage level was found. The decrease in percentage of the development effort for each XP practice when its usage level is minimum and maximum was computed and is given below. (i) Planning game - 2.67% (ii) Small Release 2.67% (iii) Metaphor - 2.01% (iv) Simple design - 2.5% (v) Continuous Testing - 2.88% (vi) Refactoring -0.677% (vii) On-site Customer - 5.48% (viii) Pair programming - 4.4% (ix) Collective Code Ownership – 4.82% (x) Forty Hours Per Week - 2% (xi) Coding Standard - 4.82% (xii) Continuous Integration - 1.13%. The finding of the present study on the effects of individual XP practices depicts a reduction in software development effort by enhancing their usage levels.
[email protected]
They are waterfall, prototype, iterative, rapid application development, and spiral model based methodologies [1]. These methodologies impose lot of rules for the developers to follow. In the evolution process of these methodologies, they have become rigid, heavily documentation oriented and process oriented, and hence they are called as heavyweight methodologies. In the present E-Business dominated environment, the rules of heavyweight methodologies are hard to follow. The procedures of heavyweight methodologies are also complex and not well understood. The effort spent on documentation goes waste, as they are never referred. This leads to a situation where there is no control over the following development parameters: cost, time, and quality [2]. In response to this, a new generation of methodologies has evolved such as Extreme Programming (XP), Scrum, Crystal Families of Methodologies, Feature Driven Development, Agile Rational Unified Process, Dynamic System Development Method, Adaptive Software Development and Open Source Software Development [3]. These methodologies are known as agile or lightweight methodologies because they have few simple rules to adopt, and insist on less documentation. Among the above methodologies, eXreme Programming (XP) is one of the earliest and important agile methodologies. XP as a methodology proposes four values, a development process and twelve practices. The inventors of XP claimed that many benefits can be achieved by choosing XP as software development methodology. One of the important benefits is the reduction of the software development effort. However, questions about the extent to which XP has fulfilled its claims on development effort are answered more by intuitive feelings[4] [5] [6] and experience reports [7] [8], than by empirical and quantitative evidences. Intuition may provide a starting point, but it needs to be supported with empirical evidence. It has been empirically found that the one of the important practice of XP, the pair programming increases the productivity by 15%.[9]. However, the effects of other practices on software development effort have not been studied. Hence, the present research work has been undertaken to investigate the effects of XP, specifically all the twelve practice of XP on software development effort quantitatively when XP development process is adopted.
Keywords: Extreme Programming (XP), software development Survey, case studies, controlled experiments, executable process, effort, process model, system dynamics. cost estimation and simulation models can be used for investigating the effects of XP practices on software development effort 1.0 Introduction [10]. Out of the above investigation methods, the simulation is Software plays an important role in the modern world. The develfound to be more suitable for investigating the effects of XP on opment of software has always been regarded as a difficult task. software development effort as other methods have constraints Different development methodologies have been proposed by the [11]. We have chosen System dynamics based simulation out of researchers to guide the software development process as a whole. many existing simulation techniques because it models software 1
development process effectively [12].
Onsite customer: A customer is present with the developement team for the entire duration of the development of the software to The system dynamics model of XP was developed and was answer questions. The customer is also involved acceptance testsimulated for a case study of a typical XP project to investigate ing process . the effects of XP practices on development effort. Using this model, we have shown how each of XP practices affects the soft- Coding Standards: Programmers write all code in accordance with ware development effort by simulating the model for various the predefined rules. The rules are framed in such away that code adoption levels of XP practices. itself can serve as document. Section 2.0 explains the basic concepts of XP. The basics of system dynamics and the developed system dynamic model of XP process are explained in section 3.0. The results of the simulation run are presented in section 4.0. A brief conclusion is given in section 5.0. 2.0 Extreme Programming (XP) XP is a lightweight methodology for small to mediums teams, developing software in the face of vague or rapidly changing requirements [4]. To date, XP has been applied to business problems only. XP is a clean and concise environment. It is formulated by observing what makes software development go faster and what makes it move slower [2]. A software development project, which adopts XP methodology, is referred as XP project. The duration of an XP project usually ranges from six to fifteen months involving two to twenty members. XP follows four core values: communication, simplicity, feedback and courage. These values are used as guidelines to define practices and process of XP [4]. The XP Practices Small Releases: The software is developed and released in successive short cycles. The software which is released in each cycle is a working version. The Planning Game: Helps to determine the features that are to be incorporated in each of the release by combining business priorities and technical estimates. Metaphor: A high level abstraction of the proposed software system which will guide the development team in developing the software. Simple Design: The system should be designed only for the current requirements and not for the future enhancement.
XP Process The requirements of a proposed system are represented as stories. The stories are implemented, and integrated into a complete system by using the following six phases of lifecycle of XP: exploration phase, planning phase, iterations to release phase, productionizing phase, maintenance phase and death phase. 3.0 Model Description The proposed system dynamics model for an XP project is illustrated in figure 2. The model was created using Vensim simulation tool [13]. For easy understanding, we have shown only the highlevel diagram. On given project size as the input the model gives the development effort in man-hours. Before explaining the model, we briefly describe the basic concepts of system dynamics and their modeling elements. Modeling Concepts of System Dynamics The system dynamics field was introduced by J. W. Forrester to apply the engineering principles of feedback and control to social systems [14]. Abdel-Hamid was the first person to use system dynamics for modeling software project management process [15]. In system dynamics a system is defined as a collection of elements that continually interact with each other and outside elements over time, to form a unified whole [16]. The two important elements of the system are structure and behavior. The structure is defined as the collection of components of a system, and their relationships. The structure of the system also includes the variables that are important in influencing the system. The behavior is defined as the way in which the elements or variables composing a system vary over time [16].System dynamics modeling is used • to understand how systems change over time and • to analyze how structural changes in one part of a system might affect the behavior of the system as a whole
Continuous Testing: Programmers continually write unit tests, which must run flawlessly for development to continue. The programmers write the test code even before writing the production code.
The software development process is highly interconnected components such as products, process and people. It also includes variables such as effort, errors, and lines of code that change over time. The system dynamics model is highly appropriate method to Refactoring: Programmers restructure the system without chang- model software development process. ing its functionality to remove duplication, improve communicaModeling Elements of System Dynamics tion, simplify, or add flexibility. Sources and sinks: are the accumulations that are external to the Pair Programming: All production code is written with two pro- system being modeled and connected to the system as input and grammers at one machine. output respectively. Collective Code Ownership: Every developer in the team has right Level: represents things being accumulated within system or utilto change any code, anywhere in the system at any time. ized by the system. Continuous Integration: Integrate and build the system many Flows: represents the movement of accumulation. The rates are times a day, whenever a task is completed. the flows, which increase or decrease the levels. 40 Hours Week: Work only for 40 hours in a week.
Auxiliary variables: are the fundamental variables that also de2
scribe the system.
size of the project before commencing is must. This determines the project size in terms of indivisible units of requirements namely user-stories.
Constants: variables whose values do not change. Links: shows the connection between two model elements.
In this stage, the actual stories are created by the onsite customer The graphical notations for the above modeling elements are practice with the help of the developers. The story generation rate, which is expressed in number of stories per day, depends on onshown in figure 1. site customer capability, nominal story generation rate, and XP experience (experience of the programmers in XP).
Fig. 1. The Graphical representation of System Dynamics Elements Stages of XP Process The input to XP process is project size. (Specified in terns of number of user stories) and output is accepted stories. The input requirements are transformed into accepted stories by adopting the following processes successively: story creation, estimation & schedule, design, testing and coding, refactoring, integration, acceptance test and rework processes. Story creation, estimation & schedule processes are done only once in a life cycle. The othprocesses are repeated for each release. The refactoring process is applied only to a part of the developed code.
The next is scheduling the user-stories where schedule for implementing the prioritized user-stories is planned. The factors that affect this are a) XP experience b) Team’s schedule generation rate c) Spike percentage b) On-site customer practice. If the programmers find it, difficult to estimate any story they create a prototype of the story to help in estimation. This prototype is called spike. Design process is the next stage. Design in XP is just scribbling at the back of the story card with a pencil for just few minutes contrasting to the structured approach and hence called simple design. The designing rate depends on the proper usage of XP practices. These factors are termed drateXPmultiplier, which includes the practices: forty-hour week, simple design, on-site customer practice and system metaphor.
Coding is initiated only when the programmers have satisfactorily completed and tested their design for its compliance to the reAssumptions The proposed model is developed based on the following assump- quirements. Coding is affected by the team’s nominal programming rate. It is also affected by the set of XP practices like coding tions: standard, collective code ownership, pair programming, system 1. Each story is of same complexity. metaphor, simple design, on-site customer practice and continuous 2. The errors in any process are found out in the same proc- testing. ess itself. Certain undetected errors are detected only dur- During or after programming the clarity of the code may be ening the acceptance tests, which are conducted at the hanced through refatoring if time permits. Yet some amount of individual release. code may be integrated without refactoring due to time restriction. Refactoring depends on code smell and schedule pressure. Code Modeling of XP Process In order to compute the total cost of a project, the important proc- smell signifies the current clarity of code and schedule pressure is ess elements have to be modeled. They are input to a process, out- the percentage by which the completion time is compressed from put from a process, and the rate of transformation. The input and the nominal. output of a process are modeled as levels. The rate of transforma- The next stage of the process is integration. The integration is contion is modeled as rate component of system dynamics. Project tinuous thus the code is integrated everyday and added to the code size in user stories, estimation & schedule, designed user stories, base. Depending on the acceptance percentage certain amount of unit tested and coded stories, integrated stories, stories to be re- the integrated stories are accepted and others rejected. The rework worked, and accepted stories are modeled as level variables. The rate is affected by average of usage levels ratings of all practices. rate variables that affect these deserves consideration are story generation rate, schedule generation rate, design rate, program- Quantification of Model Parameters ming rate , refactoring rate, integration rate, rejection rate, rework The usage level of XP practices are measured in a scale of 0 to 5 rate and acceptance test rates. These rates are in turn affected by as described in Table 1. As shown in the model, design rate, proother variables, which are modeled as auxiliary variables. The gramming rate etc. are affected by the XP practices. For brevity, developed model incorporates the influence of XP practices, by we explain only the influence of XP practices on design rate. The making the rate variables dependent on XP practices as shown in XP practices that affect the design rate are captured in a variable Fig 3. drateXPmultiplier, which includes XP practices: forty-hour week, Before constructing the model, the factors affecting the XP prac- simple design and system metaphor,On-site Customer. The tices were inferred by drawing influence/ causal-loop diagram. amount of influence of each practice is specified in the scale of 7 Each stage in the software development process is mapped onto a as Very Low, Low, Medium, High, Very High, Extra high, and Extreme High. level in the model. Hence, we would prefer to describe the model in stages of the software development process itself. Initial determination of the 3
Rati ngs
Equivalent level of usage.
Description
5
Almost ways
(over 90% of the time) When the practice is adopted as recommended.
4
Frequently
3
al-
(about 60 to 90% of the time) When the practice is is adopted but some times the practice is omitted due to difficult circumstances.
About Half
The development effort are also found when all the practices are maintained at every usage level (Not followed to Almost always). The results are represented graphically in Graph 2.
(about 40 to60% of the time) When the practice is adopted about half of the time.
2
Occasionally
(about 10 to 40% of the time) When the practice is followed but less often.
1
Rarely ever
( less than 10% of the time) When the practice is rarely followed.
0
(Table 3) and represented graphically (Graph 1). The amount of decrease in development effort for each XP practice when its usage level is minimum and maximum was computed from the table 3 and is given below. (i) Planning game - 2.67% (ii) Small Release - 2.67% (iii) Metaphor - 2.01% (iv) Simple design - 2.5% (v) Continuous Testing - 2.88% (vi) Refactoring -0.677% (vii) On-site Customer - 5.48% (viii) Pair programming - 4.4% (ix) Collective Code Ownership – 4.82% (x) Forty Hours Per Week - 2% (xi) Coding Standard - 4.82% (xii) Continuous Integration - 1.13%
if
Not Followed
The practice is not followed at all.
Table 1. EXP Measurement Scale
DrateXPmu ltiplier
0
1
2
3
4
5
Drate effort
0.81
0.9
1.0
1.1
1.21
1.3
Table 2. Design Rate Effort Multiplier Depending upon the usage level of the practices (table 1) and amount of influence of each XP practice their effect on design rate is computed as follows: DrateXPmultiplier = ((Coding standard*W1+Metaphor*W2+Simple design*W3+Forty hours per week*W4 + Onsite Customer * W5)/ (W1+W2+W3+W4+W5)) where W1 to W5 indicates the amount of influence of the corresponding XP practice on the design rate. The Drate XP multiplier influences the design rate to the required extent through Drate effort by multiplying the nominal design rate by the values ranging from 0.81 to 1.3. These are assigned depending on the computed Drate XP multiplier as shown in table 2. Rating 2 for Drate effort is treated as median value. (i.e. the design rate is not affected by XP practices). The ratings higher than median values increase the design rate and the ratings lower than median rate decreases the design rate.
Name of the Practice
Usage Level of XP Practice Not Followe d
Rarel y If Ever
Occasio nally
Abo ut Half
Frequen tly
Almost Always
Planning Game
4500
4490
4430
4400
4400
4380
Small Releases
450 0
449 0
443 0
440 0
440 0
438 0
Metaphor
448 0
447 0
442 0
440 0
439 0
439 0
Simple Design
449 0
448 0
443 0
440 0
439 0
438 0
Continious testing
451 0
449 0
444 0
440 0
440 0
438 0
Refactoriing
443 0
443 0
442 0
440 0
440 0
440 0
Onsite customer
456 0
453 0
447 0
440 0
437 0
431 0
Pair Programming
455 0
454 0
448 0
440 0
440 0
435 0
Collective Code Ownership
456 0
450 0
449 0
440 0
440 0
434 0
40 hours per week
449 0
449 0
442 0
440 0
440 0
440 0
Coding standard
456 0
450 0
449 0
440 0
440 0
434 0
Continuous Integration
444 0
443 0
443 0
440 0
440 0
439 0
Table 3. Effects of Individual XP Practices. When 4.0 Results the effects of one practice is measured all the other The effect of XP practices are found by simulating a typical XP project for many times. The development effort in man-hours were obtained for each XP practice when its usage level was varied Thus the increasing usage level of all XP practices simultaneously from minimum (Not followed) to maximum (Almost always) dur- from Not followed to Almost always brings out a difference of ing which all the other practices were maintained at a constant 195 man-days for the project size of 50 user stories. usage level of 3 (About Half). The above results are tabulated 4
[2] “What is lightweight methodology?”, Retrieved on March 18, 2003 from http://www.xprogramming.com/light1.html
4600
Onsite Customer Collective Code Ownership
4550 Effort in Man-Hours
[3] Abrahamsson, P., Salo O., Ronkainen .J., and Warsta J. (2003) : Agile software Development Methods. Retrieved on February 4, 2003 from http://www.inf.vtt.fi/pdf/478.pdf
Effects of Individual XP Practices
[4] Beck, K.(2000): Extreme Programming Explained: Embrace Change. Addison Wesley, 2000.
Small Releases
4500
[5] Cauwenberghe, P.V.(2001) : Refactoring or Upfront Design. International Conference on Extreme Programming and Agile Process in Software Engineering (XP2001), Sardina, Italy, 2001.
Planning Game
4450
Coding Standard
4400
Simple Design
[6] Fowler, M. (2002) : The New Methodology. Retrieved on December 2, 2002 from http://www.martinfowler.com/articles/newMethodology.html
40 Hours/week
4350
The Grap 2. 0 Effects of XP practices.
Pair Programming Almost Always
Frequently
About Half
Occasionally
Rarely If Ever
Not Followed
4300
[7] Maurer, F., and Martel.S.(2002) : Extreme programming: Rapid Development for Web-Based Applications. IEEE Internet Computing, JanuaryFebruary, 2002.
Metaphor
XP Usage Level Ratings
[8] Hodgetts, P., and Phillips D. (2003) : eXtreme Adoption Experiences of a B2B Start Up. Retrieved on September 4 2003, from AgileLogic.com
Continious Testing
[9] Cockburn,.A., and Williams L.A.(2000) : The Costs and Benefits of Extreme Programming. International Conference on Extreme Programming and Agile Process in Software Engineering, (XP2000), Sardina, Italy, 2000
Refactoring
Continious Integration
[10]Tvedt, J.D.(1996) : An Extensible Model for Evaluating the Impact of Process Improvements on Software Development Cycle Time. Ph.D Dissertation, Arizona State University, May 1996.
GGgggGraph. 1. Effects of Individual Practices of XP
[11] Kellner, M.I., Madachy R.J., and David R. (1999) : Software Process Simulation Modeling: Why? What? How?. Journal of Systems and Software, Vol. 46, No.2/3, April 1999.
6000
[12] Kuppuswami, S., Vivekanandan K., and Paul Rodrigues (2003) : A System Dynamics Simulation Model to Find the Effects of XP on Cost of Change Curve. In proceedings of Fourth International Conference on Extreme Programming and Agile process in Software Engineering, (XP2003), May 25 – 29, 2003, Genova, Italy.
5590 5170 4790
5000
4400
4300
4000
4030
[13] In “Vensim User Manual”, Retrieved on January http://www.vensim.com/
Almost Always
Frequently
About Half
Occasionally
Rarely If Ever
15, 2001
from
[14] Forrester, J.W. (1961) : Industrial Dynamics. The MIT Press, Cambridge, 1961
3000 Not Followed
Effort in Man-Hours
Effect of XP Practices
[15] Abdel-Hamid, and Madnick. S. (1991) : Software Project Dynamics. Englewood Cliffs, NJ, Prentice Hall 1991. [16]System Dynamics Learning Materials, Road Map 2 Online retrieved from http://www.sysdyn.mit.edu/road-maps/home.html on 02nd January 2003
Usage Level for All XP practices
Graph. 2. Effects of XP practices when all of them are tt l l 5.0 Conclusion We have developed a process simulation model of XP to find the effects of individual XP practices on cost. The values of model parameters were determined from literature and project managers. The developed model is simulated for a typical XP project of size of 50 user stories. The effects of individual XP practices on development effort were computed The results indicate a reduction in software development cost by enhancing the usage levels of Individual XP practices. Even though, the proposed simulation model is developed to compute the software development effort, it can also be used to find to perceive effects of new policies with out actually implementing them. References [1] Pressman, R. (2001): Software Engineering: A Practitioner's Approach. McGraw Hill, Fifth Edition, 2001.
5
Story creation over
Schedule over
Complexity
Project Size
User Stories Story generation rate
Estimation over Project size variable Schedule Customer generation rate multiplier Over
Individual schedule generation rate Team's SGR
XP experience Individual nominal productivity Team's Nominal productivity Individual design rate Team's Design rate
Number of developers
spike percentage
estimation and schedule number of user stories User stories not designed Release generation rate
Team's programming rate
Individual programming rate Individual refactoring rate
User stories for design release
Number of Number of developers in refac developers in prog
Design Over
Unit test and coded stories
Effective Acceptance percentage
Release number
DRate XP multiplier
Small releases
Collective code ownership
Prate effort
PRate XP multiplier refactoring amount rate
Unrefactored code
Release overrefactoring rate
Drate effort
number of user stories in small releases
Design rate Designed user stories Programming rate
Number of Team's developers in integration
Total effort
RRate XP Stories to multiplier be refactored
Coding standard
effective refactoring amount User stories ready Pair for integration programming Refactoring Code smell nominal refactoring rate1 Rrate effort amount Schedule N acc test rate Integration rate Accepted pressure Team's Stories IRate XP integration rate multiplier Integrated stories
Metaphor
Continous testing
Number of Acceptance test developers for atest rate Individual Tested integration rate Rework transfer stories
Effort multiplier
Acceptanc eamount Stories to be
reworked Reworked stories
score for all the practices adopted
rejectionamount
Nominal rework rate
Effective Rework rate
Number of developers for rework
Figure 2. System Dynamics Model of XP on Software Development Process
6
Forty hours per week
Simple design
IRate effort
N accptance amount
Planning ga
Onsite C ustomer
Refactoring
Continous Integration
