Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

25.09.1992 - 

Qualitätssicherung bei der Programmentwicklung

Verfahren der Kfz-Branche auch für SW-Projekte geeignet

Wolfgang Redtenbacher ist Entwicklungsleiter von Redtenbacher Software, Rennigen, und Mitglied des Normenausschusses für Programmiersprachen bei der Internationalen Standardisierungsorganisation (ISO).

Die Binnenweisheit, wonach ein Softwareprogramm niemals fehlerfrei ist, enthebt den Entwickler nicht der Pflicht, sein Produkt in möglichst korrektem Zustand auszuliefern. Wolfgang Redtenbacher beschreibt ein Verfahren, das aus der Kfz-Industrie übernommen wurde und auch mit bescheidenen Mitteln eine Qualitätssicherung auf relativ hohem Niveau erlaubt.

In einer Presseverlautbarung forderte die Deutsche Angestelltengewerkschaft (DAG) kürzlich "benutzerfreundlichere Software, die auch Fehleingaben verkraftet und auf Bedienungsfehler nicht mit einem Absturz reagiert". Offenbar ist dies nicht selbstverständlich, sondern hat ausgerechnet die innovative DV-Branche Probleme mit der Produktqualität.

Ein professionelles Softwareprodukt umfaßt heute zwischen 10 000 und 200 000 Programmzeilen. Das entspricht dem Umfang von ein bis 20 Büchern. Ein einziger Tippfehler - ein vergessenes Sternchen oder Komma beispielsweise - kann bereits das Programmverhalten verändern und einen Absturz bewirken.

Aus diesem Grund lehnen viele Softwarehersteller eine Garantie für ihre Programme ab und schreiben in ihre Lizenzverträge Klauseln wie diese: "Nach dem heutigen Stand der Technik ist es nicht möglich, fehlerfreie Software zu entwickeln..."

Ob nach dem Produkthaftungsgesetz vom 1. Januar 1990 eine derartige Ablehnung jeglicher Garantie noch rechtskräftig ist, darf wohl bezweifelt werden. Aber auch ohne Schadenersatz-Prozesse können Softwarefehler die Marktposition eines Unternehmens beträchtlich schwächen.

Diese schmerzliche Erfahrung mußte zum Beispiel der amerikanische Datenbankhersteller Ashton-Tate machen. Die fehlerhafte Version 4.0 des Datenbanksystems Dbase verärgerte viele Kunden, und Ashton-Tate verlor innerhalb eines einzigen Jahres über 30 Prozent seines früheren Marktanteils, büßte also die zuvor unumstrittene Führungsrolle in diesem Bereich ein.

Ähnliches wiederfuhr dem Betriebssystem OS/2, als dessen Version 1.0 in unfertigem Zustand freigegeben wurde. Obwohl in der heutigen Ausführung alle damaligen Mängel behoben sind, leidet OS/2 immer noch unter dem Vorurteil, ein instabiles und speicherfressendes Programm zu sein.

Drei Phasen der Entwicklung

Aus den oben genannten Beispielen wird bereits deutlich, daß die Qualitätssicherung mehr und mehr auch für die Software-Industrie zu einem Muß wird. Die Entwicklung neuer Software geschieht in drei Phasen, die jeweils eigene Verfahren zur Qualitätssicherung erfordern: Programmentwurf, Wahl der Programmiersprache und schließlich die eigentliche Programmcodierung.

Größere Softwarelösungen entstehen heute meist durch Teamarbeit. Daher wird ein Projekt in der Entwurfsphase nach dem Top-down-Prinzip in Teilaufgaben zergliedert, deren Beziehung zueinander dann genau festgelegt wird. Die Teilprojekte lassen sich unabhängig voneinander realisieren und anschließend zusammensetzen. Dieses Software-Engineering ist heute recht ausgereift.

Um Teamarbeit zu ermöglichen, erlauben moderne Programmiersprachen, Teile eines Programms getrennt voneinander zu schreiben und zu compilieren. Modula-2, der Nachfolger der Programmiersprache Pascal, geht dabei am weitesten und fängt bereits beim Compilieren die häufigsten Programmierfehler ab; dazu zählen Prozeduraufrufe mit falschen Parametern, falsche Adreßoperatoren oder nicht zusammenpassende Versionen der Programmodule.

Nach dem Vorbild von Modula-2 wurde mittlerweile auch die Sprache "C" nach internationalem Standard um sogenannte Prototypen erweitert, die das Aufdecken von Fehlern erheblich erleichtern.

Die Entscheidung für eine bestimmte Programmiersprache hängt von den Rahmenbedingungen eines Projekts ab. Muß ein Programm möglichst unverändert auf vielen unterschiedlichen Rechnerarchitekturen lauffähig sein, so wird heute wegen der breiten Verfügbarkeit oft "C" bevorzugt.

