TABLE OF CONTENTS The success of the CMM led to a proliferation of capability maturity models: software, systems engineering, software acquisition, people, and security just to name a few that are used by practitioners and are often required by acquisition authorities. Another look at the frameworks quagmire shown in Chapter 1 will suffice to convey this message. Implementing more than one CMM means confronting multiple definitions, jargon, and overlapping process areas. Furthermore, each of the CMM s has a unique and time-consuming associated appraisal method. Thus, among the CMMI goals were these:
Reduce the cost of implementing process improvements when several disciplines have to be considered.
Enhance understanding.
Eliminate duplication and inconsistencies among the models.
Develop common components.
Ensure consistency with the emerging ISO TR 15504 standard.
CMM integration was necessary for more reasons than model efficiency. Software is an integral part of so many products that addressing its interaction with systems engineering is not optional it is required. Even standards that carry the software name in their title, such as IEEE 12207 and 1074, address systems analysis and design as a part of the life cycle. What was once known as a software life cycle is now rapidly becoming a product life cycle.
In late 1998, the U.S. government directed the SEI to start working on CMM integration. Development of CMM v2.0 was halted and resources were channeled to the CMM integration effort. The CMMI project was born. In the beginning, the process improvement community showed some resistance to this...
