Inspektion

Ziel

Eine Inspektion dient dazu, Fehler aus einem Arbeitsergebnis zu entfernen, bevor sie teuer werden, und der BABOK gibt ihr diesen Zweck namentlich: Fehler beseitigen und ein Arbeitsergebnis hoher Qualität herstellen (§10.37.3.2). Im selben Satz fügt er die Nuance hinzu, die zu behalten ist: die Inspektion wird gewöhnlich von Peers durchgeführt, und sie kann auch für Reviews durch Stakeholder eingesetzt werden. Sie ist das formellste und systematischste der Peer-Reviews, schreibt Wiegers, und sie ist das einzige, von dem er sagt, es sei als Best Practice der Softwareindustrie anerkannt worden.

Was die Inspektion einkauft, will bezahlt sein, und die Rechnung steht bei Wiegers ausdrücklich da. Fehler verteilen sich nicht gleichmässig über ein Produkt: eine von ihm zitierte Studie findet 58 % der von Kunden gemeldeten Fehler in 31 von 425 Modulen, eine andere, dass rund 20 % der Module rund 80 % der Fehler auf sich vereinen. Sein Schluss ist die Auswahlregel der Technik: die Inspektion auf Arbeitsergebnisse mit hohem Risiko anwenden und sich für Komponenten mit geringerem Risiko auf günstigere Techniken stützen. Der BABOK sagt dasselbe von der anderen Seite her: die frühe Identifikation von Fehlern erspart es, sie später im Lebenszyklus teuer entfernen zu müssen (§10.37.4.1).

Die Zahlen, die er berichtet, geben die Grössenordnung des Gewinns. Ein Telekommunikationsunternehmen fand pro Inspektion 16 bis 20 Fehler je tausend Codezeilen, gegenüber drei, wenn das Review informell geführt wurde. Bei Ford fanden Inspektionen 50 % mehr Fehler je tausend Zeilen als Walkthroughs. Und in einem Anforderungsdokument, das bereits mehrfach zwischen Reviewern zirkuliert war, fand eine formale Inspektion des zusammengesetzten Textes durchschnittlich 4,5 zusätzliche Fehler pro Seite. Ein Umlaufverfahren nimmt die leichten Fehler schnell und günstig heraus; die Inspektion, die folgt, bezahlt sich an dem, was übrig bleibt.

Die Zieltabelle von Wiegers vergleicht sechs Review-Methoden über vierzehn Ziele, und sie markiert acht davon für die Inspektion, mehr als für jede andere Methode (Tabelle 3-3). Der formale Walkthrough trägt sieben, der informelle Walkthrough ebenfalls sieben, und es sind nicht dieselben sieben.

• Fehler im Produkt beseitigen.
• Konformität mit einer Spezifikation prüfen.
• Konformität mit einer Norm prüfen.
• Feststellen, dass das Produkt vollständig und korrekt ist.
• Verständlichkeit und Wartbarkeit des Dokuments beurteilen.
• Die Qualität einer kritischen Komponente oder einer Komponente mit hohem Risiko nachweisen.
• Daten zur Prozessverbesserung sammeln.
• Die Qualität des Dokuments messen.

Die beiden fett gesetzten Zeilen markiert Wiegers für keine der fünf anderen Methoden. Die erste ist das Ziel, das die Ausgabe rechtfertigt: eine kritische Komponente wird inspiziert, um feststellen und zeigen zu können, dass sie hält. Die zweite setzt Zählen voraus, und es ist allein der Inspektion, der Wiegers die Messung der Dokumentqualität vorbehält (Tabelle 3-3); sie ist auch die einzige, für die er das Sammeln und Auswerten von Daten ohne Vorbehalt markiert (Tabelle 3-2: ja, wo das Team-Review ein «vielleicht» erhält).

Was die Inspektion hinterlässt, ist ein geschlossenes Fehlerprotokoll, eine Produktbeurteilung und Messwerte. Das Protokoll und die Beurteilung gehen aus der Sitzung hervor; der Abschluss des Protokolls geht aus der Nachverfolgung hervor. Der formale Walkthrough spricht eine Beurteilung aus und hört dort auf (Wiegers, Tabelle 3-1: Korrektur, ja; Verifikation, nein).

Einsatz

Wann einsetzen

• Arbeitsergebnis mit hohem Risiko: ein später entdeckter Fehler ist teuer zu beheben (BABOK §10.37.4.1).
• Ein Qualitätstor oder eine Freigabe muss sich auf einen Nachweis stützen: nur ein dokumentiertes und verifiziertes Review hinterlässt einen.
• Die Konformität mit einer Norm muss nachgewiesen werden: Tabelle 3-3 von Wiegers markiert dieses Ziel für die Inspektion.
• Fehlerkennzahlen werden erwartet: Daten sammeln und die Dokumentqualität messen gehören zu ihren Zielen (Tabelle 3-3).
• Das Produkt wird zur Grundlage für andere: wiederverwendete Komponente, Vorlage, Referenzmodell, tragende Architektur.

Wann nicht einsetzen

• Das Produkt ist noch ein Entwurf und in Bewegung: die Inspektion setzt ein stabiles Artefakt voraus. Ein informeller Walkthrough lässt die Autorin den Entwurf durchgehen und sammelt Rückmeldungen.
• Geringes Risiko oder eine günstige Entscheidung: das teuerste Review des Spektrums zahlt sich dort nicht zurück. Ein Desk Check setzt eine kompetente Leserin vor das Dokument, ein Umlaufverfahren mehrere, jede für sich.
• Weder geschulter Moderator noch geschultes Team noch Prüfliste: die Technik ruht auf allen dreien, und ohne sie liefert sie das Ergebnis eines Walkthroughs zum Preis einer Inspektion. Ein formaler Walkthrough verlangt weder einen Leser noch geschulte Inspektoren.

Beschreibung

Die Rollen

Der BABOK gibt der Inspektion vier Rollen (Tabelle 10.37.1). Die Autorin beantwortet Fragen, hört zu und arbeitet die Änderungen nach der Sitzung ein. Der Reviewer prüft das Produkt gegen die Ziele des Reviews, und der BABOK präzisiert, was er in einem Review zur Fehlererkennung tut: er prüft das Arbeitsergebnis vor der Sitzung und führt die Liste der gefundenen Fehler wie auch der Verbesserungsvorschläge. Der Facilitator, wie der BABOK die Rolle in dieser Tabelle nennt, während seine Prosa einmal Moderator sagt, führt die Sitzung. Der Schreiber hält alle Fehler, Vorschläge, Kommentare, Punkte, Bedenken und offenen Fragen fest, die in der Sitzung aufgeworfen werden.

Wiegers, die IEEE und Fagan sagen Moderator. Der BABOK schreibt, dieser neutrale Facilitator sollte nicht die Autorin sein, um das Review nicht zu kompromittieren. Bei den Autoritäten der Praxis ist die Regel härter: Wiegers schreibt, in einer Inspektion sei es der Autorin nicht gestattet, die Rolle der Moderatorin zu übernehmen, und die IEEE 1028-2008, die die Inspektion namentlich definiert, verteilt fünf Rollen (Inspektionsleitung, Protokollführung, Leser, Autorin, Inspektor) und hält fest, dass die Autorin keine der ersten drei innehaben darf.

Der Leser ist die Rolle, die die Inspektion vom ganzen Rest der Familie trennt. Das Material wird dem Team von einer anderen Person als der Autorin vorgestellt, ein kleines Stück nach dem anderen. Die Begründung, die Wiegers dafür gibt, ist mechanisch: der Leser hilft dem Team, zu derselben Interpretation jedes Produktabschnitts zu gelangen, weil jeder Inspektor sein Verständnis mit dem vergleichen kann, das der Leser ausspricht. Eine Autorin, die ihr eigenes Dokument durchgeht, sagt, was sie sagen wollte. Ein Leser sagt, was dasteht, und die Differenz zwischen beidem ist ein Fehler. Ein Review, in dem die Autorin präsentiert, ist ein informeller Walkthrough, gleichgültig, welches Wort auf der Einladung steht.

