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

Pierre Metz

• Herausgeber: dpunkt.verlag
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Deutsch
• Veröffentlichungsjahr: 2016

Seitenzahl: 370

Beschreibung

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.

Leseprobe

Dr. Pierre Metz leitet den konzernweiten Aufbau der Funktionalen Sicherheit bei der Brose Fahrzeugteile GmbH & Co. KG als Teil der Unternehmensstandardprozesse für sicherheitsrelevante Mechatronikentwicklung und betreut selbst aktiv Projekte. Er ist intacs™zertifizierter SPICE und Automotive SPICE® Principal Assessor und leitete auch international Assessmentteams in den Domänen Automotive, Telekommunikation und Medizintechnik. Als intacs™akkreditierter Ausbilder für Provisional und Competent Assessoren bildet er Assessoren aus. Er ist Mitbegründer und Mitglied des intacs™-Fachbeirats und war bis 2015 Leiter der intacs™-Arbeitsgruppe für die Erarbeitung und Pflege der standardisierten, international verwendeten Kursmaterialen für die Assessorenausbildung beider Stufen.

Pierre Metz begleitete als Mitglied des VDA/QMA AK 13 die Entwicklung des in 2015 veröffentlichten Automotive SPICE® v3.0-Modells und beteiligt sich in den deutschen Normungsgremien für funktionale Sicherheit NA 052-00-32-08-01 »Allgemeine Anforderungen an Fahrzeuge« sowie NA 052-00-32-08-02 »Software und Prozesse«. Hierüber ist er zudem Mitglied der deutschen Delegation für die internationale Arbeitsgruppe der ISO 26262 (ISO TC22/SC32/WG8).

Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+:

www.dpunkt.de/plus

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

Prozessspezifische Interpretationsvorschläge

Pierre Metz

Dr. Pierre Metz

[email protected]

Lektorat: Christa Preisendanz

Copy-Editing: Ursula Zimpfer, Herrenberg

Herstellung: Birgit Bäuerlein

Umschlaggestaltung: Helmut Kraus, www.exclam.de

Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:

Print   978-3-86490-360-1

PDF   978-3-96088-009-7

ePub   978-3-96088-010-3

mobi   978-3-96088-011-0

Copyright © 2016 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Automotive SPICE® ist ein eingetragenes Warenzeichen des Verbands der Automobilindustrie e.V. (VDA). Für weitere Informationen über Automotive SPICE® siehe www.automotivespice.com.

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Vorwort

Die Entstehung dieses Buchs geht zurück auf das Jahr 2009, als ich auf der damaligen Konferenz »SPICE Days« in Stuttgart ein Tutorial zum Thema hielt, wie die generischen Praktiken der Capability Level 2 und 3 erklärt und praktisch interpretiert werden können [Metz 09]. Der Grund war, dass Automotive SPICE für diese generischen Praktiken um ein Vielfaches weniger an Erklärung bietet als für die Basispraktiken auf Capability Level 1.

Nicht lange danach riefen wir im Fachbeirat des intacs™, dem in 2006 neu gegründeten internationalen Zertifizierungsschema für Assessoren aller SPICE-Modelle, eine neue Arbeitsgruppe ins Leben, die ich damals übernahm. Diese Arbeitsgruppe hat im Schulterschluss mit der Arbeitsgruppe für die Prüfungsfragen für die Certification Bodies das komplette Ausbildungsmaterial für die Stufen des Provisional und Competent Assessors erarbeitet, was seitdem international in drei Sprachen verwendet wird. Das war der erste maßgebliche Meilenstein hin zu einem fachlichen Konsens, den es vorher in dieser Form nicht gegeben hatte. Diesen Meilenstein habe ich persönlich deshalb nicht als etwas Selbstverständliches, sondern als etwas Besonderes empfunden, weil an dessen Erstellung letztendlich mehrere konkurrierende Firmen beteiligt waren, die bis dahin ihre eigenen Ziele, Strategien und Kursmaterialien besaßen. Trotz dieser Verschiedenheiten und Konkurrenz sind die Experten dieser Häuser immer noch freundschaftlich verbunden und teilen bis heute das Ideal, gemeinsam bei und für intacs™ unser gemeinsames Fach durch Zusammenarbeit und Austausch zu verbessern und fortzuentwickeln. Es gibt meiner Überzeugung nach keine alternative Verbesserungsmöglichkeit als die des fachlichen Auseinandersetzens und Arbeitens an gemeinsam genutzten Ergebnissen. Seitdem sind viele weitere Unternehmen und Häuser zur intacs™-Arbeitsgruppe »Kursmaterialien« hinzugekommen, deren Leitung ich 2015 abgegeben habe, um den VDA/QMA-Arbeitskreis 13 sowie die nationalen und internationalen Normungsgremien der funktionalen Sicherheit (NA 052-00-32-08-0,1 NA 052-00-32-08-02, ISO TC22/SC32/WG8) unterstützen zu können.

Das damalige Tutorial ist von Anfang an in diese Ausbildungsunterlagen eingeflossen. Nun ist dennoch in den jeweils fünftägigen, intensiven Ausbildungen für SPICE-Assessoren natürlich nicht genug Zeit, um jedes noch so kleine fachliche Detail unterzubringen, was die praktische Erfahrung mit dem Modell ausmacht. Daher sind unter anderem Fachbücher notwendig, die die Möglichkeiten des Dazulernens erweitern. Auch bei mir entstand deshalb, nachdem die Fachkollegen bereits ihre Bücher über SPICE und Automotive SPICE auf den Weg gebracht hatten, seit 2009 der Wunsch, mein Tutorial weiterzuentwickeln und als Buch anzubieten. Dies passte meiner Beobachtung nach auch deswegen sehr gut, da die bisher vorhandene Fachliteratur den maßgeblichen Schwerpunkt auf die Praxis des Capability Level 1 legt und meine Erfahrung deshalb, so hoffe ich, ein ergänzendes Angebot darstellt. Letztendlich enthält der Inhalt dieses Buchs meine persönlichen Erfahrungen, Lösungen in der Praxis und fachliche Meinung, die man im Detail natürlich auch immer anders sehen kann. Gerade aber im Hinblick auf die oben beschriebene Philosophie des offenen Austauschs und der stetigen Weiterentwicklung des Fachs freue ich mich jederzeit sehr über Kritik und Feedback über [email protected].

Der VDA/QMA-Arbeitskreis 13 arbeitet seit der Veröffentlichung von Automotive SPICE v3.0 im Juli 2015 an einem Blau-Gold-Band, der Interpretationsrichtlinien für das Modell beinhalten wird, um den fachlichen Gleichklang unter den Assessoren und damit die Qualität der Assessmentergebnisse weiter zu erhöhen. Obgleich dieser Blau-Gold-Band für Capability Level 2 und 3 nicht den Umfang eines solchen Buchs haben kann, u. a. auch deshalb, weil er zusätzlich die Basispraktiken des Capability Level 1 bespricht, hoffe ich, einen Beitrag dazu zu leisten, indem ich dem Arbeitskreis auf Wunsch einen Entwurfsstand dieses Buchs in Abstimmung mit dem dpunkt.verlag zur Verfügung gestellt habe.

Mein herzlicher Dank für fachliches Sparring und Review der Buchinhalte geht an Dr. Joachim Fleckner, Dr. Jürgen Schmied, Dr. Wanja Hofer, Dr. Dirk Hamann, Markus Langhirt, Marcus Zörner, Thorsten Fuchs, Manfred Dornseiff, Hans-Leo Ross, Matthias Maihöfer, Matthias Bühler, Marco Semineth, Albrecht Wlokka, Thomas Bauer, Nadine Pfeiffer und Bhaskar Vanamali.

Nicht zuletzt aber möchte ich dem Team des dpunkt.verlags danken, hier besonders Christa Preisendanz, Ursula Zimpfer und Frank Heidt, die mich als »Neuling« beim dpunkt.verlag mit viel Geduld in jeder Weise tatkräftig unterstützt haben!

Pierre MetzBamberg, im Mai 2016

Inhaltsübersicht

1     Wie ist dieses Buch zu lesen?

2     Erläuterung im Buch referenzierter Konzepte

3     Verstehen der Capability Level 0 bis 5

4     Capability Level 2 – praktisches Verständnis der generischen Praktiken

5     Capability Level 2 – prozessspezifische Interpretation

6     Capability Level 3 – praktisches Verständnis der generischen Praktiken

7     Bewertungshilfen für CL1

Anhang

A     Abkürzungen und Glossar

B     Referenzen

Index

Inhaltsverzeichnis

1          Wie ist dieses Buch zu lesen?

2          Erläuterung im Buch referenzierter Konzepte

2.1       Produktlinie

2.2       Standardsoftwarekomponente

2.3       Baukasten

2.4       Übernahmeprojekt/Übernahmeentwicklung

2.5       Systemingenieur

2.6       Quality Gate/Stage Gate Review

2.7       Use Case/Anwendungsfall

3          Verstehen der Capability Level 0 bis 5

3.1       Motivation und Kurzabriss der Historie

3.2       Drei Abstraktionsebenen des Begriffs »Prozess«

3.3       Die Capability Level 1 bis 5

3.3.1        Capability Level 0 – Incomplete (Unvollständig)

3.3.2        Capability Level 1 – Performed (Durchgeführt)

3.3.3        Capability Level 2 – Managed (Gesteuerte Durchführung)

3.3.4        Capability Level 3 – Established (Standardisiert und qualitativ verbessernd)

3.3.5        Capability Level 4 – Predictable (Quantitativ vorhersagbar)

3.3.6        Capability Level 5 – Optimizing (Optimierend)

3.4       Erkenntnis

3.4.1        CL1 bis CL5 bilden eine Kausalkette »von unten nach oben«

3.4.2        CL5 bis CL1 bilden eine Kausalkette »von oben nach unten«

3.4.3        Capability Level sind ein Bedingungsgefüge und ein Messsystem

3.5       Zum Streitpunkt »SPICE vs. Agile«

4          Capability Level 2 – praktisches Verständnis der generischen Praktiken

4.1       PA 2.1 – Management der Prozessdurchführung

4.1.1        GP 2.1.1, GP 2.1.2 – Prozessziele und deren Planung

4.1.2        GP 2.1.6 – Ressourcen

4.1.3        GP 2.1.7 – Stakeholder-Management

4.1.4        GP 2.1.5 – Verantwortlichkeiten und Befugnisse

4.1.5        GP 2.1.3 – Überwachung der Prozessdurchführung

4.1.6        GP 2.1.4 – Anpassung der Prozessdurchführung

4.2       PA 2.2 – Management der Arbeitsprodukte

4.2.1        GP 2.2.1 – Anforderungen an die Arbeitsprodukte

4.2.1.1     Strukturelle Vorgaben (strukturelle Qualitätskriterien)

4.2.1.2     Inhaltliche Qualitätskriterien

4.2.1.3     Checklisten

4.2.1.4     Prüfmethoden, Prüfabdeckung, Prüffrequenz und Prüfparteien

4.2.2        GP 2.2.2 – Anforderungen an die Dokumentation und Kontrolle

4.2.3        GP 2.2.3 – Dokumentation und Kontrolle

4.2.4        GP 2.2.4 – Überprüfung und Anpassung der Arbeitsprodukte

4.3       Bewertungshilfen aus Sicht von Capability Level 2

4.3.1        Zwischen CL2 und CL1 anderer Prozesse

4.3.1.1     Allgemein

4.3.1.2     GP 2.1.1 Prozessziele (Performance Objectives)

4.3.1.3     GP 2.1.2 Planung

4.3.1.4     GP 2.1.3 Überwachung

4.3.1.5     GP 2.1.4 Anpassung

4.3.1.6     GP 2.1.5 Verantwortlichkeiten und Befugnisse

4.3.1.7     GP 2.1.6-Ressourcen

4.3.1.8     GP 2.1.7 Stakeholder-Management

4.3.1.9     GP 2.2.1 Anforderungen an die Arbeitsprodukte

4.3.1.10   GP 2.2.2, GP 2.2.3 Handhabung der Arbeitsprodukte

4.3.1.11   GP 2.2.4 Prüfung der Arbeitsprodukte

4.3.2        Innerhalb CL 2

4.3.2.1     GP 2.1.1 Prozessziele (Performance Objectives)

4.3.2.2     GP 2.1.2 Planung

4.3.2.3     GP 2.1.3 Überwachung

4.3.2.4     GP 2.1.4 Anpassung

4.3.2.5     GP 2.1.5: Verantwortlichkeiten und Befugnisse

4.3.2.6     GP 2.1.6 Ressourcen

4.3.2.7     GP 2.2.1 Anforderungen an die Arbeitsprodukte

4.3.2.8     GP 2.2.2 und GP 2.2.3 Anforderungen an Arbeitsprodukte

4.3.2.9     GP 2.2.4 Prüfung der Arbeitsprodukte

5          Capability Level 2 – prozessspezifische Interpretation

5.1       Spezifisches für alle Prozesse

5.1.1        GP 2.1.1 – Prozessziele (Performance Objectives)

5.1.2        GP 2.1.2, GP 2.1.3, GP 2.1.4 – Planung, Überwachung und Anpassung

5.1.3        GP 2.1.5 – Verantwortlichkeiten und Befugnisse

5.1.4        GP 2.1.6-Ressourcen

5.2       SYS.2 – Systemanforderungsanalyse

5.2.1        GP 2.1.1 – Prozessziele (Performance Objectives)

5.2.2        GP 2.1.6 – Ressourcen

5.2.3        GP 2.1.5 – Verantwortlichkeiten und Befugnisse

5.2.4        GP 2.1.7 – Stakeholder-Management

5.2.5        GP 2.1.2, GP 2.1.3, GP 2.1.4 – Planung, Überwachung und Anpassung

5.2.6        GP 2.2.1 – Anforderungen an die Arbeitsprodukte

5.2.7        GP 2.2.4 – Prüfung der Arbeitsprodukte

5.2.8        GP 2.2.2, GP 2.2.3 – Handhabung der Arbeitsprodukte

5.3       SYS.3 – Systemarchitekturdesign

5.3.1        GP 2.1.1 – Prozessziele (Performance Objectives)

5.3.2        GP 2.1.5, GP 2.1.6, GP 2.1.7 – Verantwortlichkeiten und Befugnisse, Ressourcen, Stakeholder-Management

5.3.3        GP 2.1.2, GP 2.1.3, GP 2.1.4 – Planung, Überwachung und Anpassung

5.3.4        GP 2.2.1 – Anforderungen an die Arbeitsprodukte

5.3.5        GP 2.2.4 – Prüfung der Arbeitsprodukte

5.3.6        GP 2.2.2, GP 2.2.3 – Handhabung der Arbeitsprodukte

5.4       SWE.1 – Softwareanforderungsanalyse

