Learning Objectives

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

2. ISM 5316 Software Process Models and the CMM

3. Software Process Models • Purpose of software process models: • determine order of stages • What shall we do next? • establish transition criteria from one stage to the next • How long shall we continue to do it? • Model vs. method • Process vs. product

4. Problems with Software Development Processes • Late, over-budget, chaotic, undisciplined • Poor quality software products • Best results due to individual heroic efforts, not mature process • No consistent long-term productivity • Difficult to repeat best results • Larger, more complex projects need a shift from technical to management focus • $$ spent on software increases 12+% per year • Increasing demand for added functionality

5. Steps Write some code Fix problems in the code Think about requirements, design, testing, and maintenance later Code-driven Problems Increasingly poorly structured code Increasingly expensive to change and fix Poor match to users’ needs, thus increasing the need for changing and fixing Code-and-Fix Model

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

7. Difficulties with Waterfall • Document-driven • Formal specs may be too much, inaccurate • Doesn’t accommodate: • Parallel or incremental development • Changing requirements • Interactive software • 4GL tools

8. Evolutionary and Transform Models • “I can’t tell you what I want, but I’ll know it when I see it” • Prototyping • Iterative development • Expanding operational software incrementally • Too much like Code&Fix • Lack of planning • Lack of structure • Transform Model • more structured Client

9. Risk-driven (versus document-driven or code-driven) Evolutionary and flexible Iterative enhancement Prototyping = risk reduction Specifications not uniform, exhaustive, or formal = less time Focuses early attention on reuse Incorporates software quality objectives Spiral Model (Iterative)

10. Steps in Each Cycle of Spiral Model • Objectives • Constraints • Alternatives • Risk identification • Risk resolution and results • Plan for next phase • (Re)commitment

11. Object-Oriented Process Model • Establish core requirements: Conceptualization • Proof of concept (risk) • Develop a model of desired behavior: Analysis • develop common vocabulary • Create an architecture: Design • policies for implementation • Evolve the implementation: Evolution • refine architecture • Manage postdelivery evolution: Maintenance • continued evolution based on new requirements

12. Object-Oriented Process Analysis Conceptualization Design Maintenance Evolution

13. Current Life-cycle Phases • Engineering • Inception (idea) • Elaboration (architecture) • Production • Construction (iterations - beta releases) • Transition (products)

14. Capability Maturity Model (CMM) • Helps organizations improve software processes • Based on results of assessments of contractors, industry and gov’t feedback • Software process assessment • assess current capabilities • highlight high-priority areas for improvement • gain organizational support for improvement • Based on Juran’s Trilogy of quality improvement • quality planning, control, improvement • 5 maturity levels

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

16. CMM Definitions • Software process • Activities, methods, practices, and transformations used by people to develop and maintain software products • Capability • Range of expected results achieved by a software process • Performance • Actual results achieved by a software process • Maturity • Extent to which a software process is explicitly defined, managed, controlled, effective, and consistent

17. CMM Level 1: Initial • Unstable, chaotic software processes • Poor planning undermines good software engineering practices • Process capability is unpredictable • Performance depends on individual capabilities, not repeatable • Procedures are abandoned in crises • Lack understanding of importance of planning, design, reviews, testing

18. CMM Level 2: Repeatable • Management vs. technical focus • PM policies and procedures are established, PM standards are defined and enforced • Planning is based on previous experiences • time, cost estimation • Effective processes are: • practiced, documented, enforced, trained, measured • Objective: Basic management controls

19. CMM Level 3: Defined • Software processes, both project management and software engineering, are standardized and documented • Organization-wide process definition and training • Projects can tailor processes to their unique needs • processes empower but don’t constrain • Well-defined, consistent processes, have: • readiness criteria, inputs, outputs • performance standards, completion criteria, verification • Software Engineering process group established • Common organizational understanding of process • activities, roles, responsibilities

20. CMM Level 4: Managed • Quantitative measures of quality • products and processes • Organization-wide process database for analysis and as basis for measurement • Narrow variation in process performance • Risk assessment and management • Predictable capability

21. CMM Level 5: Optimizing • Organization-wide focus on continuous improvement • incremental improvement • improvement by adoption & transfer of innovations • Goal is defect prevention • analyze defects to determine causes • Lessons learned transferred to future projects • Emulates statistical process control in manufacturing systems

22. Strengths and Limitations • Descriptive, normative model of behavior • Doesn’t constrain unique organizational process needs • Needs to be interpreted, implemented to fit the context • organization’s strategic objectives, culture, structure, systems • Assumes other organizational change processes in place • Takes 1+ years to move from one level to the next • Levels should not be skipped • each providesthefoundation for the next one

23. Difficulties in Improving Software Processes • Lack of consensus between managers and developers about how to improve • Focus on management vs. engineering • management process harder to define • Requires time - no quick fix • Must be done one level at a time • Requires culture change • Requires organization-wide commitment • Scarcity of skilled personnel

24. Benefits of CMM • Visibility of software process to management • Predictable performance • time and cost estimation • decreases differences in targeted/actual results and variability of results • Better control over new technologies and applications • More efficient communication • concise, common, quantitative terms • Disciplined change as a way of life