Design- und Code-Reviews für Embedded Software

Präsentation zum Thema: "Design- und Code-Reviews für Embedded Software"—  Präsentation transkript:

1 Design- und Code-Reviews für Embedded Software
Übersicht Motivation, Reviewarten, Begriffe Wasserfallmodell und klassische Reviews Agile Inspektionen (auch für Wasserfallprojekte) Folgerungen für Tester Datei zuletzt geändert: , (erstellt) Folie zuletzt geändert am: , (erstellt) Dipl.-Inform. Peter Rösler

2 Code-Reviews bei Embedded Software wichtiger als für andere Software
Motivation Stephan Grünfelder: (Embedded Testing Konferenz 2015, Keynote-Vortrag „Test von Embedded Software“) Code-Reviews bei Embedded Software wichtiger als für andere Software Auch Design ist bezüglich Wartbarkeit und Sicherheit zu inspizieren Im Folgenden geht es darum, wie man Design- und Code-Reviews so durchführt, dass möglichst viele Fehler gefunden werden. Folie zuletzt geändert am: , Notizen zuletzt geändert am: Grünfelder per Mail : … bei Wartbarkeit meine ich nicht nur die Wartbarkeit von Code – da unterscheidet sich embedded C++ mitunter wenig von Desktop C++, ich meine auch Wartbarkeit des Systems überhaupt – z.B. Abspeichern von Parametern bei Feldausfällen für eine spätere Analyse und die Zugänglichkeit des Prozessors für ein Debugger-Kabel. Also ich sehe beim Thema Wartbarkeit sowohl Software-Aspekte als auch System/Hardware-Aspekte.

3 Reviewarten (1) Reviewart Reviewobjekt Informelles Review
Hauptzweck Informelles Review Desk-Check, 4 Eye Check, Passaround Ein einzelnes Dokument typischerweise Fehler finden Walkthrough Inspektion Review*, Peer-Review, Fagan-/Gilb-Inspektion Folie zuletzt geändert am: , , , , Notizen zuletzt geändert am: * Die „Inspektion“ wird oft „Review“ genannt. Daher muss beim Wort „Review“ immer aus Zusammenhang erschlossen werden, ob Überbegriff „Review“ oder Reviewart „Review/Inspektion“ gemeint ist. Quelle: Rösler et al. (2013, p14)

4 Reviewarten (2) Reviewart Reviewobjekt Agile Inspektion
Hauptzweck Agile Inspektion Extreme Inspection, Agile Specification Quality Control Stichprobe aus einem Dokument typischerweise Seiten Lernkurve des Autors fördern Um zukünftige Fehlerrate zu senken Technisches Review Expertenreview Ein einzelnes Dokument oder ein Softwareprodukt Eignung bewerten, Fehler finden Management-Review Projekt-Status-Review, Meilensteinreview Projekt als Ganzes Projektfortschritt bewerten Audit Prozesse des Projekts oder der Organisations- einheit Prozesseinhaltung Folie zuletzt geändert am: , , , , Notizen zuletzt geändert am:

5 “major defect” (im Gegensatz zu “minor defect”)
Begriffe (1) “major defect” (im Gegensatz zu “minor defect”) Fehler, der möglicherweise erheblich höhere Kosten verursacht, wenn er später gefunden wird als jetzt Folie zuletzt geändert am: , , Def. error/mistake, , 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”.

6 Begriffe (2) “Inspektionsrate“
Prüfgeschwindigkeit, wird bei Programmen in NLOC / h und bei Textdokumenten in Seiten / h angegeben. Effektivität = gefundene Mj alle vorhandenen Mj Effektivität eines Review-Teams liegt irgendwo zwischen 3% und >90% (!) Folie zuletzt geändert am: , , (erstellt), Notizen zuletzt geändert am:

7 Anforderungsdefinition
Typisches V-Modell z.B. 2 Jahre t Fachkonzept Anforderungsdefinition Design Codierung Modultest Integrationstest Systemtest Abnahmetest RVW RVW Folie zuletzt geändert am: , , , (erstellt), Notizen zuletzt geändert am: Mit den Reviews in den Testphasen werden Testpläne und Testfälle inspiziert. G.T : Dargestellt ist das sogenannte V-Modell und nicht das Wasserfallmodell. Der Unterschied liegt allerdings lediglich in der Unterteilung der Testphase in mehrere Tests und der Darstellung als V. RVW = Review / Inspektion

8 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

