Sie sind hier

E-Book

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

Prozessspezifische Interpretationsvorschläge

Autor	Pierre Metz
Verlag	dpunkt
Erscheinungsjahr	2016
Seitenanzahl	286 Seiten
ISBN	9783960880097
Format	PDF/ePUB
Kopierschutz	Wasserzeichen/DRM
Geräte	PC/MAC/eReader/Tablet
Preis	42,90 EUR

Automotive SPICE ist das in der Automobilindustrie weltweit verbindliche 6-stufige Bewertungsmodell für Produktentwicklungsabläufe für softwarebasierte Systeme. Die abstrakte Formulierung des Bewertungsmodells führt jedoch häufig zu Verständnisschwierigkeiten, die eine ineffiziente Prozessumsetzung oder sogar Divergenzen in Assessmentergebnissen nach sich ziehen können. An dieser Stelle setzt das Buch an: Es bietet einen praxisorientierten Überblick über den zweiten und dritten Prozessreifegrad des Modells und liefert prozessspezifische Interpretationshilfen der generischen Praktiken anhand konkreter Beispiele für die Anwendung in der Praxis: • Verstehen der Bedeutung der Capability Level 0 bis 5 • Capability Level 2 - praktisches Verständnis der generischen Praktiken • Capability Level 2 - prozessspezifische Interpretation • Capability Level 3 - praktisches Verständnis der generischen Praktiken • Bewertungshilfen für Capability Level 1 Prozessspezifische Bewertungshilfen, Bewertungsregeln für Assessments sowie Querbezüge zwischen den Prozessen und Capability Levels zum direkten Nachschlagen unterstützen dabei, ein in sich konsistentes Assessmentergebnis zu erzielen. Das Buch richtet sich in erster Linie an Praktiker, die einen leichteren Einstieg in Automotive SPICE - Capability Level 2 und 3 - und eine Hilfestellung für die Umsetzung in der Praxis suchen.

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

Kaufen Sie hier:

Horizontale Tabs

Leseprobe

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

Blick ins Buch

Inhaltsverzeichnis

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

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

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

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

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

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

Format: PDF

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

Format: PDF

Computergrafik und OpenGL

Format: PDF

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

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

Altenheim - Lösungen fürs Management

Altenheim ist die Fachzeitschrift für Träger, Heimleitungen und leitende Mitarbeiter/innen der teilstationären und stationären Altenhilfe. Hier erfahren Sie, wie Sie Ihre Einrichtung zu ...

artist window: art to buy magazin und internetgalerie

Das artist window stellt Künstler bzw. deren Werke vor und gibt somit einen Einblick in die Ateliers und Werkstätten der Kunstschaffenden. Das besondere am artist window ist, dass die ...

Ärzte Zeitung

Zielgruppe: Niedergelassene Allgemeinmediziner, Praktiker und Internisten. Charakteristik: Die Ärzte Zeitung liefert 3 x pro Woche bundesweit an niedergelassene Mediziner ...

Berufsstart Bewerbung

»Berufsstart Bewerbung« erscheint jährlich zum Wintersemester im November mit einer Auflage von 50.000 Exemplaren und ermöglicht Unternehmen sich bei Studenten und Absolventen mit einer ...

Blätter für deutsche Landesgeschichte

Einzelbeiträge und Sammelrezensionen zur vergleichenden Landesgeschichte. Im Gesamtverein der deutschen Geschichts- und Altertumsvereine haben sich die deutschen Geschichtsvereine, die Historischen ...

care konkret

care konkret ist die Wochenzeitung für Entscheider in der Pflege. Ambulant wie stationär. Sie fasst topaktuelle Informationen und Hintergründe aus der Pflegebranche kompakt und kompetent für Sie ...

Courier

The Bayer CropScience Magazine for Modern AgriculturePflanzenschutzmagazin für den Landwirt, landwirtschaftlichen Berater, Händler und generell am Thema Interessierten, mit umfassender ...

Das Grundeigentum

Das Grundeigentum - Zeitschrift für die gesamte Grundstücks-, Haus- und Wohnungswirtschaft. Für jeden, der sich gründlich und aktuell informieren will. Zu allen Fragen rund um die Immobilie. Mit ...

SPORT in BW (Württemberg)

SPORT in BW (Württemberg) ist das offizielle Verbandsorgan des Württembergischen Landessportbund e.V. (WLSB) und Informationsmagazin für alle im Sport organisierten Mitglieder in Württemberg. ...

rfe-Elektrohändler

rfe-Elektrohändler ist die Fachzeitschrift für die CE- und Hausgeräte-Branche. Wichtige Themen sind: Aktuelle Entwicklungen in beiden Branchen, Waren- und Verkaufskunde, Reportagen über ...