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

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 ...




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




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




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




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%.




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




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




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.




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




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!




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”.




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




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




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)




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




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“




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




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




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)




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




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!




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)




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

Documents

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