Business analysts view of software development life cycle models General Approach...................................................................................................1 Linear or Phased Approaches................................................................................1 Waterfall..............................................................................................................1 V Model...............................................................................................................

!ncremental "evelopment...................................................................................# !terative Approaches...............................................................................................$ %piral ..................................................................................................................$ Microsoft %olutions &ramewor' ........................................................................11 (ationale )nified Process.................................................................................1* A+ile Approaches..................................................................................................1, (apid Application "evelopment........................................................................1, "%"M................................................................................................................1, -.treme Pro+rammin+......................................................................................1$

General Approach

(e+ardless of the time an activity ta'es whether they are done simultaneously or in lon+ planned phases frau+ht with documentation and approvals/ the %"L0 must answer certain 1uestions a2out the product 2ein+ developed. What is the 2usiness pro2lem 2ein+ solved3 0oncept phase. What is the solution to that pro2lem3 (e1uirements 4ow are we +oin+ to affect the solution3 Lo+ical "esi+n What are the elements of that solution3 Physical desi+n and codin+ 4ow do we 'now our solution is ri+ht3 )nit/ inte+ration and system testin+ 4ow do we 'now we have the ri+ht solution3 Acceptance testin+ Will it wor' in the environment with the actual users3 !mplementation -ach of the life cycle models includes activities/ tas's/ or phases that answer these 1uestions/ althou+h not necessarily in the direct format +iven a2ove. Linear or Phased Approaches Waterfall While the Waterfall Model presents a strai+htforward view of the software life cycle/ this view is only appropriate for certain classes of software development. %pecifically/ the Waterfall Model wor's well when the software re1uirements are

well understood 5e.+./ software such as compilers or operatin+ systems6 and the nature of the software development involves contractual a+reements. 7he Waterfall Model is a natural fit for contract82ased software development since this model is document driven9 that is/ many of the products such as the re1uirements specification and the desi+n are documents. 7hese documents then 2ecome the 2asis for the software development contract. 7here have 2een many waterfall variations since the initial model was introduced 2y Winston (oyce in 1:;< in a paper entitled= >mana+in+ the development of lar+e software systems= concepts and techni1ues?. Barry Boehm/ developer of the spiral model 5see 2elow6 modified the waterfall model in his 2oo' Software Engineering Economics (Prentice-Hall, 1987). 7he 2asic differences in the various models is in the namin+ and@or order of the phases. 7he 2asic waterfall approach loo's li'e the illustration 2elow. -ach phase is done in a specific order with its own entry and e.it criteria and provides the ma.imum in separation of s'ills/ an important factor in +overnment contractin+.

-.ample of a typical waterfall approach While some variations on the waterfall theme allow for iterations 2ac' to the previous phase/ >!n practice most waterfall proAects are mana+ed with the assumption that once the phase is completed/ the result of that activity is cast in concrete. &or e.ample/ at the end of the desi+n phase/ a desi+n document is delivered. !t is e.pected that this document will not 2e updated throu+hout the

rest of the development. Bou cannot clim2 up a waterfall.? 5Murray 0antor/ C2Aect8oriented proAect mana+ement with )ML/ Dohn Wiley/ 1::$6 7he waterfall is the easiest of the approaches for a 2usiness analyst to understand and wor' with and it is still/ in its various forms/ the operational %L0 in the maAority of )% !7 shops. 7he 2usiness analyst is directly involved in the re1uirements definition and@or analysis phases and peripherally involved in the succeedin+ phases until the end of the testin+ phase. 7he 2usiness analyst is heavily involved in the last sta+es of testin+ when the product is determined to solve the 2usiness pro2lem. 7he solution is defined 2y the 2usiness analyst in the 2usiness case and re1uirements documents. 7he 2usiness analyst is also involved in the inte+ration or transition phase assistin+ the 2usiness community to accept and incorporate the new system and processes.

