Automotive SPICE® in der Praxis E-Book

Markus Müller

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

Seitenzahl: 530

Beschreibung

Automotive SPICE ist ein ISO/IEC 15504-kompatibles, speziell auf die Automobilbranche zugeschnittenes Assessmentmodell. Die Herausforderung bei der Einführung und Umsetzung von Automotive SPICE besteht darin, das Modell auf eine konkrete Projekt- und Unternehmenssituation anzuwenden und in diesem Kontext richtig zu interpretieren. Dieses Buch gibt die dafür notwendigen Interpretations- und Bewertungshilfen und unterstützt dabei, Prozessverbesserung Automotive SPICE-konform zu betreiben. Nach einem Überblick werden Struktur und Bestandteile des Automotive SPICE-Modells in kompakter Form dargestellt, u.a. die seit Version 3.0 wesentlichen Schlüsselkonzepte wie die Trennung in Systemebene und Domänen (Software, Hardware, Mechanik) sowie die Traceability und Applikationsparameter. An einer praxisgerechten Auswahl von 24 Automotive SPICE-Prozessen werden jeweils Zweck, Basispraktiken und Arbeitsprodukte eines Prozesses im Detail erläutert. Der Buchaufbau entspricht der Struktur des Modells, sodass die Interpretationshilfen leicht�dem jeweiligen Abschnitt des Modells zugeordnet werden können. Das Buch richtet sich in erster Linie an Praktiker, die bereits über ISO/IEC 15504-Grundlagenwissen verfügen und Hilfestellung für die Umsetzung von Automotive SPICE in der Praxis suchen. Die 2. Auflage wurde auf Automotive SPICE v3.0 aktualisiert und ergänzt um aktuelle Themen wie praxistaugliche Assessments gemäß intacs™-�Anforderungen, agile Entwicklung und funktionale Sicherheit nach ISO 26262.

Leseprobe

Dipl.-Ing. Markus Müller ist Director Operations und Partner bei KUGLER MAAG CIE GmbH und verantwortlich für den operativen Betrieb. Er berät seit vielen Jahren namhafte Unternehmen sehr erfolgreich in Prozessverbesserung und agiler Entwicklung, überwiegend in der Automobilindustrie. Markus Müller ist auch »Project Management Professional« entsprechend der Zertifizierung PMI sowie Scrum Master und SAFe Program Consultant (Scaled Agile Framework). Außerdem ist er intacs™ ISO/IEC 15504 Principal Assessor, bildet seit vielen Jahren Assessoren aus und leitet seit fast 20 Jahren Assessments. Neben vielen Assessments hat er das bis dato größte bekannte Organisationsassessment nach Automotive SPICE durchgeführt. Zudem ist er Co-Autor mehrerer Bücher und Vortragender auf Konferenzen und Veranstaltungen.

Dr. Klaus Hörmann ist Principal und Partner bei KUGLER MAAG CIE GmbH und seit vielen Jahren schwerpunktmäßig in der Automobilindustrie tätig. Er leitet Verbesserungsprojekte und führt Assessments, Appraisals, CMMI-, Automotive SPICE- und Projektmanagement-Trainings sowie Assessoren-Trainings und -Coaching durch. Dr. Klaus Hörmann ist intacs™-zertifizierter Principal Assessor, intacs™-zertifizierter Instructor (Competent Level), Scrum Master, CMMI Institutezertifizierter SCAMPI Lead Appraiser und CMMI Instructor. Er ist ehrenamtlich bei intacs tätig und leitet die Arbeitsgruppe »Exams« und ist (Co-)Autor mehrerer Fachbücher.

Dipl.-Ing. Lars Dittmann ist bei der Volkswagen AG Marke VW PKW für den Betrieb und fachlichen Support der mobilen Aftersales Onlinedienste verantwortlich. Er baute u.a. das Software-Assessmentsystem des Konzerns auf und leitete die Software-Qualitätssicherung des Konzerns. Mit seiner jahrelangen Erfahrung als intacs™ ISO/IEC 15504 Principal Assessor beteiligt er sich aktiv an der Erweiterung der SPICE-Methodik auf neue Domains.

Dipl.-Inform. Jörg Zimmer ist seit vielen Jahren bei der Daimler AG tätig. Dort leitete er übergreifende Software-Qualitätsprojekte und interne Prozessverbesserungsprojekte. Er war Mitglied des VDAArbeitskreises 13 sowie Sprecher der HIS-Arbeitsgruppe Prozessassessment. Er ist Mitbegründer des Software-Qualitätsmanagementsystems des Konzerns und im Rahmen der aktiven Mitgliedschaft der AUTOSIG-Gruppe mitverantwortlich für die initiale Erstellung von Automotive SPICE. Aktuell ist er in der Powertrain-Entwicklung für den Inhouse-Softwareentwicklungsprozess verantwortlich. Er ist intacs™ ISO/IEC 15504 Principal Assessor.

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® in der Praxis

Interpretationshilfe für Anwender und Assessoren

2., aktualisierte und erweiterte Auflage

Markus MüllerKlaus HörmannLars DittmannJörg Zimmer

Markus Müller – [email protected] Hörmann – [email protected] Dittmann – [email protected]örg Zimmer – [email protected]

Lektorat: Christa PreisendanzCopy-Editing: Ursula Zimpfer, HerrenbergSatz: Birgit BäuerleinHerstellung: Susanne BröckelmannUmschlaggestaltung: Helmut Kraus, www.exclam.deDruck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn

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

Fachliche Beratung und Herausgabe von dpunkt.büchern im Bereich Wirtschaftsinformatik: Prof. Dr. Heidi Heilmann · [email protected]

ISBN:Print    978-3-86490-326-7PDF    978-3-86491-998-5ePub    978-3-86491-999-2mobi    978-3-96088-000-4

2., aktualisierte und erweiterte Auflage 2016Copyright © 2016 dpunkt.verlag GmbHWieblinger Weg 1769123 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

Geleitwort

Ein Blick auf die Entwicklung des Automobils über die letzten Dekaden zeigt deutlich: Fahrzeuginnovationen, wie vernetzte Infotainmentsysteme, Head-up-Displays, bidirektionale Funkschlüssel, Hybridantriebe oder Fahrerassistenzsysteme, wären ohne Software nicht denkbar. In modernen Oberklassefahrzeugen tauschen heute bis zu 100 Steuergeräte Daten aus und insgesamt sorgen bis zu 100 Millionen Programmzeilen dafür, dass Fahrer und Passagiere sicher, effizient und komfortabel ans Ziel gelangen. Zum Vergleich, ein F35-Kampfjet aus dem Jahr 2013 kam noch mit etwa 25 Millionen Programmzeilen aus und das Space Shuttle flog nur mit etwa 400.000 Zeilen ins All.

Im Fahrzeug ist allein zwischen den Jahren 2000 und 2010 der Wertschöpfungsanteil von Software von etwa 2 auf 13% gestiegen und die Tendenz zeigt klar weiter nach oben. Blickt man auf die Trends, die die Automobilindustrie bewegen, so bestätigt sich diese Annahme. Automatisiertes Fahren, Hybridisierung und Elektrifizierung, Vernetzung mit dem Internet of Everything: All diese Themen werden maßgeblich durch schlaue Algorithmen durch Bits und Bytes und letztlich durch Einsen und Nullen vorangetrieben. In der Tat sind Elektronik und Software bereits heute Basis für über 90% der Fahrzeuginnovationen. Bei der immens steigenden Bedeutung softwarebasierter Funktionen darf allerdings gerade die Automobilindustrie die grundlegenden Anforderungen nicht außer Acht lassen. Der Fahrer eines Fahrzeugs bewegt sich in einem sicherheitskritischen Umfeld. Er will zuverlässig von der Fahrzeugelektronik unterstützt werden, und das nicht nur heute und morgen, sondern über die gesamte Lebensdauer seines Fahrzeugs hinweg. Die Toleranz für Softwarefehler ist deshalb im Fahrzeug nur äußerst gering.

Es gehört zum Handwerkszeug der Automobilindustrie, Elektronik und Software zu beherrschbaren Kosten, innerhalb eines vorgegebenen Terminplans und mit höchster Qualität zu entwickeln. Bei Continental arbeiten daran schon heute etwa 11.000 Mitarbeiter im Bereich Software – gut die Hälfte des gesamten Forschungs- und Entwicklungspersonals. Dabei hat sich deutlich herauskristallisiert, dass nachhaltig implementierte Prozesse in Entwicklung, aber auch Produktion eine immens positive Wirkung auf die Produktqualität haben können.

Mit dem Start des SPICE-Projekts im Jahr 1992, der Einführung des Internationalen Standards ISO/IEC 15504 [ISO/IEC 15504] und der Veröffentlichung von Automotive SPICE wurde ein Weg gefunden, Softwareentwicklungsprozesse transparent zu bewerten. In der Praxis wurde dadurch die Transparenz in Entwicklungsprojekten deutlich erhöht. Automotive SPICE hat zudem das Bewusstsein dafür geschärft, welche Bereiche bei komplexen Softwareentwicklungen von Bedeutung sind. Damit ist Automotive SPICE zum Synonym für Entwicklungsqualität geworden.

Der Blick nach vorne zeigt deutlich, dass softwarebasierte Funktionen im Fahrzeug komplexer werden. Dabei steigt jedoch gleichzeitig der Qualitäts- und Produktivitätsdruck. Mit dieser Entwicklung geht ein Wandel von wasserfallartigen Entwicklungsprozessen hin zu agilen Prozessen (wie Scrum) einher. Da Automotive SPICE genügend Freiräume für unternehmensspezifische Prozessgestaltungen lässt, kann es auch in Zukunft die Basis für Qualität in der Softwareentwicklung bilden. Dafür wird es jedoch essenziell, den agilen Entwicklungsmethoden in der Bewertungspraxis Rechnung zu tragen.

Das vorliegende Buch »Automotive SPICE in der Praxis« gibt die notwendigen Interpretationshilfen und unterstützt den Leser dabei, die Anforderungen der neuesten Version von Automotive SPICE im Kontext der jeweiligen Situation besser zu verstehen. Es liefert konkrete Beispiele aus der Entwicklung von softwarebestimmten Systemen. Aktuelle Trends bei der Weiterentwicklung der Norm wurden entsprechend berücksichtigt. Auch gehen die Autoren auf spannende Themen wie Automotive SPICE und funktionale Sicherheit bzw. das Zusammenspiel mit agilen Methoden ein. Die Autoren sind anerkannte Experten mit jahrelangem umfangreichem Erfahrungswissen, erworben in Hunderten von Assessments im Feld, und haben zahlreiche Unternehmen bei der Umsetzung von Verbesserungsprogrammen unterstützt. Ich bin zuversichtlich, dass dieses Buch das Verständnis für die Bewertung des Reifegrades der Softwareentwicklung weiter fördert, hilfreich ist für die Durchführung von Assessments, und die notwendigen Prozessverbesserungen in den Unternehmen systematisch unterstützt.

Helmut Matschi

Vorstandsmitglied von Continental undLeiter der Division Interior

Vorwort

Acht Jahre nach Erscheinen der ersten Auflage und nachdem zwischenzeitlich das Automotive SPICE-Modell mehrfach geändert wurde, zuletzt mit größeren strukturellen Änderungen in der Version 3.0, wurde es Zeit für eine zweite Auflage. Was sich nicht geändert hat, ist die grundlegende Motivation für dieses Buch: Immer noch sind die Modellforderungen schwierig zu verstehen und werden teilweise unterschiedlich interpretiert. Wie in der ersten Auflage möchten wir den Lesern eine praxisnahe Hilfestellung geben, sowohl für Assessments als auch für die Prozessimplementierung.

In der zweiten Auflage haben wir die zwischenzeitlichen Modelländerungen eingearbeitet. Wir haben aber auch einige Themen vertieft bzw. neu aufgenommen, die durch Modelländerung, neue Entwicklungen oder veränderte Rahmenbedingungen in der Automobilindustrie an Bedeutung gewonnen haben:

Applikationsparameter sind schon vor einiger Zeit im Automotive SPICE-Modell aufgenommen worden und werden in der Praxis häufig noch nicht in voller Tragweite verstanden.

