ODC uses data we already have to give us insight we do not have about the software engineering business.
ODC is a technology which extracts valuable information from the defect stream of any software engineering process to yield insight and diagnosis. ODC stands for Orthogonal Defect Classification - a particular method of categorization that has properties of measurement. ODC was invented using the term "defect", but technically works on any "change". Thus, design changes, customer issues, or trouble tickets are all good sources of information. ODC turns all these information rich events into a measurement system with analytics to gain insight. I like to contrast ODC techniques with the MRI that has changed modern medicine. It gives us an imaging methods to look inside and assess what is really going on.
Value:
ODC helps us make better decisions. Better engineering decisions, better management decisions, and better financial decisions. We produce better product, drive more sales, reduce operating costs and cycle time.
"Hi. My name is Ram and what I'd like to share with you is a comparison between the classical root cause analysis and the ODC style of root cause analysis in software. What's different between the two? What are the advantages? And so forth. There are several differences, but there are five principle difference that I'd like to focus on".
Ram Chillarege, 2008
How does ODC (Orthogonal Defect Classification) based root cause analysis (RCA) compare with the classical root cause analysis in terms of speed of RCA? The figure below with the four quadrants that divide cost and capability illustrates the basis differences.
Ram Chillarege, 2010
Orthogonal Defect Classification (ODC) has some unique properties when it comes to software engineering measurement. While there have been several categorization schemes and taxonomies which provide a description of the defect, ODC goes beyond just description. ODC extracts semantics from defects into specific classes so that the collective set of classes create a measurement system. It is these properties that makes ODC powerful and portable.
Ram Chillarege and Kathryn A. Bassin IBM Thomas J. Watson Research Center, 1995
Abstract -- The dynamics of software faults becoming failures during the use of a product is one of the least understood aspects regarding software faults today. This paper addresses this problem by analyzing the software triggers that activate faults into failures. The work is conducted on faults experienced by a large operating systems product for two years after release into the field. The results provide some of the first demonstration of the changing trigger distribution as a function of time after release. Specifically, this paper:
Defines triggers for the three primary verification activities: software review and inspection, function test and system test.
Provides three trigger distributions as a function of time, attributable to escapes to the field from each of the verification activities: review, function test and system test.
Illustrates that each trigger peaks at a different time from date of release. This is a key finding with significant implications in several aspects of software dependability and software engineering.
Dependable Computing for Critical Applications 5, Urbana-Champaign, 1995, Dependable Computing and Fault-Tolerant Systems Vol. 10, IEEE Computer Society
What Orthogonal Defect Classification (ODC) brings to software engineering can be captured in two words: INSIGHT and SPEED.
One leads to the other. But, they are not the only things that cause our eyes to light up and the organization hum with excitement. It's the power we gain through practical knowlege to affect the right engineering and process change that makes the difference.
Fault and Failure are two terms that are often confused. In every day life they conjure up similar images of something going wrong. Even in technical circles the terms are used interchangeably further distorting the differences. However, in technical terms they are two very different things. I say "things", but, really, only one of them comes close to being a thing - the other being an "event" and less of a thing. Let us study these a little deeper since we need to be more exacting for the purposes of defect analysis and software engineering.
Ram Chillarege and Kothanda Ram Prasad Chillarege Inc., 2002
Abstract --We present a case study of a product development retrospective analysis conducted to gain an understanding of the test and development process effectiveness. Orthogonal Defect Classification (ODC) is used as an analysis method to gain insight beyond what classical qualitative analysis would yield for the probable cause of delays during test.
1. ODC Trigger analysis provides the insight to understand the degree of blockage in test, probable cause, and consequences to the test and development process.
2.Trigger distribution changes with respect to time shows the stabilization of the product, and variation among components shows the systemic nature of issues.
3. The study makes nine specific inferences and recommendations based on these analyses to guide the engineering of future releases
What Orthogonal Defect Classification (ODC) brings to software engineering can be captured in two words: INSIGHT and SPEED.