Historisch gewachsen

Erfolgreiche Software lebt häufig viel länger als ursprünglich gedacht. Kontinuierliche Erweiterungen führen zu einem Zustand, den Praktiker gerne als „historisch gewachsen“ bezeichnen. Das äußert sich in inkonsistenter User Experience, leidender Qualität, steigenden Wartungskosten und mangelnder Innovationsfähigkeit.

Somit stellt sich fast jeder Softwarefirma irgendwann die Frage, wie die eigene Software erfolgreich renoviert werden kann und wie tiefgreifend der Eingriff werden muss oder darf, um auch in Zukunft die Geschäftsziele zu erreichen. Um die Weichen der Renovierung richtig zu stellen ist es notwendig, den tatsächlichen Zustand der Software genau zu analysieren, vor allem weil dieser erfahrungsgemäß deutlich von früheren Plänen und Dokumenten abweicht.

Innovation statt Wartung

Software ist DAS Mittel, mit dem heute Innovation geschaffen wird. Leider wird es über die Lebenszeit eines Softwaresystems immer schwieriger, innovativ zu bleiben und auf neue Anforderungen und Gegebenheiten zu reagieren. Software wird immer weiterentwickelt und neue Features werden hinzugefügt, auch wenn sie nicht in das ursprüngliche Konzept passen. So altert Software spürbar und bringt vielfältige Probleme mit sich.

Für die Nutzer ist die User Experience einerseits nicht mehr einheitlich und andererseits nicht mehr zeitgemäß. Für die Entwicklung wird die Software immer schwerer zu verstehen und Änderungen werden fehleranfälliger, wodurch mehr und mehr Zeit für Wartungsaktivitäten aufgebracht werden muss.

In der Konsequenz bleibt immer weniger Zeit für die Entwicklung von innovativen Features und gerade bahnbrechende Innovation ist nahezu unmöglich.

„SOFTWARE ALTERT DOCH!“

Hartnäckig hält sich das Gerücht, Software könne nicht altern. Das gilt höchstens für den Code als solchen. Spätestens die Weiterentwicklung von Technologien und Erwartungen im Umfeld eines Softwaresystems führen dazu, dass die Software gefühlt altert. Vor allem kontinuierliche Weiterentwicklung mit vielen Kompromissen führt im Lebenszyklus einer Software meist zu einer Situation, in der mehr und mehr Aufwand für Wartung statt für Innovation aufgewendet werden muss.

©iStock.com
©iStock.com

Neubau, Umbau oder nur neu streichen?

Die Renovierung eines Softwaresystems kann je nach Ausgangszustand und Zielsetzung sehr unterschiedlich ausfallen. Viele Firmen denken zunächst über ein Refactoring nach, was relativ kostengünstig und lokal durchzuführen ist. Leider sind auch die Verbesserungseffekte überschaubar, weil globale Herausforderungen so nicht gelöst werden können. Deshalb stellt sich dann häufig die Frage, ob ein System mit einer Neuausrichtung der Architektur umgebaut werden soll oder ob es sich sogar lohnt, ein komplett neues System zu entwickeln. Die komplette Neuentwicklung ist in der Praxis oft auch keine Option, weil dieEntwicklungsmannschaft nicht gleichzeitig das alte System warten und das neue entwickeln kann.

Renovierung ist keine Einmal-Aktion sondern sollte kontinuierlich fortgeführt werden.

Dr. Dirk Muthig, Head of Product and Systems Design, Lufthansa Systems

Softwarerenovierung ist oft unumgänglich und mit Risiken verbunden.

Viele Entscheidungen über das zukünftige Produkt und den Entwicklungspfad dorthin sind notwendig. Diese Entscheidungen reichen von Features und Interaktionskonzept über die zukünftige Architektur bis hin zur Art der Qualitätssicherung. Deshalb ist eine umfangreiche Analyse der Vorgeschichte und eine gute Planung der Renovierung notwendig.

„SOFTWARE IST NICHT SOFT!“

Eine der größten Errungenschaften von Software ist, dass man sie ändern kann ohne physikalische Änderungen vornehmen zu müssen. Das hat dazu beigetragen, dass alle Aspekte, bei denen Änderungen an einem System vorgenommen werden müssen, heute soweit wie möglich über Software abgebildet werden. Das gilt für Software in Unternehmen genauso wie für Software im Auto. Obwohl Software an sich leicht und in nahezu jede Richtung geändert werden kann, ist dies in der Praxis meist nicht möglich. Viele Änderungen erstrecken sich über weite Teile des Systems, haben große und unerwartete Seiteneffekte und machen es sehr schwer, einen Zustand hoher Qualität wieder herbeizuführen.

