高級(jí)軟件工程上課用ch3

Chapter3–AgileSoftwareDevelopmentLecture11Chapter3AgilesoftwaredevelopmentTopicscoveredAgilemethodsPlan-drivenandagiledevelopmentExtremeprogrammingAgileprojectmanagementScalingagilemethods2Chapter3AgilesoftwaredevelopmentRapidsoftwaredevelopmentRapiddevelopmentanddeliveryisnowoftenthemostimportantrequirementforsoftwaresystemsBusinessesoperateinafast–changingrequirementanditispracticallyimpossibletoproduceasetofstablesoftwarerequirementsSoftwarehastoevolvequicklytoreflectchangingbusinessneeds.RapidsoftwaredevelopmentSpecification,designandimplementationareinter-leavedSystemisdevelopedasaseriesofversionswithstakeholdersinvolvedinversionevaluationUserinterfacesareoftendevelopedusinganIDEandgraphicaltoolset.3Chapter3AgilesoftwaredevelopmentAgilemethodsDissatisfactionwiththeoverheadsinvolvedinsoftwaredesignmethodsofthe1980sand1990sledtothecreationofagilemethods.Thesemethods:FocusonthecoderatherthanthedesignArebasedonaniterativeapproachtosoftwaredevelopmentAreintendedtodeliverworkingsoftwarequicklyandevolvethisquicklytomeetchangingrequirements.Theaimofagilemethodsistoreduceoverheadsinthesoftwareprocess(e.g.bylimitingdocumentation)andtobeabletorespondquicklytochangingrequirementswithoutexcessiverework.4Chapter3AgilesoftwaredevelopmentAgilemanifestoWeareuncoveringbetterwaysofdeveloping?softwarebydoingitandhelpingothersdoit.?Throughthisworkwehavecometovalue:Individualsandinteractionsoverprocessesandtools

Workingsoftwareovercomprehensivedocumentation

Customercollaborationovercontractnegotiation

RespondingtochangeoverfollowingaplanThatis,whilethereisvalueintheitemson?theright,wevaluetheitemsontheleftmore.

Chapter3Agilesoftwaredevelopment5Theprinciplesofagilemethods

PrincipleDescriptionCustomerinvolvementCustomersshouldbecloselyinvolvedthroughoutthedevelopmentprocess.Theirroleisprovideandprioritizenewsystemrequirementsandtoevaluatetheiterationsofthesystem.IncrementaldeliveryThesoftwareisdevelopedinincrementswiththecustomerspecifyingtherequirementstobeincludedineachincrement.PeoplenotprocessTheskillsofthedevelopmentteamshouldberecognizedandexploited.Teammembersshouldbelefttodeveloptheirownwaysofworkingwithoutprescriptiveprocesses.EmbracechangeExpectthesystemrequirementstochangeandsodesignthesystemtomodatethesechanges.MaintainsimplicityFocusonsimplicityinboththesoftwarebeingdevelopedandinthedevelopmentprocess.Whereverpossible,activelyworktoeliminatecomplexityfromthesystem.

