Warum Prüfen oft 50 mal länger dauert als Lesen

Präsentation zum Thema: "Warum Prüfen oft 50 mal länger dauert als Lesen"—  Präsentation transkript:

1 Warum Prüfen oft 50 mal länger dauert als Lesen
... und andere Überraschungen aus der Welt der Software-Reviews programprog ramprogramprogr amprogramprogram program BUG progr amprogramprogra mprogramprogr ampro 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. Datei zuletzt geändert: (umbenannt) (erstellt) Folien zuletzt geändert: Folie zuletzt geändert am: Peter Rösler

2 Zusammenfassung (2) Zwei dieser Zahlenangaben, die den Teilnehmern üblicherweise besonders unplausibel vorkommen, sind: 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). Das durchschnittliche Review findet nur ca. 5% der im Dokument vorhandenen Fehler. Folie zuletzt geändert am: Peter Rösler

3 Zusammenfassung (3) 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. An den Kurzexperimenten und Schätzungen beteiligten sich bisher ca. 90 Teilnehmer von 13 Reviewtechnik-Seminaren im Zeitraum von Oktober 2004 bis September 2005. Folie zuletzt geändert am: Peter Rösler

4 “major defect” (im Gegensatz zu “minor defect”) :
1. Einführung Die in diesem Beitrag betrachteten Software-Reviews werden oft auch als „Software-Inspektionen“, „Fagan/Gilb style inspections“ oder „Peer Reviews“ bezeichnet. Definitionen: “major defect” (im Gegensatz zu “minor defect”) : Fehler, der möglicherweise erheblich höhere Kosten verursacht, wenn er später gefunden wird als jetzt. 1 Seite = 300 Wörter [3] Folie zuletzt geändert am: Peter Rösler

5 Capability Maturity Model (CMM)
Level 1 Initial Level 2 Repeatable Level 3 Defined Level 4 Managed Level 5 Optimizing Key Process Areas Focus Level Heroes No KPAs at this time Project management Requirements Management, SW Project Planning SW Project Tracking and Oversight SW Subcontract Management, SW Quality Assurance SW Configuration Management Engineering process Organization Process Focus, Org. Process Definition Peer Reviews, Training Program Intergroup Coordination, SW Product Engineering Integrated Software Management Product and process quality Software Quality Management Quantitative Process Management Continuous improvement Process Change Management Technology Change Management Defect Prevention Reifegradmodell. Capability Maturity Model (SW-CMM or CMM) for Software by the Software Engineering Institute (SEI). : The purpose of Peer Reviews is to remove defects from the software work products early and efficiently. Folie zuletzt geändert am: (Animation), (neu erstellt), Notizen zuletzt geändert am: Source: quagmire/descriptions/sw-cmm.asp Peter Rösler

6 Types of Review of Documents
Walkthrough: Activity: understanding author guides the group through a document and his or her thought processes, so all understand the same thing, consensus on changes to make Review: Activity: decision making group discusses document and makes a decision about the content, e.g. how something should be done, go or no-go decision Inspection: Main activity: find defects formal individual and group checking, using sources and standards, according to detailed and specific rules [Presentation Review] [Management-Review/Projektstatus-Review] Folie zuletzt geändert am: , Source: Dorothy Graham Peter Rösler

7 Vorleser/Reader (nur wenn „double checking“ gemacht wird)
Rollen der Teilnehmer Moderator Autor Protokollführer Reviewer Vorleser/Reader (nur wenn „double checking“ gemacht wird) Ein Teilnehmer kann mehrere Rollen übernehmen. Folie zuletzt geändert am: , , , Einzige Einschränkung: der Autor darf zusätzlich höchstens die Rolle eines Reviewers übernehmen. Peter Rösler