5.4.1        GP 2.1.1 – Prozessziele (Performance Objectives)

5.4.2        GP 2.1.6 – Ressourcen

5.4.3        GP 2.1.5 – Verantwortlichkeiten und Befugnisse

5.4.4        GP 2.1.7 – Stakeholder-Management

5.4.5        GP 2.1.2, GP 2.1.3, GP 2.1.4 – Planung, Überwachung und Anpassung

5.4.6        GP 2.2.1 – Anforderungen an die Arbeitsprodukte

5.4.7        GP 2.2.4 – Prüfung der Arbeitsprodukte

5.4.8        GP 2.2.2, GP 2.2.3 – Handhabung der Arbeitsprodukte

5.5       SWE.2 – Softwarearchitekturdesign

5.5.1        GP 2.1.1 – Prozessziele (Performance Objectives)

5.5.2        GP 2.1.5, GP 2.1.6, GP 2.1.7 – Verantwortlichkeiten und Befugnisse, Ressourcen, Stakeholder

5.5.3        GP 2.1.2, GP 2.1.3, GP 2.1.4 – Planung, Überwachung und Anpassung

5.5.4        GP 2.2.1 – Anforderungen an die Arbeitsprodukte

5.5.5        GP 2.2.4 – Prüfung der Arbeitsprodukte

5.5.6        GP 2.2.2, GP 2.2.3 – Handhabung der Arbeitsprodukte

5.6       SWE.3 – Softwarefeindesign und Codierung

5.6.1        GP 2.1.1 – Prozessziele (Performance Objectives)

5.6.2        GP 2.1.5, GP 2.1.6, GP 2.1.7 – Verantwortlichkeiten und Befugnisse, Ressourcen, Stakeholder

5.6.3        GP 2.1.2, GP 2.1.3, GP 2.1.4 – Planung, Überwachung und Anpassung

5.6.4        GP 2.2.1 – Anforderungen an die Arbeitsprodukte

5.6.5        GP 2.2.4 – Prüfung der Arbeitsprodukte

5.6.6        GP 2.2.2, GP 2.2.3 – Handhabung der Arbeitsprodukte

5.7       SWE.4 – Software-Unit-Verifikation

5.7.1        GP 2.1.1 – Prozessziele (Performance Objectives)

5.7.2        GP 2.1.5, GP 2.1.6, GP 2.1.7 – Verantwortlichkeiten und Befugnisse, Ressourcen, Stakeholder

5.7.3        GP 2.1.2, GP 2.1.3, GP 2.1.4 – Planung, Überwachung und Anpassung

5.7.4        GP 2.2.1 – Anforderungen an die Arbeitsprodukte

5.7.5        GP 2.2.2, GP 2.2.3, GP 2.2.4 – Handhabung und Prüfung der Arbeitsprodukte

5.8       SWE.5 – Softwareintegration und Softwareintegrationstest

5.8.1        GP 2.1.1 – Prozessziele (Performance Objectives)

5.8.2        GP 2.1.5, GP 2.1.6, GP 2.1.7 – Verantwortlichkeiten und Befugnisse, Ressourcen, Stakeholder

5.8.3        GP 2.1.2, GP 2.1.3, GP 2.1.4 – Planung, Überwachung und Anpassung

5.8.4        GP 2.2.1 – Anforderungen an die Arbeitsprodukte

5.8.5        GP 2.2.2, GP 2.2.3, GP 2.2.4 – Handhabung und Prüfung der Arbeitsprodukte

5.9       SWE.6 – Softwarequalifizierungstest

5.9.1        GP 2.1.1 – Prozessziele (Performance Objective)

5.9.2        GP 2.1.5, GP 2.1.6, GP 2.1.7 – Verantwortlichkeiten und Befugnisse, Ressourcen, Stakeholder-Management

5.9.3        GP 2.1.2, GP 2.1.3, GP 2.1.4 – Planung, Überwachung und Anpassung

5.9.4        GP 2.2.1 – Anforderungen an die Arbeitsprodukte

5.9.5        GP 2.2.2, GP 2.2.3, GP 2.2.4 – Handhabung und Prüfung der Arbeitsprodukte

5.10     SYS.4 – Systemintegration und Systemintegrationstest

5.10.1      GP 2.1.1 – Prozessziele (Performance Objective)

5.10.2      GP 2.1.5, GP 2.1.6, GP 2.1.7 – Verantwortlichkeiten und Befugnisse, Ressourcen, Stakeholder-Management

5.10.3      GP 2.1.2, GP 2.1.3, GP 2.1.4 – Planung, Überwachung und Anpassung

5.10.4      GP 2.2.1 – Anforderungen an die Arbeitsprodukte

5.10.5      GP 2.2.2, GP 2.2.3, GP 2.2.4 – Handhabung und Prüfung der Arbeitsprodukte

5.11     SYS.5 – Systemqualifizierungstest

5.11.1      GP 2.1.1 – Prozessziele (Performance Objective)

5.11.2      GP 2.1.5, GP 2.1.6, GP 2.1.7 – Verantwortlichkeiten und Befugnisse, Ressourcen, Stakeholder-Management

5.11.3      GP 2.1.2, GP 2.1.3, GP 2.1.4 – Planung, Überwachung und Anpassung

5.11.4      GP 2.2.1 – Anforderungen an die Arbeitsprodukte

5.11.5      GP 2.2.2, GP 2.2.3, GP 2.2.4 – Handhabung und Prüfung der Arbeitsprodukte

5.12     MAN.3 – Projektmanagement

5.12.1      GP 2.1.1 – Prozessziele (Performance Objectives)

5.12.2      GP 2.1.2, GP 2.1.3, GP 2.1.4 – Planung, Überwachung und Anpassung

5.12.3      GP 2.1.6 – Ressourcen

5.12.4      GP 2.1.5 – Verantwortlichkeiten und Befugnisse

5.12.5      GP 2.1.7 – Stakeholder-Management

5.12.6      GP 2.2.1, GP 2.2.4 – Anforderungen an die Arbeitsprodukte und Prüfung

5.12.7      GP 2.2.2, 2.2.3 – Handhabung der Arbeitsprodukte

5.13     ACQ.4 – Zuliefererüberwachung

5.13.1      GP 2.1.1 bis GP 2.1.4 – Prozessziele, Planung, Überwachung und Anpassung

5.13.2      GP 2.1.5, GP 2.1.6, GP 2.1.7 – Verantwortlichkeiten und Befugnisse, Ressourcen, Stakeholder

5.13.3      GP 2.2.1, GP 2.2.4 – Anforderungen an die Arbeitsprodukte und Prüfungen

5.13.4      GP 2.2.2, GP 2.2.3 – Handhabung der Arbeitsprodukte

5.14     SUP.1 – Qualitätssicherung

5.14.1      GP 2.1.1 – Prozessziele (Performance Objectives)

5.14.2      GP 2.1.2, GP 2.1.3, GP 2.1.4 – Planung, Überwachung und Anpassung

5.14.3      GP 2.1.6 – Ressourcen

5.14.4      GP 2.1.5 – Verantwortlichkeiten und Befugnisse

5.14.5      GP 2.1.7 – Stakeholder-Management

5.14.6      GP 2.2.1, GP 2.2.4 – Anforderungen an die Arbeitsprodukte und Prüfung

5.14.7      GP 2.2.2, GP 2.2.3 – Handhabung der Arbeitsprodukte

5.15     Gemeinsame Interpretation für SUP.8, SUP.9, SUP.10

5.15.1      GP 2.1.1 – Prozessziele (Performance Objectives)

