Motivation & Anforderung

Es gibt eine Korrelation zwischen der erreichten Qualität eines Produktes oder Dienstleistung und der Art des Vorgehens (Prozesse) diese Qualität zu erreichen oder sicherzustellen.
Um sicherzustellen, dass der Lieferant fähig ist den anspruchsvollen Entwicklungsanforderungen zu genügen, gibt es oftmals von den Automobilhersteller an ihren Lieferanten die Prozesse unter anderem auch nach Automotive SPICE auszurichten und fordern zu Beginn der Entwicklung einen SPICE “Level 2” und gegen Ende der Entwicklung oder nach einer festgelegten Zeit - den nächst höheren SPICE-Level (Level 3).
Die Qualität und Quantität der Produkte oder Dienstleistung, die mit Vorgaben in Anlehnung nach Automotive SPICE Prozesse erstellt wurden sind nachweislich qualitativ besser und nutzbringender als dies ohne ASPICE erbracht werden.
Für die Vergabe von Projekt-Ausschreibungen ist ein ASPICE Nachweis immer öfter die Voraussetzung für einen Entwicklungsauftrag.

Zielsetzung

Zielsetzung ist,
- dass die Prozesse beschrieben sind,
- dass die Prozesse auch wirklich gelebt werden und
- das die Prozesse auch effektiv bezüglich des jeweiligen Prozesszieles sind und einen Mehrwert bezüglich Nutzen und Qualität bringen.
Prozesse sollen nicht überreguliert aufblasen sein, schwer verständlich, inkonsistent oder ineffektiv sein.
Diese werden vom Anwender oft nicht verstanden und somit auch nicht angenommen. Statt dessen sollten die Prozesse möglichst schlank, einfach zu verstehen, klar und effektiv bezüglich ihrer Intension sein.
Das erreicht man unter anderem durch “Wertschöpfungs-denken” sowie der Anwendung von “Lean Prinzipien”zur Erreichung des gewünschten (Prozess-) Ergebnisses.
Im agilen Kontext könnte man die Durchführung und Steuerung von Projekten auch mittels Anwendung von Agile- und Lean Management Methoden (DOR/DOD oder auch OKR Methoden) umsetzen, durchführen von Tasks aus dem Task-Backlog in Form von Sprints usw).
Darüber hinaus lassen sich bestehende Prozesse hinsichtlich Effizienz analysieren und anpassen.
Zusätzlich gilt es die Wiederverwendung (REUSEability) von Produkten, Work Products, Prozesse, Anweisungen und weiterer Arbeitsdokumente zu planen und effizient umzusetzen, einschließlich eines Lessons Learned (LL) Prozesses, das die Erfahrungen aus vorangegangenen Projekten und Aktivitäten in zukünftige Projektaktivitäten einfließen lässt.

Reifegrad CL0 & CL1

