Orthogonal Defect Classification

from Wikipedia, the free encyclopedia

Orthogonal Defect Classification (ODC) is a model for classifying errors in software development that was developed at IBM . By classifying errors according to certain categories and attributes, connections between the development process and the cause of errors can be shown. On the basis of the knowledge gained, measures to improve the development process can be derived.

concept

ODC belongs to the class of the root cause analysis ( root cause analysis ), and is a technique from the field of software engineering . In contrast to the classic cause analysis, the individual errors are not analyzed in detail and in a time-consuming manner, but are semantically classified using predefined categories.

Error classification

With the error classification with ODC, the error is classified twice - when the error is detected according to the criteria of the so-called " opener section "; after the repair then again after those of the " Closer Section ". In the opener section , the focus is on the circumstances that led to the misconduct - so these can also be reproduced later. The cause that led to the error is determined in the Closer Section . The Opener Section offers three categories, the Closer Section five.

Opener Section

The opener section consists of the following categories:

  • Activity : When was an error found? This does not mean the date, but the point in time within the development process or the product life cycle.
Example: design or code review, module, component or system test.
  • Trigger : How was the error found? The trigger must not be confused with the symptom, i.e. the effect of an error or the malfunction of a program.
Example: An error in a counting loop causes an incorrect value to be displayed on the user interface. The symptom is that the wrong value is displayed. In this case, the trigger could have been a boundary value test. The trigger is, so to speak, the “catalyst” that turns an error into a malfunction.
  • Impact : What effects would there be for the customer or what could have happened if the error had only been discovered at the customer's site in relation to ISO 9126 ?

Closer section

The Closer Section consists of the following categories:

  • Target : Which object was improved so that the bug could be fixed?
  • Defect Type : What exactly had to be improved so that the error could be fixed?
Example: assignment , interface , algorithm
  • Qualifier : Specifies whether an error was corrected due to: Missing, incorrect or redundant source code .
  • Age : Specifies whether the error occurred in a new, basic, rewritten ( refactored code ) or error-corrected code branch.
  • Source : Specifies whether the error within the source code originates from in-house development, reuse, porting or from a third-party provider.

Opportunities for evaluations with ODC

The Orthogonal Defect Classification as a representative of software metrics is suitable due to its classification of error data to be able to create evaluations with respect to the respective software development process on the basis of an ODC database . The ODC concept provides a total of two methods with which the reliability and quality of a test and development process for software can be analyzed and evaluated:

  1. Root Cause Analysis (RCA) and
  2. Statistical Defect Modeling (SDM).

Root cause analysis

As already mentioned at the beginning, the RCA belongs to the subgroup of root cause analysis of errors in software engineering . The ODC-RCA is characterized by the fact that, compared to other methods of root cause analysis, it can not only be carried out much more efficiently or faster, but also more precisely. This is due to the structuring of the respective software error in the form of the ODC attributes for the opener and closer section. During the practical implementation of an ODC-RCA, the values ​​for the ODC attributes of the opener and closer are analyzed and evaluated. By looking at the ODC values ​​and linked ODC attributes, the RCA operator can localize and determine a potential cause of error more precisely. Despite the performance gain through the ODC-RCA, the general procedure of the RCA can be classified as relatively complex and time-consuming. For this reason, an (ODC) RCA should, if possible, be carried out by an experienced software developer and primarily for higher-priority or relevant software errors .

Statistical Defect Modeling

In contrast to the ODC-RCA, in which only a single software error is examined more closely, the SDM includes a whole set of ODC data in the evaluation. In SDM, the software errors are machine-analyzed in their structured ODC form, either by combining the ODC attributes of the opener and closer sections with one another or with other determinants such as: B. development period, product components, projects, etc., can be set in relation. The results of these evaluations do not provide information about the origin of an individual software error like the ODC-RCA , but rather graphically represent the current state of the development process with regard to reliability and quality of the respective test or development phases.

Diagrams or so-called inference trees are used to display the ODC data evaluation within the framework of the SDM . Due to the structured form of the ODC database, these charts and inference trees can be generated and evaluated automatically.

Difficulty using ODC

Since error classification with ODC is a process carried out by people, there is a risk that the classification of an error will lead to differences due to different subjective views. This can be positively influenced by a targeted adaptation of the attributes to the respective circumstances in the development for the individual categories in the opener and closer section . Therefore, the individual attributes of a category should be orthogonal to one another in order to keep the space for any possible interpretation by the individual small.

See also

Individual evidence

  1. ↑ a b Ram Chillarege et al .: Orthogonal defect classification - A concept for in-process measurements. In: IEEE Transactions on Software Engineering. No. 18, 1992, pp. 943-956
  2. ↑ Ram Chillarege: ODC - a 10x for Root Cause Analysis. 2006
  3. ↑ a b Archived copy ( memento of the original dated December 6, 2013 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice. @1@ 2Template: Webachiv / IABot / www.odc2b.com
  4. ↑ Archived copy ( Memento of the original dated December 6, 2013 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice. @1@ 2Template: Webachiv / IABot / www.odc2b.com
  5. ↑ Archived copy ( Memento of the original dated December 6, 2013 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice. @1@ 2Template: Webachiv / IABot / www.odc2b.com

literature

  • Ram Chillarege et al .: Orthogonal defect classification - A concept for in-process measurements . In: IEEE Transactions on Software Engineering . No. 18 , 1992, p. 943-956 ( Article ).
  • Ram Chillarege: ODC - a 10x for Root Cause Analysis . 2006 ( PDF file ).
  • Pankaj Jalote et al .: Using defect analysis feedback for improving quality and productivity in iterative software development . In: Proceedings of the Information Science and Communications Technology (ICICT 2005) . 2005, p. 701-713 ( PDF file ).
  • M. Butcher et al .: Improving software testing via ODC: Three case studies . In: IBM System Journal . No. 41 , 2002 ( article ).