9 Reworkaufwand und Fehlerdichte
Rework sind alle Arbeiten, die aus Major Defects resultieren - Lokalisieren von gefundenen Fehlern - Korrigieren der Dokumente - Ändern von Testspezifikationen - Wiederholen von Testläufen, etc. Reworkaufwand per Definition (zumindest annähernd) proportional zu Anzahl der Major Defects in den Dokumenten, also zu Fehlerdichte der Dokumente. Folie zuletzt geändert am: , , , , Notizen zuletzt geändert am:

10 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

11 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 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

12 … 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,

13 Rollen der Teilnehmer Moderator Autor Protokollführer Reviewer
Ein Teilnehmer kann mehrere Rollen übernehmen. Folie zuletzt geändert am: , , , , Notizen zuletzt geändert am: 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 Reviewers übernehmen.

14 Phasen eines Reviews Master Planung Plan Review- objekt
Kick-off (optional) Individuelle Vorbereitung Reviewsitzung Follow-up Überarbeitung Review- objekt Checklisten Master Plan List of Findings Data Summary frei- gegebenes Review Report Vorgänger- dokumente Folie zuletzt geändert am: , , , Notizen zuletzt geändert am: Die Teilnehmer sollten sich Seite mit Post-IT markieren Quelle: Rösler et al. (2013, p11)

15 Individuelle Vorbereitung
potentielle “major defects” finden und notieren optimale Checking Rate einhalten Lesetechniken einsetzen (z.B. Checklisten) Fast alle Fehler (ca %), die das Reviewteam entdecken kann, werden schon in dieser Phase gefunden! Folie zuletzt geändert am: , , , , Notizen zuletzt geändert am: Gibt es „Zaubertechnik“? Man kommt nicht umhin, alles zu lesen. Diskussion: wie notieren wir die Fehler? (handschriftlich, aber es gibt Firmen mit Formularen) Diskussion: was ist die große Gefahr? Reviewer nimmt sich die Zeit nicht. (Rundruf) Danach Experiment „Basisprüftempo“. 10-20 major defects / Seite erwartet Gilb (SI p 385). 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. (SI p 381) 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. [die „95%“ kommen von Votta & Porter (zitiert in Radice, Ronald A.: High Quality Low Cost Software Inspections, Paradoxicon Publ., 2002, S. 159)]

16 Empfohlene Inspektionsraten
Programme 100 – 150 NLOC / h LOC/h Textdokumente Gilb/Graham: ca. 1 Seite / h Strauss/Ebenau: 3 – 5 Seiten / h IEEE Std : 2 – 3 Seiten / h 1  0.8, “typically “, “avoid rates above 2 p/h“ Folie zuletzt geändert am: , , (Animation), , Notizen zuletzt geändert am: - Radice ISBN , p95: preparation LOC for Code Units. p192: LOC for this book means non-commentary source lines of code added and modified. ... in C lines delimited with a semicolon. - Strauss/Ebenau ISBN , p89: preparation 150 NLOC/hour - Wiegers ISBN , p77: optimum balance of efficiency and effectiveness NLOC/h - (Stand ), p12: „reading rate: ... For code in a high-level language, the ideal rate is about documented lines of code per hour.“ D.h. LOC nicht NLOC, allerdings ist die reading rate für "double checking" gemeint, nicht für "individual checking". - SI p154: individual checking p/h. p80: until your own rate data is available, avoid rates above 2 p/h. - Gilb (Download Center), “Optimizing Inspection”: p/h - Gilb Optimum checking rate ranges between 0.2 and 1.8 pages (of 300 non-commentary words) per checking hour. It is typically 0.3 to 1.0 pages/hour. - andere Gilb-Quelle (wo finde ich gerade nicht mehr): individual checking p/h Ebenau an Gilb 2001: “Indeed I recommended a rate of 3 to 5 pages per hour to Peter. I have found this inspection rate to be pragmatically "doable," and while it may not be "optimal" at least the job will get done in the real world and contribute to a better product.” Evtl. in Word „Wörter zählen“ vorführen. [Fundus eigener langsamer Durchleseraten für Rechtschreibfehler und einige wenige Querchecks: - 8 p/h, 15 p/h p/h IUP learning (SEI-Übungsbeispiel) - 9 p/h A&T Positionspapier (incl. Rechtschreibfehler ausbessern) - 10/p für engl. Daich-Artikel p/h für Gilb-Buch - 22p/h für Buch „Peer Reviews in Software“ von Wiegers (Anfang 2002 gelesen) p/h (p=300 w) für Lesen von engl. Artikel p/h (BRS-Seiten) für Bag-HB korr.lesen - 28 p/h für CMM Technical Report (7h für 200 Netto-p = 476 p) p/h für „Der Termin“ - 44 p/h (p=300 w) für "High Qual. Low Cost Softw. Inspections" Jul-Sep02 (nach Schnelllesekurs 06/2002) - 60 p/h (p=300 w) für Lesen von Buch „Train the Trainer“ (dt.) (ca gelesen) ] für Architektur- und Requirements-Dokumente Weitere Daten siehe Notizseite in der PowerPoint-Datei

