The Capability Maturity Model in Software Development Paul X. Harder, JD Government Micro Resources, Inc. September 14, 2004

The Capability Maturity Model What is the Capability Maturity Model (CMM)? The application of process management and quality improvement concepts to software development and maintenance. The application of process management and quality improvement concepts to software development and maintenance. A guide for evolving toward a culture of engineering excellence. A guide for evolving toward a culture of engineering excellence. A model for organizational improvement. A model for organizational improvement.

The Capability Maturity Model Working with DoD, Carnegie-Mellon University (CMU) created the Software Engineering Institute In September 1987, the SEI released a brief description of the process maturity framework Two methods, software process assessment and software capability evaluation and a maturity questionnaire were developed to appraise software process maturity. In 1991, SEI released the Capability Maturity Model for Software version 1.0. In 2001, SEI released the Capability Maturity Model – Integrated, superseding the CMM for software.

Focuses on practices that are under control of the software group Presents a minimum set of recommended practices that have been shown to enhance a software development and maintenance capability It defines the expectation (the “what”) It defines the expectation (the “what”) Without overly constraining the implementation (the “how”) Without overly constraining the implementation (the “how”) Capability Maturity Model

Process Maturity Increases Project Success Probability Time/$/... Target N Target N+a Target N-x Target N-y Target N-z Maturity Levels Plans based on past performance are more realistic in Level 2 organizations With well-defined processes, performance improves in Level 3 organizations Schedule and cost targets are typically overrun by Level 1 organizations Based on quantitative understanding of process and product, performance continues to improve in Level 4 organizations Performance continuously improves in Level 5 organizations

CMM-I Based on the CMM-SW model created in 1991 to assess the maturity of software development, with integration into other models. Multiple models, based on disciplines addressed CMMI - SW: Software Engineering CMMI - SE / SW: above plus Systems Engineering CMMI - SE / SW / IPPD: above plus Integrated Product & Process Development CMMI - SE / SW / IPPD / SS: above plus Supplier Sourcing C M M I

Why We Chose CMM CMM today serves as a “seal of approval” in software development CMM helped guide us towards standard, repeatable processes – reduced learning time on how to get things done Standard practices mean time savings to our team - everyone knows what to expect and what to deliver Our quality activities became more aligned within the project rather than thought of as a separate event We rely on our processes and our people together, not just one or the other Ideas in CMM creates an environment of improvement – if you don’t like things one way, make it better!

Level FocusProcess Areas 5 Optimizing Continuous Process Improvement Organizational Innovation and Deployment Causal Analysis and Resolution 4 Quantitatively Managed Quantitative Management Organizational Process Performance Quantitative Project Management 3 Defined Process Standardization Requirements Development Technical Solution Product Integration Verification Validation Organizational Process Focus Organizational Process Definition Organizational Training Integrated Project Mgmt (with IPPD extras) Risk Management Decision Analysis and Resolution Integrated Teaming (IPPD only) Org. Environment for Integration (IPPD only) Integrated Supplier Management (SS only) Requirements Management Project Planning Project Monitoring and Control Supplier Agreement Management Measurement and Analysis Process and Product Quality Assurance Configuration Management 2 Managed Basic Project Management 1 Initial Quality Productivity Risk Rework Stages of Process Maturity

Level 1: the “Initial” Level Success depends on heroes Good performance is possible - but Requirements often misunderstood, uncontrolled Schedules and budgets frequently missed Progress not measured Product content not tracked or controlled Engineering activities nonstandard, inconsistent Teams not coordinated, not trained Defects proliferate

CMMI Level 2: “Managed” Baseline the product requirements Estimate project parameters, Estimate project parameters, Develop plans and processes Measure actual progress to enable timely corrective action Measure for mgmt. info needs Measure for mgmt. info needs Verify adherence of processes and products to requirements Identify and control products, changes, problem reports Select qualified suppliers / vendors; manage their activities CLARIFY REQUIREMENTS DOCUMENT PLANS TRACK PROGRESS CONTROL PRODUCTS 7 Process Areas –Requirements Management (REQM) Project Planning (PP) –Project Monitoring and Control (PMC) –Measurement & Analysis(M&A) –Process & Product Quality Assurance (PPQA) –Configuration Management (CM) –Supplier Agreement Management (SAM)

What Happens During Level 2 Processes become easier to digest and understand Managers and team members spend less time explaining how things are done and more time doing Projects are better estimated, better planned, and more flexible Quality is integrated into the project Costs may go up initially, but do go down over time And yes, there may be more documentation and paper

