The Defect Prevention Process

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:

1. Analyze defects or errors to trace the root causes.
2. Suggest preventive actions to eliminate the defect root causes.
3. Implement the preventive actions.

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:

1. Causal analysis meetings: These are usually two- hour brainstorming sessions conducted by technical teams at the end of each stage of the development process. Developers analyze defects that occurred in the stage, trace the root causes of errors, and suggest possible actions to prevent similar errors from recurring. Methods for removing similar defects in a current product are also discussed. Team members discuss overall defect trends that may emerge from their analysis of this stage, particularly what went wrong and what went right, and examine suggestions for improvement. After the meeting, the causal analysis leader records the data (defects, causes, and suggested actions) in an action database for subsequent reporting and tracking. To allow participants at this meeting to express their thoughts and feelings on why defects occurred without fear of jeopardizing their careers, managers do not attend this meeting.
2. Action team: The action team is responsible for screening, prioritizing, and implementing suggested actions from causal analysis meetings. Each member has a percentage of time allotted for this task. Each action team has a coordinator and a management representative (the action team manager). The team uses reports from the action database to guide its meetings. The action team is the engine of the process. Other than action implementation, the team is involved in feedback to the organization, reports to management on the status of its activities, publishing success stories, and taking the lead in various aspects of the process. The action team relieves the programmers of having to implement their own suggestions, especially actions that have a broad scope of influence and require substantial resources. Of course, existence of the action team does not preclude action implemented by others. In fact, technical teams are encouraged to take improvement actions, especially those that pertain to their specific areas.
3. Stage kickoff meetings: The technical teams conduct these meetings at the beginning of each development stage. The emphasis is on the technical aspect of the development process and on quality: What is the right process? How do we do things more effectively? What are the tools and methods that can help? What are the common errors to avoid? What improvements and actions had been implemented? The meetings thus serve two main purposes: as a primary feedback mechanism of the defect prevention process and as a preventive measure.
4. Action tracking and data collection: To prevent suggestions from being lost over time, to aid action implementation, and to enhance communications among groups, an action database tool is needed to track action status.

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.