Software-Reviews Erfahrungsbericht aus dem Projektgeschäft

Präsentation zum Thema: "Software-Reviews Erfahrungsbericht aus dem Projektgeschäft"—  Präsentation transkript:

1 Software-Reviews Erfahrungsbericht aus dem Projektgeschäft
Wie funktionieren SW-Reviews Warum SW-Reviews Kosten und Zeit sparen helfen Das Geheimnis der "optimalen Inspektionsrate" Das Capability Maturity Model (CMM) und was SW-Reviews zu Level 2(!) bis 5 beitragen Erfahrungen aus einem Projekt im Flughafenumfeld ... programprog ramprogramprogr amprogramprogram program BUG progr amprogramprogra mprogramprogr ampro Datei zuletzt geändert: (reine abgeleitete Datei, nämlich Inhalt von Vortrag_GI_ ppt ohne F-Test-Folien) Folien zuletzt geändert: Folie zuletzt geändert am: , Peter Rösler Softlab GmbH

2 Erfahrungen aus einem Projekt im Flughafenumfeld
Agenda (Fortsetzung) Erfahrungen aus einem Projekt im Flughafenumfeld Wie die Projektlaufzeit um 3 Wochen verkürzt werden konnte Wie die Anzahl der Fehler im Integrationstest vorausgesagt wurde Wie Modultests überflüssig gemacht werden konnten Warum beim Kunden kein Programmierfehler mehr gefunden wurde Folie zuletzt geändert am: , Peter Rösler Softlab GmbH

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

4 “major defect” (im Gegensatz zu “minor defect”)
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 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”. Folie zuletzt geändert am: (Titel verkürzt) Peter Rösler Softlab GmbH

5 Erfahrungen anderer Firmen
An AT&T Bell Laboratory project with 200 professionals instituted several changes, including inspections. Productivity improved by 14% and quality by a factor of ten. Aetna Insurance Company: inspections found 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%. Einordnung von Reviews in den SW-Entwicklungszyklus: Am Flipchart das V-Modell aufmalen. Folie zuletzt geändert am: , Source: Humphrey 1989, Managing the software process, p186/187 Peter Rösler Softlab GmbH

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

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

8 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. Manche ältere Reviewtechniken haben noch die Rolle des “Readers”, vgl. SI p 186. Folie zuletzt geändert am: , Einzige Einschränkung: der Autor darf zusätzlich höchstens die Rolle eines Reviewers übernehmen. Peter Rösler Softlab GmbH

9 Overall Process Map Folie zur Seite legen Planning Entry Master Plan
Sources Entry Master Plan Product Kickoff Checking Inspection Issue Log Checklists Change Requests to Project and Process Logging Process Brainstorming Process Brainstorm Log Edit Folie zur Seite legen Folie zuletzt geändert am: Data Summary Followup Exited Product Exit Source: Tom Gilb, Team Leader Course Peter Rösler Softlab GmbH

10 potentielle “major defects” finden und notieren
Individual Checking potentielle “major defects” finden und notieren optimale Checking Rate einhalten Checklisten verwenden % der Fehler können schon in dieser Phase gefunden werden! Gibt es „Zaubertechnik“? Man kommt nicht umhin, alles zu lesen. Diskussion: wie notieren wir die Fehler? (handschriftlich, aber es gibt Firmen mit Formularen) 20-30% der Gesamtzeit wird in dieser Phase aufgewendet. Diskussion: was ist die große Gefahr? Reviewer nimmt sich die Zeit nicht. (Rundruf) Auch Verbesserungsvorschläge (zum SW-Entwicklungsprozeß oder Reviewtechnikhandbuch) und Fragen an den Autor werden notiert. 10-20 major defects / Seite erwartet Gilb. Votta & Porter: 95 % der Fehler können hier gefunden werden, Problem der „meeting losses“. Folie zuletzt geändert am: , (Bild) Peter Rösler Softlab GmbH

