Kann man ASPICE effizient und praktikabel umsetzen? Wir behaupten: Ja.

Prozesse machen den Unterschied! Das gilt auch für die Entstehung von Software. Vor allem für Software – denn im Gegensatz zu „anfassbaren“ Produkten, kann die Qualität von Software nicht im Nachhinein bewertet werden. Mobilität ist in nächster Zukunft ohne Software nicht vorstellbar. Software sorgt für mehr Komfort, mehr Sicherheit und für die Steuerung des Antriebs im Fahrzeug. Die zunehmende Vernetzung und der zunehmende Automatisierungsgrad erhöhen die Komplexität der umgesetzten Softwarefunktionen. Um diese Komplexität in der Entwicklung zu beherrschen, sind stabile Prozesse essenziell. Prozesse schaffen die Voraussetzung für die Zusammenarbeit über Unternehmensgrenzen hinweg, in internationalen Teams und in Remote Teams (Entwickeln aus dem Home-Office). ASPICE bietet einen Rahmen, um die eigenen Prozesse zu definieren und deren Umsetzung in Projekten zu bewerten.

Um die Entwicklungsprozesse und die Qualität der Software besser beurteilen zu können, einigten sich mehrere, vorrangig deutsche Automobilhersteller auf ein Prozessreferenzmodell für die Softwareentwicklung und veröffentlichten 2005 erstmals den Standard Automotive SPICE® (kurz: ASPICE). Abgeleitet von dem internationalen Standard ISO 15504 für die Bewertung von Softwareprozessen, wurde ein branchenspezifischer Rahmen geschaffen, um Best Practices zu bündeln und eine Vergleichbarkeit von Projekten, unternehmensübergreifend, zu ermöglichen.

Dabei beschränkt sich ASPICE nicht nur auf Vorgaben an den Softwareentwicklungsprozess, sondern macht unter anderem auch Vorgaben an das Projektmanagement, die Unterstützungsprozesse wie Qualitätsmanagement, Problemlösungs-, Änderungsmanagement sowie an das Konfigurationsmanagement.

Der Level sagt, wie „gut“ die Prozesse umgesetzt sind.

Im Mai 2020 hat der Bereich EDAG Embedded Systems, Teil des Business Segments EDAG Electronics, einen wichtigen Meilenstein seiner Prozessentwicklung erreicht: den Nachweis nach ASPICE Level 2 entwickeln zu können. Im Rahmen eines Kunden-Projektes wurde in einem unabhängigen ASPICE Assessment durchgängig, für jeden betrachteten Prozess, die Reife Level 2 bestätigt. Bewertet wurden alle Software-Engineering-Prozesse, die Unterstützungsprozesse des VDA-Scopes, der Requirements Elicitation Prozess und der Project Management-Prozess. Doch was bedeutet eigentlich Level 2 und was war nötig, um diesen zu erreichen?

Die „Capability Level“ in Automotive SPICE® repräsentieren die Reife eines Prozesses: 

• Level 0: Der Prozess ist unvollständig, ungeeignet oder existieren nicht.
• Level 1: Die Resultate des Prozesses liegen vor, es kann aber nicht nachvollzogen werden, wie die Ergebnisse entstanden sind.
• Level 2: Der Prozess ist geplant, überwacht und dokumentiert. Die Verantwortlichkeiten im Projekt sind nachvollziehbar.
• Level 3: Ein generischer Standardprozess ist beschrieben, der mit leichten Anpassungen (Tailoring) für jedes Projekt Anwendung findet. Die Projekte arbeiten einheitlich.

ASPICE beschreibt zwei weitere Level, Level 4 und Level 5, die jedoch derzeit in der Praxis (noch) eine untergeordnete Rolle spielen. Unsere Erfahrung zeigt, dass in den meisten Fällen ASPICE Level 2 gefordert wird, aber nur wenige Projekte heute durchgängig, in jedem betrachteten Prozess, den Level 2 nachweisen können.

Für den Level 2 fordert ASPICE grundsätzlich, dass ein Prozess „gemanaged“ ist: Das bedeutet die Abläufe sind nachweislich geplant, sie werden überwacht und bei Bedarf korrigiert. Die Arbeitsergebnisse müssen angemessen erstellt, kontrolliert und gepflegt werden. Alle Prozessschritte müssen dokumentiert werden, um sie (auch gegenüber einem Außenstehenden wie beispielsweise einem Assessor) nachvollziehbar zu machen.

Was sich hier vielleicht trivial anhört, ist in einem Softwareentwicklungsprojekt nur mit einem tiefen Verständnis der benötigten Abläufe und hoher Disziplin bei der täglichen Umsetzung erreichbar. Beispielsweise müssen Aufwände täglich und von jedem Mitarbeiter erfasst werden, jede Änderung an einem Arbeitsergebnis muss dokumentiert werden (wer, hat was, wann geändert), die Konsistenz zwischen den Dokumenten und über Tools hinweg sowie eine tagesaktuelle Planung der Aufgaben müssen sichergestellt werden. Es muss gewährleistet sein, dass das Team groß genug und ausreichend qualifiziert ist, um mit den jeweiligen Aufgaben beauftragt zu werden – und, sollten notwendige Qualifikationen fehlen, Qualifikationsmaßnahmen geplant und durchgeführt werden. Dies erfordert in der Regel mehrere Jahre „Prozessarbeit“, um die nötige Reife in einer Organisation zu entwickeln.

Gegenstand des assessierten Projektes war die Entwicklung einer Software für einen deutschen Premium-Autohersteller. Die Software steuert die Hochvolt-Komponenten des Fahrzeugs für verschiedene Betriebszustände, einschließlich der diagnostischen Überwachung des Hochvolt-Systems und der Fehlerreaktionen. Sie wird modellbasiert und handcodiert entwickelt, vollumfänglich innerhalb der EDAG Prozesse und Toolkette.

Was war nötig, um diese Prozessreife im Projekt zu erreichen?

Entscheidend war oft die Interpretation des ASPICE Standards: Was bedeutet die jeweilige Vorgabe und wie kann sie im Projektalltag umgesetzt werden? ASPICE stellt zwar die richtigen Fragen, jedoch können die Vorgaben auf unterschiedlichste Art gelöst werden.

Das Projektteam war nicht auf sich alleine gestellt, sondern wurde von Projektbeginn an durch ein bestehendes Prozessteam – quasi im Tandem – unterstützt, durch Coachings und als Ansprechpartner bei Fragen. Die Aufgabe des Prozessteams bestand auch in einem regelmäßigen Abgleich des Projektgeschehens mit den ASPICE Vorgaben, um dem Projektteam die Lücken und notwendige Maßnahmen aufzuzeigen.

Zudem hat das Projekt nicht bei „0“ angefangen. Seit 2014 wird sukzessive das Know-How in der Organisation in einem Serien-Entwicklungs-Prozess festgehalten. Ein Prozessteam, bestehend aus Prozesseignern, Prozessmodellierer und einem Prozessmanager, entwickelt den Prozess fortlaufend, auch mit externer Unterstützung in Form eines erfahrenen ASPICE Consultants. Für jeden Prozess ist ein Prozesseigner benannt, der die Aufgabe hat, das Wissen in der Organisation in einer Prozessbeschreibung zu bündeln und „seinen“ Prozess fortlaufend weiterzuentwickeln. Für die Prozessbeschreibung und Verteilung nutzen wir das Prozesstool Stages V7 von Methodpark. Dieser generische Prozess war die Grundlage für das assessierte Projekt.

Eine dritte Säule stellt die Tool-Unterstützung dar. Die tooltechnische Umsetzung der Prozesse wurde von den Assessoren besonders hervorgehoben, weil Abläufe und ASPICE Vorgaben automatisiert werden konnten. Die Planung, Zuweisung und Nachverfolgung der Aufgaben erfolgt ticketbasiert. Im Zentrum der Toolkette stehen die Atlassian Tools Jira und Confluence, mit entsprechenden Apps für das Anforderungsmanagement und die Testspezifikation. Für die modellbasierte Softwareentwicklung kommen Matlab/Simulink und TargetLink zum Einsatz. Das Versionsmanagement für die Software erfolgt über die Open Source Software GitLab. Die Toolkette wird ebenfalls parallel zum Prozess über die Projekte hinweg weiterentwickelt.

Das Ziel bei der Gestaltung der Prozesse war immer: Es muss dem Team, dem Kunden oder der Organisation einen Nutzen bringen. Nicht wertschöpfende „Prozessbefriedigung“ konnte so vermieden werden.

Es kommt auf das Zusammenspiel der einzelnen Akteure an. Jedes Release wurde bezüglich Inhalt und Termine mit dem Kunden und dem Projektteam abgestimmt, koordiniert durch den Projektleiter. Darauf aufbauend wurden die Aufgaben geplant und nach Priorität in zweiwöchigen Sprints abgearbeitet. Regelmäßig, alle paar Wochen, erfolgt eine Software-Lieferung an den Kunden. So kann dieser früh die Software im Fahrzeug testen und Feedback geben. Der Kunde muss seinen Beitrag leisten, indem er rechtzeitig zu Beginn einer jeden Release-Phase reife und freigegebene Anforderungen übergibt.

