Evolution, Änderung und Wartung von IT-Systemen

Software systematisch verbessern – aber richtig!

Gernot Starke
©Shutterstock/alphaspirit

Die Informatikausbildung fokussiert auf die Neuentwicklung von Software – den Alltag vieler Softwerker prägen jedoch meist Pflege, Änderung oder Erweiterung von Systemen. In diesem Artikel stelle ich Ihnen aim42 vor, ein systematisches Vorgehen zur Verbesserung von Software. aim42 ist frei verfügbar und kondensiert Praktiken und Patterns rund um Evolution, Änderung und Wartung von IT-Systemen.

In Entwicklung und Betrieb von Software wünschen wir uns über die Lebensdauer unserer Systeme möglichst niedrige Änderungs- und Betriebskosten, bei gleichzeitig hoher Verständlichkeit (Abb. 1).

Abb. 1: Wunschsituation kommerzieller Software

Bei mittleren bis großen Systemen tritt diese ideale Situation in der Realität nur selten ein. Zeitdruck, Konstruktions- und Managementfehler sowie kurzfristig orientierte Entwurfsentscheidungen sorgen dafür, dass ziemlich genau das Gegenteil geschieht: Obwohl anfänglich alles sauber entwickelt und entworfen war, degenerieren Systeme über die Zeit – das Phänomen der „verfaulenden Software“ schlägt zu. Änderungen werden schwieriger, riskanter und dauern immer länger. In Entwicklung und Betrieb treten vermehrt Probleme auf, deren Behebung mehr und mehr Zeit und Ressourcen in Anspruch nimmt. Damit einher steigen Änderungs- und Betriebskosten. Die Istsituation kommerzieller Software zeigt sich in Abb. 2.

Abb. 2: Istsituation kommerzieller Software

Ganz unterschiedliche Gründe verursachen diese missliche Situation – einige verbreitete Beispiele:

  1. Mangelnde konzeptionelle Integrität: identische Probleme werden innerhalb eines Systems unterschiedlich gelöst, es gibt mehrere unterschiedliche, teils widersprüchliche Lösungsansätze.
  2. Übermäßige strukturelle Komplexität, umständliche Konzepte oder Abläufe innerhalb des Systems.
  3. Schlechter Quellcode, der beispielsweise Grundlagen des Clean-Code [1] verletzt, unter zu hoher Kopplung oder niedriger Kohäsion leidet, gegen Coding-Konventionen verstößt, Redundanzen enthält oder schlicht unverständlich ist.
  4. Zum fachlichen Problem unpassende Wahl von Technologien, Frameworks oder sonstiger Infrastruktur („mit Kanonen auf Spatzen schießen“).

Diese Liste könnte ich nahezu beliebig weiterführen – und jeder neue Eintrag würde mich dabei an eine reale Situation meines bisherigen Berufslebens erinnern.

Aufmacherbild: Businessman working with laptop on new projects von Shutterstock / Urheberrecht: alphaspirit

[ header = Seite 2: Wege in den Abgrund ]

Wege in den Abgrund

Zu Beginn vieler Entwicklungsprojekte sieht Software doch recht ordentlich aus: Motivierte Teams erarbeiten stimmige Konzepte und setzen diese dann handwerklich sauber um. Konzepte und Technologien passen zum Problem, ebenso die Daten und Datenstrukturen.

Im Laufe der Zeit jedoch beginnt das Drama: Die ursprüngliche Ordnung weicht einem ständig steigenden Chaos. Ausnahmen werden zur Regel, Code wird immer schwerer verständlich, das Entwicklungsteam beginnt von „historisch gewachsen“ zu sprechen – weil kaum jemand nachvollziehen kann, wie es zu dieser kontinuierlichen Verschlechterung kommen konnte.

Durch welche Gründe kommt es dazu? Verlernen Teams über die Zeit das vernünftige und saubere Arbeiten? Nein – vielmehr zwingen oftmals äußere Einflüsse zu Kompromissen, die dann langfristig zu den oben genannten Problemen führen [2]. Neudeutsch nennen Manager dieses Phänomen „technische Schulden“ – Softwareentwickler bezeichnen diese als Quick and Dirty, Hotfix oder Workaround – und wissen, dass sich dahinter meistens ein weiterer Schritt in Richtung „degenerierter Systeme“ (rotten-software) verbirgt.

Innere Werte werden vernachlässigt

Ursächlich resultieren diese Probleme aus einem mangelnden Bewusstsein für die innere Qualität von Software. Auftraggeber interessieren sich primär für neue Features, Erweiterungen oder schnellstmögliche Fehlerbehebung, weniger für den Erhalt konzeptioneller Integrität, verständlichen Quellcode oder stimmige Anwendung von Konzepten oder Technologien. Aber gerade diese innere Qualität von Systemen stellt sicher, Ziele wie niedrige Änderungskosten, schnelle Fehlerbehebung, hohe Anpassbarkeit zu erreichen. Leider ignorieren immer noch zu viele IT-Manager diesen kausalen Zusammenhang.

Systematisch verbessern

Der Weg zu besserer Software führt in der kommerziellen Realität immer über mehrere, meist kleine Schritte zum Ziel. Praktisch niemals können wir den Lauf der Welt für einige Monate anhalten, um in dieser Zeit die Qualität unserer Software zu verbessern. Vielmehr müssen wir Verbesserungen in die regulären Wartungsarbeiten (etwa: Erweiterungen, Fehlerkorrekturen) integrieren.

Ich möchte Ihnen aim42 vorstellen – eine frei verfügbare Methode zur systematischen Verbesserung von Software. Basierend auf der langjährigen praktischen Erfahrung einiger Initiatoren wird sie mittlerweile als Open-Source-Projekt durch ein engagiertes Team kollaborativ weiterentwickelt [3].

Die zentralen Konzepte von aim42 kommen Ihnen garantiert bekannt vor: Probleme, (Lösungs-)Maßnahmen, Kosten und Risiken. aim42 packt diese Aspekte in einen methodischen Rahmen und stellt sicher, dass wirklich relevante Probleme auch durch Maßnahmen abgedeckt werden – und nicht vorschnell an Themen optimiert wird, die nur geringen geschäftlichen Nutzen erbringen.

Grundkonzepte aim42
1. Sammeln Sie in der Analyse alle Probleme, die Sie rund um das System und dessen Organisation finden können (Abb. 3).
2. Jedes Problem bewerten Sie hinsichtlich seiner einmaligen und/oder wiederholten Kosten. Hierbei werden Sie oft auf Schätzungen sowie Annahmen angewiesen sein – halten Sie diese Bewertungen fest. Auf Basis der Kosten können Sie hervorragend Prioritäten festlegen.
3. Manche Probleme sind nur Symptome von tieferliegenden Ursachen – die „Root Cause Analysis“ hilft, denen systematisch auf die Spur zu kommen.
4. Suchen Sie mit technisch kundigen Beteiligten nach Maßnahmen, die diese konkreten Probleme oder deren Ursachen lösen oder beheben. Zwischen Maßnahmen und Problemen respektive Ursachen besteht eine m:n-Beziehung – eine einzige Maßnahme kann mehrere Probleme adressieren, ein Problem kann zur Lösung mehrere Maßnahmen benötigen.
5. Auch Maßnahmen haben Kosten, die Sie systematisch ermitteln oder schätzen müssen.
6. Maßnahmen können Nebenwirkungen besitzen – oder negative Seiteneffekte. Legen Sie diese offen.
7. Die Gegenüberstellung von Kosten-von-Maßnahmen sowie den Kosten-des-Problems ergibt eine wertvolle Entscheidungshilfe für Budget- oder fachlich Verantwortliche. Damit müssen Softwarearchitekten endlich nicht mehr über die schwer vermittelbaren inneren Qualitäten, Kopplung, Kohäsion oder Implementierungsdetails argumentieren, sondern können in Businesssprache argumentieren.
8. aim42 arbeitet hochgradig iterativ: Bewertungen von Problemen und Maßnahmen können sich über die Zeit ändern, wie sich in modernen Entwicklungsprozessen auch die Prioritäten von beispielsweise Anforderungen oder Zielen über die Zeit ändern können. Regelmäßige (iterative) Überprüfung der problem list und des improvement backlog stellen deren Aktualität sicher.

Abb. 3: Basiskonzepte systematischer Verbesserung (nach aim42)

[ header = Seite 3: Probleme verursachen Kosten ]

Probleme verursachen Kosten

Um Verbesserungen effektiv an realen Bedürfnissen auszurichten, sollten Sie für alle erkannten Probleme innerhalb von Softwaresystemen oder beteiligten Prozessen explizit deren „Kosten“ ermitteln: Welche Kosten entstehen beispielsweise durch direkt zurechenbaren Mehraufwand bei Entwicklung oder Betrieb, wie viel Geld kostet zusätzlich benötigte Hardware, welcher Umsatzausfall oder Opportunitätskosten fallen durch enttäuschte Kunden oder entgangene Verkäufe an? Zu den Kosten ermitteln Sie, in welcher Frequenz sie anfallen – etwa bei jeder Änderung, bei jedem Release des Systems oder bei jedem Aufruf einer bestimmten Systemfunktion.

aim42 nennt das problem list, eine Liste oder Tabelle sämtlicher bisher erkannten Probleme samt ihrer geschätzten Kosten. Erst wenn Sie die Kosten von Problemen kennen, können Sie mit anderen Stakeholdern zielgerichtet über Prioritäten und mögliche Abhilfen diskutieren. aim42 unterstützt Sie durch pragmatische und einfache Ansätze in dieser Bewertung.

Kontinuität und Iteration

Aus der Vogelperspektive teilt aim42 die systematische Verbesserung in drei Phasen ein (Abb. 4):

  1. Analyze: Aufdecken und sammeln von Problemen. Gleichzeitig sollten Sie in der Analyse auch Verständnis für die Organisation, Struktur und Lösungskonzepte des Systems gewinnen, weil das für die Erkennung von Problemen und Risiken fundamental ist.
  2. Evaluate: Schätzen oder ermitteln des (Geld-)Werts von Problemen und Maßnahmen. Das ermöglicht zielgerichtete Priorisierung und Planung. Diese Bewertung reichert Probleme und Maßnahmen um relevante Steuerinformationen und KPIs für das IT- und technische Management an.
  3. Improve: Durchführen von Verbesserungsmaßnahmen. Hier fasst aim42 bewährte Patterns und Praktiken von Evolution, Refactoring, Migration oder stufenweisem Umbau zusammen.

Abb. 4: Drei Phasen der Verbesserung

Kontinuität und Iteration

Verbesserung ist ein kontinuierlicher Prozess (Abb. 5). aim42 funktioniert für beliebige Entwicklungs- oder Wartungsprozesse und teilt relevante Aktivitäten (Praktiken, Vorgehensmuster) in Phasen ein. Diese Aktivitäten können Sie in Ihrem normalen Entwicklungsvorgehen nahtlos integrieren.Abb. 5: Kontinuierliche Verbesserung – iterativer Prozess

Eine gedankliche Schleife wiederholt sich in aim42 immer wieder: (1) Sie finden ein Problem oder dessen Ursachen, (2) bewerten dieses Problem hinsichtlich seiner Kosten und (3) identifizieren Lösungsmaßnahmen dafür. (4) Sie wenden die Lösungsmaßnahme an und (5) analysieren ob das ursprüngliche Problem damit behoben ist. Diese Schleife läuft in ähnlicher Form in jeglicher Art von Konstruktions- oder Optimierungsprozessen ab. Nach meiner Erfahrung kranken viele Systeme in der Praxis daran, dass die technisch Verantwortlichen vor der Bewertung der Kosten von Problem und Maßnahmen zurückschrecken. Stattdessen argumentieren sie über „Prinzipien der Softwaretechnik“ oder „technische Konzepte“ – und scheitern damit bei Management oder Auftraggebern.

[ header = Seite 4: Praktiken und (Vorgehens-)Muster  ]

Praktiken und (Vorgehens-)Muster

aim42 katalogisiert zurzeit fast achtzig erprobte Praktiken und (Vorgehens-)Muster. Einige Beispiele finden Sie im Textkasten „Auszug Praktiken und Patterns“. Allerdings garantiert der Einsatz dieser Praktiken und Mustern keinen Erfolg: Wie andere mächtige Werkzeuge auch gehört zur Anwendung dieser Praktiken Fingerspitzengefühl und etwas Erfahrung. Zwar finden Sie in der Methodenreferenz zu aim42 [4] eine Menge Hinweise über wenn, wann und wie, aber eine leistungsfähige Methode ist eben kein Algorithmus.

Auszug Praktiken und Patterns
An einigen Beispielen möchte ich Granularität und Scope von aim42 aufzeigen. Für eine ganzheitliche Übersicht über alle aktuellen aim42-Praktiken und Patterns verweise ich Sie auf das Onlinemethodenhandbuch [4].
Anticorruption-Layer: Isoliere Clients von internen Änderungen an Subsystemen.
ATAM: Architecture Tradeoff Analysis, findet Risiken in Architektur.
Assertions: Über Zusicherungen im Code fehlerhafte Annahmen aufdecken.
Branch for Improvement: Über unterschiedliche Branches in der Versionsverwaltung verschiedene Stände der Veränderung abbilden.
Capture Quality Requirements: Qualitätsziele verschiedener Beteiligter offenlegen.
Context-Analysis: Systemkontext und externe Schnittstellen klären und dokumentieren.
Data-Analysis: In Daten und Datenstrukturen nach Problemen oder Komplexität suchen.
Estimate Problem Cost: Kosten von Problemen ermitteln.
Extract Reusable Component: Aus bestehendem System wiederverwendbare Teile extrahieren.
Frontend-Switch: In der Benutzeroberfläche Anfragen entweder an alte oder veränderte Teile des Systems routen.
Hierarchical Quality Model: Qualitätsziele konkretisieren durch Qualitätsbaum mit Szenarien.
Improvement Backlog: Pflege eine Übersicht möglicher Verbesserungsmaßnahmen, inklusive ihrer Kosten und Risiken.
Introduce Boy Scout Rule: Hinterlasse Code nach Änderungen immer sauberer als vorher.
Issue-Tracker-Analysis: Bug oder Issue Tracker bezüglich Cluster und Häufungen untersuchen.
Keep Data, Toss Code: Systeme durch massive Änderungen im Code, aber unter Beibehaltung der relevanten Daten verbessern.
Pre-Interview Questionnaire: Interviews durch Stakeholder- und situationsspezifische Fragebögen vorbereiten.
Profiling: Vermesse Speicher- und anderen Ressourcenverbrauch zur Laufzeit.
Qualitative-Analysis: Risikobewertung der systemrelevanten Qualitätsanforderungen auf Basis der getroffenen Architekturentscheidungen.
Refactoring-Plan: Teamweite Koordination und Abstimmung von Refactoring-Maßnahmen – zur groß angelegten Codeverbesserung.
Root-Cause-Analysis: Finde die Ursache von Problemen – differenziere Ursache und Symptom.
Software Archeology: Verstehe Software durch Analyse von Quellcode und seiner Versionshistorie.
Stakeholder-Interview: Finde Probleme durch Befragung relevanter Beteiligter.
Static-Code-Analysis: Analysiere Quellcode, um zusammengehörige Bausteine, Abhängigkeiten, Kohäsion und andere strukturelle Eigenschaften zu finden.

Analyse: Verständnis gewinnen und Probleme identifizieren

Gewinnen Sie einen Überblick über Zweck, Aufgaben und insbesondere Qualitätsanforderungen an das System. Klären Sie interne Strukturen, Konzepte und wesentliche Architekturansätze. Dabei suchen Sie nach Problemen, Symptomen, Risiken oder technischen Schulden innerhalb des Systems, seiner Betriebs- oder Ablaufumgebung und allen zugehörigen Prozessen. Notieren Sie Lösungsideen (Maßnahmenvorschläge, „remedies“).

Evaluate: Abbildung auf betriebswirtschaftliche Größen

