SoftwareReviews Erfahrungsbericht aus dem Projektgeschft Wie funktionieren SWReviews
Software-Reviews Erfahrungsbericht aus dem Projektgeschäft Wie funktionieren SW-Reviews • • • Warum SW-Reviews Kosten und Zeit sparen helfen 1 programprogr amprogram BUG progr amprogramprogr ampro 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. . . Review-Techniken GI Regionalgruppe München 10. 06. 2002 Peter Rösler Softlab Gmb. H www. reviewtechnik. de
2 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 Review-Techniken GI Regionalgruppe München 10. 06. 2002 Peter Rösler Softlab Gmb. H www. reviewtechnik. de
3 Capability Maturity Model (CMM) Level 5 Optimizing Level 4 Managed Level 3 Defined Focus Continuous improvement Process Change Management Technology Change Management Defect Prevention Software Quality Management Product and process quality Quantitative Process Management Organization Process Focus, Org. Process Definition Engineering Peer Reviews, Training Program process Intergroup Coordination, SW Product Engineering Integrated Software Management Project Level 2 Repeatable management Level 1 Initial Key Process Areas Heroes Review-Techniken GI Regionalgruppe München 10. 06. 2002 Requirements Management, SW Project Planning SW Project Tracking and Oversight SW Subcontract Management, SW Quality Assurance SW Configuration Management No KPAs at this time Source: www. software. org/ quagmire/descriptions/sw-cmm. asp Peter Rösler Softlab Gmb. H www. reviewtechnik. de
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 Review-Techniken GI Regionalgruppe München 10. 06. 2002 Peter Rösler Softlab Gmb. H www. reviewtechnik. de
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%. Review-Techniken GI Regionalgruppe München 10. 06. 2002 Source: Humphrey 1989, Managing the software process, p 186/187 Peter Rösler Softlab Gmb. H www. reviewtechnik. de
Anteil von Rework am Gesamtaufwand 6 44 % 56 % Review-Techniken GI Regionalgruppe München 10. 06. 2002 Source: Wheeler 1996, Software inspection: an industry best practice, p 9 Peter Rösler Softlab Gmb. H www. reviewtechnik. de
Relative Fehlerbehebungskosten Review-Techniken GI Regionalgruppe München 10. 06. 2002 Source: Tom Gilb, Software Engineering Management, Daten der Standard Chartered Bank 7 Peter Rösler Softlab Gmb. H www. reviewtechnik. de
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. Review-Techniken GI Regionalgruppe München 10. 06. 2002 Peter Rösler Softlab Gmb. H www. reviewtechnik. de
9 Overall Process Map Sources Product Checklists Change Requests to Project and Process Data Summary Planning Entry Kickoff Checking Logging Process Brainstorming Edit Inspection Issue Log Process Brainstorm Log Followup Exit Review-Techniken GI Regionalgruppe München 10. 06. 2002 Master Plan Source: Tom Gilb, Team Leader Course Exited Product Peter Rösler Softlab Gmb. H www. reviewtechnik. de
10 Individual Checking • • potentielle “major defects” finden und notieren optimale Checking Rate einhalten Checklisten verwenden 80 - 85 % der Fehler können schon in dieser Phase gefunden werden! Review-Techniken GI Regionalgruppe München 10. 06. 2002 Peter Rösler Softlab Gmb. H www. reviewtechnik. de
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”. Review-Techniken GI Regionalgruppe München 10. 06. 2002 Peter Rösler Softlab Gmb. H www. reviewtechnik. de
Merkmale 1 - 5 von Fagan’s Inspektionsmethode 1. 2. 3. 4. 5. überall im Entwicklungsprozeß alle Arten von Fehlern ohne big boss mehrere Einzelschritte Checklisten Review-Techniken GI Regionalgruppe München 10. 06. 2002 12 Michael Fagan, “Erfinder” der Reviewtechnik, IBM ca. 1975 Peter Rösler Softlab Gmb. H www. reviewtechnik. de
Merkmale 6 -10 von Fagan’s Inspektionsmethode 6. 7. 8. 9. 10. 13 max. 2 Stunden Rollen werden zugewiesen trainierter Moderator Statistiken werden geführt optimale Inspektionsrate in Seiten/h oder NLOC/h Review-Techniken GI Regionalgruppe München 10. 06. 2002 Peter Rösler Softlab Gmb. H www. reviewtechnik. de
14 Defect Density against Inspection Rate Defect density (defects/page) 15 12 9 6 3 20 40 60 80 100 Inspection rate (pages/hour) Review-Techniken GI Regionalgruppe München 10. 06. 2002 Source: Tom Gilb, Denise Leigh Software Inspection p 334, 230 inspections of Sema Group (GB) Peter Rösler Softlab Gmb. H www. reviewtechnik. de
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 Review-Techniken GI Regionalgruppe München 10. 06. 2002 Peter Rösler Softlab Gmb. H www. reviewtechnik. de
Erfahrungen aus einem Projekt im Flughafenumfeld • • 16 Das BMS-System befindet sich in der Wartungsphase Erstellt wurde ein neues Teilsystem, Titel „X-RAY“-Projektlaufzeit ca. Februar – Ende Juli 2000 Bis zu max. 7 Mitarbeiter waren im Team BMS: „Baggage Management System“ Review-Techniken GI Regionalgruppe München 10. 06. 2002 Peter Rösler Softlab Gmb. H www. reviewtechnik. de
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 Review-Techniken GI Regionalgruppe München 10. 06. 2002 Peter Rösler Softlab Gmb. H www. reviewtechnik. de
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 Review-Techniken GI Regionalgruppe München 10. 06. 2002 Peter Rösler Softlab Gmb. H www. reviewtechnik. de
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) Review-Techniken GI Regionalgruppe München 10. 06. 2002 Peter Rösler Softlab Gmb. H www. reviewtechnik. de
20 Vorhersagen und Realität Komponente REFLZ (nur gereviewed) Schätzung für Integrationstest Tatsächlich gefundene Mj defects 2– 7 6 XRAYZ (nur gereviewed) 2– 6 4 OALLZ (nur modulgetestet) 0– 1 0 DBSHZ (nur modulgetestet) 0– 1 0 PC-SW (nur modulgetestet) nicht geschätzt 2 Mobile-SW (nur modulgetestet) nicht geschätzt 2 Design (nur Walkthrough) Review-Techniken GI Regionalgruppe München 10. 06. 2002 0– 2 4 Peter Rösler Softlab Gmb. H www. reviewtechnik. de
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 p 23): 60 % der Source Code Fehler können in einem Reviewdurchgang gefunden werden. Beim Kunden ist kein einziger Programmierfehler entdeckt worden! Review-Techniken GI Regionalgruppe München 10. 06. 2002 Peter Rösler Softlab Gmb. H www. reviewtechnik. de
3 Wochen weniger Laufzeit für Integrationstest ca. 7 Wo Programmierung (inkl. Modultest bzw. Review) • • 2 Wo 3 Wo (Schätzung) Integrationstest eingesparte Laufzeit 22 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! Review-Techniken GI Regionalgruppe München 10. 06. 2002 Peter Rösler Softlab Gmb. H www. reviewtechnik. de
Weitere Informationsquellen 23 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 Review-Techniken GI Regionalgruppe München 10. 06. 2002 Peter Rösler Softlab Gmb. H www. reviewtechnik. de
- Slides: 23