Qualitätssicherung in der Software-Entwicklung Technische Reviews

Teil 1:
Rollen und Vorgehen

Je später ein Fehler während der Software-Entwicklung entdeckt wird, desto teurer ist es, ihn zu beheben. Es lohnt sich deshalb, bereits in den ersten Projektphasen mit der Qualitätssicherung zu beginnen. Eine geeignete Maßnahme hierfür sind technische Reviews. Olivier Sutz beschreibt im ersten Teil seines Artikels, wie technische Reviews ablaufen, wer daran beteiligt ist und wo die Erfolgsfaktoren liegen.

Download ZIPDownload ZIP
Download PDFDownload PDF

Qualitätssicherung in der Software-Entwicklung Technische Reviews

Teil 1:
Rollen und Vorgehen

Je später ein Fehler während der Software-Entwicklung entdeckt wird, desto teurer ist es, ihn zu beheben. Es lohnt sich deshalb, bereits in den ersten Projektphasen mit der Qualitätssicherung zu beginnen. Eine geeignete Maßnahme hierfür sind technische Reviews. Olivier Sutz beschreibt im ersten Teil seines Artikels, wie technische Reviews ablaufen, wer daran beteiligt ist und wo die Erfolgsfaktoren liegen.

Wir empfehlen zum Thema Controlling
1 Tag
09.10.2024
1,550,-
Ihr Schnellstart im Project Management Office

Projektchaos in Ihrem Unternehmen? Das lässt sich leicht vermeiden. Lernen Sie in zwei Tagen die Schlüsselelemente eines erfolgreichen Project Management Office (PMO) kennen und praktisch anwenden. Mehr Infos

Viele Organisationen prüfen erst in der Testphase, ob die von ihnen entwickelte Software den fachlichen und technischen Vorgaben entspricht. Sind diese Tests oberflächlich oder mangelhaft, werden manche Fehler erst während des produktiven Betriebs aufgedeckt. In diesen späten Stadien der Software-Entwicklung ist es sehr aufwändig und teuer, Fehler zu beheben. Es lohnt sich deshalb, Qualitätssicherungsmaßnahmen möglichst früh durchzuführen, am besten bereits schon vor der Testphase. Eine geeignete Maßnahme ist das "Technische Review" (hier: "Review"), das für die Prüfung von Dokumenten und Quelltexten eingesetzt wird. Verfügt eine Organisation über eine pragmatische Prüfplanung und ein reifes Projektmanagement, kann sie mit einem Review bis zu 25% der Gesamtprojektkosten eines Projekts einsparen.

In Teil 1 dieses Beitrags erfahren Sie, welche Vor- und Nachteile ein Review hat und wie es in der Praxis abläuft. Ergänzend werden zwei alternative Prüftechniken vorgestellt: die Code Inspection und der Walk Through. Vorab wird kurz beschrieben, welchen Platz das Review im Qualitätsmanagement der Software-Entwicklung einnimmt. In Teil 2 werden die Voraussetzungen für effiziente Reviews beschrieben, außerdem werden die Einsparungen, die Reviews ermöglichen, anhand von Beispielen vorgestellt.

Elemente des Qualitätsmanagements in der Software-Entwicklung

Die Elemente des Qualitätsmanagement-Systems (QMS) in der Software-Entwicklung sind:

  • Qualitätsplanung
    Die Qualitätsplanung ist eng mit der Projektplanung verknüpft. Sie umfasst alle Tätigkeiten, welche die Qualitätsziele und -forderungen festlegen sowie die Forderungen, welche die Anwendung der Elemente eines QMS betreffen. Anders formuliert: Die Qualitätsplanung identifiziert die für das Projekt geltenden Qualitätsstandards (Qualitätslenkung) und beschreibt, wie diese zu überprüfen und zu sichern sind (Qualitätssicherung). Das Hauptergebnis der Qualitätsplanung ist der Qualitätsmanagementplan, der im Weiteren auch die Ausführungsprozesse sowie die zugehörigen Ressourcen zur Erfüllung der Qualitätsziele definiert.
  • Qualitätslenkung
    Qualität zeigt sich als Übereinstimmung von Vorgaben und geprüften Ergebnissen. Qualitätslenkung bezeichnet demzufolge alle Maßnahmen wie Arbeitstechniken, Richtlinien etc. und Tätigkeiten, die ergriffen werden, um eine möglichst große Übereinstimmung zu erreichen. Das heißt: Qualitätslenkung ist Software Engineering live.
  • Qualitätssicherung
    Im Rahmen der Qualitätssicherung (auch Qualitätsprüfung genannt) wird überprüft, ob die Anforderungen an ein Arbeitsergebnis (und im Endeffekt an ein Produkt) erfüllt werden. Die so genannte "Analytische Qualitätssicherung" unterteilt sich in statische und dynamische Prüfungen. Zu den statischen Prüfungen zählen u.a. die Dokumentenprüfung sowie das Audit von Prozessen und Strukturen; Ziel ist es, Fehler möglichst früh zu erkennen. Dynamische Prüfungen umfassen alle Bereiche des Testens von Systemen und Teilen davon.

