Elements of Software Process Assessment & Improvement / Edition 1 available in Paperback
Elements of Software Process Assessment & Improvement / Edition 1
- ISBN-10:
- 0818685239
- ISBN-13:
- 9780818685231
- Pub. Date:
- 05/11/1999
- Publisher:
- Wiley
Elements of Software Process Assessment & Improvement / Edition 1
Paperback
Buy New
$139.95Buy Used
$90.55-
-
SHIP THIS ITEM
Temporarily Out of Stock Online
Please check back later for updated availability.
-
Overview
This book describes in detail the process improvement cycle, including diagnosing an organization, establishing a business case, changing elements within a process, and evaluating the impact of these changes. These elements are divided into four parts providing a comprehensive view of the software process improvement field. The first part describes contemporary models that are used to evaluate an organization's processes and capabilities. The next covers the business case for assessment and improvement by providing ample evidence that demonstrates possible improvements as well as evidence of assessment reliability. Part three provides application guidance covering critical success factors including tools and techniques. The final portion covers important and exciting developments that enhance process improvement tools and the reader's understanding of organizational processes in practice.
These four elements answer the needs of individuals involved in software process improvement as well as those involved in basic and applied research. Elements of Software Process Assessment and Improvement is an invaluable source of practical information for software process professionals.
Product Details
| ISBN-13: | 9780818685231 |
|---|---|
| Publisher: | Wiley |
| Publication date: | 05/11/1999 |
| Series: | Practitioners , #29 |
| Pages: | 398 |
| Product dimensions: | 7.22(w) x 10.35(h) x 1.08(d) |
About the Author
Read an Excerpt
Elements of Software Process Assessment & Improvement
By Khaled El Emam
John Wiley & Sons
ISBN: 0-8186-8523-9Chapter One
The Capability Maturity Model for Software
Mark C. Paulk, Charles V. Weber, and Mary Beth Chrissis Software Engineering Institute, USA
This chapter provides an overview of the Capability Maturity Model for Software (CMM V1.1). CMM V1.1 describes the software engineering and management practices that characterize organizations as their processes for developing and maintaining software mature. This chapter stresses the need for a process maturity framework to prioritize improvement actions; describes the five maturity levels, key process areas, and their common features; and discusses future directions for the CMM.
Introduction
In many organizations, software projects are often late and over budget. This state of affairs is sometimes referred to as the "software crisis." In 1986 the Software Engineering Institute (SEI), with assistance from the MITRE Corporation, began developing a process maturity framework that would help organizations improve their software process; this has evolved into the Capability Maturity Model for Software (CMM or SW-CMM).
The SW-CMM presents sets of recommended practices in a number of key process areas that have been shown to enhance software process capability. It 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. By focusing on a limited set of issues and working aggressively to address them, an organization can steadily improve its organization-wide software process to enable continual and lasting gains in software process capability.
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.
In contrast, 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 mandated processes are usable 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 the process that produced them. 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.
Fundamental Concepts Underlying Process Maturity
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 work products (for instance, 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. An organization's software process capability is one way of predicting the most likely outcome to expect 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.
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.
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 an organizational culture that support the methods, practices, and procedures of the business so that they endure even after those who originally defined them have gone.
The Five Levels of Software Process Maturity
Continual process improvement is based on many small, evolutionary steps, although revolutionary innovations may be part of a process improvement program. The staged structure of the SW-CMM is based on principles of product quality espoused by Walter Shewart, W. Edwards Deming, Joseph Juran, and Philip Crosby. The SWCMM provides a framework for organizing these evolutionary steps into five maturity levels that lay successive foundations for continual process improvement. These five maturity levels define an ordinal scale for measuring the maturity of an organization's software process and for evaluating its software process capability. The levels also help an organization prioritize its improvement efforts.
A maturity level is a well-defined evolutionary plateau toward achieving a mature software process. Each maturity level comprises a set of process goals that, when satisfied, stabilize an important component of the software process. Achieving each level of the maturity framework establishes a higher level of process capability for the organization.
Organizing the SW-CMM into the five levels shown in Figure 1-1 prioritizes improvement actions for increasing software process capability. The labeled arrows in Figure 1-1 indicate the type of process capability being institutionalized by the organization at each step of the maturity framework.
The five levels can be briefly described as:
1) Initial The software process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort and heroics.
2) Repeatable Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications.
3) Defined The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. Projects use an approved, tailored version of the organization's standard software process for developing and maintaining software.
4) Managed Detailed measures of the software process and product quality are collected, analyzed, and used to control the process. Both the software process and products are quantitatively understood and controlled.
5) Optimizing Continual process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies.
These five levels reflect the fact that the SW-CMM is a model for improving the capability of software organizations. The priorities in the SW-CMM, as expressed by these levels, are not directed at individual projects. A project that is in trouble might justifiably set its priorities for corrective action differently from those in the SWCMM. Its solutions, however, might be of limited value to the rest of the organization, because other projects might have different problems or because other projects lack the necessary foundation to take advantage of its solutions. The SW-CMM focuses on processes that build organizational capability.
Behavioral Characterization of the Maturity Levels
Maturity Levels 2 through 5 can be characterized through the activities performed by the organization to establish or improve the software process, by activities performed on each 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, the organization typically does not provide a stable environment for developing and maintaining software. Over-commitment is a characteristic of Level 1 organizations, and such organizations frequently have difficulty making commitments that the staff can meet with an orderly engineering process, resulting in a series of crises. During a crisis, projects typically abandon planned procedures and revert to coding and testing. Success depends on having an exceptional manager and a seasoned and effective software team. Occasionally, capable and forceful 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.
In spite of this ad hoc, even chaotic, process, Level 1 organizations frequently develop products that work even though they may exceed the budget and schedule. Success in Level 1 organizations depends on the competence and heroics of the people in the [organization.sup.2] and cannot be repeated unless the same competent individuals are assigned to the next project. Thus, at Level 1, capability is a characteristic of the individuals, not of the organization.
Level 2 - The Repeatable Level
At the Repeatable Level, policies for managing a software project and procedures to implement those policies are established. Planning and managing new projects are based on experience with similar projects. Establishing basic process management discipline on a project-by-project basis enhances process capability. Projects implement effective processes that are defined, documented, practiced, trained, measured, enforced, and provide a basis for improvement.
Projects in Level 2 organizations have installed basic software management controls. Realistic project commitments are made, based on the results observed on previous projects and on the requirements of the current project. The software managers for a project track software costs, schedules, and functionality; problems in meeting commitments are identified when they arise. Software requirements and the work products developed to satisfy them are baselined, and their integrity is controlled. Software project standards are defined, and the organization ensures that they are faithfully followed. The software project works with its subcontractors, if any, to establish an effective customer-supplier relationship.
Processes may differ among projects in a Level 2 organization. The organizational requirement for achieving Level 2 is that there are policies that guide the projects in establishing the appropriate management processes.
The software process capability of Level 2 organizations can be summarized as "disciplined" because software project planning and tracking are stable and earlier successes can be repeated. The project's 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, a standard process (or processes) for developing and maintaining software is documented and used across the organization. This standard process includes both software engineering and management processes integrated into a coherent whole. This standard process is referred to throughout the SW-CMM as the organization's standard software process. Processes established at Level 3 are used (and changed, as appropriate) to help the software managers and technical staff perform more effectively. The organization exploits effective software engineering practices when standardizing its software processes. A group such as a software engineering process group or SEPG is responsible for the organization's software process activities. An organization-wide training program is implemented to ensure that the staff and managers have the knowledge and skills required to perform their assigned roles.
Projects tailor the organization's standard software process to develop their own defined software process, which accounts for the unique characteristics of the project. This tailored process is referred to in the SW-CMM as the project's defined software process. It is the process used in performing the project's activities. A defined software process contains a coherent, integrated set of well-defined software engineering and management processes. A well-defined process includes entry criteria, inputs, standards and procedures for performing the work, verification mechanisms (such as peer reviews), outputs, and exit criteria. Because the software process is well defined, management has good insight into technical progress on the project.
The software process capability of Level 3 organizations can be summarized as "standard and consistent" because both software engineering and management activities are stable and repeatable. Within established product lines, cost, schedule, and functionality are under control and software quality is tracked. This process capability is based on a common, organization-wide understanding of the activities, roles, and responsibilities in a defined software process.
Level 4 - The Managed Level
At the Managed Level, the organization sets quantitative quality goals for both software products and processes. Productivity, quality, etc. are measured for important software process activities across all projects as part of an organizational measurement program. An organization-wide software process database is used to collect and analyze the data available from the projects' defined software processes. Software processes are instrumented with well-defined and consistent measurements. These measurements establish the quantitative foundation for evaluating the projects' software processes and products.
Projects achieve control over their products and processes by narrowing the variation in their process performance to fall within acceptable quantitative boundaries. Meaningful variations in process performance can be distinguished from random variation (noise), particularly within established product lines. The risks involved in moving up the learning curve of a new application domain are known and carefully managed.
The software process capability of Level 4 organizations can be summarized as being "quantified and predictable" because the process is measured and operates within quantitative limits. This level of process capability allows an organization to predict trends in process performance and product quality within the quantitative bounds of these limits. Because the process is both stable and measured, when some exceptional circumstance occurs, the "special cause" of the variation can be identified and addressed. When the pre-defined limits are exceeded, actions are taken to understand and correct the situation. Software products are of predictably high quality.
Level 5 - The Optimizing Level
At the Optimizing Level, the entire organization is focused on continual process improvement. The organization has the means to identify weaknesses and strengthen the process proactively, with the goals of preventing defects and improving efficiency. Data on process effectiveness are used to perform cost/benefit analyses of new technologies and proposed changes to the organization's software process. Innovations that exploit the best software engineering practices are identified and transferred throughout the organization. Software teams in Level 5 organizations analyze defects to determine their causes, evaluate software processes to prevent known types of defects from recurring, and disseminate lessons learned throughout the organization. There is chronic waste, in the form of rework, in any system simply because of random variation. Organized efforts to remove waste result in changing the system by addressing "common causes" of inefficiency. While efforts to reduce waste occur at all maturity levels, it is the focus of Level 5. The software process capability of Level 5 organizations can be characterized as "continually improving" because Level 5 organizations are continually striving to improve the range of their process capability, thereby improving the process performance of their projects. Improvements occur both by incremental advancements in the existing process and by innovations using new technologies and methods. Technology and process improvements are planned and managed as ordinary business activities.
(Continues...)
Excerpted from Elements of Software Process Assessment & Improvement by Khaled El Emam Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.