Sie sind hier
E-Book

Automotive SPICE® in der Praxis

Interpretationshilfe für Anwender und Assessoren

AutorJörg Zimmer, Klaus Hörmann, Lars Dittmann, Markus Müller
Verlagdpunkt
Erscheinungsjahr2016
Seitenanzahl418 Seiten
ISBN9783864919985
FormatPDF/ePUB
KopierschutzWasserzeichen/DRM
GerätePC/MAC/eReader/Tablet
Preis46,90 EUR
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.

Kaufen Sie hier:

Horizontale Tabs

Leseprobe

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

Blick ins Buch
Inhaltsverzeichnis
Geleitwort5
Vorwort7
Vorwort zur 1. Auflage9
Zum Aufbau des Buches:9
Inhaltsübersicht11
Inhaltsverzeichnis13
1 Einführung und Überblick21
1.1 Einführung in die Thematik21
1.2 Überblick über die in der Automobilentwicklung relevanten Modelle22
1.3 intacsTM (International Assessor Certification Scheme)23
Abb. 1–1 Die intacs-Assessoren- und -Instruktorenstufen24
Abb. 1–2 Organisatorische Trennung der Definition des Ausbildungssystems von der Zertifizierung (inkl. Prüfung) der Assessoren und der Durchführung der Trainings25
1.4 Automotive SPICE: Struktur und Bestandteile26
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 Prozessdimension28
Abb. 1–4 Aufbau eines Prozesses in Automotive SPICE28
1.4.2 Die Reifegraddimension29
Abb. 1–5 Die sechs Levels29
Abb. 1–6 Die Prozessattribute30
1.5 Umsetzungsaspekte: Tipps für eine nachhaltige Prozessverbesserung31
Ausreichend Zeit einplanen – Erfolgsfaktor Zeit31
Interne Schlüsselkollegen ausreichend einbinden – Erfolgsfaktor Erfahrung32
Beschluss zur Prozessverbesserung – Erfolgsfaktor Management32
Umfang und Reihenfolge der Prozessverbesserung – Erfolgsfaktor Umfang33
Abb. 1–7 Zusammenhang von Zeit und Qualität/Performance bei Prozessverbesserungen33
Transferarbeit zu den Mitarbeitern – Erfolgsfaktor Tooling & Kommunikation34
Feedbackmechanismus – Erfolgsfaktor Feedback34
Nachweis des Erfolgs – Erfolgsfaktor Messgrößen35
Aufsetzen der Prozessverbesserung – Erfolgsfaktor Change Management35
2 Interpretationen zur Prozessdimension37
Abb. 2–1 Automotive SPICE-Prozesse und -Prozessgruppen38
Das V-Modell als zentrales Leitbild der technischen Prozesse39
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 Lieferantenmanagement41
2.1.1 Zweck41
2.1.2 Basispraktiken43
Abb. 2–4 Beispielstruktur einer Offene-Punkte-Liste (OPL)45
Erfahrungsbericht46
Erfahrungsbericht47
2.1.3 Ausgewählte Arbeitsprodukte48
02-01 Vereinbarung48
13-01 Abnahmeprotokoll48
13-09 Besprechungsprotokoll48
13-14 Fortschrittsstatusbericht48
13-16 Änderungsantrag49
13-19 Reviewaufzeichnungen49
2.1.4 Besonderheiten Level 249
Zum Management der Prozessausführung49
Zum Management der Arbeitsprodukte49
2.2 SPL.2 Releasemanagement49
2.2.1 Zweck49
Exkurs: Musterphasen in der Automobilindustrie50
2.2.2 Basispraktiken51
2.2.3 Ausgewählte Arbeitsprodukte56
08-16 Releaseplan56
WP 11-03 Produktrelease-Information56
2.2.4 Besonderheiten Level 257
Zum Management der Prozessausführung57
Zum Management der Arbeitsprodukte57
2.3 SYS.1 Anforderungserhebung57
2.3.1 Zweck57
2.3.2 Basispraktiken59
2.3.3 Ausgewählte Arbeitsprodukte64
13-21 Änderungsaufzeichnung64
17-03 Stakeholder-Anforderungen64
Abb. 2–5 Beispiel der Struktur eines Anforderungsdokuments in Anlehnung an [ISO/IEC/IEEE 29148]65
2.3.4 Besonderheiten Level 265
Zum Management der Prozessausführung65
Zum Management der Arbeitsprodukte66
2.4 SYS.2 Systemanforderungsanalyse66
2.4.1 Zweck66
Exkurs: »System«67
Abb. 2–6 Was ist das System?68
Abb. 2–7 Verfeinerung von Anforderungen über die verschiedenen Ebenen68
2.4.2 Basispraktiken69
Abb. 2–8 Schematische Struktur der Anforderungsspezifikation69
2.4.3 Ausgewählte Arbeitsprodukte75
13-22 Traceability-Aufzeichnung75
17-08 Schnittstellenanforderungen76
17-12 Systemanforderungsspezifikation76
2.4.4 Besonderheiten Level 277
Zum Management der Prozessausführung77
Zum Management der Arbeitsprodukte77
2.5 SYS.3 Systemarchitekturdesign77
2.5.1 Zweck77
Abb. 2–9 Beispiel einer statischen Systemarchitektur für ein Radio-Navigationssystem (oberste Ebene)78
Abb. 2–10 Beispiel einer tieferen Beschreibungsebene einer statischen Systemarchitektur78
2.5.2 Basispraktiken79
Abb. 2–11 Beispiel Entscheidungsmatrix82
2.5.3 Ausgewählte Arbeitsprodukte84
04-06 Systemarchitektur84
13-22 Traceability-Aufzeichnung84
17-08 Schnittstellenanforderungen84
2.5.4 Besonderheiten Level 285
Zum Management der Prozessausführung85
Zum Management der Arbeitsprodukte85
2.6 SYS.4 Systemintegration und Systemintegrationstest85
2.6.1 Zweck85
2.6.2 Basispraktiken86
Abb. 2–12 Schema einer mehrstufigen Systemintegration87
2.6.3 Ausgewählte Arbeitsprodukte92
08-50 Testspezifikation92
08-52 Testplan92
11-06 System92
13-22 Traceability-Aufzeichnung92
13-50 Testergebnis92
2.6.4 Besonderheiten Level 292
Zum Management der Prozessausführung92
Zum Management der Arbeitsprodukte92
2.7 SYS.5 Systemtest93
2.7.1 Zweck93
2.7.2 Basispraktiken93
2.7.3 Ausgewählte Arbeitsprodukte95
08-50 Testspezifikation95
08-52 Testplan95
13-50 Testergebnis96
2.7.4 Besonderheiten Level 296
2.8 SWE.1 Softwareanforderungsanalyse96
2.8.1 Zweck96
2.8.2 Basispraktiken97
Exkurs: Beispielmethode Hazard and Operability Study (HAZOP)100
Abb. 2–13 Beispiel einer HAZOP-Tabelle100
2.8.3 Ausgewählte Arbeitsprodukte102
13-22 Traceability-Aufzeichnung102
17-08 Schnittstellenanforderungen102
17-11 Softwareanforderungsspezifikation102
2.8.4 Besonderheiten Level 2102
2.9 SWE.2 Softwarearchitekturdesign103
2.9.1 Zweck103
2.9.2 Basispraktiken104
Abb. 2–14 Beispiel einer Softwarearchitektur auf oberster Beschreibungsebene (Quelle: intacs)105
2.9.3 Ausgewählte Arbeitsprodukte110
04-04 Softwarearchitektur110
13-22 Traceability-Aufzeichnung110
17-08 Schnittstellenanforderungen110
2.9.4 Besonderheiten Level 2110
Zum Management der Prozessausführung110
Zum Management der Arbeitsprodukte110
2.10 SWE.3 Softwarefeinentwurf und Softwaremodulerstellung111
2.10.1 Zweck111
2.10.2 Basispraktiken113
2.10.3 Ausgewählte Arbeitsprodukte118
04-05 Softwarefeinentwurf118
11-05 Softwaremodul119
13-22 Traceability-Aufzeichnung119
2.10.4 Besonderheiten Level 2119
Zum Management der Prozessausführung119
Zum Management der Arbeitsprodukte119
2.11 SWE.4 Softwaremodulverifikation120
2.11.1 Zweck120
Exkurs: Einheitliche Verifikations- und Teststrategie – Korrespondenz der realen Prozesse zu Automotive SPICE-Prozessen120
2.11.2 Basispraktiken122
2.11.3 Ausgewählte Arbeitsprodukte127
08-50 Testspezifikation127
08-52 Testplan128
13-50 Testergebnis128
13-22 Traceability-Aufzeichnung128
13-25 Verifikationsergebnisse128
2.11.4 Besonderheiten Level 2128
Zum Management der Prozessausführung128
Zum Management der Arbeitsprodukte129
Exkurs: Testdokumentation nach ISO/IEC/IEEE 29119-3129
2.12 SWE.5 Softwareintegration und Softwareintegrationstest131
2.12.1 Zweck131
2.12.2 Basispraktiken132
Abb. 2–15 Integrationsreihenfolge bei einer Bottom-up-Strategie133
Fallbeispiel: Softwareintegration eines Projekts bei der XY AG139
2.12.3 Ausgewählte Arbeitsprodukte140
01-03 Softwarebestandteil140
01-50 Integrierte Software140
08-50 Testspezifikation140
08-52 Testplan140
13-22 Traceability-Aufzeichnung140
13-50 Testergebnis140
17-02 Build-Liste140
2.12.4 Besonderheiten Level 2140
Zum Management der Prozessausführung140
Zum Management der Arbeitsprodukte141
2.13 SWE.6 Softwaretest141
2.13.1 Zweck141
2.13.2 Basispraktiken142
Exkurs: Kurzer Überblick über Testmethoden144
Abb. 2–16 Testmethoden und Integrationsstufen145
Exkurs: Einige Methoden zur Ableitung von Testfällen145
2.13.3 Ausgewählte Arbeitsprodukte146
08-50 Testspezifikation146
08-52 Testplan146
13-50 Testergebnis146
2.13.4 Besonderheiten Level 2146
Zum Management der Prozessausführung146
Zum Management der Arbeitsprodukte147
2.14 SUP.1 Qualitätssicherung147
2.14.1 Zweck147
Generische Praktiken GP 2.2.1 und 2.2.4147
SUP.1 Qualitätssicherung147
SUP.2 Verifikation147
Verifikationsaktivitäten in den Engineering-Prozessen148
SUP.4 Gemeinsame Reviews148
2.14.2 Basispraktiken149
Abb. 2–17 Beispiel eines QS-Berichts an das Management: Abarbeitungsstatus von QS-Befunden und Prozesskonformitätsrate (PKR)154
2.14.3 Ausgewählte Arbeitsprodukte156
08-13 Qualitätssicherungsplan156
13-07 Problemaufzeichnung156
13-18 Qualitätsaufzeichnung157
Abb. 2–18 Beispiel einer Qualitätsaufzeichnung (Titelseite)157
Abb. 2–19 Schema einer Qualitätsaufzeichnung (Maßnahmenseite)157
14-02 Liste der Korrekturaktionen157
2.14.4 Besonderheiten Level 2158
Zum Management der Prozessausführung158
»Qualitätssicherung der Qualitätssicherung«158
2.15 SUP.2 Verifikation159
2.15.1 Zweck159
Abb. 2–20 Überblick Qualitätssicherungmethoden159
2.15.2 Basispraktiken160
2.15.3 Ausgewählte Arbeitsprodukte165
13-07 Problemaufzeichnung165
13-25 Verifikationsergebnis165
14-02 Liste der Korrekturaktionen165
19-10 Verifikationsstrategie165
2.15.4 Besonderheiten Level 2165
Zum Management der Prozessausführung165
Zum Management der Arbeitsprodukte166
2.16 SUP.4 Gemeinsame Reviews166
2.16.1 Zweck166
2.16.2 Basispraktiken168
Abb. 2–21 Beispiel eines Reviewprozesses170
2.16.3 Ausgewählte Arbeitsprodukte172
13-19 Reviewaufzeichnungen172
Abb. 2–22 Beispielstruktur eines Review Log173
2.16.4 Besonderheiten Level 2173
Zum Management der Prozessausführung173
Zum Management der Arbeitsprodukte173
2.17 SUP.8 Konfigurationsmanagement174
2.17.1 Zweck174
2.17.2 Basispraktiken175
Abb. 2–23 Auszug aus einer realen Liste von KM-Elementen177
Abb. 2–24 Verschiedene Ebenen von Baselines181
2.17.3 Ausgewählte Arbeitsprodukte183
01-00 Konfigurationselement183
08-04 Konfigurationsmanagementplan184
13–08 Baseline184
Abb. 2–25 Beispielgliederung eines KM-Plans185
16-03 Konfigurationsmanagementbibliothek (auch: Konfigurationsmanagement- Repository)185
2.17.4 Besonderheiten Level 2186
Zum Management der Prozessausführung186
Zum Management der Arbeitsprodukte186
2.18 SUP.9 Problemmanagement186
2.18.1 Zweck186
Abb. 2–26 Beispiel für Problemstatus188
2.18.2 Basispraktiken188
Abb. 2–27 Beispiel einer Problem- oder Änderungsmeldung191
Abb. 2–28 Beispiel eines Problemklassifizierungsschemas192
Abb. 2–29 Beispiel für Problem- und Abarbeitungsverfolgung über die Zeit195
2.18.3 Ausgewählte Arbeitsprodukte196
08-27 Problemmanagementplan196
13-07 Problemaufzeichnung196
15-01 Analysebericht bzw. 15-05 Bewertungsbericht197
15-12 Problemstatusbericht197
2.18.4 Besonderheiten Level 2197
Zum Management der Prozessausführung197
Zum Management der Arbeitsprodukte198
2.19 SUP.10 Änderungsmanagement199
2.19.1 Zweck199
2.19.2 Basispraktiken200
Abb. 2–30 Beispiel für den Status von Änderungsanträgen201
2.19.3 Ausgewählte Arbeitsprodukte204
08-28 Änderungsmanagementplan204
13-16 Änderungsantrag204
13-21 Änderungsaufzeichnung204
2.19.4 Besonderheiten Level 2205
2.20 MAN.3 Projektmanagement205
2.20.1 Zweck205
2.20.2 Basispraktiken206
Abb. 2–31 Beispiel: Auszug aus der Funktionsliste eines Spurhalteassistenzsystems208
Exkurs: Verteilte Funktionsentwicklung und Integrationsstufen209
Abb. 2–32 Beispiel für einen Projektlebenszyklus eines Steuergeräteentwicklungsprojekts210
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 Ressourcenplanung214
Abb. 2–34 Prinzip der rollierenden Planung217
Abb. 2–35 Arten von Projektbesprechungen und Fortschrittreviews220
2.20.3 Ausgewählte Arbeitsprodukte221
08-12 Projektplan221
Beispielgliederung eines Projektplans für ein großes Projekt222
13-16 Änderungsantrag223
14-06 Terminplan223
14-09 Projektstrukturplan223
15-06 Projektfortschrittsbericht224
Abb. 2–36 Beispiel eines aggregierten Projektfortschrittsberichts für höhere Managementebenen224
2.20.4 Besonderheiten Level 2225
Zum Management der Prozessausführung225
Zum Management der Arbeitsprodukte225
2.21 MAN.5 Risikomanagement225
2.21.1 Zweck225
2.21.2 Basispraktiken227
Abb. 2–37 Überblick Risikomanagementaktivitäten230
Abb. 2–38 Beispiel einer Risikoportfoliodarstellung231
Abb. 2–39 Beispiel von Schadensklassen für terminliche Auswirkungen231
2.21.3 Ausgewählte Arbeitsprodukte234
Risikoliste234
Beispielhafter Aufbau einer Risikoliste234
2.21.4 Besonderheiten Level 2235
Zum Management der Prozessausführung235
Zum Management der Arbeitsprodukte235
2.22 MAN.6 Messen235
2.22.1 Zweck235
»You can’t control, what you can’t measure!« (Tom DeMarco)235
Exkurs: Goal/Question/Metric-(GQM-)Methode236
Abb. 2–40 GQM-Methode237
2.22.2 Basispraktiken238
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 Arbeitsprodukte245
03-03 Benchmarking-Daten245
03-04 Kundenzufriedenheitsdaten246
Beispiel einer Metrikspezifikation246
Abb. 2–43 Spezifikation der Metrik »Funktionalitätszuwachs«247
07-01 Kundenzufriedenheitsbefragung248
07-02 Feldbeobachtung248
07-08 Service-Level-Messung248
2.22.4 Besonderheiten Level 2248
Zum Management der Prozessausführung248
Zum Management der Arbeitsprodukte248
2.23 PIM.3 Prozessverbesserung249
2.23.1 Zweck249
2.23.2 Basispraktiken250
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 Organisationen256
2.23.3 Ausgewählte Arbeitsprodukte257
08-29 Verbesserungsplan257
15-16 Verbesserungsmöglichkeit257
2.23.4 Besonderheiten Level 2257
Zum Management der Prozessausführung257
Zum Management der Arbeitsprodukte257
2.24 REU.2 Wiederverwendungsmanagement258
2.24.1 Zweck258
2.24.2 Basispraktiken259
2.24.3 Ausgewählte Arbeitsprodukte263
08-17 Wiederverwendungsplan263
15-07 Bericht zur Bewertung der Wiederverwendung264
2.24.4 Besonderheiten Level 2264
Zum Management der Prozessausführung264
Zum Management der Arbeitsprodukte264
2.25 Traceability und Konsistenz in Automotive SPICE265
2.25.1 Einleitung265
2.25.2 Grundgedanken265
Abb. 2–46 Horizontale und vertikale Traceability266
2.26 Applikationsparameter in Automotive SPICE271
Abb. 2–47 ISO-26262-Sicht auf Parameter (Quelle: ISO 26262-6, Annex C)271
2.26.1 Ausgewählte Arbeitsprodukte274
WP 01-51 Applikationsparameter274
3 Interpretationen zur Reifegraddimension275
3.1 Struktur der Reifegraddimension275
3.1.1 Levels und Prozessattribute275
3.1.2 Indikatoren für die Reifegraddimension276
Abb. 3–1 Elemente der Reifegraddimension277
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 33020279
Abb. 3–3 Veranschaulichung der Bewertungsmethode R1281
Abb. 3–4 Veranschaulichung der Bewertungsmethoden R2 und R3281
Abb. 3–5 Vertikale Aggregation282
3.4 Die Levels283
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.1284
Abb. 3–7 Bewertungsbeispiele für PA 1.1285
3.4.3 Level 2 (»Gemanagter Prozess«)286
Abb. 3–8 Prozessattribute und generische Praktiken von Level 2287
PA 2.1 Management der Prozessausführung287
GP 2.1.1: Ermittle die Ziele für die Prozessausführung.288
Abb. 3–9 Kommunikationsplan296
PA 2.2 Management der Arbeitsprodukte297
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 3303
PA 3.1 Prozessdefinition304
Abb. 3–11 Prozessarchitektur nach dem EITVOX-Modell305
Exkurs: Tailoring von Prozessen306
Abb. 3–12 Tailoring-Tabelle307
Abb. 3–13 Beispiel für Rollenbeschreibung Softwareprojektleiter310
PA 3.2 Prozessanwendung313
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 Prozessverhalten319
Abb. 3–15 Prozessattribute und generische Praktiken von Level 4320
3.4.6 Level 5 (»Innovativer Prozess«)321
Abb. 3–16 Level 5 – quantitative Prozessoptimierung321
Abb. 3–17 Prozessattribute und generische Praktiken von Level 5323
3.5 Zusammenhang von Prozess- und Reifegraddimension323
Abb. 3–18 Abhängigkeiten zwischen Prozessen und Prozessattributen324
4 Automotive SPICE-Assessments325
4.1 Assessments – Überblick und Grundlagen325
4.2 Phasen, Aktivitäten und Dauer des Assessmentprozesses326
Abb. 4–1 Überblick über Phasen und Aktivitäten des Assessmentprozesses326
Assessmentvorbereitung327
Assessmentdurchführung327
Assessmentabschluss328
Wie lange dauert ein Assessment?329
4.3 Rollen im Assessmentprozess329
4.4 Komplexe Assessments330
Abb. 4–2 Von intacs definiertes OMM für Automotive SPICE331
Abb. 4–3 Anforderungen an die Maturity Levels in Form von geforderten Capability Levels für bestimmte Prozessmengen332
Wie werden die zu untersuchenden Projekte ausgewählt?332
Abb. 4–4 Definition der Assessmentklassen333
Werden OMAs anerkannt?334
5 Funktionale Sicherheit und Automotive SPICE335
5.1 Überblick funktionale Sicherheit und ISO 26262335
IEC 61508336
ISO 26262336
Abb. 5–1 Sicherheitslebenszyklus der ISO 26262336
Abb. 5–2 ISO 26262-Überblick [ISO 26262]337
ASIL338
ISO/IEC 15504-10338
5.2 Vergleich von ISO 26262 und Automotive SPICE339
Abb. 5–3 Überlappung von Automotive SPICE und ISO 26262339
5.3 Unterschiede zwischen ISO 26262 und Automotive SPICE340
5.3.1 Unterschiede im Scope der Standards340
5.3.2 Unterschiede in den Levels341
Abb. 5–4 Unterstützung der ISO-26262-Umsetzung durch Automotive SPICE342
5.3.3 Unterschiede in den Aktivitäten und Rollen342
5.3.4 Unterschiede in den Arbeitsprodukten343
5.3.5 Unterschiede in den Methodenanforderungen343
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ängigkeitsanforderungen344
5.4 Kombination von Automotive SPICE-Assessments und funktionalen Safety-Audits345
Abb. 5–6 Überlappung der Evaluierungsmethoden (Quelle [Dold et al. 2014])346
5.4.1 Kombination von Automotive SPICE-Assessment und Safety-Audit346
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 Aspekte348
Teamzusammensetzung348
Modellergänzungen348
Abb. 5–9 Beispiel für FS-Ergänzungen348
Abb. 5–10 Evaluierungen entlang des Sicherheitslebenszyklus349
5.5 Zusammenfassung ISO 26262 und Automotive SPICE350
6 Agilität und Automotive SPICE351
6.1 Warum sich mit Agilität und Automotive SPICE beschäftigen?352
Beispiele aus der Automobilindustrie353
6.2 Was bedeutet »Agilität in Automotive« ?354
Abb. 6–1 Übersicht und Klassifizierung von »agilen« Begriffen355
6.2.1 Was macht eine agile Entwicklung aus?355
Die 12 Prinzipien agiler Softwareentwicklung356
6.2.2 »Agile in Automotive (AiA)«: Welche agilen Methoden und Praktiken werden in der Automobilentwicklung aktuell eingesetzt?357
Domänen und eingesetzte Methoden357
Disziplinen und Projektphasen357
Häufige Integration358
Sprint-Dauer, Sprint-Umfang358
AiA-Team-Setup358
Retrospektiven und Demos359
User Stories359
Agile Skalierung359
6.2.3 Welche Herausforderungen werden demnächst angegangen ?360
Exkurs: Continuous Integration360
Abb. 6–2 Ablauf von Continuous Integration361
6.3 Wie bringt man Agilität und Automotive SPICE zusammen?362
6.3.1 Grundsätzliches362
Mögliches Mapping362
Abb. 6–3 Abdeckung des HIS Scope Level 1 durch typische agile Praktiken363
6.3.2 Was sind die kritischen Punkte in der Praxis?363
Generell: Die Implementierung der Automotive SPICE-Arbeitsprodukte364
Abb. 6–4 Beispiel einer agilen Entwicklungsumgebung365
Agile Vorausplanung und Automotive SPICE365
Einbettung agiler Teams in das Gesamtprojekt365
Abb. 6–5 Schnittstellen der Planungswerkzeuge zur Projektverfolgung366
Qualitätssicherung366
Anforderungsmanagement und Traceability367
Softwarearchitektur368
Continuous Integration und Test369
Unterstützende Prozesse369
Einbindung weiterer Disziplinen369
Abb. 6–6 Synchronisation und Integrationsebenen unterschiedlicher Zyklenlängen370
6.3.3 Konkrete praktische Lösungsbeispiele370
Definition of Done (DoD)371
Abb. 6–7 Auszüge aus einer DoD auf Teamebene371
Agile Vorausplanung und Automotive SPICE372
Abb. 6–8 Product Backlog mit verschiedenen Planungsebenen372
Continuous Integration und Testebenen373
Abb. 6–9 Continuous Integration und automatisierte Testebenen374
6.4 Agilität, Automotive SPICE und funktionale Sicherheit375
6.5 Zusammenfassung Agilität und Automotive SPICE376
Anhang377
A Beispiele zu Assessmentplanung und Assessmentdokumentation379
A.1 Fall 1: Einfaches Projektassessment Tier-1-Lieferant379
A.1.1 Beispiel eines Assessmentplans379
Allgemeine Angaben zum Assessment379
A.1.2 Beispiel einer Assessmentagenda bis Level 3381
Abb. A–1 Beispielagenda382
A.1.3 Beispielstruktur eines Assessmentberichts383
A.1.4 Beispielbewertung eines Prozesses inklusive Dokumentation383
Bewertung der Indikatoren und Beschreibung der Evidenzen383
Abb. A–2 Beispielbewertung384
A.1.5 Beispiel: Auszug aus der Liste der analysierten Evidenzen/Dokumente385
A.2 Fall 2: Komplexes Projektassessment, mehrere Instanzen385
A.2.1 Beispiel: Planung der Prozessinstanzen pro Prozess386
Abb. A–3 Assessmentplanung und Abdeckung eines komplexen Assessments387
A.2.2 Beispiel: Assessmentagenda388
Abb. A–4 Auszug aus Agenda eines komplexen Assessments388
A.2.3 Beispiel: Konsolidierungs- und Aggregationsregeln389
B Übersicht ausgewählter Arbeitsprodukte391
C Glossar393
D Abkürzungsverzeichnis405
E Literatur, Normen und Webadressen409
Index413
www.dpunkt.de0

Weitere E-Books zum Thema: Software - Betriebssysteme - Anwenderprogramme

Softwaretechnik

E-Book Softwaretechnik
Format: PDF

Software-Projekte geraten oft in Schwierigkeiten: Zeit und Budget werden überschritten; das Projekt tritt auf der Stelle; im schlimmsten Fall wird es ohne Ergebnis abgebrochen. Manche…

Softwaretechnik

E-Book Softwaretechnik
Format: PDF

Software-Projekte geraten oft in Schwierigkeiten: Zeit und Budget werden überschritten; das Projekt tritt auf der Stelle; im schlimmsten Fall wird es ohne Ergebnis abgebrochen. Manche…

Softwaretechnik

E-Book Softwaretechnik
Format: PDF

Software-Projekte geraten oft in Schwierigkeiten: Zeit und Budget werden überschritten; das Projekt tritt auf der Stelle; im schlimmsten Fall wird es ohne Ergebnis abgebrochen. Manche…

Statistische Grafiken mit Excel

E-Book Statistische Grafiken mit Excel
Format: PDF

Die grafische Veranschaulichung von Sachverhalten oder Entwicklungsverläufen spielt in allen empirisch orientierten Bereichen eine besondere Rolle. Empirische Informationen grafisch aufzubereiten,…

Statistische Grafiken mit Excel

E-Book Statistische Grafiken mit Excel
Format: PDF

Die grafische Veranschaulichung von Sachverhalten oder Entwicklungsverläufen spielt in allen empirisch orientierten Bereichen eine besondere Rolle. Empirische Informationen grafisch aufzubereiten,…

Computergrafik und OpenGL

E-Book Computergrafik und OpenGL
Format: PDF

Das Lehrbuch stellt die theoretischen Grundlagen zu den wichtigsten Themenbereichen der Computergrafik, wie Rastergrafik, Modellierung, Transformation, Projektion, Clipping, Sichtbarkeit, Farbe und…

Computergrafik und OpenGL

E-Book Computergrafik und OpenGL
Format: PDF

Das Lehrbuch stellt die theoretischen Grundlagen zu den wichtigsten Themenbereichen der Computergrafik, wie Rastergrafik, Modellierung, Transformation, Projektion, Clipping, Sichtbarkeit, Farbe und…

Computergrafik und OpenGL

E-Book Computergrafik und OpenGL
Format: PDF

Das Lehrbuch stellt die theoretischen Grundlagen zu den wichtigsten Themenbereichen der Computergrafik, wie Rastergrafik, Modellierung, Transformation, Projektion, Clipping, Sichtbarkeit, Farbe und…