17 Die Effizienz geht rasch auf fast Null zurück.
Fehlerfinderate flacht ab, sobald Reviewer alle seine Prüfstrategien ausgeschöpft hat Die Effizienz geht rasch auf fast Null zurück. Effizienz = gefundene Mj / h Die optimale Inspektionsrate von Gilb/Graham sagt die Stelle des „Knicks“ voraus. (Behauptung, P.Rösler 2011) Folie zuletzt geändert am: , , , (erstellt) P.Rösler, Notizen zuletzt geändert am: Auch der Folientitel „ Die Kurve flacht ab, sobald ein Reviewer alle seine Prüfstrategien ausgeschöpft hat” ist erstmal nur eine Behauptung (P.Rösler 2011). Grafik aus: A. Dunsmore, M. Roper, and M. Wood, “The Development and Evaluation of Three Diverse Techniques for OO Code Inspection,” IEEE Trans. Software Eng., vol. 29, no. 8, Aug Java was chosen for the code documents... The documents presented to participants for inspection were approximately 200 lines in length, this being in agreement with most opinion of what can reasonably be inspected in 90 minutes [10], [20], [12], [6]. Anmerkung (P.Rösler 2011): 200 lines in 90 Minuten sind 133 lines/h. Da schon nach ca. 70 Minuten fast nichts mehr gefunden wurde, ist hier die optimale Inspektionsrate eher bei ca. 170 lines/h anzusetzen. (Klingt ein bisschen hoch, vielleicht wurden nicht NLOC gezählt, sondern LOC incl. Leerzeilen und Kommentarzeilen.) Anmerkung (P.Rösler 2011): Die Kurve zeigt die Effizienz eines einzelnen Reviewers an. Für ein gesamtes Reviewteam sind noch Doubletteneffekte zu berücksichtigen. Je gründlicher die einzelnen Reviewer prüfen, desto mehr Doubletten sind zu erwarten. Vermutung: Die Kurve eines gesamten Reviewteams flacht vorher schon etwas ab und der „Knick“ ist nicht so ausgeprägt. Source: Dunsmore, Roper & Wood 2003 Quelle: s. Notizansicht der Folie

18 Effektivität eines Reviews
„Daumenwert“ : ca. 50% der im Dokument vorhandenen Fehler werden durch das Reviewteam entdeckt, sofern die optimale Inspektionsrate eingehalten wird. 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

19 Effektivität eines Reviews (2)
Wenn die optimale Inspektionsrate ignoriert wird: immature inspection process Effectiveness the normal for inspections not optimized with optimal checking rates etc. about 3% Source: Tom Gilb / Kai Gilb 2004 Klingt viel zu pessimistisch. Stimmt aber! (Zumindest für Textdokumente) Folie zuletzt geändert am: , , , Notizen zuletzt geändert am: (Forum, Stand ), Topic “Insp., Qual. Control”, Thread “Completeness of candidate doc.”, Posting 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%.” (Stand ): "Warum Prüfen oft 50 mal länger dauert als Lesen und andere Überraschungen aus der Welt der Software-Reviews„ Ein reales Beispiel mit 2% Effektivität siehe Folie "Ein Dokument mit 2 Methoden geprüft„ in Genauere Quellenangaben siehe Notizseite

20 geringere Entwicklungskosten (25-35%)
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