Die Eingangskriterien

Wiegers zählt ausdrückliche Eingangs- und Ausgangskriterien zu den Merkmalen der formellsten Reviews. Konkret: das Arbeitsergebnis ist vollständig und stabil; es ist zeilen- oder seitennummeriert, sonst lässt sich ein Fehler nicht verorten; die Fehlerprüfliste existiert; die Inspektoren sind benannt und geschult; und der Moderator hat bestätigt, dass das Material bereit ist. Der BABOK gibt dem Facilitator im Übrigen eine Aufgabe, die ein Eingangskriterium unter anderem Namen ist: er validiert, dass die Reviewer das Arbeitsergebnis vor Beginn der Sitzung geprüft haben (Tabelle 10.37.1).

Die sechs Operationen von Fagan

Die Etappenlisten der Inspektion decken sich nicht, und man muss sie ihrer Quelle zuordnen, statt sie zu verschmelzen. Der BABOK nennt fünf in seiner Definition (Überblick, individuelle Prüfung, Protokollierung der Fehler, Konsolidierung im Team, Nachverfolgung). Tabelle 3-1 von Wiegers markiert fünf andere, die Aktivitäten und keine Etappen sind (Planung, Vorbereitung, Sitzung, Korrektur, Verifikation). Seine Prosa beschreibt sieben und fügt die Ursachenanalyse hinzu. Verwendet wird die Gliederung von Fagan, der die Technik 1976 definiert hat und dessen sechs Operationen die übrige Praxis übernommen hat.

1. Planung
   Der Moderator wählt das Arbeitsergebnis und das Team, teilt das Material in Stücke, legt das Tempo fest und lädt ein. Das Tempo ist ein Parameter: jenseits weniger Seiten pro Stunde bricht die Fehlerausbeute ein.
2. Überblick
   Die Autorin gibt dem Team den Kontext des Produkts. Fagan macht daraus eine Operation, der BABOK nennt ihn als erste seiner fünf Aktivitäten, und er entfällt, wenn das Team die Domäne bereits kennt.
3. Individuelle Vorbereitung
   Jeder Inspektor prüft das Produkt allein, gegen eine Fehlerprüfliste, und notiert, was er findet. Wiegers schreibt, Inspektionen stützten sich auf Listen von Fehlern, die in den verschiedenen Arten von Arbeitsergebnissen häufig vorkommen, und seine Tabelle 3-2 markiert für die Inspektion den Gebrauch dieser Listen. Das ist die Operation, die den grössten Teil der Arbeit leistet, und es ist die, die zuerst geopfert wird. Die Prüfliste gibt dieser Lektüre ihre Form; ohne sie liest der Inspektor mit dem, was er im Kopf hat.

   Die Prüfliste wird im Haus gebaut. Eine generische Liste von anderswo beschreibt die Fehler einer anderen Organisation. Die brauchbare entsteht aus den Protokollen vergangener Inspektionen: die bereits gefundenen Fehler werden nach Typ gruppiert und die wiederkehrenden behalten. Jede behaltene Zeile wird zu einer Frage, die der Inspektor an das Dokument richtet. «Nennt jeder gedeckelte Betrag den Artikel, der ihn festsetzt?» «Sagt jedes Altersband, ob seine Grenze eingeschlossen ist?» «Ist jeder Satz datiert?» Eine Frage, die das Dokument nicht beantwortet, ist ein Fehler, und eine Frage, die in drei Inspektionen nichts gefunden hat, fällt von der Liste. Die Pflege folgt demselben Takt: nach jeder Sitzung giesst der Moderator das Protokoll in den Bestand, und ein Fehler, der dreimal aufgetreten ist, ohne auf der Liste zu stehen, kommt darauf. Eine Liste, die sich nie ändert, hat aufgehört zu beschreiben, was die Organisation falsch schreibt. Von den sieben Reviews ist die Inspektion dasjenige, dessen Definition die Protokollierung der Fehler nennt (§10.37.3.2), und damit das einzige, das den Bestand hinterlässt, von dem sich diese Arbeit nährt.

