1 The Process Maturity Framework

After two decades of unfulfilled promises about productivity and quality gains from applying new software methodologies and technologies, industry and government organizations are realizing that their fundamental problem is the inability to manage the software process [DoD87]. The benefits of better methods and tools cannot be realized in the maelstrom of an undisciplined, chaotic project. In many organizations, projects are often excessively late and double the planned budget [Siegel90]. 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, some individual software projects 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 process. In the absence of an organization-wide software process, repeating results depends entirely on having the same individuals available for the next project. Success that rests solely on the availability of specific individuals provides no basis for long-term productivity and quality improvement throughout an organization. Continuous improvement can occur only through focused and sustained effort towards building a process infrastructure of effective software engineering and management practices.

1.1 Immature Versus Mature Software Organizations

Setting sensible goals for process improvement requires an understanding of the difference between immature and mature software organizations. In an immature software organization, software processes are generally improvised by practitioners and their management during the course of the project. Even if a software process has been specified, it is not rigorously followed or enforced. The immature software organization is reactionary, and managers are usually focused on solving immediate crises (better known as fire fighting). 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 compromised to meet the schedule.

In an immature organization, there is 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.

On the other hand, a mature software organization possesses an organization-wide ability for managing software development and maintenance processes. The software process is accurately communicated to both existing staff and new employees, and work activities are carried out according to the planned process. The processes mandated are fit for use [Humphrey91b] and consistent with the way the work actually gets done. These defined processes are updated when necessary, and 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 products 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 because all of the participants understand the value of doing so, and the necessary infrastructure exists to support the process.

Capitalizing on these observations about immature and mature software organizations requires construction of a software process maturity framework. This framework describes an evolutionary path from ad hoc, chaotic processes to mature, disciplined software processes. Without this framework, improvement programs may prove ineffective because the necessary foundation for supporting successive improvements has not been established. The 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 in succeeding paragraphs.

1.2 Fundamental Concepts Underlying Process Maturity

According to Webster's dictionary, a process is "a system of operations in producing something ... a series of actions, changes, or functions that achieve an end or result." The IEEE defines a process as "a sequence of steps performed for a given purpose" [IEEE-STD-610]. A software process can be defined as a set of activities, methods, practices, and transformations that people use to develop and maintain software and the associated products (e.g., project plans, design documents, code, test cases, and user manuals). As an organization matures, the software process becomes better defined and more consistently implemented throughout the organization.

Software process capability describes the range of expected results that can be achieved by following a software process. The software process capability of an organization provides one means of predicting the most likely outcomes to be expected from the next software project the organization undertakes.

Software process performance represents the actual results achieved by following a software process. Thus, software process performance focuses on the results achieved, while software process capability focuses on results expected. Based on the attributes of a specific project and the context within which it is conducted, the actual performance of the project may not reflect the full process capability of the organization; i.e., the capability of the project is constrained by its environment. For instance, radical changes in the application or technology undertaken may place a project' s staff on a learning curve that causes their project's capability, and performance, to fall short of the organization's full process capability.

Software process maturity is the extent to which a specific process is explicitly defined, managed, measured, controlled, and effective. Maturity implies a potential for growth in capability and indicates both the richness of an organization's software process and the consistency with which it is applied in projects throughout the organization. The software process is well-understood throughout a mature organization, usually through documentation and training, and the process is continually being monitored and improved by its users. The capability of a mature software process is known. Software process maturity implies that the productivity and quality resulting from an organization's software process can be improved over time through consistent gains in the discipline achieved by using its software process.

As a software organization gains in software process maturity, it institutionalizes its software process via policies, standards, and organizational structures. Institutionalization entails building an infrastructure and a corporate culture that supports the methods, practices, and procedures of the business so that they endure after those who originally defined them have gone.

1.3 Overview of the Capability Maturity Model

Although software engineers and managers often know their problems in great detail, they may disagree on which improvements are most important. Without an organized strategy for improvement, it is difficult to achieve consensus between management and the professional staff on what improvement activities to undertake first. To achieve lasting results from process improvement efforts, it is necessary to design an evolutionary path that increases an organization's software process maturity in stages. The software process maturity framework [Humphrey 87a] orders these stages 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 a software process maturity framework provides a roadmap for 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 of their processes for developing and maintaining software and how to evolve toward a culture of software engineering and management excellence. The CMM was designed to guide software organizations in selecting process improvement strategies by determining 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, an organization can steadily improve its organization-wide software process to enable continuous and lasting gains in software process capability.

The staged structure of the CMM is based on principles of product quality that have existed for the last sixty years. In the 1930s, Walter Shewart, promulgated the principles of statistical quality control. His principles were further developed and successfully demonstrated in the work of W. Edwards Deming [Deming86] and Joseph Juran [Juran88, Juran89]. These principles have been adapted by the SEI into a maturity framework that establishes a project management and engineering foundation for quantitative control of the software process, which is the basis for continuous process improvement.

The maturity framework into which these quality principles have been adapted was first inspired by Philip Crosby of in his book Quality is Free [Crosby79]. Crosby's quality management maturity grid describes five evolutionary stages in adopting quality practices. This maturity framework was adapted to the software process by Ron Radice and his colleagues, working under the direction of Watts Humphrey at IBM [Radice85]. Humphrey brought this maturity framework to the Software Engineering Institute in 1986, added the concept of maturity levels, and developed the foundation for its current use throughout the software industry.

Early versions of Humphrey's maturity framework are described in SEI technical reports [Humphrey87a, Humphrey87b], papers [Humphrey88], and in his book, Managing the Software Process [Humphrey89]. A preliminary maturity questionnaire [Humphrey87b] was released in 1987 as a tool to provide organizations with a way to characterize the maturity of their software processes. Two methods, software process assessment and software capability evaluation, were developed to appraise software process maturity in 1987. Since 1990, the SEI, with the help of many people from government and industry, has further expanded and refined the model based on several years of experience in its application to software process improvement.

[^^]Table of contents [<-]Back one chapter [->]Forward one chapter