History and Evolution of CMM^®
The Capability Maturity Model^® for Software and its Descendants

A. The Questionnaire

• 1987, September - Watts S. Humphrey authored the first CMM, A Method for Assessing the Software Engineering Capability of Contractors, CMU/SEI-87-TR-23.

This was a 40-page document containing a list of questions to be used as an assessment tool. Each question was mapped to the five levels, still present today. To achieve a level, an organization had to demonstrate they could answer "Yes" to 90% of the "starred" questions and 80% of all questions for that level.

However, there was also a second "Technology" dimension, with two levels A and B, which was displayed vertically (with the 5 -levels horizontal)! The technology dimension assessed the level of automation present. Organizations "matured" from 1A to 5B.

• The Software Capability Evaluation^SM (SCE^SM) was developed for the government (or a prime) to measure the capability of a contractor [external evaluation]. 
• The Software Process Assessment (SPA) was developed for organizations to use to measure their own internal process improvement (self-assessment). However, since there were two different techniques, SCE differed from the SPA, the two methods frequently produced different results. This could be a major financial liability for a contractor. This issue was partially addressed by replacing the SPA with the CBA-IPI method, and later by SCAMPI.^SM

B. SW-CMM 1.0 and 1.1

• Mar 1990 - Mark Paulk, et al distributed the first rough draft of the key practices
• Aug 1991 - Mark Paulk, et al baselined version 1.0 for public release
• Feb 1993 - Mark Paulk, et al baselined version 1.1 for public release. This was published by SEI as two documents, typically distributed in a 3-ring "big-honkin'  binder":
  • Capability Maturity Model for Software, Version 1.1
  • Key Practices of the Capability Maturity Model, Version 1.1
• The CMM-Based Appraisal for Internal Process Improvement (CBA-IPI) was developed to address differences in techniques used by the SCE and SPA methods. More importantly to contractors, this method attempted to address differences in results produced from the two methods. CBA-IPI was built from a "Common Framework" used by the SCE and therefore replaced the SPA method. The CBA-IPI method, either done internally or externally, more closely aligned with, and predicted the results from, an external SCE.
• In 1994, another defining document was produced: A Software Process Framework for the SEI Capability Maturity Model. This document is usually called the CMM Handbook and provides a basic "design" for a process library. For a portable document format (PDF) version of this document (hb01_94.pdf) see the SEI homepage. It contains definitions and checklists, based on CMM, for:
  • policies
  • standards
  • processes
  • procedures
  • tools.
• In 1995, a more compact book version was produced, entitled The Capability Maturity Model: Guidelines for Improving the Software Process, Addison Wesley. This "Blue Book" merged the two 3-ring documents, provided additional supporting information, and was easier to carry. Part Two of the book, chapters 7-10, is officially version 1.1.1 of the Key Practices of the Capability Maturity Model, and fixes 4 typos.
• This version defined the last deployed SW-CMM.

C. SW-CMM 2.0

• Work was begun on updates to the SW-CMM based on industry lessons learned. These lessons included misinterpreted sections, increased knowledge in levels 4 & 5, loosening of verbiage that was seen as being over constrictive (e.g., implying a specific implementation), and "tightening" of some areas where there were common misunderstandings about what the did or did not recommend or require. Some of the rewording was motivated by an increasing user-base and best practices from non-DoD related companies (e.g., commercial and international companies).
• Some of the major changes in SW-CMM included:
  • A goal and a key practice has been added to all Key Process Areas to address "institutionalization" (that you do what you say you do)
  • All goals were rewritten in passive voice
  • Explicitly separating what is informational from what was required
  • Measurement and Analysis practices were rewritten to capture the evolution of measurements
  • Process and product concerns were separated both in the goals for Software Quality Assurance (Maturity Level 2) and the templates for Verifying Implementation (common feature of all levels).
  • Plus:
    • Level 2: Subpractices were added for test management
    • Level 3: Software risk management issues were addressed as goals and key practices in Integrated Software Management (and other KPAs)
    • Level 4: The name of Level 4 was changed from "Managed" to "Quantitatively Managed"
    • Level 5: Technology Change Management became 2 KPAs.
• 1998 - Version 2.0, Draft C was in review. However, work on Version 2 has stopped due to an increasing demand and priority for integrating the various CMM models (and in part the change of SEI sponsorship). Much of the content would be incorporated into the CMMI Project.

D. CMM Integration Project

D1. Mission:

Mission | Project Approach | Technical Approach | Deliverables | Milestones | Guidance

• different architectures
  • "staged" - SW and SA models have KPAs only at one level, which provide guidance on prioritization, and establish a "Maturity Level"
  • "continuous" - the SE model has PAs which have levels within them, with their own "Capability Level" (you could be level 5 in one PA but Level 1 in another)
• different terminology
• different content
• different appraisal methods
• different training materials

Mission | Project Approach | Technical Approach | Deliverables | Milestones | Guidance

D2. Project Approach:

• This program was originally identified by the acronym ICMM, for Integrated-CMM, not to be confused with:
  •  The FAA-iCMM or
  • Capability Im-Maturity Model (CIMM).
• The defined process was a series of Review Groups:
  • Steering Group
  • Product Development Group
    • Project Manager (from SEI)
    • Expert Author Team
  • Stakeholder/Reviewer
  • Public Review

Mission | Project Approach | Technical Approach | Deliverables | Milestones | Guidance

