Änderbarkeit
Änderbarkeit bewertet Aufwand und Risiko einer benannten Änderung; gute Grenzen halten die Zahl gemeinsam anzupassender Bausteine klein. In ISO 25010 heißt das Modifiability und gehört zur Wartbarkeit (Maintainability).
- ÄnderungEine benannte Anforderung als Maßstab.
- UmfangWie viele Module mitgeändert werden.
- MessungZahlen statt Bauchgefühl.
Einordnung
Warum das wichtig ist
Änderbarkeit zeigt sich erst bei einer konkreten Änderung: Wie viele Bausteine müssen angepasst und getestet werden? Unklare Grenzen machen aus kleinen Wünschen breite Regressionen. Die Mittel dafür vertiefen eigene Bausteine, etwa Kopplung und Modulgrenzen.
Hier legst du fest und misst, wie aufwendig und riskant Änderungen sind. Wie die Architektur das erreicht, zeigen die Taktiken unten; die laufende Prüfung übernehmen Fitness Functions.
Auf einen Blick · Eine Änderung, Umfang gemessen
Änderung Abholung einführen
Der Shop führt die Option Abholung ein. Bestellung und Lager ändern ihr Verhalten; Zahlung, Versand und Rechnung sollen über stabile Verträge nur gezielt betroffen sein.
So liest du das Bild
- Änderung Das Szenario „Abholung einführen“ nennt die Änderung, an der alle Module gemessen werden.
- Umfang Bei unklaren Grenzen sind fünf von sieben Modulen betroffen, bei klaren nur Bestellung und Lager.
- Messung Die Tabelle nennt vier Messgrößen: betroffene Module, Durchlaufzeit, Fehlerquote und verletzte Strukturregeln.
- betroffenBestellungVersandfelder überall prüfen
- betroffenLagergemeinsame Tabellenlogik ändern
- betroffenVersandSonderfälle im Ablauf verteilen
- mitprüfenZahlungWirkung unklar, mitprüfen
- mitprüfenRechnungWirkung unklar, mitprüfen
5Betroffene Module (von 7 im Shop)
Ohne klare Verträge zieht die Änderung durch viele Bausteine. Niemand weiß sicher, was betroffen ist, also wird breit getestet. Das ist eine breite Regression.
So misst du Änderbarkeit
| Messgröße | Woher die Daten kommen | Im Shop |
|---|---|---|
| Betroffene Module je Änderung | Änderungsanalyse im Git: welche Dateien und Module gemeinsam geändert werden | Abholung: 2 statt 5 Module |
| Durchlaufzeit einer Änderung | DORA-Kennzahl Lead Time for Changes (vom Commit bis zur Auslieferung) | Abholung ist in wenigen Tagen live statt nach einem Regressionszyklus |
| Fehlerquote nach Änderungen | DORA-Kennzahl Change Failure Rate | Anteil der Shop-Auslieferungen, die Nacharbeit brauchen |
| Verletzte Strukturregeln | Fitness Functions im Build | Versand liest keine Bestelltabellen |
Taktiken
So erreicht die Architektur das Ziel
Dieser Baustein legt fest und misst, wie gut sich Änderungen umsetzen lassen; die Taktiken unten sind eigene Bausteine, die dieses Ziel erreichen.
Kopplung senken
Eine Änderung an der Zahlung zwingt Bestellung und Katalog nicht zur Anpassung.
Zusammenhalt erhöhen
Zusammengehörige Preisregeln liegen an einer Stelle, sodass eine Änderung wenige Orte berührt.
Schnittstellen stabil halten
Verträge und Versionen erlauben, dass Shop und Partner sich getrennt voneinander ändern.
Nutzen & Grenzen
Hilft, wenn
- Eine häufige Regeländerung verursacht wiederholt breite Anpassungen oder Regressionen.
- Ein technischer Austausch ist absehbar und soll bei einer begrenzten Zahl von Bausteinen stattfinden.
Grenzen
- Flexibilität auf Vorrat kostet: Erweiterungspunkte für Änderungen, die nie eintreten, machen das System komplizierter (YAGNI). Investiere dort, wo Änderungen nachweislich häufig sind, und belege das mit der Git-Analyse.
- Eine Änderung kann trotz lokalem Code mehrere Freigaben oder Datenmigrationen erfordern. Prüfe neben Struktur auch Team- und Betriebsabläufe und ergänze passende Fitness Functions.
In der Praxis
- Änderungsfall konkret beschreiben. Benenne Ausgangszustand, gewünschtes Verhalten und wahrscheinliche Häufigkeit. Das Ergebnis bezieht die Bewertung auf eine reale Anpassung statt auf abstrakte Flexibilität.
- Betroffene Abhängigkeiten verfolgen. Ermittle Module, Verträge, Daten und Freigaben, die die Änderung berührt. Verknüpfe erkannte Grenzen mit Modulgrenzen, um unnötige Auswirkungen zu prüfen.
- Änderungsweg und Risiko bewerten. Berücksichtige Implementierung, Tests, Migration und Betriebsfreigabe. Eine Fitness Function prüft anschließend, ob eine relevante Strukturregel dauerhaft erhalten bleibt.
Ausführliche Erklärung lesen
Änderbarkeit zeigt sich an konkreten Regeln, Schnittstellen und Technologien, die sich voraussichtlich ändern. Zuständigkeiten und stabile Verträge begrenzen, wie viele Teile betroffen sind. Modulgrenzen kapseln Änderungen; Fitness Functions prüfen, ob wichtige Strukturregeln erhalten bleiben.
Berücksichtige Codeumfang, Abstimmung, Migration, Tests und Betriebsfreigaben gemeinsam bei der Bewertung. Eine Abstraktion lohnt sich, wenn sie einen realen Änderungsweg vereinfacht oder ein belegtes Risiko reduziert. Wiederkehrende Änderungen liefern bessere Hinweise für Strukturarbeit als eine unbestimmte Forderung nach maximaler Erweiterbarkeit.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Welche Bausteine ändern sich bei klaren Modulgrenzen?
Lösung mit Begründung ansehen
Bestellung (Lieferart ergänzen) und Lager (Abholreservierung anbieten). Versand erhält bei Abholung keinen Auftrag.
AnwendenAuf eine neue Lage übertragen
Ein Kunde wählt Abholung für B-1042. Soll das Versandmodul davon wissen?
Lösung mit Begründung ansehen
Nein, das Versandmodul erhält bei Abholung keinen Auftrag. Das Bestellmodul entscheidet anhand der Lieferart.
BewertenEine Alternative abwägen
Das Team verzichtet auf Vertragstests, um schneller zu liefern. Wie bewertest du das?
Lösung mit Begründung ansehen
Kurzfristig spart es Aufwand. Die Tabelle zeigt aber, dass klare Grenzen mit gezielten Vertrags- und Modultests verbunden sind; ohne sie wächst die Regression wieder breit.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- David Parnas · On the Criteria To Be Used in Decomposing Systems into Modules (öffnet in neuem Tab)Grundlagenpapier (1972) zu Information Hiding: Module nach Entscheidungen schneiden, die sich wahrscheinlich ändern.
- DORA · Die vier Schlüsselkennzahlen (öffnet in neuem Tab)Definiert Lead Time for Changes und Change Failure Rate.
- arc42 Quality Model · Modifiability (öffnet in neuem Tab)Beschreibt Modifiability mit Szenarien und Maßnahmen.