Altanwendungen muessen nicht immer Altlasten sein - in vielen Unternehmen sind sie wichtige Know-how-Traeger. Sie vollstaendig zu ersetzen hiesse, bewaehrte interne Informations- und Ablaufstrukturen zu veraendern. Friedrich Oberndoerfer* schildert am Beispiel der TWS AG, Stuttgart, wie es gelungen ist, PL/1- Programme zu sanieren, ohne den laufenden Betrieb zu stoeren. Der Aufwand, so zeigt sein Beitrag, war betraechlich: Rund 60 Mannmonate wurden in die Restrukturierung der PL/1-Programme investiert. TWS engagierte dafuer ein Beratungshaus.

Nahezu jeder groessere DV-Anwender ist auf seine bestehenden Softwaresysteme angewiesen: Sie haben sich im Laufe der Jahre bewaehrt, die Mitarbeiter sind an den Umgang mit ihnen gewoehnt. Allerdings gibt es auch gravierende Nachteile: Alte Anwendungen sind erfahrungsgemaess unempfaenglich fuer revolutionaere Neuerungen. Wer dennoch - wie die Technischen Werke der Stadt Stuttgart (TWS) - Veraenderungen in Gang bringen will, muss ganzheitlich vorgehen und einen evolutionaeren Entwicklungsprozess einleiten.

Im Dezember 1992 gaben die TWS den Startschuss fuer ihr Projekt "Energis". Folgende Ziele galt es zu verwirklichen:

- Durchsetzung einer Informationsstrategie unter Einbeziehung aller Fuehrungsebenen;

- Ermittlung des Informationsbedarfs;

- Suche nach einer neuen Entwicklungs- und Projektierungsmethode;

- Analyse und Gesamtplanung unter dem Arbeitstitel "Energis";

- Suche und Bewertung der Teilprojekte fuer Neuentwicklung;

- Suche nach Festlegung von Wartungsprojekten;

- Suche und Festlegung von Sanierungsprojekten sowie

- PL/1-Restrukturierung.

In der ersten Projektphase wurden mit Unterstuetzung eines externen Beraters Interviews mit dem Vorstand, dem Management und den Mitarbeitern in den Fachbereichen gefuehrt. Sie gaben ihre Anforderungen, Kritikpunkte und Ideen zu neuen Anwendungsprogrammen zu Protokoll. Darueber hinaus nahmen die Projektmitarbeiter die Ziele der einzelnen Bereiche auf und fassten sie in einer Zielmatrix zusammen. Nach der Auswertung der Befragung wurden die "kritischen Erfolgsfaktoren" sowie die "kritischen Annahmen" zu den Zielen ermittelt und in der Zielmatrix vermerkt (siehe Abbildung 1).

Auf Basis der Interviews liess sich der strategische Informationsbedarf formulieren. Um jedoch den tatsaechlichen Informationsbedarf einigermassen praezise feststellen zu koennen, erarbeitete ein wechselndes DV-Team in Zusammenarbeit mit Mitarbeitern aus den Fachbereichen eine "Informationsstruktur der energiewirtschaftlichen Anwendungen". Dabei ging die TWS davon aus, dass alle unternehmensrelevanten Daten bereits in den Datenbanken, Dateien oder Archiven des Unternehmens dokumentiert sind.

So war es moeglich, eine realitaetsnahe Informationsstruktur mit vertretbarem Arbeitsaufwand zu erstellen. Parallel musste zunaechst eine neue Entwicklungsmethode gefunden werden, die wie folgt festgelegt wurde:

- Abkehr von den funktionsorientierten Systementwicklungen;

- Basis der Anwendung sind nicht laenger die Organisationsstrukturen, sondern die stabileren Datenelemente;

- einzelne Bausteine sollen wiederverwendet werden koennen;

- die Gesamtheit der Aktionen auf ein bestimmtes Objekt darf nur in einem Teilprojekt enthalten sein;

- Minimierung der Schnittstellen, die zwischen den einzelnen Projekten bestehen;

- es muss ein enger Zusammenhang zwischen den einzelnen Objekten bestehen, die in einem Projekt zusammengefasst sind;

- die industrielle Fertigung der Programme muss erreicht werden (zum Beispiel Programmrahmen mit Generatoren).

