Reviews Definition Ziele Teilnehmer Ablauf Ergebnisse

Definition Ein Review ist ein mehr oder weniger formal geplanter und strukturierter Analyse- und Bewertungsprozeß, in dem Projektergebnisse einem Team von Gutachtern präsentiert und von diesen kommentiert oder genehmigt werden. Reviews können in einem Software Entwicklungsprojekt im Rahmen der Qualitätssicherung zu jeder Zeit durchgeführt werden. Am Ende einer jeden Phase sollte das erarbeitete Produkt dieser Phase in einem Review überprüft und abgenommen werden.

Ziele frühe und umfassende Mängelaufdeckung kostensparende Mängelverhütung Reduzierung des Test- und Wartungsaufwandes Verbesserung der Kommunikation Erfahrungsaustausch Die in der Planungsphase durch ein Review aufgedeckten Mängel verursachen nur ca. 20 % der Kosten, die die Beseitigung des Fehlers in der Realisierung verursachen würde. Alle Beteiligten müssen sich aktiv mit dem Objekt auseinandersetzen. Neue Mitarbeiter können sich durch eine Beteiligung an einem Review effektiv in das Thema einarbeiten.

Relative Fehlerkosten

Erfolgsgründe Es prüft nicht nur der Autor Synergieeffekt Die Natur des Fehlers wird entdeckt, und nicht nur ein Symptom Erkenntnis durch Präsentation Frühe Fehlererkennung hoher Wirkungsgrad (80% der Fehler werden erkannt) Zwang zu sauberer Dokumentation auf alle Dokumente anwendbar Diese Ziele können erreicht werden, weil nicht nur der Autor prüft durch die Anwesenheit von Experten unterschiedlicher Fachrichtungen das Produkt unter vielen Aspekten betrachtet wird (Synergieeffekt) die Natur des Fehlers entdeckt wird, und nicht nur ein Symptom der Autor durch die durch Präsentation neue Erkenntnis gewinnt Fehler früh erkannt werden. Die Zeit, die benötigt wird, einen Fehler in einem Review zu erkennen soll ca. 20% der Zeit betragen, den nicht erkannten Fehler in einer späteren Phase zu korrigieren ein hoher Wirkungsgrad erreicht wird (80% der Fehler werden erkannt) ein Zwang zu sauberer Dokumentation gegeben ist das Verfahren auf alle Dokumente anwendbar ist

Teilnehmer Produzent Moderator Spezialisten zukünftige Benutzer Fachkompetenz Durchsetzungsvermögen Neutralität Spezialisten zukünftige Benutzer keine disziplinarischen Vorgesetzten des Produzenten Kollegen (z.B. neue) Die Teilnehmer müssen Entscheidungsbefugnis besitzen, denn am Ende der Sitzung wird ein Entschluß über die Güte des geprüften Produkts gefasst. Dieser Entschluß bestimmt das weitere Vorgehen uns muß bindend sein.

Teilnehmer - Rollen Moderator Schriftführer Produzent Programmierer Test-Spezialist künftiger Wartungsmitarbeiter Kunde künftiger Anwender Richtlinienvertreter Moderator und Schriftführer sind beide wichtig. Zum Ende der Sitzung soll ein verwertbares Protokoll verabschiedet werden. Ein Review ist keine spontane Sitzung, sondern muß vor- und nachbereitet werden und hat folgenden Ablauf: (nächste Folie)

Ablaufskizze Vorbesprechung individuelle Planung Vorbereitung Reviewsitzung Nachbearbeitung Bewertung Jeder Teilnehmer muß vorbereitet sein. Es kann vorkommen, daß ein Review abgebrochen wird, weil die Teilnehmer nicht vorbereitet sind. Die Teilnehmer müssen entscheidungsbefugt sein und sind deshalb in der Regel hochbezahlte Spezialisten, deren Terminkalender nicht leicht koordiniert werden kann. Wenn dann ein Teilnehmer nicht vorbereitet ist, verschwendet er die Zeit aller anderen Beteiligten. Die Sitzung wird von Schriftführer nachbereitet und das bewertete Ergebnis wird an die Beteiligten verschickt.

Planung Prüfziele Auslösekriterien störungsfreie Zeit störungsfreier Ort Arbeitsmittel Teilnehmerkreis Zeitplan Unterlagen Bei der Planung müssen folgende Punkte berücksichtigt werden: Prüfziele: Welche Aspekte des Objekts sollen geprüft werden? Auslösekriterien: Warum wird ein Review veranstaltet? störungsfreie Zeit: Suchen Sie eine Tageszeit, zu der kein Teilnehmer durch vorhersehbare Ereignisse des Tagesgeschäfts gestört wird. störungsfreier Ort: Suchen Sie einen Ort, der für Störungen möglichst nicht erreichbar ist. Arbeitsmittel: Stellen Sie die benötigten Arbeitsmittel zusammen und überprüfen Sie diese (Tageslichtprojektor; Rechner, die funktionieren, damit es keinen Vorführeffekt gibt; Wandtafeln; Stifte, die schreiben; etc... ) Teilnehmerkreis: Stellen Sie den Teilnehmerkreis so zusammen, daß ein zielgerichtetes Arbeiten möglich ist. Zeitplan: Planen Sie die Reviewsitzung so, daß sie maximal 2 Stunden dauern wird. Unterlagen. Stellen Sie die notwendigen Unterlagen rechtzeitig zusammen. Verschicken Sie die Unterlagen rechtzeitig an die Teilnehmer mit der Aufforderung, diese zu bearbeiten.

