2 11automotive Spicev3 0update 160107150411

Automotive SPICE 3.
0
What is new and what
has changed?
Fabio Bella
Klaus Hoermann
Bhaskar Vanamali
Steffen Herrmann
Markus Müller
Dezember 2015
© KUGLER MAAG CIE GmbH
Version 2015-12-05
Seite 1
About the Trainer: Markus Mueller
• Married with 2 children

• Director Operations at Kugler Maag Cie
• Over 15 years of experience in industry and research projects
• Assisting medium-size companies as well as international
corporations, primarily in the automotive industry
• PMI Project Management Professional
• Very experienced trainer, moderator, and management coach
• Speaker at conferences and co-author of books
Qualification & Experience

• intacs™-certified Principal Assessor and trainer, intacs™ Advisory Board member,
who
• conducted more than 50 assessments, many of them for OEMs
• trained more than 300 ISO/IEC 15504 provisional assessors from leading car
manufactures (OEMs) and suppliers
• advised OEM representatives on the development of Automotive SPICE®
• Project leader of several change and improvement projects based on ISO/IEC
15504 and CMM/CMMI®
• Providing consultancy, coaching, and active support in several ECU development
projects in automotive
• E.g. project leader for the implementation of a project control office (PCO) in the
electronics development of a major car manufacturer, which today controls more
than 100 ECU development projects
Introducing myself
Dr. Klaus Hoermann

• Principal and Partner at Kugler Maag Cie
• Leader of the intacsTM working group “Exams”
• intacsTM SPICE Principal Assessor, intacsTM SPICE Instructor
• Volkswagen-certified Software Quality Improvement Leader (SQIL)
• CMMI® SCAMPI Lead Appraiser (CMMI Institute-Certified)
• CMMI® Instructor (CMMI Institute-Certified)
• Scrum Master (Scrum.org certified)
Seite 3
About the trainer: Bhaskar Vanamali
• Married with 4 children

• Process Director at Kugler Maag Cie
• Over 15 years of experience in industry and process
improvement
• Assisting medium-size companies as well as international
corporations, primarily in the automotive industry
• Very experienced trainer, moderator, and management coach
• Speaker at conferences and co-author of books
Qualification & Experience

• intacs™-certified Principal Assessor and trainer, VDA AK13 member, who
• conducted more than 90 assessments, many of them for OEMs
• trained more than 200 ISO/IEC 15504 provisional assessors from leading car
manufactures (OEMs) and suppliers
• advised OEM representatives on the development of Automotive SPICE®
• Project leader of several change and improvement projects based on SPICE and
CMM/CMMI®
• Providing consultancy, coaching, and active support in several ECU development
projects in automotive
• Member of ISO-working group for system and SW-engineering processes
Contents
• Executive Summary
• Introduction
• Overview of the Changes
• Changes in Detail
• And Finally
• Need more Advice?
• Contact Information
Seite 5
Executive Summary
• Version 3.0 comprises many small changes and improvements, some structural
changes, and few changes which will increase project efforts.
• Structural changes:
• The engineering processes were divided into the two groups System (SYS) and Software (SWE).
• The tip of the V was changed: Unit construction and unit verification have been separated into
two processes.
• A „Plug-In Concept“ allows integration of mechanical and hardware processes (not provided by
Automotive SPICE)
• Content-wise, the HIS-Scope remains mainly the same (however the name of some
processes have changed).
• Few changes will cause additional efforts from projects, e.g., evaluation of alternative solutions
is required for system and software architectures according to defined criteria. The evaluation
result including a rationale for the architecture/design selection has to be recorded.
• The Measurement Framework was adapted to the changes in ISO 33020
• Little changes for capability levels 1-3, major changes for capability levels 4-5
• Automotive SPICE 3.0 is not yet mandatory. This will be decided by the VDA Quality
Management Board with the release of the new „Blue/Gold Volume“ (Sep. 2016).
• In the meantime the VDA AK 13 will develop interpretation guidelines for Automotive
SPICE 3.0 and also a guideline for performing assessments (planned for April 2016).
Seite 6
Introduction
Seite 7
Basic Facts and Acknowledgements
• Automotive SPICE Vers. 3.0 will replace the Automotive SPICE Process
Assessment Model (PAM) 2.5 and the Process Reference Model (PRM) 4.5.
• ASPICE Vers. 3.0 comprises PRM and PAM in one single document.
• Automotive SPICE is no longer using ISO 12207 as guidance
• Automotive SPICE® is a registered trademark of the Verband der
Automobilindustrie e.V. (VDA)
• Automotive SPICE 3.0 has been created by the Working Group 13 of the
Quality Management Center (QMC) within the German Association of the
Automotive Industry (Verband der Automobilindustrie e.V., VDA) with the
representation of members of the Automotive Special Interest Group (SIG) –
review only, and with the agreement of The SPICE User Group. This agreement
is based on a validation of the Automotive SPICE 3.0 version regarding any ISO
copyright infringement and the statements given from VDA QMC to the SPICE
User Group regarding the current and future development of Automotive
SPICE.
Seite 8
Members VDA AK13
• Employees of Volkswagen, Continental, Schäffler, ZF, Brose, Ford, BMW,
Daimler, Knorr Bremse
• Secretary: Bhaskar Vanamali (KMC)
• Contact VDA QMC: Dr. Jan Morenzin
Seite 9
Automotive SPICE 3.0 Deployment and Timeline
• Automotive SPICE 3.0 has been published in July 2015 and may be used for
assessments in agreement with the sponsor.
• Automotive SPICE 2.3 is still the version which is considered mandatory by the
VDA. Automotive SPICE versions 2.3 or 2.5 may still be used.
• Mandatory rules for the Automotive SPICE 3.0 transition are decided by the
VDA Quality Management Board with the release of the new “Blue/Gold
Volume” (Sep. 2016).
• In the meantime the VDA AK 13 will develop interpretation guidelines for
Automotive SPICE 3.0 and also a guideline for performing assessments
(Blue/Gold Volume by VDA, planned date is September 2016).
Seite 10
Blue/Gold Volume and ASPICE 3.0 - Deployment and Timeline (1/2)
Release Release
Automotive Blue/Gold
SPICE 3.0 Volume
Period II =
Period I Transition Period Period III
Automotive
End of 2016 End of 2017
SYS
July 2015
• Timeline of publications by AK13 and transition time

• CAVE! The publication time of the Blue/Gold Volume of VDA is a target date
and the transition time of one year (Period II) is still under discussion.
Seite 11
Blue/Gold Volume and ASPICE 3.0 - Deployment and Timeline (2/2)
Topic Period I Period II Period III
Entry ASPICE 3.0 release BG Volume release End of transition

Exit BG Volume release End of transition (~1y) Open end
iNTACS Trainings Update of trainings to Update of trainings to the None

