top of page

ASPICE in der Praxis - so geht es!

Aktualisiert: vor 4 Tagen

Bild 1 - Im Validierungs-Umfeld muss man Aufpassen wie ein Fuchs


Validierungsaktivitäten sind ein Hauptbestandteil in ASPICE. Entsprechend dem V-Model besteht auf jeder Ebene, also von der Gesamtsystemarchitektur bis zur Einzelkomponente, ein Validierungsschritt.


Bei Entwicklungsprojekten in der Automobilindustrie, die ASPICE (Automotive SPICE) anwenden, wird oft empfohlen, dass etwa 20 bis 30 Prozent des gesamten Aufwands auf Tests und Qualitätssicherung entfallen. Der genaue Anteil kann jedoch je nach Projektkomplexität, Anforderungen und spezifischen Prozessen variieren. Es ist wichtig, eine angemessene Teststrategie zu entwickeln, um die Qualität und Sicherheit der Software zu gewährleisten.


In jeder Phase vom Projekt muss der Testmanager aufpassen wie ein Fuchs, um den Testprozess erfolgreich umzusetzen. Folgende Vorgehensweise empfehlen wir um von Anfang an die richtigen Schritte vorzunehmen:

  1. Analyse der Anforderungen: Die optimalen Anforderungen wird es nie geben, sind aber eine nicht wegzudenkende Basis unserer Testarbeit. Es ist sicherzustellen, dass die Anforderungen möglichst vollständig, konsistent und eindeutig sind. Weiters spart es Zeit, wenn die Anforderungen systematisch geschrieben sind. Weiters ist darauf zu achten, dass Anforderungen so formuliert sind, dass es möglich ist diese vollständig zu testen. Ist das nicht der Fall, dann muss der Testmanager eine Nachbesserung einfordern, um nicht bei der auf Anforderungen basierten Testfallerstellung zu scheitern.

  2. Anforderungspakete schrittweise umsetzen: Manche Anforderungen sind bereits besser beschrieben, haben eine höhere Reife oder sind leichter umzusetzen. Diese sollten in Arbeitspakete zusammengefasst und zuallererst umgesetzt werden. Ähnliche Tests können dadurch leichter abgeleitet werden, da die Abarbeitung von ähnlichen technischen Themen eine mehrfache Einarbeitung erspart.

  3. Auswahl der Testumgebung und Hilfsmittel:

    Die passende Auswahl an Hilfsmittel, wie zum Beispiel der Testumgebung, den Test-Frameworks, der Skript- und Programmiersprachen ist spezifisch und abhängig von der Teststufe und hat einen erheblichen Einfluss auf Testbarkeit und erstellungs- bzw. Durchführungsdauer. Deshalb ist es unerlässlich sich bei der Entscheidungsfindung genau zu überlegen, welche Vor- und Nachteile ein Tool hat. Noch besser ist es die Tool-Entscheidungen im Projekt zu treffen.

  4. Inbetriebnahme und Wartung von Testumgebungen:

    Es ist sicherstellen, dass die Testumgebungen und DUTs (Device Under Test) aktuell sind, einwandfrei funktionieren und mit den neuesten Builds und Daten aktualisiert sind.


  5. Den Testprozess mit einer Requirement-Traceability-Matrix beginnen: Die Requirement-Traceability-Matrix ist eine (Excel) Tabelle, die Anforderungen (representiert als Zeilen der Tabelle) mit entsprechenden Testfällen (Spalten in der Tabelle) verbindet. Das Erstellen dieser Tabelle um die Anforderungen mit Testfällen zu verbinden ist am Anfang mit signifikanten Aufwand verbunden, jedoch im Laufe des Testprozesses, durch Vermeidung von redundanten Tests innerhalb weniger Arbeitstage, bezahlt macht. Am Anfang des Testprozesses soll nur ein, möglichst einfaches Arbeitspaket oder Feature in die Matrix zum Testen aufgenommen werden. Im Laufe des Testprozesses ist es empfohlen die notwendigen Metriken initial über Vorlagen von kooperativen Tools wie Jira oder Polarion zu verwenden. Ein Standard-Reporting ist ebenfalls in der Testerweiterung von Jira verfügbar und es kann auf Knopfdruck ein Testreport generiert werden. Polarion bietet die Möglichkeit Metriken graphisch darzustellen.

  6. Durchführung der Tests: Die am wichtigsten zu klärende Frage ist der Grad der Testautomatisierung, also wieviel Prozent der Tests ohne manuelle Schritte durchgeführt werden können. Vorteil liegt klar in der Zeitersparnis bei Regressionen. Nachteil ist der höhere Implementierungsaufwand im Vergleich zu manuellen Tests. Weiters kann das Ausführen automatisierter Tests im Rahmen einer Continuous Testing Umgebung, zum Beispiel GitHub, eingebunden werden. Darüber hinaus könne die beiden Entwicklungsprozesse CI/CD, also Continuous Integration und/oder Continuous Deployment, mit dem Testsystem verbunden werden. Hier ist eine enge Zusammenarbeit mit der IT notwendig, damit entsprechende Zugriffberechtigungen erteilt und zum Beispiel die Konfiguration der Firewalls angepasst werden.


  7. Fehlermanagement:

    Dokumentation, Bugfixing und Testwiederholung erfordert eine enge Zusammenarbeit mit den Entwicklern. Dies bedeutet in den meisten Projekten mittlerweile ein firmenübergreifendes Denken und ist anfangs zeitintensiv umzusetzen, da Firmen unterschiedlich funktionieren, die Kommunikationskanäle erst aufgebaut werden müssen und zum Beispiel Firewalls den Austausch von Daten unterbinden.


  8. Allgemeine Punkte wie Einplanen von Buffern, Zusammenarbeit und Kommunikation, Verbesserung und Weiterbildung, sowie Berichterstellung, Refactoring und Optimierung werden hier lediglich aufgezählt und nicht extra behandelt.