Dieser Vorteil wird allerdings mit einem deutlich höheren Qualitätssicherungsaufwand bei der Implementierung erkauft, da "C" nur über geringe Sicherheitsmechanismen verfügt. Für "lebenswichtige" Programme, sogenannte "Mission critical applications", bevorzugen die Entwickler daher Sprachen wie Pascal, Ada oder Modula-2.

Wenn Entwurf und Sprache feststehen, geht es an die Umsetzung der Programmidee in die Programmiersprache, also an die eigentliche Codierung. In diesem Bereich besteht eine erfolgreiche Qualitätssicherung aus mehreren Schritten: Nach Fertigstellung eines Projekts sieht der Autor oder ein anderer Programmierer häufig noch einmal den gesamten Code sorgfältig auf Trugschlüsse oder Codierungsfehler durch. Anschließend werden alle Programmfunktionen mit typischen Beispieldaten sowie mit extremen Eingabewerten getestet. Dazu gehören auch Testreihen, wie sie für die Software-Güteprüfungen des TÜV durchgeführt werden.

Der nächste Schritt, die sogenannte Beta-Testphase, erfolgt im Praxiseinsatz bei ausgewählten Anwendern. Hier kann die Ablaufstabilität verifiziert und gegebenenfalls verbessert werden.

Für besonders "heikle" Software (wie zum Beispiel den Kern eines Großrechner-Betriebssystems) entwickelte die IBM ein aufwendiges Verfahren, bei dem der Programmautor seinen Quellcode einer Gruppe von Systemprogrammierern Befehl für Befehl erklären und begründen muß. Die Zuhörer halten dabei nach eventuellen Lücken, Denkfehlern oder Trugschlüssen Ausschau. Dieses Verfahren deckte Programmfehler sehr erfolgreich auf, erwies sich aber - wegen des hohen Aufwands - als nicht generell einsetzbar.

Um auch mit begrenzten Mitteln ein hohes Qualitätsniveau zu erreichen, wird mittlerweile bei einigen Softwareprojekten ein Verfahren verwendet, das in der Kfz-Industrie für die Fahrzeugsicherheit sorgt: die "Fehlermöglichkeits- und Einflußanalyse" (FMEA).

Diese ursprünglich von der US-Raumfahrtbehörde NASA entwickelte Methode kombiniert die Erfahrung von Fachleuten mit bestimmten Leitfragen, um potentielle Schwachstellen eines neuen Produkts in einem möglichst frühen Stadium aufzudecken.

FMEA-Schritte durch multidisziplinäres Team

Dazu führt ein multidisziplinäres Arbeitsteam - bei Softwareprojekten sind zum Beispiel die Bereiche Entwicklung, Dokumentation, Anwenderbetreuung/Hotline und Schulung betroffen - die FMEA-Schritte durch. Nachdem Aufgabenstellungen und Zielsetzungen (Pflichtenheft) festgelegt sind, werden alle Komponenten des Produkts zusammengestellt und ihre Funktionen aufgelistet.

Aus diesen Funktionen lassen sich wiederum die potentiellen Fehlerarten ableiten und die möglichen Auswirkungen auf das System beziehungsweise den Kunden sowie alle denkbaren Fehlerursachen ermitteln. Beim Druckmodul eines Textverarbeitungsprogramms wäre als Fehlerursache neben Programm- und Benutzerfehlern zum Beispiel auch die Situation zu berücksichtigen, daß der Drucker "offline" oder gar nicht eingeschaltet ist.

Risiko ermittelt aus Fehlerwerten

Jeder mögliche Fehler wird nach den drei Aspekten Schwere der Auswirkung (S), Entdeckungswahrscheinlichkeit vor Auslieferung des Produkts (E) und Wahrscheinlichkeit des Auftretens (A) mit einem Wert zwischen 1 und 10 bewertet. Ein Fehler, der zu einer vom Kunden kaum bemerkten Reaktionsverzögerung des Systems führt, würde zum Beispiel den Wert S;1 erhalten. Führt ein Fehler zu Datenverlust oder - zum Beispiel in der Buchhaltung - zur Verletzung gesetzlicher Vorschriften, so wird er hingegen mit S;10 als "äußerst schwerwiegend" eingestuft.

Aus den drei Einzelwerten für die Kriterien S, E und A läßt sich jeweils eine "Risikozahl" errechnen. Wenn alle denkbaren Fehler nach diesen Risikozahlen geordnet werden, treten die Bereiche hervor, auf die sich die Prüfung und Verbesserung konzentrieren sollte. So können die vorhandenen Mittel effektiv eingesetzt werden, um das Produkt aus ganzheitlicher Sicht für den Kunden zu optimieren.

Die ersten Erfahrungen, die im Softwarebereich mit der FMEA gemacht wurden, sind recht vielversprechend. Sie zeigen, daß auch in diesem Bereich effektive Schritte zur Qualitätssteigerung möglich sind.

Findet dieses Verfahren allgemeine Verbreitung, so können die Softwarehersteller künftig vielleicht Lizenzverträge mit ihren Kunden schließen, die etwas mehr Selbstbewußtsein verraten als bisher.