ASPICE 3.0 BG Volume
Certified assessors No implication for any Upgrade training needed Still Upgrade-Training
grade for Competent and needed for Competent
Principal and Principal
No implication for No implication yet for
Provisional assessors Provisional assessors
Additional trainings Update Trainings possible, iNTACS- and VDA WG13- Still iNTACS- and VDA
but no official trainings approved upgrade WG13-approved upgrade
trainings trainings
Provisional assessors No specific requirements Upgrade training in Upgrade training in
discussion but not clear discussion but not clear
how to enforce that how to enforce that
Assessments Assessment for any PAM Assessments for PAM 3.0 In discussion: For German
2.3 to 3.0 are possible only accepted if Lead OEMs assessments have
assessor underwent to be performed based on
upgrade training PAM 3.0
Seite 12
Rules for the Period between July 2015 until the Guidelines are
published – Period I
• There will be no official upgrade trainings.
• The iNTACS training materials for Provisional and Competent Assessors will be
updated (Update for Provisional Assessor training planned for early 2016)
• iNTACS instructors are not required to be upgraded
• To be able to perform Automotive SPICE 3.0 assessments: no additional
requirements
• Automotive SPICE 3.0 Assessments are acknowledged as EE-1.
• Certification/Recertification: No changes
Seite 13
Rules for the Period between Guidelines are published until the
end of the Transition Period (date tbd) – Period II
• iNTACS training materials will be updated. There will be an official upgrade
training. iNTACS will provide all changes, AK13 will perform reviews. iNTACS
training providers will perform the trainings.
• iNTACS instructors need to be upgraded. Bhaskar Vanamali and Pierre Metz
will perform the upgrade trainings.
• iNTACS training providers will provide upgrade trainings for all assessor grades.
• To be able to perform Automotive SPICE 3.0 assessments: The lead assessor
must have participated in official upgrade training.
• Automotive SPICE 3.0 Assessments are acknowledged as EE-1 if the assessor
has passed an upgrade training (or has attended a new provisional course).
Assessments from previous models (2.3 upwards) are still acknowledged as EE-
1.
• Certification/Recertification:
• Provisional: There are no changes to recertification. New Provisional Course.
• Competent: Need upgrade unless they took a new Provisional Course.
• Principals: Need upgrade
Seite 14
Rules for the time after the end of the Transition Period (date tbd)
– Period III
• Automotive SPICE 3.0 Assessments are acknowledged as EE-1 if the assessor
has passed an upgrade training (or has attended a new provisional course).
• Whether assessments from previous models (2.3 upwards) are still
acknowledged as EE-1 is not yet decided.
• Certification/Recertification:
• Provisional: There are no planned changes to recertification. New Provisional Course.
However, discussion on mandatory upgrade trainings for Provisional Assessors which
were trained based on old trainings.
• Competent: Need upgrade unless they took a new Provisional Course.
• Principals: Need upgrade
Seite 15
Overview of the Changes
Seite 16
Motivation for Updating Automotive SPICE
• Adaptation to ISO/IEC 15504-5 2012
• Automotive SPICE 2.5 was based on ISO/IEC 15504-5 2006.
• Adaption to the ISO/IEC 33000 series
• including the updated measurement framework
• Some basic structures, concepts, and terminology needed updates.
• Assessment Indicators needed updates
(particularly Base Practices for the HIS scope)
Seite 17
Overview of Main Changes (Document view)
Chapter Change
Editorial adaption to 33000 series, notes regarding combined PRM/PAM
Chapter 1 Introduction
in this document
Chapter 2 Statement of compliance Adaption to 33000 series
Chapter 3 Introduction Optimized for better understanding and adapted to 33000 series.
The acronym ENG changed to SYS and SWE, the structure of the
Chapter 4 Process reference model and
processes has changed, Base Practices of the HIS Scope have been
performance indicators (Level 1)
reworked.
Chapter 5 Process capability levels and

Adapted to the measurement framework of ISO/IEC 33020
process attributes
Annex A Conformity of the process
Conformity statement adapted to ISO/IEC 33004:2015.
assessment and reference model
Modifications on work product characteristics according to the changes
Annex B Work product characteristics
in chapter 4.
Annex C Terminology Update to recent standards, introduction of new terminology
Added the new major concepts relative to Annex D of AS 2.5

Annex D Key Concepts
Traceability diagram (Annex E PAM 2.5) is now in Annex D
Annex E Reference Standards Updated references to other standards
Seite 18
Overview of Main Changes
The new Annex D was extended to include a clarification of new Automotive
SPICE key concepts and is a good starting point to understand the differences
between V 3.0 and V 2.5 in particular with respect to Capability Level 1
Annex D Key Koncepts

• D.1 The “Plug-in” Concept
• D.2 The Tip of the “V”
• D.3 Terms “Element”, “Component”, “Unit”, and “Item”
• D.4 Traceability and Consistency
• D.5 “Agree” and “Summarize and Communicate”
• D.6 “Evaluate”, “Verification Criteria” and “Ensuring compliance”
• D.7 The Relation Between “Strategy” and “Plan”
Seite 19
Structural Changes in Version 3.0: “Plug-In Concept”
SYS.1
System Level
SYS.2 SYS.5
SYS.3 SYS.4
MAN.3
SUP.10
ACQ.4
SUP.1
SUP.8
SUP.9
Domain Level
HWE.1 HWE.4 SWE.1 SWE.6 MEE.1 MEE.4
HWE.2 HWE.3 SWE.2 SWE.5 MEE.2 MEE.3
SWE.3 SWE.4
SYS System Engineering
SWE Software Engineering
HWE Hardware Engineering part of the Automotive SPICE® 3.0 PAM
MEE Mechanical Engineering not developed by VDA, not included in Automotive SPICE® 3.0 PAM
Seite 20
Structural Changes in Version 3.0: The Tip of the V
SYS.2 SYS.5
System Requirements Analysis System Qualification Test
SYS.3 SYS.4
System Integration and
System Architectural Design
Integration Test
SWE.1 SWE.6
SW Requirements Analysis SW Qualification Test
SWE.2 SWE.5
SW Integration
SW Architectural Design
and Integration Test
SWE.3 SWE.4
SW Detailed Design
SW Unit Verification
and Unit Construction
Seite 21
Terms “Element”, “Component”, “Unit”, and “Item”
System Engineering Process Group (SYS)
SYS.1
Requirements Elicitation
SYS.2 SYS.5
System Requirements
System Qualification Test
Analysis
SYS.3 SYS.4
Integration Test
Software Engineering Process Group (SWE) items

elements SWE.1 SWE.6
Software Requirements
Software Qualification Test
Analysis
SWE.2 SWE.5
components Software Architectural
Design
Software Integration and
Integration Test
SWE.3 SWE.4
units Software Detailed Design
Software Unit Verification
units
• A system architecture specifies the elements of the system.

• A software architecture specifies the elements of the software.
• Software elements are hierarchically decomposed into smaller elements down to the software
components which are at the lowest level of the software architecture.
• Software components are described in the detailed design.
• A software component consists of one or more software units.
• Items on the right side of the V-model are the implemented counterparts of elements and
components on the left side. This can be a 1:1 or m:n relationship, e.g. an item may represent
more than one implemented element.
Seite 22
Traceability and Consistency
• Traceability and consistency have been formerly addressed by one single base
practice on the right side of the V and have now been split into two base
practices.
• Traceability refers to the existence of references or links between work
products. Traceability supports coverage analysis, impact analysis,
requirements implementation status tracking etc.
• Consistency means that
• All traceability references/links are available (i.e., nothing is missing)
• All traceability references/links are correct (i.e., not linking to the wrong work
product)
• Consistency has to be proven by technical review of the traceability
• New traceability requirements have been added:
• Between test cases and test results
• Between change requests and work products affected by these change requests
(SUP.10)
Seite 23
Traceability and Consistency
Bidirectional traceability
Stakeholder Consistency
requirements
SYS.2 BP7 System qualification
SYS.2 BP8 SYS.5 BP5 test specification
SYS.5 BP6 SYS.5 BP5
System System qualification
Test cases
requirements test results
SYS.3 BP6 System Integration
SYS.3 BP7 SYS.4 BP7 test specification
SYS.4 BP8 SYS.4 BP7
System System integration
Test cases
architecture test results
SWE.1 BP7 Software qualification
SWE.1 BP7 SWE.1 BP8 SWE.6 BP5 test specification
SWE.1 BP8 SWE.6 BP6 SWE.6 BP5
Software Software qualification
Test cases
requirements test results
SWE.2 BP7
Software integration
SWE.2 BP8
SWE.5 BP7 Test specification
SWE.5 BP8 SWE.5 BP7
Software Software Integration
SWE.3 BP5 Test cases
architecture test result
SWE.3 BP6
SWE.3 BP5
SWE.3 BP6
SWE.3 BP5 SWE.4 BP5
Software SWE.4 BP6 Unit SWE.4 BP5 Unit
SWE.3 BP6
detailed design test specification test results
Software SWE.4 BP5 Static varification

units results
To affected work products
Change request
SUP.10 BP8
Seite 24
“Agree” and “Summarize and Communicate”
BP: “communicate agreed…” BP: “summarize and communicate…”
SYS.2 SYS.5
SYS.3 SYS.4
Integration Test
SWE.1 SWE.6
SWE.2 SWE.5
SW Integration
SWE.3 SWE.4
SW Detailed Design
• The information flow on the left side of the “V” is ensured through a base practice
“Communicate agreed ‘work product x’”. The term “agreed” means that there is a joint
understanding of all stakeholders regarding the content of the work product.
• The information flow on the right side of the “V” is ensured through a base practice
“Summarize and communicate results”. The term “Summarize” refers to abstracted
information resulting from test executions made available to all relevant parties.
Seite 25
“Evaluate”, “Verification Criteria” and “Ensuring compliance”
SYS.2.BP5: Verification criteria

SYS.2 SYS.5
SYS.5.BP2: Ensure compliance
Verification
SUP.2
SYS.3 SYS.4
System Architectural Design SYS.3.BP3: Ensure compliance Integration Test
SWE.1.BP5: Verification criteria

