Gegenstand dieses Kapitels ist die Überprüfung des Automotive-Spice-Referenzprozesses 3.1 anhand der erarbeiteten Anforderungen (vgl. Kapitel 4.3), um eine Eignung der dort aufgeführten Prozesse zu bewerten. Hierzu werden in Abschnitt 4.4.1 den Anforderungen passende Prozesse des Referenzmodells zugeordnet und detailliert erläutert. Eine Zusammenfassung ist in der Tabelle 4 im Ergebnisabschnitt 4.4.2 zu finden.

Prozessanalyse der Automotive SPICE anhand der Anforderungen

Anhand der erarbeiteten Anforderungen aus Abschnitt 4.3 werden die einzelnen Prozesse des Referenzprozesses aSPICE den resultierenden Anforderungen zur Überprüfung gegenübergestellt. Zu Beginn jeder Anforderungsgruppe sind die einzelnen Anforderungen der passenden Prozess-ID473 aus der aSPICE zugeordnet.

A1) Anforderungserhebung und Analyse

A1.1: SYS.1, SYS.2; A1.2: D.1; A1.3: SUP.8, SUP.10

Die Anforderung A1.1 dient dem Zweck der gemeinsamen Gestaltung der Systemarchitektur unter Einbeziehung des Geschäftsmodells und adressiert somit die Systemebene. Zunächst werden im Prozess SYS.1 Anforderungen der Stakeholder über den gesamten Produktlebenszyklus des Produkts und/oder der Dienstleistung erhoben. Darüber hinaus hat der Prozess SYS.2 „System Requirements Analysis“ das Ziel Stakeholder-Anforderungen zu analysieren, um dann Systemanforderungen an die Systemarchitektur abzuleiten. Legt man dies weit aus, werden Kunden und Akteure, die zur Generierung des Leistungsversprechens und somit zur Architektur des Geschäftsmodells gehören, einbezogen. Eine explizite Analyse des Geschäftsmodells ist nicht aufgeführt. Die „Base practices“ SYS.2.BP3 und BP4 verlangen in diesem Kontext die Analyse von Kosten und Schnittstellen des Systems. Dennoch ist ein direktes Berücksichtigen oder Modellieren des Geschäftsmodells nicht vorgesehen. Die Entwicklung eines Produkt-Service-Systems wird von der Entwicklung und Gestaltung der Dienstleistungen geprägt . Abhängig vom Dienstleistungsanteil sind entsprechende fachspezifische Prozesse (Domain level) für die Entwicklung des Systems notwendig, dies verlangt Anforderung 1.2. Die aSPICE sieht ein Plugin-in-Konzept für das domänenspezifische Entwickeln vor (siehe Abschnitt 4.2).474 Demnach können Systemkomponenten nach der Systemarchitektur zur Entwicklung an ein servicespezifisches „V“ gereicht werden. Zur dynamischen Verwaltung von Anforderungen (A1.3) sind Ansätze im Unterstützungsprozess SUP.10 „Change Request Management“ vorhanden. Dieser verwaltet alle Änderungsanforderungen gemäß einer Änderungsstrategie und sorgt für die Analyse der Auswirkungen einer Änderung und für Rückverfolgbarkeit. Der Konfigurationsmanagementprozess SUP.8 unterstützt den Umgang mit Produkt- und Softwarevarianten und verwaltet diese.475 Zur Erfüllung der Anforderung A1.3 müssen diese Prozesse erweitert und dynamisch gestaltet werden.

A2) Systemarchitektur

 A2.1: SYS.2, SYS.3; A2.2: SYS.2, SYS.3