Wie kann die Testbereitschaft hinterfragt werden?


Für Testmanager ist es wichtig folgende Blocker zu identifizieren, aufzuzeigen und erst nach Fehlerbeseitigung mit den Aktivitäten fortzufahren.


  1. Klare Prozessdefinitionen und Projektmanagement: Prozesse sollten gut dokumentiert und für alle Beteiligten verständlich sein. Dies beinhaltet zumindest eine Rollen- und Aufgabenbeschreibungen und wie die Übergabe zu erfolgen hat. Effektives Projektmanagement ist entscheidend, einschließlich der Planung, Überwachung und Kontrolle von Projekten.


  2. Anforderungsmanagement: Hier ist ein systematischer Ansatz zum Erheben, Analysieren, Validieren und Verwalten von Anforderungen entscheidend. Anforderungen sollten möglichst vollständig, konsistent und eindeutig dokumentiert sein.


  3. Änderungsmanagement: Ein strukturierter Prozess für das Management von Änderungen (inklusive umfangreiche Dokumentation) sorgt dafür, dass alle Änderungen nachvollziehbar bleiben und dokumentiert werden. Dadurch kann das Testmanagement auf Änderungen reagieren und die Auswirkung auf den eigenen Bereich erfassen.


  4. Risikomanagement und Qualitätssicherung: Risiken sollten frühzeitig erkannt, bewertet und wirksame Maßnahmen zur Risikominderung implementiert werden. Eine kontinuierliche Überwachung und Anpassung der Risiken ist ebenfalls wichtig. Fehlen Qualitätssicherungsmaßnahmen, dann kann womöglich auch der Testaufwand hinfällig sein.



Welche Aktivitäten konsumieren am meisten Zeit beim Testen?


Die genaue Aufteilung von Zeitanspruch kann je nach Projekt, Organisation und spezifischem Kontext variieren. Allerdings gibt es einige allgemeine Aktivitäten, die typischerweise einen großen Teil der Testzeit beanspruchen.


Nachfolgend sind die drei zeitintensivsten Tätigkeitsfamilien aufgelistet:


  1. Testimplementierung und manuelle Testausführung - Gesamtzeitbedarf ~20 % - ~30 %: Die tatsächliche Implementierung der Testfälle, aber auch manuelle Durchführung der Tests nehmen oft den größten Zeitanteil ein.

  2. Teststrategie und Testdesign - Gesamtzeitbedarf ~30 % - ~50 %: Zu Projektbeginn nimmt das Erstellen einer Teststrategie, das Planen der Testressourcen und das Entwerfen von Testfällen einen erheblichen Teil der Gesamttestzeit in Anspruch. Diese Aktivitäten wegzulassen oder durch standardisierte Vorlagen zu ersetzt gefährdet den Projekterfolg und zieht Mehraufwände nach sich.

  3. Fehlermanagement  - Gesamtzeitbedarf ~20 % - ~30 %:

    Während der Umsetzungs- und Endphase im Projekt beansprucht das Identifizieren, Dokumentieren und Verfolgen von Fehlern signifikant Zeit, da Entwickler und Tester sehr oft eng zusammenarbeiten müssen, um effizient debuggen zu können.


Dahingegen ist die Wartung und Aktualisierung von Testfällen, das Testumgebungsmanagement, Berichterstattung und Analyse und das Automatisierung von Testfällen nur am Anfang zeitintensiv, im Projektverlauf aber langfristig gering. Ob und in welchen Ausmaß Tests zu automatisieren sind hat erheblichen Einfluss auf die Zeit- und Aufgabenaufteilung und variieren projektspezifisch sehr stark.



