Automotive SPICE 3 - KUGLER MAAG · •Automotive SPICE 3.0 Assessments are acknowledged as EE-1 if...

Seite 1

© KUGLER MAAG CIE GmbH

Automotive SPICE 3.0 What is new and what has changed? Fabio Bella Klaus Hoermann Bhaskar Vanamali Steffen Herrmann Markus Müller Dezember 2015

Version 2015-12-05

About the Trainer: Markus Mueller

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

• 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

Seite 3

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)

About the trainer: Bhaskar Vanamali

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

• 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

Seite 5

• Executive Summary

• Introduction

• Overview of the Changes

• Changes in Detail

• And Finally

• Need more Advice?

• Contact Information

Contents

Seite 6

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

Executive Summary

Seite 7

Introduction

Seite 8

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

Basic Facts and Acknowledgements

Seite 9

• Employees of Volkswagen, Continental, Schäffler, ZF, Brose, Ford, BMW, Daimler, Knorr Bremse

• Secretary: Bhaskar Vanamali (KMC)

• Contact VDA QMC: Dr. Jan Morenzin

Members VDA AK13

Seite 10

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

Automotive SPICE 3.0 Deployment and Timeline

Seite 11

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

Blue/Gold Volume and ASPICE 3.0 - Deployment and Timeline (1/2)

Automotive

SYS

July 2015

Release

Automotive

SPICE 3.0

End of 2016

Release

Blue/Gold

Volume

End of 2017

Period I Period II =

Transition Period Period III

Seite 12

Blue/Gold Volume and ASPICE 3.0 - Deployment and Timeline (2/2)

Topic Period I Period II Period III

Entry Exit

ASPICE 3.0 release BG Volume release

BG Volume release End of transition (~1y)

End of transition Open end

iNTACS Trainings

Update of trainings to ASPICE 3.0

Update of trainings to the BG Volume

None

Certified assessors No implication for any grade

Upgrade training needed for Competent and Principal No implication for Provisional assessors

Still Upgrade-Training needed for Competent and Principal No implication yet for Provisional assessors

Additional trainings Update Trainings possible, but no official trainings

iNTACS- and VDA WG13-approved upgrade trainings

Still iNTACS- and VDA WG13-approved upgrade trainings

Provisional assessors No specific requirements Upgrade training in discussion but not clear how to enforce that

Upgrade training in discussion but not clear how to enforce that

Assessments Assessment for any PAM 2.3 to 3.0 are possible

Assessments for PAM 3.0 only accepted if Lead assessor underwent upgrade training

In discussion: For German OEMs assessments have to be performed based on PAM 3.0

Seite 13

• 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

Rules for the Period between July 2015 until the Guidelines are published – Period I

Seite 14

• 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

Rules for the Period between Guidelines are published until the end of the Transition Period (date tbd) – Period II

Seite 15

• 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

Rules for the time after the end of the Transition Period (date tbd) – Period III

Seite 16

Overview of the Changes

Seite 17

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

Motivation for Updating Automotive SPICE

Seite 18

Chapter Change

Chapter 1 Introduction Editorial adaption to 33000 series, notes regarding combined PRM/PAM in this document

Chapter 2 Statement of compliance Adaption to 33000 series

Chapter 3 Introduction Optimized for better understanding and adapted to 33000 series.

Chapter 4 Process reference model and performance indicators (Level 1)

The acronym ENG changed to SYS and SWE, the structure of the processes has changed, Base Practices of the HIS Scope have been reworked.

Chapter 5 Process capability levels and process attributes

Adapted to the measurement framework of ISO/IEC 33020

Annex A Conformity of the process assessment and reference model

Conformity statement adapted to ISO/IEC 33004:2015.

Annex B Work product characteristics Modifications on work product characteristics according to the changes in chapter 4.

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

Annex D Key Concepts Added the new major concepts relative to Annex D of AS 2.5 Traceability diagram (Annex E PAM 2.5) is now in Annex D

Annex E Reference Standards Updated references to other standards

Overview of Main Changes (Document view)

Seite 19

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”

Overview of Main Changes

Seite 20

Structural Changes in Version 3.0: “Plug-In Concept”

SWE.1

SWE.2

SWE.3

SWE.5

SWE.4

SWE.6

SYS.1

SYS.2

SYS.3 SYS.4

SYS.5

Syst

em

Le

vel

HWE.1

HWE.2 HWE.3

HWE.4 MEE.1

MEE.2 MEE.3

MEE.4

Do

mai

n L

eve

l

MA

N.3

AC

Q.4

SUP.

1

SUP.

8

SUP.

9

SUP.

10

SYS System Engineering SWE Software Engineering HWE Hardware Engineering MEE Mechanical Engineering

part of the Automotive SPICE® 3.0 PAM

not developed by VDA, not included in Automotive SPICE® 3.0 PAM

Seite 21

Structural Changes in Version 3.0: The Tip of the V

SYS.2 System Requirements Analysis

SYS.3 System Architectural Design

SWE.1 SW Requirements Analysis

SWE.2 SW Architectural Design

SWE.3 SW Detailed Design

and Unit Construction

SWE.5 SW Integration

and Integration Test

SWE.6 SW Qualification Test

SYS.4 System Integration and

