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,
[Link]
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,
[Link]
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
[Link],
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)