0% found this document useful (0 votes)
2K views

(CH4XR) Alternative Life Cycle Models

The document discusses alternative life cycle models to the traditional waterfall model for developing software systems. It describes the prototyping life cycle model, where prototypes are developed to help refine requirements before beginning full development. Prototypes are meant to be "disposable" once their purpose is served, to avoid them becoming the final system. The document also mentions incremental development, where the system is developed in increments with each build upon the last, unlike the prototyping approach which discards prototypes.

Uploaded by

Cody Yeung
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
2K views

(CH4XR) Alternative Life Cycle Models

The document discusses alternative life cycle models to the traditional waterfall model for developing software systems. It describes the prototyping life cycle model, where prototypes are developed to help refine requirements before beginning full development. Prototypes are meant to be "disposable" once their purpose is served, to avoid them becoming the final system. The document also mentions incremental development, where the system is developed in increments with each build upon the last, unlike the prototyping approach which discards prototypes.

Uploaded by

Cody Yeung
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 5

MScITStudyMaterial

July2007Edition
ComputerScienceDepartment,UniversityofCapeTown
|MITNotesHome|EditionHome|

AlternativeLifeCycleModels
Prev Chapter2.Lifecyclesanddevelopmentmethods Next

AlternativeLifeCycleModels
Usingthewaterfalllifecycletoguidesystemdevelopment

Thewaterfalllifecyclemodelcanbeusedasaframeworkforsystemdevelopment.Thatis,itdescribesthe
basicprojectstructurewhichmanypeoplehavefoundtobeusefulindevelopinglargescalesoftware
systems.However,thisdoesnotmeanithastobeusedexactlyasdescribedinthisunit.

Therearemanywaysinwhichalifecyclemodelcanbeusedinpractice.Forexample,feasibilitystudiesare
notsocommonthesedays.Oftenamoreinformalapproachistakeninevaluatingtheworthofaproject.
Also,thevariousanalysisanddesignstagescaneitherbeseparatestages,orbeincorporatedintoasingle
activityofanalysisanddesignthiswouldespeciallymakesenseiftheseactivitiesweretobeperformed
bythesamepersonorteam.

Foreachrealworldproject,thedevelopersandprojectmanagermustconsiderhowbesttousealifecycle
toguidetheprojectplan.However,whatisimportantisthattheprojectplannerconsiderseachvarious
stage.Itismuchbettertodeliberatelyleaveoutastagehavingcarefullythoughtaboutthedecision,than
tomissoutastagebyaccidentsuchoversightscanresultintheprojectfailingforthereasonsoutlinedin
thepreviouschapter.

Toreiteratethewaterfalllifecycle(oranyotherlifecyclemodel)shouldnotbeviewedasaprescriptive
orrigidmodel,butratheraframeworkwhichcanbeadaptedtobestsuitthecircumstancesofaparticular
project.

Advantagesofwaterfalllifecyclemodel

ThereareanumberofadvantagesoftheWaterfalllifecycleoverinformalcodeandfixapproaches:

Thestagesconsistofwelldefinedtaskswhichpromotethechancesofgoodscheduleandcost
estimation(ifallstagesoccurintheexpectedsequenceonceonly).

Thedeliverablesprovidetargetsormilestonestoseehowfarateamhasreachedinthedevelopment
process.

Thelifecycleisbrokenintowelldefinedstagessothestaffexpertisecanbeusedefficiently(e.g.a
datamodelleronlyneedstoworkoncertainstages,aprogrammeronlyonotherstagesandsoon).

Atanyonetimetheprojectteamknowwhatshouldbehappening,andthedeliverable(s)theyareto
produce.

Limitationsofwaterfalllifecyclemodel

However,therearealsoanumberoflimitationsofthewaterfallmodel:

Althoughtherequirementsarespecifiedearlyon,thisisadocumentorsetofdiagrams,andrealuser
understandingandfeedbackwillnotoccuruntilthesystemisimplemented,whichwillbetoolate(or
verycostly)tochange.

