Von Professor Dr. Erwin Grochla

KÖLN (ee) - Aus betriebswirtschaftlicher Sicht hat Prof. Dr. Erwin Grochla (Universität Köln) den Programmier-Alltag analysiert und dabei eine umfangreiche und - vielleicht wegen der empirischen Stützung besonders brisante Mängelliste aufgestellt. Nach seiner Auffassung ist "wirtschaftliche Programmierung" gegenwärtig in der Praxis mit den "derzeit vorherrschenden Vorgehensweisen kaum zu erreichen". Grochla sieht als Konsequenz für alle Phasen der Programmier-Arbeit nur eine Grundforderung: Mehr Qualität, um die Schwachstellen in allen Phasen der Software-Entwicklung auszugleichen und so dem Ziel der Wirtschaftlichkeit näherzukommen. Grochlas Text war vorbereitet für das Fachseminar "Wirtschaftliche Programmierung", durchgeführt vom Betriebswirtschaftlichen Institut für Organisation und Automation (BIFOA) an der Universität Köln, und konnte dort nur fragmentarisch vorgetragen werden. Hier exklusiv in der COMPUTERWOCHE der volle Text (Teil 1).

Warum gibt es gerade zur Zeit so viele Probleme im Bereich der Software?

Meines Erachtens haben im wesentlichen folgende Faktoren zur heutigen Situation geführt:

- In vielen Unternehmungen wird schon seit Jahren Datenverarbeitung computergestützt betrieben. Dabei sind durch die Entwicklung umfangreicher Programme erhebliche Investitionen in die Software geflossen. Diese oft vor Jahren erstellen Programme sind im Laufe der Zeit ständig geändert worden, zum Beispiel

- weil die Fachabteilung zusätzliche Funktionen benötigte

- weil das Betriebssystem geändert wurde

- der das Maschinensystem gewechselt wurde.

Die Wartung dieser Programme bindet häufig weit über 50 Prozent der DV-Spezialisten einer Unternehmung. Und das Schlimmste: diese Programme werden durch die Änderungen immer fehleranfälliger und immer schwieriger wartbar.

- Das Wegfallen vieler hardware- und betriebssystembedingter Restriktionen bei den heute verfügbaren ADV-Systemen hat dazu geführt, daß immer umfangreichere Problemstellungen computergestützt gelöst werden können. Nicht zu Unrecht fordern viele Fachabteilungen die Abschaffung der vorhandenen Lösungen, die ihnen oft nach "einer Woche Wartezeit 10 kg Papier mit veralteten Daten" bescheren. Statt dessen wollen sie die Vorteile der verfügbaren Technologie nutzen und möchten mit Hilfe von Bildschirmarbeitsplätzen direkt auf die aktuellsten Datenbestände zurückgreifen können.

Die Aufgabe der Systementwickler besteht nun darin, diese komplexen Anwendungen auf einem komplexen ADV-System als Programmsystem zu implementieren. Der technische Fortschritt hat im Bereich der Programmierung zu einer Situation geführt, die Edsger W. Dijkstra schon 1972 folgendermaßen charakterisierte: (frei übersetzt) "Früher hatten wir kleine Computer und auch kleine Probleme - er sagt "mild problems" - und heute, da haben wir gigantische Computer und ebenso gigantische Probleme. (Original: "When we had a few waek computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem.")

Was bedeutet nun wirtschaftliche Programmierung in der dargestellten Situation?

Zur Beantwortung dieser Frage ist es notwendig, zunächst auf den Begriff der Wirtschaftlichkeit einzugehen. Wirtschaftlichkeit wird bekanntlich in der Betriebswirtschaftslehre als das Verhältnis von Leistung (Nutzen) zu Kosten (beziehungsweise von Ertrag zu Aufwand) definiert. Im Falle der Programmierung werden die Kosten im wesentlichen durch die Personalausgaben bestimmt. Eine untergeordnete Rolle spielen in der Regel die Kosten für die notwendige Rechenleistung. Diese beiden Kostenfaktoren sind relativ einfach zu bestimmen. Schwierigkeiten ergeben sich jedoch mit der Bestimmung der zweiten Größe: der Leistung. Der Output der Programmierung besteht aus den in einer Programmiersprache abgefaßten Anweisungen. Sie sind zwar in lines-of-code leicht zählbar, jedoch diese rein quantitative Angabe reicht natürlich nicht aus, um eine Bewertung der erbrachten Leistung und somit eine Ermittlung der Wirtschaftlichkeit vorzunehmen. Das bedeutet zum Beispiel, daß eine Verdoppelung der programmierten lines-of-code bei unveränderten Kosten noch lange keine Verbesserung der Wirtschaftlichkeit um den gleichen Faktor darstellt. Aussagen über die erbrachte Leistung in der Programmierung sollten sich demnach an den Merkmalen orientieren, die eine Einschätzung der Qualitätseigenschaften von Software erlauben. Von diesen sogenannten Software-Qualitätsmerkmalen sollen hier nur einige wenige genannt werden. Zunächst diejenigen, die primär den Anwender interessieren:

- Das Merkmal des Funktionsumfanges ist ein Kriterium dafür, in welchem Maße die von den Anwendern geforderten Verarbeitungsarten realisiert sind. (Mit anderen Worten: Es ist ein Maßstab dafür, inwieweit die vom Anwender geforderten Funktionen tatsächlich implementiert sind, also die gestellte Entwicklungsaufgabe im Sinne des Anwenders erfüllt wurde. Das Fehlen nur einer einzigen Funktion kann dazu führen, daß ein Programmsystem mit mehreren Mannjahren Entwicklungsaufwand nicht einsetzbar ist.)

- Die Korrektheit gibt an, in welchem Maße die vorhandenen Funktionen frei von logischen Fehlern sind. Sie gibt also an, inwieweit eine sachlich richtige Verarbeitung durch die implementierten Programme gewährleistet ist. Der Nachweis der Korrektheit von Programmen war schon immer ein zentrales Problem der Software-Entwicklung. Der anhaltende Trend nach einer verstärkten Integration der DV-Anwendungssysteme hat jedoch die fatale Folge, daß einerseits die Anforderungen an die Korrektheit der Programme dadurch enorm gestiegen ist, daß aber andererseits ihr Nachweis durch die steigende Komplexität der Systeme immer schwieriger wird.

- Die Zuverlässigkeit, oder auch Robustheit, ist ein Merkmal dafür, inwieweit ein Programm trotz Störungen während seines Laufes korrekt weiter arbeitet, oder die Auswirkungen von Fehlern gering hält. Denn welchen Wert hat ein Programm, in dem ein eventuell auftretender Fehler unbemerkt Hunderte von Folgefehlern erzeugt.

- Die Effizienz wird dadurch bestimmt, wie hoch der Kapazitätsverbrauch und wie das Zeitverhalten der implementierten Programme bei der Ausführung ist. (So ist ein Dialogsystem mit 20 Sekunden Antwortzeit in der Praxis nicht einsetzbar.)

Wenn die genannten Qualitätsmerkmale bei der Programmierung vernachlässigt worden sind, so werden unweigerlich Nachbesserungen notwendig. Und dann beginnt das Änderungskarusell: "Abnahme durch die Fachabteilung unter Vorbehalt - versuchsweiser Einsatz - große Enttäuschung - erste Nachbesserung - Abnahme durch die Fachabteilung unter Vorbehalt - zweite Nachbesserung. . . , Sie kennen das Spiel!"

Neben diesen mehr anwendungsbezogenen Merkmalen existiert eine wesentliche zweite Gruppe von Qualitätsmerkmalen, die eine Bewertung von Programmen stärker aus der Sicht der Software (...) Erstellung ermöglicht, so:

- Der Standardisierungsgrad, der ein Maß dafür ist, inwieweit die verschiedenen Programme eines Programmsystems gleichartig strukturiert sind. (Zwar ist wenig dagegen einzuwenden, wenn ein guter Programmierer einen guten Programmierstil entwickelt, aber das Problem liegt darin, daß 10 Programmierer auch 10 individuelle Programmierstile haben können.)

- Die Testbarkeit eines Programms wird dadurch bestimmt, welcher Aufwand betrieben werden muß, um eine möglichst vollständige Prüfung der Korrektheit der erstellten Software zu erreichen. Sie wird im wesentlichen durch die Struktur der Programme und damit verbunden durch die Übersichtlichkeit und durch die Lesbarkeit der Quellprogrammtexte bestimmt.