Automotive SPICE® in der Praxis (eBook)

Interpretationshilfe für Anwender und Assessoren

Markus Müller, Klaus Hörmann, Lars Dittmann, Jörg Zimmer (Autoren)

eBook Download: PDF

2016 | 2. Auflage
418 Seiten
dpunkt (Verlag)
978-3-86491-998-5 (ISBN)

Infos

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.

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 intacsTM 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 intacsTM-zertifizierter Principal Assessor, intacsTM-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 intacsTM 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 intacsTM ISO/IEC 15504 Principal Assessor.

Inhalt

Geleitwort 5
Vorwort 7
Vorwort zur 1. Auflage 9
Zum Aufbau des Buches: 9
Inhaltsübersicht 11
Inhaltsverzeichnis 13
1 Einführung und Überblick 21
1.1 Einführung in die Thematik 21
1.2 Überblick über die in der Automobilentwicklung relevanten Modelle 22
1.3 intacsTM (International Assessor Certification Scheme) 23
Abb. 1–1 Die intacs-Assessoren- und -Instruktorenstufen 24
Abb. 1–2 Organisatorische Trennung der Definition des Ausbildungssystems von der Zertifizierung (inkl. Prüfung) der Assessoren und der Durchführung der Trainings 25
1.4 Automotive SPICE: Struktur und Bestandteile 26
Abb. 1–3 Die zwei Dimensionen von Automotive SPICE (in Anlehnung an Figure 1 und Figure 3 in [Automotive SPICE]) 27
1.4.1 Die Prozessdimension 28
Abb. 1–4 Aufbau eines Prozesses in Automotive SPICE 28
1.4.2 Die Reifegraddimension 29
Abb. 1–5 Die sechs Levels 29
Abb. 1–6 Die Prozessattribute 30
1.5 Umsetzungsaspekte: Tipps für eine nachhaltige Prozessverbesserung 31
Ausreichend Zeit einplanen – Erfolgsfaktor Zeit 31
Interne Schlüsselkollegen ausreichend einbinden – Erfolgsfaktor Erfahrung 32
Beschluss zur Prozessverbesserung – Erfolgsfaktor Management 32
Umfang und Reihenfolge der Prozessverbesserung – Erfolgsfaktor Umfang 33
Abb. 1–7 Zusammenhang von Zeit und Qualität/Performance bei Prozessverbesserungen 33
Transferarbeit zu den Mitarbeitern – Erfolgsfaktor Tooling & Kommunikation
Feedbackmechanismus – Erfolgsfaktor Feedback 34
Nachweis des Erfolgs – Erfolgsfaktor Messgrößen 35
Aufsetzen der Prozessverbesserung – Erfolgsfaktor Change Management 35
2 Interpretationen zur Prozessdimension 37
Abb. 2–1 Automotive SPICE-Prozesse und -Prozessgruppen 38
Das V-Modell als zentrales Leitbild der technischen Prozesse 39
Abb. 2–2 Das V-Modell als zentrales Leitbild (in Anlehnung an Figure D.2 in [Automotive SPICE]) 40
Im V-Modell verwendete Begriffe »Element«, »Komponente«, »Modul« und »Bestandteil« 40
Abb. 2–3 Verwendete Begriffe im V-Modell (in Anlehnung an Figure D.3 in [Automotive SPICE]) 41
2.1 ACQ.4 Lieferantenmanagement 41
2.1.1 Zweck 41
2.1.2 Basispraktiken 43
Abb. 2–4 Beispielstruktur einer Offene-Punkte-Liste (OPL) 45
Erfahrungsbericht 46
Erfahrungsbericht 47
2.1.3 Ausgewählte Arbeitsprodukte 48
02-01 Vereinbarung 48
13-01 Abnahmeprotokoll 48
13-09 Besprechungsprotokoll 48
13-14 Fortschrittsstatusbericht 48
13-16 Änderungsantrag 49
13-19 Reviewaufzeichnungen 49
2.1.4 Besonderheiten Level 2 49
Zum Management der Prozessausführung 49
Zum Management der Arbeitsprodukte 49
2.2 SPL.2 Releasemanagement 49
2.2.1 Zweck 49
Exkurs: Musterphasen in der Automobilindustrie 50
2.2.2 Basispraktiken 51
2.2.3 Ausgewählte Arbeitsprodukte 56
08-16 Releaseplan 56
WP 11-03 Produktrelease-Information 56
2.2.4 Besonderheiten Level 2 57
Zum Management der Prozessausführung 57
Zum Management der Arbeitsprodukte 57
2.3 SYS.1 Anforderungserhebung 57
2.3.1 Zweck 57
2.3.2 Basispraktiken 59
2.3.3 Ausgewählte Arbeitsprodukte 64
13-21 Änderungsaufzeichnung 64
17-03 Stakeholder-Anforderungen 64
Abb. 2–5 Beispiel der Struktur eines Anforderungsdokuments in Anlehnung an [ISO/IEC/IEEE 29148] 65
2.3.4 Besonderheiten Level 2 65
Zum Management der Prozessausführung 65
Zum Management der Arbeitsprodukte 66
2.4 SYS.2 Systemanforderungsanalyse 66
2.4.1 Zweck 66
Exkurs: »System« 67
Abb. 2–6 Was ist das System? 68
Abb. 2–7 Verfeinerung von Anforderungen über die verschiedenen Ebenen 68
2.4.2 Basispraktiken 69
Abb. 2–8 Schematische Struktur der Anforderungsspezifikation 69
2.4.3 Ausgewählte Arbeitsprodukte 75
13-22 Traceability-Aufzeichnung 75
17-08 Schnittstellenanforderungen 76
17-12 Systemanforderungsspezifikation 76
2.4.4 Besonderheiten Level 2 77
Zum Management der Prozessausführung 77
Zum Management der Arbeitsprodukte 77
2.5 SYS.3 Systemarchitekturdesign 77
2.5.1 Zweck 77
Abb. 2–9 Beispiel einer statischen Systemarchitektur für ein Radio-Navigationssystem (oberste Ebene) 78
Abb. 2–10 Beispiel einer tieferen Beschreibungsebene einer statischen Systemarchitektur 78
2.5.2 Basispraktiken 79
Abb. 2–11 Beispiel Entscheidungsmatrix 82
2.5.3 Ausgewählte Arbeitsprodukte 84
04-06 Systemarchitektur 84
13-22 Traceability-Aufzeichnung 84
17-08 Schnittstellenanforderungen 84
2.5.4 Besonderheiten Level 2 85
Zum Management der Prozessausführung 85
Zum Management der Arbeitsprodukte 85
2.6 SYS.4 Systemintegration und Systemintegrationstest 85
2.6.1 Zweck 85
2.6.2 Basispraktiken 86
Abb. 2–12 Schema einer mehrstufigen Systemintegration 87
2.6.3 Ausgewählte Arbeitsprodukte 92
08-50 Testspezifikation 92
08-52 Testplan 92
11-06 System 92
13-22 Traceability-Aufzeichnung 92
13-50 Testergebnis 92
2.6.4 Besonderheiten Level 2 92
Zum Management der Prozessausführung 92
Zum Management der Arbeitsprodukte 92
2.7 SYS.5 Systemtest 93
2.7.1 Zweck 93
2.7.2 Basispraktiken 93
2.7.3 Ausgewählte Arbeitsprodukte 95
08-50 Testspezifikation 95
08-52 Testplan 95
13-50 Testergebnis 96
2.7.4 Besonderheiten Level 2 96
2.8 SWE.1 Softwareanforderungsanalyse 96
2.8.1 Zweck 96
2.8.2 Basispraktiken 97
Exkurs: Beispielmethode Hazard and Operability Study (HAZOP) 100
Abb. 2–13 Beispiel einer HAZOP-Tabelle 100
2.8.3 Ausgewählte Arbeitsprodukte 102
13-22 Traceability-Aufzeichnung 102
17-08 Schnittstellenanforderungen 102
17-11 Softwareanforderungsspezifikation 102
2.8.4 Besonderheiten Level 2 102
2.9 SWE.2 Softwarearchitekturdesign 103
2.9.1 Zweck 103
2.9.2 Basispraktiken 104
Abb. 2–14 Beispiel einer Softwarearchitektur auf oberster Beschreibungsebene (Quelle: intacs) 105
2.9.3 Ausgewählte Arbeitsprodukte 110
04-04 Softwarearchitektur 110
13-22 Traceability-Aufzeichnung 110
17-08 Schnittstellenanforderungen 110
2.9.4 Besonderheiten Level 2 110
Zum Management der Prozessausführung 110
Zum Management der Arbeitsprodukte 110
2.10 SWE.3 Softwarefeinentwurf und Softwaremodulerstellung 111
2.10.1 Zweck 111
2.10.2 Basispraktiken 113
2.10.3 Ausgewählte Arbeitsprodukte 118
04-05 Softwarefeinentwurf 118
11-05 Softwaremodul 119
13-22 Traceability-Aufzeichnung 119
2.10.4 Besonderheiten Level 2 119
Zum Management der Prozessausführung 119
Zum Management der Arbeitsprodukte 119
2.11 SWE.4 Softwaremodulverifikation 120
2.11.1 Zweck 120
Exkurs: Einheitliche Verifikations- und Teststrategie – Korrespondenz der realen Prozesse zu Automotive SPICE-Prozessen 120
2.11.2 Basispraktiken 122
2.11.3 Ausgewählte Arbeitsprodukte 127
08-50 Testspezifikation 127
08-52 Testplan 128
13-50 Testergebnis 128
13-22 Traceability-Aufzeichnung 128
13-25 Verifikationsergebnisse 128
2.11.4 Besonderheiten Level 2 128
Zum Management der Prozessausführung 128
Zum Management der Arbeitsprodukte 129
Exkurs: Testdokumentation nach ISO/IEC/IEEE 29119-3 129
2.12 SWE.5 Softwareintegration und Softwareintegrationstest 131
2.12.1 Zweck 131
2.12.2 Basispraktiken 132
Abb. 2–15 Integrationsreihenfolge bei einer Bottom-up-Strategie 133
Fallbeispiel: Softwareintegration eines Projekts bei der XY AG 139
2.12.3 Ausgewählte Arbeitsprodukte 140
01-03 Softwarebestandteil 140
01-50 Integrierte Software 140
08-50 Testspezifikation 140
08-52 Testplan 140
13-22 Traceability-Aufzeichnung 140
13-50 Testergebnis 140
17-02 Build-Liste 140
2.12.4 Besonderheiten Level 2 140
Zum Management der Prozessausführung 140
Zum Management der Arbeitsprodukte 141
2.13 SWE.6 Softwaretest 141
2.13.1 Zweck 141
2.13.2 Basispraktiken 142
Exkurs: Kurzer Überblick über Testmethoden 144
Abb. 2–16 Testmethoden und Integrationsstufen 145
Exkurs: Einige Methoden zur Ableitung von Testfällen 145
2.13.3 Ausgewählte Arbeitsprodukte 146
08-50 Testspezifikation 146
08-52 Testplan 146
13-50 Testergebnis 146
2.13.4 Besonderheiten Level 2 146
Zum Management der Prozessausführung 146
Zum Management der Arbeitsprodukte 147
2.14 SUP.1 Qualitätssicherung 147
2.14.1 Zweck 147
Generische Praktiken GP 2.2.1 und 2.2.4 147
SUP.1 Qualitätssicherung 147
SUP.2 Verifikation 147
Verifikationsaktivitäten in den Engineering-Prozessen 148
SUP.4 Gemeinsame Reviews 148
2.14.2 Basispraktiken 149
Abb. 2–17 Beispiel eines QS-Berichts an das Management: Abarbeitungsstatus von QS-Befunden und Prozesskonformitätsrate (PKR) 154
2.14.3 Ausgewählte Arbeitsprodukte 156
08-13 Qualitätssicherungsplan 156
13-07 Problemaufzeichnung 156
13-18 Qualitätsaufzeichnung 157
Abb. 2–18 Beispiel einer Qualitätsaufzeichnung (Titelseite) 157
Abb. 2–19 Schema einer Qualitätsaufzeichnung (Maßnahmenseite) 157
14-02 Liste der Korrekturaktionen 157
2.14.4 Besonderheiten Level 2 158
Zum Management der Prozessausführung 158
»Qualitätssicherung der Qualitätssicherung« 158
2.15 SUP.2 Verifikation 159
2.15.1 Zweck 159
Abb. 2–20 Überblick Qualitätssicherungmethoden 159
2.15.2 Basispraktiken 160
2.15.3 Ausgewählte Arbeitsprodukte 165
13-07 Problemaufzeichnung 165
13-25 Verifikationsergebnis 165
14-02 Liste der Korrekturaktionen 165
19-10 Verifikationsstrategie 165
2.15.4 Besonderheiten Level 2 165
Zum Management der Prozessausführung 165
Zum Management der Arbeitsprodukte 166
2.16 SUP.4 Gemeinsame Reviews 166
2.16.1 Zweck 166
2.16.2 Basispraktiken 168
Abb. 2–21 Beispiel eines Reviewprozesses 170
2.16.3 Ausgewählte Arbeitsprodukte 172
13-19 Reviewaufzeichnungen 172
Abb. 2–22 Beispielstruktur eines Review Log 173
2.16.4 Besonderheiten Level 2 173
Zum Management der Prozessausführung 173
Zum Management der Arbeitsprodukte 173
2.17 SUP.8 Konfigurationsmanagement 174
2.17.1 Zweck 174
2.17.2 Basispraktiken 175
Abb. 2–23 Auszug aus einer realen Liste von KM-Elementen 177
Abb. 2–24 Verschiedene Ebenen von Baselines 181
2.17.3 Ausgewählte Arbeitsprodukte 183
01-00 Konfigurationselement 183
08-04 Konfigurationsmanagementplan 184
13–08 Baseline 184
Abb. 2–25 Beispielgliederung eines KM-Plans 185
16-03 Konfigurationsmanagementbibliothek (auch: Konfigurationsmanagement- Repository) 185
2.17.4 Besonderheiten Level 2 186
Zum Management der Prozessausführung 186
Zum Management der Arbeitsprodukte 186
2.18 SUP.9 Problemmanagement 186
2.18.1 Zweck 186
Abb. 2–26 Beispiel für Problemstatus 188
2.18.2 Basispraktiken 188
Abb. 2–27 Beispiel einer Problem- oder Änderungsmeldung 191
Abb. 2–28 Beispiel eines Problemklassifizierungsschemas 192
Abb. 2–29 Beispiel für Problem- und Abarbeitungsverfolgung über die Zeit 195
2.18.3 Ausgewählte Arbeitsprodukte 196
08-27 Problemmanagementplan 196
13-07 Problemaufzeichnung 196
15-01 Analysebericht bzw. 15-05 Bewertungsbericht 197
15-12 Problemstatusbericht 197
2.18.4 Besonderheiten Level 2 197
Zum Management der Prozessausführung 197
Zum Management der Arbeitsprodukte 198
2.19 SUP.10 Änderungsmanagement 199
2.19.1 Zweck 199
2.19.2 Basispraktiken 200
Abb. 2–30 Beispiel für den Status von Änderungsanträgen 201
2.19.3 Ausgewählte Arbeitsprodukte 204
08-28 Änderungsmanagementplan 204
13-16 Änderungsantrag 204
13-21 Änderungsaufzeichnung 204
2.19.4 Besonderheiten Level 2 205
2.20 MAN.3 Projektmanagement 205
2.20.1 Zweck 205
2.20.2 Basispraktiken 206
Abb. 2–31 Beispiel: Auszug aus der Funktionsliste eines Spurhalteassistenzsystems 208
Exkurs: Verteilte Funktionsentwicklung und Integrationsstufen 209
Abb. 2–32 Beispiel für einen Projektlebenszyklus eines Steuergeräteentwicklungsprojekts 210
BP 5: Ermittle, überwache und passe die Projektschätzungen und Ressourcen an. Definiere und pflege die Aufwands- und Ressourcenschätzungen basierend auf den Projektzielen, Projektrisiken, Motivation und Grenzen und passe diese an. 213
Abb. 2–33 Beispiel für technische Ressourcenplanung 214
Abb. 2–34 Prinzip der rollierenden Planung 217
Abb. 2–35 Arten von Projektbesprechungen und Fortschrittreviews 220
2.20.3 Ausgewählte Arbeitsprodukte 221
08-12 Projektplan 221
Beispielgliederung eines Projektplans für ein großes Projekt 222
13-16 Änderungsantrag 223
14-06 Terminplan 223
14-09 Projektstrukturplan 223
15-06 Projektfortschrittsbericht 224
Abb. 2–36 Beispiel eines aggregierten Projektfortschrittsberichts für höhere Managementebenen 224
2.20.4 Besonderheiten Level 2 225
Zum Management der Prozessausführung 225
Zum Management der Arbeitsprodukte 225
2.21 MAN.5 Risikomanagement 225
2.21.1 Zweck 225
2.21.2 Basispraktiken 227
Abb. 2–37 Überblick Risikomanagementaktivitäten 230
Abb. 2–38 Beispiel einer Risikoportfoliodarstellung 231
Abb. 2–39 Beispiel von Schadensklassen für terminliche Auswirkungen 231
2.21.3 Ausgewählte Arbeitsprodukte 234
Risikoliste 234
Beispielhafter Aufbau einer Risikoliste 234
2.21.4 Besonderheiten Level 2 235
Zum Management der Prozessausführung 235
Zum Management der Arbeitsprodukte 235
2.22 MAN.6 Messen 235
2.22.1 Zweck 235
»You can’t control, what you can’t measure!« (Tom DeMarco) 235
Exkurs: Goal/Question/Metric-(GQM-)Methode 236
Abb. 2–40 GQM-Methode 237
2.22.2 Basispraktiken 238
Abb. 2–41 Beispiel einer grafischen Auswertung zur Metrik »Funktionalitätszuwachs« 242
Abb. 2–42 Beispiel eines Projekt-Cockpit-Charts (Quelle: [Hörmann et al. 2006]) 243
2.22.3 Ausgewählte Arbeitsprodukte 245
03-03 Benchmarking-Daten 245
03-04 Kundenzufriedenheitsdaten 246
Beispiel einer Metrikspezifikation 246
Abb. 2–43 Spezifikation der Metrik »Funktionalitätszuwachs« 247
07-01 Kundenzufriedenheitsbefragung 248
07-02 Feldbeobachtung 248
07-08 Service-Level-Messung 248
2.22.4 Besonderheiten Level 2 248
Zum Management der Prozessausführung 248
Zum Management der Arbeitsprodukte 248
2.23 PIM.3 Prozessverbesserung 249
2.23.1 Zweck 249
2.23.2 Basispraktiken 250
Abb. 2–44 Anwendung der Scrum-Methode auf das Change Management in der Organisation (Quelle: Kugler Maag Cie) 255
Abb. 2–45 Prozessarchitektur und Tailoring in größeren, verteilten Organisationen 256
2.23.3 Ausgewählte Arbeitsprodukte 257
08-29 Verbesserungsplan 257
15-16 Verbesserungsmöglichkeit 257
2.23.4 Besonderheiten Level 2 257
Zum Management der Prozessausführung 257
Zum Management der Arbeitsprodukte 257
2.24 REU.2 Wiederverwendungsmanagement 258
2.24.1 Zweck 258
2.24.2 Basispraktiken 259
2.24.3 Ausgewählte Arbeitsprodukte 263
08-17 Wiederverwendungsplan 263
15-07 Bericht zur Bewertung der Wiederverwendung 264
2.24.4 Besonderheiten Level 2 264
Zum Management der Prozessausführung 264
Zum Management der Arbeitsprodukte 264
2.25 Traceability und Konsistenz in Automotive SPICE 265
2.25.1 Einleitung 265
2.25.2 Grundgedanken 265
Abb. 2–46 Horizontale und vertikale Traceability 266
2.26 Applikationsparameter in Automotive SPICE 271
Abb. 2–47 ISO-26262-Sicht auf Parameter (Quelle: ISO 26262-6, Annex C) 271
2.26.1 Ausgewählte Arbeitsprodukte 274
WP 01-51 Applikationsparameter 274
3 Interpretationen zur Reifegraddimension 275
3.1 Struktur der Reifegraddimension 275
3.1.1 Levels und Prozessattribute 275
3.1.2 Indikatoren für die Reifegraddimension 276
Abb. 3–1 Elemente der Reifegraddimension 277
3.2 Wie werden Levels gemessen? 277
Abb. 3–2 Ermittlung des Levels mithilfe des »process capability level model« 279
3.3 Erweiterungen der ISO/IEC 33020 279
Abb. 3–3 Veranschaulichung der Bewertungsmethode R1 281
Abb. 3–4 Veranschaulichung der Bewertungsmethoden R2 und R3 281
Abb. 3–5 Vertikale Aggregation 282
3.4 Die Levels 283
3.4.1 Level 0 (»Unvollständiger Prozess«) 283
3.4.2 Level 1 (»Durchgeführter Prozess«) 283
Prozessausführung (PA 1.1) 283
Abb. 3–6 Beurteilung von PA 1.1 284
Abb. 3–7 Bewertungsbeispiele für PA 1.1 285
3.4.3 Level 2 (»Gemanagter Prozess«) 286
Abb. 3–8 Prozessattribute und generische Praktiken von Level 2 287
PA 2.1 Management der Prozessausführung 287
GP 2.1.1: Ermittle die Ziele für die Prozessausführung. 288
Abb. 3–9 Kommunikationsplan 296
PA 2.2 Management der Arbeitsprodukte 297
GP 2.2.2: Definiere Anforderungen an die Dokumentation und Lenkung von Arbeitsprodukten. Anforderungen an die Dokumentation und Lenkung von Arbeitsprodukten werden definiert. Diese können beinhalten: 299
3.4.4 Level 3 (»Etablierter Prozess«) 302
Abb. 3–10 Prozessattribute und generische Praktiken von Level 3 303
PA 3.1 Prozessdefinition 304
Abb. 3–11 Prozessarchitektur nach dem EITVOX-Modell 305
Exkurs: Tailoring von Prozessen 306
Abb. 3–12 Tailoring-Tabelle 307
Abb. 3–13 Beispiel für Rollenbeschreibung Softwareprojektleiter 310
PA 3.2 Prozessanwendung 313
GP 3.2.1: Setze einen definierten Prozess um, der die kontextspezifischen Anforderungen bezüglich der Nutzung des Standardprozesses erfüllt. Der definierte Prozess wird adäquat ausgewählt und/oder aus dem Standardprozess zurechtgeschnitten. Die K... 314
3.4.5 Level 4 (»Vorhersagbarer Prozess«) 318
Abb. 3–14 Level 4 – vorhersagbares Prozessverhalten 319
Abb. 3–15 Prozessattribute und generische Praktiken von Level 4 320
3.4.6 Level 5 (»Innovativer Prozess«) 321
Abb. 3–16 Level 5 – quantitative Prozessoptimierung 321
Abb. 3–17 Prozessattribute und generische Praktiken von Level 5 323
3.5 Zusammenhang von Prozess- und Reifegraddimension 323
Abb. 3–18 Abhängigkeiten zwischen Prozessen und Prozessattributen 324
4 Automotive SPICE-Assessments 325
4.1 Assessments – Überblick und Grundlagen 325
4.2 Phasen, Aktivitäten und Dauer des Assessmentprozesses 326
Abb. 4–1 Überblick über Phasen und Aktivitäten des Assessmentprozesses 326
Assessmentvorbereitung 327
Assessmentdurchführung 327
Assessmentabschluss 328
Wie lange dauert ein Assessment? 329
4.3 Rollen im Assessmentprozess 329
4.4 Komplexe Assessments 330
Abb. 4–2 Von intacs definiertes OMM für Automotive SPICE 331
Abb. 4–3 Anforderungen an die Maturity Levels in Form von geforderten Capability Levels für bestimmte Prozessmengen 332
Wie werden die zu untersuchenden Projekte ausgewählt? 332
Abb. 4–4 Definition der Assessmentklassen 333
Werden OMAs anerkannt? 334
5 Funktionale Sicherheit und Automotive SPICE 335
5.1 Überblick funktionale Sicherheit und ISO 26262 335
IEC 61508 336
ISO 26262 336
Abb. 5–1 Sicherheitslebenszyklus der ISO 26262 336
Abb. 5–2 ISO 26262-Überblick [ISO 26262] 337
ASIL 338
ISO/IEC 15504-10 338
5.2 Vergleich von ISO 26262 und Automotive SPICE 339
Abb. 5–3 Überlappung von Automotive SPICE und ISO 26262 339
5.3 Unterschiede zwischen ISO 26262 und Automotive SPICE 340
5.3.1 Unterschiede im Scope der Standards 340
5.3.2 Unterschiede in den Levels 341
Abb. 5–4 Unterstützung der ISO-26262-Umsetzung durch Automotive SPICE 342
5.3.3 Unterschiede in den Aktivitäten und Rollen 342
5.3.4 Unterschiede in den Arbeitsprodukten 343
5.3.5 Unterschiede in den Methodenanforderungen 343
Abb. 5–5 Beispiel einer Methodentabelle der ISO 26262 (Auszug aus der [ISO 26262], Teil 4, Tabelle 3) 344
5.3.6 Unterschiede in den Unabhängigkeitsanforderungen 344
5.4 Kombination von Automotive SPICE-Assessments und funktionalen Safety-Audits 345
Abb. 5–6 Überlappung der Evaluierungsmethoden (Quelle [Dold et al. 2014]) 346
5.4.1 Kombination von Automotive SPICE-Assessment und Safety-Audit 346
Abb. 5–7 Überlappung von Automotive SPICE-Assessment und Safety-Audit im Detail (Quelle [Dold et al. 2014]) 347
Abb. 5–8 Kombinierte Methode Automotive SPICE-Assessment und Safety-Audit (Quelle [Dold et al. 2014]) 347
5.4.2 Weitere zu beachtende Aspekte 348
Teamzusammensetzung 348
Modellergänzungen 348
Abb. 5–9 Beispiel für FS-Ergänzungen 348
Abb. 5–10 Evaluierungen entlang des Sicherheitslebenszyklus 349
5.5 Zusammenfassung ISO 26262 und Automotive SPICE 350
6 Agilität und Automotive SPICE 351
6.1 Warum sich mit Agilität und Automotive SPICE beschäftigen? 352
Beispiele aus der Automobilindustrie 353
6.2 Was bedeutet »Agilität in Automotive« ? 354
Abb. 6–1 Übersicht und Klassifizierung von »agilen« Begriffen 355
6.2.1 Was macht eine agile Entwicklung aus? 355
Die 12 Prinzipien agiler Softwareentwicklung 356
6.2.2 »Agile in Automotive (AiA)«: Welche agilen Methoden und Praktiken werden in der Automobilentwicklung aktuell eingesetzt? 357
Domänen und eingesetzte Methoden 357
Disziplinen und Projektphasen 357
Häufige Integration 358
Sprint-Dauer, Sprint-Umfang 358
AiA-Team-Setup 358
Retrospektiven und Demos 359
User Stories 359
Agile Skalierung 359
6.2.3 Welche Herausforderungen werden demnächst angegangen ? 360
Exkurs: Continuous Integration 360
Abb. 6–2 Ablauf von Continuous Integration 361
6.3 Wie bringt man Agilität und Automotive SPICE zusammen? 362
6.3.1 Grundsätzliches 362
Mögliches Mapping 362
Abb. 6–3 Abdeckung des HIS Scope Level 1 durch typische agile Praktiken 363
6.3.2 Was sind die kritischen Punkte in der Praxis? 363
Generell: Die Implementierung der Automotive SPICE-Arbeitsprodukte 364
Abb. 6–4 Beispiel einer agilen Entwicklungsumgebung 365
Agile Vorausplanung und Automotive SPICE 365
Einbettung agiler Teams in das Gesamtprojekt 365
Abb. 6–5 Schnittstellen der Planungswerkzeuge zur Projektverfolgung 366
Qualitätssicherung 366
Anforderungsmanagement und Traceability 367
Softwarearchitektur 368
Continuous Integration und Test 369
Unterstützende Prozesse 369
Einbindung weiterer Disziplinen 369
Abb. 6–6 Synchronisation und Integrationsebenen unterschiedlicher Zyklenlängen 370
6.3.3 Konkrete praktische Lösungsbeispiele 370
Definition of Done (DoD) 371
Abb. 6–7 Auszüge aus einer DoD auf Teamebene 371
Agile Vorausplanung und Automotive SPICE 372
Abb. 6–8 Product Backlog mit verschiedenen Planungsebenen 372
Continuous Integration und Testebenen 373
Abb. 6–9 Continuous Integration und automatisierte Testebenen 374
6.4 Agilität, Automotive SPICE und funktionale Sicherheit 375
6.5 Zusammenfassung Agilität und Automotive SPICE 376
Anhang 377
A Beispiele zu Assessmentplanung und Assessmentdokumentation 379
A.1 Fall 1: Einfaches Projektassessment Tier-1-Lieferant 379
A.1.1 Beispiel eines Assessmentplans 379
Allgemeine Angaben zum Assessment 379
A.1.2 Beispiel einer Assessmentagenda bis Level 3 381
Abb. A–1 Beispielagenda 382
A.1.3 Beispielstruktur eines Assessmentberichts 383
A.1.4 Beispielbewertung eines Prozesses inklusive Dokumentation 383
Bewertung der Indikatoren und Beschreibung der Evidenzen 383
Abb. A–2 Beispielbewertung 384
A.1.5 Beispiel: Auszug aus der Liste der analysierten Evidenzen/Dokumente 385
A.2 Fall 2: Komplexes Projektassessment, mehrere Instanzen 385
A.2.1 Beispiel: Planung der Prozessinstanzen pro Prozess 386
Abb. A–3 Assessmentplanung und Abdeckung eines komplexen Assessments 387
A.2.2 Beispiel: Assessmentagenda 388
Abb. A–4 Auszug aus Agenda eines komplexen Assessments 388
A.2.3 Beispiel: Konsolidierungs- und Aggregationsregeln 389
B Übersicht ausgewählter Arbeitsprodukte 391
C Glossar 393
D Abkürzungsverzeichnis 405
E Literatur, Normen und Webadressen 409
Index 413
www.dpunkt.de 0

Textauszug

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...

Produkt-Details

• Erscheint lt. Verlag: 22.9.2016
• Verlagsort: Heidelberg
• Sprache: deutsch
• Themenwelt: Mathematik / Informatik ► Informatik
• Schlagworte: Agile Automotive • Automotive SPICE • Funktionale Sicherheit • intacs • ISO 15504 • ISO 26262 • ISO/IEC 15504 • Prozessverbesserung • Qualitätsmanagement • Software Assessment • Software-Qualitätsmanagement • SPICE • VDA
• ISBN-10: 3-86491-998-3 / 3864919983
• ISBN-13: 978-3-86491-998-5 / 9783864919985