Capability Level 0 (CL0) bedeutet im SPICE Jargon dass der Fähigkeitsgrad der Prozesse bezüglich des Prozesszwecks als unvollständig bewertet wurden; das ist gleichbedeutend der Tatsache, dass die vom Prozess erwarteten Ergebnisse nur teilweise bzw. nicht erbracht wurden oder nicht/bedingt nutzbar sind.
Capability Level 1 (CL1= performed") bedeutet, dass die vom Prozess notwendigen Ergebnisse erbracht wurden, diese nutzbar sind, diese aber nicht nachweisbar in einer gemanagten (gesteuerte und strukturierte) Weise entstanden sind.

Umsetzung Reifegrad CL2

Es werden für ein Projekt alle Aktivitäten soweit wie notwendig geplant, diese aber sowenig wie möglich für die Umsetzung in einem dynamischen Prozessumfeld einschränkend sind. Diese Bewegungsfreiheit ist notwendig für projektbegleitenden Verbesserungen und Anpassungen sowie Anwendung agiler Praktiken.
Verantwortlichkeiten und Befugnisse sind festgelegt, Ressourcen bereitgestellt, Qualitätskriterien für die Prozesse, Arbeitsergebnissen etc. aufgestellt, Regel für die Steuerung des Projektes sind aufgestellt und werden umgesetzt, die projektbegleitende Qualifikation der Mitarbeiter wird umgesetzt. Die Schnittstellen und relevanten Anforderungen zu anderen Regelwerke werden berücksichtigt.

REIFEGRAD CL3

Capability Level 3 (CL3= established) bedeutet im Groben, dass es organisationsweit ein Standard-Prozess einschließlich eines Verbesserungsprozesses definiert und gelebt wird, der dann für die jeweiligen Projekte herangezogen und projektspezifisch angepasst (getailored) werden kann.

ASPICE Process Framework

Beispiel einer generischen ASPICE Prozessstruktur mit den zum Prozess gehörenden Prozessfluss-Diagramme, den Prozessbeschreibungen mit Tabellen und Grafiken sowie den unter Informationen findenden Arbeitsprodukte und Templates. Die Dokumentation wird in deutsch und/oder englisch erstellt.

Mechanical - SPICE

Zur Mechanik zählen unter anderem z.B. die mechanischen Bremsassistenz-Komponenten, Lenksystem, Antriebskomponenten, Gehäuse, Stecker, Schrauben, Dichtungen, Federn, mech. Schalteinheit usw.

Mechanical System Engineering Processes (MSE):
MSE.1 Mechanical System Requirements Analysis
MSE.2 Mechanical System Architectural Design
MSE.3 Mechanical System Integration and Integration Test
MSE.4 Mechanical System Qualification Test

Die mech. Component Engineering Processes (MCE):
MCE.1 Mechanical Component Requirements Analysis
MCE.2 Mechanical Component Design
MCE.3 Mechanical Component Sample Production
MCE.4 Test against Mechanical Component Design
MCE.5 Test against Mechanical Component Requirements

Planung (Timeline)

Schritte Automotive SPICE einzuführen sind, das Delta (die Abweichung) bestehender Prozesse und derer, die den erwünschten SPICE Level entsprechen zu ermitteln.
Welche der vorhandenen Prozesse decken die formalen (BP’s & GP’s) Anforderungen von ASPICE schon ab, welche nur teilweise und derer, die noch fehlen. Die Umsetzung der Deltas werden in enger Zusammenarbeit mit den Stakeholder der jeweiligen Prozesse begleitet. Parallel werden die betroffenen Mitarbeitern mit den Anforderungen und der Methodik von Automotive SPICE geschult. Bei der Analyse und Erstellung der Prozesse wird darauf geachtet, das die erstellten Prozesse allgemein geschrieben sind, effizient, schlank und möglichst Wiederverwendbar sind. Durch eine sogenante Vorwärtsdokumentation (WP Templates) wird die Fehlermöglichkeit sowie der Aufwand für die Erstellung der ASPICE Arbeitsprodukte für die Mitarbeiter weiter verringert. Über Checklisten kann parallel geprüft werden, ob die erstellten Arbeitsprodukte alle Anforderungen nach Automotive SPICE abdecken, oder ob noch etwas fehlt.

Anforderungen ermitteln

Die Anforderungen an das zu entwickelnde Produkt werden durch Analysen von zukünftigen Kundenmärkte- und bestehenden Wettbewerber ermittelt und bezüglich Nutzen, Ziele und Werte analysiert. Die daraus ermittelten Produktfeatures oder Funktionen werden in Kategorien wie Basis-, Leistungs- und Begeisterungsfaktoren zugeordnet und gruppiert. Daraus werden dann zielorientiert die Kundenanforderungen (Produktanforderungen) sowie die Projektanforderungen definiert.

Bei der Definition der Produktanforderungen werden die Anforderungen bezüglich funktionale Anforderungen, QM-Anforderungen (früher auch “nicht-funktionale Anforderungen” genannt) sowie den Randbedingungen (Constraints) zu den Anforderungen attributiert. Parallel zu den Anforderungserstellung werden zeitgleich die entsprechenden Abnahmekriterien oder Qualifikationen oder Testfälle definiert. Durch die parallele Bearbeitung von Anforderungen sowie den zu erwartenden Abnahme-/ Testkriterien (Test oriented Requirements Engineering) werden die jeweiligen Anforderungen effektiver- & schneller analysiert, und auch besser verstanden als in der traditionellen sequenziellen Vorgehensweisen, wo die Abnahmekriterien erst sehr spät erfolgen und dann die Abnahmekriterien so definiert wurden, das diese im schlimmsten Fall evtl. gar nicht testbar sind.

In einer QFD Analyse (oder Matrix orientierte Analysen) werden Einflüsse und Auswirkungen analysiert, in denen Kundenwünsche bzw. Marktanforderungen in Produktanforderungen abgeleitet werden.

Bei Safety- oder Security Relevanz kommen zusätzlich Anforderungen aus der Risiko- / Security-Analyse (HARA bzw. TARA).

Prozess Input-/Output

Grafischen Darstellung aller benötigten Eingangsdokumente bzw. der Arbeitsprodukte (WP), die z.B. für den Prozess MAN.3 (Project Management) benötigt werden um die geforderten Prozessergebnisse nach ASPICE zu erstellen.
Jedes Input & Output Work Product ist beschrieben und für die Erstellung werden geeignete Vorlagen und Templates bereitgestellt.

Process Outcomes (WP)

Auszug der geforderten Arbeitsprodukte die in den einzelnen ASPICE Prozesse in den Projekten zu erbringen sind.

Hardware - SPICE

Zur Hardware in diesem Kontext zählen unter anderem z.B. die Bauteile-/Baugruppen einer vollbestückten ECU, ein System-on-Chip, Mikrocontroller oder ein SBC usw.

Die Hardware Engineering Process Group (HWE):
HWE.1 Hardware Requirement Analysis
HWE.2 Hardware Design
HWE.3 Verification against Hardware Design
HWE.4 Verification against Hardware Requirements

ASPICE Umsetzung

Im ersten Schritt einer Umsetzung von Automotive mechanical- oder/und Hardware SPICE ist zu definieren, WAS im Kontext der Mechanik oder/und Hardware von den einzelnen Automotive SPICE Prozessen wie z.B. den Engeneering-Prozessen, den Management-, Supporting-, Improvement-, Reuse-, Acquisition- und Supply- Prozesse für den jeweiligen Capability Level (CL) gefordert ist.

Im zweiten Schritt werden die Forderungen aus dem ersten Schritt in einem betrieblichen Prozesskontext nämlich WIE machen wir das, WAS von Automotive SPICE gefordert wird.
Wir beschreiben die Strategie WIE wir (die Organisation) die Anforderungen für das Produkt Qualitätssteigernd, Nutzbringend (Wertschöpfungsdenken) und effizient (lean) umsetzen werden.

Im dritten Schritt müssen wir das was wir beschrieben haben WIE wir es tun im Projektkontext dann auch umsetzen also das TUN (DOING) und dafür auch den Nachweis erbringen. Das ist im Wesentlichen auch der Umfang eines evtl. SPICE Assessments.

Tasks:
- Mech. / HW SPICE Anforderungen;
- Prozesse für die Umsetzung;
- Erstellen der Work Product-Vorlagen, der Templates, Checklisten, Review-Checklisten usw.
- Coaching und Training der Mitarbeiter;
- Unterstützung bei der Erstellung der Arbeitsdokumenten;
- Vorbereitung und Unterstützung von Prozess-Audits und Assessments;
- Management der Schnittstellen und Abstimmung;
- Reuse- und Lessons Learned Prozess implementieren;
- Unterstützung der Engineering Prozesse;
- Unterstützung der Supporting- und Managementprozesse;
- Unterstützung beim Kunden;
- Support der Schnittstellen zu Funktionaler Sicherheit, Cybersecurity und QS (IATF 16949)
- Optimierung der Prozesse und Arbeitsprodukte.

Funktionale Sicherheit & ASPICE

Für die Bearbeitung von sicherheitsrelevante Projekten werden in Beschreibung der ASPICE Prozesse die jeweils relevanten Anforderungen der ISO 26262 mit beachtet und in den ASPICE Prozessbeschreibungen und den WP-Templates mit dokumentiert. Dasselbe gilt für Cyber Security relevante Prozesse, auch hier wird in den ASPICE Prozessbeschreibungen und den WP-Templates die Anforderungen der jeweils relevanten Cyber Security Normen (SAE J3061) mit berücksichtigt und dokumentiert.

Anforderungen Managen

Requirements sollten immer in einer für die Anforderung spezifischen Satzstruktur beschrieben sein. Sie sollen kurz, klar, prägnant, verständlich, strukturiert, konsistent und testbar beschrieben sein. Der Typ eines Requirements ist entweder ein funktionales Requirement) oder ein QM-Requirement (nicht-funktional) sowie Randbedingung(en) (Constraint).
Die Trennung zwischen einer Aufgabenbeschreibung und einer Lösungsbeschreibung wird zwingend empfohlen.
Über ein Attributierungsschemata werden die Requirements eindeutig identifiziert, priorisiert, versioniert, einer Quelle-, einem Ersteller sowie einem Empfänger/Rolle zugeordnet, einem aktuellen Status und Querbezüge zu weiteren Anforderungen zugeordnet, Abhängigkeiten und Einflüsse zu Komponenten und Funktionen zugewiesen, Bewertung von Risiken bez. technischer Umsetzbarkeit, Aufwand und Know-how zugewiesen, bestehenden Randbedingungen, einem nächsten Workflow, sowie den Akzeptanzkriterien bzw. Testkriterien für jedes einzelne Requirement definiert.
Über ein Requirements Management Plan (RMP) werden die Attributierung, die Requirements-Struktur (RI-Modell), welche benötigten Sichten- und Berichte es geben soll, das Tracking von Änderungen- und der jeweiligen Status, der Art der Versionierung, wie mit Varianten umgegangen wird, wie der RE-Prozess verbessert wird, wie mit den int/ext Requirement-Dokumenten umzugehen ist, die Auswahl von Werkzeugen und Tools, sowie der beteiligten Rollen und die jeweiligen Verantwortlichkeiten (z.B. durch ein RACI-Diagram).

