Entwicklungsbremse Qualitätsmanagement

Es mag an den Gegebenheiten der Software-Branche liegen; vielleicht daran, dass sich ein Stück Software in aller Regel nicht mit dem bloßen Auge durch Blickkontrolle auf vermeintliche Mängel begutachten lässt. Wäre das so, ließe sich das Thema Qualitätssicherung weitaus einfacher abwickeln und wäre nicht mit dem Aufwand verbunden, der typischerweise damit einhergeht.

Aufwand, den man sich bei kleineren Projekten oft erspart, um die verfügbaren Ressourcen nicht unnötig mit der Qualitätssicherung zu binden. Die sollen sich schließlich in erster Linie mit dem Entwickeln befassen. Dem allgegenwärtigen Zeitdruck glaubt man schon irgendwie Herr werden zu können. Das jedoch kann fatale Folgen haben, wie das Beispiel der G. GmbH zeigt:

Ein Auftraggeber betraute die G. GmbH damit, ein System für Außendienstmitarbeiter zu entwickeln, die mithilfe ihrer Notebooks Aufträge annehmen, Angebote erstellen und weitere Aufgaben kundenorientiert dezentral abwickeln sollten. Auf jedem Notebook war eine Datenbasis vorhanden, die regelmäßig in der Firmenzentrale mit der Datenbank abgeglichen werden sollten.

Weil die Systeme möglichst störungsfrei verfügbar sein sollten, beauftragte man ein externes Wartungsunternehmen, die Notebooks in festen Zeitabständen zu kontrollieren. Die darauf gespeicherten vertraulichen Daten mussten daher vor der Wartung gelöscht werden. Dem Anschein nach lief zunächst alles reibungslos: Die Datenbasis war der Größe und Struktur nach definiert, die Algorithmen zur Auswertung festgelegt, implementiert und getestet. Auch die Qualitätssicherung war bis zu diesem Zeitpunkt im üblichen Umfang eingebunden.

Die Entwicklungsdokumentation lag vor, auch Abnahmeprozeduren für Tests der Software-Module waren durchgeführt, sogar die Abnahme des Systems war erfolgt. Die letzte „Kleinigkeit“ bestand darin, dass im echten Betrieb beim Kunden die vertraulichen Daten auch vollständig zu löschen waren. Die ursprünglich dafür aufgesetzte Löschroutine war jedoch „so schlicht“, dass die Qualitätssicherung ihre Definition im Quellcode nicht eigens überprüfte.

Erst im Rahmen der Abnahme des Gesamtsystems stellte sich durch einen reinen Zufall heraus, dass sie über den eigentlichen begrenzten Zielbereich hinausging. Einem weiteren Zufall war es zu verdanken, dass während der Entwicklungsphase nie andere Anwendungsdaten gelöscht wurden und der Mangel so zunächst verborgen blieb. Da dieser letzte Abnahmetest am Ende der äußerst knapp bemessenen Qualitätssicherungsprozeduren lag, musste man die gesamte Abnahme nach der Korrektur wiederholen, was eine Verzögerung der Systemauslieferung um einen Monat bedeutete.

Und mit diesem verhältnismäßig kleinen Aufschub durfte man sich noch glücklich schätzen. Denn einzig der zufällige Umstand, dass man den Fehler überhaupt aufgespürt hatte, vermied hohe Folgeschäden: Im Produktivbetrieb auf Kundenseite hätte ein solches fehlerhaftes System operative Daten löschen und damit zum Crash führen können.

Die Konsequenz: immense Betriebsausfälle mit entsprechenden zusätzlichen Kosten. Dabei hätte eine simple Code-Inspektion mit dem Check der Definition des betreffenden Datenbereichs genügt, um diesen Fehler schon in der Codierungsphase zu entdecken und zu beheben. Der Knackpunkt bei diesem Projekt: Von vornherein glaubte man, es genüge, die Qualitätssicherung auf ein Minimum zu reduzieren, insbesondere auch weil die terminlichen Vorgaben eng gesteckt waren.

Doch gerade wenn der Faktor Zeit so knapp bemessen ist, gilt es, von Beginn an ein effektives Qualitätsmanagement zu etablieren, das sofort in das Projekt eingebunden ist, um als Kontrollinstanz früh auf potenzielle oder tatsächliche Fehler hinzuweisen. Denn dadurch lassen sich erhebliche Zeitverluste in einer späteren Phase verhindern, die dann die rechtzeitige Auslieferung oder die Funktionstüchtigkeit gefährden könnten.