11 Dokument wird geprüft, nicht der Autor!
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”. Diskussion: Sitzordnung. (Autor sitzt neben Protokollant) Diskussion: wie meldet man Fehler? 1. Zeile 50 widerspricht Spezifikation Zeile 30 2. „Ich glaube“, „ich verstehe nicht“ (besser als „ist unverständlich“) 3. „Du“ ist gefährlich, fördert Verteidigungshaltung Ohne double checking: Moderator geht durch das Dokument Abschnitt für Abschnitt. Mit double checking:t Reader ... Verhaltensregeln sind wichtig, Autor darf nicht bloßgestellt werden. Bei TRANSIT Vorg.modell für gr. Wartungsprojekte haben wir 0.5 / min. erreicht. Folie zuletzt geändert am: (Titel verkürzt, Notizen verkürzt), , Peter Rösler Softlab GmbH

12 Merkmale 1- 5 von Fagan’s Inspektionsmethode
Michael Fagan, “Erfinder” der Reviewtechnik, IBM ca. 1975 1. überall im Entwicklungsprozeß 2. alle Arten von Fehlern 3. ohne big boss 4. mehrere Einzelschritte 5. Checklisten 1. nicht nur Codereading, Baupläne 2. schlechte Wartbarkeit; wenn Hauptspeicher vollläuft 3. stellvertretend für psychologische Aspekte; nicht mißverstehen: auch Manager machen Reviews „Da hat sich ein Fehler eingeschlichen“ Folie zuletzt geändert am: (1-Blank5), , Notizen zuletzt geändert am: Peter Rösler Softlab GmbH

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 7. Umfangreiche Checklisten werden unter den Reviewern aufgeteilt. 8. - nur trainierte Moderatoren stellen krit Erfolgsfaktoren sicher Moderatoren werden zertifiziert Moderatoren, nicht Autoren stehen unter Erfolgsdruck 9. rückgekoppelter Prozeß. LIDS 10. checking UND logging rate, aus opt. Inspektionsrate folgt max. upper size des Pakets! Folie zuletzt geändert am: Peter Rösler Softlab GmbH

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

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 Folie zuletzt geändert am: (animiert, Notizen verkürzt), , Notizen zuletzt geändert am: Peter Rösler Softlab GmbH

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 Folie zuletzt geändert am: , , (neu erstellt) BMS: „Baggage Management System“ Peter Rösler Softlab GmbH

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 Folie zuletzt geändert am: (neu erstellt) Peter Rösler Softlab GmbH

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 Folie zuletzt geändert am: (neu erstellt) Peter Rösler Softlab GmbH

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) Folie zuletzt geändert am: (neu erstellt) Peter Rösler Softlab GmbH

20 Vorhersagen und Realität
Komponente Schätzung für Integrationstest Tatsächlich gefun-dene Mj defects REFLZ (nur gereviewed) XRAYZ (nur gereviewed) OALLZ (nur modulgetestet) DBSHZ (nur modulgetestet) PC-SW (nur modulgetestet) Mobile-SW (nur modulgetestet) Design (nur Walkthrough) 2 – 7 6 2 – 6 4 0 – 1 0 – 1 nicht geschätzt 2 Folie zuletzt geändert am: (neu erstellt) nicht geschätzt 2 0 – 2 4 Peter Rösler Softlab GmbH

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! Da die beiden Komponenten nicht zu 100% gereviewed wurden, waren es bezogen auf den gereviewten Code sogar 86%. Folie zuletzt geändert am: (neu erstellt) Peter Rösler Softlab GmbH

22 3 Wochen weniger Laufzeit für Integrationstest
Programmierung (inkl. Modultest bzw. Review) Integrations-test eingesparte Laufzeit ca. 7 Wo 2 Wo 3 Wo (Schätzung) 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! Folie zuletzt geändert am: (nur Animation geändert), (neu erstellt) Peter Rösler Softlab GmbH

23 Weitere Informationsquellen
: Kostenlose „Reviewtechnik-Sprechstunde“ Linksammlung zu Reviewtechnik Checklisten „Software Inspection“ von Tom Gilb und Dorothy Graham, ISBN Folie zuletzt geändert am: , „Peer Reviews in Software: A Practical Guide“ von Karl E. Wiegers, ISBN Peter Rösler Softlab GmbH