
|
Allgemeiner Hinweis
Die folgende Beschreibung baut auf den ausführlichen Leitfaden
zur Planung, Durchführung und Dokumentation von Reviews
auf, der von PSE QM herausgegeben wurde. Zur
Unterstützung von Reviews gibt es eigene Reviewformulare
für
Kommentar- und Sitzungstechnik
(Winword-Files). Was ist ein Review?
Hier die gebräuchlichste Definition:
Ein Review ist eine systematische, kritische,
dokumentierte Prüfung von Entwicklungsergebnissen am
Ende von definierten Arbeitsschritten. Es wird dabei das
Ziel verfolgt, Fehler zu finden.
Was heißt Dokumentenreview?
Als Entwicklungsergebnis wird in diesem Fall ein Dokument
verstanden, wie zum Beispiel:
- Projektplan
- CM-Plan
- QS-Plan
- Testplan
- Pflichtenheft
- und weitere Entwicklungsergebnisse, deren Review
vorgeschrieben ist oder empfehlenswert erscheint.
Was heißt Ende eines definierten
Arbeitsschrittes?
Ein Review ist nur dann sinnvoll, wenn das
Dokument auch tatsächlich fertig ist, d.h. den nötigen
Reifegrad zur Überprüfung aufweisen kann. Das ist im
allgemeinen dann der Fall, wenn ein Arbeitsschritt
abgeschlossen ist (z.B. Erstellen des QS-Plans).
Die nächsten definierten Schritte könnten dann lauten: Review
des QS-Plans, Überarbeiten des QS-Plans
und Freigabe des QS-Plans.
Wie gehe ich die Prüfung an?
Es empfiehlt sich, systematisch vorzugehen, d.h. sich
für eine bewährte Reviewmethode zu entscheiden.
Übliche und weithin bewährte Reviewmethoden sind (auch
in kombiniertem Einsatz) die
- Kommentartechnik und die
- Sitzungstechnik.
Wie läuft ein Review in Kommentartechnik ab?
Die Unterlagen werden zunächst an die Reviewer verteilt:
- Dokument (am besten mit Zeilennummern versehen
auf Papier)
- Referenzdokumente (wogegen wird reviewt?)
- Projekt-Standards und -Vorgaben (falls vorhanden)
- Protokoll-Templates
- sonstige nützliche Unterlagen
Diese arbeiten das Dokument für sich durch und
übergeben ihre Stellungnahmen dem Absender (i.a.: Autor,
Veranlasser, Moderator, Einlader, ....). Dieser bewertet
(ggf. in Absprache) die Kommentare, und der Autor
arbeitet die Änderungen ein (waren die notwendigen
Korrekturen sehr umfangreich, empfiehlt sich ein
Nachreview in kleinerem Rahmen).
Wie läuft ein Review in Sitzungstechnik ab?
Die Unterlagen werden zunächst an die Reviewer verteilt.
Zum festgesetzten Sitzungstermin wird das Dokument anhand
der Aufzeichnungen der Reviewteilnehmer gemeinsam
durchgegangen. Anschließend erstellt der
Moderator/Protokollführer das Sitzungsprotokoll und
bewertet die Fehler. Nun weiß der Autor über den Umfang
der anstehenden Ausbesserungen Bescheid.
Eine stärker formalisierte Form der Sitzungstechnik
ist die Intensivinspektion nach M. Fagan
(sie ist wesentlich effektiver und effizienter als die
traditionelle Sitzungstechnik, benötigt aber unmittelbar
relativ viel Zeit). Die Anzahl der Teilnehmer wird auf 3
bis 6 beschränkt, die ein genau definiertes Rollenspiel
durchzuführen haben. Unbedingt notwendig sind:
zusätzlich können noch bis zu 3 weitere Inspektoren
beschäftigt werden, die bestimmte Rollen ausführen, wie
ein Schnittstellen-Prüfer, ein Anwender, ein
Überprüfer von Standards, ein Tester, etc., die das
Dokument aus ihrem Rollenverständnis heraus prüfen. Die
Dauer einer derartigen Sitzung soll 2 Stunden nicht
überschreiten. Daraus ergibt sich auch eine
Beschränkung des Dokumentenumfangs, der in einer Sitzung
durchgearbeitet werden kann und die Notwendigkeit, das
Dokument ggf. in mehreren Sitzungen zu prüfen.
Welche Methode nehme ich nun für mein
Dokumenten-Review?
Für besonders heikle" Dokumente oder
heikle" Teile des Dokuments empfiehlt sich
unbedingt die Intensivinspektion. Für weitere Dokumente
soll folgende Entscheidungstabelle dienen:
pro
Kommentartechnik:
- viele Teilnehmer sind möglich
- keine Terminabsprachen sind notwendig
- keine Orts"-Probleme
- kein Sitzungsaufwand
- kein Reiseaufwand
|
contra
Kommentartechnik:
- keine Diskussion in der Runde
- kein Synergieeffekt durch Sitzung
- niedrige Fehlerfindungsrate
|
pro
Sitzungstechnik:
- höhere Fehlerfindungsrate
- Mißverständnisse lassen sich schnell
klären (Dokumente)
|
contra
Sitzungstechnik:
- zu große Runde ist abzulehnen
- das Orts"-Problem stellt sich
(D, USA, A, ....)
- Terminabsprachen werden notwendig
- negative psychologische Komponenten sind
möglich (Druck durch Vorgesetzte,
Antipathien, ....)
|
pro
Intensivinspektion:
- Rollenspiel fördert Review-Disziplin
- vollständige Prüfung des Dokuments
gegen die Vorgabe
- höchste Effizienz und Effektivität
|
contra
Intensivinspektion:
- geringe Review-Geschwindigkeit
- Ausbildung vorhanden ?
|
Warum dokumentierte Prüfung?
Unabhängig von der gewählten Methode ist jedes Review
durch ein Reviewprotokoll zu dokumentieren:
- Damit der Autor ein von allen Teilnehmern
akzeptiertes Fehlerprotokoll für die
Fehlerbehebung bei sich hat.
- Damit alle Teilnehmer und Unterrichtete ein
Dokument zur Verfügung haben, in dem sie bei der
Planung und Durchführung weiterer Reviews
Erfahrungswerte finden können.
- Um gemäß ISO9001 eine Qualitätsaufzeichnung
zum Entwicklungsergebnis ablegen zu können, um
im Bedarfsfall eine Prüfung nachweisen zu
können.
Ein Reviewprotokoll soll aus dem Deckblatt inkl.
Fehlerstatistik, der Fehlerliste und ggf. einem
Analyseprotokoll bestehen.
Wen betrifft das Dokumenten-Review?
- Den Autor: Ich will
mein Ergebnis durch eine Runde abgesichert wissen
und möglichst wenige Fehler nach vorne (in die
nächste Entwicklungsphase) weitergeben.
- Das Team: Wir wollen in
der nächsten Phase auf etwas Abgesichertes
aufsetzen können, wir haben auch ein vom Kunden
akzeptiertes Ergebnis als Basis zur Weiterarbeit,
wir kennen uns aufgrund der Reviews im ganzen
Subsystem aus und können erfolgreicher
weiterarbeiten, wir haben gelernt, miteinander
sachlich zu diskutieren.
- Den Auftraggeber: Das
Dokument wurde geprüft und von mir akzeptiert.
Ich weiß, auf was aufgesetzt werden kann. Ich
kenne den von mir zu bezahlenden Umfang.
- Den Auftragnehmer: Ich
habe das Dokument von Fachleuten überprüfen
lassen. Ich erwarte keine Fallen mehr.
Was tun bei wenig Zeit und Geld?
Setzen Sie Prioritäten: Wo ist es besonders wichtig, in
Dokumenten-Reviews Zeit und Geld zu investieren?
- bei frühen Dokumenten
(der Aufwand für die Fehlerbehebung ist noch
relativ gering)
- bei schweren Fehlerfolgen
(z.B. sicherheitsrelevante Software, Image des
Auftraggebers, zentrale Dokumente)
- bei hoher Fehlerwahrscheinlichkeit
(z.B. Autor neu in diesem Umfeld bezüglich Thema
und Tools, Kommunikationsprobleme - Ort und
Sprache, komplexes Thema,da gabs
immer schon viele Fehler",...)
Wo kann ich die meisten Fehler erwarten?
Erfahrungsgemäß konzentrieren sich die Fehler in den
Entwicklungsdokumenten auf einige wenige Themen:
- Vergessen von einzelnen CASE-Fällen (20%)
- Ignorieren von Extrembedingungen (17%)
- Mißverstehen von Vorgängerdokumenten (12%)
- Falsche Abfragen (12%)
Zusätzlich zum eigentlichen Review empfiehlt
sich eine Analyse des Reviews
Im Anschluß an ein Review soll eine kurze Analyse
durchgeführt werden, um aus dem eigenen Verhalten und
den Fehlern zu lernen (Hinweise dazu finden sich im
Reviewformular). Hinsichtlich des Reviewprozesses
bedeutet das:
- Hat bei der Planung alles gestimmt (Teilnehmer,
Termin, Material,...)?
- Wie lief das Review selbst (Konzentration,
Fehlerfindung, Räumlichkeiten,...)?
- Wie kam die Fehlerbewertung zustande (Konsens,
Machtwort des Leiters,...)
- Es lohnt sich auch, Positives im Analyseprotokoll
anzumerken!
Hinsichtlich des Entwicklungsprozesses
stellen sich folgende Fragen:
- Welche Fehler tauchen immer wieder auf?
- Warum?
- Was könnte man dagegen tun (Maßnahmen und
Verantwortliche)?
Sind diese Quellen gestopft, dann sollte einer
Verbesserung des Entwicklungsprozesses nichts mehr im
Wege stehen.
|