Warum Prüfen 50-mal länger dauert als Lesen und andere Überraschungen aus der Welt der Software-Reviews
Dipl.-Inform. Peter Rösler
freiberuflicher Trainer für Reviewtechnik, München
ros@reviewtechnik.de
Zusammenfassung:
In Schulungen zu Software-Reviews steht der Trainer immer dann vor einer didaktischen Herausforderung, wenn es darum geht, die von Fachleuten genannten Zahlenangaben zu begründen, die von den Teilnehmern intuitiv in ganz anderer Größenordnung eingeschätzt werden.
Zwei dieser Zahlenangaben, die den Teilnehmern üblicherweise besonders unplausibel vorkommen, sind: 
1. Die optimale Inspektionsrate für Textdokumente beträgt nur ca. 1 Seite pro Stunde (und liegt damit um ca. den Faktor 50 unter der reinen Lesegeschwindigkeit).
2. Das durchschnittliche Review findet nur ca. 4-7% der im Dokument vorhandenen Fehler.
Im Beitrag wird gezeigt, mit welchen Kurzexperimenten und Schätzungen, die von den Teilnehmern selbst durchgeführt werden, obige Zahlenangaben zumindest in der Größenordnung als durchaus plausibel dargestellt werden können.
Schlüsselbegriffe
Software-Reviews, optimale Inspektionsrate, Zeitpunkt der Fehlerentdeckung, konstante Fehlerentdeckungsrate,  Effektivität von Reviews
1	Einführung
Die in diesem Beitrag betrachteten Software-Reviews werden oft auch als „Software-Inspektionen“ oder „Fagan/Gilb style inspections“ bezeichnet. Hauptziel dieser Reviews ist es, Fehler in Textdokumenten oder Programmen frühzeitig zu finden. Nicht betrachtet werden 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. 
Eine ausführliche Darstellung der Phasen eines Software-Reviews (Planning, Kickoff, Individual Checking, Logging Meeting, Edit, Follow-up, Exit) findet sich im Buch "Software Inspection" [1], dem ersten Lehrbuch zu Software-Inspektionen. Bemerkenswert ist, dass ca. 80% der Fehler, die das Reviewteam insgesamt entdeckt, schon in der Phase „Individual Checking“ (Vorbereitungsphase) gefunden werden [1].
Die eigentliche Reviewsitzung („Logging Meeting“) deckt nur ca. 20% der Fehler auf, und zwar auch nur dann, wenn in der Reviewsitzung das sogenannte „Double Checking“ durchgeführt wird (eine erneute Fehlersuche, die ungefähr genauso viel Zeit benötigt wie die Fehlersuche in der Phase „Individual Checking“). Da in den meisten durchgeführten Reviews auf „Double Checking“ verzichtet wird, werden in der Praxis eher 95% der durch das Reviewteam entdeckten Fehler in der Phase „Individual Checking“ gefunden [2].
Für die Zwecke dieses Beitrags wird vereinfachend davon ausgegangen, dass alle entdeckten Fehler in der Phase „Individual Checking“ gefunden werden, und dass im „Logging Meeting“ keine neuen Fehler entdeckt werden, sondern nur die gefundenen Fehler zu Protokoll gegeben werden.
Mit Software-Reviews kann man sowohl Textdokumente, als auch Programme prüfen. Die in diesem Beitrag genannten Zahlenangaben beziehen sich vor allem auf Reviews von Textdokumenten und nur teilweise auf Code-Reviews.
An den vorgestellten Kurzexperimenten und Schätzungen haben  bisher ca. 700 Teilnehmer von 59 Reviewtechnik-Seminaren und -Vorträgen im Zeitraum von Oktober 2004 bis August 2008 teilgenommen. Die Kurzexperimente und Schätzungen waren Teil von Trainings und Vorträgen und die Teilnehmer stellen nicht unbedingt eine repräsentative Stichprobe der Grundgesamtheit dar. Die Kurzexperimente und Schätzungen können daher nicht den Anspruch erheben, die genannten Zahlenangaben zu Reviews methodisch sauber zu begründen, für den Zweck der Wissensvermittlung haben sie sich aber als sehr nützlich erwiesen. 
2	Lese- und Prüfgeschwindigkeiten im Vergleich
2.1	Die optimale Inspektionsrate
In der Phase „Individual Checking“ prüft ein Reviewer das zu prüfende Dokument, indem er alle ihm zur Verfügung stehenden sinnvollen Prüfstrategien anwendet (z.B. erstmaliges Durchlesen für einen Überblick, Lesen der relevanten Vorgängerdokumente, genaues Durchlesen, Nachdenken und Wort-für-Wort-Prüfung, Abarbeiten von Checklistenfragen etc.) Es gibt Erfahrungswerte, wie viel Zeit dafür nötig ist. Für Programme ist dies in der Regel eine Stunde für 100 bis 150 NLOCs ("non-commentary lines of code").
Für Textdokumente beträgt diese Prüfgeschwindigkeit – oft auch "optimale Inspektionsrate" genannt – laut dem Buch "Software Inspection" [1] ca. 1 Seite pro Stunde. Als Bandbreiten für die optimale Inspektionsrate werden in [3] 1 ± 0,8 Seiten pro Stunde angegeben  (1 Seite = 300 Wörter [3]).
Dieser niedrige Wert von ca. 1 Seite pro Stunde wird von den meisten Softwareentwicklern auf den ersten Blick als unglaubwürdig angesehen. Mit folgenden Kurzexperimenten und Schätzungen kann dieser Wert aber als in der Größenordnung richtig dargestellt werden:
In einem Kurzexperiment prüfen die Teilnehmer einen typischen Spezifikationstext auf „minor defects“, also formale Fehler, Rechtschreibfehler, optisches Erscheinungsbild, angemessene Schriftgröße und Einrückungen etc. (Länge des Textes: 1/3 Seite, Textausschnitt: „...For each flight in the database, this configuration file will be examined line by line. The assignment part of the first rule for which the condition part matches the carrier and trip number will be used as the new load control value. ...”). Sobald ein Teilnehmer mit seiner Prüfung fertig ist, wird seine „minor defects“-Inspektionsrate berechnet.
729 Softwareentwickler führten bisher dieses Kurzexperiment durch. Der Mittelwert dieser „minor defects“-Inspektionsraten betrug 9,8 Seiten pro Stunde.

