CMM : Introduction to Capability Maturity Model (CMM)

	Article No. :	CMM-01
	Author :	Ir Nelson Law, Managing Director of N. Law and Associates
	Date :	15 April 2002
What is CMM ? (1) Background In November 1986, the Software Engineering Institute (SEI) of the Carnegie Mellon University, USA, with assistance from the Mitre Corporation began developing a process maturity framework that would assist organizations in improving their software process. This effort was initiated in response to a request to provide the federal government with a method for assessing the capability of their software contractors. In September 1987, the SEI released a brief description of the process maturity framework and a maturity questionnaire. The SEI intended the maturity questionnaire to provide a simple tool for identifying areas where an organization's software process needed improvement. Note : The SEI is a federally funded research and development center sponsored by the U. S. Department of Defense and operated by the Carnegie Mellon University. Website of SEI is www.sei.cmu.edu After years of experience with the software process maturity framework and the preliminary version of the maturity questionnaire, the SEI evolved the maturity framework into the Capability Maturity Model for Software (CMM or sometimes designated as SW-CMM). The CMM presents sets of recommended practices in a number of key process areas that have been shown to enhance software process capability. The CMM is based on knowledge acquired from software process assessments and extensive feedback from both industry and government. The model has emerged that provides organizations with more effective guidance for establishing process improvement programs than was offered by the maturity questionnaire. The Capability Maturity Model for Software provides software organizations with guidance on how to gain control of their processes for developing and maintaining software and how to evolve toward a culture of software engineering and management excellence. (2) Introduction Initially the Capability Maturity Model (CMM) has emerged as the model for software and therefore it is called the Capability Maturity Model for Software (specifically designated as SW-CMM). It is not intended to be used by small organizations. SW-CMM v1.1 was issued in 1993 by the SEI. SW-CMM v2.0, which incorporates improvements over the v1.1, has been drafted in 1997 but it is still a draft (draft C). The SW-CMM is a model for judging the maturity of the software processes of an organization and for identifying the key practices that are required to increasethe maturity of these processes. (3) Structure of the CMM for Software CMM – SW has the following structure : 5 Maturity Levels > 19 Key Process Areas > 5 Common Features > 334 Key Practices (3.1) 5 Maturity Levels : The CMM for Software has five Maturity Levels. Maturity level is a well-defined evolutionary plateau toward achieving a mature software process. Each maturity level comprises a set of process goals. Achieving each level of the maturity framework establishes a different component in the software process, resulting in an increase in the process capability. Organizing the CMM into the five levels prioritizes improvement actions for increasing software process maturity. 5 Levels consist of the followings which are organized in increasing level of capability : - Level 1 : Initial Level (Chaotic) - Level 2 : Repeatable Level (Disciplined) - Level 3 : Defined Level (Standard consist) - Level 4 : Managed Level (Predictable) - Level 5 : Optimizing Level (Continuously improving) Each maturity level has been decomposed into constituent parts (i.e. Key Process Areas) with the exception of Level 1. (3.2) Each key process area identifies a cluster of related activities that, when performed collectively, achieve a set of goals considered important for enhancing process capability. The key process areas have been defined to reside at a single maturity level. The path to achieving the goals of a key process area may differ across projects based on differences in application domains or environments. Nevertheless, all the goals of a key process area must be achieved for the organization to satisfy that key process area. 19 Key Process Areas (KPA) are shown below : KPA at Level 2 : - Requirements management - Software project planning - Software project control - Software acquisition management - Software quality assurance - Software configuration management KPA at Level 3 : - Organization process focus - Organization process definition - Organization training program - Integrated software management - Software product engineering - Project interface coordination - Peer reviews KPA at Level 4 : - Organization software asset commonality - Organization process performance - Statistical process management KPA at Level 5 : - Defect Prevention - Organizatin process & technology innovation - Organization improvement deployment (3.3) 5 Common Features : Each key process area is organized into five sections called Common Features. There are totally 5 Common Features : - Commitment to Perform Common Feature - Ability to perform Common Feature - Activities Performed Common Feature - Measurement and Analysis Common Feature - Verifying Implementation Common Feature (3.4) 334 Key Practices Each Common Feature has specified the key practices that, when collectively addressed, accomplish the goals of the key process area. Each key process area is described in terms of the key practices that contribute to satisfying its goals. The key practices describe the infrastructure and activities that contribute most to the effective implementation and institutionalization of the key process area. Examples of Key Practices within the KPA for Level 2 (Software Quality Assurance) are Policy, Plan, Resources, Responsibility, Training, Perform, Review Activities, Review Work Products, Report Results to Software Project, Resolve Noncompliance. (4) Software Process Assessment : Software Process Assessment shall be performed by SEI Approved Assessors. As part of his non-disclosure agreement with companies, SEI cannot provide names of companies and their maturity levels based on the data stored within the Process Appraisal Information System (PAIS). However, he has compiled a list of companies that have publicly announced their maturity level and making that list available to the software community. After a successful Software Process Assessment (SPA), the Maturity Level of the organization will be determined. Results are sent by the Assessors to SEI. Published Maturity Levels are posted by the SEI of Carnegie Mellon University on his Web site as a community service. This helps to distribute a list of companies and their publicly announced maturity levels. Interested Parties shall be aware of the following issues regarding this list. a) The information in the list is obtained from publicly available sources. b) The SEI does not certify companies at maturity levels. c) The SEI does not confirm the accuracy of the maturity levels reported in the noted sources. d) The list of Published Maturity Levels is by no means exhaustive. e) The SEI does not use information stored within its Process Appraisal Information System or any information obtained in confidence to produce this document. In addition, the KPA Profile is constructed basing on reports sent to SEI by Approved Assessor after Software Process Assessement. SEI expected only 10% was reported.