Mit Stichproben-Reviews die Dauer von Testphasen vorhersagen

Präsentation zum Thema: "Mit Stichproben-Reviews die Dauer von Testphasen vorhersagen"—  Präsentation transkript:

1 Mit Stichproben-Reviews die Dauer von Testphasen vorhersagen
Datei zuletzt geändert: , Folie zuletzt geändert am: , Notizen zuletzt geändert am: Peter Rösler, Maud Schlich ReviewConsult

2 Tutorial Stichproben-Reviews
Einführung in Reviews und Inspektionen Problematik Testaufwandsschätzung, Rework-Aufwand und Fehlerdichte Schätzung über Stichproben-Reviews Tipps für erfolgreiche Reviews Einführung in Reviews und Inspektionen Folie zuletzt geändert am: , Notizen zuletzt geändert am:

3 Reifegradmodell CMM (Capability Maturity Model)
Schon CMM (eines der ersten Reifegradmodelle) forderte Reviews: Level Fokus Schlüsselprozessbereiche Level 5 Optimierend Level 4 Beherrscht Level 3 Definiert Level 2 Wiederholbar Level 1 Initial Ständige Prozess-Optimierung Prozessänderungsmanagement Technologieänderungsmanagement Fehlervorbeugung Produkt- und Prozess- Qualität Quantitatives SW-Qualitätsmanagement Quantitatives Prozessmanagement Prozess-Standards Prozess-Fokus (org.weit), Prozess-Definition (org.weit), Peer-Reviews, Trainingsprogramme Koordination von Entwicklungsgruppen, SW-Produkt-Entwicklung, Integriertes Projektmanagement Anforderungsmanagement, SW-Projektplanung SW-Projektverfolgung und -übersicht SW-Zulieferermanagement, SW-Qualitätssicherung SW-Konfigurationsmanagement Projekt- Management Folie zuletzt geändert am: , , , (neu erstellt), Notizen zuletzt geändert am: übersetzt u.a. nach Reifegradmodell. Capability Maturity Model (SW-CMM or CMM) for Software by the Software Engineering Institute (SEI). “Tom Gilb: His book Software Metrics is acknowledged as the foundation for CMM Level 4.” CMU/SEI 2001: “Process Maturity Profile of the Software Community 2000 Year End Update”: „8% of Level 1 and 22% of Level 2 organizations fully satisfied the Peer Reviews KPA“ : The purpose of Peer Reviews is to remove defects from the software work products early and efficiently. ISO9001 entspricht ungefähr CMM Level 2 (Quelle weiß ich nicht mehr) "Helden" --- Quelle: quagmire/descriptions/swcmm.asp

4 Einführung in Reviews und Inspektionen
Einleitung / Begriffe Rollen der Teilnehmer Phasen eines Reviews Einleitung / Begriffe Folie zuletzt geändert am: , Notizen zuletzt geändert am:

5 Begriffe (1) Im Folgenden verwenden wir die Begriffe “Review” oder „Software-Review“ synonym zu “Inspection” / “formale Inspektion” / “Fagan/Gilb style inspection”. Achtung: in der englischsprachigen Literatur bezeichnet “Review” oft eine zur “Inspection” deutlich abgegrenzte analytische QS-Maßnahme (s. nächste Folie). In diesem Sinne geht es im Vortrag ausschließlich um “Inspections”! Folie zuletzt geändert am: , , , Notizen zuletzt geändert am:

6 Review-Varianten (nach Graham)
Aktivität: Verstehen Autor leitet die Gruppe durch das Dokument und die dahinter stehenden Gedankenprozesse, so dass alle dasselbe verstehen und Einigkeit erzielt werden kann, was zu ändern ist. Walkthrough: [Presentation Review] Aktivität: Entscheiden Gruppe diskutiert das Dokument und trifft Entscheidungen über den Inhalt, z.B. wie etwas gemacht werden soll, Ja/Nein-Entscheidungen. Management-Review: [Projektstatus-Review] Inspektion: Hauptaktivität: Fehler finden Formale Einzel- und Gruppen-Prüfaktivität nach genau festgelegten Regeln, unter Verwendung von Vorgängerdokumenten und Standards. Folie zuletzt geändert am: , , , , , Notizen zuletzt geändert am: , Danach Video „Candid Inspection“ zeigen Quelle: Dorothy Graham

7 Begriffe (2) “major defect” (im Gegensatz zu “minor defect”)
Fehler, der möglicherweise erheblich höhere Kosten verursacht, wenn er später gefunden wird als jetzt andere übliche Definitionen: Fehler, der durch Tests gefunden werden kann Fehler, der durch den Benutzer gefunden werden kann Folie zuletzt geändert am: (Animation), , Notizen zuletzt geändert am: Auf deutsch “gravierender Fehler”, gute Übersetzung von “minor defect” fehlt noch. Auch Auslassungen sind Fehler. Anders als noch in Software Inspection, p 442, verwendet Gilb jetzt das Wort “möglicherweise” statt “wahrscheinlich”.

8 Kosten eines Major defects im Test oder im Betrieb
Durchschnittlicher Aufwand, einen Major defect zu finden und zu korrigieren, wenn er nicht im Review, sondern später gefunden wird: 9,3 h. Anzahl Fehler aus zufällig ausge-wählten Major defects (aus allen Dokument-Typen) Zum Vergleich: es kostet ca. nur 1 h Aufwand, um einen Major defect mit Reviews zu finden und zu korrigieren. Folie zuletzt geändert am: , , , Notizen zuletzt geändert am: Geschätzter Aufwand, den Fehler im Test oder im Betrieb zu finden und zu korrigieren (Bandbreite 1 bis 80 h) Quelle: MEL Inspektions-Daten Juni Januar 1990, “Software Inspection”, p 315

