Finden statt Suchen – ein Artefakt-basierter Approach zum Management von Engineeringdaten

Teil 1: Der Konflikt zwischen Vollständigkeit und Granularität

Für den Erfolg eines Entwicklungsprojektes mag die Speicherung von Entwicklungsdaten auf den ersten Blick deutlich weniger relevant sein als beispielsweise die Methodik oder die eingesetzten Tools. Tatsächlich hat jedoch die Art und Weise, wie Entwicklungsdaten abgelegt, verwaltet, strukturiert und wiedergefunden werden, erhebliche Auswirkungen auf viele Kenngrößen Ihrer Projekte. Schwächen in diesem Bereich beeinflussen unmittelbar unter anderem die Projektlaufzeit, die Wiederverwendbarkeit von Modulen, die Kommunikation und mittelbar die Qualität und die Kundenzufriedenheit. Nicht zuletzt wird auch die Adaption von Konzepten wie Agile, Digital Thread, Continuous Integration, etc. erschwert oder gar verhindert durch unzureichendes Management der Entwicklungsartefakte.

Speicherung in Dokumentenstrukturen – traditionell das Mittel der Wahl …

Diese Situation hat ganz praktische historische Ursachen: bei den frühen Entwicklungstools stand zunächst im Vordergrund, die Arbeit der Entwickler bei Entwurf und Implementierung zu unterstützen. Engineeringdaten bestanden im Wesentlichen aus Source Code, und andere Artefakte wie Architekturdarstellungen, Flussdiagramme oder auch Testergebnisse existierten parallel und oft in nicht maschinenlesbarer Form. Mit dem Entstehen weiterer spezialisierter Tools wurden die vorher auf Papier existierenden Diagramme, Texte und Daten oft einfach in Dokumentendateien elektronisch abgelegt, mit Strukturen analog zur Papierbasierten „Speicherung“, wie Kapitel und Unterkapitel.

Der Vorteil dieser Herangehensweise liegt auf der Hand: alle Daten, die zu einer Phase im Projekt gehören, sind zusammenhängend abgelegt und als Ganzes zugänglich, einzelne Elemente werden im Kontext aller Elemente dieser Phase gesehen und verstanden. Das Prinzip der Vollständigkeit ist phasenbezogen umfassend umgesetzt.

Der Nachteil liest sich fast genauso: alle Daten, die zu einer Phase im Projekt gehören, sind zusammenhängend abgelegt und NUR als Ganzes zugänglich, einzelne Elemente können AUSSCHLIESSLICH im Kontext aller Elemente dieser EINEN Phase gesehen werden. Ein Zusammenhang einzelner Daten mit korrespondierenden Daten anderer Phasen lässt sich nur manuell herstellen, mit mehr oder weniger geeigneten Mitteln.

… welches heute an seine Grenzen stößt

Betrachten wir ein (stark vereinfachtes) Beispiel aus der Automobilindustrie:

1. Kundenanforderung: Das Abblendlicht soll sich bei Dämmerung automatisch einschalten.
2. Systemanforderung: Ein Dämmerungssensor gibt bei eintretender Dunkelheit ein Signal an die Lichtsteuerung zum Einschalten des Abblendlichtes.
3. Systemspezifikation: Der Dämmerungssensor hat die Spezifikation xy und die Schnittstelle yz. Die Eingangsschnittstelle der Lichtsteuerung ist kompatibel mit der Schnittstelle yz (so dass sie das Signal des Sensors versteht).
4. Softwaredesign: Die Lichtsteuerung nimmt das Signal des Sensors entgegen (Ereignisgesteuert) und schaltet das Licht ein. (Alternativ: Lichtsteuerung fragt zyklisch den Sensor ab).
5. Modultest: Die Lichtsteuerung wird mit einem simulierten Sensorsignal stimuliert und die Generierung des Ausgangssignals wird überprüft.
6. Systemtest: Sensor und Lichtsteuerung generieren bei Dunkelheit das Ausgangssignal.
7. Integrationstest: Sensor und Lichtsteuerung schalten bei Dunkelheit das Abblendlicht ein.

Traditionell wurden alle Kundenanforderungen für das gesamte Fahrzeug in einem Dokument abgelegt, alle Systemanforderungen in einem anderen Dokument, etc.. Wenn man nun herausfinden möchte, wie die durchgängige Kette von Informationselementen aussieht, die am Ende dafür sorgt, dass bei Dunkelheit das Abblendlicht eingeschaltet wird, muss man in diesem Beispiel 7 verschiedene Quellen durchsuchen, um das jeweils passende granulare Element unter allen phasenbezogenen Informationen für das komplette Fahrzeug zu finden. Um diese Granularität auf der Ebene einer „Wirkkette“ zu managen, wird oft eine weitere Informationsquelle generiert. Dies geschieht oftmals in Form von Tabellen, die im Falle von Änderungen nur mühsam auf dem aktuellen Stand gehalten werden können. Ungelöst bleibt dabei die Frage, wie dieser Tabellenmechanismus bei der Entwicklung von Produktvarianten oder neuen Versionen sinnvoll skaliert werden kann.

Ausblick auf Teil 2

Im zweiten Teil dieses Artikels skizzieren wir einen beliebig skalierbaren Lösungsansatz für die Speicherung von Engineeringdaten – stay tuned! Und falls Sie bereits vorher tiefer in dieses Thema eintauchen möchten: hier finden Sie weitere Informationen dazu.