Die Qualität von Software ist zu erzeugen - sie kann nicht in ein Produkt hineingeprüft werden. Vorschläge, bei deren Befolgung die Qualitätssicherung nicht dem Zufall überlassen bleibt, macht Bernhard Murtz*. Zu Anfang eines Entwicklungsprojektes, so der Autor, ist ein Qualitätssicherungs-Plan zu erstellen, in dem die meßbaren Eigenschaften der zu schaffenden Software festgeschrieben sind.

Über die Qualität eines DV-Systems entscheidet, wie bei allen Produkten, der Kunde, der es kauft. Allerdings kommt das Qualitätsurteil eines Anwenders über ein Softwareprodukt zu spät für alle qualitätsverbessernden Maßnahmen. Nachträgliche Korrekturen oder Änderungen an fertiggestellter Software bedeuten ein Vielfaches an Entwicklungsaufwand gegenüber dem, was im normalen Lebenszyklus notwendig gewesen wären.

Das Bestreben der Softwareentwicklung geht deshalb dahin, auf ein definiertes Qualitätsziel hinzusteuern. Aber, was nicht meßbar ist, kann auch nicht kontrolliert beziehungsweise gesteuert werden. Zu allererst muß also die Qualität eines DV-Systems beziehungsweise der Software in Form von meßbaren Eigenschaften formuliert werden. (Siehe Beispiel in Abbildung 1)

Erst nach Festlegung konkreter Ziele auf Basis dieser Eigenschaften lassen sich angemessene Maßnahmen zur Sicherung und zum Nachweis der Qualität planen. Diese Planung findet zum Anfang eines Projekts statt und liefert als Ergebnis einen Qualitätssicherungs-Plan.

Die Definition quantifizierbare Ziele ist überaus schwierig. Wie läßt sich zum Beispiel die Verständlichkeit eines Dokuments messen. In der Praxis hat sich ein pragmatischer Ansatz bewährt, denn im wesentlichen kommt es darauf an, ein von allen Beteiligten getragenes Ziel und ein realistisches Meßverfahren aufzuschreiben. Andernfalls gilt die Aussage von Watts S. Humphrey: "without quality plans, only you are committed to quality."

Ein solches Meßverfahren muß mindestens die zu messen de Kenngröße, die Meßmethode und das Meßobjekt festlegen. Eine Betrachtung früher genesener Werte der Kenngröße überprüfen die Machbarkeit der Zielsetzung. Die Verständlichkeit eines Dokumentes zwar nicht den theoretischen Anforderungen der Maßtheorie entsprochen, doch der Zweck wird mit ausreichender Sicherheit erfüllt.

"Die Qualität eines Produktes kann nicht nachträglich geschaffen werden (Dijkstra). Qualität ist also zu erzeugen; sie kann nicht in ein Produkt hineingeprüft werden. Demzufolge sind geeignete Maßnahmen zur Verwirklichung einer definierten Qualität rechtzeitig zu planen. Diese werden dann im Qualitätssicherungs-Plan festgeschrieben. Die Eignung von Maßnahmen in einem Projekt wird anhand der Qualitätsziele überprüft.

Unter qualitätssichernde Aktivitäten fallen einerseits konstruktive und andererseits analytische Maßnahmen. Konstruktive sollen vorbeugen und bei der Erzeugung von Qualität unterstützen. Analytische Maßnahmen werden zur Überprüfung der erreichten Qualitätsziele geplant.

Die Vergangenheit hat gezeigt, daß die Kosten für Analyse und Beseitigung von Fehlern exponentiell mit dem Zeitraum zwischen der Entstehung und dem Erkennen der Fehler ansteigt. Daraus folgt, daß vorbeugende Maßnahmen, wie die gezielte Auswahl von Werkzeugen und Methoden oder eine für das Projekt sinnvolle Phasenplanung, wirtschaftlich erfolgreicher sind als reine Qualitätsprüfungen. Aber erst ein auf das Projekt angepaßtes und ausgewogenes Zusammenspiel beider Aspekte bietet dem Projektverantwortlichen ein nutzbringendes Steuerinstrument.

Wer arbeitet, macht Fehler Bekanntlich sind dem menschlichen Intellekt Grenzen gesetzt, die durch die Komplexität heutiger Systeme häufig überschritten werden. Das darf allerdings nicht dazu führen, daß Fehler von vom herein akzeptiert werden. Konstruktive Qualitätssicherungs-Maßnahmen sollen helfen, Fehler am Entstehungsort zu vermeiden. So können zum Beispiel durch Einschränkungen der Freiheitsgrade einer Programmiersprache (Programinier-Richtlinie-) bekannte Fehlerquellen ausgeschlossen werden.

Die Programmiersprache C ist hierfür ein hervorragender Kandidat. Sie bietet neben dem Vorteil, auf einer Vielzahl von Plattformen verfügbar zu sein, eine enorme Flexibilität. Diese kann sowohl positiv als auch negativ zur Qualität der Programme beitragen. Eine C-Programmierrichtlinie ermöglicht unter anderem,