SWE.1 SWE.6
SWE.6.BP2: Ensure compliance
SWE.2 SWE.5.BP3:
SWE.5
Ensure compliance SW Integration
SWE.3 SWE.4
SW Detailed Design
SWE.3.BP4: Evaluate SWE.4.BP2: Criteria for unit verification

Seite 26
• Verification criteria are used as input for the development of the test cases or
other verification measures that ensures compliance with the requirements.
Verification criteria are only used in the context of System Requirements
Analysis (SYS.2) and Software Requirements Analysis (SWE.1) processes.
Verification aspects which cannot be covered by testing are covered by the
verification process (SUP.2).
• Criteria for unit verification ensure compliance of the source code with the
software detailed design and the non-functional requirements. Possible
criteria for unit verification include unit test cases, unit test data, coverage
goals and coding standards and coding guidelines, e.g. MISRA. For unit testing,
such criteria shall be defined in a unit test specification. This unit test
specification may be implemented e.g. as a script in an automated test bench.
Seite 27
• Evaluation of alternative solutions is required for system and software

architectures. The evaluation has to be done according to defined criteria.
Such evaluation criteria may include quality characteristics like modularity,
reliability, security, and usability, or results of make-or-buy or reuse analysis.
The evaluation result including a rationale for the architecture/design
selection has to be recorded.
• Compliance with an architectural design (SWE.5.BP3) means that the

specified integration tests are capable of proving that interfaces and relevant
interactions like e.g. dynamic behavior between
- the software units,
- the software items and
- the system items
fulfill the specification given by the architectural design.
Seite 28
New practice in System Architectural Design : Evaluate alternative
system architectures
• SYS.3.BP5: Evaluate alternative system architectures. Define evaluation

criteria for architecture design. Evaluate alternative system architectures
according to the defined criteria. Record the rationale for the chosen system
architecture. [OUTCOME 1]
• NOTE 3: Evaluation criteria may include quality characteristics (modularity,
maintainability, expandability, scalability, reliability, security and usability) and
results of make-buy-reuse analysis.
Seite 29
The Relation Between “Strategy” and “Plan”
Plan
BP 1 defines the strategy… Generic plan
WP 08-00
BP1: CL >=2
Develop Strategy CL =1
Process specific plan

WP 08-nn
Which is documented in the
related WP
Both terms “Strategy” and “Plan” are commonly used across following processes of the Automotive
SPICE 3.0 PAM:
• SYS.4 System Integration and Integration Test
• SYS.5 System Qualification Test
• SWE.4 Software Unit Verification
• SWE.5 Software Integration and Integration Test
• SWE.6 Software Qualification Test
• SUP.1 Quality Assurance
• SUP.8 Configuration Management
• SUP.9 Problem Resolution Management
• SUP.10 Change Request Management
Seite 30
The Relation Between “Strategy” and “Plan”
• Capability Level 1:
Each of these processes requires the development of a process-specific
strategy. The strategy always corresponds to a process-specific “Plan”. For each
process-specific “Plan” there are process-specific work product characteristics
defined (e.g. “08-52 Test Plan”, “08-04 Configuration Management Plan”).
Scheduling like e.g. old SUP.10 BP10 has been moved to Level 2
• Capability Level 2 or higher:

Each process-specific “Plan” (WP 08-nn) inherits the work product
characteristics represented by the Generic Plan (WP 08-00). This means that
for a process-specific “Plan” both the process-specific characteristics (WP 08-
nn) and the generic characteristics (WP 08-00) apply.
• BPs for proceeding have been deleted.
Seite 31
No Separation of PAM and PRM in v3.0
• Color code for different elements
• Red for PRM elements (Process ID, name, purpose and outcomes)
• Green for base practices and generic practices
• Blue for output work products and generic resources
• Italics for content from ISO 330xx (e.g. measurement framework)
Seite 32
Rating scale as defined by ISO/IEC 33020
Rating Rationale
N Not achieved There is little or no evidence of achievement of the defined
process attribute in the assessed process.
P Partially achieved There is some evidence of an approach to, and some
achievement of, the defined process attribute in the assessed process. Some
aspects of achievement of the process attribute may be unpredictable.
L Largely achieved There is evidence of a systematic approach to, and
significant achievement of, the defined process attribute in the assessed
process. Some weaknesses related to this process attribute may exist in the
assessed process.
F Fully achieved There is evidence of a complete and systematic approach
to, and full achievement of, the defined process attribute in the assessed
process. No significant weaknesses related to this process attribute exist in the
assessed process.
Seite 33
Optional Rating Scale
Rating Rationale
P- Partially achieved: There is some evidence of an approach to, and some
achievement of, the defined process attribute in the assessed process. Many
P+ Partially achieved: There is some evidence of an approach to, and some
achievement of, the defined process attribute in the assessed process. Some
L- Largely achieved: There is evidence of a systematic approach to, and
process. Many weaknesses related to this process attribute may exist in the
assessed process.
L+ Largely achieved: There is evidence of a systematic approach to, and
process. Some weaknesses related to this process attribute may exist in the
assessed process.
Seite 34
Extended Rating Scheme - percentages
Rating Percentages
P- > 15% to 32.5%
P+ > 32.5 % to 50 %
L- > 50 % to 67.5 %
L+ > 67.5 % to 85 %
AK13 has not decided whether it is going to be part of the

guidelines or out of scope
Seite 35
Rating and Aggregation methods
• ISO/IEC 33020 identifies 3 rating methods R1, R2 and R3 and different
aggregation methods
• aggregation within one process (one-dimensional, vertical aggregation)
• across multiple process instances (one-dimensional, horizontal aggregation)
• both (two-dimensional, matrix aggregation)
• They are usually used for Assessments on Organizational Maturity
• AK13 has not decided whether it is going to be part of the guidelines or out of
scope
• In Automotive SPICE V 3.0 the rating methods are only briefly explained and
the approaches referenced
Seite 36
Example of a Rating Method
Rating method R1 (which has the strongest requirements):
• The approach to process attribute rating shall satisfy the following conditions:
• a) Each process outcome of each process within the scope of the assessment
shall be characterized for each process instance, based on validated data;
• b) Each process attribute outcome of each process attribute for each process
within the scope of the assessment shall be characterised for each process
instance, based on validated data;
• c) Process outcome characterisations for all assessed process instances shall be
aggregated to provide a process performance attribute achievement rating;
• d) Process attribute outcome characterisations for all assessed process
instances shall be aggregated to provide a process attribute achievement
rating.
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
Hori-
Bewertung der Indikatoren
zontal
GP 3.2.2 P L L L F L L
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
Hori-
zontal
GP 3.2.6 P L P P N L P
Seite 38 page 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
Bewertung der Indikkatoren
GP 3.2.2 P L L L F L
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 page 39
Changes in Detail
Seite 40
General Changes in V3.0
• See Key concepts (previous slides)

• In the testing processes (SYS.4, SYS.5, SWE.5, SWE.6) test cases have to be selected
based on the test strategy of the relevant test step.
• Removal of Level 2 activities from BPs
• Planning and monitoring activities were removed from BPs (e.g. SUP-processes)
• Reviews beyond consistency checks were removed from BPs (e.g. SWE.2-4)
Seite 41
MAN.3 Project Management – Outcomes
Outcomes V2.5 Outcomes V3.0

As a result of successful implementation of this process As a result of successful implementation of this process
1 the scope of the work for the project is defined; 1 the scope of the work for the project is defined;
2 the feasibility of achieving the goals of the project with 2 the feasibility of achieving the goals of the project with
available resources and constraints is evaluated; available resources and constraints is evaluated;
3 the tasks and resources necessary to complete the 3 the activities and resources necessary to complete the
work are sized and estimated; work are sized and estimated;
4 interfaces between elements in the project, and with 4 interfaces within the project, and with other projects
other project and organizational units, are identified and organizational units, are identified and monitored;
and monitored;
5 plans for the execution of the project are developed, 5 plans for the execution of the project are developed,
implemented and maintained; implemented and maintained;
6 progress of the project is monitored and reported; and 6 progress of the project is monitored and reported; and
7 actions to correct deviations from the plan and to 7 corrective action is taken when project goals are not
prevent recurrence of problems identified in the project achieved, and recurrence of problems identified in the
are taken when project goals are not achieved. project is prevented.
• Mainly rewording but no new content
Seite 42
MAN.3 Project Management – Base Practices
Base Practices V2.5 Base Practices V3.0
1 Define the scope of work. 1 Define the scope of work.
2 Define project life cycle 2 Define project life cycle
3 Determine and maintain estimates for project 3 Evaluate feasibility of the project
Attributes
4 Define, monitor and adjust project activities
4 Define project activities
5 Define skill needs 5 Determine, monitor und adjust project estimates and
resources
6 Define and maintain project schedule
6 Ensure required skills, knowledge, and experience
7 Identify and monitor project interfaces

