Sie sind auf Seite 1von 104

Automotive SPICE 3.

0 Was ist
neu und was sich gendert hat?

Fabio Bella
Klaus Hoermann
Bhaskar vanamali
Steffen Herrmann
Markus Mller
Dezember 2015

KUGLER MAAG CIE GmbH

Version 2015.12.05

Seite 1
ber den Trainer: Markus Mueller

Verheiratet mit 2 Kindern


Director Operations bei Kugler Maag Cie
Mehr als 15 Jahre Erfahrung in der Industrie und Forschungsprojekten
Untersttzung mittelstndische Unternehmen sowie internationale Konzerne,
vor allem in der Automobilindustrie
PMI Project Management Professional
Sehr erfahrene Trainer, Moderator und Management-Coach
Referent auf Konferenzen und Co-Autor der Bcher

Qualifikation und Erfahrung


intacs -zertifizierten Haupt Assessor und Trainer, intacs Advisory Board-Mitglied,

durchgefhrt mehr als 50 Assessments, viele von ihnen fr OEMs


trainierte mehr als 300 ISO / IEC 15504 Provisional Assessoren von fhrenden Automobilherstellern
(OEMs) und Zulieferer
beraten OEM Vertreter auf die Entwicklung von Automotive SPICE
Projektleiter von mehreren Vernderungen und Verbesserungsprojekten auf Basis von ISO / IEC 15504 und CMM /
CMMI
Die Beratung, Coaching und aktive Untersttzung in mehreren ECU Entwicklungsprojekten in der Automobil

ZB Projektleiter fr die Umsetzung eines Projekts Kontrollbro (PCO) in der Elektronik-Entwicklung eines
groen Automobilhersteller, die heute mehr als 100 Projekte ECU Entwicklung steuert
Sich vorstellen

Dr. Klaus Hoermann


Auftraggeber und Partner bei Kugler Maag Cie

Fhrer der intacs TM Arbeitsgruppe Prfungen


intacs TM SPICE Haupt Assessor, intacs TM SPICE Instructor
Volkswagen-zertifizierte Software Quality Improvement Leader (SQIL)
CMMI SCAMPI Lead Appraiser (CMMI Institute-zertifiziert)
CMMI Instructor (CMMI Institute-zertifiziert)
Scrum Master (Scrum.org zertifiziert)

Seite 3
ber den Trainer: Bhaskar vanamali

Verheiratet mit 4 Kindern


Process Director bei Kugler Maag Cie
Mehr als 15 Jahre Erfahrung in der Industrie und Prozessverbesserung

Untersttzung mittelstndische Unternehmen sowie internationale Konzerne,


vor allem in der Automobilindustrie
Sehr erfahrene Trainer, Moderator und Management-Coach
Referent auf Konferenzen und Co-Autor der Bcher

Qualifikation und Erfahrung


intacs -zertifizierten Haupt Assessor und Trainer, VDA AK13-Mitglied,
durchgefhrt mehr als 90 Assessments, viele von ihnen fr OEMs
trainierte mehr als 200 ISO / IEC 15504 Provisional Assessoren von fhrenden Automobilherstellern
(OEMs) und Zulieferer
beraten OEM Vertreter auf die Entwicklung von Automotive SPICE
Projektleiter von mehreren Vernderungen und Verbesserungsprojekten auf Basis von SPICE und CMM / CMMI

Die Beratung, Coaching und aktive Untersttzung in mehreren ECU Entwicklungsprojekten in der Automobil

Mitglied der ISO-Arbeitsgruppe fr die System- und SW-Engineering-Prozesse


Inhalt

Zusammenfassung
Einfhrung
bersicht ber die nderungen

nderungen im Detail

Und schlussendlich

mehr Frage?
Kontakt Informationen

Seite 5
Zusammenfassung
Version 3.0 umfasst viele kleine nderungen und Verbesserungen, einige strukturelle Vernderungen, und nur wenige

Vernderungen, die Projekt Anstrengungen erhhen.

Strukturelle Vernderungen:

Die Engineering-Prozesse wurden in den beiden Gruppen-System unterteilt (SYS) und Software (SWE).
Die Spitze des V wurde gendert: Die Gertekonstruktion und Einzeleichung werden in zwei Verfahren getrennt.

Ein Plug-In-Konzept ermglicht die Integration von mechanischen und Hardware-Prozesse (nicht von Automotive SPICE zur Verfgung gestellt)

Inhaltlich, der HIS-Scope bleibt im Wesentlichen gleich ist (aber der Name mehrerer Prozesse gendert
hat).
Nur wenige nderungen werden zustzliche Anstrengungen von Projekten fhren, zB Bewertung alternativer Lsungen ist erforderlich fr die
System- und Softwarearchitekturen nach definierten Kriterien. Das Bewertungsergebnis einschlielich einer Begrndung fr die Architektur /
Design Auswahl hat aufgezeichnet werden.

Der Messrahmen wurde auf die Vernderungen in der ISO 33020 angepasst
Kleine nderungen fr Fhigkeitsstufen 1-3, groe Vernderungen fr Fhigkeitsstufen 4-5

Automotive SPICE 3.0 noch nicht verpflichtend ist. Dies wird durch den VDA-Qualitts Vorstand mit der Verffentlichung
des neuen Blue / Gold Volume (September 2016) entschieden werden.

In der Zwischenzeit 13 die VDA AK wird Interpretation Richtlinien fr Automotive SPICE 3.0 und auch eine Leitlinie fr
die Durchfhrung von Assessments (geplant fr April 2016) entwickeln.

Seite 6
Einfhrung

Seite 7
Grundlegende Fakten und Anerkennungen

Automotive SPICE Vers. 3.0 wird die Automobil SPICE Process Assessment Modell (PAM) 2.5
und das Prozessreferenzmodell (PRM) 4.5 ersetzen.

ASPICE Vers. 3.0 umfasst PRM und PAM in einem einzigen Dokument.
Automotive SPICE ist nicht mehr mit ISO 12207 als Orientierungshilfe

Automotive SPICE ist ein eingetragenes Warenzeichen des Verbandes der


Automobilindustrie eV (VDA)

Automotive SPICE 3.0 wurde von der Arbeitsgruppe 13 des Qualitts Management Center (QMC) im
Verband der Deutschen Automobilindustrie (Verband der Automobilindustrie eV, VDA) mit der
Darstellung der Mitglieder der Automotive Special Interest Group (SIG) erstellt wurde - nur, und mit
der Zustimmung der SPICE User Group berprfen. Diese Vereinbarung basiert auf einer Validierung
der Automotive SPICE Version 3.0 in Bezug auf jede ISO Urheberrechtsverletzung und die von VDA
QMC zum SPICE User Group gegebenen Aussagen in Bezug auf die aktuelle und zuknftige
Entwicklung von Automotive SPICE.

Seite 8
Mitglieder VDA AK13

Die Mitarbeiter von Volkswagen, Continental, Schffler, ZF, Brose, Ford, BMW, Daimler, Knorr
Bremse

Sekretr: Bhaskar vanamali (KMC)


Kontakt VDA QMC: Dr. Jan Morenzin

Seite 9
Automotive SPICE 3.0 Bereitstellung und Timeline

Automotive SPICE 3.0 wurde im Juli 2015 verffentlicht und kann mit dem Sponsor fr die Beurteilung
zustimmend verwendet werden.

Automotive SPICE 2.3 ist immer noch die Version, die vom VDA zwingend angesehen wird. Automotive
SPICE-Versionen 2.3 oder 2.5 nach wie vor verwendet werden.

Verbindliche Regeln fr die Automotive SPICE 3.0 bergang werden durch den VDA-Qualitts Vorstand mit
der Verffentlichung des neuen Blue / Gold Volume (September 2016) beschlossen.

In der Zwischenzeit wird die VDA AK 13 Interpretation Richtlinien fr Automotive SPICE 3.0 und auch
einen Leitfaden zur Durchfhrung von Assessments entwickeln (Blau / Gold Volumen nach VDA,
geplanten Termin ist September 2016).

Seite 10
Blau / Gold Volume und ASPICE 3.0 - Deployment und Timeline (1/2)

Release Lassen Sie


Automotive Blau / Gold
SPICE 3.0 Volume

Periode II =
Zeitraum I bergangszeit Period III

Automotive
Ende 2016 Ende 2017
SYS Juli
2015

Zeitleiste von Verffentlichungen von AK13 und bergangszeit

HHLE! Die Verffentlichung Zeit des Blau / Gold Volumens des VDA ist ein Zieldatum und die
bergangszeit von einem Jahr (Periode II) noch in der Diskussion ist.

Seite 11
Blau / Gold Volume und ASPICE 3.0 - Deployment und Timeline (2/2)

Thema Zeitraum I Period II Period III

Einstiegsseiten ASPICE 3.0-Version BG BG Volume Abgabeende des Ende des bergangs

Exit Volume Release bergangs (~ 1y) ffnen Ende

iNTACS Trainings Update von Training zu Update von Training zum BG Keiner
ASPICE 3.0 Volume

Zertifizierte Gutachter Keine Auswirkungen fr jede Upgrade-Schulung erforderlich fr Keine Auswirkungen auf
Klasse kompetente und Auftraggeber keine Kompetente und Haupt ein
Auswirkungen auf Provisional Upgrade-Ausbildung noch fr
Assessoren Provisional Assessoren Noch
bentigt

Weitere Schulungen Update Training mglich, aber kein iNTACS- und VDA Noch iNTACS- und
offizielles Training WG13approved Trainings VDA-Upgrade-Trainings-WG13
Upgrade genehmigt

Provisional Assessoren Keine besonderen Anforderungen Upgrade-Training in der Upgrade-Training in der


Diskussion aber nicht klar, wie Diskussion aber nicht klar, wie
das erzwingen das erzwingen

Assessments Beurteilung fr jede PAM Assessments fr PAM 3.0 nur dann In der Diskussion: Fr die deutschen

2,3 bis 3,0 sind mglich akzeptiert, wenn Lead-Assessor OEMs haben Assessments auf Basis von

Training Upgrade unterzog PAM durchgefhrt werden 3.0

Seite 12
Regeln fr den Zeitraum zwischen Juli 2015 bis den Leitlinien verffentlicht werden -
Periode I

Es wird kein offizielles Upgrade-Training sein.


Die iNTACS Schulungsmaterialien fr Provisional und Competent Assessor werden aktualisiert (Update
fr Provisional Assessor Training geplant fr Anfang 2016)

iNTACS Lehrer sind nicht zu aktualisierenden erforderlich


Um der Lage sein, Automotive SPICE 3.0 Beurteilungen auszufhren: keine zustzlichen Anforderungen

Automotive SPICE 3.0 Assessments sind anerkannt als EE-1.


Zertifizierung / Rezertifizierung: Keine nderungen

Seite 13
Regeln fr den Zeitraum zwischen Leitlinien sind bis zum Ende der bergangszeit
(Datum tbd) verffentlicht - Periode II

iNTACS Schulungsunterlagen werden aktualisiert. Es wird ein offizielles Upgrade Training. iNTACS werden alle

nderungen bieten, werden AK13 Bewertungen durchzufhren. iNTACS Bildungsanbieter werden die Schulungen

durchfhren.

iNTACS Ausbilder mssen aufgerstet werden. Bhaskar vanamali und Pierre Metz wird die
Upgrade-Trainings durchfhren.

iNTACS Trainingsanbieter Upgrade-Training fr alle Beisitzer Qualitten bieten.


Um der Lage sein, Automotive SPICE 3.0 Assessments durchfhren: Der Lead Assessor muss haben in
offiziellen Upgrade-Training teilgenommen.

Automotive SPICE 3.0 Assessments sind anerkannt als EE-1, wenn der Prfer ein Upgrade Training
bestanden hat (oder haben einen neuen vorlufigen Kurs besucht). Beurteilungen von frheren Modellen (2.3
aufwrts) sind nach wie vor als EE- anerkannt
1.

Zertifizierung / Rezertifizierung:
Vorlufige: Es sind keine nderungen an Rezertifizierung. New Provisional Course.
Kompetent: Bentigen Sie ein Upgrade, wenn sie einen neuen provisorischen Kurs nahm.

Principals: Need Upgrade


Seite 14
Regeln fr die Zeit nach dem Ende der bergangszeit (Datum tbd)
- Period III

Automotive SPICE 3.0 Assessments sind anerkannt als EE-1, wenn der Prfer ein Upgrade Training
bestanden hat (oder haben einen neuen vorlufigen Kurs besucht).

Ob Einschtzungen von den Vorgngermodellen (2.3 aufwrts) werden anerkannt noch als EE-1
ist noch nicht entschieden.

Zertifizierung / Rezertifizierung:
Vorlufige: Es sind keine geplanten nderungen Rezertifizierung. New Provisional Course. Allerdings Diskussion ber die
obligatorische Upgrade-Training fr Provisional Assessoren, die auf altes Training auf Basis ausgebildet wurden.

Kompetent: Bentigen Sie ein Upgrade, wenn sie einen neuen provisorischen Kurs nahm.

Principals: Need Upgrade

Seite 15
bersicht ber die nderungen

Seite 16
Motivation fr die Aktualisierung Automotive SPICE

Die Anpassung an den ISO / IEC 15504-5 2012

Automotive SPICE 2.5 basiert auf ISO / IEC 15504-5 2006.


Anpassung an die ISO / IEC 33000-Serie
einschlielich der aktualisierten Messrahmen
Einige grundlegende Strukturen, Konzepte und Terminologie bentigt Updates.

Bewertungsindikatoren bentigten Updates (insbesondere


Base Practices fr den HIS scope)

Seite 17
bersicht ber die wichtigsten nderungen (Dokumentansicht)

Kapitel Vernderung

Editorial Anpassung an 33000-Serie, Hinweise dazu kombiniert PRM / PAM in diesem Dokument
Kapitel 1 Einleitung

Kapitel 2 Entsprechenserklrung Anpassung an 33000 Serie

Kapitel 3 Einfhrung Optimiert fr ein besseres Verstndnis und zu 33000 Serie angepasst.

Das Akronym ENG zu SYS und SWE gendert hat sich die Struktur der Prozesse
Kapitel 4 Prozessreferenzmodell und
verndert, Base Practices des HIS Scope wurden berarbeitet.
Leistungsindikatoren (Stufe 1)

Kapitel 5 Prozessfhigkeitsniveaus und


Angepasst an die Mess Rahmen der ISO / IEC 33020
Prozessattribute

Anhang A Konformitt der


Konformittserklrung angepasst ISO / IEC 33004: 2015.
Prozessbewertung und Referenzmodell

Anhang B Arbeitsprodukteigenschaften nderungen auf der Arbeit Produkteigenschaften entsprechend den nderungen
in Kapitel 4.

Anhang C Terminologie Update auf die jngsten Normen, die Einfhrung neuer Terminologie

Hinzugefgt wird die neuen Hauptkonzepte relativ D von AS 2.5 Rckverfolgbarkeit


Anhang D Schlsselkonzepte
Diagramm zu Anhang (Anhang E PAM 2.5) ist jetzt in Anhang D

Anhang E Referenzstandards Aktualisiert Verweise auf andere Normen

Seite 18
bersicht ber die wichtigsten nderungen

Die neue Anhang D wurden erweitert, um eine Klrung der neuen Automotive SPICE Schlsselbegriffe
enthalten und ist ein guter Ausgangspunkt, um die Unterschiede zwischen V 3.0 und V 2.5, insbesondere in
Bezug auf Fhigkeitsgrad zu verstehen 1

Anhang D Key Koncepts

D.1 Die Plug-in Concept


D.2 Die Spitze des V
D.3 Begriffe Element, Component, Einheit und Item

D.4 Rckverfolgbarkeit und Konsistenz

D.5 Agree und Fasst und Kommunizieren


D.6 Auswerten, Verifizierungskriterien und Sicherstellung der Einhaltung

D.7 Die Beziehung zwischen Strategie und Plan

Seite 19
Strukturelle nderungen in Version 3.0: Plug-In-Konzept

SYS.1

System Level
SYS.2 SYS.5

SYS.3 SYS.4
MAN.3

SUP.10
ACQ.4

SUP.1

SUP.8

SUP.9
HWE.1 HWE.4 MEE.1 MEE.4
SWE.1 SWE.6

Domain-Ebene
HWE.2 HWE.3 MEE.2 MEE.3
SWE.2 SWE.5

SWE.3 SWE.4

SYS System Entwicklung


SWE Softwareentwicklung
Bestandteil der Kraftfahrzeug SPICE 3.0 PAM
HWE Hardware Engineering
MEE Maschinenbau nicht nach VDA entwickelt, nicht in Automotive SPICE 3.0 PAM enthalten
Seite 20
Strukturelle nderungen in Version 3.0: Die Spitze des V

SYS.2 SYS.5
System-Anforderungsanalyse System Qualification Test

SYS.4
SYS.3
Systemintegration und
System Architectural Design
Integrationstest

SWE.1 SWE.6
SW-Anforderungsanalyse SW Qualification Test

SWE.5
SWE.2
SW-Integration und
SW Architectural Design
Integrationstest

SWE.3
SWE.4
SW Detailkonstruktion und
SW-Einheit Verification
Blockbauweise

Seite 21
Begriffe Element, Component, Einheit und Item
System Engineering Process Group (SYS)

SYS.1
Anforderungserhebung

SYS.2
SYS.5
System Anforderungen
System Qualification Test
Analyse

SYS.4
SYS.3
Systemintegration und
System Architectural Design
Integrationstest

Software Engineering Process Group (SWE) Artikel


Elemente SWE.1 SWE.6
Software Anforderungen
Software Qualification Test
Analyse

SWE.2 SWE.5
Software Architectural Software-Integration und
Komponenten Entwurf Integrationstest

SWE.3 SWE.4
Einheiten Software Detailkonstruktion und
Software Einzelprfung
Einheiten
Blockbauweise

Eine Systemarchitektur spezifiziert die Elemente vom System.


Eine Software-Architektur spezifiziert die Elemente die Software.
Software Elemente sind hierarchisch in kleinere zerlegt Elemente bis auf die Software-Komponenten die auf der
untersten Ebene der Softwarearchitektur ist.
Software-Komponenten sind bei der detaillierten Ausgestaltung beschrieben.

Eine Software Komponente besteht aus einem oder mehreren Software Einheiten.

Artikel auf der rechten Seite des V-Modells sind die Gegenstcke realisiert Elemente und
Komponenten auf der linken Seite. 1 oder m:: Dies kann ein 1 n-Beziehung, zB eine Artikel kann ber mehr als ein
realisiert Element.
Seite 22
Rckverfolgbarkeit und Konsistenz

Rckverfolgbarkeit und Konsistenz wurden frher von einer einzigen Basis Praxis auf der rechten Seite
des V angesprochen und haben nun in zwei Basen Praktiken aufgeteilt.

Die Rckverfolgbarkeit bezieht sich auf das Vorhandensein von Referenzen oder Links zwischen

Arbeitsprodukten. Rckverfolgbarkeit untersttzt Abdeckungsanalyse, Wirkungsanalyse, Anforderungen

Umsetzung Statusverfolgung usw.

Konsistenz bedeutet, dass


Alle Rckverfolgbarkeit Referenzen / Links verfgbar sind (dh nichts fehlt)
Alle Rckverfolgbarkeit Referenzen / Links korrekt sind (dh nicht an den falschen Arbeitsprodukt zum Verlinken)

Konsistenz durch technische berprfung der Rckverfolgbarkeit nachgewiesen werden

Neue Anforderungen an die Rckverfolgbarkeit wurden hinzugefgt:

Zwischen Testflle und Testergebnisse


Zwischen nderungsanforderungen und Arbeitsergebnisse von diesen nderungsanforderungen (SUP.10) betroffen

Seite 23
Rckverfolgbarkeit und Konsistenz
bidirektionale Nachverfolgbarkeit
Stakeholder-Anforderungen
Konsistenz

SYS.2 BP7 System-Qualifikation


SYS.2 BP8 Prfvorschrift
SYS.5 BP5
SYS.5 BP5
System SYS.5 BP6 System-Qualifikation
Testflle
Anforderungen Testergebnisse

SYS.3 BP6 Systemintegration


SYS.3 BP7 Testspezifikation
SYS.4 BP7
SYS.4 BP7
Systemarchitektur SYS.4 BP8 System Integration
Testflle
Testergebnisse

SWE.1 BP7
Software Qualifikation
SWE.1 BP8 SWE.6 BP5
SWE.1 BP7 Prfvorschrift
SWE.6 BP5
SWE.1 BP8 SWE.6 BP6 Qualifikation
Testflle
Testergebnisse

SWE.2 BP7
Software-Integration
SWE.2 BP8
SWE.5 BP7 Testspezifikation
Software-Anforderungen SWE.5 BP7
SWE.5 BP8
SWE.3 BP5 Testflle
Software-Architektur Tester Software
SWE.3 BP6
SWE.3 BP5 Software Integration
detailliertes Design
SWE.3 BP6
SWE.3 BP5 SWE.4 BP5
SWE.4 BP6 SWE.4 BP5
SWE.3 BP6 Software Unit-Test-Spezifikation Unit-Test-Ergebnisse

SWE.4 BP5
Software-Einheiten statische varification
Ergebnisse

Um betroffene Arbeitsprodukte
nderungsanforderung
SUP.10 BP8
Seite 24
Agree und Fasst und Kommunizieren

BP: communicate vereinbart ... BP: zusammenzufassen und kommunizieren ...

SYS.2 SYS.5
System-Anforderungsanalyse System Qualification Test

SYS.4
SYS.3
Systemintegration und
System Architectural Design
Integrationstest

SWE.1 SWE.6
SW-Anforderungsanalyse SW Qualification Test

SWE.5
SWE.2
SW-Integration und
SW Architectural Design
Integrationstest

SWE.3
SWE.4
SW Detailkonstruktion und
SW-Einheit Verification
Blockbauweise

Der Informationsfluss auf der linken Seite des V wird durch eine Basis Praxis gewhrleistet Communicate
vereinbartenArbeitsprodukt x. Der Begriff vereinbarte bedeutet, dass es ein gemeinsames Verstndnis aller Beteiligten ist
es, den Inhalt des Arbeitsergebnisse in Bezug auf.

Der Informationsfluss auf der rechten Seite des V durch eine Basis der Praxis gewhrleistet, zusammenfassen und
kommunizieren Ergebnisse. Der Begriff Fasst bezieht sich auf abstrahierte Informationen aus Testausfhrungen auf
alle relevanten Parteien zur Verfgung gestellt.

Seite 25
Auswerten, Verifizierungskriterien und Sicherstellung der Einhaltung

SYS.2.BP5: Prfkriterien
SYS.2 SYS.5
System-Anforderungsanalyse System Qualification Test
SYS.5.BP2: Einhaltung

berprfung
SUP.2
SYS.4
SYS.3
Systemintegration und
System Architectural Design SYS.3.BP3: Einhaltung
Integrationstest

SWE.1.BP5: Prfkriterien
SWE.1 SWE.6
SW-Anforderungsanalyse SW Qualification Test
SWE.6.BP2: Einhaltung

SWE.5
SWE.2 SWE.5.BP3:
SW-Integration und
SW Architectural Design Einhaltung
Integrationstest

SWE.3
SWE.4
SW Detailkonstruktion und
SW-Einheit Verification
Blockbauweise

SWE.3.BP4: Bewerten SWE.4.BP2: Kriterien fr die Einzelprfung


Seite 26
Auswerten, Verifizierungskriterien und Sicherstellung der Einhaltung

Prfkriterien werden als Input fr die Entwicklung der Testflle oder anderer Kontrollmanahmen
verwendet werden, die die Einhaltung der Anforderungen gewhrleistet. Prfkriterien sind nur im Rahmen
der System-Anforderungsanalyse (SYS.2) und Software-Anforderungen Analyse (SWE.1) Verfahren
verwendet. Verification Aspekte, die nicht durch Tests abgedeckt werden durch den berprfungsprozess
(SUP.2) abgedeckt ist.

Kriterien fr die Einzelprfung die Einhaltung des Quellcodes mit der Software detaillierte Design und die
nicht-funktionalen Anforderungen. Mgliche Kriterien fr die Einzelprfung umfassen Einheit Testflle, Einheit
Testdaten, Berichterstattung Ziele und Coding-Standards und Code-Richtlinien, zB MISRA. Fr Unit-Tests, so
werden diese Kriterien in einer Einheit Testspezifikation definiert werden. Diese Einheit Testspezifikation kann als
ein Skript in einem automatisierten Prfstand implementiert zB werden.

Seite 27
Auswerten, Verifizierungskriterien und Sicherstellung der Einhaltung

Bewertung alternativer Lsungen ist fr die System- und Softwarearchitekturen erforderlich. Die Bewertung der
Merkmale erfolgt nach definierten Kriterien. Solche Bewertungskriterien knnen Qualittsmerkmale wie Modularitt,
Zuverlssigkeit, Sicherheit und Benutzerfreundlichkeit oder Ergebnisse von Make-or-buy oder Wiederverwendung
Analyse. Das Bewertungsergebnis einschlielich einer Begrndung fr die Architektur / Design Auswahl hat
aufgezeichnet werden.

Die Einhaltung einer architektonischen Gestaltung (SWE.5.BP3) bedeutet, dass die festgelegten
Integrationstests beweisen Lage sind, die Schnittstellen und die relevanten Wechselwirkungen, wie zB dynamische
Verhalten zwischen
- die Software-Einheiten,

- die Software-Produkte und


- die Systemelemente
erfllt die Spezifikation, die von der architektonischen Gestaltung gegeben.

Seite 28
Neue Praxis im System Architectural Design: Auswerten alternative
Systemarchitekturen

SYS.3.BP5: alternative Systemarchitekturen auswerten. Definieren Bewertungskriterien fr


Architektur-Design. Bewerten Sie alternative Systemarchitekturen gem den definierten Kriterien.
Notieren Sie die Grnde fr die gewhlte Systemarchitektur. [Ergebnis 1]

ANMERKUNG 3: Bewertungskriterien knnen Qualittsmerkmale (Modularitt, Wartbarkeit, Erweiterbarkeit,


Skalierbarkeit, Zuverlssigkeit, Sicherheit und Benutzerfreundlichkeit) und die Ergebnisse der
Make-buy-Wiederverwendung-Analyse.

Seite 29
Die Beziehung zwischen Strategie und Plan

Planen