4. Inspektionssitzung
   Der Leser geht das Produkt in kleinen Stücken durch (Tabelle 3-2: Granularität des vorgestellten Materials, kleine Stücke); die Inspektoren bringen vor, was sie gefunden haben; der Schreiber protokolliert jeden Punkt. Die Sitzung protokolliert, und die Korrektur geschieht danach. Die Sitzung endet mit drei Dingen: dem Fehlerprotokoll, die Produktbeurteilung (Tabelle 3-2: Produktbeurteilung ausgesprochen, ja) und die Festlegung der Verifikation.
5. Nacharbeit
   Die Autorin korrigiert, allein, ausserhalb der Sitzung, und sie korrigiert gegen das Protokoll: jede Zeile erhält eine Änderung oder den schriftlichen Grund, warum sie keine erhalten hat. Eine Zeile, die die Autorin bestreitet, geht an den Moderator zurück; sie verschwindet nicht. Hier zahlt sich die Trennung von Finden und Reparieren aus: der Raum hat protokolliert, ohne über Lösungen zu diskutieren, und die Autorin hat deshalb die Zeit, den Kontext und die Ruhe, sie zu finden.
6. Nachverfolgung
   Der Moderator führt die in der Sitzung getroffene Festlegung aus, Zeile für Zeile, was das Protokoll schliesst.

Die Nacharbeit und ihre Verifikation

Hier hebt sich die Technik ab, und die genaue Formulierung zählt, weil die kurze Fassung falsch ist. Was die Nachverfolgung verlangt, wird in der Sitzung vom Team entschieden und protokolliert. Wiegers schreibt es ohne Zweideutigkeit: am Ende der Inspektionssitzung einigt sich das Team auf eine Beurteilung des Arbeitsergebnisses und beurteilt, ob die Änderungen, die die Autorin in der Nacharbeit vornehmen wird, durch eine zweite Inspektion, durch eine einzige Person oder überhaupt nicht verifiziert werden müssen. Fagan sagt dasselbe: eine triviale Korrektur kann ohne Verifikation angenommen werden, und ein nicht trivialer Fall verlangt eine vollständige erneute Inspektion durch das Team.

Die Verifikation der Nacharbeit ist also eine Festlegung, von Fall zu Fall getroffen. Was die Inspektion für sich hat: sie ist das einzige der sieben Reviews des BABOK, dessen Definition eine Nachverfolgung trägt, die Frage der Verifikation wird in ihr gestellt, entschieden und zugewiesen, und das Protokoll schliesst sich über der Antwort. Anderswo bleibt die Frage ausserhalb der Technik. Ein Fund aus einem formalen Walkthrough, der die Sitzung überleben soll, geht ins Item Tracking, und ein anderes Werkzeug, in anderer Hand, trägt ihn weiter. In einer Inspektion verlässt der Fund die Technik nicht, bevor er geschlossen ist.

Was der Moderator unter jeder der drei Festlegungen tut

Unter erneuter Inspektion lädt er das Team erneut ein oder den Teil des Teams, der die betroffenen Fehler vorgebracht hat, und zwar nur auf die überarbeiteten Abschnitte: der Leser geht durch, was sich geändert hat, das Team prüft, dass die Korrektur den Fehler behebt und keinen neuen einführt, danach schliessen sich die betroffenen Zeilen in der Sitzung. Unter Verifikation durch eine einzige Person benennt er den Verifizierenden, meist sich selbst, mitunter den Inspektor, der den Fehler gefunden hat, und dieser vergleicht die überarbeitete Fassung Zeile für Zeile mit dem Protokoll und zeichnet dann ab. Unter unverändert angenommen gibt es nichts zu verifizieren: die Zeile schliesst sich über der von der Autorin erklärten Änderung, und die Festlegung selbst ist die Spur dessen, was das Team beurteilt hat. In allen drei Fällen trägt die Zeile am Ende einen Verifizierenden, ein Datum und einen Status, und eine Zeile, der eines der drei fehlt, ist offen, was auch immer die Autorin dazu sagt.

Die Ausgangskriterien passen in einen Satz: das Fehlerprotokoll ist gemäss der in der Sitzung getroffenen Festlegung geschlossen, und die Produktbeurteilung hält.