Das Technische Review gehört zu den statischen Prüfungen und ist darauf ausgelegt, Fehler zu einem frühen Zeitpunkt zu erkennen (Bild 1).

Bild 1: Einbettung des Reviews im QM-System.

Das Review

Das Review lehnt sich eng an die Design und Code Inspections an, wie sie von M. Fagan 1976 bei IBM Federal System Division eingeführt wurden. Die hier vorgestellte Methode orientiert sich an Freedman/Weinberg 1990.

Grundidee

Bei einem Review versucht ein Team von Gutachtern (Reviewer), in einem Dokument, Programm oder in einem anderen Software-Produkt sämtliche Fehler und anderweitigen Probleme zu identifizieren. Während einer formalisierten Review-Sitzung stellen die Gutachter ihre Erkenntnisse vor. Damit ein Review erfolgreich ist, müssen die Gutachter gut vorbereitet zur Sitzung erscheinen; d.h. sie müssen das Arbeitsergebnis, das ihnen vorgelegt wurde, gründlich geprüft und ihre Ergebnisse sorgfältig festgehalten haben. Die eigentliche Prüfung des Arbeitsergebnisses findet also in der Vorbereitungsphase statt; in der Review-Sitzung werden die Ergebnisse der Gutachter "lediglich" gesammelt und protokolliert. Der Autor des zur Prüfung vorgelegten Arbeitsergebnisses sucht anschließend gezielt nach Problemlösungen und setzt diese um.

Vor- und Nachteile

Ein Review bietet folgende Vorteile:

  • Hohe Qualität des geprüften Arbeitsergebnisses bzw. des Prüflings.
  • Ein Review lässt sich bereits in der ersten Projektphase durchführen. Fehler, Missverständnisse sowie fachliche und technische Sackgassen werden frühzeitig entdeckt. Dadurch sind Kosteneinsparungen bis zu 25% möglich.
  • Projektbeteiligte und andere Stakeholder werden als Gutachter, Moderatoren oder auch als Protokollführer aktiv einbezogen (auch projektübergreifend). Dadurch erfolgt ein Know-how-Transfer, außerdem kann die Zusammenarbeit der Beteiligten verbessert werden.
  • Individuelle Maßstäbe wie z.B. der Detaillierungsgrad eines Konzepts werden nivelliert.

Ein Review hat folgende Nachteile:

  • Die Gutachter benötigen für die Prüfung relativ lange (Vorbereitungszeit).
  • Gekaufte Software lässt sich nur teilweise einem Review unterziehen. (Ist beispielsweise kein Einblick in den Quellcode möglich, kann dieser nicht geprüft werden.)

Ablauf eines Reviews

Bild 2: Ein Review unterteilt sich in sechs Schritte.

Planung

Technische Reviews


Gleich kostenlos weiterlesen!

  • Zum Newsletter anmelden und diesen Artikel freischalten

  • Jede Woche neue Inhalte, Tipps und Tools per E-Mail
Gratis Newsletter bestellen & sofort weiterlesen

 

Hiermit melde ich mich zum Newsletter an. Ich habe die Datenschutzrichtlinien gelesen und akzeptiere diese. Ihre Daten nutzen wir ausschließlich zum Newsletter-Versand und der Messung von Öffnungs- und Klickraten. Sie können sich jederzeit abmelden, indem Sie auf den Link in der Fußzeile unserer E-Mails klicken. Informationen zu unserem Datenschutz finden Sie hier.

Fortsetzungen des Fachartikels

Teil 2:
Voraussetzungen und Rentabilität
Mit einem technischen Review ist es möglich, Fehler bei der Software-Entwicklung frühzeitig zu entdecken und teure Nachbesserungen zu vermeiden. Im ersten Teil dieses Beitrags beschrieb Olivier Sutz, wie ein Review in der Praxis abläuft.

Alle Kommentare (1)

Maud
Schlich

Ein sehr schöner Artikel mit einer gut ausgearbeiteten Case Study. Leider aber mit fachlichen Ungenauigkeiten: Laut IEEE Std 1028-2008 ist ein Technisches Review ein spezieller Reviewtyp (Autor nicht zwangsläufig beteiligt, Reviewziele auch Entscheidungen treffen, Konformität sicher stellen). Das hier beschriebene Review ist eine Inspektion (Reviewziel auch Prozessverbesserung), kein Technisches Review. Es wäre daher auch schön, wenn nicht Code Inspection mit dem Rest verglichen würde - dieser Vergleich ist wenig nützlich. Die Vorgehensweise in der Sitzung ist abhängig davon wie der jeweilige Moderator die Sitzung (alle Typen) leitet und nicht vom Reviewtyp selbst. Mehr Informationen finden sich neben der IEEE Std. 1028-2008 auch in den Lehrpländen des ISTQB Certified Tester CTFL und CTAL sowie in dem empfehlenswerten Buch von Gilb/Graham "Software Inspections". Für ein Review der nächsten Teile stehe ich dem Autor gerne zur Verfügung :-)