Im zweiten Teil unserer Artikelserie rund um Automotive SPICE möchten wir einen weiteren Mythos aufdecken. Es handelt sich um die Annahme, dass Prozessgruppen in Automotive SPICE 1:1 den Architekturebenen des Systems of Interest entsprechen.

In unseren Kundenprojekten erleben wir immer wieder, dass die Prozessgruppen in Automotive SPICE direkt den verschiedenen Architekturebenen des Systems of Interest zugeordnet werden. Demnach würde jeder Prozess im Rahmen der Systementwicklung nur genau einmal durchlaufen werden (siehe Abbildung 1), abgesehen von Iterationen für das gesamte System of Interest. Das Problem hierbei ist, dass es in der Realität aufgrund der umfangreichen Systeme häufig mehr als eine System- und eine Softwareebene gibt, entlang dieser Ebenen Verantwortlichkeiten verteilt werden und das Zusammenarbeitsmodell wesentlich durch die Architektur bestimmt wird.

Trotz dieser Komplexität des System of Interest werden die Prozesse trotzdem nur einmal durchlaufen. Entscheidend ist die Frage, ob sich diese Komplexität mit einem einmaligen Durchlauf hinreichend beherrschen lässt.
Hierbei handelt es sich um ein klassisches Beispiel von einem „roten Problem“, das eben durch einen „roten Anteil“, also das Verständnis von Projektbeteiligten gegenüber dem System of Interest, gelöst werden muss.
Falls Ihnen die Definitionen von „blau“ und „rot“ noch nicht bekannt sind, dann lesen Sie gerne unseren Teil 1 der A SPICE Blogserie: A SPICE löst Probleme in der Entwicklung.

In der folgenden Abbildung sind die Prozessgruppen in Automotive SPICE im Überblick dargestellt:

Tatsächlich spiegelt Automotive SPICE nicht direkt die Architekturebenen eines Systems wider. Dieser Standard wurde entwickelt, um die Prozessqualität und -reife zu bewerten und nicht um die technische Architektur eines Produkts oder Systems zu definieren. Die Prozessgruppen in Automotive SPICE sind kategorische Einordnungen von Prozessen, die bestimmte Aktivitäten innerhalb der System- und Softwareentwicklung zusammenfassen.

Zum Beispiel beschreibt die Prozessgruppe „Systementwicklung (SYS)“, die Prozesse wie „Requirements Elicitation (SYS.1)“ und „System Architectural Design (SYS.3)“ beinhaltet, aber nicht zwangsläufig alle Architekturebenen eines Systems, sondern grenzt Tätigkeiten einer Systementwicklung von Tätigkeiten einer Softwareentwicklung ab.

Anstelle einer prozesszentrierten Sicht sollten wir beachten, welche Architekturebenen notwendig sind, um die Komplexität des System of Interest beherrschbar zu machen. Abbildung 2 zeigt anhand des Twin-Peaks-Modells [3] eine typische Architektur mit den 3 Ebenen System, Subsystem und Komponente. Nach Automotive SPICE gibt es keine eigenständige Prozessgruppe und Prozesse für Tätigkeiten innerhalb der Subsystemebene und dennoch kann es erforderlich sein, Anforderungen an die Subsysteme zu analysieren, Architekturen für diese zu erzeugen und die Subsysteme vor einer Gesamtintegration zu testen. Damit diese Tätigkeiten prozessual ausreichend gewürdigt werden, empfiehlt es sich, Prozesse aus der Prozessgruppe „Systementwicklung“, ggf. in angepasster Form, erneut innerhalb der Subsystemebene anzuwenden. Wichtig ist, die Prozesse nicht als Dogma zu verstehen, sondern sich bewusst aufgrund der im Unternehmen vorliegenden Rahmenbedingungen zu überlegen, welche Prozesse der Systementwicklung in welcher Ausprägung zur Anwendung kommen sollen.

Im Kontext der Systementwicklung müsste betont werden, dass das Hauptziel eines Unternehmens nicht ausschließlich die Anwendung von Automotive SPICE ist, sondern die Entwicklung des Produkts selbst. Während Automotive SPICE hilfreich ist, um Entwicklungsprozesse zu strukturieren, sollte es nicht als Maßstab für die technische Auslegung des Produkts gesehen werden. Basierend auf der spezifischen Produktstruktur und den unternehmensinternen Rahmenbedingungen sollte sorgfältig überlegt werden, ob und in welchem Umfang Automotive SPICE-Prozesse angewendet werden sollen. Ein umfassendes Verständnis dieser Prozesse ermöglicht es, sie im richtigen Kontext und zum Vorteil des Produktentwicklungsprozesses zu nutzen.

Nicht zu unterschätzen ist, dass Unternehmen und Entwicklerteams die wirkliche Intention hinter Automotive SPICE verstehen und Mythen wie diesen entlarven. Die Prozessgruppen sind keine Blaupause für Systemarchitekturen. Stattdessen bieten sie einen Rahmen, um Prozesse zu verbessern und sicherzustellen, dass Systeme die höchstmöglichen Qualitätsstandards erfüllen.

Wenn Sie Hilfe brauchen beim Adaptieren von ASPICE auf Ihren Kontext, helfen wir Ihnen gerne!

Quellen:

[1] Abbildung: „Prozessreferenzen“ – Auszug aus dem Automotive Spice 3.1: https://www.automotivespice.com/fileadmin/software-download/AutomotiveSPICE_PAM_31.pdf

[2] Abbildung „Twin-Peaks-Modell“: SOPHIST GmbH

[3] Nuseibeh, B.: Weaving the Software Development Process; Between Requirements and Architectures (2001), URL: https://www.semanticscholar.org/, letzter Zugriff: Januar 2020