BP 1 definiert die Strategie ...


WP 08-00

BP1: Entwicklung CL> = 2

Strategie CL = 1 Generisches Plan

Prozess spezifischer Plan


WP 08-nn
Die in der dokumentierten
verwandte WP

Beide Begriffe Strategie und Plan werden ber folgende Prozesse der Automotive SPICE 3.0 PAM hufig verwendet:

SYS.4 Systemintegration und Integrationstest


SYS.5 System-Eignungstest
SWE.4 Software Einzelprfung
SWE.5 Software Integration und Integrationstest
SWE.6 Software Qualification Test
SUP.1 Qualittssicherung
SUP.8 Configuration Management
SUP.9 Problem Resolution-Management
SUP.10 Change Request Management
Seite 30
Die Beziehung zwischen Strategie und Plan

Fhigkeitsgrad 1:
Jeder dieser Prozesse erfordert die Entwicklung eines prozessspezifischen Strategie. Die Strategie
entspricht immer einen prozessspezifischen Plan. Fr jeden Prozess-spezifischen Plan gibt es
prozessspezifische Arbeit Produkteigenschaften definiert (zB 08-52 Testplan, 08-04 Configuration
Management Plan). Planen wie zB alte SUP.10 BP10 wurde auf Ebene 2 verschoben

Fhigkeit der Stufe 2 oder hher:

Jeder Prozess-spezifische Plan (WP 08-nn) erbt die Eigenschaften Arbeitsergebnisse durch den
Generisches Plan dargestellt (WP 08-00). Dies bedeutet, dass fr einen prozessspezifische Plan sowohl
die prozessspezifischen Eigenschaften (WP 08NN) und die allgemeinen Merkmale (WP 08-00) gilt.

BPs fr Verfahren gelscht wurden.

Seite 31
Keine Trennung von PAM und PRM in v3.0

Farbcode fr verschiedene Elemente


Rot fr PRM Elemente (Prozess-ID, Name, Zweck und Ergebnisse)
Grn fr Basispraktiken und generische Praktiken
Blau fr die Ausgabe Arbeitsprodukte und Generika Ressourcen

Kursiv fr Inhalte von ISO 330xx (zB Messrahmen)

Seite 32
Bewertungsskala gem ISO / IEC 33020

Rating Rationale

N Nicht erreicht Es gibt wenig oder keine Beweise fr die Erreichung der vorgegebenen
Prozess Attribut im Prozess beurteilt.
P teil~~POS=TRUNC erreicht Es gibt einige Hinweise eines Ansatzes zu, und einige Erreichung der
definierten Prozess-Attribut im veranlagten Prozess. Einige Aspekte der Leistung des Prozess
Attributs knnen unberechenbar sein.

L weitgehend erreicht Es gibt Hinweise auf einen systematischen Ansatz, und bedeutende Leistung von der
definierte Prozess-Attribut im beurteilt Prozess. Einige Schwchen im Zusammenhang mit diesem Prozess
Attribut knnen im betrachteten Verfahren existieren.

F voll erreicht Es gibt Anzeichen fr eine vollstndige und systematische Vorgehensweise


zu, und volle Verwirklichung des definierte Prozess-Attribut im beurteilt Prozess. Keine signifikanten Schwchen
dieses Prozesses Attribut im Zusammenhang gibt es in der veranlagten Prozess.

Seite 33
Optional Rating Scale

Rating Rationale

P- Teilweise erreicht: Es gibt einige Hinweise eines Ansatzes zu, und einige Erreichung der
definierten Prozess-Attribut im veranlagten Prozess. Viele
Aspekte der Leistung des Prozess Attributs knnen unberechenbar sein.

P+ Teilweise erreicht: Es gibt einige Hinweise eines Ansatzes zu, und einige Erreichung der
definierten Prozess-Attribut im veranlagten Prozess. Einige Aspekte der Leistung des Prozess
Attributs knnen unberechenbar sein.

L- Weitgehend erreicht: Es gibt Hinweise auf einen systematischen Ansatz, und bedeutende Leistung von
der definierte Prozess-Attribut im beurteilt Prozess. Viele Schwchen dieses Prozesses Attribut im
Zusammenhang kann im betrachteten Verfahren existieren.

L+ Weitgehend erreicht: Es gibt Hinweise auf einen systematischen Ansatz, und bedeutende Leistung von der
definierte Prozess-Attribut im beurteilt Prozess. Einige Schwchen im Zusammenhang mit diesem Prozess
Attribut knnen im betrachteten Verfahren existieren.

Seite 34
Erweiterte Bewertungsschema - Prozent

Rating Prozent

P- > 15% bis 32,5%

P+ > 32,5% bis 50%

L- > 50% bis 67,5%

L+ > 67,5% bis 85%

AK13 hat nicht entschieden, ob es wird ein Teil der sein


Richtlinien oder auerhalb des Geltungsbereichs

Seite 35
Methoden Bewertung und Aggregation

ISO / IEC 33020 identifiziert 3 Bewertungsverfahren R1, R2 und R3 und unterschiedliche

Aggregationsverfahren

Aggregation innerhalb eines Prozesses (eindimensionale vertikale Aggregation)


ber mehrere Prozessinstanzen (eindimensional, horizontal Aggregation)
Beide (zweidimensionale Matrix Aggregation)
Sie werden in der Regel fr die Bewertungen Organizational Maturity verwendet

AK13 hat nicht entschieden, ob es Teil der Leitlinien sein wird oder sich auerhalb des Geltungsbereichs

Im Automotive SPICE V 3.0 die Ratingverfahren werden nur kurz erlutert und die Anstze
verwiesen

Seite 36
Beispiel fr ein Bewertungsverfahren

Rating-Verfahren R1 (der die strksten Anforderungen):


Der Ansatz Attribut Bewertung verarbeiten mssen folgende Bedingungen erfllen:
a) Jeder Prozess Ergebnis jedes Verfahrens im Rahmen der Beurteilung wird fr jede
Prozessinstanz charakterisiert werden, basierend auf validierten Daten;
b) Jeder Prozess Attribut Ergebnis jeden Prozess Attribut fr jeden Prozess in dem Rahmen der
Beurteilung wird fr jede Prozessinstanz charakterisiert werden, basierend auf validierten Daten;

c) Prozess Ergebnis Charakterisierungen fr alle bewerteten Prozessinstanzen werden aggregiert werden, um eine
Prozess-Performance-Attribut Leistung Bewertung zur Verfgung zu stellen;

d) Prozess Attribut Ergebnis Charakterisierungen fr alle bewerteten Prozessinstanzen werden


aggregiert werden ein Prozess Attributbewertung Leistung zu liefern.

Seite 37
Horizontale Aggregation

Prozessinstanzen Horizontale
<---> Aggregation
Inst. 1 Inst. 2 Inst. 3 Inst. 4 Inst. 5 Inst. 6

GP 3.2.1 P P N P P L P
Horizontal

GP 3.2.2 P L L L F L L
Bewertung der Indikatoren

GP 3.2.3 L L L L L L L
<--->

gp 3.2.4 F F F F F L F

GP 3.2.5 L L P P L L L
Horizontal

GP 3.2.6 P L P P N L P

Seite 38
Seite 38
Vertikale Aggregation

Bewertung pro Prozessinstanz


<--->
Inst. 1 Inst. 2 Inst. 3 Inst. 4 Inst. 5 Inst. 6

GP 3.2.1 P P N P P L

GP 3.2.2 P L L L F L
Bewertung der Indikkatoren

GP 3.2.3 L L L L L L
<--->

GP 3.2.4 F F F F F L

GP 3.2.5 L L P P L L

GP 3.2.6 P L P P N L

Vertikale
P L P L P L
Aggregation

Vertikale Aggregation Vertikale Aggregation

Seite 39
Seite 39
nderungen im Detail

Seite 40
Allgemeine nderungen in V3.0

Siehe Schlsselkonzepte (iV Dias)


In den Testverfahren (SYS.4, SYS.5, SWE.5, SWE.6) haben Testflle auf der Grundlage der Teststrategie des
jeweiligen Prfschritt ausgewhlt werden.

Die Entfernung der Stufe 2 Aktivitten von BPs

Planung und berwachung Aktivitten wurden von BPs (zB SUP-Verfahren) entfernt

Bewertungen ber Konsistenzprfungen wurden von BPs entfernt (zB SWE.2-4)

Seite 41
MAN.3 Projektmanagement - Outcomes

Outcomes V2.5 Outcomes V3.0

Als Ergebnis einer erfolgreichen Umsetzung dieses Prozesses Als Ergebnis einer erfolgreichen Umsetzung dieses Prozesses

1 der Umfang der Arbeiten fr das Projekt definiert ist; 1 der Umfang der Arbeiten fr das Projekt definiert ist;

2 die Durchfhrbarkeit der Ziele des Projekts mit den verfgbaren Ressourcen zu 2 die Durchfhrbarkeit der Ziele des Projekts mit den verfgbaren Ressourcen zu
erzielen und Einschrnkungen ausgewertet; erzielen und Einschrnkungen ausgewertet;

3 die Aufgaben und Ressourcen notwendig, um die Arbeit abzuschlieen sind so 3 das Aktivitten und Ressourcen notwendig, um die Arbeit abzuschlieen sind so
bemessen und geschtzt; bemessen und geschtzt;

4 Schnittstellen zwischen den Elementen in dem Projekt und mit anderem Projekt und 4 Schnittstellen im Rahmen des Projekts Und mit anderen Projekten und
Organisationseinheiten, werden identifiziert und berwacht werden; Organisationseinheiten, werden identifiziert und berwacht werden;

5 Plne fr die Durchfhrung des Projekts entwickelt werden, 5 Plne fr die Durchfhrung des Projekts entwickelt werden,
umgesetzt und aufrechterhalten; umgesetzt und aufrechterhalten;

6 Fortschritt des Projekts wird berwacht und gemeldet; und 6 Fortschritt des Projekts wird berwacht und gemeldet; und

7 Aktionen Abweichungen vom Plan zu korrigieren und 7 Abhilfemanahmen getroffen werden, wenn die Projektziele nicht sind
eine Wiederholung zu vermeiden Probleme im Projekt identifiziert werden genommen, erreicht, und ein erneutes Auftreten der in dem Projekt identifizierten Probleme
wenn die Projektziele nicht erreicht werden. verhindert.

Hauptschlich Umformulierung aber keine neuen Inhalte

Seite 42
MAN.3 Projektmanagement - Base Practices

Base Practices V2.5 Base Practices V3.0

1 Definieren Sie den Umfang der Arbeiten. 1 Definieren Sie den Umfang der Arbeiten.

2 Definieren Sie Projektlebenszyklus 2 Definieren Sie Projektlebenszyklus

3 Bestimmen Sie und halten Schtzungen fr Projekt 3 Bewerten Sie Machbarkeit des Projekts
Attribute
4 definieren, berwachung und Anpassung Projektaktivitten
4 Definieren Sie Projektaktivitten

5 Definieren Qualifikationsbedarf 5 Bestimmen Sie, berwachen und anpassen Projekt-Schtzungen und


Ressourcen

6 definieren und Projektzeitplan pflegen


6 Stellen Sie sicher, erforderlich Fhigkeiten, Wissen und Erfahrung

7 Identifizierung und berwachung von Projektschnittstellen

7 Identifizieren, berwachen und justieren Projektschnittstellen und vereinbarten

8 Stellen Projektplan Verpflichtungen

8 definieren, berwachung und Anpassung Projektplan


9 Umsetzung des Projektplans

10 Monitor-Projektattribute 9 Sicherstellung der Konsistenz

11 berprfung und Bericht ber die Fortschritte des Projekts 10 berprfung und Berichterstattung Fortschritt des Projektes

12 Gesetz Abweichungen zu korrigieren

Link zu 3, 4, 5, 6, 7, 10

Seite
43 43
nderungen in V3.0 - MAN.3 Projektmanagement

Ausarbeitung und Durchfhrung eines Projektplan wurde gelscht, da sie Verwirrung in der Vergangenheit verursacht

Stattdessen werden alle Aspekte der Planung werden mssen identifiziert, berwacht und angepasst (Schtzungen,

Aktivitten, Termine, Plne, Schnittstellen und Verpflichtungen)

Quer durch alle Artefakte Konsistenz (spezifische BP) festzulegenden - keine Rckverfolgbarkeit, nur Konsistenz

Arbeitsumfang verwendet berprfung der Machbarkeit enthalten. In 3.0 fr Machbarkeit einer spezifischen BP eingefhrt

Der Projektplan 08-12 ist noch ein Ausgabearbeitsprodukt von MAN.3. berprfen Sie Anhang B, aber die Verweise auf
das Risikomanagement wurden entfernt. Allerdings werden die Risiken in BP5 erwhnt und man.5 in dem entsprechenden
Hinweis verwiesen 6

Seite
44 44
SUP.1 Qualittssicherung - Outcomes

Outcomes V2.5 Outcomes V3.0

Als Ergebnis einer erfolgreichen Umsetzung dieses Prozesses Als Ergebnis einer erfolgreichen Umsetzung dieses Prozesses

1 eine Strategie der Qualittssicherung fr die Durchfhrung ist 1 eine Strategie zur Durchfhrung einer Qualittssicherung
entwickelt, implementiert und aufrechterhalten wird; entwickelt, implementiert und gewartet werden;