Die Messwerte

Tabelle 3-2 von Wiegers markiert die Zeile Daten gesammelt und ausgewertet für die Inspektion: ja. Für das Team-Review, das der formale Walkthrough des BABOK ist, schreibt er vielleicht. Für den Walkthrough, der der informelle Walkthrough ist, nein. Seine Tabelle 3-3, die eine Tabelle von Zielen und nicht von Aktivitäten ist, markiert Daten zur Prozessverbesserung sammeln nur für zwei Methoden, die Inspektion und das Team-Review, und sie behält die Qualität des Dokuments messen allein der Inspektion vor. Diese beiden Zeilen stehen in zwei verschiedenen Tabellen und sagen zwei verschiedene Dinge: die eine ist ein Merkmal der Technik, die andere ein Grund, sie einzuberufen.

Was sich aus dem Protokoll und der Anwesenheitsliste berechnen lässt: die Zahl der Fehler pro Seite, die Fehlerdichte nach Schweregrad, das Inspektionstempo in Seiten pro Stunde und der Aufwand pro gefundenem Fehler. Eine Organisation, die drei vergleichbare Dokumente inspiziert, besitzt eine Vergleichsbasis; eine, die nicht inspiziert, besitzt Eindrücke. Es ist der dritte Grund zu inspizieren, den Wiegers nach der IEEE anführt: Kennzahlen zu Fehlern und zum Inspektionsaufwand liefern, die sowohl den Inspektionsprozess als auch den Engineering-Prozess der Organisation verbessern lassen. Wiegers fügt seinem eigenen Inspektionsprozess im Übrigen eine siebte Etappe hinzu, die Ursachenanalyse, und sie ist das, was man mit diesen Messwerten tut: herausfinden, warum die gefundenen Fehler geschrieben wurden.

Wo die Inspektion steht

Der BABOK listet seine sieben Review-Typen nach abnehmender Formalität und bezeichnet die ersten drei als formale Techniken, die folgenden vier als informelle Techniken (§10.37.3.2). Zwei binäre Fragen durchziehen diese Ordnung: ist die Sitzung geplant, und prüft der Reviewer das Produkt allein, bevor er spricht? Die Inspektion beantwortet beide mit Ja, und darin ist sie vom formalen Walkthrough und vom technischen Review nicht zu unterscheiden. Eine dritte Frage trennt sie: enthält die Definition der Technik eine Nachverfolgung der Nacharbeit? Von den sieben Definitionen des BABOK trägt sie nur eine.

Die dritte Frage beruht auf einer Ausschlussargumentation. Tabelle 3-1 von Wiegers markiert die Verifikation für die Inspektion und verweigert sie dem Team-Review, dem Walkthrough, dem Peer Deskcheck, den er mit dem Umlaufverfahren zusammenfasst, und dem Ad-hoc-Review. Sein Spektrum enthält keine Zeile für das technische Review, das aus der Tradition von IEEE und ISO stammt. Die Deckung dieses Feldes stammt daher vom BABOK: jeder seiner sieben Typen erhält eine Definition von einem Satz, und die Nachverfolgung erscheint in genau einer davon. Das ist eine Tatsache über den Text des BABOK, der zu den sechs anderen in diesem Punkt nichts sagt. Tabelle 3-1 von Wiegers markiert die Verifikation im Übrigen auch für die Paarprogrammierung, die keines der sieben Reviews des BABOK ist und die Wiegers selbst ausserhalb der Kategorie einordnet.

Die Fallstricke

In der Sitzung korrigieren

Die Sitzung protokolliert, und der erste interessante Fehler trägt die Stunde davon, wenn der Moderator ihn lässt. Der Preis einer Inspektion ist der Preis aller Anwesenden zur selben Zeit, und über eine Korrektur zu diskutieren ist genau die Arbeit, die die Autorin später allein und günstiger erledigen wird.

Inspektoren, die nicht vorbereitet haben

