Strukturierte Programmierung beim mittelgroßen, kommerziellen Anwender?

Nichts spricht für Spaghetti-Programme

06.05.1977

Die Teilnehmer an der Structo 76, der vom Control Data Institut in Frankfurt Ende Oktober 1976 durchgeführten Kongreßveranstaltung zur Strukturierten Programmierung, waren sich einig: Die Vorzüge der Strukturierten Programmierung sind weniger unter quantitativen als vielmehr unter qualitativen Gesichtspunkten zu messen (1).

Die wichtigsten qualitativen Vorteile, die die Strukturierte Programmierung bietet, sind mittlerweile bekannt und wohl allgemein auch so weitgehend anerkannt, daß sie an dieser Stelle nur noch aufgezählt, nicht mehr diskutiert zu werden brauchen:

- Mehr Sicherheit beim Programmtest durch übersichtliche Programmkonstruktionen.

- Die Möglichkeit, einzelne Moduln auszutesten durch Top-Down-Test.

- Bessere Teilbarkeit von großen Programmen. Programmierer können ihrer Qualifikation entsprechend optimal eingesetzt werden.

- Mehr Transparenz und leichtere Lesbarkeit. Das Programm dient nicht mehr nur der Kommunikation Mensch - Maschine, sondern auch der Kommunikation Mensch - Mensch (Datenschutz, Revision, Dokumentation).

- Große Erleichterung und Sicherheit bei Wartungsarbeiten und Änderungen.

Angesichts dieser verlockenden Vorzüge ist, auch für den mittelgroßen, kommerziellen Anwender, zunächst kein vernünftiger Grund erkennbar, sich bei der Erstellung seiner Software nicht einer ingenieurmäßigen Technik in Form der Strukturierten Programmierung zu bedienen.

Die Schulung ist - ein entsprechendes, qualitatives Niveau der Mitarbeiter vorausgesetzt - nicht allzu schwierig. Freilich werden sich zuerst bestimmte Mitarbeiter gegen die "Neuheit" sträuben, aber dies erleben wir ja immer, wenn neue Methoden eingeführt werden sollen. Den wirklichen Fachmann, der die Nachteile der konventionellen Softwareproduktion voll ausgekostet hat, wird die Strukturierte Programmierung schnell überzeugen.

Nun geht es daran, das Erlernte in die Praxis umzusetzen. Und genau da beginnt unser Problem: Wie auch auf der Structo 76 zutage trat, ist ein quantitativer Vorteil der Normierten Programmierung im Sinne einer Beschleunigung umstritten. Die einschlägigen Gesichtspunkte sollen hier nicht untersucht werden. Es erscheint aber durchaus plausibel, daß gewisse zeitliche Vorteile, aus einer Abkürzung der Testzeiten etwa, andererseits durch den aufwendigen Systementwurf und die dafür nötigen Vorüberlegungen zumindest ausgeglichen werden. Eines steht jedenfalls fest: In der Lernphase dauert die Erstellung eines strukturierten Programmes eindeutig länger als die eines herkömmlichen "chaotischen" Programmes. Damit haben wir den neuralgischen Punkt getroffen: Welcher mittelgroße Anwender kann es sich wirklich erlauben, konsequent die Einhaltung der Regeln der Strukturierten Programmierung zu verlangen, wenn ihn der Arbeitsanfall zu ersticken droht und ohnehin nur noch das Notwendigste und Allerdringendste bewältigt werden kann?

Fachbereiche und betriebswirtschaftliche Abteilungen sehen ihr anstehendes Problem und ihre Termine. Die Programmiermethode interessiert sie nicht. Sie haben Vergleichswerte aus der Erledigung ähnlicher Aufgaben durch die EDV, und sie haben vielleicht auch einen "halben EDV-Fachmann" in ihren Reihen, der "genau weiß", wie lange man für ein bestimmtes Programm - nach der konventionellen Methode und ohne ordentliche Dokumentation natürlich - braucht.

DV-Chef in der Defensive

Oder eine Abteilung geht vielleicht noch weiter und holt ein Programmierangebot eines Service-Unternehmens ein. Wieder fragt keiner danach, wie diese Firma im einzelnen arbeitet - wenn Preis und Zeitdauer unter der Aufwandschätzung der EDV-Abteilung liegen, ist der EDV-Chef in der Defensive.

Die Geschäftsleitung weiß einerseits aus den Berichten des EDV-Leiters, auch aus Seminaren und Publikationen für das Management, um die Bedeutung einer zukunftssicheren, transparenten, revisionsfreundlichen Anwendersoftware. Andererseits sind da die Produktpolitik, die Marktstrategie, der Gesetzgeber, das Image des Hauses mit harten Terminen. Was letztlich höher bewertet wird, liegt auf der Hand.

Dies alles führt dazu, daß der EDV einfach der zeitliche Spielraum fehlt, um auf breiter Grundlage die notwendige Routine im Umgang mit den Regeln der Strukturierten Programmierung zu erlangen.

Soll nun die als richtig erkannte Methode deshalb nicht zum Zuge kommen?

Schützenhilfe vom DSB?

Der beharrliche EDV-Chef wird trotz der geschilderten Umstände Wege finden, um die Mitarbeiter wenigstens nacheinander mit der Strukturierten Programmierung vertraut zu machen. Dafür eignen sich zukunftsorientierte Projekte, deren Fertigstellungstermine nicht unter dem beschriebenen, außerordentlichen Termindruck stehen. Werden Mitarbeiter für solche Projekte abgestellt, dann muß dabei nachdrücklich auf Strukturiertes Systemdesign und Strukturierte Programmierung geachtet werden. Der zeitliche Mehraufwand ist bei der Zeit- und Kostenschätzung konsequent einzukalkulieren!

Zu hoffen bleibt dann, daß der Anteil solcher Projekte am gesamten Arbeitsanfall zunimmt und damit auch die neuen Methoden der Software-Fertigung beim mittelgroßen, kommerziellen Anwender Boden gewinnen. Vielleicht bekommt der EDV-Chef auch Schützenhilfe von einer ganz neuen Institution: Von einem Datenschutzbeauftragten, der nicht gern "Spaghetti-Programme" liest!

*EDV-Leiter bei der Bayerischen Beamtenversicherung, München

(1) "Online", Heft 12/76, Seite 748: Structo 76 - Soll und Ist der Strukturierten Programmierung