V Model 7he EVE model 5sometimes 'nown as the E)E model6 reflects the approach to systems development where in the definition side of the model is lin'ed directly to the confirmation side. !t specifies early testin+ and preparation of testin+ scenarios and cases 2efore the 2uild sta+e to simultaneously validate the definitions and prepare for the test sta+es. !t is the standard for German federal +overnment proAects and is considered as much a proAect mana+ement method as a software development approach. >7he V Model/ while admittedly o2scure/ +ives e1ual wei+ht to testin+ rather than treatin+ it as an afterthou+ht. !nitially defined 2y the late Paul (oo' in the late 1:$<s/ the V was included in the ).F.Gs Hational 0omputin+ 0entre pu2lications in the 1::<s with the aim of improvin+ the efficiency and effectiveness of software development. !tGs accepted in -urope and the ).F. as a superior alternative to the waterfall model9 yet in the ).%./ the V Model is often mista'en for the waterfallI >!n fact/ the V Model emer+ed in reaction to some waterfall models that showed testin+ as a sin+le phase followin+ the traditional development phases of re1uirements analysis/ hi+h8level desi+n/ detailed desi+n and codin+. 7he waterfall model did considera2le dama+e 2y supportin+ the common impression that testin+ is merely a 2rief detour after most of the milea+e has 2een +ained 2y mainline development activities. Many mana+ers still 2elieve this/ even thou+h testin+ usually ta'es up half of the proAect time.? 5Goldsmith and Graham/ >7he &or+otten Phase?/ %oftware development/ Duly J<<J6 As shown 2elow/ the model is the shape of the development cycle 5a waterfall wrapped around6 and the concept of flow down and across the phases. 7he V shows the typical se1uence of development activities on the left8hand 5downhill6 side and the correspondin+ se1uence of test e.ecution activities on the ri+ht8 hand 5uphill6 side.

0oncept of operations %ystem re1uirements %u2system re1uirements

%ystem

Acceptance test %ystem test %u2system test

%u2system desi+n

%u2system

!nte+ration test )nit test

)nit desi+n 0ode

)nit
-.ample of a typical V Model 5!---6

7he primary contri2ution the V Model ma'es is this ali+nment of testin+ and specification. 7his is also an advanta+e to the 2usiness analyst who can use the model and approach to enforce early consideration of later testin+. 7he V Model emphasiKes that testin+ is done throu+hout the %"L0 rather than Aust at the end of the cycle and reminds the 2usiness analyst to prepare the test cases and scenarios in advance while the solution is 2ein+ defined. 7he 2usiness analysts role in the V Model is essentially the same as the waterfall. 7he 2usiness analyst is involved full time in the specification of the 2usiness pro2lem and the confirmation and validation that the 2usiness pro2lem has 2een solved which is done at acceptance test. 7he 2usiness analyst is also involved in the re1uirements phases and advises the system test sta+e which is typically performed 2y independent testers L the 1uality assurance +roup or someone other than the development team. 7he primary 2usiness analyst involvement in the system test sta+e is 'eepin+ the re1uirements updated as chan+es occur and providin+ >voice of the customer? to the testers and development team. 7he rest of the test sta+es on the ri+ht side of the model are done 2y the development team to ensure they have developed the product correctly. !t is the 2usiness analysts Ao2 to ensure they have developed the correct product.

!ncremental "evelopment

