The defect prevention process (DPP) is not itself a software development process. Rather, it is a process to continually improve the development process. It originated in the software development environment and thus far has been implemented mostly in software development organizations. Because we would be remiss if we did not discuss this process while discussing software development processes, this chapter includes a brief discussion of DPP.
The DPP was modeled on techniques used in Japan for decades and is in agreement with Deming's principles. It is based on three simple steps:
The formal process, first used at the IBM Communications Programming Laboratory at Research Triangle Park, North Carolina (Jones, 1985; Mays et al., 1990), consists of the following four key elements:
Figure 2.6 shows this process schematically.
Figure 2.6. Defect Prevention Process
Different from postmortem analysis, the DPP is a real-time process, integrated into every stage of the development process. Rather than wait for a postmortem on the project, which has frequently been the case, DPP is incorporated into every sub-process and phase of that project. This approach ensures that meaningful discussion takes place when it is fresh in everyone's mind. It focuses on defect- related actions and process-oriented preventive actions, which is very important. Through the action teams and action tracking tools and methodology, DPP provides a systematic, objective, data-based mechanism for action implementation. It is a bottoms-up approach; causal analysis meetings are conducted by developers without management interference. However, the process requires management support and direct participation via the action teams.
Many divisions of IBM have had successful experiences with DPP and causal analysis. DPP was successful at IBM in Raleigh, North Carolina, on several software products. For example, IBM's Network Communications Program had a 54% reduction in error injection during development and a 60% reduction in field defects after DPP was implemented. Also, IBM in Houston, Texas, developed the space shuttle onboard software control system with DPP and achieved zero defects since the late 1980s. Causal analysis of defects along with actions aimed at eliminating the cause of defects are credited as the key factors in these successes (Mays et al., 1990). Indeed, the element of defect prevention has been incorporated as one of the "imperatives" of the software development process at IBM. Other companies, especially those in the software industry, have also begun to implement the process.
DPP can be applied to any development processwaterfall, prototyping, iterative, spiral, Cleanroom, or others. As long as the defects are recorded, causal analysis can be performed and preventive actions mapped and implemented. For example, the middle of the waterfall process includes designing, coding, and testing. After incorporating DPP at each stage, the process will look like Figure 2.7. The important role of DPP in software process improvement is widely recognized by the software community. In the SEI (Software Engineering Institute) software process maturity assessment model (Humphrey, 1989), the element of defect prevention is necessary for a process to achieve the highest maturity levellevel 5. The SEI maturity model is discussed in more detail in the next section.
Figure 2.7. Applying the Defect Prevention Process to the Middle Segment of the Waterfall Model
Finally, although the defect prevention process has been implemented primarily in software development environments, it can be applied to any product or industry. Indeed, the international quality standard ISO 9000 has a major element of corrective action; DPP is often an effective vehicle employed by companies to address this element when they implement the ISO 9000 registration process. ISO 9000 is also covered in the next section on process maturity assessment and quality standards.
What Is Software Quality?
Software Development Process Models
Fundamentals of Measurement Theory
Software Quality Metrics Overview
Applying the Seven Basic Quality Tools in Software Development
Defect Removal Effectiveness
The Rayleigh Model
Exponential Distribution and Reliability Growth Models
Quality Management Models
In-Process Metrics for Software Testing
Complexity Metrics and Models
Metrics and Lessons Learned for Object-Oriented Projects
Measuring and Analyzing Customer Satisfaction
Conducting In-Process Quality Assessments
Conducting Software Project Assessments
Dos and Donts of Software Process Improvement
Using Function Point Metrics to Measure Software Process Improvements
A Project Assessment Questionnaire