Software-Reengineering: Wann wird das Alt-System zum Problem?
von DI (FH) Alexander Leutgeb
Unternehmenskritische Software ist nicht vor einem gewissen Alterungsprozess gefeit. Ein gleichwertiger Ersatz ist aber oft nicht so einfach verfügbar. Wann aber ist es an der Zeit um das Legacy-System mithilfe von Software-Reengineering abzulösen?
Inhalt
- If it ain’t broke, don’t fix it
- Fehlende oder überholte Dokumentation
- Ursprüngliche Entwickler haben das Unternehmen verlassen
- Die Wissensbasis für das System fehlt
- Selbst die Umsetzung von kleinen Änderungen ist sehr aufwendig
- Ständige Notwendigkeit Fehler zu beheben
- Code Smells
- Die Lösung: Software Reengineering
- Quellen
- Autor
If it ain’t broke, don’t fix it
Eine weit verbreitete Weisheit lautet: „Never change a running system“ Dieser Spruch, bei dem es sich vermutlich um eine abgewandelte Form der Aussage „Never change a winning team“ des britischen Fußballspielers und -trainers Sir Alf Ramsey handelt, ist allerdings im englischen Sprachraum kaum verbreitet. Dort wird stattdessen die Aussage „If it ain’t broke, don’t fix it” verwendet. Die Aussagen sind ähnlich, jedoch wirkt die zweite Formulierung nicht ganz so streng und dogmatisch. Man soll also nur versuchen etwas zu reparieren, wenn es tatsächlich defekt oder beschädigt ist.
Aus funktionaler Sicht würde das bedeuten, ein System ist nicht mehr in der Lage die Aufgabe zu erfüllen, für das es konzeptioniert wurde. Für Software kann man hier auch noch einen Schritt weiter gehen. Ein Softwaresystem ist „reparaturbedürftig“ wenn es in einen Zustand kommt, der die Wartung schwierig bis unmöglich macht. Wir haben für Sie sechs Anzeichen gesammelt, die darauf hindeuten, dass Handlungsbedarf für Ihr Softwaresystem besteht:
Fehlende oder überholte Dokumentation
Ist die Dokumentation eines Systems in vielen Teilen veraltet oder stimmt diese in weiten Teilen nicht mehr mit dem tatsächlichen System überein, ist das ein deutliches Zeichen eines Legacy Systems an dem bereits viele Änderungen durchgeführt wurden. Noch schlimmer ist das Fehlen einer umfangreichen Dokumentation. Solch ein Umstand erschwert die Wartung und Weiterentwicklung eines Systems und macht ein zügiges Einschulen neuer Mitarbeiter*innen fast gänzlich unmöglich.
Ursprüngliche Entwickler haben das Unternehmen verlassen
Üblicherweise ist sehr viel Wissen über ein komplexes System in den Köpfen weniger Mitarbeiter*innen gespeichert. Dies führt dazu, dass der Fortbestand der Software unmittelbar von den ursprünglichen Entwickler*innen abhängt, insbesondere wenn die Dokumentation nicht adäquat ist. Der kontinuierliche Abgang dieser Mitarbeiter*innen führt unweigerlich zu einer Situation, die eine Weiterentwicklung des Systems unmöglich macht.
Die Wissensbasis für das System fehlt
Ein deutliches Alarmsignal ist, wenn kaum mehr Verständnis für die grundlegende Funktionsweise der Software bei den Mitarbeiter*innen vorhanden ist. Im schlimmsten Fall kennt niemand im Unternehmen mehr die ursprünglichen Zusammenhänge und Konzepte. Damit wird es extrem schwierig im Fall eines auftretenden Problems nachhaltige Lösungen zu finden. Das Ergebnis sind oft schnelle “Hacks” um das Problem auf irgendeine Weise zu lösen, diese beschleunigen den Teufelskreis jedoch noch mehr.
Selbst die Umsetzung von kleinen Änderungen ist sehr aufwändig
Ein von Lehman und Belady formuliertes „Gesetz“ zur Evolution von Software [1] besagt, dass Systeme immer komplexer werden, bis aktiv daran gearbeitet wird, um die Komplexität zu reduzieren. Erfordert selbst die Umsetzung von kleinen Änderungen oder Erweiterungen großen Aufwand, ist dies ein eindeutiges Zeichen dafür, dass das System bereits zu komplex geworden ist. Wenn bereits kleine Änderungen einen großen Zeitaufwand erfordern, werden schwierigere Änderungen kaum umsetzbar.
Ständige Notwendigkeit Fehler zu beheben
Kein umfangreiches Softwareprojekt wird frei von Fehlern sein, wodurch regelmäßige „Bugfixes“ zur Notwendigkeit werden. Führt jedoch immer wieder das Beheben eines Fehlers zum Auftreten eines neuen Fehlers, ist dies ein Anzeichen dafür, dass die Architektur des Systems möglicherweise nicht mehr den aktuellen Anforderungen entspricht. Dies birgt die Gefahr, dass kleine Änderungen im Programm unvorhergesehene Auswirkungen zeigen.
Code Smells
Als „code smells“ (übelriechender Code) werden Teile des Sourcecodes bezeichnet, die zwar nicht fehlerhaft sind, aber schlecht strukturiert und implementiert sind. So hat etwa die Duplizierung von Sourcecode, also die Verwendung derselben Codezeilen an verschiedenen Stellen des Programms, einen sehr schlechten Einfluss auf die spätere Wartbarkeit des Systems.
Die Lösung: Software Reengineering
Werden die „Symptome“ rechtzeitig erkannt, so kann mittels geeigneter Methoden dem Verfall der Software entgegengewirkt werden, um die Qualität des Systems auf hohem Niveau zu halten und mögliche Ausfälle zu vermeiden. Durch Reengineering wird ein bestehendes System neu strukturiert aber vor allem auch für zukünftige Entwicklung und Erweiterung vorbereitet. Während es bei der Wartung darum geht Software, die sich in einer Produktivumgebung befindet an geänderte Umgebungsbedingungen anzupassen und erkannte Fehler auszubessern, werden durch Reengineering Systeme oder deren Teile von Grund auf neu konzeptioniert und umgesetzt.
Die RISC Software GmbH unterstützt Sie gerne bei der Erstanalyse sowie bei der Umsetzung eines Reengineerings Ihres Softwaresystems.
Quellen
[1] M. M. Lehman, “Programs, life cycles, and laws of software evolution,” in Proceedings of the IEEE, vol. 68, no. 9, pp. 1060-1076, Sept. 1980 vgl. https://ieeexplore.ieee.org/document/1456074
Kontakt
Autor
DI (FH) Alexander Leutgeb
Head of Unit Industrial Software Applications