Home www.reviewtechnik.de

www.reviewtechnik.de

Software-Reviews


Einführung

Vorträge

Seminartermine

Seminarinhalt

Checklisten

Literatur

Tools

Links

Mailingliste

Kontakt

Urlaub vom 13.-29.06.2011. Erreichbarkeit siehe www.p-roesler. de/frankreich20 11.html

Urlaub vom 04.-17.07.2010 in Cuxhaven, bin gut erreichbar unter 0172/8188 154.

  • Laitenberger Promotion
  • 16.09.2010 10h: bis jetzt hat 1 Reviewer geprüft.

(***) Teilnahmegebühr 1480 EUR plus MWSt. Wenn Sie eine Teilnahme planen, rufen Sie bitte wegen organisatorischen Details direkt beim Referenten an (Kontakt).

 

Formulare für Software-Reviews

von Diamantis Gikas (nach Gilb/Graham)
von Niels Malotaux (nach Gilb/Graham)
von
Karl Wiegers

Checklisten für Software-Reviews

Construx Software Development Checklists (30 Checklisten)
Checklisten für den Software-Entwicklungsprozeß (u.a. einige Reviewchecklisten)
Software Engineering Checklists (u.a. einige Reviewchecklisten)
Checklistenbeispiele aus Q-Chess, einem Verwaltungssystem für Checklisten und Prüfnachweise (6 Checklisten)
Defect Checklists (9 Checklisten als Word-Dateien)
Checklistensammlung von Teichreber (>100 Checklisten), u.a. Inspectable Document Standard (Checkliste im Stil des Buchs "Software Inspection", gilt für Requirements Specifications, Design Specifications, Functional Specifications, Test Plans, users manuals, ... )

 Gilb's Minimal-Checklisten für Spezifikationen:
Clear enough to test, unambiguous to intended readers, no design options in the requirements. (aus "Agile Specification Quality Control") bzw.
Clarity ("clear enough to test"), unambiguousness ("to the intended readership"), completeness ("compared to sources"). (aus
SQPv7i1Gilb.pdf)

 General Document Checklist <01/2010 Link tot> [referrer]

 Requirements Document Rules <01/2010 Link tot>[referrer]

 Kriterienkatalog Anforderungsspezifikation [referrer], Tool Revager

 I2 - Code Inspection Checklist (JPL) - FORTRAN

 I2 - Code Inspection Checklist (JPL) - C language

 C/C++ Code Checklist

 An Abbreviated C++ Code Inspection Checklist
(mit vielen Positiv- und Negativbeispielen)

 Java Inspection Checklist

 Ada Checklist (runterblättern nötig)

 A Checklist of Common GUI Errors Found in Windows, Child Windows, and Dialog Boxes

 NASA Software Formal Inspections Guidebook [referrer], Appendix A enhält Sample Checklists:
Architecture Design Checklist
Detailed Design Checklist
Code Inspection Checklist C
I0 - Architecture Design Checklist (JPL)
I1 - Detailed Design Checklist (JPL)
I2 - Code Inspection Checklist (JPL) C
I2 - Code Inspection Checklist (JPL) FORTRAN
IT1 - Test Plan Checklist (JPL)
IT2 - Test Procedure and Function Checklist (JPL)
R0 - Functional Design Checklist (JPL)
R1 - Software Requirements Checklist (JPL)
SY - Functional Requirements Checklist (JPL)

 NASA Software Formal Inspections Standard
(enthält keine Checklisten, aber in Kap. 3.3.1 bis 3.3.7 wird der Zweck der einzelnen Inspektionen genau beschrieben)

 weitere Software Engineering Checklists

 weitere IT-Checklisten, z.B. für Anforderungsprofile

 DESIRe, eine "intelligente Checkliste" für Anforderungsdokumente in natürlicher Sprache

 

04. oder 05.11.2010 - Software-QS-Tag, Nürnberg -
2-stündiges Tutorial:

Wie Testmanager schon früh im Projekt die Dauer der Testphasen vorhersagen können: mit Stichproben-Reviews

Für Testmanager wird es immer wichtiger, Kompetenzen im Gebiet Reviews und Inspektionen aufzubauen. Diese Entwicklung zeigt sich schon in den Lehrplänen von ISTQB Certified Tester und in den Bestrebungen, einen neuen Zertifizierungsmodul "Certified Review Leader" zu entwickeln.

Im Tutorial wird gezeigt, wie Testmanager mit stichprobenhaft durchgeführten Reviews auf Anforderungs-, Design- und Code-Dokumenten schon frühzeitig im Projekt abschätzen können, ob die Testphasen länger als geplant dauern werden. Da ein signifikanter Anteil aller Softwareprojekte sich verzögert oder ganz abgebrochen wird (siehe Chaos Report 2004), und dies oft erst in den Testphasen erkennbar wird, können Testmanager mit Stichproben-Reviews wesentlich zur Früherkennung von Projektrisiken beitragen.