7 Identify, monitor and adjust project interfaces and
8 Establish project plan agreed commitments
8 Define, monitor and adjust project schedule
9 Implement the project plan
10 Monitor project attributes 9 Ensure consistency
11 Review and report progress of the project 10 Review and report progress of the project
12 Act to correct deviations

Link to 3, 4, 5, 6, 7, 10
Seite
43 43
Changes in V3.0 – MAN.3 Project Management
• Establish and implement Project plan has been deleted as it caused confusion in the
past
• Instead all aspects of planning have to be identified, monitored and adjusted
(estimates, activities, schedules, plans, interfaces and commitments)
• Across all artifacts consistency has to be established (specific BP) – no traceability,
just consistency
• Scope of work used to contain check of feasibility. In 3.0 a specific BP for feasibility
has been introduced
• The project plan 08-12 is still an output work product of MAN.3. Check Annex B but
the references to risk management were removed. However, risks are mentioned in
BP5 and MAN.5 is referenced in the corresponding Note 6
Seite
44 44
SUP.1 Quality Assurance – Outcomes

1 a strategy for conducting quality assurance is 1 a strategy for performing quality assurance is
developed, implemented and maintained; developed, implemented, and maintained;
2 quality assurance is performed independent of the 2 quality assurance is performed independently and
activity or project being performed; objectively without conflicts of interest;
3 evidence of quality assurance is produced and 3 non-conformances of work products, processes, and
maintained; process activities with relevant requirements are
identified, recorded, communicated to the relevant
4 adherence of products, processes and activities to
parties, tracked, resolved, and further prevented;
agreed requirements are verified, documented, and
communicated to the relevant parties; 4 conformance of work products, processes and
activities with relevant requirements is verified,
5 problems and/or non-conformance with agreement
documented, and communicated to the relevant
requirements are identified, recorded, communicated
parties;
to the relevant parties, tracked and resolved; and
5 authority to escalate non-conformances to appropriate
6 quality assurance has the independence and authority
levels of management is established; and
to escalate problems to appropriate levels of
management. 6 management ensures that escalated non-
conformances are resolved.
• Focus is more on checking conformance and ensuring resolution of non-conformances
Seite
45 45
SUP.1 Quality Assurance – Base Practices
Base Practices V2.5
1 Develop project quality assurance strategy
2 Develop and maintain an organisation structure

which ensures that quality assurance is carried out Base Practices V3.0
and report Independentely
1 Develop project quality assurance strategy
3 Develop and implement a plan for project quality
assurance based on a quality assurance strategy 2 Assure quality of work products
4 Maintain evidence of quality assurance
3 Assure quality of process activities
5 Assure quality of work products
4 Summarize and communicate quality assurance
Assure quality of process activities activities and results
6
5 Ensure resolution of non-conformances
7 Track and record quality assurance activities
6 Implement an escalation mechanism
8 Report quality assurance activities and results
9 Ensure resolution on non-conformances
10 Implement an escalation mechanism
Seite
46 46
Changes in V3.0 – SUP.1 Quality Assurance
• Overall simplifying the process with similar content

• On top of independence in QA objectivity is required.
• It is clarified that escalation has to lead to management attention and actions.
Seite
47 47
SUP.8 Configuration Management – Outcomes

1 a configuration management strategy is developed; 1 a configuration management strategy is developed;
2 all items generated by a process or project are 2 all configuration items generated by a process or
identified, defined and baselined according to the project are identified, defined and baselined according
Configuration management strategy; to the configuration management strategy;
3 modifications and releases of the items are controlled; 3 modifications and releases of the configuration items
are controlled;
4 modifications and releases are made available to
4 modifications and releases are made available to
affected parties;
affected parties;
5 the status of the items and modification requests are
5 the status of the configuration items and modifications
recorded and reported;
is recorded and reported;
6 the completeness and consistency of the items is
6 the completeness and consistency of the baselines is
ensured; and
ensured; and
7 storage, handling and delivery of the items are
7 storage of the configuration items is controlled.
controlled.
• Some rewording but in essence the outcomes have not changed

Seite
48 48
SUP.8 Configuration Management – Base Practices
1 Develop a configuration management strategy 1 Develop a configuration management strategy
2 Identify configuration items 2 Identify configuration items
3 Establish a configuration management system 3 Establish a configuration management system
4 Establish branch management strategy 4 Establish branch management strategy
5 Establish baselines 5 Control modifications and releases
6 Maintain configuration item description 6 Establish baselines
7 Control modifications and releases 7 Report configuration status
8 Maintain configuration item history 8 Verify the information about configured items
9 Report configuration status 9 Manage the storage of configuration items and

baselines
10 Verify the information about configured items
11 Manage the backup, storage, archiving, handling

and delivery of configuration items
Seite
49 49
Changes in V3.0 – SUP.8 Configuration Management
• Overall simplifying the process with similar content

• No new content
Seite
50 50
SUP.9 Problem Resolution Management – Outcomes

1 a problem management strategy is developed; 1 a problem resolution management strategy is

developed;
2 problems are recorded, identified and classified;
2 problems are recorded, uniquely identified and
classified;
3 problems are analysed and assessed to identify
acceptable solution(s); 3 problems are analyzed and assessed to identify an
appropriate solution;
4 problem resolution is implemented;
4 problem resolution is initiated;
5 problems are tracked to closure; and
5 problems are tracked to closure; and
6 the status of all problem reports is known
6 the status of problems and their trend are known
Seite
51 51
SUP.9 Problem Resolution Management – Base Practices
1 Develop a problem resolution management strategy 1 Develop a problem resolution management strategy
2 Establish a consistent problem resolution 2 Identify and record the problem

management proceeding
3 Record the status of problems
3 Identify and record the problem
4 Diagnose the cause and determine the impact of the

4 Investigate and diagnose the cause and the impact
problem
of the problem
5 Authorize urgent resolution action
5 Execute urgent resolution action, where necessary
6 Raise alert notifications

6 Raise alert notifications, where necessary
7 Initiate problem resolution

7 Initiate change request
8 Track problems to closure

8 Track problems to closure
9 Analyze problem trends

9 Analyze problem trends
Seite
52 52
Changes in V3.0 – SUP.9 Problem Resolution Management
• Only minor changes regarding terminology

• No need to start a change request anymore (However, problems have to be tracked
to closure and initiating a change request might be an option )
• So also no planning aspects on Level 1
• The proceeding is part of the strategy/plan.
Seite
53 53
SUP.10 Change Request Management – Outcomes

1 a change management strategy is developed; 1 a change request management strategy is developed;
2 requests for changes are recorded and identified; 2 requests for changes are recorded and identified;
3 dependencies and relationships to other change 3 dependencies and relationships to other change
requests are identified; requests are identified;
4 criteria for confirming implementation of the change 4 criteria for confirming implementation of change
request are defined; requests are defined;
5 requests for change are analysed, prioritized, and 5 requests for change are analyzed, and resource
resource requirements estimated; requirements are estimated;
6 changes are approved on the basis of priority and 6 changes are approved and prioritized on the basis of
availability of resources; analysis results and availability of resources;
7 approved changes are implemented and tracked to 7 approved changes are implemented and tracked to
closure; and closure;
8 the status of all change requests is known 8 the status of all change requests is known; and
9 bi-directional traceability is established between

change requests and affected work products
• Major change that traceability to affected work products is included.
• Other than that no major changes
Seite
54 54
SUP.10 Change Request Management – Base Practices
Base Practices V2.5
1 Develop a change request management strategy
2 Establish a consistent change request management Base Practices V3.0