Das Qualitätsmanagement besteht nicht darin, Tests für die verschiedenen Produktphasen zu erstellen und durchführen zu lassen. Vielmehr muss es sich von vorneherein zur Aufgabe setzen, in allen Entwicklungsschritten die Schnittstelle zwischen Anforderung und Realisierung zu sein. Am obigen Beispiel zeigt sich, dass eine Inspektion des Quellcodes durch Nichtentwickler eine größere Sicherheit bedeutet, weil sie nicht durch eine unkritische Sichtweise auf „offensichtlich triviale“ SW-Anteile eingeschränkt sind. Qualitätsmanagement beginnt beim Überprüfen der ersten Anforderungsdefinitionen:

Die Eindeutigkeit ist mitunter schwer festzustellen. Oft erstellen Personen die Spezifikationen, die die Realisierung nicht durchführen. Dass man nicht zu verschiedenen Lösungen durch verschiede Teile der Spezifikation gelangt, ist bei Algorithmen oft leichter nachzuweisen, wenn man die zugrunde liegenden mathematischen Methoden berücksichtigt. Handelt es sich nicht um einfach implementierbare Algorithmen, so müssen die Module mit etwa objektorientierten Modellen diesen Eindeutigkeitsanspruch nachweisen.

Hier bereits in der Analysephase mit Methoden des Qualitätsmanagements einzugreifen, ist ein wesentlicher Faktor für das Gelingen des Projekts. Bei der Realisierbarkeit ist während der Designphase mit der Software-Entwicklung Hand in Hand zu arbeiten. Möglichst frühzeitig sollte die Qualitätssicherung die Testsysteme, die der Abnahme dienen, festlegen und auf deren Übereinstimmung mit den Anforderungsdefinitionen sowie die Güte der Testabdeckung, wie etwa Variation aller Eingangsgrößen, überprüfen. Die Vollständigkeit ist ein weiterer komplexer Punkt.

Einerseits gilt es dabei darauf zu achten, dass sich alle Anforderungen wirklich vom fertigen System bearbeiten lassen. Andererseits muss man auch Einschränkungen zulassen. Was etwa leistet das System nicht? Aufgabe des Qualitätsmanagement ist es hier, exakt das sichtbar und transparent in der Dokumentation für den Anwender festzuhalten. Bei der Realisierung des Projektes sind aus Sicht der Qualitätssicherung folgende Kriterien anzuwenden:

Die ersten drei Punkte sind für jeden Entwickler sofort einsichtig. Die Frage nach der Konsistenz hingegen mag dann und wann Achselzucken hervorrufen. Zeigen lässt sich dieser Aspekt etwa anhand des obigen Beispiels: Der Fehler entstand, weil die formale Überprüfung auf unbeabsichtigte Nebenwirkungen eines an sich trivialen Vorgangs unterblieb.

Eben dies hätte eine umfassende Qualitätssicherung vermeiden müssen: Eine Überprüfung eventueller Überschreitung der Anwendungsgrenzen aller Teilsysteme hätte Abhilfe schaffen können. Kreativität der Entwicklung und formale Genauigkeit der Qualitätssicherung sind immer gemeinsam gefragt. Und genau hier sind auch beide aufeinander angewiesen.

Qualitätsmanagement ist kein abgehobener Prozess, der sich ohne eine konkrete Projektvorgabe aufsetzen lässt. Anzunehmen, es existierte ein immer gültiger fixer Maßnahmenkatalog, der jedes Projekt zum Erfolg führt, ist ein schwerer Fehler. Denn es gibt kein Qualitätsmanagement an sich, sondern nur Qualitätsmanagement in einem Projekt.

Die allgemeinen Regeln sind sozusagen als Rahmen vorgegeben; die Anwendung im Konkreten müssen immer neu anhand der Projektvorgaben und Ziele definiert werden. Qualitätsmanagement darf und soll sich nicht von Termin- oder Budgetvorgaben beeinflussen lassen – es ist, richtig eingesetzt, immer eine Kostenbremse, weil es Struktur schafft und Fehler vermeidet.

Denn jeder noch so kleine Flüchtigkeitsfehler kann sich zu einem handfesten Problem auswachsen, der zu Folgekosten in Form von Nachbesserungsarbeiten, etwaigen Schadensersatzansprüchen und natürlich auch ausbleibenden Folgeaufträgen aufgrund des Imageverlustes führen kann.