5.15.2      GP 2.1.2, GP 2.1.3 – Planung und Überwachung

5.15.3      GP 2.1.4 – Anpassung

5.15.4      GP 2.1.5 – Verantwortlichkeiten und Befugnisse

5.15.5      GP 2.1.6 – Ressourcen

5.15.6      GP 2.1.7 – Stakeholder-Management

5.15.7      GP 2.2.1, GP 2.2.4 – Anforderungen an die Arbeitsprodukte und Prüfung

5.15.8      GP 2.2.2, 2.2.3 – Handhabung der Arbeitsprodukte

5.16     SUP.8 – Konfigurationsmanagement

5.16.1      GP 2.1.1 – Prozessziele (Performance Objectives)

5.16.2      GP 2.1.2, GP 2.1.3 – Planung und Überwachung

5.16.3      GP 2.1.4 – Anpassung

5.16.4      GP 2.1.5 – Verantwortlichkeiten und Befugnisse

5.16.5      GP 2.1.6 – Ressourcen

5.16.6      GP 2.1.7 – Stakeholder-Management

5.16.7      GP 2.2.1 – Anforderungen an die Arbeitsprodukte

5.16.8      GP 2.2.2, GP 2.2.3 – Handhabung der Arbeitsprodukte

5.16.9      GP 2.2.4 – Prüfung der Arbeitsprodukte

5.17     SUP.9 – Problemlösungsmanagement

5.17.1      GP 2.1.1 – Prozessziele (Performance Objectives)

5.17.2      GP 2.1.2, GP 2.1.3 – Planung und Überwachung

5.17.3      GP 2.1.4 – Anpassung

5.17.4      GP 2.1.6 – Ressourcen

5.17.5      GP 2.1.7 – Stakeholder-Management

5.17.6      GP 2.1.5 – Verantwortlichkeiten und Befugnisse

5.17.7      GP 2.2.1 – Anforderungen an die Arbeitsprodukte

5.17.8      GP 2.2.2, GP 2.2.3 – Handhabung der Arbeitsprodukte

5.17.9      GP 2.2.4 – Prüfung von Arbeitsprodukten

5.18     SUP.10 – Änderungsmanagement

5.18.1      GP 2.1.1 – Prozessziele (Performance Objectives)

5.18.2      GP 2.1.2, GP 2.1.3 – Planung und Überwachung

5.18.3      GP 2.1.4 – Anpassung

5.18.4      GP 2.1.5 – Verantwortlichkeiten und Befugnisse

5.18.5      GP 2.1.6 – Ressourcen

5.18.6      GP 2.1.7 – Stakeholder-Management

5.18.7      GP 2.2.1 – Anforderungen an die Arbeitsprodukte

5.18.8      GP 2.2.2, GP 2.2.3 – Handhabung der Arbeitsprodukte

5.18.9      GP 2.2.4 – Prüfung der Arbeitsprodukte

6          Capability Level 3 – praktisches Verständnis der generischen Praktiken

6.1       PA 3.1 und PA 3.2

6.1.1        GP 3.1.1 bis GP 3.1.4 – Beschreibung von Prozessen

6.1.2        GP 3.1.1, GP 3.2.1 – Maßschneidern von Standardprozessen (Tailoring)

6.1.3        Notwendige Vorgaben für Multiprojektmanagement

6.1.4        GP 3.1.5, GP 3.2.6 – Feststellen der Effektivität und Eignung der Standards

6.1.5        GP 3.2.2, GP 3.2.3, GP 3.2.4 – Sicherstellen der verlangten Kompetenzen der ausgewählten Personen

6.1.6        GP 3.2.5 – Sicherstellen der Nutzung aller verlangten Infrastruktur

6.2       Bewertungshilfen aus Sicht von CL3

6.2.1        Zwischen CL3 und CL1 anderer Prozesse

6.2.2        Zwischen CL3 und CL2

6.2.3        Innerhalb CL 3

7          Bewertungshilfen für CL1

7.1       Die CL1-Bewertung eines Prozesses ist nicht abhängig von der eines »Vorgängerprozesses«

7.2       SYS.2, SWE.1 – Anforderungsanalyse auf System- und Softwareebene

7.3       SYS.3, SWE.2 – Architektur auf System- und Softwareebene

7.4       SWE.3 – Softwarefeindesign und Codierung

7.5       Strategie-BPs (SWE.4, SWE.5, SWE.6, SYS.4, SYS.5, SUP.1, SUP.8, SUP.9, SUP.10)

7.6       SWE.4 – Software-Unit-Verifikation

7.7       SYS.4, SWE.5 – Integrationstesten auf System- und Softwareebene

7.8       SYS.5, SWE.6 – System- und Softwaretest

7.9       MAN.3 – Projektmanagement

7.10     ACQ.4 – Zuliefererüberwachung

7.11     SUP.1 – Qualitätssicherung

7.12     SUP.8 – Konfigurationsmanagement

7.13     SUP.9 – Problemlösungsmanagement

7.14     SUP.10 – Änderungsmanagement

Anhang

A        Abkürzungen undGlossar

B        Referenzen

Index

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 zusätzlich noch:

Quellcode und dazugehörige Prüfnachweise

Unit-Design und dazugehörige Prüfnachweise

Software-Unit-Testfälle und dazugehörige Prüfnachweise

Kriterien für statische Softwareverifikation

Auf Hardwareebene zusätzlich noch:

Schaltungsentwurf/Stromlaufpläne bzw. Designrichtlinien und dazugehörige Prüfnachweise

Diese Standarddokumentation ist bereits über alle V-Modell-Ebenen hinweg konsistent in Varianten organisiert, die typischen Kundenwünschen oder technischen Notwendigkeiten entsprechen. So kann es für automatische Heckklappen z. B. folgende Varianten geben:

Zusätzliche Einklemmschutzleisten für die seitlichen Scherbereiche, wenn diese auf Fahrzeugebene mechanisch-baulich hinreichend gefährlich sind (technisch notwendig).

Technisch: Die Wahl eines Einzel- oder Doppelspindelantriebs. Dies sind motorgetriebene Schubstangen, die die Heckklappe auf- und wieder einfahren (Kundenwunsch).

Varianteninformationen ziehen sich dabei von den Anforderungen durch alle Folgedokumentationen hindurch, d. h. von den Systemanforderungen über Architektur und Design bis hinunter zum Softwarequellcode und zu Hardware-Schaltungsentwürfen. Dies kann folgendermaßen realisiert sein:

Auf der Ebene von Anforderungen durch Attributierung

Auf der Ebene des Softwaredesigns z. B. durch SysML-Stereotypen, Tagged Values oder ganzer SysML-Modelle spezifisch für eine Variante

Auf der Ebene des Quellcodes durch:

• Präprozessorkommandos wie #define und #ifdef (im Falle der Programmiersprache C)

• verschiedene statische Softwarebibliotheken (libraries)

• Applikationsparameter (calibration parameters), mittels derer über Parameterdateien oder Diagnosejobs Funktionen ein- oder ausgeschaltet oder nichtfunktionale Eigenschaften beeinflusst werden können

Auf der Ebene der Hardware durch Angaben auf Zeichnungen und Stücklisten

Ein Projekt erweitert eine Produktlinie um ein neues konkretes, kundenspezifisches Produkt, indem

zunächst eine Variante gewählt und

diese Variante noch spezifisch verändert wird.