Integration Test

SYS.5 System Qualification Test

SWE.4 SW Unit Verification

Seite 22

Terms “Element”, “Component”, “Unit”, and “Item”

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

System Engineering Process Group (SYS)

SYS.1 Requirements Elicitation

SYS.2 System Requirements

Analysis


Software Engineering Process Group (SWE)



Integration Test

SWE.1 Software Requirements

Analysis

SWE.2 Software Architectural

Design

SWE.3 Software Detailed Design


SWE.6 Software Qualification Test

SWE.5 Software Integration and

Integration Test

SWE.4 Software Unit Verification

elements

components

units units

items

Seite 23

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

Traceability and Consistency

Seite 24

Traceability and Consistency

Stakeholder requirements

System Integration test specification

Software qualification test specification

Software integration Test specification

System qualification test specification

SYS.4 BP7 SYS.4 BP8

SYS.5 BP5 SYS.5 BP6

SYS.3 BP6 SYS.3 BP7

SYS.2 BP7 SYS.2 BP8

SUP.10 BP8

SYS.5 BP5

SWE.4 BP5 SWE.4 BP5 SWE.4 BP6

SWE.1 BP7 SWE.1 BP8

SWE.3 BP5 SWE.3 BP6

SWE.2 BP7 SWE.2 BP8

SWE.6 BP5 SWE.6 BP6

SWE.5 BP7 SWE.5 BP8

SWE.3 BP5 SWE.3 BP6

SWE.3 BP5 SWE.3 BP6

SWE.1 BP7 SWE.1 BP8

SWE.4 BP5

SYS.4 BP7

SWE.6 BP5

SWE.5 BP7

To affected work products

Test cases

Test cases

Test cases

Test cases

System requirements

Unit test specification

Software detailed design

Software architecture

Software requirements

Change request

Unit test results

Software Integration test result

Software qualification test results

System integration test results

System qualification test results

System architecture

Software units

Static varification results

Consistency Bidirectional traceability

Seite 25

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

“Agree” and “Summarize and Communicate”











Integration Test



BP: “communicate agreed…” BP: “summarize and communicate…”

Seite 26

“Evaluate”, “Verification Criteria” and “Ensuring compliance”











Integration Test



SUP.

2

Ver

ific

atio

n

SYS.2.BP5: Verification criteria

SWE.1.BP5: Verification criteria

SYS.5.BP2: Ensure compliance

SYS.3.BP3: Ensure compliance

SWE.6.BP2: Ensure compliance

SWE.5.BP3: Ensure compliance

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

Seite 27

• 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 28

• 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 29

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

New practice in System Architectural Design : Evaluate alternative system architectures

Seite 30

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

The Relation Between “Strategy” and “Plan”

BP1: Develop Strategy

Plan

Process specific plan WP 08-nn

Generic plan WP 08-00

CL >=2

CL =1

Which is documented in the

related WP

BP 1 defines the strategy…

Seite 31

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

The Relation Between “Strategy” and “Plan”

Seite 32

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

No Separation of PAM and PRM in v3.0

Seite 33

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 34

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 aspects of achievement of the process attribute may be unpredictable.

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. 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 significant achievement of, the defined process attribute in the assessed process. Some weaknesses related to this process attribute may exist in the assessed process.

Seite 35

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 36

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 37

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.

Example of a Rating Method

Seite 38

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

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

Bew

ertu

ng

der

Ind

ikat

ore

n

< -

-- >

Prozessinstanzen

< --- >

Hori-

zontal

Horizontale Aggregation

page 38

Hori-

zontal

Horizontale

Aggregation

P

L

L

F

L

P

Seite 39

Vertikale Aggregation

page 39

Vertikale Aggregation Vertikale Aggregation

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

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

Bew

ertu

ng

der

Ind

ikka

tore

n

< -

-- >

Bewertung pro Prozessinstanz

< --- >

Vertikale

Aggregation P L P L P L

Seite 40

Changes in Detail

Seite 41

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 42

Outcomes V2.5

As a result of successful implementation of this process

1 the scope of the work for the project is defined;

2 the feasibility of achieving the goals of the project with

available resources and constraints is evaluated;

3 the tasks and resources necessary to complete the

work are sized and estimated;

4 interfaces between elements in the project, and with

other project and organizational units, are identified

and monitored;

5 plans for the execution of the project are developed,

implemented and maintained;

6 progress of the project is monitored and reported; and

7 actions to correct deviations from the plan and to

prevent recurrence of problems identified in the project

are taken when project goals are not achieved.

Outcomes V3.0


1 the scope of the work for the project is defined;

2 the feasibility of achieving the goals of the project with

available resources and constraints is evaluated;

3 the activities and resources necessary to complete the

work are sized and estimated;

4 interfaces within the project, and with other projects

and organizational units, are identified and monitored;

5 plans for the execution of the project are developed,

implemented and maintained;

6 progress of the project is monitored and reported; and

7 corrective action is taken when project goals are not

achieved, and recurrence of problems identified in the

project is prevented.

• Mainly rewording but no new content

MAN.3 Project Management – Outcomes

43 Seite 43

Base Practices V2.5

1 Define the scope of work.

2 Define project life cycle

3 Determine and maintain estimates for project