6Chapter3AgilesoftwaredevelopmentAgilemethodapplicabilityProductdevelopmentwhereasoftwarecompanyisdevelopingasmallormedium-sizedproductforsale.Customsystemdevelopmentwithinanorganization,wherethereisaclearcommitmentfromthecustomertoeinvolvedinthedevelopmentprocessandwheretherearenotalotofexternalrulesandregulationsthataffectthesoftware.Becauseoftheirfocusonsmall,tightly-integratedteams,thereareproblemsinscalingagilemethodstolargesystems.Chapter3Agilesoftwaredevelopment7ProblemswithagilemethodsItcanbedifficulttokeeptheinterestofcustomerswhoareinvolvedintheprocess.Teammembersmaybeunsuitedtotheintenseinvolvementthatcharacterisesagilemethods.Prioritisingchangescanbedifficultwheretherearemultiplestakeholders.Maintainingsimplicityrequiresextrawork.Contractsmaybeaproblemaswithotherapproachestoiterativedevelopment.8Chapter3AgilesoftwaredevelopmentAgilemethodsandsoftwaremaintenanceMostorganizationsspendmoreonmaintainingexistingsoftwarethantheydoonnewsoftwaredevelopment.So,ifagilemethodsaretobesuccessful,theyhavetosupportmaintenanceaswellasoriginaldevelopment.Twokeyissues:Aresystemsthataredevelopedusinganagileapproachmaintainable,giventheemphasisinthedevelopmentprocessofminimizingformaldocumentation?Canagilemethodsbeusedeffectivelyforevolvingasysteminresponsetocustomerchangerequests?Problemsmayariseiforiginaldevelopmentteamcannotbemaintained.Chapter3Agilesoftwaredevelopment9Plan-drivenandagiledevelopmentPlan-drivendevelopmentAplan-drivenapproachtosoftwareengineeringisbasedaroundseparatedevelopmentstageswiththeoutputstobeproducedateachofthesestagesplannedinadvance.Notnecessarilywaterfallmodel–plan-driven,incrementaldevelopmentispossibleIterationoccurswithinactivities.AgiledevelopmentSpecification,design,implementationandtestingareinter-leavedandtheoutputsfromthedevelopmentprocessaredecidedthroughaprocessofnegotiationduringthesoftwaredevelopmentprocess.10Chapter3AgilesoftwaredevelopmentPlan-drivenandagilespecification

11Chapter3AgilesoftwaredevelopmentTechnical,human,organizationalissuesMostprojectsincludeelementsofplan-drivenandagileprocesses.Decidingonthebalancedependson:Isitimportanttohaveaverydetailedspecificationanddesignbeforemovingtoimplementation?Ifso,youprobablyneedtouseaplan-drivenapproach.Isanincrementaldeliverystrategy,whereyoudeliverthesoftwaretocustomersandgetrapidfeedbackfromthem,realistic?Ifso,considerusingagilemethods.Howlargeisthesystemthatisbeingdeveloped?Agilemethodsaremosteffectivewhenthesystemcanbedevelopedwithasmallco-locatedteamwhocancommunicateinformally.Thismaynotbepossibleforlargesystemsthatrequirelargerdevelopmentteamssoaplan-drivenapproachmayhavetobeused.12Chapter3AgilesoftwaredevelopmentTechnical,human,organizationalissuesWhattypeofsystemisbeingdeveloped?Plan-drivenapproachesmayberequiredforsystemsthatrequirealotofanalysisbeforeimplementation(e.g.real-timesystemwithcomplextimingrequirements).Whatistheexpectedsystemlifetime?Long-lifetimesystemsmayrequiremoredesigndocumentationtocommunicatetheoriginalintentionsofthesystemdeveloperstothesupportteam.Whattechnologiesareavailabletosupportsystemdevelopment?AgilemethodsrelyongoodtoolstokeeptrackofanevolvingdesignHowisthedevelopmentteamorganized?Ifthedevelopmentteamisdistributedorifpartofthedevelopmentisbeingoutsourced,thenyoumayneedtodevelopdesigndocumentstocommunicateacrossthedevelopmentteams.

