Viele Organisationen prüfen erst in der Testphase, ob die von ihnen entwickelte Software den fachlichen und technischen Vorgaben entspricht. Sind diese Tests oberflächlich oder mangelhaft, werden manche Fehler erst während des produktiven Betriebs aufgedeckt. In diesen späten Stadien der Software-Entwicklung ist es sehr aufwändig und teuer, Fehler zu beheben. Es lohnt sich deshalb, Qualitätssicherungsmaßnahmen möglichst früh durchzuführen, am besten bereits schon vor der Testphase. Eine geeignete Maßnahme ist das "Technische Review" (hier: "Review"), das für die Prüfung von Dokumenten und Quelltexten eingesetzt wird. Verfügt eine Organisation über eine pragmatische Prüfplanung und ein reifes Projektmanagement, kann sie mit einem Review bis zu 25% der Gesamtprojektkosten eines Projekts einsparen.

In Teil 1 dieses Beitrags erfahren Sie, welche Vor- und Nachteile ein Review hat und wie es in der Praxis abläuft. Ergänzend werden zwei alternative Prüftechniken vorgestellt: die Code Inspection und der Walk Through. Vorab wird kurz beschrieben, welchen Platz das Review im Qualitätsmanagement der Software-Entwicklung einnimmt. In Teil 2 werden die Voraussetzungen für effiziente Reviews beschrieben, außerdem werden die Einsparungen, die Reviews ermöglichen, anhand von Beispielen vorgestellt.

Elemente des Qualitätsmanagements in der Software-Entwicklung

Die Elemente des Qualitätsmanagement-Systems (QMS) in der Software-Entwicklung sind:

• Qualitätsplanung
  Die Qualitätsplanung ist eng mit der Projektplanung verknüpft. Sie umfasst alle Tätigkeiten, welche die Qualitätsziele und -forderungen festlegen sowie die Forderungen, welche die Anwendung der Elemente eines QMS betreffen. Anders formuliert: Die Qualitätsplanung identifiziert die für das Projekt geltenden Qualitätsstandards (Qualitätslenkung) und beschreibt, wie diese zu überprüfen und zu sichern sind (Qualitätssicherung). Das Hauptergebnis der Qualitätsplanung ist der Qualitätsmanagementplan, der im Weiteren auch die Ausführungsprozesse sowie die zugehörigen Ressourcen zur Erfüllung der Qualitätsziele definiert.
• Qualitätslenkung
  Qualität zeigt sich als Übereinstimmung von Vorgaben und geprüften Ergebnissen. Qualitätslenkung bezeichnet demzufolge alle Maßnahmen wie Arbeitstechniken, Richtlinien etc. und Tätigkeiten, die ergriffen werden, um eine möglichst große Übereinstimmung zu erreichen. Das heißt: Qualitätslenkung ist Software Engineering live.
• Qualitätssicherung
  Im Rahmen der Qualitätssicherung (auch Qualitätsprüfung genannt) wird überprüft, ob die Anforderungen an ein Arbeitsergebnis (und im Endeffekt an ein Produkt) erfüllt werden. Die so genannte "Analytische Qualitätssicherung" unterteilt sich in statische und dynamische Prüfungen. Zu den statischen Prüfungen zählen u.a. die Dokumentenprüfung sowie das Audit von Prozessen und Strukturen; Ziel ist es, Fehler möglichst früh zu erkennen. Dynamische Prüfungen umfassen alle Bereiche des Testens von Systemen und Teilen davon.

Das Technische Review gehört zu den statischen Prüfungen und ist darauf ausgelegt, Fehler zu einem frühen Zeitpunkt zu erkennen (Bild 1).

Bild 1: Einbettung des Reviews im QM-System.

Das Review

Das Review lehnt sich eng an die Design und Code Inspections an, wie sie von M. Fagan 1976 bei IBM Federal System Division eingeführt wurden. Die hier vorgestellte Methode orientiert sich an Freedman/Weinberg 1990.

Grundidee

Bei einem Review versucht ein Team von Gutachtern (Reviewer), in einem Dokument, Programm oder in einem anderen Software-Produkt sämtliche Fehler und anderweitigen Probleme zu identifizieren. Während einer formalisierten Review-Sitzung stellen die Gutachter ihre Erkenntnisse vor. Damit ein Review erfolgreich ist, müssen die Gutachter gut vorbereitet zur Sitzung erscheinen; d.h. sie müssen das Arbeitsergebnis, das ihnen vorgelegt wurde, gründlich geprüft und ihre Ergebnisse sorgfältig festgehalten haben. Die eigentliche Prüfung des Arbeitsergebnisses findet also in der Vorbereitungsphase statt; in der Review-Sitzung werden die Ergebnisse der Gutachter "lediglich" gesammelt und protokolliert. Der Autor des zur Prüfung vorgelegten Arbeitsergebnisses sucht anschließend gezielt nach Problemlösungen und setzt diese um.

Vor- und Nachteile

Ein Review bietet folgende Vorteile:

• Hohe Qualität des geprüften Arbeitsergebnisses bzw. des Prüflings.
• Ein Review lässt sich bereits in der ersten Projektphase durchführen. Fehler, Missverständnisse sowie fachliche und technische Sackgassen werden frühzeitig entdeckt. Dadurch sind Kosteneinsparungen bis zu 25% möglich.
• Projektbeteiligte und andere Stakeholder werden als Gutachter, Moderatoren oder auch als Protokollführer aktiv einbezogen (auch projektübergreifend). Dadurch erfolgt ein Know-how-Transfer, außerdem kann die Zusammenarbeit der Beteiligten verbessert werden.
• Individuelle Maßstäbe wie z.B. der Detaillierungsgrad eines Konzepts werden nivelliert.

Ein Review hat folgende Nachteile:

• Die Gutachter benötigen für die Prüfung relativ lange (Vorbereitungszeit).
• Gekaufte Software lässt sich nur teilweise einem Review unterziehen. (Ist beispielsweise kein Einblick in den Quellcode möglich, kann dieser nicht geprüft werden.)

Ablauf eines Reviews

Bild 2: Ein Review unterteilt sich in sechs Schritte.

Planung