Automotive SPICE® - Capability Level 2 und 3 in der Praxis

Prozessspezifische Interpretationsvorschläge

Pierre Metz

• Verlag: dpunkt.verlag
• Jahr: 2016
• ISBN drucken: 9783864903601
• eBook-ISBN: 9783960880103
• Thema: Informatik
• Thema: Qualitätssicherung & Prüfung

Automotive SPICE ist das in der Automobilindustrie weltweit verbindliche 6-stufige Bewertungsmodell für Produktentwicklungsabläufe für softwarebasierte Systeme. Die abstrakte Formulierung des Bewertungsmodells führt jedoch häufig zu Verständnisschwierigkeiten, die eine ineffiziente Prozessumsetzung oder sogar Divergenzen in Assessmentergebnissen nach sich ziehen können. An dieser Stelle setzt das Buch an: Es bietet einen praxisorientierten Überblick über den zweiten und dritten Prozessreifegrad des Modells und liefert prozessspezifische Interpretationshilfen der generischen Praktiken anhand konkreter Beispiele für die Anwendung in der Praxis: • Verstehen der Bedeutung der Capability Level 0 bis 5 • Capability Level 2 – praktisches Verständnis der generischen Praktiken • Capability Level 2 – prozessspezifische Interpretation • Capability Level 3 – praktisches Verständnis der generischen Praktiken • Bewertungshilfen für Capability Level 1 Prozessspezifische Bewertungshilfen, Bewertungsregeln für Assessments sowie Querbezüge zwischen den Prozessen und Capability Levels zum direkten Nachschlagen unterstützen dabei, ein in sich konsistentes Assessmentergebnis zu erzielen. Das Buch richtet sich in erster Linie an Praktiker, die einen leichteren Einstieg in Automotive SPICE – Capability Level 2 und 3 – und eine Hilfestellung für die Umsetzung in der Praxis suchen.

1 Wie ist dieses Buch zu lesen?

Folgende Lesereihenfolge ist ideal:

In Kapitel 2 …

… werden außerhalb des Glossars (Anhang A) bestimmte Begriffe und Konzepte erläutert, die für Erklärungen sehr oft herangezogen werden.

Kapitel 3 …

… ist insbesondere für den Einsteiger in Automotive SPICE gedacht, für Erfahrene dient es nochmals zur Erinnerung. Es beschreibt die klare Abstraktionsebene von Automotive SPICE als ein Prozessbewertungsmodell. Es erläutert jeden einzelnen der Capability Level (CL) 0 bis 5 und beschreibt, wie diese aus welchem Grund aufeinander aufbauen. Außerdem wird kurz begründet, warum Automotive SPICE und agile Praktiken und Methoden sich nicht widersprechen. sondern im Gegenteil ergänzen.

Für Kapitel 4 …

… sind damit die Voraussetzungen (für eine grundlegende Interpretation des CL2) geschaffen, es sollte vor Kapitel 5 (prozessspezifische Interpretation des CL2) gelesen werden. Warum?

Kapitel 4 liefert erst einmal über die sehr begrenzten Erklärungen in Automotive SPICE hinaus ein ausführliches Verständnis und Beispiele dafür, was die einzelnen Generic Practices (GP) wollen und wie sie fachlich zusammenspielen. Dies interpretiert Kapitel 4 aber allgemein, das heißt noch nicht spezifisch für einen bestimmten Prozess. Dies geschieht dann in Kapitel 5 für die Prozesse des HIS Scope. Kapitel 4 ist also die Basis, um die spezifischen Anleitungen in Kapitel 5 zu verstehen.

Für Kapitel 5...

… habe ich kein durchgängiges Praxisszenario gewählt. Szenarien können immer nur bestimmte Aspekte und Umsetzungslösungen zeigen, andere wichtige Alternativen bleiben dabei auf der Strecke. Ziel ist es hier aber, möglichst breitgefächerte Möglichkeiten aufzuzeigen.

Die Reihenfolge der Prozesse in Kapitel 5 orientiert sich entlang des V-Mo-dell-Prinzips von links oben nach rechts unten. Innerhalb der Prozesse folgen die Erklärungen der GP einer anderen Reihenfolge als deren Nummerierung, weil dies didaktisch vorteilhafter ist (z. B. wird erst erklärt, welche die möglichen Ressourcen sind, um danach für die personellen Ressourcen angeben zu können, welche Verantwortlichkeiten sie haben). Für manche Prozesse werden auch mehrere GPs in einem Unterkapitel zusammengefasst und im Zusammenwirken erläutert, damit hier der Lesefluss und das Verständnis nicht künstlich unterbrochen wird (z. B. Ressourcen, Verantwortlichkeiten & Befugnisse und Stakeholder bei SYS.3 Systemarchitektur).

Da das Buch primär ein Nachschlagewerk sein soll, wiederholen sich in Kapitel 5 über die Prozesse hinweg viele Aussagen (z. B. welche Arbeitsprodukte bei Testprozessen wie zu prüfen sind), um »zerfleddernde« Verweise und damit zu viel Hin- und Herblättern zu reduzieren. Um auf der anderen Seite aber auch zu große Redundanz zu vermeiden, sind bestimmte Diskussionen, die für mehrere Prozesse gleichzeitig gelten, in eigene Kapitel ausgelagert (z. B. Voraussetzungen an Ausbildung für den Umgang mit Werkzeugen oder Gemeinsames für SUP.8, SUP.9 und SUP.10).

Kapitel 6 liefert …

… praktische Erklärungen und Beispiele, wie die Generic Practices des Capability Level 3 in der Praxis für alle Prozesse interpretiert werden können. Man sollte Kapitel 4 vorher gelesen haben, Kapitel 5 ist jedoch nicht notwendig.

Bei CL3 wird nicht die Disziplin des Process Change Management oder Methodiken für programmatische, organisationsweite Prozessverbesserungsprojekte behandelt. Kapitel 6 braucht als Voraussetzung bzw. zum Verständnis Kapitel 2.

Der Capability Level 3 ist abstrakter und hat eine andere Zielsetzung als Capability Level 2. Daher finden sich hier anders als bei CL2 keine durchgehenden, direkten prozessspezifischen Beispiele. Dies käme einem beliebigen konkreten Prozesssystem und damit nur einem von vielen Szenarien gleich und würde bedeuten, dass einschlägige Literatur über Methoden wiederholt werden müsste.

Bewertungsregeln für Assessments

Automotive SPICE ist voller expliziter oder impliziter fachlicher Querbezüge über Prozesse und Capability Level. Um ein Assessmentergebnis in sich konsistent zu halten, werden Querbezüge für CL2 am Schluss von Kapitel 4 zum direkten Nachschlagen für den Assessor aufgezeigt, und zwar in Form von:

• Abwertungsgründen
• Nicht-Abwertungsgründen
• Konsistenzwarnern
  Dies sind Hinweise, von denen man nicht pauschal sagen kann, dass sie Abwertungsgründe darstellen. Das hängt von der konkreten Situation ab:
  • Ob z. B. das Reagieren auf Abweichungen bei GP 2.1.4 Anpassen der Prozessdurchführung über SUP.9 Problemlösungsmanagement laufen muss oder nicht, hängt davon ab, welche Typen von Phänomenen für die Problemlösungsstrategie nach SUP.9 definiert wurden.
  • Zum Beispiel besorgen GP 2.1.2, GP 2.1.3 und GP 2.1.4 das Steuern eines Prozesses gegen seine individuellen Prozessziele, daher korrelieren diese GPs mit allen BPs bei MAN.3 Projektmanagement, die »Definiere, überwache und passe an …« im Namen tragen. Die Ziele des gesamten Projekts sind aber nicht immer nur die Summe aller individuellen Prozessziele.

Bewertungshilfen gibt es für CL3 am Ende des Kapitels 6 und zusätzlich (über den eigentlichen Zweck des Buchs hinaus) für CL1 in Kapitel 7.

Es existieren zudem auch innerhalb von Kapitel 5 verschiedene prozessspezifische Bewertungshilfen.

Was für alle Kapitel gilt

Dieses Buch ist als ein Nachschlagewerk für Praktiker, aber auch Assessoren gedacht. Der Fokus dieses Buchs liegt auf Capability Level 2 und 3, manchmal aber lässt sich etwas nicht ohne Bezug zu Capability Level 1 erklären. Solche Bezüge und Hintergründe sind deshalb als Exkurse grau unterlegt. Ebenfalls in grauer Umrahmung finden sich Hinweise für Assessoren. Diese sind für Praktiker interessant, aber nicht unbedingt notwendig.

Auf generische Ressourcen gehe ich nicht ein, weil diese weniger Verständnis bieten als die generischen Praktiken und weil sie erfahrungsgemäß kaum praktische Relevanz haben.

Da Automotive SPICE v3.0 sich durch das Plug-in-Konzept bewusst von der Softwarezentrierung weg in Richtung mechatronischer Gesamtsysteme geöffnet hat, nutze ich als Standardbeispiele eine automatische Heckklappe und einen Fensterheber, um dies zu illustrieren.

Dieses Buch bietet keine Sammlung von konkreten prozessspezifischen Methodenbeschreibungen. Es wird auch nicht die einschlägige Fachliteratur wiederholt. Einzelne Ausnahmen sind der Use-Case-Ansatz für die Anforderungsanalyse oder eine selbst vorgeschlagene Methode zum Analysieren von Abhängigkeiten von Funktionalitäten.

Es enthält auch weder für CL2 noch für CL3 Diskussionen über Eignung oder Vor- und Nachteile konkreter am Markt befindlicher Softwarewerkzeuge (Tools). Werkzeuge sind immer »Diener« von Prozessauslegungen, sie sind nicht die Voraussetzungen dafür. Auch ist die Werkzeugwahl kontextabhängig und durchaus auch subjektiv getrieben. Ich beschränke mich daher darauf, Eigenschaften und Möglichkeiten von Softwarewerkzeugen zu nennen, um zu illustrieren, welcher Vorschlag sich nur lohnt, wenn er automatisiert werden kann.

Dementsprechend werden im Buch keinerlei Inhalte von ISO, IEC, IEEE-Standards etc. zitiert oder referenziert. Diese sind ähnlich abstrakt wie Automotive SPICE und bieten daher keinen zusätzlichen Mehrwert für ein Detailverständnis.

Automotive SPICE ist ein Derivat der ISO/IEC 15504-5:2006. Zum Veröffentlichungszeitpunkt dieses Buchs ist die ISO/IEC 15504 noch nicht vollständig durch ihre Revision, ISO/IEC 330xx, ersetzt. Bei Hinweisen für Assessoren und Exkursen wird daher auf Teile sowohl der ISO/IEC 330xx als auch der ISO/IEC 15504 referenziert.

Die Inhalte dieses Buchs gehen auf ein Tutorial der Konferenz »SPICE Days« in 2009 zurück [Metz 09]. In 2016, also während der Finalisierung dieses Buchs, begann der VDA/QMA Arbeitskreis (AK) 13 an Interpretationsrichtlinien für Automotive SPICE 3.0 zu arbeiten [VDA_BG]. Durch meine Mitarbeit dort lag ein Entwurf des Buchs dem AK 13 zur Kenntnis vor. Dort, wo im AK 13 Inhalte ohne oder vor dem Blick in den Entwurf entstanden sind, aber Buchinhalte berührt werden oder überlappen, habe ich den zukünftigen Blau-Gold-Band (BGB) des VDA referenziert.

2 Erläuterung im Buch referenzierter Konzepte

Wegen ihrer durchgehenden Benutzung in Kapiteln 4, 5 und 6 werden hier bereits vorab wichtige Konzepte und Begriffe beschrieben. Weitere Begriffe sind im Glossar am Ende des Buchs erklärt.

2.1 Produktlinie

Dieser Begriff wird international nicht unbedingt einheitlich verstanden. In diesem Buch steht er für eine Produktkategorie, für die vorgefertigte Standardproduktdokumentation unter Traceability auf allen Ebenen des V-Modell-Prinzips existiert. Eine Produktlinie kann dabei sowohl auf der Ebene eines ganzen Systems wie auch nur für Software existieren (s. u. Standard-SW-Komponente). Diese Standardproduktdokumentation beinhaltet auf Systemebene, Hardwareebene und Softwareebene Folgendes:

• Anforderungen und Testfälle und dazugehörige Prüfnachweise (im Sinne von Review, Inspektion etc.)
• Architektur und Integrationstestfälle und dazugehörige Prüfnachweise
• Komponentendesign und Testfälle sowie dazugehörige Prüfnachweise

Auf Systemebene kommen noch zusätzlich hinzu:

• Produkt-FMEAs mit vormodellierten Fehlernetzen sowie Entdeckungs- und Vermeidungsmaßnahmen

Auf Softwareebene ...

Inhaltsverzeichnis

• Cover
• Titel
• Impressum
• Vorwort
• Inhaltsübersicht
• Inhaltsverzeichnis
• Kapitel 1: Wie ist dieses Buch zu lesen?
• Kapitel 2: Erläuterung im Buch referenzierter Konzepte
• Kapitel 3: Verstehen der Capability Level 0 bis 5
• Kapitel 4: Capability Level 2 – praktisches Verständnis der generischen Praktiken
• Kapitel 5: Capability Level 2 – prozessspezifische Interpretation
• Kapitel 6: Capability Level 3 – praktisches Verständnis der generischen Praktiken
• Kapitel 7: Bewertungshilfen für CL1
• Anhang
• Index
• Fußnoten