Bei Gesprächen mit Kollegen ergibt sich immer wieder das Problem, ob der Programmablaufplan Bestandteil der Dokumentation sein soll oder nicht. Im Rahmen der Forderungen der Revisoren stellt sich dieses Problem ebenfalls.
Abgrenzungsprobleme
Der Programmablaufplan muß abgegrenzt werden zu folgenden Problemkreisen:
1. Datenflußplan
2. Programmaufriß in Module
3. Modulbeschreibung.
Der Datenflußplan zeigt den Gesamten Arbeitsablauf aus der Sicht des Fachbereichs und des Rechenzentrums incl. der einzelnen Bearbeitungsschritte. Aus dem Datenflußplan läßt sich also die Integration eines bestimmten Programms ersehen. Der Programmablauf selbst wird jedoch nicht dargestellt.
Ein Programmaufriß in Module beschreibt die grobe Konstruktion eines Programms. Er zeigt die Struktur eines Programms. Im Rahmen der normierten Programmierung wird ein solcher Aufriß in Module unterstützt. Dies gilt auch für die strukturierte Programmierung. Der Programmaufriß in Module dient zum logischen Zergliedern des Programms und unterscheidet sich zum Programmablaufplan durch den Detaillierungsgrad.
Die Modulbeschreibung ist eine präzise Beschreibung der einzelnen Verarbeitungsschritte innerhalb des Programms. Sie gibt keinen Überblick hinsichtlich des Zusammenhangs des Programms.
Ist ein Programmablaufplan überhaupt erforderlich?
Selbst auf die Gefahr hin, daß viele Kollegen anderer Meinung sind, möchte ich behaupten, daß ein Programmablaufplan in der heutigen Zeit nicht mehr notwendig ist. Wenn ein Datenflußplan, ein Programmaufriß in Module und eine Modulbeschreibung vorliegen, erübrigt sich ein Pogrammablaufplan völlig. Die einzelnen Verarbeitungsschritte können aus der "gut kommentierten" Umwandlungsliste entnommen werden.
Integration in die Dokumentation
Wenn ein Programmablaufplan in Form des konventionellen Blockdiagramms dennoch erstellt worden ist, stellt sich die Frage, ob dieser Programmablaufplan in die Dokumentation übernommen werden soll. Ich vertrete hier die Meinung, daß der Programmablaufplan in den Papierkorb gehört, und zwar spätestens dann, wenn das Programm abgenommen worden ist. Dafür möchte ich folgende Gründe anführen:
1. Die Ablage eines Programmablaufplans bläht die Dokumentationsunterlagen auf. Es ergibt sich ein reines Mengenproblem in der Archivierung.
2. Programme unterliegen einem permanenten Änderungsdienst. Selbst wenn es gelingen sollte, daß pro Programm nur eine Änderung im Jahr durchgeführt wird, so müssen diese Änderungen auch im Programmablaufplan berücksichtigt werden. Hier ergibt sich ein ganz beträchtlicher Arbeitsaufwand, der jedoch fast in allen Fällen unterbleibt, da er von fast allen Programmierern abgelehnt wird. Aus diesem Grunde veraltet ein Programmablaufplan innerhalb von 1-2 Jahren nach Einsatz des Programms. Ein falscher Programmablaufplan kann jedoch zu ganz gefährlichen Programmzusammenbrüchen mit erheblichen Folgen für das Unternehmen führen. Der Arbeitsaufwand steht zudem in keinem vertretbaren Verhältnis zum Effekt.
3. Der Einsatz von sogenannten Flow-Chart-Programmen bringt kein brauchbares Ergebnis aus der Sicht des Benutzers. Die Auswertungen bzw. grafischen Darstellungen die solche Systeme liefern, sind benutzerunfreundlich. Das Handling mit derartigen Listen ist viel zu aufwendig.
Der Aussagegehalt ist beschränkt. Er läßt sich nur dann steigern, wenn der Benutzer dafür sorgt, daß ein Programmaufriß in Module erstellt wird. Für diese Arbeiten gibt es aber wesentlich bessere Hilfsmittel als Flow-Chart-Systeme. Da sich ein Programmaufriß in Module innerhalb eines Programms kaum ändert, genügt eine einmalige manuelle Darstellung.
4. Die Programmiertechnik geht immer mehr auf Online-Programmierung über. Papierlose EDV-Programmerstellung heißt die Devise der Zukunft. In wenigen Jahren wird der Programmierer zusammen mit dem Organisator das Problem am Bildschirm aufbereiten und ohne irgendwelche Papierunterlagen lösen. Dies wird für die Neuerstellung und Wartung von Programmen gelten. Voraussetzung dieser Vorgehensweise ist eine TP-Dokumentation im gesamten EDV-Bereich.
5. Die Revisoren verlangen keinen Programmablaufplan. Ihnen geht es schwerpunktmäßig darum, daß sie einen Programmaufriß in Module vorfinden, damit sie die Logik des Programms erfassen können.