Proceeding
3 Identify and record the change request 1 Develop a change request management strategy
4 Record the status of change requests 2 Identify and record the change requests
5 Establish the dependencies and relationships to 3 Record the status of change requests
other change requests
4 Analyze and assess change requests
6 Assess the impact of the change
5 Approve change requests before implementation
7 Analyze and prioritize change requests
6 Review the implementation of change requests
8 Approve change requests before implementation
7 Track change requests to closure
9 Identify and plan the verification and validation
activities to be performed for implemented changes Establish bidirectional traceability
8
10 Schedule and allocate the change request
11 Review the implemented change Has been moved to Level 2

12 Change requests are tracked until closure
New BP/aspect of SUP.10
Seite
55 55
Changes in V3.0 – SUP.10 Change Request Management
• There are two major changes:

• The planning aspects (scheduling and planning of verification and validation) have been
moved to Level 2
• The traceability between Change requests and affected Work products has been
introduced
• Other than that there are no changes except for wording.
• The proceeding is part of the strategy/plan.
Seite
56 56
ACQ.4 Supplier Monitoring – Outcomes

1 joint activities between the customer and the supplier 1 joint activities, as agreed between the customer and
are performed as needed; the supplier, are performed as needed;
2 all information, agreed upon for exchange, is 2 all information, agreed upon for exchange, is
transferred between the supplier and the customer; communicated regularly between the supplier and
customer;
3 information on progress is exchanged regularly with
the supplier; 3 performance of the supplier is monitored against the
agreements; and
4 performance of the supplier is monitored against the
agreed requirements; and 4 changes to the agreement, if needed, are negotiated
between the customer and the supplier and
5 changes to the agreement, if needed, are negotiated
documented in the agreement
between the customer and the supplier and
documented with the agreement
Seite
57 57
ACQ.4 Supplier Monitoring – Base Practices
1 Agree on joint processes and joint interfaces 1 Agree on and maintain joint processes
2 Exchange all relevant information 2 Exchange all agreed information
3 Review technical development with the supplier 3 Review technical development with the supplier
4 Review progress of the supplier 4 Review progress of the supplier
5 Track open items 5 Act to correct deviations
7 Agree on changes
Linked to 1, 3, 4 and 5
Seite
58 58
ACQ.4 Supplier Monitoring – Base Practices
1 Agree on joint processes and joint interfaces 1 Agree on and maintain joint processes
2 Exchange all relevant information 2 Exchange all agreed information
3 Review technical development with the supplier 3 Review technical development with the supplier
4 Review progress of the supplier 4 Review progress of the supplier
5 Track open items 5 Act to correct deviations
7 Agree on changes
Linked to 1, 3, 4 and 5
Seite
59 59
Changes in V3.0 – ACQ.4 Supplier Monitoring
• No major changes, but the approach was simplified
Seite
60 60
Group Work / Discussion
Discuss in small working groups and document the results on a flip chart :
• What are the major changes ? (summarize)
• Where do see barriers in changing your process to ASPICE 3.0 complaince ?
• How do you estimate the invest (higher / same / less) ? Why ?
• What will be the impact of Assessments (imagine : now based on 3.0 instead
of 2.X) ?
Seite 61
SYS.2 System Requirements Analysis – Outcomes
Outcomes V2.5 – ENG.2 Outcomes V3.0

1 a defined set of system requirements is established; 1 a defined set of system requirements is established;
2 system requirements are categorized and analyzed for 2 system requirements are categorized and analyzed for
correctness and testability; correctness and verifiability;
3 the impact of the system requirements on the 3 the impact of system requirements on the operating
operating environment is evaluated; environment is analyzed;
4 prioritization for implementing the system requirements 4 prioritization for implementing the system requirements
is defined; is defined;
5 the system requirements are approved and updated as 5 the system requirements are updated as needed;
needed;
6 consistency and bidirectional traceability are
6 consistency and bilateral traceability are established
established between stakeholder requirements and
between customer requirements and system
system requirements;
requirements;
7 the stakeholder requirements are evaluated for cost,
7 changes to the customer’s requirements baseline are
schedule and technical impact; and
evaluated for cost, schedule and technical impact; and
8 the system requirements are agreed and
8 the system requirements are communicated to all
communicated to all affected parties
affected parties and baselined
Seite
62 62
SYS.2 System Requirements Analysis – Base Practices
Base Practices V2.5 – ENG.2 Base Practices V3.0
1 Identify System Requirements 1 Specify system requirements
2 Analyze system requirements 2 Structure system requirements
3 Determine the impact on the operating environment 3 Analyze system requirements
4 Prioritize and categorize system requirements 4 Analyze the impact on the operating environment
5 Evaluate and update system requirements 5 Develop verification criteria
6 Ensure consistency and bilateral traceability of 6 Establish bidirectional traceability

customer requirements to system requirements
7 Ensure consistency
7 Communicate system requirements
8 Communicate agreed system requirements
Linked to 1-8
Seite
63 63
Changes in V3.0 – SYS.2 System Requirements Analysis
• Traceability and consistency are separated (see key concepts)

• Verification criteria explicitly required in BP5
• Other than that mainly rewording
Seite
64 64
SYS.3 System Architectural Design – Outcomes

1 a system architectural design is defined that identifies 1 a system architectural design is defined that identifies
the elements of the system and meets the defined the elements of the system;
systems requirements;
2 the system requirements are allocated to the elements
2 the system requirements are allocated to the elements of the system;
of the system;
3 the interfaces of each system element are defined;
3 internal and external interfaces of each system
element are defined; 4 the dynamic behavior objectives of the system
elements are defined;
4 verification between the system requirements and the
system architectural design is performed; 5 consistency and bidirectional traceability are
established between system requirements and system
architectural design; and
between system requirements and system
architectural design; and 6 the system architectural design is agreed and
6 the system requirements, the system architectural
design, and their relationships are baselined and
communicated to all affected parties. New aspect of system architecture
• New aspect with dynamic behavior but other than that the outcomes have not changed in essence
Seite
65 65
SYS.3 System Architectural Design – Base Practices
1 Define system architectural design 1 Develop system architectural design
2 Allocate System Requirements 2 Allocate system requirements
3 Define Interfaces 3 Define interfaces of system elements
4 Develop verification criteria 4 Describe dynamic behavior
5 Verify System Architectural Design 5 Evaluate alternative system architectures

system requirements to system architectural design
7 Communicate system architectural design
8 Communicate agreed system architectural design
New aspects of the system architecture process
Seite
66 66
Changes in V3.0 – SYS.3 System Architectural Design
• New:
• Dynamic behavior has to be explicitly addressed (before only implicitly)
• Design alternatives have to be documented
• No verification criteria required anymore
• Review only for consistency check, otherwise on Level 2
Seite
67 67
SYS.4 System Integration and Integration Test – Outcomes
1 a system integration and system integration test strategy is 1 a system integration strategy consistent with the project
developed for system elements consistent with the system plan, the release plan and the system architectural design
architectural design according to the priorities and is developed to integrate the system items;
categorization of the system requirements;
2 a system integration test strategy including the regression
2 a test specification for system integration test is developed test strategy is developed to test the system item
to verify compliance with the system architectural design, interactions;
including the interfaces between system elements;
3 a specification for system integration test according to the
3 an integrated system is integrated as defined by the system integration test strategy is developed that is suitable
integration strategy; to provide evidence for compliance of the integrated system
items with the system architectural design, including the
4 the integrated system elements are verified using the test
interfaces between system items;
cases;
4 system items are integrated up to a complete integrated
5 results of system integration testing are recorded;
system according to the integration strategy;
6 consistency and bilateral traceability are established 5 test cases included in the system integration test
between system architectural design and system integration specification are selected according to the system
test specification including test cases; and integration test strategy and the release plan;
7 a regression strategy is developed and applied for re- 6 system item interactions are tested using the selected test
testing the system elements when changes are made cases and the results of system integration testing are
recorded;
7 consistency and bidirectional traceability between the
The appropriate test cases need to be selected elements of the system architectural design and test cases
included in the system integration test specification and
to support the test strategy (incl. the regression bidirectional traceability between test cases and test results
test strategy) is established; and
8 results of the system integration test are summarized and
Seite
68 68 communicated to all affected parties
SYS.4 System Integration and Integration Test – Base Practices
1 Develop system integration strategy 1 Develop system integration strategy
2 Develop system integration test strategy 2 Develop system integration test strategy including
regression test strategy
3 Develop a test specification for system integration
3 Develop specification for system integration test
4 Integrate system elements

4 Integrate system items
5 Verify the integrated system

5 Select test cases
6 Record the results of system integration testing

6 Perform system integration test
7 Ensure consistency and bilateral traceability of

