Überall dort, wo Software eingesetzt wird, besteht die Gefahr, dass alte Systeme zu Altsystemen mutieren. Das bedeutet, dass sie nicht mehr mit vertretbarem Aufwand und ohne absehbares technisches Risiko weiterentwickelt oder gepflegt werden können. Wie kann man also verhindern, dass ein System oder Altsystem zu einem Altsystem wird? Lesen Sie den folgenden Artikel, um zu erfahren, wie man Altsysteme rechtzeitig erkennt, wie man sie beseitigt und letztlich vermeidet.
Inhalt
Ein essenzielles Qualitätskriterium für Software ist eine langfristige Wart- und Erweiterbarkeit. Durch einen Fokus auf dieses Kriterium kann sichergestellt werden, dass künftige Erweiterungen in Bezug auf Kosten, Umsetzungszeit, Wirtschaftlichkeit und Risiko akkurat eingeordnet werden können. Abbildung 1 zeigt anhand der grünen Linie eine optimale Kostenentwicklung in Bezug auf das Alter der Software. Ein initialer Anstieg der Kosten ist damit verbunden, dass Investitionen in die Qualität getätigt werden, welche mittelfristig die Kosten stabilisieren, sowie die Software am Leben erhalten.
Im Unterschied dazu zeigt die rote Linie eine mögliche Entwicklung für ein System, wo Qualitätskriterien vernachlässigt werden. Jeder rote Punkt zeigt eine Entscheidung in der Entwicklung, wo ein Kompromiss zwischen Qualität und Kosten oder eventuell Umsetzungszeit eingegangen wurde. Dadurch entsteht in der Software etwas, das unter dem Begriff „technische Schuld” bekannt ist. Diese technischen Schulden führen dazu, dass die Komplexität künftiger Wartungen und Weiterentwicklungen erhöht wird und somit auch die Änderungskosten, sowie das damit verbundene Risiko. Technische Schulden führen erfahrungsgemäß schnell dazu, dass Teile eines Systems oder das System als Ganzes nicht mehr wart- oder erweiterbar werden.
Die Entwicklung eines Systems hin zu einem Legacy-System ist allgemein gut messbar. Unter anderem können hier folgende Anzeichen beobachtet werden:
Abbildung 1: Änderungskosten
Technische Schuld wird im Rahmen einer Softwareentwicklung immer anfallen. Dies ist nicht vermeidbar. Jedoch können die Prozesse in der Softwareentwicklung derart priorisiert werden, dass technische Schulden abgebaut werden können. Hierfür ist ein gemeinsames Mindset im Projektteam notwendig. Eine konstante Überwachung der technischen Schulden und die Ermächtigung der Entwickler*innen, diese wieder entfernen zu können/dürfen, sind unumgänglich hierfür. Methoden, welche hier Anwendung finden, sind unter anderem Code Reviews, Coding Guidelines, Pair Programming, Refactoring und Test Driven Development. Abbildung 2 zeigt die konstante Korrektur der technischen Schulden durch kleine Anpassungen.
Abbildung 2: konstantes Qualitätsmanagement
Je nachdem, wie weit sich das Softwareprodukt auf der Reise in Richtung „End of Life” befindet, können kleinere Anpassungen ggf. nichts mehr bewirken und größere Refactorings oder Reengineerings notwendig werden. In diesem Fall ist es hilfreich, sich Reengineering-Spezialist*innen ins Projektteam zu holen, die nach und nach ein konsistentes Reengineering der bestehenden Alt-Systeme durchführen. Abbildung 3 zeigt das späte Erkennen technischer Schulden. Hier muss mit deutlich mehr Aufwand und Zeit gegengesteuert werden, um das System wieder auf den richtigen Pfad zu bringen.
Abbildung 3: Reengineering, größeres Refactoring
Neben der Beobachtung technischer Schulden stellt sich die Frage, wie technische Schulden vermieden werden können. Dafür muss analysiert werden, wie technische Schulden zustande kommen. Wo liegen die Ursachen hierfür und was kann getan werden, um diese Ursachen zu entschärfen?
Wie im vorigen Abschnitt festgehalten, sind die Entwickler*innen diejenigen, welche für die technische Qualität eines Softwareproduktes zuständig sind. Technische Schuld wird daher nicht vorsätzlich in ein System integriert, sondern durch externe Faktoren gefördert. Betrachtet man den zeitlichen Verlauf einer Softwareentwicklung, so kann folgender Zusammenhang festgestellt werden: Die blaue Linie zeigt die lineare Projektabwicklung, d.h. die Erfüllung des geplanten Projektumfanges bis zum Lieferzeitpunkt bei V1.0. Die Ideallinie in der Realität sollte der grünen Linie entsprechen. Es gibt kontinuierliche Anpassungen in der Umsetzung, wodurch die Produktentwicklung „auf Kurs” gehalten und so sichergestellt wird, dass ein wertvolles, lauffähiges Produkt zum geplanten Termin zur Verfügung steht.
Abbildung 5 zeigt ein Bild, welches in der Realität jedoch meist vorzufinden ist. Eine Abweichung vom Plan wird bemerkt. Wie es dazu kam, kann unterschiedliche Gründe haben. Eventuell war eine initiale Schätzung nicht akkurat, das Team hat an Effizienz verloren, es gibt äußere Einflüsse wie z.B. Krankenstände, die Komplexität der Software hat sich geändert, der Projektumfang hat sich geändert, etc. Die Gründe hierfür können vielfältig sein. An dieser Stelle wird jedoch interessant, welche Optionen ein Projektteam hat. Folgende primären Entscheidungen können unter Berücksichtigung der Gegebenheiten getroffen werden.
Abbildung 4: Entwicklungsverlauf
Abbildung 5: Realität
Die Verschiebung des Fertigstellungsdatums erfolgt nur, sofern die Produktverantwortlichen die Möglichkeit dazu haben. Hinter einer Verschiebung des Fertigstellungstermins stehen üblicherweise andere Personen oder Systeme, welche davon abhängig sind und mehr oder weniger auf den ursprünglich geplanten Termin bestehen. Dazu kommt noch der Nachteil, dass nicht nur eine Produktivsetzung und somit der (eventuell wirtschaftliche) Nutzen zeitlich verschoben wird, sondern auch noch das Projektteam für einen längeren Zeitraum finanziert werden muss. Dies führt zu zusätzlichen Kosten und späteren Einnahmen. Eine direkte, negative Auswirkung auf den ROI ist die Folge.
Abbildung 6: Releasedatum verschieben
Die wenigsten Widerstände dürfte man sich erwarten, wenn man es schafft, die Arbeitsgeschwindigkeit der Entwickler*innen dahingehend zu optimieren, dass der Fertigstellungszeitpunkt und die Entwicklungskosten eingehalten werden. Tatsächlich ist das eine Option, wobei man hier zwei unterschiedliche Szenarien unterscheiden muss.
Option 2a: Es gibt Einflussfaktoren, welche das Team in der Effizienz stört, welche auch tatsächlich behoben werden können. Diese Maßnahmen funktionieren und sind auch jene, welche bei einer kontinuierlichen Prozesskontrolle und -verbesserung stattfinden. Das Szenario in Abbildung 4 setzt eben diese voraus. Voraussetzung für diese Maßnahmen sind folglich aber auch, dass die Abweichungen nicht zu spät erkannt werden und auch nicht zu groß sind. In Abbildung 7 könnte es eventuell schon zu spät für eine solche Maßnahme sein.
Option 2b: Es gibt zwar störende Einflussfaktoren, diese werden jedoch nicht behandelt oder es ist zu spät für entsprechende Maßnahmen. In diesem Fall wird eine Erhöhung der Entwicklungsgeschwindigkeit lediglich durch den Aufbau von Druck auf die Entwickler*innen erreicht. Druck führt üblicherweise dazu, dass in den Methoden eingespart wird, welche keinen offensichtlich direkten Einfluss auf den Produktumfang einer Software haben. Dies sind jene, welche zur Erhaltung der Qualität notwendig sind und somit kommt es sukzessive zu einem Aufbau von technischer Schuld. Da es auch an Zeit und Kapital für den Abbau der technischen Schulden fehlt, schreitet dieser Aufbau gegebenfalls mit entsprechender Geschwindigkeit voran.
Abbildung 7: Erhöhung der Entwicklungsgeschwindigkeit
Als dritte Option besteht die Möglichkeit, die Inhalte des Softwareproduktes anzupassen. Eine entsprechende Befugnis der Produktverantwortlichen ist hierfür jedoch Voraussetzung, bzw. werden hierfür gegebenenfalls entsprechend intensive Verhandlungen zwischen dem bzw. der Produktverantwortlichen und den Stakeholdern benötigt. Anpassungen dieser Art werden durch diverse Maßnahmen erleichtert:
Tatsächlich ist eine solche Anpassung im Projektumfang zu jeder Zeit in der Umsetzung möglich. Rechtzeitig erkannt, sind die Änderungen marginal, spät erkannt, sind die Änderungen entsprechend umfangreicher. Hier gilt: Sofern das Produkt bereits die wertvollsten Funktionen beinhaltet, sollte eine Produktivsetzung mit vermindertem Funktionsumfang kein Hindernis sein. Durch entsprechend gut geschulte und erfahrene Produktverantwortliche kann dieses Risiko deutlich minimiert oder gar vermieden werden.
Abbildung 8: Anpassung des Projektumfangs
Wie so oft kann hier keine pauschale Aussage getroffen werden. Eventuell macht eine der Optionen für sich alleine Sinn oder eine entsprechende Kombination der Optionen 1, 2a und 3 führt zu einer entsprechenden Korrektur des Kurses. Lediglich Option 2b sollte vermieden werden, da genau diese letztendlich ein System in Richtung „End of Life” entwickelt.
Maßnahmen, welche letztendlich ein Legacy-System verhindern sind
Abschließend soll noch ein wichtiger Einflussfaktor genannt werden, welcher die Optionen 1 – 3 entsprechend einschränken kann: Der Vertrag. Es ist verständlich, dass Auftraggeber*innen vertragliche Sicherheit in Hinblick dahingehend haben wollen, welcher Umfang in welchem Zeitraum zu welchen Kosten geliefert wird. Aus diesem Grund werden oftmals Verträge mit den Auftragnehmer*innen geschlossen, wo alle drei Faktoren fixiert werden. Somit hat der bzw. die Produktverantwortliche aber keinerlei Handlungsspielraum:
Somit bleibt, vertraglich betrachtet, meist nur noch Option 2b, nämlich die Erhöhung des Drucks auf die Entwickler*innen und die damit verbundene Minimierung der Qualität des Produktes.
Empfohlen wird hier vielmehr die Fixierung von Releasedatum und Kosten (z.B. durch Stabilisierung des Teams) und die Schaffung von Flexibilität in den Anforderungen an ein Produkt. Durch die Führung eines bzw. einer Produktverantwortlichen können Auftraggeber*innen den benötigten Funktionsumfang eines Softwareprodukts bis zum Releasedatum steuern und erhalten dadurch eine transparente Kostenkontrolle. Zusätzlich kann das Produkt während der Umsetzung an die Marktbedürfnisse angepasst und so zielgruppenorientiert positioniert werden.
Head of Unit Domain-specific Applications, Head of Coaches
