Kolumne

Die Systematischverbesserin [Knigge für Softwarearchitekten]

Gernot Starke, Peter Hruschka

© Shutterstock/Peshkova

Oftmals ist die Forderung nach Verbesserung von Software eine Folge aus zu hohen Kosten von Änderungen oder Erweiterungen – denn unsere (fachlich oder betriebswirtschaftlich motivierten) Auftraggeber interessiert die innere Qualität von Systemen oftmals nur wenig. Veränderung von Software zum Besseren hin ist daher meist ein langwieriger Prozess, den Sie systematisch und schrittweise angehen müssen.

Hier kommt die Systematischverbesserin ins Spiel: Ihr gelingt es, systematisch die (wirtschaftlichen) Ziele von Auftraggebern mit der Verbesserung der (inneren) Qualität zu verbinden – und dabei noch alle Beteiligten bei Laune zu halten. Falls Sie das für schwierig halten – willkommen in der Realität.

Die Realität: degenerierte Systeme

Obwohl wir anfänglich alles sauber entwickelt und entworfen haben, degeneriert unser System mit der 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 Zufriedenheit von Entwicklern, Betreibern und (fachlichen) Auftraggebern sinkt.

Grund: Schuldenfalle

Die ursprüngliche Ordnung im System 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. Warum 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. 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. Rufen wir die Systematischverbesserin zu Hilfe.

Systematisch verbessern in kleinen Schritten

Der Weg zu besserer Software führt in der Realität fast immer über viele kleine Schritte zum Ziel. Meist müssen wir Verbesserungen in die regulären Wartungsarbeiten (etwa: Erweiterungen, Fehlerkorrekturen) integrieren. Die Systematischverbesserin verwendet dazu einen iterativen Ansatz und stellt sicher, dass wirklich relevante Probleme adressiert werden – und nicht vorschnell an Themen optimiert wird, die nur geringen geschäftlichen Nutzen erbringen.
Analysieren, Bewerten, Lösen
Unsere charmante Verbesserin schlägt uns folgende einfachen Schritte vor:

1. Sammeln Sie zuerst die Probleme, die Sie rund um das System und dessen Organisation finden (aim42 nennt das problem list).
2. Jedes Problem bewerten Sie hinsichtlich seiner einmaligen und/oder wiederholten Kosten. Nutzen Sie Schätzungen oder treffen Sie Annahmen – und halten Sie diese Bewertungen fest.
3. Suchen Sie 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.
4. Auch Maßnahmen haben Kosten – die Sie systematisch ermitteln oder schätzen müssen. (aim42 nennt das improvement backlog).
5. 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.

Verbessern funktioniert 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. 1: Probleme und Maßnahmen

Praktiken, leider ohne Gewähr

Die Systematischverbesserin verwendet am liebsten bewährte Praktiken und Patterns zur Verbesserung von Systemen, statt das Rad neu zu erfinden. Sie bedient sich gerne einem frei verfügbaren Katalog (etwa aim42). Allerdings garantiert der Einsatz dieser Praktiken leider noch keinen Erfolg: Wie andere mächtige Werkzeuge auch gehört zur Anwendung dieser Praktiken Fingerspitzengefühl und etwas Erfahrung – die eine Systematischverbesserin besitzen sollte. Falls wesentliche Stakeholder die langfristige Verbesserung boykottieren oder ausschließlich kurzfristige Ziele verfolgen, bleiben Sie trotz Methodik und bewährten Praktiken chancenlos.

Fazit

Behalten Sie bezüglich der Verbesserung Ihrer Systeme Geduld und langen Atem! Wir haben erlebt, dass die Praktiken von aim42 in der Realität gut funktionieren können – daher möchten wir Ihnen Mut machen. Aber: „You need to talk economics“: Argumentieren Sie in der Sprache Ihrer Business-Stakeholder – das steigert Ihre Erfolgsaussichten beträchtlich.

Auszug Praktiken und Patterns
An einigen Beispielen möchten wir 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:

Anti-Corruption 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.

Aufmacherbild: businessman presses skyscraper, high resolution von Shutterstock / Urheberrecht: Peshkova

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.  
Peter Hruschka
Peter Hruschka
Informatikstudium an der TU Wien, Promotion über Echtzeit-Programmiersprachen. 18 Jahre im Rahmen eines großen deutschen Softwarehauses verantwortlich für Software-Engineering. Initiator, Programmierer und weltweiter Prediger und Vermarkter eines der ersten Modellierungstools. Seit 1994 selbstständig als Trainer und Berater mit den Schwerpunkten Software-/Systemarchitekturen und Requirements Engineering, bevorzugt im technischen Umfeld.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: