Defect prevention with orthogonal defect classification

"Learning from the past" to make systems more efficient in terms of cost and time is the hallmark of any engineering discipline. Prevention of defects is the "holy grail" of "learning's from the past" i.e. every product generation we learn from our defects and prevent it from recurring in the next generation. Taking this philosophy further "capturing defects in the earlier stage of the life cycle" is a means of preventing defects in the later stages of the product life cycle. Correction of defects is costly and the cost increases exponentially with every subsequent stage. This also impacts the cycle-time directly. Defect prevention then not only helps in cost reduction but also helps in cutting down the development time.

When we talk of software development, we are talking of hundreds of defects (in-process as well as post release). It would be very inefficient and time-consuming to have preventive action planning for each of them, as most of them could be symptoms of some common root cause. If we have to handle software defects of such large magnitude the best way then would be to classify them into patterns and then do root cause analysis on those patterns.

There are number of methodologies available in the industry to do this classification and IBM's ODC (Orthogonal defect classification) is one such methodology. The methodology classifies each defect into orthogonal (mutually exclusive) attributes some technical and some managerial. These attributes provide all the information to be able to sift through the enormous volume of data and arrive at patterns on which root-cause analysis can be done. This coupled with good action planning and tracking can achieve high degree of defect reduction and cross learning.

The questions always then are -- can methodologies be really applied to do software defect prevention in a structured way? How can an abstract defect classification mechanism really help to identify patterns? How does one measure the effectiveness of such actions? Who should do these activities? How does all this fit into the existing process framework? This paper is an attempt to answer these questions by sharing the experiences of using the IBM-ODC methodology in a case study of real-life software development project (DVD player product). The motivation of this paper is not to discuss the ODC methodology itself but rather to demonstrate through a case study, the structured process for defect prevention using some attributes of ODC for defect classification and its related interpretations for causal analysis, action planning and results tracking. The fitments of the scheme into the bigger picture of defect prevention, cross learning and mapping to elements of the SEI-CMMI framework are some of the highlights of this paper. The paper concludes with a summary of learning's and some points to ponder.