8 Overall Process Map Planning Entry Master Plan Kickoff
Sources Entry Master Plan Product Kickoff Individual Checking Inspection Issue Log Checklists Change Requests to Project and Process Logging Process Brainstorming Process Brainstorm Log Edit Folie zuletzt geändert am: (Wort „Individual“ ergänzt), Data Summary Followup Exited Product Exit Source: Tom Gilb, Team Leader Course Peter Rösler

9 Phase „Individual Checking“
Von den Fehlern, die das Reviewteam insgesamt entdeckt, werden 80% im „Individual Checking“ gefunden und 20% im „Logging meeting“, sofern dort mit „Double Checking“ erneut Fehlersuche betrieben wird. [1] Da in den meisten durchgeführten Reviews auf „Double Checking“ verzichtet wird, werden in der Praxis eher 95% der durch das Reviewteam entdeckten Fehler im „Individual Checking“ gefunden. [2] Folie zuletzt geändert am: Peter Rösler

10 2. Lese- und Prüfgeschwindigkeiten im Vergleich 2
2. Lese- und Prüfgeschwindigkeiten im Vergleich 2.1 Die optimale Inspektionsrate In der Phase „Individual Checking“ wendet ein Reviewer alle ihm zur Verfügung stehenden sinnvollen Prüfstrategien an. Für Textdokumente dauert das erfahrungsgemäß 1 Seite pro Stunde. ([1], Gilb/Graham 1993) Bandbreiten für die optimale Inspektionsrate: 1 ± 0,8 Seiten pro Stunde [3] „Software Inspection“ von Tom Gilb und Dorothy Graham, 1993 Folie zuletzt geändert am: Peter Rösler

11 Kurzexperiment Mit folgenden Kurzexperimenten und Schätzungen kann der unplausibel klingende Wert „1 Seite pro Stunde“ nachvollzogen werden: In einem ersten Kurzexperiment prüfen die Teilnehmer einen typischen Spezifikationstext auf „minor defects“. Spezifikationstext: „...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. ...”). Folie zuletzt geändert am: Peter Rösler

12 „minor defects“-Inspektionsraten
Folie zuletzt geändert am: Mittelwert: 9,8 p/h Anzahl Datenpunkte: 92 Source: Peter Rösler

13 Schätzung für Major defects
Nach dem Kurzexperiment mit der „minor defects“-Inspektionsrate werden die Teilnehmer gefragt: „Wie viel mal mehr Zeit (zusätzlich) würden Sie schätzungsweise benötigen, wenn Sie auch die inhaltlichen Fehler, also die Major defects, finden wollten?“ Folie zuletzt geändert am: Peter Rösler

14 Geschätzte Zusatzzeit für „Major defects“-Suche
Folie zuletzt geändert am: Mittelwert: Faktor 9,7 Anzahl Datenpunkte: 86 Source: Peter Rösler

15 Die optimale Inspektionsrate
Der Trainer kann jetzt die optimale Inspektionsrate vorrechnen: optimale Inspektionsrate = „minor defects“-Inspektionsrate / (1+Zusatzzeitfaktor) = 9,8 p/h / (1+9,7) = 0,9 p/h „minor defects“-Inspektionsrate Zusatzzeit für „Major defects“-Suche Folie zuletzt geändert am: Peter Rösler

16 2.2 Warum Prüfen oft 50 mal länger dauert als Lesen
Das „Naturtempo“ beim Lesen von (deutschsprachigen) Texten beträgt ca. 240 Wörter pro Minute. [4] Das sind umgerechnet 48 Seiten pro Stunde. In einem Kurzexperiment ermitteln die Teilnehmer ihre eigene Lesegeschwindigkeit an einem Übungstext. 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]) Folie zuletzt geändert am: Peter Rösler

17 Lesegeschwindigkeiten
Folie zuletzt geändert am: Mittelwert: 49,4 p/h Anzahl Datenpunkte: 99 Source: Peter Rösler