D3. Technical Approach:

• Source Documents:
  • SW-CMM, Version 2, Draft C
  • EIA/Interim Standard 731 (Draft 1.0) Systems Engineering Capability Model (SECM) which combines:
    • SE-CMM
    • SECAM (INCOSE)
  • IPD-CMM, Version 0.98
• Reference Models (not a complete list):
  • SA-CMM (Version 1.01) - although it was excluded from the scope of the immediate project (except as a SW-CMM KPA), it was still a reference document
  • FAA-iCMM (Version 1.0) - members of the FAA development team were also members of the Steering Group
  • ISO/IEC 12207 - Software Life Cycle Process [IEEE/EIA 12207 is the US version]
  • ISO/IEC 15504 - Process Assessment (technical report), requires the addition of a Level 0 (not practiced, now called "incomplete")
• Leveraged Database Technology:
  • Broke models into common elements
  • Various representations generated from the database
  • Used to integrate models, compare style and content, and verify consistency

Mission | Project Approach | Technical Approach | Deliverables | Milestones | Guidance

D4. Components/Deliverables:

• CMMI - The model framework populated with various disciplines, which can be selected
  • SE - Systems Engineering
  • SW - Software Engineering
  • IPPD - Integrated Product and Process Development
  • SS - Source Selection
• ARC - Assessment Requirements for CMMI (similar to the previous CMM Appraisal Framework, CAF) defined minimum requirements for:
  • Class-A - full assessment method
  • Class-B & C - classes of less comprehensive interim assessment methods
• CMMI Lead Assessor Program - similar requirements of current program, authorized for two-year period
• CMMI Training Products - Introduction to the model, assessment team, and assessment lead training
• Definition of Standard CMMI Assessment Method for Process Improvement (compliant to ARC), see SCAMPI section below.

Mission | Project Approach | Technical Approach | Deliverables | Milestones | Guidance

D5. Early Milestones:

• July 1998 - A-Spec (requirements) Version 1.3
• Aug 1998 - Released Stakeholder Review package 1: Framework descriptions, process areas, generic practices
• Nov 1998 - Released Stakeholder Review package 2: CMMI-SW
• Dec 1998 - Released Stakeholder Review package 3: CMMI-SE, SW-CMMI-SW/SE
• Aug 1999 - CMMI^® for Systems Engineering and Software Engineering (CMMI-SW/SE) was released for Public Review: CMMI-SW, CMMI-SE, and CMMI-SW/SE
• Aug 1999 - Stakeholder Review: CMMI-SW/SE/IPPD, added Integrated Product and Process Development
• Sept 1999 - Pilot Training methods
  • Capability Model Training
  • Assessment Training
  • Framework Training
  • Tailoring Guidance
  • Glossary
• Dec 1999 - Public Review: CMMI-SW/SE/IPPD
• Oct [Nov] 1999-May 2000 - Pilot all models
• December 12, 2000 - CMMI-SE/SW/IPPD, v1.02 was released for public review comments from stakeholder review, initial public review, and actual use were incorporated (accepted change requests through Feb 28, 2001). This marked the date, three years later in December 2003, to sunset CMM for Software (SW-CMM, v.1.1.1).
• August 2001 - Release of CMMI, version 1.1, based on feedback from early adopters
• Updated "Blue Book" -- Mary Beth Chrissis, Mike Konrad, and Sandy Shrum. CMMI Guidelines for Process Integration and Product Improvement. SEI Series in Software Engineering, Addison Wesley, 2003.
  • The textbook form of the CMMI Model (like the one published for SW-CMM)
  • Provided a more convenient way to carry around the model!
• Dec-2003 - Sunset of SW-CMM, v.1.1.1 (3 years from release of 1.0)

Mission | Project Approach | Technical Approach | Deliverables | Milestones | Guidance

D6. Interpretive Guidance Project

• March 21, 2003
• Oct 2003 - preliminary report 2003-SR-007
• April 13, 2004 - Interpretive Guidance for CMMI - What We've learned, Gian Wemyss, DC SPIN Presentation

Mission | Project Approach | Technical Approach | Deliverables | Milestones | Guidance

E. SCAMPI

Standard CMMI Appraisal Method(s) for Process Improvement

For more information on SCAMPI, see Standardization of the Appraisal Method
For discussion on impacts of SCAMPI, see Action-Plan Considerations
For comparison of the three SCAMPI classes, see the CMMI page
For more information on Lead Appraisers, see the Certification page

• Sep-1999 - Pilot Assessment methods
  • Assessment Requirements
  • Assessment methodology (quick-look, first assessment, reassessment)
  • Assessment data collection models and tools
  • Assessment team qualifications
• SEPG'2000 - SCAMPI-A Pilots - One complete, two in progress, and six more scheduled
  • SCAMPI-A - (full) SCAMPI is compliant to the ARC Class-A Definition
  • Estimates were that a SCAMPI-A, for all PAs, for levels 2-5, for an organization with 3-6 projects and 6-9 team members, would take 2-3 weeks.
• Sep-2003 - Typical Direct and Indirect Artifacts
• 19-Aug-2004 Draft Community Review Baseline of:
  •  Handbook for Conducting SCAMPI B and SCAMPI C Appraisals
    • SCAMPI-B is compliant to the ARC Class-B Definition
    • SCAMPI-C is compliant to the ARC Class-C Definition