Theusermaynotbeabletodescribetherequirementsofthedesiredsysteminanydetailearlyon.
Themodeldoesnotstresstheneedtoanticipateforchangessomesystemstakeyearstodevelop,
butoncetheearlystageshavebeencompletedthemodelcommitstheprojecttoafixedspecification
ofthesystem.

Manyprojectsbasedonthewaterfallmodelstresstheimportanceofcertainproducts(documents)
beingdeliveredatcertaintimesitispossibleforaprojecttobecomemanagedinabureaucratic
way,withdocumentsbeingdeliveredonschedule,butthefocusdriftingawayfromausable,effective
systemfortheusers.

Ifaproblemisidentifiedatalaterstage,themodeldoesnotmakeiteasy(orcheap)toreturntoan
earlystagetorectifythemistake(sinceallintermediatestepswillneedtoberepeated,resultingin
significant,unplanned,timeandresourcecosts).

Sinceforsomeprojectsthelimitationsoutweightheadvantages,otherlifecyclemodelshavebeen
developed.Thenextsectionpresentsanoverviewofsomeofthealternativelifecycles.

Prototypinglifecycle(disposableprototypeapproach)

Aprototypesystemisasmallerversionofpart(s)ofthefinalsystemthatgivestheuserasenseofthelook
andfeelthatthefinishedsystemmayhave.Ithassomeofthecorefeaturesofthefinalsystemandwhere
featuresandfunctionsareomitteditpretendstobehavelikethefinalsystem.

Wherethesystemtobedevelopedisatrulynewsystem,theremaybenoclearrequirementsofwhatit
shoulddo.Theuserhassomeideasbutonlyinavagueway.Thedevelopersmayhaveotherideas.By
buildingaprototype,boththedevelopersandusershavesomereal,visibleworkingsystemmodelonwhich
tofocustheirideas.Theprototypecanbereviewed,changesmadebydevelopersandusers.Theprototype
isthenanalysedandformsthebasisfortherequirementsspecification,andperhapsevensomeofthe
design.Ifthereisstilluncertaintyofthenewsystemandquestionsstillremain,furtherprototypescanbe
developed(oranexistingprototypeextended).

Oncethedevelopersandusershaveaclearideaofthenewsystemrequirements,theprojectcanthen
moveintoamoretraditionaldevelopmentcycleandtheprototypesarethrownaway.Thisisimportant,
sinceprototypesaregeneratedquickly,withmanygapsinthefunctionality,andtheyarenotdesignedtobe
robustorcomplete,sincetheyarejusttobepartlyworkingmodelstoaiddeveloperanduser
understanding.

Toprototypequicklyandeffectively,prototypesmustbequickandeasytobuild.Fourthgeneration
languages(4GLs),graphicaluserinterface(GUI)tools,visualprogramminglanguages(likeVisualBasicand
Delphi)andofftheshelfcomponentsarecommonlyusedtogluetogetheraprototypeinaroughandready
way.Forthiskindofdisposableprototypeitdoesntmatteriftherearelimitations,ordifferentpartsofthe
programdontcommunicatewitheachother,oritonlyworkswithalimitedsetoftestdataaslongasthe
prototypehelpstheusersgainanideaofhowthefinalsystemmightbe,andthisisusedtoderivea
detailedideaofthenewsystemrequirements,theprototypehasdoneitsjob.

Adiagramofthedisposableprototypinglifecyclestagesispresentedasfollows:
Ascanbeseen,aftersomeinitialanalysisasetofobjectivesisdevelopedfortheprototype.These
objectivesmaydifferbetweenprojectsperhapsdetailedrequirementsneedtobeelicited,perhaps
alternativeuserinteractionsaretobeevaluatedandsoon.Eachversionoftheprototypeshouldbe
specified,sothatthesoftwarecanbecorrectlydesignedandimplementedaprototypethatdoesnotfully
testtheobjectivesisawasteofresources,andmightevenbemisleading.Oneceaprototypehasbeen
completed,itshouldbeevaluatedagainstitsspecification(i.e.thedetailedmodeloftheobjectives)and
eitherchangesbemadeandanewprototypeproduced(inaprototypedevelopmentcycle),orifthe
specifiedobjectivesaremet,theprojectcanmoveontotraditionalwaterfalllifecyclestages,informedby
whathasbeenlearntduringtheprototypingactivities.

