Automotive SPICE nachweisbar umsetzen - von SYS.2 bis zum Assessment
WORKSPACE.PM gibt Ihren ASPICE-Projekten das Rückgrat: Prozessgruppen als Container-Struktur, das V aus Phasen, Meilensteinen und Quality Gates, versionierte und freigegebene Arbeitsergebnisse sowie ein Audit-Trail, der jede Entscheidung belegt - im selben System, in dem Ihre Teams ohnehin arbeiten.
Wo Automotive SPICE auf dem Spektrum steht
Und welche Methoden in der Nachbarschaft liegen
Automotive SPICE: prozessgetrieben, nachweisorientiert
Automotive SPICE steht klar auf der prozessgetriebenen Seite - definierte Prozessgruppen, das V aus Spezifikation und Verifikation, belegte Freigaben. In WORKSPACE.PM bleibt das kombinierbar: Über das Container-Konzept führt jedes Teilprojekt seine eigene Arbeitsweise, sodass die ASPICE-Governance steht, während einzelne Software-Stränge agil in Sprints und auf Boards arbeiten.
Prozess definiert - Nachweise verstreut
Woran die ASPICE-Umsetzung in vielen Entwicklungsteams tatsächlich hängt
Der Prozess lebt in der Präsentation
Ihre Prozesslandschaft ist beschrieben und assessiert - aber das Projektwerkzeug kennt weder Prozessgruppen noch Arbeitsergebnisse. Also wird nebenher in Tabellen, Ordnern und Mails gepflegt, was das Modell verlangt.
Rückverfolgbarkeit im Tabellen-Flickwerk
Welches Arbeitspaket hängt an welchem Dokument, welchem Risiko, welcher Änderung? Die Antwort steht in verstreuten Listen - und kein Rückverweis überlebt die nächste Umbenennung.
Freigaben ohne belastbare Spur
Wer hat welche Version wann freigegeben? Bis zum Kundenaudit sucht das Team Nachweise in Postfächern und Dateiablagen statt im Projekt.
Gates und Baselines nur auf Papier
Phasenübergänge, Freigabekriterien und eingefrorene Planstände sollen dokumentiert sein - doch ohne gemeinsames System bleibt jeder Nachweis eine manuelle Fleißaufgabe.
Sieben ASPICE-Kernelemente - und das Werkzeug, das jedes trägt
Vom Prozessreferenzmodell bis zur Assessment-Vorbereitung: jedes Element mit seiner konkreten Umsetzung. Keine Umdeutung, keine Nebenspur.
Prozessreferenzmodell (VDA-Scope: SYS · SWE · MAN · SUP)
Automotive SPICE beschreibt Entwicklung als definierte Prozessgruppen - System- und Software-Engineering, Management und unterstützende Prozesse.
Prozessgruppen als Container-Struktur - einmal als Baustein gebaut
Jeder Prozessschritt entsteht als Strukturknoten in drei Typen - Container, Meilenstein und Quality Gate. Pro Container schalten Sie gezielt aus 13 Funktionsbereichen zu, was der Schritt wirklich braucht. Ein einmal aufgebautes SYS/SWE/MAN/SUP-Gerüst speichern Sie als wiederverwendbaren Baustein und fügen es in jedes Projekt ein.
Das V - Spezifikation und Verifikation
Im V steht jeder Spezifikationsebene links eine Verifikations- oder Validierungsebene rechts gegenüber - von den Systemanforderungen bis zum Systemtest.
Phasen, Meilensteine und Gates - über typisierte Abhängigkeiten verdrahtet
Sie modellieren die linke und rechte Seite des V aus Phasen, Meilensteinen und Quality Gates und verbinden zusammengehörige Ebenen über Abhängigkeiten in vier Typen mit Zeitversatz. Die Netzplanberechnung liefert früheste und späteste Lagen, kritischen Pfad und Puffer; ein Ringschluss-Check warnt vor zyklischen Abhängigkeiten.
Anforderungen und Prüfungen als eigene Objekte
ASPICE führt Anforderungen über alle Ebenen - Stakeholder-, System- und Software-Anforderung - mit prüfbaren Akzeptanzkriterien und zugehörigen Prüfungen.
Anforderungs- und Prüfobjekte mit Ebenen, Kriterien und Ergebnissen
Jede Anforderung ist ein eigenes, versioniertes Objekt mit Ebene, Attributen und Akzeptanzkriterien - aus denen sich der Prüffall direkt ableitet. Prüfläufe halten Ergebnis, Prüfer und Nachweis fest; ein fehlgeschlagener Lauf erzeugt den verknüpften Fehlerbericht.
Bidirektionale Rückverfolgbarkeit, Abdeckung und Konsistenz
ASPICE verlangt, Anforderungen, Design und Prüfungen beidseitig zu verknüpfen, lückenlos abzudecken und konsistent zu halten.
Trace-Matrix mit Abdeckungsanalyse und Suspect-Links
Anforderungen, Prüffälle und Ergebnisse sind über typisierte, beidseitige Verknüpfungen verbunden; die Trace-Matrix zeigt je Ebene die Abdeckung und markiert Anforderungen ohne Prüfung. Ändert sich eine Anforderung, werden abhängige Prüfungen automatisch als „zu prüfen“ gekennzeichnet, bis sie erneut bestätigt sind.
Arbeitsergebnisse - versioniert und freigegeben
Jeder Prozess erzeugt über seine Base Practices definierte Arbeitsergebnisse mit nachvollziehbarem Reifegrad und Freigabestand.
Automatische Versionierung, dreistufige Freigabe, Dokumente aus Vorlagen
Dokumentation wird bei jeder inhaltlichen Änderung automatisch versioniert und lässt sich Fassung für Fassung wiederherstellen. Statusberichte durchlaufen die Freigabe Entwurf → eingereicht → freigegeben und frieren ihre Werte danach ein. Aus eigenen Vorlagen in sieben Kategorien entstehen Projektauftrag, Statusbericht oder Abschlussbericht direkt aus den Projektdaten.
Konfigurations-, Änderungs- und Problemmanagement (SUP.8 · SUP.9 · SUP.10)
Die unterstützenden Prozesse halten Änderungen kontrolliert, Hinweise nachvollziehbar und Planstände als Baseline fest.
Vom Hinweis zum Änderungsantrag zur neuen Baseline
Auffälligkeiten typisieren Sie als Incident-Arbeitspakete, aus denen ein Änderungsantrag mit Genehmiger und Auswirkungs-Dimensionen wird - inhaltlich verknüpft mit dem betroffenen Risiko. Freigegebene Planstände frieren Sie als Baseline ein und blättern schreibgeschützt durch die gesamte Planungshistorie.
Capability Levels und Assessment-Vorbereitung
Automotive SPICE bewertet Prozesse auf Reifegraden von Level 0 bis 5 - die Vorbereitung braucht lückenlose, belegbare Nachweise.
Reifegrad als eigene Felder, Nachweise aus dem Audit-Trail
Prozessattribute und Reifegrade bilden Sie als eigene, auch berechnete Felder mit rollenbasierter Sichtbarkeit ab. Den Nachweis liefert ein systemweiter Audit-Trail über Datum, Nutzer und Aktion, dazu die Abstimmungshistorie jedes Quality Gates und dreistufig gesperrte Freigaben. Eine Volltextsuche erreicht dabei 32 Entitätstypen.
ASPICE-Assessment: Ablauf und Vorbereitung
Wie ein Automotive-SPICE-Assessment typischerweise abläuft - und wo die Nachweise dafür entstehen
- 1
Scope festlegen
Auftraggeber und Lead-Assessor legen fest, welche Prozesse bis zu welchem Capability Level bewertet werden - häufig die Prozesse des VDA-Scopes bis Level 2 oder 3.
Nachweis in WORKSPACE.PMDie Prozessgruppen stehen als Container-Struktur im Projekt und machen den Scope sichtbar.
- 2
Nachweise sichten
Die Assessoren prüfen Arbeitsergebnisse wie Anforderungen, Architektur, Prüfnachweise, Pläne und Statusberichte. Es zählt, was im Projekt tatsächlich entstanden ist.
Nachweis in WORKSPACE.PMVersionierte Dokumentation, freigegebene Statusberichte, Anforderungen und Prüfläufe an einem Ort.
- 3
Interviews führen
Projektleitung und Entwicklung erläutern, wie sie arbeiten. Die Aussagen werden mit den Nachweisen abgeglichen.
Nachweis in WORKSPACE.PMGate-Abstimmungen mit Votum und Kommentar belegen, wer wann was entschieden hat.
- 4
Prozessattribute bewerten
Jedes Prozessattribut wird mit N, P, L oder F bewertet (nicht, teilweise, weitgehend, voll erfüllt). Daraus ergibt sich das erreichte Capability Level je Prozess.
Nachweis in WORKSPACE.PMReifegrade je Prozess als eigene Felder, gebündelt in Kennzahlen und Dashboards.
- 5
Bericht und Verbesserung
Der Assessment-Bericht nennt Stärken und Schwächen je Prozess. Aus den Schwächen wird der Maßnahmenplan bis zum nächsten Assessment.
Nachweis in WORKSPACE.PMMaßnahmen als Arbeitspakete mit Verantwortlichen und Terminen verfolgen.
Ein Assessment bewertet die Prozesse Ihrer Organisation und wird von qualifizierten, in der Regel intacs-zertifizierten Assessoren durchgeführt. WORKSPACE.PM ersetzt das nicht - es sorgt dafür, dass die geforderten Nachweise im Projekt entstehen und auffindbar sind.
MAN.3, SWE.5 und MLE: Was die Prozesse fordern
Drei häufig gesuchte Prozesse - kurz erklärt und mit der Umsetzung im Werkzeug
MAN.3Projektmanagement
Der Prozess fordert
MAN.3 verlangt, dass ein Projekt Umfang, Lebenszyklus, Machbarkeit, Aktivitäten, Schätzungen und Ressourcen, Schnittstellen und Zeitplan festlegt, überwacht und bei Abweichungen anpasst - und den Fortschritt regelmäßig berichtet.
So unterstützt WORKSPACE.PM
Projektstruktur mit Phasen, Meilensteinen und Quality Gates, Netzplan mit kritischem Pfad und Puffer, Baselines für freigegebene Planstände, Ressourcenplanung und Statusberichte mit dreistufiger Freigabe.
SWE.5Integration und Integrationsverifikation
Der Prozess fordert
SWE.5 regelt, wie Software-Komponenten integriert und die Integration geprüft wird: Strategie, Prüfspezifikation, Durchführung und belegte Ergebnisse. In Automotive SPICE 3.1 heißt der Prozess „Software Integration and Integration Test“, in 4.0 „Software Component Verification and Integration Verification“.
So unterstützt WORKSPACE.PM
Prüfobjekte tragen eine Prüfebene wie Integration, sind mit den Anforderungen verknüpft und halten jeden Prüflauf mit Ergebnis fest. Ein fehlgeschlagener Lauf bleibt als Nachweis erhalten.
MLEMachine Learning Engineering (ASPICE 4.0)
Der Prozess fordert
Automotive SPICE 4.0 hat Prozesse für KI-Komponenten ergänzt: MLE.1 bis MLE.4 für Anforderungen, Architektur, Training und Test von ML-Modellen, dazu SUP.11 für das Management der Trainingsdaten.
So unterstützt WORKSPACE.PM
Die ML-Prozesse legen Sie wie jede andere Prozessgruppe als Container an. Der KI-Assistent hilft bei der Projektarbeit selbst: Projektstruktur und Meilensteine aus einem Dokument entwerfen, Risikolisten vorschlagen - schreibende Aktionen erst nach Ihrer Bestätigung.
Tailoring steckt im Container - je Teilprojekt die passende Tiefe
ASPICE-Projekte laufen selten monolithisch: die Systemseite streng nach Gates, Software-Stränge iterativ. Genau das leisten Container-Bausteine - jedes Teilprojekt aktiviert nur die Funktionen, die es braucht: Quality Gates und Berichtswesen im Gesamtprojekt, Board und Sprints im Entwicklungsstrang. Eine Struktur, mehrere Arbeitswelten, ein Nachweisweg.
Wo Automotive SPICE zählt
Projektwelten und Teams, die von prozesssicherer Umsetzung am meisten profitieren
Häufige Fragen zu Automotive SPICE in WORKSPACE.PM
Welche konkreten Werkzeuge die ASPICE-Umsetzung im Alltag tragen
Über die Container-Struktur: Jeder Prozessschritt wird als Container, Meilenstein oder Quality Gate angelegt, pro Container schalten Sie aus 13 Funktionsbereichen genau das zu, was der Schritt braucht. Ein komplettes SYS/SWE/MAN/SUP-Gerüst speichern Sie als wiederverwendbaren Baustein und fügen es in jedes neue Projekt ein - inklusive Phasen-Pipeline mit Quality Gates.
Anforderungen, Prüffälle und Ergebnisse sind eigene, versionierte Objekte, die über typisierte, beidseitige Verknüpfungen zusammenhängen. Die Trace-Matrix zeigt je Ebene die Abdeckung und listet Anforderungen ohne Prüfung. Ändert sich eine Anforderung, markiert das System abhängige Prüfungen automatisch als „zu prüfen“, bis sie erneut bestätigt sind - Ansichten und Statusberichte bündeln den Stand.
Dokumentation wird bei jeder inhaltlichen Änderung automatisch versioniert und lässt sich fassungsweise wiederherstellen. Ein Verifizierungsstand hält fest, wer wann geprüft hat, und verfällt nach einem einstellbaren Intervall automatisch. Statusberichte durchlaufen die dreistufige Freigabe Entwurf → eingereicht → freigegeben und frieren ihre Werte danach ein.
Änderungsanträge tragen Kategorie, Auswirkungs-Dimensionen und einen Genehmiger und verknüpfen sich inhaltlich mit dem betroffenen Risiko - samt Ursprungsproblem und Risikoeinschätzung. Wiederkehrende Prüf- und Freigabeschritte lösen Sie als Workflow automatisiert aus.
Ein systemweiter Audit-Trail protokolliert Datum, Nutzer und Aktion über 32 Entitätstypen hinweg, jede Quality-Gate-Abstimmung bleibt mit Votum und Kommentar erhalten, und Freigaben sind dreistufig gesperrt. Kennzahlen und Portfolio-Reporting bündeln den Reifegrad je Prozess in Dashboards.
Ja: Sie modellieren die V-Struktur aus Phasen, Meilensteinen und Quality Gates und verbinden zusammengehörige Ebenen über Abhängigkeiten in vier Typen. Die Netzplanberechnung liefert kritischen Pfad und Puffer; für rein sequenzielle Systementwicklung ist das V-Modell zusätzlich als eigene Methode hinterlegt.
Das legt der Auftraggeber fest. In der Automobilindustrie wird häufig Capability Level 2 für die Prozesse des VDA-Scopes verlangt, teils Level 3. Level 2 heißt: Der Prozess wird geplant, überwacht und angepasst, und seine Arbeitsergebnisse werden gelenkt. In WORKSPACE.PM pflegen Sie den Reifegrad je Prozess als eigene Felder und bündeln ihn in Kennzahlen und Dashboards.
Version 4.0 des VDA ergänzt unter anderem die Prozessgruppen Hardware Engineering (HWE) und Machine Learning Engineering (MLE), die Validierung (VAL.1) und das Management von ML-Daten (SUP.11) und fasst die Test- als Verifikationsprozesse neu. Wer von 3.1 umsteigt, ordnet Prozesse wie SWE.5 und SWE.6 neu zu - in WORKSPACE.PM passen Sie dafür die Container-Struktur Ihres Bausteins an.
Nein. Ein Assessment bewertet die Prozesse Ihrer Organisation, nicht ein Werkzeug, und wird von qualifizierten Assessoren durchgeführt. WORKSPACE.PM sorgt dafür, dass die geforderten Nachweise im Projekt entstehen, versioniert sind und über den Audit-Trail nachvollziehbar bleiben.
Anforderungsmanagement in WORKSPACE.PM
Der Teil dieser Methode, der am meisten Werkzeug braucht - als eigener Bereich.
Verwandte Methoden
Wenn Ihre Entwicklung mehrere Standards führt
Bringen Sie Ihre ASPICE-Prozesse ins System - prüfbar von der ersten Phase an
Starten Sie kostenlos und legen Sie Prozessgruppen, Gates und Nachweise in Minuten an.