Capability Maturity Model Integration

From Wikipedia, the free encyclopedia

Capability Maturity Model® Integration (CMMI) is a process improvement approach that provides organizations with the essential elements of effective processes. ^[1] The latest version of CMMI ver 1.2 was released in August 2006. There are 3 constellations of CMMI in the new version: CMMI Development, CMMI Services and CMMI Acquisition.

CMMI for Development Ver 1.2 consists of 22 process areas with capability or maturity levels. CMMI is created by the Software Engineering Institute (SEI) and is available for download from the SEI.

CMMI should be adapted to each individual company, therefore companies are not "certified." A company is appraised (e.g. with an appraisal method like SCAMPI) at a certain level of CMMI. The results of such an appraisal can be published if released by the appraised organization.^[2]

Contents 1 Process Areas 2 History 3 Appraisal 4 Evaluation 5 Structure 6 References 7 Footnotes 8 See also 9 External links

[edit] Process Areas

The CMMI v1.2 contains 22 process areas:

CMMI Causal Analysis and Resolution CMMI Configuration Management CMMI Decision Analysis and Resolution CMMI Integrated Project Management CMMI Measurement and Analysis CMMI Organizational Innovation and Deployment CMMI Organizational Process Definition CMMI Organizational Process Focus CMMI Organizational Process Performance CMMI Organizational Training

CMMI Product Integration CMMI Project Monitoring and Control CMMI Project Planning CMMI Process and Product Quality Assurance CMMI Quantitative Project Management CMMI Requirements Development CMMI Requirements Management CMMI Risk Management CMMI Supplier Agreement Management CMMI Technical Solution CMMI Validation CMMI Verification

[edit] History

The CMMI is the successor of the CMM. The CMM was developed from 1987 until 1997. In 2002 version 1.1 of the CMMI was released: v1.2 followed in August 2006. The goal of the CMMI project is to improve usability of maturity models for software engineering and other disciplines, by integrating many different models into one framework. It was created by members of industry, government and the SEI. The main sponsors included the Office of the Secretary of Defense (OSD) and the National Defense Industrial Association (NDIA) Systems Engineering Committee. ^[3]

CMMI is often criticized for being overly bureaucratic and for pushing reliability over services provided.^{[citation needed]}

[edit] Appraisal

There are three different types of appraisals, also know as SCAMPI Appraisals. They are type A, B and C. In Appraisal Requirements for CMMI (ARC) the requirements for CMMI appraisal methods are described.^[4] The Standard CMMI Appraisal Method for Process Improvement (SCAMPI) is the only appraisal method which meets all of the ARC requirements for a Class A appraisal method.^[5]

An appraisal team is obligatory when conducting a class A appraisal (in class B and C these are optional). Class A appraisals are more formal and is the only one that can result in a "rating." They are all used for marketing purposes.

The results of the appraisal are published (if the concerning company approves) on the website of the SEI: Published SCAMPI Appraisal Results. SCAMPI also supports the conduct of ISO/IEC 15504, also known as SPICE (Software Process Improvement and Capability Determination), assessments.

[edit] Evaluation

The SEI states that 60 organizations measured increases of performances in the categories cost, schedule, productivity, quality and customer satisfaction.^[6] The median increase in performance varied between 14% (customer satisfaction) and 62% (productivity). However, the CMMI model mostly deals with what processes should be implemented, and not so much with how they can be implemented. SEI thus also mentions that these results do not guarantee that applying CMMI will increase performance in every organization. A small company with few resources may be less likely to benefit from CMMI; this view is supported by the Process Maturity Profile (page 10). Of the small organizations (<25 employees) 70.5% is assessed at level 2: Managed, while 52.8% of the organizations with 1001–2000 employees are rated at the highest level (5: Optimizing).

Interestingly, Turner & Jain (2002) argue that although it is obvious there are large differences between CMMI and agile methods, both approaches have much in common. They believe neither way is the 'right' way to develop software, but that there are phases in a project where one of the two is better suited. They suggest one should combine the different fragments of the methods into a new hybrid method. The combination of the project management technique Earned value management (EVM) with CMMI has been described (Solomon, 2002). To conclude with a similar use of CMMI, Extreme Programming (XP), a software engineering method, has been evaluated with CMM/CMMI (Nawrocki et al., 2002). For example, the XP requirements management approach, (which relies on oral communication), was evaluated as not compliant with CMMI. An agile approach to the CMMI is discussed in detail in "Agile CMMI" by Jeff Dalton on Auerbach Publications (2007).

[edit] Structure

The CMMI comes with two different representations - staged and continuous. The staged model, which groups process areas into 5 maturity levels, was also used in the ancestor software development CMM, and is the representation used to achieve a "CMMI Level Rating" from a SCAMPI appraisal. The continuous representation, which was used in the ancestor systems engineering CMM, defines capability levels within each profile. The differences in the representations are solely organizational; the content is equivalent.