Die Ursachen für die größte Misserfolge bei ASPICE Implementierung?


Die Implementierung von ASPICE in einem Unternehmen kann viele Herausforderungen mit sich bringen, und es gibt mehrere häufige Ursachen für Misserfolge. Hier sind einige der Hauptgründe, warum ASPICE-Implementierungen nicht den gewünschten Erfolg erzielen:


  1. Unzureichende Ressourcen: Die Umsetzung von ASPICE erfordert viel Zeit, Geld und personelle Ressourcen. Wie unsere Erfahrung zeigt, liegt die Versuchung sehr nahe, an Ressourcen in der Validierung zu sparen. Ein Ressourcenmangel im Testbereich wirkt sich jedoch erst spät im Projektverlauf aus. Als Konsequenz erhöhen sich die Kosten und die Projektverzögerungen. Deswegen ist es unerlässlich die Ressourcenplanung nachhalten zu führen.

  2. Unzureichende Führungskompetenz:

    Fehlentscheidungen, fehlender Rückhalt oder Engagement des Managements kann dazu führen, dass die notwendigen Ressourcen und die Priorität nicht ausreichend zugeteilt werden. Führungskräfte müssen die Bedeutung von ASPICE erkennen und die praktische Umsetzung aktiv zu unterstützen.

  3. Mangelndes Verständnis und Schulung: Ein unzureichendes Verständnis der ASPICE-Standards und -Prozesse führt oft zu Fehlinterpretationen und falschen Implementierungen. Ausreichende Schulung und Sensibilisierung sind entscheidend für den Erfolg.

  4. Unzureichende Prozesse, Werkzeuge und Infrastruktur: Eine erfolgreiche ASPICE-Implementierung setzt geeignete Werkzeuge und Infrastrukturen voraus, um die Prozesse zu unterstützen. Fehlende oder ungeeignete Werkzeuge können die Effizienz und Effektivität der Prozesse mindern. Wenn Prozesse nicht klar definiert sind oder wenn es keine Anpassung an die spezifischen Bedürfnisse und Kontext des Unternehmens gibt, kann die Implementierung fehlschlagen.

  5. Allgemeine Faktoren für Misserfolg: Schlechte Kommunikation, unklare Ziele und Erwartungen, zu starke oder schwache Fokussierung auf Dokumentation und eine fehlende kontinuierliche Verbesserung


Auf das Erkennen und Überwinden dieser Herausforderungen kommt es an, um ASPICE erfolgreich zu implementieren und die Qualität und Effizienz von Entwicklungsprozessen erheblich zu steigern.

Im Englischen bedeutet das Wort „spice“ nichts anderes als „Gewürz“. Jedoch „SPICE®“, mit großen Buchstaben geschrieben, bezieht sich auf einen wichtigen internationalen Standard. In diesem Blog beschreiben wir, wie dieser Standard mit dem Zusatz "Automotive" oder kurz "ASPICE®" in der Automobilindustrie Anwendung findet.


In der aktuellen Version 4.0 wird die Abkürzung SPICE® mit "Systems Process Improvement and Capability dEtermination" angegeben und bedeutet auf Deutsch Systemprozessverbesserung und Bestimmung der Leistungsfähigkeit.


Was ist ASPICE?


ASPICE® ist ein in der Automobilbranche üblicher Leitfaden zur Strukturierung und Bewertung von Softwareentwicklungsprozessen bis hin zur Fertigungsüberleitung und kontinuierlicher Prozessverbesserung durch Bewertung in Fähigkeitsstufen. ASPICE hilft Automobilzulieferern hervorragende Methoden nach dem Prinzip der “Best Practices” zu integrieren, damit falsche Entwicklungen frühzeitig erkannt und eliminiert werden. Außerdem hilft ASPICE dabei sicherzustellen, dass die Anforderungen an den OEM, Other Equipment Manufacturer, erfüllt werden.

ASPICE® erweitert den SPICE-Standard ISO 33061, um auch für die Automobilbranche standardisierte Vorgehensweisen für die Softwareentwicklung zur Verfügung zu stellen. Die neuen Erweiterungen um Cybersicherheit und agile Vorgehensmodelle ist weiter unten ein eigener Bereich gewidmet.



Welche Stufen, auch als Level bezeichnet, kann in ASPICE erreichen werden?


ASPICE bewertet den Softwareentwicklungsprozess über Stufen. Diese Stufen reichen von Stufe 0, nicht konform beziehungsweise unvollständig, bis Stufe 5 für einen ASPICE optimierten Prozess.


Level 0 - Nicht komplett:

Es konnten keine notwendigen Prozesseigenschaften zufriedenstellend erreicht werden.


Level 1 - Prozessimplementierung (process performance):

Die Prozesseigenschaften ermöglichen die Erfüllung der Ziele.


Level 2 - Prozess- und Arbeitsergebnisse  (performance and work product management)

Ein Leistungsmanagement vom Arbeitsprodukt findet auf systematische Weise statt.

Level 3 -  (process definition and deployment)

Prozess wird basierend auf standardisierten Regeln innerhalb der ganzen Organisation gelebt.


Level 4 - Prozessmessung und Fertigungssteuerung (process measurement and control)

Die Prozessdurchführung wird konsistent gemessen, inklusive Fertigungssteuerung.


Level 5 - Prozessinnovation- und optimierung (process innovation and optimization)

Prozess wird fortlaufend optimiert und adaptiert um die wichtige Geschäftsziele zu erreichen.


Welche Bewertung gibt es in ASPICE?


Während des Assessments wird jedes dieser Prozessattribute entsprechend folgender Skala bewertet:

Label

Bewertung

Zielerreichung

Beschreibung

N

Nicht erreicht / not achieved

0% to ≤ 15%

Der bewertete Prozess erfüllte nicht die festgelegten Anforderungen für den Erfolg.

P

Teilweise erreicht / partially achieved

> 15% to ≤ 50%

Der bewertete Prozess hat einige Hinweise darauf gezeigt, dass sich die geforderte Eigenschaft annähert und teilweise erreicht wird. Bestimmte Elemente können jedoch bei der Erreichung dieser speziellen Eigenschaft weniger vorhersehbar sein.

L

Weitgehend erreicht / largely achieved

> 50% to ≤ 85%

Der bewertete Prozess hat ein klares, strukturiertes Vorgehen und einen Erfolg in Bezug auf die vorgegebenen Kriterien gezeigt. Obwohl bei dieser Eigenschaft des Prozesses gewisse Mängel vorhanden sein können, ist sie insgesamt immer noch stark.

F

Vollständig erreicht / fully achieved

> 85% to ≤ 100%

Der evaluierte Prozess hat sich als methodisch und schlüssig abgeschlossen erwiesen und erfüllt alle Kriterien für den Erfolg. Es gab keine nennenswerten Mängel im Zusammenhang mit diesem Attribut in der Bewertung des Systems.

Tabelle 1 - NPLF-Skala


Warum nutzt ASPICE das V-Modell?


Auf diese Weise wird sichergestellt, dass jeder Entwicklungsschritt von einem Testschritt gespiegelt wird. Das V-Modell® ist ein von der Bundesrepublik Deutschland geschütztes Vorgehensmodell für IT-Entwicklungsprojekte. ASPICE® nutzt das V-Modell® der Softwareentwicklung, das den Prozess in zwei Teile aufteilt:1. Die linke Seite des Buchstabens V symbolisiert die Entwurfs- und Entwicklungsschritte.

2. Die rechte Seite für die Testschritte.



Was sagen die Stufen (Level) über die Leistungsfähigkeit der Organisation aus?


Stufe/Level 0:

Die Bewertung der Stufe 0 von APICE bedeutet, dass die Aktivitäten in der Organisation ad hoc durchgeführt werden. Einige grundlegende ASPICE-Praktiken können eingehalten werden, aber nicht als direktes Ergebnis einer organisierten und zielgerichteten ASPICE-Initiative. Stufe 0 bedeutet also, dass Sie die von ASPICE definierten Arbeitsprodukte höchstens teilweise erreichen.


Stufe/Level 1:

Die Stufe 1 von APICE zeichnet sich dadurch aus, dass Arbeitsergebnisse vorhanden sind. Dadurch wird belegt, dass auch ein Prozess vorhanden ist. Beispiele für solche Arbeitsergebnisse sind Anforderungsspezifikationen, ein Testplan oder eine Teststrategie, ein Lieferantenbewertungsbericht oder andere Dokumente. Die Abdeckung ist möglicherweise nicht vollständig, aber erstreckt sich über den gesamten V-förmigen Lebenszyklus.

Auf Stufe 1 gibt es keine Bewertung, inwieweit ein bestimmtes Arbeitsprodukt ein vollständiger und integrierter Bestandteil Ihres Betriebs ist. Unternehmen, die Level 1 anstreben, können vorkonfigurierte Tools verwenden, die grundlegende ISO 26262- und ASPICE-Arbeitsprodukte für eine erfolgreiche Prozessbewertung enthalten.


Stufe/Level 2:

Die Stufe 2 bedeutet, dass die Organisation in der Lage ist, Ziele zu setzen, Prozesse zu verwalten, den Fortschritt zu überwachen und darauf entsprechend reagieren. Auf Stufe 2 werden Prozesspläne erstellt, Ressourcen geplant und überwacht sowie alle damit verbundenen Aktivitäten zielorientiert gestaltet. Arbeitsprodukte werden um Managementinformationen zu Themen wie Reviews oder Change Management erweitert.

Auf Stufe 2 ist es durchaus möglich, dass Projekte, die sich auf ähnliche Entwicklungsbereiche beziehen, erhebliche Unterschiede in der Ausführung aufweisen.



Wie kann ASPICE Stufe 1 in Ihrem Unternehmen implementiert werden?


Auf Stufe 1 steht die Prozessimplementierung im Vordergrund. Daher beurteilt der Gutachter, ob das Ergebnis des Prozesses in Bezug auf den Kontext des Projekts einschließlich des Erreichens aller Ergebnisse angemessen ist.


ASPICE schreibt keine spezifischen Tools oder Techniken vor, die Ingenieure verwenden müssen. Unternehmen steht es frei, eigene Entwicklungsprozesse zu etablieren, solange die angestrebten Ergebnisse erreicht werden. Ein ASPICE-Prüfer stellt beispielsweise fest, ob Ingenieure die Spezifikationen ihres Systems auf die Anforderungsanalyse zurückgeführt haben.

ASPICE-Gutachter verwenden eine NPLF-Skala, um zu bewerten, inwieweit das gewünschte Ergebnis erreicht wurde. Laut Skala werden die Ergebnisse entweder "nicht erreicht", "teilweise erreicht", "weitgehend erreicht" oder "vollständig erreicht". Der Bewerter vergibt eine NPLF-Bewertung für mehrere erwartete Ergebnisse und verwendet die aggregierte Bewertung, um das Gesamtfähigkeitsniveau des gesamten Projekts zu bestimmen. OEMs bestimmen, was für jedes Projekt als akzeptables Fähigkeitsniveau angesehen wird.

Die Lieferanten wählen Mitglieder ihrer Teams aus, die über mindestens drei Jahre einschlägige Berufserfahrung verfügen, um eine vorläufige ASPICE-Assessor-Schulung und -Zertifizierung zu absolvieren.

 

  1. Verstehen von ASPICE: Machen Sie sich mit dem ASPICE-Framework, seinen Prinzipien und Anforderungen, PRM und PAM vertraut.

  2. Gap-Analyse und Prozessdefinition:Bewerten Sie Ihre aktuellen Prozesse anhand der ASPICE-Anforderungen. Definieren Sie die Prozesse und Verfahren, die Sie zur Einhaltung der Vorschriften benötigen.

  3. Prozessimplementierung und Schulung:Implementieren Sie die oben definierten Prozesse und Verfahren. Schulen Sie Ihre Mitarbeiter, um die Einhaltung von APICE sicherzustellen.

  4. Prozessüberwachung, Messung und Verbesserung:Überwachen, messen und iterieren Sie kontinuierlich die ASPICE-konformen Prozesse.

  5. Interne und externe Assessments:Führen Sie interne Assessments durch und holen Sie externe Assessments durch leitende Assessoren ein.

  6. Zusammenarbeit mit Lieferanten:Arbeiten Sie mit nach- und vorgelagerten Lieferanten zusammen, um deren Einhaltung von APICE sicherzustellen.

  7. Dokumentation und Berichterstattung:Pflegen Sie eine umfassende Dokumentation und Berichterstattung über ASPICE-bezogene Aktivitäten.



Wie kann ASPICE Stufe 2 in Ihrem Unternehmen implementiert werden?

                

Auf Stufe 2 müssen alle Aktivitätenprozesstechnisch geplant, gesteuert und alle daraus resultierenden Arbeitsergebnisse hinsichtlich Konfigurationsmanagement und Qualitätssicherung berücksichtigt werden.

 

Zusätzlich müssen auf Stufe 2 Strategien mit Zielen geplant und für die Aktivitäten definiert und dokumentiert werden. Außerdem müssen Anforderungen an alle relevanten Arbeitsprodukte jedes Prozesses definiert werden. Zu diesen Anforderungen gehören Informationen wie Inhalt und Struktur, was zum Beispiel auch als Inhaltsverzeichnis ausgeführt werden kann. Sehr oft werden die Anforderungen an ein Arbeitsprodukt als Arbeitsproduktvorlage dokumentiert, einschließlich einer Anleitung zur Verwendung der Vorlage. Wenn Tools verwendet werden, sollte die Verwendung dieser dokumentiert werden.


  1. Verantwortlicher:Nennung einer Person, die für die ASPICE Einführung und Implementierung innerhalb der Organisation zuständig wird


  1. Ausbildung:Sicherstellung der notwendigen Ausbildung über ASPICE für ASPICE Owner und für die Personen, welche in der Implementierung von ASPICE aktiv beteiligt werden.


  1. Analyse: Analyse des Berichtes von misslungener ASPICE Zertifizierung in Hinblick auf überprüfte Prozesse, Ergebnisse, Ergebnisse der Prüfung von einzelnem Prozessen und identifizierten der Defizite.


  1. Aktionspläne:Ausarbeitung von detaillierten Aktionsplänen zur Erreichung von Level 2 Assessment für die zu überprüfenden Prozesse.


  1. Kontrolle:Implementierung von diesen Plänen unter strenger Management Kontrolle.


Eine Softwareentwicklungsfirma für die Automobilindustrie ist konform zu ASPICE, wenn sie beim Entwicklungsprozess oben genannte Prozesse erfüllt. Ein Erfüllungsgrad kann im Rahmen eines Audits durch einen unabhängigen Auditor verifiziert werden.


Abschließend, um auf die im Titel stehende Frage zu antworten:ASPICE ist für eine Firma, die für die Automobilindustrie Software entwickelt, eine vom Kunden geforderte Notwendigkeit, um „im Spiel“ zu bleiben.



Welche Vorteile ergeben sich bei Verwendung von Kanban in ASPICE?


Kanban ist eine agile Methode um Arbeitspakete zu visualisieren und die verschiedene Phasen dee Arbeitsschritte darstellen. Diese einfache Methode ist in der agilen Softwareentwicklung sehr beliebt und einfach umzusetzen. In der Automobilbranche wird vermehrt Kanban eingesetzt, weil es folgenden entscheidenden Vorteil gegenüber dem V-Model besitzt:


Das V-Modell braucht viel Zeit bis eine Anforderungsänderung umgesetzt ist, weil auch alle im Vorfeld erstellten Tests anzupassen sind. Hier kann Kanban helfen, weil das Team selbst bestimmt wann welche Aufgabe umgesetzt wird. Da werden zum Beispiel Tests zu Anforderungen erst dann umgesetzt, wenn sicher ist, dass sich die dazugehörige Anforderung nicht mehr ändert.


Wie integriert man Kanban in ASPICE?


  1. Kanban-Testdurchlauf:

    Wählen Sie ein Feature und unterteilen dieses zum Beispiel über eine User Story in die notwendigen Arbeitspakete. Passen Sie auf, dass die Arbeitspakete in ungefähr einem Tag abzuarbeiten sind. Sollte ein Arbeitspaket zu groß sein, dann kann es unterteilt werden. Führen Sie den Testdurchlauf und danach eine Retrospektive aus.Jede Aufgabe wird solange unterteilt und in mehrere kleinere Arbeitspakete zerlegt, bis jedes Arbeitspaket an maximal einen Tag umgesetzt werden kann.

  2. Erstellen vom Kanban-Board:Das Team soll ein Kanban-Board mit eigenen Spalten definieren, um den Workflow zu visualisieren. Die selbst definierten Spalten können zum Beispiel "Zu erledigen", "In Bearbeitung", und "Fertig" benannt werden. Aber auch Spalten wie "Kontrolle", "Pause", "Infobeschaffung" machen Sinn und können vom Team definiert werden.

    Anhand der Teamgröße ist es wichtig für jede Spalte die Maximalanzahl an aktiven Arbeitspaketen, auch WIP oder Work-In-Progress genannt, zu definieren. Wichtig ist einen konsistenten Workflow zu gewährleisten. Zum Beispiel macht es Sinn, dass pro Mitarbeiter im Team in der Spalte "In Bearbeitung" maximal eine Aufgabe als WIP-Wert definiert wird. Das ist dann bei fünf KollegInnen im Team ein WIP-Wert von 5.


  3. Forecast:

    Nach der Umsetzung des ersten Kanban-Testdurchlaufes kann über die Abarbeitungsgeschwindigkeit anhand der Historienwerte ein realistischer Forecast bestimmt werden. So wird bestimmt, wie viele Manntage die Umsetzung der offenen Features durch Interpolation der Anzahl an Arbeitspaketen benötigt werden.


  1. Zusatzpunkt Retrospektiven: In auch spontan abgehaltenen Retrospektiven können schriftliche Arbeitsvereinbarungen getroffen werden und Feedbackschleifen durchgesprochen werden, um zum Beispiel Engpässe oder auch unnötige Schritte zu vermeiden.