9 Begriffe (3) für Programme: NLOC non-commentary lines of code "Nichtkommentarzeilen", s. Notizansicht für Textdokumente: “Seite” oft auch "Netto-Seite" genannt (im Gegensatz zu "Druck-Seite") 300 “non-commentary” words “Inspektionsrate“ Prüfgeschwindigkeit, wird bei Programmen in NLOC / h und bei Textdokumenten in Seiten / h angegeben. Folie zuletzt geändert am: , , , , Notizen zuletzt geändert am: Bsp. Fachkonzept mit Seitenzahl 100, aber nur 40 Nettoseiten. Für Ebenau entsprechen 100 NLOC einer “Seite”. NLOC werden manchmal auch „Non-commented Lines Of Code“ genannt (auch „noncommented“, aber leider auch „Number of Lines Of Code“. Andere gebräuchliche Abkürzung: NCSL = „Noncommentary source lines“ Rösler 2007: NLOC ist in der Literatur nicht einheitlich definiert. Ich verwende folgende Variante: - Bei geändertem Code rechne ich nur die neuen und geänderten Zeilen dazu, nicht die unveränderten Zeilen. - Alle Kommentare und die Zeichen ";(){}„ werden (gedanklich) entfernt - NLOC ist dann die Anzahl der nicht leeren Zeilen Bei dieser Zählweise ergeben z.B. die folgenden 16 Programmzeilen genau 10 NLOC: 001 #include <stdio.h> 002 #define F_GET 003 static T_RC infozsc_get_load_control 004 ( /*input*/ T_FLUG_ID *flug_id, 006 ) 007 /* The load control value for the flug_id will be set */ 008 { 009 T_RC ret = ERR; /* Returncode der eigenen Prozedur */ 010 rules_filename = (char *) getenv ( "LOAD_CONTROL_RULESFILE" ) ; 011 if (rules_filename == NULL) 012 { /* Beginn Systemfehlerbehandlung */ xxtez_log_print( M_INFOZSC+F_GET+1, version, "getenv (LOAD_CONTROL_RULESFILE)" ,rc); ret = SYSF; 016 } /* Ende Systemfehlerbehandlung */

10 Erfahrungen anderer Firmen
Ein Projekt mit 200 Entwicklern bei AT&T Bell Laboratory führten mehrere Verbesserungen ein, u.a. Reviews. Die Produktivität stieg um 14% und die Qualität um Faktor 10. Aetna Insurance Company: Reviews fanden 82% der Fehler in einem COBOL-Programm, die Produktivität stieg um 25%. Weiteres COBOL-Beispiel (Gilb, Software Metrics): 80% der Entwicklungsfehler wurden durch Reviews entdeckt, die Produktivität stieg um 30%. Folie zuletzt geändert am: , (übersetzt), , , Notizen zuletzt geändert am: Folie aus QA-Systems Roadshow 2003, „Warum Code Inspektionen?“: • Das IBM Labor in Santa Teresa berichtet, dass das Finden eines Major Defect 3,5 Stunden in einer Inspektion benötigt. Das Finden des gleichen Fehlers durch Testen würde 15 – 25 Stunden dauern [Kaplan 1995]. • Kelly et al, berichtet von Projekten bei Jet Propulsion Laboratory (JPL), dass das Finden eines Fehlers durch formales Testen 17 Stunden benötigt und der gleiche Fehler durch Code- Inspektionen in 1,46 Stunden bzw. in Design- Inspektionen in 1,75 Stunden gefunden werden kann. [Kelly 1992] • Daten von Franz und Shih deuten an, dass im Schnitt der Aufwand zum Finden eines Fehlers mit Code- Inspektionen 1 Stunde beträgt, im Vergleich zu 6 Stunden durch Testen. [Franz 1994] • Ein Projekt bei Hewlett- Packard zeigte einen Return on Investment von 10: 1 (d. h. der eingesetzte Aufwand zahlte sich zehnfach aus) und eine Reduzierung der Time- To- Market von 1, 8 Monaten [Grady 1994] • Ein weiterer Bericht von IBM zeigt, dass eine Stunde zur Inspektion ca. 20 Stunden Testaufwand und 82 Stunden Reworkaufwand einsparte [Holland 1999] Weitere Beispiele siehe Notizseite in der PowerPoint-Datei Source: Humphrey 1989, Managing the software process, p186/187

11 Erfolgreiche Projekte sind nicht der Normalfall
53% 18% Mit richtig durchgeführten Reviews wäre der Anteil erfolgreicher Projekte viel höher! 29% Folie zuletzt geändert am: , , (erstellt), Notizen zuletzt geändert am: (Daten übernommen aus Proceedings 3wcsq vol II, Andreas Nehfort) 1994 [7]: suceeded 16%, challanged 53%, failed 31% 2000 [7]: suceeded 28%, challanged 49%, failed 23% 2004 [8]: suceeded 29%, challanged 53%, failed 18% Succeeded: the project is completed on time, on budget with all features & functions initially specified. Challenged: the project is completed and operational, but over budget, over the time estimate and offers fewer features & functions than initially specified. Failed: the project has been cancelled at some point during the development cycle. In 1994 the “Projects challenged” had an average cost overrun of +189% and have implemented about 61% of the features & functions initially specified. In 2000 the “Projects challenged” had an average cost overrun of +45% and have implemented about 67% of the features & functions initially specified. [7] Chaos Report 2001: The Standish Group International Inc [8] Chaos Demographics and Project Resolution, excerpt from 3rd Quarter 2004: The Standish Group International Inc. 2004 Abgebrochen Ziel verfehlt Erfolgreich Stand: 2004, Quelle: The Standish Group ältere Daten siehe Notizseite

12 Anteil von Korrekturtätigkeiten am Gesamtaufwand
44 % 56 % (Korrekturtätigkeiten) (reine Erstellung der Software) Ca. 2/3 des Rework-aufwands kann durch Reviews vermieden werden! (einmaliges) Durchspielen der Testfälle Spezifizieren der Testfälle Folie zuletzt geändert am: , , , Notizen zuletzt geändert am: „Rework“ wird oft auch „cost of non-quality“ genannt. Die Aussage "Ca. 2/3 des Reworkaufwands kann durch Reviews vermieden werden" ergibt sich aus der Aussage "geringere Entwicklungskosten (25-35%)" auf Folie "Nutzen von Reviews". 2/3 von 44% sind 29%, was genau im Bereich 25-35% liegt. Reworkanteil wird durch die Fehlerfindeeigenschaften der Reviewtechnik reduziert. Reworkanteil und Productionsanteil werden durch die Prozeßverbesserungseigenschaften der Reviewtechnik reduziert. „Rework“-Farben können wie folgt geändert werden: zuerst Gruppierung aufheben(!), dann Farbkästchen neben Rework anclicken, bei Diagramm „Reihe Rework“ auswählen, „Datenreihen formatieren“, etc. Anforderungs- definition Grobkonzept Feinspezifikation Codierung & Modultest Integrations- und Systemtest Quelle: Wheeler 1996, Software inspection: an industry best practice, p 9

13 Nutzen von Reviews geringere Entwicklungskosten (25-35%)
kürzere Entwicklungszeiten (25-35%) geringere Wartungskosten (Faktor 10-30) höhere Zuverlässigkeit ( mal weniger Fehler) Folie zuletzt geändert am: (Animation), , , Notizen zuletzt geändert am: Im seinem neueren Buch SI p 24 (s.a. p 17-19) bringt Gilb etwas andere Zahlen: net productivity increases of 30% to 100% (p 19: 30 Inspection Projekte erzeugten doppelt soviel LOCs wie 30 Structured walkthrough Projekte) - net timescale reductions of 10% to 30% - reduction in maintenance costs (2/3 due to defect elimination) by one order of magnitude Bsp. Imperial Chemical Industries ICI in GB, 400, abgeschaffte Reviews, 10* billiger zu warten Bsp. Project Orbit IBM LOCs Betriebssystem, statt 800 nur 8 Fehler Bsp. Abteilung mit 50 Mitarbeitern: 25-35% entspricht 20 neuen Mitarbeitern, die kein Gehalt und keine Räume bekommen. Fagan schreibt in The immediate and long-term effects of using this process [FAGAN INSPECTIONS plus Process Improvement (Anm. Rösler 2007)], as reported by users of the process, are evident in the following results: - 10 – 20X Reduction in customer reported defects. - 2X Increase in productivity % Reduction in Time to Shipment (Cycle Time.) - 50% Increase in meeting schedules and maintaining budgets % - 50% Improvement in Customer Satisfaction. Source: Gilb1988, Principles of Software Engineering Management, Table 12.2 vgl. auch SI p 24

14 Zeitpunkt der Fehlerentdeckung (mit Reviews)
10 20 30 40 50 gefundene Fehler vor Test während Test im Betrieb während Design vor Codierung Folie zuletzt geändert am: , , (Animation), , Notizen zuletzt geändert am: Die Daten von "ohne Reviews" (nur sichtbar wenn man Animation abspielt) stammen nicht von der Standard Chartered Bank, sondern sind geschätzt und demonstrieren nur das Prinzip. ["Wartungshinweis": damit die Animation von "ohne Reviews" klappt, wurde ein weißes Rechteck vor eine Gruppierung aus "mit Reviews" und "ohne Reviews" gesetzt.] Ohne Reviews würden die meisten Fehler “During Test” und “in Production” gefunden werden, also dann, wenn sie teuer zu beheben sind. Wenn Reviews wie hier bei der Standard Chartered Bank schon in Design-Phasen eingesetzt werden, können also die meisten Fehler schon vor der Test-Phase gefunden werden! Quelle: Tom Gilb, Software Engineering Management, Daten der Standard Chartered Bank

15 “Mitarbeiterberg” mit und ohne Reviews
Anzahl Mitarbeiter Design Codierung Test Inst. Planung/ Anford.def. Zeit mit Reviews Folie zuletzt geändert am: , , (Animation), , Notizen zuletzt geändert am: Reviews sind eine Investition in den frühen Projektphasen. In der 1. Hälfte der Produktentwicklung nehmen Reviews % des Projektaufwands ein. Radice ISBN , p49: The upfront cost of Inspections seems to vary between 8-20% of budget for the project in organizations that are 65% or more effective in removing defects with Inspections. SI p 27: The cost of running Inspection is approximately 10-15% of the development budget. Source: Fagan 1986 Schema

16 Einführung in Reviews und Inspektionen
Einleitung / Begriffe Rollen der Teilnehmer Phasen eines Reviews Rollen der Teilnehmer Folie zuletzt geändert am: , Notizen zuletzt geändert am:

17 Rollen der Teilnehmer Moderator Autor Protokollant Gutachter/Reviewer
Vorleser/Reader (nur wenn „double checking“ gemacht wird) Ein Teilnehmer kann mehrere Rollen übernehmen. Folie zuletzt geändert am: , , , , Notizen zuletzt geändert am: Protokollführer wird dort Protokollant, Reviewer wird Gutachter genannt. Manche ältere Reviewtechniken haben noch die Rolle des “Readers”, vgl. SI p 186. Einzige Einschränkung: der Autor darf zusätzlich höchstens die Rolle eines Gutachters übernehmen.

18 Einführung in Reviews und Inspektionen
Einleitung / Begriffe Rollen der Teilnehmer Phasen eines Reviews Phasen eines Reviews Folie zuletzt geändert am: , Notizen zuletzt geändert am:

19 Im Original-Tutorial folgten 13 Folien. ROS 06.11.2010
Overall Process Map Sources Product Checklists Change Requests to Project and Process Data Summary Master Plan Inspection Issue Log Brainstorm Exited Entry Planning Kickoff Checking Logging Brainstorming Edit Followup Exit Folie zuletzt geändert am: (Animation), , Notizen zuletzt geändert am: Die Teilnehmer sollten sich Seite mit Post-IT markieren Source: Tom Gilb, Team Leader Course Im Original-Tutorial folgten 13 Folien. ROS

20 Tutorial Stichproben-Reviews
Einführung in Reviews und Inspektionen Problematik Testaufwandsschätzung, Rework-Aufwand und Fehlerdichte Schätzung über Stichproben-Reviews Tipps für erfolgreiche Reviews Problematik Rework- Aufwand, Fehlerdichte Folie zuletzt geändert am: , Notizen zuletzt geändert am:

21 Anteil von Rework am Testaufwand
selbe Daten wie aus Folie 12, aber mit Blickwinkel "Testaufwand" statt "Gesamtaufwand" Testaufwand Rework macht in typischen Projekten mehr als die Hälfte des Test- aufwands aus. (einmaliges) Durchspielen der Testfälle Spezifizieren der Testfälle Folie zuletzt geändert am: , , (Variantenbildung "Testaufwand"), , Notizen zuletzt geändert am: „Rework“ wird oft auch „cost of non-quality“ genannt. Die Aussage "Ca. 2/3 des Reworkaufwands kann durch Reviews vermieden werden" ergibt sich aus der Aussage "geringere Entwicklungskosten (25-35%)" auf Folie "Nutzen von Reviews". 2/3 von 44% sind 29%, was genau im Bereich 25-35% liegt. Reworkanteil wird durch die Fehlerfindeeigenschaften der Reviewtechnik reduziert. Reworkanteil und Productionsanteil werden durch die Prozeßverbesserungseigenschaften der Reviewtechnik reduziert. „Rework“-Farben können wie folgt geändert werden: zuerst Gruppierung aufheben(!), dann Farbkästchen neben Rework anclicken, bei Diagramm „Reihe Rework“ auswählen, „Datenreihen formatieren“, etc. Anforderungs- definition Grobkonzept Feinspezifikation Codierung & Modultest Integrations- und Systemtest Quelle: Wheeler 1996, Software inspection: an industry best practice, p 9

22 Reworkaufwand und Fehlerdichte
Rework sind alle Arbeiten, die aus Major Defects resultieren, z.B. - Lokalisieren von gefundenen Fehlern - Korrigieren der Dokumente - Ändern von Testspezifikationen - Wiederholen von Testläufen, etc. (Minor Defects tragen definitionsgemäß nur unerheblich zum Reworkaufwand bei, s. Folie 7.) Der Reworkaufwand ist damit per Definition (zumindest annähernd) proportional zur Anzahl der Major Defects in den Dokumenten, also zur Fehlerdichte der Dokumente. Folie zuletzt geändert am: , , Notizen zuletzt geändert am: Fehlerdichten werden in Mj / p bzw. Mj / 100 NLOC angegeben, z.B. Anforderungsspezifikation AnfSpez-CSS.doc: 3,5 Mj / p Programm infcomp.c : 2,0 Mj / 100 NLOC

23 Die Fehlerdichte steuert den Reworkaufwand
typisches Projekt Mj Defect Dokumente, Programme Die Anzahl der Major Defects entscheidet … Rework Production … wie hoch der Reworkaufwand ist. Folie zuletzt geändert am: , Notizen zuletzt geändert am: Balkendiagramm: Source: Wheeler 1996, Software inspection: an industry best practice, p 9

24 Die Fehlerdichte ist stark variabel …
Projekt A, 5 mal weniger Mj Defects typisches Projekt Projekt C, 5 mal mehr Mj defects 3 Projekte mit um Faktor 25 unterschiedlichen Fehlerdichten Die Reviewtechnik-Literatur berichtet sogar von Projekten, die im Vergleich zu anderen Projekten eine um Faktor 100 (!) geringere Fehlerdichte hatten. Folie zuletzt geändert am: , , Notizen zuletzt geändert am: Bsp. Project Orbit IBM LOCs Betriebssystem, statt 800 nur 8 Fehler (Software Inspection p. 22) Bsp. für Faktor knapp 20 innerhalb ein und desselben Projekts: siehe Notizansicht der Folie "Lernkurve einer gesamten Organisation" in den Seminarfolien: Tom (Gilb) told me (Peter Rösler) on : at British Aerospace, Eurofighter, they had time delay, one reason was the software, he teached Inspections, they had 20 Mj/p and 18 months later only Mj/p. siehe auch Notizseite

25 … die Folgen für den Aufwand sind enorm
276 Wo 5 20 48 40 95 6 12 16 10 Requirements Preliminary Design Detailed Design Code & Unit Test Integration & System Test 5 mal weniger Mj Defects typisches Projekt 5 mal mehr Mj Defects 100 Wo Rework Production 65 Wo Folie zuletzt geändert am: , , , Notizen zuletzt geändert am: Mittleres Balkendiagramm: Source: Wheeler 1996, Software inspection: an industry best practice, p 9 Gesamtaufwand in Wochen Source: Peter Rösler,

26 Fehlerdichte als entscheidende Kennzahl
5 20 48 40 95 6 12 16 10 Requirements Preliminary Design Detailed Design Code & Unit Test Integration & System Test Dieses Projekt wird mit hoher Wahrscheinlichkeit nicht termingerecht fertig oder wird sogar ganz abgebrochen. Die Fehlerdichte gehört zu den wichtigsten Kennzahlen, die erfolgreiche von gescheiterten Projekten unterscheiden. Die Fehlerdichte ist für Projektleiter und Testmanager erst einmal unbekannt. Sie zu ermitteln ist eine (Qualitäts-) Managementaufgabe mit höchster Priorität! Folie zuletzt geändert am: , Notizen zuletzt geändert am: 276 Wo Sie zu senken ist noch wichtiger! (Aber nicht Thema dieses Vortrags.)

27 Fehlerdichte und Effektivität eines Reviews
Vor dem Review sieht das Dokument fehlerfrei aus. Die Fehlerdichte ist unbekannt. So viele Mj Defects sind vorhanden. Das Review findet einen Teil der Mj Defects: Die Mindest-Fehlerdichte ist damit bekannt. Offen ist: wie viele Mj Defects sind unentdeckt, also wie hoch ist die Fehlerdichte genau? Formeln: Effektivität = gefundene Mj alle Mj Folie zuletzt geändert am: , Notizen zuletzt geändert am: unentdeckte Mj = gefundene Mj * (1/Effektivität ─ 1)

28 Die Effektivität muss abgeschätzt werden
unentdeckte Mj = gefundene Mj * (1/Effektivität ─ 1) Leider auch erstmal unbekannt. Je nach Reifegrad des Review-Prozesses stark streuend (von unter 3% bis über 90%). Je genauer man die Effektivität abschätzen kann, desto genauer weiß man die Anzahl der unentdeckten Fehler und damit die Fehlerdichte. Beispiel: Die Effektivität des Reviews einer 20-seitigen Anforderungsspezifikation wird mit 50-66% geschätzt und es wurden durch das Reviewteam 100 Mj Defects entdeckt. Dann sind zwischen 50 und 100 Mj Defects unentdeckt, das (unkorrigierte) Dokument enthält zwischen 150 und 200 Mj Defects, die Fehlerdichte des unkorrigierten Dokuments liegt zwischen 7,5 und 10 Mj / p, die Fehlerdichte des korrigierten Dokuments liegt zwischen 2,5 und 5 Mj / p. Folie zuletzt geändert am: , , Notizen zuletzt geändert am: Mehrere Verfahren zum Schätzen der Effektivität werden später vorgestellt (im nächsten Kapitel).

29 Testaufwand vorhersagen
Rework Production Testaufwand Test-Reworkaufwand = Anzahl unentdeckter Mj * (durchschnittlicher) Reworkaufwand je Mj Test-Basisaufwand (z.B. Spezifizieren der Testfälle etc., einmaliges Durchspielen der Testfälle): wird mit üblichen Schätzmethoden abgeschätzt. Test-Reworkaufwand = Anzahl unentdeckter Mj * (durchschnittlicher) Reworkaufwand je Mj Folie zuletzt geändert am: , , Notizen zuletzt geändert am:

30 Reworkaufwand je Major Defect
Methoden, den Reworkaufwand je Major Defect zu bestimmen Kommentar zur Methode Nehmen Sie als erste grobe Schätzung an, die 9,3 h von Folie 8 gelten auch für die Mj Defects in Ihrem Projekt. Schnell machbar, aber der Wert kann bei Ihnen auch 2 bis 3 Mal höher oder niedriger liegen. Erfahrene Entwickler schätzen separat für jeden gefundenen Mj, in welcher Phase er sonst aufgetreten wäre und wie zeitaufwändig die Korrektur geworden wäre. Dann wird der Mittelwert gebildet. Aufwändig, liefert aber eine relativ gute Schätzung. (Die Daten aus Folie 8 sind übrigens genau so entstanden.) Verwenden Sie historische Daten aus eigenen ähnlichen Projekten, z.B. aus einer Fehlerdatenbank, in der auch die Korrekturaufwände erfasst sind. Ideal (Ist Ihre Firma vielleicht sogar schon auf CMM(I) Level 4?) Folie zuletzt geändert am: , Notizen zuletzt geändert am: Bem. zu "Nehmen Sie als erste grobe Schätzung an, die 9,3 h von Folie 8 gelten auch für die Mj Defects in Ihrem Projekt.": Noch besser ist es, wenn berücksichtigt wird, aus welcher Phase das Dokument stammt, das geprüft wird. Bei einer Anforderungsdefinition wird ein Mj Defect durchschnittlich mehr als 9,3 h verursachen, bei Code eher weniger. siehe auch Notizseite

31 Tutorial Stichproben-Reviews
Einführung in Reviews und Inspektionen Problematik Testaufwandsschätzung, Rework-Aufwand und Fehlerdichte Schätzung über Stichproben-Reviews Tipps für erfolgreiche Reviews Schätzung über Stichproben- Reviews Folie zuletzt geändert am: , Notizen zuletzt geändert am:

32 Schätzung über Stichproben-Reviews
Effektivitäts-Schätzverfahren: Vergleich mit opt IR Capture-Recapture Curve Fitting Subjektiv durch Experten Stichproben- Reviews Folie zuletzt geändert am: , Notizen zuletzt geändert am:

33 Aufwand für 100%ige Reviewabdeckung
Gilb: ca % des Projektaufwands (Radice: ca. 8-20%) Einsparung: z.B h eingespart durch 250 gefundene Mj defects Aufwand: z.B. 500 h verteilt auf 25 Reviews Folie zuletzt geändert am: , (weniger Animation), (erstellt, P.Rösler), Notizen zuletzt geändert am: Radice ISBN , p49: The upfront cost of Inspections seems to vary between 8-20% of budget for the project in organizations that are 65% or more effective in removing defects with Inspections. SI p 27: The cost of running Inspection is approximately 10-15% of the development budget. Die grüne Fläche geht genau genommen noch weiter nach rechts bis in die Testphasen hinein, weil z.B. auch Testspezifikationen mit Reviews geprüft werden müssen. Mj defects, die am Ende des Projekts auftauchen, sind im Durchschnitt teurer als am Anfang, und daher in der Grafik mit größerer Fläche dargestellt. Dass 1 gefundener Mj defect durchschnittlich 8 h Folgekosten einspart, wurde aus Folie "The downstream alternative cost of quality" übernommen (dort 9,3 h Folgekosten, Quelle: SI p315). Dass 500 h Reviewaufwand für 250 gefundene Mj defects nötig sind (Effizienz = 0,5 Mj/h), stimmt mit den Siemens-Daten aus Folie "Ein Dokument mit 2 Methoden geprüft (2)" überein, ist aber um Faktor 2 pessimistischer als sonst in der Literatur angegeben (sonst 1 Mj/h, s.a. Folie "The downstream alternative cost of quality"). Angenommen, die 500 h Reviewaufwand sind 12,5% des Projektaufwandes, dann handelt es sich um ein Projekt mit Gesamtaufwand 4000h = 2,35 MitarbeiterJahre. Notizen aus Folie „Mitarbeiterberg mit und ohne Reviews" : Reviews sind eine Investition in den frühen Projektphasen. In der 1. Hälfte der Produktentwicklung nehmen Reviews % des Projektaufwands ein. ROI = 4:1 Details siehe Notizseite

34 Stichproben-Reviews Ein Testmanager, wenn er "nur" eine Vorschau auf den zu erwartenden Testaufwand erhalten will, wird in diesem Fall kein Budget für eine 100%ige Reviewabdeckung der Anforderungs-, Design-, und Code-Dokumente erhalten. Es bleibt dann nur die Möglichkeit, mit Stichproben die Fehlerdichte der Dokumente festzustellen (mit allen Unsicherheiten, die bei Stichprobenverfahren unvermeidlich sind). Mit Stichproben zu arbeiten, ist in der Software-Industrie eher unüblich, wurde im Zusammenhang mit Reviews aber schon im Buch "Software Inspection" (Gilb/Graham 1993) empfohlen. Folie zuletzt geändert am: , , Notizen zuletzt geändert am: Software Inspection, ISBN

35 Vorteil von Stichproben
Wenn ein komplettes Dokument mit 100 oder mehr Seiten mit einem "gewöhnlichen" Review geprüft wird, wird nur ein kleiner Teil der Fehler entdeckt. Eine Abschätzung der realen Fehlerdichte ist kaum möglich. Ein oder zwei gut ausgewählte und gründlich geprüfte Stichproben erlauben eine viel bessere Abschätzung der realen Fehlerdichte des Dokuments. Folie zuletzt geändert am: , , Notizen zuletzt geändert am: nach Dorothy Graham

36 Aufwand für eine Stichprobe
Textdokument: 1,5 Seiten Annahmen: Teamgröße 3 (Autor + 2 Reviewer) Inspektionsrate 1,5 p/h (auch Autor prüft) Phase Checking nimmt 30% des Aufwands ein , Aufwand: 10 h Erwartete Effektivität: ca. 50% Programm: 125 NLOC Annahmen: Teamgröße 3 (Autor + 2 Reviewer) Inspektionsrate 125 NLOC/h (auch Autor prüft) Phase Checking nimmt 30% des Aufwands ein , Aufwand: 10 h Folie zuletzt geändert am: , , Notizen zuletzt geändert am: Agile Inspektionen: Sie werden auch "Extreme Inspections" oder "Agile Specification Quality Control (SQC)" genannt, für eine Einführung s. Wenn 2 Reviewer das Individual Checking durchführen, sind 2 h Aufwand nötig. Ein Logging Meeting findet nicht statt, sondern die Anzahl der Fehler wird aus den Daten der einzelnen Reviewern hochgerechnet. Mit angenommen 1 h Aufwand für Vorbereitung und Datenanalyse sind dann 3 h Aufwand zu erwarten für 1,5 p oder 125 NLOC. Anmerkungen zur restlichen Folie: Textdokument: 1 Seite = 300 Wörter Programm: bei 50 Zeilen je Druckseite und einem Verhältnis LOC/NLOC von ca. 2/1 passen folglich 125 NLOC auf ca. 5 Druckseiten. (NLOC = non-commentary lines of code) In SI p29, table 2.1 wird angegeben, dass die Phase Checking 20-30% des Aufwands der gesamten Inspektion einnimmt. Radice p 328: Russell suggests that the time for Inspections is „Days = 3 times n KLOC.“ These are days in the schedule, but not full days of Inspections. Russell [RUS91]: elapsed time (in days) = 3x n kLOC. Here n is an estimate of how many thousands lines of code will be inspected. … For example, a 20 KLOC program being inspected by a four-person team (including the author) would require 60 days or 12 weeks of elapsed time for preparation, overview and inspection. The process would consume a total of 48 man-weeks of effort. In isolation, this figure may seem unacceptably large - a full man-year. However, in large real-time projects involving millions of lines of code, the average designer produces 3,000 to 5,000 lines of code a year. Thus our 20,000-line example would require 4 to 6.7 man-years to develop. In this context, 48 man-weeks is 15 to 25 percent of the total effort - certainly a significant but not an unreasonable component. Rösler 09/2006: wenn man [RUS91] als Basis nimmt, kämen für 125 NLOC 12 h Aufwand heraus (bei 4 Reviewern). Erwartete Effektivität: ca. 50% Mit agilen Inspektionen ist der Aufwand nur ca. 3 h, siehe Notizseite

37 Effektivitäts-Schätzverfahren
Stichproben-Reviews Effektivitäts-Schätzverfahren: Vergleich mit optimaler Inspektionsrate Capture-Recapture Curve Fitting Subjektiv durch Experten Vergleich mit optimaler Inspektions- rate Folie zuletzt geändert am: , , Notizen zuletzt geändert am:

38 Vergleich der realen Inspektionsrate mit der optimalen Inspektionsrate
Bei dieser Methode wird die Effektivität des Reviews eines Dokuments wie folgt abgeschätzt: Mit Angaben aus der Literatur oder eigenen historischen Daten wird die für diesen Dokumenttyp "optimale Inspektionsrate" geschätzt. Die "erreichbare Effektivität" wird abgeschätzt, also die Effektivität, die bei Einhalten der optimalen Inspektionsrate zu erwarten ist. Die reale Inspektionsrate des Reviewteams wird mit der optimalen Inspektionsrate verglichen. Wenn sie höher ist (also "schlampiger" geprüft wurde), wird die reale Effektivität entsprechend niedriger angesetzt als die erreichbare Effektivität. Folie zuletzt geändert am: , Notizen zuletzt geändert am:

39 Optimale Inspektionsrate
Angaben aus der Literatur: Optimale Inspektionsrate für Textdokumente: 1 bis max. 2 Seiten / h (nach Gilb/Graham, 1993) (Der Wert ist kontraintuitiv, Entwickler vermuten eher 5-10 Seiten / h, siehe aber Folien 72-81) Optimale Inspektionsrate für Programme: 100 – 150 NLOC / h Folie zuletzt geändert am: , Notizen zuletzt geändert am:

40 Erreichbare Effektivität
"Daumenwert" für erreichbare Effektivität: 50%. Ca. 50% der im Dokument vorhandenen Fehler werden durch das Reviewteam entdeckt, sofern die optimale Inspektionsrate eingehalten wird. Der "Daumenwert" kann noch feinjustiert werden, wenn Sie den Reifegrad Ihres Review-Prozesses bzw. Ihrer Softwareentwicklung berücksichtigen: Maturity Effectiveness inspections just implemented 50-60% refined processes 75-85% refined processes, exceptional cases >90% Source: Fagan 2001 Angaben von Michael Fagan: ("Erfinder" der SW-Inspektionen) Folie zuletzt geändert am: , , , Notizen zuletzt geändert am: Mit "Fehler" sind "Mj defects" gemeint, (= "operational defects" im Sprachgebrauch von Fagan) Fagan’s Vortrag bei der sd&m-Konferenz am : “When people implement inspections right away they might find 50 or 60% of all the operational defects. I'm not talking about spelling mistakes or anything but things that would make for failure. When you refine the inspection process that you dealing with, we find now, you know, the last couple of years, 4, 5 years,  people we are dealing with, when they refine their processes, they find between 75 and 85% of all operational defects before any testing. Some of them are finding more than 90% if they are exceptional cases.” Ob Fagan die Zahlen pro Reviewdurchgang angibt oder kumuliert (wegen "before any testing"), ist mir unklar. (P.Rösler 9/2006) Genauere Quellenangaben siehe Notizseite

41 Erreichbare Effektivität (2)
weitere Literaturangaben: immature inspection process Effectiveness default estimation (for all types of document) 30% mature inspection process source code 60% pseudocode 80% module and interface spec. 88% Source: Gilb, SI p23, p383, Lindner 1992 Source: Radice 2002 90-100% Level 5 75-90% Level 4 65-75% Level 3 50-65% Level 2 <50% Level 1 Effectiveness SW-CMM Die Anzahl der Reviewer wird in den Literaturstellen nicht berücksichtigt, vermutlich weil sie die Effektivität weit weniger beeinflusst als es z.B. die Inspektionsrate vermag. Folie zuletzt geändert am: , , , Notizen zuletzt geändert am: Radice 2002: ISBN , p403: "… over the past twent-eight years from the many experiences I have had with organizations practicing Inspections I have come to see the following effectiveness pattern in organizations using the SW-CMM. .. Figure 14.1" SI p202: "removal effectiveness (between 30% and 88%)", p203: "… the best Inspections only find up to 88% of the errors.", p23: "IBM Rochester (Minnesota) Labs. Effectiveness of defect removal using Inspections (1991-2): in Source code 60% for single Inspection pass, in pseudocode 80%, in module and interface specification 88%", p383: "undetected defects (by the Inspection process): Default (for immature Inspection process); 70% in all documents. … The observed range for Inspection effectiveness in mature processes at IBM Rochester Labs in 1991 was 60% of all available defects in source code, 80% in pseudo code, and 88% in module and interface definition (Lindner, 1992)." todo: Quelle zu "Eine Firma berichtete" ( : vorgestern gelesen, finde die Quelle auf die Schnelle nicht) Eine Firma berichtete, dass 4 oder mehr Reviewer bei Code-Reviews nur unwesentlich mehr Fehler fanden als 3 Reviewer. Empfehlung: feinjustieren Sie die Effektivität nur dann anhand der Anzahl der Reviewer, wenn es nur sehr wenige Reviewer sind (einer oder evtl. zwei). Genauere Quellenangaben siehe Notizseite

42 Berücksichtigen der realen Inspektionsrate
Wenn Ihr Reviewteam die optimale Inspektionsrate eingehalten hat, dann setzen Sie als reale Effektivität natürlich die erreichbare Effektivität an. Wenn aber zu schnell geprüft wurde, rechnen Sie die Effektivität linear herunter. "Linear", denn es gibt Hinweise, dass in der Phase Individual Checking die Fehler zeitlich ungefähr gleichverteilt gefunden werden und es daher eine konstante Fehlerentdeckungsrate gibt, mit der Folge: „Das Verfehlen der optimalen Inspektionsrate um Faktor x bewirkt ein Sinken der Effektivität um Faktor x“ (x>=1). (Ausführliche Begründung siehe Folie zuletzt geändert am: , Notizen zuletzt geändert am:

43 Konstante Fehlerentdeckungsrate in Phase "Individual Checking"
Die 80/20-Regel gilt hier nicht! Folie zuletzt geändert am: , , (Seminarversion), , (erstellt), Notizen zuletzt geändert am: Von den 28 Reviewern prüften 8 das Übungsbeispiel 1 (Textdokument) und 20 das Übungsbeispiel 2 (C-Programm). Die Inspektionsraten bei Übungsbeispiel 1 lagen zwischen 1,1 und 2,45 p/h (Mittelwert 1,67 p/h) und bei Übungsbeispiel 2 zwischen 55 und 96 NLOC/h (Mittelwert 69 NLOC/h). Die Inspektionsraten lagen also recht nahe an den empfohlenen optimalen Inspektionsraten, so dass die Kurve aussagekräftig über den gesamten zu untersuchenden Prüfzeitraum ist. Die einzelnen Zeitachsen der Reviewer wurden vor dem Aufsummieren gestreckt bzw. gestaucht, damit alle Zeitachsen bei "100% individuelle Prüfzeit" enden. (Bei der nächsten Folie "Ähnlicher Befund beim Review von UML-Modellen" ist dies wohl nicht der Fall, wie aus der Beschriftung der x-Achse zu vermuten ist.) Die insgesamt 557 "gefundenen Fehler" bestehen aus 263 Major defects, 247 minor defects, 3 Process Improvements und 44 Fragen an den Autor. Wenn man in der Kurve nur die Major defects darstellt, und zwar getrennt nach Übungsbeispiel 1 und 2, dann stellt man fest, dass bei Übungsbeispiel 1 die Kurve über der Diagonalen liegt (bis zu [x=28%, y=48%]) und dass bei Übungsbeispiel 2 die Kurve unter der Diagonalen liegt (bis zu [x=24%, y=9%]). Dies scheint aber nicht an einem prinzipiellen Unterschied zwischen Textdokumenten und Programmen zu liegen. Wie aus den Musterlösungen der Übungen hervorgeht, sind die Major defects in Übungsbeispiel 1 im vorderen Teil gehäuft und in Übungsbeispiel 2 im hinteren Teil gehäuft zu finden. Die Kurven von Übungsbeispiel 1und 2 decken sich gut mit den aus den Musterlösungen zu erwartenden Kurven. Die genaue Argumentation müsste also lauten: die Fehlerentdeckungsrate spiegelt die reale Verteilung der Fehler im Dokument wider. Und weil über viele Dokumente gemittelt die Fehler gleichverteilt zu erwarten sind, ist über viele Reviewer gemittelt eine konstante Fehlerentdeckungsrate zu erwarten. konstante Fehlerentdeckungs-rate! Kumuliertes Histogramm für 28 Reviewer Source: Peter Rösler, s.a. Notizansicht der Folie

44 Beispiel Aus einer 50-seitigen Anforderungsspezifikation werden 3 Seiten geprüft, die nach Angaben von Autor und Projektleiter eine gute Stichprobe darstellen. Da keine historischen Daten vorliegen, werden 1,5 Seiten / h als optimale Inspektionsrate (also 2 h Prüfzeit) und eine erreichbare Effektivität von 50% angenommen. Die Reviewer fanden insgesamt 3 Mj Defects, also 1 Mj Defect / Seite. Der Mittelwert der Prüfzeiten lag bei 60 Minuten, was einer realen Inspektionsrate von 3 Seiten / h entspricht. Weil die Reviewer durchschnittlich um Faktor 2 zu schnell geprüft hatten, wird als reale Effektivität 50% / 2 = 25% angenommen. Die Fehlerdichte der Anforderungsspezifikation liegt also bei ca. 4 Mj / Seite. In den 50 Seiten sind daher ca. 200 Mj verborgen. Folie zuletzt geändert am: , Notizen zuletzt geändert am:

45 Beispiel (2) Erfahrene Entwickler des Projektes vermuten, dass ein Anforderungsfehler später in den Testphasen ca. 10 h Aufwand verursacht. Daher wird der Reworkanteil der Testphasen, der durch Anforderungsfehler verursacht ist, ca. 200 * 10 = h betragen (dazu kommt noch der durch Design- und Codierungs-Fehler verursachte Reworkanteil). Testmanager und Projektleiter sind durch die h beunruhigt. Da sie vermuten, dass die Genauigkeit der obigen Schätzung bestenfalls bei Faktor 2 liegt, werden noch 2 weitere Stichproben-Reviews durchgeführt und die Fehlerdichte mit einem genaueren Verfahren (z.B. mit Capture-Recapture) ermittelt. Folie zuletzt geändert am: , , Notizen zuletzt geändert am:

46 Effektivitäts-Schätzverfahren
Stichproben-Reviews Effektivitäts-Schätzverfahren: Vergleich mit optimaler Inspektionsrate Capture-Recapture Curve Fitting Subjektiv durch Experten Capture- Recapture Folie zuletzt geändert am: , , Notizen zuletzt geändert am:

47 Capture-Recapture Bei dieser Methode wird ermittelt, wie viele Fehler von zwei (oder mehreren) Reviewern entdeckt wurden ("Doubletten"). Aus diesen Daten wird dann die Effektivität des Reviews geschätzt. Diese Methode ist aus der Biologie bekannt und wird verwendet, um die Größe von Tierpopulationen zu ermitteln. In der Softwareentwicklung kann Capture- Recapture ganz analog eingesetzt werden und wurde als Bestandteil von TSP (Team Software Process) von Watts Humphrey vom Software Engineering Institute vorgestellt. Folie zuletzt geändert am: , Notizen zuletzt geändert am: Watts Humphrey, Introduction to the Team Software Process(SM). Addison Wesley, 2000, ISBN X

48 Ein Teich mit unbekannter Anzahl von Fischen
Fang A ergibt 10 Fische, die markiert und wieder freigelassen werden. Fang B (irgendwann später) ergibt 12 Fische, darunter 3 markierte (C). Gesamtzahl der Fische: T = A * B / C 10 * 12 / 3 = 40 Fische A C T B Folie zuletzt geändert am: , Notizen zuletzt geändert am: (Real sind es 50 Fische. So ist das eben mit Schätzmethoden.)

49 Formeln Anzahl gefundener Fehler (defects found) F = A + B - C
Anzahl aller Fehler (total defects) T = A * B / C (Schätzung) Effektivität E = F / T (Schätzung) Wobei: A = Anzahl Fehler, die von Reviewer A gefunden wurden B = Anzahl Fehler, die von Reviewer B gefunden wurden C = Anzahl Fehler, die von beiden gefunden wurden C Folie zuletzt geändert am: , Notizen zuletzt geändert am: F = = 19 T = 10 * 12 / 3 = 40 (real 50) E = 19 / 40 = 47,5% (real 36%) T A B

50 Tipps zur Anwendung Feinjustierung der Schätzung:
Wenn beide Reviewer unterschiedliches Spezial-Know-How haben und damit verschiedene Fehler des Dokuments nur mit sehr unterschiedlichen Wahrscheinlichkeiten finden können, müssen Sie die Effektivitätsschätzung entsprechend korrigieren. Capture-Recapture bei mehr als 2 Reviewern: Reviewer A ist der Reviewer, der am meisten Fehler gefunden hat. Die anderen Reviewer stellen "Reviewer B" dar, wobei ein Fehler, der von mehreren gefunden wurde, natürlich nur einfach zählt. Folie zuletzt geändert am: , Notizen zuletzt geändert am: Annahmen bei Capture-Recapture: Alle Inspektoren haben gleiche Fähigkeit, Fehler zu finden <wirklich nötig? ROS > Alle Fehler haben gleiche Wahrscheinlichkeit gefunden zu werden Anwendung: - Fehler, die alle Inspektoren gefunden haben, sind gesondert zu markieren (z.B. eigene Spalte im Reviewprotokoll) - checklistenbasierte Lesetechnik, wegen Varianzen (sonst evtl. Widerspruch zur Annahme 1 - Laut [Freimut et al 2001] beeinträchtigt die Lesetechnik die Schätzung wesentlich geringer als die Fehlerentdeckungs-Wahrscheinlichkeit. Freimut B., Laitenberger O., Biffl S. (2001) "Investigating the Impact of Reading Techniques on the Accuracy of Different Defect Content Estimation Techniques", Proc. of IEEE Int. Software Metrics Symposium, London, April 2001. siehe auch Notizseite

51 Effektivitäts-Schätzverfahren
Stichproben-Reviews Effektivitäts-Schätzverfahren: Vergleich mit optimaler Inspektionsrate Capture-Recapture Curve Fitting Subjektiv durch Experten Curve Fitting Folie zuletzt geändert am: , , Notizen zuletzt geändert am:

52 Sortierung der Daten nach bestimmten Kriterien
Curve Fitting Sortierung der Daten nach bestimmten Kriterien Anwendung von Regressionstechniken zum Erarbeiten einer Kurve (to fit a curve) Hochrechnen auf Basis der ermittelten Kurve Bei Reviews am häufigsten: Detection Profile Method (DPM) Folie zuletzt geändert am: , Notizen zuletzt geändert am:

53 Detection Profile Method (DPM)
Folie zuletzt geändert am: , , Notizen zuletzt geändert am: Freimut B., Laitenberger O., Biffl S. (2001) "Investigating the Impact of Reading Techniques on the Accuracy of Different Defect Content Estimation Techniques", Proc. of IEEE Int. Software Metrics Symposium, London, April 2001. Die gefundenen Fehler (hier 21 Stück) wurden nummeriert und entsprechend der Anzahl von Inspektoren, die sie gefunden hatten sortiert. Beispiel: Fehler Nr. 5, 6, 7 und 8 wurden von 3 Inspektoren gefunden. Anschließend wird eine Kurve durch die Punkte gelegt und damit die Anzahl der gesamt enthaltenen Fehler auf 26 prognostiziert. Wie mehrere Studien zeigten, neigt dieses Modell allgemein zu Unterschätzungen; es neigt aber zu Überschätzungen, falls genau ein Inspektor keinen Fehler findet. Gleichzeitig kann es sein, dass bei sehr geringer Überlappung der Inspektoren z.B. bei einer perspektivenbasierten Lesetechnik die Kurve sehr flach wird und damit ungenau. Insgesamt ist eine Entscheidung auf Reinspektion wegen zu hoher Restfehlerzahl eine sichere Entscheidung, da wahrscheinlich mehr Fehler nicht erkannt wurden, als DPM schätzt. Quelle: [Freimut et al 2001], Figure 2: Example of the Detection Profile Method Mehr Details siehe Notizseite

54 Effektivitäts-Schätzverfahren
Stichproben-Reviews Effektivitäts-Schätzverfahren: Vergleich mit optimaler Inspektionsrate Capture-Recapture Curve Fitting Subjektiv durch Experten Subjektiv durch Experten Folie zuletzt geändert am: , , Notizen zuletzt geändert am:

55 Subjektive Schätzung durch Experten
Schätzung der gefundenen vs. der Gesamtzahl im Dokument vorhandenen Fehler [Freimut et al 2001]: Laut mehrerer Studien überraschend genaue Schätzung Oder Schätzung von Gesamtzahl der Fehler Minimale Anzahl Wahrscheinliche Anzahl Maximale Anzahl Aber [Freimut et al 2001]: In 50% aller Reviews liegt die reale Gesamtzahl der Fehler sogar noch über der geschätzten "maximalen Anzahl". Folie zuletzt geändert am: , , Notizen zuletzt geändert am: Freimut B., Laitenberger O., Biffl S. (2001) "Investigating the Impact of Reading Techniques on the Accuracy of Different Defect Content Estimation Techniques", Proc. of IEEE Int. Software Metrics Symposium, London, April p21: However, the maximum estimate is underestimating in 50% of all inspections. Therefore, it is not recommendable to rely on this estimate as an upper bound of the defect content. Details siehe Notizseite

56 Tutorial Stichproben-Reviews
Einführung in Reviews und Inspektionen Problematik Testaufwandsschätzung, Rework-Aufwand und Fehlerdichte Schätzung über Stichproben-Reviews Tipps für erfolgreiche Reviews Tipps für erfolgreiche Reviews Folie zuletzt geändert am: , Notizen zuletzt geändert am: Im Original-Tutorial folgten 24 Folien. ROS

57 Kontaktdaten Name: Peter Rösler Firma: ReviewConsult
Hermann-Gmeiner-Weg 12 81929 München Tel.: +49 (0) 172/ Name: Maud Schlich Tel.: +49 (0) 162/ Folie zuletzt geändert am: , Notizen zuletzt geändert am: