nach oben
Meine Merkliste
Ihre Merklisteneinträge speichern
Wenn Sie weitere Inhalte zu Ihrer Merkliste hinzufügen möchten, melden Sie sich bitte an. Wenn Sie noch kein Benutzerkonto haben, registrieren Sie sich bitte im Hanser Kundencenter.

» Sie haben schon ein Benutzerkonto? Melden Sie sich bitte hier an.
» Noch kein Benutzerkonto? Registrieren Sie sich bitte hier.
Ihre Merklisten
Wenn Sie Ihre Merklisten bei Ihrem nächsten Besuch wieder verwenden möchten, melden Sie sich bitte an oder registrieren Sie sich im Hanser Kundencenter.
» Sie haben schon ein Benutzerkonto? Melden Sie sich bitte hier an.
» Noch kein Benutzerkonto? Registrieren Sie sich bitte hier.

« Zurück

Ihre Vorteile im Überblick

  • Ein Login für alle Hanser Fachportale
  • Individuelle Startseite und damit schneller Zugriff auf bevorzugte Inhalte
  • Exklusiver Zugriff auf ausgewählte Inhalte
  • Persönliche Merklisten über alle Hanser Fachportale
  • Zentrale Verwaltung Ihrer persönlichen Daten und Newsletter-Abonnements

Jetzt registrieren
Merken Gemerkt
Software-Qualität - Reviews

Reviews

Auszug aus
Ernest Wallmüller

Software Quality Engineering

07/2011, 426 Seiten, € 31,99
ISBN: 978-3-446-43019-8
S. 257 - 271

Ablauf eines Reviews
Auswahl der Teilnehmer
Die Rolle des Managements
Hilfsmittel für Reviews
Walkthroughs und Inspektionen
Reviews im Entwicklungsprozess

In Anlehnung an die Norm IEEE Std 610 („Glossary of Software Engineering Terminology“) definieren wir ein Review folgendermaßen:

Ein Review ist ein mehr oder weniger formal geplanter und strukturierter Analyse und Bewertungsprozess, in dem Projektergebnisse einem Team von Gutachtern präsentiert und von diesen kommentiert oder genehmigt werden.

International ist auch der Begriff Peer-Review gebräuchlich, der die Begutachtung von Artefakten z. B. wissenschaftlichen Veröffentlichungen, durch Ebenbürtige (Gutachter) bedeutet.

Der besondere Stellenwert dieser Prüfverfahren liegt darin, dass Software-Entwicklung und -Pflege in hohem Maß ein Dokumentationserstellungs- und -pflegeprozess ist. Jedes Dokument sollte in irgendeiner Form überprüft werden. Gegenwärtig überwiegen im Entwicklungsprozess informelle Dokumente, halbformale und formale Dokumente sind selten. Gerade für diese informelle Dokumentation bieten Reviews die beste Möglichkeit, Mängel und Abweichungen von Qualitätsvorgaben festzustellen. Reviews sind heute die einzigen wirksamen Prüfverfahren, die in den frühen Phasen nutzbringend eingesetzt werden können.

Die Hauptgründe für den Einsatz von Reviews sind:

  • unmittelbare Qualitätsverbesserung des Prüfobjekts,
  • indirekte Verbesserung der Prozessqualität und
  • bessere Kontrolle der Projektfaktoren Kosten und Zeit.

Hinsichtlich der unmittelbaren Qualitätsverbesserung des Prüfobjekts werden folgende Nutzenaspekte durch Reviews festgestellt:

  • frühzeitige Fehlererkennung,
  • Sicherstellung der geforderten Qualitätseigenschaften,
  • Überprüfung der Einhaltung von Entwicklungsstandards und -richtlinien und
  • Überprüfung von Schnittstellen der Systembausteine.

In Bezug auf die „indirekte Verbesserung der Prozessqualität“ wird festgestellt, dass durch den Einsatz von Reviews eine wesentliche Kommunikationsverbesserung innerhalb des Projektes erzielt wird und außerdem die Kommunikation mit den Fachabteilungen besser gestaltet werden kann.

Hinsichtlich der Projektfaktoren Kosten und Zeit ist zu bemerken, dass Reviews eine genaue und zuverlässige Kontrolle des Projektfortschritts sowie eine erhebliche Aufwandsreduzierung bei den dynamischen Prüfungen ermöglichen.

Ablauf eines Reviews

Die einzelnen Reviewschritte sind in folgender Abbildung dargestellt.

Bild 1: Der Ablauf eines Reviews

Bild 1: Der Ablauf eines Reviews

Planung

Als Erstes werden die Prüfziele und die Auslösekriterien für das Review bestimmt. Letztere legen fest, unter welchen Bedingungen das Reviewobjekt als prüfgerecht bezeichnet werden kann. Die Planung wird meist vom späteren Moderator durchgeführt. Das Review ist zu einer möglichst störungsfreien Zeit und an einem möglichst störungsfreien Ort anzusetzen. Es muss auch sichergestellt sein, dass die Teilnehmer zur Reviewsitzung verfügbar sind.

Eine wichtige Frage ist, wie viel Zeit für den Reviewprozess eingeplant und verwendet werden soll. Für Code-Inspektionen liegen empirische Untersuchungen vor. Buck gibt in einer Studie [Buck81] folgende Produktivitätswerte für Code-Inspektionen an:

  • für die Vorbesprechung ca. 500 Anweisungen pro Stunde
  • für die Vorbereitung ca. 125 Anweisungen pro Stunde
  • für die Inspektion ca. 90 Anweisungen pro Stunde

Die maximale Inspektionsrate beträgt ca. 125 Anweisungen pro Stunde. Wird diese Rate überschritten, so wurde festgestellt, dass die Mängelentdeckungsrate stark abnimmt. Dies führt meist dazu, dass Re-Inspektionen (also Wiederholungen der Inspektion) durchgeführt werden müssen.

Für Textdokumente geben Gilb und Graham [Gilb94] eine Leserate von ca. einer Seite pro Stunde an. Andere Erfahrungswerte gehen von 3–5 Seiten pro Stunde aus. Zum Vergleich beträgt eine durchschnittliche „Rechtschreibfehler-Leserate“ ca. 7–25 Seiten pro Stunde.

Vorbesprechung

Bei komplexen oder neuen Prüfobjekten ist es sinnvoll, eine Vorbesprechung zum Review abzuhalten. Sie dient den Reviewteilnehmern dazu, einen Überblick über das Prüfobjekt zu gewinnen.

Individuelle Vorbereitung

Anschließend erfolgt die individuelle Vorbereitung auf das Review. Dafür ist genügend Zeit einzuplanen. Die kompletten Unterlagen für ein Review sind rechtzeitig vor der Reviewsitzung mit dem Hinweis auf deren Durcharbeitung zu verschicken. Die Reviewteilnehmer arbeiten das Reviewdokument (= Prüfobjekt) intensiv durch. Dazu benutzen sie die Prüfziele und eine Checkliste, die den Unterlagen beigelegt sind. Es ist auf die Möglichkeit hinzuweisen, in dieser Checkliste Ergänzungen anzubringen. Auftretende Fragen, Mängel und Formalfehler (z.B. Schreibfehler) werden schriftlich erfasst.

Reviewsitzung

Am Anfang der Reviewsitzung werden die so genannten Formalfehler vom Moderator aus Zeitgründen eingesammelt. Anschließend gibt der Ersteller einen Überblick zum Reviewobjekt. Bei einer Inspektion lesen die Teilnehmer gemeinsam unter Anleitung des Erstellers das Dokument durch, bei Walkthroughs spielen sie die Funktionalität des Prüfobjekts anhand von Testfällen und Beispielen durch. Auftretende Mängel werden in einer Aktionsliste zur Aufarbeitung aufgezeichnet. Zum Kenntlichmachen der bisher entdeckten Mängel (in der Aktionsliste) eignen sich Overheadfolien oder ein Flipchart.

Die Dauer der Reviewsitzung sollte auf zwei Stunden begrenzt werden. Während der Sitzung sollten Mängel nur entdeckt und nicht korrigiert werden. Die Teilnehmer sind angehalten, nur konstruktive und sachliche Kritik zu äußern. Eine der wichtigen Aufgaben des Moderators besteht darin, die beiden letztgenannten Punkte sorgfältig zu kontrollieren. Zum Schluss der Reviewsitzung bestimmen die Teilnehmer das Ergebnis des Reviews. Dabei gibt es verschiedene Möglichkeiten:

  • Das Review wird abgeschlossen. Es sind keine wesentlichen Mängel entdeckt worden.
  • Das Review wird abgeschlossen, nachdem offene Mängel in einer Nachbearbeitungsphase behoben worden sind.
  • Das Review wird aufgrund schwerwiegender Mängel nicht abgeschlossen und muss wiederholt werden. Es ist zu prüfen, ob das Reviewobjekt tatsächlich prüfgerecht vorliegt.

Nachbearbeitung

In der Nachbearbeitungsphase (Rework) sind die Korrekturen der Mängel vom Autor des Reviewobjekts zu erledigen. Es ist ein zusammenfassender Mängelbericht zu erstellen und eine Erledigungsliste der Korrekturen anzulegen.

Bewertung

Als letzter Schritt erfolgt eine Bewertung (Follow-up). Ziel dieser Bewertung ist die Feststellung, ob alle Korrekturen vollständig erledigt und dabei keine neuen Probleme verursacht worden sind. Diese Bewertung führt der Moderator durch. Das Management wird durch den „Managementbericht“ über den Abschluss des Reviewprozesses informiert.

Auswahl der Teilnehmer

Der erste Schritt bei der Auswahl ist die Suche nach einem Moderator. Ausgehend von den Entscheidungen, die der Moderator zu treffen hat, gibt Schnurer [Schn88] folgende Kriterien an, um den geeigneten Moderator zu finden:

  • Fachkompetenz, um Fehler zu erkennen und zu bewerten;
  • Durchsetzungsvermögen, um Entscheidungen glaubwürdig zu vertreten;
  • Neutralität, um keine Personen oder Methoden zu bevorzugen.

Wenn der Moderator bestimmt ist, wählt er mit dem Autor des Prüfobjekts die weiteren Teilnehmer aus. Die Auswahl der Teilnehmer sollte mit größter Sorgfalt und unter besonderer Beachtung ihrer Fähigkeiten durchgeführt werden. Nach Parnas [Parn85], der genaue Regeln für diesen Selektionsprozess angegeben hat, sollen folgende Personen an einem Review teilnehmen:

  • Spezialisten, also Personen mit einem Fachwissen und langjähriger Erfahrung, z.B. im Gebiet der Datenbanken, des Flugwesens etc.;
  • mögliche Benutzer des Systems;
  • alle jene, die die Fähigkeit besitzen und Freude daran finden, logische Widersprüche in einer systematischen Weise aufzudecken.