13Chapter3AgilesoftwaredevelopmentTechnical,human,organizationalissuesArethereculturalororganizationalissuesthatmayaffectthesystemdevelopment?Traditionalengineeringorganizationshaveacultureofplan-baseddevelopment,asthisisthenorminengineering.Howgoodarethedesignersandprogrammersinthedevelopmentteam?Itissometimesarguedthatagilemethodsrequirehigherskilllevelsthanplan-basedapproachesinwhichprogrammerssimplytranslateadetaileddesignintocodeIsthesystemsubjecttoexternalregulation?Ifasystemhastobeapprovedbyanexternalregulator(e.g.theFAAapprovesoftwarethatiscriticaltotheoperationofanaircraft)thenyouwillprobablyberequiredtoproducedetaileddocumentationaspartofthesystemsafetycase.Chapter3Agilesoftwaredevelopment14ExtremeprogrammingPerhapsthebest-knownandmostwidelyusedagilemethod.ExtremeProgramming(XP)takesan‘extreme’approachtoiterativedevelopment.Newversionsmaybebuiltseveraltimesperday;Incrementsaredeliveredtocustomersevery2weeks;Alltestsmustberunforeverybuildandthebuildisonlyacceptediftestsrunsuccessfully.15Chapter3AgilesoftwaredevelopmentXPandagileprinciplesIncrementaldevelopmentissupportedthroughsmall,frequentsystemreleases.Customerinvolvementmeansfull-timecustomerengagementwiththeteam.Peoplenotprocessthroughpairprogramming,collectiveownershipandaprocessthatavoidslongworkinghours.Changesupportedthroughregularsystemreleases.Maintainingsimplicitythroughconstantrefactoringofcode.16Chapter3AgilesoftwaredevelopmentTheextremeprogrammingreleasecycle

17Chapter3AgilesoftwaredevelopmentExtremeprogrammingpractices(a)

PrincipleorpracticeDescriptionIncrementalplanningRequirementsarerecordedonstorycardsandthestoriestobeincludedinareleasearedeterminedbythetimeavailableandtheirrelativepriority.Thedevelopersbreakthesestoriesintodevelopment‘Tasks’.SeeFigures3.5and3.6.SmallreleasesTheminimalusefulsetoffunctionalitythatprovidesbusinessvalueisdevelopedfirst.Releasesofthesystemarefrequentandincrementallyaddfunctionalitytothefirstrelease.SimpledesignEnoughdesigniscarriedouttomeetthecurrentrequirementsandnomore.Test-firstdevelopmentAnautomatedunittestframeworkisusedtowritetestsforanewpieceoffunctionalitybeforethatfunctionalityitselfisimplemented.RefactoringAlldevelopersareexpectedtorefactorthecodecontinuouslyassoonaspossiblecodeimprovementsarefound.Thiskeepsthecodesimpleandmaintainable.18Chapter3AgilesoftwaredevelopmentExtremeprogrammingpractices(b)PairprogrammingDevelopersworkinpairs,checkingeachother’sworkandprovidingthesupporttoalwaysdoagoodjob.CollectiveownershipThepairsofdevelopersworkonallareasofthesystem,sothatnoislandsofexpertisedevelopandallthedeveloperstakeresponsibilityforallofthecode.Anyonecanchangeanything.ContinuousintegrationAssoonastheworkonataskiscomplete,itisintegratedintothewholesystem.Afteranysuchintegration,alltheunittestsinthesystemmustpass.SustainablepaceLargeamountsofovertimearenotconsideredacceptableastheneteffectisoftentoreducecodequalityandmediumtermproductivityOn-sitecustomerArepresentativeoftheend-userofthesystem(thecustomer)shouldbeavailablefulltimefortheuseoftheXPteam.Inanextremeprogrammingprocess,thecustomerisamemberofthedevelopmentteamandisresponsibleforbringingsystemrequirementstotheteamforimplementation.19Chapter3AgilesoftwaredevelopmentRequirementsscenariosInXP,acustomeroruserispartoftheXPteamandisresponsibleformakingdecisionsonrequirements.Userrequirementsareexpressedasscenariosoruserstories.Thesearewrittenoncardsandthedevelopmentteambreakthemdownintoimplementationtasks.Thesetasksarethebasisofscheduleandcostestimates.Thecustomerchoosesthestoriesforinclusioninthenextreleasebasedontheirprioritiesandthescheduleestimates.20Chapter3AgilesoftwaredevelopmentA‘prescribingmedication’story

