Automotive SPICE® - Capability Level 2 und 3 in der Praxis (eBook)
286 Seiten
dpunkt (Verlag)
978-3-96088-009-7 (ISBN)
Dr. Pierre Metz leitet den konzernweiten Aufbau der Funktionalen Sicherheit bei der Brose Fahrzeugteile GmbH & Co. KG als Teil der Unternehmensstandardprozesse für sicherheitsrelevante Mechatronikentwicklung und betreut selbst aktiv Projekte. Er ist intacs?-zertifizierter SPICE und Automotive SPICE® Principal Assessor und leitete auch international Assessmentteams in den Domänen Automotive, Telekommunikation und Medizintechnik. Als intacs?-akkreditierter Ausbilder für Provisional und Competent Assessoren bildet er Assessoren aus. Er ist Mitbegründer und Mitglied des intacs?-Fachbeirats und war bis 2015 Leiter der intacs?-Arbeitsgruppe für die Erarbeitung und Pflege der standardisierten, international verwendeten Kursmaterialen für die Assessorenausbildung beider Stufen. Pierre Metz begleitete als Mitglied des VDA/QMA AK 13 die Entwicklung des in 2015 veröffentlichten Automotive SPICE® v3.0-Modells und beteiligt sich in den deutschen Normungsgremien für funktionale Sicherheit NA 052-00-32-08-01 'Allgemeine Anforderungen an Fahrzeuge' sowie NA 052-00-32-08-02 'Software und Prozesse'. Hierüber ist er zudem Mitglied der deutschen Delegation für die internationale Arbeitsgruppe der ISO 26262 (ISO TC22/SC32/WG8).
Dr. Pierre Metz leitet den konzernweiten Aufbau der Funktionalen Sicherheit bei der Brose Fahrzeugteile GmbH & Co. KG als Teil der Unternehmensstandardprozesse für sicherheitsrelevante Mechatronikentwicklung und betreut selbst aktiv Projekte. Er ist intacs™-zertifizierter SPICE und Automotive SPICE® Principal Assessor und leitete auch international Assessmentteams in den Domänen Automotive, Telekommunikation und Medizintechnik. Als intacs™-akkreditierter Ausbilder für Provisional und Competent Assessoren bildet er Assessoren aus. Er ist Mitbegründer und Mitglied des intacs™-Fachbeirats und war bis 2015 Leiter der intacs™-Arbeitsgruppe für die Erarbeitung und Pflege der standardisierten, international verwendeten Kursmaterialen für die Assessorenausbildung beider Stufen. Pierre Metz begleitete als Mitglied des VDA/QMA AK 13 die Entwicklung des in 2015 veröffentlichten Automotive SPICE® v3.0-Modells und beteiligt sich in den deutschen Normungsgremien für funktionale Sicherheit NA 052-00-32-08-01 "Allgemeine Anforderungen an Fahrzeuge" sowie NA 052-00-32-08-02 "Software und Prozesse". Hierüber ist er zudem Mitglied der deutschen Delegation für die internationale Arbeitsgruppe der ISO 26262 (ISO TC22/SC32/WG8).
Vorwort 5
Inhaltsübersicht 7
Inhaltsverzeichnis 9
1 Wie ist dieses Buch zu lesen? 17
In Kapitel 2 … 17
Kapitel 3 … 17
Für Kapitel 4 … 17
Für Kapitel 5 ... 18
Kapitel 6 liefert … 18
Bewertungsregeln für Assessments 19
Was für alle Kapitel gilt 19
2 Erläuterung im Buch referenzierter Konzepte 21
2.1 Produktlinie 21
Fazit 23
2.2 Standardsoftwarekomponente 23
Abb. 2–1 Gegenüberstellung Standardsoftwarekomponente(n) und Einbindung in die Gesamtsoftwareebene auf Projektseite 23
Beispiel 1 24
2.3 Baukasten 24
2.4 Übernahmeprojekt/Übernahmeentwicklung 24
2.5 Systemingenieur 24
Beispiel 2 24
Beispiel 3 25
2.6 Quality Gate/Stage Gate Review 26
2.7 Use Case/Anwendungsfall 26
Als Anforderungsermittlungsmethode 26
Abb. 2–2 Zwei Use Cases für eine automatische Heckklappe 27
Als Anforderungsstrukturierungsmethode 27
Abb. 2–3 Abgrenzung von Use Cases und Innenabläufen: Die fachliche Leistung des äußeren Use Case wird durch den Innenablauf über die Elemente A bis F und einer Interaktion mit dem anstoßenden, äußeren Aktor erbracht. Element B wiederum stell... 29
3 Verstehen der Capability Level 0 bis 5 31
3.1 Motivation und Kurzabriss der Historie 31
3.2 Drei Abstraktionsebenen des Begriffs »Prozess« 31
Abb. 3–1 Drei Abstraktionsebenen des Begriffs Prozess (nach [intacsPA], Bild übernommen aus [Besemer et al. 14], das auch für das Automotive SPICE v3.0 PRM- und PAM-Dokument frei zur Verfügung gestellt wurde) 32
Abb. 3–2 Die zweidimensionale Struktur der ISO/IEC 33020 und ISO/EC 15504 33
3.3 Die Capability Level 1 bis 5 33
3.3.1 Capability Level 0 – Incomplete (Unvollständig) 33
3.3.2 Capability Level 1 – Performed (Durchgeführt) 33
3.3.3 Capability Level 2 – Managed (Gesteuerte Durchführung) 34
3.3.4 Capability Level 3 – Established (Standardisiert und qualitativ verbessernd) 35
3.3.5 Capability Level 4 – Predictable (Quantitativ vorhersagbar) 36
Abb. 3–3 Special Causes of Variation 36
3.3.6 Capability Level 5 – Optimizing (Optimierend) 37
Abb. 3–4 Common Causes of Variation 37
3.4 Erkenntnis 38
3.4.1 CL1 bis CL5 bilden eine Kausalkette »von unten nach oben« 38
Abb. 3–5 Capability Level bauen aufeinander auf [intacsPA] 38
3.4.2 CL5 bis CL1 bilden eine Kausalkette »von oben nach unten« 39
3.4.3 Capability Level sind ein Bedingungsgefüge und ein Messsystem 39
Abb. 3–6 Die Idee eines Prozessassessments [intacsPA] 39
Abb. 3–7 Die Begriffe des Prozessprofils und des Capability-Profils [intacsPA] 40
3.5 Zum Streitpunkt »SPICE vs. Agile« 41
4 Capability Level 2 – praktisches Verständnis der generischen Praktiken 43
Vorgriff: Der Zusammenhang zwischen CL2 und dem CL1 anderer Prozesse 43
4.1 PA 2.1 – Management der Prozessdurchführung 44
Abb. 4–1 Alle Einflüsse und Zusammenhänge zwischen allen generischen Praktiken des PA 2.1 44
Abb. 4–2 Alle Einflüsse und Zusammenhänge zwischen den generischen Praktiken des PA 2.1 und PA 2.2 44
4.1.1 GP 2.1.1, GP 2.1.2 – Prozessziele und deren Planung 45
Hinweis 1 für Assessoren 48
Beispiel 4 49
Hinweis 2 für Assessoren 49
1. Details zu Terminen und Dauern 50
2a. Details zu Aufwänden hinsichtlich Arbeitszeit 50
Hinweis 3 für Assessoren 51
Beispiel 5 51
Hinweis 4 für Assessoren 51
Beispiel 6 52
Beispiel 7 52
Exkurs 1 53
Beispiel 8 53
2b. Details zu Aufwänden hinsichtlich Budget/Kosten 54
3. Leistungsformeln und Zielwerte (Targets) 54
4. Anzuwendende Methoden und Techniken 55
Hinweis 5 für Assessoren 55
Schlussbemerkungen 55
Abb. 4–3 Zusammenhänge der GP 2.1.1 und GP 2.1.2 56
4.1.2 GP 2.1.6 – Ressourcen 56
Beispiel 9 57
Hinweis 6 für Assessoren 58
Abb. 4–4 Zusammenhänge bei GP 2.1.6 innerhalb PA 2.1 58
4.1.3 GP 2.1.7 – Stakeholder-Management 58
Exkurs 2 59
Hinweis 7 für Assessoren 60
Hinweis 8 für Assessoren 61
Abb. 4–5 Zusammenhänge bei GP 2.1.7 innerhalb von PA 2.1 61
4.1.4 GP 2.1.5 – Verantwortlichkeiten und Befugnisse 62
Hinweis 9 für Assessoren 62
Hinweis 10 für Assessoren 63
Abb. 4–6 Zusammenhänge bei GP 2.1.5 innerhalb von PA 2.1 65
4.1.5 GP 2.1.3 – Überwachung der Prozessdurchführung 65
Hinweis 11 für Assessoren 66
Hinweis 12 für Assessoren 67
Abb. 4–7 Zusammenhänge der GP 2.1.3 innerhalb von PA 2.1 67
4.1.6 GP 2.1.4 – Anpassung der Prozessdurchführung 67
Maßnahmen ergreifen, sodass die Leistung wieder zur Planung passt 68
Planung oder Prozessziele anpassen 69
Hinweis 13 für Assessoren 69
Abb. 4–8 Zusammenhänge bei GP 2.1.4 innerhalb von PA 2.1 70
Hinweis 14 für Assessoren 70
Abb. 4–9 Zusammenhänge GP 2.1.4 und PA 2.2 71
4.2 PA 2.2 – Management der Arbeitsprodukte 71
Abb. 4–10 Zusammenhänge innerhalb von PA 2.2 71
4.2.1 GP 2.2.1 – Anforderungen an die Arbeitsprodukte 72
Exkurs 3 72
4.2.1.1 Strukturelle Vorgaben (strukturelle Qualitätskriterien) 72
Hinweis 15 für Assessoren 73
Hinweis 16 für Assessoren 73
Hinweis 17 für Assessoren 73
Hinweis 18 für Assessoren 73
4.2.1.2 Inhaltliche Qualitätskriterien 74
Hinweis 19 für Assessoren 74
Hinweis 20 für Assessoren 75
Hinweis 21 für Assessoren 76
Hinweis 22 für Assessoren 77
Hinweis 23 für Assessoren 78
Exkurs 4 78
4.2.1.3 Checklisten 79
4.2.1.4 Prüfmethoden, Prüfabdeckung, Prüffrequenz und Prüfparteien 79
Prüfmethoden 80
Hinweis 24 für Assessoren 80
Prüfabdeckung 80
Prüffrequenz 81
Prüfparteien 82
Beispiel 10 82
4.2.2 GP 2.2.2 – Anforderungen an die Dokumentation und Kontrolle 82
Eigentümerschaft 83
Spezifisches Versionieren, spezifisches Konfigurationsmanagement 83
Zugriffsrechte und Arbeitsprodukt-Security 84
Ablage 84
Hinweis 25 für Assessoren 84
Status 85
Abb. 4–11 Lebenszyklus eines Arbeitsprodukts, in Anlehnung an die SysML-Notation für Zustandsdiagramme. Die vertikalen gestrichelten Linien deuten die am Zustand Beteiligten an. 85
Exkurs 5 86
Hinweis 26 für Assessoren 86
Spezifische Freigabe/Abnahme 87
Beispiel 11 87
Hinweis 27 für Assessoren 88
Exkurs 6 88
Spezifisches Änderungsmanagement 89
Exkurs 7 89
Stakeholder-Notifikation 89
Lebens-/Gültigkeitsdauern 89
Sicherheitskopien und Restauration 90
4.2.3 GP 2.2.3 – Dokumentation und Kontrolle 90
4.2.4 GP 2.2.4 – Überprüfung und Anpassung der Arbeitsprodukte 90
4.3 Bewertungshilfen aus Sicht von Capability Level 2 92
4.3.1 Zwischen CL2 und CL1 anderer Prozesse 92
Tab. 4–1 Bezüge zwischen GPs des CL2 und dem CL1 anderer Prozesse 92
4.3.1.1 Allgemein 93
Nicht-Abwertungsgrund 1 93
4.3.1.2 GP 2.1.1 Prozessziele (Performance Objectives) 93
Abwertungsgrund 1 93
4.3.1.3 GP 2.1.2 Planung 94
Konsistenzwarner 1 94
Nicht-Abwertungsgrund 2 94
4.3.1.4 GP 2.1.3 Überwachung 94
4.3.1.5 GP 2.1.4 Anpassung 95
Konsistenzwarner 2 95
Konsistenzwarner 3 95
4.3.1.6 GP 2.1.5 Verantwortlichkeiten und Befugnisse 95
Konsistenzwarner 4 95
4.3.1.7 GP 2.1.6-Ressourcen 96
Konsistenzwarner 5 96
4.3.1.8 GP 2.1.7 Stakeholder-Management 96
Konsistenzwarner 6 96
4.3.1.9 GP 2.2.1 Anforderungen an die Arbeitsprodukte 96
Konsistenzwarner 7 96
4.3.1.10 GP 2.2.2, GP 2.2.3 Handhabung der Arbeitsprodukte 97
Konsistenzwarner 8 97
Konsistenzwarner 9 97
4.3.1.11 GP 2.2.4 Prüfung der Arbeitsprodukte 97
Abwertungsgrund 2 97
Konsistenzwarner 10 98
4.3.2 Innerhalb CL 2 98
4.3.2.1 GP 2.1.1 Prozessziele (Performance Objectives) 98
Abwertungsgrund 3 98
Abwertungsgrund 4 98
4.3.2.2 GP 2.1.2 Planung 99
Abwertungsgrund 5 99
Abwertungsgrund 6 99
Nicht-Abwertungsgrund 3 99
Abwertungsgrund 7 100
Abwertungsgrund 8 100
4.3.2.3 GP 2.1.3 Überwachung 100
Konsistenzwarner 11 100
Abwertungsgrund 9 101
Abwertungsgrund 10 101
Abwertungsgrund 11 101
Abwertungsgrund 12 101
Abwertungsgrund 13 102
Abwertungsgrund 14 102
4.3.2.4 GP 2.1.4 Anpassung 102
Abwertungsgrund 15 102
Abwertungsgrund 16 103
Nicht-Abwertungsgrund 4 103
Nicht-Abwertungsgrund 5 103
Abwertungsgrund 17 103
4.3.2.5 GP 2.1.5: Verantwortlichkeiten und Befugnisse 104
Nicht-Abwertungsgrund 6 104
Nicht-Abwertungsgrund 7 105
Abwertungsgrund 18 105
4.3.2.6 GP 2.1.6 Ressourcen 106
Abwertungsgrund 19 106
Abwertungsgrund 20 106
Abwertungsgrund 21 106
4.3.2.7 GP 2.2.1 Anforderungen an die Arbeitsprodukte 107
Nicht-Abwertungsgrund 8 107
Nicht-Abwertungsgrund 9 107
Nicht-Abwertungsgrund 10 107
Nicht-Abwertungsgrund 11 108
Abwertungsgrund 22 108
Abwertungsgrund 23 108
4.3.2.8 GP 2.2.2 und GP 2.2.3 Anforderungen an Arbeitsprodukte 109
Abwertungsgrund 24 109
4.3.2.9 GP 2.2.4 Prüfung der Arbeitsprodukte 109
Abwertungsgrund 25 109
Abwertungsgrund 26 109
Nicht-Abwertungsgrund 12 110
Abwertungsgrund 27 110
5 Capability Level 2 – prozessspezifische Interpretation 111
5.1 Spezifisches für alle Prozesse 111
5.1.1 GP 2.1.1 – Prozessziele (Performance Objectives) 111
Termine und Dauern [Metz 09], [intacsPA] 111
Hinweis 28 für Assessoren 112
5.1.2 GP 2.1.2, GP 2.1.3, GP 2.1.4 – Planung, Überwachung und Anpassung 112
5.1.3 GP 2.1.5 – Verantwortlichkeiten und Befugnisse 112
5.1.4 GP 2.1.6-Ressourcen 113
5.2 SYS.2 – Systemanforderungsanalyse 113
5.2.1 GP 2.1.1 – Prozessziele (Performance Objectives) 113
Termine und Dauern 113
Beispiel 12 113
Exkurs 8 114
Aufwände 114
Methoden und Techniken 114
Beispiel 13 115
Abb. 5–1 Skizze des Aufbaus und der Funktionalitäten automatischer Heckklappen [Metz 14] 115
Abb. 5–2 Vereinfachtes Analyseergebnis für Guide-Word VORHER 117
5.2.2 GP 2.1.6 – Ressourcen 117
5.2.3 GP 2.1.5 – Verantwortlichkeiten und Befugnisse 117
5.2.4 GP 2.1.7 – Stakeholder-Management 118
5.2.5 GP 2.1.2, GP 2.1.3, GP 2.1.4 – Planung, Überwachung und Anpassung 119
5.2.6 GP 2.2.1 – Anforderungen an die Arbeitsprodukte 119
5.2.7 GP 2.2.4 – Prüfung der Arbeitsprodukte 121
5.2.8 GP 2.2.2, GP 2.2.3 – Handhabung der Arbeitsprodukte 122
Exkurs 9 122
5.3 SYS.3 – Systemarchitekturdesign 124
Exkurs 10 124
5.3.1 GP 2.1.1 – Prozessziele (Performance Objectives) 125
Termine und Dauern 125
Aufwände 125
Methoden und Techniken 125
5.3.2 GP 2.1.5, GP 2.1.6, GP 2.1.7 – Verantwortlichkeiten und Befugnisse, Ressourcen, Stakeholder-Management 125
Hinweis 29 für Assessoren 126
Hinweis 30 für Assessoren 126
Beispiel 14 127
Beispiele 15 127
5.3.3 GP 2.1.2, GP 2.1.3, GP 2.1.4 – Planung, Überwachung und Anpassung 129
5.3.4 GP 2.2.1 – Anforderungen an die Arbeitsprodukte 129
5.3.5 GP 2.2.4 – Prüfung der Arbeitsprodukte 130
5.3.6 GP 2.2.2, GP 2.2.3 – Handhabung der Arbeitsprodukte 130
5.4 SWE.1 – Softwareanforderungsanalyse 131
5.4.1 GP 2.1.1 – Prozessziele (Performance Objectives) 131
5.4.2 GP 2.1.6 – Ressourcen 131
5.4.3 GP 2.1.5 – Verantwortlichkeiten und Befugnisse 131
5.4.4 GP 2.1.7 – Stakeholder-Management 132
5.4.5 GP 2.1.2, GP 2.1.3, GP 2.1.4 – Planung, Überwachung und Anpassung 133
5.4.6 GP 2.2.1 – Anforderungen an die Arbeitsprodukte 133
5.4.7 GP 2.2.4 – Prüfung der Arbeitsprodukte 133
5.4.8 GP 2.2.2, GP 2.2.3 – Handhabung der Arbeitsprodukte 134
5.5 SWE.2 – Softwarearchitekturdesign 135
5.5.1 GP 2.1.1 – Prozessziele (Performance Objectives) 135
Termine und Dauern 135
Aufwände 135
Methoden und Techniken 136
5.5.2 GP 2.1.5, GP 2.1.6, GP 2.1.7 – Verantwortlichkeiten und Befugnisse, Ressourcen, Stakeholder 136
5.5.3 GP 2.1.2, GP 2.1.3, GP 2.1.4 – Planung, Überwachung und Anpassung 137
5.5.4 GP 2.2.1 – Anforderungen an die Arbeitsprodukte 137
5.5.5 GP 2.2.4 – Prüfung der Arbeitsprodukte 139
5.5.6 GP 2.2.2, GP 2.2.3 – Handhabung der Arbeitsprodukte 140
5.6 SWE.3 – Softwarefeindesign und Codierung 140
Exkurs 11 140
Exkurs 12 142
Exkurs 13 142
5.6.1 GP 2.1.1 – Prozessziele (Performance Objectives) 142
Termine und Dauern (Standard-SW-Komponenten einer Produktlinie) 142
Aufwände (Standard-SW-Komponenten einer Produktlinie) 143
Termine und Dauern (Ebene eines gesamten Entwicklungsprojekts) 143
Aufwände (Ebene eines gesamten Entwicklungsprojekts) 143
Methoden und Techniken (beide Ebenen) 144
5.6.2 GP 2.1.5, GP 2.1.6, GP 2.1.7 – Verantwortlichkeiten und Befugnisse, Ressourcen, Stakeholder 145
5.6.3 GP 2.1.2, GP 2.1.3, GP 2.1.4 – Planung, Überwachung und Anpassung 146
5.6.4 GP 2.2.1 – Anforderungen an die Arbeitsprodukte 146
Softwarefeindesign 146
Quellcode 147
Qualitätskriterien für beide Arten der Entwicklung 147
Exkurs 14 148
5.6.5 GP 2.2.4 – Prüfung der Arbeitsprodukte 148
5.6.6 GP 2.2.2, GP 2.2.3 – Handhabung der Arbeitsprodukte 149
Exkurs 15 150
5.7 SWE.4 – Software-Unit-Verifikation 152
Exkurs 16 152
5.7.1 GP 2.1.1 – Prozessziele (Performance Objectives) 152
Termine, Dauern und Aufwände (Standard-SW-Komponenten einer Produktlinie) 152
Termine, Dauern und Aufwände (Ebene eines gesamten Entwicklungsprojekts) 153
Methoden und Techniken (beide Ebenen) 153
5.7.2 GP 2.1.5, GP 2.1.6, GP 2.1.7 – Verantwortlichkeiten und Befugnisse, Ressourcen, Stakeholder 153
5.7.3 GP 2.1.2, GP 2.1.3, GP 2.1.4 – Planung, Überwachung und Anpassung 154
5.7.4 GP 2.2.1 – Anforderungen an die Arbeitsprodukte 154
Hinweis 31 für Assessoren 155
5.7.5 GP 2.2.2, GP 2.2.3, GP 2.2.4 – Handhabung und Prüfung der Arbeitsprodukte 155
5.8 SWE.5 – Softwareintegration und Softwareintegrationstest 157
5.8.1 GP 2.1.1 – Prozessziele (Performance Objectives) 157
Termine und Dauern 157
Aufwände 157
Methoden und Techniken 157
5.8.2 GP 2.1.5, GP 2.1.6, GP 2.1.7 – Verantwortlichkeiten und Befugnisse, Ressourcen, Stakeholder 158
5.8.3 GP 2.1.2, GP 2.1.3, GP 2.1.4 – Planung, Überwachung und Anpassung 159
5.8.4 GP 2.2.1 – Anforderungen an die Arbeitsprodukte 159
5.8.5 GP 2.2.2, GP 2.2.3, GP 2.2.4 – Handhabung und Prüfung der Arbeitsprodukte 159
5.9 SWE.6 – Softwarequalifizierungstest 160
5.9.1 GP 2.1.1 – Prozessziele (Performance Objective) 160
Termine, Dauern und Aufwände 160
Methoden und Techniken 161
5.9.2 GP 2.1.5, GP 2.1.6, GP 2.1.7 – Verantwortlichkeiten und Befugnisse, Ressourcen, Stakeholder-Management 161
Exkurs 17 162
5.9.3 GP 2.1.2, GP 2.1.3, GP 2.1.4 – Planung, Überwachung und Anpassung 163
5.9.4 GP 2.2.1 – Anforderungen an die Arbeitsprodukte 163
5.9.5 GP 2.2.2, GP 2.2.3, GP 2.2.4 – Handhabung und Prüfung der Arbeitsprodukte 164
5.10 SYS.4 – Systemintegration und Systemintegrationstest 165
5.10.1 GP 2.1.1 – Prozessziele (Performance Objective) 165
Termine, Dauern und Aufwände 165
Methoden und Techniken 166
5.10.2 GP 2.1.5, GP 2.1.6, GP 2.1.7 – Verantwortlichkeiten und Befugnisse, Ressourcen, Stakeholder-Management 166
Hinweis 32 für Assessoren 167
5.10.3 GP 2.1.2, GP 2.1.3, GP 2.1.4 – Planung, Überwachung und Anpassung 168
5.10.4 GP 2.2.1 – Anforderungen an die Arbeitsprodukte 169
5.10.5 GP 2.2.2, GP 2.2.3, GP 2.2.4 – Handhabung und Prüfung der Arbeitsprodukte 169
5.11 SYS.5 – Systemqualifizierungstest 171
5.11.1 GP 2.1.1 – Prozessziele (Performance Objective) 171
Termine, Dauern und Aufwände 171
Methoden und Techniken 171
5.11.2 GP 2.1.5, GP 2.1.6, GP 2.1.7 – Verantwortlichkeiten und Befugnisse, Ressourcen, Stakeholder-Management 171
Exkurs 18 173
5.11.3 GP 2.1.2, GP 2.1.3, GP 2.1.4 – Planung, Überwachung und Anpassung 174
5.11.4 GP 2.2.1 – Anforderungen an die Arbeitsprodukte 174
5.11.5 GP 2.2.2, GP 2.2.3, GP 2.2.4 – Handhabung und Prüfung der Arbeitsprodukte 174
5.12 MAN.3 – Projektmanagement 176
5.12.1 GP 2.1.1 – Prozessziele (Performance Objectives) 176
Termine und Dauern 176
Hinweis 33 für Assessoren 176
Aufwände 176
Leistungsformeln [Metz 09], [intacsPA] 177
Methoden und Techniken 177
5.12.2 GP 2.1.2, GP 2.1.3, GP 2.1.4 – Planung, Überwachung und Anpassung 177
5.12.3 GP 2.1.6 – Ressourcen 178
5.12.4 GP 2.1.5 – Verantwortlichkeiten und Befugnisse 179
Nicht-Abwertungsgrund 13 179
Abwertungsgrund 28 180
5.12.5 GP 2.1.7 – Stakeholder-Management 180
5.12.6 GP 2.2.1, GP 2.2.4 – Anforderungen an die Arbeitsprodukte und Prüfung 180
Abwertungsgrund 29 181
5.12.7 GP 2.2.2, 2.2.3 – Handhabung der Arbeitsprodukte 181
5.13 ACQ.4 – Zuliefererüberwachung 182
5.13.1 GP 2.1.1 bis GP 2.1.4 – Prozessziele, Planung, Überwachung und Anpassung 182
Hinweis 34 für Assessoren 182
5.13.2 GP 2.1.5, GP 2.1.6, GP 2.1.7 – Verantwortlichkeiten und Befugnisse, Ressourcen, Stakeholder 183
5.13.3 GP 2.2.1, GP 2.2.4 – Anforderungen an die Arbeitsprodukte und Prüfungen 183
Abwertungsgrund 30 183
5.13.4 GP 2.2.2, GP 2.2.3 – Handhabung der Arbeitsprodukte 184
Exkurs 19 184
5.14 SUP.1 – Qualitätssicherung 184
Hinweis 35 für Assessoren 184
Exkurs 20 185
5.14.1 GP 2.1.1 – Prozessziele (Performance Objectives) 185
Termine und Dauern 185
Aufwände 185
Leistungsformeln [Metz 09], [intacsPA] 186
Methoden und Techniken 186
5.14.2 GP 2.1.2, GP 2.1.3, GP 2.1.4 – Planung, Überwachung und Anpassung 186
5.14.3 GP 2.1.6 – Ressourcen 187
5.14.4 GP 2.1.5 – Verantwortlichkeiten und Befugnisse 187
5.14.5 GP 2.1.7 – Stakeholder-Management 187
5.14.6 GP 2.2.1, GP 2.2.4 – Anforderungen an die Arbeitsprodukte und Prüfung 188
5.14.7 GP 2.2.2, GP 2.2.3 – Handhabung der Arbeitsprodukte 189
5.15 Gemeinsame Interpretation für SUP.8, SUP.9, SUP.10 190
5.15.1 GP 2.1.1 – Prozessziele (Performance Objectives) 190
Aufwände [Metz 09], [intacsPA] 190
Termine und Dauern 191
Exkurs 21 191
Leistungsformeln 191
5.15.2 GP 2.1.2, GP 2.1.3 – Planung und Überwachung 192
5.15.3 GP 2.1.4 – Anpassung 192
5.15.4 GP 2.1.5 – Verantwortlichkeiten und Befugnisse 192
Hinweis 36 für Assessoren 193
5.15.5 GP 2.1.6 – Ressourcen 193
Hinweis 37 für Assessoren 194
5.15.6 GP 2.1.7 – Stakeholder-Management 194
Hinweis 38 für Assessoren 194
5.15.7 GP 2.2.1, GP 2.2.4 – Anforderungen an die Arbeitsprodukte und Prüfung 195
Abwertungsgrund 31 195
Abwertungsgrund 32 196
5.15.8 GP 2.2.2, 2.2.3 – Handhabung der Arbeitsprodukte 196
5.16 SUP.8 – Konfigurationsmanagement 196
5.16.1 GP 2.1.1 – Prozessziele (Performance Objectives) 196
Aufwände 196
Leistungsformeln [Metz 09], [intacsPA] 197
Hinweis 39 für Assessoren 197
Termine und Dauern [Metz 09], [intacsPA] 197
5.16.2 GP 2.1.2, GP 2.1.3 – Planung und Überwachung 198
5.16.3 GP 2.1.4 – Anpassung 198
5.16.4 GP 2.1.5 – Verantwortlichkeiten und Befugnisse 198
5.16.5 GP 2.1.6 – Ressourcen 199
5.16.6 GP 2.1.7 – Stakeholder-Management 199
5.16.7 GP 2.2.1 – Anforderungen an die Arbeitsprodukte 201
5.16.8 GP 2.2.2, GP 2.2.3 – Handhabung der Arbeitsprodukte 201
5.16.9 GP 2.2.4 – Prüfung der Arbeitsprodukte 202
Hinweis 40 für Assessoren 202
5.17 SUP.9 – Problemlösungsmanagement 203
5.17.1 GP 2.1.1 – Prozessziele (Performance Objectives) 203
Aufwände 203
Termine und Dauern [Metz 09], [intacsPA] 203
Leistungsformeln [Metz 09], [intacsPA] 203
5.17.2 GP 2.1.2, GP 2.1.3 – Planung und Überwachung 204
5.17.3 GP 2.1.4 – Anpassung 204
5.17.4 GP 2.1.6 – Ressourcen 204
5.17.5 GP 2.1.7 – Stakeholder-Management 205
5.17.6 GP 2.1.5 – Verantwortlichkeiten und Befugnisse 205
Hinweis 41 für Assessoren 206
5.17.7 GP 2.2.1 – Anforderungen an die Arbeitsprodukte 206
5.17.8 GP 2.2.2, GP 2.2.3 – Handhabung der Arbeitsprodukte 206
5.17.9 GP 2.2.4 – Prüfung von Arbeitsprodukten 207
5.18 SUP.10 – Änderungsmanagement 207
5.18.1 GP 2.1.1 – Prozessziele (Performance Objectives) 207
Aufwände 207
Termine und Dauern [Metz 09], [intacsPA] 207
Leistungsformeln [Metz 09], [intacsPA] 207
5.18.2 GP 2.1.2, GP 2.1.3 – Planung und Überwachung 208
5.18.3 GP 2.1.4 – Anpassung 208
5.18.4 GP 2.1.5 – Verantwortlichkeiten und Befugnisse 208
5.18.5 GP 2.1.6 – Ressourcen 209
5.18.6 GP 2.1.7 – Stakeholder-Management 209
5.18.7 GP 2.2.1 – Anforderungen an die Arbeitsprodukte 210
5.18.8 GP 2.2.2, GP 2.2.3 – Handhabung der Arbeitsprodukte 210
5.18.9 GP 2.2.4 – Prüfung der Arbeitsprodukte 210
6 Capability Level 3 – praktisches Verständnis der generischen Praktiken 211
Hinweis 42 für Assessoren 211
6.1 PA 3.1 und PA 3.2 212
6.1.1 GP 3.1.1 bis GP 3.1.4 – Beschreibung von Prozessen 212
Use-Case-orientierter Einstieg in Prozesse 213
Abb. 6–1 In der Praxis vorkommende Art von Einstiegsseiten in Standardprozessbeschreibungen – Liste von nachgeahmten Prozessen bzgl. Automotive SPICE-Struktur 213
Abb. 6–2 Mögliche Einstiegsseite in Standardprozessbeschreibungen – Aktivitäten und/oder Arbeitsprodukte angeordnet nach V-Modell 213
Beispiel 16 214
Beispiel 17 215
Abb. 6–3 Beispielhafte Skizze eines Use-Case-orientierten Einstiegs in Standardprozessbeschreibungen für einen Softwareentwickler 215
Abb. 6–4 Abstrakte, beispielhafte Skizze von Aktivitäten hinter dem Use Case Ergebnisse für eine Softwareübernahme generieren (in Anlehnung an UML-Aktivitätsdiagramme) 216
Abb. 6–5 Abstrakte, beispielhafte Skizze von Aktivitäten hinter dem Use Case Eine Produktlinie applizieren (in Anlehnung an UML-Aktivitätsdiagramme) 217
Abb. 6–6 Abstrakte, beispielhafte Skizze von Aktivitäten hinter dem Use Case Neuentwicklung betreiben (in Anlehnung an UML-Aktivitätsdiagramme) 218
Wichtige Anmerkung speziell zum Use Case Neue Produktlinie erstellen: 218
Verweben aller Prozesse in integrierte Arbeitsflüsse 219
Abb. 6–7 Die Prozessschritte hinter den Use Cases sind thematisch verwoben, dargestellt an einer Skizze für die Detaillierung von Implementiere SW-Funktionalitäten für nicht umgesetzte Anforderungen aus den Abbildungen 6–4, 6–5 und 6–6 (in... 220
Zur Wahl der Modellierungssprache 220
Hinweis 43 für Assessoren 221
Hinweis 44 für Assessoren 221
Elemente einer Prozessbeschreibung 221
Abb. 6–8 Skizzenhafte Beispielausprägung des Dreigestirns. Ein Dreigestirn gilt für jeden Prozessschritt. 222
Beschreibung von Arbeitsprodukten und Werkzeugen 223
Abb. 6–9 Dreigestirn, Arbeitsprodukte mit Zusatzinformationen, und Werkzeuge 224
Beispiel 18 225
Abb. 6–10 Dreigestirn, präzise Anteile von Arbeitsprodukten als Input 226
Hinweis 45 für Assessoren 226
Beschreibung von Rollen und notwendigen Fähigkeiten für Aktivitäten 227
Hinweis 46 für Assessoren 228
Abb. 6–11 Dreigestirn, Fähigkeiten für Aktivitäten und/oder Rollen 229
Beschreibung von Methoden und Techniken 229
Abb. 6–12 Dreigestirn, Methoden an Arbeitsprodukten oder Aktivitäten 230
Konfigurationsmanagement von Standardprozessen 231
Hinweis 47 für Assessoren 231
Standardprozess vs. Ausbildungsunterlagen 232
Muss ein Standardprozess immer dokumentiert sein? 232
Hinweis 48 für Assessoren 233
6.1.2 GP 3.1.1, GP 3.2.1 – Maßschneidern von Standardprozessen (Tailoring) 233
Hinweis 49 für Assessoren 233
Beispiel 19 234
Abb. 6–13 Use Cases aus Abbildung 6–3 (S. 199), die sich nur in den entsprechenden Prozesselementen unterscheiden. Hier für den Leser durch UML-Stereotypen gekennzeichnet. 234
Beispiel 20 235
Abb. 6–14 Use Cases aus Abbildung 6–13, deren dahinterliegende Arbeitsflüsse sich durch »Wahleinstellung« des ASIL ergeben. 235
Hinweis 50 für Assessoren 236
6.1.3 Notwendige Vorgaben für Multiprojektmanagement 237
Beispiel 21 237
Abb. 6–15 Übersichtsskizze des Zusammenhangs der Entwicklung von Funktionalitäten eines Produktlinienprojekts und deren Nutzung für Releases von Kundenprojekten an einem fiktiven Beispiel einer automatischen Heckklappe. Eine solche Tabelle wird ... 237
6.1.4 GP 3.1.5, GP 3.2.6 – Feststellen der Effektivität und Eignung der Standards 238
Hinweis 51 für Assessoren 239
Hinweis 52 für Assessoren 240
Prozessbeschreibungen als Redaktionssystem mit dem Konzept sozialer Netzwerke 240
Exkurs 22 241
Weitere Methoden zur Ermittlung von Prozesseignung 242
Abb. 6–16 Auszug aus [Metz 12], automatisierter Bericht zur Verfolgung von Arbeitsprodukterzeugung nach Standardprozess. Vertikal Arbeitsprodukte, horizontal Termine zu Lieferständen. Hellgrau = Arbeitsprodukt existiert vollständig zu der vorherg... 243
Hinweis 53 für Assessoren 244
Kultur der offenen Kommunikation 244
Managementreviews 244
6.1.5 GP 3.2.2, GP 3.2.3, GP 3.2.4 – Sicherstellen der verlangten Kompetenzen der ausgewählten Personen 246
Exkurs 23 246
6.1.6 GP 3.2.5 – Sicherstellen der Nutzung aller verlangten Infrastruktur 247
Hinweis 54 für Assessoren 247
6.2 Bewertungshilfen aus Sicht von CL3 248
Tab. 6–1 Zusammenhänge der GP des CL3 mit dem CL1 anderer Prozesse 248
6.2.1 Zwischen CL3 und CL1 anderer Prozesse 248
Abwertungsgrund 33 249
Konsistenzwarner 12 249
Konsistenzwarner 13 249
Konsistenzwarner 14 249
6.2.2 Zwischen CL3 und CL2 250
Abwertungsgrund 34 250
Konsistenzwarner 15 250
6.2.3 Innerhalb CL 3 251
Abwertungsgrund 35 251
Konsistenzwarner 16 251
Nicht-Abwertungsgrund 14 252
Nicht-Abwertungsgrund 15 252
Abwertungsgrund 36 252
Nicht-Abwertungsgrund 16 253
7 Bewertungshilfen für CL1 255
7.1 Die CL1-Bewertung eines Prozesses ist nicht abhängig von der eines »Vorgängerprozesses« 255
Beispielszenario 255
Vermutung 256
Das Problem 256
Was das für Assessoren bedeutet 256
Ist dann eine Produktaussage nicht mehr möglich? 257
7.2 SYS.2, SWE.1 – Anforderungsanalyse auf System- und Softwareebene 258
Abwertungsgrund 37 258
7.3 SYS.3, SWE.2 – Architektur auf System- und Softwareebene 258
Abwertungsgrund 38 258
7.4 SWE.3 – Softwarefeindesign und Codierung 258
Abwertungsgrund 39 258
7.5 Strategie-BPs (SWE.4, SWE.5, SWE.6, SYS.4, SYS.5, SUP.1, SUP.8, SUP.9, SUP.10) 259
Nicht-Abwertungsgrund 17 259
Nicht-Abwertungsgrund 18 259
7.6 SWE.4 – Software-Unit-Verifikation 259
Abwertungsgrund 40 259
7.7 SYS.4, SWE.5 – Integrationstesten auf System- und Softwareebene 260
Abwertungsgrund 41 260
7.8 SYS.5, SWE.6 – System- und Softwaretest 260
Abwertungsgrund 42 260
7.9 MAN.3 – Projektmanagement 260
Konsistenzwarner 17 260
Konsistenzwarner 18 261
Konsistenzwarner 19 261
Abwertungsgrund 43 261
7.10 ACQ.4 – Zuliefererüberwachung 262
Abwertungsgrund 44 262
Abwertungsgrund 45 262
Abwertungsgrund 46 262
7.11 SUP.1 – Qualitätssicherung 262
Abwertungsgrund 47 262
Abwertungsgrund 48 263
Abwertungsgrund 49 263
Konsistenzwarner 20 263
Konsistenzwarner 21 263
7.12 SUP.8 – Konfigurationsmanagement 263
Abwertungsgrund 50 263
Abwertungsgrund 51 264
7.13 SUP.9 – Problemlösungsmanagement 264
Abwertungsgrund 52 264
Abwertungsgrund 53 264
Abwertungsgrund 54 264
Konsistenzwarner 22 265
7.14 SUP.10 – Änderungsmanagement 265
Abwertungsgrund 55 265
Abwertungsgrund 56 265
Abwertungsgrund 57 266
Abwertungsgrund 58 266
Anhang 267
A Abkürzungen und Glossar 269
B Referenzen 279
Index 281
www.dpunkt.de 0
2 Erläuterung im Buch referenzierter Konzepte
Wegen ihrer durchgehenden Benutzung in Kapiteln 4, 5 und 6 werden hier bereits vorab wichtige Konzepte und Begriffe beschrieben. Weitere Begriffe sind im Glossar am Ende des Buchs erklärt.
2.1 Produktlinie
Dieser Begriff wird international nicht unbedingt einheitlich verstanden. In diesem Buch steht er für eine Produktkategorie, für die vorgefertigte Standardproduktdokumentation unter Traceability auf allen Ebenen des V-Modell-Prinzips existiert. Eine Produktlinie kann dabei sowohl auf der Ebene eines ganzen Systems wie auch nur für Software existieren (s. u. Standard-SW-Komponente). Diese Standardproduktdokumentation beinhaltet auf Systemebene, Hardwareebene und Softwareebene Folgendes:
-
Anforderungen und Testfälle und dazugehörige Prüfnachweise (im Sinne von Review, Inspektion etc.)
-
Architektur und Integrationstestfälle und dazugehörige Prüfnachweise
-
Komponentendesign und Testfälle sowie dazugehörige Prüfnachweise
Auf Systemebene kommen noch zusätzlich hinzu:
-
Produkt-FMEAs mit vormodellierten Fehlernetzen sowie Entdeckungs- und Vermeidungsmaßnahmen
Auf Softwareebene zusätzlich noch:
-
Quellcode und dazugehörige Prüfnachweise
-
Unit-Design und dazugehörige Prüfnachweise
-
Software-Unit-Testfälle und dazugehörige Prüfnachweise
-
Kriterien für statische Softwareverifikation
Auf Hardwareebene zusätzlich noch:
-
Schaltungsentwurf/Stromlaufpläne bzw. Designrichtlinien und dazugehörige Prüfnachweise
Diese Standarddokumentation ist bereits über alle V-Modell-Ebenen hinweg konsistent in Varianten organisiert, die typischen Kundenwünschen oder technischen Notwendigkeiten entsprechen. So kann es für automatische Heckklappen z. B. folgende Varianten geben:
-
Zusätzliche Einklemmschutzleisten für die seitlichen Scherbereiche, wenn diese auf Fahrzeugebene mechanisch-baulich hinreichend gefährlich sind (technisch notwendig).
-
Technisch: Die Wahl eines Einzel- oder Doppelspindelantriebs. Dies sind motorgetriebene Schubstangen, die die Heckklappe auf- und wieder einfahren (Kundenwunsch).
Varianteninformationen ziehen sich dabei von den Anforderungen durch alle Folgedokumentationen hindurch, d. h. von den Systemanforderungen über Architektur und Design bis hinunter zum Softwarequellcode und zu Hardware-Schaltungsentwürfen. Dies kann folgendermaßen realisiert sein:
-
Auf der Ebene von Anforderungen durch Attributierung
-
Auf der Ebene des Softwaredesigns z. B. durch SysML-Stereotypen, Tagged Values oder ganzer SysML-Modelle spezifisch für eine Variante
-
Auf der Ebene des Quellcodes durch:
• Präprozessorkommandos wie #define und #ifdef (im Falle der Programmiersprache C)
• verschiedene statische Softwarebibliotheken (libraries)
• Applikationsparameter (calibration parameters), mittels derer über Parameterdateien oder Diagnosejobs Funktionen ein- oder ausgeschaltet oder nichtfunktionale Eigenschaften beeinflusst werden können
-
Auf der Ebene der Hardware durch Angaben auf Zeichnungen und Stücklisten
Ein Projekt erweitert eine Produktlinie um ein neues konkretes, kundenspezifisches Produkt, indem
-
zunächst eine Variante gewählt und
-
diese Variante noch spezifisch verändert wird.
Umgekehrt finden sinnvolle und vorteilhafte Veränderungen, die zu einer spezifischen Produktausprägung geführt haben, wieder in die Produktlinie zurück durch Hinzufügen einer Variante oder Änderungen einzelner Anforderungen, Quellcode etc. Dasselbe gilt für Test- und Validierungsergebnisse und Erfahrung aus Feldrückläufern.
Fazit
-
Eine Produktlinie bedeutet also die systematische und gemeinschaftliche Wiederverwendung von Arbeitsprodukten anstelle einer opportunistischen Wiederverwendung durch einfaches Kopieren einzelner Aspekte [Clements & Northrop 02]. Eine solche Form der Wiederverwendung macht die Produkte homogener, und das damit verbundene Lernen von Fehlern oder Erfolgen anderer bedeutet dauernde Qualitätserhöhung. All dies wiederum führt zu wirtschaftlich effizienterer Produktentwicklung.
-
Ein Produktlinienansatz erfordert aber auch dedizierte Experten oder eine Gruppe für dessen Pflege, die die Projekte beraten. Ohne solche Verantwortliche fällt es den Projektmitarbeitern in den einzelnen Projekten zeitlich und logistisch schwer, auf alle anderen Projekte gleichzeitig zu schauen, um so kollektiv von allein Produktstandards zu schaffen oder einzuhalten.
2.2 Standardsoftwarekomponente
Unter einer Standardsoftwarekomponente wird hier eine Produktlinie verstanden, die auf eine Softwarekomponente beschränkt ist (zur Unterscheidung zwischen Softwarekomponente und Software-Unit siehe Exkurs 11 auf S. 124).
Abb. 2–1 Gegenüberstellung Standardsoftwarekomponente(n) und Einbindung in die Gesamtsoftwareebene auf Projektseite
Eine Standardsoftwarekomponente muss neben den Anforderungen an ihre fachlichen Funktionalitäten und ihren fachlichen Algorithmus auch Anforderungen an die Schnittstelle zu anderen SW-Komponenten stellen. Diese Schnittstellenanforderungen sagen aus, wie die jeweilige andere SW-Komponente an- oder eingebunden werden muss, und sie sind auch beim SW-SW-Integrationstests zugrunde zu legen.
Beispiel 1
-
Die SW-Komponente Basis-SW gibt an, wie die Applikationssoftware zu initialisieren ist.
-
Applikations-SW-Komponenten geben umgekehrt für die SW-Komponente Basis-SW z. B. an, in welcher Auflösung Signale bereitgestellt werden müssen.
-
Die SW-Komponente Hall-Sensor Auswertung gibt der Komponente NVRAM Manager z. B. an, wie viel Byte letztere mit welchem Timing an welchen Ort speichern bzw. laden muss.
2.3 Baukasten
Ähnlich einer Produktlinie enthält ein Baukasten die darin beschriebenen Varianten, jedoch ist eine gewählte Variante nicht mehr spezifisch veränderbar.
2.4 Übernahmeprojekt/Übernahmeentwicklung
Ein am Markt befindliches Produkt eines Vorgängerprojekts und dessen Produktdokumentation wird übernommen, ohne oder mit geringfügigen Änderungen, z. B. Fehlerkorrektur oder kundenspezifische Anpassung der Bedienschnittstelle (z. B. Kommunikation mit der Fahrzeugumgebung über z. B. LIN, CAN, FlexRay oder MOST). Es liegt hier keine Ausprägung einer Produktlinie oder eines Baukastens vor.
2.5 Systemingenieur
Insbesondere mechatronische Systementwicklung ist mehr als nur das Zusammenbringen von Komponenten, die von den Mechanik-, Hardware- und Softwareabteilungen isoliert voneinander entwickelt worden sind, und die bloße Betrachtung aller Schnittstellen.
Beispiel 2
-
Für einen einwandfreien Einklemmschutz eines Fensterhebers ist es notwendig, dass die physikalische Position der Scheibe in der Fahrzeugtür dieselbe ist, die die Software über das Zählen von Motorumdrehungen errechnet. Durch mechanischen Verschleiß, Umweltbedingungen und Nutzerverhalten bei der Scheibenbedienung allerdings wird sich die Position in der Software gegenüber der tatsächlichen Position mit der Zeit verfälschen.
Beispiel 3
-
Sollte das Taktsignal auf der Elektronik permanent verschoben sein, dann würde die Motorgeschwindigkeit eines Fensterhebers durch die Software falsch interpretiert werden, was zu einer Fehlinterpretation der tatsächlichen Scheibenkraft in der Fahrzeugtür führte. Dies wiederum resultierte darin, dass der Einklemmschutz im Bedarfsfall zu früh (Qualitätsproblem) oder zu spät (Produktsicherheitsproblem) reagiert.
Um solche Lücken zu verhindern und die (meist durch organisatorische Trennung oder gar Abwesenheit von Projektorganisationen noch verschlimmerte) Isolation der verschiedenen Bereiche aufzubrechen, stellt ein Systemingenieur als ein technischer Projektleiter die Anforderungen aus mechatronischer bzw. elektronischer Sicht gesamtheitlich auf, steht dem Systemdesign vor und sorgt für die technische Erfüllung aus den Einzelergebnissen aus Mechanikkonstruktion, Hardware- und Softwareentwicklung. Er beachtet dabei Produktlinien und Standardkomponenten (s. o.), wenn vorhanden.
Ohne die Experten der Teilbereiche ersetzen zu wollen oder zu können, muss er dazu innerhalb seines fachlichen Produktbereichs bis zu einer gewissen Detailebene auf folgenden Gebieten mechatronisch bzw. elektronisch kompetent sein:
-
Aufbau und der Auslegung von Mechanik
-
Aufbau von Motoren und Motortypen
-
Aufbau und Architekturen von Elektronik und Embedded Software
• z. B. Halbleiter- vs....
| Erscheint lt. Verlag | 30.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-96088-009-X / 396088009X |
| ISBN-13 | 978-3-96088-009-7 / 9783960880097 |
| Haben Sie eine Frage zum Produkt? |
PDF (Wasserzeichen)Größe: 5,2 MB
DRM: Digitales Wasserzeichen
Dieses eBook enthält ein digitales Wasserzeichen und ist damit für Sie personalisiert. Bei einer missbräuchlichen Weitergabe des eBooks an Dritte ist eine Rückverfolgung an die Quelle möglich.
Dateiformat: PDF (Portable Document Format)
Mit einem festen Seitenlayout eignet sich die PDF besonders für Fachbücher mit Spalten, Tabellen und Abbildungen. Eine PDF kann auf fast allen Geräten angezeigt werden, ist aber für kleine Displays (Smartphone, eReader) nur eingeschränkt geeignet.
Systemvoraussetzungen:
PC/Mac: Mit einem PC oder Mac können Sie dieses eBook lesen. Sie benötigen dafür einen PDF-Viewer - z.B. den Adobe Reader oder Adobe Digital Editions.
eReader: Dieses eBook kann mit (fast) allen eBook-Readern gelesen werden. Mit dem amazon-Kindle ist es aber nicht kompatibel.
Smartphone/Tablet: Egal ob Apple oder Android, dieses eBook können Sie lesen. Sie benötigen dafür einen PDF-Viewer - z.B. die kostenlose Adobe Digital Editions-App.
Buying eBooks from abroad
For tax law reasons we can sell eBooks just within Germany and Switzerland. Regrettably we cannot fulfill eBook-orders from other countries.
aus dem Bereich
