Orthogonal Defect Classification - different approach to software defect classification

Software quality has always been a concern and bottleneck to enabling change in business. It is belived that software has not been able to keep pace with improvement in hardware and services, even though it is the biggest part of the the total IT cost a business has to  bear. There has been a lot of research in the area of software reliability and measurement in academics and industry. ODC or orthogonal defect classification is one of such schemes that came from IBM research almost 10 years ago. To understand ODC better lets understand the two proven way of measuring software reliability, Statistical defect model and qualitative causal analysis.
Statistical defect models are used to predict the software reliability by classifying the defects in the field, its severity and growth rate and detection rate. This is sort of defect report card which keeps track of whats happening but has very little value to the team that is developing the product. On the other hand, Root Cause Analysis or RCA is  a defect prevention method, using which defects are analyzed individually by knowledgeable person. The qualitative analysis of each defect is very human intensive and limited to the human expertise and not to mention very expensive.
ODC bridges the gap between the two extremes mentioned above. The technique was inspired by the study conducted at IBM which identified the measurable cause and effect relationships (semantics of defects and their net result)  in the software development process. When defects were uniquely categorized by a set of defect types representing the semantics of the fix/solutions, it was possible to relate changes in the rleibaility growth curve to the specific type of defects. These defect types could be associated with the various activities of the software development process. It was found that the group that got more than average intial defect had a 's' curve inflected. Also some functional defects started to question design problems. These kinds of in-process measurements are key to shifting development strategies on time. ODC helps capture the semantics by providing the categorization of a defect into classes that collectively point to the process that needs attention.
What do you need for ODC to work?
A well designed defect tracking tool such as IBM Rational ClearQuest, eucation for the team and process to apply in specific area are critical to the success. More information on ODC and its application can be found at IBM Research: http://www.research.ibm.com/softeng/ODC/ODC.HTM