Die Manager der Unternehmen müssen noch viel dazulernen, denn:

Richtlinien allein gewährleisten noch keine Software-Qualität

08.01.1988

Auf kaum einem Gebiet der Datenverarbeitung wurde in den letzten Jahren so viel geforscht und entwickelt wie bei der Software- Erstellung. Bereits die 70er Jahre brachten wichtige Methoden und Werkzeuge, beispielsweise die Strukturierte Programmierung, das Structured Design oder, die Strukturierte Analyse. Doch trotz dieser modernen Techniken ist die Software-Qualität auch heute immer noch nicht zufriedenstellend.

Nach und nach wurden und werden von Software-Häusern, Computerherstellern und Anwendern rechnerunterstützte Werkzeuge entwickelt, die das methodische Arbeiten mit Verfahren des Software Engineering erleichtern sollen. Naturgemäß knüpft sich an diese Entwicklung die Hoffnung, wesentliche Verbesserungen in der Software-Erstellung zu erhalten. Spricht man jedoch mit den dafür Verantwortlichen beziehungsweise liest einschlägige Erfahrungsberichte, so gilt mit wenigen Ausnahmen das, was Niclaus Wirth, Pionier des Software-Engineering und Pascal-Vater, in einem Interview Anfang dieses Jahres gesagt hat: "Sicher, wir haben Fortschritte gemacht, aber im großen und ganzen kann man sagen, daß es böse hapert."

Betreiber und Entwickler solcher Systeme beklagen vor allem, daß diese - wenn überhaupt - nur noch von wenigen Spezialisten wartbar seien. Ferner lassen sich Erweiterungen kaum mehr durchführen, und die Systeme würden gegenüber neuen Daten instabil reagieren.

Es ist jedoch relativ schwierig zu erfahren, wie es zu diesen Qualitätsmängeln kommen konnte. Häufig begnügen sich die Software-Manager mit Pauschalantworten, die lediglich zeigen, daß bei der Erstellung des mangelhaften Software-Produktes die Möglichkeiten des Software-Engineering nicht im erforderlichen Ausmaß eingesetzt wurden. Einige bekannte Gründe sind zum Beispiel die fehlende Integration der Methoden, der Werkzeuge und der Fachleute allgemeine Managementfehler bei der Einführung der Software-Engineering-Methoden und das fehlende Know-how beim Einsatz der Methoden und Tools. Allgemeine Ansicht ist, daß sich die Qualität der neuerstellten Software dann bessern wird, wenn es gelingt, eine Methode des Software-Engineering mit Reviews, Inspektionen und "Walk-throughs" zur Qualitätssicherung zu etablieren. Die genauere Ursachenforschung in der jetzigen Arbeitsumgebung interessiert weniger. Gerade das sollte aber unternommen werden, denn hier stellt sich heraus, daß manch schönes theoretisches Konzept von Anfang an eine Illusion ist.

Irrglauben der Manager behindert Projektarbeit

Das Management glaubt nämlich fest daran, daß die SW-Architektur eines geplanten großen Systems durch einige wenige "Systemanalytiker" so detailliert werden kann, daß die Programmierung ein fast mechanisierbarer Vorgang ist, der lediglich eine handwerkliche Schulung und ein gewisses Maß an Erfahrung in einer Programmiersprache erfordert.

Genährt wird diese Fiktion noch durch theoretisierende Vertreter von Sprachen der vierten Generation sowie durch Apostel der CAP-Verfahren (Computer Aided Programming) und Verfechtern von Programmgeneratoren. Im Bewußtsein des Managements verwischen sich damit die Grenzen zwischen Programmierung und Codierung.

Eine Folge dieser Einstellung ist die personelle Fehlbesetzung. Es werden dazu nämlich vom Management nur wenige qualifizierte Kräfte, die als Systemanalytiker arbeiten können, zur Verfügung gestellt - im Gegensatz zu vielen "Programmierern", die im großen und ganzen lediglich codieren können. Dies hat für die weitere Projektarbeit schlimme Auswirkungen.

Ein Beispiel gibt die Implementierungsphase großer komplexer Anwendungs-Systeme ab. Die Kerntruppe der Systemanalytiker ist zunächst lediglich in der Lage, eine grobe Software-Architektur des geplanten Systems zu erstellen. Hauptbestandteil dieser Architektur sind Module, bei denen neben den zu erfüllenden Leistungsanforderungen hauptsächlich die Schnittstellen zu anderen Komponenten festliegen. Genau diese Module sollen nun die "Programmierer in eigener Verantwortung realisieren. Sie müssen sich dazu aber erst in den fachlichen Hintergrund einarbeiten. Die hierbei auftretenden fachlichen Probleme sind häufig so komplex, daß sie nach einiger Zeit nur noch von dem für die Realisierung dieses Moduls zuständigen Programmierer in allen Details verstanden werden. Der Projektleiter kennt zwar den Aufbau, aber eben nur bis zu einer gewissen Detailstufe. Er ist daher bei entsprechend großen Projekten auch nicht mehr in der Lage, jedes einzelne Moduldesign zu überprüfen.

Analoges gilt für alle, die an den Reviews teilnehmen sollen. Das heißt aber, daß die vom Management zur Verfügung gestellten Programmierer in der Lage sein müssen, einen vernünftigen Entwurf eines Programm Komplexes zu erstellen. Dazu bedarf es aber gewisser analytischer und abstrahierender Fähigkeiten. Die Programmierer sollten zumindest wissen, wie ein Top-down-Entwurf sinnvoll zu erstellen ist. Das Schwierige an diesem Entwurf ist jedoch, die richtige Strukturierung zu finden. Erst die richtige Konzeption von Anfang an macht die Programm-Struktur - auch nach Ergänzungen und Erweiterungen - einfach und übersichtlich. Letzteres ist vor allem deshalb wichtig, weil Ergänzungen und Erweiterungen mit zunehmendem Detaillierungsgrad im Projekt der Normalfall sind. Programmieren bedeutet daher weit mehr als Codieren und ist deshalb im Gegensatz zu den jahrelang von vielen Seiten geäußerten Meinungen eine schwierige Tätigkeit.

