Learning Objectives You should be able to:  Describe the evolution

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

ISM 5316 Software Process Models and the CMM

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

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

Code-and-Fix Model 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

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

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

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

Spiral Model (Iterative) 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

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

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

Object-Oriented Process Analysis Conceptualization Design Maintenance Evolution

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

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

Software Organization Maturity 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

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

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

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

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

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

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

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 provides the foundation for the next one

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

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