©iStock.com
©iStock.com

Bauen kann jeder. Renovieren können nur Spezialisten.

Viele Renovierungen von Softwaresystemen scheitern, obwohl sie notwendig wären. Während eine Neuentwicklung aus vielerlei Gründen oft schnell ausgeschlossen wird, erscheint eine Renovierung als ein gangbarer und steuerbarer Weg, um ein Softwaresystem wieder in die richtige Spur zu bringen. Das führt aber oft zu einer zu niedrigen Priorität und halbherzigem Vorgehen. Dann erscheint manchmal schon die Analyse als zu große Hürde.

Software-Renovierung muss als strategische Aufgabe angegangen werden

Software-Renovierung muss als strategische Aufgabe angegangen werden und erfordert den Einsatz von fachlichen und methodischen Spezialisten. Aufbauend auf der Analyse der Vorgeschichte des Softwaresystems wird der neue Zielzustand konstruiert. Während eine Neukonstruktion mit bedeutend weniger Einschränkungen arbeiten kann, muss eine Renovierung auf das existierende Softwaresystem Rücksicht nehmen. Somit gibt es eine ständige Abwägung zwischen den Umbaukosten und dem neu entstehenden Nutzen, die schwer zu quantifizieren ist.

Ganzheitliches Betrachten von Features und Qualitätsanforderungen

Ganzheitlich müssen Features und Qualitätsanforderungen aus den Blickwinkeln Benutzung, Betrieb und Entwicklung berücksichtigt werden. Renovierung muss die externe Gestaltung eines Softwaresystems im Sinne von Interaktions- und visuellem Design integriert mit der internen Gestaltung im Sinne der Softwarearchitektur betrachten. Die Entscheidungen über zukünftige Features, Oberflächen und Interaktionen betreffen viele Stakeholdergruppen und sollten nicht einseitig getroffen werden (z.B. nur durch den Vertrieb). Insbesondere sollten sie durch Fakten untermauert sein, wie z.B. durch die Messung der tatsächlichen Nutzung.

Die Herausforderung liegt nicht nur im Design eines Zielzustandes für das Softwaresystem, sondern auch im darauf abgestimmten Design eines Migrationspfades. Renovierung findet fast immer parallel zur Weiterentwicklung des Systems statt und deshalb müssen beide Aktivitäten koordiniert werden, sodass eine schrittweise Renovierung möglich wird. Renovierung beinhaltet auch viel Change Management. Nicht nur die Software ändert sich, es gibt auch Auswirkungen auf die Nutzer, die Entwickler, das Betriebspersonal und den Vertrieb. Änderungen, auch wenn sie Verbesserungen darstellen, werden oft als negativ wahrgenommen. Deshalb müssen diese Stakeholdergruppen rechtzeitig involviert werden und brauchen abhängig von der Softwareänderung auch neue Qualifikationen oder zumindest Trainings. Stetige und zielgerichtete Migration stellt sehr hohe Anforderungen an die Qualitätssicherung und insbesondere automatisierte Tests, um die Auswirkungen von Änderungen überprüfen zu können.

Unsere Expertise

Die Renovierung eines Softwaresystems ist immer komplex und individuell und es gibt dafür keinen Königsweg. Das Fraunhofer IESE baut daher auf Erfahrung von über 100 Renovierungsprojekten und stellt einen gut gefüllten Werkzeugkasten an Methoden und Tools zur Verfügung.

Das Fraunhofer IESE hat viele Softwarefirmen bei der Renovierung ihrer Softwaresysteme unterstützt und forscht an weiteren Verbesserungen von Methoden und Tools für die Softwarerenovierung.

„NACH DER RENOVIERUNG IST VOR DER RENOVIERUNG!“

Auch nach einer erfolgreichen Renovierung eines Softwaresystems dreht sich die Welt weiter, es kommen neue Anforderungen hinzu und neue Technologien stehen zur Verfügung. Deshalb sollte Renovierung nicht als einmalige Aktion, sondern vielmehr als kontinuierliche Aktivität aufgefasst werden, die je nach benötigtem Grad entsprechend ausgestaltet werden kann. Trotzdem sollte auch die Option einer kompletten Neuentwicklung nicht immer kategorisch ausgeschlossen werden, weil eine Renovierung eine Renovierung bleiben sollte und nicht den Umbau auf ein komplett anderes System verfolgen sollte.

1 Kommentare:


Kommentar schreiben

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.