Informelles & Technisches Review: Nie gefordert und doch verlangt?

Mittwoch 30. September 2015

Ein Review ist eine manuelle Bewertung eines Artefakts (z.B. Code, Dokument), das abhängig von den formalen Anforderungen und den beteiligten Personen beispielsweise als Inspektion oder Walk-through bezeichnet wird.

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:

  1. 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.
  2. 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:

FehlerexplosionOhne 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

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:

  1. Planung: Festgelegen, wann im Prozess wer welches Dokument auf was (Kriterien) wie prüfen soll
  2. Vorbereitung Teil 1: Einladen, verteilen der Dokumente, erläutern der Ziele, prüfen der formalen Eingangskriterien
  3. 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
  4. Durchführung der Reviewsitzung. Lesen Sie weiter unten mehr dazu.
  5. Nachbereitung durch Autor: Überarbeiten (Fehler beheben), ggf. Wiedervorlage
  6. 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

  • Autor
  • Moderator
  • Gutachter
  • Protokollierer
Anwesend Niemand, keine Sitzung Anwesend

  • Ja
  • Nein
  • Ja
  • optional
Anwesend

  • Nein (!)
  • Ja
  • Ja
  • Nein
  • Kein Management
Anwesend

  • Ja
  • Ja
  • Ja
  • Ja
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.

War dieser Artikel hilfreich? Bitte bewerten Sie:
1 Stern2 Sterne3 Sterne4 Sterne5 Sterne

Kategorien: Regulatory Affairs

2 Kommentare über “Informelles & Technisches Review: Nie gefordert und doch verlangt?”

  1. Michael Ständer schrieb:

    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.

  2. Christian Johner schrieb:

    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.

Kommentar schreiben