Umgang mit Veränderungen in der Systemtechnik

Der Umgang mit Veränderungen wird immer schwieriger, da sich Veränderungen im Allgemeinen beschleunigen. Daher benötigen wir neue Paradigmen für den Umgang mit Veränderungen. Dieser Artikel skizziert die Idee, eine Bibliothek von Mustern für das Management von Veränderungen in der Produktentwicklung aufzubauen.

Viele Organisationen haben etablierte Prozesse für das Change Management und führen auch Initiativen zur Transformation ihrer Organisation durch. Ziel der Bibliothek ist es, einfache und bewährte Bausteine für die Umsetzung bereitzustellen.

Mehr über diese Konzepte können Sie auf der ReConf 2019 im Vortrag erfahren “Entwicklungsmuster für den Umgang mit Veränderung” (Michael Jastram). Also, wir haben bereits eingeführt eine erste Zusammenfassung dieser Idee auf unserem deutschen Partnerblog SE-Trends (Google Übersetzung).

SE ist ziemlich gut im Umgang mit Veränderungen

Änderungsmanagement war schon immer ein integraler Bestandteil des System-Engineerings. ISO/IEC 15288:2015 enthält beispielsweise einen Prozess für das Konfigurationsmanagement (Abschnitt 6.3.5), der sich unter anderem mit kontrollierten Änderungen befasst. Der Standard enthält aber auch eine Reihe von Definitionsprozessen (für Stakeholder-Anforderungen, 6.4.2, Systemanforderungen, 6.4.3, Architektur, 6.4.4, und Design, 6.4.5). Während der Definition findet ebenfalls eine Änderung statt, jedoch weniger kontrolliert.

Aber der Standard gibt vor, was getan (und geändert) werden muss, nicht wie. Hier kommt diese Bibliothek von Mustern ins Spiel. Sie ermöglicht es, bestehende Prozesse zielgerichtet und systematisch kontinuierlich zu verbessern.

Umfang dieser Arbeit

Obwohl diese Arbeit einen Schwerpunkt auf Veränderung legt, ist das zugrunde liegende Ziel des System Engineerings, großartige Produkte zu entwickeln. Daher soll diese Arbeit einen positiven Einfluss auf die Produktentwicklung haben. Jedes Muster soll entweder zu besseren Ergebnissen, schnelleren Ergebnissen oder denselben Ergebnissen bei geringerem Ressourceneinsatz führen. Und am wichtigsten ist, dass die Muster der Auswirkung erhöhter Veränderbarkeit entgegenwirken sollen.

Organisieren von Entwicklungsmustern

Es gibt viele Möglichkeiten, Muster zu organisieren, aber eine davon ist nach dem gewünschten Ergebnis. Wir ändern etwas, weil wir etwas verbessern wollen. Die Muster werden grob in folgende Kategorien eingeteilt:

• Qualität verbessern Im Kontext des Change Managements möchten wir die Anzahl der Fehler reduzieren und die Erkennung von Inkonsistenzen, die eine Änderung einführen kann, erhöhen.
• Effizienz steigern – Eine Änderung löst Nacharbeit aus, die minimiert werden soll. Automatisierung kann auch dazu beitragen, die Effizienz im Lichte von Veränderungen zu steigern.
• Transparenz verbessern – Wir müssen die Auswirkungen einer Änderung im Voraus verstehen und ihre Folgen danach sehen. Nur Transparenz ermöglicht es uns, die richtigen Kompromisse in Bezug auf Änderungen einzugehen.
• Änderungsauswirkungen verringern Veränderungen können eine Kettenreaktion auslösen, bei der eine Veränderung weitere Veränderungen nach sich zieht, die wiederum weitere nach sich ziehen.
• Kollaboration verbessern – Letztendlich entwickeln Menschen Produkte. Die Verbesserung der Zusammenarbeit ist eine Möglichkeit sicherzustellen, dass alle Beteiligten die Auswirkungen geplanter Änderungen verstehen und dass das Team die Möglichkeit hat, die Änderung zu optimieren, z. B. um die Auswirkungen zu reduzieren oder gleichzeitig die Architektur zu verbessern.

Beachten Sie, dass diese sich nicht gegenseitig ausschließen (und die Liste ist übrigens noch nicht endgültig). Bessere Zusammenarbeit verbessert beispielsweise in der Regel auch die Qualität und Transparenz. Daher haben Muster eine primäre und können sekundäre Kategorien haben.

Aktivitäten

ISO 15288 definiert eine große Anzahl von Aktivitäten, aber diese lassen sich auch grob kategorisieren. Sie fallen typischerweise in eine der folgenden Kategorien:

