In allen Bereichen schreitet die Prozeßautomatisierung mit Riesenschritten voran. Dabei rückt die Software immer mehr in den Vordergrund, und muß aus Wirtschaftlichkeitsüberlegungen auch immer stärker unter die Lupe genommen werden. Der Softwareanteil der DV-Anwendungskosten lag im Jahre 1955 noch bei 10 Prozent, 1970 bei zirka 50 Prozent und wird im Jahre 1985 nach Schätzungen auf 90 Prozent der Gesamtkosten eines Projektes steigen. Dabei werden als Kosten nur Erstellungs- und Wartungskosten betrachtet.
Unter Software muß nicht nur das Programm als Summe aller Maschinenbefehle verstanden werden, sondern auch sämtliche Dokumente aus der Mensch-Mensch-Kommunikation. Das beinhaltet die Entwickungsdokumente (Pflichtenheft bis Testdokumentation) als auch die Benutzungsdokumente (Managemententscheidungen bis Rechenzentrumsanweisungen). Die Programme gliedern sich in anwendungsbezogene und systembezogene Teile auf.
Was versteht man nun unter der Zuverlässigkeit dieser Software? Die DIN 40041 definiert wie folgt:
"Die Fähigkeit einer Betrachtungseinheit, innerhalb der vorgegebenen Grenzen denjenigen, durch den Verwendungszweck bedingten Anforderungen zu genügen, die an das Verhalten ihrer Eigenschaften während einer gegebenen Zeitdauer gestellt sind." Damit liegt die Abgrenzung des Begriffs Zuverlässigkeit zum verwandten Begriff Qualität nur in der Zeitbezogenheit. Verkürzt gesagt: Zuverlässigkeit ist Qualität auf Zeit.
Minimalprinzip oberstes Gebot
Diese vorgesehene Qualität auf Zeit im Sinne des Minimumsprinzips, nämlich mit möglichst wenig Kosten die Software zu erstellen und zu betreiben, muß das Ziel eines jeden Entwicklers und Anwenders sein. Um dieses Ziel zu erreichen, müssen die Kosten und die Kostenverteilung auf den gesamten Lebenszyklus von Software bekannt sein.
Softwarekosten lassen sich in mehrere große Pakete einteilen. Ein Paket umfaßt die Kosten, die durch Arbeiten an der Software entstehen - dies sind die Entwicklungs- und Wartungskosten. Ein weiteres Paket setzt sich aus Kosten zusammen, die durch Arbeiten mit der Software entstehen - dies sind die Betriebs- und Ausfallkosten. Ein schwer bewertbarer aber nicht zu vernachlässigender Teil sind Kosten durch fehlende Akzeptanz der Software.
Neuprogrammierung bei Spezifikationsfehlern
Die Aufwendungen für die Entwicklung betragen nur die Hälfte der Wartung. Die Maintenance um faßt nun selber vier Hauptaktivitäten: die Stabilisierung (25 Prozent), die Optimierung (15 Prozent), die Änderung (20 Prozent) und die Erweiterung (40 Prozent).
Die Stabilisierung beinhaltet die Fehlerbeseitigung, während Optimierung der Leistungssteigerung dient. Die Änderung und die Erweiterung haben fließende Grenzen und unterscheiden sich im wesentlichen durch den Umfang der durchzuführenden Wartungsmaßnahmen.
Die Behebung eines Code-Fehlers nach Integration des Systems kosten fünfmal soviel wie nach der Codierung und zehnmal soviel nach der Freigabe. Bei Entwurfsfehlern muß mit einem zehnfachen Aufwand nach der Integration und dem zwanzigfachen nach der Freigabe gerechnet werden. Spezifikationsfehler führen zu einer völligen Neuprogrammierung mit einem zusätzlichen Kostenaufwand von 150 Prozent der ursprünglichen Programmierung.
Mängel in den Quellprogrammen
Großprojekte haben gezeigt, daß zirka 60 Prozent aller Ausfälle von Rechnersystemen auf die Software zurückzuführen sind. Dies erklärt sich aus der Tatsache, daß bei dem heutigen Stand der Softwaretechnologie etwa zwei Prozent aller abgelieferten Quellprogrammbefehle fehlerhaft sind. Diese Fehler lassen sich wiederum in Anforderungsfehler und Entwurfsfehler (je 30 Prozent), sowie in Konstruktionsfehler (40 Prozent) unterteilen.
Die Fehler können zu Rufschäden bei den Softwareproduzenten, zu Vertrauensverlusten bei den Anwendern und eventuell zur Ablehnung durch Genehmigungsbehörden führen und sind in ihrer Auswirkung vorhersehend nicht quantifizierbar.
Eine höhere Zuverlässigkeit von Software wird erreicht, wenn weniger Qualitätsmängel während des Betriebs auftreten. Daher richtet sich bei dem Ziel einer hoch zuverlässigen Software das Augenmerk auf Qualitätssicherungsmaßnahmen.
Diese Maßnahmen gliedern sich entsprechend dem Lebenszyklus in die Spezifikationsabnahme, die Entwurfsbewertung, der statischen dynamischen Programmanalyse und die Systemrevision auf.
Die Spezifikationsabnahme beschäftigt sich mit einer formalen und einer fachlichen Prüfung. Dabei wird formal auf Vollständigkeit, Konsistenz und Plausibilität geprüft. Die fachliche Abnahme kann nur durch den Benutzer selbst oder einen äquivalenten Stellvertreter durchgeführt werden.
Die Entwurfsbewertung prüft das DV-technische Lösungskonzept und hat ebenfalls eine formale und eine technische Prüfung. Die statische und dynamische Analyse beschäftigt sich mit dem, was leider heute noch von den meisten Menschen als Software angesehen wird: dem Quellenprogramm. Im statischen Prüfabschnitt wird die Source selbst getestet, im dynamischen Teil wird das Ablaufverhalten geprüft.
Die Systemrevision beginnt dort, wo der Programmtest aufhört. Dabei wird integral das Gesamtsystem im Zusammenwirken mit der technischen Umgebung, der einzelnen Programme untereinander und mit den Endbenutzern geprüft.
Revisionsabteilung ist betriebsblind
Die absolute Voraussetzung dieser Qualitätssicherungsmaßnahmen ist ein Phasenkonzept oder ein Lebenszyklus für die Entwicklung und Wartung eines Softwaresystems. Dies muß mit organisatorischen Mitteln sichergestellt werden. Die Qualitätskontrolle kann dabei sowohl innerhalb des Hauses als auch außerhalb erfolgen. Bei der Herstellung von Software für den Eigenbedarf ist sicherlich eine interne Revision sinnvoll, obwohl auch diese aus den unterschiedlichsten Gründen eine "Betriebsblindheit" besitzt.
Bei der Herstellung von Software für einen anderen bietet sich eine externe Revision von alleine an. Nicht zuletzt sollte sich der Käufer von Software versichern, daß eine ordnungsgemäße Prüfung der Software stattgefunden hat. Diese Bemerkungen sind für die Hardware wohl schon lange eine Binsenweisheit.
Daß Sich in der Vergangenheit die Software solchen Qualitätssicherungen entzog, lag wohl daran, daß erst in letzter Zeit - aufgrund der Unzuverlässigkeit und der hohen Kosten - Software als ein Produkt aus besonderem Material angesehen wurde, welches einer ingenieurmäßigen Behandlung zugänglich ist.
Axel Stöhr ist Leiter der Zentralabteilung Mathematik, Programmierung und Softwarezuverlässigkeit beim Rheinisch-Westfälischen TÜV, Essen.