Die Stärken von Kanban liegen in seiner Flexibilität und Einfachheit und eignet sich für unterschiedlichste Teams und Aufgaben.


Warum ist Cybersecurity ein Bestandteil von ASPICE?


Einige Gründe, warum "Cybersecurity" ein Bestandteil von ASPICE® ist:


  1. Steigende Komplexität:

    Fahrzeuge werden immer komplexer und stärker vernetzt, was sie anfälliger für Cyberangriffe macht. Integrierte Sicherheitsmaßnahmen sind daher unerlässlich.


  1. Standardisierung:

    ASPICE® bietet einen Rahmen für die Bewertung von Entwicklungsprozessen. Durch die Integration von Cyber-Security-Elementen kann eine standardisierte Herangehensweise an IT-Sicherheitsaspekte im Fahrzeugdesign gefördert werden.

  2. Produktsicherheit:

    Die Sicherheit und Zuverlässigkeit von Fahrzeugen hat höchste Priorität. Cyber-Security ist ein kritischer Faktor, um Sicherheitslücken zu schließen und die Integrität und Sicherheit von Fahrzeugfunktionen zu gewährleisten.

  3. Regulatorische Anforderungen:

    Es gibt zunehmende gesetzliche und regulatorische Anforderungen an die Cybersicherheit in der Automobilindustrie. Eine Integration in ASPICE hilft, diese Anforderungen systematisch zu erfüllen.

  4. Vermeidung von Risiken:

    Durch die Berücksichtigung von Cyber-Security in der Entwicklungsphase können potenzielle Schwachstellen frühzeitig identifiziert und beseitigt werden, was das Risiko von Sicherheitsvorfällen im späteren Betrieb minimiert.

  5. Steigerung des Kundenvertrauens:

    Die Kunden erwarten sichere und geschützte Systeme in ihren Fahrzeugen. Eine Integration von Cybersicherheitsstandards in den Entwicklungsprozess kann das Vertrauen in die Technologie stärken.


Die seit Juli 2021 publizierte Ergänzung „Quality Management Center des Verbands der Automobilindustrie „Automotive SPICE® for Cybersecurity – Process Reference and Assessment Model” (ASPICE® CS) leitet analog zu ASPICE® ein Prozessreifegradmodell für Cyber-security für Fahrzeughersteller in der Management Process Group MAN.7 Cybersecurity Risk Management ab.


ASPICE® CS behandelt nur die Produktentwicklung. Ausgeschlossen ist sowohl die Übergabe in die Produktion als auch die fortwährende Betreuung über den gesamten Produktlebenszyklus.


Die Fahrzeuge entwickeln sich zunehmend zu interagierenden Fahrzeugen mit künstlicher Intelligenz. Beginnend beim Infotainmentsystem mit Navigation, über smarte Matrix-LED-Lichter und Steer-/ Brake-By-Wire“ hin zum autonomen Fahren übernehmen Fahrzeugcomputer auch ASIL-relevante Aufgaben. ASIL steht für Automotive Safety Integrity Level, das sind sicherheitsrelevante Funktionen.


Die Realisierung dieser Funktionen erfordert teilweise weitreichende Zugriffsrechte auf die Fahrzeugfunktionen. Jede Schnittstelle ist dabei auch ein potenzielles Angriffsziel und stellt ein Risiko für die Fahrzeuginsassen und andere Verkehrsteilnehmer dar.

Daraus resultierende Herausforderung für Hersteller vernetzter Produkte (insbesondere Fahrzeuge) besteht somit darin, die digitale Angriffssicherheit – allgemein als Cyber-Security (CS) bezeichnet – über die gesamte Wertschöpfungskette zu gewährleisten. Es ist die Aufgabe des Fahrzeugherstellers, neben dem Projektrisikomanagement ein Risikomanagement für digitale Angriffe auf das Fahrzeug sowie dessen Infrastruktur über die gesamte Lebensdauer durchzuführen. Die gesamte Lebensdauer umfasst die Entwicklung, die Inverkehrbringung und auch die Außerbetriebnahme.


Wie wird bei ASPICE CS vorgegangen?


Nach der Planung des Inhalts bezüglich Anforderungen und Architektur über die System- und Hard/Software-Ebene sind die Risiken zu bewerten. Sind diese nach der Bewertung von Entwicklungsteams nicht tolerierbar, müssen Risikomaßnahmen abgeleitet und die Planung entsprechend angepasst werden. Projektterminplan und Projektbudget sind ebenfalls abzugegliche. Erst, wenn Inhalt, Kosten, Zeit und Risiko zueinander widerspruchsfrei sind, kann mit der Umsetzung begonnen werden. Dieser Abgleich muss im Laufe des Projekts bei jeder Planänderung erneut stattfinden.


