SOFTWARE ENGINEERING & ANALYSIS LABINTRODUCTIONTO THE SOFTWARE ENGINEERING PROCESS GUIDEBOOKFinalFebruary 5, 1997National Aeronautics
and |
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 [Siegel, 1990] . 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.
The Software Engineering Institute (SEI) Capability Maturity Model (CMM) is based on knowledge acquired from software process assessments and extensive feedback from both industry and government. By elaborating the maturity framework, a model has emerged that provides organizations with more effective guidance for establishing process improvement programs [CMU/SEI-93-TR-24].
More, better, faster, and cheaper are challenging words to all levels of management. These are the same demands made in the marketplace, demands that led organizations to focus not only on product, but on process.
In 1920, after the introduction of the assembly line, product inspection controlled product quality. This is sometimes called "inspecting in" quality. Around 1960, Japan began a major effort to penetrate the global electronics market and adopted statistical, process-control methods to improve products. Japan's success drove most manufacturers to adopt similar techniques. In the 1980s, attention shifted to improving the underlying process and product designs to achieve product improvement. This latest approach is sometimes referred to as "building in" quality.
Some of the tried and tested contributions from the quality world influenced what are today's best software engineering practices. J. M. Juran defined a four-step approach to quality improvement [Juran, 1988] . W. E. Deming proposed a 14-point, organization-wide approach [Deming, 1986] . P. B. Crosby developed a quality management-maturity framework to identify where an organization stands in incorporating quality into its business practices [Crosby, 1979] . The key message from Juran, Deming, Crosby, and others is that long-term improvement can be attained only through systematic analysis and action. In any business, the interaction of people, processes, and technologies affects development costs, schedules, and product quality. Process management is a systematic approach to planning, managing, and improving product development and maintenance. Incorporating these ideas and approaches, the Software Engineering Institute (SEI), funded by the Department of Defense (DoD), developed a conceptual framework called the "Capability Maturity Model (CMM) for Software." This model classifies software development organizations into five levels of process maturity (see Figure 1.1-1), and outlines an evolutionary path for improving the management of software activities.
Figure 1.1-1 The Five Levels of Software Process Maturity
(The labeled arrows indicate the type of process capability being institutionalized by the organization at each step of the maturity framework.)
The following paragraphs describe the characteristics of the five maturity levels and the primary process changes required to achieve each level.
At the Initial Level, the organization typically does not provide a stable environment for developing and maintaining software. When an organization lacks sound management practices, the benefits of good software engineering practices are undermined by ineffective planning and a reactive approach to software development.
The software process capability of Level 1 organizations is unpredictable because it changes as the work progresses (i.e., the process is ad hoc). During a crisis, a project typically reverts to coding and testing. As a result, schedules, budgets, functionality, and product quality also are generally unpredictable. Performance rests on the skills, knowledge, and motivations of individuals, rather than on organizational capability. Success entirely depends on having an exceptional manager and a seasoned and effective software team. Occasionally, capable and forceful project software managers can withstand the pressures to take shortcuts in the software process; but when they leave the project, their stabilizing influence leaves with them. Even a strong engineering process cannot overcome the instability created by the absence of sound management practices [CMU/SEI-93-TR-24].
An effective process can be characterized as practiced, documented, enforced, trained, measured, and capable of being improved. An organization at the Repeatable Level has institutionalized effective processes for managing software development. These processes allow the organization to repeat successful practices developed in earlier projects. Planning, tracking, and managing the software project are stable, and based on experience with similar software projects. Realistic project commitments are based on the results observed on previous software projects and current project requirements.
A Level 2 organization is disciplined. The project software manager tracks software costs, schedules, and functionality. The software engineering staff identifies problems compromising project commitments as they arise. The organization baselines software requirements and the products developed to satisfy them, thus, controlling their integrity. Software project standards are defined, and the organization ensures these standards are faithfully followed. The software project staff works with each of its subcontractors to establish a strong customer-supplier relationship [CMU/SEI-93-TR-24].
At the Defined Level, a documented, standard process for developing and maintaining software across the organization integrateseffective software engineering and management processes. The CMM calls this process the organization's "standard software process." A software engineering process group (SEPG) or similar group monitors the organization's software process activities. An organization-wide training program ensures that staff and managers have the knowledge and skills required to fulfill their assigned roles.
Each project team tailors the organization's standard software process to accommodate the project's unique characteristics. The CMM refers to this as the project's "defined software process." This process includes: readiness criteria, inputs, standards, work procedures, verification mechanisms (e.g., peer reviews), outputs, and completion criteria. Because the software process is well defined, management has good insight into each project's technical progress.
The software process capability of a Level 3 organization is standard and consistent. Software engineering and management activities are stable and repeatable, based on a common, organization-wide understanding of the activities, roles, and responsibilities in a defined software process. Within established product lines, costs, schedules, and functionality are under control, and software quality is tracked [CMU/SEI-93-TR-24].
At the Managed Level, the organization sets quantitative and qualitative goals for software products and processes; measures productivity and quality in important software process activities across all projects; collects the data in an organization-wide,software process database; and analyzes the data. The measurements are well defined and consistent, forming the quantitative foundation for evaluating the project's software processes and products.
Software projects control their products and processes by narrowing the variation(s) in their process performance to within acceptable, quantitative boundaries. In a Level 4 organization, meaningful variations in process performance can be distinguished from random variation (noise), particularly within established software product lines. The risks in moving along the learning curve of a new application are known and carefully managed.
The software process capability of a Level 4 organization is predictable because the process is measured and operates within quantitative limits, allowing the organization to predict trends in software process and product quality. When the limits are exceeded, the organization corrects the situation. Software products are of predictably high quality [CMU/SEI-93-TR-24].
At the Optimizing Level, the entire organization is focused on continuous process improvement. The organization identifies weaknesses and proactively strengthens the process to prevent defects. Data on the effectiveness of the software process is used in cost-benefit analyses of new technologies and in proposed changes to the organization's standard software process. Innovations that exploit the best software engineering practices are identified and disseminated throughout the organization.
Software project teams in Level 5 organizations analyze defects to determine their causes. These teams evaluate and alter the software processes to prevent known types of defects from recurring, and then disseminate lessons learned to other projects.
The software process capability of Level 5 organizations is continuously improving because these organizations are striving to improve their process performance on every project. Improvement consists of both incremental advances in the existing processes and innovations that use new technologies and methods [CMU/SEI-93-TR-24].