Parnas betont auch die Notwendigkeit, die Auswahl der Teilnehmer von den speziellen Zielsetzungen eines Reviews abhängig zu machen.

Reviews mit einer großen Anzahl von Teilnehmern (> 8) sind schon sehr schwierig zu moderieren. Für die Teilnehmeranzahl von Inspektionen empfehlen wir nicht mehr als 4 bis 7 Teilnehmer. Je höher der Grad der Arbeitsteilung in einem Projekt, desto größer sollte natürlich auch die Anzahl der Teilnehmer bei der Reviewsitzung sein.

Die Rolle des Managements

Der Software-Projektmanager, der die Verantwortung für ein Software-Projekt hat, ist auch an der Beurteilung der Qualität interessiert. Es gibt zwei verschiedene Modelle für die Rolle des Managements in Reviews.

Bei der ersten Variante, dem Management-Review, ist der Manager für folgende Aktivitäten verantwortlich: Er plant das Review, stellt das Reviewteam zusammen und veranlasst, dass die Teilnehmer auch zur Verfügung stehen. Weiters entscheidet er über Abnahme oder Überarbeitung des Reviewobjekts. An der eigentlichen Reviewsitzung nimmt der Manager teil.

Bei der zweiten Variante initiiert der Autor eines Dokuments das Review und lädt das Reviewteam, insbesondere auch den Moderator ein. Das Reviewteam selbst entscheidet über Abnahme oder Überarbeitung des Reviewobjekts. Der Moderator informiert das Management über die Reviewergebnisse im Managementbericht.

Ein Review dient nicht zur Mitarbeiterbeurteilung. Es gibt allerdings genügend Hinweise dafür, dass gerade das Management versucht, Reviews dafür heranzuziehen. Die Gefahr einer Mitarbeiterbeurteilung ist bei Variante 1 größer, da der Manager bei der Reviewsitzung anwesend ist. Weinberg und Freedman [Wein84] schlagen in diesem Zusammenhang vor, dass diejenigen, die die Entwickler eines Produkts zu bewerten haben, von fachtechnischen Reviews fernbleiben sollen, da sonst ein beachtlicher Teil des Reviewaufwands durch positive Selbstdarstellung der Entwickler verlorengeht. Ohne ausreichende Managementunterstützung ist die Einführung von Reviews gefährdet. Es ist daher ratsam, für das Management eine spezielle Schulung anzubieten, die Folgendes vermittelt:

  • Grundlagen und Prinzipien von Reviews;
  • Nutzen für das Management;
  • Bedeutung des Managements für eine erfolgreiche Reviewabwicklung;
  • Motivation, um ausreichende Ressourcen bereitzustellen und die Verfügbarkeit der Teilnehmer zu sichern.

Hilfsmittel für Reviews

Reviews können durch verschiedene Hilfsmittel effizienter geplant und durchgeführt werden. Das sind vor allem statische Analysatoren und verschiedene Formulare (siehe http://www.itq.ch/Tools + Templates ).

Durch statische Analysatoren kann man jene Teile von Dokumenten bzw. eines Software-Produkts herausfiltern, die einen gewissen Grad an Komplexität übersteigen oder Anomalien (z.B. toten Code) enthalten. Diese Teile sind besonders geeignete Kandidaten für Reviews.

Folgende Hilfsmittel können verwendet werden:

  • Reviewvorbereitung
  • Reviewmängelliste
  • Reviewbericht

Das Formular „Reviewvorbereitung“ wird in der persönlichen Vorbereitungsphase von jedem Reviewteilnehmer ausgefüllt. Es enthält Mängel, Probleme und Unklarheiten, die der Reviewteilnehmer festgestellt hat.

Das Formular „Reviewmängelliste“ füllt der Moderator oder ein von ihm ernannter Schriftführer während der Reviewsitzung aus. Es dient zur Aufzeichnung von Mängeln, die während der Sitzung entdeckt werden. Die Mängel werden durch ihre Position im Dokument, eine verbale Beschreibung, durch die Klasse und den Typ erfasst.

Das Formular „Reviewbericht“, das ebenfalls vom Moderator ausgefüllt wird, enthält eine Zusammenfassung der Reviewaktivitäten und -ergebnisse und geht an das Management. Es ist somit ein formeller Nachweis über die Durchführung des Reviews und sollte auch die Unterschriften aller am Review Beteiligten enthalten.

Mit Abschluss des Follow-up sollten alle Korrekturen ordnungsgemäß erledigt worden sein. Das Follow-up ist somit ein Abschlusskiterium für den Reviewprozess.

Walkthroughs und Inspektionen

Wir konzentrieren uns im Folgenden auf die verschiedenen Durchführungsarten von Reviews. Grundsätzlich wird zwischen Walkthroughs und Inspektionen unterschieden. Der wesentliche Unterschied zwischen den beiden besteht darin, dass Inspektionen formaler geplant und durchgeführt werden als Walkthroughs. Bei Walkthroughs wird die Funktionalität des Prüfgegenstands anhand von Beispielen und Testfällen durchgespielt, bei Inspektionen hingegen wird die Dokumentation des Prüfgegenstands Zeile für Zeile gelesen. Walkthroughs dienen unter anderem zur Ausbildung von Mitarbeitern und fördern die Teamkommunikation. Sie können zu regen Diskussionen bzw. zu einer hohen Interaktion zwischen dem Vortragenden und den Teilnehmern führen. Bei der Planung einer Inspektion wird darauf geachtet, dass die Inspektionsziele spezifiziert und durch eine begrenzte Anzahl von Fragen behandelt werden. Ein weiteres Kennzeichen von Inspektionen ist, dass jeder Teilnehmer eine ganz bestimmte vordefinierte Rolle einnimmt. In Inspektionen involviert sind der Moderator, der die Inspektion plant und leitet, der Autor, dessen Dokument inspiziert wird, und Gutachter (Inspektoren).

Wir gehen im Folgenden detailliert auf Inspektionen ein. Als Beispiel wählen wir eine Code-Inspektion.

Auslösekriterien

Damit eine Inspektion überhaupt begonnen werden kann, muss das zu inspizierende Objekt einige Bedingungen erfüllen bzw. müssen bestimmte Zusatzinformationen vorhanden sein. Zur Auslösung einer Code-Inspektion müssen beispielsweise folgende vier Bedingungen erfüllt sein:

  • Der Quellcode muss fehlerfrei übersetzt sein, d.h. die Programmliste darf keine Syntaxfehler enthalten.
  • Alle Entwurfsänderungen müssen im Code dokumentiert sein. Dem Quellcode liegen alle Entwurfsunterlagen und eine Liste der Änderungen bei.
  • Das Dokumentationsraster im Modulkopf muss vollständig ausgefüllt und aktuell sein. Es enthält unter anderem Hinweise auf den Ersteller des Moduls, Vor- und Nachbedingungen, die Änderungsgeschichte und technische Details.
  • Der Code muss so kommentiert sein, dass ein unabhängiger Leser anhand der Programmdokumentation den Code versteht.

Ende-Kriterien

Für die Beendigung einer Inspektion müssen Abschlussbedingungen gelten. Beispiele für solche Abschlussbedingungen sind „alle Code-Mängel sind korrigiert“ oder „alle nicht behobenen Mängel sind im Problemaufzeichnungssystem für das Projekt erfasst“.

Strategien zur Mängelentdeckung

Aufgrund der bisherigen Erfahrung ist es sinnvoll, eine Strategie zur Mängelentdeckung bereits bei der Vorbereitung einer Inspektion zu entwickeln. Checklisten und Richtlinien können eine solche Strategie unterstützen. Beispielsweise wird eine Code-Inspektion durch eine Checkliste gut unterstützt, in der die Ursachen der häufigsten Programmier- und Codierfehler eingearbeitet sind.

Mängelbewertung und -klassifikation

Für spätere Analysen des Entwicklungsprozesses ist es wichtig, die aufgetretenen Mängel und Fehler in Klassen und Typen einzuteilen. Eine sinnvolle Klasseneinteilung ist z.B. jene in fehlende Aussagen, falsche Aussagen und Diverses. Hinsichtlich der Typen können die Mängel und Fehler eingeteilt werden in solche, die die Daten, die Funktionalität, die Schnittstellen etc. betreffen. Weitere Kriterien zur Einteilung von Mängeln und Fehlern können der Schwierigkeitsgrad (Form, Inhalt, „offene Fragen“) oder die Fehlerquelle (welche Aktivität im Prozess hat den Fehler verursacht?) sein.

Bei der Klassifikation ist auf Konsistenz und Einheitlichkeit zu achten. Nur so ist es möglich, die Inspektionsergebnisse zu vergleichen. Es ist daher ratsam, Klassifikationsrichtlinien auszuarbeiten und regelmäßig die Moderatoren und Projektleiter zu schulen.

Eine Optimierung des Reviewprozesses kann durch perspektivenbasierte Lesetechniken erzielt werden ([Basi96], [Basi00], [Klei00]).

Dabei werden Dokumente aus der Sicht (Perspektive) der Kunden geprüft, die Ansprüche an die Qualität des Software-Produkts stellen. Jedem Prüfer wird ein Szenario zusammengestellt (Welche Qualitätsaspekte sind von Interesse? Welche Aktivitäten sind durchzuführen? Welche Fragen sind zu beantworten?), das die perspektivenbasierten Prüfaktivitäten und Fragestellungen enthält. Er bereitet sich damit auf die Review-/Inspektionssitzung vor. Aufgrund der unterschiedlichen Perspektiven wird das Dokument vielschichtig und effizient geprüft.

Reviews im Entwicklungsprozess

Große IT-Firmen, wie z.B. die IBM oder Siemens, haben die Bedeutung von Reviews seit Längerem erkannt und setzen diese sehr erfolgreich im Entwicklungsprozess ein [Faga86].

Reviews können je nach Reviewgegenstand in technisch orientierte Reviews und Management-orientierte Reviews (so genannte Projektreviews) eingeteilt werden. Bei technisch orientierten Reviews wird ein Software-Produkt nach Form und Inhalt geprüft und bewertet. Bei den Management-orientierten Reviews wird die Einhaltung von Kosten- und Zeitplänen im Speziellen und der Projektfortschritt im Allgemeinen geprüft und bewertet.

Im Weiteren gehen wir auf Projektreviews und auf technisch orientierte Reviews und ihre Anwendung näher ein. Die wesentlichen Prüfobjekte von technisch orientierten Reviews sind Anforderungsspezifikation, Entwurf, Code, Testpläne, Testfälle, Testergebnisse und das Benutzerhandbuch.

Projektreviews

Projektreviews sind Reviews, die Projekte zu bestimmten Zeitpunkten im Entwicklungsprozess aus der Sicht des Managements bewerten. Sie werden häufig als Projektstandssitzungen bezeichnet. Da sie in der Praxis oft eingesetzt werden, stellen wir sie im Folgenden näher dar.

Die Ziele dieser Reviews, die durch das Management bestimmt werden, sind:

  • Kontrolle des Projekts

    Typische Fragen zu dieser Zielsetzung:

    • Hat das Projektteam den gestellten Projektauftrag verstanden?
    • Ist der Projektauftrag zu modifizieren?
    • Gibt es einen prüf- oder messbaren Projektfortschritt?
    • Ist die bisher geleistete Arbeit vollständig und korrekt durchgeführt worden, und bildet sie eine zuverlässige Basis für weitere Arbeiten?
    • Wurden die vorgegebenen Standards und Richtlinien eingehalten?
    • Können die Zeit- und Kostenpläne eingehalten werden?
  • Steuerung des Projekts

    Die Projektmitarbeiter diskutieren spezifische Lösungsansätze für anstehende Probleme mit dem Management. Der Projektmanager gibt in Abstimmung mit dem Projektleiter die Lösungsstrategie bekannt.

Die Planung und Durchführung ist bei weitem nicht so straff und formal wie beispielsweise bei einer Inspektion. Die Teilnehmer sind:

  • der Projektmanager, der z.B. in der Linienorganisation für das Projekt verantwortlich ist (z.B. Sektions-, Abteilungsleiter),
  • der Projektleiter
  • die Projektmitglieder,
  • externe Spezialisten, die das Projekt begleiten.

Die Reviewsitzung ist dadurch gekennzeichnet, dass der Projektmanager das Review leitet, der Projektleiter das Projekt präsentiert und anschließend eine Diskussion stattfindet. Erfolgskriterien für Projektreviews sind:

  • Die Projektergebnisse müssen „reviewbar“ (lesbar und verständlich) sein.
  • Die Projektplanung und -durchführung erfolgt in kleinen und überschaubaren Arbeitseinheiten, die vom Aufwand her leicht einem Review unterzogen werden können.
  • Es gibt einen gut strukturierten Entwicklungsplan mit Meilensteinen, an denen der Projektfortschritt gemessen werden kann (keine „90 %-Fertig-Meldungen“).
  • Es gibt gut dokumentierte oder bereits durch technische Reviews bewertete Projektergebnisse.

Gerade der letzte Punkt ist in der Praxis häufig eine Schwachstelle von Projektreviews. Aus Zeitmangel oder aus Angst des Managements, Entscheidungen bzw. Prüffunktionen zu delegieren, wird auf technische Reviews verzichtet. Es besteht dann die Notwendigkeit, beim Projektreview auch inhaltlich tiefgehende (produkt-)technische Bewertungen durchzuführen. Für diese reicht meistens die geplante Zeit nicht. Daher werden wesentliche technische Probleme und Schwachstellen im Entwicklungsprozess übersehen, und der Projektmanager trifft seine weiteren Entscheidungen auf der Basis einer sehr unsicheren technischen Bewertung.

Die ideale Situation des Zusammenspiels von technischen Reviews und Projektreviews ist in Abbildung 3 dargestellt. Das Ziel ist, technische Bewertungen soweit wie möglich in technische Reviews zu verlagern und sicherzustellen, dass die Ergebnisse der technischen Reviews in Projektreviews ausgiebig mit dem Projektteam besprochen werden.

Bild 2: Zusammenspiel von technischen Reviews und Projektreviews

Bild 2: Zusammenspiel von technischen Reviews und Projektreviews

Abschließend fassen wir die Ergebnisse von Projektreviews für das Management zusammen:

  • Projektfortschrittskontrolle;
  • differenzierte Risikobeurteilung bezogen auf Kosten, Termine, verbrauchte Ressourcen und Produktqualität;
  • generelle Produktbewertung.

Eine ausgewogene Planung berücksichtigt beide Arten von Reviews (Projektreviews und technische Reviews).

Reviews der Anforderungsspezifikation

Mangelhafte Anforderungen haben bereits viele Informatikprojekte erheblich verzögert oder den Abbruch von Projekten verursacht. Nach der Erfahrung des Autors findet man folgende Kategorien von Anforderungsfehlern häufig vor:

  1. unklare, widersprüchliche Anforderungen;
  2. fehlende und unvollständige Anforderungen;
  3. fehlerhafte, untestbare Anforderungen;
  4. Anforderungen, die außerhalb des Auftrags liegen;
  5. Anforderungsfehler, die auf Schreibfehlern beruhen.

Ein Teil dieser Fehler lässt sich durch strukturiertes methodisches Vorgehen, die Verwendung einer präzisen Anforderungsdefinitionssprache und den Einsatz von SoftwareWerkzeugen zur Anforderungsermittlung und -prüfung reduzieren. Boehm stellte fest [Boeh84], dass es bis zu 100mal so teuer sein kann, einen Anforderungsfehler zu beheben, wenn sich die Software bereits im Einsatz befindet, als wenn dieser Fehler in der Anforderungsspezifikation festgestellt und behoben wird. Gerade Reviews der Anforderungsspezifikation sind ein sehr nützliches Hilfsmittel, Fehler in den frühen Phasen aufzudecken.

Eine wesentliche Zielsetzung bei einem Review der Anforderungsspezifikation ist die Prüfung, ob bestimmte Qualitätsmerkmale erfüllt sind. Folgende Qualitätsmerkmale einer Anforderungsdefinition sind zu prüfen:

  1. intern und extern widerspruchsfrei

    Für die interne Widerspruchsfreiheit wird überprüft, ob die Elemente der Spezifikation miteinander in Konflikt stehen. Für die externe Widerspruchsfreiheit wird geprüft, ob die Elemente der Spezifikation mit externen Spezifikationen oder Entitäten der realen Welt in Widerspruch stehen.

  2. vollständig

    Die Anforderungen enthalten keine Lücken, es gibt keine Bezugnahmen auf nicht existierende Funktionen, Eingaben oder Ausgaben; es fehlen keine Elemente des Dokumentenmusters, keine Funktionen und keine Teilprodukte.

  3. realistisch/durchführbar

    Die Anforderungen sind hinsichtlich der Ergonomie (Human Engineering), technischer und wirtschaftlicher Ressourcen und Risiken durchführbar.

  4. überprüfbar/präzise

    Die Anforderungen sind nicht in vager Form formuliert. Alle Anforderungen sind eindeutig identifizierbar und referenzierbar.

  5. verständlich

    Die Anforderungen sind z.B. durch Graphiken und/oder halbformale Spezifikationen so formuliert, dass sie sowohl für den Auftraggeber/die Benutzer als auch für den Software-Ingenieur verständlich sind.

Wie schon früher erwähnt, sind Checklisten eine wertvolle Hilfe zur Durchführung von Reviews. Eine Checkliste für Reviews der Anforderungsspezifikation sollte einerseits die Struktur des zu prüfenden Dokuments und andererseits die Kategorien von typischen Anforderungsfehlern berücksichtigen. Eine solche Checkliste im Bereich der Prozessdatenverarbeitung könnte folgende Fragen enthalten:

  • Sind die Anforderungen vollständig und widerspruchsfrei spezifiziert?
  • Sind alle benötigten Hardware-Ressourcen spezifiziert?
  • Sind die spezifizierten Antwortzeiten auch realisierbar? Sind alle Hardware- und externen Software-Schnittstellen beschrieben? - Sind alle Schnittstellenelemente durch ihre Quellen und Senken identifiziert bzw. durch Format-, Wertebereichs- und Skalenangaben spezifiziert?
  • Wurden externe Schnittstellenprogramme definiert?
  • Wurden die Eingabedatenströme in Form von Menge pro Zeiteinheit oder, wenn notwendig, in Form einer statistischen Verteilung spezifiziert?
  • Wurden alle Funktionen, die der Benutzer benötigt, identifiziert und spezifiziert?
  • Sind alle Algorithmen, die zu den funktionalen Anforderungen vorgegeben sind, spezifiziert?
  • Wurden Anforderungen in Bezug auf die zeitliche Ausführung einer jeden Funktion spezifiziert?
  • Gibt es zu jeder spezifizierten Funktion Abnahmekriterien?
  • Wurden Genauigkeitsangaben für Ergebnisse spezifiziert?
  • Ist der Initialzustand des Systems definiert?
  • Sind alle benötigten Initialisierungsoperationen spezifiziert?
  • Gibt es Anforderungen für die Gültigkeitsprüfungen von Eingabedaten?
  • Sind die Anforderungen verständlich für jene, die den Entwurf durchführen müssen?
  • Sind die Anforderungen überspezifiziert?
  • Wurden Anforderungen für spätere Erweiterungen spezifiziert und sind diese Anforderungen speziell gekennzeichnet?
  • Wurden die notwendigen Erfahrungen bzw. Ausbildungsbedürfnisse des Bedienpersonals spezifiziert?

Viele Werkzeuge zum Erstellen und Pflegen einer Anforderungsdefinition besitzen Prüffunktionen, die die Prüfung obiger Fragestellungen unterstützen können.

Entwurfsreviews

Je nach Art des Entwurfs unterscheidet man Grobentwurfsreviews (preliminary design reviews) und Feinentwurfsreviews (critical design reviews). Folgende Ziele werden durch Entwurfsreviews verfolgt:

  1. Feststellen und Bewerten des jeweiligen Zustands eines Entwurfs (Merkmal Vollständigkeit)
  2. Aufdecken von Fehlern und Widersprüchlichkeiten
    1. Widerspruch zwischen der Spezifikation und dem Entwurf
    2. interne Entwurfswidersprüche, z.B. Widersprüche zwischen Modulschnittstellen

Wir geben im Folgenden eine Checkliste für Grobentwurfsreviews an:

Performance

  • Gibt es Hinweise auf die Nichterfüllung von Performance-Anforderungen?

Benutzerschnittstelle

  • Sind die Layouts der Benutzerschnittstellen einheitlich?
  • Sind die Bildschirmmasken mit Informationen nicht überladen?
  • Sind die Bildschirmausgaben übersichtlich?
  • Ist die Benutzerführung ausreichend?
  • Sind die Benutzereingaben auf ein Minimum beschränkt?

Daten

  • Wurde das Datenmodell geprüft?
  • Gibt es fehlende oder nicht benutzte Variablen in einem Input-, Output- oder Update-Modul?
  • Gibt es falsche oder fehlende Datentypen in einem Input-, Output- oder Update-Modul?

Schnittstellen (bei älteren 3. Generationssprachen)

  • Gibt es einen Programmaufruf zu viel oder zu wenig in einem Verarbeitungsteil? Bei modernen Sprachen wie Modula-2 oder Ada bieten der Compiler und das Laufzeitsystem ausreichende Schnittstellenprüfungen, um diese Art von Fehlern zu lokalisieren oder zu verhindern.

Funktionalität

  • Ist in einem Verarbeitungsmodul ein Teil nicht vorhanden, überflüssig oder falsch?
  • Sind in einem Verarbeitungsmodul logische Bedingungen nicht vorhanden, überflüssig oder falsch formuliert?

Dokumentation

  • Ist die Entwurfsbeschreibung unvollständig?
  • Ist die Entwurfsbeschreibung mehrdeutig?
  • Sind die Algorithmen eines Moduls nicht klar spezifiziert?

Standards

  • Ist ein relevanter Entwicklungsstandard des Projekthandbuchs nicht eingehalten worden?

Syntax der Entwurfsbeschreibung

  • Wurde die Entwurfsnotation syntaktisch korrekt verwendet?
  • Enthält die Entwurfsbeschreibung Rechtschreibfehler?

Diverses

  • Gibt es andere Fehler, die nicht zu einem der oben angegebenen Typen gehören?

Für Feinentwurfsreviews existieren ähnliche Checklisten.

Code-Inspektionen

Bereits im Jahre 1972 wurden bei IBM Code-Inspektionen eingeführt [Faga76]. Die Absicht war, einerseits die Software-Qualität zu verbessern und andererseits die Produktivität der Programmierer zu steigern. Eine weitere Zielsetzung von Code-Inspektionen ist die Überprüfung des Codes auf Übereinstimmung mit dem Feinentwurf. Ebenso wird diese Art von Reviews verwendet, um die Einhaltung von Programmierrichtlinien und Codierstandards zu überprüfen.

Mögliche Prüfbereiche bei einer Code-Inspektion sind:

  • Schnittstellen des Prüfobjekts,
  • Ablaufstruktur des Programms,
  • die Verwendung von Variablen bzw. deren Namen,
  • Berechnungsformeln,
  • Ein-/Ausgabe,
  • Kommentare,
  • Einhaltung der Codierstandards.

Eine wichtige Voraussetzung bei der Durchführung von Code-Inspektionen ist die Fähigkeit, Code richtig lesen zu können. In diesem Zusammenhang sind einige interessante Fakten zu nennen:

  • Progammierer haben oft Probleme mit der Anerkennung ihrer Arbeit. Der Grund dafür besteht darin, dass der Quellcode von niemandem gelesen wird. Die korrekte Ausführung des Programmes ist oft zu wenig, um Programmierer zu motivieren, eine bessere Arbeit zu leisten. Durch Code-Inspektionen wird hier Abhilfe geleistet.
  • Das Lesen von Code sollte vor dem Schreiben von Code gelehrt werden. Dies führt zu leichter lesbarem Code.

Gute Lesbarkeit des Codes erreicht man dadurch, dass beim Schreiben des Codes eine einfache, klare und logische Struktur entworfen wird. Trickreiche Programme sind schwierig zu lesen.

Beim Lesen eines Programmes sind folgende Regeln zu beachten:

  1. Aufmerksamkeit schenkt man zuerst der Struktur des Programms.
  2. Ein erkannter Fehler ist noch kein Indiz, dass keine weiteren Fehler existieren.
  3. Auch Kommentare können fehlerhaft sein.
  4. Bei schwer lesbarem Code ist eine Untersuchung der Ursachen durchzuführen.
  5. Beim Lesen von Code sind alle Details von Bedeutung.
  6. Beim Lesen von Code ist nichts als wahr anzunehmen, wenn es nicht zuvor geprüft wurde.

Untersuchungen [Faga86] zeigen, dass ca. 2/3 der Programmierfehler vor dem Modultest bereits gefunden werden können und dass in Programmen, die einer Code-Inspektion unterzogen worden sind, um ca. 40 % weniger Fehler enthalten sind. Dabei wurde eine 7-monatige Betriebsphase nach Abnahme des Produkts untersucht.

Testreviews

Wir unterscheiden zwei Arten von Reviews für das Testen, nämlich Testentwurfsreviews und Testinspektionen (Testkonferenzen).

Die Zielsetzung von Testentwurfsreviews ist die Überprüfung der Übereinstimmung des Testentwurfs mit den Testzielen. Jeder Testfall sollte einer Vollständigkeitsprüfung unterzogen werden. Dabei sind folgende Fragen zu beantworten:

  • Welche Eigenschaften des Testobjekts sollen geprüft werden?
  • Wurden alle Testziele des Testplans bei der Erstellung des Testfalles für das Testobjekt berücksichtigt?
  • Wurden die Testfälle so gewählt, dass auch wirtschaftliche Aspekte bei der Erreichung der Testziele berücksichtigt werden?
  • Welche Umgebung ist für die Testfallausführung notwendig?
  • Wie bekommt das Testobjekt welche Eingabewerte zur Verfügung gestellt?
  • Welche Ausgabewerte (Sollwerte) sind zu erwarten?

Die Ziele bei der Testinspektion sind:

  • Begutachtung und Revidieren von Testfällen;
  • Prüfung der korrekten Durchführung des Tests laut Testprozedur und Testprotokoll;
  • Aufdecken von Mängeln in Schnittstellenspezifikationen einzelner Module;
  • Besprechung des Erfolgs der Einzeltests.

Bei dieser Art von Review geht es prinzipiell darum, den Erfolg der Testaktivitäten zu untersuchen. Der Durchführungszeitpunkt für die Testinspektion: nach der Testdurchführung.

Zusammenfassende Bewertung

Erfahrungen der letzten Jahrzehnte haben gezeigt, dass Reviews eine sehr wirksame Fehlerentdeckungsmethode sind. Die Wirksamkeit der Reviews ist durch folgende Fakten bedingt:

  • Vier Augen sehen mehr als zwei.
  • Bei der Erklärung seiner Arbeit bemerkt der Entwickler oft selbst Unstimmigkeiten.
  • Die an der Entwicklung nicht beteiligten Prüfer hinterfragen Sachverhalte, die dem Entwickler durch seine eingeschränkte Sicht auf das Prüfobjekt nicht naheliegen.

Die Fehlerentdeckungsraten liegen bei 60 bis 90% vor Abnahme der Software [Faga86]. Reviews liefern dem Programmierer sehr gute Hinweise für die Verbesserung seiner zukünftigen Arbeit.

Die Kosten für Entwurfs- und Code-Inspektionen zusammen werden mit ca. 15% der Projektkosten geschätzt.

Folgende Vorteile lassen sich beim Einsatz von Reviews feststellen:

  • Durch Reviews können die menschlichen Denk- und Analysefähigkeiten (kognitive Fähigkeiten) zur Bewertung und Prüfung komplexer Sachverhalte genutzt werden.
  • Reviews eignen sich sowohl für formale (z.B. Code-Listing) als auch informale Dokumente (z.B. verbale Entwurfsbeschreibungen).
  • Reviews sind Prüfverfahren mit einer hohen Erfolgsquote.

Als Nachteile beim Einsatz von Reviews sehen wir:

  • Der Erfolg eines Reviews ist stark personenabhängig. Insbesondere ist die Moderatorrolle von entscheidender Bedeutung.
  • Das Gesprächsklima ist wichtig für die Aktivierung der menschlichen Denk- und Analysefähigkeiten.
  • Das Abgleiten in Problemlösungen kann dazu führen, dass die kostbare Reviewzeit verstreicht und keine weiteren Mängel mehr entdeckt werden.
  • Die Gefahr der Mitarbeiterbeurteilung ist gegeben. Darunter kann die Akzeptanz dieses sehr nützlichen Prüfverfahrens leiden.

Die Bedeutung von Reviews im Entwicklungsprozess wird oft unterschätzt. Die wesentlichen Auswirkungen auf den Entwicklungsprozess sind:

  • frühe und umfassende Mängelentdeckung;
  • kostensparende Mängelverhütung;
  • wirksame Kontrolle und Steuerung des Entwicklungsprozesses;
  • Steigerung der Produktivität durch Reduzierung des Testaufwands;
  • Verbreitung des Know-hows über die Reviewobjekte;
  • Zwang zu sauberer Dokumentation.

Durch den Einsatz statischer Analysatoren lässt sich die Effizienz von Reviews noch weiter steigern. Somit sind Fehlerraten von weniger als einem Fehler pro 10000 LOC realisierbar.

Auszug aus
Ernest Wallmüller

Software Quality Engineering

07/2011, 426 Seiten, € 31,99
ISBN: 978-3-446-43019-8
S. 257 - 271
Literaturhinweis

[Basi96] Basili V. R.: The Empirical Investigation of Perspective-Based Reading; Empirical Software Engineering, Vol. 1, No. 2, 1996, pp. 133–164.

[Basi00] Basili V. R., Shull F., Rus I.: How Perspective-Based Reading Can Improve Requirements Inspections; IEEE Computer, July 2000, pp. 73–79.

[Boeh84] [Boeh84] Boehm B., et al.: A Software Development Environment for Improving Productivity; IEEE Computer, June 1984, pp. 30–43.

[Buck81] Buck F.: Indicators of Quality Inspections; IBM Tech. Report IBM TR21.802, Sept. 1981.

[Faga76] Fagan M.: Design and code inspections to reduce errors in program development; IBM Systems Journal, Vol. 15, No. 3, 1976.

[Faga86] Fagan M.: Advances in Software Inspections; IEEE Transactions on Software Engineering, SE-12, No. 7, 1986.

[Klei00] Klein B.: QS-Technologien für die Euro-Konvertierung bei Allianz Leben; SQM-2000, Tagungsband.

[Parn85] Parnas D.: Active Design Reviews: Principles and Practices; IEEE Proc. of 8th Int. Conf. on Software Engineering, London, 1985.

[Schn88] Schnurer K.: Programminspektionen; Informatik-Spektrum 11, 1988, pp. 312–322.

[Wein84] Weinberg G. M., Freedman D. P.: Reviews, Walkthroughs, and Inspections; IEEE Transactions on Software Engineering, SE-10, No. 1, 1984, pp. 68–72.

DIN EN ISO 9001:2015

Zum ISO 9001:2015 Special

Prozesswelt

Serie zum Thema Prozesse, veröffentlicht von QM-Experten deutscher Unternehmen gemeinsam mit der N5 GmbH und der Fachzeitschrift QZ

Zur Prozesswelt