4. The continuous representation allows you to select fewer process areas to institutionalize.

These myths and legends have been gathered from the marketing of the CMMI, user perceptions, organizational implementations of the model, appraisals , public statements made during conferences, and conflicting statements in the CMMI itself. The authors of this book do not make any claims as to these arguments. We believe readers should be able to make up their own minds.

1. CMM Maturity Level 2 is the same as CMMI Maturity Level 2.

Because several of the process areas are named the same, uninitiated users feel that the two models are not significantly different. We disagree . For example, Requirements Management under the CMM only included requirements as they related to building your software. So while you may have had some systemwide requirements, the only responsibility you had toward them was to use them as the basis for initially deriving software- related requirements. You did not have to ensure that the higher-level requirements had been met. Now, Requirements Management under the CMMI includes all requirements ” from the systems engineering people, the hardware people, the software people, and any other requirements that need to be met. Thus, the scope has been greatly expanded. In addition, a few more process areas have been added. For example, Measurement and Analysis is now its own process area, and includes not only metrics to collect, but describes different activities recommended/ required to be instituted. Most smaller organizations and less-mature organizations have indicated that this is a good process area but far too difficult to implement at Level 2. So with the increased scope of the model including the various disciplines (systems engineering, supplier sourcing, etc.), plus the additional process areas, the two models and the two levels are dissimilar.