2 Qualittssicherung ist unabhngig von der durchgefhrt 2 Qualittssicherung wird durchgefhrt, unabhngig und
Aktivitt oder ein Projekt durchgefhrt wird; objektiv ohne Interessenkonflikte;

3 Nachweis der Qualittssicherung erzeugt wird und 3 Nichteinhaltungen von Arbeitsergebnissen, Prozesse und
gehalten wird; Prozessaktivitten mit entsprechenden Anforderungen
identifiziert, erfasst, an die betreffenden Parteien mitgeteilt,
4 Einhaltung von Produkten, Prozessen und Aktivitten
verfolgt, gelst, und weiter verhindert;
vereinbarte Anforderungen werden berprft, dokumentiert und an die
zustndigen Stellen bermitteln; 4 Konformitt der Arbeits Produkte, Verfahren und
Aktivitten mit den entsprechenden Anforderungen berprft,
5 Probleme und / oder Nicht-Konformitt mit Vertrag
dokumentiert und an die zustndigen Stellen bermittelt;
Anforderungen identifiziert, erfasst, an die betreffenden Parteien
mitgeteilt, verfolgt und gelst; und
5 Autoritt nicht-Abweichungen zu eskalieren aneignen
6 Qualittssicherung hat die Unabhngigkeit und Autoritt
Managementebene geschaffen wird; und
Probleme, geeignete Managementebene zu eskalieren.
6 Management sorgt dafr, dass eskaliert nicht
Abweichungen werden aufgelst.

Der Schwerpunkt liegt mehr auf Konformitt berprft und die Gewhrleistung Auflsung von Abweichungen

Seite
45 45
SUP.1 Qualittssicherung - Base Practices

Base Practices V2.5

1 Entwickeln Projekt Qualittssicherungsstrategie

2 Entwicklung und Aufrechterhaltung einer Organisationsstruktur


dadurch wird gewhrleistet, dass die Qualittssicherung durchgefhrt und Base Practices V3.0
berichtet Independentely
1 Entwickeln Projekt Qualittssicherungsstrategie
3 Entwickeln und einen Plan fr die Projektqualitt implementieren
Sicherung basiert auf einer Qualittssicherungsstrategie
2 Assure Qualitt der Arbeitsergebnisse

4 Pflegen Nachweis der Qualittssicherung


3 Assure Qualitt der Prozessaktivitten
5 Assure Qualitt der Arbeitsergebnisse
4 Fassen Sie zusammen und kommunizieren Qualittssicherung
Aktivitten und Ergebnisse
6 Assure Qualitt der Prozessaktivitten
5 Sicherstellen Auflsung von Abweichungen
7 Track Record und Qualittssicherung
6 Implementieren eines Eskalationsmechanismus
8 Bericht Qualittssicherung und Ergebnisse

9 Sicherstellen Auflsung auf nicht Einhaltungen

10 Implementieren eines Eskalationsmechanismus

Seite
46 46
nderungen in V3.0 - SUP.1 Qualittssicherung

Insgesamt vereinfacht den Prozess mit hnlichem Inhalt

Obendrein Unabhngigkeit in QA Objektivitt ist nicht erforderlich.

Es wird klargestellt, dass Eskalation muss die Aufmerksamkeit des Managements und Aktionen fhren.

Seite
47 47
SUP.8 Configuration Management - Outcomes

Outcomes V2.5 Outcomes V3.0

Als Ergebnis einer erfolgreichen Umsetzung dieses Prozesses Als Ergebnis einer erfolgreichen Umsetzung dieses Prozesses

1 eine Konfigurationsmanagement-Strategie entwickelt wird; 1 eine Konfigurationsmanagement-Strategie entwickelt wird;

2 alle Einzelteile durch einen Prozess oder ein Projekt erzeugt werden, 2 alle Konfiguration Artikel nach einem Verfahren erzeugt wird, oder
nach der Configuration Management-Strategie identifiziert, Projekt identifiziert, definiert und Baseline entsprechend der
definiert und mit Baseline; Konfigurationsmanagement-Strategie;

3 Modifikationen und Versionen der Elemente sind gesteuert wird; 3 Modifikationen und Versionen des Konfiguration Artikel
sind gesteuert wird;

4 nderungen und Freigaben zur Verfgung gestellt werden


4 nderungen und Freigaben zur Verfgung gestellt werden
betroffene Parteien;
betroffene Parteien;

5 der Status der Elemente und nderungswnsche werden erfasst


5 der Status der Konfiguration Artikel und Modifikation s
und gehen;
wird aufgezeichnet und berichtet;

6 die Vollstndigkeit und Konsistenz der Produkte gewhrleistet ist;


und
6 die Vollstndigkeit und Konsistenz der Basislinien gewhrleistet ist; und

7 Lagerung, Handhabung und Lieferung der Gegenstnde sind


7 Speicherung der Konfigurations Artikel gesteuert wird.
gesteuert.

Einige Umformulierung aber im Grunde haben die Ergebnisse nicht gendert

Seite
48 48
SUP.8 Configuration Management - Base Practices

Base Practices V2.5 Base Practices V3.0

1 Entwickeln Sie eine Konfigurations-Management-Strategie 1 Entwickeln Sie eine Konfigurations-Management-Strategie

2 Identifizieren Sie Konfigurationselemente 2 Identifizieren Sie Konfigurationselemente

3 Richten Sie ein Konfigurationsmanagementsystem 3 Richten Sie ein Konfigurationsmanagementsystem

4 Stellen Zweig-Management-Strategie 4 Stellen Zweig-Management-Strategie

5 erkennen Grund 5 Steuer nderungen und Freigaben

6 Pflegen Konfigurationselement Beschreibung 6 erkennen Grund

7 Steuer nderungen und Freigaben 7 Report Konfigurationsstatus

8 pflegen Konfigurationselement Geschichte 8 berprfen der Informationen ber Objekte konfiguriert

9 Bericht Konfigurationsstatus 9 Verwalten der Speicherung von Konfigurationselementen und


Basislinien
10 berprfen der Informationen ber Objekte konfiguriert

11 Verwalten der Sicherung, Speicherung, Archivierung, Handhabung


und Lieferung von Konfigurationselementen

Seite
49 49
nderungen in V3.0 - SUP.8 Configuration Management

Insgesamt vereinfacht den Prozess mit hnlichem Inhalt

Keine neuen Inhalte

Seite
50 50
SUP.9 Problem Resolution-Management - Outcomes

Outcomes V2.5 Outcomes V3.0

Als Ergebnis einer erfolgreichen Umsetzung dieses Prozesses Als Ergebnis einer erfolgreichen Umsetzung dieses Prozesses

1 ein Problem-Management-Strategie entwickelt wird; 1 ein Problem Lsung Management-Strategie ist


entwickelt;
2 Probleme erfasst, identifiziert und klassifiziert;
2 Probleme aufgezeichnet werden, einmalig identifiziert und
klassifiziert;
3 Probleme werden analysiert und bewertet zu identifizieren
akzeptable Lsung (s); 3 Probleme werden analysiert und bewertet ein identifizieren
angemessen Lsung;
Problemlsung 4 implementiert ist;
4 Problemlsung eingeleitet wird;
5 Probleme werden zum Abschluss verfolgt; und
5 Probleme werden zum Abschluss verfolgt; und
6 der Status aller Problemberichte bekannt ist
6 der Status von Problemen und dessen Trend sind bekannt

Einige Umformulierung aber im Grunde haben die Ergebnisse nicht gendert

Seite
51 51
SUP.9 Problem Resolution-Management - Base Practices

Base Practices V2.5 Base Practices V3.0

1 Entwickeln Sie eine Problemlsung Management-Strategie 1 Entwickeln Sie eine Problemlsung Management-Strategie

2 Stellen Sie eine konsistente Problemlsung 2 Identifizieren und notieren Sie das Problem
Managementverfahren
3 Notieren Sie sich den Status von Problemen
3 Identifizieren und notieren Sie das Problem

4 Diagnostizieren der Ursache und bestimmen die Auswirkungen der


4 Untersuchen und die Ursache und die Auswirkungen des Problems
Problem
diagnostizieren

5 Autorisieren Dringlichkeitsentschlieung Aktion


5 Fhren Dringlichkeitsentschlieung Aktion, soweit erforderlich

6 Heben Alarmbenachrichtigungen
6 Heben Sie Warnmeldungen, soweit erforderlich

7 Einleiten Problemlsung
7 Initiieren nderungsanforderung

8 Track Probleme Verschluss


8 Track Probleme Verschluss

9 Analysieren Problem Trends


9 Analysieren Problem Trends

Seite
52 52
nderungen in V3.0 - SUP.9 Problem Resolution-Management

Nur geringfgige nderungen Terminologie in Bezug auf

Keine Notwendigkeit, eine nderungsanforderung zu starten mehr (haben jedoch zu Problemen Abschluss verfolgt und eine

nderungsanforderung initiieren knnte eine Option sein)

So auch keine planerischen Aspekte auf Ebene 1

Das Verfahren ist Teil der Strategie / Plan.

Seite
53 53
SUP.10 Change Request Management - Outcomes

Outcomes V2.5 Outcomes V3.0

Als Ergebnis einer erfolgreichen Umsetzung dieses Prozesses Als Ergebnis einer erfolgreichen Umsetzung dieses Prozesses

1 eine Change-Management-Strategie entwickelt wird; 1 eine nderungsanforderung Managementstrategie entwickelt wird;

2-Anforderungen fr nderungen werden aufgezeichnet und identifiziert; 2-Anforderungen fr nderungen werden aufgezeichnet und identifiziert;

3 Abhngigkeiten und Beziehungen zu anderen ndern 3 Abhngigkeiten und Beziehungen zu anderen ndern
Anfragen werden identifiziert; Anfragen werden identifiziert;

4 Kriterien fr die Durchfhrung der nderung besttigt 4 Kriterien fr die Durchfhrung der nderung besttigt
Anfrage definiert sind; anfordern s sind festgelegt;

5 nderungswnsche werden analysiert, priorisiert und 5 nderungswnsche werden analysiert , und Ressource
Ressourcenanforderungen geschtzt; Anforderungen werden geschtzt;

6 nderungen werden auf der Grundlage der Prioritt genehmigt und 6 nderungen genehmigt und priorisiert auf Basis von
Verfgbarkeit von Ressourcen; Analyseergebnisse und die Verfgbarkeit der Ressourcen;

7 genehmigten nderungen umgesetzt und verfolgt 7 genehmigten nderungen umgesetzt und verfolgt
Schlieung; und Schlieung;

8 der Status aller nderungsanforderungen bekannt ist 8 der Status aller nderungsanforderungen, ist bekannt; und

9 bidirektionale Rckverfolgbarkeit hergestellt wird zwischen


nderungswnsche und die betroffenen Arbeitsprodukte

Wesentliche nderung, dass die Rckverfolgbarkeit auf die betroffenen Arbeitsprodukte enthalten ist.

Abgesehen davon keine wesentlichen nderungen

Seite
54 54
SUP.10 Change Request Management - Base Practices

Base Practices V2.5

1 Entwickeln Sie einen Change Request Management-Strategie

2 Stellen Sie ein konsistentes nderungsmanagement Base Practices V3.0


Vorgehen

3 Identifizieren und die nderungsanforderung aufnehmen 1 Entwickeln Sie einen Change Request Management-Strategie

4 Notieren Sie sich den Status von nderungsanforderungen 2 Identifizieren und die nderungsanforderungen aufzeichnen

5 Stellen Sie die Abhngigkeiten und Beziehungen zu 3 Notieren Sie den Status von nderungsanforderungen

andere nderungswnsche
4 Analysieren und nderungsanforderungen beurteilen
6. Bewertung der Auswirkungen der nderung

5 genehmigen nderungsanforderungen vor der Umsetzung


7 Analysieren und nderungsanforderungen priorisieren

6 berprfen Sie die Umsetzung von Vernderungs Anfragen


8 genehmigen nderungsanforderungen vor der Umsetzung

7 Track nderungsanforderungen Verschluss


9 Identifizieren und plant, die Verifikation und Validierung wird fr
gefhrte nderungen durchgefhrt
8 Stellen Sie eine bidirektionale Rckverfolgbarkeit

10 vereinbaren, und ordnen Sie die nderungsanforderung

11 berprfen Sie die nderung umgesetzt Wurde auf Ebene 2 verschoben

12 nderungsanforderungen werden bis zum Abschluss verfolgt


New BP / Aspekt SUP.10
Seite
55 55
nderungen in V3.0 - SUP.10 Change Request Management

Es gibt zwei wesentliche nderungen:

Die Planungsaspekte (Planung und Planung der Verifikation und Validierung) werden auf Ebene 2 verschoben

Die Rckverfolgbarkeit zwischen nderungsanforderungen und die betroffenen Arbeits Produkte eingefhrt

Abgesehen davon gibt es keine nderungen mit Ausnahme der Formulierung.

Das Verfahren ist Teil der Strategie / Plan.

Seite
56 56
ACQ.4 Lieferant Monitoring - Outcomes

Outcomes V2.5 Outcomes V3.0

Als Ergebnis einer erfolgreichen Umsetzung dieses Prozesses Als Ergebnis einer erfolgreichen Umsetzung dieses Prozesses

1 gemeinsame Aktivitten zwischen dem Kunden und dem Lieferanten werden nach Bedarf 1 gemeinsame Aktivitten, wie vereinbart zwischen dem Kunden und dem Lieferanten
durchgefhrt werden; wird nach Bedarf durchgefhrt werden;

2 alle Informationen, vereinbart fr den Austausch auf, ist 2 alle Informationen, vereinbart fr den Austausch auf, ist
zwischen dem Lieferanten und dem Kunden bergeben; regelmig zwischen dem Lieferanten und Kunden mitgeteilt ;

3 Informationen ber die Fortschritte regelmig mit dem Lieferanten ausgetauscht


werden; 3 Leistung des Lieferanten gegen die berwachte
Vereinbarungen ; und
4 Leistung des Lieferanten gegen die berwachte
vereinbarte Anforderungen; und 4 nderungen an der Vereinbarung, falls erforderlich, verhandelt
zwischen dem Kunden und dem Lieferanten und in der
5 nderungen an der Vereinbarung, falls erforderlich, verhandelt
Vereinbarung dokumentiert
zwischen dem Kunden und dem Lieferanten und mit der
Vereinbarung dokumentiert

Einige Umformulierung aber im Grunde haben die Ergebnisse nicht gendert

Seite
57 57
ACQ.4 Lieferant Monitoring - Base Practices

Base Practices V2.5 Base Practices V3.0

1 vereinbaren gemeinsame Prozesse und gemeinsame Schnittstellen 1 vereinbar und pflegen gemeinsame Prozesse

2 alle einschlgigen Informationen 2 Austausch all vereinbart Information

3 Bewertung der technische Entwicklung mit dem Lieferanten 3 Bewertung der technische Entwicklung mit dem Lieferanten

4 berprfung Fortschritt des Anbieters 4 berprfung Fortschritt des Anbieters

5 Track offene Posten 5 Gesetz zu korrigieren Abweichungen

6 Gesetz zu korrigieren Abweichungen

7 vereinbaren nderungen

Verbunden mit 1, 3, 4 und 5

Seite
58 58
ACQ.4 Lieferant Monitoring - Base Practices

Base Practices V2.5 Base Practices V3.0

1 vereinbaren gemeinsame Prozesse und gemeinsame Schnittstellen 1 vereinbar und pflegen gemeinsame Prozesse

2 alle einschlgigen Informationen 2 Austausch all vereinbart Information

3 Bewertung der technische Entwicklung mit dem Lieferanten 3 Bewertung der technische Entwicklung mit dem Lieferanten

4 berprfung Fortschritt des Anbieters 4 berprfung Fortschritt des Anbieters

5 Track offene Posten 5 Gesetz zu korrigieren Abweichungen

6 Gesetz zu korrigieren Abweichungen

7 vereinbaren nderungen

Verbunden mit 1, 3, 4 und 5

Seite
59 59
nderungen in V3.0 - ACQ.4 Lieferantenberwachung

Keine groen Vernderungen, aber der Ansatz wurde vereinfacht

Seite
60 60
Gruppenarbeit / Diskussion

Diskutieren Sie in kleinen Arbeitsgruppen und dokumentieren die Ergebnisse auf einer Flip-Chart:

Was sind die wichtigsten nderungen? (zusammenfassen)

Wo sehen Barrieren in Ihrem Prozess zu ASPICE 3.0 complaince zu ndern?


Wie schtzen Sie die investieren (hhere / same / weniger)? Warum ?
Was werden die Auswirkungen von Assessments sein (man stelle sich: jetzt basierend auf 3,0 statt 2.X)?

Seite 61
Anforderungsanalyse SYS.2 System - Outcomes

Ergebnisse V2.5 - ENG.2 Outcomes V3.0

Als Ergebnis einer erfolgreichen Umsetzung dieses Prozesses Als Ergebnis einer erfolgreichen Umsetzung dieses Prozesses

1 ein definierter Satz von Systemanforderungen wird hergestellt; 1 ein definierter Satz von Systemanforderungen wird hergestellt;

2 Systemanforderungen kategorisiert und analysiert fr 2 Systemanforderungen kategorisiert und analysiert fr


Korrektheit und Testbarkeit; Korrektheit und berprfbarkeit ;

3 die Auswirkungen der Systemanforderungen an die 3 die Auswirkungen der Systemanforderungen an die Betriebsumgebung
Betriebsumgebung ausgewertet; ist analysiert ;

4-Priorisierung fr die Systemanforderungen der Umsetzung 4-Priorisierung fr die Systemanforderungen der Umsetzung
ist definiert; ist definiert;

5 die Systemanforderungen sind je nach Bedarf geprft und aktualisiert werden; 5 die Systemanforderungen werden nach Bedarf aktualisiert werden;

6 Konsistenz und bidirektionale Rckverfolgbarkeit


6 Konsistenz und Traceability sind etabliert
die zwischen Interessengruppen Anforderungen und
zwischen Kundenanforderungen und
Systemanforderungen;
Systemanforderungen;
7 die Stakeholder Anforderungen sind fr die Kosten, Zeitplan und technische
7 nderungen an den Grundanforderungen des Kunden sind
Auswirkungen bewertet; und
fr Kosten, Zeitplan und technische Auswirkungen bewertet; und

die Systemanforderungen an alle betroffenen Parteien 8 die Systemanforderungen vereinbart und an alle
8
betroffenen Parteien mitgeteilt
mitgeteilt und Baseline

Einige Umformulierung aber im Grunde haben die Ergebnisse nicht gendert

Seite
62 62
SYS.2 System-Anforderungsanalyse - Base Practices

Base Practices V2.5 - ENG.2 Base Practices V3.0

1 Identifizieren Systemvoraussetzungen 1 Angeben System Anforderungen

2 Analyse Systemanforderungen 2 Struktur System Anforderungen

3 Ermitteln der Auswirkung auf die Betriebsumgebung 3 Analysieren Systemanforderungen

4 priorisieren und kategorisieren Systemvoraussetzungen 4 Analysieren die Auswirkungen auf die Betriebssystemumgebung

5 auswerten und Systemanforderungen aktualisieren 5 Entwickeln Prfkriterien

6 Stellen Sie sicher, Konsistenz und Traceability von 6 Stellen Sie eine bidirektionale Rckverfolgbarkeit
Kundenanforderungen an Systemanforderungen
7 Sicherstellung der Konsistenz
7 Kommunizieren Systemanforderungen

8 Kommunizieren Sie vereinbarten Systemanforderungen

Verknpft mit 1-8

Seite
63 63
nderungen in V3.0 - SYS.2 System-Anforderungsanalyse

Rckverfolgbarkeit und Konsistenz getrennt sind (siehe Schlsselbegriffe)

Prfkriterien erforderlich explizit in BP5


Anders als das hauptschlich Umformulierung

Seite
64 64
SYS.3 Systems Architectural Design - Outcomes

Ergebnisse V2.5 - ENG.3 Outcomes V3.0

Als Ergebnis einer erfolgreichen Umsetzung dieses Prozesses Als Ergebnis einer erfolgreichen Umsetzung dieses Prozesses

1 eine Systemarchitektur ist so definiert, dass identifiziert 1 eine Systemarchitektur ist so definiert, dass identifiziert
die Elemente des Systems und erfllt die Anforderungen definiert die Elemente des Systems;
Systeme;
2 die Systemanforderungen sind an die Elemente des Systems zugeordnet sind;
2 die Systemanforderungen sind an die Elemente des Systems zugeordnet sind;

3 Die Schnittstellen der einzelnen Systemelement definiert sind;

3 interne und externe Schnittstellen jedes Systemelement


definiert sind; 4 Das dynamische Verhalten Ziele der Systemelemente
definiert sind;
4 berprfung zwischen den Systemanforderungen und der
Systemarchitektur durchgefhrt wird; 5 Konsistenz und bidirektionale Rckverfolgbarkeit
zwischen Systemanforderungen und Systemarchitektur etabliert; und
5 Konsistenz und Traceability sind etabliert
zwischen Systemanforderungen und
Systemarchitektur; und 6 die Systemarchitektur wird an alle betroffenen Parteien
vereinbart und mitgeteilt
6 die Systemanforderungen, die Systemarchitektur und ihre
Beziehungen als Baseline und an alle betroffenen Parteien
mitgeteilt. New Aspekt der Systemarchitektur

Neuer Aspekt mit dynamischem Verhalten, aber abgesehen, dass die Ergebnisse im Wesentlichen nicht gendert haben

Seite
65 65
SYS.3 Systems Architectural Design - Base Practices

Base Practices V2.5 - ENG.3 Base Practices V3.0

1 Definieren der Systemarchitektur 1 Entwickeln Systemarchitektur

2 Ordnen Systemvoraussetzungen 2 Ordnen Sie die Systemanforderungen

3 definieren Interfaces 3 definieren Schnittstellen von Systemelementen

4 Entwickeln Verifikationskriterien 4 Beschreiben Sie das dynamische Verhalten

5 berprfen des System Architectural Design 5 Bewerten Sie alternative Systemarchitekturen

6 Stellen Sie sicher, Konsistenz und Traceability von 6 Stellen Sie eine bidirektionale Rckverfolgbarkeit
Systemanforderungen Systemarchitektur
7 Sicherstellung der Konsistenz
7 Kommunizieren Systemarchitektur

8 Kommunizieren vereinbart Systemarchitektur

Neue Aspekte der Systemarchitektur Prozess

Seite
66 66
nderungen in V3.0 - SYS.3 System Architectural Design

Neu:
Dynamisches Verhalten hat explizit angesprochen werden (bisher nur implizit)

Designalternativen haben zu dokumentieren

Rckverfolgbarkeit und Konsistenz getrennt sind (siehe Schlsselbegriffe)

Keine Prfkriterien erforderlich mehr


berprfen Sie nur fr Konsistenzprfung, sonst auf Ebene 2

Seite
67 67
SYS.4 Systemintegration und Integrationstest - Outcomes
Ergebnisse V2.5 - ENG.9 Outcomes V3.0

Als Ergebnis einer erfolgreichen Umsetzung dieses Prozesses Als Ergebnis einer erfolgreichen Umsetzung dieses Prozesses

1 eine Systemintegration und Systemintegration Teststrategie ist 1 eine Systemintegrationsstrategie mit dem Projekt im Einklang
fr Systemelemente im Einklang mit der Systemarchitektur entsprechend Plan, der Release-Plan und die Systemarchitektur entwickelt, um die
den Prioritten und Kategorisierung der Systemanforderungen entwickelt; Systemelemente zu integrieren;

2 eine Systemintegrationsteststrategie einschlielich der Regression


2 ist eine Testspezifikation fr den Systemintegrationstest wird entwickelt Teststrategie die System Artikel Interaktionen testen entwickelt wird;
Einhaltung der Systemarchitektur, einschlielich der Schnittstellen zwischen
den Systemelementen zu berprfen;
3 eine Spezifikation fr den Systemintegrationstest entsprechend der
3 ist ein integriertes System, integriert, wie durch die definierte Systemintegration Teststrategie entwickelt, das fr den Nachweis zu erbringen
Integrationsstrategie; Einhaltung der integrierten Systemelemente mit der Systemarchitektur,
einschlielich der Schnittstellen zwischen Systemelementen geeignet ist;
4 Die integrierten Systemelemente werden unter Verwendung der Testflle verifiziert;

4 Systemelemente werden zu einem kompletten integrierten integriert up


5 Ergebnisse der Systemintegrationstests aufgezeichnet werden;
System gem der Integrationsstrategie;

6 Konsistenz und Traceability sind etabliert 5 Testflle in der Systemintegration Testspezifikation enthalten sind,
zwischen der Systemarchitektur und Systemintegration Testspezifikation entsprechend der Systemintegrationsteststrategie ausgewhlt, und
einschlielich Testflle; und der Release-Plan;

7 eine Regressionsstrategie entwickelt und angewendet, fr die Wieder 6 System Artikel Wechselwirkungen werden mit dem ausgewhlten Test getestet

Testen der Systemelemente, wenn nderungen vorgenommen werden Flle und die Ergebnisse der Integration Prfsystems werden aufgezeichnet;

7 Konsistenz und bidirektionale Rckverfolgbarkeit zwischen der


Elemente der Systemarchitektur und Testflle in der Systemintegration
Die entsprechenden Testflle mssen ausgewhlt werden, um die
Testspezifikation und bidirektionale Rckverfolgbarkeit zwischen Testfllen
Teststrategie untersttzen (inkl. Die Regressionsteststrategie)
und Testergebnissen enthalten sind, festgelegt; und

8 Ergebnisse des Systemintegrationstest werden an alle betroffenen Parteien


Seite
68 68 zusammengefasst und mitgeteilt
SYS.4 Systemintegration und Integrationstest - Base Practices

Base Practices V2.5 - ENG.9 Base Practices V3.0

1 Entwickeln Systemintegrationsstrategie 1 Entwickeln Systemintegrationsstrategie

2 Entwickeln Systemintegration Teststrategie 2 Entwickeln Systemintegration Teststrategie einschlielich


Regressionsteststrategie
3 Entwickeln Sie eine Testspezifikation fr die Systemintegration
3 Entwickeln Spezifikation fr Systemintegrationstest

4 Integrieren Systemelementen
4 Integrieren Systemelemente

5 berprfen des integrierten Systems


