Unit5SoftwareProcessSectionASoftwareProcessModelsI.IntroductionAsoftwareprocessisasetofactivitiesthatleadstotheproductionofasoftwareproduct.Theseactivitiesmayinvolvethedevelopmentofsoftwarefromscratch(從零開始、白手起家)inastandardprogramminglanguagelikeJavaorC.Increasingly,however,newsoftwareisdevelopedbyextendingandmodifyingexistingsystemsandbyconfiguringandintegratingoff-the-shelfsoftwareorsystemcomponents.Asoftwareprocessmodelisanabstractrepresentationofasoftwareprocess.Eachprocessmodelrepresentsaprocessfromaparticularperspective,andthusprovidesonlypartialinformationaboutthatprocess.Thissectionintroducesanumberofverygeneralprocessmodels(sometimescalledprocessparadigms)andpresentsthemfroman

architecturalperspective.Thatis,weseetheframeworkoftheprocessbutnotthedetailsofspecificactivities.Thesegenericmodelsarenotdefinitivedescriptionsofsoftwareprocesses.Rather,theyareabstractionsoftheprocessthatcanbeusedtoexplaindifferentapproachestosoftwaredevelopment.Youcanthinkofthemasprocessframeworksthatmaybeextendedandadaptedtocreatemorespecificsoftwareengineeringprocesses.Theprocessmodelscoveredherearethewaterfallmodel,evolutionarydevelopmentandcomponent-basedsoftwareengineering.Thesethreegenericprocessmodelsarewidelyusedincurrentsoftwareengineeringpractice.Theyarenotmutuallyexclusiveandareoftenusedtogether,especiallyforlargesystemsdevelopment.Sub-systemswithinalargersystemmaybedevelopedusingdifferentapproaches.Therefore,althoughitisconvenienttodiscussthesemodelsseparately,

youshouldunderstandthat,inpractice,theyareoftencombined.II.TheWaterfallModelThefirstpublishedmodelofthesoftwaredevelopmentprocesswasderivedfrom（起源于）moregeneralsystemengineeringprocesses.ThisisillustratedinFigure5A-1.Becauseofthecascadefromonephasetoanother,thismodelisknownasthewaterfallmodelorsoftwarelifecycle.Theprincipalstagesofthemodelmapontofundamentaldevelopmentactivities:1.Requirementsanalysisanddefinition.Thesystem'sservices,constraintsandgoalsareestablishedbyconsultationwithsystemusers.Theyarethendefinedindetailandserveasasystemspecification.2.Systemandsoftwaredesign.Thesystemsdesignprocesspartitionstherequirementstoeitherhardwareorsoftwaresystems.Itestablishesanoverallsystemarchitecture.Softwaredesigninvolvesidentifyingand

describingthefundamentalsoftwaresystemabstractionsandtheirrelationships.3.Implementationandunittesting.Duringthisstage,thesoftwaredesignisrealizedasasetofprogramsorprogramunits.Unittestinginvolvesverifyingthateachunitmeetsitsspecification.|4.Integrationandsystemtesting.Theindividualprogramunitsorprogramsareintegratedandtestedasacompletesystemtoensurethatthesoftwarerequirementshavebeenmet.Aftertesting,thesoftwaresystemisdeliveredtothecustomer.5.Operationandmaintenance.Normally(althoughnotnecessarily)thisisthelongestlife-cyclephase.Thesystemisinstalledandputintopracticaluse.Maintenanceinvolvescorrectingerrorswhichwerenotdiscoveredinearlierstagesofthelifecycle,improvingtheimplementationofsystemunitsandenhancingthesystem’sservicesasnewrequirementsarediscovered.

Inprinciple,theresultofeachphaseisoneormoredocumentsthatareapproved.Thefollowingphaseshouldnotstartuntilthepreviousphasehasfinished.Inpractice,thesestagesoverlapandfeedinformationtoeachother.Duringdesign,problemswithrequirementsareidentified;duringcodingdesignproblemsarefoundandsoon.Thesoftwareprocessisnotasimplelinearmodelbutinvolvesasequenceofiterationsofthedevelopmentactivities.Becauseofthecostsofproducingandapprovingdocuments,iterationsarecostlyandinvolvesignificantrework.Therefore,afterasmallnumberofiterations,itisnormaltofreezepartsofthedevelopment,suchasthespecification,andtocontinuewiththelaterdevelopmentstages.Problemsareleftforlaterresolution,ignoredorprogrammedaround.Thisprematurefreezingofrequirementsmaymeanthatthesystemwon'tdowhattheuserwants.Itmayalsoleadtobadlystructured

systemsasdesignproblemsarecircumventedbyimplementationtricks.Duringthefinallife-cyclephase(operationandmaintenance),thesoftwareisputintouse.Errorsandomissionsintheoriginalsoftwarerequirementsarediscovered.Programanddesignerrorsemergeandtheneedfornewfunctionalityisidentified.Thesystemmustthereforeevolvetoremainuseful.Makingthesechanges(softwaremaintenance)mayinvolverepeatingpreviousprocessstages.Theadvantagesofthewaterfallmodelarethatdocumentationisproducedateachphaseandthatitfitswithotherengineeringprocessmodels.Itsmajorproblemisitsinflexiblepartitioningoftheprojectintodistinctstages.Commitmentsmustbemadeatanearlystageintheprocess,whichmakesitdifficulttorespondtochangingcustomerrequirements.Therefore,thewaterfallmodelshouldonlybeusedwhentherequirementsarewellunderstoodandunlikelytochangeradically

