Capability Maturity

One of the more interesting developments in software engineering has been that of the Capability Maturity Model (CMM). The CMM was formulated by the Software Engineering Institute (SEI) at Carnegie Mellon University, with the assistance of subcontractors. Work on the CMM was sponsored by the DoD and has had an enormous impact on the thinking, as well as the behavior, of a large number of industrial companies. It has also found its way into the programs of civil government agencies, for example, the Federal Aviation Administration (FAA).

Notions of the software CMM are generally attributed to Watts Humphrey [10.12] and his colleagues [10.13] at the SEI. The structure of the CMM is based on a five-level characterization of software maturity, namely:

1. An initial level

2. A repeatable level

3. A defined level

4. A managed level

5. An optimizing level

Initial Level. At this level, software development processes are mostly ad hoc, and therefore can be chaotic at times. Individual as well as group processes are generally not defined or well organized, and individual efforts and capabilities have a strong influence on the success, or lack of it, on a software development project.

Repeatable Level. Some processes are established at this level, mostly dealing with the tracking of schedule, cost, and software functionality. Processes established at the initial level can be repeated to the extent that they led to success. A repeatable level can be achieved by adopting similar earlier applications, but generally not with new applications.

Defined Level. At the defined level, the software processes for the team effort are documented, standardized, and integrated for the organization. That is, all projects within an organization follow standard software processes that are designed to be effective in the various domains of software engineering.

Managed Level. A key element of this level is measuring the software process as well as the results (products) of that process. Through such measurement, it is then possible to determine process and product efficacy and exercise control through changes when both are not yielding appropriate results.

Optimizing Level. At the optimizing level, continuous process improvement is achieved through a well-developed system of measurement, feedback, and change. New ideas and technologies for improvement are routinely explored with the objective of optimizing all software development processes and products.

Given these basic concepts, the next obvious question is: How is one to determine, or measure, the capability maturity level of an organization? Considerable attention has been focused on this matter, bringing the CMM from a conceptual framework to a real-world change mechanism and agent. Implementation is structured into two parts, namely:

1. A Software Process Assessment (SPA)

2. A Software Capability Evaluation (SCE)

For the SPA, the focus is an individual organization and how it can (a) identify the status of its software process, and (b) establish priorities with respect to improving that process. Thus, the SPA is an internal mechanism to help an organization determine where it is in terms of capability maturity and point the direction toward enhancing that level of maturity. The SCE, on the other hand, is used by agencies that are acquiring software systems to determine the CMM levels of various organizations. It is therefore an external view of an organization's capability for the main purpose of establishing which organizations are qualified to produce high-quality software and systems.

For both SPA and the SCE, key process areas (KPAs) are defined and profiled, and questionnaires are used as assessment and evaluation devices. Examples of key process areas for CMM levels 2 through 5 are shown in Exhibit 10.4.

Exhibit 10.4: Examples of Key Process Areas (KPAs) CMM Level 2

• Requirements management

• Software project planning

• Software project tracking and oversight

• Software subcontract management

• Software quality assurance

• Software configuration management CMM Level 3

• Organizational process focus

• Organizational process definition

• Training program

• Integrated sofware management

• Software product engineering

• Intergroup coordination

• Peer reviews CMM Level 4

• Process measurement and analysis

• Quality management CMM Level 5

• Defect prevention

• Technology innovation

• Process change management

Each key process area is rated as not satisfied (NS), partially satisfied (PS), or fully satisfied (FS).

With respect to the use of questionnaires as part of the CMM, there are some lessons to be learned. Often, project systems and software engineers tend to disregard processes that they consider to be less than fully rigorous and measurable. However, as the CMM construct demonstrates, it is indeed possible, through questionnaires, to obtain some type of measurement that can be used to make both qualitative and quantitative statements about organizations and the processes that they employ. This method of ''measuring the unmeasurable,'' although perhaps not fully rigorous or even repeatable, can be put into place and can also have enormous real-world impacts. The project, systems, and software engineering managers must understand the role of such procedures and use them wherever and whenever they appear to be applicable. An unyielding stance that fails to acknowledge the utility of checklists and questionnaires normally leads to management difficulties and problems. Organizations are paying a great deal of attention to the CMM notions because they are having major impacts on what they do and how prepared they are to do business in the software development world.

Although essentially everyone appears to acknowledge the impacts of the CMM notions, not everyone is pleased by these impacts and their consequences. For example, in some circles, it is claimed that the ''opposition (to the CMM) is loud and clear'' [10.14]. However, the bottom line reported is that ''the CMM, on balance, can be considered a very successful model, particularly when combined with TQM [Total Quality Management] principles.'' Examples of CMM implementations by Hughes and Raytheon supported this latter conclusion. For example, Hughes, in moving a division from level 2 to level 3, spent about $400,000 over a three-year period. The estimated return on that investment was $2 million annually. Raytheon invested almost $1 million annually in process improvements, achieving a 7.7:1 return on that investment and 2:1 productivity gains.

Based on extensive industry interest in adopting CMM and because some government agencies are indicating that competition will be limited to enterprises that achieve certain levels of capability, it is likely that the CMM, and extensions thereof, will continue to have a strong influence on the practice of software engineering. Thus, for all software-intensive systems, the Project Manager (PM), Chief Systems Engineer (CSE), and Chief Software Engineer are likely to have to pay considerable attention to the CMM.

Beyond the CMM for software lies a CMM concept and implementation for systems engineering (in distinction to software engineering). This issue is explored in Chapter 12.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment