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

Slides:



Advertisements
Ähnliche Präsentationen
Algorithmen und Datenstrukturen
Advertisements

Developing your Business to Success We are looking for business partners. Enterprise Content Management with OS|ECM Version 6.
Anzahl der ausgefüllten und eingesandten Fragebögen: 211
Mit Stichproben-Reviews die Dauer von Testphasen vorhersagen
Vorlesung: 1 Betriebliche Informationssysteme 2003 Prof. Dr. G. Hellberg Studiengang Informatik FHDW Vorlesung: Betriebliche Informationssysteme Teil3.
Qualitätssicherung von Software
E / IDE Enhanced / Integrated Device Elektronics
Qualitätssicherung von Software (SWQS)
Universität Stuttgart Institut für Kernenergetik und Energiesysteme Regeln für Tester - best practice 1 Prüfe das eigene Programm nie als Einziger Testen.
Capability Maturity Model
Vorlesung: 1 Betriebliche Informationssysteme 2003 Prof. Dr. G. Hellberg Studiengang Informatik FHDW Vorlesung: Betriebliche Informationssysteme Teil2.
PKJ 2005/1 Stefan Dissmann Zusammenfassung Bisher im Kurs erarbeitete Konzepte(1): Umgang mit einfachen Datentypen Umgang mit Feldern Umgang mit Referenzen.
Software-Reviews Erfahrungsbericht aus dem Projektgeschäft
Reviews - richtig durchgeführt Version 2006 Peter Rösler 1 Ein Dokument mit 2 Methoden geprüft Anzahl Reviewer Inspektionsrate in.
Warum Prüfen 50 mal länger dauert als Lesen... und andere Überraschungen aus der Welt der Software-Reviews Zusammenfassung: Bei der Diskussion über Software-Reviews.
Warum Prüfen 50 mal länger dauert als Lesen... und andere Überraschungen aus der Welt der Software-Reviews Zusammenfassung: Bei der Diskussion über Software-Reviews.
Review-Techniken GI Regionalgruppe Nordhessen Peter Rösler Softlab GmbH 1 Software-Reviews Erfahrungsbericht aus dem Projektgeschäft.
Projektplan: Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University.
Can you think of some KEY phrases which would be useful in multiple contexts? Take 2 minutes with a partner and come up with as many as you can!
Bild 1.1 Copyright © Alfred Mertins | Signaltheorie, 2. Auflage Vieweg+Teubner PLUS Zusatzmaterialien Vieweg+Teubner Verlag | Wiesbaden.
20:00.
Die Geschichte von Rudi
GERMAN 1013 Kapitel 2 3.
TWS/Graph HORIZONT Produkt-Präsentation Software für Rechenzentren
1 Fachtagung am Seniorenorientiertes Design und Marketing ThyssenKrupp Immobilien Design for all - Anpassungen im Wohnungsbestand 1.Demographie.
HORIZONT 1 XINFO ® Das IT - Informationssystem Java Scanner HORIZONT Software für Rechenzentren Garmischer Str. 8 D München Tel ++49(0)89 / 540.
1 Ein kurzer Sprung in die tiefe Vergangenheit der Erde.
Computational Thinking Online Algorithmen [Was ist es wert, die Zukunft zu kennen?] Kurt Mehlhorn Konstantinos Panagiotou.
Wir üben die Malsätzchen
HORIZONT 1 XINFO ® Das IT - Informationssystem HORIZONT Software für Rechenzentren Garmischer Str. 8 D München Tel ++49(0)89 /
HORIZONT 1 XINFO ® Das IT - Informationssystem PL/1 Scanner HORIZONT Software für Rechenzentren Garmischer Str. 8 D München Tel ++49(0)89 / 540.
Ertragsteuern, 5. Auflage Christiana Djanani, Gernot Brähler, Christian Lösel, Andreas Krenzin © UVK Verlagsgesellschaft mbH, Konstanz und München 2012.
Das IT - Informationssystem
MINDREADER Ein magisch - interaktives Erlebnis mit ENZO PAOLO
Schutzvermerk nach DIN 34 beachten 20/05/14 Seite 1 Grundlagen XSoft Lösung :Logische Grundschaltung IEC-Grundlagen und logische Verknüpfungen.
Folie Beispiel für eine Einzelauswertung der Gemeindedaten (fiktive Daten)
Universität StuttgartInstitut für Wasserbau, Lehrstuhl für Hydrologie und Geohydrologie Copulas (1) András Bárdossy IWS Universität Stuttgart.
Dokumentation der Umfrage BR P2.t Ergebnisse in Prozent n= 502 telefonische CATI-Interviews, repräsentativ für die Linzer Bevölkerung ab 18 Jahre;
Ertragsteuern, 5. Auflage Christiana Djanani, Gernot Brähler, Christian Lösel, Andreas Krenzin © UVK Verlagsgesellschaft mbH, Konstanz und München 2012.
Titelmasterformat durch Klicken bearbeiten Textmasterformate durch Klicken bearbeiten Zweite Ebene Dritte Ebene Vierte Ebene Fünfte Ebene 1 Rising energy.
Folie Einzelauswertung der Gemeindedaten
1 10 pt 15 pt 20 pt 25 pt 5 pt 10 pt 15 pt 20 pt 25 pt 5 pt 10 pt 15 pt 20 pt 25 pt 5 pt 10 pt 15 pt 20 pt 25 pt 5 pt 10 pt 15 pt 20 pt 25 pt 5 pt Modalverben.
Numbers Greetings and Good-byes All about Me Verbs and Pronouns
1 10 pt 15 pt 20 pt 25 pt 5 pt 10 pt 15 pt 20 pt 25 pt 5 pt 10 pt 15 pt 20 pt 25 pt 5 pt 10 pt 15 pt 20 pt 25 pt 5 pt 10 pt 15 pt 20 pt 25 pt 5 pt Wie.
Konjunktionen & Indirekte Fragen {Conjunctions}
Das IT - Informationssystem
Die Fragen Wörter Wer? Was? Wann?.
1 Medienpädagogischer Forschungsverbund Südwest KIM-Studie 2014 Landesanstalt für Kommunikation Baden-Württemberg (LFK) Landeszentrale für Medien und Kommunikation.
Monatsbericht Ausgleichsenergiemarkt Gas – Oktober
Arbeiten in einem agilen Team mit VS & TFS 11
E STUNDE Deutsch AP. Montag, der 6. Mai 2013 Deutsch AP (E Stunde)Heute ist ein D Tag Goal: to understand authentic written text, audio material and audio-visual.
E STUNDE Deutsch AP. Mittwoch, der 24. April 2013 Deutsch AP (E Stunde)Heute ist ein C Tag Goal: to understand authentic written text, audio material.
E STUNDE Deutsch AP. Freitag, der 19. April 2013 Deutsch AP (E Stunde)Heute ist ein G Tag Goal: to understand authentic written text, audio material and.
E STUNDE Deutsch AP. Donnerstag, der 9. Mai 2013 Deutsch AP (E Stunde)Heute ist ein G Tag Goal: to understand authentic written text, audio material and.
Warum Prüfen 50-mal länger dauert als Lesen... und andere Überraschungen aus der Welt der Software-Reviews Zusammenfassung: Bei der Diskussion über Software-Reviews.
Automation and Drives Diamantis Gikas, A&D AS RD DH N 1 Reviews erfolgreich durchführen, Nürnberg Reviews erfolgreich durchführen “Reviews erfolgreich.
Warum Prüfen 50-mal länger dauert als Lesen... und andere Überraschungen aus der Welt der Software-Reviews Zusammenfassung: Bei der Diskussion über Software-Reviews.
E STUNDE Deutsch AP. Dienstag, der 23. April 2013 Deutsch AP (E Stunde)Heute ist ein B Tag Goal: to understand authentic written text, audio material.
E STUNDE Deutsch AP. Donnerstag, der 2. Mai 2013 Deutsch AP (E Stunde)Heute ist ein B Tag Goal: to understand authentic written text, audio material and.
E STUNDE Deutsch AP. Dienstag, der 28. Mai 2013 Deutsch AP (E Stunde)Heute ist ein E Tag Goal: to understand authentic written text, audio material and.
Gregor Graf Oracle Portal (Part of the Oracle Application Server 9i) Gregor Graf (2001,2002)
EUROPÄISCHE GEMEINSCHAFT Europäischer Sozialfonds EUROPÄISCHE GEMEINSCHAFT Europäischer Fonds für Regionale Entwicklung Workpackage 5 – guidelines Tasks.
E STUNDE Deutsch AP. Donnerstag, der 30. Mai 2013 Deutsch AP (E Stunde)Heute ist ein G Tag Goal: to understand authentic written text, audio material.
E STUNDE Deutsch AP. Donnerstag, der 11. April 2013 Deutsch AP (E Stunde)Heute ist ein A Tag Goal: to understand authentic written text, audio material.
LLP DE-COMENIUS-CMP Dieses Projekt wurde mit Unterstützung der Europäischen Kommission finanziert. Die Verantwortung für den Inhalt dieser.
Interrogatives and Verbs
IT QM Part2 Lecture 7 PSE GSC
- moodle – a internet based learning platform
 Präsentation transkript:

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: 19.11.05 (umbenannt) 06.11.05 (erstellt) Folien zuletzt geändert: 06.11.05 Folie zuletzt geändert am: 01.11.05 Peter Rösler www.reviewtechnik.de

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: 01.11.05 Peter Rösler www.reviewtechnik.de

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: 01.11.05 Peter Rösler www.reviewtechnik.de