Funktionale Sicherheit und Automotive SPICE hat seit der ersten Auflage weiter an Wichtigkeit gewonnen und stellt für viele Organisationen eine doppelte Herausforderung dar.

Agile Entwicklungsmethoden verbreiten sich schnell, treffen aber auf Beurteilungsunsicherheiten und teilweise auf Vorurteile. Wir zeigen, worauf man achten muss, um mit agilen Methoden Automotive SPICE-kompatibel zu bleiben.

Erfolgreiche Prozessverbesserung ist eine Herausforderung, die alle Unternehmen betrifft. Wir geben Tipps, worauf es ankommt.

Automotive SPICE-Assessments: Wir beschreiben den Stand der Praxis bezüglich Assessmentmethoden inklusive Organisationsassessments.

Wir danken Frau Christa Preisendanz (dpunkt.verlag) für die professionelle Abwicklung sowie unseren Kollegen bei der Firma KUGLER MAAG CIE GmbH für die Unterstützung bei den Kapiteln »Funktionale Sicherheit und Automotive SPICE« und »Agilität und Automotive SPICE«. Bei unseren Familien bedanken wir uns für das aufgebrachte Verständnis angesichts diverser zeitlicher Engpässe.

Markus Müller, Klaus Hörmann, Lars Dittmann, Jörg ZimmerMai 2016

Vorwort zur 1. Auflage

In unserer langjährigen Arbeit mit Modellen wie SPICE, Automotive SPICE und CMMI haben wir immer wieder festgestellt, wie schwierig die Modellforderungen zu verstehen sind und wie unterschiedlich diese teilweise interpretiert werden. Diese Interpretationsvielfalt liegt in dem Wesen eines solchen Modells, das für ein breites Spektrum von Anwendungen geeignet sein soll. Dessen Elemente wie z.B. Praktiken oder Arbeitsprodukte müssen im jeweiligen Anwendungskontext des Projektes bzw. der Organisation interpretiert werden. Gleiches gilt auch für die Bewertung dieser Modellelemente in Assessments. Es gibt daher keine absoluten Maßstäbe bei der Erfüllung der Modellforderungen.

Seit Erscheinen des Buchs »SPICE in der Praxis« (dpunkt.verlag) wurde in der Automobilindustrie der Umstieg von SPICE zu Automotive SPICE vollzogen. Es erscheint uns daher an der Zeit, dass auch für Automotive SPICE eine deutschsprachige Interpretationshilfe verfügbar ist. Wir hoffen, dass dieses Buch den Lesern sowohl für Assessments als auch für die Prozessimplementierung hilfreich ist.

Zum Aufbau des Buches:

Kapitel 1 (Einführung und Überblick) führt in die grundlegenden Konzepte von Reifegradmodellen ein und behandelt in Kürze deren Historie, Zusammenhänge und Tendenzen. Das für das Verständnis des Buches notwendige Grundwissen bezüglich Struktur und Bestandteilen von Automotive SPICE wird kompakt vermittelt.

Kapitel 2 (Interpretationen zur Prozessdimension) behandelt eine praxisgerechte Auswahl von Automotive SPICE-Prozessen im Detail und erläutert jeweils den Zweck des Prozesses, die Basispraktiken und die Arbeitsprodukte. Enthalten sind auch deutsche Übersetzungen der Normtexte sowie Hinweise für Assessoren. Ein separater Abschnitt ist dem wichtigen Thema der »Traceability« gewidmet.

Kapitel 3 (Interpretationen zur Reifegraddimension) erklärt, wie Reifegradstufen gemessen werden, und beschreibt und interpretiert im Detail die Reifegradstufen, Prozessattribute und die generischen Praktiken. Auch hier sind deutsche Übersetzungen der Normtexte sowie Hinweise für Assessoren enthalten.

Kapitel 4 (CMMI – Unterschiede und Gemeinsamkeiten) trägt dem Faktum Rechnung, dass CMMI in vielen Fällen in der Automobilindustrie zusätzlich zu Automotive SPICE eingesetzt wird. Strukturen, Inhalte und Untersuchungsmethoden der beiden Modelle werden in der gebotenen Kürze verglichen, um den betroffenen Personen eine erste Orientierungshilfe zu geben.

Kapitel 5 (Funktionssicherheit) gibt einen kurzen Überblick über die IEC 61508, die in den nächsten Jahren einen größeren Rollout in der Automobilindustrie erleben wird. Diese stellt ebenfalls Forderungen an Entwicklungsprozesse und Methoden. Viele der Automotive SPICE Prozesse tragen zur Erfüllung dieser Anforderungen bei, die IEC 61508 Forderungen gehen aber an vielen Stellen deutlich darüber hinaus.

Der Anhang enthält eine Übersicht ausgewählter Arbeitsprodukte, ein Glossar, ein Abkürzungsverzeichnis und Verzeichnisse von Webadressen, Literatur und Normen.

Die zahlreichen deutschen Übersetzungen der Modelltexte wurden kursiv gesetzt. Bei der Übersetzung haben wir uns sehr eng an das englische Original gehalten, waren jedoch in einigen Fällen, wenn eine wörtliche Übersetzung nicht sinnvoll war, zu einer freieren Übersetzung gezwungen. In Zweifelsfällen und bei schwierigen Interpretationsfragen sollte daher immer auch der englische Originaltext hinzugezogen werden.

Unsere Interpretationen, Hinweise und Tipps basieren auf unseren praktischen Erfahrungen und wurden mit der größtmöglichen Sorgfalt niedergeschrieben. Dennoch müssen wir darauf hinweisen, dass die Konformität mit Automotive SPICE immer einer Einzelfallbeurteilung im jeweiligen Kontext des Unternehmens und der Projekte bedarf. Daran wollen und können wir mit diesem Buch nichts ändern. Insofern übernehmen wir keine Gewährleistung für den Erfolg von Implementierungen, basierend auf den von uns gegebenen Interpretationen, Empfehlungen und Beispielen.

Bedanken möchten wir uns bei Frau Christa Preisendanz (dpunkt.verlag) für die gewohnt professionelle Abwicklung und bei unserer konstruktiven Reviewerin, Frau Prof. Dr. Heidi Heilmann. Bei unseren Familien bedanken wir uns für das aufgebrachte Verständnis angesichts diverser zeitlicher Engpässe.

Markus Müller, Klaus Hörmann, Lars Dittmann, Jörg ZimmerJuni 2007

Inhaltsübersicht

1        Einführung und Überblick

2        Interpretationen zur Prozessdimension

3        Interpretationen zur Reifegraddimension

4        Automotive SPICE-Assessments

5        Funktionale Sicherheit und Automotive SPICE

6        Agilität und Automotive SPICE

Anhang

A        Beispiele zu Assessmentplanung und Assessmentdokumentation

B        Übersicht ausgewählter Arbeitsprodukte

C        Glossar

D        Abkürzungsverzeichnis

E        Literatur, Normen und Webadressen

Index

Inhaltsverzeichnis

1        Einführung und Überblick

1.1      Einführung in die Thematik

1.2      Überblick über die in der Automobilentwicklung relevanten Modelle

1.3      intacs™ (International Assessor Certification Scheme)

1.4      Automotive SPICE: Struktur und Bestandteile

1.4.1    Die Prozessdimension

1.4.2    Die Reifegraddimension

1.5      Umsetzungsaspekte: Tipps für eine nachhaltige Prozessverbesserung

2        Interpretationen zur Prozessdimension

2.1      ACQ.4 Lieferantenmanagement

2.1.1    Zweck

2.1.2    Basispraktiken

2.1.3    Ausgewählte Arbeitsprodukte

2.1.4    Besonderheiten Level 2

2.2      SPL.2 Releasemanagement

2.2.1    Zweck

Exkurs:    Musterphasen in der Automobilindustrie

2.2.2    Basispraktiken

2.2.3    Ausgewählte Arbeitsprodukte

2.2.4    Besonderheiten Level 2

2.3      SYS.1 Anforderungserhebung

2.3.1    Zweck

2.3.2    Basispraktiken

2.3.3    Ausgewählte Arbeitsprodukte

2.3.4    Besonderheiten Level 2

2.4      SYS.2 Systemanforderungsanalyse

2.4.1    Zweck

Exkurs:    »System«

2.4.2    Basispraktiken

2.4.3    Ausgewählte Arbeitsprodukte

2.4.4    Besonderheiten Level 2

2.5      SYS.3 Systemarchitekturdesign

2.5.1    Zweck

2.5.2    Basispraktiken

2.5.3    Ausgewählte Arbeitsprodukte

2.5.4    Besonderheiten Level 2

2.6      SYS.4 Systemintegration und Systemintegrationstest

2.6.1    Zweck

2.6.2    Basispraktiken

2.6.3    Ausgewählte Arbeitsprodukte

2.6.4    Besonderheiten Level 2

2.7      SYS.5 Systemtest

2.7.1    Zweck

2.7.2    Basispraktiken

2.7.3    Ausgewählte Arbeitsprodukte

2.7.4    Besonderheiten Level 2

2.8      SWE.1 Softwareanforderungsanalyse

2.8.1    Zweck

2.8.2    Basispraktiken

Exkurs:    Beispielmethode Hazard and Operability Study (HAZOP)

2.8.3    Ausgewählte Arbeitsprodukte

2.8.4    Besonderheiten Level 2

2.9      SWE.2 Softwarearchitekturdesign

2.9.1    Zweck

2.9.2    Basispraktiken

2.9.3    Ausgewählte Arbeitsprodukte

2.9.4    Besonderheiten Level 2

2.10    SWE.3 Softwarefeinentwurf und Softwaremodulerstellung

2.10.1  Zweck

2.10.2  Basispraktiken

2.10.3  Ausgewählte Arbeitsprodukte

2.10.4  Besonderheiten Level 2

2.11    SWE.4 Softwaremodulverifikation

2.11.1  Zweck

Exkurs:    Einheitliche Verifikations- und Teststrategie – Korrespondenz der realen Prozesse zu Automotive SPICE-Prozessen

2.11.2  Basispraktiken

2.11.3  Ausgewählte Arbeitsprodukte

2.11.4  Besonderheiten Level 2

Exkurs:    Testdokumentation nach ISO/IEC/IEEE 29119-3

2.12    SWE.5 Softwareintegration und Softwareintegrationstest

2.12.1  Zweck

2.12.2  Basispraktiken

Fallbeispiel:    Softwareintegration eines Projekts bei der XY AG

2.12.3  Ausgewählte Arbeitsprodukte

2.12.4  Besonderheiten Level 2

2.13    SWE.6 Softwaretest

2.13.1  Zweck

2.13.2  Basispraktiken

Exkurs:    Kurzer Überblick über Testmethoden

Exkurs:    Einige Methoden zur Ableitung von Testfällen

2.13.3  Ausgewählte Arbeitsprodukte

2.13.4  Besonderheiten Level 2

2.14    SUP.1 Qualitätssicherung

2.14.1  Zweck

2.14.2  Basispraktiken

2.14.3  Ausgewählte Arbeitsprodukte

2.14.4  Besonderheiten Level 2

2.15    SUP.2 Verifikation

2.15.1  Zweck

2.15.2  Basispraktiken

2.15.3  Ausgewählte Arbeitsprodukte

2.15.4  Besonderheiten Level 2

2.16    SUP.4 Gemeinsame Reviews

2.16.1  Zweck

2.16.2  Basispraktiken

2.16.3  Ausgewählte Arbeitsprodukte

2.16.4  Besonderheiten Level 2

2.17    SUP.8 Konfigurationsmanagement

2.17.1  Zweck

2.17.2  Basispraktiken

2.17.3  Ausgewählte Arbeitsprodukte

2.17.4  Besonderheiten Level 2

2.18    SUP.9 Problemmanagement

2.18.1  Zweck

2.18.2  Basispraktiken

2.18.3  Ausgewählte Arbeitsprodukte

2.18.4  Besonderheiten Level 2

2.19    SUP.10 Änderungsmanagement

2.19.1  Zweck

2.19.2  Basispraktiken

2.19.3  Ausgewählte Arbeitsprodukte