18 Prüfen dauert 50 mal länger als Lesen
Lesegeschwindigkeiten Lesegeschwindigkeit: ca. 50 Seiten pro Stunde optimale Inspektionsrate: ca. 1 Seite pro Stunde Folie zuletzt geändert am: „Man kann zwar ca. 50 Seiten pro Stunde lesen, aber nur ca. 1 Seite pro Stunde gründlich prüfen.“ Peter Rösler

19 3. Effektivität von Reviews
Das Reviewteam findet ca. 50% der im Dokument vorhandenen Fehler [1][2], wenn die optimale Inspektionsrate eingehalten wird, ansonsten: Tom Gilb / Kai Gilb: “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] Mit den im Folgenden gezeigten Kurzexperimenten und Schätzungen kommt man auf einen ähnlichen Wert: nur ca. 5% der Fehler werden in typischen Reviews entdeckt. Folie zuletzt geändert am: Peter Rösler

20 3.1 Typische Inspektionsraten beim Review eines Textdokuments
In einer Umfrage gaben die Teilnehmer an, mit welchen Inspektionsraten die Reviews in ihrer Firma typischerweise durchgeführt werden. „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! ...“ Folie zuletzt geändert am: Peter Rösler

21 Typische Inspektionsraten beim Review eines Textdokuments
Folie zuletzt geändert am: Mittelwert: 10,2 p/h Anzahl Datenpunkte: 93 Source: Peter Rösler

22 Typische Reviews: um Faktor 10 zu schnell!
typische Inspektionsraten bei Textdokumenten Die optimale Inspektionsrate (1 Seite pro Stunde) wird in typischen Reviews um den Faktor 10 verfehlt. Die Werte aus der Umfrage entsprechen 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] Folie zuletzt geändert am: Peter Rösler

23 abnehmende Fehlerentdeckungsrate? konstante Fehlerentdeckungsrate?
Wann findet ein Reviewer die Fehler in der Phase „Individual Checking“? Fehlerentdeckungsrate Checking Dauer abnehmende Fehlerentdeckungsrate? konstante Fehlerentdeckungsrate? mit Einarbeitungszeit? mit Einarbeitungszeit? Folie zuletzt geändert am: Source: Peter Rösler

24 3.2 Hypothese: Im „Individual Checking“ werden die Fehler zeitlich ungefähr gleichverteilt gefunden
10 Reviewer wurden gebeten, bei jedem entdeckten Fehler den Zeitpunkt minutengenau zu protokollieren. Folie zuletzt geändert am: Peter Rösler

25 Zeitpunkt der Fehlerentdeckung in Phase „Individual Checking“, Reviewer 1
Folie zuletzt geändert am: Vorlage s. Issue_Log_demo.xls, P1 Source: Peter Rösler

26 Zeitpunkt der Fehlerentdeckung in Phase „Individual Checking“
Source: Textdokument C-Programm zum 0 abdecken Folie zuletzt geändert am: Auszug aus der Textfassung des Vortrags: Der Punkt am Ende jeder Reihe gibt an, wann der Reviewer die Phase „Individual Checking“ beendet hat. Major defects sind in der jeweiligen Reihe etwas höher positioniert als minor defects. Die Daten der Reviewer 1 bis 4 legen meiner Auffassung eher eine Gleichverteilung nahe. Es ist nicht zu erkennen, dass es einen 80/20-Effekt oder ähnliches geben würde, bei dem zu Beginn der Phase „Individual Checking“ die Fehler deutlich gehäuft entdeckt werden. Evtl. gibt es am Ende der Phase „Individual Checking“ einen leichten Rückgang der Fehlerentdeckungsrate, wenn überhaupt. Bei Reviewer 1 bis 4 ist übrigens auch keine Einarbeitungszeit zu erkennen, die ersten Fehler werden schon ganz am Anfang der Phase „Individual Checking“ gefunden. Bei den Code-Reviews (Reviewer 5 bis 10) ist am Anfang eine Einarbeitungszeit schon eher erkennbar, danach scheinen auch hier die Fehler relativ gleichverteilt gefunden zu werden, und auch hier ohne deutlichen Rückgang der Fehlerentdeckungsrate am Ende der Phase „Individual Checking“. end-of-Auszug Peter Rösler