21 Agile Inspektionen: vorgestellt 2005 von Tom Gilb
Agile Inspektionen besonders in V-Modell-Projekten nützlich, weil dort keine kurzen Feedback-Schleifen (z.B. in Form von Iterationen) Tom Gilb Folie zuletzt geändert am: , , , (erstellt), Notizen zuletzt geändert am: Gilb, Tom: Agile Specification Quality Control. Cutter IT Journal, Vol. 18, No. 1, pp , January 2005. (Stand ): He is an independent teacher, consultant and writer. He has published nine books, including the early coining of the term "Software Metrics" (1976) which is the recognized foundation ideas for IBM CMM / SEI CMM/CMMI Level 4. He is directly recognized as the idea source for parts of the Agile and Extreme programming methods (primarily the incremental cycles). Tom and Kai have recently developed their own Agile Inspections and Agile Evolutionary Project Management processes, that are being successfully used by clients. (Stand ) p18 "Value-Driven Development Principles and Values – Agility is the Tool, Not the Master" by Tom Gilb: And its first principle “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”, is central to the ideas in this article. It is not strange that I agree, since many of the Agilistas, for example Kent Beck, explicitly point to my 1988 book as a source of some of their ideas [4, 5, 6, 7, 8, 9, 12]. 5. Mike Cohn, “I’ve always considered Tom to have been the original agilist. In 1989, he wrote about short iterations (each should be no more than 2% of the total project schedule). This was long before the rest of us had it figured out.”

22 Eine Beobachtung als Ausgangspunkt
Bei klassischen Inspektionen: Autoren beginnen manchmal aufgrund Review-Erfahrungen, deutlich fehlerfreier zu arbeiten. Signifikante Lernkurve kann erreicht werden. Folie zuletzt geändert am: , , , (erstellt), Notizen zuletzt geändert am:

23 Marie’s persönliche Lernkurve
Geschätzte verbleibende Major defects / Seite 28 13 4 3 5 10 15 20 25 1 2 30 6 7 Reihenfolge der Dokumente, die einem Review unterzogen wurden Marie Lambertsson’s Lernkurve, Ericsson, Stockholm, 1997 Folie zuletzt geändert am: , , Notizen zuletzt geändert am: Quelle: Tom Gilb

24 Gary’s persönliche Lernkurve
80 gefundene Major defects (~ insgesamt vorhanden!) 40 23 8 20 60 80 100 1 2 3 4 5 Gefundene Major defects / Seite Februar April Reviews von Gary’s Design-Dokumenten “Gary” bei McDonnell-Douglas Folie zuletzt geändert am: , , , , Notizen zuletzt geändert am: begin -Aus Gilb‘s Original-Folie incl. Notizansicht:- Early defect removal also pays dividends in terms of personal skills. Take the case of “Gary” at McDonald Douglas. From a standing start, he participated in 5 successive Inspections of his own software designs (ignore the hard hat!). Note that, as Author of the 5 documents, he was required to join the Inspection team that was looking for his errors. The first document revealed an average defect density of 80 majors per page – a frightening number, but actually quite typical. By the time he’d fixed them all, though, Gary had learnt so much about how to write good design documents, that his second Inspected design was only half as buggy. Each successive document was only half as buggy as its predecessors, and by the fifth – well, I had to cheat there, because the graphing tool wouldn’t let me graph an observation of zero, so I had to put in one spurious defect! Here’s how McDonald-Douglas felt about the personal value of Inspections: “We find an hour of doing Inspection is worth ten hours of company classroom training.” A McDonnell-Douglas line manager “Even if Inspection did not have all the other measurable quality and cost benefits which we are finding, then it would still pay off for the training value alone.” A McDonnellDouglas Director end -Aus Gilb‘s Original-Folie incl. Notizansicht- Andere Quelle (welche weiß ich nicht mehr): 3 mal schneller lernt man Quelle: Douglas Aircraft, 1988, private report to Tom Gilb

25 Grundidee der Agilen Inspektionen
Schwerpunkt der Inspektionen wird verschoben weg vom frühzeitigen Fehler finden und korrigieren („cleanup“-Modus) hin zum Schätzen der Fehlerdichte der Dokumente, um die Entwickler zu motivieren, zu lernen wie man von vorne herein fehlerfreier arbeitet. Kosten für Inspektionen sinken enorm: Stichproben reichen aus (statt 100% der Dokumente zu prüfen), denn Zweck ist jetzt „Messen“ statt „cleanup“-Modus. Folie zuletzt geändert am: , , (erstellt), Notizen zuletzt geändert am:

26 Allgemeine Prinzipien von Agilen Inspektionen
Wenige Seiten auf einmal (z.B Seiten) Evtl. frühzeitig (erste 5% eines großen Dokuments) Kontinuierlich (z.B. jede Woche), bis Arbeit fertig ist Für jeden Entwickler (jeder einzelne Autor muss persönlich motiviert und trainiert werden) Folie zuletzt geändert am: , , (erstellt), Notizen zuletzt geändert am: "1 bis 3 Seiten" aus Agile_SQC_INCOSE05.pdf übernommen