Umgekehrt finden sinnvolle und vorteilhafte Veränderungen, die zu einer spezifischen Produktausprägung geführt haben, wieder in die Produktlinie zurück durch Hinzufügen einer Variante oder Änderungen einzelner Anforderungen, Quellcode etc. Dasselbe gilt für Test- und Validierungsergebnisse und Erfahrung aus Feldrückläufern.

Fazit

Eine Produktlinie bedeutet also die systematische und gemeinschaftliche Wiederverwendung von Arbeitsprodukten anstelle einer opportunistischen Wiederverwendung durch einfaches Kopieren einzelner Aspekte [Clements & Northrop 02]. Eine solche Form der Wiederverwendung macht die Produkte homogener, und das damit verbundene Lernen von Fehlern oder Erfolgen anderer bedeutet dauernde Qualitätserhöhung. All dies wiederum führt zu wirtschaftlich effizienterer Produktentwicklung.

Ein Produktlinienansatz erfordert aber auch dedizierte Experten oder eine Gruppe für dessen Pflege, die die Projekte beraten. Ohne solche Verantwortliche fällt es den Projektmitarbeitern in den einzelnen Projekten zeitlich und logistisch schwer, auf alle anderen Projekte gleichzeitig zu schauen, um so kollektiv von allein Produktstandards zu schaffen oder einzuhalten.

2.2 Standardsoftwarekomponente

Unter einer Standardsoftwarekomponente wird hier eine Produktlinie verstanden, die auf eine Softwarekomponente beschränkt ist (zur Unterscheidung zwischen Softwarekomponente und Software-Unit siehe Exkurs 11 auf S. 124).

Abb. 2–1 Gegenüberstellung Standardsoftwarekomponente(n) und Einbindung in die Gesamtsoftwareebene auf Projektseite

Eine Standardsoftwarekomponente muss neben den Anforderungen an ihre fachlichen Funktionalitäten und ihren fachlichen Algorithmus auch Anforderungen an die Schnittstelle zu anderen SW-Komponenten stellen. Diese Schnittstellenanforderungen sagen aus, wie die jeweilige andere SW-Komponente an- oder eingebunden werden muss, und sie sind auch beim SW-SW-Integrationstests zugrunde zu legen.

Beispiel 1

Die SW-Komponente Basis-SW gibt an, wie die Applikationssoftware zu initialisieren ist.

Applikations-SW-Komponenten geben umgekehrt für die SW-Komponente Basis-SW z. B. an, in welcher Auflösung Signale bereitgestellt werden müssen.

Die SW-Komponente Hall-Sensor Auswertung gibt der Komponente NVRAM Manager z. B. an, wie viel Byte letztere mit welchem Timing an welchen Ort speichern bzw. laden muss.

2.3 Baukasten

Ähnlich einer Produktlinie enthält ein Baukasten die darin beschriebenen Varianten, jedoch ist eine gewählte Variante nicht mehr spezifisch veränderbar.

2.4 Übernahmeprojekt/Übernahmeentwicklung

Ein am Markt befindliches Produkt eines Vorgängerprojekts und dessen Produktdokumentation wird übernommen, ohne oder mit geringfügigen Änderungen, z. B. Fehlerkorrektur oder kundenspezifische Anpassung der Bedienschnittstelle (z. B. Kommunikation mit der Fahrzeugumgebung über z. B. LIN, CAN, FlexRay oder MOST). Es liegt hier keine Ausprägung einer Produktlinie oder eines Baukastens vor.

2.5 Systemingenieur

Insbesondere mechatronische Systementwicklung ist mehr als nur das Zusammenbringen von Komponenten, die von den Mechanik-, Hardware- und Softwareabteilungen isoliert voneinander entwickelt worden sind, und die bloße Betrachtung aller Schnittstellen.

Beispiel 2

Für einen einwandfreien Einklemmschutz eines Fensterhebers ist es notwendig, dass die physikalische Position der Scheibe in der Fahrzeugtür dieselbe ist, die die Software über das Zählen von Motorumdrehungen errechnet. Durch mechanischen Verschleiß, Umweltbedingungen und Nutzerverhalten bei der Scheibenbedienung allerdings wird sich die Position in der Software gegenüber der tatsächlichen Position mit der Zeit verfälschen.

Beispiel 3

Sollte das Taktsignal auf der Elektronik permanent verschoben sein, dann würde die Motorgeschwindigkeit eines Fensterhebers durch die Software falsch interpretiert werden, was zu einer Fehlinterpretation der tatsächlichen Scheibenkraft in der Fahrzeugtür führte. Dies wiederum resultierte darin, dass der Einklemmschutz im Bedarfsfall zu früh (Qualitätsproblem) oder zu spät (Produktsicherheitsproblem) reagiert.

Um solche Lücken zu verhindern und die (meist durch organisatorische Trennung oder gar Abwesenheit von Projektorganisationen noch verschlimmerte) Isolation der verschiedenen Bereiche aufzubrechen, stellt ein Systemingenieur als ein technischer Projektleiter die Anforderungen aus mechatronischer bzw. elektronischer Sicht gesamtheitlich auf, steht dem Systemdesign vor und sorgt für die technische Erfüllung aus den Einzelergebnissen aus Mechanikkonstruktion, Hardware- und Softwareentwicklung. Er beachtet dabei Produktlinien und Standardkomponenten (s. o.), wenn vorhanden.

Ohne die Experten der Teilbereiche ersetzen zu wollen oder zu können, muss er dazu innerhalb seines fachlichen Produktbereichs bis zu einer gewissen Detailebene auf folgenden Gebieten mechatronisch bzw. elektronisch kompetent sein:

Aufbau und der Auslegung von Mechanik

Aufbau von Motoren und Motortypen

Aufbau und Architekturen von Elektronik und Embedded Software

• z. B. Halbleiter- vs. Relais-Lösungen

• Verstehen von EMV-Entstörung und ESD

• Aufbau- und Verbindungstechnik

• Softwarefunktionalitäten des Produkts

• Kenntnis von Applikationsparametern (calibration parameters)

• Kommunikations- und Diagnoseschnittstelle

Physikalische Schnittstellen

• Motor gegenüber Mechanik

• Motor zu Elektronik

2.6 Quality Gate/Stage Gate Review

Unter einem Quality Gate wird hier eine am Ende einer jeden Projektphase eines Produktionsentstehungsprozesses (PEP) stattfindende Gremiumsitzung verstanden, die heterogen u. a. durch folgende Leitungsfunktionen besetzt ist:

Qualitätsmanagement (hat meist den Vorsitz)

Versuch

Entwicklung (Mechanik, Elektronik, Software)

Fertigungsplanung

Controlling

Einkauf

Management Produktbereich

Im Gegensatz zum Begriff Quality stellt ein Quality Gate ein Kontrollgremium für alle zu steuernden Aspekte eines Projekts dar, da der Projektleiter darin seine Bewertung des Projektstatus hinsichtlich Zeitplanung, technischem Fortschritt, Kosten und Risiken vorstellt. Gleichzeitig besitzt der Projektleiter (neben der Linien- und Projekthierarchie) damit einen zusätzlichen Eskalationspunkt.

Das Gremium prüft diese Informationen und genehmigt ggf. als Managementfreigabe formal die Fortführung der Projektaktivitäten in der nächsten PEP-Phase oder lehnt sie formal ab.

2.7 Use Case/Anwendungsfall

Use Cases sind ein Konzept für das

Ermitteln von Anforderungen an ein System, d. h., es handelt sich nicht um eine Designtätigkeit für das Systems, und

