Vortrag GI 040312 b

Software-Reviews Erfahrungsbericht aus dem Projektgeschäft: 

Software-Reviews Erfahrungsbericht aus dem Projektgeschäft programprog ramprogramprogr amprogramprogram program BUG progr amprogramprogra mprogramprogr ampro 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 ...

Agenda (Fortsetzung): 

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

Capability Maturity Model (CMM): 

Capability Maturity Model (CMM) Source: www.software.org/ quagmire/descriptions/sw-cmm.asp Heroes No KPAs at this time Project management Requirements Management, SW Project Planning SW Project Tracking and Oversight SW Subcontract Management, SW Quality Assurance SW Configuration Management Engineering process Organization Process Focus, Org. Process Definition Peer Reviews, Training Program Intergroup Coordination, SW Product Engineering Integrated Software Management Product and process quality Software Quality Management Quantitative Process Management Continuous improvement Process Change Management Technology Change Management Defect Prevention

Begriffe: 

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

Erfahrungen anderer Firmen: 

Erfahrungen anderer Firmen Source: Humphrey 1989, Managing the software process, p186/187 An ATandamp;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%.

Anteil von Rework am Gesamtaufwand: 

Anteil von Rework am Gesamtaufwand Source: Wheeler 1996, Software inspection: an industry best practice, p 9

Relative Fehlerbehebungskosten: 

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

Rollen der Teilnehmer: 

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.

Overall Process Map: 

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

Individual Checking: 

Individual Checking potentielle 'major defects' finden und notieren optimale Checking Rate einhalten Checklisten verwenden

Logging Meeting: 

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

Merkmale 1- 5 von Fagan’s Inspektionsmethode: 

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

Merkmale 6-10 von Fagan’s Inspektionsmethode: 

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

Defect Density against Inspection Rate: 

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

Empfohlene Inspektionsraten: 

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

Erfahrungen aus einem Projekt im Flughafenumfeld : 

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'

Wo wurden Reviews eingesetzt?: 

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

Ergebnisse der Reviews: 

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

Vorhersagen für den Integrationstest: 

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)

Vorhersagen und Realität: 

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

Effektivität der Reviews: 

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!

3 Wochen weniger Laufzeit für Integrationstest: 

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!

Weitere Informationsquellen: 

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