“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: 01.11.05 Peter Rösler www.reviewtechnik.de

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). www.wa.gov/DIS/PMM/tr25/tr25_l3g.html : The purpose of Peer Reviews is to remove defects from the software work products early and efficiently. Folie zuletzt geändert am: 01.11.05 (Animation), 30.12.00 (neu erstellt), Notizen zuletzt geändert am: 26.12.01 Source: www.software.org/ quagmire/descriptions/sw-cmm.asp Peter Rösler www.reviewtechnik.de

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: 28.12.01, 01.05.99 Source: Dorothy Graham Peter Rösler www.reviewtechnik.de

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: 01.11.05, 24.10.05, 12.07.01, 16.09.99 Einzige Einschränkung: der Autor darf zusätzlich höchstens die Rolle eines Reviewers übernehmen. Peter Rösler www.reviewtechnik.de

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: 06.11.05 (Wort „Individual“ ergänzt), 16.09.99 Data Summary Followup Exited Product Exit Source: Tom Gilb, Team Leader Course Peter Rösler www.reviewtechnik.de

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: 01.11.05 Peter Rösler www.reviewtechnik.de

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: 01.11.05 Peter Rösler www.reviewtechnik.de

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: 01.11.05 Peter Rösler www.reviewtechnik.de

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

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: 06.11.05 Peter Rösler www.reviewtechnik.de

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

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: 01.11.05 Peter Rösler www.reviewtechnik.de

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: 01.11.05 Peter Rösler www.reviewtechnik.de