Individuelle Vorbereitung Rechtzeitiges Versenden der Unterlagen genügend Zeit für die Durcharbeitung einplanen inensive Durcharbeit an Hand der Prüfziele und Checklisten schriftliche Erfassung der Mängel, Fragen und Formalfehler evtl abbrechen, wenn die Teilnehmer nicht vorbereitet sind Vorbereitung der Teilnehmer Die einzelnen Teilnehmer sollten, nachdem sie rechtzeitig die Unterlagen bekommen haben, genügend Zeit für die Bearbeitung einplanen. Sie sollten an Hand der Prüfziele und Checklisten die Unterlagen durcharbeiten Mängel, Fragen und Formalfehler schriftlich erfassen. Der Moderator sollte den Mut haben, das Review abzubrechen, wenn die Teilnehmer nicht vorbereitet sind.

Reviewsitzung Dauer höchstens zwei Stunden Formalfehler einsammeln Produzent gibt Überblick zum Reviewobjekt Inspektion: Teilnehmer gehen gemeinsam durch das Dokument Test: Teilnehmer testen gemeinsam das Prüfobjekt an Hand von Testfällen Ergebnis festhalten abgeschlossen, keine wesentlichen Mängel abgeschlossen, offene Mängel nachzubearbeiten nicht abgeschlossen, Wiederholung Die Sitzung sollte höchstens zwei Stunden dauern. Zu Beginn der Sitzung werden die vorher protokollierten Formalfehler eingesammelt. Der Produzent gibt einen kurzen Überblick über das Prüfobjekt. Es gibt im wesentlichen zwei Klassen von Reviews: Inspektion eines Dokumentes (z.B. eines ERD’S): Die Teilnehmer gehen unter Anleitung des Produzenten das Dokument durch. Test eines Programmes: Die Teilnehmer testen unter Anleitung des Produzenten das Programm mit vorher erstellten Testdaten und Testsequenzen. Teststrategien: Z.B. werden Grenzfälle gesucht, bei denen das Programm zu Verzweigungen gezwungen ist. Beispiel: Jahr.Tag -> Jahr.Monat.Tag 98.60 -> 98.03.01; 04.60 -> 04.02.29; 98.366-> Fehler; 04.366->04.12.31 Das Ergebnis der Reviewsitzung wird festgehalten und das Prüfobjekt wird kategorisiert: abgeschlossen, keine wesentlichen Mängel abgeschlossen, offene Mängel nachzubearbeiten nicht abgeschlossen, Wiederholung

Spielregeln keine halbfertigen Produkte begutachten Alle Teilnehmer müssen vorbereitet sein keine Lösungsversuche keine langwierigen Diskussionen Ergebnis vertraulich behandeln Prüfen Sie das Produkt, nicht den Produzenten Damit ein Review erfolgreich wird, müssen einige Spielregeln eingehalten werden: begutachten Sie keine halbfertigen Produkte. Alle Teilnehmer müssen vorbereitet sein. Unternehmen Sie keine Lösungsversuche. Die Lösung der aufgezeigten Probleme ist Aufgabe des Produzenten nach der Reviewsitzung. Brechen Sie langwierigen Diskussionen ab. Behandeln Sie das Ergebnis vertraulich. Prüfen Sie das Produkt, nicht den Produzenten

Spielregel Nr. 1 Prüfen Sie das Produkt, nicht den Produzenten Fehler sind nicht persönliche Schwächen, sondern resultieren aus der prinzipiellen Schwierigkeit, ein Softwareprodukt in angemessener Zeit beliebig präzise zu beschreiben

Mängelbewertung und -Klassifikation Klassen unvollständig falsch überflüssig Typen Spezifikationsfehler Entwurfsfehler Programmierfehler Sonstiges Schweregrad gravierend ->Wiederholung mittel -> Nachbearbeitung erforderlich leicht -> Nachbearbeitung erwünscht Die während der Reviewsitzung aufgetretenen Mängel werden im Protokoll festgehalten und bewertet und klassifiziert: Klassen unvollständig falsch überflüssig Typen Spezifikationsfehler Entwurfsfehler Programmierfehler Sonstiges Schweregrad gravierend ->Wiederholung mittel -> Nachbearbeitung erforderlich leicht -> Nachbearbeitung erwünscht

Zusammenfassung Ein Review ist ein formaler Bewertungsprozess Die Teilnehmer müssen vorbereitet sein Prüfen Sie das Produkt, nicht den Produzenten Es wird ein Protokoll erstellt Es gibt eine Erledigungsliste der Korrekturen