21Chapter3AgilesoftwaredevelopmentExamplesoftaskcardsforprescribingmedication22Chapter3AgilesoftwaredevelopmentXPandchangeConventionalwisdominsoftwareengineeringistodesignforchange.Itisworthspendingtimeandeffortanticipatingchangesasthisreducescostslaterinthelifecycle.XP,however,maintainsthatthisisnotworthwhileaschangescannotbereliablyanticipated.Rather,itproposesconstantcodeimprovement(refactoring)tomakechangeseasierwhentheyhavetobeimplemented.23Chapter3AgilesoftwaredevelopmentRefactoringProgrammingteamlookforpossiblesoftwareimprovementsandmaketheseimprovementsevenwherethereisnoimmediateneedforthem.Thisimprovestheunderstandabilityofthesoftwareandsoreducestheneedfordocumentation.Changesareeasiertomakebecausethecodeiswell-structuredandclear.However,somechangesrequiresarchitecturerefactoringandthisismuchmoreexpensive.Chapter3Agilesoftwaredevelopment24ExamplesofrefactoringRe-organizationofaclasshierarchytoremoveduplicatecode.Tidyingupandrenamingattributesandmethodstomakethemeasiertounderstand.Thereplacementofinlinecodewithcallstomethodsthathavebeenincludedinaprogramlibrary.Chapter3Agilesoftwaredevelopment25KeypointsAgilemethodsareincrementaldevelopmentmethodsthatfocusonrapiddevelopment,frequentreleasesofthesoftware,reducingprocessoverheadsandproducinghigh-qualitycode.Theyinvolvethecustomerdirectlyinthedevelopmentprocess.Thedecisiononwhethertouseanagileoraplan-drivenapproachtodevelopmentshoulddependonthetypeofsoftwarebeingdeveloped,thecapabilitiesofthedevelopmentteamandthecultureofthecompanydevelopingthesystem.Extremeprogrammingisawell-knownagilemethodthatintegratesarangeofgoodprogrammingpracticessuchasfrequentreleasesofthesoftware,continuoussoftwareimprovementandcustomerparticipationinthedevelopmentteam.Chapter3Agilesoftwaredevelopment26Chapter3–AgileSoftwareDevelopmentLecture227Chapter3AgilesoftwaredevelopmentTestinginXPTestingiscentraltoXPandXPhasdevelopedanapproachwheretheprogramistestedaftereverychangehasbeenmade.XPtestingfeatures:Test-firstdevelopment.Incrementaltestdevelopmentfromscenarios.Userinvolvementintestdevelopmentandvalidation.Automatedtestharnessesareusedtorunallcomponenttestseachtimethatanewreleaseisbuilt.28Chapter3AgilesoftwaredevelopmentTest-firstdevelopmentWritingtestsbeforecodeclarifiestherequirementstobeimplemented.Testsarewrittenasprogramsratherthandatasothattheycanbeexecutedautomatically.Thetestincludesacheckthatithasexecutedcorrectly.UsuallyreliesonatestingframeworksuchasJunit.Allpreviousandnewtestsarerunautomaticallywhennewfunctionalityisadded,thuscheckingthatthenewfunctionalityhasnotintroducederrors.29Chapter3AgilesoftwaredevelopmentCustomerinvolvementTheroleofthecustomerinthetestingprocessistohelpdevelopacceptancetestsforthestoriesthataretobeimplementedinthenextreleaseofthesystem.Thecustomerwhoispartoftheteamwritestestsasdevelopmentproceeds.Allnewcodeisthereforevalidatedtoensurethatitiswhatthecustomerneeds.However,peopleadoptingthecustomerrolehavelimitedtimeavailableandsocannotworkfull-timewiththedevelopmentteam.Theymayfeelthatprovidingtherequirementswasenoughofacontributionandsomaybereluctanttogetinvolvedinthetestingprocess.Chapter3Agilesoftwaredevelopment30Testcasedescriptionfordosechecking

