1. Learning Objectives You should be able to: zDescribe the evolution of software process models zExplain the features of each model, I.e., how each improves on the previous model zDiscuss the motivation for the CMM, e.g., its relationship to software engineering and quality improvement zCompare immature and mature software organizations zList and describe the 5 CMM maturity levels zDiscuss benefits and difficulties in implementing the CMM

2. ISM 5316 Software Process Models and the CMM

3. Software Process Models zPurpose of software process models: ydetermine order of stages xWhat shall we do next? yestablish transition criteria from one stage to the next xHow long shall we continue to do it? zModel vs. method zProcess vs. product

4. Problems with Software Development Processes zLate, over-budget, chaotic, undisciplined zPoor quality software products zBest results due to individual heroic efforts, not mature process zNo consistent long-term productivity zDifficult to repeat best results zLarger, more complex projects need a shift from technical to management focus z$$ spent on software increases 12+% per year zIncreasing demand for added functionality

5. Code-and-Fix Model zSteps yWrite some code yFix problems in the code yThink about requirements, design, testing, and maintenance later yCode-driven z Problems yIncreasingly poorly structured code yIncreasingly expensive to change and fix yPoor match to users’ needs, thus increasing the need for changing and fixing

6. Stagewise/Waterfall Models Feasibility Design Implementation Evaluation/ maintenance Construction Analysis Functional Specifications Detailed Design Specs

7. Difficulties with Waterfall zDocument-driven yFormal specs may be too much, inaccurate zDoesn’t accommodate: yParallel or incremental development yChanging requirements yInteractive software y4GL tools

8. Evolutionary and Transform Models zPrototyping yIterative development yExpanding operational software incrementally yToo much like Code&Fix yLack of planning yLack of structure zTransform Model ymore structured “I can’t tell you what I want, but I’ll know it when I see it” Client

9. Spiral Model (Iterative) zRisk-driven (versus document-driven or code-driven) zEvolutionary and flexible zIterative enhancement zPrototyping = risk reduction zSpecifications not uniform, exhaustive, or formal = less time zFocuses early attention on reuse zIncorporates software quality objectives

10. Steps in Each Cycle of Spiral Model zObjectives zConstraints zAlternatives zRisk identification zRisk resolution and results zPlan for next phase z(Re)commitment

11. Object-Oriented Process Model zEstablish core requirements: Conceptualization yProof of concept (risk) zDevelop a model of desired behavior: Analysis ydevelop common vocabulary zCreate an architecture: Design ypolicies for implementation zEvolve the implementation: Evolution yrefine architecture zManage postdelivery evolution: Maintenance ycontinued evolution based on new requirements

12. Conceptualization Design Analysis Evolution Maintenance Object-Oriented Process

13. Current Life-cycle Phases zEngineering yInception (idea) yElaboration (architecture) zProduction yConstruction (iterations - beta releases) yTransition (products)

14. Capability Maturity Model (CMM) zHelps organizations improve software processes zBased on results of assessments of contractors, industry and gov’t feedback zSoftware process assessment yassess current capabilities yhighlight high-priority areas for improvement ygain organizational support for improvement zBased on Juran’s Trilogy of quality improvement yquality planning, control, improvement z5 maturity levels

15. Software Organization Maturity Immature zprocesses improvised zreactionary zunrealistic estimates zquality compromised to meet schedule zno objective basis for evaluation zinadequate review, testing, etc. Mature z standard, documented processes z known, used, and learned z organization-wide ability to manage processes z continuous process improvement z clear roles and responsibilities z managers monitor product quality and customer satisfaction z realistic schedules and budgets based on historical data

16. CMM Definitions zSoftware process yActivities, methods, practices, and transformations used by people to develop and maintain software products zCapability yRange of expected results achieved by a software process zPerformance yActual results achieved by a software process zMaturity yExtent to which a software process is explicitly defined, managed, controlled, effective, and consistent

17. CMM Level 1: Initial zUnstable, chaotic software processes zPoor planning undermines good software engineering practices zProcess capability is unpredictable zPerformance depends on individual capabilities, not repeatable zProcedures are abandoned in crises zLack understanding of importance of planning, design, reviews, testing

18. CMM Level 2: Repeatable zManagement vs. technical focus zPM policies and procedures are established, PM standards are defined and enforced zPlanning is based on previous experiences ytime, cost estimation zEffective processes are: ypracticed, documented, enforced, trained, measured zObjective: Basic management controls

19. CMM Level 3: Defined zSoftware processes, both project management and software engineering, are standardized and documented zOrganization-wide process definition and training zProjects can tailor processes to their unique needs yprocesses empower but don’t constrain zWell-defined, consistent processes, have: yreadiness criteria, inputs, outputs yperformance standards, completion criteria, verification zSoftware Engineering process group established zCommon organizational understanding of process yactivities, roles, responsibilities

20. CMM Level 4: Managed zQuantitative measures of quality yproducts and processes zOrganization-wide process database for analysis and as basis for measurement zNarrow variation in process performance zRisk assessment and management zPredictable capability

21. CMM Level 5: Optimizing zOrganization-wide focus on continuous improvement yincremental improvement yimprovement by adoption & transfer of innovations zGoal is defect prevention yanalyze defects to determine causes zLessons learned transferred to future projects zEmulates statistical process control in manufacturing systems

22. Strengths and Limitations zDescriptive, normative model of behavior zDoesn’t constrain unique organizational process needs zNeeds to be interpreted, implemented to fit the context yorganization’s strategic objectives, culture, structure, systems zAssumes other organizational change processes in place zTakes 1+ years to move from one level to the next zLevels should not be skipped yeach provides the foundation for the next one

23. Difficulties in Improving Software Processes zLack of consensus between managers and developers about how to improve zFocus on management vs. engineering ymanagement process harder to define zRequires time - no quick fix zMust be done one level at a time zRequires culture change zRequires organization-wide commitment zScarcity of skilled personnel

24. Benefits of CMM zVisibility of software process to management zPredictable performance ytime and cost estimation ydecreases differences in targeted/actual results and variability of results zBetter control over new technologies and applications zMore efficient communication yconcise, common, quantitative terms zDisciplined change as a way of life