27 Ablauf einer Agilen Inspektion (1)
Stichprobe wird ausgewählt (z.B. 1 Seite) und gegen ca Regeln geprüft, z.B. Clarity („clear enough to test“) Unambiguous („to the intended readership“) Consistent („with other statements in the same or related documents“) Completeness („compared to sources“) Für Anforderungsdokumente: „no design“ Reviewer sollen alle Regelabweichungen identifizieren und klassifizieren. Die Mj Defects werden an Moderator berichtet. Folie zuletzt geändert am: , , (erstellt), Notizen zuletzt geändert am: sources = Vorgängerdokumente (aus den SW-Entwicklungsphasen vorher)

28 Ablauf (2) An Prüfsitzung nehmen beispielsweise zwei Reviewer teil, Dauer ca Minuten. Geprüft wird mit optimaler Inspektionsrate. Trainierter Moderator ist anwesend und leitet den Prozess. Danach wird geschätzte Anzahl der tatsächlich vorhandenen Fehler aus Gesamtzahl der gefundenen Fehler berechnet. (Berechnungsgrundlage: typischerweise findet Team in diesem Setting ein Drittel der vorhandenen Fehler.) Folie zuletzt geändert am: , , (erstellt), Notizen zuletzt geändert am: Es gibt genauere Verfahren zur Abschätzung der vorhandenen Fehler, z.B. 1. Die Effektivität wird abgeschätzt durch den Vergleich der realen Inspektionsrate mit der für den jeweiligen Dokumenttyp optimalen Inspektionsrate. 2. Die Effektivität wird durch die Capture-Recapture-Methode abgeschätzt. (vgl. Foliensatz "Mit Stichproben-Reviews die Dauer von Testphasen vorhersagen" vom , Tutorial auf Software-QS-Tag 2010, Rösler/Schlich). Details siehe Notizseite

29 Maßnahmen werden festgelegt
Ablauf (3) Maßnahmen werden festgelegt Bei sehr hoher Fehlerdichte (z.B. 10 Mj / p oder mehr): Unökonomisch, die anderen Seiten zu prüfen, um „alle Fehler“ zu finden, oder die bisher gefundenen Fehler zu korrigieren. Zu viele Mj Defects bleiben trotzdem unentdeckt. Beste Alternative: Autor oder jemand anderes schreibt Dokument neu. (Hier sieht man, dass eine frühzeitige Agile Inspektion sinnvoll ist, z.B. schon wenn 5% des Dokuments fertig sind.) Folie zuletzt geändert am: , , , , (erstellt), Notizen zuletzt geändert am:

30 Gilb's Paradigmenwechsel
Unmittelbare Lösung gegen hohe Fehlerdichten ist nicht, die gefundenen Fehler aus dem Dokument zu entfernen, und ist nicht, den SW-Entwicklungs- Prozess zu ändern! Die effektivste praktikable Lösung: Sicherstellen, dass jeder Autor das Ausgangskriterium der maximalen Fehlerdichte ernst nimmt. sehr überraschend für Qualitäts-sicherer Folie zuletzt geändert am: , , , (erstellt), Notizen zuletzt geändert am:

31 Folgerungen für Tester (1)
Hypothese: Für Tester wird es immer wichtiger, Kompetenzen zu Reviews und Inspektionen aufzubauen. (Zeigt sich auch in den Lehrplänen von ISTQB Certified Tester.) Zwei Reviewverfahren stehen zur Verfügung: - klassische Reviews (etabliert in SW-Industrie) - agile Inspektionen (kaum Industrieerfahrung vorhanden) Tester können beitragen als - Reviewmoderatoren - Reviewteilnehmer (s. nä. Folie) Folie zuletzt geändert am: , Notizen zuletzt geändert am:

32 Tester als Reviewteilnehmer
Employee Type Con-tract Reqts. Archit. Design Detail Design Test Plan Test Design Source Code Tech. Doc. User Manual Task author x Req. analyst Arch. designer Detail. designer Programmer Tester Maintainer User Manager Marketing Legal department Folie zuletzt geändert am: (Testerhervorhebung), (Animation), (erstellt), Notizen zuletzt geändert am: SI = Software Inspection, ISBN Die Teilnehmer sollten sich Seite mit Post-IT markieren Source: SI p159 Table 8.1

