Re-Engineering ist nicht die neue Ersatzdroge für CASE, sondern eine notwendige Ergänzung des gesamten Software-Lebenszyklus auf der Basis eines Engineering-Gesamtkonzeptes. Nur unter Einschluß von Re-Engineering-Tools läßt sich, so Marc Hirschleber*, eine vollständige Basis für ein künftiges Computer Integrated Software Engineering (CISE) schaffen.

Was ist es eigentlich, was wir vom Re-Engineering erwarten? Einen vollständig automatisierten Prozeß - eine Black box -, in den wir unseren unstrukturierten, fehlerbehafteten, undokumentierten, auf der Basis von Dateien geschriebenen und von beliebigen Systemebenen stammenden Code eingeben, worauf wir uns geduldig zurücklehnen können und wenig später sauber strukturierte, vollständig dokumentierte, CASE-orientierte Programme erhalten, die auf beliebige Computer-Plattformen portierbar sind?

Schön wär's! Mit dieser Erwartungshaltung sollten Sie Re-Engineering am besten gleich vergessen.

Es ist noch gar nicht so lange her, da kamen wir scheinbar noch ohne Re-Engineering aus. Aber dann führte das Fehlen von durchdachten Datenmodellen, von Dokumentationen der Programmsysteme sowie von automatisierten Entwicklungswerkzeugen zur Softwarekrise, die ihren Ausdruck in einem starken Anwachsen der Wartungstätigkeiten fand.

Um einerseits den Wartungsprozeß effektiver zu gestalten und andererseits einen effizienten Softwarezyklus zu erhalten, mußte man sich der Methoden und Verfahren des Software-Engineering annehmen. Hieraus entstand die Disziplin des Re-Engineering.

Re-Engineering ist wesentlich mehr als Softwarewartung, aber ein effizienter Wartungsprozeß ist der Schlüssel zum Re-Engineering.

Abgrenzung der Begriffe

Die Begriffe Restructuring, Reverse Engineering und Re-Engineering werden häufig miteinander verwechselt. Deshalb ist es notwendig, zunächst eine Abgrenzung vorzunehmen: Restructuring bedeutet, die Programmstruktur eines korrekt arbeitenden Programms auf der Basis fest vorgegebener Algorithmen neu zu arrangieren. Das reicht von "optischer Aufbereitung", sprich: Einrücken von Codierungszeilen, bis hin zur Verbesserung der Kontrollstruktur von Programmen.

Da es zu geordneten Codierungszeilen führt, kann das Restructuring bei der Softwarepflege gute Dienste leisten. Anwendbar ist es vor allem im Bereich alter, umfangreicher Batch-Programme, die gegebenenfalls redundanten Code enthalten.

Mit Reverse Engineering ist die Rückwärtsentwicklung vom ablauffertigen Programm zu den Analyse- oder Design-Informationen und gegebenenfalls zu einer erneuten Generierung auf der Basis funktionaler Äquivalenz gemeint. Mit Hilfe dieser Methode können wir herausfinden, wie ein Programm arbeitet. Reverse Engineering reicht jedoch nicht aus, um Fehler zu beseitigen oder Kundenanforderungen zu adaptieren; auf diese Weise bleiben schlechte Systeme nämlich in bezug auf ihre Funktionen unverändert.

Re-Engineering hingegen umfaßt das Re-Design einer mängelbehafteten Anwendung mit dem Ziel, eine bessere Anwendung zu erstellen. Re-Engineering verlangt intelligente Eingaben, um schlechte Designentscheidungen zu identifiziere und sie durch bessere zu ersetzen. Das ist oftmals genau das, was der Anwender möchte wenn er von Restructuring oder von Reverse Engineering spricht.

Ein signifikanter Abbau des Wartungsstaus läßt sich nur über Re-Engineering-Verfahren - eingebettet in ein automatisiertes Gesamtkonzept - realisieren.

Aus mangelnder Automatisierung und den Methoden des Software-Engineering hervorgegangen, liegt der Schwerpunkt von CASE weiterhin auf dem Engineering-Konzept, welches den gesamten Anwendungsentwicklungsprozeß einbezieht und die dafür notwendigen Werkzeuge umfaßt. Es stellt sich die Frage, wann eigentlich der Erstellungsprozeß abgeschlossen ist beziehungsweise ob er jemals beendet wird.

Verstehen wir den Entwicklungsprozeß als fortwährenden Zyklus, dann stellt das Re-Engineering eine Untermenge des Software-Engineering dar. Entscheidend ist an dieser Stelle nicht, wie sich CASE und Re-Engineering beziehungsweise Neuentwicklung und Wartung voneinander abgrenzen lassen sondern wie sie sich jeweils auf den Anwendungsentwicklungs-Prozeß auswirken.

Neuentwicklung von exotischen Altsystemen

Es ist nicht zu bestreiten, daß der Anteil der Wartungsaufgaben im Verhältnis zur Neuentwicklung von Systemen in den vergangenen Jahren stark angestiegen ist. Die Pflegebedürftigkeit der in Produktion befindlichen Programme hat ja gerade zum Anwendungsstau geführt. Die Hauptursache hierfür liegt in den qualitativ minderwertigen Systemen begründet, die nur sehr aufwendig zu warten sind, und keineswegs etwa in der Tatsache, daß der Bedarf an zusätzlichen Softwaresystemen nicht gegeben sei.