Der Aufwand in den Testphasen besteht im Wesentlichen aus zwei Blöcken. Ein Aufwandsblock ist immer da, egal ob die Software Fehler hat oder nicht, nämlich das Spezifizieren der Testfälle und das (einmalige) Durchspielen aller Testfälle. Diesen Aufwand können Testmanager in der Regel aus der Größe des Softwaresystems (z.B. gerechnet in Funktion Points) und anderen Daten schätzen.

Der zweite Aufwandsblock, der "Rework-Aufwand", ist annähernd proportional zur Fehlerdichte der Software. Der Rework-Aufwand besteht aus allen Arbeiten, die aus Fehlern resultieren: das Lokalisieren von gefundenen Fehlern, das Korrigieren der Dokumente inklusive Programme, das Ändern der Testspezifikationen, das Wiederholen von Testläufen etc. Die Fehlerdichte und damit der Rework-Aufwand sind leider die großen Unbekannten für Projektleiter und Testmanager. Der Rework-Aufwand macht in typischen Projekten mehr als die Hälfte des Testaufwands aus, ist aber stark variabel, je nach Firma und Projekt. Die Reviewtechnik-Literatur berichtet von Projekten, die im Vergleich zu anderen Projekten eine um Faktor 100 geringere Fehlerdichte hatten. Aus Metriksicht gehört die Fehlerdichte zu den wichtigsten Kennzahlen, die erfolgreiche von gescheiterten Projekten unterscheiden. Im Tutorial wird gezeigt, wie ein Testmanager die Fehlerdichte mit stichprobenhaft durchgeführten Reviews abschätzen kann.

Die Fehlerdichte kann nur ermittelt werden, wenn die Effektivität der Reviews genau genug bekannt ist. Es muss also herausgefunden werden, wie viele der im Dokument vorhandenen Fehler das Reviewteam tatsächlich entdeckt hat. Im Tutorial werden zwei praktikable Ansätze vorgestellt: 1. Die Effektivität wird abgeschätzt durch den Vergleich der realen Inspektionsrate mit der für den jeweiligen Dokumenttyp optimalen Inspektionsrate. 2. Die Effektivität wird durch die Capture-Recapture-Methode abgeschätzt. Diese Methode ist aus der Biologie bekannt und wird verwendet, um die Größe von Tierpopulationen zu ermitteln. In der Softwareentwicklung kann diese Methode ganz analog eingesetzt werden, wenn mindestens zwei Reviewer dasselbe Dokument prüfen.

Testmanager wissen, dass es nicht möglich ist, Qualität in ein Softwaresystem hineinzutesten. Sie wissen, dass die Hilfe für manches Projekt zu spät kommt, wenn die Tester erst in den Testphasen in das Projekt einsteigen. Für das Projekt (und nebenbei erwähnt auch für die eigene berufliche Zufriedenheit) ist es besser, wenn Testmanager frühzeitig im Projekt Reviews und Inspektionen einsetzen können.

Die erste Hälfte des Tutorials besteht aus einer Einführung in Reviews und Inspektionen, so dass auch Teilnehmer ohne Reviewtechnikvorkenntnisse am Tutorial teilnehmen können.

(Koautorin dieses Tutorials: Maud Schlich)



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

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

Vortragsfolien PowerPoint: Reviewtechnik_GI_020610.ppt (ca. 300 kB, Animation der Folie 20 "Vorhersagen und Realität", Spalte "Tatsächlich gefundene Mj defects" scheint nicht mit jeder Powerpoint-Version zu funktionieren, bitte wenn nötig die Folie in anderem Modus, z.B. "Folien bearbeiten", betrachten.)
Kurzfassung Word: Software-Reviews_30.11.2005.doc (ca. 28 kB)

30.11.2005 - TAE Kolloquium "Testen ...", Ostfildern -
11.05.2005 -
ASQF Regionalgruppe Süd, Garching -
23.03.2004 -
ASQF Fachgruppe Software-Test, Erlangen -
12.03.2004 - GI Köln -
06.11.2003 -
Praxisforum 2003 "Embedded Test", München -
04.11.2003 -
Praxisforum 2003 "Embedded Test", Braunschweig -
17.09.2003 - GI Stuttgart/Böblingen -
29.04.2003 -
GI Nordhessen -
10.12.2002 - GI Rhein/Neckar -
10.06.2002 - GI München -


20.-24.06.2005 - Tom Gilb´s Review Symposium, tsg London -

  • When exactly do checkers find the defects during individual checking?
  • How an Inspection trainer can demonstrate the optimum checking rate with 5 short exercices.

[Home] [Einführung] [Vorträge] [Seminartermine] [Seminarinhalt] [Checklisten] [Literatur] [Tools] [Links] [Mailingliste] [Kontakt]

URL: <http://www.reviewtechnik.de/seminartermine.html> erstellt 1999
zuletzt geändert am 05.04.2009 von P. Rösler  ros@reviewtechnik.de