Der BABOK überträgt dem Facilitator die Validierung, dass die Reviewer das Arbeitsergebnis vor Beginn der Sitzung geprüft haben (Tabelle 10.37.1), und es ist die einzige Aufgabe der Technik, die vor dem Füllen des Raums geschieht. Vier Inspektoren, die das Dokument in der Sitzung entdecken, liefern eine erste gemeinsame Lektüre zum Preis einer Inspektion.

Die Autorin inspizieren

Der BABOK stellt die Regel in einem Satz auf: jedes Review richtet sich auf ein Arbeitsergebnis und nicht auf die Fähigkeiten oder Handlungen der Beteiligten (§10.37.2). Eine Inspektion, die zur Beurteilung einer Person wird, hört auf, Fehler hervorzubringen, weil niemand mehr welche meldet.

Die vorgesetzte Person im Raum

Der BABOK schreibt, dass der Moderator, wenn eine vorgesetzte oder verantwortliche Person Reviewer ist, darauf achtet, die Offenheit der übrigen Beteiligten nicht zu beeinträchtigen und die Entscheidungen des Teams nicht unangemessen zu beeinflussen (§10.37.3.3). Die Formulierung ist vorsichtig, und sie bleibt es hier: es ist eine Wachsamkeit des Moderators, und er hat zu entscheiden, ob die Anwesenheit tragbar ist.

Zu viele Seiten pro Stunde

Das Tempo ist der Parameter, der die Ausbeute lautlos zerstört. Eine Inspektion, die dreissig Seiten in zwei Stunden verschlingt, hat gekostet, was eine Inspektion kostet, und geliefert, was ein Korrekturlesen liefert.

Die Nachverfolgung überspringen

Die einzige Operation, die die Technik auszeichnet, ist die, die unter Termindruck fällt.

Die Autorin präsentieren lassen

Wiegers eröffnet sein Kapitel mit einer Organisation, die ihren Walkthrough-Prozess in einen Inspektionsprozess verwandelt hatte, indem sie überall das Wort Walkthrough durch das Wort Inspektion ersetzte. Der Leser, die individuelle Vorbereitung, die Prüfliste und die Nachverfolgung sind das, was das Wort bezeichnet. Ohne sie bezeichnet es nichts.

KI-Überlegungen

Die Inspektion trennt Finden von Entscheiden, und diese Trennung sagt, wo ein Sprachmodell nützt und wo es nicht hineinkommt.

Die individuelle Vorbereitung

Sie ist die Operation, die die KI am stärksten verändert. Ein Modell, das eine Spezifikation gegen eine Fehlerprüfliste liest, leistet genau die mechanische Hälfte dieser Arbeit: innere Widersprüche, ohne Definition verwendete Begriffe, eine zweimal mit zwei verschiedenen Schwellen genannte Regel, ein fehlender Grenzfall, eine Abbildung, die der Text nicht abdeckt. Es bringt Fehlerkandidaten hervor, für nichts, bevor eine menschliche Stunde ausgegeben ist. Der Inspektor wendet seine Lektüre dann dem zu, was nur eine Leserin des Fachs sehen kann.

Die Prüfliste aus der Historie bauen

Eine Inspektion hinterlässt einen Bestand protokollierter Fehler, und das ist der einzige Bestand, über den eine Organisation verfügt, um zu wissen, was sie falsch schreibt. Ein Modell gruppiert die vergangenen Protokolle, führt die unterschiedlichen Formulierungen desselben Fehlers zusammen und bringt hervor, was wiederkehrt, und das ist die Arbeit, die zwischen zwei Inspektionen niemand von Hand macht.

Konsolidieren und entdoppeln

Mehrere Inspektoren protokollieren denselben Fehler mit verschiedenen Worten, und diese Zeilen zusammenzuführen ist eine undankbare Arbeit, die die Sitzung von Hand erledigt.

Die Nachverfolgung instrumentieren

Das überarbeitete Produkt Zeile für Zeile mit dem Fehlerprotokoll zu vergleichen, um zu zeigen, dass jedem protokollierten Fehler eine Änderung gegenübersteht, ist eine mechanische Prüfung. Es ist auch die Operation, die Teams überspringen, weil sie mühsam ist, was sie zur besten Kandidatin der Technik macht.