31Chapter3AgilesoftwaredevelopmentTestautomationTestautomationmeansthattestsarewrittenasexecutablecomponentsbeforethetaskisimplementedThesetestingcomponentsshouldbestand-alone,shouldsimulatethesubmissionofinputtobetestedandshouldcheckthattheresultmeetstheoutputspecification.Anautomatedtestframework(e.g.Junit)isasystemthatmakesiteasytowriteexecutabletestsandsubmitasetoftestsforexecution.Astestingisautomated,thereisalwaysasetofteststhatcanbequicklyandeasilyexecutedWheneveranyfunctionalityisaddedtothesystem,thetestscanberunandproblemsthatthenewcodehasintroducedcanbecaughtimmediately.Chapter3Agilesoftwaredevelopment32XPtestingdifficultiesProgrammerspreferprogrammingtotestingandsometimestheytakeshortcutswhenwritingtests.Forexample,theymaywritepleteteststhatdonotcheckforallpossibleexceptionsthatmayoccur.Sometestscanbeverydifficulttowriteincrementally.Forexample,inacomplexuserinterface,itisoftendifficulttowriteunittestsforthecodethatimplementsthe‘displaylogic’andworkflowbetweenscreens.Itdifficulttojudgethecompletenessofasetoftests.Althoughyoumayhavealotofsystemtests,yourtestsetmaynotprovidecompletecoverage.Chapter3Agilesoftwaredevelopment33PairprogrammingInXP,programmersworkinpairs,sittingtogethertodevelopcode.Thishelpsdevelopcommonownershipofcodeandspreadsknowledgeacrosstheteam.Itservesasaninformalreviewprocessaseachlineofcodeislookedatbymorethan1person.Itencouragesrefactoringasthewholeteamcanbenefitfromthis.Measurementssuggestthatdevelopmentproductivitywithpairprogrammingissimilartothatoftwopeopleworkingindependently.34Chapter3AgilesoftwaredevelopmentPairprogrammingInpairprogramming,programmerssittogetheratthesameworkstationtodevelopthesoftware.Pairsarecreateddynamicallysothatallteammembersworkwitheachotherduringthedevelopmentprocess.Thesharingofknowledgethathappensduringpairprogrammingisveryimportantasitreducestheoverallriskstoaprojectwhenteammembersleave.Pairprogrammingisnotnecessarilyinefficientandthereisevidencethatapairworkingtogetherismoreefficientthan2programmersworkingseparately.35Chapter3AgilesoftwaredevelopmentAdvantagesofpairprogrammingItsupportstheideaofcollectiveownershipandresponsibilityforthesystem.Individualsarenotheldresponsibleforproblemswiththecode.Instead,theteamhascollectiveresponsibilityforresolvingtheseproblems.Itactsasaninformalreviewprocessbecauseeachlineofcodeislookedatbyatleasttwopeople.Ithelpssupportrefactoring,whichisaprocessofsoftwareimprovement.Wherepairprogrammingandcollectiveownershipareused,othersbenefitimmediatelyfromtherefactoringsotheyarelikelytosupporttheprocess.Chapter3Agilesoftwaredevelopment36AgileprojectmanagementTheprincipalresponsibilityofsoftwareprojectmanagersistomanagetheprojectsothatthesoftwareisdeliveredontimeandwithintheplannedbudgetfortheproject.Thestandardapproachtoprojectmanagementisplan-driven.Managersdrawupaplanfortheprojectshowingwhatshouldbedelivered,whenitshouldbedeliveredandwhowillworkonthedevelopmentoftheprojectdeliverables.Agileprojectmanagementrequiresadifferentapproach,whichisadaptedtoincrementaldevelopmentandtheparticularstrengthsofagilemethods.37Chapter3AgilesoftwaredevelopmentScrumTheScrumapproachisageneralagilemethodbutitsfocusisonmanagingiterativedevelopmentratherthanspecificagilepractices.TherearethreephasesinScrum.Theinitialphaseisanoutlineplanningphasewhereyouestablishthegeneralobjectivesfortheprojectanddesignthesoftwarearchitecture.Thisisfollowedbyaseriesofsprintcycles,whereeachcycledevelopsanincrementofthesystem.Theprojectclosurephasewrapsuptheproject,completesrequireddocumentationsuchassystemhelpframesandusermanualsandassessesthelessonslearnedfromtheproject.

Chapter3Agilesoftwaredevelopment38TheScrumprocess