Diagramm 1:  „minor defects“-Inspektionsraten
Mittelwert: 9,8 p/h (pages/hour), Medianwert: 8,6 p/h
Anzahl Datenpunkte: 729

Nach dem Kurzexperiment mit der „minor defects“-Inspektionsrate werden die Teilnehmer gefragt, wie viel mal mehr Zusatzzeit sie schätzungsweise benötigt hätten, wenn sie den Text auch auf „Major defects“, also inhaltliche Fehler, hätten prüfen müssen. Die Teilnehmer sollen dabei berücksichtigen, dass in dieser Zeitspanne auch das Nachdenken über den Text, das Lesen von Vorgängerdokumenten, das Abarbeiten von Checklisten, das Notieren der gefundenen  Major und minor defects etc. geleistet werden muss. 
735 Softwareentwickler nahmen bisher an der Schätzung teil, der Mittelwert der Schätzungen betrug 14,0-fache Zusatzzeit. Die Softwareentwickler vermuten also im Durchschnitt, dass die Suche nach „Major defects“ ca. 14-mal zeitaufwendiger ist, als die Suche nach „minor defects“.

Diagramm 2:  geschätzte Zusatzzeit für „Major defects“-Suche
Mittelwert: 14,0, Medianwert: 10,0
Anzahl Datenpunkte: 735 (davon 20 größer als Faktor 50)

Der Trainer kann jetzt die optimale Inspektionsrate vorrechnen:
optimale Inspektionsrate = „minor defects“-Inspektionsrate / (1+Zusatzzeitfaktor)
= 9,8 p/h / (1+14,0) = 0,7 p/h
Es ergibt sich eine optimale Inspektionsrate von 0,7 Seiten pro Stunde (bzw. 0,8 Seiten pro Stunde, wenn man mit den Medianwerten rechnet: 8,6 p/h / (1+10,0) = 0,8 p/h). Die Zahlenangabe aus der Literatur („ca. 1 Seite pro Stunde“) ist damit plausibel gemacht.
2.2	Warum Prüfen 50-mal länger dauert als Lesen
Die Prüfgeschwindigkeit „1 Seite pro Stunde“ für die optimale Inspektionsrate kann jetzt noch verglichen werden mit der reinen Lesegeschwindigkeit. Die Leseforschung gibt an, dass das „Naturtempo“ beim Lesen von (deutschsprachigen) Texten ca. 240 Wörter pro Minute beträgt [4]. Das sind umgerechnet 48 Seiten pro Stunde (1 Seite = 300 Wörter [3]).
Um diese Angaben selbst erfahren zu können, lesen die Teilnehmer in einem Kurzexperiment einen Übungstext (Länge des Textes: 1 Seite, Textausschnitt: „...Ein skeptischer Autor beschloss, Magliabechis Bekanntheitsgrad wegen seines Schnelllesens und Gedächtnisses auf die Probe zu stellen und gab ihm ein neues Manuskript, das er vorher nie gesehen haben konnte. ...“ [5])
740 Softwareentwickler führten bisher dieses Kurzexperiment durch. Der Mittelwert der Lesegeschwindigkeiten betrug 50,4 Seiten pro Stunde und liegt sehr nahe an der Literaturangabe von 48 Seiten pro Stunde.

