Software-Qualitätssicherung (QS) steckt weltweit In den Kinderschuhen. Sie ist bisher nicht über den Status eines Feigenblattes hinausgewachsen. Abgesehen von lapidaren Lippenbekenntnissen durch die verantwortlichen Führungskräfte führt sie ein Schattendasein in den meisten Unternehmen: Die Mehrzahl der deutschen Unternehmen hat keine zuständige Stelle für die Software-Qualitätssicherung.

Bundesdeutsche Unternehmen setzen keine QS-Werkzeuge ein, sie haben nur rudimentäre Standards und sie scheuen sich vor einer Kontrolle ihrer Mitarbeiter. Qualitäts- und Fehlerdaten werden nirgendwo erfaßt. Software-Metriken sind weitgehendst unbekannt. Wenn Software-Engineering die neue Religion der DV-Welt sein sollte, ist Deutschland ein Heidenreich mit einzelnen Inseln des Glaubens.

Daß dies jedoch nicht nur in Deutschland so ist, zeigt eine Untersuchung 108 amerikanischer Betriebe durch die American Society of Quality Control. Daraus ergaben sich folgende Ergebnisse:

- 74 Prozent der Betriebe haben immerhin eine Stelle für Qualitätssicherung;

- 23 Prozent des Personals in den QS-Stellen haben eine adäquate Ausbildung;

- 7 Prozent der Betriebe gehen nach dem Pareto-Gesetz vor, um die 20 Prozent der Problemsoftware zu identifizieren;

- 6 Prozent der Betriebe führen eine Fehleranalyse durch;

- 4 Prozent der Betriebe benutzen Software-Metriken;

- 13 Prozent der Betriebe erfassen die Kosten der Qualitätssicherung;

- 5 Prozent der Betriebe setzen QS-Werkzeuge ein.

Ed Yourdon führt diese negative Bilanz der Qualitätssicherung in den USA auf die Zurückhaltung der DV-Führung zurück. Sie möchte warten bis die Nutzen der Qualitätssicherung eindeutig bewiesen sind.

Ohne praktischen Einsatz lassen sich aber die Nutzen nicht beweisen. Somit bleibt alles beim alten.

Qualitätssicherung ist nach dem amerikanischen Verteidigungsministerium ein geplantes und systematisches Modell für alle Tätigkeiten, die erforderlich sind, um angemessenes Vertrauen zu erreichen daß der Gegenstand oder das Produkt den aufgestellten technischen Anforderungen entspricht. Durch die Qualitätssicherung muß folgendes bestätigt werden:

- das Produkt erfüllt die vorgegebenen Kundenforderungen;

-das Produkt stimmt mit den herrschenden Normen und Standards überein;

- das Produkt erhöht die Gesamtwirtschaftlichkeit;

- das Produkt ist ausreichend dokumentiert;

- das Produkt läßt sich mit möglichst wenig Aufwand pflegen.

Victor Basili und Dieter Rombach haben in ihrem IEEE-Software-Beitrag "Implementing Qualitative SQA: A Practical Model" die vier Schlüsselfragen der Software-Qualitätssicherung gestellt. Sie lauten:

- Was soll gesichert werden (was ist das Objekt der Qualitätssicherung)?

Antwort: Die Substanz "Software" einschließlich Programme, Spezifikationen, Dokumente und Testfälle.

- Wann soll gesichert werden (zu welchem Zeitpunkt im Entwicklungsprozeß soll geprüft werden)?

Antwort: Nach jeder Phase der Entwicklung gemäß dem Phasenmodell der IEEE.

