Overview

StandardSDLC
Waterfallmodel
Evolutionaryprototyping
Evolutionarydelivery
Summary

TheSystemDevelopmentLifeCycle

Projectproposal
Preliminaryinvestigation
Requirementsanalysisandspecification
Systemdesign
Detaileddesign
Programming/implementation

 Testing
Installationandchangeover
Maintenance

TheTerribleReality
Muchcurrentsoftwarehasbeencreatedbythecodeandfix
SEmethodology:
Decide,sittingaloneinyouroffice,thatsometool/system/etc
needstobecreated
Decidethatyouknowwhatneedsdoingwithoutfurther
investigation
Whangsomecodetogether
Giveittousers
IFitgetsused,discoverthatithasseriousflaws

Thefalloutfromthisapproach:
softwareultimatelycostsmore
softwareultimatelytakeslongertocreate
withlittle/noexplicitrecognitionofuserrequirements,
softwaremaynotbeusableordowhattheuserneeds
withlittle/noexplicitrecognitionofneedforsystematic
testing(throughoutdevelopment),softwarewillcontain
morebugs
maintenanceisanightmare

 Buildingabridge:

~10%ofjobcostisdesign
restofcostisconstruction
Buildingalargepieceofsoftware:
~15%ofjobcostisconstruction
restofcostisdesign

ThestandardWaterfallModelfordevelopment

Requrements
gathering
Specification

Design

Implementation

Testing

Maintenance

Characteristics

Documentdriven(mainartifactspassedfromstagetostageare
documents)

Notangible(software)resultsuntiltheendofthelifecycle

Performswellwhentheresastableproductdefinitionandyoure
workingwithwellunderstoodtechnologies(cantrapproblemsinthe
early,cheaperstagesoftheproject)

Performswellforprojectswellunderstoodbutcomplex(cantackle
complexityinanorderlyway)

Worksespeciallywellifyouhaveatechnicallyweakor
inexperiencedstaff(structurecanhelpminimizewastedeffort)

Inflexible:canbeverydifficulttofullyspecifyrequirementsatthe
beginningofaproject,monthsoryearsbeforeanyworkingversion
producedforusertolookat

Doesnottakeintoaccountthefactthatrequirementschange(orthat
understandingoftherequirementschanges)

Modelimpliesthatyoucangettherequirementsrightbysimply
writingthemdownandreviewingthemmakesnoallowancefor
prototyping(andthelessonslearnedfromaprototype)

Havingnotangible(software)resultsuntilendoflifecyclecreates
perceptionofslowdevelopmentwithcustomers

Modelputstestingattheendsowhendeadlinesarebeingpushed,
testingcangetsqueezedout.Alsoimpliesthattestingcanbedone
once,inonespot.

Modelimpliesthatoncetheproductisfinished,everythingelseis
maintenance

Backingupispossible,butverydifficult:thesalmonlifecycle
model

EvolutionaryPrototyping
Anagilemethodology:mostfamousrepresentativeSE
methodologyisExtremeProgramming

Initial Designand Refine

Complete
concept implement prototypeuntilacceptable andrelease
initial
prototype
prototype
Agilemethodologiesfeatureadaptivedesigns,notpredictive
designs
Note:agiletechnologiesareNOTthesameascodeandfix
emphasisisondesign

 includinguserinvolvementindesignafundamentalfor
agiletechnologies
design/buildinincrementalstepswiththecodeservingasa
testofthedesignsgoodness

Characteristics:
notthesameasThrowawayPrototyping;codeisnotdiscarded,but
insteadevolvesintothecodeultimatelydelivered
firststep:identifymostvisibleorriskiestpartasyourstartingpoint
mostEPprojectsbeginbyprototypingtheuserinterface,then
evolvingthecompletesystemfromthat
addressesrisksearly,sincedevelopmentstartswithriskiestareas(if
youcantovercomethoseobstacles,projectcanbecancelledearly)

 goodwhenyoudontknowatoutsetexactlywhatyou(ortheuser)
needtobuild
afterfirstpartofsystemisbuilt,demonstrateit;continueprototype
developmentbasedonfeedback:customeroriented
bestsuitedtobusinesssysteminwhichdeveloperscanhavefrequent,
informalinteractionswithendusers.Alsowellsuitedtoanyproject
inwhichyoucangetendusersheavilyinvolved(althoughforlarger
projectstheuserinteractionismorestructuredandformal).

RisksassociatedwithEP
unrealisticscheduleandbudgetexpectations
clientseesfastprogresswithUI,expectssimilarprogresswith
entiresystem
prototypesusuallydesignedtohandlethenominalcases,notthe
exceptionalcasesbutexceptionhandlingcantakeasmuchas
90%ofthefinalcode
mustexplicitlymanagetheexpectationsofusers/clientsasthe
prototypeisrefined

 diminishedprojectcontrol
dontknowatoutsethowlongitwilltaketocreateanacceptable
project
dontknowhowmanyiterationsitwilltake,orhowlongeach
willlast
customersseesteadyprogress,andtendtobelessnervousabout
eventuallygettingaproductthanwithwaterfallmodel

 potentialforpoorenduserfeedback
commonphenomenon:usersdazzledbyglitz,giverubberstamp
approvaltoprototype
sometimesmustprobeformeaningfulfeedback
poorproductperformance
benchmarkperformanceearly,toensureprototypesupports
adequateperformance
dontdevelopquickanddirtycodeforprototypes.Remember,
yourenotthrowingitaway!

 Poordesign
Featurecreep
Finalproductcaninheritdesignpatchesfromintermediate
prototypes
Watchoutforcustomersteeringproductinanunexpected
direction:maysignalneedforfullredesign,notapatch
DontfocusdesignentirelyonUI(dontforgetotherpartsof
systemthatshouldstronglyinfluencetheoveralldesign)

PositivesideeffectsofEP,reportedintheliterature:
Improvedmoraleofendusers,customers,anddevelopers
becauseprogressisvisible
Earlyfeedbackonwhetherthefinalsystemwillbeacceptable
Decreasedoverallcodelengthbecauseofbetterdesignsand
morereuse
Lowerdefectratesbecauseofbetterrequirementsdefinition
Smoothereffortcurves,reducingthedeadlineeffect(whichis
commonwhenusingwaterfallmethod)