Software-Reviews Erfahrungsbericht aus dem Projektgeschäft

1. Software-Reviews Erfahrungsbericht aus dem Projektgeschäft • Wie funktionieren SW-Reviews • Warum SW-Reviews Kostenund Zeit sparen helfen • Das Geheimnis der"optimalen Inspektionsrate" • Das Capability Maturity Model (CMM) undwas SW-Reviews zu Level 2(!) bis 5 beitragen • Erfahrungen aus einem Projekt im Flughafenumfeld ... programprog ramprogramprogr amprogramprogram program BUG progr amprogramprogra mprogramprogr ampro

2. Agenda (Fortsetzung) • Erfahrungen aus einem Projekt im Flughafenumfeld • Wie die Projektlaufzeit um 3 Wochenverkürzt werden konnte • Wie die Anzahl der Fehler im Integrationstestvorausgesagt wurde • Wie Modultests überflüssig gemacht werden konnten • Warum beim Kunden kein Programmierfehler mehrgefunden wurde

3. Capability Maturity Model (CMM) Continuous improvement Process Change ManagementTechnology Change ManagementDefect Prevention Product andprocess quality Software Quality ManagementQuantitative Process Management Engineering process Organization Process Focus, Org. Process DefinitionPeer Reviews, Training ProgramIntergroup Coordination, SW Product EngineeringIntegrated Software Management Requirements Management, SW Project PlanningSW Project Tracking and OversightSW Subcontract Management, SW Quality Assurance SW Configuration Management Projectmanagement Heroes No KPAs at this time Source: www.software.org/quagmire/descriptions/sw-cmm.asp

4. Begriffe • “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

5. Erfahrungen anderer Firmen • An AT&T Bell Laboratory project with 200 professionals instituted several changes, including inspections. Productivity improved by 14% and qualityby a factor of ten. • Aetna Insurance Company: inspectionsfound 82% of errors in a COBOL program,productivity was increased by 25%. • Another COBOL example (Gilb, Software Metrics): 80% of the development errors were found by inspections, productivity was increased by 30%. Source: Humphrey 1989, Managing the software process, p186/187

6. 44 % 56 % Anteil von Rework am Gesamtaufwand Source: Wheeler 1996, Software inspection: an industry best practice, p 9

7. Relative Fehlerbehebungskosten Source: Tom Gilb, Software Engineering Management, Daten der Standard Chartered Bank

8. Rollen der Teilnehmer • Moderator • Autor • Protokollführer • Reviewer • Vorleser/Reader (nur wenn „double checking“ gemacht wird) Ein Teilnehmer kann mehrere Rollen übernehmen. Einzige Einschränkung: der Autor darf zusätzlich höchstens die Rolle eines Reviewers übernehmen.

9. Overall Process Map Planning Sources Entry Master Plan Product Kickoff Checking Inspection Issue Log Checklists Logging Change Requests to Project and Process Process Brainstorming Process Brainstorm Log Edit Data Summary Followup Exited Product Exit Source: Tom Gilb, Team Leader Course

10. 80 - 85 % der Fehler können schon in dieser Phase gefunden werden! Individual Checking • potentielle “major defects” finden • und notieren • optimale Checking Rate einhalten • Checklisten verwenden

11. Logging Meeting • Dokument wird geprüft, nicht der Autor! • keine Diskussion von Fehlern und Lösungswegen • hohe Logging Rate (> 1 defect pro Minute) • wenn „double checking“ gemacht wird:optimale Inspektionsrate einhalten • Ergebnis ist das “Inspection Issue Log”.

12. Michael Fagan, “Erfinder” der Reviewtechnik, IBM ca. 1975 Merkmale 1- 5 von Fagan’s Inspektionsmethode 1. überall im Entwicklungsprozeß 2. alle Arten von Fehlern 3. ohne big boss 4. mehrere Einzelschritte 5. Checklisten

13. Merkmale 6-10 von Fagan’s Inspektionsmethode 6. max. 2 Stunden 7. Rollen werden zugewiesen 8. trainierter Moderator 9. Statistiken werden geführt 10. optimale Inspektionsrate in Seiten/h oder NLOC/h

14. Defect Density against Inspection Rate 15 12 9 Defect density (defects/page) 6 3 20 40 60 80 100 Inspection rate (pages/hour) Source: Tom Gilb, Denise Leigh Software Inspection p 334, 230 inspections of Sema Group (GB)

15. Empfohlene Inspektionsraten • Programme • 100 – 150 NLOC / h • Textdokumente • Gilb/Graham: ca. 1 Seite / h • Strauss/Ebenau: 3 – 5 Seiten / h • Zum Vergleich: „Rechtschreibfehler-Leserate“ beträgt ca. 7 – 25 Seiten / h

