Definition „SRE“ Was ist Software Reengineering?

Autor / Redakteur: chrissikraus / Stephan Augsten

Software Reengineering, kurz SRE, ist die grundlegende Überarbeitung von Software bzw. ihrer Teilkomponenten. Ziel ist die Realisierung einer effizienteren oder sogar komplett neuen Software mit gleicher Funktionalität.

Firmen zum Thema

Software Reengineering beeinflusst große Teile einer Anwendung bis hin zum gesamten System, da vieles komplett neu aufgelegt wird.
Software Reengineering beeinflusst große Teile einer Anwendung bis hin zum gesamten System, da vieles komplett neu aufgelegt wird.
(© monsitj - stock.adobe.com)

Beim Software Reengineering wird eine bestehende Software (Legacy Software) analysiert, neu konzipiert und anschließend neu implementiert. Reengineering kann mit der gesamten Software oder mit ausgewählten Komponenten vorgenommen werden. Ziel ist es, die Qualität und Wartbarkeit durch die Neuschreibung zu verbessern.

Warum wird Reengineering nötig?

Legacy-Systeme wachsen im Laufe der Zeit mit ihren Anforderungen. Es muss kontinuierlich am System gearbeitet werden, um neue Funktionen aufzunehmen, Kompatibilität mit anderen Systemen herzustellen oder Probleme zu beheben. Dabei gibt es verschiedene Schwierigkeiten, die ein sauberes Arbeiten stören, z. B. dass sich Zusammenhänge erst später ergeben oder dass die schnelle Umsetzung einer zweckmäßigen Lösung Priorität hat.

Unter diesen Umständen wachsen Module auf unnötige Größen heran, Code mit der exakt gleichen Aufgabe existiert an mehreren Stellen unabhängig voneinander, die Performance der Software sinkt mit jedem Update oder die saubere Trennung der Schichten wird zunehmend aufgeweicht. Kurz: Im Laufe der Zeit sinkt die Softwarequalität und es entsteht Code, der zunehmend schwerer zu warten ist.

Reengineering vs. Refactoring

Um die Qualität von Software zu optimieren, gibt es verschiedene Ansätze. Refactoring und Reengineering sind zwei Wege, die verwandt klingen, sich aber in einigen Punkten unterscheiden.

1. Refactoring:

Die Absicht beim Refactoring ist es, im Code immer wieder nach schlecht gemachten Strukturen zu suchen und diese durch elegantere Lösungen zu ersetzen. Man versucht durch Refactoring einige Zeit nach der eigentlichen Implementierung von Änderungen das System so zu verbessern, dass das gleiche Verhalten auf einem simpleren Weg erreicht wird. Das hilft dabei, die Software langfristig gut wartbar zu halten; der Code bleibt nachvollziehbar und kann leichter erweitert oder verändert werden.

Die Änderungen haben einen eher kleinen Umfang und finden tendenziell in einem lokalen Kontext statt. Man kann z. B. eine einzelne Funktion oder Klasse durch Refactoring verbessern. Refactoring ist ein kontinuierlicher Prozess, der im Idealfall regelmäßig durchgeführt wird. Allerdings bedeutet Refactoring somit auch zusätzlichen Aufwand zur nachhaltigen Verbesserung der Software. Je nach Budget und Auslastung der Mitarbeiter ist das nicht überall praktikabel.

2. Reengineering:

Beim Reengineering kommen drastischere Maßnahmen zum Einsatz. Genauer gesagt wird Altes verworfen und neu aufgelegt. Reengineering beeinflusst große Teile der Software bis hin zum gesamten System. Es ist also durchaus möglich, dass es im Zuge von Software Reengineering zu einer kompletten Neuschreibung eins Systems mit identischem Funktionsumfang kommt. Das hat den Vorteil, dass die neue Lösung sauber und technisch auf dem gewünschten Niveau ist.

Bei einer kompletten Neuschreibung kommen z. B. oft modernere Technologien infrage, mit denen man komfortabler arbeiten kann. Allerdings ist der Aufwand hoch. Reengineering einer kompletten Software kann lange dauern. Das ist nicht nur ein Zeit- und Kostenfaktor, sondern bedeutet unter Umständen auch, dass die Legacy Software parallel zur Neuschreibung weiterhin von einem Teil des Teams betreut werden muss.

Reengineering von einzelnen Teilen einer Software ist oft ein Kompromiss aus Kosten und Nutzen. Ein altes System kann z. B. durch einen Wrapper für modernere Szenarien (z. B. Webanwendung) zugänglich gemacht werden. Ein weiteres gängiges Szenario ist, dass häufiger gebrauchte oder verwandte Funktionalitäten in ein eigenes Modul ausgelagert werden, um wiederverwendbare und leichter wartbare Komponenten zu schaffen.

Wie läuft Software Reengineering ab?

Software Reengineering hat viel mit Software Engineering gemeinsam. Die exakte Ausprägung der Projektphasen richtet sich in der Praxis nach den Vorgehensweisen, die im jeweiligen Softwarehaus eingesetzt werden. Beispielhaft könnte die Vorgehensweise wie folgt aussehen.

1. Analyse & Definition der Anforderungen

In beiden Fällen muss zuerst analysiert werden, was genau das fertige Stück Software können soll. Wie bei regulärer Softwareentwicklung zieht man also die Anforderungen an die Software als Grundlage für die Konzeption heran. Diese Anforderungen können z. B. aus der Dokumentation der Bestandssoftware, von Fachentwicklern, von Kunden oder aus dem Code der Legacy Software selbst stammen. Müssen die Anforderungen aus der alten Software abgeleitet werden, spricht man von Reverse Engineering.

Reverse Engineering ist auch dann wichtig, wenn nur Teile der Software neu gedacht werden sollen, weil die neuen Bestandteile nahtlos mit dem vorhandenen Code zusammenarbeiten müssen. Erweiterung oder Veränderung des Funktionsumfangs im Zuge des Software Reengineering ist denkbar, z. B. wenn bestimmte Funktionen nicht mehr nötig sind, sich zwischenzeitlich neue Anforderungen entwickelt haben oder bestimmte Dinge dank neuer Technologie plötzlich wirtschaftlicher in der Realisierung werden.

2. Design

Wenn alle Anforderungen klar sind, wird am Konzept gearbeitet. Das kann man sich ebenfalls wie bei der regulären Entwicklung vorstellen. Je nach Projekt umfasst das z. B. Architektur, Datenmodellierung usw.

3. Implementierung

Auf die Designphase folgt die Implementierung, also die technische Umsetzung des Konzepts.

4. Test

Dann kommt die Testphase, in der die korrekte Umsetzung der fachlichen Anforderungen gesichert wird.

5. Auslieferung

Entspricht das neue Stück Software den festgelegten Kriterien, kann die Auslieferung beginnen.

6. Wartung

Danach geht der Code wie üblich in die Wartungsphase über.

(ID:47569530)