Qualitätsmanagement und Softwareentwicklung

Es ist nicht verwunderlich, dass die Qualitäts- und Quantitätssteigerung der Softwareentwicklung nicht mit dem überproportionalem Bedeutungszuwachs der Software mithalten kann, was unter anderem dazu führt, dass mehr als 50% der Produktionsausfälle auf Softwareprobleme zurückzuführen sind. (vgl. Teich 2002)

Deshalb stellt sich natürlich die Frage, warum nicht einfach mehr Software produziert und die Qualität verbessert wird, wie es auch bei der Produktion von anderen Waren gemacht wird.

Im Gegensatz zu anderen Produkten weist Software einige Besonderheiten auf, die Schwierigkeiten bereiten könnten:

Software ist, genau wie Literatur oder Musik, ein immaterielles Gut und sie baut auf Logik auf. Sie ist also schlecht darstellbar, man kann sich nur „hineindenken“, die Funktionsweise aber schlecht visuell oder hörbar, also passend für die menschlichen Sinne, darstellen.

Erschwerend kommt hinzu, dass Software nur durch die Hardware begrenzt wird, also theoretisch alles realisierbar ist, der Aufwand hierfür aber oft nicht mit dem Nutzen vereinbar ist.

Ein Praxistest an Hand von Beispieldaten ist auch nur bedingt möglich, da durch die enge Verknüpfung der Module Programme oft nur als Ganzes lauffähig sind, die Fehler erst in Folgemodulen sichtbar werden und oft auch nur bei bestimmten Datenkonstellationen auftreten.

Es kann also nur bewiesen werden, dass eine Software nicht fehlerfrei arbeitet. Allerdings trifft der Umkehrschluss, dass sie fehlerfrei arbeitet, wenn beim Test kein Fehler aufgetreten ist, häufig nicht zu.

Eine weitere Besonderheit ist, dass Software keiner Abnutzung unterliegt. Dies bedeutet zum einen, dass Softwarefehler immer Konstruktionsfehler sein müssen, zum anderen wird Software auch nicht kontinuierlich automatisch mit besseren Versionen ersetzt, wie es z.B. bei verbesserten Rezepturen von Rohstoffen der Fall ist, sondern eine Verbesserung muss immer explizit durchgeführt werden.

Auswirkungen von Fehlern bei der Softwareentwicklung sieht man deutlich am Beispiel der Ariane 5, die am 4. Juni 1996 auf Grund eines Softwarefehlers auf ihrem Jungfernflug explodierte. Die Entwicklungskosten für diese Rakete lagen zu diesem Zeitpunkt bei ca. 7 Milliarden $, der Verlust durch die Explosion betrug immerhin noch 500 Millionen $.

Die Analyse des Fehlers zeigt auch, wie komplex die Fehlervermeidung bei der Softwareentwicklung sein kann und dass ein gezieltes Wissensmanagement diesen Fehler wahrscheinlich hätte vermeiden können.

Bei einem Test des Trägheitssystems trat nacheinander in der Software sowie im Ersatzsystem der gleiche Fehler auf, der zum Abbruch des Programms führte, da eine Messgröße einen Wert erreicht hatte, der größer war als der maximal vorgesehene. (vgl. Jézéquel, Meyer)

Das Projekt wurde sorgfältig geplant und gemanagt, es lag ein technischer Fehler im Programm vor. Die Programmiersprache hätte eine Fehlerbehandlung für alle Variablen durchführen können, es wäre dann aber die Hardware stärker beansprucht worden und hätte das geforderte Limit überschritten. Eine Analyse bei der Programmierung ergab, dass so große Werte gar nicht auftreten können. Das Modul wurde aber schon für die Ariane 4 programmiert.

Das Gesamtprojekt wurde auch ausführlich getestet, das Problem bei Tests ist aber wie bereits erwähnt, dass man zwar Fehler nachweisen kann, aber nicht die Fehlerfreiheit eines Programms.

Der Fehler ist darauf zurückzuführen, dass bei der Wiederverwendung der Programmteile nicht darauf geachtet wurde, dass von vornherein genau die Spezifikationen und Voraussetzungen, die für die einzelnen Module zu Grunde gelegt wurden, dokumentiert waren.

Ein Ansatz der dies berücksichtigt ist Design by Contract, es werden Preconditions (Eintrittsbedingungen für das Softwaremodul) und Postconditions (Zustände, die nach Ausführen des Moduls zwingend eingetreten sind) beachtet.

Möglicherweise wäre es aber auch ausreichend gewesen, einen von den Punkten, die nicht für den Fehler „verantwortlich“ waren, sondern ihn nur unterstützt hatten, etwas zu verbessern und somit den Fehler zu vermeiden. Ausdrücklich ausschließen könnte man den Fehler so allerdings nicht.

Ein weiteres Beispiel ist das Versagen einer Patriot Rakete im Golfkrieg 1991, bei der die nicht abgefangene Scud-Rakete 28 Todesopfer forderte. Dabei handelt es sich um einen winzigen Rundungsfehler, der bei der Berechnung der Systemzeit entstanden ist. Dadurch, dass das System bereits 100 Stunden im Einsatz war, summierte sich der Fehler, was in Verbindung mit den hohen Geschwindigkeiten der Raketen dazu führte, dass die Flugroute für die Patriot falsch berechnet wurde und sie so die Scud-Rakete verfehlt hat. (vgl. Arnold 2000) Es ist also nötig, auch die späteren Einsatzbedingungen schon bei der Softwareentwicklung genau zu berücksichtigen.

Die bereits aufgeführten Besonderheiten können nicht verändert werden, es kann nur versucht werden, dafür bessere Lösungen zu finden als sie im Moment verwendet werden.