Attributes

4 Define project activities

5 Define skill needs

6 Define and maintain project schedule

7 Identify and monitor project interfaces

8 Establish project plan

9 Implement the project plan

10 Monitor project attributes

11 Review and report progress of the project

12 Act to correct deviations

Base Practices V3.0

1 Define the scope of work.

2 Define project life cycle

3 Evaluate feasibility of the project

4 Define, monitor and adjust project activities

5 Determine, monitor und adjust project estimates and

resources

6 Ensure required skills, knowledge, and experience

7 Identify, monitor and adjust project interfaces and

agreed commitments

8 Define, monitor and adjust project schedule

9 Ensure consistency

10 Review and report progress of the project

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

MAN.3 Project Management – Base Practices

44 Seite 44

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

45 Seite 45

Outcomes V2.5


1 a strategy for conducting quality assurance is

developed, implemented and maintained;

2 quality assurance is performed independent of the

activity or project being performed;

3 evidence of quality assurance is produced and

maintained;

4 adherence of products, processes and activities to

agreed requirements are verified, documented, and

communicated to the relevant parties;

5 problems and/or non-conformance with agreement

requirements are identified, recorded, communicated

to the relevant parties, tracked and resolved; and

6 quality assurance has the independence and authority

to escalate problems to appropriate levels of

management.

Outcomes V3.0


1 a strategy for performing quality assurance is

developed, implemented, and maintained;

2 quality assurance is performed independently and

objectively without conflicts of interest;

3 non-conformances of work products, processes, and

process activities with relevant requirements are

identified, recorded, communicated to the relevant

parties, tracked, resolved, and further prevented;

4 conformance of work products, processes and

activities with relevant requirements is verified,

documented, and communicated to the relevant

parties;

5 authority to escalate non-conformances to appropriate

levels of management is established; and

6 management ensures that escalated non-

conformances are resolved.

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

SUP.1 Quality Assurance – Outcomes

46 Seite 46

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

and report Independentely

3 Develop and implement a plan for project quality

assurance based on a quality assurance strategy

4 Maintain evidence of quality assurance

5 Assure quality of work products

6 Assure quality of process activities

7 Track and record quality assurance activities

8 Report quality assurance activities and results

9 Ensure resolution on non-conformances

10 Implement an escalation mechanism

Base Practices V3.0

1 Develop project quality assurance strategy

2 Assure quality of work products

3 Assure quality of process activities

4 Summarize and communicate quality assurance

activities and results

5 Ensure resolution of non-conformances

6 Implement an escalation mechanism

SUP.1 Quality Assurance – Base Practices

47 Seite 47

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.

48 Seite 48

Outcomes V2.5


1 a configuration management strategy is developed;

2 all items generated by a process or project are

identified, defined and baselined according to the

Configuration management strategy;

3 modifications and releases of the items are controlled;

4 modifications and releases are made available to

affected parties;

5 the status of the items and modification requests are

recorded and reported;

6 the completeness and consistency of the items is

ensured; and

7 storage, handling and delivery of the items are

controlled.

Outcomes V3.0


1 a configuration management strategy is developed;

2 all configuration items generated by a process or

project are identified, defined and baselined according

to the configuration management strategy;

3 modifications and releases of the configuration items

are controlled;

4 modifications and releases are made available to

affected parties;

5 the status of the configuration items and modifications

is recorded and reported;

6 the completeness and consistency of the baselines is

ensured; and

7 storage of the configuration items is controlled.

• Some rewording but in essence the outcomes have not changed

SUP.8 Configuration Management – Outcomes

49 Seite 49

Base Practices V2.5

1 Develop a configuration management strategy

2 Identify configuration items

3 Establish a configuration management system

4 Establish branch management strategy

5 Establish baselines

6 Maintain configuration item description

7 Control modifications and releases

8 Maintain configuration item history

9 Report configuration status

10 Verify the information about configured items

11 Manage the backup, storage, archiving, handling

and delivery of configuration items

Base Practices V3.0

1 Develop a configuration management strategy

2 Identify configuration items

3 Establish a configuration management system

4 Establish branch management strategy

5 Control modifications and releases

6 Establish baselines

7 Report configuration status

8 Verify the information about configured items

9 Manage the storage of configuration items and

baselines

SUP.8 Configuration Management – Base Practices

50 Seite 50

Changes in V3.0 – SUP.8 Configuration Management

• Overall simplifying the process with similar content

• No new content

51 Seite 51

Outcomes V2.5


1 a problem management strategy is developed;

2 problems are recorded, identified and classified;

3 problems are analysed and assessed to identify

acceptable solution(s);

4 problem resolution is implemented;

5 problems are tracked to closure; and

6 the status of all problem reports is known

Outcomes V3.0


1 a problem resolution management strategy is

developed;

2 problems are recorded, uniquely identified and

classified;

3 problems are analyzed and assessed to identify an

appropriate solution;

4 problem resolution is initiated;

5 problems are tracked to closure; and

6 the status of problems and their trend are known


SUP.9 Problem Resolution Management – Outcomes

52 Seite 52

Base Practices V2.5

1 Develop a problem resolution management strategy

2 Establish a consistent problem resolution

management proceeding

3 Identify and record the problem

