Capability Maturity Model (CMM) broadly refers to a
process improvement approach that is based on a process model. CMM also refers
specifically to the first such model, developed by the Software Engineering
Institute (SEI) in the mid-1980s, as well as the family of process models that
followed. A process model is a structured collection of practices that describe
the characteristics of effective processes; the practices included are those
proven by experience to be effective.
CMM can be used to assess an organization against a
scale of five process maturity levels. Each level ranks the organization
according to its standardization of processes in the subject area being
assessed. The subject areas can be as diverse as software engineering, systems
engineering, project management, risk management, system acquisition,
information technology (IT) services and personnel management.
CMM was developed by the SEI at Carnegie Mellon
University in Pittsburgh. It has been used extensively for avionics software
and government projects, in North America, Europe, Asia, Australia, South
America, and Africa.Currently, some government departments require software
development contract organization to achieve and operate at a level 3 standard.
History
The Capability Maturity Model was initially funded
by military research. The United States Air Force funded a study at the
Carnegie-Mellon Software Engineering Institute to create a model (abstract) for
the military to use as an objective evaluation of software subcontractors. The
result was the Capability Maturity Model, published as Managing the Software
Process in 1989. The CMM is no longer supported by the SEI and has been
superseded by the more comprehensive Capability Maturity Model Integration (CMMI).
Maturity Model
The Capability Maturity Model (CMM) is a way to
develop and refine an organization's processes. The first CMM was for the
purpose of developing and refining software development processes. A maturity
model is a structured collection of elements that describe characteristics of
effective processes. A maturity model provides:
• a
place to start
• the
benefit of a community’s prior experiences
• a
common language and a shared vision
• a
framework for prioritizing actions
• a
way to define what improvement means for your organization
A maturity model can be used as a benchmark for
assessing different organizations for equivalent comparison. It describes the
maturity of the company based upon the project the company is dealing with and
the clients.
Context
In the 1970s, technological improvements made
computers more widespread, flexible, and inexpensive. Organizations began to
adopt more and more computerized information systems and the field of software
development grew significantly. This led to an increased demand for
developers—and managers—which was satisfied with less experienced
professionals.
Unfortunately, the influx of growth caused growing
pains; project failure became more commonplace not only because the field of
computer science was still in its infancy, but also because projects became
more ambitious in scale and complexity. In response, individuals such as Edward
Yourdon, Larry Constantine, Gerald Weinberg, Tom DeMarco, and David Parnas
published articles and books with research results in an attempt to
professionalize the software development process.
Watts Humphrey's Capability Maturity Model (CMM)
was described in the book Managing the Software Process (1989). The CMM as
conceived by Watts Humphrey was based on the earlier work of Phil Crosby.
Active development of the model by the SEI began in 1986.
The CMM was originally intended as a tool to
evaluate the ability of government contractors to perform a contracted software
project. Though it comes from the area of software development, it can be, has
been, and continues to be widely applied as a general model of the maturity of
processes in IS/IT (and other) organizations.
The model identifies five levels of process
maturity for an organisation. Within each of these maturity levels are KPAs
(Key Process Areas) which characterise that level, and for each KPA there are
five definitions identified:
• 1.
Goals
• 2.
Commitment
• 3.
Ability
• 4.
Measurement
• 5.
Verification
The KPAs are not necessarily unique to CMM,
representing - as they do - the stages that organizations must go through on
the way to becoming mature.
The assessment is supposed to be led by an
authorised lead assessor. One way in which companies are supposed to use the
model is first to assess their maturity level and then form a specific plan to
get to the next level. Skipping levels is not allowed.
Timeline
• 1987 SEI-87-TR-24 (SW-CMM
questionnaire), released.
• 1989
Managing the Software Process, published.
• 1991
SW-CMM v1.0, released.
• 1993
SW-CMM v1.1, released.
• 1997
SW-CMM revisions halted in support for CMMI.
• 2000
CMMI v1.02, released.
• 2002
CMMI v1.1, released.
• 2006
CMMI v1.2, released.
Current state
Although these models have proved useful to many
organizations, the use of multiple models has been problematic. Further,
applying multiple models that are not integrated within and across an
organization is costly in terms of training, appraisals, and improvement
activities. The CMM Integration project was formed to sort out the problem of
using multiple CMMs. The CMMI Product Team's mission was to combine three
source models:
1. The
Capability Maturity Model for Software (SW-CMM) v2.0 draft C
2. The
Systems Engineering Capability Model (SECM)
3. The
Integrated Product Development Capability Maturity Model (IPD-CMM) v0.98
4. Supplier
sourcing
CMMI is the designated successor of the three
source models. The SEI has released a policy to sunset the Software CMM and
previous versions of the CMMI. The same can be said for the SECM and the
IPD-CMM; these models were superseded by CMMI.
Future direction
With the release of the CMMI Version 1.2 Product
Suite, the existing CMMI has been renamed the CMMI for Development (CMMI-DEV),
V1.2. Two other versions are being developed, one for Services, and the other
for Acquisitions.
In some cases, CMM can be combined with other
methodologies. It is commonly used in conjunction with the ISO 9001 standard,
as well as with the computer programming methodologies of Extreme Programming
(XP), and Six Sigma.
Levels of the CMM
There are five levels of the CMM:
• Level 1 - Initial
o Processes
are usually ad hoc and the organization usually does not provide a stable
environment. Success in these organizations depends on the competence and
heroics of the people in the organization and not on the use of proven
processes. In spite of this ad hoc, chaotic environment, maturity level 1
organizations often produce products and services that work; however, they
frequently exceed the budget and schedule of their projects.
o Organizations
are characterized by a tendency to over commit, abandon processes in the time
of crisis, and not be able to repeat their past successes again.
o Software
project success depends on having quality people.
• Level
2 - Repeatable
o Software
development successes are repeatable. The processes may not repeat for all the
projects in the organization. The organization may use some basic project
management to track cost and schedule.
o Process
discipline helps ensure that existing practices are retained during times of
stress. When these practices are in place, projects are performed and managed
according to their documented plans.
o Project
status and the delivery of services are visible to management at defined points
(for example, at major milestones and at the completion of major tasks).
o Basic
project management processes are established to track cost, schedule, and
functionality. The minimum process discipline is in place to repeat earlier
successes on projects with similar applications and scope. There is still a
significant risk of exceeding cost and time estimate.
• Level
3 - Defined
o The
organization’s set of standard processes, which is the basis for level 3, is
established and improved over time. These standard processes are used to
establish consistency across the organization. Projects establish their defined
processes by the organization’s set of standard processes according to
tailoring guidelines.
o The
organization’s management establishes process objectives based on the
organization’s set of standard processes and ensures that these objectives are
appropriately addressed.
o A
critical distinction between level 2 and level 3 is the scope of standards,
process descriptions, and procedures. At level 2, the standards, process
descriptions, and procedures may be quite different in each specific instance
of the process (for example, on a particular project). At level 3, the
standards, process descriptions, and procedures for a project are tailored from
the organization’s set of standard processes to suit a particular project or
organizational unit.
• Level
4 - Managed
o Using
precise measurements, management can effectively control the software
development effort. In particular, management can identify ways to adjust and
adapt the process to particular projects without measurable losses of quality
or deviations from specifications. At this level organization set a
quantitative quality goal for both software process and software maintenance.
o Subprocesses
are selected that significantly contribute to overall process performance.
These selected subprocesses are controlled using statistical and other
quantitative techniques.
o A
critical distinction between maturity level 3 and maturity level 4 is the
predictability of process performance. At maturity level 4, the performance of
processes is controlled using statistical and other quantitative techniques,
and is quantitatively predictable. At maturity level 3, processes are only
qualitatively predictable.
• Level
5 - Optimizing
o Focusing
on continually improving process performance through both incremental and
innovative technological improvements. Quantitative process-improvement
objectives for the organization are established, continually revised to reflect
changing business objectives, and used as criteria in managing process
improvement. The effects of deployed process improvements are measured and
evaluated against the quantitative process-improvement objectives. Both the
defined processes and the organization’s set of standard processes are targets
of measurable improvement activities.
o Process
improvements to address common causes of process variation and measurably
improve the organization’s processes are identified, evaluated, and deployed.
o Optimizing
processes that are nimble, adaptable and innovative depends on the
participation of an empowered workforce aligned with the business values and
objectives of the organization. The organization’s ability to rapidly respond
to changes and opportunities is enhanced by finding ways to accelerate and
share learning.
o A
critical distinction between maturity level 4 and maturity level 5 is the type
of process variation addressed. At maturity level 4, processes are concerned
with addressing special causes of process variation and providing statistical
predictability of the results. Though processes may produce predictable
results, the results may be insufficient to achieve the established objectives.
At maturity level 5, processes are concerned with addressing common causes of
process variation and changing the process (that is, shifting the mean of the
process performance) to improve process performance (while maintaining
statistical probability) to achieve the established quantitative
process-improvement objectives.
The most beneficial
elements of CMM Level 2 and 3:
• Creation of Software Specifications,
stating what is going to be developed, combined with formal sign off, an
executive sponsor and approval mechanism. This is NOT a living document, but
additions are placed in a deferred or out of scope section for later
incorporation into the next cycle of software development.
• A
Technical Specification, stating how precisely the thing specified in the
Software Specifications is to be developed will be used. This is a living
document.
• Peer
Review of Code (Code Review) with metrics that allow developers to walk through
an implementation, and to suggest improvements or changes. Note - This is
problematic because the code has already been developed and a bad design can
not be fixed by "tweaking", the Code Review gives complete code a
formal approval mechanism.
• Version
Control - a very large number of organizations have no formal revision control
mechanism or release mechanism in place.
• The
idea that there is a "right way" to build software, that it is a
scientific process involving engineering design and that groups of developers
are not there to simply work on the problem du jour.
What is
Capability Maturity Model (CMM)? What are CMM Levels?
Capability Maturity Model is a bench-mark for measuring the maturity of
anorganization’s software process. It is a methodology used to develop and
refine an organization’s software development process. CMM can be used to
assess an organization against a scale of five process maturity levels based on
certain Key Process Areas (KPA). It describes the maturity of the company based
upon the project the company is dealing with and the clients. Each level ranks
the organization according to its standardization of processes in the subject
area being assessed.
A maturity model provides:
§ A place to start
§ The benefit of a
community’s prior experiences
§ A common language
and a shared vision
§ A framework for
prioritizing actions
§ A way to define
what improvement means for your organization
In CMMI models with a staged representation, there are five maturity
levels designated by the numbers 1 through 5 as shown below:
1. Initial
2. Managed
3. Defined
4. Quantitatively
Managed
5. Optimizing
Maturity levels
consist of a predefined set of process areas. The maturity levels are measured
by the achievement of the specific and generic goals that
apply to each predefined set of process areas. The following sections describe
the characteristics of each maturity level in detail.
Maturity Level 1 – Initial: Company has no standard process
for software development. Nor does it have a project-tracking system that
enables developers to predict costs or finish dates with any accuracy.
In detail we can describe it as given below:
§ At maturity level
1, processes are usually ad hoc and chaotic.
§ The organization
usually does not provide a stable environment. Success in these organizations
depends on the competence and heroics of the people in the organization and not
on the use of proven processes.
§ Maturity level 1
organizations often produce products and services that work but company has no
standard process for software development. Nor does it have a project-tracking
system that enables developers to predict costs or finish dates with any
accuracy.
§ Maturity level 1
organizations are characterized by a tendency to over commit, abandon processes
in the time of crisis, and not be able to repeat their past successes.
Maturity Level 2 – Managed: Company has installed basic
software management processes and controls. But there is no consistency or
coordination among different groups.
In detail we can describe it as given below:
§ At maturity level
2, an organization has achieved all the specific and generic
goalsof the maturity level 2 process areas. In other words, the projects of
the organization have ensured that requirements are managed and that processes
are planned, performed, measured, and controlled.
§ The process
discipline reflected by maturity level 2 helps to ensure that existing practices
are retained during times of stress. When these practices are in place,
projects are performed and managed according to their documented plans.
§ At maturity level
2, requirements, processes, work products, and services are managed. The status
of the work products and the delivery of services are visible to management at
defined points.
§ Commitments are
established among relevant stakeholders and are revised as needed. Work
products are reviewed with stakeholders and are controlled.
§ The work products
and services satisfy their specified requirements, standards, and objectives.
Maturity Level 3 – Defined: Company has pulled together a
standard set of processes and controls for the entire organization so that
developers can move between projects more easily and customers can begin to get
consistency from different groups.
In detail we can describe it as given below:
§ At maturity level
3, an organization has achieved all the specific and generic
goals.
§ At maturity level
3, processes are well characterized and understood, and are described in
standards, procedures, tools, and methods.
§ A critical
distinction between maturity level 2 and maturity level 3 is the scope of
standards, process descriptions, and procedures. At maturity level 2, the
standards, process descriptions, and procedures may be quite different in each
specific instance of the process (for example, on a particular project). At
maturity level 3, the standards, process descriptions, and procedures for a
project are tailored from the organization’s set of standard processes to suit
a particular project or organizational unit.
§ The organization’s
set of standard processes includes the processes addressed at maturity level 2
and maturity level 3. As a result, the processes that are performed across the
organization are consistent except for the differences allowed by the tailoring
guidelines.
§ Another critical
distinction is that at maturity level 3, processes are typically described in
more detail and more rigorously than at maturity level 2.
§ At maturity level
3, processes are managed more proactively using an understanding of the
interrelationships of the process activities and detailed measures of the
process, its work products, and its services.
Maturity Level 4 – Quantitatively Managed: In addition
to implementing standard processes, company has installed systems to measure
the quality of those processes across all projects.
In detail we can describe it as given below:
§ At maturity level
4, an organization has achieved all the specific goals of the
process areas assigned to maturity levels 2, 3, and 4 and the generic
goalsassigned to maturity levels 2 and 3.
§ At maturity level 4
Sub-processes are selected that significantly contribute to overall process
performance. These selected sub-processes are controlled using statistical and
other quantitative techniques.
§ Quantitative
objectives for quality and process performance are established and used as
criteria in managing processes. Quantitative objectives are based on the needs
of the customer, end users, organization, and process implementers. Quality and
process performance are understood in statistical terms and are managed
throughout the life of the processes.
§ For these
processes, detailed measures of process performance are collected and statistically
analyzed. Special causes of process variation are identified and, where
appropriate, the sources of special causes are corrected to prevent future
occurrences.
§ Quality and process
performance measures are incorporated into the organizations measurement
repository to support fact-based decision making in the future.
§ A critical
distinction between maturity level 3 and maturity level 4 is the predictability
of process performance. At maturity level 4, the performance of processes is
controlled using statistical and other quantitative techniques, and is
quantitatively predictable. At maturity level 3, processes are only
qualitatively predictable.
Maturity Level 5 – Optimizing: Company has accomplished all of
the above and can now begin to see patterns in performance over time, so it can
tweak its processes in order to improve productivity and reduce defects in
software development across the entire organization.
In detail we can describe it as given below:
§ At maturity level
5, an organization has achieved all the specific goals of the
process areas assigned to maturity levels 2, 3, 4, and 5 and the generic
goalsassigned to maturity levels 2 and 3.
§ Processes are
continually improved based on a quantitative understanding of the common causes
of variation inherent in processes.
§ Maturity level 5
focuses on continually improving process performance through both incremental
and innovative technological improvements.
§ Quantitative
process-improvement objectives for the organization are established,
continually revised to reflect changing business objectives, and used as
criteria in managing process improvement.
§ The effects of
deployed process improvements are measured and evaluated against the
quantitative process-improvement objectives. Both the defined processes and the
organization’s set of standard processes are targets of measurable improvement
activities.
§ Optimizing
processes that are agile and innovative depends on the participation of an
empowered workforce aligned with the business values and objectives of the
organization.
§ The organization’s
ability to rapidly respond to changes and opportunities is enhanced by finding
ways to accelerate and share learning. Improvement of the processes is
inherently part of everybody’s role, resulting in a cycle of continual
improvement.
§ A critical
distinction between maturity level 4 and maturity level 5 is the type of
process variation addressed. At maturity level 4, processes are concerned with
addressing special causes of process variation and providing statistical
predictability of the results. Though processes may produce predictable
results, the results may be insufficient to achieve the established objectives.
At maturity level 5, processes are concerned with addressing common causes of
process variation and changing the process (that is, shifting the mean of the
process performance) to improve process performance (while maintaining
statistical predictability) to achieve the established quantitative
process-improvement objectives.
