Schlamperei bei der Entwicklung kann sich böse rächen:

Nachträgliche Prüfung allein hat wenig Sinn

10.04.1987

Software-Qualität muß von Anfang an geplant werden. Sie nachträglich in ein Produkt "hineinzuprüfen", hat wenig Sinn. In der Praxis wird jedoch fast immer zu schnell. zu schlampig und ohne adäquate Mittel gearbeitet. Als Resultat nehmen die Probleme im SW-Wartungsbereich ständig zu. Harry Sneed* gibt in seinem Beitrag Tips, wie sich Qualität im Softwarebereich steigern läßt.

Qualität ist relativ zu dem, was man erreichen will. Aus der Sicht des Managements gibt es im Falle von Software-Systemen zwei Zielgruppen-Produzenten und Konsumenten. Insofern ist Software-Qualität relativ zu den Zielen der Konsumenten sowie zu denen der Produzenten. Der Konsument verlangt die Erfüllung kurzfristiger Forderungen wie Zuverlässigkeit, Sicherheit, Benutzerfreundlichkeit und Effizienz.

Erhaltungsaufwand kann ins Unermeßliche wachsen

Der Produzent hingegen strebt langfristig Wartungsfreundlichkeit, Übertragbarkeit und Erweiterbarkeit an. Beide Zielgruppen sind wichtig, die erste wegen der Akzeptanz, die zweite wegen der Wirtschaftlichkeit.

Das beststrukturierte, normierte und dokumentierte System ist wertlos, wenn der Anwender es nicht annimmt. Akzeptanz durch den Anwender setzt eine gewisse Stabilität, Sicherheit und Bedienungskomfort voraus. Wenn diese drei Voraussetzungen nicht erfüllt sind, wird keiner bereit sein, mit dem Produkt zu arbeiten. Dazu kommt die effiziente Nutzung der Maschinenressourcen-Zeit und Speicher. Ein System, das zu langsam oder zu speicheraufwendig ist, wird ebenfalls abgelehnt.