Stellen Sie die Vergleichbarkeit von Problemen und Lösungsmaßnahmen sicher, indem Sie deren betriebswirtschaftliche Werte (etwa in Euro oder Aufwandsgrößen) schätzen oder ermitteln. Damit können Sie Probleme und mögliche Maßnahmen priorisieren.

[ header = Seite 5: Improve: Mehr als nur Refactoring  ]

Improve: Mehr als nur Refactoring

Planen und koordinieren Sie die auf konkrete Probleme bezogenen Verbesserungsmaßnahmen. Ändern Sie, je nach Situation, Quellcode, Konzepte oder beteiligte Entwicklungs- oder Betriebsprozesse. Reduzieren Sie technische Schulden. Optimieren Sie Qualitätseigenschaften, beispielsweise Wartbarkeit, Verständlichkeit, Sicherheit oder Performance. Sämtliche Verbesserungen beziehen sich dabei auf Probleme oder deren Ursachen, die Sie in der Analysephase erkannt und anschließend bewertet haben – so stellen Sie sicher, keine Veränderung um ihrer selbst willen durchzuführen.

Improvement Backlog

Eine wesentliche Frage innerhalb der kontinuierlichen Verbesserung habe ich bisher offen gelassen: Woher kommen die konkreten Verbesserungsvorschläge und -maßnahmen? In der Bewertungsphase wollen wir diese Maßnahmen bezüglich ihrer Aufwände und Risiken bewerten, und in der Verbesserungsphase wollen wir sie umsetzen – aber wann definieren wir sie überhaupt?

Die Antwort lautet „kontinuierlich“: Ideen, Maßnahmen, Taktiken oder Strategien zur Verbesserung finden Sie in jeder der aim42-Phasen. Ich empfehle Ihnen, im Rahmen der systematischen Verbesserung von Software dazu einen Improvement Backlog zu führen, d. h. sämtliche Ideen für Verbesserungen im Rahmen einer Aufgabenliste zu dokumentieren.

Auch hierfür gilt wieder das Prinzip der systematischen Sparsamkeit: Halten Sie diese Dokumentation kurz und knapp. Aktualität ist wichtiger als Vollständigkeit, Transparenz wichtiger als Ausführlichkeit (Abb. 6).

Abb. 6: Maßnahmen in allen Phasen sammeln

Community: Mitmachen erwünscht

aim42 ist ein junges Open-Source-Projekt, das noch tatkräftige Unterstützung benötigt. Die bisherigen Committer bringen ihre langjährige und reichhaltige Erfahrung ein – und die gesamte Community freut sich über weitere Anregungen und Input.

Für Interessierte: Das Handbuch zur Methodik (der so genannte Method-Guide) wird im AsciiDoc-Format [5] geschrieben und automatisch im aim-Guide publiziert. Der gesamte Text liegt unter einer liberalen Creative-Commons-Lizenz auf einem öffentlichen GitHub Repository [6].

Werfen Sie einen Blick auf unsere offenen Punkte [7], ergänzen Sie Kommentare oder machen Sie Verbesserungsvorschläge.

Fazit

aim42 fasst bekannte und bewährte Praktiken und Vorgehensmuster für die Evolution und systematische Verbesserung von Software in einem methodischen Rahmen zusammen. In vielen Real-Life-Situationen haben diese Praktiken ihre Praxistauglichkeit unter Beweis gestellt – aim42 integriert sie in einem gemeinsamen Kontext.

Danksagung: Danke an die fleißigen Reviewer dieses Artikels, Per Starke, Oliver Tigges, Burkhard Neppert, Tammo van Lessen und das aim42-Team.

Geschrieben von
Gernot Starke
Gernot Starke
    Informatikstudium an der RWTH Aachen, Dissertation über Software-Engineering an der J. Kepler Universität Linz. Langjährige Tätigkeit bei mehreren Software- und Beratungsunternehmen als Softwareentwickler, -architekt und technischer Projektleiter. 1996 Mitgründer und technischer Direktor des „Object Reality Center“, einer Kooperation mit Sun Microsystems. Dort Entwickler und technischer Leiter des ersten offizielle Java-Projekts von Sun in Deutschland. Seit 2011 Fellow der innoQ GmbH.  
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.