Capability Maturity Model Integration (CMMI) Definition and Solutions
Capability Maturity Model Integration (CMMI) topics covering definition, objectives, systems and solutions.
Wed, October 17, 2007
- What does CMMI mean?
- Where did it come from?
- What is it used for?
- Why should I bother with it?
- Is CMMI for everyone?
- What improvements can I expect?
- What's SCAMPI?
- What's the future of CMMI?
Where did it come from?
CMMI is the successor to CMM (Capability Maturity Model). Both CMM and CMMI were developed at the Software Engineering Institute (SEI) at Carnegie Mellon University in Pittsburgh, Pa. CMM was developed in the late 1980s, and retired a decade later when CMMI was developed. CMMI v1.02 was released in 2000.
The current version, released in August 2006, is CMMI 1.2.
A Little History
Since CMMI inherited much of its structure from CMM, let's take a look at CMM's genesis and reasons for being to get an idea of how both models were meant to be used.
CMM was developed as a result of a study financed by the U.S. Air Force as a way to objectively evaluate the work of software subcontractors. The Department of Defense, concerned over escalating software development costs and issues with quality, established the SEI in the early 1980s, and work on the CMM began in 1988. It was first described in the 1989 book, Managing the Software Process, by Watts Humphrey, director of the software process program at the SEI, and in August 1991 the first version of the Capability Maturity Model for Software (SW-CMM) was published by the SEI.
The CMM was originally intended to be a tool to evaluate the ability of government contractors to perform a contracted software project. Though it was designed to measure software development, it has been, and continues to be, applied as a general model of the maturity of processes in both IT and non-IT organizations.
The model identifies five levels of process maturity for an organization:
- Initial (chaotic, ad hoc, heroic): The starting point for use of a new process.
- Repeatable (project management, process discipline): The process is used repeatedly.
- Defined (institutionalized): The process is defined/confirmed as a standard business process.
- Managed (quantified): Process management and measurement take place.
- Optimizing (process improvement): Process management includes deliberate process optimization/improvement.
There are key process areas (KPAs) within each of these maturity levels that characterize that level, and five measures for each KPA:
- Goals
- Commitment
- Ability
- Measurement
- Verification
Companies were expected to be formally assessed as to their maturity level. As they achieved each level, they formed a plan to get to the next. However, the rigorous processes required precluded the advancement of many commercial software companies beyond level 1.
Critics also noted that the CMM was too firmly entrenched in the waterfall development model, and didn't address other facets of the software development process such as design and deployment. It didn't adapt to peripheral processes involved in software development, such as acquisition. They complained that CMM generated too much paperwork and too many meetings, and that it wasn't a good fit for many industries.
Industry and government sought to solve the problem by adapting the CMM to other areas. After the original CMM for software (SW-CMM) was released, the Enterprise Process Improvement Collaboration (EPIC), a group of representatives from industry and government, developed and published the Systems Engineering Capability Maturity Model (SE-CMM), and the International Council on Systems Engineering (INCOSE) developed and published the Systems Engineering Capability Assessment Model (SECAM). Other CMMs were then added to the mix, including the Software Acquisition CMM, the People CMM and the Integrated Product Development CMM.
The Electronic Industries Alliance (EIA), along with EPIC and INCOSE, began an effort to consolidate the two systems engineering CMMs, resulting in the Systems Engineering Capability Model (SECM) that was assigned the designation EIA/IS-731. Other organizations also developed CMMs that integrated several disciplines, resulting in CMMs such as the Federal Aviation Administration's integrated Capability Maturity Model (FAA-iCMM). The alphabet soup was getting out of hand, so when the SW-CMM Version 2.0 was completing its review process, the Office of the Undersecretary of Defense for Acquisition and Technology (OSD) decided that the CMM Version 2.0 should be canceled as a standalone CMM, and the CMMI project be undertaken collectively by industry, government and SEI to pull everything together.
The entire process is overseen by a steering group, which is composed of representatives from OSD, Air Force, Army, Navy, other government, SEI and industry. Its mission is to direct and oversee the development of the CMMI product suite, including approving CMMI products for review and public release. SEI handles project management in collaboration with subject matter experts, initially in software, systems engineering, and integrated product and process development. Stakeholder/reviewers are chartered to review, comment and make recommendations on the CMMI products developed. They also consist of representatives from industry, government and the SEI.
So, as you see, CMMI isn't exactly new. Rather, it's an amalgamation and adaptation of the many CMM variants that grew up in response to industry demands. Understand CMM and where it came from, and you'll see the foundation of CMMI. For example, CMMI defines maturity in the same five levels as its predecessor, with the same KPAs. Its models consist of 22 process areas organized into four categories: process management, project management, engineering and support. And it's used in most of the same places—think evolution, not revolution. CMMI brings together the collective wisdom of the various industries that tweaked the CMM to suit themselves.