39Chapter3AgilesoftwaredevelopmentTheSprintcycleSprintsarefixedlength,normally2–4weeks.TheycorrespondtothedevelopmentofareleaseofthesysteminXP.Thestartingpointforplanningistheproductbacklog,whichisthelistofworktobedoneontheproject.Theselectionphaseinvolvesalloftheprojectteamwhoworkwiththecustomertoselectthefeaturesandfunctionalitytobedevelopedduringthesprint.40Chapter3AgilesoftwaredevelopmentTheSprintcycleOncetheseareagreed,theteamorganizethemselvestodevelopthesoftware.Duringthisstagetheteamisisolatedfromthecustomerandtheorganization,withallcommunicationschannelledthroughtheso-called‘Scrummaster’.TheroleoftheScrummasteristoprotectthedevelopmentteamfromexternaldistractions.Attheendofthesprint,theworkdoneisreviewedandpresentedtostakeholders.Thenextsprintcyclethenbegins.41Chapter3AgilesoftwaredevelopmentTeamworkinScrumThe‘Scrummaster’isafacilitatorwhoarrangesdailymeetings,tracksthebacklogofworktobedone,recordsdecisions,measuresprogressagainstthebacklogandcommunicateswithcustomersandmanagementoutsideoftheteam.Thewholeteamattendsshortdailymeetingswhereallteammembersshareinformation,describetheirprogresssincethelastmeeting,problemsthathavearisenandwhatisplannedforthefollowingday.Thismeansthateveryoneontheteamknowswhatisgoingonand,ifproblemsarise,canre-planshort-termworktocopewiththem.Chapter3Agilesoftwaredevelopment42ScrumbenefitsTheproductisbrokendownintoasetofmanageableandunderstandablechunks.Unstablerequirementsdonotholdupprogress.Thewholeteamhavevisibilityofeverythingandconsequentlyteamcommunicationisimproved.Customersseeon-timedeliveryofincrementsandgainfeedbackonhowtheproductworks.Trustbetweencustomersanddevelopersisestablishedandapositivecultureiscreatedinwhicheveryoneexpectstheprojecttosucceed.Chapter3Agilesoftwaredevelopment43ScalingagilemethodsAgilemethodshaveprovedtobesuccessfulforsmallandmediumsizedprojectsthatcanbedevelopedbyasmallco-locatedteam.Itissometimesarguedthatthesuccessofthesemethodscomesbecauseofimprovedcommunicationswhichispossiblewheneveryoneisworkingtogether.Scalingupagilemethodsinvolveschangingthesetocopewithlarger,longerprojectswheretherearemultipledevelopmentteams,perhapsworkingindifferentlocations.44Chapter3AgilesoftwaredevelopmentLargesystemsdevelopmentLargesystemsareusuallycollectionsofseparate,communicatingsystems,whereseparateteamsdevelopeachsystem.Frequently,theseteamsareworkingindifferentplaces,sometimesindifferenttimezones.Largesystemsare‘brownfieldsystems’,thatistheyincludeandinteractwithanumberofexistingsystems.Manyofthesystemrequirementsareconcernedwiththisinteractionandsodon’treallylendthemselvestoflexibilityandincrementaldevelopment.Whereseveralsystemsareintegratedtocreateasystem,asignificantfractionofthedevelopmentisconcernedwithsystemconfigurationratherthanoriginalcodedevelopment.45Chapter3AgilesoftwaredevelopmentLargesystemdevelopmentLargesystemsandtheirdevelopmentprocessesareoftenconstrainedbyexternalrulesandregulationslimitingthewaythattheycanbedeveloped.Largesystemshavealongprocurementanddevelopmenttime.Itisdifficulttomaintaincoherentteamswhoknowaboutthesystemoverthatperiodas,inevitably,peoplemoveontootherjobsandprojects.Largesystemsusuallyhaveadiversesetofstakeholders.Itispracticallyimpossibletoinvolveallofthesedifferentstakeholdersinthedevelopmentpro