Mehrfachbelegungsfelder für die Allokation von Architekturkomponenten – Teil 2

Architektur Multivalue Attribute in DOORS und Polarion

Im ersten Teil des Blogs ging es um die Wichtigkeit von Attributen im Anforderungsspezifikationsprozess. Weiter wurden Beispiele für die Verwendung von Attributfeldern mit Mehrfachauswahl genannt. Das letzte Beispiel bezog sich auf den Architekturprozess und die Bezugsetzung von Architekturteilen zu Anforderungen. Diese ist allgemein als Allokation bekannt.

Bevor diese Arbeitsprozesse die Früchte eines guten Tool-Designs ernten dürfen, müssen wir etwas “Gehirnschmalz” in die Definition von Multivalue-Attributen stecken. Die Defintion und Umsetzung unterscheidet sich je nach verwendetem RM-Tool. In diesem Blog werden die beiden RM-Tools DOORS und Polarion dazu näher beleuchtet und gegenübergestellt.

---

Im RM-Tool DOORS spielt sich die Defintion eines Multivalue-Attributs in den Typ- und Attributdefinitionen eines Modul-Fensters ab. Mit vielen Abstrichen lässt sich ein Modul in DOORS mit einem Dokument gleichsetzen, also einem geschützten “Container”, der die Erstellung eines Anforderungsdokuments erlaubt.

Im RM-Tool Polarion wird dieser Container als „Project“ bezeichnet. Wobei auch hier der Vergleich hinkt, da diese Art von Container eine Vielzahl von Dokumentelementen anzulegen und zu pflegen erlaubt – in den Polarion-Unterlagen werden diese „Untercontainer“ manchmal auch als „Tracker“ oder „Modul“ bezeichnet. Im Unterschied zu DOORS ist für jeden Workitem-Typ, der im „Project“ zur Verfügung steht, oder noch selbst vom Project-Administrator definiert wird, ein eigenes Set an Feldern festgelegt.

Das DOORS-Konzept basiert auf einer vorgegebenen generischen Objektdefinition pro Modul, die durch den Nutzer erweiterbar ist. Durch ein definierbares Attribut wie z. B. “Objekttyp” lässt sich der Workitem-Typ-Ansatz ähnlich wie in Polarion nachahmen.

---

Ein beispielhaftes Architekturszenario

Nehmen wir an, wir arbeiten an einem System mit den Subsystemen A, B und C und verfolgen den weiter oben schon erwähnten Ansatz der Subsystem-Allokation, so benötigen wir in der Spezifikationsumgebung die entsprechenden Attribut- bzw. Felddefinitionen und eine Sicht auf die Anforderungsattribute, die uns die Manipulation der Allokation erlaubt.

Das Vorgehen der Definition und Anwendung von Allokationsfeldern stellt sich in beiden Werkzeugen folgend dar:

---

Schritt I – Ein Allokationsattribut und seine Werteliste anlegen

---

---

---

Nun geht es ans Füllen der Spezifikation. In vielen Fällen sind schon Spezifikationsdaten vorhanden und der Requirements Engineer möchte größere Mengen im Dokument filtern und diesen eine spezielle Allokation aufprägen. Das können ganze Teilverzeichnisstrukturen sein, oder Anforderungsselektionen, die bestimmte Begriffe im Anforderungstext enthalten und damit hinweise auf eine architektonische Zugehörigkeit geben.

Wie gehen wir nun im jeweiligen Tool idealerweise in solchen Fällen vor.

---

Schritt II – Die Felder nutzbar machen

---

---

---

Schritt III – Anforderungen Selektieren und gleichzeitig Werte setzen

---

---

---

Schritt IV – Multiselektion von Multivalue Felder in multibler Anforderungsauswahl anpassen

---

---

Vom Lehrbeispiel zur Realität der Praxis