duringsystemdevelopment.However,thewaterfallmodelreflectsthetypeofprocessmodelusedinotherengineeringprojects.Consequently,softwareprocessesbasedonthisapproacharestillusedforsoftwaredevelopment,particularlywhenthesoftwareprojectispartofalargersystemsengineeringproject.III.EvolutionaryDevelopmentEvolutionarydevelopmentisbasedontheideaofdevelopinganinitialimplementation,exposingthistousercommentandrefiningitthroughmanyversionsuntilanadequatesystemhasbeendeveloped(Figure5A-2).Specification,developmentandvalidationactivitiesareinterleavedratherthanseparate,withrapidfeedbackacrossactivities.Therearetwofundamentaltypesofevolutionarydevelopment:1.Exploratorydevelopmentwheretheobjectiveoftheprocessistoworkwiththecustomerstoexploretheirrequirementsand

deliverafinalsystem.Thedevelopmentstartswiththepartsofthesystemthatareunderstood.Thesystemevolvesbyaddingnewfeaturesproposedbythecustomer.2.Throwawayprototypingwheretheobjectiveoftheevolutionarydevelopmentprocessistounderstandthecustomer'srequirementsandhencedevelopabetterrequirementsdefinitionforthesystem.Theprototypeconcentratesonexperimentingwiththecustomerrequirementsthatarepoorlyunderstood.Anevolutionaryapproachtosoftwaredevelopmentisoftenmoreeffectivethanthewaterfallapproachinproducingsystemsthatmeettheimmediateneedsofcustomers.Theadvantageofasoftwareprocessthatisbasedonanevolutionaryapproachisthatthespecificationcanbedevelopedincrementally.Asusersdevelopabetterunderstandingoftheirproblem,thiscanbereflectedinthesoftwaresystem.However,fromanengineeringandmanagementperspective,the

evolutionaryapproachhastwoproblems:1.Theprocessisnotvisible.Managersneedregulardeliverablestomeasureprogress.Ifsystemsaredevelopedquickly,itisnotcost-effectivetoproducedocumentsthatreflecteveryversionofthesystem.2.Systemsareoftenpoorlystructured.Continualchangetendstocorruptthesoftwarestructure.Incorporatingsoftwarechangesbecomesincreasinglydifficultandcostly.Forsmallandmedium-sizedsystems(upto500,000linesofcode),theevolutionaryapproachmaybethebestapproachtodevelopment.Theproblemsofevolutionarydevelopmentbecomeparticularlyacuteforlarge,complex,long-life-timesystems,wheredifferentteamsdevelopdifferentpartsofthesystem.Itisdifficulttoestablishastablesystemarchitectureusingthisapproach,whichmakesithardtointegratecontributionsfromtheteams.

Forlargesystems,amixedprocessisrecommendedwhichincorporatesthebestfeaturesofthewaterfallandtheevolutionarydevelopmentmodels.Thismayinvolvedevelopingathrowawayprototypeusinganevolutionaryapproachtoresolveuncertaintiesinthesystemspecification.Youcanthenreimplementthesystemusingamorestructuredapproach.Partsofthesystemthatarewellunderstoodcanbespecifiedanddevelopedusingawaterfall-basedprocess.Otherpartsofthesystem,suchastheuserinterface,whicharedifficulttospecifyinadvance,shouldalwaysbedevelopedusinganexploratoryprogrammingapproach.IV.Component-BasedSoftwareEngineeringInthemajorityofsoftwareprojects,thereissomesoftwarereuse.Thisusuallyhappensinformallywhenpeopleworkingontheprojectknowofdesignsorcodewhichissimilartothatrequired.Theylookforthese,

modifythemasneededandincorporatethemintotheirsystem.Intheevolutionaryapproach,reuseisoftenessentialforrapidsystemdevelopment.Thisinformalreusetakesplaceirrespectiveofthedevelopmentprocessthatisused.However,inthelastfewyears,anapproachtosoftwaredevelopmentcalledcomponent-basedsoftwareengineering(CBSE),whichreliesonreuse,hasemergedandisbecomingincreasinglyused.Thisreuse-orientedapproachreliesonalargebaseofreusablesoftwarecomponentsandsomeintegratingframeworkforthesecomponents.Sometimes,thesecomponentsaresystemsintheirownright(COTSorcommercialoff-the-shelfsystems)thatmayprovidespecificfunctionalitysuchastextformattingornumericcalculation.ThegenericprocessmodelforCBSEisshowninFigure5A-3.Whiletheinitialrequirementsspecification

stageandthevalidationstagearecomparablewithotherprocesses,theintermediatestagesinareuse-orientedprocessaredifferent.Thesestagesare:1.Componentanalysis.Giventherequirementsspecification,asearchismadeforcomponentstoimplementthatspecification.Usually,thereisnoexactmatch,andthecomponentsthatmaybeusedonlyprovidesomeofthefunctionalityrequired.2.Requirementsmodification.Duringthisstage,therequirementsareanalyzedusinginformationaboutthecomponentsthathavebeendiscovered.Theyarethenmodifiedtoreflecttheavailablecomponents.Wheremodificationsareimpossi