Orthogonal Defect Classification

Orthogonal Defect Classification (ODC) ist ein Modell zur Klassifikation von Fehlern in der Softwareentwicklung, das bei IBM entwickelt wurde. Durch die Klassifikation von Fehlern nach bestimmten Kategorien und Attributen lassen sich Zusammenhänge zwischen dem Entwicklungsprozess und der Ursache von Fehlern aufzeigen. Anhand der dabei gewonnenen Erkenntnisse lassen sich Maßnahmen zur Verbesserung des Entwicklungsprozess ableiten.

ODC gehört zur Klasse der Ursachenanalyse (Root cause analysis) und ist eine Technik aus dem Bereich Softwaretechnik. Im Gegensatz zur klassischen Ursachenanalyse werden hierbei die einzelnen Fehler nicht detailliert und zeitaufwändig analysiert, sondern mittels vordefinierten Kategorien semantisch klassifiziert.

Bei der Fehlerklassifikation mit ODC wird der Fehler zweimal klassifiziert – bei Feststellen des Fehlers nach den Kriterien der sogenannten „Opener Section“; nach dem Beheben dann noch einmal nach denen der „Closer Section“. In der Opener Section liegt der Fokus auf den Umständen, die zum Fehlverhalten geführt haben – so können diese auch später reproduziert werden. In der Closer Section wird die Ursache bestimmt, die zu dem Fehler geführt haben. Die Opener Section bietet drei Kategorien, die Closer Section fünf.

Die Opener Section besteht aus den Kategorien:

• Activity: Wann wurde ein Fehler gefunden? Hierbei ist nicht das Datum gemeint, sondern der Zeitpunkt innerhalb des Entwicklungsprozesses bzw. des Produktlebenszyklus.

Beispiel: Design- oder Codereview, Modul-, Komponenten- oder Systemtest.

• Trigger: Wie wurde der Fehler gefunden? Hierbei darf der Trigger nicht mit dem Symptom, also der Auswirkung eines Fehlers bzw. dem Fehlverhalten eines Programms verwechselt werden.

Beispiel: Durch einen Fehler in einer Zählschleife wird ein falscher Wert auf der Benutzeroberfläche angezeigt. Das Symptom ist dabei die Anzeige des falschen Wertes. Der Trigger könnte in diesem Fall ein Boundary-Value Test gewesen sein. Der Trigger ist sozusagen der „Katalysator“, der einen Fehler zu einem Fehlverhalten werden lässt.

• Impact: Welche Auswirkungen ergeben sich für den Kunden bzw. hätten sich ergeben können, wenn der Fehler erst beim Kunden entdeckt worden wäre in Bezug auf ISO 9126?

Die Closer Section besteht aus den Kategorien:

• Target: Welches Objekt wurde verbessert, damit der Fehler behoben werden konnte?
• Defect Type: Was genau musste verbessert werden, damit der Fehler behoben werden konnte?

Beispiel: Zuweisung, Schnittstelle, Algorithmus

• Qualifier: Spezifiziert, ob die Behebung eines Fehlers aufgrund von: Fehlendem, fehlerhaftem oder überflüssigem Quellcode erfolgte.
• Age: Spezifiziert, ob der Fehler in einem neuen, basis, umgeschriebenen (refactored code) oder fehlerbereinigtem Codezweig auftrat.
• Source: Spezifiziert, ob der Fehler innerhalb des Quellcodes aus Eigenentwicklung, Wiederverwendung (reuse), Portierung oder von einem fremden Anbieter stammt.

Die Orthogonal Defect Classification als ein Vertreter der Softwaremetriken eignet sich durch seine Klassifizierung von Fehlerdaten dazu, auf Basis eines ODC-Datenbestandes Auswertungen bzgl. des jeweiligen Softwareentwicklungsprozesses erstellen zu können. Dabei sieht das ODC-Konzept insgesamt zwei Methoden vor, mit denen die Zuverlässigkeit und Qualität eines Test- und Entwicklungsprozesses für Software analysiert und bewertet werden kann:

1. Root Cause Analysis (RCA) und
2. Statistical Defect Modeling (SDM).^[1]

