Einen Projektplan erstellenIn Kapitel 5 haben wir den Qualitätsbegriff eingeführt und die relevanten Qualitätsmerkmale der Software und des Entwicklungsprozesses vorgestellt. Gute Qualität entsteht aber erfahrungsgemäß nicht ohne spezielle Anstrengungen und Vorkehrungen; alle Aktivitäten, die diesem Ziel dienen, werden mit dem Begriff »Qualitätssicherung« (quality assurance) bezeichnet.
Die Qualitätsbeurteilung passt gleichermaßen in dieses Kapitel wie in das folgende Kapitel 14 (Metriken und Bewertungen). Wir behandeln sie dort in Abschnitt 14.3.2.
Die Software-Qualitätssicherung hat die Aufgabe, alle qualitätsrelevanten Aktivitäten und Prozesse zu gestalten, zu organisieren, abzustimmen und zu überwachen. Im IEEE-Standard finden wir folgende Definitionen:
software quality assurance — See: quality assurance.
quality assurance — (1) A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements.
(2) A set of activities designed to evaluate the process by which products are developed or manufactured.
IEEE Std 610.12 (1990)
Diese etwas wolkige Definition entspricht dem üblichen Verständnis von Software-Qualitätssicherung: Alles, was zu tun ist, damit man der Qualität eines Produkts trauen kann, gehört dazu. Die Bedeutung (2) wird dagegen heute kaum noch verwendet, denn die Prozessbewertung ist zu einem eigenen, von der Qualitätssicherung getrennten Thema geworden (siehe dazu Kap. 11).
Die Doppeldeutigkeit der Definition (1) ist sinnvoll: Damit man dem Produkt traut, kann man es gut machen oder nachweisen, dass es gut ist. Beides ist Qualitätssicherung.
Software-Qualitätssicherung hat unmittelbar zum Ziel, das Vertrauen in eine Software zu erhöhen; mittelbar wirkt sie sich, wie jede angekündigte Prüfung, auf das Qualitätsniveau aus, steigert also die Fähigkeit, qualitativ hochwertige Produkte zu entwickeln.
Es gibt viele Maßnahmen, die nach allen Erfahrungen dazu beitragen, die Qualität zu heben (oder genauer: Qualitätsmängeln vorzubeugen). Die folgende Liste nennt einige Stichwörter, sie ist natürlich weit von jeder Vollständigkeit entfernt.
Einen Projektplan erstellen
Dabei nicht nur die Konstruktion, sondern auch Reviews, Tests und andere Prüfungen einplanen
Die Dokumentation planen
Identifikation und Verwaltung der Arbeitsergebnisse regeln (Konfigurationsverwaltung)
Aufgaben erst stellen, dann lösen
Resultate erst prüfen, dann verwenden
Für alle wiederkehrenden Arbeiten Checklisten verwenden
Hohe Programmiersprachen einsetzen
Muster (Templates) und Codierrichtlinien vorgeben
Fehler und Änderungswünsche kontrolliert bearbeiten
Fehlerstatistiken führen
Jedes abgeschlossene Projekt kritisch analysieren
In der Praxis werden solche Regeln oft durch Richtlinien kodifiziert. Fragt man die Verantwortlichen, ob dieses oder jenes sichergestellt sei, so wird auf diese Regeln verwiesen, anscheinend im Glauben, dass sie auch eingehalten würden, obwohl das oft nicht kontrolliert wird. Die Abbildung 13–1 zeigt, wie man der segensreichen Wirkung der Richtlinien blind vertraut.
Die Erfahrung zeigt jedoch, dass Regeln ohne Kontrollen wirkungslos sind. Der Grund ist einfach: Selbst wenn sich eine Mehrheit der Entwickler zunächst nach den Regeln richtet, bleibt ihr Effekt gering, solange sich einige nicht daran halten. Was nützt eine Fehlerstatistik, die unvollständig ist, was nützt die Prüfung einiger Ergebnisse, wenn der Abnehmer damit rechnen muss, auch ungeprüfte Module zu bekommen? Darum werden sich auch die Gutwilligen bald den Mehraufwand sparen, den systematisches Vorgehen kostet; die Richtlinien sind damit wirkungs- und wertlos geworden. Als einer der wichtigsten Effekte von Reviews wird immer wieder genannt, dass die Richtlinien gelebt werden. Man kann daraus schließen, dass sie vorher ohne Überprüfung eben nicht gelebt wurden.
Abb. 13–1 Befolgung / Überprüfung der Richtlinien (aus Dünki, Galasso, 1987, S. 37)
Entgegen einem weitverbreiteten Vorurteil bedeutet Software-Qualitätssicherung nicht primär Prüfung. Organisatorische und konstruktive Maßnahmen sind wesentlich wichtiger, sie werden durch analytische Maßnahmen ergänzt (siehe Abb. 13–2).
Abb. 13–2 Gliederung der Software-Qualitätssicherung
Diese Maßnahmen zielen darauf ab, die Entwicklung und die Qualitätssicherung systematisch durchzuführen. Dazu gehören alle Formen der Planung und der Organisation, beispielsweise die gründliche Zeitplanung, die auch Prüfungen und Korrekturen berücksichtigt, und die Festlegung der Verantwortlichkeiten für Prüfungen.
Konstruktive Maßnahmen
Wie schon beim Cleanroom Development (Abschnitt 10.5) festgestellt wurde, ist es viel besser, Software-Mängeln konsequent aus dem Weg zu gehen, als sie leichtfertig zu verursachen, später nach ihnen zu suchen und sie, soweit sie entdeckt werden, zu beheben. Konstruktive Maßnahmen zielen darauf ab, Probleme zu vermeiden. Hier geht es also um den Einsatz geeigneter Methoden, Sprachen und Werkzeuge. Aber auch die Schulung von Mitarbeitern oder die Verwendung eines geeigneten Prozessmodells sind konstruktive Maßnahmen.
Analytische Maßnahmen
Darunter fallen alle Arten der Software-Prüfung. Mit ihnen verfolgen wir das Ziel, Fehler und Mängel in den Arbeitsergebnissen zu erkennen. Die wichtigsten Verfahren dieser Kategorie sind methodisch durchgeführte Reviews und alle Arten des Tests.
Alle Aktivitäten der Qualitätssicherung werden definierten Rollen im Projekt (z. B. dem Tester) und in der Entwicklungsorganisation zugeordnet. Dabei bleibt zunächst offen, ob die Rolle einfach oder mehrfach besetzt ist; auch kann eine Person mehrere Rollen übernehmen. Eine besondere Stellung hat der QS-Ingenieur. (Die Bezeichnung dieser Rolle ist nicht einheitlich!) Der QS-Ingenieur ist insbesondere für die organisatorischen Qualitätssicherungsmaßnahmen verantwortlich. Zu den Aufgaben dieser Rolle zählen:
Erstellen von Richtlinien, Musterdokumenten, Checklisten usw.
Auswählen und Einführen von Werkzeugen
Schulung und Beratung der Projektmitarbeiter in Methoden und Techniken der Qualitätssicherung
Aufstellen von Plänen, insbesondere von Prüfplänen
Mitwirkung oder Teilnahme an Prüfungen, vor allem an den formalen Prüfungen, die Meilensteinen zugeordnet sind
Überwachen aller Maßnahmen, die im Interesse höherer Qualität durch Pläne, Richtlinien usw. vorgesehen sind
Der QS-Ingenieur sollte nicht dem Projektleiter unterstellt sein. Die Stellungnahmen des QS-Ingenieurs müssen der Ebene über dem Projektleiter zugehen. Es ist allerdings fraglich, ob der QS-Ingenieur bei der Auslieferung ein Vetorecht haben sollte, denn die Projektverantwortung sollte eindeutig beim Projektleiter liegen.
Prüfungen haben den Zweck, die Qualität eines Prüflings festzustellen, insbesondere, ob er im Sinne der Anforderungen fehlerfrei ist. Die Begriffe »Qualität« (siehe Abschnitt 5.1) und »Fehler« (siehe Abschnitt 13.3.1) sind darum vom Begriff der Prüfung nicht zu trennen.
Mit Software-Prüfung ist hier eine systematische Suche nach Fehlern in der Software gemeint. Vor allem dort, wo aus gutem Grund nur von Programmen, nicht von Software gesprochen wird, besteht oft nicht der Wunsch oder die Möglichkeit, systematisch zu prüfen. Diese Entscheidung ist nicht mit quasimoralischen Argumenten zu werten (im Sinne eines Ehrenkodex oder einer Benimmregel wie der, Kartoffeln nicht mit dem Messer zu schneiden), sondern nur unter dem Aspekt, dass Software, die wirklich gebraucht wird, weniger Probleme und damit letztlich geringere Kosten verursacht, wenn sie geprüft und verbessert wurde. Die Prüfung der Software ist also – wie das ganze Software Engineering – nicht Selbstzweck, sondern wirtschaftlich geboten.
Bevor wir den Fehlerbegriff näher definieren, wollen wir den Nutzen und die Wirkungen von Prüfungen am Beispiel der Schule herausarbeiten.
Anders als die expliziten, aber eher abstrakten Lehrpläne liefern Prüfungen eine implizite, sehr konkrete Definition der Leistungskriterien. Sie sagen damit den Schülern, welchen Stoff sie beherrschen sollten.
Prüfungen zeigen kollektive und individuelle Schwächen und liefern den Lehrern eine Rückmeldung über den Erfolg ihres Unterrichts.
Direkt erhöhen Prüfungen die Leistungen der Prüflinge nur in Ausnahmefällen (beispielsweise, wenn eine Aufgabe einen Aha-Effekt auslöst).
Prüfungen schaffen die Möglichkeit, die extrem guten und die extrem schlechten Kandidaten zu erkennen; dann können die einen belohnt, die anderen gefördert oder in aussichtslosen Fällen ausgeschlossen werden. Durch eine Belohnung werden die Guten angespornt. Die Förderung der Schlechteren verringert die Gefahr, dass diese den Anschluss verlieren. Der Ausschluss als Ultima Ratio wirkt einerseits als Drohung, gibt andererseits den Lehrern ein Mittel, um zu verhindern, dass die Arbeit durch einzelne Schüler blockiert wird.
Die Erwartung einer Prüfung beeinflusst das Verhalten der Schüler: Sie bemühen sich um besseres Verständnis, damit sie bessere Prüfungsresultate erzielen. Auf diesem Wege erhöht die Prüfung indirekt also auch die Leistung. (Das bestätigen auch alle Erfahrungen mit ungeprüften Lehrveranstaltungen.)
Über die Prüfungsergebnisse werden auch die Lehrer – vor allem durch die Aufmerksamkeit der Schüler und ihrer Eltern – laufend geprüft, sodass ein grundsätzlicher Konflikt mit den Regeln des Unterrichts nicht unbemerkt bleibt.
Diese Beobachtungen lassen sich weitgehend auf das Thema »Prüfung von Software« übertragen; dabei ist die Leistung der Schüler durch die Qualität der Software zu ersetzen.
Prüfungen liefern – als Ergänzung der oft unzureichenden Spezifikation – implizit eine simple Definition der Qualitätskriterien. Sie zeigen damit den Entwicklern, welchen konkreten Anforderungen ihre Produkte genügen sollen. Darum spielt der Test beim Extreme Programming (Abschnitt 10.6.4) eine besonders wichtige Rolle.
Prüfungen zeigen kollektive und individuelle Schwächen der Prüflinge (also der Dokumente, Programme usw.). Sie geben damit den Entwicklern einen Eindruck von der Qualität ihrer Arbeit insgesamt, also Hinweise für das Software Engineering und für die Verbesserung der einzelnen Komponenten (auf Programmebene für die Fehlerbehebung).
Direkt erhöhen sie die Qualität der Prüflinge nicht.
Prüfungen machen die extrem guten und die extrem schlechten Prüflinge sichtbar; dann können die einen als Vorbilder gezeigt, die anderen verbessert oder in aussichtslosen Fällen verworfen werden. Eine solche Ablehnung kann verhindern, dass ein ganzes System durch eine unzureichende Komponente unbrauchbar wird.
Die Erwartung einer Prüfung beeinflusst das Verhalten der Entwickler: Sie bemühen sich, Software zu liefern, die gute Prüfresultate erzielt. Auf diesem Wege erhöht die Prüfung die Qualität des Produkts.
Durch Audits kann und muss überprüft werden, ob die festgelegten Regeln zur Durchführung des Projekts auch eingehalten werden. Damit wird auch die Qualität des Managements geprüft.
ISO 9000 (2005), die Norm, in der die Grundlagen und Begriffe für Qualitätsmanagementsysteme beschrieben sind, liefert uns Definitionen für Fehler, Mangel und Anforderung. Eine Anforderung ist definiert als Erfordernis oder Erwartung, das oder die festgelegt, üblicherweise vorausgesetzt oder verpflichtend ist; eine Anforderung muss demnach nicht unbedingt in der Spezifikation stehen. Ist irgendeine Anforderung durch das Produkt (die Software) nicht erfüllt, dann liegt ein Fehler vor. Ein Mangel ist die Nichterfüllung einer Anforderung in Bezug auf einen beabsichtigten oder festgelegten Gebrauch.
Der Unterschied zwischen »Fehler« und »Mangel« liegt also in der Perspektive: Geht es beim Fehler nur um die Frage, ob das Produkt die Anforderungen erfüllt, so schließt die Einstufung eines Fehlers als Mangel die Feststellung ein, dass der Gebrauch des Produkts beeinträchtigt ist. Wenn ein Fehler die Verwendbarkeit nicht beeinträchtigt, liegt kein Mangel vor. Ein Mangel kann juristische Folgen haben (z. B. die Forderung nach Schadensersatz).
Umgangssprachlich wird kaum zwischen Fehler und Mangel unterschieden; da jeder Mangel auch ein Fehler ist, reicht es aus, wenn wir nachfolgend von Fehlern sprechen.
Software Engineering zielt darauf ab, Fehler zu vermeiden oder, wo dies nicht gelungen ist, sie so früh wie möglich durch Prüfungen zu erkennen und zu beseitigen.
Die Suche nach Fehlern wäre einfacher, wenn wir Genaues über sie wüssten. Das ist natürlich nicht der Fall, es sei denn, wir haben sie selbst bewusst eingebaut (was man beim sogenannten »error seeding« tatsächlich tut, um die Wirksamkeit der Fehlersuche festzustellen). Es gehört also zum Wesen der Fehler, dass wir sie suchen müssen, ohne Näheres über sie zu wissen. Insbesondere wissen wir auch nicht, ob es in irgendeinem betrachteten Ausschnitt der Software überhaupt einen Fehler gibt.
Wenigstens die letzte Frage wäre in Bezug auf ein Programm grundsätzlich leicht zu beantworten, wenn wir überprüfen könnten, dass es immer genau das Richtige tut. Dazu müssten zwei Bedingungen erfüllt sein:
1. Die Eigenschaften des Programms sind – i. Allg. durch die Spezifikation – eindeutig und vollständig festgelegt.
2. Die Eigenschaften lassen sich durch Prüfungen eindeutig und vollständig feststellen.
Die erste Bedingung ist in der Praxis so gut wie nie erfüllt. Sie kann jedoch für gewisse Aspekte, z. B. für die Funktionalität, bei manchen Systemen erfüllt werden. Dagegen stellen uns die meisten nichtfunktionalen Anforderungen vor unlösbare Probleme.
Die zweite Bedingung ist (außer bei einigen extrem primitiven Beispielen) nicht zu erfüllen, weil sich Software nicht stetig verhält und die Zahl der möglichen Zustände praktisch unendlich groß ist (Abschnitt 2.3.2). Vor allem aus diesem Grunde kann keine Prüfung zu einem Korrektheitsbeweis führen.
Wir suchen also bei der Prüfung nach Fehlern – ohne Chance, den Erfolg zu erzwingen. Auch hier gilt das Prinzip der Kostenminimierung, d. h., wir wollen mit minimalem Aufwand möglichst viele Fehler finden. Genau betrachtet ist das Kriterium nicht die Zahl der gefundenen Fehler, sondern der vermiedene Schaden, das Schadenspotenzial. Wenn eine Prüfung einen einzigen sehr kritischen Fehler aufdeckt, ist sie wirksamer als eine, die viele harmlose Fehler zeigt.
Jede Suche geht von Annahmen über das Gesuchte aus, jeder Prüfung liegt also eine Fehlertheorie zu Grunde. Wer kontrolliert, ob Schleifenrümpfe einmal zu oft oder einmal zu wenig durchlaufen werden, hat die Theorie im Kopf, dass diese Fehler (off by 1 error) mit einiger Wahrscheinlichkeit gemacht werden. Wer im Test (absichtlich!) ungültige Eingaben macht, rechnet mit Mängeln in der Fehlerbehandlung des Programms. Aber unsere Fantasie reicht nicht aus: Wenn sich ein Fehler besonders hartnäckig gegen seine Enttarnung gewehrt hat, bevor er uns endlich ins Netz geht, stellen wir meist fest, dass wir uns diesen Fehler einfach nicht haben vorstellen können.
Alle Prüfungen folgen grundsätzlich dem gleichen Schema. Neben dem eigentlichen Weg von einer Vorgabe zum Resultat (der Produktion) wird ein zweiter Weg durchlaufen, auf dem Anforderungen an das Resultat ausgewählt oder festgestellt werden (siehe Abb. 13–3). Auf diese Weise ist es möglich, das Resultat mit den Anforderungen an das Resultat zu vergleichen. Eine dabei festgestellte Diskrepanz weist auf einen Fehler hin.
Abb. 13–3 Grundprinzip der Prüfung
Die Abbildung zeigt auch die Achillesferse jeder Prüfung: Was nicht in den parallelen Pfaden liegt, wird nicht geprüft. Das ist zum einen die Vorgabe, zum anderen der Vergleichsmechanismus. Der Vergleich gehört nicht zum zu entwickelnden Produkt und lässt sich in der Regel mit entsprechendem Aufwand (also durch konstruktive Qualitätssicherung) zuverlässig realisieren. Die Vorgabe aber, d. h. die Spezifikation, ist in aller Regel viel zu komplex, als dass wir uns darauf verlassen können, ihren Inhalt zu überblicken und zu verstehen; aber natürlich können wir sie nicht reduzieren oder vereinfachen. Nur die Klienten können (vielleicht!) erkennen, dass ihre Anforderungen nicht richtig oder nicht vollständig dargestellt sind. Hier zeichnet sich die große Bedeutung von Analyse und Spezifikation ab (siehe Kap. 16).
Boehm (1979) unterscheidet zwei Arten von Prüfung:
Verification: to establish the truth of the correspondence between a software product and its specification. »Am I building the product right?«
Validation: to establish the fitness or worth of a software product for its operational mission. »Am I building the right product?«
Die Verifikation kontrolliert also, ob ein Verfahrensschritt richtig ausgeführt wurde; die Validierung beantwortet die Frage, ob das Resultat, unser Produkt, den Erwartungen der Klienten entspricht. Man kann das mit dem Versuch vergleichen, ein technisches Spielzeug, z. B. einen ferngelenkten Hubschrauber, nach einer Anleitung zusammenzusetzen und in Betrieb zu nehmen. Wenn er sich am Ende in die Luft erhebt und den Steuerbefehlen gehorcht, war der Zusammenbau erfolgreich: Er ist validiert, denn das Richtige ist entstanden. Aber zwischendurch entstehen oft Unsicherheiten; da das Zwischenresultat, der unvollständige Helikopter, nicht erprobt werden kann, bleibt uns nur die Möglichkeit, jeden Schritt genau zu überprüfen. (Habe ich den Akku so mit den Klemmen der Elektronik verbunden, wie es die Anleitung beschreibt?) Das ist Verifikation.
Für die Software-Entwicklung bedeutet das: Wir verifizieren, wenn wir prüfen, ob ein Schritt im Entwicklungsprozess, beispielsweise die Implementierung einer Klasse, den Regeln (der Programmierrichtlinie) folgt und das Ergebnis (der Code) konsistent mit den Vorgaben (der Beschreibung im Entwurf) ist.
Wichtiger ist zweifellos die Validierung; sie ist aber erst möglich, wenn das Produkt (oder ein selbständiges Teilprodukt oder ein Prototyp) fertig ist. Bis dahin können wir nur verifizieren.
Oft werden die Begriffe aber weniger präzise verwendet, als Boehm es vorschlägt. Von Verifikation spricht man vor allem dann, wenn mit formalen Techniken bewiesen wird, dass ein Programm seine (formale) Spezifikation korrekt implementiert (siehe Abschnitt 16.6.1).
Eine Welle aus Stahl, die Teil einer Maschine werden soll, wird durch eine technische Zeichnung spezifiziert. Der Dreher bearbeitet das Material gemäß Zeichnung. Ein Prüfer entnimmt der Zeichnung die Maße der Welle und ihre Toleranzen. Er prüft, ob die Maße der fertigen Welle im Rahmen der Toleranzen liegen. Ist das nicht der Fall, so liegt ein Fehler vor, das Prüfergebnis ist positiv (!). (Man vergleiche die ähnliche Terminologie in der Medizin, wo man von einem positiven oder negativen Befund spricht.)
Grundsätzlich ist bei positiven Ergebnissen nicht a priori klar, wo der Fehler liegt. In den meisten Fällen ist tatsächlich das Produkt fehlerhaft. Es kann aber auch sein, dass sich der Prüfer geirrt hat, dass ihm die falsche Vorgabe vorgelegen hatte (im Beispiel eine falsche Konstruktionszeichnung) oder dass er die falsche Welle geprüft hat. Er kann auch bei der Prüfung den Wert falsch abgelesen haben. Alle diese Fälle sind, wie man sagt, falsch positiv.
Auch bei der Software-Prüfung kann es – aus ganz ähnlichen Gründen – zu falsch positiven »Diagnosen« kommen. Der Prüfer versteht die Spezifikation falsch, oder er arbeitet mit einer obsoleten Gestaltungsrichtlinie.
Falsch positive Resultate machen unnötig Arbeit, sind aber sonst kein Problem, eine Nachprüfung zeigt, dass das Produkt in Ordnung ist. Viel schlimmer sind falsch negative Resultate, bei denen ein tatsächlich vorhandener Fehler übersehen wird, obwohl er eigentlich auffallen müsste. Daher ist es bei jeder Prüfung weit wichtiger, falsch negative als falsch positive Resultate zu vermeiden.
Im Beispiel der Prüfung einer Welle kann es zu einem falsch negativen Resultat kommen, wenn der Prüfer eine fehlerhafte Welle gegen eine falsche Zeichnung prüft, die der Welle zufällig gerade entspricht. Das ist natürlich sehr unwahrscheinlich. Viel öfter kommt es vor, dass es auf einer Zeichnung schlecht lesbare Zahlen gibt, die sowohl der Dreher als auch der Prüfer falsch, aber beide gleich falsch, lesen. In diesem Falle sind falsch negative Resultate sehr wahrscheinlich. In der Software ist das offensichtlich der Fall, wenn der Entwickler seine Produkte, z. B. den Programmcode, selbst prüft. Alle Missverständnisse, die Fehler im Code verursacht haben, liegen auch der Prüfung zu Grunde, werden also nicht aufgedeckt.
Falsch negative Prüfresultate sind natürlich nicht die einzige Ursache für unerkannte Fehler. Wo nicht gesucht wird, wird auch nicht gefunden. Das ist der Fall, wenn die Zeichnung der Welle eine bestimmte Materialhärte vorschreibt, die Härte aber nicht geprüft wird, oder wenn ein Programm mit einem bestimmten Hauptspeicherausbau laufen soll, aber nie auf einem entsprechenden Rechner getestet wurde.
Wir können daraus Feststellungen ableiten, die für alle Prüfungen gelten:
Alles, was gefordert wurde, muss auch geprüft werden, sonst ist unsicher, ob die Anforderungen verstanden und umgesetzt wurden.
In jeder Prüfung gibt es zwei Pfade von der Vorgabe zum Resultat, die eigentliche Produktion und den Prüfpfad.
Die Prüfung kann nur Fehler aufdecken, die auf einem der beiden getrennten Pfade liegen, aber keine Fehler, die in den gemeinsamen Teilen liegen, also in der gemeinsamen Vorgabe oder im Vergleich zwischen Resultaten und Anforderungen an die Resultate. Diese beiden Teile sind also besonders kritisch, ihre Qualität muss auf andere Weise sichergestellt werden.
Werden Fehler entdeckt, so ist das Prüfresultat positiv. Liegt der Fehler (nur) im Prüfzweig, so ist es falsch positiv.
Werden Fehler nicht entdeckt, so wurde entweder nicht nach ihnen gesucht, oder das Prüfresultat war falsch negativ. Falsch negative Resultate entstehen entweder durch eine zufällige Kompensation mehrerer Fehler im produktiven Pfad und im Prüfpfad oder (sehr viel öfter) durch Fehler in den gemeinsamen Teilen, also in der Vorgabe und im Vergleich. Eine weitere wichtige Ursache für falsch negative Resultate ist die allzu großzügige Interpretation negativer Resultate. Beispielsweise wird aus einem oberflächlichen Test ohne Befund der Schluss gezogen, der Prüfling sei in Ordnung. Im (wahrscheinlichen) Fall, dass Fehler übersehen wurden, ist dieses Resultat falsch negativ.
Falsch negative Resultate sind schlimmer als keine Resultate: Sie vermitteln unbegründetes Vertrauen in ein Produkt und erschweren die Fehlersuche, wenn irgendwann auffällt, dass es einen Fehler gibt. Die Fehlerursache wird dann besonders leicht übersehen, weil jeder denkt: »Das haben wir ja schon geprüft!«
Wie die Abbildung 13–2 zeigt, kann Software ohne oder mit Hilfe eines Rechners geprüft werden.
Prüfung ohne Rechner (»nichtmechanische Prüfung«)
Die Arbeitsergebnisse werden von Experten geprüft. Gängige Verfahren sind Durchsicht, Inspektion (Review) oder Walkthrough. Wo diese Prüfverfahren noch nicht angewandt werden, ist ihre Einführung die einfachste und billigste Möglichkeit, Fortschritte im Software Engineering zu erzielen, weil dadurch nicht nur die Ergebnisse geprüft werden, sondern auch das Wissen unter den Mitarbeitern verbreitet wird und ein gemeinsames Qualitätsverständnis im Projektteam entsteht. Wir behandeln diese Verfahren in Abschnitt 13.4.5.
Prüfung mit Rechner (»mechanische Prüfung«)
Hierzu zählen alle Testverfahren, aber auch die statische Analyse mit Hilfe spezieller Werkzeuge (z. B. CASE-Tools, siehe Abschnitt 15.2). Die Methoden zum Test werden im Kapitel 19 behandelt.
Es ist offensichtlich, dass nur Dokumente mit formalem Charakter (z. B. eine formale Spezifikation oder Programmcode) mit dem Rechner geprüft werden können. Da bei üblicher Entwicklung erst relativ spät formale Dokumente entstehen, ist die Prüfung durch Inspektion, also ohne Rechner, bei weitem wichtiger.
Für alle Software-Prüfungen gelten die folgenden Prinzipien:
Nur gegen Vorgaben prüfen! Wir benötigen mindestens die Anforderungen oder Vergleichsresultate. Um die Anforderungen selbst zu prüfen, brauchen wir die Klienten, von denen die Anforderungen kommen.
Prüfungen planen! Prüfungen benötigen Zeit und Ressourcen.
Prüfverfahren präzise definieren! Nur dann liefern sie reproduzierbare Ergebnisse! Reproduzierbarkeit ist bei subjektiven Verfahren (z. B. bei Reviews) natürlich nicht absolut erreichbar, aber auch nicht so schlecht, wie viele Leute befürchten.
Prüfergebnisse dokumentieren! Für die rasch wachsenden Datenmengen ist eine geordnete Ablage in der Konfigurationsverwaltung anzulegen.
Beim Prüfen erkannte Fehler nach der Prüfung beheben! Die Korrektur ist eine notwendige Konsequenz, aber kein Teil der Prüfung.
Da eine Trennung von Prüfung und Korrektur in der Praxis nicht allgemein üblich ist, betonen wir sie hier ausdrücklich. Auf den ersten Blick scheint es allzu umständlich, die Prüfung nach der Erkennung eines Fehlers fortzusetzen, ohne den Fehler gleich zu beheben. Wenn ein Programm gleich zu Beginn eines Tests versagt, »abstürzt«, wenn also ein »blockierender Fehler« vorliegt, ist es gar nicht möglich, ohne Eingriff ins Programm fortzufahren. Diese Überlegung ist aber vordergründig:
Erstens sollte es klar sein, dass Schrott nicht in die Prüfung kommt. Wer ein Programm abliefert, sollte sich selbst überzeugt haben, dass es in Ordnung ist. Dazu gehört in der Regel ein Versuch, das Programm auszuführen. Wenn sich am Ende des Fließbands zeigt, dass im Auto der Motor fehlt, sollte man nicht rasch einen einbauen, sondern den Fehler im Fertigungsprozess suchen und beheben.
Zweitens haben Änderungen während der Prüfung den Effekt, dass am Ende nicht klar ist, was genau geprüft wurde; in der Regel ist nur klar, dass die Ergebnisse der Prüfung irgendwelche nicht dokumentierten Zwischenzustände betreffen, aber weder den Anfangs- noch den Endzustand. Die Prüfergebnisse kann man dann getrost wegwerfen.
Drittens werden grundsätzliche Mängel oft erst durch die komplette Prüfung sichtbar, nicht durch einen einzelnen Prüfschritt. Wenn sich zu Beginn der Inspektion zeigt, dass die Reihenfolge der Verarbeitungsschritte falsch ist, sind die Zusammenhänge nicht sichtbar. Vielleicht erkennt man später, dass in Wahrheit ein Missverständnis über die Funktion des Programms zu diesem Problem und zu weiteren Problemen geführt hat. Die Änderung der Verarbeitungsschritte hätte den Fehler verdeckt, nicht beseitigt. Und sie hätte wahrscheinlich weitere Änderungen und Änderungen der Änderungen nach sich gezogen (die gefürchteten additiven Änderungen an Stelle einer sinnvollen kumulativen Änderung).
Viertens sind Änderungen besonders fehlerträchtig; sie sollten nicht en passant bei der Prüfung beschlossen und umgesetzt werden.
Fünftens ist es so gut wie ausgeschlossen, dass über entdeckte Fehler, wenn sie sofort unter den Teppich gekehrt werden, eine brauchbare Statistik geführt wird.
Sechstens sind die Rollen Entwickler und Prüfer getrennt oder sollten es sein. Wenn der Prüfer ändert, läuft er in Bezug auf sein Rollenverständnis zu den Entwicklern über und wird anschließend nicht mehr nach Fehlern suchen, sondern die Korrektheit seiner Entscheidung verteidigen.
Es gibt also mehr als genug gute Gründe, Prüfung und Korrektur zu trennen!
Von den vielen möglichen Verfahren, Software zu inspizieren, sollen hier die folgenden vier weiter diskutiert werden:
1. die Durchsicht (der »Schreibtisch-Test«), eine informelle Prüfung ohne Verwendung des Rechners, vom Urheber selbst und allein durchgeführt,
2. die Stellungnahme, ein verbreitetes Vorgehen, um die Meinung anderer Entwickler einzuholen,
3. das Technische Review, ein wohldefiniertes, dokumentiertes Verfahren zur Bewertung eines Prüflings, und schließlich
4. der Walkthrough, ein Ansatz zwischen Technischem Review und Stellungnahme.
Im Mittelpunkt unserer Darstellung stehen die Reviews (Abschnitt 13.5). Die übrigen genannten Verfahren werden daran anschließend kurz vorgestellt (Abschnitt 13.6).
In vielen Firmen finden – vor allem zur Klärung der Anforderungen – halboder ganztägige Gesprächsrunden statt, die ebenfalls als Reviews bezeichnet werden. Solche Workshops (nach unserer Terminologie) können sehr sinnvoll sein, dienen aber nicht primär der Aufdeckung von Mängeln, die wir als wesentliches Ziel der Reviews betrachten. Wir behandeln solche Workshops im Abschnitt über die Analyse (Abschnitt 16.2.8).
Nachfolgend wird als Standardform der Inspektion das Technische Review beschrieben. Dabei handelt es sich um ein Verfahren, das weit verbreitet ist und sehr oft angewendet wird. Wir haben das Technische Review sowohl in der Industrie als auch in der Hochschule gelehrt und damit sehr gute Erfahrungen gesammelt. Das bedeutet freilich nicht, dass seriöse Reviews nach anderen Regeln schlechter sind, solange einige zentrale Punkte (Prüfung eines definierten Dokuments nach rationalen Kriterien, Vorbereitung der Gutachter, Sitzung unter kompetenter Leitung, Dokumentation der Resultate) gewährleistet sind.
Als Prüfling kommt jeder in sich abgeschlossene, für Menschen lesbare Teil von Software in Betracht – ein einzelnes Dokument, ein Modul, ein Satz Testdaten, eine Installationsanleitung. Achtung, der Prüfling ist keine Person, sondern ein Stück Software! Es ist fatal, wenn Prüfling und Autor (Abschnitt 13.5.1) verwechselt werden.
Zur Prüfung sind Referenzunterlagen nötig, die eine Beurteilung ermöglichen. Dazu gehören als Basis eine Vorgabe oder Spezifikation sowie die Richtlinien, die zu beachten sind. Zusätzlich können Fragenkataloge verwendet werden, also Listen von Fragen, die im Review beantwortet werden sollen. So kann beispielsweise eine Entwurfsbeschreibung (der Prüfling) daraufhin überprüft werden, ob der Lösungsansatz die in der Spezifikation festgelegten Anforderungen erfüllt und die für Entwurfsbeschreibungen gültigen Richtlinien (z. B. für Kennzeichnung, Inhalt, Gestaltung, Darstellung) einhält.
Das Technische Review ist eine effektive und äußerst effiziente Art der Prüfung (siehe Porter, Votta, Basili, 1995). Sein wichtigster Vorteil ist, dass Zuständigkeiten und Verantwortlichkeiten im Review klar durch folgende Rollen definiert sind:
Der Moderator leitet das Review, sorgt also für den ordnungsgemäßen Ablauf und ist dafür verantwortlich. Der Moderator muss eine Persönlichkeit sein, die mit den organisatorischen und auch den menschlichen Problemen des Reviews fertig wird. Er kann aus dem Kreis der Kollegen kommen oder als Externer seine spezielle Kompetenz einbringen.
Der Autor ist der Urheber des Prüflings oder Repräsentant des Teams, das den Prüfling erstellt hat. Der Autor nimmt an der Review-Sitzung teil, um die Diskussion zu hören und um auf Befragen Unklarheiten zu beseitigen; er sollte nicht ungefragt das Wort ergreifen und quasi als Verteidiger des Prüflings agieren.
Der Gutachter ist ein Kollege, der den Prüfling beurteilen kann. Sein Sachverstand kann sich auf verschiedene Aspekte beziehen, z. B. den technischen Inhalt oder die für die Erstellung eingesetzten Methoden. Vor allem sind es aber der gesunde Menschenverstand und die Erfahrung mit Software, die eine Person befähigen, Inkonsistenzen oder Unvollständigkeiten zu erkennen, ohne Experte für den Prüfling zu sein.
Der Notar ist ein Kollege, der in der Review-Sitzung das Protokoll erstellt. Diese Rolle kann, wenn die Reviews eingespielt sind, auch vom Autor übernommen werden.
Das Review-Team bilden alle Teilnehmer des Reviews außer dem Autor.
Keine Rolle im Review hat der Manager, typischerweise ein Linienvorgesetzter oder Projektleiter, der den Auftrag zur Erstellung des Prüflings gegeben hat und somit auch die Verantwortung für die Freigabe des Prüflings trägt. Der Manager entscheidet, nimmt aber nicht am Review teil!
Beim Technischen Review werden Kollegen als Gutachter hinzugezogen. Natürlich kommen dafür vor allem andere Entwickler in Frage, aber in bestimmten Phasen sind Benutzer, Produktmanager oder Auftraggeber die Wissensträger, die zur Beurteilung eines Arbeitsresultats wichtige Beiträge liefern können. Die Gutachter erhalten im Technischen Review immer konkrete Aufträge, wie nachfolgend am Beispiel dargestellt ist (siehe Abb. 13–5 auf S. 284).
Diese Aufträge haben einen doppelten Sinn: Zum einen ist dadurch sichergestellt, dass Fehler, die immer wieder vorkommen, sehr wahrscheinlich entdeckt werden. Zum anderen ist ein Gutachter, der nach bestimmten Mängeln sucht, insgesamt aufmerksamer, er findet also allgemein mehr Fehler als ohne speziellen Prüfauftrag.
Das Technische Review wird nach dem in Abbildung 13–4 dargestellten Schema organisiert und durchgeführt.
Abb. 13–4 Organisation und Ablauf eines Reviews
Art des Dokuments: Spezifikation |
Bereiten Sie die Review-Sitzung vor, indem Sie den Prüfling speziell unter den Ihnen in der Einladung zugeordneten Aspekten aus der folgenden Liste prüfen:
Aspekt »Form«:
Ist die Darstellung im Dokument sinnvoll?
1. Sind alle Anforderungen erkennbar, von Erklärungen unterscheidbar?
2. Sind alle Anforderungen eindeutig referenzierbar?
3. Ist die Spezifikation jeder Anforderung eindeutig?
4. Sind alle Anforderungen überprüfbar formuliert?
Aspekt »Schnittstellen«:
Sind alle Schnittstellen eindeutig spezifiziert?
5. Sind alle Objekte der Umgebung (Benutzer, andere Systeme, Basis-Software etc.) sowie ihre Informationsflüsse spezifiziert?
6. Sind alle Benutzerklassen des Systems (Dauerbenutzer, gelegentliche Benutzer, System-Administrator etc.) identifiziert?
7. Ist die Bedienschnittstelle für jede der Benutzerklassen festgelegt?
8. Ist die Bedienphilosophie einheitlich?
9. Ist das Bedienkonzept den Vorkenntnissen der Benutzer angemessen?
10. Ist die Schnittstelle zur Datenerfassung eindeutig festgelegt?
11. Gibt es Vorgaben bezüglich Verwendung von BetriebssystemFunktionen, Bibliotheken und Hilfsprogrammen?
Aspekt »Zustände und Ereignisse«:
Sind alle Zustände und Ereignisse eindeutig spezifiziert?
12. Sind alle möglichen Betriebsarten (offline, online etc.) definiert?
13. Sind alle möglichen Betriebsmodi (Betrieb für die verschiedenen Benutzerklassen, Test, Wartung etc.) definiert?
14. Sind alle möglichen Betriebszustände (Normalbetrieb, reduzierter Betrieb, Notbetrieb etc.) definiert?
15. Sind alle Ereignisse spezifiziert, die zur Änderung des Betriebsmodus oder des Betriebszustands führen?
Aspekt »Vertraulichkeit«:
Sind Aspekte des Datenschutzes berücksichtigt?
16. Ist spezifiziert, welche Information zu schützen ist?
17. Sind die Zugriffsrechte aller Benutzerklassen definiert?
...
Abb. 13–5 Beispiel eines Fragenkatalogs (Auszug)
Der Anstoß zum Review kommt von der Konfigurationsverwaltung (siehe Kap. 21). Wenn ihr eine neue Einheit unterstellt wird, ist eine Prüfung fällig. Der vorgesehene Moderator wird informiert, er verteilt die Einladungen an die Gutachter; Prüfling und Prüfaufträge sind Teile der Einladung.
Im ersten Schritt des Reviews, in der Vorbereitung, lesen die Gutachter das zu prüfende Dokument und prüfen es nach den ihnen individuell zugeteilten Gesichtspunkten.
Den zweiten Schritt bildet die Review-Sitzung, in der die Gutachter die in der Vorbereitung entdeckten Mängel vortragen. Gemeinsam erheben, gewichten und protokollieren sie die Befunde. Der Auftrag für die Review-Sitzung lautet also, den Prüfling zu begutachten, nicht, ihn zu korrigieren. Die Sitzung liefert eine Liste der Schwächen mit einer Empfehlung, welche Mängel vor der Freigabe des Prüflings beseitigt werden sollten.
Damit die Gutachter ihre im Review nicht gefragten Lösungsideen loswerden können, folgt die sogenannte Dritte Stunde. Dann reden die Gutachter und der Autor ohne Regeln und ohne Protokoll.
Die Entscheidung über Art und Umfang der Nacharbeit trifft die zuständige Führungsinstanz im Projekt (in der Regel der Manager, der am Review nicht teilnimmt).
Die Nacharbeit selbst ist Sache des Autors oder der Autoren. Die Gutachter kommen bei der Überprüfung der Nacharbeit evtl. nochmals zum Zuge. Bei umfangreichen Änderungen wird das überarbeitete Dokument einem weiteren Review unterzogen, einfachere Änderungen kann ein Gutachter oder der Moderator kontrollieren.
Planung und Analyse finden lange vor bzw. nach dem Review statt. Durch die Planung wird sichergestellt, dass der notwendige Aufwand im Zeitplan berücksichtigt ist. Die Analyse dient dazu, Erfahrungen in weitere Entwicklungen, auch in die Verbesserung der Reviews selbst, einzuspeisen.
Damit in einem Technischen Review möglichst viele Mängel aufgedeckt werden, sollten die nachfolgenden Regeln beachtet werden:
1. Der Moderator organisiert das Review, lädt dazu ein und führt es durch.
Das Review ist quasi ein kleines Projekt. Sein Projektleiter ist der Moderator. Er lädt zur Sitzung ein und leitet sie, im Normalfall überwacht er auch die Nacharbeiten.
In der Praxis ist es schwierig bis unmöglich, einen Termin zu finden, an dem alle beteiligten Personen kommen können. Oft weicht man dann auf »asynchrone Reviews« aus, bei denen schriftliche Gutachten das Gespräch ersetzen. Dieses Verfahren hat aber erhebliche Nachteile, denn der sehr wichtige Schulungseffekt kommt dadurch nicht zustande. Viel besser ist es, einen festen Termin zu vereinbaren (beispielsweise den Donnerstagnachmittag), den sich alle potenziellen Review-Teilnehmer reservieren.
2. Die Review-Sitzung ist auf zwei Stunden beschränkt. Falls nötig wird eine weitere Sitzung, frühestens am nächsten Tag, einberufen.
Wo Reviews neu eingeführt werden, sollte man mit kleinen Prüflingen (einige Seiten Text) beginnen und sich von unten an den Umfang herantasten, den man im Review bewältigen kann. Mit wachsender Routine bearbeitet man ohne Einbußen an Effektivität größere Prüflinge.
3. Der Moderator sagt oder bricht die Sitzung ab, wenn sie nicht erfolgreich durchgeführt werden kann, weil Experten nicht erscheinen oder ungenügend vorbereitet sind oder andere Bedingungen dem Erfolg im Wege stehen. Der Grund des Abbruchs wird protokolliert.
Eine Review-Sitzung, die nur der Form halber durchgezogen wird, ist verlorene Zeit und verwässert das Konzept.
4. Das Resultat, nicht der Autor steht zur Diskussion. Die Gutachter müssen auf ihre Sprache und Ausdrucksweise achten. Der Autor darf weder sich noch den Prüfling verteidigen.
Vor allem bei den ersten Reviews kommt es oft zur Konfrontation, und Konflikte, die die Beteiligten lange vorher hatten, finden in feindseligen Ausfällen ihren Ausdruck. Es ist die Aufgabe des Moderators, solche Tendenzen rasch zu erkennen und im Keim zu ersticken.
5. Die Rollen werden nicht vermischt. Insbesondere darf der Moderator nicht gleichzeitig als Gutachter fungieren.
Der Moderator ist mit seiner eigenen Rolle völlig ausgelastet.
6. Allgemeine Stilfragen außerhalb der Richtlinien dürfen nicht diskutiert werden.
Dieser scheinbar harmlose Punkt erweist sich als besonders schwierig, weil bei der Einführung von Reviews in aller Regel keine ausreichenden, sinnvollen Richtlinien vorliegen. Damit besteht die Gefahr, dass der individuelle Geschmack der Gutachter zum Maßstab wird. Das ist natürlich keine Lösung. Stattdessen sollte parallel zur Einführung von Reviews ein Prozess angestoßen werden, in dem die Richtlinien verbessert und komplettiert werden.
7. Die Entwicklung oder Diskussion von Lösungen ist nicht Aufgabe des Review-Teams. Befunde werden nicht in Form von Anweisungen an den Autor protokolliert.
Die Gründe für diese Regel wurden in Abschnitt 13.4.4 ausführlich dargelegt.
8. Jeder Gutachter erhält Gelegenheit, seine Befunde angemessen zu präsentieren.
Es ist sinnvoll, den Prüfling Abschnitt für Abschnitt zu diskutieren und jeweils die Befunde jedes einzelnen Gutachters abzufragen. Der Moderator muss Gutachter bremsen, wenn sie längere Monologe halten, aber auch Gutachter ins Gespräch (zurück-)holen, die allzu vorsichtig, beleidigt oder einfach träge sind.
9. Der Konsens der Gutachter zu jedem Befund wird laufend protokolliert.
Solange der Konsens nicht erzielt ist, darf der Moderator nicht fortfahren. Notfalls muss der Notar bremsen. Sein Protokoll muss für alle Beteiligten sichtbar sein (Laptop mit Beamer), sodass Unklarheiten sofort entdeckt und beseitigt werden.
10. Die einzelnen Befunde werden gewichtet als:
• Kritischer Fehler
Der Prüfling ist für den vorgesehenen Zweck unbrauchbar, ein kritischer Fehler muss unbedingt vor der Freigabe behoben werden.
• Hauptfehler
Die Nutzbarkeit des Prüflings wird merklich beeinträchtigt, der Fehler sollte vor der Freigabe behoben werden.
• Nebenfehler
Die Nutzbarkeit des Prüflings wird kaum beeinträchtigt. Der Fehler sollte bei Gelegenheit behoben werden.
• Gut
In diesem Abschnitt wurde kein Mangel festgestellt.
Die Gewichtung wird für die Gesamtbewertung des Prüflings (Punkt 11) und für die Statistik benötigt. Die Kennzeichnung »gut« stellt klar, dass der Abschnitt wirklich geprüft wurde.
11. Das Review-Team gibt eine der folgenden Empfehlungen über die Annahme des Prüflings ab:
• Akzeptieren ohne Änderungen
• Akzeptieren mit Änderungen
• Nicht akzeptieren
»Akzeptieren mit Änderungen« ist der Normalfall. Auf ein weiteres Review kann damit verzichtet werden. Dagegen bedeutet »Nicht akzeptieren«, dass nach der Überarbeitung erneut ein Review angesetzt werden muss.
12. Das Protokoll wird am Ende ausgedruckt und von allen Teilnehmern unterschrieben.
Sie dokumentieren damit ihre Verantwortung für die Qualität des (korrigierten) Prüflings.
Im Review arbeiten Leute eng zusammen, die sich sonst nur in der Kantine treffen. Und sie erhalten Einblick in die aktuelle Arbeit der anderen. Solange es keine Reviews gibt, ist ein solcher Blick in den Garten des Nachbarn nicht üblich, wird sogar als Verletzung der Intimsphäre empfunden. Darum stellt die Einführung von Reviews eine wesentlich größere Veränderung dar als die Einführung eines Werkzeugs oder einer neuen Programmiersprache.
Naturgemäß werden zuerst die negativen Folgen sichtbar: Ein Entwickler, der zum ersten Mal als Autor an einem Review teilnimmt, fühlt sich nackt vor eine Prüfungskommission gestellt. Die Tatsache, dass viele Entwickler als Autodidakten, also ohne einschlägige Berufsausbildung, in diese Tätigkeit hineingerutscht sind, verschärft ihre Angst.
Viele der oben aufgelisteten Regeln sollen dazu beitragen, dass diese Angst nicht in Panik umschlägt, sondern abgebaut wird und dem Gefühl Platz macht, als Kollege unter Kollegen anerkannt zu sein und Unterstützung zu bekommen. Dazu zählen
der Ausschluss des Vorgesetzten, der in jedem Fall im Verdacht steht, die Kritik am Prüfling in eine Mitarbeiterbeurteilung umzudeuten,
das Verbot, über Stilfragen zu diskutieren, denn die Beschränkung auf Regeln, die in Richtlinien dokumentiert sind, gibt dem Autor Sicherheit,
die sachliche Leitung des Reviews durch den erfahrenen Moderator und sein rasches Einschreiten, wenn es zu persönlichen Auseinandersetzungen kommt,
die Dritte Stunde, die den Emotionen Auslauf gibt,
der regelmäßige Rollentausch, der verhindert, dass jemand immer Autor oder immer Gutachter ist,
ein objektives, technisches Kriterium, welche Resultate einem Review unterzogen werden. Ohne ein solches Kriterium entsteht bei manchen Autoren der Verdacht, zu den »üblichen Verdächtigen« zu gehören.
Angesichts einer solchen Problemliste drängt sich die Frage auf, ob sich die Mühe lohnt. Die Antwort ist ein klares Ja. Sie lohnt sich nicht nur dadurch, dass nachweisbar viele Fehler zu insgesamt akzeptablen Kosten entdeckt werden, bevor sie Schaden anrichten; alle Statistiken belegen eindeutig, dass es weit teurer wäre, die Fehler nicht zu suchen. Vorteile, die vielleicht noch wichtiger sind, liegen dort, wo auch die Probleme liegen, nämlich in der Zusammenarbeit der Entwickler. Wo Reviews zur Routine geworden sind, ist das Vertrauen zwischen den Software-Leuten deutlich höher, die Richtlinien werden nicht verspottet und ignoriert, sondern gelebt, und niemand fürchtet sich davor, die anderen um Rat zu fragen. Nicht zuletzt entwickeln die Beteiligten ein sachlich fundiertes Selbstbewusstsein und einen begründeten Stolz auf ihre Arbeit. Wer einmal an Reviews gewöhnt ist, möchte auf keinen Fall mehr darauf verzichten.
Reviews sind weltweit seit langem als wichtigste Technik der Software-Prüfung anerkannt, ihr Nutzen ist klar nachgewiesen und von allen, die regelmäßig und systematisch Reviews durchführen, bestätigt. Trotzdem gibt es viele Fälle, in denen die Einführung von Reviews gescheitert oder zu einer ohne Überzeugung betriebenen Formalübung degeneriert ist. In diesem Abschnitt werden die wichtigsten Schwierigkeiten diskutiert.
1. Für die Vorbereitung oder sogar für die Review-Sitzung selbst fehlt die Zeit.
Reviews müssen in der Planung mit den dafür notwendigen erheblichen Aufwänden (je nach Qualitätsanforderungen zwischen 10 % und 50 % des Gesamtaufwands) berücksichtigt werden. Es ist sinnlos und kontraproduktiv, in ein allzu optimistisch geplantes, bereits angeschlagenes Projekt noch Reviews hineindrücken zu wollen, ohne die Planung erheblich zu verändern.
2. Die Reviews finden in einer bis zur Unkenntlichkeit reduzierten Form statt.
Der Kostendruck ist überall hoch. Es liegt daher nahe, die Reviews, die ja erheblichen Aufwand verursachen, abzumagern. Dabei erreicht man aber rasch einen Punkt, an dem das Verhältnis zwischen Aufwand und Nutzen kippt. Zwei vorbereitete Gutachter, einen Moderator und eine ungestörte Sitzung braucht es unbedingt.
3. Gute Moderatoren fehlen.
Die Rolle des Moderators ist anspruchsvoll. Wer sie übernimmt, sollte taktvoll und selbstbewusst sein und die Regeln des Reviews sicher beherrschen. Dazu bedarf es einer speziellen Ausbildung. Sie wird von verschiedenen Institutionen angeboten. Für eine Übergangszeit sind externe Moderatoren eine gute Lösung. Langfristig sollte dieses Know-how aber im eigenen Hause vorhanden sein.
4. Bezugsdokumente fehlen.
Die ersten, unzureichend vorbereiteten Reviews scheitern oft an den Unzulänglichkeiten der Bezugsdokumente. Darum sollte schon zu Beginn ein Grundstock sinnvoller Richtlinien vorhanden sein. Dann sollten die Dokumente entsprechend ihrer Entstehungsreihenfolge Reviews unterzogen werden, also beginnend mit der Planung und der Spezifikation, sodass bei den weiteren Reviews die entsprechenden Bezugsdokumente sicher in geprüfter Qualität vorliegen.
5. Entwickler haben Angst, wenn sie als Autoren an Reviews teilnehmen sollen.
Wer Jahre oder Jahrzehnte Software entwickelt, Programme geschrieben hat, ohne dass je ein Kollege oder ein Vorgesetzter die Ergebnisse kritisch untersucht hat, fürchtet sich vor dem Review. Die Tatsache, dass er diese Angst mehr oder minder überzeugend leugnet, macht die Sache nicht leichter. Volle Aufklärung über Prinzipien und Ziele, wechselnde Rollen (Gutachter/Autoren) und eine pannenfreie Durchführung der allerersten Reviews vermindern das Problem.
6. Die Reviews beißen sich an Äußerlichkeiten fest.
In den ersten Reviews fällt vor allem auf, dass sich die Entwickler bislang nicht an die Richtlinien zur Formatierung und Gestaltung der Dokumente gehalten haben. Das sind meist relativ harmlose Nebenfehler, sodass sich die Teilnehmer der Reviews über die scheinbar sinnlos vertane Zeit ärgern. Aber die Äußerlichkeiten müssen in Ordnung sein, damit die inhaltlichen Fehler sichtbar werden. Darum darf der Moderator die formalen Fehler nicht bagatellisieren, er muss sie ernst nehmen und ihre Behebung durchsetzen. Dazu genügt aber ein einziger summarischer Eintrag im Protokoll. (Beispiel: »Die Formatierung des Programms entspricht nicht der Richtlinie XYZ« oder »Bei den Begriffen in der Spezifikation fehlt durchgängig der geforderte Bezug zum Begriffslexikon.«) Der Moderator stellt sicher, dass diese Mängel in der revidierten Fassung behoben sind. Damit ist den Entwicklern ganz klar, dass sie mit ihren kleinen Schlampereien (»Das habe ich immer so gemacht!«) nicht mehr durchkommen.
7. Die Bezugsdokumente erweisen sich als unzulänglich.
Selbst wenn Richtlinien vorliegen, ist keineswegs sicher, dass sie auch anwendbar sind. In den ersten Reviews zeigt sich regelmäßig, dass die darin enthaltenen Vorschriften teilweise unsinnig rigide, teilweise lückenhaft, unklar oder schwammig sind. Darum muss sich ein schnell reagierender Kreis von Entwicklern und QS-Leuten mit der Verbesserung der Richtlinien befassen.
8. Der Zeitdruck sabotiert die Prüfungen.
Termine haben in der Industrie in aller Regel deutlich höhere Priorität als die Produktqualität. Darum wächst in schlingernden Projekten der Druck, alle Kapazitäten einzusetzen, um den Liefertermin einzuhalten. Reviews werden dann nur noch pro forma inszeniert, damit kein Kreuz auf der Checkliste fehlt. Aber mangels Vor- und Nachbereitung ist der Nutzen sehr gering. Allgemein gilt: Wo keine seriösen Reviews möglich sind, sollte man ganz darauf verzichten.
9. Dokumente werden verändert, während ihre Prüfung läuft.
Wenn der Entwickler weiter an der Komponente arbeitet, während bereits ein Review vorbereitet wird, betreffen die Hinweise der Gutachter in der Review-Sitzung bereits eine veraltete Fassung. Sie finden also Fehler, die der Autor schon behoben hat, können aber Fehler, die der Autor in seinen letzten »Verschlimmbesserungen« eingeschleppt hat, nicht entdecken. Das frustriert die Gutachter und mindert den Nutzen der Reviews erheblich. Geprüft wird nur, was der Konfigurationsverwaltung unterstellt ist, und das darf niemand, auch nicht der Autor, unkontrolliert verändern. Erst mit dem Auftrag zur Nacharbeit ist der Autor wieder am Zuge.
10. Das Interesse an Reviews sinkt, wenn ihr Erfolg zur Routine geworden ist.
Ein typischer Kommentar lautet dann: »Ja, die Reviews haben viel gebracht, die Entwickler arbeiten jetzt viel disziplinierter und halten sich an die Regeln, und die Qualität ist sicht- und zählbar gestiegen. Aber nun können wir eigentlich darauf verzichten.« Das ist sehr kurzsichtig. Ohne Reviews kommt es schnell zum Rückfall in alte (schlechte) Gewohnheiten. Tatsächlich sind die Reviews nach einigen Jahren sehr viel effizienter als zu Beginn, die Kosten pro gefundenem Fehler stabilisieren sich und bleiben auf Dauer deutlich unter den Kosten, die ein Fehler verursacht, der nicht vor der Auslieferung abgefangen wurde. Aber um diesen anhaltenden Vorteil nachzuweisen, müssen Statistiken geführt werden, die alle Kosten und alle Fehlerzahlen zeigen und anschaulich machen, am besten im Vergleich mit den Kosten von Feldfehlern, die erst im Einsatz aufgefallen sind.
Die Einführung der Reviews ist eine Durststrecke: Während der Nutzen noch nicht erkennbar ist, weil er sich erst einige Zeit später einstellt, sind die Probleme zu Beginn am größten, die Widerstände am stärksten. Trotzdem lohnt sich der Aufwand bereits nach wenigen Monaten, wenn die geprüften Dokumente ihre Vorzüge zeigen und die Angst der Entwickler vor dem vermeintlichen Spießrutenlaufen nachlässt.
Wer vor dem Erfolg aufgibt, hat eine große Chance verpasst. Die hohen Kosten der Reviews sind nicht nur durch die noch höheren Einsparungen gerechtfertigt, die dank der besseren Software-Komponenten über lange Zeit entstehen, sondern mit mindestens gleich hohem Gewicht durch den Schulungseffekt, den sie haben. In einer firmeninternen Untersuchung1 wurden die Beteiligten nach dem wichtigsten Nutzen der Reviews gefragt; mit 58 % war die häufigste Nennung Know-how-Transfer, gefolgt von Fehler (früh) finden (46 %), Mitarbeiter einarbeiten (38 %) und Qualitätsverbesserung (33 %). Ein Viertel der Befragten bestätigt, dass die Richtlinien nun gelebt werden. Keine andere einzelne Maßnahme des Software Engineerings hat einen ähnlich großen Nutzen.
Nur in speziellen Situationen ist von der Review-Einführung abzuraten:
Wenn ein Projekt praktisch bereits gescheitert ist und die Verantwortlichen nach einem Wunder Ausschau halten, ist der Griff nach den Reviews als Wunderwaffe sinnlos. Sie können nicht mehr seriös vorbereitet werden und haben keine Konsequenzen, aber am Ende wird das (ohnehin sichere) Scheitern des Projekts noch den Reviews angelastet.
Wenn keinerlei Bezugsdokumente vorliegen, könnte in Reviews nur über Geschmacksfragen diskutiert werden.
Wenn die Entwickler (z. B. nach einer Firmenfusion) in mehr oder minder feindliche Lager gespalten sind, schaffen die Reviews nur einen weiteren Kriegsschauplatz.
In keiner der genannten Situationen muss man aber untätig bleiben: Auch in einem Projekt mit schwerer Schlagseite ist es sinnvoll zu retten, was zu retten ist. Beispielsweise kann man versuchen, wenigstens zentrale Dokumente (vor allem die Spezifikation und die Planung für die restliche Laufzeit des Projekts) in einen akzeptablen Zustand zu bringen. Wo Bezugsdokumente fehlen, kann man eine Art Versuchsreview durchführen, um die Defizite zu erkennen und die Arbeit an den Bezugsdokumenten anzustoßen. Wo unterschiedliche Unternehmenskulturen aufeinanderstoßen, kann man die Reviews zunächst separat weiterlaufen lassen, aber jeweils einen Gutachter der »Gegenseite« beiziehen, sodass sich die beiden Fraktionen kennenlernen und annähern können.
Die Durchsicht führt der Entwickler allein durch. Es ist zweckmäßig, dazu den Bildschirm zu verlassen und das ausgedruckte (Teil-)Resultat in Ruhe, quasi aus einer gewissen Distanz, zu überprüfen.
Diese Durchsicht ist nicht die »Software-Qualitätssicherung des kleinen Mannes«, sondern eine Prüfung, die selbstverständlich und obligatorisch sein sollte. Sie wird durch Reviews o. Ä. nicht überflüssig: Es ist weder rücksichtsvoll noch effizient, wenn der Autor einen Prüfling weitergibt, den er selbst nicht kritisch betrachtet hat.
Als die Stapelverarbeitung noch jede Programmübersetzung und -ausführung mit einer Wartezeit von mehreren Stunden bestrafte, war die Durchsicht selbstverständlich. Heute ist sie es leider nicht mehr, obwohl wir – unter anderem durch die Arbeiten von Humphrey (1997) zum »Personal Software Process« (Abschnitt 6.5) – sicher wissen, dass die Durchsicht weit effizienter ist als jeder Test.
Bei diesem Verfahren entscheidet der Autor, dass andere Meinungen die Qualität seiner Arbeit verbessern könnten. Er gibt daher einem Kollegen oder mehreren Kollegen eine Kopie zum Lesen. Die Reaktionen sammelt er und wertet sie aus, um den Prüfling zu überarbeiten.
Das Verfahren hat den offensichtlichen Vorteil, dass der Organisationsaufwand gering ist. Dem stehen allerdings erhebliche Nachteile gegenüber:
Ein Manager ist nicht beteiligt. Der Aufwand für die Stellungnahmen ist nicht geplant, die Gutachter arbeiten selbst an dringenden Aufgaben und haben eigentlich keine Zeit für die Prüfung.
Der Autor ist gleichzeitig Moderator. Er wählt die Gutachter aus, deren Engagement ungewiss bleibt.
Das Dokument ändert sich während der Ausarbeitung der Stellungnahmen, ein Teil der Kommentare geht darum ins Leere.
Einen Notar gibt es nicht, und somit auch kein Protokoll über die Befunde. Die Nachbearbeitung geschieht nach Gutdünken des Autors und wird nicht kontrolliert.
In der Praxis ist es schwierig, Reviews, insbesondere Code-Reviews, in kleinen Teams (bis zu fünf Personen) durchzuführen. Es gibt zum einen zu wenige Entwickler, die in der Lage sind, ein fremdes Programm kritisch durchzusehen. Zum anderen erscheint der Aufwand eines Technischen Reviews zu hoch für Programme, an die keine hohen Anforderungen gestellt werden, d. h., bei denen einige Restfehler keine dramatischen Folgen haben.
Hier bewährt sich der Walkthrough, eine einfachere Variante des Reviews. Sie ist weniger streng definiert und kann mit geringerem Aufwand durchgeführt werden. Dafür ist aber der Nutzen auch geringer.
Im Mittelpunkt steht die Walkthrough-Sitzung, die der Autor moderiert. Er stellt sein Arbeitsergebnis Schritt für Schritt vor, die Gutachter werfen (vorbereitete oder spontane) Fragen auf und versuchen so, Probleme zu identifizieren. Die Probleme werden protokolliert. Es gibt zwei Varianten dieses Verfahrens:
Mit Vorbereitung
Die Gutachter erhalten den Prüfling vor der Sitzung und können Fragen vorbereiten.
Ohne Vorbereitung
Der Prüfling wird den Gutachtern erst zu Beginn der Sitzung ausgehändigt.
Das Verfahren bewahrt die meisten Vorteile des Technischen Reviews, weil der Autor durch seine Präsentation die fehlende oder geringere Vorbereitung der Gutachter teilweise kompensiert; während seiner Vorbereitung und seiner Präsentation entdeckt er selbst viele Fehler. Aber einige Nachteile bleiben:
Es gibt keine klare Kompetenzregelung (z. B. Planung, Freigabe). Die Nacharbeit wird nicht kontrolliert, sie liegt im Ermessen des Autors.
Die Sitzung wird zwar geplant, die Vorbereitungszeit muss aber meist gestohlen werden.
Der Autor bestimmt den Gang der Dinge. Ist er ein guter »Verkäufer«, kann er unter Umständen die Gutachter blenden.
Die Effizienz (die Zahl der gefundenen Fehler, bezogen auf den Prüfaufwand) ist niedriger als beim Review.
Während das Walkthrough als die Sparvariante des Reviews betrachtet werden kann, handelt es sich bei den Design and Code Inspections (DCIs), wie sie von Michael Fagan Mitte der Siebzigerjahre bei IBM Federal Systems Division eingeführt wurden (Fagan 1976, 1986), um die Edelvariante. Die zusätzlichen Elemente der DCIs sind:
Der Prüfprozess beginnt mit einer Einführungssitzung. In dieser Sitzung werden der Prüfling und sein Umfeld vorgestellt, die Ziele der DCIs werden allen Beteiligten nochmals deutlich gemacht.
Zu Beginn der Review-Sitzung geben die Gutachter ihre Notizen aus der Vorbereitung an den Moderator ab.
In der Review-Sitzung gibt es einen Vorleser, der den Prüfling Seite für Seite vorliest, bevor dann zu dem vorgelesenen Teil die Befunde erfasst werden.
Das Review-Team gibt nicht nur eine Empfehlung, sondern ist auch die Entscheidungsinstanz für die Freigabe des geprüften Arbeitsergebnisses.
Der Review-Bericht ist stärker als beim Review formalisiert, die Fehler werden anders gewichtet (mit »major« oder »minor«).
Es werden mehr Daten erfasst und viele Kennzahlen ermittelt.
Untersuchungen von Zopf (1996) haben gezeigt, dass die DCIs einen etwa 50 % höheren Aufwand verursachen – und etwa 50 % mehr Fehler aufdecken. »You get what you pay for!«: Das gilt auch für Inspektionen.