4 Investigate and diagnose the cause and the impact

of the problem

5 Execute urgent resolution action, where necessary

6 Raise alert notifications, where necessary

7 Initiate change request

8 Track problems to closure

9 Analyze problem trends

Base Practices V3.0

1 Develop a problem resolution management strategy

2 Identify and record the problem

3 Record the status of problems

4 Diagnose the cause and determine the impact of the

problem

5 Authorize urgent resolution action

6 Raise alert notifications

7 Initiate problem resolution

8 Track problems to closure

9 Analyze problem trends

SUP.9 Problem Resolution Management – Base Practices

53 Seite 53

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.

54 Seite 54

Outcomes V2.5


1 a change management strategy is developed;

2 requests for changes are recorded and identified;

3 dependencies and relationships to other change

requests are identified;

4 criteria for confirming implementation of the change

request are defined;

5 requests for change are analysed, prioritized, and

resource requirements estimated;

6 changes are approved on the basis of priority and

availability of resources;

7 approved changes are implemented and tracked to

closure; and

8 the status of all change requests is known

Outcomes V3.0


1 a change request management strategy is developed;

2 requests for changes are recorded and identified;

3 dependencies and relationships to other change

requests are identified;

4 criteria for confirming implementation of change

requests are defined;

5 requests for change are analyzed, and resource

requirements are estimated;

6 changes are approved and prioritized on the basis of

analysis results and availability of resources;

7 approved changes are implemented and tracked to

closure;

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

SUP.10 Change Request Management – Outcomes

55 Seite 55

Base Practices V2.5

1 Develop a change request management strategy

2 Establish a consistent change request management

Proceeding

3 Identify and record the change request

4 Record the status of change requests

5 Establish the dependencies and relationships to

other change requests

6 Assess the impact of the change

7 Analyze and prioritize change requests

8 Approve change requests before implementation

9 Identify and plan the verification and validation

activities to be performed for implemented changes

10 Schedule and allocate the change request

11 Review the implemented change

12 Change requests are tracked until closure

Base Practices V3.0

1 Develop a change request management strategy

2 Identify and record the change requests

3 Record the status of change requests

4 Analyze and assess change requests

5 Approve change requests before implementation

6 Review the implementation of change requests

7 Track change requests to closure

8 Establish bidirectional traceability

Has been moved to Level 2 New BP/aspect of SUP.10

SUP.10 Change Request Management – Base Practices

56 Seite 56

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.

57 Seite 57

Outcomes V2.5


1 joint activities between the customer and the supplier

are performed as needed;

2 all information, agreed upon for exchange, is

transferred between the supplier and the customer;

3 information on progress is exchanged regularly with

the supplier;

4 performance of the supplier is monitored against the

agreed requirements; and

5 changes to the agreement, if needed, are negotiated

between the customer and the supplier and

documented with the agreement

Outcomes V3.0


1 joint activities, as agreed between the customer and

the supplier, are performed as needed;

2 all information, agreed upon for exchange, is

communicated regularly between the supplier and

customer;

3 performance of the supplier is monitored against the

agreements; and

4 changes to the agreement, if needed, are negotiated

between the customer and the supplier and

documented in the agreement


ACQ.4 Supplier Monitoring – Outcomes

58 Seite 58

Base Practices V2.5

1 Agree on joint processes and joint interfaces

2 Exchange all relevant information

3 Review technical development with the supplier

4 Review progress of the supplier

5 Track open items


7 Agree on changes

Base Practices V3.0

1 Agree on and maintain joint processes

2 Exchange all agreed information




Linked to 1, 3, 4 and 5

ACQ.4 Supplier Monitoring – Base Practices

59 Seite 59

Base Practices V2.5

1 Agree on joint processes and joint interfaces

2 Exchange all relevant information



5 Track open items


7 Agree on changes

Base Practices V3.0

1 Agree on and maintain joint processes

2 Exchange all agreed information




Linked to 1, 3, 4 and 5

ACQ.4 Supplier Monitoring – Base Practices

60 Seite 60

Changes in V3.0 – ACQ.4 Supplier Monitoring

• No major changes, but the approach was simplified

Seite 61

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

Group Work / Discussion

62 Seite 62

Outcomes V2.5 – ENG.2


1 a defined set of system requirements is established;

2 system requirements are categorized and analyzed for

correctness and testability;

3 the impact of the system requirements on the

operating environment is evaluated;

4 prioritization for implementing the system requirements

is defined;

5 the system requirements are approved and updated as

needed;

6 consistency and bilateral traceability are established

between customer requirements and system

requirements;

7 changes to the customer’s requirements baseline are

evaluated for cost, schedule and technical impact; and

8 the system requirements are communicated to all

affected parties and baselined

Outcomes V3.0


1 a defined set of system requirements is established;

2 system requirements are categorized and analyzed for

correctness and verifiability;

3 the impact of system requirements on the operating

environment is analyzed;

4 prioritization for implementing the system requirements

is defined;

5 the system requirements are updated as needed;

6 consistency and bidirectional traceability are

established between stakeholder requirements and

system requirements;

7 the stakeholder requirements are evaluated for cost,

schedule and technical impact; and

8 the system requirements are agreed and

communicated to all affected parties


