Schluss mit "one size fits all" – modellbasiertes Variantenmanagement

Teil 3: Nutzung eines spezialisierten Werkzeuges für Variantenmanagement

Wie angekündigt schauen wir heute auf die Optionen, die modellbasiertes Variantenmanagement mit IBM Rhapsody in Kombination mit einem spezialisierten Werkzeug wie pure::variants eröffnet.

Auf den ersten Blick mag der Einsatz eines weiteren Tools wie zusätzlicher Overhead aussehen, der die Entwicklung von Varianten eines Produktes oder Systems eher komplizierter als einfacher macht. Wenn man sich jedoch näher mit der Entwicklung von Varianten komplexer Systeme befasst, stößt man auf Aspekte, die den Einsatz eines dedizierten Werkzeuges für Variantenmanagement sinnvoll werden lässt:

1. In solchen Entwicklungsprojekten arbeiten in der Regel auch Experten aus Disziplinen, die mit Variantenmanagement auf der Ebene von UML-Modellen nicht vertraut sind, z.B. Experten für Anforderungsmanagement, Testen und Qualitätssicherung. Je nach Art des Projektes können auch Einkauf, Fertigung, Logistik und weitere Unternehmensbereiche involviert sein.
2. Eine Integration des UML-basierten Variantenhandlings auf Tool-Ebene steht nicht immer zur Verfügung, so dass für alle Disziplinen, die nicht mit UML arbeiten, die korrekte Handhabung der Varianten sehr aufwendig werden kann.
3. Je nach Art des Produktes kann die Anzahl der Varianten sehr groß werden, und die Varianten können auf vielfältige Weise verzahnt oder verschachtelt sein. Die Abbildung aller Varianten im UML-Modell kann aufwendig und unhandlich werden.

Varianten, Variation, Variabilität … was genau heißt das eigentlich?

Um eine Vorstellung davon zu entwickeln, welche Art von Zusammenhängen beim Variantenmanagement betrachtet und verwaltet werden muss, ist es hilfreich, sich die semantischen Details von Begriffen wie Variation, Variation Point, Variante, Ableitung einer Variante und Variabilität zu vergegenwärtigen. Eine gute Einführung in die Begriffe gibt dieser Artikel (link in neuem Tab zu https://www.pure-systems.com/ple-knowledge/whitepaper-and-editorials/versions-variants-and-the-rest-basic-definitions). Eine vollständige Definition dieser Begriffe würde den Rahmen dieses Artikels sprengen, daher hier nur soviel: „Variante“ ist kein Synonym für „Version“!

Das „Feature Tree“ Modell

Eine verbreitete Herangehensweise ist die Abbildung des gewünschten Spektrums von Varianten in Form eines „Feature Tree“ Modells, das als dediziertes Metamodell ausschließlich der Beschreibung der Varianten dient und von allen Projektbeteiligten genutzt wird. In der praktischen Entwicklungsarbeit wird dieses Feature Tree Modell in einem dedizierten Werkzeug wie pure::variants angelegt und verwaltet. Die Verknüpfung von pure::variants mit den im Projekt verwendeten Engineering Tools ermöglicht allen Projektbeteiligten den direkten Zugriff auf die aktuelle und vollständige Dokumentation der Varianten und verhindert das Divergieren von Planung und Realisierung.

Wie der Ablauf im Projekt konkret aussehen kann, zeigen wir in einer integrierten Umgebung mit den IBM Engineering Tools DOORS Next, Rhapsody und Engineering Workflow Management (EWM) mit dem auf Variantenmanagement spezialisierten Werkzeug pure::variants.

Das Kolibri Beispiel – Definition von Varianten und Features

In unserem Beispiel betrachten wir eine Drohne (im Modell als „Hummingbird“, deutsch Kolibri, bezeichnet) mit den Features „Target Tracking“, „Remote Monitoring“ und „Power Management“. Dabei sind „Target Tracking“ und „Remote Monitoring“ optionale Features. „Power Management“ ist eine Basisfunktion, die in allen Varianten vorhanden sein muss, da der Betrieb der Drohne ohne Spannungsversorgung nicht möglich ist. Die Auslegung der Spannungsversorgung für eine Variante ist abhängig von den in dieser Variante gewählten optionalen Features: durch den erhöhten Strombedarf der Funktion „Target Tracking“, muss bei Auswahl dieser Funktion die Spannungsversorgung mit 7Ah parametrisiert werden, ansonsten sind 5Ah ausreichend.

Die genaue Abfolge der Schritte bei der Realisierung von Varianten entlang des Lebenszyklus finden Sie ausführlich mit vielen Screenshots in diesem PDF Dokument

Fazit:

Wir haben in dieser Serie drei unterschiedliche Varianten für das Management von Varianten bei Modell-basierter Entwicklung vorgestellt. Welche Option im konkreten Projekt zum Einsatz kommt, hängt von den Rahmenbedingungen ab; es gibt keine „beste Lösung“, die für jedes Projekt gleichermaßen optimal funktioniert.

1. Nutzung der Funktionen, die im Modellierungswerkzeug vorhanden sind: In dem UML-Modellierungswerkzeug IBM Rhapsody gibt es die Möglichkeit, Varianten über das Element VariationPoint im Modell zu definieren. Diese Option empfiehlt sich für Projekte mit Implementierungsvarianten, die keine oder nur überschaubare Abhängigkeiten zueinander haben und durch das Austauschen einzelner Klassen oder Blöcke realisiert werden.
2. Nutzung eines speziellen UML-Profils: Mit dem VAMOS Profil von Tim Weilkiens, das spezifisch für Variantenmanagement im Systems Engineering ausgelegt ist, können Variantenmodelle präzise modelliert werden, inklusive aller Elemente, die zu anderen Varianten gehören (150%-Modell) sowie definierte Konfigurationen dieser Varianten innerhalb des SysML-Modells. Diese Option ist empfehlenswert für komplexe Varianten, die dennoch vollständig im SysML/UML-Modell beschrieben werden sollen.
3. Nutzung eines spezialisierten Tools für Variantenmanagement: Ein Tool wie pure::variants lässt sich nahtlos in die Entwicklungsumgebung integrieren und ermöglicht die zentrale Definition und Verwaltung von Varianten und damit verbundenen Features. Diese Option ist von Vorteil, wenn die Bildung von Varianten sich durch alle Disziplinen im Entwicklungsprozess zieht und daher alle Beteiligten Zugriff auf Varianten und Features haben müssen. Die Möglichkeit, ausschließlich optimierte 100%-Modelle für die jeweiligen Disziplinen auszuleiten, um sie an Projektpartner zu übergeben, sorgt zudem für eine Verschlankung und Vereinfachung der Zusammenarbeit im Projekt.

Im Rahmen dieser Artikelserie war natürlich nur eine relativ oberflächliche Betrachtung der Optionen möglich; eine detailliertere Beschreibung hätte den Rahmen gesprengt. Falls Sie sich gerade mit dem Thema Variantenmanagement beschäftigen und tiefer in die Materie eintauchen wollen, sprechen Sie uns jederzeit an. Das hier beschriebene Beispiel können Sie selbst anschauen und sich damit in einer Sandbox-Umgebung vertraut machen; die Zugangsdaten schicken wir Ihnen gern auf Anfrage. Auch für einen unverbindlichen ersten Austausch stehen unsere Experten gern zur Verfügung. Nehmen Sie Kontakt auf per Email an info@sodiuswillert.com, und wir kommen ins Gespräch.

Hier gehts zu Teil 1 und Teil 2