ODC - Orthogonal Defect Classification

Results and Discussion

We present trigger data from an operating systems product that has been studied in the field for a duration of two years. The data is used to extract triggers by reading the defects and manually classifying them into the different possible triggers. Usually the fault reports contain a sufficient description of the situation under which the failure was caused, thereby providing us the input to identify the trigger. When information involving customer reported failures is captured in IBM, the reports are written in such a way as to make the translation to triggers a relatively simple task. The intent of the failure report text is to describe key elements of the failing scenario in order to facilitate two activities. First, to enable the failure to be recreated in order to isolate and diagnose the fault, and second, to enable the failure record to be easily found in the event the failure is reported by another customer.

While associating these customer reported failures with related development activities is not of primary importance to customers, it is an extremely valuable analysis from a defect prevention and removal viewpoint. Thus, extracting the 'real life' trigger from the manner in which the customer exercises the code from an external viewpoint is fairly straightforward.

Note that each of the triggers may belong to any one of the three groupings, review and inspection triggers, function test triggers or system test triggers. Once having established the trigger that occurred in the field, the grouping allows us to identify the most likely part of the process where the faults escaped detection.

There are two major kinds of results that we report in this section. The first has to do with the nature and characteristics of triggers. The second has to do with very specific inferences from the trigger distributions that we have found with this product. The first group of results address general issues, on how triggers are manifested in the field and how they could be used to improve predictions, diagnosis, process changes, and fault injection. The second kind of result has to do with the specific issue involving the operating system chosen and provides very practical insight on strategies that could be adopted given the nature of the data that we discuss.

• General Issues
• Specific Issues