Architekturberatung im Software-Engineering
Evaluation von Systemstrukturen und Entwicklungsprozessen
Softwarequalität ist dynamisch und das Resultat aktiver Steuerung.
Gleichzeitig wächst die Komplexität technischer Systeme rasant und verlangt eine gezielte Steuerung
(controlled Self-Governance).
Um Qualität, Stabilität, Leistungsfähigkeit und Anpassungsfähigkeit systematisch zu erhöhen,
werden Steuerungsinstrumente und Methoden der Verifikation und Validierung speziell
für industrielle Systeme ständig weiterentwickelt.
Durch eine fehlende aktive Steuerung ergibt sich ein bekanntes Phänomen,
das sich brachenübergreifend mustertypisch beobachten lässt (siehe Abbildung 1).
Abbildung 1: Das Phänomen „Technische Schulden“ (Kruchten et al., 2019)
Die Gründe für das Phänomen „Technische Schulden im Software-Engineering“ sind umfassend beschrieben;
eine wesentlich Ursache ist die projektbezogene Finanzierung;
damit werden Anforderungen priorisiert, die einen direkten Geschäftswert (Projektnutzen) generieren.
Software-Qualitätsmetriken (wie Wartbarkeit > Modularisierung und Isolation) sind daher strakt unterrepräsentiert.
Formulierte Qualitätsziele und gemessene Metriken driften auseinander;
die entstehende Diskrepanz lässt sich auf Organisationsebene messen.
Quelle:
Kruchten et al. (2019),
Kruchten, Nord & Ozkaya (2012)
Das Muster:
Abhängig von der Organisation entstehen bereits nach einem Jahr aufgrund der Vernachlässigung qualitativer Anforderungen erhöhte Kosten in der Entwicklung.
Nach weiteren 6-24 Monaten, sinkt die Produktivität messbar, Fehlerkorrekturen nehmen zu, Entwicklungsgeschwindigkeit (Velocity) und Entwicklungskapazität mit direktem Geschäftswert nehmen ab.
Nach 3-5 Jahren, übersteigen Aufwände für Fehlerkorrekturen die Kosten der Entwicklung, die Externalisierungsquote steigt und trägt zur Beschleunigung der Architektur-Erosion bei;
die (fehlende) strategische Ausrichtung verstärkt das Phänomen und wirkt unmittelbar auf die Wettbewerbsfähigkeit.
Eine evolutionsstrategische Ausrichtung ist für fundierte Architektur- und Designentscheidungen
(Priorisierung, Berücksichtigung von Lösungsalternativen und Risiken) hilfreich,
um auf operativer Ebene Effektivitäts- und Effizienzpotenzialen zu aktivieren.
Notwendig sind jedoch verlässlich formulierte Anforderungen.
Daher ist nach wie vor das Requirements Engineering (RE) im Software-Engineering ein zentraler Aspekt jedoch auch eine zentrale Herausforderung.
“Successful software systems always evolve as the environment in which these systems operate changes and
stakeholder requirements change. Therefore managing change is a fundamental activity in RE.”
Quelle: Nuseibeh & Easterbrook (2000) „Requirements engineering: A roadmap“
In der Softwareentwicklung verbergen sich Technische Schulden häufig hinter Fehlern, Störungen und Systemausfällen.
Eine systematische Vorgehensweise zur Identifikation und Priorisierung von Störungen ist die
Methode der Eight Disciplines (8D). Sie stützt sich auf Industriestudien, mit Forschungsfeldern wie
Root Cause Analysis und Technical Debt, Prozessstandards und -verbesserung und insbesondere Re-Work im industriellen Software-Engineering.
Die Ergebnisse zeigen: Erfolgreiche agile Softwareentwicklung ist kein Zufallsprodukt, sondern das Ergebnis aktiver Steuerung.
Organisationsspezifische Besonderheiten, Strukturen, Praktiken und Herausforderungen tragen zu diesem tendenziell evolutionären Phänomen bei.
- Für eine unabhängige Studie stehen wir gerne zur Verfügung