Im Prozessgebiet „System Engineering“ finden sich zwei Prozesse auf Systemebene wieder, welche die Anforderung A2.1 berücksichtigen. Im Prozess SYS.2 „System Requirements Analysis“ werden die Systemanforderungen des SUD analysiert, um im nächsten Schritt daraus ein Systemarchitekturdesign abzuleiten. Im Prozess SYS.2.BP4 „Analyze the impact on the operating environment “ werden das Systemumfeld, Schnittstellen und das Betriebsumfeld analysiert. Hier kann das Ergebnis der Umfeldanalyse eine weitere Abstraktionsebene mit eigenem Systemkontext sein, da eine Sicht der Systemauswirkungen außerhalb der Systemgrenzen, also der Systemumgebung eingenommen wird.476

 Des Weiteren wird im Prozess SYS.3 „System Architectural Design“ die Systemarchitektur entsprechend den Systemanforderungen entworfen und bewertet. Der Prozess hat u.a. als Ergebnis, dass alle Komponenten, also auch andere System(ebenen) definiert werden können. Verschiedene Basispraktiken wie SYS.3.BP3 definieren und legen Schnittstellen zwischen Elementen fest. Die Basispraktik SYS.3.BP8 gibt die Möglichkeit der mehrstufigen Systemsicht in dem Sinne, dass Elemente weitere Subsysteme darstellen können. Jedoch existieren keine Basisanforderungen, die eine direkte hierarchische Systemsicht unterstützen.

Die Anforderung A2.2 adressiert die Systemarchitektur in den Prozessen SYS.2 und SYS.3. Anforderungen, die sich auf eine IT-Infrastruktur beziehen, können im Prozess SYS.2 als Systemumfeld mit Schnittstellen betrachtet werden. Durch die Basisprakt ik SYS.2.BP4 wird die Auswirkung der Systemanforderungen auf Schnittstellen und Komponenten der Betriebsumgebung analysiert und definiert. Auf der Architekturebene im Prozess SYS.3.BP3 werden alle Schnittstellen von Systemkomponenten definiert.477 Allerdings bestehen hier keine Hinweise zu dynamischen Systemkomponenten bzw. Systemgrenzen.

A3) Datenmanagement

A3.1:Man.6; A3.2: REU.2; A3.3: –

Das Referenzmodell berücksichtigt den Produktlebenszyklus mit umfassenden Prozesskategorien (siehe Abschnitt 4.2). Die Prozesse wie der „Measurement“-Prozess, das „Reuse Programm Management“ oder das „Configuration Management“ sind zwar aufgeführt, aber in keiner gemeinsamen Lösung integriert. Ein Integrationsansatz ist lediglich in Form von SUP.8.BP7 erwähnt: „Aufzeichnen und Berichten des Status von Konfigurationskomponenten zur Unterstützung des Projektmanagements und anderer relevanter Prozesse“. Die geforderte ganzheitliche PLM-Lösung mit integriertem konsistenten Datenmanagement zur Felddaten-Verwaltung wird von der aSPICE nicht abgedeckt. Der Prozess „Measurement“ (MAN.6) dient als Datensammel- und Analyseprozess, ist jedoch auf Produkt- und Prozessdaten innerhalb des Unternehmens begrenzt und somit nur eingeschränkt nutzbar.478

Die Anforderung A3.2 fordert das Einpflegen, Verwalten und Bereitstellen von modularen Entwicklungsartefakten. Der Referenzprozesses „Reuse Programm Management “ (REU.2) sorgt für das systematische Planen, Verwalten und Überwachen von Wiederverwendungsmöglichkeiten und kommt somit der Anforderung nach. Die Prozesse „Base practices“ BP1 und BP7 sorgen für die Definition einer Wiederverwendungsstrategie und von Benachrichtigungsmechanismen zwischen den betroffenen Parteien.479

Für die Anforderung A3.3 zur Verwendung eines digitalen Zwillings für Produkt-Rekonfiguration werden keine entsprechenden Prozesse vorgesehen. Das vorhandene Change Request Management SUP.10 und der Konfigurationsmanagementprozess SUP.8 weisen erste Ansätze für eine Rekonfiguration auf, müssen aber entsprechend der notwendigen Voraussetzungen eines digitalen Zwillings ausgebaut werden. Prozessbeschreibungen wie auszugsweise SUP.8.BP9 („Verwaltung der Speicherung von Konfigurationsobjekt en zur Sicherstellung der Integrität und Verfügbarkeit “) können sinnvoll ausgebaut werden, um eine Rekonfiguration zu ermöglichen.