textuelle Strukturieren der gefundenen Anforderungen, unterstützt von einem Use-Case-Diagramm als Übersicht.

Als Anforderungsermittlungsmethode

Man nimmt die Perspektive eines Aktors ein, der sich in der Außenwelt des betrachteten Systems (dem Systemkontext) befindet, und fragt, welche in sich abgeschlossenen, zielorientierten Services dieses System dem Aktor anbietet (die Use Cases). Die Use Cases liefern Ergebnisse, die den Aktoren einen fachlichen Nutzen bringen müssen. Damit der Use Case sein Ziel erreichen kann, interagiert das System ggf. mit den Aktoren.

Das Konzept von Aktoren hat folgenden Vorteil: Selbst, wenn z. B. jeder ein modernes Textverarbeitungsprogramm kennt, ist es schwerer, schnell vollständige Antworten zu geben auf die erschlagende Frage: »Welche Funktionalitäten muss es können?« Schneller und intuitiver geht es tatsächlich, wenn man nacheinander fragt: »Welche Erwartungen daran hat ein Buchautor, Diplomand, Privatmann, …?«

Abb. 2–2 Zwei Use Cases für eine automatische Heckklappe

Als Anforderungsstrukturierungsmethode

Ein Use Case (UC) kann innerhalb der Anforderungsspezifikation als Kapitel durch folgende Struktur beschrieben werden:

Name:

Der Use-Case-Name ist ein einfacher Satz, der das fachliche Serviceziel aus der Perspektive des Aktors (nicht aus der des Systems) beschreibt. Beispiel siehe Abbildung 2–2.

Auslöser:

Diejenigen vom System detektierbaren Ereignisse (ein Ereignis hat keine Ausdehnung in der Zeit), die den Use Case auslösen sollen. Diese können vom Aktor stammen oder auch aus dem Innern des Systems kommen, wie z. B. ein Zyklus oder ein bestimmtes Datum und Zeit. Beispiele:

• UC Heckklappe schließen:Nutzeranforderung des Schließens

• UC Heckklappe reversieren:Schwergängigkeit detektiert

Vorbedingungen:

Welche Systemzustände mit Ausdehnung in der Zeit (d. h. nicht ein Zustand eines Aktors oder eines anderen Elements im Systemkontext) müssen vorliegen, wenn ein Auslöser eintrifft, um den Use Case zu starten? Beispiele:

• UC Heckklappe schließen:Heckklappe nicht in Schließposition und es liegt kein Einklemmfall vor.

• UC Heckklappe reversieren:Heckklappe nicht in Schließposition

Interaktions-Hauptpfad:

Der am häufigsten vorkommende Pfad der Interaktionsschritte, die zum Erreichen des Use-Case-Ziels und damit zum Herstellen der Erfolgsergebnisse (s. u.) führt. Er startet, wenn während des Erfülltseins der Vorbedingungen ein Auslöser eintritt. Beispiele:

• Bzgl. Heckklappe keine. Ein Beispiel wäre das Einstellen des Ziels in ein Navigationssystem.

Interaktions-Nebenpfade:

Alternative Interaktionspfade, die entweder auch zum Use-Case-Ziel oder aber zum Fehlschlag des Ziels und damit zum Abbruch des Use Case führen. Im letzteren Fall werden nur die Misserfolgsergebnisse erreicht. Beispiele:

• Der Use Case Heckklappe reversieren bildet gesamthaft einen Nebenpfad für Heckklappe schließen.

• UC Heckklappe reversieren:Keine

Erfolgsergebnisse:

Die fachliche Leistung, die beim erfolgreichen Ausgang des Use-Case-Ziels erreicht ist. Beispiele:

• UC Heckklappe schließen:Heckklappe befindet sich in Endposition und ist verrastet.

UC Heckklappe reversieren:

Heckklappe wurde in x sec. um x cm entgegen der Schließrichtung bewegt, verharrt bewegungslos und befindet sich nicht in Endposition.

Misserfolgsergebnisse:

Fachliche Leistung, die bei Misserfolg und Abbruch des Use-Case-Ziels erreicht ist. Beispiele:

• UC Heckklappe schließen:Heckklappe wurde um x cm in Schließrichtung bewegt, verharrt bewegungslos und befindet sich nicht in Endposition (… weil z. B. ein detektierter Einklemmfall das weitere Schließen verhindert hat).

• UC Heckklappe reversieren:Keine

Wie in [Umbach & Metz 06] erklärt, werden Use Cases in der Literatur nicht als ein Konzept, sondern oft nur als eine grafische Notation wahrgenommen. Daher werden sie auch oft ungenau von den dahinterliegenden Abläufen im Innern des Systems (z. B. Geschäftsprozesse in Unternehmen oder die Wirkketten über Software- und Hardwareelemente in einem technischen Produkt) abgegrenzt. Use Cases und dahinterliegende Innenabläufe beschreiben jedoch jeweils eine andere Sicht auf das zu modellierende System [Umbach & Metz 06]:

Use Cases beschreiben, was die Aktoren im Systemkontext vom System erwarten. Use Cases ziehen somit auch die Systemgrenze eindeutig.

Die dahinterliegenden Innenabläufe repräsentieren die Lösung, wie das Ziel des Use Case erreicht wird.

Abb. 2–3 Abgrenzung von Use Cases und Innenabläufen: Die fachliche Leistung des äußeren Use Case wird durch den Innenablauf über die Elemente A bis F und einer Interaktion mit dem anstoßenden, äußeren Aktor erbracht. Element B wiederum stellt einen Aktor für das Subsystem dar, das für ihn den inneren Use Case anbietet.

Diese Abgrenzung gilt auf jeder Systemebene, also unabhängig von der Art des zu modellierenden Systems. Sie ist auch nicht mit der Unterscheidung zwischen Whitebox- und Blackbox-Modellierung gleichzusetzen: Ein Use Case kann eine Whitebox-Aussage enthalten, wenn dies eine fachliche Notwendigkeit für den Aktor darstellt. Zum Beispiel muss ein Onlinekunde erfahren können, dass im Rahmen seiner Bestellung eines Buchs über das Internet das Unternehmen eine Schufa-Abfrage über ihn durchführt.

3 Verstehen der Capability Level 0 bis 5

3.1 Motivation und Kurzabriss der Historie

