Software-Reengineering

Software-Reengineering ist die Untersuchung und Veränderung eines bestehenden Systems, um es in einer neuen, verbesserten Form wiederherzustellen, typischerweise zur Modernisierung veralteter Legacy-Software unter Beibehaltung ihres wesentlichen Verhaltens.

Definition

Software-Reengineering ist der Prozess der Untersuchung eines bestehenden Systems, um es zu verstehen, und dessen anschließende Neuimplementierung oder Restrukturierung, um seine Form oder Plattform zu verbessern, während seine Funktionalität im Wesentlichen erhalten bleibt.

Scope

Dieses Thema umfasst Reverse Engineering und Design-Wiederherstellung; Restrukturierung von Code und Daten; Migration auf neue Plattformen, Sprachen und Architekturen; Kapselung (Wrapping) und inkrementelle Modernisierungsstrategien für Legacy-Systeme; Tests zur Verhaltenssicherung während der Transformation; und die Entscheidungskriterien für Reengineering im Vergleich zu fortgesetzter Wartung oder vollständigem Ersatz.

Core questions

• Wie wird das Design eines Legacy-Systems aus seinem Code und seinen Daten wiederhergestellt?
• Welche Strategien migrieren oder restrukturieren ein System mit akzeptablem Risiko?
• Wie wird das Verhalten bewahrt, während die Implementierung transformiert wird?
• Wann ist Reengineering einer fortgesetzten Wartung oder einem vollständigen Ersatz vorzuziehen?

Key theories

Reverse Engineering und Design-Wiederherstellung

Chikofsky und Cross definierten eine Taxonomie, die Reverse Engineering (Wiederherstellung höherer Repräsentationen aus einem System) von Re-Dokumentation, Restrukturierung und Forward Engineering abgrenzte und die Aktivitäten der Design-Wiederherstellung umrahmte.

Inkrementelle Legacy-Modernisierung

Anstatt riskanter Big-Bang-Neuentwicklungen werden Legacy-Systeme inkrementell modernisiert, indem Tests um bestehenden Code herum eingeführt, Änderungsstellen isoliert und Komponenten schrittweise restrukturiert oder ersetzt werden.

Clinical relevance

Reengineering ermöglicht es Organisationen, die Lebensdauer und den Wert geschäftskritischer Legacy-Systeme mit geringerem Risiko zu verlängern, als dies bei einer Neuentwicklung von Grund auf der Fall wäre; eine fundierte Strategie und verhaltenserhaltende Techniken sind unerlässlich, da Legacy-Systeme oft unersetzliches, undokumentiertes Geschäftswissen enthalten.

History

Als große Systeme, die in den 1960er bis 1980er Jahren entwickelt wurden, alterten, entwickelten sich Reverse Engineering und Reengineering Ende der 1980er und 1990er Jahre zu eigenständigen Anliegen, formalisiert durch die Taxonomie von Chikofsky und Cross; praktische Techniken zur Beherrschung ungetesteten Legacy-Codes wurden später von Feathers kodifiziert.

Debates

Inkrementelles Reengineering versus vollständige Neuentwicklung

Ob ein Legacy-System inkrementell modernisiert oder vollständig neu entwickelt werden sollte, ist umstritten; Neuentwicklungen versprechen einen Neuanfang, überschreiten aber häufig Budgets und verlieren eingebettetes Wissen, während inkrementelles Reengineering sicherer, aber langsamer ist.

Key figures

• Elliot Chikofsky
• James Cross
• Michael Feathers

Seminal works

• chikofsky1990
• feathers2004
• sommerville2015

Frequently asked questions

Was ist der Unterschied zwischen Refactoring und Reengineering?

Refactoring nimmt kleine, verhaltenserhaltende Verbesserungen am Quellcode vor, in der Regel als Teil der laufenden Entwicklung; Reengineering ist eine größere Aktivität, die Designs wiederherstellen und ein ganzes System auf eine neue Plattform oder Architektur migrieren kann, wobei Refactoring eine Technik davon sein kann.

Warum sollte man ein Legacy-System nicht einfach von Grund auf neu schreiben?

Legacy-Systeme verkörpern oft jahrelang angesammelte, schlecht dokumentierte Geschäftsregeln; eine Neuentwicklung von Grund auf birgt das Risiko, dieses Wissen zu verlieren, und überschreitet häufig Budgets, sodass inkrementelles Reengineering trotz seines langsameren Tempos häufig der risikoärmere Weg ist.