Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe Nordhessen29.04.2003
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 Nordhessen29.04.2003
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 Nordhessen29.04.2003
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 Nordhessen29.04.2003
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 Nordhessen29.04.2003
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 Nordhessen29.04.2003
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 Nordhessen29.04.2003
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 Nordhessen29.04.2003
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 Nordhessen29.04.2003
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 Nordhessen29.04.2003
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 Nordhessen29.04.2003
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 Nordhessen29.04.2003
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 Nordhessen29.04.2003
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 Nordhessen29.04.2003
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 Nordhessen29.04.2003
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 Nordhessen29.04.2003
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 Nordhessen29.04.2003
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 Nordhessen29.04.2003
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 Nordhessen29.04.2003
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 Nordhessen29.04.2003
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 Nordhessen29.04.2003
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 Nordhessen29.04.2003
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 Nordhessen29.04.2003
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
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe Nordhessen29.04.2003
24Dr. Juran’s Test “The Game Rules”
• No questions! No discussion! Make your best interpretation of these rules.
• You will get 30 seconds to check.
• Count all defects for
Source: Tom Gilb,Team Leader Course
Rule F: no instances of “F” (any type) allowed on the screen.
• Advice: count even“remote cousins” “remote cousins” (example “f” and “F ”).
• Write down your count of “defects” on paper.
• You may move to any position in theroom to see better. Do not interferewith the view of others.
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe Nordhessen29.04.2003
25Juran's “80%” Test
How many letter F's can you find on How many letter F's can you find on this page?this page?
Write the number down in this boxWrite the number down in this box
"FEDERAL FUSES ARE THE RESULTS OF "FEDERAL FUSES ARE THE RESULTS OF YEARS OF SCIENTIFIC STUDY COMBINED YEARS OF SCIENTIFIC STUDY COMBINED
WITH THE EXPERIENCE OF YEARS."WITH THE EXPERIENCE OF YEARS."
Source: Tom Gilb,Team Leader Course
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe Nordhessen29.04.2003
26Checklist for "F" SearchingAll questions support “Rule F”
F1. Do you find the word "of"?F2. Did you look outside borders?F3. Do you find large graphic
patterns resembling F ?F4. Did you find all "F" shapes within other symbols, for example in letter "E"?F5. Did you find all numbers and shapes pronounced "F", for example 55 and "frames"?F6. Did you examine things under a microscope?F7. Did you check the back of the screen?F8. Did you look for lettering on the screen casing?F9. Did you see the upside-down, backwards letter “t” (= “f”)?
Source: Tom Gilb,Team Leader Course
Rule F: no instances of “F” (any type) allowed on the screen.
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe Nordhessen29.04.2003
27Dr. Juran’s Test: Gilb’s Prediction
Gilb: The group average for “obvious” F’s will be
• 55%±7% for software people,
• 65%±8% for engineers.
• The group average for ‘really obscure’ F’s will be less than 10%.
[Peter Rösler's 16 Kurse/Vorträge von Feb 2002 - April 2003 lagen alle bis auf eine Ausnahme im Bereich 71%±7%]
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe Nordhessen29.04.2003
28Dr. Juran’s Test: Gilb’s Prediction
Gilb: The group average for “obvious” F’s will be
• 52%±1%
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe Nordhessen29.04.2003
29Dr. Juran’s Test: Gilb’s Prediction
Gilb: The group average for “obvious” F’s will be
• 54%±1%
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe Nordhessen29.04.2003
30Dr. Juran’s Test: Gilb’s Prediction
Gilb: The group average for “obvious” F’s will be
• 56%±1%
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe Nordhessen29.04.2003
31Dr. Juran’s Test: Gilb’s Prediction
Gilb: The group average for “obvious” F’s will be
• 58%±1%
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe Nordhessen29.04.2003
32Dr. Juran’s Test: Gilb’s Prediction
Gilb: The group average for “obvious” F’s will be
• 60%±1%
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe Nordhessen29.04.2003
33Dr. Juran’s Test: Gilb’s Prediction
Gilb: The group average for “obvious” F’s will be
• 62%±1%
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe Nordhessen29.04.2003
34Dr. Juran’s Test: Gilb’s Prediction
Gilb: The group average for “obvious” F’s will be
• 64%±1%
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe Nordhessen29.04.2003
35Dr. Juran’s Test: Gilb’s Prediction
Gilb: The group average for “obvious” F’s will be
• 66%±1%
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe Nordhessen29.04.2003
36Dr. Juran’s Test: Gilb’s Prediction
Gilb: The group average for “obvious” F’s will be
• 68%±1%
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe Nordhessen29.04.2003
37Dr. Juran’s Test: Gilb’s Prediction
Gilb: The group average for “obvious” F’s will be
• 70%±1%
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe Nordhessen29.04.2003
38Dr. Juran’s Test: Gilb’s Prediction
Gilb: The group average for “obvious” F’s will be
• 72%±1%
Peter RöslerSoftlab GmbH
www.reviewtechnik.de
Review-TechnikenGI Regionalgruppe Nordhessen29.04.2003
39Dr. Juran’s Test: Gilb’s Prediction
Gilb: The group average for “obvious” F’s will be
• 74%±1%