CMM – an Introduction

Is CMM just another buzz word or is there something more to it.

Capability Maturity Model (CMM), has found it’s way from Carnegie Melon University’s
(CMU) software engineering Institute (SEI) to major Software developers all over the
world. Some consider it as an answer to Software Industry’s chaotic problems, and some
consider it just another exhaustive framework that requires too much to do and too little
to show for it. This article is not intended to be a comprehensive introduction to CMM,
the interested readers should read official CMM documentation available from SEI’s web
site to get a comprehensive discussion of CMM. This article is intended to show that
CMM is not a framework that advocates magical and revolutionary new ideas, but it is in
fact a tailored compilation of the best practices in Software engineering.

The intention of this article is to introduce CMM as a logical and obvious evolution of the
Software Engineering practices. The article does not require any prior knowledge of
CMM; however it is assumed that the reader is cognizant of issues involved in Software
development.

Before we move any further, we must define one term that is central to almost every
industry – Process. This term has also found its rightful place in Software Industry. It was
Deming who popularized this term. Japanese have managed a miraculous industrial
revolution based on the simple concept of a Process. “ Process is a mean by which
people, procedures, methods, equipment, and tools are integrated to produce a desired
end result” [quoted from CMM for Software, version 2B]. Humphrey in his Book
Introduction to the PSP, (1997) defines a process in Software Development context as “
Process defines a way to do a project, Projects typically produces a product, and Product
is something you produce for a co-worker, an employer, or a customer.”.

Now that we know what Process means, how can we use this knowledge to achieve
success. The answer lies in the following three-step strategy:

1- Analyze the current process by which your organization executes its projects,

2- Figure out the strengths and weaknesses of the current process,

3- Improve upon your Process’s strengths and remove its weaknesses.

Bingo you have a simple recipe for success !

The above seemingly simple steps, have baffled the Software Industry for years.
Different software developers have adopted different techniques to implement the three-
step recipe, with varying degree of success.
Having noted down the above “three-step approach to success”, we would now
concentrate on mastering each of the above three steps.

Let us start by considering the normal course of events that follow when a software
project is undertaken. We will only outline the steps, without going into the details of
each; since our purpose is to highlight the most common events and not there particular
details, as they may vary depending on the contract and the nature of the project.

Step-1 – The Requirements:

The client gives a set of Requirements of the product to the contracting company
(referred to as “the Company”). The first step is to discuss these requirements with the
client. The discussion will focus on removing any ambiguity, conflict, or any other issues
related to the product in question. The outcome of this discussion will ideally be a “Well-
defined set of functionalities that the product will achieve”.

Step-2 – The Planning (cost, time estimates):

The next step is to plan the project. Given the required set of functionalities the million
dollar question is “How much time and Dollars will the Company require to complete the
project?”. Based on these estimates, resources (both human and non-human) will be
allocated to the project. Various milestones will be defined, to facilitate project
monitoring. Plans will also be made to outsource any part of the project, if deemed
necessary.

Step-3 – On with the Project:

Assuming that the plans have been made, team formed, and estimates in place now the
Company is ready to start actual work on the project.

Step-4 – How is the Project Doing (continuous monitoring):

Once the project is under way, the project will continuously monitor their progress
against the Plans and milestones made in Step-2.

Step-5 – How are the sub-contractors Doing:

In Step-2, if the Company decided to outsource or sub-contract a part of the project, then
the sub-contractors will also be managed and their progress monitored closely. This will
ensure that no delays occur due to lapses caused by the sub-contractor.

Step-6 Software Quality Assurance:

In Step-4 the Company monitored the project for any cost overrun, or any schedule
slippage; but that’s not all that need to be monitored. An in-budget, with-in-time project
may still have serious problems. In Step-4 the Company ensured that the project is going
according to the schedule, and is with in budget, but is it doing what it is suppose to do?.
That is, are all the tasks completed according to the Company’s standards and according
to, the Requirements agreed in Step-1?. In Step-6, the Company will ensure that no work
is done in violation of any standard and any system Requirements.

Step-7 Handling the inevitable changes:

A software project, usually involves different teams working on different aspects of the
project, e.g. one team may be coding a module, while another may be working on writing
the users manual. Although Teams work on a certain aspect of the project, but the project
is eventually going to be delivered as a single product. It’s evident that all the teams
MUST co-ordinate their work, to produce a well-integrated final product. In Step-2, the
plan was well laid, and all the involved personnel were assigned their share of work. But
some changes will almost always have to be made. These changes may affect more than
one team. Therefore it is necessary for the Company to ensure that all the bits-and-pieces
of the project remain well coordinated. The Company must determine if a change made to
one piece of the product also necessitate a change to one or more other pieces, and if it
does then those changes must be made accordingly. In Software terms this is called
“Configuration Management”.

One can come up with many other activities that a software company would normally
follow. But we would stop here and will focus only on the above-mentioned activities.

It is obvious that the above mentioned activities are performed by almost all the software
companies; then what is it that makes a company Microsoft and another company go
bellies up ?.

The answer is simple: Not all the companies observe the above steps with the same vigor.
These steps are all very simple to understand but extremely difficult to execute
effectively.

The purpose of the above discussion was to enable the readers to appreciate the need for a
guideline, or a road map that software companies can follow to produce quality software,
with in budget and with in time. One such roadmap is called Capability Maturity Model
(CMM).

I shall discuss CMM in the easiest way I could. But the readers must realize that CMM is
a tricky model to fully understand and is even trickiest to successfully implement.

CAPABILITY MATURITY MODEL (CMM)SM

Capability Maturity Model, as already mentioned, is the outcome of decades of research
and study of successful and unsuccessful projects. The major philosophy of CMM is very
similar to life itself. When a child is born it is at a very "initial" level of maturity. The
child grows up, learns and attains a higher level of maturity. This keeps on going until
he/she becomes a fully mature adult; and even after that the learning goes on.

According to CMM, a software company also goes (or should go) through similar
maturity evolutions. The CMM maturity levels are discussed later.

Readers should notice that CMM is NOT a software development life cycle model.
Instead it is a strategy for improving the software process irrespective of the actual life-
cycle model used [Schach 1996].

Lets dive right into the intricacies of CMM.

COMPONENTS OF CMM

Given below is a brief explanation of various components of CMM. This explanation has
been extracted from SEI's official documents. This section is followed by more detailed
explanation of each component.

Maturity levels

A maturity level is a well-defined evolutionary plateau

toward achieving a mature software process. The five
maturity levels provide the top-level structure of the CMM.

Process capability

Software process capability describes the range of expected

results that can be achieved by following a software
process. The software process capability of an organization
provides one means of predicting the most likely outcomes
to be expected from the next software project the
organization undertakes.

Key process areas

Each maturity level is composed of key process areas. Each

key process area identifies a cluster of related activities
that, when performed collectively, achieve a set of goals
 considered important for establishing process capability at
that maturity level. The key process areas have been
defined to reside at a single maturity level. For example,
one of the key process areas for Level 2 is Software Project
Planning.

Goals

The goals summarize the key practices of a key process

area and can be used to determine whether an organization
or project has effectively implemented the key process area.
The goals signify the scope, boundaries, and intent of each
key process area. An example of a goal from the Software
Project Planning key process area is "Software estimates
are documented for use in planning and tracking the
software project." See "Capability Maturity Model for
Software, Version 1.1" [Paulk93a] and Section 4.5,
Applying Professional Judgment, of this document for
more information on interpreting the goals.

Common features

The key practices are divided among five Common

Features sections: Commitment to Perform, Ability to
Perform, Activities Performed, Measurement and Analysis,
and Verifying Implementation. The common features are
attributes that indicate whether the implementation and
institutionalization of a key process area is effective,
repeatable, and lasting.The Activities Performed common
feature describes implementation activities. The other four
common features describe the institutionalization factors,
which make a process part of the organizational culture.

Key practices

Each key process area is described in terms of key practices