Produktentwicklung findet heute immer mehr in verteiltem Kontext statt, und es wird auf spezialisierte Zulieferer zurückgegriffen. Als Auftraggeber benötigt man hierzu Auswahlkriterien, die technische, ökonomische, einkaufsstrategische Aspekte sowie Ansprüche an die Prozessreife beinhalten. Prozessreife ist deswegen ein Kriterium, da die Prämisse gilt, dass strukturierte und gesteuerte Abläufe nach Stand der Technik die Wahrscheinlichkeit systematischer Fehler im Produkt reduziert sowie wirtschaftlich und planerisch exaktere Schätzungen ergibt (vgl. z. B. [Etzkorn 11].

Daher wurden in den 1980er-Jahren die Charakteristika und Prinzipien technisch und kommerziell erfolgreicher Projekte in der industriellen Praxis identifiziert und analysiert. Diese Prinzipien wurden abstrahiert und in Prozessbewertungsmodellen zusammengefasst wie z. B. in CMM® bzw. CMMI® (vom Software Engineering Institute der Carnegie Mellon Universität in den USA) und später in ISO/IEC 15504/SPICE (initiiert in Europa) und dessen sektorspezifischen Ableitungen wie u. a. Automotive SPICE.

3.2 Drei Abstraktionsebenen des Begriffs »Prozess«

Um in diesem Zusammenhang den problematischen und teilweise inflationär benutzten Begriff Prozess besser fassbar zu machen, kann man sich ihn auf drei Abstraktionsebenen1 vorstellen (siehe Abb. 3–1):

Abb. 3–1 Drei Abstraktionsebenen des Begriffs Prozess (nach [intacsPA], Bild übernommen aus [Besemer et al. 14], das auch für das Automotive SPICE v3.0 PRM- und PAM-Dokument frei zur Verfügung gestellt wurde)

Die operative Produktentwicklung findet auf der TUN-Ebene statt. Das Aufschreiben von Erfahrungen und Anleitungen dafür bedeutet, sich eine WIE-Ebene zu schaffen. Eine bestimmte WIE-Ebene ist jedoch immer nur anwendbar für den spezifischen Kontext der Organisation, für die sie geschaffen wurde: Die WIE-Ebene eines Unternehmens A ist nicht einfach übertragbar auf ein Unternehmen B, weil dort die Abläufe, Werkzeuge und Kultur etc. anders sind. Dennoch ist es möglich, von beiden Unternehmen zu erwarten, dass sie z. B. Arbeitsprodukte versionieren und Lieferungen zuordnen, gegen die dann z. B. Change Requests gestellt werden etc. Genau diese abstrahierten Erwartungen sind als Prinzipien in der WAS-Ebene dokumentiert und belassen konkrete Umsetzungsentscheidungen einer WIE-Ebene Projekten oder Unternehmensebenen. Auf der WAS-Ebene befinden sich genau diese Prozessbewertungsmodelle. Neben dem »Verständnisgerüst« für das Definieren von WIE-Ebenen können diese Prinzipien zusätzlich auch dafür benutzt werden, Unternehmen oder Projekte zu vergleichen. Vergleichsgründe sind z. B. Zuliefererauswahl oder auch der organisationseigene Wunsch, festzustellen, ob eine interne Prozessverbesserung angeschlagen hat oder nicht.

Um solche Vergleiche detaillierter und damit informativer zu gestalten, ordnen alle SPICE-Modelle, so auch Automotive SPICE, diese Prinzipien in eine zweidimensionale Struktur:

Abb. 3–2 Die zweidimensionale Struktur der ISO/IEC 33020 und ISO/EC 15504

Prozesse

In Prozessbewertungsmodellen sind die Prozesse in eigene Kapitel nach Fachthemen getrennt, wie z. B. Projektmanagement, Systemanforderungsanalyse, Konfigurationsmanagement, Softwaredesign etc.

Capability Level (Fähigkeitsgrade)

Jeder dieser Prozesse kann auf sechs verschiedenen Niveaustufen durchgeführt werden. Da durch ein Assessment überprüft wird, ob eine Produktentwicklung die Prinzipien der WAS-Ebene einhält, kann daraus auch abgeleitet werden, auf welchem Niveau dieser sechs Stufen ein Prozess betrieben wird.

Nähere Erklärungen der Capability Level siehe im folgenden Kapitel.

3.3 Die Capability Level 1 bis 5

3.3.1 Capability Level 0 – Incomplete (Unvollständig)

Der Prozesszweck ist nicht erfüllt. Dies ist der Fall, wenn alle vom individuellen Prozess erwarteten Ergebnisse teilweise oder gar nicht erbracht werden bzw. wenn die Ergebnisse technisch und fachlich-inhaltlich nicht nutzbar sind.

3.3.2 Capability Level 1 – Performed (Durchgeführt)

Kurzverständnis:

Der Prozesszweck wird irgendwie erreicht. Das heißt, die für den Prozesszweck notwendigen Ergebnisse sind technisch und fachlich-inhaltlich nutzbar, sie sind aber nicht auf eine strukturierte und gesteuerte Weise entstanden.

Weitere Erklärung:

Die erforderlichen Ergebnisse sind inhaltlich vollständig und inhaltlich nutzbar. Jedoch wird auf dem Weg dorthin z. B. wegen Informationslücken, unklarer Kompetenzen und Zuständigkeiten zu viel Zeit für dauernde Absprachen benötigt. Oft erfolgt die Ausbildung und Qualifizierung auch inhaltlich nicht zielgerichtet auf die Aufgaben der Mitarbeiter und/oder nicht rechtzeitig. Dadurch gelingt der Prozesserfolg meist nur durch »Helden« und »Feuerwehrmänner«, die stets der Gefahr unterliegen, auszubrennen und die Motivation und dadurch langfristig die Loyalität zu verlieren. Der Erfolg ist also stark personenabhängig. Dies bedeutet, dass der Prozesserfolg im Unterschied zu CL2 prinzipiell zufällig ist und unter anderen Bedingungen nicht gesichert wiederholbar ist.

3.3.3 Capability Level 2 – Managed (Gesteuerte Durchführung)

Kurzverständnis:

Sowohl die Art und Weise der Entstehung als auch die Qualität des Inhalts der Ergebnisse, die den Prozesszweck ausmachen, werden vorgegeben (Soll) und durch Steuern von Ist gegen das Soll erzeugt. All dies geschieht in jedem Projekt aber (noch) methodisch unterschiedlich.

Weitere Erklärung:

Es werden Erwartungen (zeitliche Fertigstellung und/oder Aufwandsgrenzen und/oder dabei zu nutzende Methoden) an (Teil-)Ergebnisse gestellt. Dazu werden Verantwortlichkeiten und Befugnisse unter den Teammitgliedern festgelegt, nichts wird doppelt getan oder vergessen. Es wird nicht längere Zeit für unnötige Aktivitäten (Ansprechpartner, Arbeitsergebnisse oder Informationen suchen, wiederholt gleiche Fehler ausbügeln etc.) verbraucht. Die dazu notwendige Qualifikation von Mitarbeitern geschieht rechtzeitig. Qualitätskriterien für die Ergebnisse und Regeln für Versionierung, Ablage, Konfigurationsmanagement, Zugriffsrechte etc. werden aufgestellt. Die für alle Erwartungen notwendigen Ressourcen (neben den Mitarbeitern auch Werkzeuge sowie logistische, budgetäre und infrastrukturelle Ressourcen etc.) werden bestimmt, beschafft und rechtzeitig zur Verfügung gestellt.

Das Einhalten all dessen wird mit der gelebten Realität verglichen und bei Abweichungen werden Anpassungen vorgenommen, d. h., es wird qualitätsgerichtet gesteuert. Die Prozesskultur hat sich also verändert vom Belohnen von »Helden und Feuerwehrmännern« hin zum Belohnen von Mitarbeitern, die unauffällig erfolgreich arbeiten, d. h., die systematisch und strukturiert zusammenarbeiten, und zwar unter großem operativem Druck und Stress.

3.3.4 Capability Level 3 – Established (Standardisiert und qualitativ verbessernd)

Kurzverständnis:

Der Prozesszweck wird nur projekt- und/oder abteilungsübergreifend methodisch gleichartig erreicht. Das heißt, sowohl die Art und Weise der Entstehung als auch die Qualitätsziele der Ergebnisse sind standardisiert, ebenso die Vorgehensweise zum Steuern des Istzustands gegen den Sollzustand. Zudem existiert ein dauerhaft gelebter, qualitativer Regelkreis hinsichtlich Verbesserungsbedarf der Standards.

Weitere Erklärung:

Im Unternehmensbereich existiert nun eine Menge von vereinbarten methodischen und technischen Standardvorgehensweisen für den betrachteten Prozess. Der Plural deshalb, da für den betrachteten Prozess verschiedene Standardvorgehensweisen notwendig sein können, abhängig von z. B. der Projektgröße, Kunden oder Produktfamilien, sicherheitsrelevanten wie nicht-sicherheitsrelevanten Entwicklung etc. Diese Standardvorgehensweisen sind projektübergreifend vereinbart, können und sollen jedoch wiederum speziell auf das spezifische Projekt angepasst werden können (Maßschneidern, Tailoring) – das trifft zu, da Standards grundsätzlich immer nur eine Abstraktion eines ganz konkreten Falls sein können.

Die Standardvorgehensweisen verbessern sich evolutionär durch eingeforderte und gelebte Rückführung der Erkenntnisse von den Ausführenden in den Entwicklungsprojekten und Organisationseinheiten zu den Prozessautoren. Veränderte Standardvorgehensweisen werden neu ausgerollt. Projekte profitieren so also von institutionalisiert verbreiteten positiven Erfahrungen und dem Vermeiden bereits gemachter Fehler anderer. Sofortiges Zurechtfinden von Mitarbeitern in neuen Projekten und Wiederverwendung von Arbeitsergebnisinhalten (z. B. über Produktlinienansätze) aufgrund gleicher Arbeitsweise ist hier erfolgreich möglich.

Der Prozesserfolg ist nicht mehr allein von Individuen abhängig, es existiert nun Unternehmenswissen (corporate knowledge). Es hat sich die Kultur entwickelt, nutzen-getriebenen Arbeitsweisen zu folgen. CL3 ist also eine Leistung und Eigenschaft einer Organisation, nicht eines einzelnen Projekts.

3.3.5 Capability Level 4 – Predictable (Quantitativ vorhersagbar)

Kurzverständnis:

Die seit CL3 standardisierte Prozessdurchführung wird nun quantitativ gemessen. Man sieht durch eine analytische Auswertung der so entstehenden Zahlenhistorie, »welche Zahlen normal sind«, um bei aktuellen Ausreißern proaktiv agieren zu können. Dies dient dem Zweck, Geschäftsziele des Unternehmens zu unterstützen.

Weitere Erklärung:

Aufgrund gleichartiger Arbeitsweise seit CL3 ist es auf Organisations- und Managementebene überhaupt erst möglich, Mess-/Kennzahlen von Prozessdurchführungen verschiedener Projekte oder Organisationseinheiten sinnvoll vergleichen zu können.

Das Management stellt nun geschäftszielgetrieben (z. B. wirtschaftliche Effizienzerhöhung) Informationsbedürfnisse an die Prozessdurchführung auf (z. B. wie viel verworfene Ergebnisse maximal, wo wird die meiste Zeit verbraucht). Für diese Informationsbedürfnisse werden nun Metriken (Formeln) aufgestellt. Die Projekte und Organisationseinheiten ermitteln dann die quantitativen (Kenn-) Zahlen nach den Metriken, und diese Zahlen werden historisch archiviert. Dadurch ist es möglich, über diese Historie hinweg durch statistische Analyse Schranken und Grenzwerte zwischen Normal und Inakzeptabel zu erkennen und festzulegen. Bei Verletzungen der Grenzwerte jeder individuellen Prozessdurchführung (special causes of variation, siehe Abb. 3–3) werden deren individuelle Gründe kausal analysiert. Um diese Gründe abzustellen, werden individuell zur Prozessdurchführung Maßnahmen ergriffen, damit sie wieder in die erlaubten Schranken kommt (siehe Abb. 3–3).

Abb. 3–3 Special Causes of Variation

Das bedeutet, CL4 ersetzt durch historisch analysierte, quantitative Kennzahlen das Bauchgefühl, was dem Management erstmals objektivere Einsicht in die wirklichen Phänomene liefert und damit objektiviertes und schnelleres Reagieren möglich macht.

3.3.6 Capability Level 5 – Optimizing (Optimierend)

Kurzverständnis:

Durch das quantitative Messen des standardisierten Prozesses seit CL4 entscheidet man nun, warum und wo genau in die Standardprozessverbesserung zu investieren ist. Anstatt also noch auf das Vorliegen schlechter Zahlen proaktiv reagieren zu müssen, werden nun die Ursachen schlechter Zahlen durch gezielte Standardprozessverbesserung im Vorhinein vermieden. Diese Verbesserung wird noch bereichert durch das Evaluieren von Industry Best Practices und neuen Techniken.

Weitere Erklärung:

Um die Geschäftsziele weiter zu unterstützen, werden Abweichungen von Grenzwerten in allen Prozessdurchführungen (desselben Prozesses) nun zusätzlich auf gemeinsame Ursachen hin überprüft (common causes of variation). Können diese gemeinsamen Ursachen durch Abänderung der Standardprozesse zukünftig unterbunden werden, wird dies auch getan (z. B. andere Ressourcen, bessere Qualifikation, andere Methoden, neue Werkzeuge, Wiederverwendung etc.), für andere Ursachen gilt dies jedoch nicht (z. B. eine Reduzierung an Auftragsumfang seitens des Kunden, Änderung in Einkaufs- und Verkaufspreisen). Durch die sich dadurch auch verändernden Messzahlen kann der Erfolg, aber auch die Verschlechterung durch die Standardprozessänderung beobachtet werden.

Abb. 3–4 Common Causes of Variation

Standardprozessänderungen werden jedoch nicht nur durch quantitative Informationen motiviert, sondern auch gezielt durch Marktbeobachtung von neuen Technologien, Stand der Technik und Industry Best Practices.

3.4 Erkenntnis

3.4.1 CL1 bis CL5 bilden eine Kausalkette »von unten nach oben«

Abb. 3–5 Capability Level bauen aufeinander auf [intacsPA]

Zunächst muss man in der Lage sein, überhaupt erst einmal Ergebnisse zu erzielen (= CL1), bevor man ordnende Planung und Steuerung darüberlegen und die Ergebnisse strukturiert behandeln kann (= CL2). Was würde man sonst steuern und strukturieren wollen?

Wenn man nun qualitätsgerichtete Steuerung der Ergebniserzeugung beherrscht, dann kann man überlegen, sich über Projekte und Organisationseinheiten hinweg auszutauschen mit dem Zweck, voneinander zu lernen (niemand macht alle möglichen positiven und negativen Erfahrungen selbst), und zwar dadurch, dass man eine gemeinsame, gleichartige Auffassung über das genaue WIE entwickelt (= CL3) und gemeinsam pflegt.

Hat man eine gleichartige Arbeitsweise erreicht, dann (erst) sind Kennzahlen und Messergebnisse für die Multiprojekt- und Unternehmenssteuerung überhaupt sinnvoll vergleichbar. Dies kann man sich zunutze machen, indem man Kennzahlen und ihre Entstehungskontexte historisch aufzeichnet und dadurch statistisch Schranken erkennt, die anzeigen, was die heute vorgelegte Kennzahl an Auswirkungen hat (= CL4).

Wenn man so weit ist, Zahlen von heute einschätzen zu können, also zu wissen, ob es eine gute oder schlechte Zahl ist, dann kann man sich dazu hinentwickeln, das Entstehen schlechter Zahlen im Vorhinein zu vermeiden, anstatt nur proaktiv darauf zu reagieren. Dies lässt sich durch gezielte Investition in Veränderung dort erreichen, wo es die schlechten Zahlen andeuten (= CL5).

3.4.2 CL5 bis CL1 bilden eine Kausalkette »von oben nach unten«