Software Development Life Cycle Models by Raymond Lewallen at CodeBetter.

com
From URL: http://codebetter.com/blogs/raymond.lewallen/archive/2005/07/ !/ 2" #.asp$

% was as&ed to p't together this high(level and traditional so)tware li)e cycle in)ormation as a )avor )or a )riend o) a )riend* so % tho'ght % might as well share it with everybody.

The General Model

+o)tware li)e cycle models describe phases o) the so)tware cycle and the order in which those phases are e$ec'ted. ,here are tons o) models* and many companies adopt their own* b't all have very similar patterns. ,he general* basic model is shown below: -eneral Li)e .ycle /odel

0ach phase prod'ces deliverables re1'ired by the ne$t phase in the li)e cycle. Re1'irements are translated into design. .ode is prod'ced d'ring implementation that is driven by the design. ,esting veri)ies the deliverable o) the implementation phase against re1'irements.

Req irements
2'siness re1'irements are gathered in this phase. ,his phase is the main )oc's o) the pro3ect managers and sta&e holders. /eetings with managers* sta&e holders and 'sers are held in order to determine the re1'irements. 4ho is going to 'se the system5 6ow will they 'se the system5 4hat data sho'ld be inp't into the system5 4hat data sho'ld be o'tp't by the system5 ,hese are general 1'estions that get answered d'ring a re1'irements gathering phase. ,his prod'ces a nice big list o) )'nctionality that the system sho'ld provide* which describes )'nctions the system sho'ld per)orm* b'siness logic that

processes data* what data is stored and 'sed by the system* and how the 'ser inter)ace sho'ld wor&. ,he overall res'lt is the system as a whole and how it per)orms* not how it is act'ally going to do it.

Desi!n
,he so)tware system design is prod'ced )rom the res'lts o) the re1'irements phase. 7rchitects have the ball in their co'rt d'ring this phase and this is the phase in which their )oc's lies. ,his is where the details on how the system will wor& is prod'ced. 7rchitect're* incl'ding hardware and so)tware* comm'nication* so)tware design 8U/L is prod'ced here9 are all part o) the deliverables o) a design phase.

"mplementation
.ode is prod'ced )rom the deliverables o) the design phase d'ring implementation* and this is the longest phase o) the so)tware development li)e cycle. For a developer* this is the main )oc's o) the li)e cycle beca'se this is where the code is prod'ced. %mplementation my overlap with both the design and testing phases. /any tools e$ists 8.7+0 tools9 to act'ally a'tomate the prod'ction o) code 'sing in)ormation gathered and prod'ced d'ring the design phase.

Testin!
:'ring testing* the implementation is tested against the re1'irements to ma&e s're that the prod'ct is act'ally solving the needs addressed and gathered d'ring the re1'irements phase. Unit tests and system/acceptance tests are done d'ring this phase. Unit tests act on a speci)ic component o) the system* while system tests act on the system as a whole. +o in a n'tshell* that is a very basic overview o) the general so)tware development li)e cycle model. ;ow lets delve into some o) the traditional and widely 'sed variations.

#aterfall Model
,his is the most common and classic o) li)e cycle models* also re)erred to as a linear(se1'ential li)e cycle model. %t is very simple to 'nderstand and 'se. %n a water)all model* each phase m'st be completed in its entirety be)ore the ne$t phase can

begin. 7t the end o) each phase* a review ta&es place to determine i) the pro3ect is on the right path and whether or not to contin'e or discard the pro3ect. Unli&e what % mentioned in the general model* phases do not overlap in a water)all model.

4ater)all Li)e .ycle /odel

$dvanta!es
+imple and easy to 'se. 0asy to manage d'e to the rigidity o) the model < each phase has speci)ic deliverables and a review process. =hases are processed and completed one at a time. 4or&s well )or smaller pro3ects where re1'irements are very well 'nderstood.

Disadvanta!es
7d3'sting scope d'ring the li)e cycle can &ill a pro3ect ;o wor&ing so)tware is prod'ced 'ntil late d'ring the li)e cycle. 6igh amo'nts o) ris& and 'ncertainty. =oor model )or comple$ and ob3ect(oriented pro3ects. =oor model )or long and ongoing pro3ects. =oor model where re1'irements are at a moderate to high ris& o) changing.