SYS.2 System Requirements Analysis – Outcomes

63 Seite 63

Base Practices V2.5 – ENG.2

1 Identify System Requirements

2 Analyze system requirements

3 Determine the impact on the operating environment

4 Prioritize and categorize system requirements

5 Evaluate and update system requirements

6 Ensure consistency and bilateral traceability of

customer requirements to system requirements

7 Communicate system requirements

Base Practices V3.0

1 Specify system requirements

2 Structure system requirements

3 Analyze system requirements

4 Analyze the impact on the operating environment

5 Develop verification criteria



8 Communicate agreed system requirements

Linked to 1-8

SYS.2 System Requirements Analysis – Base Practices

64 Seite 64

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

65 Seite 65



1 a system architectural design is defined that identifies

the elements of the system and meets the defined

systems requirements;

2 the system requirements are allocated to the elements

of the system;

3 internal and external interfaces of each system

element are defined;

4 verification between the system requirements and the

system architectural design is performed;


between system requirements and system

architectural design; and

6 the system requirements, the system architectural

design, and their relationships are baselined and

communicated to all affected parties.

Outcomes V3.0


1 a system architectural design is defined that identifies

the elements of the system;

2 the system requirements are allocated to the elements

of the system;

3 the interfaces of each system element are defined;

4 the dynamic behavior objectives of the system

elements are defined;


established between system requirements and system

architectural design; and

6 the system architectural design is agreed and


• New aspect with dynamic behavior but other than that the outcomes have not changed in essence

New aspect of system architecture

SYS.3 System Architectural Design – Outcomes

66 Seite 66


1 Define system architectural design

2 Allocate System Requirements

3 Define Interfaces


5 Verify System Architectural Design


system requirements to system architectural design

7 Communicate system architectural design

Base Practices V3.0

1 Develop system architectural design

2 Allocate system requirements

3 Define interfaces of system elements

4 Describe dynamic behavior

5 Evaluate alternative system architectures



8 Communicate agreed system architectural design

New aspects of the system architecture process

SYS.3 System Architectural Design – Base Practices

67 Seite 67

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

68 Seite 68



1 a system integration and system integration test strategy is

developed for system elements consistent with the system

architectural design according to the priorities and

categorization of the system requirements;

2 a test specification for system integration test is developed

to verify compliance with the system architectural design,

including the interfaces between system elements;

3 an integrated system is integrated as defined by the

integration strategy;

4 the integrated system elements are verified using the test

cases;

5 results of system integration testing are recorded;


between system architectural design and system integration

test specification including test cases; and

7 a regression strategy is developed and applied for re-

testing the system elements when changes are made

Outcomes V3.0


1 a system integration strategy consistent with the project

plan, the release plan and the system architectural design

is developed to integrate the system items;

2 a system integration test strategy including the regression

test strategy is developed to test the system item

interactions;

3 a specification for system integration test according to the

system integration test strategy is developed that is suitable

to provide evidence for compliance of the integrated system

items with the system architectural design, including the

interfaces between system items;

4 system items are integrated up to a complete integrated

system according to the integration strategy;

5 test cases included in the system integration test

specification are selected according to the system

integration test strategy and the release plan;

6 system item interactions are tested using the selected test

cases and the results of system integration testing are

recorded;

7 consistency and bidirectional traceability between the

elements of the system architectural design and test cases

included in the system integration test specification and

bidirectional traceability between test cases and test results

is established; and

8 results of the system integration test are summarized and


The appropriate test cases need to be selected to support the test strategy (incl. the regression test strategy)

SYS.4 System Integration and Integration Test – Outcomes

69 Seite 69


1 Develop system integration strategy

2 Develop system integration test strategy

3 Develop a test specification for system integration

4 Integrate system elements

5 Verify the integrated system

6 Record the results of system integration testing


system architectural design to the system integration

test specification

8 Develop regression testing strategy and perform

regression testing

Base Practices V3.0

1 Develop system integration strategy

2 Develop system integration test strategy including

regression test strategy

3 Develop specification for system integration test

4 Integrate system items

5 Select test cases

6 Perform system integration test



9 Summarize and communicate results

New aspects of the system integration and integration test process

SYS.4 System Integration and Integration Test – Base Practices

70 Seite 70

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


71 Seite 71



1 a strategy is developed to test the system according to

the priorities of and categorization the system

requirements;

2 a test specification for system test of the integrated

system is developed that demonstrates compliance

with the system requirements;

3 the integrated system is verified using the test cases;

4 results of system testing are recorded;


between system requirements and the system test

specification including test cases; and

6 a regression test strategy is developed and applied for

re-testing the integrated system when a change in

system elements is made

Outcomes V3.0


1 a system qualification test strategy including

regression test strategy consistent with the project plan

and release plan is developed to test the integrated

system;

2 a specification for system qualification test of the

integrated system according to the system qualification

test strategy is developed that is suitable to provide

evidence for compliance with the system requirements;

3 test cases included in the system qualification test

specification are selected according to the system

qualification test strategy and the release plan;

4 the integrated system is tested using the selected test

cases and the results of system qualification test are

recorded;


established between system requirements and test

cases included in the system qualification test

specification and between test cases and test results;

and

6 results of the system qualification test are summarized

