|
|
|
30.06.2016 - Embedded Testing 2016, Dornach bei München
Design- und Code-Reviews für Embedded Software
Vortragsfolien pdf: Reviews_EmbTesting2016.pdf (ca. 1,0 MB)
Vortragsfolien PowerPoint: Reviews_EmbTesting2016.ppt (ca. 5,0 MB)
29.06.2016 - Embedded Testing 2016, Dornach bei München
Schnell-Lesen für Informatiker
[Ist ein Soft Skill-Thema, kein Review-Thema. Folien] |
|
 |
|
|
|
|
|
|
|
|
 |
|
|
|
03.06.2014 - Océ Printing Systems GmbH, Poing bei München
Reviews - richtig durchgeführt |
|
|
|
25.03.2011 - T-Systems SE Community Workshop 2011, Frankfurt
Special Aspects of Software Inspections |
|
|
|
15.03.2011 - REConf 2011, Dornach bei München |
|
|
|
 |
|
|
Agile Inspektionen für große Anforderungsdokumente
Folien wie bei 09.12.2010 |
|
|
|
|
|
|
|
09.12.2010 - ESE-Kongress, Sindelfingen |
|
|
|
 |
|
|
|
Agile Inspektionen
Wasserfallmodell und klassische Inspektionen
Agile Software-Entwicklung
- Prinzipien
- Pair Programming und anderes "Reviewartiges"
in der agilen Software-Entwicklung
Agile Inspektionen (für Wasserfallprojekte)
Diskussion
Wie agil sind agile Inspektionen wirklich?
Vortragsfolien pdf: AgileInspektionen...ESE2010_v1.3.pdf (ca. 1,1 MB)
Vortragsfolien PowerPoint: AgileInspektionen...v1.3.ppt (ca. 2,0 MB)
Textfassung pdf: AgileInspektionen...ESE2010_v1.6.pdf (ca. 72 kB)
Textfassung Word: AgileInspektionen...ESE2010_v1.6.doc (ca. 72 kB) |
|
|
|
|
|
|
|
04.11.2010 - Software-QS-Tag, Nürnberg - |
|
|
|
 |
|
|
|
Mit Stichproben-Reviews die Dauer von Testphasen vorhersagen
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)
Vortragsfolien pdf: SW-QS-Tag-2010_Stichproben-Reviews....pdf (ca. 750 kB)
Vortragsfolien PowerPoint: SW-QS-Tag-2010_Stichproben-Reviews....v1.5_pub.ppt (ca. 3,4 MB) |
|
|
|
|
|
|
|
Warum Prüfen 50-mal länger dauert als Lesen und andere Überraschungen aus der Welt der Software-Reviews |
|
|
|
 |
|
|
|
Bei der Diskussion über Software-Reviews werden einige Zahlenangaben, die von Fachleuten genannt werden, von den meisten Softwareentwicklern intuitiv in ganz anderer Größenordnung eingeschätzt und daher stark angezweifelt.
Zwei dieser Zahlenangaben, die den meisten Softwareentwicklern besonders unplausibel vorkommen, sind:
1. Die optimale Inspektionsrate für Textdokumente beträgt nur ca. 1 Seite pro Stunde (und liegt damit um ca. den Faktor 50 unter der reinen Lesegeschwindigkeit).
2. Das durchschnittliche Review findet nur ca. 5% der im Dokument vorhandenen Fehler.
Während des Vortrags können die Zuhörer an einigen Kurzexperimenten und Schätzungen teilnehmen, deren Ergebnisse die obigen Zahlenangaben plausibel machen. Im Vortrag wird auch begründet, warum trotz Software-Qualitätssicherung ein großer Prozentsatz aller Software-Projekte scheitert.
Version 2008:
Vortragsfolien pdf: Vortrag_GI_080923.pdf (ca. 1,0 MB)
Vortragsfolien PowerPoint: Vortrag_GI_080923.ppt (ca. 5,6 MB)
Textfassung pdf: Reviewtechnik_GI_080923.pdf (ca. 140 kB)
Textfassung Word: Reviewtechnik_GI_080923.rtf (ca. 4,2 MB)
alte Versionen:
2007b: Reviewtechnik_GI_070702b.pdf Reviewtechnik_GI_070702b.ppt
2007: Reviewtechnik_GI_070213.pdf Reviewtechnik_GI_070213.ppt
2005: TAV23F7Roesler.pdf TAV23F7Roesler.ppt TAV23P7Roesler.pdf TAV23P7Roesler.rtf
14.01.2009 - TU München, Garching -
10.12.2008 - ESE-Kongress, Sindelfingen -
23.09.2008 - GI Rhein-Main, Darmstadt -
23.04.2008 - GI Karlsruhe, Karlsruhe -
18.09.2007 - ASQF Fachgruppe Software-Test, München -
02.07.2007 - GI Münsterland, Münster -
27.06.2007 - Schüco Service, Bielefeld -
04.06.2007 - GI Dortmund, Dortmund -
08.05.2007 - GI Rhein/Neckar, Heidelberg -
24.04.2007 - ASQF Fachgruppe Software-Test, Erlangen -
23.04.2007 - GI Ostthüringen/Jena, Jena -
13.02.2007 - GI Bremen/Oldenburg, Bremen -
11.12.2006 - GI München, München -
18.11.2005 - GI TAV, München -
16.11.2005 - Metrikon 2005, Kaiserslautern - |
|
|
|
|
|
|
|
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.
|
|
|