5 Whlen Sie Testflle

6 Aufzeichnung der Ergebnisse der Systemintegrationstests


6 Ausfhren Systemintegrationstest

7 Stellen Sie sicher, Konsistenz und Traceability von


7 Stellen Sie eine bidirektionale Rckverfolgbarkeit
Systemarchitektur auf die Systemintegration Testspezifikation

8 Sicherstellung der Konsistenz


8 Aufbau Regressionsteststrategie und fhren
Regressionstests 9 Fassen Sie zusammen und kommunizieren Ergebnisse

Neue Aspekte der Systemintegration und Integration Testprozess

Seite
69 69
nderungen in V3.0 - SYS.4 Systemintegration und Integrationstest

Testflle haben nach der Teststrategie zu whlen, einschlielich der Regressionsteststrategie

Rckverfolgbarkeit und Konsistenz getrennt sind (siehe Schlsselbegriffe)

Seite
70 70
SYS.5 System-Qualifikation Test - Outcomes

Ergebnisse V2.5 - ENG.10 Outcomes V3.0

Als Ergebnis einer erfolgreichen Umsetzung dieses Prozesses Als Ergebnis einer erfolgreichen Umsetzung dieses Prozesses

1 eine Strategie entwickelt, um das System zu testen gem 1 eine System-Qualifikation Teststrategie einschlielich
die Prioritten und die Systemanforderungen Regressionsteststrategie im Einklang mit dem Projektplan und
Kategorisierung; Release-Plan entwickelt wird das integrierte System zu testen;

2 ist eine Testspezifikation fr einen Systemtest der integrierten


System entwickelt, das die Einhaltung der Systemanforderungen 2 eine Spezifikation fr die Systemeignungsprfung der
zeigt; integriert System nach dem System Qualifikationsteststrategie entwickelt
wird, dass ist geeignet Nachweis zu erbringen, Fr die Einhaltung der
3 Das integrierte System wird mit den Testflle verifiziert;
Systemanforderungen;

4 Ergebnisse des Systemtests werden aufgezeichnet; 3 Testflle in der Systemeignungsprfung Spezifikation enthalten
sind, gem dem System Qualifikationsteststrategie ausgewhlt,
5 Konsistenz und Traceability sind etabliert und der Release-Plan;
zwischen den Systemanforderungen und der Systemtestspezifikation
4 Das integrierte System ist testeten die ausgewhlten Testflle mit und die
einschlielich Testflle; und
Ergebnisse der Systemeignungsprfung werden aufgezeichnet;

6 eine Regressionsteststrategie entwickelt und angewandt, fr


Wieder Testen des integrierten Systems, wenn eine nderung in
5 Konsistenz und bidirektionale Rckverfolgbarkeit
Systemelementen besteht
zwischen Systemanforderungen und Testflle etabliert im System
Qualifizierungs Prfvorschrift und zwischen Testfllen und
Testergebnisse enthalten sind; und

Die entsprechenden Testflle mssen ausgewhlt werden, um die 6 Ergebnisse der Systemeignungsprfung zusammengefasst
Teststrategie untersttzen (inkl. Die Regressionsteststrategie) und an alle betroffenen Parteien mitgeteilt

Seite
71 71
SYS.5 System-Qualifikation Test - Base Practices

Base Practices V2.5 - ENG.10 Base Practices V3.0

1 Entwickeln Systemteststrategie 1 Entwickeln Systemqualifizierung Teststrategie einschlielich


Regressionsteststrategie
2 Entwickeln Testspezifikation fr einen Systemtest
2 Entwickeln Spezifikation fr Systemeignungsprfung

3 berprfen integriertes System


3 Whlen Sie Testflle

4 zeichnen die Ergebnisse der Systemtests


4 Test integriertes System

5 Stellen Sie sicher, Konsistenz und Traceability von


5 Stellen Sie eine bidirektionale Rckverfolgbarkeit
Systemanforderungen an die Systeme
Prfvorschrift
6 Sicherstellung der Konsistenz
6 Develop System Regressionsteststrategie und
Durchfhrung Test 7 Fassen Sie zusammen und kommunizieren Ergebnisse

Neue Aspekte des Systems Qualifikationstestprozess

Seite
72 72
nderungen in V3.0 - SYS.5 System-Eignungstest

Neuer Name fr einen Systemtest Systemeignungsprfung (von ISO 15504-5: 2012)

Testflle haben nach der Teststrategie zu whlen, einschlielich der Regressionsteststrategie

Rckverfolgbarkeit und Konsistenz getrennt sind (siehe Schlsselbegriffe)

Seite
73 73
SWE.1 Software-Analyse-Anforderungen - Outcomes
Ergebnisse V2.5 - ENG.4 Outcomes V3.0

Als Ergebnis einer erfolgreichen Umsetzung dieses Prozesses Als Ergebnis einer erfolgreichen Umsetzung dieses Prozesses

1 die Software-Anforderungen an die Softwareelemente des Systems 1 die Software-Anforderungen an die Softwareelemente des Systems
und ihre Schnittstellen definiert zugeordnet werden; und ihre Schnittstellen definiert zugeordnet werden;

2 Softwareanforderungen kategorisiert und analysiert 2 Softwareanforderungen kategorisiert und analysiert


auf Korrektheit und Testbarkeit; Fr die Richtigkeit und berprfbarkeit ;

3 die Auswirkungen der Software-Anforderungen an die Betriebsumgebung 3 die Auswirkungen der Software-Anforderungen an die
ausgewertet; Betriebsumgebung analysiert ;

4-Priorisierung fr die Implementierung der Software 4-Priorisierung fr die Implementierung der Software
Anforderungen definiert ist; Anforderungen definiert ist;

5 die Software-Anforderungen werden je nach Bedarf geprft und aktualisiert werden; 5 die Software-Anforderungen werden nach Bedarf aktualisiert werden;

6 Konsistenz und bidirektionale Rckverfolgbarkeit


6 Konsistenz und Traceability sind etabliert
zwischen den Systemanforderungen und
zwischen den Systemanforderungen und Software-Anforderungen;
Software-Anforderungen festgelegt; und Konsistenz und
und Konsistenz und Traceability zwischen der Systemarchitektur und
bidirektionale Rckverfolgbarkeit zwischen der
Softwareanforderungen etabliert;
Systemarchitektur und Softwareanforderungen etabliert;

7 nderungen an den Softwareanforderungen ausgewertet


fr Kosten, Zeitplan und technische Auswirkungen; und
7 die Software-Anforderungen ausgewertet fr Kosten,
Zeitplan und technische Auswirkungen; und

8 die Software-Anforderungen als Baseline und an alle


betroffenen Parteien mitgeteilt
8 die Software-Anforderungen vereinbart und
an alle betroffenen Parteien mitgeteilt

Einige Umformulierung aber im Grunde haben die Ergebnisse nicht gendert

Seite
74 74
SWE.1 Software Analysis Anforderungen - Base Practices

Base Practices V2.5 - ENG.4 Base Practices V3.0

1 Identifizieren Softwareanforderungen 1 Angeben Software Anforderungen

2 Analysieren Softwareanforderungen 2 Struktur Software Anforderungen

3 Ermitteln der Auswirkung auf die Betriebsumgebung 3 Analysieren Softwareanforderungen

4 priorisieren und kategorisieren Softwareanforderungen 4 Analysieren die Auswirkungen auf die Betriebssystemumgebung

5 auswerten und aktualisieren Software-Anforderungen 5 Entwickeln Prfkriterien

6 Stellen Sie sicher, Konsistenz und Traceability von 6 Stellen Sie eine bidirektionale Rckverfolgbarkeit
Systemanforderungen Software-Anforderungen
7 Sicherstellung der Konsistenz
7 Stellen Sie sicher, Konsistenz und Traceability von
Systemarchitektur zu Softwareanforderungen
8 Kommunizieren vereinbart Software Anforderungen
8 Kommunizieren Software-Anforderungen

Verknpft mit 1-8

Seite
75 75
Analyse SWE.1 Software-Anforderungen - nderungen in V3.0

Rckverfolgbarkeit und Konsistenz getrennt sind (siehe Schlsselbegriffe)

Prfkriterien erforderlich explizit in BP5


Anders als das hauptschlich Umformulierung

Seite
76 76
SWE.2 Software Architectural Design - Outcomes

Ergebnisse V2.5 - ENG.5 Outcomes V3.0

Als Ergebnis einer erfolgreichen Umsetzung dieses Prozesses Als Ergebnis einer erfolgreichen Umsetzung dieses Prozesses

1 ein Software-Architektur-Design ist, dass identifiziert definiert 1 ein Software-Architektur-Design ist, dass identifiziert definiert
die Komponenten der Software und erfllt die definierten das Elemente der Software;
Software-Anforderungen; (ENG.5 - 1)
2 die Software-Anforderungen werden an die Elemente der
2 die Software-Anforderungen werden an die Elemente der Software-zugeordnet;
Software-zugeordnet; (ENG.5 - 2)
3 die Schnittstellen jedes Softwareelement definiert sind;
3 interne und externe Schnittstellen der jeweiligen
Softwarekomponente definiert sind; (ENG.5 - 3) 4 das dynamische Verhalten und Ressourcenverbrauch Ziele der
Software Elemente sind festgelegt;
4 das dynamische Verhalten und Ressourcenverbrauch Ziele der
Softwarekomponenten definiert sind; (ENG.5 - 4) 5 Konsistenz und bidirektionale Rckverfolgbarkeit
zwischen Software-Anforderungen und Software-Architektur
etabliert; und
5 Konsistenz und Traceability sind etabliert
zwischen Software-Anforderungen und 6 die Softwarearchitektur ist an alle betroffenen Parteien
Software-Architektur; (ENG.5 - 6) vereinbart und mitgeteilt

Neuer Aspekt der Software-Architektur

Outcomes zwischen SWE.2 und SWE.3 (frher ENG.5 und ENG.6) wurden umgeordnet

Seite
77 77
SWE.2 Software Architectural Design - Base Practices

Base Practices V2.5 - ENG.5 Base Practices V3.0

1 Entwickeln Sie Softwarearchitektur (ENG.5 - 1 Entwickeln Sie Softwarearchitektur


BP1)
2 Ordnen Software-Anforderungen
2 Ordnen Softwareanforderungen (ENG.5 - BP2)

3 definieren Schnittstellen der Software-Elemente


3 definieren Schnittstellen (ENG.5 - BP3)

4 Beschreiben dynamisches Verhalten


4 Beschreiben dynamisches Verhalten (ENG.5 - BP4)

5 Definieren Sie den Ressourcenverbrauch Ziele


5 Definieren Sie Ziele Ressourcenverbrauch (ENG.5 -
BP5)
6 Bewerten Sie alternative Software-Architekturen
6 Entwickeln Verifizierungskriterien (ENG.5 - BP7)
7 Stellen Sie eine bidirektionale Rckverfolgbarkeit
7 Stellen Sie sicher, Software Design (ENG.5 - BP8)
8 Sicherstellung der Konsistenz
8 Stellen Sie sicher, Konsistenz und Traceability von
Software-Anforderungen an Software-Architektur (ENG.5 - 9 Kommunizieren Sie vereinbarte Softwarearchitektur
BP9)

Neue Aspekte der Softwarearchitektur Prozess

Seite
78 78
nderungen in V3.0 - SWE.2 Software Architectural Design

Neu:
Designalternativen haben zu dokumentieren

Die Architektur hat zu vereinbaren und mitgeteilt


Die Prozesse der Konstruktion und Bau-Einheit (ENG.5 / 6) wurden in drei verschiedene Prozesse aufgeteilt (SWE.2 - 4)

Rckverfolgbarkeit und Konsistenz getrennt sind (siehe Schlsselbegriffe)

Prfkriterien nicht explizit erforderlich


berprfen Sie nur fr Konsistenzprfung, sonst auf Ebene 2

Seite
79 79
SWE.3 Software Detailkonstruktion und Einheit Construction - Outcomes

Ergebnisse V2.5 - ENG.5 / 6 Outcomes V3.0

Als Ergebnis einer erfolgreichen Umsetzung dieses Prozesses Als Ergebnis einer erfolgreichen Umsetzung dieses Prozesses

1 ein detailliertes Design entwickelt, das beschreibt Software 1 ein detailliertes Design entwickelt, das beschreibt Software
Einheiten, die implementiert und getestet werden kann; (ENG.5 - 5) Einheiten;

2 interne und externe Schnittstellen der jeweiligen 2 Schnittstellen jeder Software Einheit sind festgelegt;
Softwarekomponente definiert sind; (ENG.5 - 3)

das dynamische Verhalten und Ressourcenverbrauch Ziele der 3 das dynamische Verhalten der Software-Einheiten definiert ist;
3
Softwarekomponenten definiert sind; (ENG.5 - 4)
4 Konsistenz und bidirektionale Rckverfolgbarkeit
zwischen Softwareanforderungen und Softwareeinheiten
4 Konsistenz und Traceability sind etabliert etabliert ; und Konsistenz und bidirektionale
zwischen Software-Architektur und Software detaillierten Design. Rckverfolgbarkeit zwischen Software-Architektur und Software
(ENG.5 - 7) detaillierten Design etabliert; und Konsistenz und bidirektionale Rckverfolgb
zwischen Software detaillierten Design und Software-Einheiten
5 Software-Einheiten durch das Software-Design definiert sind
festgelegt;
hergestellt (ENG.6 - 3)

