The Capability Maturity Model in Software Development Paul X. Harder,

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. A guide for evolving toward a culture of engineering excellence. 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.

Capability Maturity Model 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”) Without overly constraining the implementation (the “how”)

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

CMM-I 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

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!

Stages of Process Maturity Level 5 Optimizing Focus Continuous Process Improvement 4 Quantitatively Quantitative Managed Management 3 Defined 2 Managed 1 Initial Process Standardization Basic Project Management Process Areas Organizational Innovation and Deployment Causal Analysis and Resolution Quality Productivity Organizational Process Performance Quantitative Project Management 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 Risk Rework

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

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

What Happens During Level 3 Process Improvement becomes the standard – Cross-Functional teams look for ways to “shortcut” 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

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

CMMI Level 5: “Optimizing” OPTIMIZE PERFORMANCE Identify and eliminate the cause of defects early 2 Process Areas – Causal Analysis and Resolution (CAR) ADOPT IMPROVEMENTS Identify and deploy new tools and process improvements to meet needs – Organizational Innovation and Deployment and business objectives (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 Ability to Perform – Personnel, tools, and templates in place Activities Performed – Documentation and interviews demonstrating that policies are implemented Measurement and Analysis – Metrics and other tools used to evaluate effectiveness of 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).

CMM Process Maturity Profile of Software Organizations Maturity Level 1987-91 1997 1999 2001 1- Initial 80% 61% 48% 38% December 2002 32% 2- Repeatable 12% 23% 30% 34% 37% 3- Defined 7% 14% 16% 20% 21% 4- Managed 0% 2% 4% 5% 5% 5- Optimizing 1% 1% 2% 4% 5% Organizations reporting to SEI 130 795 1179 1641 1998 Source: http://www.sei.cmu.edu/sema/profile.html

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 6-12 months of implementation 3 months of assessment preparation 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. Process focus used more as a stick than as a carrot. 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! 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: http://www.sei.cmu.edu/cmm/obtain.cmm.html Overview article: in SME Guidebook and at http://www.sei.cmu.edu/publications/documents/96.reports/96.ar.cmm.v1.1.ht ml CMMI Sources: CMMI Softcopy: http://www.sei.cmu.edu/cmmi/models/models.html Transitioning to CMMI – A Guide for Executives http://www.sei.cmu.edu/cmmi/publications/exec.pdf