7he !ncremental approach is a +eneric method of deliverin+ a wor'in+ part of a total product or solution. !t is the 2asis of most a+ile and iterative methods includin+ (ational )nified Process 5()P6. 7he a+ile concept of >time2o.in+?/ adapted from !BM/ is an incremental delivery approach. %imilar to the V model/ incremental development is as much a mana+ement approach to software development as a development approach/ pro2a2ly more so. >!ncremental development is a schedulin+ and sta+in+ techni1ue nicely suited to proAects usin+ technolo+y and techni1ues new to an or+aniKation... M!t isN a schedulin+ and sta+in+ strate+y that allows pieces of the system to 2e developed at different times or rates and inte+rated as they are completed. %pecifically intended is that 2etween increments/ additions could 2e made to the re1uirements/ process chan+es could 2e incorporated/ or the schedule could 2e improved and revised. !ncremental is distin+uished from iterative development in that the latter supports Epredicted rewor'E of parts of the system. A +ood +rasp of incremental development helps in applyin+ iterative development...? 5Alistair 0oc'2urn/ >)nravelin+ incremental development?6 %ta+ed "elivery 7he sta+ed delivery model initially advanced 2y 7om Gil2 and later championed 2y %teve Mc0onnell applies the principles of incremental delivery to the waterfall model. !t s a development approach that emphasiKes proAect plannin+ and ris' reduction 2y usin+ multiple software releases. "urin+ the first phases of the sta+ed delivery process/ the overall pro2lem is defined and the solution specified. 7he second phase consists of creatin+ an architecture for the overall solution. After that the product is partitioned into interim or successive deliveries and each delivery +oes throu+h its own development life cycle as shown in the dia+ram 2elow. 7he +oal of each sta+e is to advance toward a complete and ro2ust product on time and within 2ud+et. 7ypically each sta+e has its own 2ud+et and delivera2le schedule that may 2e refined 2ased on previous delivera2les. 7he duration of each successive sta+e is +enerally similar. 7he num2er of planned sta+es for achievin+ a final release is dependent upon the functionality/ application comple.ity/ and so forth.

%oftware

concept
(e1uirements

analysis
Architectural

desi+n

%ta+e 1= "etailed desi+n/ code/ de2u+/ test/ and delivery

%ta+e J= "etailed desi+n/ code/ de2u+/ test/ and delivery

%ta+e n= "etailed desi+n/ code/ de2u+/ test/ and delivery

-.ample of the sta+ed approach 5&rom %teve Mc0onnell/ %oftware ProAect %urvival Guide/ Microsoft Press6 At the core of successful sta+ed delivery is the customer review that occurs 2etween sta+es and is typically 2ased on usin+ the software in the 2usiness environment. 7his is what Alistair 0oc'2urn calls the >2reathin+ space?. !t allows for customer feed2ac' and adAustments to the architect/ re1uirements/ and process for successive sta+es. 7he sta+ed and any incremental delivery approach poses e.tra challen+es for the 2usiness analyst. After the pro2lem has 2een defined and the product re1uirements specified/ the 2usiness analyst then may 2e handlin+ re1uirements chan+es for multiple sta+es/ or addressin+ the user or sta'eholder feed2ac' from previously installed software while assistin+ with the development and testin+ of succeedin+ sta+es. -specially when multiple development teams are involved/ the 2usiness analyst activities in a sta+ed or incremental delivery life cycle are 2est handled in a team effort with multiple 2usiness analysts assi+ned to different sta+es and product delivera2les.

Iterative Approaches %piral 7he spiral model was defined 2y Barry Boehm/ now at the )niversity of %outhern 0alifornia/ as an early e.ample of an iterative approach to software development. !t was not the first model to discuss iteration/ 2ut it was the first model to e.plain why the iteration matters. As ori+inally envisioned/ the iterations were typically # months to J years lon+. -ach phase of the spiral starts with a desi+n +oal 5such as a user interface prototype as an early phase6 and ends with the client 5which may 2e internal6 reviewin+ the pro+ress and determinin+ if the ne.t spiral will ta'e place. 7he primary difference 2etween the spiral model and the other life cycle models is the emphasis of ris' assessment as evidenced 2y the illustration 2elow. -ach cycle throu+h the phases ends with an evaluation 2y the customer and an assessment of the ris' of +oin+ ahead with the ne.t iteration or stoppin+ and completin+ the delivery of the product. Cnce the product is deemed ready for development 2ased on customer feed2ac' and ris' assessment/ the process 2ecomes a standard waterfall approach. 7he difference is that the hi+h level desi+n and specifications have 2een completed and the construction phase has a prototype to follow. 7his ma'es the implementation faster and of hi+her 1uality. While the spiral model in its pure form is not used much outside the ).%. Military/ it sets the pattern for most of the a+ile and iterative approaches that follow it. 7here are also a multitude of >spiral? variations for all or parts of the solution life cycle such that spiral has almost 2ecome synonymous with iterative.