6 Konsistenz und Traceability sind etabliert


zwischen Software detaillierten Design und Software-Einheiten; (ENG.6 - 6)
5 die Software detaillierte Design und die Beziehung zur Software
architektonische Gestaltung wird an alle betroffenen Parteien vereinbart und
mitgeteilt; und

6 Softwareeinheiten von der Software definiert ausfhrlich Entwurf


werden produziert
Software-Ausfhrungsplanung neu geordnet

Outcomes zwischen SWE.2 und SWE.3 (frher ENG.5 und ENG.6) hat neuen Aspekt der

Seite
80 80
SWE.3 Software Detailkonstruktion und Einheit Construction - Base Practices

Base Practices V2.5 - ENG.5 / 6 Base Practices V3.0

1 Entwickeln Detailplanung (ENG.5 - BP6) 1 Entwickeln Sie Software detaillierte Design

2 Definieren Schnittstellen (ENG.5 - BP3) 2 Definieren Sie Schnittstellen von Softwareeinheiten

3 Beschreiben dynamisches Verhalten (ENG.5 - BP4) 3 Beschreiben dynamisches Verhalten

4 Analysieren Softwareeinheiten (ENG.6 - BP2) 4 Evaluieren Software detaillierte Design

5 Priorisieren und Softwareeinheiten (ENG.6 kategorisieren - 5 Stellen Sie eine bidirektionale Rckverfolgbarkeit
BP3)
6 Sicherstellung der Konsistenz
6 Entwickeln Verifizierungskriterien (ENG.5 - BP7)

7 Kommunizieren vereinbarte Software detailliertes Designs


7 Stellen Sie sicher, Software Design (ENG.5 - BP8)

8 Aufbau Softwareeinheiten
8 Stellen Sie sicher, Konsistenz und Traceability von
Softwarearchitektur Software detailliertes Design (ENG.5 -
BP10) Neue Aspekte der SWE.3

9 Stellen Sie sicher, Konsistenz und Traceability von


Software detailliertes Design und den Softwareeinheiten (ENG.6 - BP8) Verknpft mit BPs 5 und 6

10 Stellen Sie sicher, Konsistenz und Traceability von


Software-Anforderungen an Software-Einheiten (ENG.6 - BP9)

11 Entwickeln Softwareeinheiten (ENG.6 - BP4)

Seite
81 81
nderungen in V3.0 - SWE.3 Software Detailplanung und Bau Einheit

Neu:
Das Design hat sich zu vereinbaren und mitgeteilt
Die Prozesse der Konstruktion und Bau-Einheit (ENG.5 / 6) wurden in drei verschiedene Prozesse aufgeteilt (SWE.2 - 4)

Analyse und Priorisierung der detaillierten Gestaltung / Einheiten (ENG.6 BP2 / 3) in der Auswertung der Detailkonstruktion
(SWE.3 BP4) abgedeckt sind

Rckverfolgbarkeit und Konsistenz getrennt sind (siehe Schlsselbegriffe)

Prfkriterien nicht explizit erforderlich mehr


berprfen Sie nur fr Konsistenzprfung, sonst auf Ebene 2

Seite
82 82
SWE.4 Software Einzelprfung - Outcomes

Ergebnisse V2.5 - ENG.6 Outcomes V3.0

Als Ergebnis einer erfolgreichen Umsetzung dieses Prozesses Als Ergebnis einer erfolgreichen Umsetzung dieses Prozesses

1 eine Einheit Verifikationsstrategie fr Software entwickelt 1 eine Softwareeinheit Verifikationsstrategie einschlielich


Einheiten im Einklang mit dem Software-Design; (ENG.6 - Regressionsstrategie ist entwickelt die Software-Einheiten zu berprfen;
1)

2 Software-Einheiten, die durch das Software-Design definiert sind 2 Kriterien fr die Software-Einzelprfung entwickelt
auf Korrektheit und Testbarkeit analysiert; (ENG.6 - nach der Software-Einheit Verifikationsstrategie, die fr den Nachweis zu
2) erbringen die Einhaltung der Software-Einheiten mit der Software
detaillierten Design und mit den nicht-funktionalen Software-Anforderungen
3 Softwareeinheiten werden entsprechend der Einheit verifiziert
geeignet ist;
Verifikationsstrategie;
(ENG.6 - 4) 3 Softwareeinheiten werden entsprechend der Software verifiziert
Einzeleichung Strategie und die definierten Kriterien fr Software Einzeleichung und
4 Ergebnisse der Einzelprfung werden aufgezeichnet; (ENG.6 - 5)
die Ergebnisse werden aufgezeichnet;
und
4 Konsistenz und bidirektionale Rckverfolgbarkeit
5 Konsistenz und Traceability sind etabliert
die zwischen Softwareeinheiten, die Kriterien fr die Prfung
zwischen Software detaillierten Design und Software-Einheiten; (ENG.6 - 6)
und Prfungsergebnisse; und

5 Ergebnisse der Einzelprfung werden zusammengefasst und


an alle betroffenen Parteien mitgeteilt.

Neuer Aspekt der Software-Einzeleichung

Outcomes zwischen SWE.3 und SWE.4 (frher ENG.6) wurden umgeordnet


Seite
83 83
SWE.4 Software Einzelprfung - Base Practices

Base Practices V2.5 - ENG.6 Base Practices V3.0

1 Definieren Sie eine Einheit Verifikationsstrategie (ENG.6 - BP1) 1 Entwickeln Sie Softwareeinheit Verifikationsstrategie einschlielich
Regressionsstrategie
2 Analysieren Softwareeinheiten (ENG.6 - BP2)
2 Entwickeln Kriterien fr die Einzelprfung

3 Priorisieren und Softwareeinheiten (ENG.6 kategorisieren -


3 Fhren Sie statische Verifikation von Software-Einheiten
BP3)

4 Einheit Prfkriterien entwickeln (ENG.6 - BP5) 4 Test Software-Einheiten

5 berprfen Softwareeinheiten (ENG.6 - BP6) 5 Stellen Sie eine bidirektionale Rckverfolgbarkeit

6 Nehmen Sie die Ergebnisse der Einzelprfung (ENG.6 - BP7) 6 Sicherstellung der Konsistenz

7 Stellen Sie sicher, Konsistenz und Traceability von 7 Fassen Sie zusammen und kommunizieren Ergebnisse
Software-Einheiten Spezifikation fr Software-Einheiten zu testen (ENG.6 -
BP10)

Neue Aspekte des Software-Einheit Prfungsprozesses

Covered in SWE.3

Seite
84 84
nderungen in V3.0 - SWE.4 Software Einzelprfung

Neu:
Die Prozesse der Konstruktion und Bau-Einheit (ENG.5 / 6) wurden in drei verschiedene Prozesse aufgeteilt (SWE.2 - 4)

Alle Prfungsttigkeiten auf Einheitenebene sind in diesem Prozess abgedeckt

Rckverfolgbarkeit und Konsistenz getrennt sind (siehe Schlsselbegriffe)

Seite
85 85
SWE.5 Software Integration und Integrationstest - Outcomes

Ergebnisse V2.5 - ENG.7 Outcomes V3.0

Als Ergebnis einer erfolgreichen Umsetzung dieses Prozesses Als Ergebnis einer erfolgreichen Umsetzung dieses Prozesses

1 eine Software-Integration und Integrationsteststrategie ist fr 1 eine Software-Integrationsstrategie im Einklang mit dem Projektplan, Release-Plan
Software-Produkte, die mit dem Software-Design zu den Prioritten und und der Software-Architektur entwickelt, um die Software-Produkte zu integrieren;
Kategorisierung der Softwareanforderungen entsprechend entwickelt;

2 eine Software-Integrationsteststrategie einschlielich der Regressionsteststrategie zu testen,


2 ist eine Testspezifikation Software-Integration entwickelt, das die Einhaltung wird entwickelt, die Software-Einheit und Software-Element-Wechselwirkungen;
der auf die Elemente zugeordnet Softwarearchitektur, Software detailliertes
Design, gewhrleistet;
3 eine Spezifikation fr Software-Integrationstest nach der Software-Integration
3 Softwareeinheiten und Softwarekomponenten integriert werden, wie durch die Teststrategie ist entwickelt die geeignet ist, den Nachweis zu erbringen fr die
Integrationsstrategie definiert; Einhaltung der integrierten Software-Artikel mit der Softwarearchitektur, einschlielich
der Schnittstellen zwischen den Softwareeinheiten und zwischen den
4 integrierte Software-Produkte werden unter Verwendung der Testflle verifiziert;
Software-Artikel ;

5 Ergebnisse der Software-Integrationstests aufgezeichnet werden;


4 Softwareeinheiten und Softwarekomponenten sind zu einer vollstndigen
integrierten Software gem der Integrationsstrategie integriert up;
6 Konsistenz und Traceability zwischen Software-Architektur und Software
detaillierter Design-Software-Integration Testspezifikation einschlielich Testflle
festgestellt; und 5 Testflle, die in der Software-Integrationstest
Spezifikation wird gem der Software-Integration Teststrategie ausgewhlt, und
7 eine Regressionsstrategie entwickelt und angewendet, fr die Reintegration und Wieder Verifizieren
der Release-Plan;
Artikel Software, wenn eine nderung in der Software-Produkte (einschlielich damit verbundenen
Anforderungen, Design und Code) auftritt 6 integrierte Software-Produkte sind testeten die ausgewhlten Testflle mit und die Ergebnisse
der Software-Integrationstest aufgezeichnet werden;

7 Konsistenz und bidirektionale Rckverfolgbarkeit zwischen den Elementen der


Softwarearchitektur etabliert und die Testflle enthalten in der Software-Integration
Testspezifikation und zwischen Testflle und Testergebnisse ; und
Neuer Aspekt des Software-Integration und Integrationstest

8 Ergebnisse des Software-Integrationstest zusammengefasst und an alle


einige Umformulierung
Seite
86 86 betroffenen Parteien mitgeteilt
SWE.5 Software Integration und Integrationstest - Base Practices

Base Practices V2.5 - ENG.7 Base Practices V3.0

1 Entwickeln Software Integrationsstrategie 1 Entwickeln Software Integrationsstrategie

2 Entwickeln Sie Software-Integration Teststrategie 2 Entwickeln Sie Software-Integration Teststrategie einschlielich


Regressionsteststrategie
3 Entwickeln Prfvorschrift fr die Softwareintegration
3 Entwickeln Spezifikation fr Software-Integrationstest
Test

4 Integrieren Softwareeinheiten und Softwarekomponenten 4 Integrieren Softwareeinheiten und Softwarekomponenten

5 berprfen Sie die integrierte Software 5 Whlen Sie Testflle

6 Nehmen Sie die Ergebnisse der Software-Integrationstests


6 Fhren Sie Software Integrationstest

7 Stellen Sie sicher, Konsistenz und Traceability von 7 Stellen Sie eine bidirektionale Rckverfolgbarkeit
Software Architektur und Software detailliertes Design

8 Sicherstellung der Konsistenz


Software-Integration Prfvorschrift

8 Aufbau Regressionsteststrategie und fhren 9 Fassen Sie zusammen und kommunizieren Ergebnisse
Regressionstests

Neue Aspekte des Software-Integration und


Integrationstestprozesses

Seite
87 87
nderungen in V3.0 - SWE.5 Software Integration und Integrationstest

Neu:
Auswahl von Testfllen auf der Grundlage der Teststrategie

Rckverfolgbarkeit und Konsistenz getrennt sind (siehe Schlsselbegriffe)

Seite
88 88
SWE.6 Software Qualification Test - Outcomes

Ergebnisse V2.5 - ENG.8 Outcomes V3.0

Als Ergebnis einer erfolgreichen Umsetzung dieses Prozesses Als Ergebnis einer erfolgreichen Umsetzung dieses Prozesses

1 eine Strategie entwickelt, um die integrierte Software zu testen 1 eine Software Qualifikation Teststrategie einschlielich
entsprechend den Prioritten und Kategorisierung der Regressionsteststrategie im Einklang mit dem Projektplan und
Software-Anforderungen; Release-Plan ist entwickelt die integrierte Software zu testen;

2 ist eine Testspezifikation fr Software-Test der integrierten


Software entwickelt, die die Einhaltung der 2 eine Spezifikation fr Software Eignungsprfung der
Software-Anforderungen zeigt; integrierte Software nach der Software-Qualifikation Teststrategie ist
entwickelt die geeignet ist, Beweise mit den
3 die integrierte Software wird unter Verwendung der Testflle verifiziert;
Software-Anforderungen fr die Einhaltung zu sorgen;

4 Ergebnisse der Software-Tests werden aufgezeichnet;


3 Testflle in der Software-Qualifikationstestspezifikation enthalten
5 Konsistenz und Traceability sind etabliert sind, entsprechend die Software-Qualifikationsteststrategie
zwischen Software-Anforderungen und Software-Testspezifikation ausgewhlt, und der Release-Plan;
einschlielich Testflle; und
4 die integrierte Software verwendet testet die ausgewhlt
6 eine Regressionsteststrategie entwickelt und angewandt, fr Testflle und die Ergebnisse der Software Eignungsprfung werden aufgezeichnet;
Wieder Testen der integrierten Software, wenn eine nderung in der

