Reviews,, Inspektionen und Walkthroughs. Nils von Delft

Transkript

1 Reviews,, Inspektionen und Walkthroughs Nils von Delft

2 Gliederung Motivation Begriffsklärung und Erläuterung Review Walkthrough Inspektion Inspektionsmodelle nach Humphrey und Gilb Weitere Aspekte von Reviews Nebeneffekte Faktor Mensch Praxiseinsatz von Reviews Computerunterstützung bei Reviews 2

3 Motivation Relative Fehlerkosten Codierfehler Entwurfsfehler Anforderungsfehler Review der Anforderungen Review des Entwurfs Code Review Strukturtest Funktionstest Karol Frühauf, Jochen Ludewig, Helmut Sandmayr: Software-Prüfung: Eine Anleitung zum Testen und zur Inspektioan,

4 Motivation 2 Fehler im Software-Entwicklungs-Zyklus treten oft früh auf unentdeckte Fehler verursachen deutlich höhere Kosten, je später sie gefunden werden Programmierer übersieht oft Fehler Abstand zum Bildschirm/zum Programm nötig n Augen sehen mehr als 2 (für n > 2) Fehler sind oft nicht (oder nur schwer) mit automatisierten Mitteln zu finden Probleme besonders bei informelleren Dokumenten (Anforderungen, Design) Weitere Prüfung durch weitere Personen sinnvoll 4

5 Review re : erneut view: sehen Also Review: nochmal sehen, nochmal drübergucken Eine formell organisierte Zusammenkunft von Personen zur inhaltlichen oder formellen Überprüfung eines Produktteils (Dokument, Programmstück, etc.) nach vorgegebenen Prüfkriterien und listen.* Also: Zusammenkunft um Fehler im Programm zu finden (nicht zu korrigieren). * Prof. Dr. M. Glinz, Uni Zürich, Software Engineering I, 05 5

6 Walkthroughs Ein Walkthrough ist ein Review, bei dem der Autor oder die Autorin die Funktionsweise des Prüflings Schritt für Schritt beschreibt, während die Gutachter aufmerksam zuhören und überall einhaken, wo sie Mängel entdecken.* Formalisierung flexibel für gewöhnlich vom Autor einberufen und geleitet zwei oder mehr Personen Diskussion über Entwurf und Programmcode gute Möglichkeit zum Erfahrungsaustausch Betonung liegt auf Fehlerfindung * Prof. Dr. M. Glinz, Uni Zürich, Software Engineering I, 05 6

7 Inspektionen Inspektionen beinhalten einen stärker formalisierten Prozess, in dem Prüfer individuell und systematisch ein Dokument untersuchen und ihre Ergebnisse festhalten.* traditionell von Hand durchgeführt erfordern eigene Vorbereitung und Meetings Hauptkandidaten sind Systeme die sehr ausfallsicher sein müssen (Flugverkehr, medizinische Systeme) Große Systeme * nach Ciolkowski, Laitenberger, Biffl: Software Reviews: The State of the Practice,

8 Inspektionen 2 Streng formale Review-Form eingeführt von Michael Fagan bei IBM (1976) Konzentration auf Checklisten feste Rollenverteilung auch hier Fehlerfindung (weniger Behebung) Prüfer bereiten sich getrennt vor Prüfer kommen mit Fehlerliste zum Meeting Treffen wird nur durchgeführt, wenn alle gut vorbereitet sind Treffen dauert max. 2 Stunden keine Design- oder Ideologiediskussion im Meeting nicht als Indikator für Qualität zu betrachten (Loyalität) 8

9 Rollen bei der Inspektion Manager stellt Auftrag für die Erstellung des Prüflings löst Review aus ist für die Freigabe des Prüflings verantwortlich Moderator verwaltet und plant die Inspektion leitet das Meeting und sorgt dafür, dass alles in geregelten Bahnen verläuft und das Tempo angemessen ist Autor ist derjenige der den Prüfling verfasst hat spielt eher untergeordnete Rolle 9

10 Rollen bei der Inspektion 2 Prüfer hat die Aufgabe Fehler zu finden zunächst während der Vorbreitung dann in der Sitzung im Team Schriftführer hält Ergebnisse der Sitzung fest sollte nicht Moderator sein 10

11 Phasen der Inspektion Planung Initialisierung Vorbereitung Sitzung Dritte Stunde Nacharbeit Freigabe Analyse 11

