Inspektion (Software-Entwicklung)

Inspektionen in der Software-Entwicklung sind eine formale Methode der Qualitätssicherung mit dem Ziel, frühzeitig und kostengünstig Fehler während der Software-Erstellung zu finden und zu beheben. Die Methode wurde 1972 im IBM-Labor Kingston, NY entwickelt und von M. E. Fagan im Jahre 1976 veröffentlicht.

Beschreibung

Während Software-Tests erst dann beginnen können, wenn ein lauffähiges Programm vorhanden ist (dynamischer Test), können Inspektionen bereits in sehr frühen Phasen des Entwicklungsprozesses durchgeführt werden (statischer Test). Hierbei werden die Dokumente, die bereits vorhanden sind, auf Abweichungen untersucht. Die Idee dahinter: Je früher ein Fehler gefunden wird, um so einfacher und kostengünstiger kann er korrigiert werden.

Im Folgenden werden diese Begriffe für zu inspizierende Entwicklungsdokumente benutzt (firmenspezifisch werden unterschiedliche Begrifflichkeiten verwendet):

• Zielsetzungen (englisch Objectives): Beschreibung der generellen Funktion des geplanten Produktes und der Ziel-Benutzergruppen.
• Spezifikation: Genaue Beschreibung der geplanten Funktionen und der externen Schnittstellen sowie der Qualitätsziele des Produkts.
• Strukturentwurf (englisch High-level design): Beschreibung der Funktion der einzelnen Module sowie ihrer Abhängigkeiten und Schnittstellen.
• Logikentwurf (englisch Low-level design): Detaillierte Beschreibung der Logik und der benutzten Algorithmen für jedes einzelne zu programmierende Modul. Häufig wird hier bereits eine formale Entwurfssprache verwendet.
• Kode: Der ausführbare Code in einer Programmiersprache.

Die Idee des Inspektionsverfahrens ist, je zwei bereits erstellte Dokumente miteinander zu vergleichen und Unterschiede festzustellen. Damit gibt es die folgenden Inspektionstypen:

• Interface-Inspektion: Vergleich von Zielsetzungen mit der Spezifikation
• High-level Design Inspektion (I0): Vergleich der Spezifikation mit dem Strukturentwurf
• Low-level Design Inspektion (I1): Vergleich des Strukturentwurfs mit dem Logikentwurf
• Code Inspektion (I2): Vergleich des Logikentwurfs mit dem Kode

Neben der Kodeentwicklung können auch weitere Bereiche dem Inspektionsprozess unterworfen werden, z. B. Testziele vs. Testplan (IT1), Testplan vs. Testfälle (IT2) oder Dokumentationsplan vs. Benutzerdokumentation. Die Kürzel (I0 etc.) zur Bezeichnung des Inspektionstyps wurden bereits von Fagan 1976 eingeführt.

Jede Abweichung zwischen den beiden jeweils inspizierten Dokumenten wird in einem Protokoll festgehalten. Dabei werden folgende Abweichungstypen dokumentiert (hier werden die englischen Begriffe genutzt, da sich diese im Sprachgebrauch eingebürgert haben):

• Major Error: Ein Design- oder Kodeproblem, das - wenn es so implementiert würde - zu einer Fehlfunktion im laufenden Programm oder zu einer Abweichung von den Zielsetzungen/Spezifikationen führen würde. Ein Major Error muss vom Autor korrigiert werden.
• Minor Error: Eine Verletzung von Programmierstandards, (Namens-)Konventionen oder Regeln, die nicht zu einer Fehlfunktion des Programms, aber in der Regel zu Schwierigkeiten bei der Wartung führen würde. Ein Minor Error muss vom Autor korrigiert werden.
• Suggestion: Kein Fehler, aber ein Verbesserungsvorschlag, der bei Implementation zu einer besseren Verständlichkeit oder klarerem Design führt. Die Empfehlung kann vom Autor akzeptiert oder verworfen werden.
• Open Problem: Eine Situation, die möglicherweise zu einem Fehler führen würde. Die Teilnehmer am Inspektionsmeeting können aber hierbei nicht zu einer Entscheidung kommen. Diese Situation muss außerhalb der Inspektionssitzung weiter verfolgt werden. Dies tritt häufig in Interface- oder Design-Inspektionen auf, wenn noch nicht alle notwendigen Details abgestimmt sind.

Anmerkung: Fagan hat in seiner ersten Veröffentlichung nur "major" und "minor" Fehler beschrieben. Die beiden anderen Abweichungstypen sind später hinzugekommen.

Teilnehmer

Jeder Teilnehmer an einer Inspektion hat die beiden Vergleichsdokumente vorab erhalten und sich entsprechend vorbereitet. Checklisten können die Vorbereitungsarbeit unterstützen.

Ein Inspektionsmeeting sollte aus Effizienzgründen zwischen drei und fünf Teilnehmer haben. Jeder Teilnehmer hat dabei eine spezifische Rolle:

• Der Moderator: Eine nicht an der Programmentwicklung beteiligte, aber für den Inspektionsprozess ausgebildete Person. Der Moderator leitet das Inspektionsmeeting und führt das Protokoll. Jede gefundene Abweichung wird protokolliert.
• Der Autor: Diejenige Person, die das zu inspizierende Dokument erstellt hat und die für die Korrektur verantwortlich ist.
• Der Leser: Ein Projektmitarbeiter (nicht der Autor!), der in seinen eigenen Worten durch das zu inspizierende Dokument führt. Das Material wird dabei nicht "vorgelesen", sondern der Leser beschreibt, wie er das Dokument verstanden hat. Dabei werden Verständnisprobleme sofort ersichtlich.
• Der Inspektor: Ein Projektmitarbeiter ohne spezielle Rolle. Hauptaufgabe des Inspektors ist es, Fehler zu finden. Ein Inspektor kann aus dem Entwicklungsteam oder einem anderen Projektbereich (z. B. Test, Dokumentationsentwickler, Wartungsmitarbeiter) kommen. Der Inspektor kann im Laufe des Inspektionsmeetings seine Rolle auch mit dem Leser wechseln.