2.19.4  Besonderheiten Level 2

2.20    MAN.3 Projektmanagement

2.20.1  Zweck

2.20.2  Basispraktiken

Exkurs:    Verteilte Funktionsentwicklung und Integrationsstufen

2.20.3  Ausgewählte Arbeitsprodukte

2.20.4  Besonderheiten Level 2

2.21    MAN.5 Risikomanagement

2.21.1  Zweck

2.21.2  Basispraktiken

2.21.3  Ausgewählte Arbeitsprodukte

2.21.4  Besonderheiten Level 2

2.22    MAN.6 Messen

2.22.1  Zweck

Exkurs:    Goal/Question/Metric-(GQM-)Methode

2.22.2  Basispraktiken

2.22.3  Ausgewählte Arbeitsprodukte

2.22.4  Besonderheiten Level 2

2.23    PIM.3 Prozessverbesserung

2.23.1  Zweck

2.23.2  Basispraktiken

2.23.3  Ausgewählte Arbeitsprodukte

2.23.4  Besonderheiten Level 2

2.24    REU.2 Wiederverwendungsmanagement

2.24.1  Zweck

2.24.2  Basispraktiken

2.24.3  Ausgewählte Arbeitsprodukte

2.24.4  Besonderheiten Level 2

2.25    Traceability und Konsistenz in Automotive SPICE

2.25.1  Einleitung

2.25.2  Grundgedanken

2.26    Applikationsparameter in Automotive SPICE

2.26.1  Ausgewählte Arbeitsprodukte

3        Interpretationen zur Reifegraddimension

3.1      Struktur der Reifegraddimension

3.1.1    Levels und Prozessattribute

3.1.2    Indikatoren für die Reifegraddimension

3.2      Wie werden Levels gemessen?

3.3      Erweiterungen der ISO/IEC 33020

3.4      Die Levels

3.4.1    Level 0 (»Unvollständiger Prozess«)

3.4.2    Level 1 (»Durchgeführter Prozess«)

3.4.3    Level 2 (»Gemanagter Prozess«)

3.4.4    Level 3 (»Etablierter Prozess«)

Exkurs:    Tailoring von Prozessen

3.4.5    Level 4 (»Vorhersagbarer Prozess«)

3.4.6    Level 5 (»Innovativer Prozess«)

3.5      Zusammenhang von Prozess- und Reifegraddimension

4        Automotive SPICE-Assessments

4.1      Assessments – Überblick und Grundlagen

4.2      Phasen, Aktivitäten und Dauer des Assessmentprozesses

4.3      Rollen im Assessmentprozess

4.4      Komplexe Assessments

5        Funktionale Sicherheit und Automotive SPICE

5.1      Überblick funktionale Sicherheit und ISO 26262

5.2      Vergleich von ISO 26262 und Automotive SPICE

5.3      Unterschiede zwischen ISO 26262 und Automotive SPICE

5.3.1    Unterschiede im Scope der Standards

5.3.2    Unterschiede in den Levels

5.3.3    Unterschiede in den Aktivitäten und Rollen

5.3.4    Unterschiede in den Arbeitsprodukten

5.3.5    Unterschiede in den Methodenanforderungen

5.3.6    Unterschiede in den Unabhängigkeitsanforderungen

5.4      Kombination von Automotive SPICE-Assessments und funktionalen Safety-Audits

5.4.1    Kombination von Automotive SPICE-Assessment und Safety-Audit

5.4.2    Weitere zu beachtende Aspekte

5.5      Zusammenfassung ISO 26262 und Automotive SPICE

6        Agilität und Automotive SPICE

6.1      Warum sich mit Agilität und Automotive SPICE beschäftigen?

6.2      Was bedeutet »Agilität in Automotive« ?

6.2.1    Was macht eine agile Entwicklung aus?

6.2.2    »Agile in Automotive (AiA)«: Welche agilen Methoden und Praktiken werden in der Automobilentwicklung aktuell eingesetzt?

6.2.3    Welche Herausforderungen werden demnächst angegangen ?

Exkurs:    Continuous Integration

6.3      Wie bringt man Agilität und Automotive SPICE zusammen?

6.3.1    Grundsätzliches

6.3.2    Was sind die kritischen Punkte in der Praxis?

6.3.3    Konkrete praktische Lösungsbeispiele

6.4      Agilität, Automotive SPICE und funktionale Sicherheit

6.5      Zusammenfassung Agilität und Automotive SPICE

Anhang

A        Beispiele zu Assessmentplanung und Assessmentdokumentation

A.1      Fall 1: Einfaches Projektassessment Tier-1-Lieferant

A.1.1    Beispiel eines Assessmentplans

A.1.2    Beispiel einer Assessmentagenda bis Level 3

A.1.3    Beispielstruktur eines Assessmentberichts

A.1.4    Beispielbewertung eines Prozesses inklusive Dokumentation

A.1.5    Beispiel: Auszug aus der Liste der analysierten Evidenzen/Dokumente

A.2      Fall 2: Komplexes Projektassessment, mehrere Instanzen

A.2.1    Beispiel: Planung der Prozessinstanzen pro Prozess

A.2.2    Beispiel: Assessmentagenda

A.2.3    Beispiel: Konsolidierungs- und Aggregationsregeln

B        Übersicht ausgewählter Arbeitsprodukte

C        Glossar

D        Abkürzungsverzeichnis

E        Literatur, Normen und Webadressen

Index

1 Einführung und Überblick

Dieses Kapitel besteht aus fünf Teilen: In Abschnitt 1.1 beschäftigen wir uns mit der Frage, warum Automotive SPICE und weitere Modelle mit steigender Tendenz eingesetzt werden. In Abschnitt 1.2 geben wir einen kurzen Überblick über die in der Automobilentwicklung relevanten Modelle, deren Historie und die sich abzeichnenden Tendenzen. Abschnitt 1.3 beschreibt intacs, das in der Automobilindustrie etablierte und offiziell anerkannte Ausbildungssystem. Abschnitt 1.4 erläutert die wesentlichen Strukturen von Automotive SPICE, soweit sie für das Verständnis der restlichen Kapitel notwendig sind. Abschnitt 1.5 widmet sich den Umsetzungsaspekten in Form von Tipps für eine nachhaltige Prozessverbesserung.

1.1 Einführung in die Thematik

In der globalisierten Weltwirtschaft werden Produkte und Dienstleistungen kaum noch von einzelnen Unternehmen isoliert entwickelt. Unternehmen sind zunehmend gezwungen, ihre Entwicklung in einem Netz von weltweiten Entwicklungsstandorten, Lieferanten und gleichberechtigten Partnern durchzuführen. Der entscheidende Treiber hierfür ist der stetig steigende Kostendruck, der die Unternehmen zur Entwicklung an Niedrigkostenstandorten und zu strategischen Partnerschaften zwingt. Da gleichzeitig die Produkte immer komplexer und anspruchsvoller werden und sich die Entwicklungszeiten verkürzen, haben sich zwei kritische Themen herauskristallisiert:

Wie können die komplexen Kooperationen und Wertschöpfungsketten beherrscht werden?

Wie können unter diesen Umständen Qualität, Kosten- und Termineinhaltung sichergestellt werden?

Dies ist für viele Unternehmen zur existenziellen Herausforderung geworden, mit unmittelbarer Auswirkung auf Markterfolg und Wachstum. Ein entscheidender Erfolgsfaktor bei diesen Fragen sind systematische und beherrschte Prozesse, insbesondere für Management, Entwicklung, Qualitätssicherung, Einkauf und für die Kooperation mit externen Partnern. Die Methodik der »Reifegradmodelle« bietet sich geradezu an, um dieser Probleme Herr zu werden.

Reifegradmodelle wie Automotive SPICE und CMMI werden schon seit vielen Jahren erfolgreich zu diesem Zweck eingesetzt. Historisch begann es mit CMM und dessen Nachfolger CMMI, mit denen enormen Qualitäts-, Kostenund Zeitproblemen entgegengewirkt wurde. Es ist bei vielen Auftraggebern üblich, von Lieferanten einen bestimmten CMMI- oder Automotive SPICE-Level zu verlangen, bevor ein Angebot akzeptiert wird. In der Automobilindustrie wollen die Hersteller damit das Risiko hinsichtlich Qualität, Zeit und Funktionsumfang in den Lieferantenprojekten reduzieren.

1.2 Überblick über die in der Automobilentwicklung relevanten Modelle

Das erste Reifegradmodell, das weite Verbreitung fand, war Anfang der 90erJahre CMM (siehe [CMM 1993a], [CMM 1993b]). In der Automobilindustrie hat CMM nie eine nennenswerte Rolle gespielt, auch wenn ein Automobilhersteller damit für kurze Zeit Ansätze zur Lieferantenbeurteilung erprobte. Das SPICE-kompatible BOOTSTRAP wurde bei wenigen Pionieren unter den Automobilzulieferern eingesetzt, konnte sich aber gegenüber SPICE nie durchsetzen und wurde 2003 eingestellt.

SPICE1 (siehe [Hörmann et al. 2006]) entstand aus einem gleichnamigen Projekt der ISO2 und wurde 1998 als ISO/IEC TR 15504 veröffentlicht, wobei TR (Technical Report) eine Vorstufe zu einem späteren International Standard (IS) darstellt. Die verschiedenen Teile des International Standard ISO/IEC 15504 erschienen sukzessive ab 2003. 2006 erschien der für die Praxis wichtigste Teil 5, der 2012 eine neue Version erhielt. 2008 erschien der Teil 7 (»Assessment of organizational maturity«), der normative Grundlagen von Organisationsassessments definierte. Im Gegensatz zu den sonst üblichen Projektassessments kann hier die Reife einer Organisation anhand einer größeren Zahl von Untersuchungsstichproben beurteilt werden. Bisher wurden auf dieser Grundlage erfolgreich einige Pilotassessments durchgeführt. In der Breite hat sich diese Methodik noch nicht durchgesetzt. Wir gehen darauf in Abschnitt 4.4 näher ein.

Die ISO/IEC 15504 wird seit 2015 sukzessive in die ISO/IEC-33000-Familie [ISO/IEC 33000] überführt. Die folgenden Normen sind die Basisnormen, auf die das Automotive SPICE-Modell aufsetzt:

ISO/IEC 33001 Concepts & Terminology

ISO/IEC 33002 Requirements for Performing Process Assessment

ISO/IEC 33003 Requirements for Process Measurement Frameworks

ISO/IEC 33004 Requirements for Process Models

ISO/IEC 33020 Measurement Framework for assessment of process capability and organizational maturity

Der Durchbruch zum Einsatz von Reifegradmodellen in der Automobilindustrie geschah 2001 durch die Entscheidung der Herstellerinitiative Software (HIS)3, SPICE zur Lieferantenbeurteilung im Software- und Elektronikbereich einzusetzen. Ab diesem Zeitpunkt verbreitete sich SPICE flächendeckend in der Automobilindustrie. Einer der großen Vorzüge von SPICE ist, unter einem gemeinsamen normativen Framework branchenspezifische Modelle entwickeln zu können. Davon machte u.a. die Automobilindustrie Gebrauch: 2005 veröffentlichte die Automotive Special Interest Group (AUTOSIG) das Automotive SPICE-Modell (siehe [Automotive SPICE]) und löste damit SPICE ab. Automotive SPICE wird heute durch den VDA-Arbeitskreis 134 weiterentwickelt. Nach einigen Jahren der Versionspflege erschien 2015 die Version 3.0, die neben inhaltlichen Weiterentwicklungen auch einige strukturelle Änderungen mit sich brachte.

Die Lieferanten müssen neben Automotive SPICE insbesondere die Forderungen nach funktionaler Sicherheit von elektrisch-elektronischen Systemen in Pkws erfüllen. 2011 erschien die ISO 26262 (»Road vehicles – Functional safety«) [ISO 26262] und löste eine neue Umsetzungswelle in der Automobilindustrie aus. Das Verhältnis der beiden Modelle kann man etwa wie folgt zusammenfassen: Beide Modell besitzen Anforderungen an Prozesse, die sich teilweise überlappen, aber auch teilweise unterschiedlich sind. Dabei wirkt Automotive SPICE (ab Level 2, besser noch ab Level 3) sehr förderlich für die Umsetzung von funktionaler Sicherheit (für Details siehe Kap. 5).

1.3 intacs™ (International Assessor Certification Scheme)

intacs ist das weltweit führende Ausbildungs- und Zertifizierungssystem für ISO/IEC-33000-konforme Modelle und ist auch in der Automobilindustrie als Ausbildungssystem etabliert und offiziell anerkannt5. intacs hat in den letzten zwölf Jahren eine weltweite Community aufgebaut, die Prozessassessments, basierend auf der ISO/IEC-15504- bzw. ISO/IEC-33000-Familie, unterstützt. Es wurde 2006 gegründet und verzeichnet derzeit über 30 Mitgliedsorganisationen, darunter Automobilhersteller und -zulieferer, Trainings- und Beratungsunternehmen sowie Vertreter aus der Forschung. Die Organisation ist nicht gewinnorientiert und arbeitet ausschließlich mit ehrenamtlichen Mitarbeitern, die ohne Ausnahme sehr erfahrene Assessoren sind.

Abb. 1–1 Die intacs-Assessoren- und -Instruktorenstufen

intacs hat ein Ausbildungssystem aufgebaut, das weltweit anerkannt und verwendet wird. Dabei werden drei Assessorenstufen und zwei Instruktorenstufen unterschieden (siehe Abb. 1–1). Die unteren beiden Assessorenstufen werden nur für einzelne Prozessassessmentmodelle zertifiziert (»PAM-specific certification«), die Principal Assessoren sind für alle PAMs zugelassen. Für alle Stufen gibt es Lehrund Prüfungspläne sowie standardisierte Trainingsmaterialien. Diese werden von denjenigen intacs-Mitgliedsorganisationen verwendet, die auch als Trainingsanbieter tätig sind. Nicht-intacs-Trainingsanbieter können ihre Trainingsmaterialien von intacs auf Konformität mit den Lehrplänen validieren lassen.

Das Grundprinzip des intacs-Ausbildungssystems ist die organisatorische Trennung der Definition des Ausbildungssystems von der Zertifizierung (inklusive Prüfung) der Assessoren und der Durchführung der Trainings (siehe Abb. 1–2). In der Automobilindustrie ist der VDA QMC der maßgebliche »Certification Body«, für alle anderen Modelle ist die ECQA zuständig.

Abb. 1–2 Organisatorische Trennung der Definition des Ausbildungssystems von der Zertifizierung (inkl. Prüfung) der Assessoren und der Durchführung der Trainings

Seit der Gründung wurden weltweit ca. 3.300 Prüfungen durch die Zertifizierungsorganisationen durchgeführt. Zum Beispiel kann sich eine Person nach Absolvierung des intacs™ Provisional Assessor Training für Automotive SPICE und nach bestandener Prüfung bei der zuständigen Zertifizierungsorganisation (VDA QMC) gegen Zahlung einer Gebühr für drei Jahre registrieren lassen. Sie erhält dadurch den Status »intacs™ Provisional Assessor (Automotive SPICE)« sowie eine »Authorisation Card« mit aufgedruckter Zertifizierungsnummer. Dieser Status ist in der Automobilindustrie der Qualifikationsnachweis schlechthin für Automotive SPICE. Man kann danach als Co-Assessor an offiziellen, intacsanerkannten Assessments teilnehmen und, wenn man genügend Erfahrung gesammelt hat, das intacs™ Competent Assessor Training für Automotive SPICE besuchen und die Prüfung ablegen. Zusätzlich zu diesem Training (davor oder danach) durchlaufen Provisional Assessoren in der Regel mehrere Ausbildungsassessments, in denen sie schrittweise die Aufgaben eines Lead Assessors wahrnehmen und dabei von einem erfahrenen Assessor6 gecoacht und beobachtet werden. Der beobachtende Assessor füllt einen detaillierten »Observation Report« aus mit Bewertungen und detaillierten Befunden in mehreren Kategorien, die alle erforderlichen Fähigkeiten eines Lead Assessors abdecken. Ist die Competent-Assessor-Prüfung bestanden und ist die Observation positiv verlaufen, kann sich der Kandidat beim VDA QMC als »intacs™ Competent Assessor (Automotive SPICE)« registrieren lassen.

Ende 2015 waren weltweit ca. 1.250 Assessoren bei den Zertifizierungsorganisationen registriert, darunter ca. 1.105 Provisional Assessoren, ca. 100 Competent Assessoren und ca. 45 Principal Assessoren.

Weitere wichtige Aufgaben von intacs sind:

Die Förderung der Entwicklung und Erprobung von neuen Prozessassessmentmodellen (PAMs). In den letzten Jahren wurden mit Unterstützung von intacs z.B. das TestSPICE PAM und das ISO/IEC 20000 PAM entwickelt und in das Ausbildungssystem integriert. Das Gleiche gilt für neue PAM-Versionen wie z.B. die Transition von Automotive SPICE v2.5 zu v3.0.

Die Förderung der Interaktion in der Community der Assessoren, Instruktoren und Anwender der von intacs betreuten Modelle. Hierzu gehören sowohl intacs-interne Arbeitskreise als auch öffentliche Veranstaltungen (in Deutschland »Gate4SPICE« genannt), in denen sich Unternehmen treffen und Erfahrungen und Neuigkeiten austauschen.

Eine Plattform für Arbeitsgruppen und Interessierte rund um das Thema SPICE zu bieten. Aus dem Bedarf der Mitglieder haben sich hier mehrere interessante Arbeitsgruppen gebildet, zum Beispiel zu Themen wie Mechanikund Mechatronik-SPICE und die Arbeitsgruppe »Trustworthy Assessments«, die sich mit komplexen Assessments und Organisationsassessments beschäftigt. Eine weitere wichtige Arbeitsgruppe ist die Gruppe »Internationalisierung«, die die weltweite Verbreitung von intacs vorantreibt. In Japan gibt es z.B. eine weitere sehr große Community mit Fokus auf die Automobil- und die Luft- und Raumfahrtindustrie. Ableger von Gate4SPICE gibt es in Indien und Italien. Weitere Länder wie Korea sind Stand 2016 auf dem Sprung, und in vielen Ländern gibt es »Regional Representatives« von intacs.

1.4 Automotive SPICE: Struktur und Bestandteile

Automotive SPICE besteht aus einem Prozessreferenzmodell (PRM) und einem Prozessassessmentmodell (PAM), die in einem gemeinsamen Dokument enthalten sind und sich durch Farbcodes unterscheiden. Für die praktische Anwendung ist die Kenntnis des Prozessassessmentmodells7 relevant und ausreichend, auf das wir uns daher im Folgenden beschränken.8

Das Prozessassessmentmodell enthält die Details zur Bewertung der Prozessreife (sog. Indikatoren) und ist in zwei Dimensionen organisiert:

Prozessdimension

Diese enthält für alle Prozesse die Indikatoren für die Prozessdurchführung (»process performance indicators«). Mit diesen wird beurteilt, inwieweit die Prozesse durchgeführt werden. Diese Indikatoren sind für jeden Prozess verschieden und bilden eine wichtige Voraussetzung zur Erreichung von Level 1.

Reifegraddimension

Diese enthält die Indikatoren für die Prozessfähigkeit (»process capability indicators«). Mit diesen wird beurteilt, welcher Level erreicht wird. Diese Indikatoren sind für alle Prozesse gleich.

Abbildung 1–3 zeigt die zwei Dimensionen des Prozessassessmentmodells sowie dessen Quellen: Die Reifegraddimension (y-Achse) basiert auf den Vorgaben der ISO/IEC 33020 und fügt dieser die Indikatoren für die Prozessfähigkeit hinzu. Die Prozessdimension basiert auf dem Automotive SPICE-Prozessreferenzmodell und fügt diesem die Indikatoren für die Prozessdurchführung hinzu.

Abb. 1–3 Die zwei Dimensionen von Automotive SPICE (in Anlehnung an Figure 1 und Figure 3 in [Automotive SPICE])

1.4.1 Die Prozessdimension

Die in Automotive SPICE verwendeten Prozesse sind in Abbildung 2–1 dargestellt. Jeder Prozess hat den in Abbildung 1–4 gezeigten Aufbau. Basispraktiken sind modellhafte Aktivitäten9, durch deren Umsetzung die Prozessergebnisse (»process outcomes«) erzielt werden sollen. Die Prozessergebnisse sind eine Detaillierung des Prozesszweckes (»process purpose«), sie spezifizieren, was durch den Prozess erreicht werden soll. Arbeitsprodukte10 (»output work products«) sind modellhafte, typische Ergebnisse eines Prozesses. Zusammen mit den Basispraktiken stellen sie objektive Nachweise für die Erfüllung des Zweckes des Prozesses dar. Sie werden daher als Indikatoren für die Prozessdurchführung (»process performance indicators«) bezeichnet und sind die Kriterien für die Erreichung von Level 1.

Abb. 1–4 Aufbau eines Prozesses in Automotive SPICE

1.4.2 Die Reifegraddimension

Automotive SPICE verwendet sechs Levels für Prozesse (siehe Abb. 1–5). Die Levels bauen aufeinander auf. Jede höhere Stufe beinhaltet die Anforderungen der darunterliegenden Stufen.

Die Levels haben folgende Bedeutung:

Abb. 1–5 Die sechs Levels

Level 0:Unvollständig

Der Prozess ist nicht implementiert oder der Zweck des Prozesses wird nicht erfüllt. Projekterfolge sind durchaus möglich, basieren dann aber häufig auf den individuellen Leistungen der Mitarbeiter.

Level 1:Durchgeführt

Der implementierte Prozess erfüllt den Zweck des Prozesses. Dies bedeutet, dass grundlegende Praktiken sinngemäß implementiert sind und definierte Prozessergebnisse erzielt werden.

Level 2:Gemanagt

Die Prozessausführung wird zusätzlich geplant und verfolgt und die Planung ständig fortgeschrieben. Die Arbeitsprodukte des Prozesses sind adäquat implementiert, stehen unter Konfigurationsmanagement und werden qualitätsgesichert gesteuert und fortgeschrieben.

Level 3:Etabliert

Es existiert ein organisationseinheitlich festgelegter Standardprozess. Ein Projekt verwendet eine angepasste Version dieses Standardprozesses, einen sogenannten »definierten Prozess«, der daraus mittels »Tailoring« abgeleitet wird. Dieser ist in der Lage, definierte Prozessergebnisse zu erreichen. Zur Messung und Verbesserung der Prozesseffektivität gibt es einen Feedbackmechanismus.

Level 4:Vorhersagbar

Bei der Ausführung des definierten Prozesses werden detaillierte Messungen durchgeführt und analysiert, die zu einem quantitativen Verständnis des Prozesses und einer verbesserten Vorhersagegenauigkeit führen. Messdaten werden gesammelt und analysiert, um zuordenbare Gründe für Abweichungen zu ermitteln. Korrekturmaßnahmen werden auf Basis eines quantitativen Verständnisses durchgeführt.

Level 5:Innovativ

Die Prozesse werden fortlaufend verbessert, um auf Änderungen in Verbindung mit Organisationszielen zu reagieren. Innovative Ansätze und Techniken werden erprobt und ersetzen weniger effektive Prozesse, um dadurch vorgegebene Ziele besser zu erreichen. Die Effektivität der Änderung wird nachgewiesen.

Ob ein bestimmter Level vorliegt, wird anhand von Prozessattributen beurteilt. Die Prozessattribute sind den Levels zugeordnet und charakterisieren diese inhaltlich (siehe Abb. 1–6). Jedes Prozessattribut definiert einen bestimmten inhaltlichen Aspekt der Prozessreife, z.B. ist Level 2 durch die Attribute »Management der Prozessausführung« (d.h. Planung, Zuweisung von Verantwortlichkeiten und Ressourcen, Überwachung etc.) und »Management der Arbeitsprodukte« (d.h. Sicherstellung, dass die Anforderungen an Arbeitsprodukte erfüllt werden) definiert.

Abb. 1–6 Die Prozessattribute

Die Prozessattribute und deren Bewertung sind in Kapitel 3 im Detail erläutert. Die Bewertung der Prozessattribute erfolgt auf einer vierstufigen Bewertungsskala:

N    Not achieved bzw. nicht erfüllt

P    Partially achieved bzw. teilweise erfüllt

L    Largely achieved bzw. überwiegend erfüllt

F    Fully achieved bzw. vollständig erfüllt

Der Level wird aus den Prozessattributbewertungen nach einer einfachen Methode berechnet (siehe Kap. 3). Danach müssen die Prozessattribute des betreffenden Level mindestens mit L bewertet sein, um diesen Level zu erreichen, und alle Prozessattribute der darunter liegenden Levels müssen mit F bewertet sein.

1.5 Umsetzungsaspekte: Tipps für eine nachhaltige Prozessverbesserung

In unserer langjährigen Berufserfahrung trafen wir bei der Durchführung von Prozessverbesserungen häufig auf ähnliche Fragestellungen und Probleme. Wir wollen Ihnen mit diesem Abschnitt ein paar dieser Probleme aufzeigen und Denkanstöße bzw. Ideen geben, damit Ihre Prozessverbesserungsaktivitäten und -programme in der Zukunft erfolgreicher werden.

Nachfolgend sind die wesentlichen Erfolgsfaktoren für eine nachhaltige Prozessverbesserung dargestellt.

Ausreichend Zeit einplanen – Erfolgsfaktor Zeit

Vor allem im Umfeld der SPICE-Assessments wird immer wieder vorgeschlagen, die Prozessverbesserung im betroffenen Unternehmen durch einen verstärkten internen und externen Kapazitätseinsatz zu beschleunigen. Das heißt, um von einem Level auf den nächsten zu gelangen, wird mit großem Personaleinsatz für einen bestimmten Zeitraum an der Abarbeitung von Maßnahmen aus vorangegangenen Assessments gearbeitet. Man geht davon aus, dass so der gewünschte Level innerhalb kurzer Zeit sicher erreicht wird.

Sicher, die Maßnahmen aus einem Assessment lassen sich so abarbeiten, aber die Resultate müssen von den Mitarbeitern verstanden, akzeptiert und verinnerlicht werden. Dafür vergehen erfahrungsgemäß mindestens 1–2 Jahre. In diesem Zeitraum können dann auch die Veränderungen an das Umfeld angepasst und weiter verbessert und optimiert werden. Daher wird auch in dieser Zeit erhöhte Kapazität benötigt.

Tipp: »Gut Ding braucht Weile.« Fangen Sie so früh wie möglich mit Ihrer Prozessverbesserungsinitiative an und planen Sie pro Level wirklich 1–2 Jahre an Zeit und Kapazität ein. Vereinbaren Sie die Verbesserungen mit Ihren Mitarbeitern und lassen Sie ihnen Zeit für die Umsetzung der Veränderungen. Diese betreffen deren tägliche Arbeit und der Mensch ist ein Gewohnheitstier, d.h., er hat seine übliche und bekannte Arbeitsweise, an die er gewöhnt ist, und kann sich nur langsam umstellen. Schaffen Sie eine Kultur der ständigen Verbesserung unter Einbeziehung der Mitarbeiter. Die Adaption der Veränderungen muss in dieser Zeit regelmäßig kontrolliert werden und Abweichungen durch die Prozesscoaches oder Führungskräfte abgestellt werden.

Interne Schlüsselkollegen ausreichend einbinden – Erfolgsfaktor Erfahrung

Prozessverbesserung erfordert Zusatzaufwand für Assessments, für die Umsetzung von Maßnahmen und das Ausrollen in die Organisation. Hier wird häufig externe Unterstützung gesucht.

Das mag in vielen Fällen sinnvoll sein. Es kommt aber immer darauf an, für welche Aufgaben die externe Unterstützung eingesetzt werden soll. Kann man z.B. ein Automotive SPICE-Assessment nicht selbst durchführen oder ist man ratlos, was man am Entwicklungsprozess verbessern soll, sind externe Experten hervorragend geeignet. Man sollte aber nie vergessen, dass diese weder genügend firmenspezifisches Wissen und Erfahrung besitzen noch den Rückhalt in der eigenen Mannschaft.

Tipp: Der Schlüssel zum Erfolg einer Prozessverbesserung ist die maßgebliche Beteiligung von internen, sehr erfahrenen Kollegen (Manager, erfahrene Entwickler, interne Know-how-Träger etc.) mit großem Rückhalt in der Entwicklungsmannschaft. Diese übernehmen die Verantwortung für die Prozessverbesserung und Kommunikation und lassen sich dabei von den externen Kollegen unterstützen. Nur so finden die Veränderungen interne Akzeptanz und die Kompetenz und das Verständnis für die Veränderungen bleiben auch nach dem Weggang der externen Verstärkung erhalten.

Tipp: Ergänzen Sie die Prozessverbesserung gezielt durch externe Experten, wenn das interne Know-how nicht ausreichend ist.

Beschluss zur Prozessverbesserung – Erfolgsfaktor Management

Für den Erfolg einer Prozessverbesserung ist es unabdingbar, sich die Zustimmung des verantwortlichen Managements einzuholen. Oft wird nur das Budget genehmigt und ein nachhaltiges Commitment bleibt aus. Doch was bedeutet »Zustimmung«? Ist das ein schriftlicher Beschluss? Ist es eine mündliche Zusage?

Tipp: Auch bei noch so kleinen Prozessverbesserungen ist immer ein schriftlicher Beschluss einzuholen. Dieser beinhaltet auch die Freigabe der benötigten, kompetenten, internen und ggf. auch externen Personalressourcen. Gibt es diesen Beschluss nicht, so steht auch das Management nicht voll hinter der Prozessverbesserungsinitiative. Dann wird auch im Ernstfall die Unterstützung ausbleiben und die Prozessverbesserung fehlschlagen. Daher sollte bei Ausbleiben einer verbindlichen Managementunterstützung die Initiative gestoppt werden.

Tipp: Ein weiterer Aspekt ist das nachhaltige Management Commitment durch kontinuierliches Einbinden des Managements in z.B. Steuerkreise oder durch eine aktive Wahrnehmung der Sponsorrolle.

Umfang und Reihenfolge der Prozessverbesserung – Erfolgsfaktor Umfang

Häufig wird nach einem Automotive SPICE-Assessment versucht, alle Befunde aus dem Assessment für das betroffene Projekt gleichzeitig anzugehen. Das kann zu einer Überforderung des Projekts führen. Außerdem sinkt zunächst die Qualität der Arbeitsprodukte und die Performance der Mitarbeiter zu Beginn der Prozessverbesserung, bevor sie am Ende der Prozessverbesserung über das ursprüngliche Maß hinauswachsen. Während einer Prozessverbesserung müssen die neuen und geänderten Prozesse durch die Mitarbeiter verstanden, gelernt und akzeptiert werden. In dieser Einarbeitungs- bzw. Lernphase entstehen natürlicherweise Fehler, die sich auf die Qualität des Produktes und auf die Performance der Mitarbeiter auswirken können.

Abb. 1–7 Zusammenhang von Zeit und Qualität/Performance bei Prozessverbesserungen

Tipp: Wenn die Maßnahmen nicht von einem OEM nachdrücklich gefordert werden, sollten in einem laufenden Projekt möglichst nur Maßnahmen mit gutem Kosten-Nutzen-Verhältnis angegangen werden. Weitere Veränderungen sollten vorbereitet und erst bei neu beginnenden Projekten umgesetzt werden.

Tipp: Denken Sie daran, in der Organisation parallel laufende Prozessverbesserungsinitiativen aufeinander abzustimmen! Am besten richten Sie eine zentrale Stelle zur Koordination der gesamten Prozessverbesserungen ein.

Tipp: Sorgen Sie in dieser Zeit für eine zusätzliche Unterstützung der eingebundenen Personen, da diese in der Regel gut ausgelastet sind. Ist beispielsweise ein erfahrener Projektleiter in die Prozessverbesserung des Projektmanagements intensiv eingebunden, so sollte er diese Unterstützung bei Routinetätigkeiten bekommen (z.B. durch eine Projektassistenz).

Transferarbeit zu den Mitarbeitern – Erfolgsfaktor Tooling & Kommunikation

Die notwendige Transferarbeit, damit Veränderungen von Mitarbeitern tatsächlich umgesetzt werden können, wird fast immer unterschätzt. Die neuen Prozesse, Methoden, Tools, Templates etc. sind oft noch nicht ganz ausgereift, passen noch nicht gut bzw. sind noch nicht richtig in die bestehende Toollandschaft integriert (z.B. doppelte Datenhaltung und manueller Transfer von Daten reduziert die Akzeptanz dramatisch) und ihre Benutzerfreundlichkeit ist schwach. Auch Kommunikation und Schulungen lassen häufig zu wünschen übrig.

Tipp: Erstellen Sie eine kleine Auswirkungsanalyse, z.B. eine SWOT-Analyse: Welche Prozessdokumentation muss geändert werden? Wie ändert sich ein Werkzeug? Ändern Sie alle betroffenen Dokumente und erstellen Sie einen Kommunikations- und Schulungsplan, um die Zielsetzung bzw. den Grund für die Änderungen sowie die Änderungen selbst in die Entwicklungsmannschaft nachhaltig zu kommunizieren. Stellen Sie eine Anlaufstelle für interne Unterstützung zur Verfügung, falls Mitarbeiter Probleme oder Fragen haben. Je weniger manuelle Schritte, desto erfolgversprechender ist der Ansatz.

Feedbackmechanismus – Erfolgsfaktor Feedback

Essenziell bei Prozessverbesserungen ist es, dass die Betroffenen eine Rückmeldung geben können in Form von Kritik, Fragen, Verbesserungsvorschlägen etc. Hier kann man viel falsch machen, insbesondere wenn die Mitarbeiter den Eindruck gewinnen, dass ihre Rückmeldungen ignoriert werden.

Tipp: Bieten Sie einen guten, toolgestützten Feedbackmechanismus an und kommunizieren Sie ihn an die Mitarbeiter. Mitarbeiter sollten in einer definierten Antwortzeit eine individuelle (nicht automatisch generierte) E-Mail erhalten und den Status ihrer Rückmeldung verfolgen können. Für die Organisation ist es wichtig, die Feedbacks tatsächlich auszuwerten und für Korrekturmaßnahmen zu nutzen. Dies kostet nicht unerheblich Aufwand und muss in der Personalplanung berücksichtigt werden.

Tipp: Planen Sie für die Umsetzung kurze Retroperspektiven, z.B. alle vier Wochen, damit das Feedback auch analysiert und ggf. rechtzeitig kleinere Nachschärfungen durchgeführt werden können.

Nachweis des Erfolgs – Erfolgsfaktor Messgrößen

Wie weisen Sie denn Ihren Auftraggebern den Erfolg Ihrer Prozessverbesserung nach? Erheben Sie bereits Prozess- oder Produktkennzahlen vor einer Prozessverbesserung? Erfahrungsgemäß fängt eine Organisation erst nach einem Assessment damit an. Automotive SPICE besitzt zwar den Prozess MAN.6 Measurement, der allerdings nicht im HIS Scope (gefüllte Kreise in Abb. 2–1) enthalten ist und daher selten verwendet wird.

Tipp: Erforschen Sie den Zusammenhang zwischen den geplanten Verbesserungen und den Geschäftszielen Ihrer Organisation und finden Sie geeignete Messgrößen, um die Auswirkungen zu verfolgen. Fangen Sie mit den Messungen VOR den Verbesserungen an, um den Vorher-Nachher-Effekt darstellen zu können.

Tipp: Prüfen Sie kontinuierlich die Prozesskonformität durch z.B. interne Audits, entsprechende Messgrößen und Kommunikation, damit die Prozessverbesserung nachhaltig aktiv bleibt.

Aufsetzen der Prozessverbesserung – Erfolgsfaktor Change Management

Wie setzen Sie Ihre Prozessverbesserung auf? Ist ein Automotive SPICE-Assessment von außen der Auslöser? Oder setzen Sie eine eigenständige größere Prozessverbesserungsinitiative auf?