0umulative cost Pro+ress throu+h steps (is' analysis (is' analysis (is' analysis 0om ( Proto Cp A 8type s (1ts plan 0oncept of Life8cycle operation plan Prototype %oftware re1uirements Prototype
%imulations/ mode

"etermine o2Aectives/ alternatives/ constraints

0ommitment (eview Partition

-valuate alternatives/ identity/ resolve ris's

Cperational prototype
ls/ 2enchmar's

!nte + and ration tes t pl an

"eve lopm ent plan

(e1uirements validation

%oftware product desi+n

"etailed desi+n 0ode )nit test

"esi+n validation and verification

Acceptance test !nte+ration and test

!mplemen8 tation

Plan ne.t phases

"evelop/ verify ne.t8level product

-.ample of the spiral model 5from Boehm/ B.W. A Spiral Model of Software Development and Enhancement . !--- %oftware -n+ineer and ProAect Mana+ement/ 1:$;6

7he steps in the spiral model can 2e +eneraliKed as follows= 1. 7he new system re1uirements are defined in as much detail as possi2le. 7his usually involves interviewin+ a num2er of users representin+ all the e.ternal or internal users and other aspects of the e.istin+ system. J. A preliminary desi+n is created for the new system. *. A first prototype of the new system is constructed from the preliminary desi+n. 7his is usually a scaled8down system/ and represents an appro.imation of the characteristics of the final product. . A second prototype is evolved 2y a fourfold procedure= 516 evaluatin+ the first prototype in terms of its stren+ths/ wea'nesses/ and ris's9 5J6 definin+ the re1uirements of the second prototype9 5*6 plannin+ and desi+nin+ the second prototype9 5 6 constructin+ and testin+ the second prototype.

,. At the customerGs option/ the entire proAect can 2e a2orted if the ris' is deemed too +reat. (is' factors mi+ht involve development cost overruns/ operatin+8cost miscalculation/ or any other factor that could/ in the customerGs Aud+ment/ result in a less8than8satisfactory final product. #. 7he e.istin+ prototype is evaluated in the same manner as was the previous prototype/ and/ if necessary/ another prototype is developed from it accordin+ to the fourfold procedure outlined a2ove. ;. 7he precedin+ steps are iterated until the customer is satisfied that the refined prototype represents the final product desired. $. 7he final system is constructed/ 2ased on the refined prototype. :. 7he final system is thorou+hly evaluated and tested. (outine maintenance is carried out on a continuin+ 2asis to prevent lar+e8scale failures and to minimiKe downtime.

7he 2usiness analysts role in the spiral is further e.tended into the development life cycle. !n addition to the re1uirements definition and liaison activities/ the 2usiness analyst is typically 1uite involved with the prototypin+ efforts and the ris' assessment sta+es. 7he 2usiness analyst also wor's with the customer durin+ the evaluations and sometimes represents the customer in evaluatin+ the applica2ility of the product at that point.

Microsoft %olutions &ramewor' >MicrosoftO %olutions &ramewor' 5M%&6 is a deli2erate and disciplined approach to technolo+y proAects 2ased on a defined set of principles/ models/ disciplines/ concepts/ +uidelines/ and proven practices from Microsoft... 7he M%& is an iterative approach created 2y Microsoft for the development of its operatin+ systems and productivity software pac'a+es. M%& helps teams directly address the most common causes of technolo+y proAect failure in order to improve success rates/ solution 1uality/ and 2usiness impactI 0reated to deal with the dynamic nature of technolo+y proAects and environments/ M%& fosters the a2ility to adapt to continual chan+e within the course of a proAect.? 5 Microsoft Solutions Framework Version 3.0 Overview/ Microsoft 0orporation/ Dune J<<*6

-.ample of Microsoft %olutions &ramewor' 5&rom Microsoft 0orporation6

M%& is similar to PP 5see 2elow6 with similar principles and methods. 7he lan+ua+e is different reflectin+ the difference in o2Aectives 2etween the mar'et8 oriented structure of M%& and the development oriented approach of PP. 7he core M%& principles are &oster open communications Wor' toward a shared vision -mpower team mem2ers -sta2lish clear accounta2ility and shared responsi2ility &ocus on deliverin+ 2usiness value %tay a+ile/ e.pect chan+e !nvest in 1uality Learn from all e.periences 7here is also a heavier emphasis on release mana+ement in the M%& than with other a+ile approaches. >7he M%& Process Model is 2ased on phases and milestones. At one level/ phases can 2e viewed simply as periods of time with an emphasis on certain activities aimed at producin+ the relevant delivera2les for that phase. 4owever/ M%& phases are more than this9 each has its own distinct character and the end of each phase represents a chan+e in the pace and focus of the proAect. 7he phases can 2e viewed successively as e.ploratory/ investi+atory/ creative/ sin+le8minded/ and disciplined. Milestones are review and synchroniKation points for determinin+ whether the o2Aectives of the phase have 2een met. Milestones provide e.plicit opportunities for the team to adAust the scope of the proAect to reflect chan+in+ customer or 2usiness re1uirements and to accommodate ris's and issues that may materialiKe durin+ the course of the proAect. >5 Microsoft Solutions Framework Version 3.0 Overview/ Microsoft 0orporation/ Dune J<<* M%& has not cau+ht on much outside of Microsoft/ 2ut many of its principles and techni1ues are incorporated into other approaches.

(ationale )nified Process 7he (ational )nified Process 5()P6 was developed 2y !var Daco2son/ Grady Booch and Dim (um2au+h at (ational %oftware 0orporation after they had defined the )nified Modelin+ Lan+ua+e 5)ML6. Both the )ML and the )nified Process were handed over to the C2Aect Mana+ement Group 5CMG6 to 2e esta2lished as o2Aect8oriented development standards. 7he approach assumes the development will 2e done usin+ o2Aect8oriented analysis/ desi+n and pro+rammin+ as a 2asis. >()P is a software en+ineerin+ process. !t provides a disciplined approach to assi+nin+ tas's and responsi2ilities within a development or+aniKation. !ts +oal is to ensure the production of hi+h81uality software that meets the needs of its end users within a predicta2le schedule and 2ud+etI 7he (ational )nified Process is also a process framewor' that can 2e adapted and e.tended to suit the needs of an adoptin+ or+aniKation.? 5Philiippe Frutchen/ !" an introduction# 3rd edition/ Addison8Wesley/ J<<*6 7he ()P is or+aniKed around phases and disciplines in a matri. 5see the illustration 2elow6 that emphasiKes the iterative nature of the process. -ach of the disciplines iterates a num2er of times throu+h each of the phases until the e.it criteria for that phase is achieved. 7he phases are not defined so much 2y activities/ 2ut 2y +oals and outcomes= !nception= a+reement amon+ the team and customer as to what will 2e 2uilt -la2oration= a+reement within the team as to the architecture and desi+n needed to deliver the a+reed system 2ehavior 0onstruction= the iterative implementation of a fully functional system 7ransition= delivery/ defect correction/ and tunin+ to ensure customer acceptance

-.ample of the (ational )nified Process 5&rom (ational %oftware6 7he ()P is a use8case driven/ )ML82ased iterative development approach that delivers software incrementally. 7he 2usiness analyst is usually deeply involved as the >voice of the customer? throu+hout all the iterations and phases/ more so/ of course/ in the inception and ela2oration phases.

Agile Approaches

(apid Application "evelopment (apid Application "evelopment 5(A"6 is also a +eneric term for a ran+e of evolutionary prototypin+ approaches. Many of the approaches have 2een developed over the years and are used within or+aniKations and 2y consultin+ firms to produce software results on a more rapid 2asis than the structured linear methods. (A" is now in vo+ue due to the increasin+ demand for we282ased software to 2e developed at hi+h speed. Most (A" approaches nowadays are o2Aect8oriented 2ecause of the rapidity o2Aect8oriented lan+ua+es and tools provide. 4owever/ (A" approaches have 2een successfully applied to speed up structured analysis/ desi+n and pro+rammin+ efforts. "%"M 7he "ynamic %ystems "evelopment Method is a framewor' of controls for the development of !7 systems to ti+ht timescales. !t is independent of any particular set of tools and techni1ues. !t can 2e used with o2Aect8oriented and structured analysis and desi+n approaches in environments ran+in+ from the individual P0 to +lo2al distri2uted systems. "%"M has 2een used successfully 2y or+aniKations in 2oth the pu2lic and private sectors. "%"M provides a +eneric process which must 2e tailored for use in a particular or+aniKation dependent on the 2usiness and technical constraints. "%"M outlines a five phase process= 8 &easi2ility %tudy 7he feasi2ility study assesses the suita2ility of the application for a (A" approach and chec's that certain technical and mana+erial conditions are li'ely to 2e met. 7he feasi2ility study typically lasts a matter of wee's 8 Business study 7he 2usiness study scopes the overall activity of the proAect and provides a sound 2usiness and technical 2asis for all future wor'. 7he hi+h8level functional and non8functional re1uirements are 2aselined/ a hi+h8level model of the 2usiness functionality and information re1uirements is produced/ the system architecture is outlined and the maintaina2ility o2Aectives are a+reed 8 &unctional model iteration 7he 2ul' of development wor' is in the two iteration phases where prototypes are incrementally 2uilt towards the tested system which is placed in the user environment durin+ the implementation phase

8 "esi+n and 2uild iteration "urin+ the desi+n and 2uild iteration/ the focus is on ensurin+ that the prototypes are sufficiently well en+ineered for use in the operational environment 8 !mplementation !mplementation consists of puttin+ the latest increment into the operational environment and trainin+ the users. 7he final step in implementation is a review of what has 2een achieved Principles of "%"M= 8 Active user involvement is imperative 8 "%"M teams must 2e empowered to ma'e decisions 8 7he focus is on fre1uent delivery of products 8 &itness for 2usiness purpose is the essential criterion for acceptance of delivera2les !terative and incremental development is necessary to conver+e on an accurate 2usiness solution All chan+es durin+ development are reversi2le (e1uirements are 2aselined at a hi+h level 7estin+ is inte+rated throu+hout the life8cycle A colla2orative and co8operative approach 2etween all sta'eholders is essential

"%"M= process overview

&unctional model iteration

&easi2ility Business study

!mplementation "esi+n and 2uild iteration

-.ample of "%"M process 5from %tapleton/ Dennifer. DSDM$ %he Method in "ractice. Addison8Wesley6

-.treme Pro+rammin+ -.treme Pro+rammin+ 5PP6 is the poster child for the a+ile approaches. 7he process was developed 2y Fent Bec'/ Ward 0unnin+ham and (on Deffries. When people thin' of a+ile they usually thin' in terms of PP. -.treme Pro+rammin+ 5PP6 is a software development methodolo+y that represents a throw2ac' to the very earliest and purest days of software development when technicians ran the show. 7hen/ software en+ineers enAoyed +reater autonomy lar+ely 2ecause there were few in the mana+ement ran's who understood the tas' at hand. PP is the hi+hest ris' approach and re1uires the +reatest s'ill/ 'nowled+e and e.perience to run it successfully. Accordin+ to the founders/ all the principles of PP must 2e adhered to in order to 2e successful9 adaptin+ several of the principles and tryin+ to do PP will not wor'.

-.ample PP Process 7he PP process as shown a2ove starts with a proAectGs re1uirements which are laid out as individual stories typically written on *., cards. 7hese stories have test cases which are written 2y the customer and developer wor'in+ as a team. A test case includes the test and the desired results which/ if met/ indicate that that story is complete.

7he proAect is done in iterations. At the end of an iteration/ the ne.t iteration is planned out in an iteration plannin+ meetin+ called the Plannin+ Game. 7he customer 5with the developersG +uidance/ of course6 decides what stories are to 2e implemented in the ne.t iteration/ 2ased on what is most important to them/ and what is most practical to implement ne.t. !t is important that all iterations ta'e the same amount of time. 7his is so that metrics can 2e retained that let the PP team 'now what their velocity 5speed of development6 is. 7he time that it too' to complete a +iven story is recorded so that the pro+rammers +et a +ood feel for how much effort it ta'es to do that type of wor'. 7he stories are 2ro'en down into tas's/ which are the steps needed to implement a +iven user story. "evelopers then si+n up to do those tas's. Cn the completion of an iteration/ acceptance tests are done to ensure that the test cases defined in that story have 2een met. 7he acceptance tests include 2oth automated unit testin+/ and customer testin+. 7his ma'es sure that all re1uirements are reached 2ecause the development is 2ased around those re1uirements and there are definite indicators that tell whether a +iven re1uirement is met. !t also 2rea's down the proAect into reacha2le +oals rather than havin+ pro+rammers wor' away forever on an ever8e.pandin+ scope.

%ome PP Precepts= 8 PP calls for short release cycles/ a few months at most/ so the scope of any slip is limited. Within a release/ PP uses one8 to four8wee' iterations of customer re1uested features for fine8+rained feed2ac' a2out pro+ress. Within an iteration/ PP plans with one8 to three8day tas's/ so the team can solve pro2lems even durin+ an iteration 8 PP as's the customer to choose the smallest release that ma'es the most 2usiness sense/ so there is less to +o wron+ 2efore +oin+ into production and the value of the software is +reatest 8 PP creates and maintains a comprehensive suite of tests/ which are run and re8 run after every chan+e 5several times a day6/ to ensure a 1uality 2aseline 8 PP calls for the customer to 2e an inte+ral part of the team. 7he specification of the proAect is continuously refined durin+ development/ so learnin+ 2y the customer and the team can 2e reflected in the software 8 PP as's pro+rammers to accept responsi2ility for estimatin+ and completin+ their own wor'/ +ives them feed2ac' a2out the actual time ta'en so their estimates can improve/ and respects those estimates MFent Bec'/ -.treme Pro+rammin+ -.plained/ Addison8Wesley/ J<<<N

PP Principles 7he followin+ principles from Fent Bec's 2oo' -.treme Pro+rammin+ -.plained constitute the essence of PP. Many are the same as principles already descri2ed for other a+ile processes or in +eneral. %ome were initiated 2y PP and some were adopted 2y PP. 1. 7he Plannin+ Game= Business and development cooperate to produce the ma.imum 2usiness value as rapidly as possi2le. 7he plannin+ +ame happens at various scales/ 2ut the 2asic rules are the same= Q Business comes up with a list of desired features for the system. -ach feature is written out as a )ser %tory/ which +ives the feature a name/ and descri2es in 2road stro'es what is re1uired. )ser stories are typically written on .# cards. Q "evelopment estimates how much effort each story will ta'e/ and how much effort the team can produce in a +iven time interval. Q Business then decides which stories to implement in what order/ as well as when and how often to produce a production release of the system J. %mall (eleases= PP teams practice small releases in two important ways= &irst/ the team releases runnin+/ tested software/ deliverin+ 2usiness value chosen 2y the 0ustomer/ every iteration. 7he 0ustomer can use this software for any purpose/ whether evaluation or even release to end users. 7he most important aspect is that the software is visi2le/ and +iven to the customer/ at the end of every iteration. %econd/ PP teams release to their end users fre1uently as well. PP We2 proAects release as often as daily/ in house proAects monthly or more fre1uently. *. %imple "esi+n= PP uses the simplest possi2le desi+n that +ets the Ao2 done. 7he re1uirements will chan+e tomorrow/ so only do whatGs needed to meet todayGs re1uirements. "esi+n in PP is not a one8time thin+ 2ut an all8the8time thin+. 7here are desi+n steps in release plannin+ and iteration plannin+/ plus teams en+a+e in 1uic' desi+n sessions and desi+n revisions throu+h refactorin+/ throu+h the course of the entire proAect. . Metaphor= -.treme Pro+rammin+ teams develop a common vision of how the pro+ram wor's/ which we call the EmetaphorE. At its 2est/ the metaphor is a simple evocative description of how the pro+ram wor's. PP teams use a common system of names to 2e sure that everyone understands how the system wor's and where to loo' to find the functionality youGre loo'in+ for/ or to find the ri+ht place to put the functionality youGre a2out to add.

,. 0ontinuous 7estin+= PP teams focus on validation of the software at all times. Pro+rammers develop software 2y writin+ tests first/ and then code that fulfills the re1uirements reflected in the tests. 0ustomers provide acceptance tests that ena2le them to 2e certain that the features they need are provided. #. (efactorin+= PP 7eam (efactor out any duplicate code +enerated in a codin+ session. (efactorin+ is simplified due to e.tensive use of automated test cases. ;. Pair Pro+rammin+= All production code is written 2y two pro+rammers sittin+ at one machine. 7his practice ensures that all code is reviewed as it is written and results in 2etter desi+n/testin+/ and code. %ome pro+rammers o2Aect to pair pro+rammin+ without ever tryin+ it. !t does ta'e some practice to do well/ and you need to do it well for a few wee's to see the results. Hinety percent of pro+rammers who learn pair pro+rammin+ prefer it/ so it is recommended to all teams. Pairin+/ in addition to providin+ 2etter code and tests/ also serves to communicate 'nowled+e throu+hout the team. $. 0ollective 0ode Cwnership= Ho sin+le person EownsE a module. Any developer is e.pected to 2e a2le to wor' on any part of the code2ase at any time. :. 0ontinuous !nte+ration= All chan+es are inte+rated into the code2ase at least daily. 7he unit tests have to run 1<<R 2oth 2efore and after inte+ration. !nfre1uent inte+ration leads to serious pro2lems on a software proAect. &irst of all/ althou+h inte+ration is critical to shippin+ +ood wor'in+ code/ the team is not practiced at it/ and often it is dele+ated to people who are not familiar with the whole system. Pro2lems creep in at inte+ration time that are not detected 2y any of the testin+ that ta'es place on an uninte+rated system. Also wea' inte+ration process leads to lon+ code freeKes. 0ode freeKes mean that you have lon+ time periods when the pro+rammers could 2e wor'in+ on important shippa2le features/ 2ut that those features must 2e held 2ac'. 1<. <84our Wor' Wee'= Pro+rammers +o home on time. !n crunch mode/ up to one wee' of overtime is allowed. But multiple consecutive wee's of overtime are treated as a si+n that somethin+ is very wron+ with the process and@or schedule. 11. Cn8site 0ustomer= "evelopment team has continuous access to the customer who will actually 2e usin+ the system. &or initiatives with lots of customers/ a customer representative5i.e Product Mana+er6 will 2e desi+nated for "evelopment team access. 1J. 0odin+ %tandards= -veryone codes to the same standards. 7he specifics of the standard are not important= what is important is that all the code loo's familiar/ in support of collective ownership.