and communicated to all affected parties


SYS.5 System Qualification Test – Outcomes

72 Seite 72


1 Develop system test strategy

2 Develop test specification for system test

3 Verify integrated system

4 Record the results of system testing


system requirements to the systems test

specification

6 Develop system regression test strategy and

perform testing

Base Practices V3.0

1 Develop system qualification test strategy including


2 Develop specification for system qualification test

3 Select test cases

4 Test integrated system




New aspects of the system qualification test process

SYS.5 System Qualification Test – Base Practices

73 Seite 73

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


74 Seite 74



1 the software requirements to be allocated to the

software elements of the system and their interfaces

are defined;

2 software requirements are categorized and analyzed

for correctness and testability;

3 the impact of software requirements on the operating

environment is evaluated;

4 prioritization for implementing the software

requirements is defined;

5 the software requirements are approved and updated

as needed;


between system requirements and software

requirements; and consistency and bilateral traceability

are established between system architectural

design and software requirements;

7 changes to the software requirements are evaluated

for cost, schedule and technical impact; and

8 the software requirements are baselined and


Outcomes V3.0


1 the software requirements to be allocated to the

software elements of the system and their interfaces

are defined;

2 software requirements are categorized and analyzed

for correctness and verifiability;

3 the impact of software requirements on the operating

environment is analyzed;

4 prioritization for implementing the software

requirements is defined;

5 the software requirements are updated as needed;


established between system requirements and

software requirements; and consistency and

bidirectional traceability are established between

system architectural design and software

requirements;

7 the software requirements are evaluated for cost,

schedule and technical impact; and

8 the software requirements are agreed and



SWE.1 Software Requirements Analysis – Outcomes

75 Seite 75


1 Identify software requirements

2 Analyze software requirements

3 Determine the impact on the operating environment

4 Prioritize and categorize software requirements

5 Evaluate and update software requirements


system requirements to software requirements


system architectural design to software requirements

8 Communicate software requirements

Base Practices V3.0

1 Specify software requirements

2 Structure software requirements

3 Analyze software requirements

4 Analyze the impact on the operating environment




8 Communicate agreed software requirements

Linked to 1-8

SWE.1 Software Requirements Analysis – Base Practices

76 Seite 76

Changes in V3.0 – SWE.1 Software Requirements Analysis


• Verification criteria explicitly required in BP5

• Other than that mainly rewording

77 Seite 77



1 a software architectural design is defined that identifies

the components of the software and meets the defined

software requirements; (ENG.5 – 1)

2 the software requirements are allocated to the

elements of the software; (ENG.5 – 2)

3 internal and external interfaces of each software

component are defined; (ENG.5 – 3)

4 the dynamic behaviour and resource consumption

objectives of the software components are defined;

(ENG.5 – 4)


between software requirements and software

architectural design; (ENG.5 – 6)

Outcomes V3.0


1 a software architectural design is defined that identifies

the elements of the software;

2 the software requirements are allocated to the

elements of the software;

3 the interfaces of each software element are defined;

4 the dynamic behavior and resource consumption

objectives of the software elements are defined;


established between software requirements and

software architectural design; and

6 the software architectural design is agreed and

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

SWE.2 Software Architectural Design – Outcomes

78 Seite 78


1 Develop software architectural design (ENG.5 –

BP1)

2 Allocate software requirements (ENG.5 – BP2)

3 Define interfaces (ENG.5 – BP3)

4 Describe dynamic behaviour (ENG.5 – BP4)

5 Define resource consumption objectives (ENG.5 –

BP5)

6 Develop Verification Criteria (ENG.5 – BP7)

7 Verify Software Design (ENG.5 – BP8)


software requirements to software architectural

design (ENG.5 – BP9)

Base Practices V3.0

1 Develop software architectural design

2 Allocate software requirements

3 Define interfaces of software elements


5 Define resource consumption objectives

6 Evaluate alternative software architectures



9 Communicate agreed software architectural design

New aspects of the software architecture process

SWE.2 Software Architectural Design – Base Practices

79 Seite 79

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


80 Seite 80

Outcomes V2.5 – ENG.5/6


1 a detailed design is developed that describes software

units that can be implemented and tested; (ENG.5 – 5)

2 internal and external interfaces of each software

component are defined; (ENG.5 – 3)

3 the dynamic behaviour and resource consumption

objectives of the software components are defined;

(ENG.5 – 4)


between software architectural design and software

detailed design. (ENG.5 – 7)

5 software units defined by the software design are

produced (ENG.6 – 3)


between software detailed design and software units;

(ENG.6 – 6)

Outcomes V3.0


1 a detailed design is developed that describes software

units;

2 interfaces of each software unit are defined;

3 the dynamic behavior of the software units is defined;



software units; and consistency and bidirectional

traceability are established between software

architectural design and software detailed design; and

consistency and bidirectional traceability are

established between software detailed design and

software units;

5 the software detailed design and the relationship to the

software architectural design is agreed and

communicated to all affected parties; and

6 software units defined by the software detailed design

are produced

• Outcomes between SWE.2 and SWE.3 (formerly ENG.5 and ENG.6) have been rearranged

New aspect of software detailed design

SWE.3 Software Detailed Design and Unit Construction – Outcomes