27 Weiteres Indiz für konstante Fehlerentdeckungsrate
Folie zuletzt geändert am: Source: Górski / Jarzębowicz: Development and validation of a HAZOP-based inspection of UML models, in: Proceedings of the 3rd World Congress for Software Quality, Erlangen, 2005 Peter Rösler

28 Noch ein Indiz: die Reihenfolge der Prüfstrategien ist weitgehend beliebig
Ein Reviewer kann vorab nicht wissen, welche Prüfstrategie zu welchem Erfolg führt. Es bleibt reiner Zufall, wann während der Prüfzeit welcher Fehler entdeckt wird. erstmaliges Durchlesen für einen Überblick Vorgänger-dokument 1 mit Prüfling vergleichen Vorgänger-dokument 2 mit Prüfling vergleichen Lesedurch-gang um Querbezüge zu prüfen Checklisten-fragen 1-5 abarbeiten komplizierte Stellen genau durchdenken Wort-für-Wort-Prüfung Checklisten-fragen 6-10 abarbeiten Mj m 20 40 60 80 100 120 min. Ein Reviewer kann in dieser Reihenfolge prüfen ... erstmaliges Durchlesen für einen Überblick Vorgänger-dokument 1 mit Prüfling vergleichen Vorgänger-dokument 2 mit Prüfling vergleichen Lesedurch-gang um Querbezüge zu prüfen Checklisten-fragen 1-5 abarbeiten komplizierte Stellen genau durchdenken Checklisten-fragen 6-10 abarbeiten Wort-für-Wort-Prüfung Mj m 20 40 60 80 100 120 min. ... oder in einer ganz anderen Reihenfolge ... Folie zuletzt geändert am: Source: Peter Rösler

29 Aus der Hypothese der Gleichverteilung folgt:
3.3 Schlussfolgerung: Im typischen Review werden nur 5% der vorhandenen Fehler entdeckt Aus der Hypothese 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 SW-Projekten ca. 10 Seiten pro Stunde geprüft werden und damit die optimale Inspektionsrate um ca. Faktor 10 verfehlt wird, werden diese Reviews anstelle der möglichen 50% nur 5% der vorhandenen Fehler entdecken! Folie zuletzt geändert am: Peter Rösler

30 Schlussbemerkung Wenn obige Hypothese richtig ist, dann wirft das ein schlechtes Licht auf den Stand der Qualitätssicherung in den meisten SW-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 95% dieser Fehler übersieht! Folie zuletzt geändert am: Peter Rösler

31 Literatur 1.     Gilb, Tom / Graham, Dorothy: Software Inspection, Addison-Wesley, 1993, 2.     Radice, Ronald A.: High Quality Low Cost Software Inspections, Paradoxicon Publishing, 3.     (Download Center), “Optimizing Inspection” von Tom Gilb 4.     Michelmann, Rotraut / Michelmann Walter U.: Effizient lesen, Gabler Verlag, Wiesbaden, 1. Auflage 1995 5.     Buzan, Tony: Speed Reading, mvg-verlag, Landsberg-München, 2002 6.     Topic “Insp., Quality Control”, Thread “Completeness of candidate doc.”, Posting von Kai Gilb vom 7.     Gorski, J. / Jarzebowicz A.: Development and validation of a HAZOP-based inspection of UML models, in: Proc. of the 3rd World Congress for Software Quality, Erlangen, 2005 Folie zuletzt geändert am: Peter Rösler PowerPoint-Folien und Textfassung des Vortrags:

32 Diskussion „minor defects“-Inspektionsrate Zusatzzeit für „Major defects“-Suche Lesegeschwindigkeiten typische Inspektionsraten bei Textdokumenten Folie zuletzt geändert am: („Wartungshinweis“: damit Folie vorgespielt richtig aussieht, ist ein weißes Rechteck mit den Einzeldiagrammen gruppiert) Peter Rösler

