軟件工程課件：04-Software Process

1、Software Process1OutlineSoftware lifecycle and processProcess modelsWaterfallEvolutionaryRUPCMMI2Software LifecycleRequirementsSpecification (Analysis)DesignImplementationIntegrationMaintenanceRetirement3The Process Premise4“The quality of a software system is governed by the quality of the process

2、used to develop and evolve it.”- Watts Humphrey5Software Process SpectrumAd Hoc developmentProcess ModelsHeavy-weight ProcessLight-weight Process6The Waterfall Process ModelW. Royce，1970A systematic, sequential approach to software developmentRequirements analysis and definitionSystem and software d

3、esignImplementation and unit testingIntegration and system testingOperation and maintenanceThe Waterfall Process Model7RequirementDesignCodingTestingMaintenance8The Waterfall Process ModelThe criticismBuilding software is by nature an iterative social learning processChange may cause confusion Hard

4、to state all requirements explicitly at the beginning of the projectA working version of the program will not be available until late in the project time-span.9Evolutionary Process ModelEnable software engineers to develop increasingly, iteratively more complete versions of the softwareIncremental P

5、rototypingSpiralToo often, software work follows the first law of bicycling: No matter where youre going, its uphill and against the wind. 10Evolutionary Process Model Incremental DevelopmentApply the linear sequences in a staggered fashionEach linear sequence produces deliverable “increments” of th

6、e software.11Evolutionary Process Model PrototypingSoftware customers and end-users usually find it very difficult to express their real requirements. Hard to predicate how a system will affect working practicesA prototype is an initial version of a software system demonstrate conceptstry out design

7、 options find out more about the problem and its possible solutions. 12Evolutionary Process Model PrototypingEvolutionary prototypingAn approach to system development where an initial prototype is produced and refined through a number of stages to the final systemThrow-away prototypingA prototype wh

8、ich is usually a practical implementation of the system is produced to help discover requirements problems and then discarded. The system is then developed using some other development process13Evolutionary Process Model SpiralProcess is represented as a spiral rather than as a sequence of activitie

9、s with backtrackingEach loop in the spiral represents a phase in the process. No fixed phases such as specification or design - loops in the spiral are chosen depending on what is requiredRisks are explicitly assessed and resolved throughout the process14Evolutionary Process Model Spiral15Evolutiona

10、ry Process Model SpiralObjective settingSpecific objectives for the phase are identifiedRisk assessment and reductionRisks are assessed and activities put in place to reduce the key risksDevelopment and validationA development model for the system is chosen which can be any of the generic modelsPlan

11、ningThe project is reviewed and the next phase of the spiral is planned16RUP: Rational Unified ProcessUML gives a standard notation for OO methodologies and enables an OOAD process. RUP is the recommended software process when UML is used as the modeling language.RUP evolution Ericsson Approach (Lat

12、e, 1960s)Objectory Process (Ivar Jacobson) (1987-1995)Rational Objectory Process (1996-1997)UML became OMG standard (1997)Rational Unified Process (1998)17RUP WorkflowsCore WorkflowsBusiness modelingRequirements captureAnalysis and DesignImplementation TestDeploymentSupporting WorkflowsConfiguration

13、 and Change ManagementProject ManagementEnvironmentRUP PhasesLife cycle phasesInception: Define the scope of the project and develop business casesElaboration: Plan project, specify features, and baseline the architectureConstruction: Build the projectTransition: Transition the project to its user18

14、InceptionElaborationConstructionTransitiontime1920SEI CMMSEI- Software Engineering InstituteUS DOD funded with Carnegie Mellon University, 1984Mission is to promote software technology transfer particularly to defense contractorsCMM Capability Maturity ModelMaturity model proposed in mid-1980s, refi

15、ned in early 1990s.Work has been very influential in process improvementCMM1986.11: Establish the program1987.6 : The framework is proposed and the questionnaire is developed with 101 questions in Sep. 1991, CMM v1.01997, CMM v2.02002, CMMI: CMM Integration21SEI & Mitre1986Framework &Questionnaire19

16、87CMMV1.01991CMMV1.11993CMMV2.01997CMMI200222CMM 5-levels of Software ProcessLevel1InitialLevel2RepeatableLevel3DefinedLevel4ManagedLevel5OptimizingNo effective management proceduresDepend on individual developersThe process and process are unpredictable Has formal managementNo formal process modelD

17、epend on individual managersHas defined process, basis for qualitative processImprovement. Formal procedures are in place to ensure the defined process is followed. Has defined process and formal programme ofQualitative data collection. Process and product Metrics are collected. The organization is

18、committed to continuous Process improvement. 23CMM StructureProcessCapabilityGoalsImplementation orInstitutionalizationInfrastructure orActivitiesMaturity LevelsKey Process AreasCommon FeaturesKey Practicesindicatecontainorganized bycontainachieveaddressdescribe5 levels，18 KPA，52 Goals，316 Key pract

19、ices24CMM ProblemsThe model focuses exclusively on project management rather than product development. It does not take into account an organizations use of technologies. Excludes risk analysis and resolution as a key process technology. The domain of the applicability of the model is not defined. T

20、he authors of the model clearly recognize that the model is NOT appropriate for all organizations. 25CMMI CMM IntegrationRepresent a process meta-model in two different waysA continuous modelA staged modelFive maturity levelsThe continuous model describe a process in two dimensionsProcess areaCapabi

21、lity levelsEach process area is formally assessed against specific goals and practices and is rated according to the capability levels. 26Capability ModelCMMI CMM Integration0: Incomplete1: Performed2: Managed3: Defined4: QuantitativelyManaged5: OptimizedPPREQMMACMPPQAPP: Project planningREQM: Requi

22、rements managementMA: Measurement and analysisCM: Configuration managementPPQA: Process and project QAProcess Areas27SPICESoftware Process Improvement and Capability dEtermineAn International Standard for Software Process Assessment To develop a working draft for a standard for software process asse

23、ssment. To conduct industry trials of the emerging standard. To promote the technology transfer of software process assessment into the software industry world-wide. 6/1991, ISO survey7/1993, SPICE project launched6/1995, draft published9/1996, ISO 1550428SPICE Framework29The SPICE CurveCUS.1CUS.2CUS.3CUS.4CUS.5ORG.4ORG.513204530SummaryPrescriptive software process models have been applied for many years in an effort to bring