81 Seite 81

Base Practices V2.5 – ENG.5/6

1 Develop detailed design (ENG.5 – BP6)

2 Define interfaces (ENG.5 – BP3)

3 Describe dynamic behaviour (ENG.5 – BP4)

4 Analyze software units (ENG.6 – BP2)

5 Prioritize and categorize software units (ENG.6 –

BP3)

6 Develop Verification Criteria (ENG.5 – BP7)

7 Verify Software Design (ENG.5 – BP8)


software architectural design to software detailed

design (ENG.5 – BP10)


software detailed design to software units (ENG.6 –

BP8)


software requirements to software units (ENG.6 –

BP9)

11 Develop software units (ENG.6 – BP4)

Base Practices V3.0

1 Develop software detailed design

2 Define interfaces of software units


4 Evaluate software detailed design



7 Communicate agreed software detailed design

8 Develop software units

New aspects of SWE.3 Linked to BPs 5 and 6

SWE.3 Software Detailed Design and Unit Construction – Base Practices

82 Seite 82

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


83 Seite 83



1 a unit verification strategy is developed for software

units consistent with the software design;

(ENG.6 – 1)

2 software units defined by the software design are

analyzed for correctness and testability;

(ENG.6 – 2)

3 software units are verified according to the unit

verification strategy;

(ENG.6 – 4)

4 results of unit verification are recorded; (ENG.6 – 5)

and


between software detailed design and software units;

(ENG.6 – 6)

Outcomes V3.0


1 a software unit verification strategy including

regression strategy is developed to verify the software

units;

2 criteria for software unit verification are developed

according to the software unit verification strategy that

are suitable to provide evidence for compliance of the

software units with the software detailed design and

with the non-functional software requirements;

3 software units are verified according to the software

unit verification strategy and the defined criteria for

software unit verification and the results are recorded;


established between software units, criteria for

verification and verification results; and

5 results of the unit verification are summarized and

communicated to all affected parties.

• Outcomes between SWE.3 and SWE.4 (formerly ENG.6) have been rearranged

New aspect of software unit verification

SWE.4 Software Unit Verification – Outcomes

84 Seite 84


1 Define a unit verification strategy (ENG.6 – BP1)

2 Analyze software units (ENG.6 – BP2)

3 Prioritize and categorize software units (ENG.6 –

BP3)

4 Develop unit verification criteria (ENG.6 – BP5)

5 Verify software units (ENG.6 – BP6)

6 Record the results of unit verification (ENG.6 – BP7)


software units to test specification for software units

(ENG.6 – BP10)

Base Practices V3.0

1 Develop software unit verification strategy including

regression strategy

2 Develop criteria for unit verification

3 Perform static verification of software units

4 Test software units




New aspects of the software unit verification process Covered in SWE.3

SWE.4 Software Unit Verification – Base Practices

85 Seite 85

Changes in V3.0 – SWE.4 Software Unit Verification

• New:


• All verification activities on Unit Level are covered in this process


86 Seite 86



1 a software integration and integration test strategy is

developed for software items consistent with the software

design according to the priorities and categorization of the

software requirements;

2 a test specification software integration is developed that

ensures compliance with the software architectural design,

software detailed design, allocated to the items;

3 software units and software items are integrated as defined by

the integration strategy;

4 integrated software items are verified using the test cases;

5 results of software integration testing are recorded;

6 consistency and bilateral traceability are established between

software architectural design and software detailed design to

software integration test specification including test cases; and

7 a regression strategy is developed and applied for re-

integrating and re-verifying software items when a change in

software items (including associated requirements, design and

code) occurs

Outcomes V3.0


1 a software integration strategy consistent with the project plan,

release plan and the software architectural design is

developed to integrate the software items;

2 a software integration test strategy including the regression

test strategy is developed to test the software unit and

software item interactions;

3 a specification for software integration test according to the

software integration test strategy is developed that is suitable

to provide evidence for compliance of the integrated software

items with the software architectural design, including the

interfaces between the software units and between the

software items;

4 software units and software items are integrated up to a

complete integrated software according to the integration

strategy;

5 Test cases included in the software integration test

specification are selected according to the software integration

test strategy, and the release plan;

6 integrated software items are tested using the selected test

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

the test cases included in the software integration test

specification and between test cases and test results; and

8 results of the software integration test are summarized and


New aspect of software integration and integration test • Some rewording

SWE.5 Software Integration and Integration Test – Outcomes

87 Seite 87


1 Develop software integration strategy

2 Develop software integration test strategy

3 Develop test specification for software integration

Test

4 Integrate software units and software items

5 Verify the integrated software

6 Record the results of software integration testing


software architectural design and software detailed

design to

software integration test specification

8 Develop regression testing strategy and perform

regression testing

Base Practices V3.0

1 Develop software integration strategy

2 Develop software integration test strategy including


3 Develop specification for software integration test

4 Integrate software units and software items

5 Select test cases

6 Perform software integration test




New aspects of the software integration and integration test process

SWE.5 Software Integration and Integration Test – Base Practices

88 Seite 88

Changes in V3.0 – SWE.5 Software Integration and Integration Test

• New:

• Selection of test cases based on the test strategy


89 Seite 89