Process flow

Auszug eines Prozessflussdiagrams z.B. für den Prozess MAN.3 (Project Management). Die Pfeile stellen die Eingangs- & Ausgangsdokumente der einzelnen Prozessschritte dar.

ASPICE Processes for Mech-& HW-SPICE

Beispiel einer ASPICE Life Cycle Prozessdarstellung mit den Prozessen auf System- und Component Level:

- Automotive SPICE (SW)
- HW SPICE (E/E/PE)
- Mechanical SPICE. (Mechanic)

Automotive SPICE v3.0 also der Vorgänger der jetzigen aktuellen Version war ein softwarezentriertes Modell, das den Fokus der Prozesse auf Softwareentwicklung gelegt hatte. Mit der ASPICE v3.1wurden die “Primary Life Cycle” Prozesse für ein Plug-in-Konzept von mechanischer- und auch Hardware-Entwicklung vorbereitet und angepasst.
Mit dem Plug-In Konzept können jetzt die Software-spezifischen Prozesse des Automotive SPICE-Modells durch andere PRM/PAM-Subdomänen wie elektrische-, elektronische und mechanische oder/und Hardware ersetzt und ergänzt werden.
So ist es jetzt möglich in einer strukturierten Form Verbesserungen von mechanischen- und Hardware Entwicklungsprozessen vorzunehmen und diese auch zu bewerten.

Bem: Einige System Engineering-, Management-, Supporting- & Supply-Prozesse müssen jedoch noch überarbeitet werden, um z.B. ein mechatronisches System oder im HW Kontext umfänglich adressieren zu können.