7 Establish bidirectional traceability
system architectural design to the system integration
test specification
8 Develop regression testing strategy and perform
regression testing 9 Summarize and communicate results
New aspects of the system integration and integration

test process
Seite
69 69
Changes in V3.0 – SYS.4 System Integration and Integration Test
• Test cases have to be selected according to the test strategy including the regression
test strategy
Seite
70 70
SYS.5 System Qualification Test – Outcomes
1 a strategy is developed to test the system according to 1 a system qualification test strategy including
the priorities of and categorization the system regression test strategy consistent with the project plan
requirements; and release plan is developed to test the integrated
system;
2 a test specification for system test of the integrated
system is developed that demonstrates compliance 2 a specification for system qualification test of the
with the system requirements; integrated system according to the system qualification
test strategy is developed that is suitable to provide
3 the integrated system is verified using the test cases;
evidence for compliance with the system requirements;
4 results of system testing are recorded; 3 test cases included in the system qualification test
specification are selected according to the system
5 consistency and bilateral traceability are established qualification test strategy and the release plan;
between system requirements and the system test
4 the integrated system is tested using the selected test
specification including test cases; and
cases and the results of system qualification test are
6 a regression test strategy is developed and applied for recorded;
re-testing the integrated system when a change in
system elements is made
established between system requirements and test
cases included in the system qualification test
specification and between test cases and test results;
and
The appropriate test cases need to be selected 6 results of the system qualification test are summarized
to support the test strategy (incl. the regression and communicated to all affected parties
test strategy)
Seite
71 71
SYS.5 System Qualification Test – Base Practices
1 Develop system test strategy 1 Develop system qualification test strategy including
2 Develop test specification for system test
2 Develop specification for system qualification test
3 Verify integrated system

3 Select test cases
4 Record the results of system testing

4 Test integrated system

system requirements to the systems test
specification
6 Develop system regression test strategy and
perform testing 7 Summarize and communicate results
New aspects of the system qualification test process
Seite
72 72
Changes in V3.0 – SYS.5 System Qualification Test
• New name for system test  system qualification test (from ISO 15504-5:2012)
• Test cases have to be selected according to the test strategy including the regression
test strategy
Seite
73 73
SWE.1 Software Requirements Analysis – Outcomes
1 the software requirements to be allocated to the 1 the software requirements to be allocated to the
software elements of the system and their interfaces software elements of the system and their interfaces
are defined; are defined;
2 software requirements are categorized and analyzed 2 software requirements are categorized and analyzed
for correctness and testability; for correctness and verifiability;
3 the impact of software requirements on the operating 3 the impact of software requirements on the operating
environment is evaluated; environment is analyzed;
4 prioritization for implementing the software 4 prioritization for implementing the software
requirements is defined; requirements is defined;
5 the software requirements are approved and updated 5 the software requirements are updated as needed;
as needed;
established between system requirements and
between system requirements and software
software requirements; and consistency and
requirements; and consistency and bilateral traceability
bidirectional traceability are established between
are established between system architectural
system architectural design and software
design and software requirements;
requirements;
7 changes to the software requirements are evaluated
7 the software requirements are evaluated for cost,
for cost, schedule and technical impact; and
schedule and technical impact; and
8 the software requirements are baselined and
8 the software requirements are agreed and
Seite
74 74
SWE.1 Software Requirements Analysis – Base Practices
1 Identify software requirements 1 Specify software requirements
2 Analyze software requirements 2 Structure software requirements
3 Determine the impact on the operating environment 3 Analyze software requirements
4 Prioritize and categorize software requirements 4 Analyze the impact on the operating environment
5 Evaluate and update software requirements 5 Develop verification criteria

system requirements to software requirements
system architectural design to software requirements
8 Communicate agreed software requirements
8 Communicate software requirements
Linked to 1-8
Seite
75 75
Changes in V3.0 – SWE.1 Software Requirements Analysis

• Verification criteria explicitly required in BP5
• Other than that mainly rewording
Seite
76 76
SWE.2 Software Architectural Design – Outcomes

1 a software architectural design is defined that identifies 1 a software architectural design is defined that identifies
the components of the software and meets the defined the elements of the software;
software requirements; (ENG.5 – 1)
2 the software requirements are allocated to the
2 the software requirements are allocated to the elements of the software;
elements of the software; (ENG.5 – 2)
3 the interfaces of each software element are defined;
3 internal and external interfaces of each software
component are defined; (ENG.5 – 3) 4 the dynamic behavior and resource consumption
objectives of the software elements are defined;
4 the dynamic behaviour and resource consumption
objectives of the software components are defined; 5 consistency and bidirectional traceability are
(ENG.5 – 4) established between software requirements and
software architectural design; and
between software requirements and software 6 the software architectural design is agreed and
architectural design; (ENG.5 – 6) communicated to all affected parties
New aspect of software architecture
• Outcomes between SWE.2 and SWE.3 (formerly ENG.5 and ENG.6) have been rearranged
Seite
77 77
SWE.2 Software Architectural Design – Base Practices
1 Develop software architectural design (ENG.5 – 1 Develop software architectural design

BP1)
2 Allocate software requirements
2 Allocate software requirements (ENG.5 – BP2)
3 Define interfaces of software elements

3 Define interfaces (ENG.5 – BP3)
4 Describe dynamic behavior

4 Describe dynamic behaviour (ENG.5 – BP4)
5 Define resource consumption objectives

5 Define resource consumption objectives (ENG.5 –
BP5)
6 Evaluate alternative software architectures
6 Develop Verification Criteria (ENG.5 – BP7)
7 Verify Software Design (ENG.5 – BP8)
software requirements to software architectural 9 Communicate agreed software architectural design
design (ENG.5 – BP9)
New aspects of the software architecture process
Seite
78 78
Changes in V3.0 – SWE.2 Software Architectural Design
• New:
• Design alternatives have to be documented
• The architecture has to be agreed upon and communicated
• The processes of design and unit construction (ENG.5/6) have been split in three different
processes (SWE.2 – 4)
• Verification criteria not required explicitly
Seite
79 79
SWE.3 Software Detailed Design and Unit Construction – Outcomes
Outcomes V2.5 – ENG.5/6 Outcomes V3.0

1 a detailed design is developed that describes software 1 a detailed design is developed that describes software
units that can be implemented and tested; (ENG.5 – 5) units;
2 internal and external interfaces of each software 2 interfaces of each software unit are defined;
component are defined; (ENG.5 – 3)
3 the dynamic behavior of the software units is defined;
3 the dynamic behaviour and resource consumption
objectives of the software components are defined;
(ENG.5 – 4)
established between software requirements and
4 consistency and bilateral traceability are established software units; and consistency and bidirectional
between software architectural design and software traceability are established between software
detailed design. (ENG.5 – 7) architectural design and software detailed design; and
consistency and bidirectional traceability are
5 software units defined by the software design are
established between software detailed design and
produced (ENG.6 – 3)
software units;
5 the software detailed design and the relationship to the
between software detailed design and software units;
software architectural design is agreed and
(ENG.6 – 6)
communicated to all affected parties; and
6 software units defined by the software detailed design
are produced
New aspect of software detailed design
• Outcomes between SWE.2 and SWE.3 (formerly ENG.5 and ENG.6) have been rearranged
Seite
80 80
SWE.3 Software Detailed Design and Unit Construction – Base
Practices
Base Practices V2.5 – ENG.5/6 Base Practices V3.0
1 Develop detailed design (ENG.5 – BP6) 1 Develop software detailed design
2 Define interfaces (ENG.5 – BP3) 2 Define interfaces of software units
3 Describe dynamic behaviour (ENG.5 – BP4) 3 Describe dynamic behavior
4 Analyze software units (ENG.6 – BP2) 4 Evaluate software detailed design
5 Prioritize and categorize software units (ENG.6 – 5 Establish bidirectional traceability

BP3)
6 Develop Verification Criteria (ENG.5 – BP7)
7 Communicate agreed software detailed design

7 Verify Software Design (ENG.5 – BP8)
8 Develop software units

