|
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 faa 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.
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 softwar 195 e 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.
According to Webster's dictionary, a process is "a system of operations
in producing so faa mething ... 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.
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 gai 190 n 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 fe7 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.
|
|