Tipp: Prozessverbesserung bedeutet Change Management einschließlich Änderung der Unternehmenskultur. Planen Sie die Prozessverbesserungsinitiative als eigenständiges Projekt mit eigenen Zielen, Ressourcen und Plänen. Binden Sie das Management ein. Überwachen die den Fortschritt und kommunizieren Sie rechtzeitig.

2 Interpretationen zur Prozessdimension

Aus Platzgründen können wir leider nicht alle Prozesse von Automotive SPICE behandeln, sondern müssen uns auf eine sinnvolle Auswahl beschränken. Wir haben uns daher an den Prozessen orientiert, die aufgrund unserer Erfahrung aus Verbesserungsprojekten und vielen Assessments für die meisten Anwender – zumindest zu Beginn ihrer Verbesserungsaktivitäten – von zentraler Bedeutung sind. Außerdem sollten zumindest die Prozesse abgedeckt sein, die von der Herstellerinitiative Software (siehe Kap. 1) im Rahmen von Lieferantenassessments untersucht werden, da diese das bei Weitem größte Volumen an Assessments ausmachen.

Die in den nachfolgenden Kapiteln kursiv gedruckten Texte sind unsere freie Übersetzung der Automotive SPICE-Texte. Für ein tieferes Verständnis und in Zweifelsfragen sollte immer der englischsprachige Originaltext hinzugezogen werden [Automotive SPICE].

Abbildung 2–1 zeigt die in diesem Buch behandelten Prozesse (mit Kreisen markiert). Gefüllte Kreise bezeichnen die von den OEMs geforderten Prozesse (sog. HIS Scope). Bei reinen Softwarelieferanten fallen die SYS-Prozesse weg. Wenn keine Lieferanten eingesetzt werden, fällt ACQ.4 weg. Jeder der in Abbildung 2–1 markierten Prozesse ist in diesem Kapitel mit einem eigenen Abschnitt vertreten, der folgendermaßen aufgebaut ist:

Zweck

Der »Process Purpose«, wie in Automotive SPICE definiert, wird von uns ausführlich erläutert.

Basispraktiken

Die von Automotive SPICE definierten Basispraktiken werden einzeln und im Detail durchgesprochen. Den im Modell enthaltenen Anmerkungen (engl. notes) kommt in der Assessmentpraxis eine größere Bedeutung zu, als es sonst in Normen üblich ist. Sie stellen meistens Konkretisierungen bzw. Interpretationshinweise dar, die in Assessments häufig geprüft werden.

Abb. 2–1 Automotive SPICE-Prozesse und -Prozessgruppen

Ausgewählte Arbeitsprodukte

In Automotive SPICE wird eine große Zahl von Arbeitsprodukten definiert. Wir haben zu den für die Praxis wichtigen Arbeitsprodukten Erläuterungen und z.T. Beispiele angegeben. Dabei werden die Work-Product (WP)-ID und -Bezeichnung referenziert.

Besonderheiten Level 2

Da die generischen Praktiken (siehe Kap. 3) prozessunspezifisch definiert sind, ist für das praktische Verständnis eine prozessspezifische Interpretation hilfreich. Wir haben uns dabei in der Regel auf Level 2 beschränkt, da die Unterschiede auf Level 3 nicht so gravierend sind. Durch die Zwischenüberschriften »Zum Management der Prozessausführung« und »Zum Management der Arbeitsprodukte« wird auf die Prozessattribute PA 2.1 und PA 2.2 Bezug genommen.

Zusätzlich haben wir unregelmäßig vorkommende Gestaltungselemente verwendet:

Exkurse

An einigen Stellen sind weiterführende oder prozessübergreifende Ausführungen in Form von Exkursen dargestellt.

Hinweise für Assessoren

Damit wollen wir für den Einsatz im Assessment sowohl praktische Tipps (z.B. in Form von typischen Assessmentfragen) geben als auch auf besondere Probleme, häufige Schwachstellen und schwierige Bewertungssituationen hinweisen.

Erfahrungsberichte

Hier beschreiben wir typische Probleme oder Situationen aus der Praxis.

Zum besseren Verständnis der Prozesse erläutern wir vorab noch einige grundlegende Konzepte. Weitere Konzepte sind in [Automotive SPICE] im Annex D »Key Concepts« beschrieben.

Das V-Modell als zentrales Leitbild der technischen Prozesse

Die Systemprozesse SYS.2 bis SYS.5 und die Softwareentwicklungsprozesse SWE.1 bis SWE.6 bilden zusammen das V-Modell1. Parallel zu den Softwareentwicklungsprozessen könnten in Zukunft die Prozesse anderer Domänen hinzukommen, insbesondere die Hardware- und Mechanikentwicklungsprozesse. Diese existieren zwar noch nicht in Automotive SPICE2, in Zukunft könnte aber ein Assessmentumfang aus den Systemprozessen und den Domänenprozessen für Software, Hardware oder Mechanik zusammengestellt werden. Die davon unabhängigen Prozesse wie MAN.3, ACQ.4 und die unterstützenden Prozesse kommen wie bisher bei Bedarf hinzu.

Abb. 2–2 Das V-Modell als zentrales Leitbild (in Anlehnung an Figure D.2 in [Automotive SPICE])

Im V-Modell verwendete Begriffe »Element«, »Komponente«, »Modul« und »Bestandteil«

Teile des Systems bzw. der Software werden in verschiedenen Prozessen des V-Modells mit verschiedenen Begriffen benannt (siehe Abb. 2–3):

Eine Systemarchitektur spezifiziert die »Elemente« des Systems.

Eine Softwarearchitektur spezifiziert die »Elemente« der Software.

»Elemente« der Software werden hierarchisch in kleinere »Elemente« heruntergebrochen bis zu den »Komponenten« der Software, die die unterste Ebene der Softwarearchitektur darstellen.

Die »Komponenten« der Software werden im Feinentwurf beschrieben.

Eine »Komponente« der Software besteht aus ein oder mehreren »Softwaremodulen«.

Die »Bestandteile« auf der rechten Seite sind die implementierten Gegenstücke der »Elemente« und »Komponenten« auf der linken Seite. Dabei kann es eine 1:1- oder m:n-Beziehung geben.

Abb. 2–3 Verwendete Begriffe im V-Modell (in Anlehnung an Figure D.3 in [Automotive SPICE])

2.1 ACQ.4 Lieferantenmanagement

2.1.1 Zweck

Zweck des Prozesses ist es, die Leistungen des Lieferanten bezüglich der vereinbarten Anforderungen zu verfolgen und zu bewerten.

Dieser Prozess behandelt die Überwachung und Steuerung des Lieferanten sowie die Zusammenarbeit und Kommunikation mit diesem. Basis für die Zusammenarbeit sind eine erfolgte Lieferantenauswahl sowie eine vertragliche Vereinbarung zwischen Auftraggeber und Lieferant.

Beim Lieferantenmanagement können Methoden aus MAN- und SUP-Prozessen wie Projektmanagement, Risikomanagement, Messen und Änderungsmanagement angewendet werden, indem diese vom Auftraggeber zur Überwachung und Steuerung des Lieferanten eingesetzt werden.

Werden Entwicklungsleistungen an den Lieferanten vergeben, so müssen die Prozessschnittstellen aufeinander abgestimmt sein. Neben den Engineering-Prozessen sollten insbesondere die unterstützenden Prozesse wie z.B. Konfigurations- und Änderungsmanagement sowie Qualitätssicherung aufeinander abgestimmt sein.

Bei der Entwicklung von Automobilkomponenten arbeiten Fahrzeughersteller und Lieferanten3 meist sehr eng zusammen. Es gibt eine Vielzahl von Projektkonstellationen.

Eine einfache Anwendung von ACQ.4 ist beispielsweise der Fall, wenn der Automobilhersteller bereits entwickelte Komponenten einkauft, die nur in geringem Umfang angepasst werden. Komplexer wird die Anwendung von ACQ.4, wenn die Entwicklung größerer Komponenten vollständig bei einem Lieferanten durchgeführt wird.

Bei der Entwicklung von komplexen Komponenten im Automobil arbeiten oft mehrere Lieferanten mit. Bei einer derart vernetzten Entwicklung werden häufig Partnerschaften eingegangen, wobei meist einer der Lieferanten als Systemlieferant beauftragt wird, dessen Aufgabe es unter anderem ist, die übrigen Lieferanten zu steuern.

Oft entsteht dabei eine ganze Hierarchie von Auftraggeber-Auftragnehmer-Beziehungen, d.h., ein Lieferant (»tier one«) akquiriert weitere Systembestandteile von eigenen Unterlieferanten (»tier two«) und steuert die Zusammenarbeit. Häufig werden dem Lieferanten bestimmte Tier-two-Lieferanten durch den Auftraggeber vorgegeben oder der OEM schreibt gewisse Softwarekomponenten als zu integrierende Zulieferungen vor. Oft kommt es auch vor, dass der OEM4 wettbewerbskritische Funktionen selbst entwickelt, die in das Gesamtsystem integriert werden müssen. Der OEM ist somit gleichzeitig ein Tier-two-Lieferant, was besondere Herausforderungen an den Systemlieferanten stellt.

Daher kommt der Auswahl und Steuerung von Lieferanten in der Automobilentwicklung eine besondere Bedeutung zu.

Hinweise für Assessoren

Dieser Prozess wird nur dann assessiert, wenn die Organisation (z.B. ein Tier-one-Lieferant) Unterlieferanten (tier two) besitzt. Es wird also geprüft, wie der Lieferant seine Unterlieferanten überwacht und steuert. Dabei ist darauf zu achten, dass der Tier-one-Lieferant relevante OEM-Anforderungen an den Tier-two-Lieferanten weitergibt und diese um eigene Anforderungen ergänzt.

Der Prozess wird nur dann assessiert, wenn Entwicklungsleistungen (z.B. die Entwicklung von Komponenten) unterbeauftragt werden, ganze Prozesse (wie z.B. Testen) outgesourct werden oder Produktkomponenten eingekauft werden, die an die Projektbedürfnisse angepasst werden. Werden lediglich Ressourcen für Entwicklungstätigkeiten eingekaufta (auch »Body Leasing« genannt) oder nur Standardprodukte ohne Anpassungen (»Produkte von der Stange«b), ist ein Assessieren des Prozesses nicht sinnvoll, da ACQ.4 von einer starken Verzahnung der Entwicklungsprozesse ausgeht, was in diesen Fällen aber nicht zutrifft.

a. In diesem Fall arbeiten die Fremdmitarbeiter nach Prozessen des Auftraggebers und werden im Assessment bei Bedarf wie dessen eigene Mitarbeiter befragt.

b. Engl. COTS (Commercial off-the-shelf).

2.1.2 Basispraktiken

BP 1: Vereinbare gemeinsame Prozesse, gemeinsame Schnittstellen und auszutauschende Informationen und halte diese aktuell. Erstelle eine Vereinbarung über auszutauschende Informationen und gemeinsame Prozesse und gemeinsame Schnittstellen, Verantwortlichkeiten, Art und Häufigkeit von gemeinsamen Aktivitäten, Kommunikation, Besprechungen, Statusberichte und Reviews und halte diese aktuell.

Anmerkung 1: Gemeinsame Prozesse und Schnittstellen beinhalten gewöhnlich Projektmanagement, Anforderungsmanagement, Änderungsmanagement, Konfigurationsmanagement, Problemmanagement, Qualitätssicherung und Abnahme durch den Kunden.

Anmerkung 2: Gemeinsam durchzuführende Aktivitäten sollten einvernehmlich zwischen dem Kunden und dem Lieferanten vereinbart werden.

Anmerkung 3: Der Ausdruck Kunde bezieht sich in diesem Prozess auf die zu assessierende Organisation. Der Ausdruck Lieferant bezieht sich auf den Lieferanten der zu assessierenden Organisation5.

Im Rahmen der Projektabwicklung müssen die Prozesse und Schnittstellen zwischen Kunde6 und Lieferant abgestimmt und dokumentiert werden. Dies umfasst:

Vereinbarungen bezüglich durchzuführender Regelbesprechungen und Reviews (siehe BP 2 bis 4)

Planung und Steuerung der Kommunikation und der Schnittstellen, z.B. mittels eines Kommunikationsplans (siehe Abb. 3–9 sowie Abschnitt 3.4.3, Ausführungen zu GP 2.1.7)

Regelungen bezüglich des Austauschs von Arbeitsprodukten und Informationen, z.B. welche Arbeitsprodukte zur Verfügung gestellt werden, Datenaustauschformate, Art und Weise der Übermittlung (z.B. Verschlüsselung bei E-Mails oder Kommunikation über einen gemeinsamen Server mit Zugriff beider Seiten auf gemeinsame Projektdaten und -dokumente oder Cloud-Lösungen)

Abstimmung von Rollen und Verantwortlichkeiten

Planung und Abstimmung der Prozesse und Abläufe für gemeinsame Aktivitäten. Die Basispraktik fordert dies zumindest für die in der ersten Anmerkung genannten Prozesse. Darüber hinaus empfehlen sich auch Regelungen bezüglich gemeinsamer Tests – zumindest einer gemeinsam abgestimmten Teststrategie –, der Releaseplanung der beigestellten Produkte sowie bezüglich der durchgängigen Traceability über die Organisationsgrenzen hinweg (siehe hierzu auch Abschnitt 2.25).

Definition von Eskalationspfaden bei Problemen. Dies ist insbesondere wichtig, wenn mehrere Lieferanten beteiligt sind. Als oberstes Entscheidungsgremium kann ein Steuerkreis mit Vertretern aller Lieferanten dienen. Häufig verbreitet ist das Problem, dass die Verantwortung für eine detaillierte Analyse und Fehlerbeseitigung zwischen mehreren Partnern hin und her geschoben wird. Der Auftraggeber muss hierauf ein besonderes Augenmerk haben. Es ist sinnvoll, einen lieferantenübergreifenden Fehlermanagementprozess zu etablieren und den Hauptverantwortlichen klar zu benennen.

Verfolgung von offenen Punkten z.B. mittels einer gemeinsamen Offene-Punkte-Liste (OPL, siehe Abb. 2–4). Bei mehreren Lieferanten gilt die gleiche Problematik wie beim vorherigen Punkt.

Regelungen bezüglich Projektfortschrittsberichten des Lieferanten an den Kunden und Austausch von Projektplänen

Die Zusammenarbeit der Qualitätssicherung von Kunde und Lieferant7

Gute Praxis ist es, ein gemeinsames Projektteam zwischen Kunde und Lieferant zu installieren. So können zuverlässig (Haupt-)Verantwortliche (z.B. Funktionsverantwortliche) auf beiden Seiten benannt werden, die vom Projektstart an zusammenarbeiten.

BP 2: Tausche alle vereinbarten Informationen aus. Nutze die definierten gemeinsamen Schnittstellen zwischen Kunde und Lieferant zum Austausch aller vereinbarten Informationen.

Anmerkung 4: Die vereinbarten Informationen sollten alle relevanten Arbeitsprodukte enthalten.

Informationen und insbesondere Arbeitsprodukte wie Softwarelieferungen, Dokumentation etc. werden wie in BP 1 vereinbart regelmäßig ausgetauscht. Die vereinbarte Kommunikation muss über den Projektverlauf aufrechterhalten werden.

BP 3: Überprüfe die technische Entwicklung zusammen mit dem Lieferanten. Überprüfe die Entwicklung mit dem Lieferanten auf einer vereinbarten, regelmäßigen Basis. Dies umfasst technische Aspekte, Probleme und Risiken. Verfolge offene Punkte bis zum Abschluss.

Insbesondere zu technischen Fragen muss eine permanente Kommunikation im Projekt aufrechterhalten werden, um sicherzustellen, dass der Lieferant technische Anforderungen versteht und seine Aufgaben ordnungsgemäß und planmäßig erledigt. Hierzu dienen in erster Linie regelmäßige Projektbesprechungen zu technischen Themen, Problemen und Risiken. In Entwicklungsprojekten sind über den gesamten Projektverlauf meist eine Fülle von technischen Fragen und Problemen zu klären.

Außerdem sollten technische Arbeitsprodukte und Dokumente in gemeinsamen technischen Reviews bewertet werden. Dies bietet sich zu folgenden Dokumenten bzw. Liefergegenständen an:

Anforderungsspezifikationen (Lastenheft/Pflichtenheft)

Systemarchitektur (bei Systemlieferanten)

Softwarearchitektur

Schnittstellenspezifikationen

Testpläne und Testdokumentation, Benutzer- und sonstige Entwicklungsdokumentation, die vereinbart wurde

Abnahmetest (bzgl. Kundenabnahme)

Vorteilhaft ist es, technische Reviews mit geeigneten Reviewmethoden (z.B. Inspektionen) möglichst frühzeitig8 im Entwicklungsprozess durchzuführen (siehe auch SUP.4).

Die identifizierten technischen Fragen, Probleme und offenen Punkte müssen bis zu ihrem Abschluss verfolgt werden. Um sicherstellen, dass alle offenen Punkte termingerecht abgearbeitet werden, sollte die Abarbeitung durch eine gemeinsame Offene-Punkte-Liste (OPL, siehe Abb. 2–4) systematisch verfolgt werden. In dieser Liste können sowohl Punkte des Kunden als auch des Lieferanten verfolgt werden.

Abb. 2–4 Beispielstruktur einer Offene-Punkte-Liste (OPL)

BP 4: Überprüfe den Fortschritt des Lieferanten. Überprüfe regelmäßig wie vereinbart den Fortschritt des Lieferanten bezüglich Zeitplan, Qualität und Kosten. Verfolge offene Punkte bis zum Abschluss und führe Maßnahmen zur Abschwächung der Risiken durch.

Der Fortschritt beim Lieferanten wird regelmäßig überprüft9. Der Arbeitsfortschritt wird gegen den Plan bewertet, es werden signifikante Probleme (u.a. auch Qualitätsprobleme) und Risiken sowie die Terminsituation (insbesondere Terminverschiebungen und -prognosen) und eventuell auch die Ressourcensituation besprochen. Erfolgt die Vergütung nach Aufwand, werden auch die aufgelaufenen Kosten gegen den Kostenplan geprüft sowie Kostenprognosen beurteilt.

Automotive SPICE fordert weiterhin, dass für Risiken Maßnahmen zur Abschwächung der Risiken eingeleitet werden und dass Probleme und Maßnahmen bis zum Abschluss verfolgt werden. Das Risikomanagement (siehe MAN.5) im Projekt muss daher erweitert werden und auch die Risiken abdecken, die sich aus der Zusammenarbeit mit den Lieferanten ergeben.

Eine besondere Bedeutung gewinnt diese Praktik, wenn mehrere Lieferanten im Projekt des Kunden integriert und koordiniert werden müssen. Dann muss der Gesamtprojektstatus sowohl der Lieferantenaktivitäten als auch der Aktivitäten des Kunden zusammengefasst und im Ganzen überwacht werden. Hier empfiehlt sich eine offene Kommunikation des Gesamtstatus (an alle Beteiligten), damit jeder seinen Beitrag zum Gesamtwerk versteht. Ein weiterer Vorteil dieser Transparenz ist es, dass der dadurch indirekt geschaffene Wettbewerb den Projektfortschritt fördert (keiner will der Letzte sein). Zur objektiven Verfolgung des Projektfortschritts beim Lieferanten empfiehlt sich die Verfolgung des Fortschritts mittels Metriken (siehe MAN.6 und Abb. 2–41 auf S. 222).

Die Fortschrittsüberwachung sollte auch die Überwachung von vereinbarten Verbesserungsmaßnahmen (BP 5) im laufenden Projekt beinhalten.

Erfahrungsbericht

Der Projektfortschritt wird häufig sehr optimistisch dargestellt. Daher sind die Einschätzungen von Lieferanten (z.B. in Statusberichten oder im Projektplan) kritisch zu hinterfragen. Außerdem sollten frühzeitig erste Zwischenlieferungen vereinbart werden, um den tatsächlichen Fortschritt besser überprüfen zu können.

Problemursachen sind häufig auch unzureichende Mitwirkungen des Kunden. Der Lieferant wartet oft lange auf Antworten (z.B. von technischen Fragen), es dauert sehr lange, bis Entscheidungen getroffen werden, und dringend benötigte fachliche Ansprechpartner stehen nicht oder nicht in ausreichendem Umfang zur Verfügung. Ein weiteres Problem bei vernetzten Entwicklungen zeigt sich darin, dass Beistellungen des Auftraggebers oft nicht rechtzeitig oder in ausreichendem Umfang zur Verfügung stehen (z.B. Prototypen zu Testzwecken).

BP 5: Reagiere auf Abweichungen. Ergreife Maßnahmen, wenn vereinbarte Ziele nicht erreicht werden, um die Abweichungen von den vereinbarten Projektplänen zu korrigieren und um das erneute Auftreten der erkannten Probleme zu verhindern. Änderungen von Zielen werden verhandelt und diese werden in einer Vereinbarung dokumentiert.

Wenn bei der Durchführung des Projekts und bei der Überwachung des Projektfortschritts Abweichungen gegenüber dem Planungsstand festgestellt werden und dadurch vereinbarte Ziele nicht erreicht werden können, müssen entsprechende Maßnahmen eingeleitet werden. Automotive SPICE fordert neben der Durchführung der Maßnahmen zur Korrektur der Planabweichungen auch Maßnahmen zur Behebung bzw. Vermeidung der Ursachen.

Über den gesamten Projektverlauf muss zwischen Auftraggeber und Lieferant ein definierter und systematischer Änderungsmanagementprozess (siehe SUP.10) eingesetzt werden. Neben der Abstimmung selbst ist die Dokumentation der Änderungen gefordert. Zu beachten ist hierbei, dass sich die Änderungen nicht nur auf technische Fragen beziehen können, sondern auch auf definierte Prozesse, Vorgehensweisen, Vereinbarungen, Verträge etc.

Erfahrungsbericht

Im Kunden-Lieferanten-Verhältnis gibt es bei Festpreisprojekten bei der Umsetzung von Änderungen oft Probleme, wenn die Änderungen Kostenerhöhungen verursachen. Viele Kunden scheuen daher vor formalen Änderungsanträgen zurück und versuchen, Änderungen informell bzw. als Fehlermeldung getarnt an den Lieferanten zu übermitteln. Verschärft wird die Problematik bei der Entwicklung von Systemen, wenn neue Technologien angewendet werden und das Projektergebnis in einem evolutionären Prozess entsteht. Anforderungen können hier zu Projektbeginn nur unzureichend (unvollständig, nicht detailliert genug usw.) definiert werden und werden erst später im Laufe der Entwicklung portionsweise an den Lieferanten übergeben. In diesen Fällen muss auch der Änderungsmanagementprozess entsprechend angepasst werden. Zum Beispiel kann vereinbart werden, dass Änderungen zwar formal über den Änderungsmanagementprozess erfasst werden, aber erst unter bestimmten Bedingungen10 kostenwirksam werden. In solchen Fällen, d.h. mit neuen Technologien und unklaren Anforderungen, können agile Entwicklungsansätze sehr hilfreich sein (siehe dazu auch Kap. 6).

2.1.3 Ausgewählte Arbeitsprodukte

02-01 Vereinbarung

Gemeint ist hier eine verbindlich getroffene Vereinbarung zwischen Kunde(n) und Lieferant(en). Die Vereinbarung muss nachweislich und verbindlich dokumentiert werden (z.B. in einem Vertrag oder in der Kombination aus Anfragelastenheft, Angebot, Bestellung). Nach Vertragsabschluss werden eventuell weitere, detaillierte Vereinbarungen zwischen Kunde(n) und Lieferant(en) getroffen.

13-01 Abnahmeprotokoll

Das Abnahmeprotokoll besteht nach [Hindel et al. 2009] aus dem eigentlichen Protokoll und einer Mängelliste. Grundlegendes zur Mängelliste ist bei SUP.9, Arbeitsprodukt 13-07 (Problemmeldung), beschrieben. Zusätzlich sollte das Abnahmeprotokoll Folgendes enthalten:

Projektdaten (Projektbezeichnung, Auftragsnummer, Auftragsdatum, Auftraggeber etc.)