Nach der Festlegung von Zielen und Methoden wurden die einzelen Aufgaben auf mehrere Projektteams verteilt: Eine Gruppe wurde mit der Aufgabe betraut, ein CASE-Werkzeug auszuwaehlen - sie entschied sich fuer

"ADW" von Knowledgeware. Eine andere sollte dieses Tool um die TWS-spezifischen Anforderungen - abgeleitet aus den neuen Entwicklungsmethoden - erweitern. Ein drittes Team stellte das Schulungskonzept auf. In weiteren Gruppen wurde die definierte Methode an einer prototypischen Anwendung geprobt und die Methoden und Werkzeuge an die TWS-Erfordernisse angepasst.

Die Informationsstrukturen der bestehenden Anwendungssoftware wurden als Gesamtmodell "Energis" mit etwa 500 Entitaeten als Entity-Relationship-Diagramm dargestellt. Aufgrund der methodischen Anforderungen mussten Teilprojekte gebildet werden.

25 Teilprojekte wurden geschaffen

Da ein solches nur maximal 30 Entitaeten enthalten sollte, waren insgesamt 25 Teilprojekte zu formieren, die wiederum aufgeteilt wurden in:

1. Projekte, die sich unabhaengig voneinander realisieren lassen;

2. Projekte, deren Umsetzung die vorherige Durchfuehrung anderer Projekte voraussetzt, und

3. Projekte, die von Organisationsprojekten abhaengig sind.

Mit einer solchen Aufteilung sollte das Entwicklungsrisiko auf das jeweils realisierte Projekt minimiert werden. Ausserdem konnte die Nutzung der Teileinheiten schneller wirksam werden. In der Realisierungsphase kristallisierten sich jedoch zwei massgebliche Probleme heraus.

Man stellte zum einen fest, dass trotz Neuentwicklung und Migrationsstrategie zwischen alten und neuen Anwendungen erhebliche Wartungsaufgaben fuer die Altsysteme anfallen wuerden, die einzuplanen waren. Zum anderen musste das strategisch wichtige Anwendungssystem "Statistik/Buchhaltung" durch geeignete Sanierungsmassnahmen in einen wartungsfaehigen Zustand versetzt werden.

PL/1-Anwendungen aus den fruehen 70ern

Um diese Probleme effizient zu loesen, kam man auf den naheliegenden Gedanken, die Programmiersprache PL/1 zu restrukturieren. Die PL/1-Anwendungen waren Anfang der 70er Jahre geschrieben und seitdem an neue Anforderungen angepasst worden. Entsprechend unstrukturiert erschienen sie auf den ersten Blick. Fuer die TWS waren sie jedoch von zentraler Bedeutung. Auch war eine etwaige Abloesung durch Neuentwicklung oder Standardsoftware - zumindest in absehbarer Zukunft - auszuschliessen.

Dem TWS-Vorstand schien die PL/1-Restrukturierung sinnvoll, wenngleich sie einen Arbeitsaufwand von 60 Mannmonaten mit sich brachte. Leider stellte sich schnell heraus, dass keine vernuenftigen Sanierungs-Tools fuer PL/1-Programme auf dem Markt erhaeltlich waren, was die TWS-Fuehrung zu dem Entschluss brachte, einen Partner mit Werkzeug- und Software-Entwicklungserfahrung zu suchen. Die Wahl fiel auf die Koelner Collogia Unternehmensberatung GmbH.

Dem Beratungshaus oblag es nun, die PL/1-Anwendungen der TWS in eine standardisierte, revisionsfaehige formale Struktur zu bringen. Der Aufbau des Programms war somit fest vorgegeben. Um auch tatsaechlich eine Unterstuetzung der Wartungsarbeiten zu erzielen, mussten saemtliche Anwendungen analysiert und die Ergebnisse in einem Repository nachvollziehbar bereitgestellt werden. Hier waren nicht nur die Informationen zum jeweiligen Programm von Belang, sondern auch dessen Einbettung in die Job-Ablaeufe.

Mit der Restrukturierung der Anwendungssoftware sollte immer nur dann begonnen werden, wenn sowieso Wartungsarbeiten anstanden. Durch dieses schrittweise Vorgehen sparte die TWS Kosten und Arbeitskapazitaet.