12 Modelle von Humphrey ( 89)( und Gilb ( 93)( Entry Organisations- Phase Planning Overview Planning Kick-Off Erkennungs- Phase Preparation Analysis Inspection Checking Logging Brainstorming Abschluss- Phase Rework Follow-Up Edit Follow-Up Exit 12

13 Mögliche Variationen bei Inspektionen jeder Inspekteur gibt Fehler an - danach kann asynchron abgestimmt werden (zustimmen, ablehnen, neutral) jeder gefundene Fehler wird auch als solcher behandelt (alles was falsch aussieht bedarf Verbesserung) Brainstorming-Session nach Meeting, um Design-Fragen oder ähnliches zu diskutieren mehrere Inspektionen gleichzeitig (evtl. verschiedene Techniken) mehrere Reviews parallel, die verschiedene Aspekte des Prüflings betrachten 13

14 Inspektionen vs. Walkthroughs Inspektionen sehr formal Aufdeckung von etwa 60% der Fehler (Reduzierung der Fehlerkosten um 75%) umfassen etwa 15% bis 20% des Erstellungsaufwands eines Prüflings Senkung der Gesamtkosten eines Projekts (14% bis 25%) Walkthroughs weniger formal weniger Organisationsaufwand Aufdeckung von 20% bis 40% der Fehler geeignet auch für größere Gruppen da Meetings sehr teuer sind auch Walkthroughs teuer 14

15 Reviews in der Praxis Review-Ziele 73% Qualitätssteigerung 54% Durchsetzung von Standards 52% Bestimmung des Projektstatus Regelmäßigkeit von durchgeführten Reviews 42% Requirements 40% Design 30% Code Planung, Überblick 20% regelmäßige Planung 30% keine Benutzung von formalen Eintritt- und Abschlusskriterien Abschluss 40% keine Sammlung von Daten 18% Sammlung ohne Daten auszuwerten Studie von Ciolkowski, Laitenberger, Biffl: Software Reviews: The State of the Practice,

16 Positive Nebeneffekte von Reviews regelmäßiges Feedback für Programmierer Entwicklung und Einhaltung von Code-Standards bessere Beurteilung des Prozessfortschritts Wissensverteilung verbesserter Team-Spirit erweiterte Projekt-Kenntnisse 16

17 Der Faktor Mensch Tagesform Zeitdruck Motivation Loyalität Prinzipienreiterei auf Teufel komm raus Fehler finden 17

18 Wie sinnvoll ist das Meeting? Pro Synergie des Meetings Team-Geist, Kommunikation Wissensverteilung in einigen Fällen wurden bis zu 80% der Fehler erst im Meeting gefunden Contra 20% zusätzliche Kosten Unterbrechung des Zeitplan der Entwickler deutlich mehr Organisationsaufwand Inspektion kann sich deutlich verlängern viele Fehler werden schon in der Vorbereitung gefunden (in der Regel 67% bis 95%) 18

19 Warum Computer-Unterst Unterstützung? tzung? viele Tätigkeiten wiederholen sich haben nichts mit dem eigentlichen Prozess zu tun halten vom Fehlerfinden ab traditionelle Vorgehensweise kann schnell unübersichtlich werden Zeitfaktor wird immer wichtiger Programmierer sind immer häufiger geogr. getrennt gemeinsame Termine sind oft schwer organisierbar 19

20 Ansatzpunkte für f r Computer-Unterst Unterstützungtzung Was ändert sich? ausgedruckte Dokumente elektronische Dokumente Schnellhefter Sammlung von elektr. Dokumenten suchen durch einen Stapel von Dokumenten Datenbankanfrage physische Memos Aber eigentlicher Review-Prozess wird immer noch von Hand durchgeführt Tools greifen nur unterstützend ein 20

21 Nochmal das Wichtigste Reviews: Verfahren zur frühen Fehlerbehebung durch menschliche Überprüfung Wird in der Praxis auch häufig eingesetzt Walkthroughs: schnelle kostengünstigere Review-Art Inspektion: starke Formalität mit großem Erfolg Es gibt verschiedene Inspektionsmodelle mit verschiedenen Betonungen und Elementen Teurer und umstrittener Punkt ist das Face-to-Face -Meeting Computer-Unterstützung sinnvoll greift unterstützend ein (nimmt das Drumherum ab) kann eigentlichen Review-Prozess allerdings nicht abnehmen 21