The CMMI uses a common structure to describe each of the 22 process areas (PAs). A process area has 1 to 4 goals, and each goal is comprised of practices. Within the 22 PAs these are called specific goals and practices, as they describe activities that are specific to a single PA. There is one additional set of goals and practices that apply in common across all of the PAs; these are called generic goals and practices. Table 1 describes CMMI terminology in more detail. The page numbers refer to the Staged Representation. Common Features are historical artifacts from the software CMM; they do not appear in the CMMI v1.2.

Table 1: CMMI concept definition list

Concept	Definition (source)
CAPABILITY LEVEL	CAPABILITY LEVELS, which belong to the continuous representation, apply to an organization’s process-improvement achievement for each process area. There are six capability levels, numbered 0 through 5. Each capability level corresponds to a generic goal and a set of generic and specific practices. (page 20)
CMMI MODEL	Since the CMMI Framework can generate different models based on the needs of the organization using it, there are multiple CMMI models. Consequently, the phrase “CMMI MODEL” could be any one of many collections of information. The phrase “CMMI models” refers to one, some, or the entire collection of possible models that can be generated from the CMMI Framework. (page 29)
CONTINUOUS REPRESENTATION	The CONTINUOUS REPRESENTATION uses capability levels to measure process improvement. (page 20)
DISCIPLINE AMPLIFICATION	Model components that provide guidance for interpreting model information for specific disciplines (e.g., systems engineering, or software engineering) are called “DISCIPLINE AMPLIFICATIONS.” Discipline amplifications are added to other model components where necessary. These are easy to locate because they appear on the right side of the page and have a title indicating the discipline that they address (for example, “For Software Engineering”). (page 8)
GENERIC GOAL	GENERIC GOALS are called “generic” because the same goal statement appears in multiple process areas. In the staged representation, each process area has only one generic goal. Achievement of a generic goal in a process area signifies improved control in planning and implementing the processes associated with that process area, thus indicating whether these processes are likely to be effective, repeatable, and lasting. Generic goals are required model components and are used in appraisals to determine whether a process area is satisfied. (page 19)
GENERIC PRACTICE	GENERIC PRACTICES provide institutionalization to ensure that the processes associated with the process area will be effective, repeatable, and lasting. Generic practices are categorized by generic goals and common features and are expected components in CMMI models. (Only the generic practice title, statement, and elaborations appear in the process areas.) (page 19)
GENERIC PRACTICE ELABORATIONS	After the specific practices, the generic practice titles and statements appear that apply to the process area. After each generic practice statement, an elaboration may appear in plain text with the heading “Elaboration.” The GENERIC PRACTICE ELABORATION provides information about how the generic practice should be interpreted for the process area. If there is no elaboration present, the application of the generic practice is obvious without an elaboration. (page 7)
GOAL	A “GOAL” is a required CMMI component that can be either a generic goal or a specific goal. When you see the word “goal” in a CMMI model, it always refers to model components (for example, generic goal, specific goal). (page 27)
MATURITY LEVEL	A MATURITY LEVEL is a defined evolutionary plateau of process improvement. Each maturity level stabilizes an important part of the organization’s processes. Maturity levels, which belong to the staged representation, apply to an organization’s overall maturity. There are five maturity levels, numbered 1 through 5. Each maturity level comprises a predefined set of process areas. (page 21)
PROCESS AREA	A PROCESS AREA is a cluster of related practices in an area that, when performed collectively, satisfy a set of goals considered important for making significant improvement in that area. All CMMI process areas are common to both continuous and staged representations. In the staged representation, process areas are organized by maturity levels. (page 17)
REFERENCE	REFERENCES are informative model components that direct the user to additional or more detailed information in related process areas. Typical phrases expressing these pointers are “Refer to the Organizational Training process area for more information about identifying training needs and providing the necessary training” or “Refer to the Decision Analysis and Resolution process area for more information about evaluating and selecting among alternatives.” All references are clearly marked in italics. (page 19)
SPECIFIC GOAL	SPECIFIC GOALS apply to a process area and address the unique characteristics that describe what must be implemented to satisfy the process area. Specific goals are required model components and are used in appraisals to help determine whether a process area is satisfied. (page 17)
SPECIFIC PRACTICES	A SPECIFIC PRACTICE is an activity that is considered important in achieving the associated specific goal. The specific practices describe the activities expected to result in achievement of the specific goals of a process area. Specific practices are expected model components. (page 17)
STAGED REPRESENTATION	The STAGED REPRESENTATION uses maturity levels to measure process improvement. (page 20)
STATEMENT	A STATEMENT is designed to be used for process-improvement and appraisal purposes. (page 7)
SUBPRACTICE	SUBPRACTICES are detailed descriptions that provide guidance for interpreting specific or generic practices. Subpractices may be worded as if prescriptive, but are actually an informative component in CMMI models meant only to provide ideas that may be useful for process improvement. (page 18)
WORK PRODUCT	The term WORK PRODUCT is used throughout the CMMI Product Suite to mean any artifact produced by a process. These artifacts can include files, documents, parts of the product, services, processes, specifications, and invoices. Examples of processes to be considered as work products include a manufacturing process, a training process, and a disposal process for the product. A key distinction between a WORK PRODUCT and a product component is that a work product need not be engineered or part of the end product. (page 25)