11 Mar 2019
In der modernen arbeitsteiligen Gesellschaft werden komplexe Systeme durch viele unterschiedliche Personen entwickeln. Diese Aufteilung der Arbeit überschreitet auch Unternehmensgrenzen: Damit beispielsweise ein Auto auf die Straße kommt, arbeiten die großen Automobilhersteller mit vielen Lieferanten zusammen. Lieferanten liefern die Teile und die Automobilbauer integrieren diese Teile zu einem Gesamtfahrzeug. Natürlich sind diese Teile nicht nur mechanisch und elektrisch/elektronisch, sondern zu ihnen zählt zu immer größer werdendem Teil auch Software.
Damit die Lieferanten wissen, was genau zu tun ist, werden Anforderungen ausgetauscht. Pro System, das es zu entwickeln gilt, muss es ein Systemlastenheft geben. Das System wird in Komponenten verfeinert und pro Komponente gibt es auch ein Komponentenlastenheft. Ein modernes Fahrzeug hat über 100 Systeme und noch mehr Komponenten. Berücksichtigt man auch noch die verschiedenen Baureihen, kommen bei einem Automobilhersteller schnell Millionen an Anforderungen zusammen.
Eine Anforderung könnte lauten: “Wenn der Airbag auslöst, dann muss das Gefahrenblinken aktiviert werden”. Und hier sind wir mitten in einem der aktuellsten Themen der Automobilbranche (Stand 2019), dem Model Based Systems Engineering (MBSE). Stellen Sie sich vor, Sie bräuchten als Entwickler*in bereits sehr früh im Produktentstehungsprozess einen Gesamtüberblick über die Abläufe im Fahrzeug. Dann hätten Sie gern einen Graphen, dessen Knoten die Fahrzeugfunktionen (z.B. “Airbag auslösen” und “Gefahrenblinken aktivieren”) und dessen Kanten die Kommunikationswege (“A” ruft “B” auf) sind. Stattdessen haben Sie viele einzelne Anforderungen, die in so vielen einzelnen Spezifikationsdokumenten verteilt sind, dass sie eine einzelne Person bei weitem nicht überblicken kann.
Kundenkontext
Beim Kunden, einem großem Automobilhersteller, werden Anforderungen in IBM DOORS gepflegt (Stand 2019). Bevor aber die Anforderungen tatsächlich spezifiziert werden, wird erst einmal festgelegt, welche Systeme und Funktionen das Fahrzeug überhaupt haben soll. Dies wird mit einer Liste, auch in DOORS, erledigt:
- Baureihe A
- System: Insassenschutz
- Funktion: Airbag auslösen
- …
- System: Außenlicht
- Funktion: Gefahrenblinken aktivieren
- …
- System: Scheibenwischen
- Funktion: Frontwischen (Intervall)
- Funktion: Heckwischen
- …
- System: Insassenschutz
Das Ziel unseres Projektes war es, aus dieser Liste (bzw. diesem Baum) einen Graphen zu machen, der auch die Abhängigkeiten zwischen den Funktionen enthält. Diese Abhängigkeiten sind (aus Sicht des Computers) jedoch in den Lastenheften in Form von natürlicher Sprache kodiert.
Unser Beitrag
In diesem Projekt haben wir
- den Excel-Export der System- und Funktionsliste mit Python bereinigt.
- den Graphen in JSON als Baum initialisiert.
- in Anforderungen (CSV-Exporte aus DOORS) mit Python nach Links gesucht.
- den Graphen um diese Links erweitert.
- den Graphen in Rhapsody (Modellierungstool von IBM) mittels Java API importiert.
- den Graphen in neo4j importiert.
Lessons learned
Für uns war die Haupterkenntnis in dem Projekt: Auch Requirements sind Daten!
Zudem ist die Größe der Systemliste, die auch als Management-Werkzeug benutzt wird, beeindruckend. Würde man sie von DOORS in Excel exportieren und ausdrucken, so wäre sie so groß wie ein Fußballfeld (neben logischen Systemen und Funktionen enthält sie auch die technischen Komponenten). Management-Werkzeug bedeutet, dass in der Liste neben Abhängigkeiten auch die Verantwortlichkeiten abgestimmt werden. Diese Personen haben wir in den Graphen eingepflegt und konnten somit in neo4j die Kommunikationswege des Konzerns visualisieren. Dies war sehr beeindruckend!
Außerdem können wir mit den Graphalgorithmen von neo4j spannende Analysen durchführen. Daraus sollte sich bestimmt Optimierungspotential zum Aufbau der Systeme und deren Kommunikation aufdecken lassen. Mal schauen, ob wir in einem Folgeprojekt daran arbeiten dürfen. Wir bleiben auf jedem Fall am Ball.
Author
Twitter Facebook XING