16. Erfahrungen aus einem Projekt im Flughafenumfeld • Das BMS-System befindet sich in der Wartungsphase • Erstellt wurde ein neues Teilsystem, Titel „X-RAY“-Projekt • Projektlaufzeit ca. Februar – Ende Juli 2000 • Bis zu max. 7 Mitarbeiter waren im Team BMS: „Baggage Management System“

17. Wo wurden Reviews eingesetzt? • Nur Programme wurden gereviewed,(leider) keine Designdokumente • Nur 2 von 6 Komponenten wurden gereviewed • Auswahlkriterien: hauptsächlich neue, komplexe, nicht durch „copy und rename“ entstandene Komponenten

18. Ergebnisse der Reviews • 37 Mj defects wurden in den beiden geprüften Komponenten gefunden • Gesamtaufwand der Reviews: 25 h (ohne „Edit-Phase“, d.h. Fehlerkorrektur) • Vgl. Theorie (Gilb/Graham 1993):1 h Review-Aufwand (inkl. „Edit-Phase“) pro Mj defect

19. Vorhersagen für den Integrationstest • Vor Beginn des Integrationstests (nachdem die Reviews erfolgt waren) wurde geschätzt, wie viele Mj defects im Integrationstest wohl auftauchen werden(s. nächste Folie)

20. Vorhersagen und Realität 2 – 7 6 2 – 6 4 0 0 – 1 0 0 – 1 nicht geschätzt 2 nicht geschätzt 2 0 – 2 4

21. Effektivität der Reviews • 78 % der Fehler in den beiden gereviewten Komponenten wurden mit Reviews gefunden!(von insgesamt 47 Mj defects wurden 37 mit Reviews und 10 mit Tests gefunden) • Vgl. Theorie (Gilb/Graham 1993 p23): 60 % der Source Code Fehler können in einem Reviewdurchgang gefunden werden. • Beim Kunden ist kein einziger Programmierfehler entdeckt worden!

22. ca. 7 Wo 2 Wo 3 Wo (Schätzung) Programmierung(inkl. Modultest bzw. Review) Integrations-test eingesparte Laufzeit 3 Wochen weniger Laufzeit für Integrationstest • Integrationstest dauerte 6 Tage für Testfall-Spezifikation und 4 Tage für Testdurchführung (inkl. Korrektur von 10 Mj defects) • Ohne Reviews wären es 6 Tage + ca. 19 Tage (für 47 Mj defects) gewesen!

23. Weitere Informationsquellen • www.reviewtechnik.de : • Kostenlose „Reviewtechnik-Sprechstunde“ • Linksammlung zu Reviewtechnik • Checklisten „Software Inspection“ von Tom Gilb und Dorothy Graham, ISBN 0-201-63181-4 „Peer Reviews in Software: A Practical Guide“ von Karl E. Wiegers, ISBN 0-201-73485-0

24. Dr. Juran’s Test “The Game Rules” • No questions! No discussion! Make yourbest 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 theroom to see better. Do not interferewith the view of others. Source: Tom Gilb, Team Leader Course

25. 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 Source: Tom Gilb, Team Leader Course

26. Checklist for "F" SearchingAll 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. Source: Tom Gilb, Team Leader Course

27. Dr. Juran’s Test: Gilb’s Prediction • Gilb: 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%. • [Peter Rösler's 16 Kurse/Vorträge von Feb 2002 - April 2003 lagen alle bis auf eine Ausnahme im Bereich 71%±7%]

28. Dr. Juran’s Test: Gilb’s Prediction • Gilb: The group average for “obvious” F’s will be • 52%±1%

29. Dr. Juran’s Test: Gilb’s Prediction • Gilb: The group average for “obvious” F’s will be • 54%±1%

30. Dr. Juran’s Test: Gilb’s Prediction • Gilb: The group average for “obvious” F’s will be • 56%±1%

31. Dr. Juran’s Test: Gilb’s Prediction • Gilb: The group average for “obvious” F’s will be • 58%±1%

32. Dr. Juran’s Test: Gilb’s Prediction • Gilb: The group average for “obvious” F’s will be • 60%±1%

33. Dr. Juran’s Test: Gilb’s Prediction • Gilb: The group average for “obvious” F’s will be • 62%±1%

34. Dr. Juran’s Test: Gilb’s Prediction • Gilb: The group average for “obvious” F’s will be • 64%±1%

35. Dr. Juran’s Test: Gilb’s Prediction • Gilb: The group average for “obvious” F’s will be • 66%±1%

36. Dr. Juran’s Test: Gilb’s Prediction • Gilb: The group average for “obvious” F’s will be • 68%±1%

37. Dr. Juran’s Test: Gilb’s Prediction • Gilb: The group average for “obvious” F’s will be • 70%±1%

38. Dr. Juran’s Test: Gilb’s Prediction • Gilb: The group average for “obvious” F’s will be • 72%±1%

39. Dr. Juran’s Test: Gilb’s Prediction • Gilb: The group average for “obvious” F’s will be • 74%±1%