Diagramm 3:  Lesegeschwindigkeiten
Mittelwert: 50,4 p/h, Medianwert: 48,8 p/h
Anzahl Datenpunkte: 740 (davon 4 größer als 100 p/h)

Die Ergebnisse stützen die plakative Aussage: „Man kann zwar ca. 50 Seiten pro Stunde lesen, aber nur ca. 1 Seite pro Stunde gründlich prüfen“. (Die Aussage ist natürlich stark vereinfachend, da sich die 50 Seiten pro Stunde auf deutschsprachige Texte mit durchschnittlichem Schwierigkeitsgrad beziehen, die 1 Seite pro Stunde bezieht sich aber auf typische Textdokumente der Softwareentwicklung, die normalerweise einen höheren Schwierigkeitsgrad aufweisen, oft in Englisch geschrieben sind und während der Prüfung mehr als einmal durchgelesen werden müssen.)
3	Effektivität von Reviews 
Unter der „Effektivität“ eines Reviews versteht man den Anteil der Fehler, die das Reviewteam gefunden hat, im Verhältnis zu allen im Dokument vorhandenen Fehlern. Es ist bekannt, dass die Effektivität eines Reviews ca. 50% beträgt [1][2], sofern die Reviewer in der Phase „Individual Checking“ die optimale Inspektionsrate einhalten. Also ungefähr jeden zweiten Fehler kann ein Reviewteam entdecken.
In den Reviews, wie sie in realen Projekten stattfinden, wird aber selten die optimale Inspektionsrate eingehalten. Die Effektivität dieser Reviews wird also unter 50% liegen; die Frage ist nur, wie weit unter 50%. Für viele Softwareentwickler ist es überraschend zu hören, dass nach Meinung von Fachleuten in Reviews normalerweise sogar nur 3% der vorhandenen Fehler entdeckt werden.
Tom Gilb (Autor von [1]) und sein Sohn Kai Gilb berichten: „known effectiveness: any defect finding method will find somewhere between 0% and 100% of the defects that actually are there. We have found Inspection to operate in the area of about 3% (the normal for inspections not optimized with optimal checking rates etc.) to about 88%.” [6].
Beim Versuch, mit Kurzexperimenten und Schätzungen diese Effektivität von ca. 3% nachzuvollziehen, komme ich persönlich jedoch eher auf eine Effektivität von 4-7%, wie im weiteren Beitrag genau berichtet wird. Da dieser Wert aber in derselben Größenordnung liegt, sehe ich das Ergebnis durchaus als Bestätigung der Literaturangabe von „ca. 3%“ an, wenn man das Wort „ca.“ nicht zu eng auslegt. 
Hier eine Zusammenfassung der in den nächsten Kapiteln folgenden Argumentationskette:
1.	Die typische Inspektionsrate in realen Projekten beträgt im Mittel ca. 13 Seiten pro Stunde, wie mit einer Umfrage unter den Teilnehmern festgestellt wird. Die optimale Inspektionsrate wird also um den Faktor 13 verfehlt.
2.	Die Hypothese, dass in der Phase „Individual Checking“ die Fehler zeitlich ungefähr gleichverteilt gefunden werden, wird mit minutengenauen Protokollierungen in der Phase „Individual Checking“ plausibel gemacht.
3.	Aus der in 2. genannten Hypothese der Gleichverteilung folgt: „Das Verfehlen der optimalen Inspektionsrate um Faktor x bewirkt ein Sinken der Effektivität um Faktor x“. Mit anderen Worten, wer nur ein Dreizehntel der nötigen Prüfzeit ins Review investiert, wird nur ein Dreizehntel soviel Fehler finden, wie ansonsten möglich gewesen wäre. Statt der möglichen Effektivität von 50% erreichen typische Reviews in realen Projekten also nur 4%. (Wenn man die Rechnung nicht mit Mittelwerten, sondern mit Medianwerten durchführt, erhält man als Ergebnis 7%, siehe unten.)
Das Neue dieses Beitrags gegenüber dem Buch "Software Inspection" sind nicht die Zahlenangaben (die werden im Wesentlichen bestätigt), sondern die Hypothese, dass in der Phase „Individual Checking“ die Fehler zeitlich ungefähr gleichverteilt gefunden werden, sowie die Darstellung von Daten, die die Hypothese stützen.  
3.1	Typische Inspektionsraten in realen Projekten
Um festzustellen, mit welchen Inspektionsraten die Reviews in realen Projekten (im deutschsprachigen Raum) durchgeführt werden, nahmen 497 Softwareentwickler an folgender Schätzung teil:
„In Ihrer Firma soll ein Review eines Textdokuments stattfinden. Das Dokument ist so groß, dass es in einzelnen Paketen geprüft wird, jedes Paket in einer eigenen Reviewsitzung. Angenommen, jeder Reviewer kann ca. 2 Stunden Aufwand in die Vorbereitung für eine Reviewsitzung investieren. Versuchen Sie abzuschätzen, aus wie vielen Seiten ein solches Paket in Ihrer Firma typischerweise besteht! Wenn Sie die Daten aus Ihrer Firma zuwenig kennen, geben Sie einfach an, welche Paketgröße Sie selbst wählen würden.“
Aus den Angaben wurden die Inspektionsraten ermittelt, wie sie in typischen Reviews stattfinden. Der Mittelwert der Inspektionsraten betrug 13,3 Seiten pro Stunde.