software architectural design to software detailed
design (ENG.5 – BP10) New aspects of SWE.3
software detailed design to software units (ENG.6 – Linked to BPs 5 and 6
BP8)
software requirements to software units (ENG.6 –
BP9)
11 Develop software units (ENG.6 – BP4)
Seite
81 81
Changes in V3.0 – SWE.3 Software Detailed Design and Unit
Construction
• New:
• The design has to be agreed upon and communicated
• Analysis and prioritization of the detailed design/units (ENG.6 BP2/3) is covered in the
evaluation of the detailed design (SWE.3 BP4)
• Verification criteria not explicitly required anymore
Seite
82 82
SWE.4 Software Unit Verification – Outcomes
1 a unit verification strategy is developed for software 1 a software unit verification strategy including
units consistent with the software design; regression strategy is developed to verify the software
(ENG.6 – 1) units;
2 software units defined by the software design are 2 criteria for software unit verification are developed
analyzed for correctness and testability; according to the software unit verification strategy that
(ENG.6 – 2) are suitable to provide evidence for compliance of the
software units with the software detailed design and
3 software units are verified according to the unit
with the non-functional software requirements;
verification strategy;
(ENG.6 – 4) 3 software units are verified according to the software
unit verification strategy and the defined criteria for
4 results of unit verification are recorded; (ENG.6 – 5)
software unit verification and the results are recorded;
and
established between software units, criteria for
between software detailed design and software units;
verification and verification results; and
(ENG.6 – 6)
5 results of the unit verification are summarized and
communicated to all affected parties.
New aspect of software unit verification
• Outcomes between SWE.3 and SWE.4 (formerly ENG.6) have been rearranged
Seite
83 83
SWE.4 Software Unit Verification – Base Practices
1 Define a unit verification strategy (ENG.6 – BP1) 1 Develop software unit verification strategy including
regression strategy
2 Analyze software units (ENG.6 – BP2)
2 Develop criteria for unit verification
3 Prioritize and categorize software units (ENG.6 –

3 Perform static verification of software units
BP3)
4 Develop unit verification criteria (ENG.6 – BP5) 4 Test software units
5 Verify software units (ENG.6 – BP6) 5 Establish bidirectional traceability
6 Record the results of unit verification (ENG.6 – BP7) 6 Ensure consistency
7 Ensure consistency and bilateral traceability of 7 Summarize and communicate results

software units to test specification for software units
(ENG.6 – BP10)
New aspects of the software unit verification process
Covered in SWE.3
Seite
84 84
Changes in V3.0 – SWE.4 Software Unit Verification
• New:
• All verification activities on Unit Level are covered in this process
Seite
85 85
SWE.5 Software Integration and Integration Test – Outcomes
1 a software integration and integration test strategy is 1 a software integration strategy consistent with the project plan,
developed for software items consistent with the software release plan and the software architectural design is
design according to the priorities and categorization of the developed to integrate the software items;
software requirements;
2 a software integration test strategy including the regression
2 a test specification software integration is developed that test strategy is developed to test the software unit and
ensures compliance with the software architectural design, software item interactions;
software detailed design, allocated to the items;
3 a specification for software integration test according to the
3 software units and software items are integrated as defined by software integration test strategy is developed that is suitable
the integration strategy; to provide evidence for compliance of the integrated software
items with the software architectural design, including the
4 integrated software items are verified using the test cases;
interfaces between the software units and between the
software items;
5 results of software integration testing are recorded;
4 software units and software items are integrated up to a
complete integrated software according to the integration
6 consistency and bilateral traceability are established between strategy;
software architectural design and software detailed design to
software integration test specification including test cases; and 5 Test cases included in the software integration test
specification are selected according to the software integration
7 a regression strategy is developed and applied for re- test strategy, and the release plan;
integrating and re-verifying software items when a change in
software items (including associated requirements, design and 6 integrated software items are tested using the selected test
code) occurs cases and the results of software integration test are recorded;
7 consistency and bidirectional traceability are established
between the elements of the software architectural design and
New aspect of software integration and integration the test cases included in the software integration test
specification and between test cases and test results; and
test
8 results of the software integration test are summarized and
• Some rewording
Seite
86 86 communicated to all affected parties
SWE.5 Software Integration and Integration Test – Base Practices
1 Develop software integration strategy 1 Develop software integration strategy
2 Develop software integration test strategy 2 Develop software integration test strategy including
3 Develop test specification for software integration
3 Develop specification for software integration test
Test
4 Integrate software units and software items 4 Integrate software units and software items
5 Verify the integrated software 5 Select test cases
6 Record the results of software integration testing Perform software integration test
6
7 Ensure consistency and bilateral traceability of Establish bidirectional traceability
7
software architectural design and software detailed
design to Ensure consistency
8
software integration test specification
8 Develop regression testing strategy and perform 9 Summarize and communicate results
regression testing
New aspects of the software integration and

integration test process
Seite
87 87
Changes in V3.0 – SWE.5 Software Integration and Integration Test
• New:
• Selection of test cases based on the test strategy
Seite
88 88
SWE.6 Software Qualification Test – Outcomes
1 a strategy is developed to test the integrated software 1 a software qualification test strategy including
according to the priorities and categorization of the regression test strategy consistent with the project plan
software requirements; and release plan is developed to test the integrated
software;
2 a test specification for software test of the integrated
software is developed that demonstrates compliance 2 a specification for software qualification test of the
to the software requirements; integrated software according to the software
qualification test strategy is developed that is suitable
3 the integrated software is verified using the test cases;
to provide evidence for compliance with the software
requirements;
4 results of software testing are recorded;
3 test cases included in the software qualification test
5 consistency and bilateral traceability are established specification are selected according to the software
between software requirements and software test qualification test strategy and the release plan;
specification including test cases; and
4 the integrated software is tested using the selected
6 a regression test strategy is developed and applied for test cases and the results of software qualification test
re-testing the integrated software when a change in are recorded;
software items occur
established between software requirements and
software qualification test specification including test
cases and between test cases and test results; and
The appropriate test cases need to be selected
6 results of the software qualification test are
to support the test strategy (incl. the regression summarized and communicated to all affected parties
test strategy)
Seite
89 89
SWE.6 Software Qualification Test – Base Practices
1 Develop software test strategy 1 Develop software qualification test strategy including
2 Develop test specification for software test
2 Develop specification for software qualification test
3 Verify integrated software

3 Select test cases
4 Record the results of software testing

4 Test integrated software

software requirements to software test specification
6 Develop regression test strategy and perform 6 Ensure consistency
regression testing
7 Summarize and communicate results
New aspects of the software qualification test process
Seite
90 90
Changes in V3.0 – SWE.6 Software Qualification Test
• New name for software test  software qualification test (from ISO 15504-5:2012)
• New:
• Selection of test cases based on the test strategy
Seite
91 91
Changes to Generic Practices - CL2 (1/3)
Vers. 3.0 / ISO 330xx Vers. 2.5 / ISO 15504
• GP 2.1.1 Identify the objectives for the • GP 2.1.1 Identify the objectives for the
performance of the process. performance of the process.
• GP 2.1.2 Plan the performance of the • GP 2.1.2 Plan and monitor the
process to fulfill the identified objectives. performance of the process to fulfill the
• GP 2.1.3 Monitor the performance of the identified objectives.
process against the plans. • GP 2.1.3 Adjust the performance of the
• GP 2.1.4 Adjust the performance of the process.
process. • GP 2.1.4 Define responsibilities and
• GP 2.1.5 Define responsibilities and authorities for performing the process.
authorities for performing the process. • GP 2.1.5 Identify and make available
• GP 2.1.6 Identify, prepare, and make resources to perform the process
available resources to perform the process according to plan.
according to plan. • GP 2.1.6 Manage the interfaces between
• GP 2.1.7 Manage the interfaces between involved parties.
involved parties.
Seite 92
• GP 2.1.2 Plan the performance of the process to fulfill the identified
objectives. [ACHIEVEMENT b]
• Plan(s) for the performance of the process are developed.
• The process performance cycle is defined.
• Key milestones for the performance of the process are established.
• Estimates for process performance attributes are determined and maintained.
• Process activities and tasks are defined.
• Schedule is defined and aligned with the approach to performing the process.
• Process work product reviews are planned.
• GP 2.1.3 Monitor the performance of the process against the plans.

[ACHIEVEMENT c]
• The process is performed according to the plan(s).
• Process performance is monitored to ensure planned results are achieved and to
identify possible deviations
Seite 93
GP 2.1.6 Identify, prepare, and make available resources to perform the

