Ziele von Reviews
Reviews dienen dazu, Fehler in Dokumenten zu finden. Wenn das nicht gelingt, können die Folgen verheerend sein: Treffen wir zwei Annahmen, die ich als einigermaßen realistisch ansehe:
- In jeder Phase Ihres Entwicklungsprozesses arbeiten Sie zu 80% korrekt. Beispielsweise haben Sie in der ersten Entwicklungsphase 80% aller Nutzungsanforderungen richtig erkannt, d.h. die Nutzungsanforderungen sind zu 80% vollständig, korrekt, widerspruchsfrei usw.
- Jede nachfolgende Phase ist doppelt so aufwendig wie die vorausgegangene. Beispielsweise bereitete es doppelt so viel Arbeit, eine Systemspezifikation zu erstellen wie die Nutzungsanforderungen zu erheben. Oder doppelt so viel Arbeit, eine Softwarearchitektur in Code zu überführen (zu programmieren) wie die Softwarearchitektur zu spezifizieren.
Wenn Sie diese Hypothese gelten lassen, erkennen Sie, weshalb Produkte so fehlerhaft sind:
Abb.1: Ohne Reviews kann die Anzahl der Fehler während der Entwicklung exponentiell wachsen.
Der Anteil der fehlerhaften Entwicklungsartefakte wächst exponentiell! Bald gibt es mehr fehlerhafte als korrekte Inhalte.
Es gibt nur einen Weg, diesem Desaster zu entkommen: In jeder Phase müssen Sie die Fehler, die in dieser und allen vorausgegangenen Phasen eingeführt wurden, systematisch erkennen und eliminieren. Und hier sind – besonders in den konstruktiven Phasen des Entwicklungsprozesses – Reviews und andere Verifizierungsaktivitäten Ihre einzige Rettung.
Regulatorische Anforderungen
Keine Norm verlangt ein Review explizit als Methode. Einzig die ISO 13485 fordert Design Reviews.
Die IEC 62304 fordert die Verifizierung der Aktivitäten beispielsweise
- dem Spezifizieren der Software-Anforderungen,
- dem Beschreiben der Software-Architektur,
- der Software-Einheiten (Units) oder
- eine Bewertung der Verfahren für die Integrationsprüfung.
Ein Review bietet sich hierfür als geeignete Methode an.
Vorgehen bei Reviews
Abhängig von dem Typ und damit dem Grad der Formalisierung beinhalten Reviews folgende Schritte:
- Planung: Festgelegen, wann im Prozess wer welches Dokument auf was (Kriterien) wie prüfen soll
- Vorbereitung Teil 1: Einladen, verteilen der Dokumente, erläutern der Ziele, prüfen der formalen Eingangskriterien
- Vorbereitung Teil 2: Individuelle Vorbereitung der Reviewsitzung durch Gutachter, Prüfung anhand der Prüfkriterien z.B. anhand von Checklisten (bei Code z.B. Coding Guidelines). Gutachter notieren Fragen und Fehlerzustände
- Durchführung der Reviewsitzung. Lesen Sie weiter unten mehr dazu.
- Nachbereitung durch Autor: Überarbeiten (Fehler beheben), ggf. Wiedervorlage
- Nachbereitung durch Firma: Sammeln von Metriken, Nachbedingungen prüfen
Typen von Reviews
| Aspekt | Informelles Review | Walkthrough | Technisches Review | Inspektion |
|---|---|---|---|---|
| Grad der Formalisierung | Gering | Geringster, schwankend | Mittel | Höchster |
| Vergleich | Korrekturlesen (Autor-Leser-Zyklus), Pair-Programming | Präsentation Seminararbeit | Journals, nur gibt es Treffen der Gutachter Klausur mit mehreren Profs? | Akkreditierung Hochschule |
Anwesende
|
Anwesend Niemand, keine Sitzung | Anwesend
|
Anwesend
|
Anwesend
|
| Einsatz | Kleine Teams, nicht so wichtige Dokumente | |||
| Vorbereitung | Nein, kaum | Formale Prüfung (vorab) durch Gutachter anhand fixer Prüfkriterien, Checklisten vor Review, die vorab eingereicht werden | Formale Prüfung durch Gutachter anhand fixer Prüfkriterien, Checklisten vor Inspektion (Reviewfähigkeit) | |
| Prüfung durch | Autor schickt Dokument den Gutachtern, die schicken Liste mit Anmerkungen zurück oder Paar-Review | meist spontane Fragen des Gutachters | In Sitzung werden eingereichte Ergebnisse diskutiert und ein einstimmiges Urteil gefällt | Befragung des Autors |
| Sitzungsleitung | Keine Sitzung, kein Abgleich der Ergebnisse | Durch Autor selbst (open end) | Moderator | Moderator |
| Ziel | Fehler, Unklarheiten in schriftlichen Dokumenten finden, Lernen | Fehler finden Übereinstimmung von Dokumenten mit Spezifikationen, Standards | Fehler finden, Übereinstimmung mit Spezifikationen, Standards , Metriken | |
| Vorteil | Preisgünstig, schnell |
Reviews praxisnah umgesetzt
Regeln für Review-Sitzungen
- Erlauben Sie Diskussion, aber begrenzen Sie den Zeitrahmen (z.B. auf 2h)
- Der Moderator sollte nicht ein Gutachter
- Diskutieren Sie keine Lösungen. Das ist nicht der Fokus der Reviews.
- Halten Sie dafür Fehlerzustände, Befunde (und Bewertung) fest
- Erlauben Sie als Ergebnisse
- Dokument akzeptiert
- Dokument muss überarbeitet werden
- Dokument muss neu geschrieben werden
- Fertigen Sie ein schriftliches Protokoll an, das von allen zu unterschreiben ist.
- Dieses Protokoll ist eine Aufzeichnung. Lenken Sie es entsprechend.
Reviews und Templates in einem Dokument?
Wer liest schon gerne QM-Handbücher und SOPs? Entwickler in vielen Fällen nicht. Auch deshalb empfehle ich häufig, Inhalte aus SOPs in Templates zu verlagern. Diese Templates geben eine Kapitelstruktur vor und beinhalten in jedem Teilkapitel konkrete Hinweise zum Ausfüllen. Ein Beratungskunde von mir geht noch einen Schritt weiter: Er fügt in die Templates auch die Checklisten-Punkte ein, die bei einem Review durchgegangen werden müssen. Nun denke ich darüber nach, welche Vor- und Nachteile dieser Ansatz hat. Bisher sind mir folgende Aspekte eingefallen: Vorteile eines Dokuments, das den Review mit beinhaltet:
- Es ist völlig klar, auf welche Version bzw. welches Dokument sich das Review bezieht.
- Es bedarf nur einer Unterschrift des Reviewers. Er kann ggf. damit das Dokument direkt freigeben.
- Man muss beim Review nicht zwei Dokumente „offen“ haben.
Vorteile, wenn man das zu prüfende Dokument und das Review getrennt hält:
- Das eigentliche Dokument ist kürzer.
- Der Autor kann nicht so einfach Review-Checklistenpunkte löschen.
- Man kann in einer getrennten Checkliste besser Kommentare einfügen.
Fallen Ihnen noch weitere Aspekte ein? Ich freue mich auf Ihre Gedanken.
Mir fiel sofort dazu ein: wie werden Änderungen / Revisionen eines Dokuments gehandhabt? Muss dann eine neue Checkliste hinzukopiert werden? Bleibt die Checkliste(n) der vorherigen Version(en) im Dokument?
Der Übersichtlichkeit wegen wäre ich für die getrennte Lösung.
Wenn ich es richtig verstehe, ist die Checkliste immer Bestandteil des Dokuments. D.h. bei einer neuen Version wird die Checkliste neu ausgefüllt – wahrscheinlich wie Sie vermuten durch Kopieren. Ganz sicher bin ich nicht, müsste ich nachfragen.