Diagramm 4:  typische Inspektionsraten beim Review eines Textdokuments
Mittelwert: 13,3 p/h, Medianwert: 7,5 p/h
Anzahl Datenpunkte: 497 (davon 3 größer als 100 p/h)

Die genannten Werte entsprechen übrigens den publizierten Erfahrungen („we typically review documents at five to twenty pages per hour, when systematic calculation and application of optimum rates are not applied.” [1]).
Da die optimale Inspektionsrate ca. 1 Seite pro Stunde beträgt, wird in den realen Softwareprojekten die optimale Inspektionsrate um ca. den Faktor 13 verfehlt. 
3.2	Hypothese: In der Phase „Individual Checking“ werden die Fehler zeitlich ungefähr gleichverteilt gefunden
Um festzustellen, wann in der Phase „Individual Checking“ die Fehler entdeckt werden, wurden 28 Reviewer gebeten, bei jedem entdeckten Fehler den Zeitpunkt minutengenau zu protokollieren. Von den 28 Reviewern prüften 8 ein Textdokument (ca. 1,5 Seiten lang) und 20 ein C-Programm (ca. 80 NLOC lang). Die Inspektionsraten beim Textdokument lagen zwischen 1,1 und 2,45 p/h (Mittelwert 1,67 p/h) und beim C-Programm zwischen 55 und 96 NLOC/h (Mittelwert 69 NLOC/h). Die Inspektionsraten lagen also recht nahe an den empfohlenen optimalen Inspektionsraten (siehe 2.1).

Die insgesamt 557 gefundenen Fehler (bestehend aus 263 Major defects, 247 minor defects, 3 Process Improvements und 44 Fragen) wurden in einem kumulierten Histogramm dargestellt (siehe Diagramm 5). Die einzelnen Zeitachsen der Reviewer wurden vor dem Aufsummieren gestreckt bzw. gestaucht, damit alle Zeitachsen bei "100% individuelle Prüfzeit" enden.

Diagramm 5:  Phase "Individual Checking", kumuliertes Histogramm für 28 Reviewer

