DUISBURG - "Hauptsächlich um den Anforderungen der jährlich einmal stattfindenden EDV-Revision gerecht zu werden" - so Software-Abteilungsleiter Hans-Dieter Tumfart - mußte bei Klöckner & Co. in Duisburg ein Flow-Chart-System her, das die von der Wirtschaftsprüfungsgesellschaft "kategorisch verlangten" (Tumfart) Programmablaufpläne zeichnet. "Da die Flußdiagramme sonst nicht unbedingt erforderlich und immer nur mit großem manuellem Aufwand up to date gehalten werden können, haben wir uns zum Einsatz dieses Software-Hilfsmittels entschieden", begründet der EDV-Mann weiter die Anschaffung. Er weiß sich jetzt im Besitz eines Instruments, mit dem "auf Revisions-Forderungen automatisch ohne großen Aufwand schnell und sicher reagiert werden kann". "Daß dabei quasi als Bonus noch verbesserte Cross-Reference- sowie Fehlerdiagnostik-Möglichkeiten abgefallen sind, kann uns nur recht sein", freut sich der Klöcknerianer.
Bei Klöckner/Duisburg wird Software-Entwicklung mit COBOL und Normierter Programmierung betrieben. Zur Dokumentation (Tumfart: "Rein manuell, händisch") wird eine genormte Programmakte geführt, in der beispielsweise Umwandlungslisten abgelegt werden. Dabei wird allerdings weitgehendst darauf verzichtet, Programmablaufpläne zu schreiben. "Flußdiagramme sind unserer Meinung nach nicht unbedingt erforderlich. Der Programmierer kann Programme viel besser anhand der mit Kommentarzeilen versehenen Codierung testen", begründet der Software-Profi seine "Anti-Flow-Chart-Philosophie". Außerdem sei die manuelle Wartung der Ablaufpläne bei Programmänderungen nur mit sehr großem Aufwand möglich. "Daher über lassen wir die Entscheidung über das Führen von Flow-Charts den Programmierern und geben auch grundsätzlich keinerlei Programmiervorgaben von der Systemanalyse oder EDV-Organisation in Form von Flußdiagrammen an die Systementwickler", berichtet der Abteilungsleiter.
Bei der jährlich von einem Wirtschaftsprüfungsunternehmen durchgeführten EDV-Revision kam es dann allerdings zu einem "dauernden Konflikt": "Die verlangten kategorisch von uns das Vorlegen von Programmablaufplänen für einzelne Anwendungen - eine Forderung, der wir nicht entsprechen konnten und auch nicht wollten", erzählt Tumfart. Und weiter: "Da wir die Revisoren nicht davon überzeugen konnten, daß es auch ohne Flußdiagramme geht, mußten wir in den sauren Apfel beißen und die Möglichkeit schaffen, Flußdiagramme schreiben zu können." Und das war schließlich der Grund, daß zirka 30 000 Mark aus dem EDV-Budget lockergemacht wurden, um ein Flow-Chart-System zu beschaffen, betont der Programm-Chef.
Die Softwareentwickler bei Klöckner machten die Erfahrung, daß Auswahl und Vergleich von Softwarepaketen durch Man-Power-Aufwand und Maschinenzeiten für Vergleichsläufe schnell zu einer kostenaufwendigen Angelegenheit werden kann. "Wir gingen deshalb ganz pragmatisch vor, indem wir uns im ISIS Software Report über das einschlägige Angebot orientierten, den Anbieter-Kreis mit Preis-, Installationszahl- und Firmen-Renommee-Untersuchungen sehr schnell einengten und nur zwei in Frage kommende Firmen mit ihren Produkten zu Test- und Demonstrationsläufen einluden", erinnert sich der Klöckner-Mann. In die Endauswahl dieses "relativ bescheidenen Verfahrens" kamen die Flow-Chart-Systeme "Quick-Draw" von Zeda und "Autoflow" von CPP.
Nach Preis- und Leistungsvergleichen dieser beiden Pakete fiel dann die Entscheidung für "Quick-Draw".
Seit zirka einem Jahr werden bei Klöckner Programmablaufpläne mit dem ZEDA-Flow-Chart-System erstellt, "die den exakten Programmablauf irrtumsfrei widerspiegeln". Dabei würden allerdings nur auf Anforderung Flußdiagramme gezeichnet, "da die Diagramme doch veralten, wenn sie in der Dokumentationsmappe abgelegt werden".
Die Revisoren wären jetzt aber sehr zufrieden, denn auf deren Forderungen könne jetzt schnell und sicher reagiert werden: "Wenn die eine Anwendung prüfen wollen, lassen wir eben schnell von Quick-Draw den Ablaufplan der aktuellen Programm-Version erstellen."
"Als Bonus, den man bei diesem Paket mitgeliefert bekommt, haben sich bei uns außerdem die zusätzlichen Diagnostik-Möglichkeiten bewährt", freut sich Tumfart über den positiven Nebeneffekt. Über die Möglichkeiten des COBOL-Compilers hinaus könnten anhand von "umfangreichen Cross-Referenz-Listen" logische Schwachstellen beziehungsweise Programmfehler diagnostiziert werden. Es werden beispielsweise Value-Eintragungen in der Data-Division referenziert und ein Überblick der Verarbeitungen mit einem Feld gegeben. Außerdem seien auch Programmschleifen-Diagnosen möglich. "Eigentlich gehören diese Funktionen in den Compiler. Doch die haben in der Regel weder ausführlich Cross-Referenz-Listen noch gehen sie über eine Diagnose von Formalfehlern hinaus", kritisiert der Software-Spezialist die Mängel von kommerziellen Programmiersprachen.