Liebe Leserinnen, liebe Leser,

Ich bin glücklich zu verkünden, dass ich das Schreiben einer Übersicht/Zusammenfassung der Arcadia modellbasiertes Systems-Engineering Methode, die ich auf meiner Github-Seite veröffentlicht habe, zu Ende gemacht habe. Dies war hart zu erledigen, besonders wenn man die interessante Struktuierung des Buches in Betracht zieht (siehe meine Rezension), aber es lohnte sich, mit dieses Thema Zeit zu verbringen.

Also, warum sollte man beträchtliche Zeit in das Schreiben dieser Zusammenfassung investieren? Einfach gesagt, weil modellbasiertes Systems-Engineering (MBSE) heutzutage schwer zu vermeiden ist. Da ein stetiger Übergang von dem klassischen dokumentbasierten Systems-Engineering (DBSE) zum MBSE stattfindet, ist das Lernen der Methode gut angelegte Zeit. Um es deutlicher zu machen, warum dieser Übergang unterwegs ist, werden beide Ansätze in Kürze unter die Lupe gestellt.

DBSE bewältigt das Problem des Systementwurfs durch die Erstellung eine Reihe von Dokumenten, während eine gut definierte Methode, wie das V-Modell, im Auge behalten wird. Einerseits stellt die linke Seite der “V” die Dekomposition der Anforderungen und die Erstellung von Systemspezifikationen dar, andererseits die rechte Seite die Integration und Validierung. Die linke Seite produziert eine Reihe von Dokumenten, wobei jede stimmt mit einer der Abstraktionsebenen des V überein. Eine Beispielreihe von Dokumenten könnte das Folgende sein:
Projektantrag –> funktionaltechnische Spezifikation –> architekturtechnische Spezifikation –> komponententechnische Spezifikation
Das Endprodukt ist eine große Reihe von Dokumenten, die miteinander etwas verbunden sind.

Hier gibt’s ein paar Einschränkungen dieses Ansatzes:

  • Um Kohärenz und Konsistenz unter allen Dokumenten zu halten, braucht man im Laufe des Projekts in ein erheblich hoches Ausmaß an Arbeit für das Schreiben, die Prüfung und Aktualisierung der verschiedenen Dokumenten zu investieren.
  • Anforderungen werden mithilfe der natürlichen Sprache und Abbildungen erfasst, aber es ist aufwändig, die Konsistenz darunter zu halten. Überspezifikation ist eine echte Gefahr.
  • Wegen der fehlenden gut definierten und durchzusetzenden Verbindungen ist es sehr schwierig, eine Rückverfolgbarkeit unter den Entwurfelementen der Tief- und Hochebenen zu schaffen.
  • Die Kommunikation der Ideen ist aufwändiger, da die Informationen unter vielen Dokumenten ausgebreitet sind.
  • Eine große Reihe von Werkzeugen ist notwenig, um die Dokumenten zu erstellen: Analysewerkzeug, Diagrammwerkzeug, Veröffentlichungswerkzeug, Dokumentenmanager, usw.

Andererseits, MBSE konzentriert sich auf die Erstellung von Dokumenten nicht (sie sind nur Nebenprodukte), stattdessen verfolgt das das Ziel, eine Reihe von Elementen, die eine Anforderung, einen Bedarf, ein Verhalten, eine Aktion, einen Aktor oder etwas Anderes in Bezug auf das System representiert, zu erstellen. Diese Elemente werden in einem Datenbank gespeichert, und gut definierte Beziehungen werden für alle Elemente binnen und unter den verschiedenen Engineeringebenen auch erstellt. Dies garantiert nicht nur die uniforme Darstellung der Konzepte, sondern auch ermöglicht das eine uniforme Visualisierung durch standardisierte Diagramme. Die Verwendung solches Ansatzes garantiert Konsistenz und Rückverfolgbarkeit unter allen Ebenen, und das ermöglicht eine einfachere Kommunikation unter allen betroffenen Beteiligten auch.

Natürlich braucht man eine Modellierungssprache und Methode, um ein Modell bauen zu können. Glücklicherweise stehen einige Möglichkeiten zur Verfügung:

  • Als Sprache gibt es:
  • Als Methode kann man die Folgenden auswählen:
    • Harmony-SE
    • INCOSE Object-Oriented SE (OOSEM)
    • IBM Rational Unified Process SE (RUP SE)
    • Vitech SE
    • JPL State Analysis (SA)
    • NATO Architecture Framework Methodology (NAF)
    • Dori Object-Process Methodology (OPM)
    • Arcadia
    • Und vielleicht mehr

Über eine gute Übersicht der meisten obengenannten Methoden (ausschließlich Arcadia und NAF) kann man in einer JPL-Publikation lesen. Eine weitere gute Quelle ist eine relativ aktuelle Dissertation, die OOSEM/SysML mit Arcadia/Capella vergleicht. Letztendlich kann man über NAF in der offiziellen NATO-Publikation mehr herausfinden.

Es ist schon ganz klar, dass ziemlich viele Möglichkeiten vorhanden ist, und die Auswahl ist nicht einfach. Lange Rede kurzer Sinn, ich habe Arcadia/Capella basierend auf den folgenden Gründen ausgewählt:

Die Methode, Sprache und das zugehörige Entwicklungswerkzeug wurden

  • unter Betrachtung von Zusammenarbeit
  • basierend auf den Erkenntnissen, die bei der Nutzung der anderen Methoden gewonnen wurden,
  • mittels Ideen aus etlichen anderen Sprachen (NAF, SysML, AADL)
  • als etwas Einfacheres für Ingeniuere (schneller On-Boarding)
  • als etwas Allgemeineres und nicht Bereichspezifiziertes
  • unter Betrachtung von dem “Leerpapier-Syndrom”
  • schrittweise, im Laufe mehreren Jahren (8), basiernd auf den Rückmeldungen der Ingeniuere, die an verschiedenen Projekten aus verschiedenen Bereichen arbeiten,
  • von einem großen Unternehmen (Thales), das sachliche Systmes-Engineering (Luftfahrt, Transport, Verteidigung, Sicherheit) macht,

entwickelt.

An dieser Stelle weiß ich natürlich nicht, ob sich Arcadia als das erwartete Werkzeug herausstellen wird, aber die obengenannten Argumenten scheinen für eine ernste Ausprobierung ziemlich solide zu sein, besonders wenn man bedenkt, dass ich die Zeitmenge, die die Tales-Leute für die Prüfung der anderen Sprachen/Methoden hatten, nicht habe. Einfach gesagt verlasse ich mich jetzt auf ihre Erfahrung und Beurteilung (und ihren Bedarf für die Entwicklung einer eigenen Methode trotz der zahlreichen anderen vorhandenen Methoden).

Mal wieder, vielen Dank fürs Lesen.