Post on 05-Apr-2015
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe München10.06.2002
1Software-Reviews Erfahrungsbericht aus dem Projektgeschäft
programprog ramprogramprogramprogramprogramprogram BUG progr amprogramprogra mprogramprogr ampro
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 ...
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe München10.06.2002
2Agenda (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
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe München10.06.2002
3Capability Maturity Model (CMM)
Level Focus Key Process Areas
Level 5Optimizing
Level 4Managed
Level 3Defined
Level 2Repeatable
Level 1
Initial
Source: www.software.org/quagmire/descriptions/sw-cmm.asp
Heroes No KPAs at this time
Projectmanagement
Requirements Management, SW Project PlanningSW Project Tracking and OversightSW Subcontract Management, SW Quality Assurance SW Configuration Management
Engineering process
Organization Process Focus, Org. Process DefinitionPeer Reviews, Training Program Intergroup Coordination, SW Product EngineeringIntegrated Software Management
Product andprocess quality
Software Quality ManagementQuantitative Process Management
Continuous improvement
Process Change ManagementTechnology Change ManagementDefect Prevention
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe München10.06.2002
4Begriffe
“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
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe München10.06.2002
5Erfahrungen 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 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%.
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe München10.06.2002
6Anteil von Rework am Gesamtaufwand
6%12%
16%12% 10%
4%
8%12%
19%
1%
Requirements Preliminary Design Detailed Design Code & Unit Test Integration &System Test
Rework
Production
44 %
56 %
Source: Wheeler 1996,Software inspection: an industrybest practice, p 9
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe München10.06.2002
7Relative Fehlerbehebungskosten
1,5 1
10
60
100
0
20
40
60
80
100
120
During Design Before Code Before Test During Test In Production
Co
st
Un
its
Source: Tom Gilb,Software Engineering Management,Daten der Standard Chartered Bank
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe München10.06.2002
8Rollen 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.
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe München10.06.2002
9Overall Process Map
Sources
Product
Checklists
ChangeRequeststo Project
andProcess
DataSummary
MasterPlan
InspectionIssueLog
ProcessBrainstorm
Log
ExitedProduct
EntryPlanning
Kickoff
Checking
Logging
ProcessBrainstorming
Edit
Followup
Exit
Source: Tom Gilb,Team Leader Course
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe München10.06.2002
10Individual 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!
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe München10.06.2002
11Logging 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”.
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe München10.06.2002
12Merkmale 1- 5 von Fagan’s Inspektionsmethode
1. überall im Entwicklungsprozeß
Michael Fagan,“Erfinder” derReviewtechnik,IBM ca. 1975
2. alle Arten von Fehlern
3. ohne big boss
4. mehrere Einzelschritte
5. Checklisten
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe München10.06.2002
13Merkmale 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
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe München10.06.2002
14Defect Density against Inspection Rate
15
12
9
6
3
20 40 60 80 100
Def
ect
den
sity
(d
efec
ts/p
age)
Inspection rate (pages/hour)
Source: Tom Gilb, Denise LeighSoftware Inspection p 334,230 inspections of Sema Group (GB)
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe München10.06.2002
15Empfohlene 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
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe München10.06.2002
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“
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe München10.06.2002
17Wo 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
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe München10.06.2002
18Ergebnisse 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
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe München10.06.2002
19Vorhersagen 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)
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe München10.06.2002
20Vorhersagen 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
2 – 6
nicht geschätzt
0 – 1
0 – 1
nicht geschätzt
0 – 2
6
4
0
0
2
2
4
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe München10.06.2002
21Effektivitä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!
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe München10.06.2002
223 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 Wo 2 Wo 3 Wo (Schätzung)
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe München10.06.2002
23Weitere 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