Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Review-Techniken GI Regionalgruppe München 10.06.2002 Peter Rösler Softlab GmbH www.reviewtechnik.de 1 Software-Reviews Erfahrungsbericht aus dem Projektgeschäft.

Ähnliche Präsentationen


Präsentation zum Thema: "Review-Techniken GI Regionalgruppe München 10.06.2002 Peter Rösler Softlab GmbH www.reviewtechnik.de 1 Software-Reviews Erfahrungsbericht aus dem Projektgeschäft."—  Präsentation transkript:

1 Review-Techniken GI Regionalgruppe München Peter Rösler Softlab GmbH 1 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...

2 Review-Techniken GI Regionalgruppe München Peter Rösler Softlab GmbH 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

3 Review-Techniken GI Regionalgruppe München Peter Rösler Softlab GmbH 3 Capability Maturity Model (CMM) LevelFocusKey Process Areas Level 5 Optimizing Level 4 Managed Level 3 Defined Level 2 Repeatable Level 1 Initial Source: 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

4 Review-Techniken GI Regionalgruppe München Peter Rösler Softlab GmbH 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 Review-Techniken GI Regionalgruppe München Peter Rösler Softlab GmbH 5 Erfahrungen anderer Firmen Source: Humphrey 1989, Managing the software process, p186/187 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%.

6 Review-Techniken GI Regionalgruppe München Peter Rösler Softlab GmbH 6 Anteil von Rework am Gesamtaufwand 44 % 56 % Source: Wheeler 1996, Software inspection: an industry best practice, p 9

7 Review-Techniken GI Regionalgruppe München Peter Rösler Softlab GmbH 7 Relative Fehlerbehebungskosten Source: Tom Gilb, Software Engineering Management, Daten der Standard Chartered Bank

8 Review-Techniken GI Regionalgruppe München Peter Rösler Softlab GmbH 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 Review-Techniken GI Regionalgruppe München Peter Rösler Softlab GmbH 9 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

10 Review-Techniken GI Regionalgruppe München Peter Rösler Softlab GmbH 10 Individual Checking potentielle major defects finden und notieren optimale Checking Rate einhalten Checklisten verwenden % der Fehler können schon in dieser Phase gefunden werden!

11 Review-Techniken GI Regionalgruppe München Peter Rösler Softlab GmbH 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 Review-Techniken GI Regionalgruppe München Peter Rösler Softlab GmbH 12 Merkmale 1- 5 von Fagans Inspektionsmethode 1. überall im Entwicklungsprozeß Michael Fagan, Erfinder der Reviewtechnik, IBM ca alle Arten von Fehlern 3. ohne big boss 4. mehrere Einzelschritte 5. Checklisten

13 Review-Techniken GI Regionalgruppe München Peter Rösler Softlab GmbH 13 Merkmale 6-10 von Fagans 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 Review-Techniken GI Regionalgruppe München Peter Rösler Softlab GmbH 14 Defect Density against Inspection Rate Defect density (defects/page) Inspection rate (pages/hour) Source: Tom Gilb, Denise Leigh Software Inspection p 334, 230 inspections of Sema Group (GB)

15 Review-Techniken GI Regionalgruppe München 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

16 Review-Techniken GI Regionalgruppe München 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 BMS: Baggage Management System

17 Review-Techniken GI Regionalgruppe München 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

18 Review-Techniken GI Regionalgruppe München 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

19 Review-Techniken GI Regionalgruppe München 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)

20 Review-Techniken GI Regionalgruppe München Peter Rösler Softlab GmbH 20 Vorhersagen und Realität KomponenteSchä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 2 – 6 nicht geschätzt 0 – 1 nicht geschätzt 0 –

21 Review-Techniken GI Regionalgruppe München 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!

22 Review-Techniken GI Regionalgruppe München Peter Rösler Softlab GmbH 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! Programmierung (inkl. Modultest bzw. Review) Integrations- test eingesparte Laufzeit ca. 7 Wo2 Wo3 Wo (Schätzung)

23 Review-Techniken GI Regionalgruppe München Peter Rösler Softlab GmbH 23 Weitere Informationsquellen : Kostenlose Reviewtechnik-Sprechstunde Linksammlung zu Reviewtechnik Checklisten Software Inspection von Tom Gilb und Dorothy Graham, ISBN Peer Reviews in Software: A Practical Guide von Karl E. Wiegers, ISBN


Herunterladen ppt "Review-Techniken GI Regionalgruppe München 10.06.2002 Peter Rösler Softlab GmbH www.reviewtechnik.de 1 Software-Reviews Erfahrungsbericht aus dem Projektgeschäft."

Ähnliche Präsentationen


Google-Anzeigen