that, when implemented, help to satisfy the goals of that
key process area. The key practices describe the
infrastructure and activities that contribute most to the
effective implementation and institutionalization of the key
process area. For example, one of the practices from the
Software Project Planning key process area is "The
project's software development plan is developed according
to a documented procedure."
As mentioned earlier the above description of various components of CMM has been
taken out of SEI's official documents. The readers need not worry if they don't understand
some or all of what has been written above. I will explain each component in details in
the sections below.

CMM FRAMEWORK

MATURITY LEVELS

CMM defines five levels of maturity:

Level 1 : Initial Level

This is the lowest of the maturity levels; you may consider

it as the immature level. At this level the software process is
not documented and is not fixed. Everything in these
companies is done on an ad-hoc basis. The projects are
usually late, over budgeted and have quality issues. This
does not mean that a company at this level can not do
successful projects. As a matter of fact the author himself
works for a company that is somewhere between Level 1
and Level 2 and despite this it has a very impressive track
record for producing quality software, with in budget and
with in time. Companies at Level 1 do manage to produce
good software mainly because of their personnel immense
competency. These companies are characterized by heroes
- individuals with good programming, communications and
peoples skills. It is for these individual heroes that the
companies at Level 1 manage to complete successful
projects. Most of the companies around the world are at
Level 1. These companies make their decisions on the spur
of the moment, rather than anticipating problems and fixing
them before they occur. Software developers in these
companies are usually over-worked, over-burdened and
spend major portion of their time in re-working, or fixing
bugs. The success of a project depend totally on the team
working on the project and on the project manager's
abilities rather than on the company's processes. As the
team changes or some key individuals of the team leave -
the project usually fall flat on its face.
Level 2: Repeatable Level

At this level basic software project management practices

are in place. A project planning, monitoring and
measurements are properly done according to certain well-
defined processes. Typical measurements include tracking
of costs and schedule. The results of these measurements
are used in future projects to make a better and realistic
project plan. Projects have a stronger chance of being
successful, and if unsuccessful the mistakes are recorded
and thus are avoided in the future projects. The key point is
that without measurements it is impossible to foresee and
detect the problems before they get out of hand.

Level 3: Defined Level

At this level the process of software development is fully

documented. Both the managerial and technical aspects are
fully defined and continued efforts are made to better the
process. At this level CASE tools are used for development
of software. If a Level 1company tries to follow activities
involved in Level 3, the result usually are disastrous. This
is because in CMM a preceding level lays the ground work
for the next level. In order to be able to achieve Level 3,
one must first achieve Level 2.

An example of a documented process could be "the process

for identifying software defects/bugs". This process may be
documented by using checklist for identification of
common defects; the check list may contain entries like
"All variables initialized, all pointers initialized, all pointers
deleted, all exceptions caught" etc. The process of defect
identification may also include the total count of defects,
and the categories of each software defects. A company
may use any method to documents its processes. CMM lays
no compulsion on how a process should be documented.
The only compulsion is that the process should be
documented in such a manner that a new recruit to the
company can easily do his/her job by reading the
documentation.

Level 4: Managed Level

Level 3, provides a way to document the processes; Level 4

allows that documentation to be used in a meaningful
manner. Level 4, involves software matrices, and statistical
 quality control techniques. In Level 3, I gave an example of
documenting a Software Defects/bugs identification
process. Imagine that the total count of defects per
thousand lines of code turn out to be 500. Level 4 would
have activities aimed at identifying the root cause(s) of
these bugs, and would set goals to decrease the defect
number to a reasonable level.

Level 5: Optimizing Level

The software environment changes all the time. Technology

changes and so do the techniques. Level 5 deals with the
ongoing changes and with ways to improve the current
processes to meet the changing environment. In essence
Level 5 provides a positive feedback loop. Level 5 is about
continuous improvement. A company at Level 5 uses
statistical methods to incorporate future changes and to be
receptive to ideas and technologies for continuous growth.
The above discussion would make sense only to the readers who already know about
CMM. For others the above lines just add to confusion. Once again I remind the readers
that "patience has its virtue", CMM is a vast subject, and a few lines can not even begin
to explain it. The rest of the article further break the above levels down, with a hope that
this would help the readers in understanding CMM. So if the above discussion has left
you confused and has not added much to your understanding of CMM then keep reading
on, as the best is yet to come :)

