Wirtschaftliches Programmieren:

Die meisten Entwurfskonzepte verhindern die Transparenz

27.10.1978

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 zweite Teil.

- Die Wartbarkeit eines Programmes wird dadurch bestimmt, mit welchem Aufwand - und oft ob überhaupt - notwendige Änderungen vorgenommen werden können. Neben den Merkmalen Übersichtlichkeit und Lesbarkeit spielt hier die Gute - nicht der Umfang - der vorhandenen Dokumentation eine entscheidende Rolle. Denn wir wissen auch, wenn die ursprünglichen Entwickler eines Programms nicht mehr greifbar sind (was bei der starken personellen Fluktuation sehr oft der Fall ist), müssen Änderungen, möglichst ohne das Einbauen von neuen Fehlern, durchführbar sein.

Aufgrund unseres Kontaktes mit der Wirtschaftspraxis haben wir die Erkenntnis gewonnen, daß die genannten Softwarequalitätsmerkmale in den meisten Fällen nicht erreicht werden. Ich könnte mir denken, daß Sie diese Erkenntnis aus Ihrem Erfahrungsbereich bestätigen werden.

Gelingt es aber, die genannten Qualitätsmerkmale zu erfüllen, so führt dies:

- zu einer höheren Transparenz des Erstellungsprozesses

- zu einer größeren Übereinstimmung mit den Benutzeranforderungen und

- zu geringeren Folgekosten.

Man kann also sagen: Wird Software mit einem hohen Qualitätsniveau erstellt so heißt dies zugleich langfristig wirtschaftlicher arbeiten!

Betrachten wir demgegenüber die Praxis, so ist festzustellen, daß das Ziel einer wirtschaftlichen Programmierung mit der derzeit vorherrschenden Vorgehensweise bei der Erstellung von Programmen kaum zu erreichen ist. Es fehlt in allen Phasen der Software-Erstellung sowohl an systematischen Vorgehensweisen als auch an wirksamen Instrumenten. Dies gilt sowohl für die Aktivitäten: Entwurf, Programmerstellung, Programmtest und Dokumentation.

Mängel in der Entwurfsphase wirken sich auf alle anschließenden Phasen bis hin zur Anwendung eines Programmsystems aus. Kommunikationsschwierigkeiten zwischen den Fachabteilungs- und den DV-Spezialisten sind ein wesentlicher Grund für die oft mangelhaft erfaßte Aufgabenerstellung. Die Güte einer erfaßten Aufgabenerstellung hängt immer noch weitgehend von der Qualität der beteiligten Aufgabenträger ab; es fehlen Verfahren, die eine höhere Unabhängigkeit von qualifiziertem Personal erlauben. Die Umsetzungen der Aufgabenstellungen in Systementwürfe erfolgt von Entwickler zu Entwickler nach individuellen Konzepten. Eine Standardisierung läßt sich so sicher nicht erreichen; ein Mangel der bei größeren Projekten mit mehreren Entwicklern besonders deutlich wird. Da das Entwurfskönnen bei den Entwicklern im wesentlichen auf den Erfahrungen stapelorientierter Systeme basiert, sind sie den heute auftretenden Anforderungen bei Online-Systemen, Datenfernverarbeitung, Datenbanken nicht immer gewachsen.

Die heute zur Anwendung kommenden Entwurfskonzepte erlauben sehr oft keine übersichtliche Darstellung der Problemlösung. Die sich daraus ergebenden Konsequenzen sind nicht nur eine schwierige Überprüfbarkeit der konzipierten Problemlösung für die Fachabteilung, sondern auch, daß die notwendige Transparenz für die DV-Spezialisten nicht erreicht wird.

Zusammenfassend kann hier folgende Forderung formuliert werden: Einerseits benötigen wir Instrumente und Methoden, die eine vollständige Erfassung der Benutzeranforderungen sicherstellen und andererseits solche, die die Umsetzung dieser Anforderungen in transparente Systementwürfe unterstützen.

- Die Umsetzung der Entwürfe erfolgt im Rahmen der eigentlichen Programmerstellung. Diese Tätigkeit besteht heute oft noch darin, daß die Programmierer die Programme vom ersten bis zum letzten Statement niederschreiben müssen, obwohl ähnliche Programmteile vorhanden sind und übernehmbar wären. Die auch heute noch oft praktizierte Art, Lochkarten als Datenträger für die Quellprogrammtexte zu verwenden, ist ein wahrer Anachronismus.

Weiterhin fehlen Hilfsmittel, die die Codierarbeit erleichtern, und es auch leicht machen, vorhandene Programmtexte mit Änderungen zu übernehmen. Diese Hilfen haben sicherlich auch positive Auswirkungen auf die Kommentierung in den Programmen, und auch "Schreibfaulheit" der Programmierer ist keine Entschuldigung mehr für unverständliche Kürzel zur Bezeichnung von Datenfeldern. Fassen wir es zusammen: Für die Unterstützung dieser Phase der Software-Erstellung benötigen wir Instrumente, die uns die Bearbeitung und Verwaltung von Programmtexten erleichtern, wie auch solche, die es erlauben, mit wenigen Aufgaben Programme oder zumindest Programmteile automatisch zu erzeugen.

Der oft letzte - und auch manchmal überhaupt nicht vollzogene - Schritt ist die Dokumentation der erstellten Programme. Unser Institut hat Untersuchungen durchgeführt, die erheblich Mängel gerade in diesem Bereich zutage gefördert haben. Hier nur einige Schwachpunkte:

- Die Dokumentation genügt oft nicht den zu steilen Anforderungen.

- Unzureichende Standardisierung - oft wegen Mißachtung der diesbezüglichen Vorschriften - machen es schwer, sich in den Unterlagen zurechtzufinden.

- Die Entwicklung der Programmsysteme ist nicht dokumentiert, so daß zum Beispiel die Gründe für die einzelnen Entwurfsentscheidungen nicht nachvollziehbar sind.

- Die Dokumentation stimmt nicht mit den im Einsatz befindlichen Programmen überein, weil Programmänderungen ohne die entsprechende Korrektur der Dokumentation erfolgen.

Die daraus resultierenden Folgen für die Programmwartung sind bekannt. Zusammenfassend ist festzustellen: Die Instrumente und Methoden zur Unterstützung der Dokumentation müssen deren Erstellung und Handhabung vereinfachen. Des weiteren müssen die Vorschriften sicher anwendbar und ihre Einhaltung leichter überprüfbar sein.