- durch das einheitliche Aussehen der Programme die Lesbarkeit zu erhöhen,

- durch das Verbot bestimmter Sprachkonstrukte (zum Beispiel doppelte Referenzen) bekannte Fehlerquellen auszuschließen,

- mit dem Umbenennen bestimmter Operatoren (zum Beispiel = =) die durch Schreibfehler entstehenden Bugs zu verringern. Die Einhaltung solcher Richtlinien zu überprüfen, kann heute mit den am Markt erhältlichen Werkzeugen automatisiert werden.

Ohne eine Anleitung dokumentiert der Entwickler seine Arbeiten soweit er dies für notwendig hält. Ob diese Dokumentation den Notwendigkeiten einer späteren Wartungsphase gerecht wird, ist dabei meistens Glücksache. Wie bei einer Programmierrichtlinie wirken sich auch bei der Dokumentation bindende Vorgaben, zum Beispiel an die Struktur und den Inhalt von Dokumenten (eine Dokumentationsrichtlinie), qualitätssteigernd auf deren Vollständigkeit aus. Wichtig ist in diesem Zusammenhang, daß alle Ergebnisse des Entwicklungsprozesses festgelegt und beschrieben werden.

Eine Dokumentationsrichtlinie findet nur dann Akzeptanz, wenn sie handhabbar und lesbar ist. So sollte sie weniger als 15 Seiten Text umfassen und mit vielen Anwendungsbeispielen versehen sein. Es lohnt sich auch, ein "echtes Dokument" als Vorzeigeexemplar zur Verfügung zu stellen.

"Was man nicht kennt, kann man nicht ändern" (Parnas). Analytische Qualitätssicherungs-Maßnahmen sollen die erreichte Qualität während des Entwicklungsprozesses messen und Korrekturschritte im Hinblick auf die geplante Qualität ermöglichen. Solche analytische Qualitätsicherungs-Maßnahmen sind zum Beispiel:

- Audits, eine Aktivität zur Prüfung der Angemessenheit, der Einhaltung vorgegebener Vorgehensweisen, Anweisungen und Standards sowie deren Wirksamkeit und Sinnhaftigkeit (ANSI-Norm);

- Reviews, ein mehr oder weniger formaler und geplanter Analyse- und Bewertungsprozeß von Projektergebnissen durch ein Team von Gutachtern (IEEE-Norm);

- Inspektionen, ein streng formaler geplanter Analyse- und Bewertungsprozeß von Projektergebnissen durch ein ausgewähltes Team;

- Softwaremessungen, die statische Analyse der Software (zum Beispiel Komplexität) mit Hilfe von Werkzeugen;

- Testen, das dynamische Prüfen von Programmen mit dem Ziel, Fehler zu finden.

In den letzten Jahren haben vor allem Inspektionen eine große Zahl von Anhängern gefunden. Die Erfahrungen zeigen, daß durch Inspektionen nicht nur der Programme (Codeinspektion), sondern aller Dokumente des Entwicklungsprozesses - 60 bis 80 Prozent der Fehler gefunden werden können. Ein Verfahren für Inspektionen, das auch in der Lage ist, Fehler im Entwicklungsprozeß aufzudecken, wird von T. Gilb in seinem Werk "Principies of Software Engineering Management", 1988, beschrieben.

Häufig werden große Erwartungen an Softwaremessungen (Metriken) gestellt. Ein Einsatz von Komplexitätsmaßen, wie sie von McCabe und Halstead definiert wurden, sind zur Bestimmung der Qualität allerdings nur sinnvoll, wenn sie beweisbar sind. Eine Komplexitätszahl muß also einer bestimmten Qualität zugeordnet werden. Solche Bewertungsmaßstäbe sind nur unternehmensspezifisch aufzustellen und bedürfen einer umfangreichen Analyse der im Unternehmen erstellten Produkte (Dokumente und Software). Dazu sind alle quantitativen und qualitativen Aspekte der Produkte beziehungsweise Projekte über einen längeren Zeitraum zu erfassen und zu verfolgen. Alle Maßnahmen zur Planung, Erzeugung und Kontrolle von Qualität sind von einer Reihe von Faktoren abhängig, deren unternehmensspezifische Analyse erst die Basis für ein eigenes Qualitätssicherungs-System bietet. Anforderungen an ein solches System sind durch die DIN 9000 hinreichend bekannt. Das System wird in einem Qualitätssicherungs-Handbuch verbindlich festgelegt. Darin enthalten sind unter anderem:

- Aufbau- und Ablauforganisation der Qualitätssicherung,

- Vorgehensmodelle,

- Festlegung der Erzeugnisse (Produkte) in Art, Inhalt, Struktur und Zusammenhängen,

- Richtlinien,

- Maßnahmen zur Überprüfung des Systems etc.