33 Es folgen Folien, die für die Diskussion verfügbar sein sollen
Folie zuletzt geändert am: Peter Rösler

34 Anteil von Rework am Gesamtaufwand
44 % 56 % „Rework“ wird oft auch „cost of non-quality“ genannt. Reworkanteil wird durch die Fehlerfindeeigenschaften der Reviewtechnik reduziert. Productionsanteil wird durch die Prozeßverbesserungseigenschaften der Reviewtechnik reduziert. Folie zuletzt geändert am: (Farbe von Rework) Source: Wheeler 1996, Software inspection: an industry best practice, p 9 Peter Rösler

35 Relative Fehlerbehebungskosten
Das ist der klassische Lebenslauf eines major defects! Obige Daten der Standard Chartered Bank passen gut zu den Daten einer Analyse von 63 Projekten in Boehm, 1981, Software Engineering Economics. Folie zuletzt geändert am: (Rechtschreibfehler), Source: Tom Gilb, Software Engineering Management, Daten der Standard Chartered Bank Peter Rösler

36 “Mitarbeiterberg” mit und ohne Reviews
Without Inspections Using Inspections People Resource Reviews sind eine Investition in den frühen Projektphasen. In der 1. Hälfte der Produktentwicklung nehmen Reviews % des Projektaufwands ein. Folie zuletzt geändert am: Planning/ Requirements Design Code Testing Ship Schedule Source: Fagan 1986 Schema Peter Rösler

37 Effectiveness against Inspection Rate
Average errors found (of 21 maximum known) Buck’s Daten stammen aus “IBM inspection classes using a student problem”. Folie zuletzt geändert am: 70 to 122 130 to 285 Inspection rate (lines/hour) Source: Frank Buck, 1981, Technical Report 21.802, September, IBM Peter Rösler

38 Defect Density against Inspection Rate
15 12 9 Defect density (defects/page) 6 3 „Bereich der Illusion von QS“. Nicht ungerecht sein * 1 = 10 * 6 Gilb/Ebenau/Leserate einzeichnen Folie zur Seite legen Folie zuletzt geändert am: 20 40 60 80 100 Inspection rate (pages/hour) Source: Tom Gilb, Denise Leigh Software Inspection p 334, 230 inspections of Sema Group (GB) Peter Rösler

39 Empfohlene Inspektionsraten
Programme 100 – 150 NLOC / h Textdokumente Gilb/Graham: ca. 1 Seite / h Strauss/Ebenau: 3 – 5 Seiten / h Zum Vergleich: normale Lesegeschwindigkeit: ca. 50 Seiten / h „minor defects“-Prüfgeschwindigkeit: ca. 10 Seiten / h Folie zuletzt geändert am: („Zum Vergleich“ geändert) (animiert, Notizen verkürzt), , Notizen zuletzt geändert am: Begriff „minor defects“-Prüfgeschwindigkeit ist in Lese_und_Pruefgeschw_ doc mit „Basisprüftempo“ bezeichnet: Der Text soll an den Kunden gehen und natürlich inhaltlich fehlerfrei sein. Dies sollen Sie in diesem Experiment aber nicht überprüfen. Sie sollen nur prüfen, ob der Text auf den ersten Blick einen guten Eindruck macht, d.h. –        der Text soll möglichst wenig Rechtschreibfehler enthalten, –        der Text soll bezüglich Satzbau und sprachlicher Formulierung nicht negativ auffallen, –        das optische Erscheinungsbild (Schriftgröße, Einrückungen etc.) soll nicht negativ auffallen, –        inhaltlich soll der Text für einen Laien auf den ersten Blick einigermaßen vernünftig klingen. Für die Prüfung sollte es ausreichen, den Text ein oder höchstens zweimal sorgfältig durchzulesen. Peter Rösler