1 a strategy is developed to test the integrated software

according to the priorities and categorization of the

software requirements;

2 a test specification for software test of the integrated

software is developed that demonstrates compliance

to the software requirements;

3 the integrated software is verified using the test cases;

4 results of software testing are recorded;


between software requirements and software test

specification including test cases; and

6 a regression test strategy is developed and applied for

re-testing the integrated software when a change in

software items occur

Outcomes V3.0


1 a software qualification test strategy including

regression test strategy consistent with the project plan

and release plan is developed to test the integrated

software;

2 a specification for software qualification test of the

integrated software according to the software

qualification test strategy is developed that is suitable

to provide evidence for compliance with the software

requirements;

3 test cases included in the software qualification test

specification are selected according to the software

qualification test strategy and the release plan;

4 the integrated software is tested using the selected

test cases and the results of software qualification test

are recorded;



software qualification test specification including test

cases and between test cases and test results; and

6 results of the software qualification test are

summarized and communicated to all affected parties

SWE.6 Software Qualification Test – Outcomes


90 Seite 90


1 Develop software test strategy

2 Develop test specification for software test

3 Verify integrated software

4 Record the results of software testing


software requirements to software test specification

6 Develop regression test strategy and perform

regression testing

Base Practices V3.0

1 Develop software qualification test strategy including


2 Develop specification for software qualification test

3 Select test cases

4 Test integrated software




New aspects of the software qualification test process

SWE.6 Software Qualification Test – Base Practices

91 Seite 91

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 92

Vers. 3.0 / ISO 330xx

• GP 2.1.1 Identify the objectives for the performance of the process.

• GP 2.1.2 Plan the performance of the process to fulfill the identified objectives.

• GP 2.1.3 Monitor the performance of the process against the plans.

• GP 2.1.4 Adjust the performance of the process.

• GP 2.1.5 Define responsibilities and authorities for performing the process.

• GP 2.1.6 Identify, prepare, and make available resources to perform the process according to plan.

• GP 2.1.7 Manage the interfaces between involved parties.

Vers. 2.5 / ISO 15504

• GP 2.1.1 Identify the objectives for the performance of the process.

• GP 2.1.2 Plan and monitor the performance of the process to fulfill the identified objectives.

• GP 2.1.3 Adjust the performance of the process.

• GP 2.1.4 Define responsibilities and authorities for performing the process.

• GP 2.1.5 Identify and make available resources to perform the process according to plan.

• GP 2.1.6 Manage the interfaces between involved parties.

Changes to Generic Practices - CL2 (1/3)

Seite 93

• 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 94

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 95

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.

Changes to Generic Practices – CL3 (1/2)

Seite 96

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.

Changes to Generic Practices – CL3 (2/2)

Seite 97


• GP 4.1.1 Identify business goals.

• GP 4.1.2 Establish process information needs.

• GP 4.1.3 Derive process measurement objectives from process information needs.

• GP 4.1.4 Identify measurable relationships between process elements.

• GP 4.1.5 Establish quantitative objectives.

• GP 4.1.6 Identify process measures that support the achievement of the quantitative objectives.

• GP 4.1.7 Collect product and process measurement results through performing the defined process.

Vers. 2.5 / ISO 15504

• GP 4.1.1 Identify process information needs, in relation with business goals.

• GP 4.1.2 Derive process measurement objectives from process information needs.

• GP 4.1.3 Establish quantitative objectives for the performance of the defined process, according to the alignment of the process with the business goals.

• GP 4.1.4 Identify product and process measures that support the achievement of the quantitative objectives for process performance.

• 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 98

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 99


• GP 5.1.1 Define the process innovation objectives for the process that support the relevant business goals.

• GP 5.1.2 Analyze data of the process to identify opportunities for innovation.

• GP 5.1.3 Analyze new technologies and process concepts to identify opportunities for innovation.

• GP 5.1.4 Define and maintain an implementation strategy based on innovation vision and objectives.

Vers. 2.5 / ISO 15504

• GP 5.1.1 Define the process improvement objectives for the process that support the relevant business goals.

• GP 5.1.2 Analyse measurement data of the process to identify real and potential variations in the process performance.

• GP 5.1.3 Identify improvement opportunities of the process based on innovation and best practices.

• GP 5.1.4 Derive improvement 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.

Changes to Generic Practices – CL5

Seite 100

And finally…

Seite 101

• 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”

Need more advice?

http://www.kuglermaag.com/aspice-intro



http://www.kuglermaag.de/aspice-intro



http://www.kuglermaag.com/aspice-update



http://www.kuglermaag.de/aspice-update



Seite 102

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 103

Contact information

KUGLER MAAG CIE GmbH Leibnizstr. 11 70806 Kornwestheim, Germany [email protected] 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 [email protected] www.kuglermaag.com

Phone +1 248 687 1210

KUGLER MAAG CIE Central Eastern Europe

[email protected]

Phone +48 513 144 297

Automotive SPICE 3 - KUGLER MAAG · •Automotive SPICE 3.0 Assessments are acknowledged as EE-1 if...

Documents

Transcript of Automotive SPICE 3 - KUGLER MAAG · •Automotive SPICE 3.0 Assessments are acknowledged as EE-1 if...