Bei komplexen Software-Systemen muß man davon ausgehen, daß sie fünf bis zehn Jahre leben werden. [n dieser Zeit werden sie mehrmals korrigiert, optimiert, geändert und erweitert. Außerdem besteht die Möglichkeit der Übertragung auf andere technische Umgebungen. Wenn nicht von Anfang an auf diese Ziele hingearbeitet wird, wächst der Aufwand zur Erhaltung des Software-Systems ins Unermeßliche. Deshalb muß der Produzent darauf achten, daß die Software pflegeleicht, änderbar, erweiterbar und übertragbar bleibt. Sonst werden die Kosten der Systemerhaltung untragbar.

Zuverlässigkeit ist die Abwesenheit von Fehlern im System. Gemessen wird sie daran, wie viele Bewegungen beziehungsweise Transaktionen fehlerfrei ausgeführt werden. Leider sind SW-Fehler nicht auszuschließen, solange der Mensch die Software entwickelt. Durch höhere Sprachen, bessere Kommunikation zwischen Anwendern und Entwicklern sowie durch Generatoren und wiederverwendbare Komponenten kann zwar die Fehlerrate reduziert werden, trotzdem bleiben "Macken" im System, die zu unerwünschten Ergebnissen führen. Die einzige Möglichkeit, die verbleibenden Fehler zu entfernen, ist durch einen systematischen Test gegeben.

Software muß sowohl verifiziert als auch validiert werden. Bei der Verifizierung handelt es sich um den Test, ob die Software korrekt ist; das heißt es wird geprüft auf die Übereinstimmung zwischen dem spezifizierten und dem tatsächlichen Programmverhalten. Die Software-Produktionsumgebung müßte eine eigene Assertionssprache zur Verifikation des Programmverhaltens enthalten. Damit werden nicht nur alle Programmeingaben generiert, sondern auch alle Programmausgaben bestätigt. Die Korrektheit der Programme läßt sich auf diese Weise systematisch nachprüfen.

Funktionsfähigkeit des SW-Systems wird geprüft

Die Validierung ist der Test, ob die Software mit ihrer Umgebung übereinstimmt, das heißt ob sie in der Produktion funktionsfähig ist. In der Software-Produktionsumgebung sind sowohl die Bewegungen und Transaktionen als auch die Stammdateien und Datenbanken zu generieren und zu validieren. Außerdem werden die Datenflüsse und Programmabläufe genau überwacht und protokolliert. Schließlich wird die Testdeckung der Programme und Daten zum Zwecke der Testrevision festgehalten.

Systemsicherheit hat zwei Aspekte. Zum einen wehrt sich das System gegen alle unberechtigten Eingriffe, zum anderen gegen alle fehlerhaften Eingaben. Im ersten Fall handelt es sich um böswillige Versuche, in das System einzubrechen, im zweiten um unbeabsichtigte Fehler bei der Eingabe. Das System muß also den unberechtigten Eingriff abwehren beziehungsweise die Fehler registrieren und melden.

Die Software-Produktionsumgebung müßte den ersten Zweck durch die eindeutige Spezifikation revisionsfähiger Datenschutzfunktionen erfüllen. Den zweiten Part kann sie durch Editmodule, in denen jedes Eingabedatum auf seine Plausibilität geprüft wird, sowie durch die standardmäßigen Fehlerbehandlungsroutinen abdecken. Recovery- und Restart-Funktionen sind als Standardbausteine in dem Programmrahmen vorzusehen.

Benutzerfreundlichkeit steht in engem Zusammenhang mit der Software-Ergonomie, und diese ist wiederum eine Frage der Zufriedenheit des Endbenutzers im Umgang mit dem System. Zwei Faktoren beeinflussen in der Hauptsache die Benutzerfreundlichkeit. Der erste ist die Gestaltung der Dialogschnittstelle. Die Bildschirmformate müssen für den Benutzer leicht zu verstehen und leicht zu bedienen sein. Die Art und Weise, wie ihn das System an die richtigen Formate heranführt, zum Beispiel per Menü oder Windowtechnik, ist ebenso wichtig. Schließlich sollte die Bildschirmschnittstelle ansehnlich sein, das heißt übersichtlich und ergonomisch.

Zweitens wird die Benutzerzufriedenheit durch die Gestaltung der Berichte bestimmt. Diese müssen in einer übersichtlichen, wohlstrukturierten Form sein, damit auch der Nichtkenner sie verstehen kann. Die Reports brauchen einen adäquaten Kopfteil sowie einen Fußteil, um die Liste eindeutig zu identifizieren. Darüber hinaus dürfen sie nur wenig Daten auf jedem Blatt haben. Die Gruppenwechsel und die Kontrollfelder müssen sich leicht erkennen lassen. Nicht zuletzt müßte es möglich sein,

die Kontrollsummen gesondert auszugeben.

Die sicherste Methode, Endbenutzer zufriedenzustellen ist, sie an der Gestaltung der Bildschirmformate und der Listenbilder zu beteiligen. Die Software-Produktionsumgebung sollte einen Belegeditor anbieten, mit dem jeder Laie Bildschirme und Listenbilder entwerfen kann. Für die Absprache mit den anderen Endbenutzern werden Belegmuster generiert, und zur Abstimmung der Dialogschnittstelle ließe sich der Dialog simulieren. Auf diese Weise bekommt der Endanwender einen repräsentativen Eindruck von dem, was auf ihn zukommt. Die Benutzerfreundlichkeit des Systems liegt sozusagen in den eigenen Händen.

Qualität des Design bestimmt Systemeffizienz

Auch die Effizienz hat zwei Seiten - die zeitliche und die räumliche. Zeiteffizienz ist die Minimierung des Zeitbedarfs, wobei man hier zwischen der CPU-Zeit und der Systemzeit unterscheiden muß. Interessant für den Benutzer sind Response-Zeit bei Online-Anwendungen und gesamte Laufzeit bei Batch-Anwendungen. Systeme mit einem schlechten Zeitverhalten haben kaum eine Chance, akzeptiert zu werden. Das gleiche trifft für die Raumeffizienz zu. Produkte, die einen zu großen Speicherbedarf haben, verdrängen nicht nur andere Systeme; sie verursachen auch zu viel Page-Swapping, was wiederum zu einem höheren Zeitbedarf führt. Effizienz ist eben für viele Anwendungen unabdingbar.

Eine Software-Produktionsumgebung kann am wenigsten zur Erfüllung dieses Qualitätskriteriums beitragen. Effizienz ist aber in erster Linie eine Frage des guten Designs, und gerade dies wird durch die Entwurfsmethoden und Hilfsmittel in der Umgebung gefördert. Durch die exakte und umfangreiche Entwurfsdokumentation ist es möglich, Engpässe in der Ressourcennutzung rechtzeitig zu erkennen, ehe die Programme erstellt werden. Und da die Programme normiert, modular und strukturiert sind, wird die Optimierung wesentlich einfacher. Meß- und Tuning-Maßnahmen sollten in der Software explizit unterstützt sein.

Programme in möglichst kleine Module aufbrechen

Wartungsfreundlichkeit ist der Grad, zu dem man Programme leicht korrigieren und optimieren kann ohne dadurch weitere Fehler oder Performance-Probleme zu verursachen. Sie hat eine enge Verwandtschaft mit der Anpassungsfähigkeit der Programme und Dateien. Anpassungsfähigkeit ist der Grad, zu dem man bestehende Module und Datenkapseln ändern kann, ohne dadurch weitere Fehler zu verursachen.

Zum Zwecke der Korrektur und Anpassung müssen Programme in möglichst kleine Module mit wohldefinierten, nicht allzu komplexen Schnittstellen geteilt werden. Die Module sollten wohlstrukturiert und nicht zu tief verschachtelt sein, denn dies reduziert die Testbarkeit.

Gerade in dieser Hinsicht müßte die Software-Produktionsumgebung besonders strenge Regeln haben. Um eine zu tiefe Verschachtelung zu vermeiden, gibt es nur die Steuerungsstrukturen WHILE und IF. ELSE dürfte auch nicht vorkommen. Dadurch wird die Anzahl Testpfade erheblich reduziert. GO/TO-Anweisungen sollten überhaupt nicht möglich sein.

Die Abläufe sind nur im Sinne des reinen Structured Programming mit den Konstrukten Sequenz, Auswahl (=IF) und Wiederholung (=WHILE) zu strukturieren. Außerdem sollten die Software-Entwurfsschablonen den Entwickler zwingen, seine Programme in Module zu teilen und die Module über formale Parameterschnittstellen miteinander zu koppeln. Dabei sind die Regeln der Modulbindung und Modulkopplung zu beachten. Auf der Datenseite sollten die Datenstrukturen möglichst unabhängig von der jeweiligen Anwendung sein. Diese Datenunabhängigkeit wird am ehesten mit relationalen Datenbanken und getrennten Zugriffsmodulen realisiert. Die Programme dürften nur Views der Daten in der dritten Normalform zu sehen bekommen.

Erweiterbarkeit ist der Grad, zu dem neue Komponenten-Module, Programme, Dateien oder Datenkapseln in ein bestehendes Software-System eingefügt werden können, ohne vorhandene Komponenten ändern zu müssen. Es kommt also darauf an, bei der Zufügung neuer Komponenten möglichst wenig vorhandene Bausteine ändern zu müssen.

Eine Software-Produktionsumgebung fördert die Erweiterbarkeit der Software vor allem durch ihre strengen Modularisierungsrichtlinien und Zwänge, die schon bei der Anforderungsspezifikation in Erscheinung treten. So wird der Spezifizierer gezwungen, mehrere kleinere logische Datenmengen, also Objekte, und auch mehrere kleinere logische Funktionsmengen, also Vorgänge, zu bilden.

In der Entwurfsphase wird der Entwickler angeleitet, möglichst viele relationale, inhaltlich voneinander unabhängige Zugriffseinheiten - Datenkapseln - sowie möglichst viele funktional gebundene, parametergekoppelte Module zu entwerfen. Der Aufruf der Module über CALL-Anweisungen mit einer eindeutig definierten Parameterliste zur Bildung abstrakter Datentypen trägt am meisten dazu bei, die Erweiterbarkeit der Software zu gewährleisten.

Übertragbarkeit oder Portabilität ist die Fähigkeit, Programmsysteme von einer technischen Umgebung in eine andere mit einem Minimum an Änderungen zu versetzen. Je weniger Module man für die Übertragung anfassen muß, desto besser.

Die zu ändernden Module sind diejenigen, in denen Anweisungen wegen der neuen technischen Umgebung geändert werden müssen. Denn auch wenn nur eine Anweisung geändert wird, muß das ganze Modul neu compiliert, gebunden und getestet werden.

I/O-Operationen verlagert

In der Software-Produktionsumgebung wird die Portabilität dadurch verwirklicht, daß sämtliche I/O-Operationen in die Randmodule verlagert sind. So enthält das Steuerungsmodul alle Schnittstellen zu dem TP-Monitor beziehungsweise im Batchmodul zu den Bewegungsdateien, während die Datenmodule alle Schnittstellen zu dem Datenbank- beziehungsweise zu dem Dateiverwaltungssystem beinhalten. Die eigentlichen Verarbeitungsmodule sind frei von DB-, DC- oder IO-spezifischen

Anweisungen. Auch die Abend" Behandlung soll in einem extra Fehlerbehandlungsmodul durchgeführt werden. Schließlich sollten die logischen Datenstrukturen möglichst unabhängig von der physischen Datenbank sein. Somit läßt sich ein hohes Maß an Systemunabhängigkeit erreichen.

Entwickler dürfen nicht unter Zeitdruck stehen

In Anbetracht dieser Maßnahmen zur Steigerung der Software-Qualität ist es offensichtlich, daß Qualität von Anfang an geplant werden muß. Sie ist nicht etwas, das man nachträglich in die Software hineinkontrollieren kann. Um jedoch diese konstruktiven Maßnahmen zu verwirklichen braucht der Entwickler gute Werk zeuge, fundierte Methoden und genügend Zeit, um die Software richtig zu konstruieren. Leider fehlen diese Voraussetzungen in fast allen Anwendungsbetrieben. Es wird in der Regel zu schnell, zu schlampig und ohne adäquate Mittel Software produziert. Niemand kümmert sich um die Qualität, weder die Entwickler noch die Anwender oder die Manager. Termine und Kosten haben fast immer den Vorrang. Darum darf es auch niemanden wundern, wenn die Qualitätsprobleme und mit ihnen die Wartungsprobleme ständig zunehmen. Solange die Prioritäten so gesetzt sind, kann man nichts anderes erwarten.

*Harry Sneed ist Geschäftsführer der SEES Software Engineering Service GmbH, Neubiberg bei München.