ODC - Orthogonal Defect Classification

Combining ODC and Growth Modelling

Separate growth curves can be generated for each of the defect type categories, demonstrating their relative growth. This is not always practical, since some of the categories may be sparse - such as build/package/merge. It is often meaningful to collapse some of the categories, to better reflect a broader aspect of the development process. Function and algorithm defects integrate the design and low level design aspects of the product. Similarly, assignment and checking tend to be related to coding quality. A reasonable collapsing of the categories provides a few useful subdivisions of the data, making the relative comparison far more comprehensible.

  
Figure 3: ODC For Risk Assessment

However, when split by three groups of defect types, (shown below) there is much greater insight into what is happening in the development. Here, it is obvious that function and algorithm defects have stabilized, since that growth curve has already reached its knee. This is a sign that the design aspects of the products are stable.

On the other hand, the code quality represented by assignment and checking defects has not stabilized anywhere close to the degree that function defects have. Yet, clearly this growth curve has well passed the inflection point and the knee of the curve is predictable reasonably well, with the existing model. Between the function+algorithm growth curve and the assignment+checking growth curves, it looks as though the code parts of the product will stabilize, a little after the design aspects. The regular testing effort, if continued, should stabilize the product, with respect to the quality of code. On the other hand, this is not so with the third growth curve (miscellaneous or other), which combines user interface, documentation etc. This growth curve is clearly rising very rapidly and the prediction of when it will stabilize is much further out. It is also clear that these miscellaneous defects tend to dominate the overall growth curve in the top half of the figure.

Looking at the relative growth curves, a development manager could respond to what is occurring in the product by carefully choosing the right skill mix and staffing levels during the later parts of testing. It is evident that the lead developers, with the design skills, are not necessarily required at time and they can be moved on to the next release. Whereas, defects of type assignment+checking, representing coding issues, will be opened at current rates, given the testing effort, which will need appropriate skills to close them and staffing to handle the volume. However, the volume is dominated by other defects including documentation and interface problems. There is a major exposure here, since the end is not in sight, and the management has to deal with stabilizing this aspect of the product. Since the type of problems are known, management has the opportunity to respond to it by process changes and bringing the right type of skills and experience to bear. Also, the severity of the defects can be examined, to understand the risk of shipment without complete closure of the open problems.