- Womit soll gesichert werden (mit welchen Techniken und Werkzeugen wird die Qualität ach jeder Phase der Entwicklung gemäß dem Phasenmodell der IEEE.

- Womit soll gesichert werden (mit welchen Techniken und Werkzeugen wird die Qualität kontrolliert)?

Antwort: Spezifikationsanalysator, Entwurfsanalysator, Programmanalysator, Code-Auditor und Testwerkzeuge sowie Checklisten, Reviews und Inspektionen.

- Wer soll die Qualität sichern (welche Stellen sind für die Durchführung der Kontrollen verantwortlich)?

Antwort: Qualitätsbeauftragte beziehungsweise Testmanager in den Entwicklungs- und Wartungsprojekten sowie unabhängige, professionelle Testingenieure. Der Qualitätsbeauftragte in der Projektgruppe entspricht dem Pfarrer in der Gemeinde, der Unterstützung durch die zentrale Kirchenorganisation benötigt.

Software im weiteren Sinne umfaßt viel mehr als nur die maschinell verarbeitbaren Instruktionen und Daten. Harlan Mills von IBM definiert Software als die Summe aller Anweisungen an die Menschen und an die Maschinen sowie alle Dokumente zur Planung, Entwicklung, Verifikation, Validation, Wartung und Nutzung jener Anweisungen. Mills zufolge ist Software eine Substanz mit Größe, Komplexität, Densität und Dimensionalität, die an und für sich meßbar ist.

Basili schließt sich dieser Definition an. Für ihn ist Software ein "tangible product" mit eigenen physischen Eigenschaften wie Anzahl Anweisungen, Anzahl Daten, Anzahl Komponenten, Komplexität und Integrität. Diese Eigenschaften lassen sich durch Software-Metriken ausdrücken.

Nach dem IEEE-Standard umfaßt der Begriff "Software" Programme, Daten und alle dazugehörigen Dokumente: Requirements Specification, System Design, Program Documentation, Test Documentation und User Documentation. Im Prinzip läßt sich Software als Kommunikationsmittel nach dem Empfänger klassifizieren. Es gibt Kommunikationen mit Rechnern und Kommunikationen mit dem Menschen.

Am Rechner zeigt sich Software in der Gestalt von programmierten Anweisungen und gespeicherten Daten. Die programmierten Anweisungen gliedern sich wiederum in anwendungsbezogene Anweisungen und systembezogene Anweisungen. Anwendungsbezogene Anweisungen führen die fachlichen Funktionen aus. Systembezogene Anweisungen verwalten die Maschinenressourcen und stellen sie den fachlichen Funktionen zur Verfügung.

Das gleiche trifft für die Daten zu. Sie teilen sich in anwendungsbezogene und systembezogene Daten. Erstere ergeben fachliche Informationen für die Anwendung, systembezogene Daten über die Maschine und den Zustand der Software.

Software im engeren Sinne, als Mensch/Maschine-Kommunikation, besteht demnach aus Datenkapseln, Moduln und Kommandoprozeduren, wobei "Datenkapsel" anwendungs- und systembezogene Daten, Module anwendungs- und systembezogene Funktionen beinhalten können.

Software im weiteren Sinne, als Mensch/Maschine-Kommunikation, teilt sich in Benutzungsdokumente und Entwicklungsdokumente.

Benutzungsdokumente sind nach Adressatenkreisen gegliedert: Überblicksdokumente, Bedienungsanleitungen und Operationshandbücher. Überblicksdokumente informieren über den Zweck, die Funktion und die Zusammensetzung des Software-Systems. Bedienungsanleitungen erklären den Umgang mit dem Software-System für die Endbenutzer. Operationshandbücher erläutern, wie das Software-System zu installieren und in Betrieb zu halten ist und welcher Ressourcen es bedarf.

Entwicklungsdokumente repräsentieren die semantischen Ebenen der Software von der abstrakten Planungsebene bis zur detaillierten Testebene. Nach den Normen der IEEE gibt es hier mindestens die vier Dokumentenarten Requirements Specification, System Design, Program Documentation und Test Documentation. Für jede Dokumentenart bietet sich ein Standard an, der die Struktur und den Inhalt der jeweiligen Dokumentation festlegt.

Maßnahmen zur Qualitätssicherung

Bei der Software-Qualitätssicherung kommt es darauf an, die Güte und die Normengerechtigkeit aller obengenannten Elemente der Substanz "Software" zu ermitteln und zu beurteilen - sowohl die Programme und Daten als auch deren Dokumente. Dazu sind vor allem genormte Maßstäbe erforderlich.

Qualität muß auf jeder semantischen Ebene der Software-Entwicklung gesichert werden, denn zu warten bis das Software-Produkt fertig ist, ist nur bei Prototypenbau möglich. Qualitätssicherung ist daher eine projektbegleitende Tätigkeit, die sich auf die einzelnen Teilprodukte bezieht. Sobald ein Teilprodukt vorliegt, muß dessen Qualität gesichert werden. Die Notwendigkeit einer Qualitätskontrolle ist schließlich ein Hauptgrund für die Zerlegung des Software-Entwicklungsprozesses in mehrere Phasen mit entsprechenden Teilprodukten.

Die erste Maßnahme zur Sicherung der Software-Qualität ist deren Definition bei der Definition der Systemanforderungen. Hier müssen die einzelnen Qualitätsmerkmale identifiziert, benotet und gewichtet werden. Benotet werden sie auf der Skala von 0 bis 1, wobei die 0 die totale Abwesenheit der Qualität und 1 die totale Erfüllung dieser Eigenschaft bedeutet. Gewichtet werden sie durch die Verteilung einer festen Anzahl Punkte auf die einzelnen Qualitätsmerkmale. Damit sind die Qualitätsziele erstmals festgelegt.

Die zweite Maßnahme ist die Abnahme der Spezifikation beziehungsweise des Fachkonzepts. Diese Prüfung umfaßt drei Schritte. Im ersten Schritt wird die Spezifikationsdokumentation formal auf Vollständigkeit, Konsistenz und Plausibilität geprüft. Im zweiten Schritt wird der fachliche Inhalt beziehungsweise der fachliche Lösungsvorschlag von Fachexperten begutachtet. Im dritten Schritt wird die DV-technische Realisierbarkeit der fachlichen Lösung bestätigt.

Die dritte Maßnahme ist die Bewertung des technischen Systementwurfs. Diese Prüfung vollzieht sich ebenfalls in drei Schritten. Im ersten Schritt wird die Entwurfsdokumentation formal auf Vollständigkeit, Konsistenz und Einhaltung der Entwurfsrichtlinien geprüft. Im zweiten Schritt wird der Entwurf gegen die Spezifikation verifiziert, ob alle spezifizierten Funktionen, Daten und Beziehungen abgedeckt sind. Im dritten Schritt werden die technischen Maßeinheiten gemessen und mit den Sollmaßnahmen verglichen.

Die vierte Maßnahme ist die Prüfung der Programme, ebenfalls in drei Schritten. Im ersten Schritt werden die Programme kompiliert und dabei deren Syntax kontrolliert. Im zweiten Schritt werden die Programme gegen die Programmierkonvention geprüft, ob alle Regeln eingehalten sind. Im dritten Schritt wird die Struktur und der Inhalt der Programme mit dem Programmentwurf verglichen, um sicherzustellen, daß die Programme eine korrekte Wiedergabe des Entwurfs sind.

Die fünfte Maßnahme ist die Revision des Programmtests. Diese Prüfung hat nur einen Schritt, in dem die Testdeckung und die gefundenen Fehlerraten kontrolliert werden. Dabei werden sowohl die Programm- als auch die Datendeckung geprüft.

Die sechste Maßnahme ist die Revision des Systemtests. Diese Prüfung zielt darauf hin, die Systemdeckung und den Grad der Integration zu kontrollieren. Es werden Schnittstellen- und Funktionsdeckung sowie die Fehlerrate analysiert.

Die siebte und letzte Maßnahme ist die Abnahme des Systems. Hier wird das Software-Produkt mit der Dokumentation und der aktuellen Spezifikation verglichen, um zu gewährleisten, daß alle Software-Komponenten und Dokumente miteinander im Einklang sind.

Kosten der Qualitätssicherung

Aus Berichten von Betrieben wie IBM und TRW, die ernsthaft Qualitätssicherung betreiben, geht hervor, daß die Kosten bis zu 50 Prozent der Entwicklungskosten betragen können. Die Society of Quality Control ermittelte rund sieben Prozent. Dies würde bedeuten, daß die Kosten der Qualitätssicherung irgendwo zwischen 7 und 50 Prozent der Entwicklungskosten liegen.

Dieses Kostenverhältnis entspricht durchaus dem "Cocomo"-Modell von Barry Boehm, nach dem die Qualitätsanforderungen die Kosten um den Faktor 0,5 bis 1,5 erhöhen. Im Los Alamos Labor in New Mexico beträgt beispielsweise die Stärke des unabhängigen Testteams 50 Prozent des Entwicklungsteams. Dieses Team besteht aus professionellen Testingenieuren, deren einzige Aufgabe es ist, Fehler zu finden.

Bei den Kosten der Qualitätssicherung ist zwischen manueller und computerunterstützter Qualitätssicherung sowie zwischen Spezifikationsabnahme, Entwurfsbewertung, Programmprüfung, Programmtest und Systemtestversion zu unterscheiden. Danach verursacht eine manuelle Spezifikationsabnahme 12,5 Prozent der Spezifikationskosten. Durch den Einsatz von Prüfwerkzeugen können diese Kosten auf 9 Prozent reduziert werden.

Eine manuelle Entwurfsbewertung kann bis zu 34 Prozent des Entwurfsaufwandes verursachen. Durch den Einsatz von Prüfwerkzeugen ließe sich der Aufwand für die Entwurfsbewertung auf 7 Prozent drücken. Manuelle Programmprüfungen kosten bis zu 50 Prozent dessen, was die Programmierung selbst kostet. Mit dem Einsatz automatisierter Prüfwerkzeuge sinkt der Aufwand für die Programmprüfung auf nur 11 Prozent.

Ein systematischer Programmtest ohne Werkzeuge kostet das Doppelte wie die Programmierung selbst: Wenn für die Programmierung eines Moduls eine Mannwoche erforderlich ist, werden zwei Mannwochen für den Test des Moduls benötigt. Mit einer computergestützten Testumgebung kostet der Programmtest nach Ramamoorthy nur ein Drittel des Programmieraufwandes.

Schließlich kostet eine Systemtest-version ohne Hilfsmittel 34 Prozent des Testaufwandes - mit Hilfsmittel sind es nur 16 Prozent. Insgesamt erhöht eine manuelle Qualitätssicherung aller Phasen der Software-Entwicklung die Projektkosten um mindestens 35 Prozent. Diese Zahl liegt in der Mitte des oben abgesteckten Bereiches von 7 bis 50 Prozent. Eine computergestützte Qualitätssicherung würde jedoch die Projektkosten lediglich um 12 Prozent erhöhen. Damit liegt die computergestützte Qualitätssicherung in der Nähe der unteren Grenze des Kostenbereiches.

Daß Qualität nicht "free" ist, beweisen die Erfahrungsberichte von Fagan und Remer bei der IBM. Nach ihnen nehmen Design Reviews und Code-Inspektionen rund ein Viertel des Entwicklungsaufwandes in Anspruch. Und in dem "Cleanroom"-Projekt von Harlan Mills erfordern diese Prüftätigkeiten sogar ein Drittel der Projektzeit.

Es ist daher irreführend, wie Phil Crosby zu behaupten, "quality is free". Dies erweckt bei den zuständigen Managern den Eindruck, sie müßten dafür nichts ausgeben. Daß durch diese Kosten andere Kosten eingespart werden, steht auf einem anderen Blatt. Fest steht, daß Qualitätssicherung zunächst Geld kostet. Es wird Personal dafür ausgebildet und nur zu diesem Zweck eingesetzt. Es werden Richtlinien und Prüflisten verfaßt. Es werden Werkzeuge gekauft und gewartet. Schließlich wird die kostbare Zeit der Entwickler dafür in Anspruch genommen.

Es darf niemanden wundern, wenn durch den Einsatz eines Qualitätsprüfers in einer Projektgruppe von fünf Entwicklern die Kosten um mindestens 20 Prozent steigen. Wenn die Programme außerdem durch unabhängige Tester getestet werden, steigen die Kosten weiter um 33 Prozent. Die Frage ist, ob diese Mehrkosten durch eine Reduzierung der Entwicklungs- und Wartungskosten ausgeglichen werden.

Entwurf

Quantitative Maße

Ein Software-Entwurf beziehungsweise ein technisches Konzept hat quantitative Maßeinheiten wie die Anzahl der

- Dateien

- Datennachrichten

- Datenkapsel

- Datensichten

- Datenfelder

- Schlüssel

- Prozesse

- Programme

- Module

- Schnittstellen

- Abschnitte.

- Pseudo-Code-Anweisungen

Qualitative Maße

Die qualitativen Maßeinheiten eines Software-Entwurfs beziehungsweise eines technischen Konzeptes sind

- Datenunabhängigkeit

- Datenintegrität

- Datensicherheit

- Datenschutz

- Modularität

- Portabilität

- Flexibilität

- Komplexität

Programm

Quantitative Maße

Ein Programm hat quantitative Maßeinheiten wie die Anzahl der

- Anweisungen

- Prädikate

- Argumente

- Ergebnisse

- Datenreferenzen

- Parameter

- Datenfelder

- Steuerungsanweisungen

- I/0-Anweisungen

- Call-Anweisungen

- Ablaufzweige

- Ablaufpfade

Qualitative Maße

Die qualitativen Maßeinheiten eines Programms sind

- Portabilität

- Modularität

- Wartbarkeit

- Testbarkeit

- Strukturierbarkeit

- Wiederverwendbarkeit

Spezifikation

Quantitative Maße

Eine Spezifikation beziehungsweise ein Fachkonzept hat quantitative Maßeinheiten wie die Anzahl der

- Objekte

- Vorgänge

- Funktionen

- Bedingungen

- Daten

- Objekt/Objekt-Beziehungen

- Vorgang/Vorgang-Beziehungen

- Vorgang/Objekt-Beziehungen

- Funktion/Bedingung-Beziehungen

- Funktion/Daten-Beziehungen

- Daten/Bedingung-Beziehungen

Qualitative Maße

Die qualitativen Maßeinheiten einer Spezifikation beziehungsweise eines Fachkonzeptes sind

- funktionale Vollständigkeit

- informationale Vollständigkeit

- relationale Vollständigkeit

- Konsistenz

- Wiederverwendbarkeit

- Verständlichkeit

- Implementierungsgerechtigkeit

Test

Quantitative Maße

Der Test hat quantitative Maßeinheiten wie die Anzahl der

- Testdaten

- Testergebnisse

- Input-Assertions

- Output-Assertions

- Testfälle

- Testpfade

- Testzweige

- Testläufe

- Fehler

Qualitative Maße

Die qualitativen Maßeinheiten des Testes sind

- Programmdeckung

- Datendeckung

- Funktionsdeckung

- Fehlerrate

- Restfehler-wahrscheinlichkeit

Die Teilprodukte der Substanz "Software"

Software als Produkt besteht aus den Teilprodukten

- Spezifikation

- Entwurf

- Programm

-Test