Software-Elemente auftreten
5 Konsistenz und bidirektionale Rckverfolgbarkeit
die zwischen Software-Anforderungen und Software Qualifikation Prfvor
einschlielich Testflle und zwischen Testflle und
Testergebnisse ; und
Die entsprechenden Testflle mssen ausgewhlt werden, um die
6 Ergebnisse der Software Eignungsprfung sind
Teststrategie untersttzen (inkl. Die Regressionsteststrategie)
zusammengefasst und an alle betroffenen Parteien mitgeteilt

Seite
89 89
SWE.6 Software Qualification Test - Base Practices

Base Practices V2.5 - ENG.8 Base Practices V3.0

1 Software-Entwicklung Teststrategie 1 Software-Entwicklung Qualifikation Teststrategie einschlielich


Regressionsteststrategie
2 Entwickeln Testspezifikation fr Software-Test
2 Entwickeln Spezifikation fr Software Qualifikation Test

3 Stellen Sie sicher, integrierte Software


3 Whlen Sie Testflle

4 Notieren Sie die Ergebnisse der Software-Tests


4 Test integrierte Software

5 Stellen Sie sicher, Konsistenz und Traceability von


5 Stellen Sie eine bidirektionale Rckverfolgbarkeit
Software-Anforderungen an Software-Test-Spezifikation

6 Entwickeln Regressionsteststrategie und fhren 6 Sicherstellung der Konsistenz


Regressionstests
7 Fassen Sie zusammen und kommunizieren Ergebnisse

Neue Aspekte der Software Qualifizierung Testprozess

Seite
90 90
nderungen in V3.0 - SWE.6 Software Qualification Test

Neuer Name fr Software-Test Software Eignungsprfung (von ISO 15504-5: 2012)


Neu:
Auswahl von Testfllen auf der Grundlage der Teststrategie

Rckverfolgbarkeit und Konsistenz getrennt sind (siehe Schlsselbegriffe)

Seite
91 91
nderungen an Allgemeinpraxis - CL2 (1/3)

Vers. 3.0 / ISO 330xx Vers. 2.5 / ISO 15504


GP 2.1.1 die Ziele fr die Durchfhrung des GP 2.1.1 die Ziele fr die Durchfhrung des
Prozesses identifizieren. Prozesses identifizieren.

2.1.2 GP Planen Sie die Durchfhrung des Verfahrens der GP 2.1.2 Planung und berwachung der Durchfhrung
identifizierten Ziele zu erfllen. des Verfahrens der identifizierten Ziele zu erfllen.

GP 2.1.3 die Leistung des Prozesses gegen die


Plne berwachen. GP 2.1.3 die Leistung des Prozesses anpassen.
GP 2.1.4 die Leistung des Prozesses anpassen.
GP 2.1.4 Aufgaben und Zustndigkeiten festlegen zur
GP 2.1.5 Aufgaben und Zustndigkeiten festlegen zur Durchfhrung des Verfahrens.

Durchfhrung des Verfahrens. GP 2.1.5 Identifizierung und verfgbare


GP 2.1.6 Identifizierung, Vorbereitung und verfgbare Ressourcen, um den Prozess durchfhrt nach

Ressourcen, um den Prozess durchfhrt nach Plan. Plan.

GP 2.1.6 die Schnittstellen zwischen den beteiligten Parteien

GP 2.1.7 die Schnittstellen zwischen den beteiligten Parteien verwalten.

verwalten.

Seite 92
nderungen an Allgemeinpraxis - CL2 (2/3)

2.1.2 GP Planen Sie die Durchfhrung des Verfahrens der identifizierten Ziele zu erfllen. [ ACHIEVEMENT
b]

Plan (en) fr die Durchfhrung des Verfahrens entwickelt.


Die Prozessleistung Zyklus definiert.
Wichtige Meilensteine fr die Durchfhrung des Verfahrens sind etabliert.
Schtzwerte fr die Prozessleistungsattribute bestimmt und aufrechterhalten wird.
Prozessaktivitten und Aufgaben definiert.
Zeitplan definiert und ausgerichtet mit dem Ansatz zur Durchfhrung des Verfahrens.
Prozessarbeit Bewertungen sind geplant.

GP 2.1.3 die Leistung des Prozesses gegen die Plne berwachen.


[ACHIEVEMENT c]
Das Verfahren wird durchgefhrt nach dem Plan (s).
Prozessleistung wird berwacht geplante Ergebnisse, um sicherzustellen, erreicht werden und mgliche Abweichungen zu

identifizieren

Seite 93
nderungen an Allgemein Practices - CL2 (3/3)

GP 2.1.6 Identifizierung, Vorbereitung und verfgbare Ressourcen, um den Prozess durchfhrt


nach Plan. [ ACHIEVEMENT f, g]

Die menschlichen und Infrastruktur-Ressourcen, die fr die Durchfhrung des Verfahrens identifiziert werden zur

Verfgung gestellt, zugeordnet und verwendet werden.

Die Personen, die Durchfhrung und den Prozess der Verwaltung werden durch Ausbildung, Mentoring
oder Coaching bereit sind, ihre Aufgaben auszufhren.

Die Informationen, die zur Durchfhrung des Verfahrens identifiziert und zur Verfgung gestellt.

Seite 94
nderungen an Allgemeinpraxis - CL3 (1/2)

GP 3.1.1 Definieren und pflegen Das Standardverfahren, die den Einsatz des definierten
Prozesses untersttzen. [ACHIEVEMENT a]

Ein Standardverfahren entwickelt und gepflegt Das beinhaltet die grundlegenden


Prozesselemente.
...

GP 3.1.3 die Rollen und Kompetenzen identifizieren, Verantwortlichkeiten und Behrden


fr die Standardverfahren durchgefhrt wird. [ ACHIEVEMENT c]

Prozessleistung Rollen identifiziert


Kompetenzen zur Durchfhrung des Verfahrens werden identifiziert.

Die Behrden, die fr die Ausfhrung Verantwortlichkeiten identifiziert.

Seite 95
nderungen an Allgemein Practices - CL3 (2/2)

GP 3.1.5 geeignete Verfahren fest, und Manahmen die Wirksamkeit und Eignung des
Standardprozesses zu berwachen. [ ACHIEVEMENT e]

Methods und Manahmen zur berwachung werden die Wirksamkeit und Eignung des Prozesses
bestimmt.

...

PA 3.2 Prozessentfaltungs Attribut


Das Verfahren Entfaltungs Attribut ist ein Ma fr das Ausma, in dem das Standardverfahren ist, effektiv
eingesetzt als definierte Prozess seine Prozessergebnisse zu erzielen. Als Folge der vollstndigen
Erreichung dieses Attribut:

Darber hinaus die folgenden Hinweise fr GP 3.2.6 sammeln und Daten ber die Leistung des
Prozesses analysieren, um die Eignung und Wirksamkeit zu zeigen.
[ACHIEVEMENT f]

Anmerkung 1: Die Daten ber die Prozessleistung knnen qualitativ oder quantitativ sein.

Seite 96
nderungen an Allgemeinpraxis - CL4 (1/2)

Vers. 3.0 / ISO 330xx Vers. 2.5 / ISO 15504


GP 4.1.1 Geschftsziele identifizieren. 4.1.1 GP Identifizieren Prozessinformationen muss im

4.1.2 GP Stellen Prozessinformationen bentigt. Zusammenhang mit den Geschftszielen.

GP 4.1.2 leiten Messziele Prozess von


GP 4.1.3 leiten Messziele Prozess von Prozessinformationen bentigt.
Prozessinformationen bentigt.
GP 4.1.4 Identifizierung messbare Beziehungen zwischen GP 4.1.3 fr die Durchfhrung des definierten
Prozesselementen. Prozesses quantitative Ziele festlegen, entsprechend
der Ausrichtung des Prozesses mit den
GP 4.1.5 quantitative Ziele festlegen.
Geschftszielen.
GP 4.1.6 Prozess Manahmen identifizieren, die die
GP 4.1.4 Produkt- und Prozess Manahmen
Erreichung der quantitativen Ziele untersttzen.
identifizieren, die die Erreichung der quantitativen Ziele
fr die Prozessleistung zu untersttzen.
GP 4.1.7 Sammeln Produkt- und
Prozessmessergebnisse durch den definierten Prozess
GP 4.1.5 Sammeln Produkt- und
durchgefhrt wird.
Prozessmessergebnisse durch den definierten Prozess
durchgefhrt wird.

GP 4.1.6 Verwendung der Ergebnisse der definierten


Mess der Erreichung der Prozessleistungsziele zu
berwachen und zu berprfen.

Seite 97
nderungen an Allgemein Practices - CL4 (2/2)

GP 4.1.4 Identifizierung messbare Beziehungen zwischen Prozesselementen. [Ergebnis


a, d]
Identifizieren, die die Beziehungen zwischen den Prozesselementen, die zu den abgeleiteten
Messzielen beitragen.

Seite 98
nderungen an Allgemeinpraxis - CL5

Vers. 3.0 / ISO 330xx Vers. 2.5 / ISO 15504


GP 5.1.1 der Prozessinnovationsziele fr den Prozess GP 5.1.1 die Prozessverbesserungsziele fr den Prozess
definieren, die die relevanten Unternehmensziele definieren, die die relevanten Unternehmensziele
untersttzen. untersttzen.

GP 5.1.2 Daten des Prozesses analysieren Mglichkeiten GP 5.1.2 Messdaten des Prozesses analysieren zu realen
fr Innovationen zu identifizieren. und potentiellen Variationen in der Prozessleistung zu

GP 5.1.3 Analyse neue Technologien und identifizieren.

Prozesskonzepte Innovationsmglichkeiten zu 5.1.3 GP Verbesserungsmglichkeiten des Prozesses


identifizieren. identifizieren, basierend auf Innovation und Best

GP 5.1.4 definieren und eine Practices.

Umsetzungsstrategie halten auf Innovation GP 5.1.4 Ableitung von Verbesserungsmglichkeiten des


Vision und Zielen basiert. Prozesses aus neuen Technologien und
Prozesskonzepten. Auswirkungen neuer Technologien auf
die Prozessleistung identifiziert und bewertet.

GP 5.1.5 eine Umsetzungsstrategie zur langfristigen


Verbesserung Vision und Zielen auf der Grundlage definieren.

Seite 99
Und schlussendlich

Seite 100
mehr Frage?

Treffen Sie die Experten:

Wir bieten kostenlose halbtgige ffentliche Seminare. Unsere Experten werden die nderungen erklren und Ihre

individuellen Fragen beantworten.

Fr die englische Sprache Einfhrungen sehen


www.kuglermaag.com/aspice-intro
Fr die deutsche Sprache Einfhrungen sehen
www.kuglermaag.de/aspice-intro

Planen Sie einen eintgigen Inhouse-Seminar:

Unsere Experten werden die nderungen erklren, Ihre Fragen beantworten, sondern auch auf Ihre individuelle Situation zu
betrachten und zu planen, wie Ihre Organisation zu Automotive SPICE 3.0 Compliance fortfahren zu aktualisieren.

Fr eine Update-Schulungen finden


www.kuglermaag.com/aspice-update (Englische Version)

www.kuglermaag.de/aspice-update (Deutsche Version)


Alle anderen Fragen und Anliegen?
Siehe Kontaktinformationen

Seite 101
ber die Autoren
Fabio Bella
Process Director bei Kugler Maag Cie, Country Manager fr Italien
intacs TM Beirat
intacs TM SPICE Haupt Assessor, intacs TM SPICE Instructor
TV Rheinland Functional Safety Engineer (Automotive)
Volkswagen-zertifizierte Software Quality Improvement Leader (SQIL)

Dr. Klaus Hoermann


Auftraggeber und Partner bei Kugler Maag Cie

Fhrer der intacs TM Arbeitsgruppe Prfungen


intacs TM SPICE Haupt Assessor, intacs TM SPICE Instructor
Volkswagen-zertifizierte Software Quality Improvement Leader (SQIL)
CMMI SCAMPI Lead Appraiser (CMMI Institute-zertifiziert)
CMMI Instructor (CMMI Institute-zertifiziert)
Scrum Master (Scrum.org zertifiziert)

Bhaskar vanamali
Process Director bei Kugler Maag Cie
Mitglied des VDA AK13 (Arbeits auf Automotive SPICE), Mitglied des SC7 WG10 (arbeitet
an ISO 15504 / ISO 33000)
intacs TM SPICE Haupt Assessor, intacs TM SPICE Instructor
SixSigma Green Belt
Seite 102
Volkswagen-zertifizierte Software Quality Improvement Leader (SQIL)
Kontakt Informationen

KUGLER MAAG CIE GmbH


Leibnizstr. 11
70806 Kornwestheim, Deutschland
information@kuglermaag.com
www.kuglermaag.de Telefon +49 7154
1796 100

KUGLER MAAG CIE North America Inc.


Columbia Center, 201 W Big Beaver Rd, Troy, MI
48084, USA usa@kuglermaag.com
www.kuglermaag.com Telefon +1 248 687 1210

KUGLER MAAG CIE Central Eastern Europe

cee@kuglermaag.com Telefon

+48 513 144 297

Seite 103
Danke fr Ihre
Aufmerksamkeit.

Fragen? Bemerkungen?

KUGLER MAAG CIE GmbH

Seite 104