Benennung aller abzunehmenden Produkte gemäß Releaseplanung, neben dem eigentlichen (Teil-)System auch Dokumentation und Begleitmaterial, das übergeben wurde (Empfänger, Datum der Übergabe, Benennung inklusive Versionsbezeichnung etc.)

Datum, Ort, Teilnehmer der Abnahme (inklusive der Zuordnung zur Firma, d.h. Lieferant oder Kunde)

Art der Abnahme (handelt es sich z.B. um eine Teilabnahme oder um die Gesamtabnahme)

Verweis auf weitere Eingangs- und/oder Ergebnisdokumente der durchgeführten Abnahme

Test- bzw. Verifikationsergebnisse

Abnahmeergebnis (und ggf. weiteres Vorgehen, wie z.B. Mängelbeseitigung, erneute Abnahme)

Unterschrift von Kunde und Lieferant

13-09 Besprechungsprotokoll

Die Besprechungen zwischen Auftraggeber und Lieferant sollten mittels Protokollen dokumentiert werden. Das Protokoll sollte beinhalten:

Zweck der Besprechung, Tagesordnung, Ort, Datum und Zeiten, Teilnehmer

Getroffene Beschlüsse und sonstige wesentliche Ergebnisse

Offene Punkte (ggf. auch als separate Liste, siehe Abb. 2–4)

Gegebenenfalls Hinweis auf nächste Besprechung

Verteiler des Protokolls

13-14 Fortschrittsstatusbericht

Siehe bei MAN.3, Arbeitsprodukt 15-06 Projektfortschrittsbericht

13-16 Änderungsantrag

Siehe Erläuterung bei SUP.10

13-19 Reviewaufzeichnungen

Siehe Erläuterung bei SUP.4

2.1.4 Besonderheiten Level 2

Zum Management der Prozessausführung

Zu Projektbeginn ist die Abstimmung der Kommunikation zwischen Auftraggeber und Lieferant gemäß BP 1 zu planen (Abstimmung von Prozessschnittstellen, Abstimmung von Rollen und Verantwortlichkeiten, Definition von Eskalationspfaden etc.). Im Projektverlauf werden die Regeltermine und Fortschrittsreviews sowie Zwischen- und Endabnahmen eingeplant und deren Einhaltung bzw. Durchführung verfolgt. Zur Steuerung des Lieferanten sollte in der Regel eine verantwortliche Person benannt sein. Manchmal ist dies der (Teil-)Projektleiter oder es gibt hierfür eine Rolle »Supplier Manager«.

Zum Management der Arbeitsprodukte

Die im Rahmen der Abstimmung der Kommunikation gemäß BP 1 vereinbarten Arbeitsprodukte des Lieferanten sind zu reviewen und unter Versions- und Änderungsmanagement zu stellen. Neben den vereinbarten Zwischen- und Endlieferungen gilt dies auch für vereinbarte Planungsdokumente des Lieferanten und Fortschrittsberichte. Des Weiteren sind auch Änderungsanträge, die die Arbeit des Lieferanten betreffen, zu reviewen. Es sollte auch vereinbart werden, dass ein gemeinsames Konfigurationsmanagement eingerichtet wird (siehe BP 1, Anmerkung 1) und dass die Arbeitsprodukte entsprechend versioniert und geändert werden.

2.2 SPL.2 Releasemanagement

2.2.1 Zweck

Zweck des Prozesses ist es, Produktreleases für den Kunden zu steuern.

Ein Produktrelease ist eine konsistente Menge von versionierten Objekten mit definierten Eigenschaften und Merkmalen, die zur Auslieferung an interne oder externe Kunden bestimmt ist. Ein Produktrelease ist somit eine Baseline im Sinne des Konfigurationsmanagements (siehe SUP.8 BP 6). Der Prozess beinhaltet:

Die Planung und Steuerung von Releases

Die Vorbereitung und Durchführung von Zwischen- und Endfreigaben für Releases inklusive Freigabekriterien

Die Definition von »Build-Aktivitäten und -Umgebung«

Festlegung von Klassifizierungs- und Nummerierungsschema

Die Definition der Art und Weise der Auslieferung

Dokumentation und Support von Releases

Der Prozess hat Schnittstellen zum Anforderungsmanagement, zum Projektmanagement und zum Konfigurationsmanagement. Im Anforderungsmanagement werden die zu realisierenden Anforderungen priorisiert (siehe z.B. SYS.2 BP 2). Im Rahmen des Projektmanagements werden diese Anforderungen z.B. mittels einer Funktionsliste (siehe Abb. 2–31 auf S. 188) den verschiedenen Releases und Meilensteinen zugeordnet, und deren Umsetzung wird verfolgt.

Exkurs: Musterphasen in der Automobilindustrie

Die Automobilindustrie arbeitet mit sogenannten Musterständen (A, B, C, D). Dabei werden Entwicklungsstände der zu entwickelnden Bauteile mit zunehmendem Reifegrad im Entwicklungsprozess bereitgestellt und in Erprobungsfahrzeugen integriert. Ziel sind die frühzeitige Integration und der Test des Zusammenspiels im Fahrzeug. Die Musterphasen bedeuten:

A-Muster

Dies sind bedingt fahrtaugliche Funktionsmuster mit geringem Reifegrad. Das Bauteil erfüllt noch nicht die Anforderungen z.B. bezüglich Temperaturund Spannungsbereich, Abmessungen, Rüttel-/Stoßfestigkeit, elektromagnetischer Störsicherheit bzw. Verträglichkeit (EMV) und Optik. A-Muster gestatten aber bereits die Erprobung von (Software-)Grundfunktionen unter Versuchsbedingungen. A-Muster dienen der Funktionsdarstellung.

B-Muster

Dies sind funktionsfähige, fahrtaugliche Grundsatzmuster mit hohem Reifegrad. B-Muster sehen aus wie das spätere Serienteil und haben alle zu dem Zeitpunkt geforderten (Software-)Funktionen. B-Muster bestehen aus weitgehend seriennaher Hardware und erlauben erste Aussagen bezüglich elektromagnetischer Verträglichkeit und Temperaturbereich. B-Muster können aber noch aus Hilfswerkzeugen erstellt worden sein. B-Muster gewährleisten eine ausreichende Betriebssicherheit für die Erprobung auf dem Prüfstand und im Fahrzeug. Die Infrastruktur für die Diagnose ist enthalten. Für den Einsatz im Fahrzeug kann es noch Einschränkungen geben. B-Muster dienen der konstruktiven Festlegung z.B. hinsichtlich Einbau und Platzbedarf sowie der Funktionserprobung, Funktionsabsicherung und Applikation im Fahrzeug, Prüfstand und im Labor.

C-Muster

Diese werden mit Serienwerkzeugen unter seriennahen Bedingungen gefertigt und dienen u.a. der Erprobung im Fahrzeugdauerlauf. Die Bauform und Spezifikationen entsprechen den Serienanforderungen. Sämtliche Spezifikationen für Funktion, Zuverlässigkeit und Störsicherheit müssen eingehalten werden. Ferner entsprechen die Einbauverhältnisse, der Platzbedarf und die Kontaktierung dem Serienstand. Es muss weiterhin eine Reproduzierbarkeit in der Serienfertigung gewährleistet sein. Bei den C-Mustern sind keine technischen Einschränkungen zugelassen, und es ist somit ein uneingeschränkter Einsatz im Fahrzeug gewährleistet. Die Elektronikbauteile müssen qualifizierte Serienteile sein. In der Theorie sollen die Softwarefunktionen bereits beim B-Muster fertiggestellt sein. In der Praxis werden letzte Softwarefunktionen bei einigen Steuergeräten aber erst mit dem C-Muster fertiggestellt. C-Muster dienen der Gesamterprobung (Dauererprobung, Funktionsabsicherung, Applikation) unter serienähnlichen Bedingungen.

Baumuster/D-Muster

Diese werden vom Lieferanten für die Baumusterfreigabe bereitgestellt. Baumuster, manchmal auch D-Muster genannt, werden mit Serienwerkzeugen unter Serienbedingungen gefertigt. Die Geräte sind voll einsatzfähig und beurteilbar. Alle Qualitätsanforderungen sollten gleichbleibend sichergestellt sein. Freigegebene Baumuster können auch für die Erstmusterfreigabe genutzt werden und in der Produktvorserie/Serie verbaut werden.

2.2.2 Basispraktiken

BP 1: Definiere den funktionalen Inhalt der Releases. Erstelle eine Releaseplanung, die die zu implementierende Funktionalität eines jeden Release bestimmt.

Anmerkung 1: Der Plan sollte aufzeigen, welche Applikationsparameter, die die identifizierte Funktionalität beeinflussen, für welches Release wirksam sind.

Eine Releaseplanung definiert, in welcher Version eines Produktes bestimmte Eigenschaften realisiert werden. Auf dieser Basis kann man den Entwicklungsablauf strukturieren und die Arbeiten priorisieren. Häufig werden Funktionslisten (siehe Abb. 2–31 auf S. 188) zur Planung der funktionalen Inhalte genutzt. Neben den »offiziell« vereinbarten A/B/C-Mustern sind häufig auch Zwischenreleases notwendig (z.B. HW-Stand auf B-Muster, aber aktuelle Softwarefunktionalität). Auch diese müssen geplant werden. Die Releaseplanung ändert sich häufig im Projektverlauf. Gründe hierfür sind z.B.:

Das Projekt hat Verzug. Die Releasetermine müssen eingehalten werden. Also wird die Funktionalität des Release reduziert und ein weiteres Release mit voller Funktionalität wird nachgeliefert.

Anforderungen ändern sich im Projektverlauf, werden anders priorisiert, oder neue Anforderungen müssen berücksichtigt werden. Dadurch werden die Anforderungen vorgezogen11 oder auf ein späteres Release verschoben.

Werden daher neben den ursprünglich geplanten Releases weitere Releases notwendig, so sollten diese beantragt und genehmigt werden. Ein Releaseantrag für weitere Releases sollte zumindest folgende Punkte beinhalten:

Die betroffenen Objekte

Die Gründe für das Release

Wie die Lieferung erfolgt

Die Releaseplanung muss verfolgt und aktualisiert werden. Die Anmerkung weist darauf hin, dass die Releaseplanung auch die für die jeweilige Funktionalität wirksamen Applikationsparameter (siehe auch Abschnitt 2.26) für jedes Release beinhalten soll.

BP 2: Definiere Releaseprodukte. Definiere die mit dem Release verbundenen Produkte.

Anmerkung 2: Releaseprodukte können Programmierungstools beinhalten, wenn dies vereinbart wurde. Im Automobilsprachgebrauch kann ein Release einem Muster, z.B. A, B, C, zugeordnet sein.

Neben den funktionalen Inhalten muss definiert werden, welche Objekte und Dokumente ein Release umfasst. Dies können z.B. auch entwicklungsbegleitende Dokumentation, Test- und QS-Berichte oder eine Liste bekannter Fehler sein. Außerdem ist zu definieren, ob es sich um ein reines Softwarerelease handelt oder ob ein System (also Software auf definiertem HW-Stand) geliefert wird. Wird z.B. zu einem vereinbarten A/B/C-Musterstand nur eine Kiste mit Steuergeräten geliefert oder umfasst dies auch Dokumentation und notwendige Tools wie Bedatungs- oder Flashtools12?

BP 3: Lege eine Klassifizierung der Produktreleases und ein Nummerierungsschema fest. Eine Klassifizierung der Produktreleases und ein Nummerierungsschema werden gemäß dem vorgesehenen Zweck der Releases und der Erwartungen an die Releases eingeführt.

Anmerkung 3: Die Releasenummerierung kann Folgendes beinhalten:

Die Hauptversionsnummer

Die Versionsnummer eines Funktionsmerkmals13

Die Fehlerbehebungsnummer

Die Alpha- oder Beta-Version

Die Iteration innerhalb der Alpha- oder Betaversion

Ein Klassifikationsschema wird eingeführt. Mögliche Klassifikationen sind z.B.:

Internes Release

Kundenrelease zu Testzwecken

Offizielles Musterrelease

Serienrelease