One Day ODC Workshop

Learn Technology, Understand Applications, Plan Implementation:
One Day Workshop for Architects, Managers, Developers and Testers.

  • Understand basic ODC Concepts, and share real-world experiences. 
  • Case studies provide an insight into the data, analysis, and conclusions.
  • Discuss implementation for specific projects.
  • Who does what?  When? Tools? Analysis? Engagments?
  • Typical $ value gained?
  • Additional burden? How much? Why so little?
  • In-process ? or Retroactive ?
  • Compare ODC to other methods.
  • ODC in Agile?  How?  Why?
  • What risk am I taking in Agile without ODC?
  • How do avoid Turbulence that spills over from one Sprint to the next?


Orthogonal Defect Classification - ODC


What is Orthogonal Defect Classification?

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.


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.

ODC RCA Performance

Ram Chillarege
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.

There is a related video on how ODC based root cause analysis is different from classical RCA -- that may also be of interest to you. ["5 Difference" Video]


SRE Handbook - ODC Chapter

Edited by Michael R. Lyu. Published by IEEE Computer Society Press and McGraw-Hill Book Company

Chapter 9. Orthogonal Defect Classification

Ram Chillarege Excript from the table of contents


This book has been out of print for a while.  Write to us to get literature on ODC - or material that is in the ODC Chapter.



5 Differences between Classical and ODC Root Cause Analysis in Software

Ram Chillarege


Transcript of video clip.


"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".

ODC Properties

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.

Software Triggers as a Function of Time - ODC on Field Faults

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:
  1. Defines triggers for the three primary verification activities: software review and inspection, function test and system test.
  2. 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.
  3. 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