Agile Software Development The most important Methods – Status Report 2010 BQI Research [email protected]
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Agile Software Development
The most important Methods –
Status Report 2010
BQI Research
Table of ConTenTs1 INTRODUCTION 42 AGILITY IN SOFTWARE DEVELOPMENT 5
2.1 Definition“Agility” 52.2 Theagilemanifesto 5
3 AGILE PROCEDURE MODELS 73.1 ActiF 93.2 AdaptiveSoftwareDevelopment(ASD) 93.3 AgileEnterprise(formerlyXBreed) 103.4 AgileModelDrivenDevelopment(AMDD) 113.5 BehaviorDrivenDevelopment(BDD) 123.6 Crystal 133.7 DesignDrivenDevelopment(D3) 143.8 DynamicSystemDevelopmentMethod(DSDM) 153.9 EclipseWayProcess 173.10 EvolutionaryProcessForIntegratingCots-BasedSystems(EPIC) 173.11 EvolutionaryProjectManagement&ProductDevelopment(EVO) 193.12 ExtremeProgramming(XP) 203.13 FeatureDrivenDevelopment(FDD) 253.14 Iconix 293.15 Internet-SpeedDevelopment 313.16 LeanSoftwareDevelopment(LSD) 323.17 MicrosoftSolutionsFrameworkForAgileSoftwareDevelopment(MSF4ASD) 363.18 Mobile-D 373.19 RapidApplicationDevelopment(RAD) 373.20 Scrum 383.21 TestDrivenDevelopment(TDD) 403.22 UnifiedProcess(UP) 413.23 UsabilityDrivenDevelopment(UDD) 46
4 EVALUATION 494.1 Coverageofdisciplinesinsoftwareengineering 494.2 Profilesafterevaluatingthemethods 524.3 Tables 58
5 LINKS 686 SUMMARY 707 ABOUTBQI 718 DISCLAIMER 73
foReWoRD Rapidlygrowingbusinessrivalry,shortenproductlife-cycles,highcomplexityaswellashighexpectationsconcerningqualityleadtothefactthatsoftwareshouldnot“only”beinnovativeanduseful.Inordertostaycompetitiveasabusinesscompany,applicationshavetobedeployedmorequicklytotheuser.User-requests that change very quickly should be answered short-termed.Thus,thedevelopmentofsoftwarehastobecarriedoutquickly,flexible,effi-cientandundercomplianceofaconstantlevelofquality.
Throughtheserequirements,avarietyofsoftwareengineeringmethodshavebeenevolvedoverthecourseofthelastyears,whicharecategorizedas“agile”incommonsense.Asaconsequenceconsulting-andsystemhousearefacedwiththissubjectuponitscustomersingrowingextent.Eitherinthewaythatprojectsarealreadyaccomplished“agile”or inthewaythatcustomersaregettingsupportfromusduringintroducingappropriatemethod(s).
Assoonasyouconcernyourselfabout“agilesoftwaredevelopment”,youmayrecognizequicklythatthereareplentyofmethodsandthatitisnoteasytoidentifytheonesthatcomeintoconsiderationforyourobjective.Thereforewedesignedthisoverview–includingatryofevaluatingeverysinglemethod.
Despiteknowingapproximatelyinwhatwearegettinginto,whenitcametoinquiryweweresurprisedbythediversityofmethodsthatareinternationallyexisting.Wehadtolimitourselvesinordertopublishthissurveyasintendedin2010.Thus,afewmethodsweknowwillnotbefurtherdiscussed–youwillfindalistoftheseinchapter4.
Theauthorswishthegentlereaderasmanynewinsightsastheauthorshadthemwhileresearching.
TheBQI’sProjectTeam
Berlin,June2010
eXeCUTIVe sUMMaRY Thisreportaddressesparticularlythesemethodsofagilesoftwaredevelop-ment, which have been internationally established until now. On the basisofpublicsourcesanddocumentation,26methodswillbeshowninthefirstpart.
In thesecondpart, thesemethodswillbeevaluatedbyaseriesofcriteria,whichhavebeendevelopedbyourgroupofauthors.Ithasbeenexamined,whichdisciplinesofsoftware-engineeringarecovered,whichtypesofprojectsaresupported,iftherearefocusesconcerningbranchesandiftherearetoolstothemethodsavailable.Furthermore,thelevelofnormalization,standardi-zation,certification, licensingandthesupportduringadoptionandusehasbeenexamined.Last,butnotleastthepopularityandthelevelofdissemina-tionwith thehelpofpredefinedparameterhasbeen includedregarding toevaluation.
The object of evaluationwas to give the persons responsible during appli-cation-developmentasortofcompasstothephaseoforientationbeforetheadoptionofagilemethods.Thefiguresatthechapterofevaluationarechoseninawaythatthereadershouldbeabletoemergetwoorthreemethodsformorein-depthresearch,whenheapplieshisowncriteriaofdecision.
4
InTRoDUCTIon 1 Agilemethods facilitate projects in software developmentmore andmore.AccordingtoGartners“HypeCycleforApplicationDevelopment”(2008and2009),agilemethodshavebeenclassifiedas“EarlyMainstream”(seefigure1).Concluding,thismethodology(inGartnerclassifiedas“technology”)hasalreadybeenusedandworkedout.Vendors,themethoditselfandtheadop-tionofagilemethodswillevolverapidlyinthenextyears.Further,Gartnerpresumesitwilltakeaboutfivetotenyearsuntilthe“plateauofproductivity”isreached,inwhichagilemethodswillbeacceptedinmostenterprises.Fromthen on a substantial benefitwill be recognizable. Yet the analysts do notarriveatanagreementcompletely.AccordingtoacontemporarystudyfromForrester,agilesoftwaredevelopmentprocessesappeartobealreadyestab-lished.
However,whatmeansagilityinsoftwaredevelopmentacutally?Whatcharac-terizesagilesoftwaredevelopment?Whichagilemethodsexistalready?
The Best Quality Institute and its team of international authors have con-cernedthemselveswiththeseissuesintenselyandsummeduptheachievedinsightsinthisglobalstudy.Popularmethods(like“Scrum”or“ExtremePro-gramming”)aswellaslessknownones(like“Iconix”)havebeenanalyzed.Inordertogainatruebenefitforthereader,attheendanevaluationintermsofdifferentcriteriatakesplace(seechapter5).
HypeCycleforAppli-Figure1:cationDevelopment2008(source:Gartner,HypeCycleforApplicati-
onDevelopment2008)
5
aGIlITY In sofTWaRe DeVeloPMenT 2
DefInITIon “aGIlITY”2.1 When the term “Agility” comes into onesmind, people think of “mobility”,“adaptability”and“flexibility”.Once itgetsconnectedwith theword“soft-waredevelopment”,thequestion“whatdoesitmeanbasically?”arises.Basedon the “manifest for agile software development” the following points arerelevanttothedefintion:
Earlydeploymentofworkingsoftware ⬗Customer-requestscanbeincorporatedatanytime ⬗Collaborationoftheinvolvedpersonsdaily ⬗Face-to-faceCommunicationamongallinvolvedpersons ⬗Theteamisself-organizing ⬗Theteamachievesgrowingeffectivityautonomously ⬗
Agilesoftwaredevelopmenttakeschangesasachancetoacompetitiveadvan-tageinordertomeetcustomersrequestsasflexibleaspossibleandwithoutabigbureaucratic overhead.Thiswayahighcustomer-satisfaction canbeachieved.Theadaptabilityiscrucialtothewholeagileprocess–itcanleadto thepoint thatchangeshave tobesetup, if thesechangesappear tobereasonable,resultinginanadvantage.Now“agilesoftwaredevelopment”canbedefinedasansoftwaredevelopmentprocess:
whichadoptsnewsituationsflexible,fastandwithoutabigbureaucra- ⬗ticoverheadthattakeschangesasadvantage ⬗atwhichinvolvedpersonsmeeteachotherinface-to-face-communica- ⬗tionanddailycollaborationinwhichtheproject-teamisself-organizingandresponsibleforgro- ⬗wingeffectivityinwhichcustomerrequestscanbeincorporatedatanytime ⬗thatdeploysanoperatingsoftware(notaprototype!)early ⬗
The aGIle ManIfesTo2.2 Theagilemanifesto(www.agilemanifesto.org)wasfoundedin2001byKentBeck,MartinFowlerandKenSchwaber;itrepresentsanewparadigminsoft-ware development. It describes away off from rigid, inflexible and formalprocessestowardflexibilityandcommunication.Theagilemanifestoencom-passesfourvaluationsandtwelveprinciples.
Thosevaluationsare:
Individualsandinteractionsoverrideprocessesandtools. ⬗Viableproductsoverrideexpandeddocumentation ⬗Collaborationwiththecustomeroverridescontract ⬗Dwellingonchangesoverridesrigoroustracingofconcepts ⬗
6
Theprinciplesoftheagilemanifestoare:
Ourhighestpriorityistosatisfythecustomerthroughearlyandconti- ⬗nuousdeliveryofvaluablesoftware.Welcomechangingrequirements,evenlateindevelopment.Agilepro- ⬗cessesharnesschangeforthecustomer‘scompetitiveadvantage.Deliverworkingsoftwarefrequently,fromacoupleofweekstoacoup- ⬗leofmonths,withapreferencetotheshortertimescale.Businesspeopleanddevelopersmustworktogetherdailythroughout ⬗theproject.Buildprojectsaroundmotivatedindividuals.Givethemtheenviron- ⬗mentandsupporttheyneed,andtrustthemtogetthejobdone.Themostefficientandeffectivemethodofconveyinginformationto ⬗andwithinadevelopmentteamisface-to-faceconversation.Workingsoftwareistheprimarymeasureofprogress. ⬗Agileprocessespromotesustainabledevelopment.Thesponsors,deve- ⬗lopers,andusersshouldbeabletomaintainaconstantpaceindefini-tely.Continuousattentiontotechnicalexcellenceandgooddesignenhan- ⬗cesagility.Simplicity–theartofmaximizingtheamountofworknotdone–is ⬗essential.Thebestarchitectures,requirements,anddesignsemergefromself- ⬗organizingteams.Atregularintervals,theteamreflectsonhowtobecomemoreeffec- ⬗tive,thentunesandadjustsitsbehavioraccordingly
The agilemanifesto is the foundation of agile softwaredevelopment.Agileproceduremodelsapplyonthatfoundationandimplementthevaluationsandprinciplesoftheagilemanifesto.
7
aGIle PRoCeDURe MoDels 3 Duringoursubstantialresearchmanyas“agile”namedmethodshavebeenfound.Inthesecondlistbelowyouwillfindthosemethodsthatareindeedknowntous,butwhicheitherdonotfittoourscaleorappeartobetooexcep-tionallytobediscussedhere.
Listoftheanalyzedmethods:
ActiF ⬗AdaptiveSoftwareDevelopment(ASD) ⬗AgileEnterprise(formerlyXBreed) ⬗AgileModelDrivenDevelopment(AMDD) ⬗BehaviorDrivenDevelopment(BDD) ⬗Crystal ⬗DesignDrivenDevelopment(D3) ⬗DynamicSystemDevelopmentMethod(DSDM) ⬗EclipseWayProcess ⬗EvolutionaryProcessforintegratingCOTS-BasedSystems(EPIC) ⬗EvolutionaryProjectManagement&ProductDevelopment(EVO) ⬗ExtremeProgramming(XP) ⬗FeatureDrivenDevelopment(FDD) ⬗Iconix ⬗InternetSpeedDevelopment ⬗LeanSoftwareDevelopment(LSD ⬗MicrosoftSolutionsFrameworkforagileDevelopment(MSF4ASD) ⬗Mobile-D ⬗RapidApplicationDevelopment(RAD) ⬗Scrum ⬗TestDrivenDevelopment(TDD) ⬗UnifiedProcess(UP) ⬗UsabilityDrivenDevelopment(UDD) ⬗
Agile,butnotwidespreadmethods:
UniversalApplication ⬗UPXS ⬗
Concerningthefollowingmethodshasbeenascertainedthatthesedonotfittoourdefinitionof“agility”(seechapter3.1),hencecannotbeclassifiedas“agil”andwerenotanalyzedfurther:
PragmaticProgramming: ⬗~isnotanagilemethod,butaguidelinetoadoptthesethingsfromothermethods,whichappeartobereasonable.Itgoesbacktothebook“DerPragmatischeProgammierer”(thepragmaticprogrammer)fromAndrewHuntandDavidThomas.Software-Expedition: ⬗~isnotanagilemethod,butadissertationinwhichitisexaminedtowhatextenttheguidingprincipleofanexpeditioncanleadtoabetterunderstandingofsoftwaredevelopmentprojects.ProcessPatterns: ⬗
8
~representaproven(pattern-)processthatsolveafrequentlyoccur-ringproblem.Theproblemembodiesaconcretesituation,whichcanariseduringthesoftwaredevelopment.Theprocessdescribesabunchofactivitiesthatcanbeimplementedtosolvetheproblem.Catalysis: ⬗~isnotanagilemethod,butanapproachtoshapeonthefootofUML(seehttp://www.catalysis.org/index.html).SoftwarePrototyping: ⬗~isnotautomaticallyagile–itjusttellsusthatitshouldbeworkedwithprototypes.SoftwareCraftsmanship ⬗~isnotanagilemethod,butanextensionoftheagilemanifestocon-cerningassertionsto“softwarehandwerkskunst”(softwarecraftsman-ship)(seehttp://manifesto.software-craftsmanship.org/)
9
aCTIf 3.1
ActiFisaproceduremodelconcerningsoftwareplanningandsoftwaredeve-lopment,which is supportedby theproduct „in-Step“ that comes from thesame enterprise named microTOOL. It is grounded on an agile, iterativeapproachand is stronglydrivenby requirements.ActiFarranges theorga-nizedhandling(allocationandadministration)withtasksandresponsabilitieswithinagroupofdevelopers.ActiFistailoredtoobject-orienteddevelopmentbyUMLinC#orVisualBasic.NETwithMicrosoftVisualStudio.NET.ActiFtherebyprovides a concrete process pattern to this development platform.Itdefinesallactivitiesandresults,whichmaybe found inanagileprojectinthistechnicalenvironment.Whereverpossible,ActiFoffersmachine-madetemplatesfortheresults.
aDaPTIVe sofTWaRe DeVeloPMenT (asD) 3.2 AccordingtothedeveloperoftheASD-MethodologyJamesA.HighsmithIIIasoftware-developerteamisacomplexsystem,inwhichseveralpersonsworktogether to generate one solution.Generally it is believed that those com-plexsystemsneedcomplexrulesaswellinordertoworkanyway.YetHigh-smithdeniesthatandallegesthatfew,simplebasicrulesaresufficient.Byhisownadmission,softwaredevelopmentshouldbefunand,moreover,thebestsoftwareemergesratheraccidentally.Hedeclaresthisphenomenonas„Emergence“,whichisoneofthemostimportantsignstoadaptivesoftwaredevelopment.
„Emergence“ isequal to realizationofnew ideas,solvingproblemsaswellascreativityinthiscontext.Inordertopreventadisorderlyrunningproject,ASD provides a framework including only just asmany guidelines as nee-dednottodisplace„Emergence“.Thefocusofthismethodismoreupontheresultsandthequalityofthese(component-orientation)thanuponthetaskstobecarriedoutortheprocessthatisneededtoachievetheobjective(task-orientation).Thisisachievedbyadaptivedevelopment-cycles.Thefoundationofeverycycleisthewaterfall-modelwiththefollowingstages:
Plan ⬗Build ⬗Implement ⬗
ThesetraditionalstagesaresubstitutedinASDbythefollowingterms:
Speculate ⬗Collaborate ⬗Learn ⬗
Agreateracceptancetotheagileapproachshallbereachedbyrenamingthestages.Thus,aplanisgenerallyspeakingasdefinedinexactlyandeverydriftfromtheplanisconsideredasamistake.Byrenaming„Plan“(plan)to„Spe-kulation“ (speculation) an understanding shall be created,meaning a driftfromtheplanisnothingbadandthatitcanbeusedasadvantageandchance.Forthispurpose,newapproachesandideasarewelcome.Everycycleconsistsoftheabovementionedstages.Theresultofeverycycleisanexecutablepieceofsoftware.
10
sPeCUlaTe: Inthisstagetheentiresuperiorstrategyoftheprocedureandobjectivescon-cerningthedevelopmentcycletakesplace.Thebasicconditionsofthispro-jectaredefinedintheprojectmission,whichalreadysetsaroughframeworkfortheendproduct.Thewholedevelopmentiscontrolledinawaythattheprojectmissioncanberealized.
WoRkInG ToGeTheR (CollaboRaTe): Thecyclesthathavebeenenvisagedinthepriorstagespeculatearetrans-lated and implemented here. Beneath highlighting the importance of teamwork,severalcomponentsaredevelopedsimultaneously.Thedescriptionsoftheindividualcomponentsarerefinedconstantlytodocumentnewinforma-tionimmediately.
leaRnInG (leaRn): Ifadditionalcyclesshallbe integrated, itcan takeplace in thisstageonly.Othercyclesaredeclaredas“LearningLoop”.Qualityassuranceisthefoun-dation,whichfocusesthefunctionalityofthedevelopedsoftware.Itcantakeplacejustinthepresenceofthecustomer.
aGIle enTeRPRIse (foRMeRlY X bReeD) 3.3 XBreedwasoriginallypicturedbyMikeBeedleandisacombinationofScrumandXP.SinceScrumismoremanagement-orientedandXPrathertechnical,bothmodelscomplementeachother.MeanwhileXBreedhasbecomeAgileEnterprise.
AgileEnterprisesupportsnotonlyindividualprojects,butcoordinatesseveralprojectsinacompanysimultaneouslythatmayrelyonthesameresources.ThereforeAgileEnterprise applies techniques like the “ScrumofScrums”-Meeting.However,italsoentrenchesmoreresourceslikethe“GlobalBack-lock”orthe“SharedResourcesTeam”.FurthermoreAgileEnterprisepublici-zestheuseofScrumwhenitcomestoadoptionofnewbusinessprocessesormodificationofexistingones.
Adap-Figure2:tiveDevelopmentCycle(ownchart,afterHighsmith
Speculate Collaborate Learn
Learning Loop
Project start Planning of adaptive cycles
Simultaneous development of
components
Quality assurance
Final quality assurance &
release
11
aGIle MoDel DRIVen DeVeloPMenT (aMDD)3.4 AMDDis theagileversionofModel-Driven-Softwaredevelopment (MDSD).Themaindifferencebetweenthesetwomethodsistheblueprintofthemodels.InMDSDextensivemodelsarebeingdeveloped(forexampleinUML)beforewritingthesourcecode,inAMDDthedevelopmentofmodelswithminimaleffort(forexamplewhiteboard)takesplacesinordertodepictthemostbasicrequirements first. The developedmodels shall justmeet the currentwor-kload.Infurtheriterations(IterationsDevelopment),thebasicrequirementsarebeingrefinedandoptimized.
TheAMDD-Processisdepictedinfigure3andcontainsthefollowingstages:
enVIsIonInG: Atthebeginningofaprojectaclosecooperationwithstakeholderstakesplaceinordertodeterminethemostimportantbasicrequirementsandtomodeltheextentroughly.Thesystemarchitecture isalsomodelledroughly tospecifythetechnicaldirection.Theentiremodelatthisstageislessdetailedandjustsufficient.Itisessentialthattheproblemitselfgetsunderstood.
DeVeloPMenT ITeRaTIons: Atthebeginningofeachiteration,theteamplansitsworkandprioritizestherequirements.Bymeansofclosecooperationbetweenstakeholderanddeve-loperineveryiterationneworextendedrequirementscanbedeveloped.ThedevelopmentiscarriedoutbyTestDrivenDevelopment(TDD).
Release: Withinthisstagefinal-andacceptance-testiscarriedouttoverifythefunctio-nalityofthewholesystem.Anyerrorsoccurringwillbecorrected.Endusersarebeingtrainedtoworkwiththesystemeffectively.
PRoDUCTIon: Tokeepthesystemmaintainedandtosupporttheusershandlingistheaiminthisstage.Itendswhenasystemorthesupportexpires.
AMDD Figure3:Process(ownchart)
12
behaVIoR DRIVen DeVeloPMenT (bDD) 3.5 BehaviorDrivenDevelopment(BDD)wasdeveloped in2003byDanNorthasananswertoTestDrivenDevelopment.BDDfocusestodevelopsoftwarethatisrelevantforusers.Concerningtheidentificationofrequirements,thebehaviourintheformofpre-andpostconditionisacquiredaswellastheuserstories
(scheme:“Asa<ROLE>Iwant<ACTION>sothat<BENEFIT>”).
Themeansforthispurposeisthescheme“Given–When–Then”,whichcanbedescribedas“precondition–action–postcondition”.Thus, forauserstory several scenarioswithdifferentboundaryconditionscanbecreated.Theydescribeinanaturallanguagethewaythesoftwarewillbehaveineachcase.Inthefollowingyouwillfindanexamplewithabancomatasanexpla-nation.Theuserstoryfordrawingacertainamountofmoneyis:
Role action Benefit
Ascustomer Iwanttowithdrawmoneyatthebancomat
SothatIdon‘tneedtolineupatthecounter
Therearedifferentscenariosthatneedtobeconsidered,like“Istheaccountbalanced?Istheecorcreditcardvalid?”Thesescenariosaredescribedasbelow:
Given When Then
Iftheaccountisba-lancedANDthecreditcardisvalidANDthePINisenteredcor-rectlyANDthedeskhasenoughmoney
WHENthecusto-merwantstowith-drawmoney
THENcheck,iftheaccountisbalancedANDensurethatmoneywillbepaidoutANDensurethatthecreditcardwillbereturned
Asshowninthisexample,multipleconditionscanbelinkedwith„AND“.Onceyoudescribedtherequirementsthisway,thesurfaceshallbedevelopedatfirst.Thesurfaceiswhattheuserssee.Itwillbetunedandcomplywiththeuser’sfeedback.Startingfromthesurfacetherestoftheapplicationwillbeimplementedstepbystep.
13
CRYsTal3.6 Crystalisnotasinglemethodforsoftwaredevelopment,butacollectionofbestpracticesinsoftwaredevelopmentprojects.Itsdeveloper,AlistairCock-burn,wasoughttoelaborateamethodforobject-orienteddevelopmentintheearly1990sfortheIBMConsultingGroup.However,atthattimetherewerenomeansofcomparisonatwhichtheresultcouldbeorientedby.
ThatiswhyCockburnanalyzedasmanyprojectsaspossibleandaskedtherelevantprojectteams,whichthingswerecrucialtothesuccessorfailure.
Hecameto thesurprisingresult thatprojectswerecompletedsuccessful,whentheprojectteamdidnotfollowafixedprocedure,butsimplycommuni-catedwitheachotherregularly.Theresultsremainedconsistentlyfrom1991to1999,internationallyaswellasacrossvariousdevelopmentlanguages.
Cockburnconsequentlyconcluded thatbotheachprojectandeach team isuniqueandthatthereisnogeneralapproach.Basedonthat,aroughdistinc-tionofsoftwaredevelopmentprojectstakesplaceinCrystalbythefollowingsizes(seefigure4):
Numberofemployees ⬗Criticality(impactofthefailure) ⬗Prioritiesoftheproject(suchasearlydelivery,governmentalregulati- ⬗ons)
Thenumberofemployeesrepresentsthenumberofprojectemployeesthatshouldbecoordinated.Thecriticalityclassifies,iftheerrorsinthesoftwareaffectthecomfortoftheuseronly(lowestlevel),theadditionalcostsfortheprincipal,theenterprise’ssurvivaloriftheseerrorsmayhaveevenanimpactonhumanlives(highestlevel).
Prioritiescanbedeterminedindividuallyandasrequired.Thesedimensionsfacilitatebothchoosingthemostappropriatemethodbeforetheprojectbeginsandmakingadjustmentsduringtheprojectasrequired.
Particular components, that could be chosen individually and assembled,therebysupporttheflexibilityofthisfamilyofmethods.Eachsinglemethodwithinthisfamilyofmethodsisnamedbyacolor(CrystalClear,CrystalYel-
Project-Figure4:Classificationaccor-dingtoCrystal(ownchart)
Fehler in Software bedeutet Gefahr für:
14
low,CrystalOrange,…) (seeFigure4).Thereto,Crystaldefines just a fewgeneralguidelinesanddoesnotforcetheusertoanyspecificcourseofaction.Crystalsimplypointsouttheexperiencefromvariousprojectsinwhichteamsmadesomeparticularexperienceincludingtheresultingconsequences.
Thedifferenttechniqueswithincrystalcoulddifferstrongly,butshowthefol-lowingcommoncharacteristics:
Thedifferenttechniqueswithincrystalcoulddifferstrongly,butshowthefol-lowingcommoncharacteristics:
Thecustomerreceivesexecutable,intermediateversionsofthesoft- ⬗wareregularly(atleasteveryquarter) ⬗Problemsanddifferences(bothwithintheteamandtosuperiors)are ⬗discussedopenlyOngoingsearch,collectionandprioritizationofimprovementpropo- ⬗salsClosecommunication(intheteamandthecustomer) ⬗Onthecustomersideanexperiencedemployeemustbeaccessibleas ⬗auseroftheproductatanytimeEmployeesworktargeted ⬗Useofversioncontrol(better:configurationmanagement) ⬗Frequent(automated)testingofprogramcodeaswellasCreatingan ⬗executabletestversionregularly.
DesIGn DRIVen DeVeloPMenT (D3)3.7 DesignDrivenDevelopment(D3)wasdevelopedbyHenryJacob.Objectiveistocreateinnovativesolutions.D3isanagileprocess,whichgivesprioritytothedesignofanapplication.Theprocesscanbeappliedindependently,butalsoasacomplementtoothernon-agileandagilemethods.D3isbasedonthefollowingvaluations:
Abundanceofdesignanddream-fulfillment is thenewmantra forbusinesssuccess.
Design isa fortuitousevent thatoccursduringconception.Maximizingthelikelihoodofoccurrenceiskeytoinnovation.
Noprocesscanguaranteeabetterdesign.Thecreationoftherightenviron-mentwiththerightpeopleistheonlywaytoyieldinnovations.
Bestdesignsarealwaystheresultofacontinuoussimplificationandrefine-ment.
Customersandusersoftenneedsupportonunderstanding,description,visu-alizationandorganizationtheirrequirements.
Figure5depictstheinteractionbetweenD3,ScrumandXP:
15
DYnaMIC sYsTeM DeVeloPMenT MeThoD 3.8 (DsDM)
TheDynamicSystemDevelopmentMethod(DSDM)wasdesignedinthe90sintheUKbytheDSDMConsortium,anassociationofITcompanies.DSDMisanextensiontotheRapidApplicationDevelopments(RAD)–itpursuesaniterative,incrementalapproachandemphasizesthecontinuousinvolvementofusers.
DSDMconsistsofnineprinciples,whichneedtoberespectedinaproject.Thenineprinciplesare:
Thecustomerisactivelyinvolvedintheworkoftheteam. ⬗Thepowerofdecisions(atleastinlargeparts)restsontheteam. ⬗Aregularsupplyofcompleted(partial-)productsisaspired. ⬗Every(partial-)deliverymusthaveatransactionvaluefortheuser, ⬗whichistherelevantacceptancecriterion(Business-Value-Driven).Aniterative,incrementaldevelopmentisnecessarytoachieveanade- ⬗quatesolution.Allchangesduringdevelopmentarerevocableorreversible. ⬗Requirementsarefixedatarelativelyhighlevel. ⬗Testingisanintegralpartofthewholeprocess. ⬗Thecooperativecollaborationamongallinvolvedpersonsisessential. ⬗
InteractionFigure5:betweenD3,ScrumandXP
16
TheprocessofdevelopmentinDSDMencompassessevenphases.Dependingonprojectconstellation,individualphasesmaybeomitted.
Phase 1 - PRe-PRojeCT: Thepre-projectphaseincludestheprojectselectionandtheGo/No-Godecis-ionofaproject.
Phase 2 - feasIbIlITY sTUDY: Inthefeasibilitystudyitisexamined,whetherDSDMisthemostappropriateapproachbytheknownsurroundingconditions.Furthermore,thefeasibility,therisksandthecostswillroughlybeanalyzed.
Phase 3 - bUsIness sTUDY: Thebusinessstudyserves the identificationofaffectedprocessesandusergroups,identifyingtherequirementsandpreparingabusinesscase.
Phase 4 - fUnCTIonal MoDel ITeRaTIon: Within the functionalmodel iteration,basedon the resultsof theBusinessStudy,theproductisspecified,thearchitecturecreatedandaprototypedeve-loped.
Phase 5 - DesIGn anD bUIlD ITeRaTIon: Thedesignanddevelopmentofthesystemtakesplaceinthisphase.
Phase 6 - IMPleMenTaTIon: Thecompletedproductisdeliveredtotheusers.
Phase 7 - PosT-PRojeCT: InthePost-Projectphase,itisexaminedwhether,thesystemworkseffectivelyandefficiently.Itisalsoanalyzed,whetherenhancementsareneeded.
InadditionDSDMusesthefollowingcoretechnologies:
TIMe boXInG: Eachiterationhasadefinedduration.Iterationscanbecharacterizedbyvari-ouslengthsanddifferentphases.
The MosCoW PRInCIPle: Requirementsareclassifiedintothefollowingcategories:
Musthave ⬗Shouldhave ⬗Couldhave ⬗Won’thave(Thistimenotimplemented,butearmarkedforfuture ⬗implementation)
Withinaniteration,requirementsfromdifferentcategorieswillbeimplemen-ted. Ifwithin one iteration problems concerning the implementation arise,low-priorityrequirementscouldberemovedfromthisiteration.
17
ThelatestversionofDSDMisDSDMAtern(orjustAtern).Inthisversion,allIT-specificahavebeenremovedfromtheproceduremodelsothatthismethodisapplicableeveninnon-ITprojects.
eClIPse WaY PRoCess 3.9 TheEclipseWayprocessgetsitsnamefromthewidelyusedopen-sourcedeve-lopmentenvironmentEclipse.ItdescribesthewayinwhichEclipseisdeve-loped. It isacombinationofagilemethods,methods from theopen-sourcedevelopmentandtechniquesforworkinlarge,distributedteams.
Notshowninthisfigurearethebasicelements:
Iterative ⬗Incremental ⬗Reflection ⬗Adaptation ⬗Feedback ⬗
ThetechniquesoftheEclipseWayProcesscanbecomposedmodularandareadaptabletothespecificprojectcondition.TheEclipseWayProcessisverysimilartotheOpenUnifiedProcess.
eVolUTIonaRY PRoCess foR InTeGRaTInG 3.10 CoTs-baseD sYsTeMs (ePIC)
COTS stands for „Commercial off-the-shelf“ and is the english term forstandard-software.This includes, inadditiontoclassicalstandard-software,suchasSAP,shareware/freewareandprefabricatedcomponents.EPICisanapproachfortheselection,adaptationandintroductionofstandard-softwareandhasbeendevelopedat theSoftwareEngineering InstituteofCarnegieMellonUniversityinPittsburgh.
TechniquesofEclipseFigure6:Way(source:http://www.ibm.com/developerworks/rational/lib-rary/edge/08/jul08/vanVelzen/)
18
Althoughtheauthorsofthemethoddonottalkaboutagility,theconceptsofEPICcoverthevaluationsoftheagilemanifestoaswell.BasedontheRationalUnifiedProcess(RUP),aframeworkhasbeendevelopedthatpublicizestheintegrationofusers,aniterativeapproachandtheperiodicaldeploymentofresults.Thefollowingfiguredepictsthecourseofaniteration:
In reference to theRUP,EPICconsists of the initializationphase,prepara-tionphase,elaborationphase,developmentphaseanddeliveryphase.Ineachphaseatleastoneiterationcomestopass.Thefurtheroneprogressesintheproject,themoreconcretetheobjectivesandcontentgets,asthefollowingfigureillustrates:
ContentofanFigure7:iterationinEPIC
ContainmentFigure8:ofthesolutionspacein
progressingtime
19
eVolUTIonaRY PRojeCT ManaGeMenT & 3.11 PRoDUCT DeVeloPMenT (eVo)
EVOwasdescribedin1988forthefirsttimebyTomGilbinhisbook„Prin-ciplesofSoftwareEngineeringManagement“,at that timenamed„Evoluti-onaryDevelopment“.BackthenGilbalreadyrecommendedtocreatesmall,incrementalreleasesorbuildsofsoftwareandtomakethemregularlyandfrequentlyavailbletothecustomers.Planningshouldbedynamicallyinordertobeabletotakethefeedbackofusersintoaccount.EVOischaracterizedbythefollowingproperties:
Trackingofmultipletargets ⬗Earlyandfrequentiterations ⬗Completeanalysis,design,implementationandtestingineachiterati- ⬗onUserorientation ⬗Considerationoftheentiresystem,notindividualalgorithms ⬗Openbase-architecture ⬗Target-oriented,not(softwaredevelopment)process-oriented ⬗
WithinEVO,theprojectisdividedintosmallpieces(„chunks“),each„chunk“shouldincludenomorethan5%ofthetotalexpense.Indoingso,thosefunc-tionsaredevelopedfirst,whichprofitthemostandareimplementedeasily.
Inthemeantime,EVOwasrefinedandafterwardsrenamedto„EvolutionaryProjectManagement&ProductDevelopment“byTomGilbandhissonKai.ThefollowingfigureshowsthekeyelementsofthecurrentversionofEVO:
sTakeholDeR ValUes, PRoDUCT QUalITY ReQUIReMenTs UnD DeVeloPMenT ResoURCe bUDGeTs:
Clarifyingtherequirementsandtheavailableresources.
solUTIons:Ideasforsolutionsinordertosatisfythestakeholdervaluesandproductqua-lityrequirementswiththeavailableresources.
IMPaCT esTIMaTIon: Mappingtheideasforsolutionsontothestakeholdervalues,productqualitiesanddevelopmentresources.Intentionistoproof,whetherthesolutionscon-cerningthestakeholdervaluesandproductqualityrequirementsaresustai-nableandwhethertheycanbeimplementedwiththeresources.
KeyelementsofEVOFigure9:
20
eVolUTIonaRY Plan:Initialroughplanofthesequenceandtheway,howonewillachievethesta-keholdervaluesandproductqualityrequirements.Thenecessarydetailingoftheevolutionaryplanisevolvedtogetherwiththeprojectduringimplemen-tation.
fUnCTIons:Descriptionofwhatthesystemdoes.
DefInITIons:Descriptionoftermsandconcepts.
eXTReMe PRoGRaMMInG (XP)3.12 ExtremeProgramming(XP)wasdevelopedinthemid90‘sbyKentBeck,WardCunninghamandRonJeffries.Itisaniterative,incrementalproceduremodel.XPiscomposedofvaluations,principles,techniquesandroles.
ValUaTIons3.12.1 ThevaluationsofXPare:
Communication ⬗Simplicity ⬗Courage ⬗Feedback ⬗Respect ⬗
CoMMUnICaTIon: Ongoingand intensivecommunicationbetween thedeveloperandwith thecustomerfacilitatesensuringfastestpossiblefeedback,preventingunneces-sary functionality, resolving emerging problems as quickly as possible andalleviatingtheproblemofmissingdocumentation.
sIMPlICITY:The software should be desigend as simple as possible, no preparation ofpossible future extensions, no redundant or unnecessary functionality andnoredundantstructuresare tolerated.Thereby, thesystemremainssimpleandmaintainable.Thisisbasedontheassumptionthatitismoreefficienttocreatesomethingsimpletodayandtoinvestalittlemoreefforttomorrowtoincorporatechangesratherthantodevelopsomethingcomplextoday,whichwillnotbeusedtomorrowornotintheanticipatedform.
CoURaGe:Theimplementationofprinciplesandvaluationsrequirescourage.Thisinclu-descommunicatingthetruthabout theprojectprogressandefforts,not tolookforexcusesforfailuresandtoacceptchangeswhenevertheyoccur.
feeDbaCk:Many of todays (software development) projects fail due tomisunderstan-dingsbetweendevelopers andusers.Evolutionarydevelopment of the sys-teminreleasesaslittleaspossibleandapermanentavailabilityofcustomersfacilitatequickfeedbackandthusaflexiblecontroloftheprojectprogress.Anotherimportantsourceoffeedbackisthedevelopmentoftestsfordifferent
21
levels(unittesting,test-stories)inordertocheck,whethertherealizedfunc-tionalityiscorrect,solidandmeetsthegivenrequirements.
ResPeCT:Everyonegivesandreceivestherespecthedeservesasateammember.Eachindividualdelivers itscontribution tosuccess,even if it is justenthusiasm.Developerrespecttheexpertiseofcustomersandviceversa.
PRInCIPles 3.12.2 The principles bridge between the abstract valuations and the specificallyapplicablepractices.XPdescribesthefollowing13principles:
Humanity ⬗Efficiency ⬗Double-sidedadvantage ⬗Improvements ⬗Diversity ⬗Reflection ⬗Flow ⬗Acceptingfailures ⬗Perceivingoccasions ⬗Quality ⬗Avoidduplications ⬗Smallsteps ⬗Acceptedresponsibility ⬗
hUManITY:Software isdevelopedbyhumans.Sopeopleare the factor that shouldbegivenspecialattentionaccordingtoXP.Bycreatingacomfortableatmosphere,thebasicneedsofthedeveloper(security,completion,identificationwiththegroup,perspectiveandunderstanding)shallbemet.
effICIenCY anD MUTUal benefIT:Thedevelopedsoftwareorasinglefunctionalityhastobeefficientandnever-thelesstoyieldatruevalueontheonehand.Ontheotherhand,itmustbebeneficialforbothsidesandsatisfyingforallparties(developmentteamandcustomer).
IMPRoVeMenTs anD DIVeRsITY: Thereuseofexistingsolutionsisessential,whichmeansforexampleaccom-plishingvariousdifferenttestscontinuallyandautomatically.Thereby,ever-yonegetsstraightthatthefirstsolutionsareusuallynotthebestones.Newinsightsgainedbyoneselfthroughfeedbackshallleadtoimprovedsolutions.Recognizing better solutions day by day is only made possible by steadyreflectionandcallingtherespectiveapproacheswithintheteamcontinuouslyintoquestion.Theproductivityofthisproceedingincreasesproportionallytotheheterogeneityoftheteam,whichisconstitutedofvaryingskillsandcha-racters.Differingopinionsarenotonlytolerated,butevenencouraged.Thisrequiresaconflictmanagementtobeestablished.
floW, ToleRaTInG faIlURes anD PeRCeIVInG oPPoRTUnITIes: Theexecutabilityofsoftwarehastobeguaranteedatanytime.Althoughshortiterationswithcontinuous feedback facilitatekeeping theproject inaflow,neverthelessfailureshavetobetakenintoaccount.Inthecourseofthis,itis
22
quiteusualandacceptedtoconductanimplementationthatinitiallymaynotbeoptimalorevenfaulty.Thesedifficultieshavetobetakenasopportunityandchancetoripenfurtherboththeproductandtheteam.
Themoreallinvolvedpersonsarewillinglytoaccepttheirresponsibility,thebetterastraightforwardly,constructivedealingwith thechallengesof soft-waredevelopmenttakesplace.Chargingadeveloperwithanactivityandaresponsibilitydisciplinaryisnotenough,sincehehastoagreetothatrespon-sibilityactivelyandtoliveit.
QUalITY: Another importantpoint ishighquality,which is - inaccordancetoXP - incontrast to other factors like resources, featuresor expirydate, notunderconsideration.Thisbasic attitudediffers frommanyothermethodsof soft-ware development,where software has to be completed at a certain pointoftimeandinadefinedrangeoffunctions,amongwhichalmostalwaysthesoftwarequalitysuffers.However,qualityiscrucialtoholdtheproductusa-ble,bug-freeandexpandable.Softwarewithgooddesignandhighqualityismedium-datedcheaper,moreexpendableandlessbuggythanfastdeveloped,so-called“Quick-and-dirty”-software.
aVoID DUPlICaTIon: Thepreventionofredundancyispartofgoodqualityaswell.Theseareauto-matablestepsthathavebeenexecutedunnecessarilymultipletimesormanu-ally.
sMall sTePs: Throughquick,smallstepstheteamremainsadjustableandisabletoadaptnewsurroundingconditionsandtorespondtofeedbackquickly.Thenegativeconsequencesofasingle,smallstepthathasnotbeensuccessfulcanbecom-pensatedmuchmorequicklythanincaseofasingle,majorstep.
TeChnIQUes3.12.3 ThefollowingtechniquesareusedinXP:
Experimentalgame ⬗Smallreleases ⬗Systemmetaphor ⬗Simpledesign ⬗Pair-programming ⬗Refactoring ⬗Continuoustesting ⬗CollectiveCode-Ownership ⬗On-sitecustomer ⬗Codingstandards ⬗40hourweek ⬗Continuousintegration ⬗
eXPeRIMenTal GaMe: Intheexperimentalgame,availabledeveloper-resourcesarebroughtintolinewithcustomerrequirements.Here it isdecided,whichfunctionalitywillbeimplementednext.Functionsareprioritizedanddescribedas„UserStories”.Developersestimate theeffortonuserstories.Basedon that, it isdecidedwhichfunctionsaretobeimplementednewly.
23
sMall Releases: Startwiththesmallestmeaningfulextentoffunctions.Deliverearly,frequentlyandaddnewfeatureseverytime.
sYsTeM MeTaPhoR:Systemmetaphorisconceivedasbasicarchitectureofthesystem.Thisreferstotheoverallpicturethatalldevelopershaveinmind.Everydeveloperdoesnotonlyknowapartorsubsystemonwhichheworks,butalsotheoverallobjectiveandthebasicarchitecturethatdeterminethesystem.
sIMPle DesIGn:Themostsimple,possibledesignthatmeetsthecurrentrequirementsisselec-tedalways.Therequirementschangedaily,soyoushouldnotdoanythingthatyoumightneedtomorrow.
PaIR-PRoGRaMMInG: Twodevelopersareworkingtogetheronacomputer.Oneofthemis„Driver“,whodevelopsandtheotheristhe„Follower“,whoseconsiderationsareincor-poratedtoo.Theserolesareswitchedconstantly.Thus,areviewofcodetakesplaceatthesametimeasdevelopment.
RefaCToRInG: Byrefactoringtheinternalstructureoftheprogram,improvementisachievedwithoutchangingbehaviororfunctionalityoftheprogram.
ConTInUoUs TesTInG: Beforeadeveloper implements anew function, hefirstwrites a test for it(„Testfirst“).Typically,theseareunittests,whicharegroupedintotestsuitesthatrunaftereachintegrationautomatically.
ColleCTIVe CoDe-oWneRshIP: Thesourcecodebelongstothewholeteam.Everydevelopershouldalwaysbeabletoeditanyofthecode.
on-sITe CUsToMeR: Thedevelopment team isworking at the customer site. Thus, an intensivecooperationandcommunicationispossible.Developersgetquickfeedbackontheprovidedreleaselikewise
PRoGRaMMInG GUIDelInes: Thepredetermined coding standards (e.g. naming conventions) have to berespectedbyall.Thus,thesourcecodeisconsistent,whichmakesiteasiertoensurethatalldeveloperscanworkanywhere.
40 hoUR Week: Inthelengthoftime,extrahoursreducemotivationandproductivityofdeve-loper.Inexceptionalcircumstancesextrahoursareallowed.However,ifitisgetting a permanent condition, something concerning the process is goingwrong.
ConTInUoUs InTeGRaTIon: Allchangesareloadedtothecodebaseatleastonceaday.Thetestsmustrunbothbeforeandafterintegrationcompletelyandcorrectly.
24
Roles3.12.4 InaXP-projecttherearethefollowingroles:
Customer ⬗Developers ⬗Manager ⬗
CUsToMeR: Thecustomerdecideswhatcreatesanaddedvaluetohim,prioritizesthesepoints and then chooseswhat shall be implementedandwhat is tobeputback.Inaddition,hedefinesteststhatverifythefunctionalityofthesystem(acceptancetests).
DeVeloPeR:Thedeveloperestimateseffortsandcomplexityoftheuserstoriesandcont-rolspacethatfunctionalityisbeingdevelopedanddeployedwith.
ManaGeR: Themanagermakesupcustomersanddevelopersandhelpsthemtocoalescetoapowerfulteam.
PRoCess:TheXPprocessisaniterativeprocess,wheretheabove-describedtechniquesarerepeatedconstantly.
Figure10representthecompleteframeofaXP-project.
An actionwithin an iteration at that is the development. There the above-mentionedtechniquesapply.Withinaniterationthefollowingactions(Figure11)takeplace:
The Figure10:XP-Process(sour-ce:www.extreme-
programming.org)
25
feaTURe DRIVen DeVeloPMenT (fDD) 3.13 FeatureDrivenDevelopment (FDD)wasdesigned in1997by JeffDeLuca,PeterCoadas slimmethod for softwaredevelopment.As timewentby themethodwasenhancedcontinuously.
FDDputstheterm„Feature“incenterofdevelopment.Atthatafeatureisdefinedassomethingusefulintheeyesofthecustomer.Thus,eachfeaturerepresentsavaluetothecustomer.Thedescriptionofafeatureaccordingtotheschemelookslike:
<action> <result> <object>
compute thebalance oftheaccount
Consequently,featuresareveryfine-grainedfunctions.Dependenciesbetweenthe features often exist.Related features are grouped to so-calledFeatureSets.ThedescriptionofaFeatureSetfollowsthepattern:
<action> <-ing> <object>
mak- -ing aproductsale
Inturn,FeatureSetsaregroupedtosuperior,professionalgroups–theMajorFeatureSets.TheMajorFeatureSetsaredescribedbythescheme:
<object>management
Example:„productsalemanagement“
FortheimplementationofthesefeaturesFDDprovidesprocesses,rolesand„BestPractices“.
Role MoDel 3.13.1 Therolemodelsubclassifieskeyroles,supportrolesandadditionalroles.
Pro-Figure11:cesswithinaniterationinXP(source:www.extremepro-gramming.org
26
keY Roles: Project-Manager ⬗ChiefArchitect ⬗DevelopmentDirector(administrativesupportoftheChief-Program- ⬗merintheirdailywork)Chief-Programmer ⬗Class-Responsibles ⬗Experts(users,customers,sponsors,etc.) ⬗
sUPPoRTInG Roles: Domain-Manager(Headofdomainexpertsinlargeteams,coincides ⬗mostlywithProject-Manager)ReleaseManager(controlstheprojectprogress) ⬗LanguageLawyerorLanguageGuru(aspecialistinusedprogram- ⬗ming-languageortechnology)BuildEngineer ⬗Toolsmith(createsproject-specificdevelopmenttools) ⬗System-Administrator ⬗
aDDITIonal Roles: Testers ⬗Deployers(systeminstallationanddeployment,includingdataconver- ⬗sion)TechnicalWriters ⬗
Typically-especiallyinsmallteams-employeesoccupyseveralroles
PRoCess MoDel 3.13.2 Theprocessmodelconsistsoffiveprocesses:
Developmentoftheoverall-model ⬗Creationoffeature-list ⬗Planningofeachfeature ⬗Designofeachfeature ⬗Constructionofeachfeature ⬗
Thefirstthreeprocessesareusuallypassedonlyonce.Thelasttwoprocesses,however,representtherealizationoffeaturesandrunincycles.
DeVeloPMenT of The oVeRall-MoDel: Aimofthefirstprocessistoreachaconsensusconcerningcontentandrangeofthesystemtobedeveloped,aswellasdevelopingthetechnicalcoremodel.Thereto,expertsanddevelopersdefinecontentandrangeofthesystem,ledbythechiefarchitect.Insmallgroupstechnicalmodelsforthedifferentsys-tem-areas are developed,whichwill be presented in the group, eventuallyrevisedandfinallyintegrated.
FDDprocessflowFigure12:(source:wikipedia
27
CReaTIon of feaTURe-lIsT: Inthesecondprocess,thepreviouslyspecifiedsystem-areas–thefeatures–willbedefined.Inthisprocesstheaforementionedthree-stepscheme(MajorFeatureSets,FeatureSetsandFeatures) isused.The implementationofafeaturemaynottakelongerthantwoweeks.Theresultofthissecondprocessisacategorizedfeature-list,whosecategoriescomeontotoplevelfromtheexpertsofprocess#1.
PlannInG PeR feaTURe: Inthethirdprocess,theProject-Manager,theDevelopmentDirectorandtheChiefProgrammerareplanningtheorderthefeaturesshallberealized.The-reto,theycomplywithdependenciesbetweenfeatures,workloadofthedeve-lopingteamandthecomplexityofthefeatures.
Based on the plan, the completion dates for each business activitywill bedefined.Eachbusinessactivitygetsachief-programmerasownerassigned.Moreover, for known core classes developers will be set as owner (ClassOwnerList).
DRafT of eaCh feaTURe: Thechiefprogrammeranalyzesitsassociatedfeatureandputs,onthebasisoftheinvolvedclasses,thefeatureteamtogether.ADomainWalkthroughisexecuted,theobjectmodelrefined,thedesignoftheFeatureSetfixedandfinallyreviewedduringaninspection.
ConsTRUCTIon foR eaCh feaTURe: Inthefifthprocess,thedeveloperscodethefeaturesthathavebeenpreparedinthefourthprocess.Duringprogramming,componenttestsandcodeinspec-tionswilltakeplaceforthepurposeofqualityassurance.
FDDmakesnofixingsconcerningiterationsbeyondincrementaldevelopmentperfeature.Yetforlargerprojects,itisusefultodefineformalmilestones,bythosepartsofthefinalproductmaybepresented.Thus,oneisabletodocu-menttheprogressevenbyexecutablecode.
besT PRaCTICes 3.13.3 BestPracticesaremethodsandproceduresthathavebeenproveninmanyprojects.FDDallowstheuseforthefollowingBestPractices:
DomainObjectModeling ⬗DevelopingbyFeature ⬗IndividualClass(Code)Ownership ⬗FeatureTeams ⬗Inspections ⬗RegularBuilds ⬗ConfigurationManagement ⬗VisibilityofProgressandResults ⬗
DoMaIn objeCT MoDelInG:Atthebeginningofeachproject,itisaboutgettinganoverviewasgoodaspossibleabouttheproblemarea.Forthispurpose,FDDincludestheproduc-tionofaDomainObjectModel.TheDomainObjectModeltherebyencompas-sesonlythosebusinessobjectsthatareusuallypersistent.GUIsandControl-
28
Objectsdonotmatteratthisstage-thesewouldmaketheviewontotheBusi-nessObjectModelmoredifficult.
DeVeloPInG bY feaTURe:Featuresaresmallandmanageableunitsthatarerealizableinnomorethantwoweeks.Eachfunctionthatistoocomplextoberealizedinthattime,willbedetailedaslongasanappropriatesizeisreached.Thisfacilitatesdeliver-ingcorrectfunctionalityandextendingormodifyingthesystemmoreeasily.
InDIVIDUal Class (CoDe) oWneRshIP:Incontrastto„CollectiveCodeOwnership“(alldevelopersarejointlyrespon-sibleforthecodebase,asforexampleXP),FDDpropagates„IndividualCodeOwnership“.Sotherearededicatedpersonsinchargetoindividualpiecesofsourcecode.Thoseresponsiblepersonsareinchargeconcerningconsistency,performanceandconceptualintegrityoftheircode.
feaTURe TeaMs: Featureteamsareteamsthatcometogetherdynamicallytoimplementfea-tures. Thus, various design proposalswill be discussed at implementation,beforeacommitmentontoacertaindesignfollows.
InsPeCTIons: Asastepofqualityassurance,FDDenvisionsinspections.Here,developmentresultsofotherteammembersarebeingassessedandreviewed.Thiscondu-cesimprovementofcodebaseontheonehand,ontheotherhandknowledgetransferbetweenteammemberswillbeaided.Inspectionsalsohelptopro-mote effective enforcement of coding standards.Within the scope of FDD,codeinspectionsaretypicallydoneinthecontextoffeatureteams,whereastheChief-Programmerasthe leadingteammemberdeterminesthe levelofformalityofsuchaninspection.
FDDhasnobuilt-intest,asithasbecomepopularthroughXP‘s„TestFirst“forexample.ThatdoesnotmeanthatthispracticeincontextofFDDwouldnotbeusefulornotassimilable.Itisjustnotimperativelyrequired.Ingeneral,itisreferencedtotheexistingqualityassuranceprocesseswithintheorganisationconcerningtheissueoftesting.Eachdevelopershouldrunhisown“Smoke-Test”withhiscodedcomponents.
ReGUlaR bUIlDs: Regularlycompiledbuildsoftheentireproductserveforonethingthevisibilityofprojectprogress-linkedtoexecutablecode-andforanotherthing(espe-ciallyinlargeprojects)thepreventionofdramaticintegrationproblems.
ThereisnofrequencyspecifiedintermsofthesebuildsinFDD.Dependingontheproject,aweekly,dailyorevenacontinuousbuild-processcouldbethebestchoice.FDDrequiresonlythatthebuildtakesplaceregularly.Indoubt,ashortcycleisthebetterchoice.
ConfIGURaTIon ManaGeMenT:Each project should have a configurationmanagement, independently of aprocessmodel.Configurationmanagementiscentralbasisforprojectresultsandthusthe„SinglePointofTruth“.Inprinciple,allartifactscreatedintheproject(analysis,design,code,testcases,etc.)aresubjecttoconfigurationmanagement.
29
VIsIbIlITY of PRoGRess anD ResUlTs: Continuoustuningoftheprojectprocessrequiresaquicklyandfine-grainedvisibleprojectprogress.Thedegreeofgranularityis,inturn,thesinglefea-ture.
Thereto,FDDproposesa simple report-formatbasedon„Mini-milestones“.Thefollowingsixmilestonesaresetaseachfeatureisbeingdeveloped:
DomainWalkthrough ⬗Design ⬗DesignInspection ⬗Code ⬗CodeInspection ⬗PromotetoBuild ⬗
Everysinglemilestoneisdefinedinawaythatitsachievementisa„binary“decision. The domain walkthrough is complete, the design is created, thedesign is inspected, thecode is created, thecode is inspected, thecode isapprovedforthenextbuild.
In order to achieve milestones, a certain percentage of the total cost isattachedtothecreationofeachfeatureset.Feature-specificestimationsarenot considered during this step, but default values that are in accordancewithpreviousexperienceswithintheorganization.Intheirbook„APracticalGuidetoFeatureDrivenDevelopment“,PalmerandFelsingrecommendthefollowingstartingvalues:
Basedonthat,foreverysinglefeatureapercentuallevelofcompletioncanbecalculated.Thislevelmaynotseemtobeentirelycorrect,butasfeaturesarefine-grainedrequirements(hencesmall),thefaultsaremostlysmallandnegligible.
On the same basis, the plans are drawn by each team (or the responsibleChief-Programmer)viaestimatingaslongasitwilltaketocompletethefea-ture.Detailedplanningofeachmilestonewillbecarriedout incompliancewiththeabove-mentionedscheme.
IConIX3.14 AsRUP(RationalUnifiedProcess),IconixrepresentsaUML-basedsoftwaredevelopmentmethodthatindeedismuchmorelightweight1asRUP.TheIco-nix-processgenerallyconsistsoffourphases(seefigure13)andusesatotal
1Beforetheagilemanifesto(2001)existed,theterm„lightweight“wasusedinsteadof„agile.“Bothtermsaretobeunderstoodassynonyms
Design by feature build by feature
DomainWalkth-through
DesignDesign Inspection Code
CodeInspection
PromotetoBuild
1% 40% 3% 45% 10% 1%
30
offourdiagramsbasedonUML(UseCase,Sequence,Domain,Class)inordertotransferprioritizeduscasestoexecutablecodethroughiterations.
Ineachphaseavalidationofpreviouslycompletedworktakesplace,followedbyanadjustmentasfarasneeded.
ReQUIReMenTs:Functionalrequirementsuponthesystemaregatheredatfirst.Soastocreateacommonvocabularyforclearcommunicationbetweentheteammembers,adictionarywillbesetup (DomainModeling).Goal is toensure thateach
memberintheprojectunderstandstheproblemareawithoutdoubt.Moreo-ver,thedictionarydefinestheextentandshapesfoundationforusecases.Attheendofthisphase,itisensuredthatthedescriptionofusecasesmatchthecustomer‘sexpectations.Validationofusecasestakesplaceinsmallbundlesinorder toprioritize themandafterwards todesign them in thenext step(Analysis/PreliminaryDesign).
analYsIs / PRelIMInaRY DesIGn:Inthisphase,thedevelopmentstrategyisset.Thus,assumptionsconcerningdesignaswellastechnicalarchitecturearemade.PotentialerrorswithintheusecasedescriptionsshallbeidentifiedbytheRobustnessAnalysis.Indoingso,missingclassesbecomeapparent,ambiguitiescanbecorrectedandattri-butesareaddedtotheDomain-Objects.Afterwards,thedomainmodelshallbeupdated.Beforeswitchingtothenextphase,anothervalidationoftheworkperformedinthisphaseiscarriedout.
DeTaIleD DesIGn:Sinceinthepreviousphaseadevelopmentstrategyhasbeendefinedonly,itwillbeimplementedhere.Domainmodelandusecasedescriptionsareusedto design the system. Thus, the domainmodel is converted to a class dia-gram(Class).Usecasedescriptionsareusedtocompilesequencediagrams(Sequence).Attheendofthisphase,avalidationtakesplacetoo.
IMPleMenTaTIon:Basedonpreviousphases,theprogrammingofbothsoftwareandunittestsnowtakesplace.Thereto,classdiagrams-aswellassequencediagrams-willbeusedasguidelines.TheactualdevelopmenttakesplaceincompliancewithTestDrivenDevelopment(TDD).Thelevels„Analysis/PreliminaryDesign“,„DetailedDesign“and„implementation“willbe run throughuntil the soft-waremeetsthedesiredcustomerrequirements
IconixProcessFigure13:(ownchart)
31
InTeRneT-sPeeD DeVeloPMenT3.15 Internet-SpeedDevelopmentwasdevelopedinthelate90s.Itisacombinationofthewaterfallmodelandspiralmodel.Whenthemethodwasdeveloped,aimwastocarryouttheacutaldevelopmentinastructuredwayontheonehand,andtoupholdrequiredflexibilitytobeabletoactonchangesontheother.
ThefollowingfigureshowstheflowofInternet-SpeedDevelopment:
Internet-SpeedDevelopmentisaniterativeprocedure,whoseineachiterationthephasesEnvisioning,Planning,Developing,StabilizingandDeployingarepassedthrough.Attheendofaniterationanexecutableversionofsoftwareisready.
Thecontentsofeachphaseare:
enVIsIonInG:DuringEnvisioningphasetherequirementsareanalyzed,scopeisdefinedandrisksareidentified.
PlannInG:InthePlanningphase,afunctionalspecification,aroughdesignandaplan-ningiscreated.
DeVeloPInG:IntheDevelopmentphase,thefunctionsarerealized.
sTabIlIzInG:DuringStabilizationphase,thefullydevelopedfeaturesaretestedanderrorscorrected.
DePloYInG:Inthedeploymentphase,thesystemisinstalledandactivated.
Thephase-modelofFigure14:theInternet-SpeedDevelopment
32
lean sofTWaRe DeVeloPMenT (lsD)3.16 LeanSoftwareDevelopmentwasdeveloped in2003byMaryandTomPop-pendieck,wherebyLeanDevelopmentservedasamodel.LeanDevelopmentled to farreachingchangesprimarily in theautomotive industry.Theyrea-lizedgreatsimilaritiesbetweentheideasfromproductdevelopmentandagilemethodsinsoftwaredevelopment.
LeanSoftwareDevelopmenthassevenprincipleswhicharetransformedbymeansof22approaches.Thesevenprinciplesare:
Avoidingwaste ⬗Supportlearning ⬗Decidingaslateaspossible ⬗Deployingasearlyaspossible ⬗Givingresponsibilitytotheteam ⬗Incorporateintegrity ⬗SeeingtheWhole ⬗
aVoIDInG WasTe:Anythingthatprovidesnoaddedvaluetothecustomeriswaste.Thismaybeafeaturenobodyusesordocumentswhichremainunreadinacupboard.Inordertoavoidwaste,youhavetorecognizeitatfirst.ThisisthefirstactioninLeanSoftwareDevelopmentaswell:recognizingwaste.Thefollowingsevenpointsareclassicalsourcesofwaste,accordingtowhichoneshouldlookforintheproject:
Incompletework: ⬗Incompletesoftwareprovidesnoaddedvalue.Eitheritislyingandcompletedlater(whichcausesinductionexpenses),oritwillneverbecompleted.Unnecessaryprocesses: ⬗Anyunnecessarysettingduringdevelopmentprocessiswaste.ThisinsightisalsoknownintheCrystalmethod.Unnecessaryfeatures: ⬗Featuresnotneededbythecustomerarewaste.Switchingdevelopers: ⬗Developersoftenworkinseveralprojectssimultaneously.Thepersis-tentswitchingbetweenprojectsisbornebyproductivity.Waiting: ⬗Anykindofwaitingiswaste-nomatterwhetherthetesteriswaitingforthedevelopmentorthewholeteamforprocurementofaspecialtool.Movement: ⬗Howmanystationshavetobecrossedtofindoutwhocanhelponewithaproblem?Howoftenhasanissuetobemovedfromonepersoninchargetothenextuntilitcreatesaddedvalue?Eachavoidablemo-vementiswaste.Bugs/Failures: ⬗Unfortunately,bugscannotbecompletelyavoided.Theycanbeveryexpensive,inworstcaseevencosthumanlives.Therefore,mechanis-msmustbeprovidedsothatemergingbugsorfailurescannothurtpeople.
33
Management: ⬗Awrittenstatusreportthatiscreatedeverydayisaswellaswasteoftimethanrecordingofworkedtimethatiscontrolledbynobody.Sameistrueforthetechnicalmanagement-„over-engineering“ofarchitec-turesiswaste.
Anotherapproachtoavoidwastearevaluechains.Basedontheaddedvaluefor thecustomer,eachactivity thatcontributes toacertainaddedvalue islocatedinasketch.Thishelpstoexamineallstepsofadevelopmentprocessconcerningthevaluetheyprovide.Ifonesteponlyprovideslowtonovalue,hewillbedropped.
sUPPoRT leaRnInG:Inthecourseofaprojectallpartieslearn-boththecustomerandthedevelo-pers.Thisisgreatlydesiredandshouldbesupported.
Oneaidtothisisfeedback.Feedbackisaquickresponseonworkoutcomes.Inthisway,forexample,onecantrydifferentvariantsdirectlyinthesourcecodeandwillreceivefeedbackabouttherunningabilityimmediately-insteadoflarge-scalearchitecture-anddesigndocuments.Andinsteadofgatheringrequirementscompletely,itisbettertodesignafewscreensanddiscussthemwiththecustomer.
Inordertoapplyfeedbackpurposefully,iterationisused.Byregularprovisionofexecutablesoftware,oneisabletoobtainappropriatefeedbackfromthecustomer.Thereby,iterationsmightdifferinlength.However,itisimportanttokeepinmindthatiterationsare„Time-boxed“,whichmeansthatthefinaldateisfixed.Ifabottleneckarises,extentoftherespectiveiterationischan-ged,notthefinaldate.
The„SetbasedDesign“actsasa furtheraid tosupport learning.The ideabehindistokeepasmanyalternativesaslongaspossibleopen.
Thecommitmenttoanalternativeisnotmadeuntilinone‘sviewislearnedenoughtomakeadecision.ThisalsoaidsafurtherprincipleofLeanSoftwareDevelopments,namely,to„decideaslateaspossible“.
DeCIDInG as laTe as PossIble:In Lean Software Development it is postulated tomake a decision as lateas possible.Before then, thedevelopment in all affected areas is fostered,untilonehasgatheredtherequiredinformationtomaketherightdecision.Inparticular,professionalanalysis,architecture,designandimplementationarefosteredparallel.ThisisknownasConcurrentDevelopment.
Asupportingwayisthinkinginoptions.Aslongasonedoesnothaveallthenecessaryinformationtomakeadecision,onedoesnotcommitoneselfandleavesdifferentoptionsopen.Thosewhothinkinoptions,arethuscapableofdelayingdecisions.Itis,however,equallyimportanttorecognizetherighttimeforadecision.Thisisthenextresource,thelatestpossiblemoment.
Therighttimeforadecisioniswhenonemightblockanimportantalternativeotherwise.Thisshouldnot„justhappen“,butbyaconsciousdecision.MakingdecisionsisalsoanotherresourceofLeanSoftwareDevelopment.Decisionsaretakenbyexperienceandwithgutinstinct.Indoingso,itisveryimportanttoinvolveallthosepeoplethathavetobepartofimplementation.
34
DePloYInG as eaRlY as PossIble:Delayingdecisionsaffectnotonlytechnicaldecisions.Eventheprofessionalchoicesshouldnotbemadeuntiltheprofessionalshaveunderstoodtheimpli-cationsclearly.Inmanycases,allinvolvedpersonsneedtohaveexperiencewithexecutablesoftware.Hence,itisnecessarytodeliversoftwareasearlyaspossible,whichmakeshighdemandstothetaskmanagement.
Thereto, resources exist aswell. Such is thepull system,whereupcomingactivitieswillbecollectedasinacardindex.Theactivitiesareprioritized,thedevelopertaketasksoutofthisboxbypriorityandtheirownabilities.
Regular(daily)meetingstakeplacetosupportcoordinatingthetasks.Bysomesortofblackboarditismadetransparent,whoisworkingatwhichtasksandwhichonesaretobedevelopednext.ThePullSystemcanberegardedasachainofqueues.TheQueuingtheoryisaresourceofLeanSoftwareDevelop-ment.Thequeuingtheoryisabranchofsystemicthinking.Thereareseveraloptimizationmethodstoqueues.
Thecostsofdelaysarealsoaresource.Rapiddevelopmentisnotalwaysthemorefavorablealternative.Itmaybenecessarytopurchaseexpensivetoolsthatcostmorethanthepossiblesavedworkingtime.Insuchdecisions,LeanSoftwareDevelopmentrecommendstoconsidernotonlythedirectsavings,butalsothecostsforadelayeddelivery.Businessmanagementteachesthatthecostsformissedmarketopportunitiesoverliedevelopmentcostsfaraboveall.
GIVInG ResPonsIbIlITY To The TeaM:LeanSoftwareDevelopmentpromotestheideaoftransferringresponsibilitytotheteamasoneofthebiggestmotivators.
In order to motivate the team, Lean Software Development provides theapproachthattheteammaydetermineitsgoalsitself.Objectivesthathavebeenspecifiedbythemselvesaretobeachievedmoreoftenthanoneswhichcomefromothers.
However,self-setgoalsarenotyetsufficient.Teammembersmustbemoti-vated too. Often, it is tried to motivate employees with rewards (usuallyfinancial).Butthisaffectsonlytheexternalmotivation.Inordertoachieveagenuineinternalmotivation,itisnecessarytoaddressthefollowingfactorsinaccordancewithmotivationresearchers:
Membership ⬗Security ⬗Expertise ⬗Visibleprogress ⬗
Butyouneedmore:Leadership.Aleadingpersonalityhelpstheteamtofinddirectionandtoorganizetheenvironmentalworksituation,whichisneededtosuccessfulwork.Itprotectstheteamagainstinterferencesfromtheout-side,withoutinterferingthenecessaryinformationflow.Leadershipleadstoagoodteamthatisabletofightacrisissuccessfully,ifitshouldslipinthereonce.
35
InCoRPoRaTe InTeGRITY:Integrityofasystemmeansthatthisformsacoherentwhole.LeanSoftwareDevelopmentdistinguishesbetweeninternal,conceptualintegrityandexter-nal, perceived integrity. The conceptual integrity describes the technicalstructureofthesystem.Isthearchitecturebothunderstandableandexten-sible?Isitpossibletobuildinnewfeatureswithoutproblems?Isthedesignconsistent?
The perceived integrity, however, is a characteristic of the user interface.Doestheuserinterfaceuseasfewaspossibleandcatchymetaphors?Isanappropiatelevelconcerningtheeaseofusereached?Ifsamethingsappear,aretheynamedequally?Integritycannotbe„included“initially.
Asatexthastobereadagainandagaininordertobecorrect,auserinter-face or a design also has to be checked critically and changed, especiallysinceintegrityisusuallynotabigissueatthebeginningofaproject.Itisnotcritical until changesoccur that oversize theplannedextent. Inparticular,theattempttoincorporatethosechanges-withouttouchingtheexistingcodepreferably-leadto„backpacks“,„spaghetticode“andultimatelytothedeathoftheproject.
Thus,thenextimportantitemistheperceivedintegrity.Aclosecooperationbetweendevelopersandusers isbasicrequirement toenableuserspercei-vedintegrity,whentheyworkwithasystem.Thebetterthiscommunicationworks, themoreeasilywrongdecisionscanbedetectedandcorrected.Byshort iterationswithexecutablesoftware,thiscoordinationworksbest.Formorecomplextasks,earliercoordinationmaymakesense.
Inadditiontotheperceivedintegrity,theconceptualintegrityisofimportance.Thebestperceivedintegritywillhardlytobeupholdinthelengthoftime,ifitissheerabigfront,andifitreflectsnointernalconceptualintegrity.Ensuringthe internal conceptual integrity is themain taskof theMasterDeveloper.Therefore,aboveall,thecommunicationwithintheteamhastowork.
However,softwarethatcomesincrementallylosesitsconceptualintegrityovertime.Tocounteractthat,afurthermethodologyisapplied:Therefactoring.Thispointwasalreadydiscussedinsection4.12ExtremeProgramming(XP).
Another,alreadywell-knownresourceforensuringtheintegrityisautomatedtesting.Besidessecuringthecodequalityandthestabilitytowardschanges,automatedtestsanswerthefollowingpurposesaswell:
Communicationofrequirements ⬗Feedback ⬗Skeletonforfurthermethodologies,suchasforexampleRefactoring ⬗Documentation ⬗Maintainability ⬗
seeInG The Whole:Projectmanagementisnotjustaboutquality,time,scopeandcosts.Allthesepoints are important.However, none of thesepoints canbe applied singu-larly.
36
Asuccessfulprojectmanagerneedstoseethewholething:thevariousindivi-dualinterestsofcustomers,employeesandsuppliers,themanyprofessionalandtechnicalfactorsandtheinnerdynamicofaproject.Theyareallcloselyintertwined.Theydonotshapesimplecause-effectchains,butacomplexsys-tem including feedback loops,delaysandunpredictableevents.Understan-dingthesecorrelationsandinfluencingthemistheessentialtaskofeachpro-jectmanager.
Measurementservesasabasisinfulfillingthistask.However,herewithisnotmeanttoapplyhighlycomplex,meaninglessmetrics,buttooberservatetheprojectconsciouslyingeneralandtointerprettheapparentprojectprogess.Simplekeyfigures, suchase.g. thenumberofopenerrors, areabsolutelysufficient.
Drawingabowtocooperation,oneresourceremains:thecontracts.Contractsserveasabasis formainly twopurposes.First, theyare the foundation tocooperationandsecondly,theyallocatetheresponsibilitytothecontractingparties.
A method similar to Lean Software Development is Kanban. Kanban wasdevelopedin2007byDavidAndersonandisbasedontheprinciplesofLeanDevelopmenttoo.Themethodreliesonalimitationofthe„WorkinProgress“(WiP),whereuponnomorethanadefinedsetofrequirementsmaybeimple-mentedatthesametime.
AvisualizationoftheWiP,e.g.onawhiteboard,makesvisiblewherebottle-necksareintheprocessing.Byeliminatingthebottlenecksanimprovementoftheflowpathisachieved.
SinceKanbanandLeanSoftwareDevelopmentareelsewhereverysimilar,inthefurtherprogressofthisstudyKanbanwillnotbeexplicitlyaddressed.
MICRosofT solUTIons fRaMeWoRk foR 3.17 aGIle sofTWaRe DeVeloPMenT (Msf4asD)
The Microsoft Solutions Framework (MSF) is a set of principles, models,disciplines,conceptsandguidelinesforIT-projects.Aspecificprocessmodelisnotgivenbydefault-itcanbeappliedbothfortheclassicaldevelopingaswellasforagileapproaches.
The Microsoft Solutions Framework for Agile Software Development(MSF4ASD)isaparticularexpressionoftheMSF,justforagiledevelopment.Thereby it is about a template for theVisual Studio TeamSystem (VSTS).Productdefinition,developmentandtestingareprocessedinoverlappingite-rationswiththeaimofcompletingtheprojectincrementally.Eachiterationhasaslightlydifferentfocus,suchasthefollowingfigureshows.
Furthermore,MSF4ASDprovidesavarietyofprinciples, rolesandwaysofthinking,which are based on the agilemanifesto. Similarly,many types ofresultsarepre-definedtowhichthetemplatefortheVSTSincludesexamplesandtemplatesforthegivensituation.
37
MobIle-D3.18 Mobile-DistheagilemethodeformobileapplicationdevelopmentoftheFin-nishresearch-organisationVTT.Themethodincludesthephases
Explore ⬗Initialize(iteration0) ⬗Productionize ⬗Stabilize ⬗SystemTest&Fix ⬗
ThephasesProductionize,StabilizeandSystemTest&Fixruniterativelyandincludeeachof thestepsPlanningDay,WorkingDayandReleaseDay.ThesequencewithinaphaseisshowninFigure16.
RaPID aPPlICaTIon DeVeloPMenT (RaD)3.19
The„rapidapplicationdevelopment“istoascribedtoanideabyBrianGal-lagher,AlexBalchin,BarryBoehmandScottShultzbythe1980s,inordertomake the heavy software developmentmethods developed from the 1970smoreflexible.ThetermRADtherebywasnotpopularuntiltheearly1990s.JamesMartindevelopedamethodbasedoniterativedevelopmentofproto-types,whileIBMpublishedabookcalled„RapidApplicationDevelopment“in1991.
Asshowninfigure17,theprocessstartswithadiscussionincludingallpar-ties to create a rough list of basic requirements and prioritize them.Bothdevelopersandcustomersmayhaveconversationswitheachother,asoppo-sedtofurtherdiscussions.Basedonthelistofbasicrequirements,developersdesignaworkingprototypeofthesoftwareassoonaspossibleaccordingto
ContentsofFigure15:iterationsinMSF4ASD
TheendofaphaseinFigure16:Mobile-D
38
therelevanceofpriorities.Theymayusea„softwarebuildingkit“soas toassemblethemostimportantbasicrequirementsquickly.
Aftercompletionof thefirstprototype,a testby thecustomer takesplace.Headdsfurtherrequirementsandrefinesexistingrequirements.Inafurthermeeting,theagentshallnotifytheprincipleconcerningenhancedand/ornewrequirements.Thismeetingshalltherebyratherbeperformedasamonologueoftheagent.
Thenewrequirementsareoptimizedinashortdevelopmentcycle(fromoneday to threeweeks) and added to the software. This iteration is repeateduntilthesoftwarewithallpropertiesdesiredbythecustomerispresent.Thisapproachcreates ineach iterationnew, improvedversionsof thesoftware.Byminimalplanninginadvanceandplanningparalleltodevelopment,RADpromisesoperationalsoftwareinlessthan120days.
sCRUM3.20 Asearlyasinthe1980s,itwaslookedformoreflexibleapproachesinsoftwaredevelopment.Scrumisanagileframeworkbothforthesoftwaredevelopmentaswellasforprojectmanagement.Basedon„LeanProduction“,itwasdesi-gnedbyKenSchwaber,JeffSutherlandandMikeBeedle.Bothmethods,LeanProductionandScrum,focusthecontinuousdevelopment(employees,proces-ses,resources,methods)withtheaimofongoingproductionimprovementsoastoreachhighestqualitywithminimaleffort.
InScrum,thereisthecardinalhypothesisthatproductionassemblyaswellasdevelopmentprocessesaresuchlikeextensivethatparticularphasesandstepscannotbeplannedinadvance.However,ifateamorganizesitself incompliancewithfixedpresettings,thiswillleadtomoreeffectiveness.
Scrumusesitsownvocabularytoknownstandardterms.Forthatreason,themostsignificanttermswillbeexplainedhereinafter.Threerolesareinvolveddirectlyintheprocess.
Roles3.20.1 PRoDUCT oWneR:TheProductOwnershallprovidetheagentroleandisplacedingeneralbythedepartment.Hewritesandprioritizetherequirementsanddeterminestheirorder.Heisavailabletotheteamforinformationandisresponsibleforthesuccessoftheprojectlikewise.
RADprocess(Source:Figure17:http://blog.twinklesprings.com)
39
sCRUM MasTeR:Asacoachandfacilitatoroftheteam,theScrumMastermakessurethatthescrumrulesarestickedto.Hemanagestheentireprocess,eliminatesdisor-dersandworkscloselywiththeProductOwnertogetherinordertoshapetheprojectasvalue-addingaspossibleforthecompany.Moreover,hehelpstheteamtoincreaseitsproductivity.
TeaM:Therearepeoplewithdifferentexpertiseinvolvedtothedevelopmentoftheproductwithintheteam.Theteamhasallthequalificationsneededtotransferthedefinedrequirementsinfunctionality.
MaIn eleMenTs3.20.2 PRoDUCT baCkloG:Theproductbacklogshowsallthepropertiesoftheproducttobedevelopedinaprioritizedlist.Theserequirementscanberemovedandnewrequirementsadded.Theprocessingofrequirementsiscarriedoutindecreasingorderofpriority.
sPRInT:Fixedcycle(iteration)intwotofourweeksusually,withintheproductisdeve-loped.Attheendofeachsprint,afunctionalincrementcanbedeployed.Yetinordertogainrealaddedvaluetothecompany,usuallyseveralsprintsarenecessary.
sPRInT baCkloG:TheSprintBacklogdefines theworkscopeof the team foreach individualsprint. It contains the selected requirements from theProductBacklog. Inaddition,asummaryofalltaskstobedevelopediscompiledregularlysoastoachievethegoalofthesprint.
DaIlY sCRUM:Ato15minuteslimitedmeeting,whichtakesplaceeveryday.Regularcom-municationservestheexchangeofinformationamongeachotherrelatedto:
Statusquo ⬗Futuretasks ⬗Problemsoccured ⬗
oPeRaTIonal seQUenCe DesCRIPTIon3.20.3 Inalist(ProductBacklog)requirementsareadded,completedandprioritized.IncollaborationwiththeProductOwner,thehigherprioritiziedrequirementsof theProductBacklog are extracted regularly by the teamandduring aniteration(Sprint)completelyimplemented.PartsoftheProductBacklogthathavenotbeenextractedsofarmaybeprioritizedagainbytheProductOwnerforsubsequentsprints.
During Sprint, the teamworks focused andwithout interferences in orderto transfer therequirementsof theSprintBacklog inacompletelyfinishedandpotentiallyproductive,operatingapplicationpart(PotentiallyShippableFunctionality). A to 15minutes limited Informationmeeting (Daily Scrum)takesplaceeverydaytoassurethatallteammembersreachthesamelevelofknowledgeandtoproactivelypointtopotentialproblems.Attheendofthe
40
Sprint, theteamdemonstratesall involvedpersonsthe fullydevelopedandexecutablepropertiesonthesysteminrealtime(SprintReviewMeeting).
ReactionsofparticipantsandnewrequirementsareincorporatedintothenextSprintPlanningMeeting,whichistobeheldbeforeeachsprint.Theprocess(seefigure18)willbepassedthroughagain.
TesT DRIVen DeVeloPMenT (TDD)3.21 Thetraditionalsoftwaredevelopmentproposesimplementingcustomerrequi-rementsfirst inphasesand to test independentlyat theend.The testsarecreatedeitherparalleltothedevelopmentofsoftwareoronlyattheendofdevelopment.TDDreversesthisprocedure.Beforecoding,theprogrammerthinksabouttherequirementsthesoftwarehastomeetandwhichtestsareappropiate.Basedonthetests,theactualprogrammingisdonegraduallyinshort,iterativecycles.Anycycletraversedoptimizesthesoftwaretoadditio-nalproperties.Thisprocedureisexecutedthefollowingway:
1sT: CReaTInG a TesTAnewtestisgeneratedtoeachnewfeatureacustomerrequiresrelatedtothesoftware.Inordertocreateatest,thedeveloperhastoclearlyunderstandthecustomer‘srequirementsorspecialfeaturesofthesoftware.
2nD: eXeCUTInG a TesT (1)Bythefirsttestrun,theprogrammingisnottobechecked,sincenosinglelineofcodewaswritten.Thefirsttestrunisusedforthefunctionalvalidationofthetestingenvironmentandtoensurethatthetestrunsitselfandprovidestheexpectedresult„error“.
ScrumFigure18:Process
41
3RD: WRITInG/ fITTInG CoDe:Afterthefirsttest,thecodeisbeingwrittenwithaslittleeffortaspossibleinorderto justpassthenexttest.Additional functionalityof futurephasesshouldnotbeanticipated.Thewrittencodeinpresentconditionisnotperfect,butisoptimizedinthenextpasses.
4Th: eXeCUTInG a TesT (2)Whenthecodeiswrittenoradjusted,atestruntakesplaceagain.Thethirdandfourthsteptherebywillbelooped,untilalltestcasesarepassedfortheprogrammedunit.Developersnowcanbeconfidentlythatthecodemeetsallthetestedrequirements.
5Th: RefaCToRInGInthelaststep,thecodeissimplifiedbyrefactoring,eliminatingredundancyandmakingitcomprehensible.Attheendofrefactoring,itisrecommendedtoexecutealasttestruninordertoensurethatnoexistingfunctionalityhasbeendamagedbyrefactoring.Figure19 illustrates theentireprocess.Thedevelopmentofasoftwareisstructuredindifferent„units“.Eachunitpassesthroughthelifecycle.Thestagesthreeandfour(Writing/fittingcode,execu-tingatest)arerepeated,untilthedesiredfunctionalityofaunitisreached,allerrorshavebeeneliminatedandthedevelopercannotthinkofmorereaso-nabletests.Theprocesswillbepassedthroughbyeachunit.TDDisnotestmethod,butasoftwaredevelopmentmethod.
UnIfIeD PRoCess (UP)3.22 TheUnifiedProcess(UP) isapopularprocessframework.Themostknownrealization is theRationalUnifiedProcess(RUP).However, thereareothervariantsoftheUP.ThecommonfoundationofallrealizationsofUPis:
DeVeloPMenT Phases:Thedevelopmentisdividedintophases.TheUPresemblesthefollowingpha-ses:
23
TestDrivenDevelop-Figure19:mentLifecycle(ownpresentation)
42
Inception ⬗Elaboration ⬗Construction ⬗Transition ⬗
SomevariantsoftheUPextendthisphasemodel.
DIsCIPlInes:Thefollowingdisciplinesareprocessedinasoftwaredevelopmentproject:
BusinessModeling ⬗Requirements ⬗AnalysisandDesign ⬗Implementation ⬗Test ⬗Deployment ⬗
Overthephases,thecostdistributionconcerningthedisciplinesisrepresen-tedinthefollowingfigure20.
ITeRaTIVe anD InCReMenTal:Within thephases,projectresultsareprogressed iterativelyand incremen-tally.
Use Case DRIVen:Inordertodocumentthefunctionalrequirements,usecaseswillbeemplo-yed.
aRChITeCTURe-CenTeReD:UPfocusestheeffortsinthedesignofasystem-architecture.
CostFigure20:distributionofthedifferentdiscip-linesaboutthe
phasesoftheUP(source:Wikipe-
dia)
43
RIsk-foCUseD:RisksareaddressedearlywithinUP.Theresultsofeachphaseareselectedinawaythatpointswiththehighestrisksareprogessedfirst.
ThefollowingrealizationsoftheUnifiedProcessexist:
AgileUnifiedProcess(AUP):AlightweightversionbyScottW.Ambler ⬗EssentialUnifiedProcess(EssUP):AlightweightversionbyIvarJacob- ⬗sonOpenUnifiedProcess(OpenUP):Thedevelopmentprocessofthe ⬗EclipseProcessFrameworksRationalUnifiedProcess(RUP):Thedevelopmentprocessofthecom- ⬗panyRational(nowIBM)RationalUnifiedProcess-SystemEngineering(RUP-SE):Adaptationof ⬗RUPforsystemsengineeringEnterpriseUnifiedProcess(EUP)AnextensiontotheRUPatphases ⬗fortheentirelifecycleofsoftware(operatingandphase-out)OracleUnifiedMethod(OUM):ThedevelopmentprocessoftheOracle ⬗company
The Unified Process and its most famous realization, the Rational UnifiedProcess,arenoagileprocessmodels.ThesameistrueoftheRationalUni-fiedProcessforsystemengineering,theEnterpriseUnifiedProcessandtheOracleUnifiedMethod.Inthefollowing,onlythosevariantsoftheUPwillbeconsideredinmoredetail,whichsupporttheagilemethodology.
aGIle UnIfIeD PRoCess (aUP) 3.22.1
TheAgileUnifiedProcess(AUP)isasimplifiedversionoftheRationalUnifiedProcessandwasdevelopedbyScottW.Ambler.ThegoalistofacilitateagilitywithintheframeworkofRUP.Therefore,thedisciplinesBusinessModeling,RequirementsandAnalysisanddesignhavebeenaggregatedto„Model“.As
PhasesFigure21:anddisciplinesoftheAgileUnifiedProcess(source:www.ambysoft.com)
44
showninfigure21,thisdisciplinetakessignificantlylessefforttocomplete.Inthiscase,itissufficientthatmodelsare„justgoodenough“fortheproject.
AUPdistinguishesbetweeniterationsin„DevelopmentReleases“andin„Pro-ductionReleasesaswell:DevelopmentreleasesaredeployedinaQA-and/ordemoenvironment.Aproductionrelease,ontheotherhand,goesinproduc-tion.
Eventhoughnotallreleasesaregoingtobeinproduction,allreleaseswillbetargetedasexecutableresults.
TheAUPistherebybasedonthefollowingprinciples:
Thewholeteamknowswhatitdoes ⬗Simplicity ⬗Agility(withinthemeaningoftheagilemanifesto) ⬗Focusoncurrenttasks ⬗Toolindependence ⬗Possibiltyoftailoringthemethod ⬗
essenTIal UnIfIeD PRoCess (essUP)3.22.2 The Essential Unified Process (EssUP)was developed by Ivar Jacobson asanimprovementtotheRationalUnifiedProcess.Itidentifiespracticessuchasusecases,ArchitectureDrivenDevelopment,teampracticesandprocesspracticesborrowedfromCMMI,RUPandagiledevelopment.Fromallthesepractices,onecannowtakethose,whichareappropiatefortheconcretesitu-ationandmergethemtoaseparateprocess.
oPen UnIfIeD PRoCess (oPenUP)3.22.3 TheOpenUnifiedProcess(OpenUP)isaleanrealizationoftheUnifiedPro-cess,which provides iterative, incremental approaches in a structured lifecycle.ItispartoftheEclipseProcessFramework,anOpenSourceProcessFrameworkoftheEclipseFoundation.
TheOpenUPisbasedonfourbasicprinciples:
Cooperationinfavorofcommonunderstandingandbalanceofinte- ⬗restsCompetingprioritiesarebalancedtothehighestuserbenefits ⬗Earlyfocustothearchitecturetominimizerisksandtoguidedevelop- ⬗mentContinuousfeedbackandimprovement ⬗
ThecontentoftheOpenUPisdividedintothreeareas:
Personalarea:Encompassestheworkofeachindividualasamicro- ⬗incrementTeamarea:Thewholeteamdevelopsoperatingsoftwarewithinone ⬗iterationStakeholderarea:Encompassesthefullprojectlifecycle ⬗
45
DIsCIPlInes:AsallrepresentativesoftheUnifiedProcess,OpenUPencompassesdifferentdisciplinesaswell.Theseare:
Requirements ⬗Architecture ⬗Development ⬗Test ⬗ProjectManagement ⬗ConfigurationandChangeManagement ⬗
TheprojectlifecycleofanOpenUPprojectisdepictedbelowinfigure23.
ContentareasFigure22:oftheOpenUP(Source:http://epf.eclipse.org/wi-kis/openup/)
ProjectLifeFigure23:CycleunderOpenUP(source:http://www.eclipse.org/epf/general/OpenUP.pdf)
46
UsabIlITY DRIVen DeVeloPMenT (UDD)3.23 UsabilityDrivenDevelopment(UserInterfaceDrivenDevelpomentorUI-FirstSoftwareDevelopmentlikewise)isaniterativedevelopmentprocessthatcen-terstheusabilityofasystem.ExtremeProgrammingservesasamodel-ithasbeenextendedwithelementsoftheUserCenteredDesign.
EachiterationconsistsofninephasesinUDD: ⬗Experimentalgame ⬗Costestimation ⬗Interfacedesign ⬗Modeling ⬗Testdesign ⬗Programming ⬗Integration ⬗Deployment ⬗UsabilityTest ⬗
Thesequenceofphasesisshowninfigure24.
Phase 1 - eXPeRIMenTal GaMe:ThedevelopmentofsoftwareinaccordwithUDDbeginswithanexperimentalgame.Thecustomerorateammemberofthebusinesssidenotesallthetasksthesystemshouldbeabletohandleintermsofstorycards.Thesestorycardsareorderedasperpriorityanddevelopedaccordingtothatorder.
Theexperimentalgameisrepeatedateachiteration.Thisgivesthecustomertheabilitytochangeprioritizationineachiterationandtoaddcompletelynewstorycards.Morestorycardswillbeaddedbyusabilityteststakenplaceinthecourseofdevelopment.Thesehavegottobeprioritizedbythecustomerlikewise.
Phase 2 - CosT esTIMaTIon: Eachdevelopertakesstorycards,whichencompasstheworktobedoneuntilthenextexperimentalgame.Here,thecostestimationisdonebythedevelo-persthemselves.Theactualtimeswiththeestimatedtargettimesarecompa-
EndofaniterationFigure24:inUDD(source:http://www.jensjaeger.com/tag/usability-
drivendevelopment/)
Programming
47
redaftereachiteration.Thisresultsinabetterbasisforfurtherestimatesinthecourseofaproject.
Phase 3 - InTeRfaCe DesIGn: Comparedtothedesignofinterfaces,programmingisverycomplexandonlydifficultlyalterable.Hence, inUDDtheGUIofanapplication isconsideredfirst.Shapingthesurfaceofsoftwareisrelativelyeasy.Asketchonasheetofpaperismadequicklyandalteredeasily.Anotherimportantreasontodesigntheinterfacefirstisthatthesurfaceiswhatusersgettosee.Itwillbedifficulttoattractcustomerswithanapplicationsoftware,whichhasgreatfeatures,butanunattractivesurface.
In caseof extensionsor extensive changes concerning the surface, it shallbemadeuseoftheoptiontojumpinthephaseofusabilitytesting.Thus,thedrafteddesignwillbeexaminedandpossiblyimproved,beforetoomuchworkhasbeeninvested.
Phase 4 - MoDellInG: Oncethesurfaceofafunctionisdesigned,thephaseofmodellingbegins.Anoverviewexplainingthewaythenewfunctionalitymaybeintegratedinthewholesystemshallbecreatedwithinthemodelling.
Whatdatabasefieldsareneeded,whereinthelayermodelthefunctionistobeimplemented,whichlibraryfunctionscanbeused,whichalgorithmsaremostsuitableforthesolutionofproblems?Thesequestionsshouldbeaskedandansweredbythedevelopers.
Ifindoubt,theviewsofcolleagueswillbeobtainedorifpossible,atestwillbedeveloped.Aloadtestcanbequiterevealing,especiallyincaseofperfor-manceissues.
Inthisstageitisnotaboutdescribingthefunctionalitytobedevelopeddownto the lastdetailwithUMLcharts.Chartsshouldonlybeused,where it isusefulandthuscreatingbenefit.
Phase 5 - TesT DesIGn: Thenextphaseisnamedtestdesign.Allonthestorycardlistedfeaturestobeelaboratedwillbeimplementedintermsoftests.Itresultsinanexecutablespecificationof the functionalityrelating to thestorycard (seeTestDrivenDevelopment).Exceptionsarestorycards,whichdealexclusivelywithimpro-vementstothesurfaceanddonotalteranyfunctionalityofthesystem.Thesemayhaveemergedbyausabilitytestandmaybedifficultornotmechanicallytestableatall.Inthatcase,thisphasewillbeskipped.
Phase 6 - PRoGRaMMInG: Intheprogrammingphase,theresultsfromthepreviousphaseswillbeimple-mented. The previously designed user interface is implemented, requiredclassesandmethodswrittenanddatabasestructuresdeveloped.
Indoingso, the simplest solution thatworks shouldalwaysbechosenandimplemented.Programmingisdone,whenalltestscanbeexecutedcorrectly.Aftersuccessfullytesting,thenewlydevelopedsourcecodeshouldbetrialedbyarefactoring.
48
Phase 7 - InTeGRaTIon: Integration means bringing the modified source code with the code basetogether.Beforethisstepcanbemade,all testshavetobecompletedsuc-cessfully.
Asatooltointegration,aversionmanagementshouldbeusedbyallmeans.Itisadvisablethatthepossiblycreatedchartsduringthemodellingphasegetcheckedinaswellintheversionmanagementinadditiontothesourcecode.
Ontoolsthatautomaticallypassalltestsandtriggerabuildineachsoftwareversion,whichisrecordedtotheversionmanagement,shouldnotbewaived.Thus,errors,suchasaforgottencheck-inofafileintheversionmanagement,canbeeasilydetected.
Phase 8 - DePloYMenT:Thetermdeploymentdescribestheautomaticdistributionanddeliveryofthedevelopedsoftware.Ideally,thenewlycreatedfunctionisrecordedinthepro-ductionsystem.
Thisleadstotheadvantagethatfurtherdevelopmentsareavailableimmedia-telytotheusers.Despiteextensivetesting,thisyetimpliestheriskoferrorswithintheproductiveversion.Inordertotakethisrisk,thepossibilityofrevo-kingadeploymenthastobepresentatanytime.
Ifanimmediateproductionstartofanewreleaseisnotpossibleornotdesi-red,oneshoulddeployatleastonatestsystemtohaveaworkingsystemwiththelatestsoftwareversionfortestsanddemonstrationsalwaysavailable.
Phase 9 - UsabIlITY TesT: TheusabilitytestisthefinalphaseofaUDD-iteration.Thedeveloperwilltestthenewlyimplementedfunctionregardingtothefunctionalitydescriptiononthestorycard.
If,despiteofextensivetesting,errorsarefound,theprecedingdeploymentwillbecalledoffimmediatelyandtheiterationwillbepassedthroughagainwithaviewtodebugging.Thefunctionalityshouldbeensurednormally.
However,itwilloftenbethecasethatideasforimprovingregardingthejustdevelopedfunctionalityoradifferentfeatureofthesystemarise.Thesearelistedintermsofstorycardsandhavetobeprioritizedbythecustomersinthenextexperimentalgame.
49
eValUaTIon 4 Inthefollowingsections,theagilemethodsarebeingevaluatedinaccordancetovariouscriteria.Thecriteriaare:
Coverageofdisciplinesinsoftwareengineering ⬗Levelofawarenessanddisseminationofmethods ⬗Supportfordifferenttypesofprojects ⬗Supportbytools ⬗Normalization,standardization,certification,licensing ⬗Industryfocus ⬗Supportduringintroductionandutilization ⬗
Adetaileddescriptionof thecriteriausedand the individualevaluations isprovidedintherespectivechapters.
CoVeRaGe of DIsCIPlInes In sofTWaRe 4.1 enGIneeRInG
Itwillbeexaminedbelow,towhatextentagilemethodscoverdisciplinesofsoftwareengineering.Asdisciplinesofsoftwareengineeringwillbeconside-red:
ProjectManagement ⬗QualityManagement ⬗RequirementsManagement ⬗Systemdesign/technicalconception ⬗Implementation ⬗Test ⬗Integrationanddeployment ⬗Maintenance ⬗Operation ⬗
PRojeCT ManaGeMenT: Projectmanagementisuseofknowledge,skills,toolsandtechniquesonpro-jectactivitiestomeetprojectrequirements.Thisencompassestheactivitiesofplanning,controllingandchecking,andtheareasoftimemanagement,scopemanagement,riskmanagement,costmanagement,project-specificprocure-mentofproductsandservices,humanresourceplanning,projectintegrationandprojectcommunication.
QUalITY ManaGeMenT: QualityManagement is understood as coordinated activities to direct andcontrolanorganizationintermsofquality.Directingandcontrollingintermsofqualitytypicallyincludessettingthequalitypolicyandqualityobjectives,qualityplanning,qualityassuranceandqualityimprovement(ISO9000).
50
ReQUIReMenTs ManaGeMenT: Requirementsmanagementistheprocessofidentification,inquiry,documen-tation, analysis, tracking, prioritization and coordination of requirements.AccordingtoIEEE610,arequirementisadocumentedrepresentationofaconditionorcapabilityasper1.or2.:
1.Habitorabilitythatuserneedtosolveaproblemortoachieveanobjec-tive.
2.Habitorabilitythatiscompliedorneededbyasystemorsystempart,inordertofulfillacontract,astandard,aspecificationorotherformallygivendocument.
sYsTeM DesIGn / TeChnICal ConCePTIon: Systemdesignisthedefinitionofasystem-architectureaswellasthecom-ponents,modules,interfacesanddataofasoftware-system.
IMPleMenTaTIon: Implementationistheconversionofthetechnicalspecificationandthealgo-rithmsintoanexecutablesoftwareprogram.
TesT: Thetestsupportsensuringthesoftwarequalityandtotest,whethertherequi-rementsconcerningthesoftwarewillbemet.AccordingtoIEEE829,atestisacertainquantityinoneormoretestcases.AtestcaseregardingtoIEEE610comprisesthefollowing:
Thenecessarypre-conditionsfortheaccomplishment ⬗Thesetofinputvalues(onevaluepertestobjectparameter) ⬗Thesetofpredictedresults ⬗Theexpectedpost-conditions ⬗
Testcasesaredevelopedwithaviewtoacertaintargetoratestcondition,e.g.executingaparticularprogrampathorexaminingthecompliancewithspecificrequirements(suchashandingoffinputsthetestobjectandreadingoffdesiredvalues).
InTeGRaTIon anD DePloYMenT: Integrationistheprocessoflinkingindividualcomponentstolargerunitsandultimatelytothewholesystem.Deploymentisthecommissioningofsoftwareandtheroll-outtotheusers.
MaInTenanCe: Maintenanceisthemodificationofasoftwareproductafteritsdeploymentinordertocorrecterrorconditions,toimprovetheperformanceorothercharac-teristicsortoadapttheproductforadifferentenvironment.
51
oPeRaTIon: Operationmeanssecuringtheproductiveuseofsoftware.ThisencompassesthefollowingtopicsincompliancewithITILV3
ServiceStrategy ⬗ServiceDesign ⬗ServiceTransition ⬗ServiceOperation ⬗ContinualServiceImprovement ⬗
withtheirrespectiveprocesses.
52
PRofIles afTeR eValUaTInG The MeThoDs 4.2 Theresultofevaluationispresentedinthefollowingfiguresintheformofspidercharts.Theevaluationisdonewiththevalues0-4,where0meansnoandfourfullcoverage.Ithasbeenevaluated,towhatextentthedisciplinesofsoftwareengineeringwillbeaddressedbytherespectivemethods.Theevalu-ationdoesnotspecifythequalityofresultstoaspecificproject.
PRofIlesThefollowingabbreviationsareusedinthespidercharts:
PM:ProjectManagementQM:QualityManagementRM:RequirementsManagementSD:Systemdesign/technicalconceptionIMP:ImplementationT:TestINT:IntegrationandDeploymentM:MaintenanceO:Operation
53
0
1
2
3
4PM
QM
RM
SD
IMPT
INT
W
B
Agile Enterprise
0
1
2
3
4PM
QM
RM
SD
IMPT
INT
W
B
AMDD
0
1
2
3
4PM
QM
RM
SD
IMPT
INT
W
B
ActiF
0
1
2
3
4PM
QM
RM
SD
IMPT
INT
W
B
ASD
0
1
2
3
4PM
QM
RM
SD
IMPT
INT
W
B
BDD
0
1
2
3
4PM
QM
RM
SD
IMPT
INT
W
B
Crystal
54
0
1
2
3
4PM
QM
RM
SD
IMPT
INT
W
B
Design Driven Development (DDD)
0
1
2
3
4PM
QM
RM
SD
IMPT
INT
W
B
Dynamic System Development Method (DSDM)
0
1
2
3
4PM
QM
RM
SD
IMPT
INT
W
B
Eclipse Way Process
01234
PM
QM
RM
SD
IMPT
INT
W
B
Evolutionary Process for integrating COTS-Based
Systems (EPIC)
01234
PM
QM
RM
SD
IMPT
INT
W
B
Evolutionary Project Management & Product
Development (EVO)
0
1
2
3
4PM
QM
RM
SD
IMPT
INT
W
B
Extreme Programming (XP)
55
0
1
2
3
4PM
QM
RM
SD
IMPT
INT
W
B
Feature Driven Development (FDD)
0
1
2
3
4PM
QM
RM
SD
IMPT
INT
W
B
Iconix
0
1
2
3
4PM
QM
RM
SD
IMPT
INT
W
B
Internet-Speed Development (ISD)
0
1
2
3
4PM
QM
RM
SD
IMPT
INT
W
B
Lean Software Development (LSD)
0
1
2
3
4PM
QM
RM
SD
IMPT
INT
W
B
MS Solution Framework (MSF4ASD)
0
1
2
3
4PM
QM
RM
SD
IMPT
INT
W
B
Mobile-D
56
0
1
2
3
4PM
QM
RM
SD
IMPT
INT
W
B
Rapid Application Development (RAD)
0
1
2
3
4PM
QM
RM
SD
IMPT
INT
W
B
Scrum
0
1
2
3
4PM
QM
RM
SD
IMPT
INT
W
B
Unified Process
0
1
2
3
4PM
QM
RM
SD
IMPT
INT
W
B
Agile Unified Process (AUP)
0
1
2
3
4PM
QM
RM
SD
IMPT
INT
W
B
Essential Unified Process (EssUP)
0
1
2
3
4PM
QM
RM
SD
IMPT
INT
W
B
Open Unified Process (OpenUP)
57
0
1
2
3
4PM
QM
RM
SD
IMPT
INT
W
B
Test Driven Development (TDD)
0
1
2
3
4PM
QM
RM
SD
IMPT
INT
W
B
Usability Driven Development (UDD)
58
Tables4.3 Thefollowingtablesummarizestheevaluation,wherethefollowingsymbolsareused:
0 Nocover1 Lowcoverage2 Mediumcoverage3 Coverage4 Fullcoverage
Thefollowingabbreviationsareusedinthetables:
PM:ProjectManagementQM:QualityManagementRM:RequirementsManagementSD:Systemdesign/technicalconceptionIMP:ImplementationT:TestINT:IntegrationandDeploymentM:MaintenanceO:Operation
59
Method PM QM RM sD IMP T InT W b
actif 3 2 4 3 4 1 3 0 0
agile enterprise 4 3 4 2 4 4 3 1 0
aMDD 1 2 2 2 3 4 3 3 3
asD 2 4 1 1 2 1 0 0 0
bDD 0 3 4 1 2 2 1 0 0
Crystal 2 3 2 0 3 4 1 1 0
DDD 0 1 3 1 1 1 0 0 0
DsDM 2 2 4 4 4 4 4 3 2
eclipse Way Process 4 2 4 4 4 4 3 1 0
ePIC 4 3 3 3 2 3 3 0 0
eVo 4 2 2 3 2 4 2 0 0
extreme Programming (XP) 1 3 3 2 4 4 2 1 0
fDD 3 3 3 4 3 1 1 0 0
Iconix 3 4 4 4 4 4 3 1 0
IsD 3 0 3 1 3 3 4 0 1
lsD 1 4 2 3 3 4 2 1 1
Mobile-D 2 2 2 1 2 3 1 0 0
Ms solution framework 3 2 2 2 3 3 2 0 0
RaD 1 1 2 0 4 3 3 1 0
scrum 4 3 4 1 1 1 3 1 0
TDD 0 3 1 0 4 4 2 1 0
UDD 2 3 3 2 2 4 4 1 0
Unified Process 1 1 4 4 4 3 3 1 0
aUP 4 1 3 3 4 3 3 1 0
essUP 4 2 3 4 4 3 3 1 0
oUP 4 1 4 4 4 3 3 1 0
Summaryofevaluation.Table1:
60
leVel of aWaReness anD DIsseMInaTIon of 4.3.1 MeThoDs
Theevaluationofthelevelofawarenessanddisseminationofagilemethodswasperformedbyreferencetothefollowingparameters:
nUMbeR of seaRCh ResUlTs In GooGle: Thenumberof searchresults inGoogle (www.google.com)hasbeenanaly-zed.Inordertofindonlythemostrelevantmethodsandtopreventobtainingresultswithothermeaningsofaterm(thetermScrume.g.comesfromtherugbysports),thefollowingsearchtextwasused
„<method>“agiledevelopment
Themethodtherebyhasbeenwrittenwithnoabbreviations.Example:
„TestDrivenDevelopment“agiledevelopment
Thenumberofresults for the levelofdiffusionhasbeendivided in„high“,„medium“and„low“.
Levelofdiffusionhigh:>100.000hitsbytheabovesearch ⬗Levelofdiffusionmedium:10.000-100.000hits ⬗Levelofdiffusionlow:<10.000hits ⬗
nUMbeR of books aVaIlable aT aMazon: Theobtainednumberofbooks,onthewebpageofAmazon(www.amazon.com)hasbeenanalyzed.Thesamesearch termsasonGoogle’spagehavebeenused.
The number of results for level of diffusion has been divided in „high”,„medium“and„low“.
Levelofdiffusionhigh:>10hitsbytheabovesearch ⬗Levelofdiffusionmedium:5-10hits ⬗Levelofdiffusionlow:<5hits ⬗
nUMbeR of PeRsons WITh knoWleDGe anD eXPeRIenCe In The MeThoDs:
Profiles that are saved inaWesternEuropean portal for freelancershavebeenanalyzed.Indoingso,thecandidate’sprofileshavebeensearchedfortherespectivemethodnames.Inordertoonlyfindtheappropriatemethods,themethodshavebeensearchedinquotationmarks.Example:„Feature-dri-vendevelopment“
The number of results for level of diffusion has been divided in „high“,„medium“and„low“.
Levelofdiffusionhigh:>100hitsbytheabovesearch ⬗Levelofdiffusionmedium:10-100hits ⬗Levelofdiffusionlow:<10hits ⬗
61
Method Google books People Total
actif Low Low Low Low
agile enterprise Medium Low Low Low
aMDD Medium Low Low Low
asD Low Low Low Low
bDD Low Low Low Low
Crystal High Low High High
DDD Low Low Low Low
DsDM Medium Low Low Low
eclipse Way Process Low Low Low Low
ePIC Low Low Low Low
eVo Medium Low Low Low
extreme Programming (XP) High High High High
fDD Medium Medium Medium Medium
Iconix Low Medium Low Low
IsD Low Low Low Low
lsD Medium High Low Medium
Mobil-D Low Low Low Low
Ms solution framework Low Low Low Low
RaD Medium Medium Medium Medium
scrum High High High High
TDD High Medium Medium Medium
UDD Low Low Low Low
Unified Process Medium Medium Medium Medium
aUP Medium Low Low Low
essUP Medium Low Low Low
oUP Medium Low Low Low
Evaluationoflevelofawarenessanddissemination.Table2:
62
Thefollowingfiguredepictstheresultsgraphically:Thetoponescanbeseenasthe„favorites“,theonesbelowratherasthe„exotic“.
0 2 4 6 8 10
UDD
MSF4ASD
Mobil-D
ISD
EPIC
Eclipse Way Process
DDD
BDD
ASD
Actif
Iconix
EVO
DSDM
AMDD
Agile Enterprise
OUP
EssUP
AUP
Unified Process
RAD
LSD
FDD
TDD
Crystal
Scrum
XP
Overallevaluationre-Figure25:gardingtothelevelofawareness
(Google,books,people)
63
sUPPoRT of DIffeRenT TYPes of PRojeCTs 4.3.2 Anothercriterionfortheevaluationofthemethodsisthesupportofdifferenttypesofprojects.Threetypesofprojectswereconsidered:
Newdevelopmentofcustomsoftware ⬗Furtherdevelopmentofcustomsoftware ⬗Customizingandadjustingdevelopmentofstandardsoftware ⬗
neW DeVeloPMenT of CUsToM sofTWaRe: Thenewdevelopmentofcustomsoftwareisunderstoodasthedevelopmentofanewsoftwaresystem.
DeVeloPMenT of CUsToM sofTWaRe: Thefurtherdevelopmentofcustomsoftwareisunderstoodasthefunctionalextensionofanexistingsoftwaresystem.
CUsToMIzInG anD aDaPTInG DeVeloPMenT of sTanDaRD sofTWaRe:
Customizingofstandardsoftwareandadaptingdevelopmentisunderstoodastheadoptionofastandardsystemtocompany-specificcircumstances.Custo-mizingtherebyistheadjustmentofconfigurationofthesoftwarewithoutpro-grammingactivities(e.g.thechangeofconfigurationfilesinthetexteditor),whileintheadaptingdevelopmentthesoftwareismadereadyforoperationbyprogrammingactivities(e.g.ABAP-developmentinanSAPsystem).
Wehavecometotheconclusionthatinanagileprojectenvironmentitcannot be differentiated between different types of projects, since the projectapproachprimarilydependson thebasic, surrounding conditions (e.g. sta-bilityandmaturityoftherequirements,standardprojectapproachofacom-pany, desired appointments andguidelines). Thus, as an example, thenewdevelopment of custom software can take place both in a classical and anagileway.
ItisrestrictivelytobesaidthattheuseofTestDrivenDevelopmentortheuseof the“TestFirst”approachofExtremeProgramming isnot recommendedboth incaseof furtherdevelopmentandcustomizingof standardsoftware.Incaseoffurtherdevelopmentofcustomsoftware,theuseofthesemethodsdependsontheexistingcoverageofthesoftwarebyunit-tests,incaseofcus-tomizingitgenerallydependsonthepresenceofaunit-testframework.
sUPPoRT bY Tools 4.3.3 Inordertouseamethodreasonable,atoolsupport isoftenhelpful.Itwasanalyzed,whetherthereisasupportbyspecializedsoftwaresolutionstotherespectivemethods.Withthis,toolsofbasicnaturethatmaybeusedintheagile software development, e.g.MSExcel orBugzilla, are notmeant, buttools specifically designed for the use of a particularmethod (e.g. Scrum-works).SeeTable3.
64
noRMalIzaTIon, sTanDaRDIzaTIon, CeRTIfICaTIon, 4.3.4 lICensInG
Inordertobeabletoassessthefutureviabilityandreliabilityofamethod,theissuesofnormalization/standardization,certificationandlicensinghavebeenconsidered.Indetail,thefollowingquestionshavebeenexamined:
Whoisthecarrier/driverofamethod(singlecompany,consortium, ⬗non-profitorganization,community)?Isthereastandardizationauthority? ⬗Isthereatrainingprogramwithcertification(e.g.,„CertifiedScrum ⬗Master“)?Doesamethodhavetobelicensedbeforeutilization? ⬗
ThepointsarepresentedIntable4.
InDUsTRY foCUs 4.3.5 As part of the research,we have come to the insight that for the applica-tionofagilesoftwaredevelopmentmethodsno industry focuscanbeseen.Inouropinion,anagileapproachsuitsinbranches,inwhichcompaniesactboth innovative and value-oriented and have to adopt onmarket demandsquicklyandflexiblyinordertoremaincompetitiveinthemarket(suchasintheTelecommunicationsindustry).Forbrancheswithafocusonsafety-criticalaspects(e.g.military,air&space),astronglegalprecept(e.g.bankingsector)andpublicinstitutionssuitsamoretraditionalmethod,suchasthewaterfallmodel,orV-modelXT.
However, thereareadditional criteria thathaveabearingon thedecision,whetheritshouldbeproceededtraditionaloragile.Thus,asanexample,inthebankingsectoracustomerportalmaybedevelopedagile,thecoreban-kingsystemincontrastshouldbedevelopedinamoretraditionalwayduetoavailabilityanddatasecurity.
sUPPoRT DURInG InTRoDUCTIon anD Use 4.3.6 Whenanewmethodoranewprocessisintroduced,itisoftendrawnonout-sidehelp.Itisnotdifferentwithinagilesoftwaredevelopment.Forthisreasonithasbeenexamined,whichmethodssupportandconsultingisavailabletoduringintroduction.
Table5shows,whethersupport(e.g.externconsultant,trainings)foramethodisoffered.
65
Method support by Tools
actif Yes
agile enterprise No
aMDD No
asD Yes
bDD Yes
Crystal Yes
DDD No
DsDM Yes
eclipse Way Process No
ePIC No
eVo No
extreme Programming (XP) Yes
fDD Yes
Iconix No
IsD No
lsD No
Mobile-D No
Ms solution framework Yes
RaD Yes
scrum Yes
TDD Yes
UDD No
Unified Process Yes
aUP No
essUP No
oUP Yes
describes,whetherthereisaspecializedtoolsupporttoamethod.Table3:
66
Methodnormali-zation /
standard-ization
Certifi-ation licensing
actif No No No
agile enterprise No No No
aMDD No No No
asD No No No
bDD No No No
Crystal No Yes No
DDD No No No
DsDM Yes Yes Yes
eclipse Way Process No No No
ePIC Yes No Yes
eVo Yes No No
extreme Programming (XP) No No No
fDD No Yes No
Iconix No No No
IsD No No No
lsD Yes Yes No
Mobile-D No No No
Ms solution framework No No No
RaD No No No
scrum Yes Yes No
TDD No Yes No
UDD No No No
Unified Process Yes Yes Yes
aUP Yes Yes No
essUP No No Yes
oUP No Yes No
Overviewofnormalization/standardization,certificationandlicensingTable4:
67
Method support available
actif Yes
agile enterprise No
aMDD No
asD Yes
bDD No
Crystal Yes
DDD No
DsDM Yes
eclipse Way Process Yes
ePIC Yes
eVo Yes
extreme Programming (XP) Yes
fDD Yes
Iconix Yes
IsD No
lsD Yes
Mobile-D No
Ms solution framework Yes
RaD No
scrum Yes
TDD Yes
UDD Yes
Unified Process Yes
aUP Yes
essUP Yes
oUP Yes
shows,whethersupport(e.g.externconsultant,trainings)foramethodisTable5:offered.
68
lInks5 aCTIf
http://www.microtool.de/instep/en/actif.aspaDaPTIVe sofTWaRe DeVeloPMenT (asD)
http://en.wikipedia.org/wiki/Adaptive_Software_Developmenthttp://www.jimhighsmith.com/articles/messy.htmhttp://www.pss-europe.com/P478.pdf
aGIle enTeRPRIse (foRMeRlY X bReeD) http://www.e-architects.com/AE/ aGIle MoDel DRIVen DeVeloPMenT (aMDD)
http://www.agilemodeling.com/essays/amdd.htmhttp://conferences.embarcadero.com/article/images/32437/3202.pdfhttp://bestofcyber.wordpress.com/2007/02/09/amdd-agile-model-driven-development/
behaVIoR DRIVen DeVeloPMenT (bDD) http://en.wikipedia.org/wiki/Behavior_Driven_Developmenthttp://behaviour-driven.org/http://www.code-magazine.com/article.aspx?quickid=0805061
CRYsTal http://alistair.cockburn.us/Crystal+methodologieshttp://alistair.cockburn.us/Crystal+light+methodshttp://www.agilekiwi.com/crystal_clear.htm
DesIGn DRIVen DeVeloPMenT (D3) http://www.designdrivendevelopment.org/http://en.wikipedia.org/wiki/Design-driven_development
DYnaMIC sYsTeM DeVeloPMenT MeThoD (DsDM) http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Methodhttp://www.dsdm.org/http://www.freetutes.com/systemanalysis/sa2-dynamic-system-development-method.html
eClIPse WaY PRoCess http://www.eclipsezone.com/eclipse/forums/t20805.htmlhttp://www.ibm.com/developerworks/rational/library/edge/08/jul08/vanVelzen
eVolUTIonaRY PRoCess foR InTeGRaTInG CoTs-baseD sYsTeMs (ePIC)
http://www.sei.cmu.edu/library/abstracts/reports/02tr009.cfmhttp://en.wikipedia.org/wiki/Evolutionary_Process_for_Integrating_COTS-Based_Systemshttp://www.ibm.com/developerworks/rational/library/aug05/peraire-pannone/index.html
eVolUTIonaRY PRojeCT ManaGeMenT & PRoDUCT DeVeloPMenT (eVo)
http://www.gilb.com/Project-Management eXTReMe PRoGRaMMInG (XP)
http://www.extremeprogramming.org/http://en.wikipedia.org/wiki/Extreme_Programminghttp://xprogramming.com/index.php
feaTURe DRIVen DeVeloPMenT (fDD) http://www.featuredrivendevelopment.com/http://www.nebulon.com/articles/fdd/download/fddprocessesA4.pdf
IConIX http://en.wikipedia.org/wiki/iconixhttp://iconixprocess.com/iconix-process/
69
InTeRneT sPeeD DeVeloPMenT http://www.viswiki.com/en/Internet-Speed_Development
lean sofTWaRe DeVeloPMenT (lsD) http://www.poppendieck.com/http://agilesoftwaredevelopment.com/leanprincipleshttp://www.leanprimer.com/downloads/lean_primer.pdf
MICRosofT solUTIons fRaMeWoRk foR aGIle DeVeloPMenT (Msf4asD)
http://download.microsoft.com/download/8/6/3/86375d9e-1263-4ba0-b5f2-f696aceb94f3/20060418.ppthttp://www.microsoft.com/downloads/details.aspx?FamilyId=9F3EA426-C2B2-4264-BA0F-35A021D85234&displaylang=en
MobIle-D http://virtual.vtt.fi/virtual/agile/mobiled.html
RaPID aPPlICaTIon DeVeloPMenT (RaD) http://www.cs.bgsu.edu/maner/domains/RAD.htmhttp://en.wikipedia.org/wiki/Rapid_application_development
sCRUM http://en.wikipedia.org/wiki/Scrum_(development)http://www.scrumalliance.org/
TesT DRIVen DeVeloPMenT (TDD) http://en.wikipedia.org/wiki/Test-driven_developmenthttp://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci1246164,00.html
UnIfIeD PRoCess (UP) http://en.wikipedia.org/wiki/Unified_Process http://www.ambysoft.com/unifiedprocess/agileUP.htmlhttp://www.ivarjacobson.com/process_improvement_technology/essential_unified_process_software/http://www.eclipse.org/epf/general/OpenUP.pdf
UsabIlITY DRIVen DeVeloPMenT (UDD) http://cakebaker.42dh.com/2007/07/07/usability-driven-development/
70
sUMMaRY6 Agilesoftwaredevelopmentisontheriseallovertheworld.Evidenceofthatisthevarietyofmethodsinagileenvironment.ThehugenumberofmethodstestamentsthatTHEagileMethoddoesnotexist(yet?).
Each of themethods examined has its specific focus, its strengths and itsweaknesses,butitseligibilityaswell.
Eachprojectisuniqueregardingtoitscontentanditsboundaryconditions.Choosing the appropriate method to implementation is usually not easy.Nevertheless,theapplicationofaparticularmethoddoesnotguaranteepro-jectsuccess.
Byselectingtherightteamortherightpartner,youcansetthecoursealreadytosuccessbeforeprojectstart,regardlessoftheappliedmethod.
Attheendoftheday,itcomesdowntotheexperience,skillsandknowledgeofpeople,whorealizetheproject-forprojectsarecarriedoutbyman,notbymethods.
71
aboUT bQI7 TheBestQualityInstitute(BQI),basedinBerlin,istheleadinginstituteforawardswhichmeasureandassessthequalityofcompaniesandemployees.
BQIisthefirstplacetocallfordevelopinghighlyspecializedresearchstudiesandassessmentmodelsforthemostdiverseareasofyourbusiness.BQIisapioneerinstandardizingqualityassessmentofsoftwareandpersonnel.
Independence,comparabilityandtransparencyareBQI’scorecompetenciesandallowBQItoliveuptothehighexpectationsofitsclientsandparticipa-tingcompanies.
73
DIsClaIMeR8 ThecontentsofthisdocumentareprotectedduetocopyrightbyBQI.Citationisallowedwhilsttakingtheusualrulesandguidelinesintoaccount.Copyingorprintingbelatedly, includingexcerptsaswell asphotomechanical repro-ductionorsavingonastoragemediumisonlypermittedbywrittenapprovaloftheBQI.
The corresponding safeguard provision hold true for brands and businessrelationships,thatareusedinthecontentofthispresentation,eveniftheyarenotlabelledassuch.
eXClUsIon of lIabIlITY: TheBQIassumesnoliabilityfortheactuality,correctness,completenessorquality of the information provided at all. Liability claims against theBQI,basedondisadvantagesorharmsofanykindrelatingtoaphysicalorimagi-naryway,whichhavebeencausedbyuseordisuseofthepresentedinforma-tionortheuseofincompleteandfaultyinformation,areprincipallyexcluded,asfarasthereisnoevidenceofdeliberateorrecklessguiltinessonthepartoftheBQI.
ThisresearchhasbeencarriedoutexclusivelyforBQIby
PENTASYS AGRüdesheimerSt.980686Munichwww.pentasys.de
BQIBestQualityInstituteGmbHJägerstraße67-69D-10117BerlinGermanywww.bqi.euMail:[email protected]
Related Documents