Was ein Modell nicht kann

Die Produktbeurteilung ist das Urteil einer Gruppe qualifizierter Leute. Der Schweregrad eines Fehlers ist kontextabhängig, und Wiegers sagt es: ob ein Fehler schwer oder leicht ist, hängt von seinem Kontext ab und von der Wirkung, die er hätte, bliebe er unkorrigiert; ein Modell weiss nicht, was das Produkt steuert. Ein von einem Modell erzeugter Fehlerkandidat bleibt ein Kandidat, und er geht in die Vorbereitung ein, nie unmittelbar ins Protokoll: bei einer Fachregel, einem BVG-Umwandlungssatz oder einem Koordinationsabzug ist das Modell dort selbstsicher und falsch, wo der Leser am wenigsten gerüstet ist, ihm zu widersprechen. Ein Modell kann auch nicht Moderator sein und nicht die Eigenschaft liefern, auf der die Technik gebaut ist: eine Prüfung durch jemanden, der nicht die Autorin ist und der dafür einsteht, sie durchgeführt zu haben.

Der Datenschutz

Eine Spezifikation zur Leistungsberechnung trägt interne Regeln und oft Personendaten. Sie geht nicht an einen Dienst, der sich an dem trainiert, was man ihm gibt, und die Regel der Organisation, welches Modell, welche Daten, wo gehostet, wird festgelegt, bevor das Produkt zu den Inspektoren geht.

Beispiele

Was eine Inspektion hervorbringt, ist ein Fehlerprotokoll, dessen letzte Spalte sich schliesst.

Einundvierzig Fehler auf den zwölf inspizierten Seiten, also 3,4 Fehler pro Seite. Zwölf Seiten in drei Stunden Sitzung durchgegangen, also vier Seiten pro Stunde. Diese beiden Zahlen sind das, was keines der sechs anderen Reviews des BABOK liefern kann.

Die Inspektion endet, wenn die Spalte «Verifikation» auf jeder der 41 Zeilen geschlossen ist. Die Festlegung wurde in der Sitzung getroffen, Zeile für Zeile, und sie ist nicht für alle dieselbe.

Visualisierungen

Das Formalitätsspektrum ist ein räumlicher Gegenstand: sieben Typen auf einer Achse, drei Markierungen pro Feld. Die ersten beiden Tore trennen die Inspektion nicht von ihren beiden formalen Nachbarn, und das dritte stellt sie allein. Eine Achse und Positionen lassen sich nicht in Zellen wiedergeben.

Der Prozess der Inspektion besteht aus Kästen und Pfeilen, und einer dieser Pfeile kehrt dorthin zurück, woher er kam: die Nachverfolgung gibt das Arbeitsergebnis an das Team zurück oder gibt es frei, je nach der in der Sitzung getroffenen Festlegung. Eine Schleife lässt sich weder in Prosa noch in einer Tabelle wiedergeben. Die Beschriftung dieses Pfeils trägt die drei möglichen Festlegungen, und das ist die einzige Art zu zeigen, dass die Nachverfolgung eine Entscheidung ist.

Das Fehlerprotokoll lässt sich in Zellen wiedergeben, in Zeilen und Spalten. Seine letzte Spalte ist das, was die Technik hervorbringt und was kein anderes Review der Familie hervorbringt: die sechs anderen liefern Kommentare, einen konsolidierten Satz von Funden, eine Auflösung, ein annotiertes Exemplar oder gar nichts. Die Wahl zwischen den sieben gehört zur Technik der Reviews.

Aufwand

Werkzeuge

Die Inspektion verlangt zuerst ein verortbares Arbeitsergebnis. Ein Fehler wird an einer Stelle protokolliert, und ein Dokument ohne Zeilen- oder Seitennummern gibt diese Stelle nicht her: der paginierte Export, oder das Werkzeug, das stabile Anker bereitstellt, ist die erste Bedingung der Technik. Er ist auch das, was der Nachverfolgung erlaubt, wiederzufinden, was sie verifizieren muss.

