The Capability Maturity Model
- To frame our discussion, consider:
-
What is CMM?
What is the structure of the CMM?
How is CMM used in support of process improvement?
Why is CMM used in support of process improvement?
The application of process management and quality improvement concepts to software development and maintenance.
A guide for evolving toward a culture of engineering excellence.
A model for organizational improvement.
The underlying structure for reliable and consistent software process assessments and software capability evaluations.
The CMM should support:
- setting goals for senior management
- identifying priorities for process improvement
- identifying process capability of organizations
- predicting future process performance of projects
- industry-wide comparisons of the state of the practice
| Process Performance |
The actual results achieved by following a software process. |
| Process Capability |
The range of expected results that can be achieved by following a software process.
|
| Process Maturity |
The extent to which a specific process is explicitly defined, managed, measured,
controlled, and effective. |
| Model | Comments |
|---|
 |
The performance of a process is described as a probability distribution. What this diagram shows
is that the majority
of projects do not (can not) meet the target resources. The second feature of this diagram is the
variability (variance) of the distribution. Since the distribution is somewhat flat, it indicates the
variance (and standard deviation) is large. Hence, projects described by this not only do not hit
the mark but the results vary considerably. |
 |
In this diagram we see that projects are now capable of meeting the target goals for resources
use. We now have increased confidence that the process
is capable of delivering a product on time and within budget. The variability is still too high
but meeting project goals has improved. |
 |
Having conquered the process demons in the last model, we now see how with the process under greater
control we begin to reduce the variability and the resource utilization. |
 |
|
A maturity level is a well-defined evolutionary plateau toward achieving a mature software process. Each maturity
level provides a layer in the foundation for continuous process improvement. Each level comprises a set of process
goals that, when satisfied, stabilize an important component of the software process. Achieving each level of the
maturity framework establishes a different component in the software process, resulting in an increase in the process
capability of the organization.
Improvement is not a revolutionary activity. Improvement is achieved through many small actions. CMM is a framework
for these small steps. By conceptualizing it in this manner it becomes clearer that improvement is incremental
transitioning from one level to another implies the foundation required from the prior level is in place. The layered
structure of the CMM implies moving from one level to another where the upper layer depends on the existence of
the practices defined in the lower level.
1) Initial The software process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort.
2) Repeatable Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications.
3) Defined The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization's standard software process for developing and maintaining software.
4) Managed Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled.
5) Optimizing Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies.
CMM is a descriptive model that provides details on essential operational activities at a particular maturity level.
CMM is a normative model in it describes practices that
characterize the normal types of behavior expected in a software organization. The intent is that the CMM is at a sufficient level of abstraction that it does not unduly
constrain how the software process is implemented by an organization.
The CMM is not prescriptive. it does not tell an organization how to improve. The CMM describes an organization at
each maturity level without prescribing the specific means for getting there.
| Level | View |
|---|
 |
The software process is a black box.
Visibility of the project's processes is not possible. |
 |
The customer requirements and work products are controlled, and basic project management practices have
been established. |
 |
The tasks that define the internal structure of the boxes is visible. The
internal structure represents the way the standard software process is applied to projects. |
 |
The defined software processes are instrumented and controlled quantitatively. Managers are able to measure
progress and problems. |
 |
New and improved ways of building the software are continually tried, in a controlled manner, to improve
productivity and quality. Disciplined change is a way of life as inefficient or defect-prone activities are identified and
replaced or revised. |
- Maturity Levels
Maturity levels are evolutionary plateaus. Each level characterizes a process capability.
- Key Process Areas
Maturity levels are described by key process areas that indicate areas of
potential improvement. These areas help identify areas that must be addressed to
achieve a particular maturity level. Key process areas identify a cluster of related activities that,
when performed collectively, achieve a set of goals considered important for enhancing process capability.
There are both project and organizational responsibilities in all key process areas.
- Common Features
Key process areas have attributes indicating whether particular activities
are effective as well as whether they have become part of the infrastructure.
Common features are:
- commitment to perform
Typical subfeatures include:
- policies
- senior management sponsorship
- responsibility
- ability to perform
Typical subfeatures include:
- resources
- organization structure
- delegation
- training
- orientation
- activities performed
Typical subfeatures include:
- establishing plans and procedures
- performing the work
- tracking it
- taking corrective actions as necessary
- measurement and analysis
Typically includes examples of the
measurements that could be taken to
determine the status and effectiveness of the
Activities Performed
- verifying implementation
Typical subfeatures include reviews and
audits by:
- senior management
- project management
- software quality assurance
- Key Practices
Key practices provide a more detailed view of specific activities, policies,
procedures for key process areas.
| Level | | |
| 1 | initial
| |
| 2 | repeatable | software projects can be repeatably delivered on schedule with reasonable quality. Project management is in place, there is a disciplined process.
Software configuration management, SQA, Project tracking and oversight, Project Planning |
| 3 | defined | the process is standardized, documented and followed. SEs are trained in process activities and SQA activities. There is a consistent process.
Peer reviews, intergroup coordination, Training Program, Software process definition. |
| 4 | managed | the process collects and uses metrics to understand process/product. There is a predictable process.
Quality management, quantitative Process management |
| 5 | optimized | establish mechanisms to plan and implement change.There is a continuously improving process.
Process change management, technology change management, Defect prevention |
A reasonable software process is:
- practiced
- documented
- enforced
- trained
- measured
- able to improve
A well-defined process can be characterized
in terms of:
- readiness criteria
- inputs
- standards and procedures for performing
the work
- verification mechanisms (e.g., peer
reviews)
- outputs
- completion criteria
How is CMM used in support of process improvement?
- Software process assessments are used to determine the state of an organization's current software process, to determine the high-priority software process-related issues facing an organization, and to obtain the organizational support for software process improvement.
- Software capability evaluations are used to identify contractors who are qualified to perform the software work or to monitor the state of the software process used on an existing software effort.
Software process assessments and software capability evaluations differ in motivation, objective, outcome, and ownership of the results. These factors lead to substantive differences in the dynamics of interviews, the scope of inquiry, the information gathered, and the formulation of the outcome. The assessment and evaluation methods are quite different when the detailed procedures employed are examined. Assessment training does not prepare a team to perform evaluations, or vice versa.
Software process assessments are performed in an open, collaborative environment. Their success depends on a commitment from both management and the professional staff to improve the organization. The objective is to surface problems and help managers and engineers improve their organization. While the questionnaire is valuable in focusing the assessment team on maturity level issues, the emphasis is on structured and unstructured interviews as tools for understanding the organization's software process. Aside from identifying the software process issues facing the organization, the buy-in to improvement, the organization-wide focus on process, and the motivation and enthusiasm in executing an action plan are the most valuable outcomes of an assessment.
Software capability evaluations, on the other hand, are performed in a more audit-oriented environment. The objective is tied to monetary considerations, since the team's recommendations will help select contractors or set award fees. The emphasis is on a documented audit trail that reveals the software process actually implemented by the organization.
Why is CMM used in support of process improvement?
Go To Lecture
[Outline] [Overview]
Go To
[311 Course Outline] [CIS Department Page]
Paulk, M. C., B. Curtis, M. B. Chrissis, & C. V. Weber (1993) The Capability Maturity Model For Software, Version
1.1. Software Engineering Institute, Carnegie Mellon University, CMU/SEI-93-TR-24.
SEI (1993) The Capability Maturity Model: A Tutorial.