Der allseits bekannte Entwicklungs- ist eigentlich ein Wartungsstau. Demzufolge muesste den DV-Leitern daran gelegen sein, mit minimalem Aufwand den Wuenschen der Anwender nachzukommen - das Gegenteil scheint der Fall. Peter Reger* beschreibt die Ergebnisse einer Recherche, die den Bedarf an Re-Engineering-Tools feststellen sollte. Die Projektarbeit zeigte unter anderem, dass Anbieter und Nachfrager zuwenig voneinander wissen.

Die in diesem Jahr durchgefuehrten Marktforschungs -beziehungs- weise Akquisitionsprojekte fuer Re-Engineering-Produkte hatten zur Aufgabe, die grundsaetzliche Haltung der DV-Entscheider zu ermitteln und den Bedarf festzustellen. Gegenstand waren Re- Engineering-Tools fuer PL/1- und Cobol-Programme.

Telefonisch angesprochen wurden DV-Bereichsleiter, Leiter der Anwendungsentwicklung beziehungsweise der Abteilung "Methoden und Verfahren" von mittleren und grossen Unternehmen. Diese haben ueberwiegend PL/1- beziehungsweise Cobol-Programme im Einsatz.

Die Gespraechsbereitschaft war sehr gross. Die Ansprechpartner waren durchweg offen dafuer, ueber ihre Sicht des Themas Re-Engineering Auskunft zu geben und die Moeglichkeiten zu diskutieren.

Die DV-Verantwortlichen mach- ten keinen Hehl aus der Tatsache, dass 3GL-Programme nach Stueckzahlen gerechnet noch einen grossen Anteil an der produktiven Software haben. Ebenso bestaetigten sie, dass die Wartung dieser Anwendungen oft aeusserst aufwendig ist; dies gilt vor allem, wenn sie schlecht dokumentiert sind und ihr Autor das Unternehmen bereits verlassen hat. Die bestehende Softwarelandschaft in den Unternehmen wird zunehmend durch Standardsoftware beziehungsweise durch Client-Server-Architekturen mit anderen Sprachen und neuen Technologien ersetzt.

3GL-Programme laufen noch jahrelang weiter

Einmuetige Meinung der DV-Leiter war allerdings auch, dass dieser Prozess Jahre in Anspruch nehmen wird - und so fristen die 3GL- Programme ihr Dasein weiter.

Die Pro- und Kontrastimmen zum Thema Re-Engineering - bezogen auf alle befragten Unternehmen - hielten sich fast die Waage (vgl. zu den folgenden Ergebnissen die Abbildung). Dass nahezu die Haelfte aller DV-Leiter dem Re-Engineering ablehnend gegenuebersteht, hat im wesentlichen zwei Gruende: zum einen will man Standardsoftware einsetzen, zum anderen sucht man noch nach Loesungen und denkt dabei auch ueber Neuentwicklungen nach.

Der Einsatz von PL/1-Anwendungen ist offensichtlich ein Motivationsfaktor fuer Re-Engineering.

Die Re-Engineering ablehnenden Unternehmen planen folgendes: Zirka drei Viertel sehen sich zukuenftig eher als Standardsoftware- Anwender und zirka ein Viertel wird neue Programme entwickeln. Dass sich die letztere Gruppe nicht mit Re-Engineering befasst, hat hauptsaechlich einen Grund: Mit den bekannten Tools laesst sich aus bestehenden Programmen kein wertvolles Know-how fuer die Neuentwicklung nutzbar machen.

Vielfach werden Anforderungen der Fachbereiche argumentativ dazu genutzt, bestehende Programme nicht mehr anzupassen. Hierbei wird oft ausser acht gelassen, dass eine im Rahmen des Re-Engineerings zu erreichende Modularitaet die Voraussetzung schaffen koennte, grosse Teile der Programme wiederzuverwenden. Eine positive Einstellung zum Re-Engineering zeigen meist solche Unternehmen, die so viele 3GL-Programme im Einsatz haben, dass an eine Abloesung in den naechsten Jahren nicht zu denken ist. Gruende hierfuer sind die Individualitaet (keine Standardsoftware am Markt), die grundsaetzliche Zufriedenheit mit den Anwendungen (aber es mangelt an der Wartbarkeit) oder fehlende finanzielle Mittel, um alternative Loesungen angehen zu koennen.

So haben bereits einige Unternehmen Re-Engineering-Massnahmen durchgefuehrt - viele DV-Leiter werden sich in naher Zukunft mit dem Thema konkret beschaeftigen. Die Erfahrungen mit Re- Engineering-Werkzeugen waren nicht immer positiv.

Manche Tools koennen zuwenig an die individuelle Regelbasis der Programmstile angepasst werden.

Vollautomatische Werkzeuge, die ohne Dialog mit dem Entwickler arbeiten, haben teilweise unbefriedigende Resultate erbracht. Sicherlich ist davon auszugehen, dass der Lernprozess fuer alle Beteiligten noch nicht abgeschlossen ist.

Software wird - gestern wie heute - mit grossem finanziellem Aufwand entwickelt. Hierauf basieren die Chancen des Re- Engineerings. Auch wenn Programme schlecht dokumentiert sind, hat das Re-Engineering derselben seine Berechtigung, weil dadurch das bereits bezahlte Gedankengut der Vergangenheit gerettet wird. Darauf aufbauend koennen dann die erforderlichen Aenderungen durchgefuehrt werden: vielfach kostenguenstiger und effektiver. Das ist die Argumentation der DV-Verantwortlichen, die gute Erfahrungen mit Re-Engineering-Tools gemacht haben.

Fehlende Aufklaerung ueber die Chancen und Risiken

Die Projektarbeit hat gezeigt, dass Anbieter und Nachfrager zuwenig voneinander wissen:

- Die Nachfrager, weil sie zwar Re-Engineering in Betracht ziehen, die Idee aber nicht konsequent verfolgen, was seine Ursache in der bislang fehlenden Aufklaerung seitens der Anbieter ueber Chancen und Risiken hat. So haben einige DV-Leiter schlechte Erfahrungen gesammelt, die andere davon abhalten, sich mit dem Thema ueberhaupt auseinanderzusetzen.

- Die Entwickler von Re-Engineering-Tools andererseits ruehren die Werbetrommel zuwenig - mit dem Effekt, dass potentielle Anwender keinen Marktueberblick haben und zur Neuentwicklung oder zur Abloesung durch Standardsoftware greifen.

Haltungen zum Re-Engineering

DV-Verantwortliche, deren Unternehmen mit PL/1-Applikationen arbeiten, sind Re-Engineering-Massnahmen gegenueber tendenziell positiv ein- gestellt. Anwender von Cobol-Programmen interessieren sich fuer entsprechende Verfahren und Tools weniger.

*Peter Reger ist geschaeftsfuehrender Gesellschafter der Data Marketing Service GmbH, Koeln.