%&Shaped Model
>'st li&e the water)all model* the ?(+haped li)e cycle is a se1'ential path o) e$ec'tion o) processes. 0ach phase m'st be completed be)ore the ne$t phase begins. ,esting is emphasi@ed in this model more so than the water)all model tho'gh. ,he testing proced'res are developed early in the li)e cycle be)ore any coding is done* d'ring each o) the phases preceding implementation. Re1'irements begin the li)e cycle model 3'st li&e the water)all model. 2e)ore development is started* a system test plan is created. ,he test plan )oc'ses on meeting the )'nctionality speci)ied in the re1'irements gathering. ,he high(level design phase )oc'ses on system architect're and design. 7n integration test plan is created in this phase as well in order to test the pieces o) the so)tware systems ability to wor& together. ,he low(level design phase is where the act'al so)tware components are designed* and 'nit tests are created in this phase as well. ,he implementation phase is* again* where all coding ta&es place. Ance coding is complete* the path o) e$ec'tion contin'es 'p the right side o) the ? where the test plans developed earlier are now p't to 'se.

?(+haped Li)e .ycle /odel

$dvanta!es
+imple and easy to 'se. 0ach phase has speci)ic deliverables. 6igher chance o) s'ccess over the water)all model d'e to the development o) test plans early on d'ring the li)e cycle. 4or&s well )or small pro3ects where re1'irements are easily 'nderstood.

Disadvanta!es
?ery rigid* li&e the water)all model. Little )le$ibility and ad3'sting scope is di))ic'lt and e$pensive. +o)tware is developed d'ring the implementation phase* so no early prototypes o) the so)tware are prod'ced. /odel doesnBt provide a clear path )or problems )o'nd d'ring testing phases.

"ncremental Model
,he incremental model is an int'itive approach to the water)all model. /'ltiple development cycles ta&e place here* ma&ing the li)e cycle a Cm'lti(water)allD cycle. .ycles are divided 'p into smaller* more easily managed iterations. 0ach iteration passes thro'gh the re1'irements* design* implementation and testing phases. 7 wor&ing version o) so)tware is prod'ced d'ring the )irst iteration* so yo' have wor&ing so)tware early on d'ring the so)tware li)e cycle. +'bse1'ent iterations b'ild on the initial so)tware prod'ced d'ring the )irst iteration.

%ncremental Li)e .ycle /odel

$dvanta!es
-enerates wor&ing so)tware 1'ic&ly and early d'ring the so)tware li)e cycle. /ore )le$ible < less costly to change scope and re1'irements. 0asier to test and deb'g d'ring a smaller iteration. 0asier to manage ris& beca'se ris&y pieces are identi)ied and handled d'ring its iteration. 0ach iteration is an easily managed milestone.

Disadvanta!es
0ach phase o) an iteration is rigid and do not overlap each other. =roblems may arise pertaining to system architect're beca'se not all re1'irements are gathered 'p )ront )or the entire so)tware li)e cycle.

Spiral Model
,he spiral model is similar to the incremental model* with more emphases placed on ris& analysis. ,he spiral model has )o'r phases: =lanning* Ris& 7nalysis* 0ngineering and 0val'ation. 7 so)tware pro3ect repeatedly passes thro'gh these phases in iterations 8called +pirals in this model9. ,he baseline spiral* starting in the planning phase* re1'irements are gathered and ris& is assessed. 0ach s'bse1'ent spirals b'ilds on the baseline spiral. Re1'irements are gathered d'ring the planning phase. %n the ris& analysis phase* a process is 'nderta&en to identi)y ris& and alternate sol'tions. 7 prototype is prod'ced at the end o) the ris& analysis phase. +o)tware is prod'ced in the engineering phase* along with testing at the end o) the phase. ,he eval'ation phase allows the c'stomer to eval'ate the o'tp't o) the pro3ect to date be)ore the pro3ect contin'es to the ne$t spiral. %n the spiral model* the ang'lar component represents progress* and the radi's o) the spiral represents cost.

+piral Li)e .ycle /odel

$dvanta!es

6igh amo'nt o) ris& analysis -ood )or large and mission(critical pro3ects. +o)tware is prod'ced early in the so)tware li)e cycle.

Disadvanta!es
.an be a costly model to 'se. Ris& analysis re1'ires highly speci)ic e$pertise. =ro3ectBs s'ccess is highly dependent on the ris& analysis phase. :oesnBt wor& well )or smaller pro3ects.

7nd thatBs it. %) yo' have any inp't* especially yo'r views on advantages and disadvantages o) any partic'lar model* )eel )ree to leave them in the comments and % can add them to my copy.