its inception in 1991, the Software Engineering Institute's Capability
Maturity Model (SEI/CMM) has been used as a benchmark for improving the
development and implementation of software solutions. The SEI/CMM has
five maturity levels, each of which has a set of specific goals and objectives
that provide organizations with a kind of "to-do list" that helps them
improve their software development process. Each of the five levels builds
on the accomplishments of the one before it to provide firms with a structured
approach they can use to create a continuous improvement learning environment.
The five maturity levels of the CMM are as follows:
A brief history
- Initial - At this level, the software development process is
typically ad hoc and occasionally even chaotic, with no structured methodology
in place. This is where many firms are today.
- Repeatable - Organizations at this level typically have some
basic project management processes in place to track cost, schedule
and software functionality. Some organizations achieved Level 2 last
year because of their Y2K projects.
- Defined - Firms at Level 3 usually have some type of structured
methodology for software management and engineering activities. At this
level the process is documented, standardized and integrated into standard
software processes for the firm.
- Managed - At this level, organizations collect detailed measures
of the software process and product quality, but may not be feeding
those results back into the software development process.
- Optimizing - At this "top-tier" level, organizations feed data
about metrics such as development times, costs and lessons learned back
into the software development process. Using the data from the process
enables continuous process improvement.
In 1982, a joint task force was set up by the U.S. Department of Defense
(DoD) to review its software problems. This task force eventually decided
that a standards organization was needed … and thus, the Software Engineering
Institute (SEI) was born.
In 1984, Carnegie Mellon University, Pittsburgh, won a competitive bid
process to host the newly created SEI. The SEI developed the Software
Process Maturity Model for DoD and industry, which eventually led to the
creation of the CMM in 1991.
Over time, the SEI received demands from various types of organizations
to create maturity models for other types of activities, such as acquiring
software packages and managing people. This led to the creation of several
other types of CMMs, including:
- Capability Maturity Model for Software (SW-CMM)
- People Capability Maturity Model (P-CMM)
- Software Acquisition Capabil- ity Maturity Model (SA-CMM)
- Systems Engineering Capabil- ity Maturity Model (SE-CMM)
- Integrated Product Develop- ment Capability Maturity Model (IPD-CMM).
These models evolved individually over time, with input from many organizations.
Overlaps and significant differences between the models, however, had some
organizations confused as to which CMM to use in their various projects.
In addition, when individual models were used in combination, they sometimes
provided inconsistent or even conflicting guidance.
This confusion and model proliferation led to the SEI's initiation of
the CMM Integration (CMMI) project. The CMMI project will integrate the
Capability Maturity Model for Software (SW-CMM), the Systems Engineering
Capability Maturity Model (SE-CMM) and the Integrated Product Development
Capability Maturity Model (IPD-CMM). The CMMI project is designed to eliminate
redundancies and conflicts, and to provide organizations with a simple,
clear, concise and cohesive set of steps to improve the quality of software
products and processes — almost a "Holy Grail" of software development.
If the CMMI project results in a set of easy-to-follow best practices,
software developers should beat a path to the SEI's door. A streamlined
model with reduced complexity should improve the efficiency of the software
development process, as well as increase the return on investment for
both process management efforts and the software products themselves.
Measurement is a key factor in managing and improving the software development
process. The CMMI project should simplify and consolidate software measurement
requirements and processes for multiple models. This means that organizations
will have a much better idea of what to measure, how to measure it, and
how to continuously feed measurements back into the software development
process to achieve continuous improvement. By combining deliverables from
the three models, the SEI reduces the potential for confusion and makes
it easier for organizations to determine which deliverables and tasks
are needed to create a continuous improvement learning environment.
Process management and methodology groups, and organizations in general,
should find the consolidated CMMI model beneficial for several reasons.
The process management group's work and the tasks necessary to accomplish
it will be clarified. The consolidated model should also reduce the amount
of time organizations need to move up each step of the CMM ladder, which
ultimately improves efficiency. Process management groups will be able
to communicate what they need to accomplish to IT and business management
much more easily. This will give the organization a better understanding
of what the process management group does, and what needs to be done to
improve software development processes. When the organization better understands
why it must improve its software development processes, it is more likely
to dedicate dollars to those efforts.
Software companies will also benefit. The consolidated CMMI model should
help software companies and other software engineering organizations get
"better" faster. Customers often become aggravated with software companies
because of significant bugs that could have been prevented. The new CMMI
model will provide software companies with a "no excuses" rationale for
implementing software development best practices. Improved software development
processes mean fewer bugs in software, and higher customer satisfaction.
Software companies that can prove higher quality and provide good customer
references will be more profitable over the long haul.
One possible downside to the consolidation of the various models is
the potential loss of the specific characteristics in each model that
made it useful. The SEI must avoid deleting those parts of the original
models that were the reason for their creation. The SEI's public review
process should help prevent this problem, but very few organizations typically
participate in these review processes. It is possible that when the model
is complete, organizations will find gaps in the CMMI consolidated model
that were created by the consolidation. Organizations that have an interest
in, or are currently using, any of the CMMs should keep track of the effort
through the SEI's Web site (www.sei.cmu.edu).
The SEI appears to be following its own advice, and is continuously
improving the CMM. Reducing conflict and redundancy between models will
make the CMM more attractive to organizations that want to improve their
software development processes. Whether or not the CMMI project attracts
more companies to the CMM process remains to be seen. However, as more
organizations discover the benefits of the streamlined model, they may
be more likely to try to improve their own software products and processes,
and, ultimately, their bottom line.
Charles Trepper is a Minneapolis-based consultant and author of the
upcoming book Training for Software Rollouts. Mr. Trepper can be reached
at [email protected].
Charles H. Trepper is CEO of The Trepper Group, a Minneapolis-based consultancy.