Overview

CMMI currently addresses three areas of interest:

1. Product and service development — CMMI for Development (CMMI-DEV),

2. Service establishment, management, and delivery — CMMI for Services (CMMI-
SVC), and
3. Product and service acquisition — CMMI for Acquisition (CMMI-ACQ).

CMMI was developed by a group of experts from industry, government, and the Software
Engineering Institute (SEI) at Carnegie Mellon University. CMMI models provide
guidance for developing or improving processes that meet the business goals of an
organization. A CMMI model may also be used as a framework for appraising the
process maturity of the organization.[1]

CMMI originated in software engineering but has been highly generalised over the years
to embrace other areas of interest, such as the development of hardware products, the
delivery of all kinds of services, and the acquisition of products and services. The word
"software" does not appear in definitions of CMMI. This generalization of improvement
concepts makes CMMI extremely abstract. It is not as specific to software engineering as
its predecessor, the Software CMM (CMM, see below).

[edit] History
CMMI was developed by the CMMI project, which aimed to improve the usability of
maturity models by integrating many different models into one framework. The project
consisted of members of industry, government and the Carnegie Mellon Software
Engineering Institute (SEI). The main sponsors included the Office of the Secretary of
Defense (OSD) and the National Defense Industrial Association.

CMMI is the successor of the capability maturity model (CMM) or software CMM. The
CMM was developed from 1987 until 1997. In 2002, CMMI Version 1.1 was released.
Version 1.2 followed in August 2006.

[edit] CMMI topics

[edit] CMMI representation

CMMI exists in two representations: continuous and staged.[1] The continuous

representation is designed to allow the user to focus on the specific processes that are
considered important for the organization's immediate business objectives, or those to
which the organization assigns a high degree of risk. The staged representation is
designed to provide a standard sequence of improvements, and can serve as a basis for
comparing the maturity of different projects and organizations. The staged representation
also provides for an easy migration from the SW-CMM to CMMI.[1]
[edit] CMMI model framework

For more details on this topic, see Process area (CMMI).

Depending on the CMMI constellation (acquisition, services, development) used, the

process areas it contains will vary. Key process areas are the areas that will be covered by
the organization's processes. The table below lists the process areas that are present in all
CMMI constellations. This collection of eight process areas is called the CMMI Model
Framework, or CMF.

Capability Maturity Model Integration (CMMI) Model Framework (CMF)

Maturity
Abbreviation Name Area
Level
REQM Requirements Management Engineering 2
PMC Project Monitoring and Control Project Management 2
PP Project Planning Project Management 2
CM Configuration Management Support 2
MA Measurement and Analysis Support 2
Process and Product Quality
PPQA Support 2
Assurance
Process
OPD Organizational Process Definition 3
Management
CAR Causal Analysis Support 5

[edit] CMMI models

CMMI best practices are published in documents called models, each of which addresses
a different area of interest. The current release of CMMI, version 1.2, provides models
for three areas of interest: development, acquisition, and services.

• CMMI for Development (CMMI-DEV), v1.2 was released in August 2006. It

addresses product and service development processes.
• CMMI for Acquisition (CMMI-ACQ), v1.2 was released in November 2007. It
addresses supply chain management, acquisition, and outsourcing processes in
government and industry.
• CMMI for Services (CMMI-SVC), v1.2 was released in February 2009. It
addresses guidance for delivering services within an organization and to external
customers.
• CMMI Product Suite (includes Development, Acquisition, and Services), v1.3 is
expected to be released in 2010. CMMI Version 1.3—Plans for the Next Version

Regardless of which model an organization chooses, CMMI best practices should be

adapted by an organization according to its business objectives.

[edit] Appraisal
An organization cannot be certified in CMMI; instead, an organization is appraised.
Depending on the type of appraisal, the organization can be awarded a maturity level
rating (1-5) or a capability level achievement profile.

Many organizations find value in measuring their progress by conducting an appraisal.

Appraisals are typically conducted for one or more of the following reasons:

1. To determine how well the organization’s processes compare to CMMI best

practices, and to identify areas where improvement can be made
2. To inform external customers and suppliers of how well the organization’s
processes compare to CMMI best practices
3. To meet the contractual requirements of one or more customers

Appraisals of organizations using a CMMI model[3] must conform to the requirements

defined in the Appraisal Requirements for CMMI (ARC) document. There are three
classes of appraisals, A, B and C, which focus on identifying improvement opportunities
and comparing the organization’s processes to CMMI best practices. Appraisal teams use
a CMMI model and ARC-conformant appraisal method to guide their evaluation of the
organization and their reporting of conclusions. The appraisal results can then be used
(e.g., by a process group) to plan improvements for the organization.

The Standard CMMI Appraisal Method for Process Improvement (SCAMPI) is an

appraisal method that meets all of the ARC requirements.[4]

A class A appraisal is more formal and is the only one that can result in a level rating.
Results of an appraisal may be published (if the appraised organization approves) on the
CMMI Web site 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 etc.

[edit] Achieving CMMI compliance

The traditional approach that organizations often adopt to achieve compliance with the
CMMI involves the establishment of an Engineering Process Group (EPG) and Process
Action Teams (PATs) [5] This approach requires that members of the EPG and PATs be
trained in the CMMI, that an informal (SCAMPI C) appraisal be performed, and that
process areas be prioritized for improvement. More modern approaches that involve the
deployment of commercially available, CMMI-compliant processes, can significantly
reduce the time to achieve compliance. SEI has maintained statistics on the "time to move
up" for organizations adopting the earlier Software CMM and primarily using the
traditional approach.[6] These statistics indicate that, since 1987, the median times to
move from Level 1 to Level 2 is 23 months, and from Level 2 to Level 3 is an additional
20 months. These statistics have not been updated for the CMMI.

The Software Engineering Institute’s (SEI) Team Software Process methodology and the
Capability Maturity Modeling framework have been successfully employed to accelerate
progress from Maturity Level 1 to Maturity Level 4. They’ve demonstrated progressing
from Level 1 to Level 4 in 30 months, which is less than half of the average time it has
taken traditionally.[7]

[edit] Applications
The SEI published that 60 organizations measured increases of performance in the
categories of cost, schedule, productivity, quality and customer satisfaction.[8] 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. 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% are 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. Sutherland et al. (2007)
assert that a combination of Scrum and CMMI brings more adaptability and predictability
than either one alone. David J. Anderson (2005) gives hints on how to interpret CMMI in
an agile manner. Other viewpoints about using CMMI and Agile development are
available on the SEI Web site.

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.

CMMI can be appraised using two different approaches: staged and continuous. The
staged approach yields appraisal results as one of five maturity levels. The continuous
approach yields one of six capability levels. The differences in these approaches are felt
only in the appraisal; the best practices are equivalent and result in equivalent process
improvement results.