Clarify customer requirements Clarify customer requirements Solve design requirements; develop implementation processes Solve design requirements; develop implementation processes Assemble product components, deliver Assemble product components, deliver Ensure products meet requirements Ensure products meet requirements Ensure products fulfill intended use Ensure products fulfill intended use Analyze decisions systematically Analyze decisions systematically Follow integrated, defined processes Follow integrated, defined processes Identify and control potential problems Identify and control potential problems Establish org. responsibility for PI Establish org. responsibility for PI Define the org’s best practices Define the org’s best practices Develop skills and knowledge Develop skills and knowledge ENGINEER THE PRODUCT MANAGE THE PROCESSES PROVIDE ORG. INFRASTRUCTURE CMMI Level 3: “Defined” 11 Process Areas* 11 Process Areas* –Requirements Definition (RD) –Technical Solution (TS) –Product Integration(PI) –Verification(Ver) –Validation(Val) –Decision Analysis & Resolution(DAR) –Integrated Project Mgmt(IPM) –Risk Management(RSKM) –Org. Process Focus(OPF) –Org. Process Definition (OPD) –Org. Training(OT)

What Happens During Level 3 Process Improvement becomes the standard – Cross-Functional teams look for ways to “short- cut” the system Solutions go from being “coded” to being “engineered” Quality gates appear throughout the project effort with the entire team involved in the process, reducing rework Risks are managed and don’t take the team by surprise

MANAGE PROJECTS QUANTITATIVELY MANAGE THE ORGANIZATION QUANTITATIVELY CMMI Level 4: “Quantitatively Managed” Statistically manage the project’s processes and sub-processes Understand process performance; quantitatively manage the organization’s projects 2 Process Areas –Quantitative Project Management(QPM) –Organizational Process Performance(OPP)

CMMI Level 5: “Optimizing” Identify and eliminate the cause of defects early Identify and deploy new tools and process improvements to meet needs and business objectives OPTIMIZE PERFORMANCE ADOPT IMPROVEMENTS 2 Process Areas –Causal Analysis and Resolution(CAR) –Organizational Innovation and Deployment(OID)

The CMM Maturity Levels Maturity Level 1 ~ Maturity Level 2 ~ ~ ~ Maturity Level 3 ~ ~ ~ ~ ~~ Maturity Level 4 ~~ ~ ~~~ ~ Maturity Level 5

Proving Maturity Levels Five characteristics must be demonstrated in each practice to be assessed in that maturity level practice areas: Commitment to Perform – Policies, procedures, and resources to perform the work Commitment to Perform – Policies, procedures, and resources to perform the work Ability to Perform – Personnel, tools, and templates in place Ability to Perform – Personnel, tools, and templates in place Activities Performed – Documentation and interviews demonstrating that policies are implemented Activities Performed – Documentation and interviews demonstrating that policies are implemented Measurement and Analysis – Metrics and other tools used to evaluate effectiveness of processes Measurement and Analysis – Metrics and other tools used to evaluate effectiveness of processes Verifying Implementation – Independent review and evaluation of the processes Verifying Implementation – Independent review and evaluation of the processes Maturity levels are proven through documentation (policies, procedures, templates) and interviews of staff (to prove institutionalization).

Source: CMM Process Maturity Profile of Software Organizations

Pitfalls of Implementation

How Long Does it Take? Implementing CMM does not occur overnight. Implementing CMM is not merely a “paper drill”. Typical times for implementation: 3-6 months of preparation 3-6 months of preparation 6-12 months of implementation 6-12 months of implementation 3 months of assessment preparation 3 months of assessment preparation 12 months for each new level 12 months for each new level

Is it Perfect? No! Some implementations do more harm than good. Complete re-vamp of processes to “get certified” instead of smartly adapting processes. Complete re-vamp of processes to “get certified” instead of smartly adapting processes. Process focus used more as a stick than as a carrot. Process focus used more as a stick than as a carrot. Focusing on compliance instead of improvement. Focusing on compliance instead of improvement.

Overall Benefits Defect rates have dropped Defect detection occurs earlier User requirements are documented, controlled, and managed Especially important when users change their minds! Especially important when users change their minds! Estimating improves and becomes more precise Risk management is a practice Development processes remain agile!

Implementation Best Practices Be Realistic – Some processes will be more ready than others. Be Flexible – Allowing tailoring is key to adoption. Be Open – The key is to learn how to do things better, not how to “comply”. Be Patient – It does not happen overnight.

For More Information CMM Softcopy: Overview article: in SME Guidebook and at 96.ar.cmm.v1.1.html Overview article: in SME Guidebook and at 96.ar.cmm.v1.1.html 96.ar.cmm.v1.1.html 96.ar.cmm.v1.1.html CMMI Sources: CMMI Softcopy: CMMI Softcopy: Transitioning to CMMI – A Guide for Executives Transitioning to CMMI – A Guide for Executives