Advantagesofprototypinginclude:

Usersgetanearlyideaofthefinalsystemfeatures.
Theprototypeprovidesanopportunitytoidentifyproblemsearlyon,andtochangetherequirements
appropriately,beforecostlylaterstageshavebeenperformed.

Theprototypeisamodelthatallusersshouldbeabletounderstandandprovidefeedbackon,thus
theprototypecanbeanimportantwaytoimprovecommunicationbetweenusersanddevelopers.

Itmaybepossibletouseaspectsoftheprototypespecificationanddesigninthefinalsystem
specificationanddesign,thussomeoftheprototypedevelopmentresourcescanberecouped.

However,amajorproblemwiththisdisposableuseofprototypesisthatunlessthedeveloperisvery
strongwilledtheprototypeturnsintotherealsystem.Atthispoint,itisprobablybesttodeclarethesystem
afailureandgetanewjob!Theclientsseetheprototype,thinkthatthefinalsystemisclosetocompletion
andsodemandthattheprototypejustbecleanedupandreleasedtothem.However,prototypesare
deliberatelyputtogetherquicklyandroughly.Whattheuserperceivesasaquickandeasytaskmaytake
severalweeks,monthsorevenyearsofdesign,codingandtesting.Also,theprototypetechnologymaynot
evenbeabletohandletheloadoftherealsystem.Thetoolsusedtoproducetheprototypearemeantto
begoodatproducingprototypesandarefarfromoptimalinhandlinghugevolumesofdataandanyspeed.

Note

Amodelwhereprototypesarenotdiscarded,butextendedanddevelopedintopartsofthe
finalsystemthemselvesisknownasevolutionarydevelopmentorevolutionaryprototyping.
Weshallnotgointothedetailsofthisapproach,itisenoughtosaythatthisapproach
attemptstomaintainalltheadvantagesofprototypingwhilesavingresourcesby
incorporatingaversionofaprototypeintothefinalsystem.Themainpitfallofsuchan
approachisthatwithoutstrongmanagementitcanfallbackintotheoldcodeandfix
approachtosystemdevelopment.

Incrementaldevelopmentsystemlifecycle

Incrementalapproachesattempttomaintainsomeoftheadvantagesofdisposableprototypingoverthe
purewaterfallmodel,buttoavoidthediscardingofallearlydevelopment.Theincrementaldevelopmentlife
cycleisacompletelifecyclemodelinitsownright,ratherthanasupplementtoawaterfallmodel.

Inincrementaldevelopment,therequirementsareanalyzedasusualandabroadarchitecturaldesignis
drawnup.Thisisalargescaleviewofthefinalsystembrokendownintothemainfunctionalareas.The
remainderofthedevelopmentisbrokenintostages.Ateachstage,asetoffunctionsareidentified.These
areimplementedontopoftheexistingversionofthesystemusingthetraditionalapproachesofdetailed
design,codingandtesting.Ideally,themostimportantfunctionsareimplementedfirstandsuccessive
stagesaddnewfunctionalityinorderofpriority.

Bydoingthis,thefulldevelopmenttaskisbrokendownintosmallermoremanageableareasallowingany
problemsinimplementationtobehighlightedbeforethefullsystemiscompleted.Thismaybeparticularly
usefulwheretheremaybetechnologicaldifficultieswhichcouldonlybeidentifiedbytryingtoimplement
thefullsystem.

IncrementaldevelopmentapproachisNOTaversionofCODEANDFIX

Itimportanttounderstandthattheincrementaldevelopmentapproachisnotjustanothernameforthe
codeandfixapproachthatwasthemainwaysystemsdevelopedbeforedevelopersbeganusingthe
waterfalllifecycletoguidemorestructuredsystemsdevelopment.Featuresthatdifferentiateincremental
systemdevelopmentfromcodeandfixinclude:

Fullyworking,androbust,subsystemsaredeveloped

Systemdesignfocusesonmodularityidentifyingsubsystemsthancanbeproperlydevelopedin
isolationinsuchawayastonotlimittheotherpartsofthefinal,overallsystemwithwhichthesub
systemmustinteract
Incrementaldevelopmentisnotnecessarilyincrementaldelivery

Althoughanoptionfortheprojectmanagers,eventhoughasystemmaybedevelopedasanumberof
modularsubsystems,itisnotnecessarilythecasethateachsubsystemisdeliveredtotheuserassoonas
itiscomplete.Reasonsfordelayingdeliverymayincludecomplexitiesofintegrationanexistingsystemwith
smallpartsofanewsystemitmightonlymakesensetowaituntilacoherentcollectionofsubsystemsis
completebeforeinstallation.

However,if,attheendofeachstage,thesystemisreleasedtotheclient,thisiscalledincrementaldelivery.
Theclientthengetsregularversionsofthesoftwareandisabletoperceivetheprogressbeingmadeonthe
project.Itmaysometimeshappenthattheclientshaveoverspecifiedtheoriginalrequirementsandon
receivingareleasedeclarethemselveshappywiththesystemsofarandnofurtherworkisnecessary.This
canbeparticularlylucrativeiftheoriginalcontractwasafixedprice!

Thepossibilityofincrementaldeliveryofasystemtousersisoneofthemotivationsfortheadoptionofan
incrementaldevelopmentapproachtosystemsdevelopment

Incrementaldevelopmentisnotsimplydeliveringtidiedupprototypes

Althoughbothdisposableprototypingandincrementaldevelopmentinvolveproducingworkingsubsystems,
therequirementsforthesesubsystemsareverydifferent.Prototypesneedtobecheaptodevelop,donot
needtoberobustorfullyfunctional,anddonotneedtobeabletoworkwithothersubsystems.Asub
systemtobefullydevelopedduringanincrementalsystemdevelopmenthastoberobust,fullyfunctional
andfullyabletointeractwithothersubsystemsoncetheyaredeveloped.Forthisreason,thesubsystem
developedusinganincrementaldevelopmentapproacharemoreexpensiveandtimeconsumingtodevelop.
Also,beforeasubsystemisdeveloped,awiderunderstandingoftheimpactandinteractionofeachsub
systemmustbeunderstoodandspecified,sothatthewayonesubsystemisdevelopeddoesnothavea
negativeimpactonthewaylatersubsystemsaredeveloped.

However,anincrementaldevelopmentapproachhasthefollowingadvantagesoverwaterfallanddisposable
prototypingapproaches:

Theprocessismoreresponsivetochanginguserrequirementsthanawaterfallapproachlatersub
systemscanberespecified,alsoamodularapproachcanmeanmaintenancechangesaresimpler
andlessexpensive.

Thedevelopmentresourcesforeachsubsystemarenotwasted,sincethesubsystemsformpartof
thefinalsystemdeliveredtousers.

Thereisanopportunityforincrementaldeliverytousers,sotheuserscanbenefitfrompartsofthe
systemdevelopmentwithouthavingtowaitfortheentirelifecycletorunitscourse.

Completeprojectfailureislesslikely,sinceuserswillhavesomeworkingsubsystemseveniftime
andmoneyrunoutbeforethecompletesystemisdelivered.

Therearesomecosts,anddangersassociatedwithanincrementaldevelopmentapproachthough:

thisdevelopmentmodelreliesoncloseinteractionwiththeusers.iftheyarenoteasilyavailableor
slowinevaluatingprototypes,thewholeprocesscangrindtoahalt

therelianceonuserinvolvementexacerbatesthealreadydifficulttaskofestimatingtheamountof
timeandbudgetrequired

highuserinvolvementmeansthatresourcesaredrawnawayfromthenormaloperationofthe
organisationduringsystemdevelopment

Exercise2

Whatisasystemlifecycle?Isthereonlyone?

You might also like