Citrix Presentation Server

E-Book Citrix Presentation Server
Format: PDF

Der Citrix MetaFrame Presentation Server ist unangefochtener Marktführer unter den Terminalservern für Windows-Systeme. Unternehmen setzen ihn ein, um die Systemverwaltung von Windows-Netzwerken…

Citrix Presentation Server

E-Book Citrix Presentation Server
Format: PDF

Der Citrix MetaFrame Presentation Server ist unangefochtener Marktführer unter den Terminalservern für Windows-Systeme. Unternehmen setzen ihn ein, um die Systemverwaltung von Windows-Netzwerken…

Weitere Zeitschriften

arznei-telegramm

arznei-telegramm

Das arznei-telegramm® informiert bereits im 53. Jahrgang Ärzte, Apotheker und andere Heilberufe über Nutzen und Risiken von Arzneimitteln. Das arznei-telegramm®  ist neutral und ...

cards Karten cartes

cards Karten cartes

Die führende Zeitschrift für Zahlungsverkehr und Payments – international und branchenübergreifend, erscheint seit 1990 monatlich (viermal als Fachmagazin, achtmal als ...

Das Hauseigentum

Das Hauseigentum

Das Hauseigentum. Organ des Landesverbandes Haus & Grund Brandenburg. Speziell für die neuen Bundesländer, mit regionalem Schwerpunkt Brandenburg. Systematische Grundlagenvermittlung, viele ...

dental:spiegel

dental:spiegel

dental:spiegel - Das Magazin für das erfolgreiche Praxisteam. Der dental:spiegel gehört zu den Top 5 der reichweitenstärksten Fachzeitschriften für Zahnärzte in Deutschland (laut LA-DENT 2011 ...

DSD Der Sicherheitsdienst

DSD Der Sicherheitsdienst

Der "DSD – Der Sicherheitsdienst" ist das Magazin der Sicherheitswirtschaft. Es erscheint viermal jährlich und mit einer Auflage von 11.000 Exemplaren. Der DSD informiert über aktuelle Themen ...