Aber wir brauchen auch Ressourcen für die Neuentwicklung exotischer Altsysteme, also selbstentwickelte Systeme, Sprachen mit geringem Verbreitungsgrad etc., beziehungsweise solcher Systeme, für die es Re-Engineering-Automatismen nicht geben wird oder bei denen der Re-Engineering-Aufwand unverhältnismäßig hoch wäre. In welchen Fällen ein Re-Engineering-Ansatz vorzuziehen ist, läßt sich, pauschal nicht beantworten. Eine Kosten-Nutzen-Analyse und langfristige Wartbarkeits-Einschätzungen in bezug auf das Gesamtsystem müssen hier im konkreten Fall den Ausschlag geben.

Systemübergreifende Technologien fehlen

Eine inadäquate Ausrichtung der Anwendungsentwicklungs-Technologien und die Inkompatibilität vieler Tools erschweren uns den Weg zu einem effizienten Re-Engineering-System. Auch für das Re-Engineering sind Standards, ein Repository und die Integration von Upper- und Lower-CASE-Informationen relevant. Systemübergreifende Technologien, die sowohl dem Engineering wie auch dem Re-Engineering entscheidende Impulse vermitteln könnten, sind bislang Mangelware.

Ein Zusammenspiel der verfügbaren Tools ist notwendig, da es kein Werkzeug geben wird, das alle Aspekte des Re-Engineering allein abdeckt. Dabei kommt einem offenen und flexiblen (Projekt-)Repository als Basis eines Re-Engineering-Ansatzes besondere Bedeutung zu. Die Integration von Informationen aus existierenden Systemen in ein firmenkonformes Ablageschema zur weiteren Sytementwicklung ist obligatorisch.

Re-Engineering läßt sich nur mit Tool-Unterstützung sinnvoll einsetzen. Entsprechende Produkte decken einzelne Aspekte des Re-Engineering ab und erzielen deutliche Wartungsvorteile. Doch erst in einem abgestimmten Gesamtkonzept aller Komponenten können wir signifikante Verbesserungen erzielen. Ein alles umfassendes Repository wird dazu gar nicht benötigt.

Tools decken nur Teilbereiche ab

Kann ein isoliertes Re-Engineering unsere Probleme lösen? Die verfügbare Tools decken jeweils nur Teilbereiche des Re-Engineering ab. Bei einer Migration zum Beispiel ist fraglich, ob einer gegebenenfalls notwendigen Nachdokumentation Rechnung getragen und wie der Zugriff anderer Komponenten auf das neue System realisiert wird, ob nur Daten und/oder Prozesse übernommen und wo die gewonnenen Informationen abgelegt werden. Vor dem Einsatz jeglicher Werkzeuge für das Re-Engineering sollte eine Betrachtung des (Engineering-)Gesamtkonzepts erfolgen.

Für eine Infrastruktur, die sowohl den Bereich der Anwendungsentwicklung als auch das Re-Engineering abdeckt, ist zunächst der organisatorisch-technische Ablauf von entscheidender Bedeutung. Auf der Basis zentraler Entscheidungen Hardware, zentrale oder verteilte Architektur, Standards etc. muß ein Konzept aufgebaut werden, das Aufschluß über zweierlei gibt: die Methoden, die bei der Software-Entwicklung zum Einsatz kommen, und die Ergebnisse, die zu erzielen sind. Darauf sollten dann die Tools und die Informationsablage - jeweils mit einer offenen Architektur - aufsetzen.

Eine methodisch integrierte Tool-Infrastruktur erhöht die Effekte auf den gesamten Bereich der Anwendungsentwicklung. Ohne Engineering-Konzept können wir weder sinnvoll Software erstellen noch pflegen. Es wird notwendig sein, Analyseinformationen aus Programmen herauszuziehen und diese in einem zweiten Schritt in ein (Projekt-)Repository zu überführen, um sie daraufhin an aktuelle Gegebenheiten anpassen zu können. Ausschließlich auf diesem Weg können wir dem ständig ansteigenden Wartungsproblem entgegenwirken.

Ein neues Schlagwort

CASE ist tot, es lebe der objektorientierte Ansatz! Objektorientierte Anwendungen erleichtern die Wartung erheblich, sind aber in erster Linie im Bereich der Neuentwicklung angesiedelt. Gute Entwickler beziehungsweise Entwicklungsabteilungen haben zudem schon vor "Bekanntwerden" dieser neuen Technologie objektorientiert gearbeitet.

Allerdings kann die reine Präsenz dieser Methoden das Problem der "Altlasten" ebenso wenig lösen, wie CASE-Tools und -Methoden es können. Eine Überführung von Informationen über das Re-Engineering in objektorientierte Systeme ist sicherlich anzustreben und mit Hilfe entsprechender Algorithmen aus dem Bereich der Expertensysteme auch denkbar; hinsichtlich einer automatischen Konvertierung stehen wir allerdings noch am Anfang der Entwicklung.