In der CW Nr. 30/1979 wurde durch meinen Aufsatz über Struktogramme die Grundlage für eine anregende Diskussion über die Form und den Einsatz von Struktogrammen gelegt. Ich danke einmal den Lesern der CW, daß sie sich so eingehend und kritisch mit dem Thema auseinandergesetzt haben, zum anderen danke ich dem CW-Team, daß es die Stellungnahmen abgedruckt und das Thema auch aus eigener Sicht beleuchtet hat. (In diesem Zusammenhang schlage ich vor, auch andere Themen öffentlich in der CW zu diskutieren.)

Die Diskussionen über die Struktogramme erinnern mich an ein lustiges Beispiel aus der Zoologie: In Kanada gibt es eine Fliege mit unförmigem Körper und winzigen Flügeln. Zoologen sollen wissenschaftlich errechnet haben, daß diese Fliege nicht fliegen kann, da ihre Flügel viel zu klein sind. Zum Glück weiß das diese Fliege aber nicht; denn sie fliegt emsig von Blute zu Blüte.

Auch bei der Beurteilung von Arbeitstechniken müssen wir die Kriterien aus der Sicht des Theoretikers/ Wissenschaftlers und des Anwenders/Praktikers unterscheiden.

An dieser Stelle scheiden sich die Geister.

Der Praktiker legt seine Schwerpunkte ganz anders als der Wissenschaftler. Ich möchte aus der Sicht des Praktikers noch einmal auf Probleme und Ziele der Strukturierung aufmerksam machen.

Gegenargumente richtig, aber nur im ersten Hinsehen

Meine Tätigkeit der Ausbildung erstreckt sich auf externe Seminare und firmeninternes "training on the job" über Methoden der Software-Entwicklung Dabei werden keine theoretischen Aufgaben gelöst. Diese Aufgaben sind vielmehr Vorgaben für Programme, die von meinen Klienten tatsächlich realisiert werden müssen. Welches sind bei der EDV-Projektarbeit die eigentlichen Probleme, welche Argumente werden immer wieder gegen die Struktogramme ins Feld geführt?

1. Zeitdruck

"Wir haben keine Zeit, Struktogramme zu entwerfen."

"Wir haben keine Zeit, die neue Technik zu üben und anzuwenden."

2. Dokumentation

"Es ist aufwendiger, ein Struktogramm zu ändern als einen Ablaufplan."

"Das Programm ändert sich sowieso ständig, so daß ein Struktogramm nie den richtigen logischen Ablauf des Programmes widerspiegelt."

3. Doppelter Aufwand

"Bei jeder Programmänderung müssen wir das Programm und das Struktogramm andern."

4. Speicher und Zeitverhalten

"Ein Programm, das mit Struktogrammen entworfen wurde, benötigt mehr Kernspeicher und mehr Laufzeit."

Alle Argumente sind richtig, können aber entkräftet werden (was jedoch den Rahmen dieses Aufsatzes sprengen würde).

Bei längerer Diskussion mit den Seminarteilnehmern und bei längerer Zusammenarbeit im Projekt stellt sich meistens heraus, daß die Probleme der EDV-Projektarbeit noch woanders liegen, nämlich

- in der Aufnahme der vom Anwender (Sachbearbeiter) geforderten Informationen,

- in der detaillierten Entwicklung eines organisatorischen EDV-Konzeptes,

- in der schriftlichen Darstellung der Programmvorgabe und

- in der systematischen Realisierung des Programmes.

Kann bei diesen Problemen das Struktogramm weiterhelfen? Das Struktogramm dient in der Hauptsache dem Entwurf eines einzelnen Programms. Voraussetzung dafür sind ein fertiges organisatorisches EDV-Konzept und eine detaillierte Programmiervorgabe (mündlich oder schriftlich). Somit dient das Struktogramm nur einem winzigen Teil des EDV-Projektes:

Im Gesamtzusammenhang eines EDV-Projektes ist es also völlig gleichgültig, wie ein Struktogramm gezeichnet wird. Die Forderungen des Projektleiters sind nicht "kantendeckende Zeichnungen", sondern:

- Zuverlässigkeit des Programmes,

- Flexibilität (Anpassung, Änderung),

- gute Dokumentation,

- Termintreue

Ob diese Bedingungen erfüllt werden mit Programmablaufplänen, mit Struktogrammen Version Elstermann, Version Junger, Version Ballin oder anderen, mit Pseudocode, PL/1 oder Jackson-Diagrammen ist letztlich belanglos.

Am leichtesten werden diese Bedingungen jedoch erfüllt, wenn die Grundidee des Strukturierens - das Top-Down-Design - der Entwurfsmethode zugrunde liegt. Der einfachste Weg dazu führt über die Struktogramme und damit zu neuen Erkenntnissen in der Software-Entwicklung. Ganz besonders erzieht die Top-Down-ldee zu systematischem Vorgehen in allen Phasen eines EDV-Projektes.

Wie kann man strukturiertes Arbeiten lernen? Sicherlich nicht in einem Trockenkurs. Meine Erfahrungen haben gezeigt, daß Überzeugen am praktischen Beispiel den größten Erfolg garantiert. Jedes Programm hat besondere Probleme. Zehn Gebote zur Lösung dieser Probleme gibt es nicht. Individuelles Anpassen der Methode ist erforderlich.

In einem "training on the job" lernt der Programmierer den strukturierten Entwurf eines Programmes, sieht den Erfolg des Entwurfs bei der Realisierung und erkennt gleichzeitig die Grenzen der Individualität. Wer allerdings kritische Programmierprofis mit Top-Down überzeugen will, der muß top-fit sein.

Volker Elstermann*

*Volker Elstermann, EDV-Berater und -Ausbilder in 6374 Steinbach, will mit diesem Beitrag nach eigenen Worten "abschließend zum Thema Struktogramme noch einen Erfahrungsbericht aus meiner praktischen Ausbildungstätigkeit liefern".