Unstrukturierte Programme gehen zu Lasten der Neuentwicklung; sie binden einen Großteil der Kapazitäten in Wartung und Pflege ein. Die Entscheidung, veraltete Software durch Neuentwicklungen zu ersetzen, bedeutet jedoch die Preisgabe von Anwender-Investitionen. Eine mögliche Alternative ist das "Reverse-Engineering". Klaus Lutosch* beschreibt die Hintergründe.
Es gibt DV-Verantwortliche, denen das Schlagwort "Software-Krise" nicht den Schlaf raubt. Diese Glücklichen haben ein konstantes Anwendungsumfeld, wohlstrukturierte und wartungsfreundliche Systeme oder aber stets genügend Ressourcen für die Pflege und Entwicklung zur Verfügung.
Für den Rest der DV-Leiter sieht die Situation anders aus: Gewachsene und oft unzureichend dokumentierte Programmsysteme versperren den Weg in die Zukunft, weil sie aufgrund ihrer lange zurückliegenden Entstehungszeit und der häufigen partiellen Veränderungen weitgehend unwartbar geworden sind. Durch Personalfluktuation ist zudem ein Know-how-Verlust eingetreten, der jeden Eingriff in ein solches System zu einem Abenteuer macht.
Deswegen ist immer mehr und immer höher qualifiziertes Personal in die Wartung und Pflege der Programme eingebunden. Anpassungen und Erweiterungen aufgrund neuer Anforderungen werden immer aufwendiger, der Personalanteil für notwendige Neuentwicklungen hingegen immer kleiner; er reicht also nicht aus, um die ständig wachsenden Zukunftsaufgaben der Büro- und Fabrikautomation zu bewältigen. Es ist vielmehr zu erwarten, daß in absehbarer Zeit zusätzliches Personal nur für Wartung und Pflege aufgebaut werden muß. Der Anwendungsstau beträgt in vielen Unternehmen bereits drei bis acht Jahre.
Diesen Trend zu stoppen, um die immensen Investitionen, die bereits in das Programmvolumen gesteckt wurden, nicht eines Tages völlig ab schreiben zu müssen, ist Aufgabe des Reverse-Engineering. Der Begriff kommt, wie viele neue Ideen auf dem Gebiet der Softwareentwicklung, aus den USA. Dort hat man sich darauf besonnen, wieviel Investitionskapital in bereits bestehende umfangreiche Programmsysteme gesteckt worden ist und welche Vergeudung von Ressourcen es bedeutet, wenn man diese alle fünf bis zehn Jahre durch neue ersetzt. Daran knüpft sich sehr schnell der Gedanke, ganze Systeme oder große Teile davon zu überarbeiten und zu modernisieren.
Beim Reverse-Engineering geht es zunächst darum, die vorliegende Struktur des Programmsystems zu analysieren und grafisch darzustellen. So können zum Beispiel "tote Zweige", verwirrende Sprungtechniken, "Balkonausbauten" und anderer Wildwuchs erkannt werden. Im nächsten Schritt lassen sich diese Fehlstrukturen bereinigen; gleichzeitig entsteht eine neue, aktuelle, grafisch aufbereitete Beschreibung des Programmsystems. Ziel ist die Verbesserung und Vereinheitlichung der Systemstruktur und der technischen Dokumentation. Dadurch können die Programme leichter gewartet werden; außerdem verbessern sich die Weiterentwicklungsmöglichkeiten und die Lebensdauer. Im Endeffekt wird Pflegekapazität eingespart und für neue Entwicklungsaufgaben freigesetzt.
Reverse-Engineering hilft auch, neuen Anforderungen an die Systembasis gerecht zu werden; dazu gehören beispielsweise der Austausch alter Datenhaltungskomponenten durch ein Datenbanksystem oder die Ablösung einer Dialogoberfläche durch einen Transaktionsmonitor. Hier liefert das Reverse-Engineering die Ist-Strukturen, aus denen die Soll-Strukturen für das Gesamtsystem einschließlich der neuen Teile konstruiert werden können. Ein weiteres Einsatzgebiet ist die Einführung neuer Sprachstandards wie zum Beispiel Cobol85.
Es steht heute außer Frage, daß nur gut strukturierte und dokumentierte Programmsysteme die qualitativen Voraussetzungen bieten, mit einem Minimum an Personalaufwand Wartung und Pflege zu betreiben. Bereits die Mehrzahl der aktuellen höheren Programmiersprachen unterstützt in Verbindung mit modernen Entwurfsmethoden die Entwicklung solcher Systeme.
Eine rechte Plage für viele Anwender sind die zahlreichen Code-lines, die vielfach aus Zeiten stammen, in denen der Programmierer noch als Künstler galt. Sie gilt es neu zu strukturieren, zu optimieren und nachzudokumentieren. Lokale Ad-hoc-Sanierung nach dem Motto "Wenn ich schon mal an der Ecke ändere, mache ich sie gleich neu" bringt hier keine akzeptable Lösung. Das Reverse-Engineering muß sich auf kom......