1 / 23

Software-Reviews Erfahrungsbericht aus dem Projektgeschäft

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

toviel
Download Presentation

Software-Reviews Erfahrungsbericht aus dem Projektgeschäft

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related