33 Folgerungen für Tester (2)
Bekannt: Kaum möglich, Qualität in ein Softwaresystem hineinzutesten Bekannt: Hilfe oft zu spät, wenn Tester ins Projekt erst während Testphasen einsteigen Es tut dem Projekt gut, wenn Tester als „Dokumenten-Tester“ früh im Projekt aktiv sind!* Am besten schon zum Review der Anforderungen („Sind die Anforderungen testbar formuliert?“) Folie zuletzt geändert am: , Notizen zuletzt geändert am: * Im dt. Sprachraum sind Reviews und Inspektionen übrigens seit langem auch unter dem Begriff „Dokumententest“ bekannt.

34 Literatur zu Reviews und Inspektionen
1.  Gilb, Tom: Agile Specification Quality Control. Cutter IT Journal, Vol. 18, No. 1, pp , January 2005. 2. Gilb, Tom / Graham, Dorothy: Software Inspection, Addison-Wesley, 1993, 3.  Radice, Ronald A.: High Quality Low Cost Software Inspections, Paradoxicon Publishing, 2002 4. Rösler, P.; Schlich, M.; Kneuper, R.: Reviews in der System- und Softwareentwicklung: Grundlagen, Praxis, kontinuierliche Verbesserung. dpunkt.verlag, Heidelberg, 2013 Folie zuletzt geändert am: , , , ,

35 Dr. Juran’s Test “The Game Rules”
No questions! No discussion! Make your best interpretation of these rules. You will get 30 seconds to check. Count all defects for Rule F: no instances of “F” (any type) allowed on the screen. Advice: count even “remote cousins” (example “f” and “F ”). Write down your count of “defects” on paper. You may move to any position in the room to see better. Do not interfere with the view of others. Folie zuletzt geändert am: , (animiert), , Notizen zuletzt geändert am: Gilb Mai 2001: „Gilb‘s variation of Juran‘s test“ Juran spricht sich „Dschurähn“ aus, Betonung auf letzte Silbe Die 30 Sek. entsprechen einer Inspektionsrate von 20 p/h. Source: Tom Gilb, Team Leader Course

36 Juran's “80%” Test "FEDERAL FUSES ARE THE RESULTS OF YEARS OF SCIENTIFIC STUDY COMBINED WITH THE EXPERIENCE OF YEARS." How many letter F's can you find on this page? Write the number down in this box Folie zuletzt geändert am: (f rein), (Farben geänd.), , Notizen zuletzt geändert am: es dauert ca. 25 Sek. um alles auf der Folie zu lesen F-Test übernommen aus: Tom Gilb, Team Leader Course

37 Checklist for "F" Searching All questions support “Rule F”
F1. Do you find the word "of"? F2. Did you look outside borders? F3. Do you find large graphic patterns resembling F ? F4. Did you find all "F" shapes within other symbols, for example in letter "E"? F5. Did you find all numbers and shapes pronounced "F", for example 55 and "frames"? F6. Did you examine things under a microscope? F7. Did you check the back of the screen? F8. Did you look for lettering on the screen casing? F9. Did you see the upside-down, backwards letter “t” (= “f”)? Rule F: no instances of “F” (any type) allowed on the screen. Folie zuletzt geändert am: , Notizen zuletzt geändert am: In Gilb’s Folien gibt es noch Folie “F Test Predictions”: Prediction (made in advance, we will check it out later): The group average for “obvious” F’s will be 55%±7% for software people 65%±8% for engineers The group average for ‘really obscure’ F’s will be less than 10%. und Folie “The F-test ‘Lessons’”: Defect finding is difficult Even when a simple clear Rule defines a defect Tools (Checklists) might be necessary to understand a simple Rule. Checklists supplement but do not change the Rule Time might be necessary to use the Tools. We can predict number of defects NOT found! Source: Tom Gilb, Team Leader Course

38 Das Gummibärchenbild enthält fünf absichtlich eingebaute "Fehler" bzw
Das Gummibärchenbild enthält fünf absichtlich eingebaute "Fehler" bzw. Auffälligkeiten. Können Sie mindestens vier dieser Fehler finden? Folie zuletzt geändert am: Das Gummibärchenbild auf dem Buchcover enthält übrigens fünf absichtlich eingebaute "Fehler" bzw. Auffälligkeiten. Können Sie mindestens vier dieser Fehler selbst finden, ohne im Korrekturverzeichnis ( nachzuschauen? (Einer der fünf Fehler ist zeitabhängig und dank Haribo seit Juli 2014 kein Fehler mehr.)