Dieser "evolutionaere Weg" braucht Zeit. Die Restrukturierung von Programmen ist ein langfristiges Vorhaben, an dem mehrere Mitarbeiter zu unterschiedlichen Zeiten beteiligt sind. Eine geeignete Werkzeugumgebung ist mithin unumgaenglich (vgl. Abbildung 2).

Mangels adaequater Standard-Tools zur Restrukturierung von PL/1- Software, stellten die Unternehmensberater eine spezifische Werkzeugumgebung - die "Collcare Workbench" - aus den vorhandenen Bausteinen zusammen. Die Basis fuer das Repository dieser Workbench bildet das Datenbanksystem "Entire SQL-DB Server" (heute "Adabas D") der Software AG.

Sie kommt mit den Utility-Programmen "Xload", "Xquery" und "Xutil" zum Einsatz. Alle Funktionen sind in einer CUA-kompatiblen (Common User Access) Oberflaeche integriert, wobei "Analyse" und "Restrukturierung" die beiden wichtigsten Funktionsbereiche darstellen. Unter "Analyse" gibt es je einen Parser (syntaktischen Analysierer) fuer die Programmiersprachen PL/1 und JCL sowie drei spezielle Analysatoren fuer die Metrik-, Scope- und Datenbankstruktur-Analyse. Der Funktionsbereich "Restrukturierung" enthaelt Hilfsinstrumente zur Visualisierung von Strukturen (Browser) sowie zum Erkennen und Umsetzen von Strukturmustern.

Alle Browser sind mit dem integrierten Editor "Micro-Emacs" verknuepft, so dass die einzelnen Strukturen in verschieden Praesentationsformen am Bildschirm zu sehen sind. Micro-Emacs ist ein Sharewareprodukt, das Forderungen wie freie Programmierbarkeit ueber Makros, Aufruf anderer Programme im Editor oder das Arbeiten in mehreren Puffern voll erfuellt. Durch die Wahl der Basiswerkzeuge und Programmiersprachen ist die Portabilitaet der Workbench fuer MS-Windows und OS/2 gewaehrleistet.

Die Restrukturierung der PL/1-Programme mit Hilfe der Collcare Workbench vollzieht sich halbautomatisch. Das System erkennt bestimmte vorgegebene Muster im Programm und schlaegt sie zur Restrukturierung vor. Die Entscheidung, welche Massnahmen nun durchgefuehrt werden sollen, muss jedoch der Programmierer faellen.

Der Vorteil: Die Ergebnisse finden bei den Programmierern mehr Akzeptanz als vollautomatische Restrukturierungsprogramme, da sich die Mitarbeiter durch ihre Miteinbeziehung in diesen Prozess staerker mit dessen Resultaten identifizieren koennen.

Die Erfahrung zeigt, dass sich mit dem Tool "Collcare Workbench" und der geschilderten Vorgehensweise eine Personenunabhaengigkeit selbst bei komplizierten Anwendungsprogrammen erreichen laesst - denn diese Methode foerdert auch den Lernprozess des Wartungstechnikers. Hinzu kommt, dass seine Arbeit durch den Einsatz dieses Werkzeugs aufgewertet wird. Nach der Restrukturierung rechnet TWS nur noch mit einem Drittel des frueheren Wartungsaufwands.

Die restrukturierten Programme selbst wurden insgesamt qualitativ aufgewertet, da wesentliche Maengel durch die Sanierung beseitigt wurden. Ihre verbesserte Struktur und Dokumentation erhoehte die Revisionsfaehigkeit. Eine Tatsache, die fuer die TWS aeusserst wichtig war, da die restrukturierten Programme von einer externen Pruefungsgesellschaft gecheckt werden sollten. Im Betriebsalltag liess sich feststellen, dass die Anwendungen in Ausnahmesituationen und im Fehlerfall eine verbesserte Reaktionsfaehigkeit zeigten.

Bei der TWS war die Restrukturierung der Programme das ausschliessliche Ziel. Doch ist ein Einsatz dieser Werkzeugumgebung und Methode auch in anderen Projekten denkbar. Beispielsweise dort, wo es primaer um die Aenderung der Systemarchitektur geht.