In den folgenden Kapiteln möchte ich auf das Thema Automotive SPICE (ASPICE) eingehen und dieses Thema näher erläutern.
Inhaltsverzeichnis
Für wen ist dieser Artikel?
| Ziel des Artikels: | Einführung in Automotive SPICE (ASPICE) |
| Artikelzielgruppe: | Interessenten aus der Automotive-Welt, die den ASPICE-Standard kennenlernen möchten. |
| Sprache: | technisch und Automotive mit vielen spezifischen Begriffen |
| Empfohlene Vorkenntnisse: | ASPICE, Automotive-Umfeld, Englisch |
| Hilfsmittel: | Vokabular, Automotive-Prozesse, *1) |
| Lesedauer: | ca. 15 Minuten |
*1) Um Grafiken zu vergrößern, benutzen Sie die rechte Maustaste und die Option: “Bild in neuem Tab öffnen”.
Einführung
Da aktuelle Automotive-Projekte komplex und aufwendig sind, insbesondere in Bereichen von autonomem Fahren, Fahrerassistenz und Elektroantrieben, müssen die Projekte bestimmte Anforderungen bezüglich Entwicklungsprozessen erfüllen. Der Standard ASPICE gibt die Vorgaben für die Bewertung und Verbesserung der Softwareentwicklungsprozesse vor.
In den folgenden Abschnitten wird die ASPICE Standard-Versionen 3.1 und 4.0 erklärt und ein Weg erläutert, wie man einen ASPICE Level 2 in der Projektprozesslandschaft erreichen kann.
Was ist Automotive SPICE (ASPICE)?
Das Automotive SPICE ist ein Modell für das Prozess-Assessment, das auf einem Standard ISO/IEC 15504 (SPICE – Software Process Improvement und Capability Determination) basiert und in modernen Automotive-Projekten und Unternehmen hilft, Aussage über die Reife der Entwicklungsprozesse zu treffen und anschließend diese Prozesse zu verbessern. Automotive SPICE dient als Rahmenwerk für die ständige Bewertung und Optimierung von internen Entwicklungsprozessen und erhöht die Qualität der Arbeitsprodukte, welche an Kunden geliefert werden, erheblich.
Ein weiteres Argument für die Implementierung der im ASPICE-Standard vorhandenen Anforderungen ist die Effizienzsteigerung und schonendes Umgehen mit Ressourcen während der Entwicklung. Im Absatz unten gibt es weitere Ziele für die Implementierung des ASPICE-Standards.
Ziele vom ASPICE
| Ziele vom ASPICE-Standard: | Beschreibung: |
| Qualitätssteigerung | – erhebliche Verbesserung der Produktqualität durch detaillierte, gut durchdachte, strukturierte Prozesse (im besten Fall unternehmensübergreifend) |
| Risikominimierung | – Reduzierung von Risiken im Projekt durch definierte und kontrollierte Prozessüberwachung |
| Effizienz | – klare Zuordnung von Rollen und Verantwortlichkeiten in Prozessen, sowie gut beschriebene Methodologie-Dokumentation erlaubt, die Arbeitsprodukte viel schneller und qualitativ besser zu bewältigen |
| Compliance | – Erfüllung der Kundenvorgaben und regulatorischen Anforderungen (der ASPICE ist ein „muss“ für viele Automotive-Projekte) |
Die Entwicklung von ASPICE
Die Geschichte von ASPICE begann in den 1990er Jahren unter der Aufsicht der ISO und IEC Organisationen. In der ersten Phase war der Standard nicht auf die Automobilindustrie ausgerichtet und hieß SPICE Technical Report (ISO/IEC 15504). Das Ziel von SPICE war eine allgemeine Verbesserung von Softwareentwicklungsprozessen.
In den 2000er Jahren hat die Automotive SIG zusammen mit Automobilherstellern und Lieferanten die Anpassung der ISO/IEC 15504 an die Anforderungen der Automobilindustrie durchgeführt. Der Standard wurde in den späteren 2000er Jahren in der Automobilbranche zu einem De-facto-Standard. Im Jahr 2017 wurde die Version 3.0 veröffentlicht und im 2023 die Version 4.0.
In der untenstehenden Abbildung ist die Geschichte des ASPICE-Standard zu sehen.
Unterschiede zwischen Version Automotive SPICE (ASPICE) 3.1 und 4.0
An der Stelle werden die wesentlichen Unterschiede zwischen den Versionen 3.0 und 4.0 erläutert. Im Folgenden ist eine Liste aller veröffentlichten ASPICE-Versionen aufgeführt.
In den folgenden Abschnitten werden die Einzelheiten der Änderungen der beiden letzten Versionen behandelt.
| Version | Veröffentlichungsdatum | Änderungen |
| 1.0 | 2005 | – Erste Veröffentlichung des Prozessreferenz- und Bewertungsmodells, angepasst an die spezifischen Anforderungen der Automobilindustrie. |
| 2.5 | 2010 | – Aktualisierung und Erweiterung der Prozesse, basierend auf praktischen Erfahrungen und Feedback aus der Industrie. |
| 3.0 | 2015 Juli | – Anpassung an die ISO/IEC 330xx-Serie, die ISO/IEC 15504 ablöste. – Einführung neuer Prozesse und Klarstellungen zur Verbesserung der Anwendbarkeit. |
| 3.1 | 2017 November | – Redaktionelle Klarstellungen und Präzisierungen zur Vermeidung von Interpretationsspielräumen. – Integration von Erfahrungen aus der Praxis zur Verbesserung der Prozessbeschreibungen |
| 4.0 | 2023 Dezember | – Einbindung von Hardware-Engineering-Prozessen und Machine Learning Engineering (MLE). – Neuer Validierungsprozess und Anpassungen zur besseren Abbildung mechatronischer Entwicklungsprozesse. |
ASPICE 3.1
ASPICE 3.1 [1] wurde im November 2017 veröffentlicht und hat sich seitdem als Standard in der Automobilindustrie etabliert. Der Standard beinhaltet ein umfassendes Modell für die Bewertung von Softwareentwicklungsprozessen in Automotive-Projekten. Die Version 3.1 konzentriert sich auf Standardanpassung (Input), die aus der Industrie kam, und beinhaltet folgende wichtige Punkte:
- Kernprozesse: detaillierte Definition von Prozessen für System- und Softwareentwicklung.
- Prozessattribute: Bewertung der Prozessfähigkeit anhand definierter Attribute.
- Anpassungsfähigkeit: Möglichkeit, das Modell an spezifische Projektanforderungen anzupassen.
In dem untenstehenden Diagramm sind die Prozessgruppen von ASPICE 3.1 abgebildet.
ASPICE 4.0
ASPICE 4.0 [2] wurde im November 2023 offiziell veröffentlicht. Unten in der Liste sind die Änderungen/Ergänzungen aufgelistet:
- Weitere Prozessgruppen: HWE (HW-Engineering), MLE (Machine Learning Engineering) und VAL (Validation Process Group) sind ab Version 4.0 die wichtigen Prozessmodelle in ASPICE.
- Prozessindikatoren: genaues Mapping von Base Practices und Generic Practices zu Information Items (früher Output Work Products genannt) in Form einer Tabelle vorhanden.
- Künstliche Intelligenz: Berücksichtigung von KI-bezogenen Entwicklungsprozessen.
- Konsistente Benutzung von Begriffen: “risk”, “metric”, “measure”, “task” und vielen anderen.
Auf dem Diagramm unten sieht man die Prozessgruppen von ASPICE 4.0. Die Änderungen zur Version 3.1 sind mit roten Rahmen markiert.
Hier sind die Prozessänderungen zwischen den ASPICE Versionen 3.1 und 4.0 aufgeführt:
| Prozess: | Beschreibung: |
| SUP.2, SUP.4, SUP.7 | Die Prozesse sind nicht mehr ein Teil von ASPICE (PRM). |
| MLE Group | Beschreibt die Prozesse für das Machine Learning. |
| ACQ.3, ACQ.11, ACQ.12, ACQ.13, ACQ.14, ACQ.15 | Die Prozesse sind nicht mehr ein Teil von ASPICE (PAM). |
| SPL.1 | Die Prozesse sind nicht mehr ein Teil von ASPICE (PAM). |
| VAL Group | Beschreibt die neuen Prozesse für Validierung. |
| HWE Group | Beschreibt die neuen Prozesse für die Hardware-Entwicklung. |
Anforderungen in Automotive SPICE (ASPICE) 4.0
Die Anforderungen in ASPICE sind in verschiedene Prozessbereiche unterteilt, die spezifische Ziele und Praktiken umfassen.
Diese Prozessbereiche lassen sich in Primäre Prozesse und Unterstützende Prozesse kategorisieren. Unten kann man die Primären Prozesse und entsprechenden Hauptaktivitäten sehen.
Primäre Prozesse
| Prozessname: | Ziel: | Aktivitäten: |
| ACQ.4 Supplier Monitoring | Überwachung und Bewertung der Leistung eines externen Lieferanten, basierend auf vereinbarten Verpflichtungen. | – Vereinbarung und Aufrechterhaltung gemeinsamer Aktivitäten, Schnittstellen und Austausch von Informationen. – Regelmäßiger Austausch der vereinbarten Informationen über definierte Schnittstellen. – Überprüfung der Lieferantenfortschritte hinsichtlich Zeitplan, Qualität und Kosten sowie Einleitung von Abhilfemaßnahmen. |
| SPL.2 Product Release | Sammlung und Klärung der Stakeholderanforderungen, um eine einheitliche Basis für die Entwicklung zu schaffen. | – Sammlung und Analyse der Stakeholderanforderungen. – Abstimmung der Anforderungen mit relevanten Parteien. – Verwaltung von Änderungen und Kommunikation der Anforderungen. |
| SYS.1 Requirements Elicitation | Sammlung und Analyse von Stakeholder-Anforderungen, um ein gemeinsames Verständnis zu schaffen. | – Sammlung und Analyse der Stakeholderanforderungen. – Abstimmung der Anforderungen mit relevanten Parteien. – Verwaltung von Änderungen und Kommunikation der Anforderungen. |
| SYS.2 System Requirements Analysis | Erstellung und Analyse der Systemanforderungen, um Konsistenz und technische Machbarkeit zu gewährleisten. | – Spezifikation der Systemanforderungen. – Strukturierung und Priorisierung der Anforderungen. – Sicherstellung der Rückverfolgbarkeit zwischen Kunden- und Systemanforderungen. |
| SYS.3 System Architectural Design | Entwicklung einer robusten Systemarchitektur, die den Kunden- und Systemanforderungen entspricht. | – Erstellung der Systemarchitektur, (Ressourcen, Schnittstellen und Interaktionsmechanismen usw.) – Validierung der Systemarchitektur durch Entwicklung einer Simulation oder eines Prototyps. – Dokumentation der Architektur. |
| SYS.4 System Integration and Integration Verification | Integration von Systemkomponenten und Verifizierung der Funktionalität des Gesamtsystems. | – Durchführung der Integration gemäß der Systemarchitektur. – Verifikation der Systemintegration durch Tests. – Dokumentation und Behebung von Abweichungen. |
| SYS.5 System Verification | Sicherstellung, dass das System die definierten Anforderungen erfüllt. | – Durchführung von Verifikationstests auf Systemebene. – Analyse, Dokumentation und Bereitstellung der Testergebnisse. – Kommunikation der Ergebnisse an alle Beteiligten. |
| SWE.1 Software Requirements Analysis | Erstellung und Pflege der Softwareanforderungen basierend auf Systemanforderungen. | – Analyse und Dokumentation der funktionalen und nicht-funktionalen Softwareanforderungen. – Sicherstellung der Rückverfolgbarkeit zwischen Software- und Systemanforderungen. – Überprüfung der Anforderungen auf Konsistenz und Vollständigkeit. |
| SWE.2 Software Architectural Design | Entwicklung einer Softwarearchitektur, welche den System- und Softwareanforderungen entspricht. | – Erstellung und Validierung der Softwarearchitektur entsprechend den Anforderungen. – Definition der Softwaremodule und ihrer Schnittstellen, Ressourcen usw. – Dokumentation der Architektur. |
| SWE.3 Software Detailed Design and Unit Construction | Erstellung von Software Detailed Design und Implementierung der Softwarekomponenten. | – Entwicklung des detaillierten Designs für jede Einheit. – Implementierung der Softwarekomponenten gemäß den Spezifikationen. – Einhaltung von Standards und Qualitätsrichtlinien. |
| SWE.4 Software Unit Verification | Sicherstellen, dass Softwareeinheiten korrekt funktionieren. | – Durchführung von Unit-Tests. – Dokumentation, Analyse und Bereitstellung der Testergebnisse. – Behebung von Abweichungen. |
| SWE.5 Software Component Verification and Integration Verification | Verifizierung von Softwarekomponenten und ihrer Integration. | – Integration der Komponenten entsprechend der Architektur. – Durchführung von Verifikationstests. – Dokumentation der Testergebnisse. |
| SWE.6 Software Verification | Sicherstellen, dass die Software alle Anforderungen erfüllt. | – Durchführung umfassender Verifikationen. – Analyse der Ergebnisse. – Kommunikation der Verifikationsergebnisse an die Teams (und andere Disziplinen). |
| MLE.1 Machine Learning Requirements Analysis | Identifizierung und Definition der ML-bezogenen Anforderungen. | – Analyse der funktionalen und nicht-funktionalen Anforderungen. – Dokumentation der Anforderungen. – Rückverfolgbarkeit zu übergeordneten Anforderungen sicherstellen und aufrechterhalten. |
| MLE.2 Machine Learning Architecture | Entwicklung einer Architektur für ML-Modelle. | – Definition der Architektur und relevanter Schnittstellen. – Auswahl geeigneter ML-Frameworks und Tools. – Validierung der Architektur. |
| MLE.3 Machine Learning Training | Training von ML-Modellen gemäß den definierten Anforderungen. | – Datenvorbereitung und Vorverarbeitung. – Training und Optimierung der Modelle. – Dokumentation der Trainingsprozesse. |
| MLE.4 Machine Learning Model Testing | Sicherstellung der Modellleistung und Konformität. | – Durchführung von Modelltests. – Analyse der Testergebnisse. – Dokumentation und Kommunikation der Resultate. |
| HWE.1 Hardware Requirements Analysis | Definition und Analyse der Hardwareanforderungen. | – Sammlung und Spezifikation der Anforderungen. – Analyse der Anforderungen auf Machbarkeit. – Sicherstellung der Rückverfolgbarkeit. |
| HWE.2 Hardware Design | Entwicklung eines Hardwaredesigns basierend auf den Anforderungen. | – Erstellung des Designs für Hardwarekomponenten. – Überprüfung der Kompatibilität zu Systemanforderungen. – Validierung des Hardwaredesigns. |
| HWE.3 Verification against Hardware Design | Verifizierung der Hardware gegen das Design. | – Durchführung von Designüberprüfungen. – Durchführung von Tests auf Komponentenniveau. – Dokumentation der Verifikation-Ergebnisse. |
| HWE.4 Verification against Hardware Requirements | Sicherstellen, dass die Hardware die Anforderungen erfüllt. | – Durchführung von Verifikationen. – Analyse der Ergebnisse. – Bugfixing von vorhandenen Fehlern. |
Unterstützende Prozesse
| Prozessname: | Ziel: | Aktivitäten: |
| SUP.1 Quality Assurance | Sicherstellung, dass die Projekt- und Produktqualität den definierten Anforderungen entspricht. | – Planung und Durchführung von Qualitätsbewertungen. – Überwachung der Qualitätsergebnisse und Identifikation von Abweichungen. – Kommunikation von Qualitätsproblemen und Maßnahmen zur Korrektur. |
| SUP.8 Configuration Management | Verwaltung der Konfigurationselemente, um Konsistenz und Nachverfolgbarkeit sicherzustellen. | – Identifikation und Kontrolle von Konfigurationselementen. – Dokumentation und Nachverfolgung von Änderungen. – Sicherstellung der Verfügbarkeit von aktuellen Konfigurationen. |
| SUP.9 Problem Resolution Management | Systematisches Management von Problemen zur Sicherstellung ihrer Behebung. | – Identifikation und Klassifikation von Problemen. – Analyse der Ursachen und Erarbeitung von Lösungen. – Überwachung der Umsetzung von Abhilfemaßnahmen. |
| SUP.10 Change Request Management | Effektive Verwaltung und Nachverfolgung von Änderungsanforderungen. | – Erfassung und Analyse von Änderungen in Anforderungen. – Bewertung der Auswirkungen auf Zeit, Kosten und Qualität. – Genehmigung und Umsetzung der Änderungen. |
| SUP.11 Machine Learning Data Management | Sicherstellen, dass ML-Daten verfügbar, korrekt und für das Training geeignet sind. | – Sammlung und Aufbereitung von Daten für das Training und die Tests. – Sicherstellung der Datenintegrität und Rückverfolgbarkeit. – Verwaltung von Datenversionen und -zugriffen. |
| MAN.3 Project Management | Sicherstellung, dass Projekte gemäß den definierten Zielen und Anforderungen durchgeführt werden. | – Planung von Projekten, einschließlich Zeitplan, Ressourcen und Kosten. – Überwachung und Steuerung des Projektfortschritts. – Identifikation und Management von Risiken und Problemen. |
| MAN.5 Risk Management | Identifikation, Bewertung und Steuerung von Risiken zur Minimierung negativer Auswirkungen im Projekt. | – Ermittlung potenzieller Risiken und deren Ursachen. – Bewertung der Eintrittswahrscheinlichkeit von Risiken und deren Auswirkungen. – Entwicklung und Umsetzung von Risikominderungsmaßnahmen. |
| MAN.6 Measurement | Bereitstellung von objektiven Daten zur Unterstützung von Entscheidungen. | – Definition von Messzielen und -methoden. – Sammlung und Analyse von Messdaten. – Kommunikation der Ergebnisse zur Entscheidungsunterstützung. |
| PIM.3 Process Improvement | Verbesserung der Prozesse, um die Leistungsfähigkeit und Effizienz zu steigern. | – Identifikation von Verbesserungsbereichen basierend auf Daten und Bewertungen. – Entwicklung und Umsetzung von Verbesserungsmaßnahmen. – Überwachung und Bewertung der Wirksamkeit der Verbesserungen. |
| REU.2 Management of Products for Reuse | Systematische Wiederverwendung von Produkten und Komponenten zur Steigerung der Effizienz und Reduzierung von Kosten. | – Identifikation von Produkten und Komponenten mit Wiederverwendungspotenzial. – Erstellung und Pflege von Reuse-Richtlinien und -Datenbanken. – Sicherstellung der Qualität und Kompatibilität von wiederverwendeten Elementen. |
Modell von ASPICE Prozessreifegrade
Die ASPICE-Prozessreifegrade geben an, wie gut ein Unternehmen die jeweiligen Entwicklungsprozesse einhält und durchführt. Es gibt insgesamt 6 Ebenen (Levels) von 0 (niedrigste Prozessdurchführung- und Prozessintegrationsebene) bis 5 (höchste Prozessdurchführung- und Prozessintegrationsebene, die Prozesse werden dabei kontinuierlich verbessert). Unten sind die Prozessreifegrade und eine kurze Beschreibung für jeden Reifegrad aufgeführt.
- Level 0 (Unvollständig): Der Prozess ist nicht implementiert oder erreicht nicht sein Ziel.
- Level 1 (Durchgeführt): Der Prozess erreicht seine Ziele.
- Level 2 (Gemanagt): Der Prozess wird geplant, überwacht und angepasst.
- Level 3 (Etabliert): Der Prozess ist dokumentiert und standardisiert.
- Level 4 (Vorhersehbar): Der Prozess wird innerhalb definierter Grenzen ausgeführt.
- Level 5 (Optimierend): Der Prozess wird kontinuierlich verbessert.
Je höher das Level ist, desto mehr Anforderungen müssen erfüllt werden. Allerdings bedeutet das höhere Level eine bessere Integration von Prozessen und bessere Qualität der Arbeitsergebnisse.
In den meisten Projekten aus meiner Praxis genügte das Level 2 (Gemanagt) als ASPICE-Anforderung von der Kundenseite. In diesem Dokument möchte ich nur das Level 2 näher erläutern, um den Dokumentationsrahmen nicht besonders zu belasten.
Das ASPICE Level 2
Das Ziel von ASPICE Level 2 ist sicherzustellen, dass Prozesse nicht nur durchgeführt, sondern auch gemanagt und kontrolliert werden. Dies bedeutet, dass Prozesse geplant, überwacht und angepasst werden, um die Arbeitsergebnisse zu überprüfen und gegebenenfalls zu korrigieren.
Hier sind die wesentlichen Merkmale von ASPICE Level 2:
| Prozessmerkmale: | Beschreibung: |
| Process Performance (Prozessleistung): | Die Arbeitsergebnisse werden gegen die definierten Prozesse überprüft, um sicherzustellen, dass die Prozesse verlässliche, kontinuierliche und konsistente Arbeitsergebnisse liefern können. |
| Work Product Management (Arbeitsprodukt-Management): | Es soll eine Überwachung von allen Arbeitsprodukten stattfinden. Das Ziel ist, die Arbeitsprodukte in einer strukturierten und nachvollziehbaren Art und Weise zu erstellen und zu sichern. |
| Process Management (Prozess-Management): | Alle Prozesse laufen kontrolliert ab. Es gibt klare Verantwortlichkeiten; die Prozesse werden überwacht und gesteuert. Ein kontrollierter Prozess erhält klare Merkmale für die Bewertung: z. B. Zeit, Qualität, Ressourcen und andere. |
Anforderungen von ASPICE Level 2
Damit Level 2 erreicht werden kann, müssen bestimmte Voraussetzungen (Aktivitäten) erfüllt werden. In der Tabelle unten sind die Voraussetzungen aufgelistet:
| Anforderungsstichwörter: | Anforderungen: | Beispiele für Arbeitsergebnisse: |
| Planung und Monitoring | Alle Aufgaben und Ressourcen müssen geplant werden und alle Fortschritte im Projekt werden überwacht und gegebenenfalls korrigiert. | Ein klar definierter Projektplan mit geplanten Meilensteinen und regelmäßiger Verifizierung von Arbeitsergebnissen ist vorhanden. |
| Qualitätssicherung | Alle Prozesse werden gegen die Standards verglichen und verifiziert. Die Arbeitsergebnisse werden auch hinsichtlich der ausreichenden Qualität überprüft. | Die Prozesse und Arbeitsergebnisse beinhalten Implementierungen von Anforderungen aus z. B. ISO 26262, ASPICE sowie anderen Standards und Normen. |
| Projektdokumentation | Es muss eine klare und ausreichende Dokumentation für Prozesse und Arbeitsergebnisse geben, um die Rückverfolgbarkeit zu gewährleisten. | Im Projekt gibt es klare, dokumentierte Ablagen für Dokumentation und Arbeitsergebnisse. |
| Konfigurationsmanagement | Alle Änderungen von Arbeitsprodukten müssen dokumentiert werden. | Es gibt klare Vorgaben für die Versionierung der Arbeitsergebnisse im Projekt. |
Umsetzung der Anforderungen für ASPICE Level 2
In den Abschnitten unten sind die Prozesse als Arbeitsschritte in einer Liste vorhanden, die für das Erreichen von ASPICE Level 2 eingehalten werden müssen.
Die “Praktische Tipps” geben an, welche praktische Maßnahmen ergriffen werden sollen, um die Ziele zu erreichen und deuten darauf, was gemacht werden muss, um ASPICE Level 2 zu erreichen.
1. Prozessdefinition und -dokumentation
- Entwicklung von standardisierten Prozessen (am besten unternehmensübergreifend), die den ASPICE-Richtlinien entsprechen.
- Erstellung, Überprüfung und Freigabe von Prozessbeschreibungen, Arbeitsanweisungen und Templates.
- Klare Definition von Verantwortlichkeiten und Zuständigkeiten innerhalb der Prozesse.
Praktische Tipps
- Erstellung einer Prozesslandkarte zur Visualisierung der Prozesslandschaft.
- Einsatz von Prozessmanagement-Tools zur Dokumentation und Kommunikation (Prozessmodellierung und Design, Automatisierungstools, Projektmanagementtools, Prozessüberwachung, Dokumentations- und Qualitätstools usw.).
2. Projektmanagement (MAN.3)
- Festlegung und Dokumentation von Projektzielen, Zeitplänen, Ressourcen, Auslieferungsmeilensteinen und Budgets.
- Identifikation von potenziellen Projektrisiken und Entwicklung von Maßnahmen zur Projektrisikominimierung.
- Regelmäßige Überprüfung des Projektfortschritts und Anpassung der Pläne an die Projektgegebenheiten.
Praktische Tipps
- Verwendung von Diagrammen, Tabellen oder ähnlichen Datensammlungen für die Zeitplanung.
- Erstellung einer Risikoliste zur systematischen Risikodokumentation und Risikoverfolgung.
3. Anforderungsmanagement (SYS.1, SWE.1)
- Sammlung und Klärung von Anforderungen unter Einbeziehung aller Stakeholder.
- Überprüfung auf Vollständigkeit, Konsistenz und Realisierbarkeit der Anforderungen.
- Gewährleistung der bidirektionalen Nachverfolgbarkeit (Traceability) zwischen Anforderungen auf unterschiedlichen Ebenen (SYS, SW, HW, ME).
Praktische Tipps
- Einsatz von Tools wie DOORS, Jama oder anderen zur Verwaltung von Anforderungen.
- Durchführung von Workshops mit Stakeholdern zur Klärung von Anforderungen.
4. System- und Softwaredesign (SYS.2, SWE.2)
- Entwicklung einer modularen und skalierbaren Architektur (entsprechend der Disziplin: SYS oder SW).
- Anwendung von Best Practices und Standards im Designprozess.
- Durchführung von Peer-Reviews zur Qualitätskontrolle.
Praktische Tipps
- Verwendung von UML oder SysML zur Modellierung der Architektur (Einsatz von z. B. Enterprise Architekt).
- Anwendung bewährter Design Patterns zur Lösung wiederkehrender Probleme.
5. Implementierung und Test (SWE.3, SWE.4, SWE.5)
- Entwicklung der Software gemäß den Designspezifikationen.
- Durchführung von Tests auf Komponentenebene.
- Zusammenführung der Komponenten und Validierung ihrer Zusammenarbeit.
- Überprüfung, ob die Software die Anforderungen erfüllt (Durchführung von Qualifikationstests).
Praktische Tipps
- Ansatz zur Verbesserung der Codequalität unter Verwendung von Test-Driven Development und unterschiedlichen Tools wie z. B. Git, Debugger, CppUTest, CMock, Simulink Real-Time, Lauterbach, Jenkins usw.).
- Entwicklung und Einsatz von Testautomatisierung zur Effizienzsteigerung.
6. Qualitätssicherung (SUP.1)
- Definition von Qualitätszielen und -metriken im Projekt.
- Regelmäßige Überprüfung der Prozesse und Produkte auf Einhaltung der Standards und Fehlerprotokollierung.
- Identifikation von Fehlerursachen und Einleitung von Korrekturmaßnahmen.
Praktische Tipps
- Einführung von KPIs zur Messung der Qualität im Projekt.
- Systematische Dokumentation von Erfahrungen zur kontinuierlichen Verbesserung von Prozessabläufen.
7. Konfigurationsmanagement (SUP.2)
- Festlegung, Definition und Dokumentation der zu verwaltenden Projektartefakte.
- Einsatz von Tools wie Git oder Subversion zur Verwaltung von Versionsständen durch Versionskontrolle, sowie zur Aufrechterhaltung und Versionierung von Artefakten.
- Definition von Referenzpunkten (Baselines) für die Projektartefakte während der Entwicklung.
Praktische Tipps
- Verwendung von Gitflow-Branching-Strategie zur effizienten Verwaltung von Entwicklungszweigen.
- Automatisierung des Build-Prozesses für konsistente Ergebnisse von einem SW-Stand-Build.
8. Änderungs- und Problemmanagement (SUP.3, SUP.4)
- Erstellung von formalisierten Prozessen zur Beantragung und Genehmigung von Projektänderungen (Änderungsmanagement).
- Nutzung von Tools wie JIRA oder Bugzilla zur Dokumentation und Nachverfolgung von Problemen und deren Status.
- Transparente Information über Änderungen und Probleme sowie ein Mechanismus zur Verteilung dieser Informationen an alle Beteiligten.
Praktische Tipps
- Einrichtung eines Gremiums zur Bewertung und Genehmigung von Änderungen (CCB – Change Control Board).
- Feststellung und Klassifizierung von Projektproblemen nach
- Dringlichkeit und Auswirkung.
Praktische Umsetzungstipps
Nutzung von Werkzeugen und Technologien
- Unterstützung bei der Verwaltung von Anforderungen, Tests und Defekten durch Verwendung von Application Lifecycle Management (ALM)-Tools.
- Einsatz von Tools wie Jenkins oder GitLab CI zur Automatisierung von Build- und Testprozessen (Continuous Integration/Continuous Deployment, CI/CD).
- Verwendung von Tools wie SonarQube zur Überprüfung der Codequalität mit Static Code Analysis.
Mitarbeiterqualifizierung
- Regelmäßige Trainings zu ASPICE und den angewandten Entwicklungsprozessen im Projekt.
- Förderung von Zertifizierungen wie “Certified Automotive SPICE Assessor” und anderen für Kompetenzverbesserung innerhalb von Teams.
- Einsatz von Prozessberatern zur Unterstützung bei der Implementierung.
Prozessverbesserung
- Anwendung des PDCA-Zyklus (Plan-Do-Check-Act) zur kontinuierlichen Verbesserung.
- Sammlung und Analyse von Projektdaten zur Analyse und Bewertung der Prozessleistung.
- Vergleich von Prozessergebnissen mit Best Practices und Industriestandards zur Identifikation von Verbesserungspotenzialen.
Herausforderungen bei der Umsetzung von ASPICE Level 2
| Herausforderungen: | Mögliche Lösungen: |
| Akzeptanz innerhalb eines Teams: Öfter treten Probleme bei der Integration neuer Prozessen während der Entwicklung auf. | Es soll klar kommuniziert werden, welche Vorteile diese Änderungen mit sich bringen sollen und was damit verbessert werden kann. |
| Mögliche Budgetknappheit: Die Implementierung und Integration von neuen Prozessen benötigen entsprechende Ressourcen und brauchen in der Startphase besonders viele Ressourcen. | Die besonders kritischen Bereiche, welche dringend eine Unterstützung seitens der Prozesslandschaft benötigen, werden als Erstes behandelt. |
| Überforderung des Team: Unter Umständen kann es sein, dass Teams einen größeren Zeitanteil mit der Umsetzung von neuen Prozessen verbringen und die eigentliche Tätigkeit auf der Seite bleibt. | Das Einführen von komplexen Prozessabläufen soll schrittweise durchgeführt werden. |
| Schwierigkeiten bei der Tool-Integration: Die bestehenden Systeme können aus Konfigurationssicht träge sein, und nicht jedes Tool kann problemlos in die Entwicklungslandschaft integriert werden. | Die Tools sollen sorgfältig gewählt und überprüft werden, bevor sie in die Prozesse übernommen werden. |
Falls Sie eine Unterstützung im ASPICE-Bereich und begleitenden Prozessen benötigen, können Sie mich gerne kontaktieren:
Weitere Tipps für die Umsetzung von Prozessen in einem Projekt kann man in dem Artikel: Lessons Learned finden.
Fallstudie: Vorgehensweise für die erfolgreiche Implementierung von ASPICE Level 2
In diesem Kapitel wird eine Beispielsituation dargestellt, welche aus der Praxis kommt, ohne Unternehmensangaben und ein spezifisches Projekt zu erwähnen.
Ein mittelständischer Automobilzulieferer mit Fokus auf Embedded Systems stand vor der Herausforderung, seine Entwicklungsprozesse zu verbessern, um den steigenden Anforderungen eines OEM gerecht zu werden. Meistens ist das Projekt auf einen engen Zeitrahmen beschränkt. Hier möchte das Projekt innerhalb von 1.5 Jahren das ASPICE Level 2 erreichen.
Ausgangssituation
Probleme: Hohe Fehlerquoten, Verzögerung des Projekts und unzufriedene Kunden.
Ziel: Erreichen von ASPICE Level 2 innerhalb von 18 Monaten.
Vorgehensweise
- Initiale Gap-Analyse: Durchführung einer GAP-Analyse gegenüber den Vorgaben zum ASPICE Level 2 durch einen (externen) ASPICE Berater.
- Analyse und Bestimmung von Änderungen für ASPICE Level 2: Durch eine Analyse werden die Arbeitspakete erarbeitet, die für das Zielerreichen nötig sind.
- Bestimmung von benötigten Ressourcen: Beschaffung und Freigabe von nötigen Kapazitäten für die Fertigstellung der im Schritt 2 definierten Arbeitspaketen.
- Prozessentwicklung: Anpassung bestehender Prozesse (oder Erstellung von neuen Prozessen) in der Prozesslandschaft und Einführung neuer Praktiken gemäß den ASPICE-Anforderungen in Teams.
- Schulung: Intensives Training der Mitarbeiter auf allen Ebenen, einschließlich Projektmanagement, Entwicklung und Qualitätssicherung.
- Feedback und Anpassung: Kontinuierliche Verbesserung basierend auf den Erfahrungen und Feedback der Mitarbeiter. Für ein effizientes Feedback sollen spezielle Rollen definiert werden, mit den klaren Vorgaben für die Kommunikation zum Prozessteam.
- Finales Assessment: Durchführung eines offiziellen Assessments zur Bestätigung des erreichten Levels.
Ergebnisse
- Erfolgreiches Assessment: Erreichen von ASPICE Level 2 nach 16 Monaten möglich. Das Ergebnis hängt stark von unterschiedlichen Faktoren wie Team-Erfahrenheit, Kommunikationskanälen, Ausmaß der Prozessänderungen und dedizierten Ressourcen für die Umsetzung von Änderungen ab.
- Qualitätssteigerung: Die Fehlerquote kann man um mehrere zehn Prozent reduzieren. Dadurch, dass die Abläufe klar definiert und die Zuständigkeiten bekannt sind, werden die Aufgaben viel schneller erledigt.
- Kundenzufriedenheit: Positive Rückmeldungen vom OEM und Sicherung weiterer Aufträge.
- Mitarbeiterzufriedenheit: Erhöhte Motivation und geringere Fluktuation durch klar definierte Prozesse und Verantwortlichkeiten.
Zu beachten
Die Punkte aus den Ergebnissen werden in der Implementierungs- und in der ersten Umsetzungsphase nicht wahrgenommen. Die Beanspruchung des Teams steigt, die Zufriedenheit sowohl im Team als auch auf der Kundenseite sinkt und die täglichen Geschäfte werden noch weniger gemacht als früher. Die Prozessänderungen sind ein großer Aufwand für das Projekt und umso mehr für ein Unternehmen.
Die positiven Effekte treten erst dann auf, wenn alle Teamstakeholder die betroffenen geänderten Prozesse “gleich” benutzen und ausführen. Erfahrungsgemäß benötigt man an der Stelle einige Tage bis Monate, abhängig von Willen der Projektstakeholder und vom Änderungsumfang.
Fazit
ASPICE ist schon seit längerer Zeit ein Standard in der Automobilbranche geworden, welcher von vielen OEMs als selbstverständliche Anforderung eingestuft ist. Die Umsetzung der ASPICE-Anforderungen ist aber eine große Herausforderung für Automobilzulieferer. Insbesondere steigt der Aufwand für die Implementierung höherer ASPICE-Levels. Wie bereits im Kapitel: Vorgehensweise für die erfolgreiche Implementierung von ASPICE Level 2 beschrieben ist, sind die Vorteile von ASPICE-Level Implementierung erst ab dem Zeitpunkt wahrnehmbar, sobald die Prozesse im Team etabliert sind. Für die Implementierung und Einführung von neuen Prozessen werden ergänzende Ressourcen gebraucht.
Nach der Integration und Einspielen von neuen Prozessen werden die Vorteile klar und deutlich sichtbar. Die Übersicht über die Tätigkeiten, Aufgaben und Verantwortlichkeiten steigt immens. Die täglichen Aufgaben im Entwicklungsteam werden dadurch viel präziser und schneller erledigt. Das Management kennt den aktuellen Software-Stand und weiß genau, welche Features für die Auslieferung an Kunden versprochen waren.
Alles zusammen bietet die Implementierung von ASPICE-Vorgaben deutlich mehr Vorteile als Nachteile, obwohl die Ergebnisse nicht sofort zu sehen sind.
Quellenangaben:
- [1] Automotive SPICE Process Assessment / Reference Model, Version 3.1
- [2] Automotive SPICE Process Assessment / Reference Model, Version 4.0
- [3] Bernd Hindel Method Park Consulting 31st May 2016, Rochester (Presäntation)
Autor: Dipl.-Ing. Nachrichtentechnik (FH) Oleg Czaikowsky, den 24.03.2025