Technisches Review
Das technische Review ist das Review einer einzigen Frage. Der BABOK zählt es zu den sieben Review-Typen und definiert es in einem Satz: eine formelle Technik, die sich entweder auf eine einzelne Frage oder auf eine Norm richtet und bei der die Reviewer das Arbeitsergebnis sorgfältig prüfen, bevor eine gemeinsame Sitzung stattfindet, die einberufen wird, um die betreffende Frage zu klären (§10.37.3.2). Von den sieben ist es das einzige, dessen Gegenstand eine Frage und kein Arbeitsergebnis ist: die übrigen sechs fragen, wie aufmerksam dieses Dokument zu lesen ist, dieses fragt, was die Sache ist, die geklärt werden muss. Es hat die Zeremonie der formellen Reviews, geplant, vorbereitet, in einer Sitzung gehalten, und die Reichweite einer einzigen Frage. Was es hervorbringt, ist eine Entscheidung zu dieser Frage, und der BABOK weist niemanden dafür aus, sie aufzuschreiben: das ist das Erste, was derjenige regelt, der es einberuft.
Ziel
Ein technisches Review wird einberufen, wenn eine Sache geklärt werden muss und die Antwort tragen soll. Die Frage wird vor der Sitzung benannt, die Reviewer prüfen das Arbeitsergebnis jeder für sich, und die Sitzung wird allein für diese Frage gehalten (§10.37.3.2). Seine ganze Ökonomie kommt daher: die Vorbereitung ist echt, die Sitzung ist formell, und beide gelten einer einzigen Frage.
Der BABOK führt sieben mögliche Ziele eines Reviews auf (§10.37.3.1), und das technische Review bedient davon zwei, die seine Definition beide benennt. Konformität zu einer Spezifikation oder einer Norm prüfen: die Definition trägt es ausdrücklich, eine formelle Technik, gerichtet «entweder auf eine einzelne Frage oder auf eine Norm», und der Singular macht die Technik aus: eine einzelne Norm und nicht die allgemeine Konformität eines Produkts. Einen Punkt klären: die Definition spricht von einer gemeinsamen Sitzung, gehalten «um die betreffende Frage zu klären».
Das fünfte Ziel des BABOK fasst drei zusammen: eine Frage beantworten, einen Punkt klären, Alternativen ausloten. Das technische Review nimmt jenes, das seine Definition benennt. Die beiden anderen werden anderswo erledigt, und was sie trennt, ist die Formalität und die Reichweite und nicht das Ziel. Eine eng gefasste Frage, an der eine Autorin hängen bleibt, geht an einen verfügbaren Peer und ist in Minuten erledigt, und das ist das Terrain des Ad-hoc-Reviews (10.37g). Optionen, die auf einem Entwurf noch offen sind, werden vor der Gruppe gegeneinander abgewogen, die die Autorin versammelt hat, und das ist jenes des informellen Walkthroughs (10.37d). Das technische Review klärt eine bereits gestellte Frage, in einer Sitzung, die für sie allein einberufen wurde, vor Reviewern, die das Produkt geprüft haben, bevor sie den Raum betraten. Optionen werden unterwegs abgewogen; worauf die Sitzung zielt, ist die Entscheidung.
Fünf Ziele entgehen ihm und alle fünf aus demselben Grund, seiner Reichweite. Fehler beseitigen: der BABOK gibt dieses Ziel namentlich der Inspektion, in derselben Liste von Definitionen, «der Fokus liegt darauf, Fehler zu beseitigen und ein Arbeitsergebnis hoher Qualität zu schaffen» (§10.37.3.2). Was ein technisches Review findet, ist eine Abweichung von der in Frage stehenden Norm, und was es hinterlässt, ist eine Entscheidung zu dieser Abweichung; das Fehlerprotokoll und die Prüfung der Nachbesserung gehören der Inspektion (10.37a). Sicherstellen, dass das Arbeitsergebnis vollständig und korrekt ist: die Vollständigkeit ist ein Urteil über das ganze Produkt, und der Gegenstand dieses Reviews ist eine Frage. Das ganze Produkt gehört der Inspektion (10.37a) und dem formalen Walkthrough (10.37b). Konsens über einen Ansatz oder eine Lösung herstellen: eine Einigung über einen Ansatz betrifft ebenfalls das Ganze, und ein Liefergegenstand, den ein Team tragen muss, gehört dem formalen Walkthrough (10.37b); die Einigung, die ein technisches Review hervorbringt, betrifft einen Punkt. Die Reviewer über den Inhalt informieren: eine für eine Frage einberufene Sitzung informiert über die Frage. Das Produkt wird vor einer Gruppe in einem formalen Walkthrough (10.37b) oder einem informellen Walkthrough (10.37d) durchgegangen, und es wird mehreren unabhängigen Lesern in einem Umlaufverfahren (10.37f) vorgelegt. Die Qualität des Arbeitsergebnisses messen: eine Messung setzt ein Fehlerprotokoll voraus, und der BABOK überträgt das Protokollieren und das Zusammenführen der Inspektion (10.37a). Wiegers zeichnet dieselbe Abstufung in seiner Tabelle 3-2: das Sammeln und Auswerten von Daten ist dort mit ja für die Inspektion, «vielleicht» für das Team-Review und nein für den Walkthrough markiert.
Der Liefergegenstand ist die Entscheidung zur betreffenden Frage. Sie benennt die Abweichung, sie sagt, was sich ändert, sie sagt, wer es trägt und bis wann. Aus ihr geht weder ein Fehlerprotokoll noch eine zusammengeführte Liste von Funden hervor: das sind die Artefakte der Inspektion (10.37a) und des formalen Walkthroughs (10.37b). Die Sitzung kommt auch nicht zurück, um zu kontrollieren, dass die beschlossenen Änderungen eingetragen wurden: sie hat geklärt, und der entschiedene Punkt wird danach im Item Tracking (10.26) verfolgt.
Einsatz
Wann einsetzen
- Eine einzige Norm steht auf dem Spiel: die Definition des BABOK benennt diesen Fall, «entweder eine einzelne Frage oder eine Norm» (§10.37.3.2).
- Eine präzise Frage muss geklärt werden: sie wird vor der Sitzung gestellt, und die Sitzung besteht für sie.
- Die Antwort verlangt mehrere Kompetenzen: Recht, Architektur, Fachbereich, einmal um denselben Punkt versammelt.
- Die Reviewer können das Produkt vor der Sitzung allein prüfen: die Definition macht das zur Bedingung der Technik.
- Die Entscheidung muss schriftlich tragen: sie führt eine Abweichung, einen Verantwortlichen und ein Datum.
- Ein Punkt blockiert eine Freigabe: das Review ist formell, und eine Freigabe braucht etwas, worauf sie sich stützen kann.
Wann nicht einsetzen
- Das ganze Produkt muss durchkämmt werden (Fehler, Vollständigkeit, Korrektheit): eine Inspektion (10.37a) protokolliert die Fehler und prüft die Nachbesserung; ein formaler Walkthrough (10.37b) führt im Team zusammen, was jeder allein gefunden hat.
- Die Frage ist offen und das Dokument ist ein Entwurf: die Optionen werden in einem informellen Walkthrough (10.37d) abgewogen, und eine eng gefasste Frage geht an einen Peer in einem Ad-hoc-Review (10.37g).
- Eine kompetente Lektüre genügt und keine Sitzung rechtfertigt sich: ein Desk Check (10.37e) stellt einen Reviewer vor das Dokument und die Norm; ein Umlaufverfahren (10.37f) stellt mehrere davor, jeden für sich.
Beschreibung
Die Grösse der Frage
Der BABOK gibt dieser Technik keine Schritte. Was über das Ergebnis entscheidet, liegt in der Art, wie die Frage gestellt wird, und das spielt sich ab, bevor irgendjemand den Raum betritt.
Nur eine Frage stellen
«Entspricht unser Datenmodell dem revDSG?» ist ein Arbeitsprogramm. «Entspricht die Entität Kunde des Datenmodells dem Art. 6 revDSG, Zweck und Verhältnismässigkeit, und dem Art. 5 lit. c über die besonders schützenswerten Personendaten?» ist eine Frage: sie lässt sich vorbereiten, sie lässt sich klären und eine Sitzung genügt dafür. Eine Frage passt in einen Fragesatz, was sie von einer Traktandenliste unterscheidet.
Die Norm bei ihren Artikeln nennen
ISO/IEC 20246 beschreibt das technische Review als jenes, das «Abweichungen von Spezifikationen und Normen identifiziert» (§3.18), und eine Abweichung misst sich an einem Text und nicht an einer Absicht. Die Norm betritt die Sitzung mit ihren Artikelnummern und dient während der Vorbereitung als Checkliste.
Die Reviewer nach Kompetenz wählen
Die IEEE spricht von einem Team qualifizierter Personen (§3.7), die ISO von einem Team technisch qualifizierter Personen (§3.18): was in den Raum führt, ist die Kompetenz zur Sache. Der BABOK hält im Übrigen fest, dass eine vorgesetzte Person bisweilen wegen ihrer Fachkenntnis an einem Review teilnimmt und dass der Moderator dann darauf achtet, die Offenheit des Austauschs zu wahren (§10.37.3.3).
Die vorgängige Prüfung verlangen
Die Definition des BABOK ruht ganz darauf: die Reviewer prüfen das Arbeitsergebnis sorgfältig, bevor die gemeinsame Sitzung stattfindet. Die IEEE macht daraus eine Pflicht für ihr eigenes Instrument: jedes Mitglied des Review-Teams muss das Produkt vor der Sitzung prüfen, und der Review-Leiter muss überprüfen, dass die Mitglieder vorbereitet sind, notfalls indem er einen Ersatz sucht oder die Sitzung verschiebt (§5.5.5). Eine Sitzung, in der niemand gelesen hat, beginnt zu lesen, und eine Lektüre im Raum ist eine andere Technik.
Wo das technische Review steht
Der BABOK führt seine sieben Review-Typen in absteigender Formalität auf und nennt die ersten drei formelle Techniken, die folgenden vier informelle Techniken (§10.37.3.2). Zwei binäre Fragen durchqueren diese Ordnung: ist die Sitzung geplant, prüft der Reviewer das Produkt allein, bevor er spricht? Das technische Review antwortet auf beide mit Ja, genau wie die Inspektion (10.37a) und der formale Walkthrough (10.37b). Die drei formellen Reviews tragen dieselbe Signatur: auf der Achse steht das technische Review auf der formellen, geplanten, vorbereiteten Seite, und was es von seinen beiden Nachbarn trennt, liest sich anderswo. Wiegers markiert diese zwei Tätigkeiten für sechs der sieben Typen (Tabelle 3-1); das technische Review, das in seinem Spektrum fehlt, hat seine zwei Ja vom BABOK selbst, der es als eine sorgfältige individuelle Prüfung vor einer gemeinsamen Sitzung beschreibt.
Derselbe Name bei der IEEE und bei der ISO
Der BABOK gibt diesem Review selbst seinen anderen Namen, technisches Review, den die beiden Normen des Gebiets tragen. Es lohnt sich zu lesen, was sie dazu sagen, denn ihr Instrument ist breiter als jenes des BABOK.
ISO/IEC 20246 definiert das technische Review als ein formelles Peer-Review, durchgeführt von einem Team technisch qualifizierter Personen, das die Eignung des Arbeitsergebnisses für den vorgesehenen Gebrauch prüft und Abweichungen von Spezifikationen und Normen identifiziert (§3.18); sie zählt es zu den Review-Typen, die sie definiert (§5.3). Dieselbe Norm definiert ein formelles Review als eines, das einem definierten Prozess folgt und eine formell dokumentierte Ausgabe hervorbringt (§3.5): daher kommt die Spur, und die ISO sagt es von ihrem eigenen Instrument. Die IEEE 1028 gibt dieselbe Definition, jene des Softwareprodukts (§3.7), und geht weiter: vier Rollen müssen für ein technisches Review eingerichtet werden, Entscheidungsträger, Review-Leiter, Protokollführer und technischer Reviewer (§5.2).
Hier trennen sich die beiden Traditionen. Der Gegenstand des technischen Reviews der IEEE ist das Softwareprodukt als Ganzes, seine Eignung für den vorgesehenen Gebrauch; der Gegenstand jenes des BABOK ist eine Frage oder eine Norm. Das Review der IEEE empfiehlt und gibt nach oben weiter; jenes des BABOK klärt die betreffende Frage. Die IEEE verlangt vier Rollen, darunter einen Protokollführer; der BABOK hält fest, dass ein Moderator für das technische Review hilfreich sein kann, und führt keinen Schreiber unter dessen anwendbaren Rollen (Tabelle 10.37.1). Zwei Instrumente tragen denselben Namen, sodass ein Team, das von einem technischen Review spricht, angeben muss, welcher der beiden Definitionen es folgt.
Was die Sitzung hervorbringt
Die drei formellen Reviews des BABOK lesen sich in ihren drei Definitionen, in je einem Satz, und sie bringen nicht dasselbe hervor (§10.37.3.2).
| Inspektion (10.37a) | Formaler Walkthrough (10.37b) | Technisches Review (10.37c) | |
|---|---|---|---|
| Was im Review steht | Das Arbeitsergebnis | Das Arbeitsergebnis | Eine einzelne Frage oder eine Norm |
| Was die gemeinsame Sitzung tut | Sie führt im Team die Fehler zusammen, die jeder Reviewer allein protokolliert hat | Sie führt im Team, mit denselben Tätigkeiten, zusammen, was jeder allein gefunden hat | Sie klärt die betreffende Frage |
| Was sie hinterlässt | Ein Fehlerprotokoll und eine Nachverfolgung, die sicherstellen soll, dass die Änderungen vorgenommen wurden | Einen zusammengeführten Satz von Funden | Eine Entscheidung zur betreffenden Frage |
Wer moderiert, wer protokolliert
Der BABOK ordnet jeder Review-Rolle die Techniken zu, auf die sie anwendbar ist (Tabelle 10.37.1). Für den Moderator führt er die Inspektion (10.37a) und den formalen Walkthrough (10.37b) auf, den er im Übrigen Team-Review nennt, und dann: «kann für das technische Review hilfreich sein». Für den Schreiber führt er die Inspektion (10.37a) und die formalen und informellen Walkthroughs auf, also den formalen Walkthrough (10.37b) und den informellen Walkthrough (10.37d), und das technische Review steht nicht darauf.
Der BABOK bringt diese beiden Zeilen nicht zusammen. Das Zusammenbringen lohnt sich dennoch, weil das technische Review jenes der sieben ist, das besteht, um eine Entscheidung hervorzubringen. Der Moderator hat in derselben Tabelle überdies die Aufgabe, zu validieren, dass die Reviewer das Arbeitsergebnis geprüft haben, bevor die Sitzung beginnt, eben die Eigenschaft, auf der die Definition des technischen Reviews ruht, die sie das Produkt vor der gemeinsamen Sitzung prüfen sieht. Die Pflicht, auf der die Definition ruht, ist jene, die der BABOK in der Rolle unterbringt, von der er nur sagt, dass sie für dieses Review hilfreich sein kann.
Was daraus zu machen ist, entscheidet sich vor der Sitzung und liegt in zwei Ernennungen. Wer ein technisches Review einberuft, benennt die Person, welche die Entscheidung schreiben wird, denn die Entscheidung ist der Liefergegenstand und ein Liefergegenstand hat einen Urheber. Und er benennt jemanden, der validiert, dass die Reviewer gelesen haben, denn die ganze Technik ruht auf dieser Lektüre.
Die Fallen
Die Frage in der Sitzung ausweiten
Die Sitzung wurde für eine Frage einberufen, die Reviewer haben diese Frage vorbereitet, und eine zweite kommt auf die Traktandenliste, weil alle da sind. Niemand hat sie vorbereitet, und eine Sitzung kann nur klären, was vorbereitet wurde. Eine Frage, die mitten in der Sitzung auftaucht, geht zurück in die Vorbereitung oder wechselt das Review.
Es für eine Inspektion halten
Es ist formell, es ist vorbereitet, es hält eine Sitzung, und es ist leicht, daraus zu schliessen, das Produkt sei durchkämmt worden. Geprüft wurde nur, was die Frage verlangte. Der Nachweis, dass ein ganzes Produkt Fehler für Fehler geprüft wurde, mit einer Prüfung der Nachbesserung, entsteht in einer Inspektion (10.37a).
Ohne Verantwortlichen und ohne Datum aus der Sitzung gehen
«Wir sind uns einig, dass dieses Attribut weg muss» ist eine Einigung, und sie lebt drei Wochen. Eine Entscheidung führt einen Verantwortlichen und eine Frist, und sie kommt noch am selben Tag ins Item Tracking (10.26). Das ist das Einzige, was eine Entscheidung von einer geteilten Meinung unterscheidet.
Die Norm vor der Tür lassen
Eine Sitzung, die darüber debattiert, was die Norm bedeutet, hat die Norm nicht vorbereitet. Der Text, seine Artikel und seine Absätze liegen auf dem Tisch, und die Uneinigkeit betrifft dann das Produkt und nicht das Recht.
KI-Überlegungen
Der Stoff eines technischen Reviews ist eine Gegenüberstellung zweier Texte, eines Arbeitsergebnisses und einer Norm, und das ist eine Arbeit, die ein grosses Sprachmodell schnell und gut erledigt. Es ist zugleich das Review der Familie, bei dem die Rolle des Modells am leichtesten überschätzt wird, denn es bringt eine Entscheidung hervor, und ein Modell bringt eine Antwort hervor.
Die Gegenüberstellung vorbereiten
Die 24 Attribute einer Entität gegen die deklarierten Zwecke durchgehen, jene markieren, die keinen haben, jene aufführen, die unter eine besondere Kategorie des Textes fallen: das ist mechanisch, das ist mühsam, und das ist genau, was ein Modell in Minuten liefert. Die Stunde der Reviewer wird dann auf die strittigen Fälle verwendet und nicht auf das Sortieren.
Den Text der Norm in den Kontext geben
Das revDSG ist am 1. September 2023 in Kraft getreten, und die Nummerierung der Artikel hat sich geändert. Ein Modell, das aus dem Gedächtnis antwortet, antwortet oft auf das alte Gesetz, mit der Sicherheit des neuen. Die Norm wird in den Kontext eingefügt, Artikel für Artikel, und die Antwort wird an ihr geprüft.
Die Entscheidung bleibt menschlich
Die Sitzung besteht, um eine Entscheidung zu treffen, die die Organisation bindet, und eine Entscheidung bindet jemanden. Ein Modell, das schreibt «dieses Attribut sollte entfernt werden», hat eine Empfehlung hervorgebracht, und der Wert des technischen Reviews liegt darin, dass es etwas anderes hervorbringt: einen geklärten Punkt, durch benannte Personen, zu einem Datum.
Die vorgängige Prüfung bleibt zu leisten
Eine sauber geführte Liste von Funden, aus einer Maschine gekommen, lässt eine Sitzung, in der drei Personen das Thema entdecken, wie eine vorbereitete aussehen. Die Definition der Technik ruht darauf, dass die Reviewer das Produkt geprüft haben, und niemand kann das an ihrer Stelle validieren.
Der Datenschutz
Ein Datenmodell, das ein Gesundheitsdatum führt, wird nicht in ein öffentliches Modell eingefügt: das ist eine Frage des revDSG, bevor es eine Frage der Produktivität ist, und die Regel der Organisation, welches Modell, welche Daten, wo gehostet, wird vor der Sitzung geklärt und nicht während ihr.
Beispiele
Was ein technisches Review hervorbringt, ist die aufgeschriebene Klärung der betreffenden Frage.
| Betreffende Frage | Entspricht die Entität Client des Datenmodells dem Art. 6 revDSG (Zweck, Verhältnismässigkeit) und dem Art. 5 lit. c (besonders schützenswerte Personendaten)? |
|---|---|
| Die Norm | revDSG, Art. 5 lit. c (besonders schützenswerte Personendaten), lit. f (Profiling) und lit. g (Profiling mit hohem Risiko); Art. 6 Abs. 2, Abs. 3 und Abs. 7; Art. 7 (Datenschutz durch Technik und durch datenschutzfreundliche Voreinstellungen) |
| Reviewer | Der Datenschutzberater, der Datenarchitekt, die Produktverantwortliche des Kundenbindungsprogramms |
| Vorgängige Prüfung | Jeder hat allein die 24 Attribute von Client den deklarierten Zwecken des Programms gegenübergestellt |
| Feststellung | 3 von 24 Attributen ohne deklarierten Zweck: date_naissance_conjoint, revenu_estime und etat_sante_declare, das ein besonders schützenswertes Personendatum im Sinne von Art. 5 lit. c ist |
| Entscheidung der Sitzung | etat_sante_declare und date_naissance_conjoint verlassen das Modell. revenu_estime bleibt: sein Zweck ist deklariert. Es ist ein abgeleitetes Datum, also ein Profiling im Sinne von Art. 5 lit. f, der die wirtschaftliche Lage nennt, und die Sitzung hält es für ein Profiling mit hohem Risiko; die ausdrückliche Einwilligung kommt in die Registrierungsstrecke (Art. 6 Abs. 7 lit. b). Das Modell ist konform, sobald die drei Änderungen vorgenommen sind. |
| Weiteres | Getragen vom Datenarchitekten, Frist 31. August, verfolgt als offenes Item |
Die Sitzung wurde für eine Frage einberufen, und sie endete mit einer Antwort: drei Attribute, drei Entscheidungen, mit einem Verantwortlichen und einem Datum. Zwei davon nehmen ein Datum aus dem Modell. Die dritte behält eines und fügt der Registrierungsstrecke die ausdrückliche Einwilligung hinzu, die Art. 6 Abs. 7 lit. b revDSG für ein Profiling mit hohem Risiko durch eine private Person verlangt, und das ist der Detailhändler. Das Urteil über das Risiko dieses Profilings ist genau die Frage, welche die Sitzung zu klären hatte.
Die drei Reviewer waren vorbereitet gekommen, und eine Sitzung genügte. Das Review kommt nicht zurück, um zu kontrollieren, dass die drei Änderungen im Modell eingetragen wurden: es hat geklärt, und der Punkt bleibt bis zu seinem Abschluss offen, verfolgt im Item Tracking (10.26).
Visualisierungen
Das Formalitätsspektrum ist ein räumliches Objekt: sieben Typen auf einer Achse, zwei Markierungen je Feld. Es verortet nur, ohne zu unterscheiden: die drei formellen Reviews antworten dort auf beide Fragen mit Ja. Die Abbildung zeigt die Stellung des technischen Reviews auf der formellen, geplanten, vorbereiteten Seite. Eine Achse und Positionen lassen sich nicht in Zellen wiedergeben, also wird sie gezeichnet.
Was das technische Review von seinen beiden Nachbarn trennt, ist seine Reichweite, und eine Reichweite liest sich, indem man drei Definitionen Begriff für Begriff vergleicht. Was aus Zeilen und Spalten besteht, gibt sich in Zellen wieder. Die drei Spalten kommen aus einer einzigen Quelle, dem §10.37.3.2 des BABOK, und die Legende der Tabelle sagt es dort, wo es zu sagen ist, in der Tabelle.
Das hervorgebrachte Artefakt ist das Protokoll eines technischen Reviews, mit der Frage, der Norm, der Feststellung und der Entscheidung. Die Wahl zwischen den sieben Reviews gehört der übergeordneten Technik (10.37), die genau dafür besteht.
Aufwand
| Phase | Stufe | Begründung |
|---|---|---|
| Vorbereitung | Mittel | Die Frage wird gestellt und die Norm vor der Sitzung benannt, und jeder Reviewer prüft das Arbeitsergebnis allein: der BABOK schreibt es in die Definition der Technik selbst (§10.37.3.2). Die Vorbereitung ist echt und sie wird bezahlt, aber sie betrifft eine Frage und nicht ein ganzes Produkt. |
| Durchführung | Mittel | Eine formelle Sitzung, mehrere Personen im selben Raum zur selben Zeit, ein einziges Traktandum. Der Aufwand ist jener der Sitzung mal der Zahl der Reviewer, und er ist durch die Reichweite begrenzt. |
| Dokumentation | Mittel | Die Entscheidung ist der Liefergegenstand: sie wird geschrieben, sie benennt eine Abweichung, einen Verantwortlichen und eine Frist, und der offene Punkt kommt ins Item Tracking (10.26). Der BABOK führt keinen Schreiber unter den auf dieses Review anwendbaren Rollen (Tabelle 10.37.1), also wird jemand zum Schreiben benannt, und dessen Zeit wird bezahlt. |
Werkzeuge
Das technische Review verlangt drei Dinge: den Text der Norm mit seinen Artikelnummern, das Arbeitsergebnis in einer Form, in der jeder Reviewer es allein kommentieren kann, und einen Ort, an dem die Entscheidung nach der Sitzung weiterlebt. Das Erste ist ein Dokument, das Zweite ist das Werkzeug, in dem das Produkt entstanden ist, das Dritte ist das Item Tracking (10.26).
Die Norm dient während der Vorbereitung als Checkliste, Artikel für Artikel, gegen das Produkt. Eine Zuordnungstabelle zwischen den Artikeln des Textes und den Elementen des Produkts, in einer Tabellenkalkulation oder im Anforderungsmanagement-Werkzeug geführt, ist es, was eine Sitzung von einer Stunde möglich macht: jeder Reviewer kommt mit demselben Raster, und die Sitzung betrifft die Felder, in denen die drei Lektüren auseinandergehen.
Review-Plattformen und Kommentarstränge sind das natürliche Werkzeug der individuellen Prüfung, jeder für sich. Die Sitzung dagegen wird gehalten: sie besteht, um zu klären, und eine Entscheidung fällt dort, wo die Leute sind. An dem Tag, an dem der Austausch vollständig schriftlich erfolgt und keine Sitzung stattfindet, ist es ein Umlaufverfahren (10.37f), und der BABOK hält fest, dass per E-Mail ausgetauschte Kommentare sehr viele zu bearbeitende Nachrichten hervorbringen können, was es der Autorin erschwert, die Uneinigkeiten aufzulösen (§10.37.4.2).
Quellen
- IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.37 Reviews (§10.37.3.1, die sieben Ziele; §10.37.3.2, die sieben Typen; §10.37.3.3, die Beteiligten; Tabelle 10.37.1, die Rollen; §10.37.4.2, die Limitationen).
- Karl E. Wiegers, Peer Reviews in Software: A Practical Guide, Addison-Wesley, 2002, Kapitel 3, «Peer Review Formality Spectrum» (Tabelle 3-1, Tätigkeiten je Review-Typ; sein Spektrum zählt sechs Methoden und enthält das technische Review nicht).
- ISO/IEC, ISO/IEC 20246:2017, Software and systems engineering: Work product reviews (§3.5, das formelle Review; §3.18, das technische Review; §5.3, die Review-Typen).
- IEEE, IEEE Std 1028-2008, IEEE Standard for Software Reviews and Audits (§3.7, das technische Review; §5.2, die Rollen; §5.5.5, die Vorbereitung).