Die Kurve in Diagramm 5 liegt sehr nahe an der Diagonalen, es gilt also eine annähernd konstante Fehlerentdeckungsrate, d.h. die Fehler werden zeitlich ungefähr gleichverteilt gefunden. (Was übrigens der Intuition der meisten Softwareentwickler widerspricht, die hier eher einen 80/20-Effekt oder ähnliches erwartet hätten, bei dem zu Beginn der Phase „Individual Checking“ die Fehler deutlich gehäuft entdeckt werden). 
Neben den in Diagramm 5 gezeigten Daten gibt es mindestens noch zwei weitere Hinweise auf eine Gleichverteilung:
Im Jahr 2005 wurde für eine Inspektionsmethode für UML Modelle gezeigt, dass  hier eine konstante Fehlerentdeckungsrate vorliegt [7]. Das in [7] dargestellte kumulierte Histogramm zeigt genauso wie Diagramm 5 annähernd eine Gerade.
Im Buch "Software Inspection" [1] aus dem Jahr 1993 findet sich auf Seite 334 ein Diagramm, in dem 230 Reviews der Sema Group dargestellt sind. Auf der x-Achse wurde die Inspektionsrate (p/h), auf der y-Achse die gefundenen Fehler pro Seite aufgetragen. Die Punktewolke der 230 Reviews hat ungefähr die Form einer Hyperbel, also x * y = Konstante, und veranlasste einen meiner Kollegen (Uwe Schöffel, Softlab GmbH, 1998) zu der Bemerkung: “Die Anzahl der Fehler, die man pro Stunde findet, scheint laut dieser Kurve konstant zu sein.”
Wie ist diese Gleichverteilung, also die konstante Fehlerentdeckungsrate, zu erklären? Vielleicht ergibt sich das direkt aus dem Vorgehen eines Reviewers in der Phase „Individual Checking“. In welcher Reihenfolge ein Reviewer die ihm zur Verfügung stehenden sinnvollen Prüfstrategien anwendet, ist bis zu einem gewissen Grad beliebig: z.B. wann welche Checklistenfrage abgearbeitet wird, wann und in welcher Reihenfolge die relevanten Vorgängerdokumente mit dem zu prüfenden Dokument verglichen werden, bei welchem Lesedurchgang an welcher Stelle genau nachgedacht wird, etc. Ein Reviewer kann vorab nicht wissen, welche Prüfstrategie zu welchem Erfolg führt. Es bleibt also reiner Zufall, wann während der Prüfzeit welcher Fehler entdeckt wird. Im Einzelfall kann es natürlich sein, dass ein Reviewer die Fehler gehäuft am Anfang, in der Mitte oder am Ende der Prüfzeit findet. Gemittelt über viele Reviews ergibt sich aber eine Gleichverteilung.
3.3	Schlussfolgerung: Im typischen Review werden vermutlich nur ca.
4-7% der vorhandenen Fehler entdeckt
Aus der Gleichverteilung folgt: „Das Verfehlen der optimalen Inspektionsrate um Faktor x bewirkt ein Sinken der Effektivität um Faktor x“ (x>=1).
Da in den realen Softwareprojekten die Reviews im Mittel ca. 13 Seiten pro Stunde prüfen und damit die optimale Inspektionsrate um ca. Faktor 13 verfehlt wird, werden diese Reviews anstelle der möglichen 50% nur ca. 4% der vorhandenen Fehler entdecken. (Wenn man die Rechnung stattdessen mit dem Medianwert "7,5 Seiten pro Stunde" durchführt, erhält man als Ergebnis, dass im typischen Review ca. 7% der vorhandenen Fehler entdeckt werden.)
Zum Schluss noch eine allgemeine Bemerkung: das Ergebnis, dass das durchschnittliche Review nur ca. 4-7% Fehler findet, wirft ein schlechtes Licht auf den Stand der Software-Qualitätssicherung in den meisten Software-Projekten. Ein Projekt, das scheitern würde, weil in den Dokumenten zu viele Fehler stecken, scheitert wahrscheinlich auch dann noch, wenn die „Qualitätssicherung“ mit ihren Reviews 93-96% dieser Fehler übersieht!
	Literaturhinweise
1.	Gilb, Tom / Graham, Dorothy: Software Inspection, Addison-Wesley, 1993, ISBN 0-201-63181-4, S. 78, 381, 435
2.	Radice, Ronald A.: High Quality Low Cost Software Inspections, Paradoxicon Publishing, 2002, ISBN 0-9645913-1-6, S. 159, 403
3.	www.gilb.com (Download Center, Stand 23.09.2005), “Optimizing Inspection” von Tom Gilb, S. 2
4.	Michelmann, Rotraut / Michelmann Walter U.: Effizient lesen, Gabler Verlag, Wiesbaden, 1. Auflage 1995, ISBN 3-409-19643-9, S. 63
5.	Buzan, Tony: Speed Reading,  mvg-verlag, Landsberg-München, 8. Auflage 2002, ISBN 3-478-71961-5, S. 87-89
6.	www.gilb.com (Forum, Stand 23.09.2005), Topic “Inspection, Quality Control”, Thread “Completeness of candidate documents”,  Posting von Kai Gilb vom 17.09.2004
7.	Górski, Janusz / Jarzębowicz Aleksander: Development and validation of a HAZOP-based inspection of UML models, in: Proceedings of the 3rd World Congress for Software Quality, Erlangen, 2005, ISBN 3-9809145-2-6, S. I-352
8.	Foliensatz zu diesem Beitrag: www.reviewtechnik.de/vortraege.html (Stand 23.09.2008), Datei Vortrag_GI_080923.ppt