Sie verlangt sodann eine Fehlerprüfliste, die eine Tabellenkalkulation zu tragen genügt, und ein Fehlerprotokoll mit Fundstelle, Fehler, Schweregrad, Nacharbeit und Verifikation. Eine geteilte Tabellenkalkulation leistet auch das. Was die Technik verlässt, eine offene Frage, eine anderswo zu treffende Entscheidung, gehört ins Item Tracking.

Sie verlangt schliesslich etwas zum Zählen. Die Messwerte der Inspektion berechnen sich aus dem Protokoll und der Anwesenheitsliste, und eine Tabellenkalkulation hält sie, solange es wenige sind. Sie zählen nur im Vergleich, also wird das Format bei der ersten Inspektion festgelegt und bewegt sich nicht mehr.

Die spezialisierten Werkzeuge der Inspektion sind die der dokumentierten Reviews. Eine Review-Plattform, ein Kommentarstrang eines Pull Request, der Revisionsstrang eines Dokuments: alle drei tragen dasselbe und geben der Inspektion dasselbe zurück. Sie liefern stabile Anker auf Zeilenebene, und sie liefern sie ohne paginierten Export. Sie hängen den Fehlerstrang an die Stelle des Fehlers statt an eine Zeile einer Tabellenkalkulation: die Auseinandersetzung um Fehler 12 wird neben dem Text gelesen, den sie bestreitet, und die Autorin, die nacharbeitet, sieht, was der Inspektor sah. Und sie tragen einen Verifikationsstatus, der sich zuweisen, datieren und schliessen lässt, was das Unterscheidungsmerkmal der Technik als Werkzeuganforderung ausgedrückt ist: unter erneuter Inspektion bleibt der Strang bis zur zweiten Sitzung offen; unter Verifikation durch eine Person trägt er den Namen des Verifizierenden und das Datum seiner Freigabe; unter unverändert angenommen schliesst er sich über der Änderung der Autorin.

Was diese Werkzeuge nicht liefern, ist das Tempo. Eine Plattform nimmt dreissig Seiten in zwei Stunden entgegen, und es ist am Moderator, das Material zu teilen. Auch die Messtabelle bleibt daneben zu führen: ein Kommentarstrang kann sagen, dass ein Fehler geschlossen ist, er kann nicht sagen, wie viele Fehler pro Seite die Organisation findet.

Auf Distanz hält die Technik unter zwei Bedingungen: der Leser teilt seinen Bildschirm und geht in kleinen Stücken im vereinbarten Tempo vor, und das Protokoll ist während der Sitzung für alle sichtbar, so dass jeder sieht, was der Schreiber von dem geschrieben hat, was er gesagt hat. Nichts an der Inspektion hängt an einem physischen Artefakt.

Quellen

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.37 Reviews (§10.37.2, der Gegenstand des Reviews; §10.37.3.1, die sieben Ziele; §10.37.3.2, die sieben Typen und die Definition der Inspektion; §10.37.3.3, die Durchführung des Reviews; Tabelle 10.37.1, die Rollen; §10.37.4, Stärken und Grenzen).
• Karl E. Wiegers, Peer Reviews in Software: A Practical Guide, Addison-Wesley, 2002, Kapitel 3, «Peer Review Formality Spectrum» (Tabelle 3-1, Aktivitäten nach Review-Typ; Tabelle 3-2, verglichene Merkmale; Tabelle 3-3, Ziele und Methoden; die Merkmale der formellsten Reviews, die Rollen, der Leser, die Festlegung der Verifikation und die Wirksamkeitsdaten).
• M. E. Fagan, «Design and code inspections to reduce errors in program development», IBM Systems Journal 15(3), 1976, 182-211 (die sechs Operationen, die Nacharbeit und die Nachverfolgung).
• IEEE, IEEE Std 1028-2008, IEEE Standard for Software Reviews and Audits (die Definition der Inspektion, ihre fünf Rollen und der Ausschluss der Autorin).
• ISO/IEC, ISO/IEC 20246:2017, Software and systems engineering: Work product reviews (die Inspektion unter den rigorosesten Review-Typen der Norm).