Capability maturity model
After two decades of unfulfilled promises for productivity and quality gains from applying new software methods and technologies, industry and government organizations are realizing that their fundamental problem is the inability to manage the software development process. The benefits of better methods and tools cannot be realized in the chaos of undisciplined projects. In many organizations, projects are often excessively late and as much as double the planned budget. In such instances, the organization frequently is not providing the infrastructure and support necessary to help projects avoid these problems.
Even in undisciplined organizations, however, individual software projects occasionally produce excellent results. When such projects succeed, it is generally through the heroic efforts of a dedicated team, rather than through repeating the proven methods of an organization with a mature software development process. In the absence of an organization-wide software process, repeating results depends entirely on the availability of specific individuals available for the next project. Success that rests solely on the availability of specific individuals provides a poor basis for long-term productivity and quality improvement through an organization. Continuous improvement can best occur through focused and sustained efforts at building a process infrastructure of effective software engineering and management practices.
Immature vs. Mature Software Development Organizations
Setting goals for process improvement requires an understanding of the difference between immature and mature software development organizations. In an immature software organization, software development processes are generally improvised by practitioners and managers during the course of the project. Even when a software process has been specified, it is not rigorously followed or enforced. The immature software development organization is reactionary, and managers are usually focused on solving immediate and generally unpredicted crises. Schedules and budgets are routinely exceeded because they are not based on realistic estimates. When hard deadlines are imposed, product functionality and quality are often compromized to meet the schedule.
In an immature software development organization, there is typically no objective basis for judging product quality or for solving product or process problems. Therefore, product quality is difficult to predict. Activities intended to enhance quality such as reviews and testing are often curtailed or eliminated when projects fall behind schedule. Most of the software development staff does not realize the importance of software processes and standards. They see it as wishful thinking and overhead to their productivity.
On the other hand, a mature software organization possesses an organization-wide ability for managing software development processes. The software process is accurately communicated to both existing staff and new employees, and work activities are carried out effectively. The processes are consistent with the way the work actually gets done. These defined processes are updated when necessary, and process improvements are developed through controlled pilot tests and/or cost-benefit analyses. Roles and responsibilities within the defined process are clear throughout the project and across the organization.
In a mature organization, managers monitor the quality of the software product and customer satisfaction. There is an objective, quantitative basis for judging product quality and analyzing problems with the product and process. Schedules and budgets are based on historical performance and are realistic; the expected results for cost, schedule, functionality, and quality of the product are usually achieved. In general, a disciplined process is consistently followed.
Fundamental Concepts Underlying Process Maturity
Capitalizing on these observations about immature and mature software organizations requires the construction of a software process maturity framework. Such a framework describes an evolutionary path from an ad-hoc, chaotic process to a mature, disciplined software development process. Without this framework, improvement programs may prove ineffective because the necessary foundation for supporting successive improvements has not been established. A software process maturity framework emerges from integrating the concepts of software process, software process capability, software process performance, and software process maturity, all of which are defined respectively in the following paragraphs.
Software process can be defined as a set of activities, methods, practices, and transformations that people use to develop and maintain software and its associated products (e.g. project plans, design documents, code, test cases, user manuals). As an organization matures, its software process becomes better defined and more consistently implemented and enforced throughout the organization.
Software process capability describes the range of expected results from a software process. The software process capability of an organization provides one means of predicting the most likely outcomes that are expected from all the software project the organization undertakes.
Software process performance represents the actual results from following a software process. Thus, software process performance focuses on the results achieved, while software process capability focuses on the results expected. Based on the attributes of a specific project and the context within which it is conducted, the performance of the project may not reflect the full process capability of the organization. The CMM is based on the premise that maturity is an indicator of capability.
Software process maturity implies that the productivity and quality resulting from an organizations software process can be improved over time through consistent gains in the discipline achieved by applying its software process. Software process maturity is increased in a software organization when it institutionalizes its software process through policies, standards, and organizational structures. Institutionalization entails building a corporate culture that supports and enforces the established methods, practices, and procedures, so that they endure after those originally defined them have gone.
Overview of the Capability Maturity Model (CMM)
Although software engineers and managers often know their problems in great detail, they often disagree on which improvements are most important. Without an organized strategy for improvement, it is difficult to come to an agreement between the management and the professional software development staff on what improvement activities to undertake first, and their relative importance.
To achieve lasting results from process improvement efforts, it is necessary to design an evolutionary path that increases an organizations software process maturity in stages. These stages must be ordered so that improvements at each stage provide the foundation on which to build improvements undertaken at the next stage. Thus, an improvement strategy drawn from the software process maturity framework provides a roadmap for organizations embarking on the journey of continuous process improvement. It guides advancement and identifies deficiencies in the organization; it is not intended to provide a quick fix for projects in trouble.
The Capability Maturity Model for Software provides software organizations with guidance on how to gain control on their process for developing and maintaining software and how to evolve towards a culture of software engineering and software project management excellence. The CMM was designed to guide software development organizations in selecting process improvement strategies by determining their current process maturity and identifying the few issues most critical to software quality and process improvement.
By focusing on a limited set of activities and working aggressively to achieve them, organizations can steadily improve their organization-wide software development process to enable continuous and lasting gains in software process capability.
The Five Levels of Software Process Maturity
Continuous process improvement is based on many small, evolutionary steps rather than revolutionary innovations. The CMM provides a framework for organizing these evolutionary steps into five maturity levels that lay the successive foundations for continuous process improvement. These five maturity levels define an ordinal scale for measuring the maturity of an organizations software development process and for evaluating its software process capability.
A maturity level is a well-defined evolutionary plateau on the path towards becoming a mature software development organization. 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 development 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. Organizing the CMM into the five levels prioritizes improvement actions for increasing software process maturity. Each transition to the next level represent a different and incremental process capability being institutionalized by the organization at each step of the maturity framework.
The following short characterization of the five maturity levels highlights the primary process changes made at each level.
Initial: The software development process is characterized as an ad hoc, and occasionally even chaotic. Few processes are defined, and even fewer are consistently followed in all projects. Success depends solely on the heroic efforts of highly knowledgeable and experienced individuals in the team.
Repeatable: Basic project management processes are established, but generally not fully defined or documented, to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects in similar application domains, hence the name of this maturity level.
Defined: The software process for both management and software engineering activities is documented, standardized, and integrated into an organization-wide software process. All projects use a documented and approved version of the organizations process for developing and managing software.
Managed: Detailed measures of the software process and product quality are established and collected. Both the software development process and its products are quantitatively understood and controlled using detailed measures, enabling better quality and productivity control for all software projects.
Optimizing: Continuous process improvement is enabled by quantitative feedback through quality assessment metrics from the software development process and from testing innovative ideas and technologies in the ever-evolving discipline of software engineering.
Behavioral Characterization of the Maturity Levels
Maturity Levels 2 to 5 can be characterized by the activities to be performed by the organization to establish or improve its software development process, by activities performed on each software project, and by the resulting process capability across projects. A behavioral characterization of Level 1 is included to establish a base of comparison for process improvements at higher maturity levels.
Level 1 - The Initial Level
At the Initial Level, a software development organization typically does not provide a stable environment for developing and maintaining software. When sound management practices are lacking with an organization, the benefits of establishing software engineering practices are undermined by ineffective planning and reactionary project management. The organization is also heavily dependent on the experience and expertise of a handful of software development practitioners, engineers and managers.
Projects typically abandon planned procedures and revert to coding and ad hoc testing during a crisis. Success depends entirely on having an exceptional manager and a seasoned and effective software development team. Occasionally, exceptionally capable and forceful software managers can withstand the pressure to take shortcuts in the software process, but when they leave the project, their stabilizing influence leaves with them. The software development staff work in a hectic and frustrating environment, and their experience and knowledge is primordial for the survival of the projects they are working on. They are overcommitted and hardworking and are thus more likely to leave, eventually putting the organization in a precarious situation, especially if they leave during an important project.
The process capability of Level 1 organizations is unpredictable because the software development process is constantly changed or modified as the work progresses. Schedules, budgets, functionality, and product quality are generally unpredictable. Performance depends on the highly variable individual capabilities of the software development staff with their own skills, knowledge, and motivations. There are few hints of stable software processes in operation, and productivity can only be predicted by individual rather than organizational capability.
Level 2 - The Repeatable Level
At the Repeatable Level, software project management policies and procedures are established by the organization. Planning and managing new projects is based on experience with similar projects. An objective in achieving Level 2 is to stabilize the software project management processes, which allows organizations to repeat successful practices developed on earlier projects.
Projects in Level 2 organizations have installed basic software management controls. Realistic project commitments are established from risks and results observed on previous similar projects. Project managers track software costs, schedules, and functionality; and most of the times, problems in meeting commitments are identified only when they arise. Software requirements and the artifacts developed to satisfy them are baselined, and their integrity is controlled. Project standards are defined, and the organization ensures they are consistently followed. The project development teams work with their customers, and their subcontractors, if any, to establish a stable, managed, working environment.
The process capability of Level 2 organizations can be summarized as stable for planning and tracking the evolution of software projects, but only because a disciplined management process provides a project environment for repeating earlier successes. The process is under the effective control of a project management system, following realistic plans based on the performance of previous projects.
Level 3 - The Defined Level
At the Defined Level, the standard process for developing and maintaining software across the organization is documented, including both software engineering and software management processes, which are integrated into a coherent whole. Processes established at the Defined Level are used by both management and staff and are changed as appropriate to help them perform more effectively in various situations. The organization exploits effective software engineering practices when standardizing software processes for the organization.
There is a permanent organizational focus on the software development process; a Software Engineering Process Group (SEPG) facilitates process definition and improvement efforts. An organization-wide training program is implemented to ensure that all practitioners have the knowledge and skills required to carry out their tasks in these processes.
Projects use the organization-wide standard software development process for developing and maintaining software as a basis for creating their own defined software process that encompasses the unique characteristics of each project. Each process uses a peer review process to enhance product quality. Because the software process is well defined, management has a good visibility into the progress on all projects. Management and engineering activities are coherently integrated on each project.
The process capability of Level 3 organizations can be summarized as stable for both management and engineering activities. Within established product lines, cost, schedule, and functionality are under control and software quality is tracked. This capability is based on a common understanding of processes, roles, and responsibilities in a defined and documented process.
Level 4 - The Managed Level
At the Managed Level, the organization sets quantitative quality goals for software development projects. Productivity and quality are measured for important software development process activities across all projects in the organization. An organization-wide process database is used to collect and analyze the data available from a carefully defined process. Software processes have been instrumented with well-defined and consistent measures at Level 4. These measures establish the quantitative foundation for evaluating projects, processes, and delivered products.
Projects achieve control over their products and processes by narrowing the variation in their performance to within acceptable quantitative boundaries. Meaningful variations in performance can be distinguished from random variation (noise), particularly when comparing similar projects. To reduce the process variation due to constant shifts among new application domains, a strategic business plan describes which product lines the organization is to pursue. The risks involved in moving up the learning curve of a new application domain are known and carefully managed.
The process capability of Level 4 organizations can be summarized as measured and operating within measureable limits. This level of process capability allows an organization to predict process and product quality trends within the established quantitative bounds. When these limits are violated, action is taken to correct the situation. Software products are of predictable high quality.
Level 5 - The Optimizing Level
At the Optimizing Level, the organization is focused on continuous process improvement. The organization has the means to identify weak process elements and strengthen them, with the goal of preventing the occurence of similar defects in future projects. Statistical evidence is available on process effectiveness and is used in performing cost/benefit analyses on new technologies. Innovations that exploit the best software engineering practices are seeked and identified. Project managers analyze process performance to establish a relation with project defects. Software processes are evaluated and changed to prevent known types of defects from reoccuring, and lessons learned are disseminated to other projects. Level 5 organizations are continuously striving to raise the upper bounds of their process capability. Improvement occurs both by incremental advancements in the existing process and by innovations using new technologies and methods.
Skipping Maturity Levels
Because of impatience for results, senior management occasionally attempts to reach Level 5 without progressing through the previous levels in sequence. This approach has proven to be counterproductive, however, because each level forms a necessary foundation from which to construct the next level. The CMM identifies the levels through which an organization must evolve to establish a culture of software engineering and software project management excellence. Software engineering and project management processes without the proper foundation fail at every point they are needed most, i.e. under stress, and they provide no basis for future improvement.
A Level 1 organization that is trying to implement a Defined process (Level 3) before it has established a Repeatable process (Level 2) is usually unsuccessful because project managers are overwhelmed by schedule and cost pressures. This is the fundamental reason for focusing on management processes before engineering processes. It may seem easier to define and implement an engineering process than a management process (especially in the eyes of technical people), but without management discipline, the engineering process is sacrificed to schedule and cost pressures.
An organization that has not established a Defined process (Level 3) and is trying to implement a Managed process (Level 4) is usually unsuccessful because without properly defined processes, there is no common basis for implementing measurements. While data can be collected, few metrics have significant meaning across projects, especially if they are of different nature or applicable to specific application domains. The collected data will not increase the understanding of the software development process. It is difficult to identify meaningful metrics in the absence of defined processes because of the variation in the processes being measured.
An organization that has not established a managed process (Level 4) and is trying to implement an optimizing process (Level 5) is most likely to fail. Without controlling the process with statistically narrow boundaries, there is too much noise in the data to objectively determine whether a specific process improvement has an effect. Decisions must be based on intuition or politics because little quantitative foundation exists for making rational, informed decisions.
All maturity levels in the CMM framework provide an incremental basis for the next level. Most practices that have to be implemented in a maturity level depend on the implementation of many practices in the previous levels. Process improvement is a project in itself. It should be undertaken consistently, and strictly following guidelines and processes. For the same reasons as curtailing or skipping software process activities never pay off, skipping maturity levels should never be attempted, as it will inevitably lead to increase in implementation cost one day ore another.
Operational Definition of the Capability Maturity Model
The CMM is a framework representing a path of improvements recommended for software organizations that want to increase their software process capability. To use the CMM to guide improvement programs, it must be defined in terms of software activities. The intended diversity in use of the CMM requires that it be decomposed in sufficient details, and that actual process recommendations be derived from the structure of the maturity levels. This decomposition also makes it possible to determine which among these recommended processes are the most potent indicators of software process maturity and capability.
Internal Structure of the Maturity Levels
Each maturity level has been decomposed into constituent parts. With the exception of Level 1, each level is decomposed from abstract summary down to an operational definition of the items composing it. Thus, a maturity level is composed of several key process areas. Each key process area consists of numerous key practices that, when addressed collectively, accomplish the goals of the key process area. Some key practices are selected as key indicators of whether the goals of a key process area are accomplished.
A maturity level is a well-defined evolutionary plateau towards achieving a mature software development process. The maturity levels provide the top-level structure of the CMM. Each maturity level indicates a level of process capability. For instance, at the Repeatable Level, the process capability of an organization has been elevated by establishing a disciplined process under sound project management control.
Key Process Areas
Except for Level 1, each maturity level is decomposed into several key process areas that indicate the areas an organization should focus on to improve its software process. Key process areas identify the issues that must be addressed to reach a maturity level. Although other issues affect process performance, the key process areas were identified because of their effectiveness in improving an organizations software capability. They may be considered the requirements for achieving a maturity level. To achieve a maturity level, the goals of each key process area at that level must be satisfied. The key process areas have been defined to reside at a single maturity level. The specific practices to be executed in each key process area will evolve in content as the organization achieves higher levels of process maturity.
For instance, many of the project estimating capabilities described in the Software Project Planning key process area at Level 2 must evolve to handle additional project data available at Levels 3, 4 and 5. For example, at Level 3, the Integrated Software Management key process area is defined to capture the evolution from managing a project according to a plan to managing a project using a defined software process.
Each key process area represents a cluster of related activities that, when performed collectively, achieve a set of goals considered important for enhancing the overall process capability The path to achieving the goals of a key process area may differ across projects based on differences in application domains or environments. Nevertheless, all the goals of a key process area must be achieved for an organization to satisfy that key process area. When the goals of a key process area have been accomplished on a continuing basis, the organization can be said to have institutionalized the process capability characterized by the key process area.
Key Practices
Each key process area is defined by the key practices that contribute to satisfying its goals. The key practices are the policies, procedures, and activities that contribute to the effective institutionalization and implementation of the key process area. At the highest level of abstraction, the goals themselves represent the key practices of a key process area. The key practices describe what is to be accomplished, but they should not be interpreted as mandating how the key practices should be performed. An important consideration is whether an alternative process accomplishes the goals of the key process area. The key practies should be interpreted rationally in the project environment to judge whether the goals of the key process area are effectively, although perhaps differently, achieved. The key practices for all key process areas are contained in [1], along with guidance on their interpretation.
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 key process areas. 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.
Common Features
The key practices are divided among five common features sections:
Commitment to Perform describes the actions the organization must take to ensure that the process is established and will be continuously followed. Commitment to Perform typically involves establishing organizational control policies and senior management sponsorship and involvement.
Ability to Perform describes the preconditions that must exist in the project or organization to implement the software development process and project management competently. Ability to Perform typically involves resources, organizational structures, and training of the staff involved.
Activities Performed describes the roles and procedures necessary to implement and achieve the goals of a key process area. Activities Performed typically involve establishing plans and procedures, performing the work, tracking it, and taking corrective actions as necessary.
Measurement and Analysis describes the need to measure the process and analyze the measurements. Measurement and Analysis typically includes examples of the measurements that could be taken to determine the status and effec-tiveness of the Activities Performed.
Verifying Implementation describes the steps to ensure that the activities are performed in compliance with the process that has been established. Verification typically encompasses reviews and audits by management and software quality assurance teams.
The practices in the common feature Activities Performed describe what must be implemented to establish a process capability. The other practices, taken as a whole, form the basis by which an organization can institutionalize the practices described in the Activities Performed common feature. The Activities Performed by projects or the organization provide the largest category of key practices because they describe the actual implementation of the key process area. Key practices under the other common features are equally important, however, for they address what must be done to support and institutionalize the key process area.
The Key Process Areas of the CMM
Each key process area identifies a cluster of related activities or policies that, when applied in conjunction, achieve a specific goal considered important for enhancing process capability. The key process areas have been defined to reside in a single maturity level, although most of them must be improved upon reaching higher maturity levels. The key process areas are the building blocks that indicate the areas an organization should focus on to improve its software process. Key process areas identify issues that must be addressed to achieve a maturity level.
Level 2 Key Process Areas
The key process areas at Level 2 focus on the software projects concerns related to establishing basic project management controls. Descriptions of each of the key process areas for Level 2 are given below:
The purpose of Requirements Management is to establish a common understanding between the customer and the software project staff of the problem to be addressed by the software project. This agreement with the customer is the basis for planning (Software Project Planning) and managing (Software Project Tracking and Oversight) the software project. Control of the relationship with the customer depends on following an effective change control process (Software Configuration Management).
The purpose of Software Project Planning is to establish reasonable plans for performing the software engineering tasks and for managing the software project. These plans are the necessary foundation for managing the software project (Software Project Tracking and Oversight). Without realistic plans, effective project management cannot be implemented.
The purpose of Software Project Tracking and Oversight is to establish adequate visibility into actual progress so that management can take effective actions when the software projects performance deviates significantly from the software plans.
The purpose of Software Subcontract Management is to select qualified software subcontractors and manage them effectively. It combines the concerns of Requirements Management, Software Project Planning, and Software Project Tracking and Oversight for basic management control, along with necessary oversight of Software Quality Assurance and Software Configuration Management.
The purpose of Software Quality Assurance is to provide management with appropriate visibility into the process being used by the software project and of the products being built. Software Quality Assurance is part of most software engineering and management processes.
The purpose of Software Configuration Management is to establish and maintain the integrity of the products of the software project throughout the projects software life cycle. Software Configuration Management is an integral part of most software engineering and management processes.
Level 3 Key Process Areas
The key process areas at Level 3 address both project and organizational issues, as the organization establishes an infrastructure that institutionalizes effective software engineering and management processes across all projects. Descriptions of each of the key process areas for Level 3 are given below:
The purpose of Organization Process Focus is to establish the organizational responsibility for software process activities that improve the organizations software process capability. The primary result is a set of software process assets, which are described in Organization Process Definition. These assets are used by the software projects, as is described in Integrated Software Management.
The purpose of Organization Process Definition is to develop and maintain a usable set of software process assets that improve process performance across the projects and provide a basis for cumulative, long-term benefits to the organization. These assets provide a stable foundation that can be institutionalized via mechanisms such as training, which is described in Training Program.
The purpose of Training Program is to develop the skills and knowledge of individuals so they can perform their roles effectively and efficiently. Training is an organizational responsibility, but the software projects should identify their needed skills and provide the necessary training when the projects needs are unique.
The purpose of Integrated Software Management is to integrate the software engineering and management activities into a coherent, defined software process that is tailored from the organizations standard software process and related process assets, which are described in Organization Process Definition. This tailoring is based on the business environment and technical needs of the project, as described in Software Product Engineering. Integrated Software Management evolves from Software Project Planning and Software Project Tracking and Oversight from Level 2.
The purpose of Software Product Engineering is to consistently perform a well-defined engineering process that integrates all the software engineering activities to produce correct, consistent software products effectively and efficiently. Software Product Engineering describes the technical activities of the project, e.g., requirements analysis, design, code, and test.
The purpose of Intergroup Coordination is to establish a means for the software engineering group to participate actively with the other groups so the project is better able to satisfy the customers needs effectively and efficiently. Intergroup Coordination is the interdisciplinary aspect of Integrated Software Management that extends beyond software engineering; not only should the software process be integrated, but the software engineering groups interactions with other groups must be coordinated and controlled.
The purpose of Peer Reviews is to remove defects from the process deliverables early and efficiently. An important corollary effect is to develop a better understanding of the process deliverables and of the defects that can be prevented. The peer review is an important and effective engineering method that is called out in Software Product Engineering and that can be implemented via structured inspections and walkthroughs, or a number of other established review methods.
Level 4 Key Process Areas
The key process areas at Level 4 focus on establishing a quantitative understanding of both the software development process and the process deliverables being built. The two key process areas at this level, Quantitative Process Management and Software Quality Management, are highly interdependent, as is described below:
The purpose of Quantitative Process Management is to control the process performance of the software project quantitatively. Software process performance represents the actual results achieved from following a software process. The focus is on identifying special causes of variation within a measurably stable process and correcting, as appropriate, the circumstances that drove the variation to occur. Quantitative Process Management adds a comprehensive measurement program to the practices of Organization Process Definition, Integrated Software Management, Intergroup Coordination, and Peer Reviews.
The purpose of Software Quality Management is to develop a quantitative understanding of the quality of the projects software products and achieve specific quality goals. Software Quality Management applies a comprehensive measurement program to the process deliverables described in Software Product Engineering.
Level 5 Key Process Areas
The key process areas at Level 5 cover the issues that both the organization and the projects must address to implement continuous and measurable software process improvement. Descriptions of each of the key process areas for Level 5 are given below:
The purpose of Defect Prevention is to identify the causes of defects and prevent them from recurring. The software project analyzes defects, identifies their causes, and changes its defined software process, as is described in Integrated Software Management. Process changes of general value are transitioned to other software projects, as is described in Process Change Management.
The purpose of Technology Change Management is to identify beneficial new technologies (i.e., tools, methods, and processes) and transfer them into the organization in an orderly manner, as is described in Process Change Management. The focus of Technology Change Management is on performing innovation efficiently in an ever-changing world.
The purpose of Process Change Management is to continually improve the software processes used in the organization with the intent of improving software quality, increasing productivity, and decreasing the cycle time for product development. Process Change Management takes the incremental improvements of Defect Prevention and the innovative improvements of Technology Change Management and makes them available to the entire organization.
