 |
s.a. Populäre Irrtümer in der Reviewtechnik (pdf, 59 kB)
Mit einem Software-Review bzw. Software-Inspektion versucht ein Team von Gutachtern, Fehler und sonstige Probleme in einem Programm oder einem anderen Software-Produkt zu finden. Was bei Reviews zu beachten ist und welchen Nutzen sie bringen, können Sie im folgenden Artikel nachlesen (aus Integrata Training News 4/2000):
Reviewtechnik –
Software-Reviews optimal durchführen
Leider gibt es keinen Nobelpreis für Informatik, denn Michael Fagan von IBM hätte ihn verdient. Als er 1976 seine Reviewtechnik veröffentlichte, hatte er damit die kosteneffektivste manuelle Qualitätstechnik geschaffen. Auch heute, fast 25 Jahre später, setzen 80% der Softwareunternehmen in den USA Reviews ein, wie eine Umfrage ergab. Natürlich sind computergestützte Qualitätstechniken wie Modultests, statische Analysetools usw. unverzichtbar. Aber nach wie vor sind die Kollegen eines Softwareentwicklers die idealen Prüfer, wenn es darum geht, Fehler in Textdokumenten oder Programmen zu finden.
Die optimale Inspektionsrate
Reviews sind dann am erfolgreichsten, wenn die Reviewer gründlich vorbereitet zur Sitzung kommen. Ca. 80% der Fehler, die durch Reviews entdeckt werden können, finden die Reviewer schon in der Vorbereitungsphase! In der eigentlichen Reviewsitzung werden also (nur) noch die restlichen 20% Fehler gefunden. Dies zeigt, dass die gründliche Vorbereitungsphase ein kritischer Erfolgsfaktor ist. Es gibt Erfahrungswerte, wie viel Zeit sich ein Reviewer für die Vorbereitung nehmen muss, um die oben erwähnten 80% der Fehler finden zu können. Für Programme ist dies in der Regel eine Stunde für 100 – 150 NLOCs ("non-commentary lines of code"). Dies gilt ziemlich unabhängig von der Programmiersprache. Für Textdokumente ist diese Prüfgeschwindigkeit, oft auch "optimale Inspektionsrate" genannt, stärker abhängig von der Art des zu prüfenden Dokuments. Sie beträgt oft nur einige wenige Seiten pro Stunde und liegt bei extrem kritischen Dokumenten wie z.B. Anforderungsdefinitionen für ein neues Flugzeug bei einer Seite pro Stunde oder sogar noch darunter!
Warum man mit Reviews Kosten einsparen kann
15 kritische Erfolgsfaktoren müssen bei Reviews beachtet werden. Der Lohn ist nicht nur eine erhebliche Verbesserung der Softwarequalität, sondern auch eine bessere Produktivität der Projektteams. Viele Firmen berichten von Produktivitätssteigerungen im Bereich von 25 – 35%! Wo diese Einsparungen in einem Softwareprojekt möglich sind, zeigt die Abbildung mit den verschiedenen Phasen eines Softwareprojekts. In jeder dieser Phasen gibt es einen Anteil an Tätigkeiten, der nur deshalb nötig ist, weil Menschen nicht von vornherein absolut fehlerfrei arbeiten können (in der Abb. mit "Rework" bezeichnet). Wenn zum Beispiel im Integrationstest ein Fehler gefunden wird, kann es sein, dass sich dieser Fehler als Designfehler herausstellt. Dann muss ein Designdokument geändert werden, einige Funktionen müssen neu programmiert werden, Modultests müssen nachgeholt werden, und dann erst kann der Integrationstest wieder aufgenommen werden. Dieser ganze Aufwand wäre nicht nötig gewesen, wenn der Fehler bei einem Review des Designdokuments gefunden worden wäre! Ca. 2/3 des Rework-Anteils eines Softwareprojektes können so durch Reviews "wegoptimiert" werden. |
|
|
Nutzen in der Wartungsphase
Ein weiterer Nutzen von Reviews zeigt sich, nachdem das Softwareprojekt abgeschlossen ist. Mit dem Auslieferungstermin ist der Software-Lebenszyklus bekanntlich nicht zuende, denn in der Wartungsphase wird oft sogar noch mehr Aufwand in die Software investiert als für die Ersterstellung nötig war. Software, die bei der Ersterstellung einem Review unterzogen wurde, verursacht weit geringere Wartungskosten als Software, bei der dies nicht geschah. Die Wartungskosten können durchaus um den Faktor 10 bis 30 niedriger ausfallen!
Dazu ein Beispiel aus England: in der Firma ICI wurden Reviews eingeführt und im Laufe der Zeit bei 400 Programmen angewandt. Später wurden die Reviews wieder eingestellt, vermutlich, weil man den Nutzen von Reviews nicht eingesehen hatte und "Kosten senken" wollte. Ein Jahr danach wurden die Auswirkungen dieser Entscheidung untersucht und dabei festgestellt, dass die 400 Programme, bei denen Reviews durchgeführt worden waren, nur ein Zehntel der Wartungskosten verursacht hatten wie 400 vergleichbare Programme ohne Reviews.
Das heißt mit anderen Worten, wenn der Zeithorizont der Betrachtung nur bis zum Auslieferungstermin der Software reicht, dann können "nur" die oben erwähnten Produktivitätssteigerungen von 25 – 35% erreicht werden. Wird aber die Wartungsphase mit berücksichtigt, z.B. weil die Software von der eigenen IT-Abteilung gewartet werden muss, dann tragen Reviews noch deutlich darüber hinaus zur Kostenreduktion im eigenen Unternehmen bei.
Andere Review-Arten
Die in diesem Artikel beschriebenen Reviews werden oft "Inspektionen" oder "Fagan’s inspections" genannt. Andere Review-Arten sind Walkthroughs/Presentation Reviews, in denen der Autor den Inhalt eines Dokuments vorstellt, und Management-Reviews/Projektstatus-Reviews, in denen entschieden wird, ob und wie etwas durchgeführt wird. Wenn es darum geht, Fehler in Textdokumenten oder Programmen zu finden, haben sich die "Fagan’s inspections" als mit Abstand beste Methode herausgestellt. ...
[im Original-Artikel folgen Hinweise zum Integrata Seminar Nr. 2004.]
Autor:
Peter Rösler, Dipl.-Informatiker
Berater und QS-Beauftragter |
|