Das Absurde an der Sache ist, daß das Management meist glaubt, die richtige Konzeption von Anfang an durch Vorgabe gewisser einzuhaltender, "Software-Qualitätsfaktoren " erzwingen zu können. Hierzu gehören unter anderem neben der Beschränkung auf die Sprachmittel der Strukturierten Programmierung die Festlegung einer Maximalgröße von Einzelmodulen (zum Beispiel zwei Seiten Sourcecode für Einzelprozeduren in Cobol) und die Beschränkung der Schachtelungstiefe von Schleifen. Daß viele dieser Anforderungen für einen guten Programmierstil notwendig sind, ist unbestritten; sie sind jedoch keinesfalls hinreichend für einen guten Programmentwurf, ja nicht einmal für kleine Programmabschnitte, wie schon vor Jahren von Michael Jackson aufgezeigt wurde.

Urfassung des Programms endet als Flickwerk

In der Praxis werden dann unter dem Zwang obiger Vorschriften von den überforderten Programmierern Anwendungen erstellt, die zwar alle meßbaren Kriterien erfüllen, aber bei weitem nicht kompakt und übersichtlich sind. Viele dieser Programme, die in der, "Urfassung" noch einigermaßen übersichtlich waren, sind deshalb undurchschaubar geworden, weil sie nach x-maligem Zusammenbruch mit echten Daten immer wieder geflickt werden mußten. Zusätzliche Reviews sind, wenn sie wirklich erfolgreich sein sollen, meist wenig ergiebig, da sie - entgegen einer vielfach geäußerten Meinung - von allen Beteiligten Detailkenntnisse des Fachproblems erfordern.

Das Management verläßt sich aber oft nur auf die maschinelle Überprüfung der vorgegebenen Kriterien. Muß ein solches Programm dennoch analysiert werden, weil es zum Beispiel zu erweitern ist und der Programm-Hersteller nicht mehr zur Verfügung steht, ergibt sich meist Unerquickliches. So ist beispielsweise die Unterteilung des Problems in Module keine sinnvolle hierarchische Strukturierung sondern weitgehend willkürlich. Sie wird lediglich deshalb durchgeführt, um die Programmiervorhaben bezüglich der Modulgröße zu erfüllen. Dazu kommt, daß die Struktur durch die x-malige Flickerei völlig verwirrend geworden ist. Die mit der Analyse betrauten Fachleute sind dann meist nicht mehr in der Lage, die Gedankengänge des ursprünglichen Programmerstellers nachzuvollziehen und müssen häufig die Anwendungen neu entwickeln.

Gutes Programmieren ist eine schwierige Sache

Was kann aber getan werden, um das Entstehen von solch unerwünschtem Flickwerk zu vermeiden? Abhilfe schaffen sicherlich nicht noch mehr Regeln und Restriktionen. Wichtiger ist zunächst, die Einstellung des Managements zu ändern. Es muß trotz aller gegenteiliger jahrelanger Behauptungen klar werden, daß "gutes Programmieren" eine schwierige Sache ist und vom Codieren, das in relativ kurzer Zeit erlernbar ist, unterschieden werden muß. Ein guter Programmierer braucht einiges Talent, um in konkreten Situationen eine gewisse Originalität bei der Lösung von Problemen zu entwickeln. Dies ist selbst bei ausgebildeten Informatikern oft nicht automatisch vorhanden. Nicht jedermann ist eben für das Programmieren geeignet. Das Management muß daher beim Berufsstand der Programmierer mehr differenzieren, gute Programmierer fördern und ihnen entsprechende Stellungen bei der Durchführung großer Softwareprojekte bieten. Die Besetzung von Projekten muß auch nach wesentlich differenzierteren Gesichtspunkten als bisher erfolgen. Damit wäre -sicher ein erster Schritt in Richtung qualitativ besserer Software getan.

Ein weiterer Schritt wäre, genügend Systemanalytiker bereitzustellen, die bis zu einem gewissen Detailgrad die Strukturierung der Programm-Komplexe überprüfen. Voraussetzung hierfür ist natürlich, daß ausreichend qualifiziertes Personal zur Verfügung steht. Unumgänglich für die Beurteilung einer sinnvollen Strukturierung des Programm-Komplexes ist hierbei allerdings, daß sich die Systemanalytiker bis zu einem bestimmten Grad auch in den fachlichen Hintergrund der Programme einarbeiten. Die Idee, projektfremde Qualitätsprüfer heranzuziehen, dürfte damit mehr Theorie bleiben.

Erleichterung kann allerdings das Top-down-Vorgehen mit hierarchischer Strukturierung des Programm-Komplexes bringen, da eine eindeutige Schnittstelle für den Detailgrad der Unterstützung festgelegt werden kann. Hier ist auch ein Ansatzpunkt für den Einsatz von Tools, um die Softwarequalität zu verbessern. Diese Werkzeuge sollten den Programmierern in einheitlicher Form vom Entwurf bis hin zur Codierung unterstützen. Als besonders vorteilhaft für den Programm-Ersteller erweisen sich Tools, die vom Bildschirm im Dialog einsetzbar sind und grafische Unterstützung bieten, wie zum Beispiel die Standarddiagramme der Grafik-Workbench-Tools.