Think back to the mid-1980s: The Cold War was still warm, and the U.S. Department of Defense was increasingly relying on computers for all aspects of its operations. The computers were puny compared with today's, and military computers had to meet stringent environmental and reliability requirements that made them even bigger, heavier and slower than civilian machines.
Graphical operating systems and applications were starting to appear, and most military software was developed by external contractors. The DOD badly needed a way to determine whether contractors could provide software on time, within budget and to specifications.
The answer came from Carnegie Mellon University's Software Engineering Institute. Its Capability Maturity Model was a way to assess and describe the quality of an organization's software development. First released around 1990, CMM was eventually extended to other process areas. In 2001, many disparate elements were brought together into a single initiative known as CMMI, or Capability Maturity Model Integration.
CMMI combines a carefully chosen set of best practices based on experience in a variety of disciplines, including systems analysis and design, software engineering and management. With CMMI, an organization can simultaneously tackle a range of improvements that would otherwise be addressed as free-standing initiatives. This, in turn, encourages improvement throughout the enterprise and helps organizations consider the full product development life cycle.
CMMI comes in two basic flavors: staged and continuous. Staged CMMI is the better known, with its five levels of maturity. It enables comparisons between organizations and offers a proven sequence for improvement.
Continuous representation of CMMI lets an organization select specific improvements that best meet its business objectives and minimize risk, while perhaps making it easier to compare processes across projects and to transition from other quality standards. Both CMMI representations are designed to provide equivalent results.
Within each of the CMMI maturity levels, key processes are defined in five areas: goals, commitment, ability, measurement and verification. CMMI developers have defined a rigorous method to assess how well an organization meets the goals of each level. The Standard CMMI Appraisal Method for Process Improvement (SCAMPI) provides detailed ratings of strengths and weaknesses relative to the CMMI models.
SCAMPI was developed to help organizations improve their processes by setting priorities and focusing on improvements that match business goals. Many third-party organizations offer SCAMPI appraisal services.
CMMI is similar to ISO 9001, an international standard that specifies an effective quality system for software development and maintenance. The main difference between the two is that ISO 9001 specifies a minimal acceptable quality level for software processes, while CMMI establishes a framework for measuring continuous process improvement and is more explicit in defining the means to that end.
One unanticipated consequence of CMM development was that it gave a significant boost to software development outsourcing, particularly in the pre-Y2k period. Economic development agencies in India and Ireland, for example, have praised CMMI for allowing them to compete for U.S. outsourcing contracts. This has had a very positive effect on the employment of software engineers in Third World economies, but it has also adversely affected the high-tech job market in developed countries.
What CMMI Can't Do
CMMI was invented to help military officers quickly assess and describe contractors' abilities to deliver correct software on time, and in this regard, it has been a great success. But CMMI is not the answer for every organization. Its rigid requirements for documentation and step-by-step progress make it better suited to large organizations than to small.
But even most large, commercial developers that sell packaged software—including companies such as Apple Computer Inc. and Microsoft Corp.—rarely manage their requirements documents as formally as CMMI requires. And because such documentation is a requirement for Level 2, all of those companies would, if rated, rank on the maturity scale as Level 1, initial or ad hoc.
In particular, CMMI does not tell an organization how to implement improvements in software development—it merely indicates where they're needed. CMMI models are not themselves processes or even process descriptions. The actual processes an organization chooses depend on many factors, and the process areas of a CMMI model may simply not map one-to-one with those used in your organization. It turns out that the traits CMMI measures are, in practice, difficult to develop, even though they're easy to recognize.