Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

17.12.1993

Zeit zum Re-Engineering

Innovation bei gleichzeitiger Bestandssicherung ist ein Dauerproblem. Heute vielleicht weniger brennend, weil einerseits die Rezession Manpower zur Verfuegung stellt, andererseits die ueberall zumindest diskutierte Reorganisation, verbunden mit der Dezentralisierung der DV, ins Haus steht.

Das heisst, dass die Wirtschaft den Zwang zur Erneuerung der Verfahren und Organisationsformen zwar in aller Haerte spuert, Ausreden im Sinne von "fehlendes Know-how" oder auch "Personalprobleme" indes gegenstandslos sind.

Angedacht wird in wenigen Einzelfaellen der voellige Neuansatz, das bedeutet

- erst Tabula rasa und dann beispielsweise eine Client-Server- Konfiguration unter Unix oder eben

- stufenweise Einfuehrung neuer Strukturen und Techniken.

Dann - und dies wird der haeufigere Fall sein - muss das leidige Problem des Software-Re-Engineerings angepackt werden.

Das zentrale Ziel aller einschlaegigen Re-Engineering Bemuehungen ist das Aufruesten von Altsystemen auf die aktuelle Softwaretechnologie, um auf dieser Ebene die weitere Pflege und Wartung des Systems sicherstellen zu koennen. Das entspricht in vielen Faellen dem Ansatz, das Design aus den vorhandenen Loesungen abzuleiten und eine Reimplementierung auf dieser Basis vorzunehmen.

Dass dieser Ansatz auf Skepsis stoesst, ist vorstellbar: Informationen, die ein Dokument nicht enthaelt, koennen auch mit noch so intelligenten Tools nicht wiedergefunden werden (siehe "Anwendungssystem-Analyse als Basis fuer Kosteneinsparungen", Seite 34). Doch steckt zum Glueck in den meisten Loesungen mehr als die Loesung selbst.

Weitere Ziele von Reverse Engineering sind:

- aus korrekten, aber qualitativ minderwertigen Programmen korrekte und qualitativ hochwertige Programme zu generieren, ferner

- die Software-Wiederverwendung.

Hier kommt dann auch und speziell objektorientiertes Re- Engineering zum tragen. Warum Objektorientierung?

Software, die mit ihrem Leistungsangebot Schritt halten muss mit den sich aendernden Wuenschen ihrer Benutzer, muss notwendigerweise weiterentwickelt, das heisst veraendert werden.

Anpassung und Erweiterbarkeit verlangen ebenso wie auch Wiederverwendbarkeit und Kompatibilitaet ein flexibles Design; und dafuer stellt der objektorientierte Ansatz die gegenwaertig wohl beste Loesung dar (siehe "Methoden objektorientierten Re- Engineerings bei Cobol 85", Seite 37). bi