• Strukturieren – Aufbau einer Struktur (oder eines Meta-Modells) für die Entwicklungsobjekte. Die Anwendung von Mustern auf die Struktur kann diese besser für den Umgang mit Änderungen geeignet machen.
• Entwickeln – Dies ist der eigentliche Prozess des Verfassens und Entwickelns von Inhalten. Das Befolgen von Mustern während dieser Aktivität kann den Umgang mit Änderungen erleichtern, z. B. durch das Schreiben atomarer Anforderungen.
• Analysieren – Bestimmte Analyse-Patterns haben einen direkten Einfluss auf den Umgang mit Veränderungen, wie die Auswirkungsanalyse.
• Zur Dokumentation – Dokumentation kann überraschend viel Aufwand erfordern und ist im Lichte des Änderungsmanagements eine wichtige Tätigkeit.
• Ändern – Diese Aktivität befasst sich mit formellen Änderungen, im Gegensatz zu den Änderungen, die während der Entwicklung auftreten.

Zusammenfügen

Muster können nun in einer Matrix platziert werden, die Aktivität und Zweckmäßigkeit vereint. Als Beispiel haben wir fünf Muster hinzugefügt, die kurz unten beschrieben werden.

Die in dieser Tabelle als Beispiel verwendeten Muster sind:

• Black Box – Dieses Muster schlägt vor, Blöcke unseres Systems anhand ihrer Anforderungen und Schnittstellen zu definieren, nicht anhand ihrer internen Arbeitsweise. Dieser Ansatz ist in SysML-Blöcken formalisiert, kann aber auch informell angewendet werden. Dieses Muster wird bei der Strukturierung unserer Systembeschreibung angewendet. Es hat den Vorteil einer verringerten Auswirkung von Änderungen (im Vergleich zu informellen Anforderungen): Jegliche Änderungen innerhalb eines Blocks beeinträchtigen andere Systeme, die den Block nutzen, nicht, solange sich die Schnittstellen und das Verhalten nicht ändern.
• Überprüfung – Reviews erhöhen nachweislich die Qualität und verringern das Entwicklungsrisiko, wenn sie frühzeitig und häufig durchgeführt werden. Entscheidend ist dabei, dass die Reviews effizient durchgeführt werden. Jama’s Review Center ist ein Beispiel für ein Werkzeug, das etwa doppelt so effizient ist wie die Nutzung von Word und E-Mail für Überprüfungen.
• Anforderungsänderung – Diese Metrik misst die Stärke der Änderungen innerhalb der Anforderungen im Verhältnis zur Gesamtzahl. Die Volatilität ist zu Beginn der Entwicklung typischerweise hoch und nimmt ab, wenn sich die Anforderungen stabilisieren. Plötzliche Spitzen in der Volatilität sind ein Zeichen für zugrunde liegende Probleme (z. B. Probleme in der Architektur). Die Messung der Volatilität und die proaktive Reaktion darauf sind ein Weg, effizienter mit Änderungen umzugehen. Allerdings messen nur wenige Organisationen die Volatilität von Anforderungen.
• Einseiter – Die Verwendung einiger Einzelseiten kann die Transparenz zwischen Teams drastisch verbessern, selbst wenn keine integrierten Toolchains vorhanden sind. Einseiter wurde hier schon einmal beschrieben.
• Verdächtige Verbindungen – Viele Werkzeuge unterstützen diese Funktion bereits: Eine Änderung an einem Element markiert verwandte nachgelagerte Elemente als fraglich. Beispielsweise führt die Änderung der Batterielaufzeit eines Produkts dazu, dass nachgelagerte Designelemente (z. B. Akkukapazität) und Tests (z. B. Ausdauertest) als fraglich markiert werden. Die Verwendung von Fraglich-Links stellt sicher, dass nur die Elemente, die von einer Änderung betroffen sein könnten, erneut analysiert werden. Wenn dies eine nachgelagerte Änderung auslöst, werden die verbundenen Elemente eine Ebene tiefer erneut als fraglich markiert, aber nicht weiter.

Demnächst: Eine Kollektion von Mustern

Was wir hier vorstellen ist ein Rahmenwerk für Muster im Zusammenhang mit Veränderungen in der Produktentwicklung. Wir erforschen diese Ideen derzeit und werden sie zu einer ausreichenden Reife vorantreiben, um demonstrieren auf der ReConf 2019. Ob wir über dieses hinausgehen, hängt vom Feedback ab, das wir erhalten.

Foto von Suzanne D. Williams auf Unsplash