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
Level 5 - Optimizing
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
-
GOAL 1:
System requirements allocated to software are controlled to
establish a baseline for software
engineering and management use.
-
GOAL 2:
Software plans, products, and activities are kept consistent with
the system requirements allocated to
software.
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
-
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
9000refers 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
<原文地址：http://homepages.com.pk/kashman/CMMIntro.htm >