Lesegeschwindigkeiten Folie zuletzt geändert am: 01.11.05 Mittelwert: 49,4 p/h Anzahl Datenpunkte: 99 Source: www.reviewtechnik.de Peter Rösler www.reviewtechnik.de

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: 01.11.05 „Man kann zwar ca. 50 Seiten pro Stunde lesen, aber nur ca. 1 Seite pro Stunde gründlich prüfen.“ Peter Rösler www.reviewtechnik.de

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: 01.11.05 Peter Rösler www.reviewtechnik.de

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: 06.11.05 Peter Rösler www.reviewtechnik.de

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

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: 06.11.05 Peter Rösler www.reviewtechnik.de

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: 03.11.05 Source: www.reviewtechnik.de Peter Rösler www.reviewtechnik.de

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: 01.11.05 Peter Rösler www.reviewtechnik.de

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

Zeitpunkt der Fehlerentdeckung in Phase „Individual Checking“ Source: www.reviewtechnik.de Textdokument C-Programm zum 0 abdecken Folie zuletzt geändert am: 06.11.05 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 www.reviewtechnik.de

Weiteres Indiz für konstante Fehlerentdeckungsrate Folie zuletzt geändert am: 06.11.05 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 www.reviewtechnik.de

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: 06.11.05 Source: www.reviewtechnik.de Peter Rösler www.reviewtechnik.de

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: 01.11.05 Peter Rösler www.reviewtechnik.de

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: 01.11.05 Peter Rösler www.reviewtechnik.de

Literatur 1.     Gilb, Tom / Graham, Dorothy: Software Inspection, Addison-Wesley, 1993, 2.     Radice, Ronald A.: High Quality Low Cost Software Inspections, Paradoxicon Publishing, 3.     www.gilb.com (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.     www.gilb.com, Topic “Insp., Quality Control”, Thread “Completeness of candidate doc.”, Posting von Kai Gilb vom 17.09.2004 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: 01.11.05 Peter Rösler www.reviewtechnik.de PowerPoint-Folien und Textfassung des Vortrags: www.reviewtechnik.de/vortraege.html

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

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

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: 30.12.00 (Farbe von Rework) Source: Wheeler 1996, Software inspection: an industry best practice, p 9 Peter Rösler www.reviewtechnik.de

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: 26.12.01 (Rechtschreibfehler), 16.09.99 Source: Tom Gilb, Software Engineering Management, Daten der Standard Chartered Bank Peter Rösler www.reviewtechnik.de

“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 20 - 30 % des Projektaufwands ein. Folie zuletzt geändert am: 01.05.99 Planning/ Requirements Design Code Testing Ship Schedule Source: Fagan 1986 Schema Peter Rösler www.reviewtechnik.de

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: 16.09.99 70 to 122 130 to 285 Inspection rate (lines/hour) Source: Frank Buck, 1981, Technical Report 21.802, September, IBM Peter Rösler www.reviewtechnik.de

Defect Density against Inspection Rate 15 12 9 Defect density (defects/page) 6 3 „Bereich der Illusion von QS“. Nicht ungerecht sein ... 60 * 1 = 10 * 6 Gilb/Ebenau/Leserate einzeichnen Folie zur Seite legen Folie zuletzt geändert am: 18.09.99 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 www.reviewtechnik.de

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: 11.06.05 („Zum Vergleich“ geändert) 09.06.02 (animiert, Notizen verkürzt), 30.12.00, Notizen zuletzt geändert am: 29.03.02 Begriff „minor defects“-Prüfgeschwindigkeit ist in Lese_und_Pruefgeschw_041009.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 www.reviewtechnik.de