KEY PROCESS AREAS (KPAs)

Each level (Level 1,2, 3, 4, 5) have been divided into certain KPAs. For a company to
achieve a certain maturity level it must fulfill all the KPAs of the desired maturity level.
Since every company is at least at Level 1, there is no Key Process Areas for Level 1 -
meaning that a Software Company does not need to do anything to be at level 1. You may
think of Key Process Areas as "TO DOs of a maturity level" or a Task list that must be
performed. A Key Process Area contains a group of common activities that a company
must perform to fully address that Key process Area. Given below is the list of KPAs for
each Maturity Level.

Level 1 - Initial

Level 2 - Repeatable

• Requirements Management
• Software Project Planning
• Software Project Tracking & Oversight
• Software Subcontract Management
• Software Quality Assurance
• Software Configuration Management

Level 3 - Defined

• Organizational Process Focus

• Organizational Process Definition
• Training Program
• Integrated Software Management
• Software Product Engineering
• Intergroup Coordination
• Peer Reviews

Level 4 - Managed

• Quantitative Process Management

• Software Quality Management

Level 5 - Optimizing

• Defect Prevention
• Technology Change Management
• Process Change Management
There are 18 KPAs in CMM. So what should the reader make out of the above KPAs ?. A
detailed book on CMM would explain what each KPA means. But with in the space and
scope restriction of this article I could not delve deep into each KPA. Just by reading the
KPAs, readers would realize that some of the KPAs would immediately make sense while
others would be difficult to understand. For example the "Peer Reviews" KPA of Level 3
is easily understood and so are most of the KPAs of Level 2. However KPAs like
"Organizational Process focus, Process definition, Integrated Software Management etc."
are difficult to understand without some explanation. There is a reason why some of the
KPAs are easily understood while others take considerable effort. Those KPAs that are
usually done by many companies (namely the KAPs of Level-2) are the ones that are
easily understood - while the other KPAs alienate us - not because they are some abstract
terms being churned out in the labs of CMU, but simply because most of the companies
in the world do not follow the activities encompassed by these KPAs. And that is why
CMM is such a wonderful roadmap to follow. It tells us exactly what successful, big
software companies have been doing to achieve success.

Unfortunately the scope of this article restrict me from explaining the above KPAs in
detail.

What CMM tells us by virtue of the above KPAs is: For a company to level with the best
it MUST address all the 18 KPAs. Failing to address one or more of the above KPAs
would result in a relatively immature company - hence resulting in a decreased
productivity and increased risk.

GOALS

Looking at the KPAs an obvious question comes to mind. How can a company be sure
that it has successfully addressed a KPA ?. CMM assigns GOALS to each KPA. In order
to successfully address a KPA a company must achieve ALL the goals associated with
that KPA. Given below is the complete list of GOALS associated to each of the above 18
KPAs.

Level 2 - Repeatable

• Requirements Management
o GOAL 1:

System requirements allocated to software

are controlled to establish a baseline for
software engineering and management use.

o GOAL 2:

Software plans, products, and

activities are kept consistent
with the system requirements
allocated to software.

• Software Project Planning

o GOAL 1:

Software estimates are documented for use

in planning and tracking the software
project.

•
o GOAL 2:
 Software project activities and
commitments are planned and documented.

o GOAL 3:

Affected groups and individuals agree to

their commitments related to the software
project.

• Software Project Tracking & Oversight

o GOAL 1:

Actual results and performances are tracked

against the software plans.

o GOAL 2:

Corrective actions are taken and managed to

closure when actual results and performance
deviate significantly from the software
plans.

o GOAL 3:

Changes to software commitments are

agreed to by the affected groups and
individuals.

• Software Subcontract Management

o GOAL 1:

The prime contractor selects qualified

software subcontractors.

o GOAL 2:

The prime contractor and the software

subcontractor agree to their commitments to
each other.
 o GOAL 3:

The prime contractor and the software

subcontractor maintain ongoing
communications.

o GOAL 4:

The prime contractor tracks the software

subcontractor's actual results and
performance against its commitments.

• Software Quality Assurance

o GOAL 1:

Software quality assurance activities are

planned.

o GOAL 2:

Adherence of software products and

activities to the applicable standards,
procedures, and requirements is verified
objectively.

o GOAL 3:

Affected groups and individuals are

informed of software quality assurance
activities and results.

o GOAL 4:

Noncompliance issues that cannot be

resolved within the software project are
addressed by senior management.

•
• Software Configuration Management
o GOAL 1:

Software configuration management

activities are planned.

o GOAL 2:
 Selected software work products are
identified, controlled, and available.

o GOAL 3:

Changes to identified software work

products are controlled.

o GOAL 4:

Affected groups and individuals are

informed of the status and content of
software baselines.

Level 3 - Defined

• Organizational Process Focus

o GOAL 1:
o GOAL 2:
• Organizational Process Definition
o GOAL 1:
o GOAL 2:
• Training Program
o GOAL 1:
o GOAL 2:
• Integrated Software Management
o GOAL 1:
o GOAL 2:
• Software Product Engineering
o GOAL 1:
o GOAL 2:
• Intergroup Coordination
o GOAL 1:
o GOAL 2:
• Peer Reviews
o GOAL 1:
o GOAL 2:

Level 4 - Managed

• Quantitative Process Management

o GOAL 1:
 o GOAL 2:
• Software Quality Management
o GOAL 1:
o GOAL 2:

Level 5 - Optimizing

• Defect Prevention
o GOAL 1:
o GOAL 2:
• Technology Change Management
o GOAL 1:
o GOAL 2:
• Process Change Management
o GOAL 1:
o GOAL 2:

• Common Features
• Key Practices

The interrelationship of the terms discussed above can be best shown by the following
diagram:
 The Structure of Capability Maturity Model

CMM - SUCCESS STORIES

Many companies have successfully implemented CMM, and have

reported considerable improvement in almost all the aspects of
software life cycle. SEI Document [17] reports a few of these
organization that adopted CMM : Bull HN, GTE Government Systems,
Hewlett Packard, Hughes Aircraft Co., Loral Federal Systems (formerly
IBM Federal Systems Company), Lockheed Sanders, Motorola,
Northrop,Schlumberger,Siemens Stromberg-Carlson, Texas
Instruments, United States Air Force Oklahoma City Air Logistics Center
, United States Navy Fleet Combat Direction Systems Support Activity.
[18] gives a detail of CMM Level-4, and Level-5 organizations.

The CMM certified organizations have reported improvement in almost

every sphere of their work.

ISO, TickIt and CMM

ISO

The term ISO 9000 refers to a set of quality management standards.

ISO 9000 currently includes three quality standards: ISO 9000:2000, ISO 9001:2000,
and ISO 9004:2000. In the past, ISO had three standards: ISO 9001:1994,
ISO 9002:1994, and ISO 9003:1994. Now there's only one
standard: ISO 9001:2000! ISO 9002 and ISO 9003 have been
dropped. ISO 9001:2000 presents requirements, while ISO 9000:2000 and ISO
9004:2000 present guidelines. All of these are process standards (not product standards).
ISO first published its quality standards in 1987, revised them in 1994,
and then republished an updated version in 2000. These new
standards are referred to as the "ISO 9000 2000 Standards". ISO's
purpose is to facilitate international trade by providing a single set of
standards that people everywhere would recognize and respect. The
ISO 9000 2000 Standards apply to all kinds of organizations in all kinds
of areas. ISO standards are too generic to be successfully implemented to software
industry. A special version of ISO for Software Industry also exists, its called ISO 9000-3
[13]. Many people get confused between ISO 9001 and ISO 9000-3.The following
statement best explain the difference between ISO 9001 and ISO 9000-3 "ISO
prepared the 9000-3:1997 quality guidelines to help organizations to
apply the ISO 9001:1994 requirements to computer software.
Use ISO 9000-3 if you develop, supply, install, and maintain
computer software. ISO 9000-3:1997 is really an expanded version of
the old ISO 9001:1994 standard. ISO has simply copied the old text
from ISO 9001 and pasted it into the new version of ISO 9000-3, and
then added some new text that refers only to software."[13]. The ISO
9000 standards are being improved/modified continuously. The next
ISO standard review will abolish ISO 9000-3 and would make this a part
of ISO 9001 - this would reduce the above mentioned confusion.

TickIT

TickIT initiative came about as a result of a report commissioned by the British

Department of Trade and Industry (DTI) to review the state of software quality and
development in industry. This report showed that there was a reluctance on the part of the
software producers to adopt ISO9000 as it was pitched at a high level of generality, the
terminology was difficult to interpret for software and the guidance documentation was
confusing. As a result of the findings of this report, the British Government decided to
appoint the British Computer Society (BCS) to lead an initiative called TickIT. The aim
of this initiative was to create a detailed method for organization, procedures and rules for
a Software Sector Certification Scheme (SSCS) which would cover the assessment and
certification of an organization's software quality management scheme to
ISO9000/BS5750. A successful audit by a TickIT-accredited certification body results in
the award of a certificate of compliance to ISO 9001:2000, endorsed with a TickIT
logo[16]. One may consider TickIT as a British guide to using ISO 9001 and ISO 9000-
3[15]

So how does ISO/TickIT compare to CMM. Both these standards have a

common concern for quality. While ISO identifies the minimal
requirements for a quality system, the CMM underlies the need for a
continuous improvement[14]. The ISO members maintain that if you
read ISO 9001 in depth then you would realize that it does address the
continuous process improvement. e.g. Corrective Action clause in ISO
may be considered to address continuous improvement. Both ISO and
CMM have been accepted world wide. Some organizations, e.g. NASA,
have adopted ISO, while other organizations e.g. Department Of
Defense, have opted for CMM.

Mark C. Paulk has given an insightful view of comparison between ISO 9001 and
CMM[15].

Given below is a diagram taken from Paulk's comparison of ISO 9001,

ISO 9000-3 and CMM. The dark shading indicates practices that are
directly addressed by ISO 9001 or ISO 9000-3; the light shading
indicates practices that may be addressed depending on an
interpretation of ISO 9001; and the unshaded areas indicate practices
not addressed by ISO 9001. Key process areas may be, therefore,
partially or fully satisfied, satisfied under some interpretations, or not
satisfied. The size of the bar indicates the percentage of key practices
within the key process area that are addressed in either ISO 9001 or
ISO 9000-3
… to be Continued

References:

[1] STEPHEN R. SCHACH Classical and Object-Oriented Software Engineering Mcgraw-Hill

Companies, Inc. USA, 1996
[2] KIM CAPUTO CMMSM Implementation Guide
[3] WATTS S. HUMPHREY Managing the Software Process
[4] JALOTE CMMSM in Practise
[5] MARK C. PAULK, CHARLES V. WEBER, SUZANNE M. GARCIA, MERY BETH CHRISSIS, MARILYN BUSH
SEI's Capability Maturity ModelSM ver 1.1
[6] PAULK Key Practices of the Capability Maturity ModelSM , version 1.1
[7] STEVE MASTERS, CAROL BOTHWELL CMMSM Appraisal framework , version 1.1
[8] DONNA L. JOHNSON, JUDITH G. BROADMAN Tailoring the CMMSM for Small Businesses,
Small Organizations, and Small Projects
[9] DONNA L. JOHNSON, JUDITH G. BROADMAN Applying CMMSM Project Planning Practices to
Diverse Environments
[10] BILL PITTERMAN Telcordia Technologies: The Journey to High Maturity
[11] GARGI KEENI The Evolution of Quality Processes at Tata Consultancy Services
[12] DAVID N. CARD Sorting out Six Sigma and the CMM SM
[13] ISO in Simple English by . PRAXIOM RESEARCH GROUP LIMITED
[15] MARK C. PAULK How ISO 9001 compares with the CMM
[16] TickIT official web-site
[17] HERBSLEB, CARLETON, ROZUM, SIEGEL, ZUBROW ARGI KEENI Benefits of CMM-Based
Software Process Improvement (SEI, 1993)
[18] KASHIF MANZOOR The challenge of implementing CMM in Pakistan software industry
SM
CMM and Capability Maturity Model are service marks of Carnegie Mellon University

home