© Excellent backgrounds/Shutterstock.com
Java Magazin
Kolumne: Knigge für Softwarearchitekten

Die Systematischverbesserin

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.

Peter Hruschka, Gernot Starke


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 SystemeGrund: SchuldenfalleSystematisch verbessern in kleinen Schritten Abb. 1: Probleme und MaßnahmenSammeln Sie zuerst die Probleme, die Sie rund um das System und dessen Organisation finden ([1] nennt das problem list).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.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.Auch Maßnahmen haben Kosten – die Sie systematisch ermitteln oder schätzen müssen. ([1] nennt das improvement backlog).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.Praktiken, leider ohne GewährFazitAuszug Praktiken und PatternsAn 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 [1]: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 wiede...

Java Magazin
Kolumne: Knigge für Softwarearchitekten

Die Systematischverbesserin

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.

Peter Hruschka, Gernot Starke


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 SystemeGrund: SchuldenfalleSystematisch verbessern in kleinen Schritten Abb. 1: Probleme und MaßnahmenSammeln Sie zuerst die Probleme, die Sie rund um das System und dessen Organisation finden ([1] nennt das problem list).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.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.Auch Maßnahmen haben Kosten – die Sie systematisch ermitteln oder schätzen müssen. ([1] nennt das improvement backlog).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.Praktiken, leider ohne GewährFazitAuszug Praktiken und PatternsAn 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 [1]: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 wiede...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang