Columns

Streamlining CMM

• By Charles H. Trepper
• March 1, 2000

Since 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:

1. 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.

2. 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.

3. 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.

4. 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.

5. 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).

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.

Who benefits?

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].