Wichtig: Ein Mitarbeiter des Projektmanagements nimmt am Inspektionsmeeting nicht teil, damit eine offene Atmosphäre gewährleistet ist.

Datensammlung aus Inspektionen

Die Durchführung jeder Inspektion wird mit Anzahl der Teilnehmer, Dauer der Vorbereitung und des Inspektionsmeetings und Umfang des inspizierten Materials dokumentiert.

Jede gefundene Abweichung wird mit ihrem Typ (major, minor, suggestion, open) protokolliert. Fehler vom Typ "Major Error" können dabei direkt mit Fehlern verglichen werden, die in den späteren Testphasen gefunden werden. Damit kann man Fehlerstatistiken über den gesamten Entwicklungsprozess erstellen und dabei fehleranfällige Bereiche frühzeitig identifizieren. Meistens wird in Statistiken die Anzahl der gefundenen Fehler pro 1000 Kodierzeilen (kLoC) normiert.

Weiterhin kann pro Fehler eine Fehlerkategorie (z. B. Interface Problem, Logikproblem, Performanceproblem, Benutzbarkeitsproblem) festgehalten werden um häufig vorkommende Fehlerbereiche zu erkennen und Gegenmaßnahmen definieren zu können.

Eine Organisation, die intensiv Software-Inspektionen durchführt, kann im Laufe der Zeit aus den gesammelten Daten "Sollwerte" z. B. für zu findende Fehler pro Inspektionstyp oder für die optimale Dauer von Inspektionsmeetings ableiten. Werden diese Sollwerte signifikant verfehlt, sollte eine Inspektion wiederholt werden.

Die gesammelten Daten sollten dafür benutzt werden, aus gemachten Fehlern zu lernen und für die Zukunft diese Fehler zu vermeiden. Hierzu wurde ein eigener Prozess "Fehlervermeidung" (englisch defect prevention oder root cause analysis) entwickelt.

Erfolgsfaktoren

Um effektive Inspektionen zu erreichen, sollen folgende Faktoren berücksichtigt werden:

• Das Management steht hinter dem Verfahren
• Es ist ausreichende Zeit für Vorbereitung und Durchführung von Inspektionsmeetings geplant
• Die Anzahl der Teilnehmer ist auf 3-5 Personen begrenzt
• In der Inspektion wird gezielt nach Fehlern gesucht, keine Diskussion über Stilfragen oder Lösungen
• Alle Teilnehmer kennen ihre Rolle, der Moderator ist entsprechend geschult
• Das Inspektionsmeeting ist nicht signifikant kürzer als geplant und findet eine typische Anzahl von Abweichungen

Fagan zeigt in , dass Entwicklungsprojekte mit gutem Inspektionsprozess total weniger Ressourcen und meist auch weniger Zeit benötigen als Projekte ohne Inspektionen. Dabei wird der meist etwas höhere Aufwand in den Spezifikations- und Designphasen durch den geringeren Aufwand in den späteren Testphasen mehr als wett gemacht.

Neuere Entwicklungen

Mit dem Aufkommen von grafischen Entwicklungsumgebungen und Kodegeneratoren oder neuen Programmiertechniken (z. B. Paarprogrammierung) wird die Rolle der Kode-Inspektion immer geringer. Interface- und Design-Inspektionen haben allerdings weiterhin ihren Wert.

Agile Entwicklungsprozesse verwenden andere entwicklungsspezifische Dokumente als im herkömmlichen Wasserfallmodell (z. B. gibt es meist keine komplette Spezifikation), der Inspektionsprozess wird daher nur selten genutzt.

Literatur

• Inspections in Application Development - Introduction and Implementation Guidelines, IBM Form GC20-2000, Juli 1977
• Code Reading, Structured Walk-Throughs and Inspections, IBM Form GE19-5200, März 1978
• Improved Programming Technologies - An Overview, IBM Form GC20-1850, Oktober 1978
• Gerald M Weinberg, Daniel P. Friedman: Reviews, Walkthroughs and Inspections. In: IEEE Transactions on Software Engineering, Vol. 10, No. 1, Januar 1984
• C. L. Jones: A process-integrated approach to defect prevention, IBM Systems Journal, Vol. 24, No. 2 (1985)
• V. R. Basili, R. W. Selby: Comparing the Effectiveness of Software Testing Strategies. In: IEEE Transactions on Software Engineering, Vol. 13, No. 12, Dezember 1987
• K. E. Schnurer: Programminspektionen, Erfahrungen und Probleme. In: Informatik Spektrum, Band 11, Heft 6, Dezember 1988
• D. B. Bisant, J. R. Lyle: A Two-Person Inspection Method to Improve Programming Productivity. In: IEEE Transactions on Software Engineering, Vol. 15, No. 10, Oktober 1989
• Mario Winter: Reviews in der objekt-orientierten Softwareentwicklung. In: Softwareteschnik-Trends, Band 17, Heft 2, Mai 1997
• Ronald A. Radice: High Quality Low Cost Software Inspections, Paradoxicon Publishing, Andover, MA, ISBN 0-9645913-1-6 (2002)