Mit Technischen Reviews lassen sich Fehler bei der Software-Entwicklung frühzeitig entdecken und kostspielige Nachbesserungen vermeiden. In Teil 1 dieses Beitrags haben Sie erfahren, welche Vor- und Nachteile ein Review hat, wer daran beteiligt ist und wie es in der Praxis abläuft. In Teil 2 werden nun die Voraussetzungen für effektive Reviews vorgestellt; des Weiteren wird anhand von Beispielen aufgezeigt, welche Kosteneinsparungen mit Reviews möglich sind.
Voraussetzungen für effektive Reviews
Wille zu kontinuierlicher Verbesserung
Um erfolgreiche Reviews durchzuführen und mit ihnen Kosteneinsparungspotenziale zu realisieren, braucht eine Organisation den Willen, sich laufend zu verbessern und einen hohen Reifegrad (Maturity Level) zu erreichen. Um den Reifegrad einer Organisation zu bestimmen, wurde 1986 an der Universität Pittsburgh das Capability Maturity Model (CMM) entwickelt. Im Jahr 2002 wurde dieses durch das Capability Maturity Model Integration (CMMI) ersetzt. In Bild 1 ist eine vereinfachte Übersicht des CMMI dargestellt.
Bild 1: Der Reifegrad einer Organisation lässt sich nach dem fünfstufigen Capability Maturity Model Integration (CMMI) einordnen.
Um Level 2 im CMMI zu erreichen, muss eine Organisation im Rahmen der Qualitätsplanung Qualitätsstandards wie zum Beispiel Prüftechniken, Prozesse und Werkzeuge in einem Qualitätssicherungsplan definieren und weitgehend einhalten. Die wichtigste Voraussetzung für eine funktionierende Qualitätssicherung ist das Management Commitment. Fehlen Rückendeckung und Engagement des Managements, können QS-Maßnahmen nicht die gewünschte Wirkung erzielen. Ohne Management Commitment werden QS-Maßnahmen weniger ernst genommen und mit der Zeit mangelhaft bis gar nicht mehr durchgeführt. Der Mensch ist ein "Gewohnheitstier" und braucht Vertrauen und in der Regel auch einen gewissen Druck, um sich zu verändern. Zudem ist es bei Veränderungen am effektivsten, wenn das Management mit gutem Beispiel vorangeht.
Prüfplan
In der Qualitätsplanung wird u.a. festgelegt, wie die Qualitätsprüfung von Dokumenten, Quelltext und lauffähiger Software durchgeführt werden soll. Das Ergebnis dieser Planung ist der so genannte Prüfplan für Dokumente und Quelltexte sowie der Testplan für ausführbare Software. Da wir uns in diesem Artikel mit dem technischen Review beschäftigen, wird im Folgenden nur der Prüfplan für die statischen Prüfungen näher beleuchtet.
Im Prüfplan werden die Dokumente und Quelltexte aufgeführt, die mittels eines Reviews, eines Walk Throughs oder einer Code Inspection geprüft werden sollen. Grundvoraussetzung dafür ist, dass der Projektleiter weiß, welche Dokumente bzw. Arbeitsergebnisse in einem Projekt entstehen.
Die Kunst bei der Erstellung eines Prüfplans besteht darin, die Prüftechniken richtig und pragmatisch festzulegen. Es gibt weniger formelle Prüftechniken (Walk Through) und sehr formelle Prüftechniken (Review und Code Inspection). Welche Prüftechnik gewählt wird, hängt davon ab, welche Ziele mit der Prüfung verfolgt werden. Mögliche Ziele sind beispielsweise das Finden von Fehlern, der Erwerb von Fachwissen, die Förderung des Verständnisses fachlicher Zusammenhänge oder das Anstoßen einer Diskussion, an die sich eine Konsensentscheidung anschließen soll. Tabelle 1 zeigt, welche Methode für welche Zielsetzung am besten geeignet ist.
| Zielsetzung | Review | Code Inspection | Walk Through |
|---|---|---|---|
| Qualität beurteilen und hohe Qualität sicherstellen | x | x | |
| Hohe Qualität von Quelltexten sicherstellen | x | ||
| Mit möglichst wenig Aufwand Qualität prüfen (geeignet für Arbeitsergebnisse mit niedriger Kritikalität - auch für Quelltexte) | x | ||
| Erkennen von fachlichen Zusammenhängen | x | bedingt | x |
| Frühzeitiger Einbezug von anderen Teams, Teilprojekten, Endkunden etc., um Fehler, Unklarheiten und Sackgassen zu finden, aber auch um positive Aspekte zu bestätigen und eine gemeinsame Sichtweisen zu festigen (vor Realisierungsphase) | x | x | |
| Diskussion mit Konsensentscheidung, um dem Management eine Empfehlung vorlegen zu können (Arbeitsergebnis akzeptieren, zurückweisen etc.) | x | x | |
| Diskussion inkl. Entscheidung, welcher Weg (z.B. Lösungsvariante) eingeschlagen werden soll | x | ||
| Einhalten von Richtlinien, Standards und Anforderungen sicherstellen | x | x | |
| Reflektieren des eigenen Entwicklungsprozesses und Sammeln von Vorschlägen für dessen Verbesserung (optional) | x | x | |
| Überprüfen von Abläufen bzw. Prozessen | x | x | |
| Organisation bzw. Projektteam "sanft" in die statische Qualitätssicherung einführen | x | ||
|
Know-how-Transfer (Bei Review und Code Inspection ist dies mehr ein Nebeneffekt und nicht primäres Ziel.) |
(x) | (x) | x |
| Während Prüfsitzung Ermittlung bzw. Zuordnung von Kennzahlen zur Verbesserung der Prüfprozesse (bei Walk Throughs nur selten durchgeführt) | x | x | (x) |
| Während Prüfsitzung Ermittlung bzw. Zuordnung von Kennzahlen zur Verbesserung der Prozesse (gesamter Software-Lebenszyklus) | x | x |
Daneben gibt es noch eine Reihe weiterer statischer Prüfungstechniken, die je nach Situation (z.B. Projektkultur, Reifegrad, Kritikalität des Arbeitsergebnisses) eingesetzt werden können. Eine Minimalvariante ist das so genannte Stellungnahmeverfahren. Es verursacht nur einen geringen Aufwand, außerdem ist für die Durchführung keine Ausbildung notwendig. Hierbei sendet der Autor das Arbeitsergebnis an ausgewählte Personen, um von ihnen ein Feedback zu erhalten. In der Praxis bewährt sich diese informelle Prüfungstechnik allerdings meist nicht, da sie unverbindlich ist. Viele Gutachter nehmen sich deshalb nicht ausreichend Zeit und lesen die vorgelegten Dokumente meist nur oberflächlich durch. Außerdem hat alleine der Autor die…