Zusammenfassung der Analyse und Bewertung

Die Analyse des Referenzprozessmodells mit den gestellten Anforderungen aus Abschnitt 4.3 führt zu folgenden Bewertungen, die in Tabelle 4 zusammengefasst sind.  

A1) Anforderungserhebung und Analyse

A1.1) Das Einbeziehen des Geschäftsmodells und die Zusammenhänge des Modells werden nur unzureichend in die Anforderungserhebung und -analyse einbezogen. Die System- Anforderungsanalyse der aSPICE geht zwar auf Stakeholder, Kunden und Akteure ein, erwähnt aber nicht explizit eine Betrachtung bzw. Modellierung des Geschäftsmodells. Der stärker werdende Servicebezug ist somit nicht abgedeckt.

A1.2) Das Erweitern des V-Modells durch eine eigene Service-Domäne wird durch ein Plug-in-Konzept der aSPICE abgedeckt. Anforderungen können an entsprechende domänenspezifische Prozesse, nach dem integrierten Systementwurf, an Service-Komponenten abgegeben und weiter spezifiziert werden.

A1.3) Dynamische Änderungen von Anforderungen: Keine der aufgeführten Prozesse sieht eine dynamische Änderung während der Produktnutzungsphase vor. Die in der aSPICE beschriebenen Prozesse beziehen sich nur auf die Produktentwicklung. Es sind detaillierte Änderungs- und Konfigurationsmanagement-Prozesse vorhanden und diese könnten entsprechend erweitert werden.

A2) Systemarchitektur

A2.1) Modellieren auf mehreren Abstraktionsebenen: Das Modellieren auf verschiedenen hierarchischen Abstraktionsebenen auf „System level“ wird von dem Referenzprozessmodell ermöglicht, muss aber noch weiter unterstützt werden.

A2.2) Anforderungen an die IT-Infrastruktur: Die aufgeführten Prozesse beziehen zwar die Analyse von Schnittstellen und das Systemumfeld ein, unterstützen aber kein direktes Einbeziehen einer IT-Infrastruktur. Somit kommt die aSPICE der Anforderung nicht nach.

A3) Datenmanagement

A3.1) Management von Felddaten: Die Anforderung nach einer integrierten Verwaltung und nach Bereitstellung von Felddaten für Entwicklungszwecke wird in keiner der betrachteten Prozesse erwähnt. Ein Datensammel- und Analyseprozess für interne Produkt- und Prozessdaten ist vorhanden.

A3.2) Management der Wiederverwendung: Ein Wiederverwendungsprozess ist vollständig beschrieben und wird der Anforderung gerecht. Eine stärker ausgeprägte Wiederverwendungsstrategie ist zukünftig zu erwarten.

 A3.3) Management der Produkt-Rekonfiguration: Die Anforderung nach einer Verwendung eines digitalen Zwillings setzt eine integrierte Produktdatenverwaltung voraus. Die in der aSPICE vorhandenen Ansätze sind im Rahmen einer Produkt-Rekonfiguration weiter auszugestalten.

Nicht alle der gestellten Anforderungen werden vom Referenzprozessmodell Automotive SPICE 3.1 erfüllt. Besonders deutlich ist der Mangel an Prozessinformationen über das Verwalten von Entwicklungsdaten, insbesondere Felddaten. Des Weiteren deckt das Referenzprozessmodell keine Prozesse zur integrierten Entwicklung von Dienstleistungen ab. Viele Prozesse sind vorhanden, beschreiben aber nur Teilaspekte wie zum Beispiel das Änderungs- und Konfigurationsmanagement. Hier besteht noch Handlungsbedarf, um den beschriebenen Auswirkungen der Digitalisierung gerecht zu werden.