ASPICE® CS trägt diesem iterativen Vorgehen im Sinne einer risikogetriebenen Entwicklung Rechnung. Die relative Zuordnung der ASPICE® CS Prozesse mit denen von ASPICE® hier dargestellt.


Nach der Umsetzung gilt es auf der rechten Seite des V-Modells die Erfüllung der zuvor gestellten Anforderungen zu überprüfen. Hierzu fordert ASPICE® CS für jede Ebene (Software, System) jeweils eine Verifikation auf der rechten Seite, genannt "Risk Treatment Verification", zur Überprüfung der Anforderungen der linken Seite anhand der dort definierten Tests und Testkriterien.

Um bisher unberücksichtigte Risiken aufzudecken, sieht ASPICE® zusätzlich Validierungstests, sogenannte Risk Treatment Validation. Das sind zum Beispiel Penetration-Tests. Diese erlauben es, die Erreichung der Cyber-Security-Ziele unabhängig von den identifizierten Risiken zu überprüfen. Im Rahmen der Validierung können unerkannte Risiken im Zusammenhang mit Cyber-Security aufgedeckt werden. Diese sind im Rahmen von ASPICE® aufzunehmen und zu bewerten. Wenn die Bewertung ergibt, dass die neuen Cyber-Security-Risiken adressiert werden müssen, erfordert dies einen erneuten Durchlauf vom V-Modell. Wichtiges Aspekt ist, dass im Gegensatz zur ISO 21434, ASPICE® CS nur die Produktentwicklung behandelt, nicht aber die fortwährende Betreuung über den gesamten Produktlebenszyklus bis zum Produktlebensende.


Wie wird Cyber-Security in ASPICE integriert?


Die Integration von Cyber-Security in ASPICE ist ein komplexer Prozess, der mit mehreren Herausforderungen verbunden ist. Hier sind einige der größten Schwierigkeiten:


  1. Komplexität der Normen und Standards: Sowohl Cybersicherheit als auch ASPICE bringen umfangreiche Anforderungen und Best Practices mit sich. Die Kombination beider kann zu einem komplexen Geflecht von Vorgaben führen, die schwierig zu überblicken und zu integrieren sind.


  2. Ressourcenbedarf: Die Implementierung umfangreicher Sicherheitsmaßnahmen erfordert erhebliche zeitliche, finanzielle und personelle Ressourcen. Viele Organisationen haben Schwierigkeiten, die notwendigen Investitionen in Schulung, Tools und Personal zu rechtfertigen.


  3. Unterschiedliche Zielsetzungen: Während ASPICE sich auf Prozessverbesserung und Qualitätsmanagement konzentriert, zielt Cyber-Security auf den Schutz vor externen und internen Bedrohungen ab. Die unterschiedlichen Schwerpunkte können zu Zielkonflikten und Schwierigkeiten bei der Priorisierung führen.


  4. Dynamische Bedrohungslage: Cyber-Security muss sich ständig weiterentwickeln, um neuen Bedrohungen gerecht zu werden. Diese dynamische Natur erschwert eine standardisierte Vorgehensweise, wie sie durch ASPICE vorgegeben wird.


  5. Fachkräftemangel:

    Besonders im Bereich der Cybersicherheit herrscht ein Mangel an qualifizierten Fachkräften. Dies kann die Implementierung und Aufrechterhaltung effektiver Sicherheitsmaßnahmen verlangsamen oder behindern.


  6. Integration in bestehende Prozesse:

    Die Einbindung von Cyber-Security-Anforderungen in bestehende Entwicklungsprozesse, die bereits auf ASPICE basieren, kann kompliziert sein und erfordert häufig eine umfassende Prozessneugestaltung.


  7. Bewusstsein und Kulturwandel:

    Bei der Integration von Cyber-Security geht es nicht nur um technische Lösungen, sondern auch um eine kulturelle Änderung innerhalb der Organisation. Mitarbeiter müssen hinsichtlich der Bedeutung von Sicherheit geschult und sensibilisiert werden.


  8. Messbarkeit und Assessments:

    Die Bewertung von Maßnahmen zur Steigerung der Cybersicherheit und deren Integration in ASPICE-basierte Assessments kann herausfordernd sein, da sicher designte Systeme stabil gegen potenzielle Angriffe sind.



Die Integration erfordert daher eine sorgfältige Planung und Strategie, um sicherzustellen, dass beide Disziplinen effektiv zusammenarbeiten und den spezifischen Anforderungen der Automobilindustrie gerecht werden.


Wo noch findet man weitere Ressourcen zu ASPICE und Kanban?




 
 
bottom of page