Die gezeigten Beispiele sind eine für Lehrzwecke stark vereinfachte Darstellung. In realen Entwicklungsvorhaben können Allokationslogiken weit umfassender sein und mehrere Ebenen umfassen (siehe Praxisbeispiel). Weiterhin muss man effiziente Routinen zur Hand haben, die einen schnell und genau auf Änderungen in der Architekturentwicklung reagieren lassen. Dass Komponenten zusammengefasst oder geteilt werden, neu benannt oder gelöscht werden, ebenso wie Komponentenschnittstellen, sollte sich auch schnell in der Allokation von Anforderungen widerspiegeln können. Geeignete Schnittstellen zwischen RM-Tool und Architekturmodell-Tool sollten die involvierten Managementdisziplinen unterstützen. Diese benötigen verschiedene Abgleichsmodelle, die die Qualitätsanforderungen aus dem jeweiligen Entwicklungsprozess erfüllen.

Folgendes Praxisbeispiel zeigt eine Allokationslogik, die in fünf Ebenen unterteilt wurde. Diese Unterteilungen stellen immer einen Kompromiss zwischen Praktikabilität und benötigter Präzision in der Kontrollierbarkeit der Systemevolution dar. Ein kleines Geheimnis der Spezifikationsprofis ist dabei die Abbildung des Spezifikationsbaums auf die statischen Systemarchitekturen. Diese Abbildung mittels eines geeigneten Allokationssystems anpassbar und konfigurierbar zu halten, zahlt sich bei den unvermeidlichen und unvorhersehbaren Änderungen, die das Weltgeschehen mit sich bringt, aus.

Praxisbeispiel: Fünf-Ebenen-Architekturallokation

---

Fazit

Produktinnovation heißt oft, große Spezifikationsbestände einer Neubearbeitung und Neuverwendung zuzuführen. Meist kommt dabei aus einer Risikobewertung oder puren regulativen Rahmenbedingungen die Notwendigkeit einer Anforderungsverfolgung in das Systemdesign dazu (Stichwort RLFP). Zeigt sich also, dass eine dokumentierte Weiterverfolgung von Spezifikation und Nachfolgetätigkeiten angebracht ist, so kann DOORS mit seinen herausragenden Fähigkeiten zur Bearbeitung von Attributen eine sehr gute Wahl sein. Manchmal muss auch tief in die Trickkiste gegriffen werden, um z. B. gezielt Optionsfelder in gefilterten Anforderungssichten zu manipulieren.

Für den ambitionierten Toolschmied, der ein tiefgehendes Gespür für die Wünsche und Träume eines Spezifikationsprofis hat, zeigen die obigen Beispiele auch nur eine mittelmäßige Lösung. Die Premium-Lösung muss performant sein, mit großen tief strukturierten Spezifikationsdatenmengen umgehen können und mit einer smarten Oberfläche ausgestattet sein. Smarte Oberfläche heißt aber nicht, mit Assistenten, Workflow und Guidance Funktionen überladene Apps zu generieren. Profis wissen was zu tun ist, freuen sich, wenn kontinuierlich Fortschrittsanzeigen (z. B. bearbeitete Bereiche versus nicht bearbeitete Bereiche) vorhanden sind und „Bulk“-Operationen die Mächtigkeit besitzen, sehr gezielte Füll- und Manipulations-Aktionen auf zielgenauen Filtersichten zu erlauben. Die „Inmates“ der Spezifikationsabteilungen kennen für diese Ansprüche in vielen Fällen nur noch Tabellen-Tools als mächtigstes Hilfsmittel. Der Mehraufwand des Tool Roundtrips muss dann leider in Kauf genommen werden.

Gibt es in deinem Umfeld „Mehrfachauswahlfeld“-Herausforderungen? Kontaktiere uns gern und vereinbare mit unseren Experten ein unverbindliches Gespräch!

Dieser Blogbeitrag wurde von Andreas Kreß für HOOD geschrieben.

Series Navigation

<< Mehrfachbelegungsfelder für die Allokation von Architekturkomponenten – Teil 1