Was haben wir daraus gelernt?

Das Projektteam wurde nach dem Assessment gefragt, was sie jetzt, nach dem Assessment, weglassen würden. Auch die eher pragmatisch vorgehenden Mitarbeiter sagten: „Nichts“. Es könnte kein besseres Feedback geben! Die Maßnahmen zur Etablierung der ASPICE Prozessvorgaben konnten also für das Projektteam einen Nutzen schaffen. Und die Mannschaft steht hinter den eingeführten Prozessen.

Das sind unsere Erkenntnisse aus unserem Weg zu ASPICE Level 2:

• Durchgängig Level 2 erreicht ein Projekt nicht ad hoc. Die Organisation muss sich über Jahre hinweg (wir schätzen mindestens 2 Jahre) intensiv und ernsthaft mit ihren Entwicklungsprozessen auseinandersetzen.
• ASPICE Vorgaben kann man praktikabel umsetzen - ohne Formalismus, ohne „Prozessbefriedigung“.
• Die Automatisierung der Prozesse ist ein Schlüssel für Effizienz und Reduzierung der Komplexität.
• Akzeptierte Prozesse kommen aus der Praxis und sind auf das Wesentliche reduziert.
• Kurze Iterationen. Kleine „V-Zyklen“, z.B. alle 2 Wochen, bieten die Möglichkeit, den Fortschritt genau zu verfolgen und Korrekturbedarfe früh zu erkennen.
• ASPICE und agile Entwicklung schließen sich nicht aus.
• Nicht nur die funktionalen, auch die nicht-funktionalen Anforderungen müssen von Anfang an bewertet und in Maßnahmen überführt werden.

Als Erfolgsfaktoren sehen wir an:

• Im Projektteam wird ein grundlegendes Prozessverständnis geschaffen, beispielsweise durch Coaching oder Schulungen.
• Ein präziser Projektauftrag bildet den Aufsetzpunkt für die Planung im Projekt.
• Die ASPICE Vorgaben werden immer mit Blick auf den Kundennutzen und praktische Umsetzbarkeit interpretiert.
• Das Ziel „ASPICE Level 2“ ist in den internen Zielvorgaben verankert.
• Das Management steht nicht nur dahinter, sondern fordert Nachweise aktiv ein.
• Vor Beginn jeder Release-Phase einigen sich die Stakeholder verbindlich auf die umzusetzenden Anforderungen.

Fazit

Die durchgängige Bewertung aller betrachteten Prozesse mit Level 2 sehen wir als große Auszeichnung für unser Projektteam, dass die Prozessthemen nicht nur mitgetragen, sondern auch weiterentwickelt hat und als Bestätigung, dass wir mit unseren früh begonnen Bestrebungen für gute Entwicklungsprozesse auf dem richtigen Weg sind. Für uns als Organisation ist der „Next Step“ die Etablierung des ASPICE Level 2 in allen Serienprojekten, sowie der Nachweis von ASPICE Level 3 (was Dank des generisch beschriebenen Serien-Entwicklungs-Prozesses keine große Hürde mehr darstellt).

Die Automobilindustrie befindet sich im grundlegenden Wandel, getrieben durch veränderte Kundenerwartungen, Elektrifizierung des Antriebs und Digitalisierung. Die Lösungen basieren zunehmend auf Software, was sich auf den gesamten Entwicklungsprozess auswirkt. Die Prozesse müssen der Dynamik dieser Transformation folgen und sie sogar mitgestalten.

ASPICE ist für uns kein Zukunftsthema – aber ein Thema mit Zukunft. Die Zunahme der Komplexität in der Automobilentwicklung ist nur mit guten Prozessen zu bewältigen. EDAG Embedded Systems setzt auf eine prozessorientierte Arbeitsweise und auf eine fortlaufende Anpassung und Weiterentwicklung der Entwicklungsabläufe.

Unser Motto lautet daher: Better Process. Better Projects.

Alin Javorsky, Process Manager Embedded Systems, ist zuständig für die fortlaufende Optimierung der Engineering- und Projektmanagement-Abläufe und deren Vereinheitlichung über die Standorte des Bereiches hinweg. Er kann Ihnen genauere Einblicke in die Herangehensweise von EDAG Embedded Systems bei ASPICE Projekte geben. Oder laden Sie unsere Checkliste herunter. Sie liefert Ihnen das nötige Grundgerüst, mit dem Sie in einem entsprechenden Assessment den Nachweis erbringen, dass Sie Ihre Prozesse gemäß Capability-Level 2 umsetzen.