Wie bereits zu Beginn erwähnt, zählt die RCA zur Untergruppe der Ursachenanalyse eines Fehlers im Bereich Softwaretechnik. Die ODC-RCA zeichnet sich dadurch aus, dass sie im Vergleich zu anderen Methoden der Ursachenanalyse nicht nur wesentlich effizienter bzw. schneller, sondern auch genauer durchzuführen lässt. Dies ist auf die Strukturierung des jeweiligen Softwarefehlerfalls in Form der ODC-Attribute zur Opener und Closer Section zurückzuführen.^[2] Bei der praktischen Durchführung einer ODC-RCA werden die Werte zu den ODC-Attributen der Opener und Closer analysiert und ausgewertet. Durch die Betrachtung der ODC-Werte und miteinander verknüpfter ODC-Attribute kann der RCA-Durchführende eine potenzielle Fehlerursache genauer lokalisieren und bestimmen. Trotz des Leistungsgewinns durch die ODC-RCA, ist das generelle Verfahren der RCA als relativ aufwendig und zeitintensiv einzuordnen. Aus diesem Grund sollte eine (ODC-)RCA möglichst durch einen erfahrenen Software-Entwickler und vorrangig für höher priorisierte bzw. relevante Softwarefehler durchgeführt werden.^[3]

Im Gegensatz zur ODC-RCA, bei der lediglich ein einziger Softwarefehler genauer betrachtet wird, bezieht das SDM einen ganzen Bestand an ODC-Daten in die Auswertung ein. Beim SDM werden die Softwarefehler in ihrer strukturieren ODC-Form maschinell analysiert, indem entweder die ODC-Attribute der Opener und Closer Section zueinander oder mit anderen Determinanten, wie z. B. Entwicklungszeitraum, Produktkomponenten, Projekte usw., in Relation gesetzt werden. Die Ergebnisse dieser Auswertungen geben nicht wie die ODC-RCA Auskünfte über die Herkunft eines einzelnen Softwarefehlers, sondern stellen den IST-Zustand des Entwicklungsprozesses in Bezug auf Zuverlässigkeit und Qualität der jeweiligen Test- bzw. Entwicklungsphasen allgemein grafisch dar.^[3]

Zur Darstellung der ODC-Datenauswertung im Rahmen des SDM werden Diagramme oder auch so genannte Inferenzbäume verwendet.^[1][4][5] Aufgrund der strukturierten Form des ODC-Datenbestandes können diese Charts und Inferenzbäume automatisch erzeugt und ausgewertet werden.

Da es sich bei der Fehlerklassifikation mit ODC um einen von Menschen durchgeführten Prozess handelt, besteht die Gefahr, dass aufgrund von unterschiedlichen subjektiven Auffassungen die Klassifikation eines Fehlers zu Unterschieden führt. Dies kann durch eine gezielte Anpassung der Attribute an die jeweiligen Umstände in der Entwicklung für die einzelnen Kategorien in der Opener und Closer Section positiv beeinflusst werden. Daher sollten die einzelnen Attribute einer Kategorie orthogonal zueinander sein, um somit den Raum für eine etwaige Interpretation durch den Einzelnen gering zu halten.

• Fehlerklassifizierung

1. ↑ ^{a b} Ram Chillarege et al.: Orthogonal defect classification -- A concept for in-process measurements. In: IEEE Transactions on Software Engineering. Nr. 18, 1992, S. 943–956
2. ↑ Ram Chillarege: ODC - a 10x for Root Cause Analysis. 2006
3. ↑ ^{a b} Archivierte Kopie (Memento des Originals vom 6. Dezember 2013 im Internet Archive)  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.odc2b.com
4. ↑ Archivierte Kopie (Memento des Originals vom 6. Dezember 2013 im Internet Archive)  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.odc2b.com
5. ↑ Archivierte Kopie (Memento des Originals vom 6. Dezember 2013 im Internet Archive)  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.odc2b.com

• Ram Chillarege et al.: Orthogonal defect classification -- A concept for in-process measurements. In: IEEE Transactions on Software Engineering. Nr. 18, 1992, S. 943–956 (Artikel). 
• Ram Chillarege: ODC - a 10x for Root Cause Analysis. 2006 (chillarege.com [PDF]). 
• 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, S. 701–713 (iitk.ac.in [PDF]). 
• M. Butcher et al.: Improving software testing via ODC: Three case studies. In: IBM System Journal. Nr. 41, 2002 (Artikel).