process according to plan. [ACHIEVEMENT f, g]
• The human and infrastructure resources, necessary for performing the process
are identified made available, allocated and used.
• The individuals performing and managing the process are prepared by
training, mentoring, or coaching to execute their responsibilities.
• The information necessary to perform the process is identified and made
available.
Seite 94
Changes to Generic Practices – CL3 (1/2)
GP 3.1.1 Define and maintain the standard process that will support the
deployment of the defined process. [ACHIEVEMENT a]
• A standard process is developed and maintained that includes the
fundamental process elements.
•…
GP 3.1.3 Identify the roles and competencies, responsibilities, and authorities

for performing the standard process. [ACHIEVEMENT c]
• Process performance roles are identified
• Competencies for performing the process are identified.
• Authorities necessary for executing responsibilities are identified.
Seite 95
Changes to Generic Practices – CL3 (2/2)
GP 3.1.5 Determine suitable methods and measures to monitor the
effectiveness and suitability of the standard process. [ACHIEVEMENT e]
• Methods and measures for monitoring the effectiveness and suitability of the
process are determined.
•…
PA 3.2 Process deployment attribute

The process deployment attribute is a measure of the extent to which the
standard process is effectively deployed as a defined process to achieve its
process outcomes. As a result of full achievement of this attribute:
In addition the following Notes for GP 3.2.6 Collect and analyze data about
performance of the process to demonstrate its suitability and effectiveness.
[ACHIEVEMENT f]
NOTE 1: Data about process performance may be qualitative or quantitative.
Seite 96
• GP 4.1.1 Identify business goals. • GP 4.1.1 Identify process information
• GP 4.1.2 Establish process information needs, in relation with business goals.
needs. • GP 4.1.2 Derive process measurement
• GP 4.1.3 Derive process measurement objectives from process information
objectives from process information needs. needs.
• GP 4.1.4 Identify measurable relationships • GP 4.1.3 Establish quantitative objectives
between process elements. for the performance of the defined
• GP 4.1.5 Establish quantitative objectives. process, according to the alignment of the
process with the business goals.
• GP 4.1.6 Identify process measures that
support the achievement of the quantitative • GP 4.1.4 Identify product and process
objectives. measures that support the achievement of
the quantitative objectives for process
• GP 4.1.7 Collect product and process performance.
measurement results through performing
the defined process. • GP 4.1.5 Collect product and process
measurement results through performing
the defined process.
• GP 4.1.6 Use the results of the defined
measurement to monitor and verify the
achievement of the process performance
objectives.
Seite 97
GP 4.1.4 Identify measurable relationships between process elements.

[ACHIEVEMENT a, d]
Identify the relationships between process elements, which contribute to the
derived measurement objectives.
Seite 98
Changes to Generic Practices – CL5
• GP 5.1.1 Define the process innovation • GP 5.1.1 Define the process improvement
objectives for the process that support the objectives for the process that support the
relevant business goals. relevant business goals.
• GP 5.1.2 Analyze data of the process to • GP 5.1.2 Analyse measurement data of the
identify opportunities for innovation. process to identify real and potential
• GP 5.1.3 Analyze new technologies and variations in the process performance.
process concepts to identify opportunities • GP 5.1.3 Identify improvement
for innovation. opportunities of the process based on
• GP 5.1.4 Define and maintain an innovation and best practices.
implementation strategy based on • GP 5.1.4 Derive improvement
innovation vision and objectives. opportunities of the process from new
technologies and process concepts. Impact
of new technologies on process
performance is identified and evaluated.
• GP 5.1.5 Define an implementation
strategy based on long-term improvement
vision and objectives.
Seite 99
And finally…
Seite 100
Need more advice?
• Meet the experts:
• We offer free half day public seminars. Our experts will explain the changes and
answer your individual questions.
• For English language introductions see
www.kuglermaag.com/aspice-intro
• For German language introductions see
www.kuglermaag.de/aspice-intro
• Schedule a one day inhouse seminar:
• Our experts will explain the changes, answer your questions, but also look at your
individual situation and plan how to proceed to upgrade your organization to
Automotive SPICE 3.0 compliance.
• For update trainings see
www.kuglermaag.com/aspice-update (English version)
• www.kuglermaag.de/aspice-update (German version)
• Any other questions and concerns?
• See “contact information”
Seite 101
About the Authors
Fabio Bella
• Process Director at Kugler Maag Cie, Country Manager for Italy
• intacsTM advisory board member
• TüV Rheinland Functional Safety Engineer (Automotive)
Dr. Klaus Hoermann

• Principal and Partner at Kugler Maag Cie
• Leader of the intacsTM working group “Exams”
• CMMI® SCAMPI Lead Appraiser (CMMI Institute-Certified)
• CMMI® Instructor (CMMI Institute-Certified)
• Scrum Master (Scrum.org certified)
Bhaskar Vanamali
• Process Director at Kugler Maag Cie
• Member of the VDA AK13 (working on Automotive SPICE), member of the
SC7 WG10 (working on ISO 15504/ISO 33000)
• SixSigma Green Belt
Seite 102 • Volkswagen-certified Software Quality Improvement Leader (SQIL)
Contact information
KUGLER MAAG CIE GmbH

Leibnizstr. 11
70806 Kornwestheim, Germany
information@kuglermaag.com
www.kuglermaag.de
Phone +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
Phone +1 248 687 1210
KUGLER MAAG CIE Central Eastern Europe

cee@kuglermaag.com
Phone +48 513 144 297
Seite 103
Thank you for your
attention.
Questions? Comments?
© KUGLER MAAG CIE GmbH
Seite 104

2 11automotive Spicev3 0update 160107150411

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

2 11automotive Spicev3 0update 160107150411

Uploaded by

Copyright:

Available Formats

Automotive SPICE 3.

• Married with 2 children

Qualification & Experience

Dr. Klaus Hoermann

• Married with 4 children

Qualification & Experience

• Timeline of publications by AK13 and transition time

Entry ASPICE 3.0 release BG Volume release End of transition

iNTACS Trainings Update of trainings to Update of trainings to the None

Chapter 5 Process capability levels and

Annex C Terminology Update to recent standards, introduction of new terminology

Added the new major concepts relative to Annex D of AS 2.5

Annex D Key Koncepts

HWE.2 HWE.3 SWE.2 SWE.5 MEE.2 MEE.3

Software Engineering Process Group (SWE) items

• A system architecture specifies the elements of the system.

Software SWE.4 BP5 Static varification

SYS.2.BP5: Verification criteria

SWE.1.BP5: Verification criteria

SWE.3.BP4: Evaluate SWE.4.BP2: Criteria for unit verification

• Evaluation of alternative solutions is required for system and software

• Compliance with an architectural design (SWE.5.BP3) means that the

• SYS.3.BP5: Evaluate alternative system architectures. Define evaluation

Process specific plan

• Capability Level 2 or higher:

• BPs for proceeding have been deleted.

AK13 has not decided whether it is going to be part of the

Bewertung pro Prozessinstanz

Vertikale Aggregation Vertikale Aggregation

• See Key concepts (previous slides)

Outcomes V2.5 Outcomes V3.0

• Mainly rewording but no new content

Base Practices V2.5 Base Practices V3.0

1 Define the scope of work. 1 Define the scope of work.

2 Define project life cycle 2 Define project life cycle

7 Identify and monitor project interfaces

10 Monitor project attributes 9 Ensure consistency

12 Act to correct deviations

Outcomes V2.5 Outcomes V3.0

• Focus is more on checking conformance and ensuring resolution of non-conformances

Base Practices V2.5

1 Develop project quality assurance strategy

2 Develop and maintain an organisation structure

9 Ensure resolution on non-conformances

10 Implement an escalation mechanism

• Overall simplifying the process with similar content

Outcomes V2.5 Outcomes V3.0

1 a configuration management strategy is developed; 1 a configuration management strategy is developed;

• Some rewording but in essence the outcomes have not changed

Base Practices V2.5 Base Practices V3.0

1 Develop a configuration management strategy 1 Develop a configuration management strategy

2 Identify configuration items 2 Identify configuration items

3 Establish a configuration management system 3 Establish a configuration management system

4 Establish branch management strategy 4 Establish branch management strategy

5 Establish baselines 5 Control modifications and releases

6 Maintain configuration item description 6 Establish baselines

7 Control modifications and releases 7 Report configuration status

9 Report configuration status 9 Manage the storage of configuration items and

11 Manage the backup, storage, archiving, handling

• Overall simplifying the process with similar content

Outcomes V2.5 Outcomes V3.0

1 a problem management strategy is developed; 1 a problem resolution management strategy is

• Some rewording but in essence the outcomes have not changed