ODC - Orthogonal Defect Classification

In-Process Measurement

Measurement on software defects has existed for a long time. In the industry, there is a substantial amount of effort in bean counting the defects and the accuracy and repeatability of this as an art form. The prediction of service costs using such bean counts can leave the casual scientist quite dumb founded. On the other hand, defect reports are not only used for bean counting, but often become the artifacts for postmortem studies on a release of software.

There is undoubtedly a broad spectrum in the use of defect information, and I illustrated this in figure 2. Two extremes are identified in the figure: One purely quantitative-i.e., numbers and the other purely qualitative - i.e., descriptive. As it happens, the two extremes are actually quite well defined and used. The middle part is where there is a large white space. Let us, for a moment, focus on the extremes.

The goal of statistical defect modeling, which includes what is commonly referred to as Software Reliability Growth, has been to predict the reliability of a software product. Typically, this may be measured in terms of the number of defects remaining in the field, the failure rate of the product, the short term defect detection rate, etc. [RB82, Goe85, MIO87]. Although this may provide a good report card, it often occurs so late in the development cycle that it is of little value to the developer. Ideally, a developer would like to get feedback during the process.

The goal of causal analysis is to identify the root cause of defects and execute actions so that the source of defects are eliminated. To do so, defects are analyzed, one at a time, by a team that is knowledgeable in the area. The analysis is qualitative and only limited by the range of human investigative capabilities. To sustain such pursuit and provide a focus for the activity, a process description has been found useful. At IBM, the Defect Prevention Process [MJHS90] and similar efforts elsewhere, have found causal analysis to be very effective in reducing the number of errors committed in a software project. The qualitative analysis provides feedback to developers that eventually improves both the quality and the productivity of the software organization [Hum89].

Defect Prevention can provide feedback to developers at any stage of their software development process. However, the resources required to administer this method are significant, although the rewards have proven to be well worth it. Moreover, given the qualitative nature of the analysis, the method does not lend itself well to measurement and quantitative analysis. Consequently, Defect Prevention, though not a part of the engineering process control model, could eventually work in conjunction with it.

• The Gap - cause and effect relationship
• The birth of ODC