Title:

Automotive SPICE Process Reference Model

Automotive SIG 2010-05-10 RELEASED Automotive SIG \tpf\automotivesig\prm\v4.5

Author(s): Date: Status: Confidentiality: File Ref:

The SPICE User Group 2005-2010

Copyright Notice This document reproduces relevant material from ISO/IEC 15504:2003 Information Technology Process Assessment Part 2: Performing an assessment and ISO/IEC 15504:2006 Information Technology Process Assessment Part 5: An exemplar Process Assessment Model ISO/IEC 15504 Part 2 provides the following copyright release: Users of this part of ISO/IEC 15504 may freely reproduce relevant material as part of any Process Assessment Model, or as part of any demonstration of conformance with this international standard, so that it can be used for its intended purpose. ISO/IEC 15504 Part 5 provides the following copyright release: Users of this part of ISO/IEC 15504 may freely reproduce the detailed descriptions contained in the exemplar assessment model as part of any tool or other material to support the performance of process assessments, so that it can be used for its intended purpose. Permission has been obtained from ISO to incorporate the relevant material under the copyright release notice.
The SPICE User Group 2005-2010

The SPICE User Group 2005-2010

Distribution The Automotive SPICE PAM may be distributed under the following conditions: Distribution: The document must be distributed in whole as-is and at no cost. Derivative Works Derivative works: You may not alter, transform, or build upon this work without the prior consent of The SPICE User Group. Such consent may be given provided ISO copyright is not infringed. The detailed descriptions contained in this document may be incorporated as part of any tool or other material to support the performance of process assessments, so that this Process Assessment Model can be used for its intended purpose, provided that any such material is not offered for sale. Trademarks Automotive SPICE is a registered trademark of the Verband der Automobilindustrie e.V. (VDA).

The SPICE User Group 2005-2010

For further information about Automotive SPICE visit www.automotivespice.com or contact automotivespice@spiceusergroup.com .

The Procurement Forum Rond Point Schuman 6 B-1040 Brussels Belgium

The SPICE User Group 6 Wilmslow Road, Unit 50 Manchester M14 5TD United Kingdom

AUDI AG 85045 Ingolstadt Germany

BMW AG 80788 Munich Germany

Daimler AG 70435 Stuttgart Germany

Fiat Auto S.p.A. Corso Agnelli 200 10100 Torino Italy

Ford Werke GmbH 50725 Kln Germany

Jaguar/Land Rover Banbury Road Gaydon WARWICK CV35 0RR United Kingdom

Dr. Ing. h.c. F. Porsche Aktiengesellschaft 70435 Stuttgart Germany

Volkswagen AG 38436 Wolfsburg Germany

Volvo Car Corporation SE-405 31 Gteborg Sweden

The SPICE User Group 2005-2010

Document History

Version: Date: 4.0 4.1 4.2 4.3 4.4 4.5 2005-05-02 2005-06-24 2005-08-21 2007-05-05 2008-08-01 2010-05-08

By: AD AD AD AD AD AD

Notes: DRAFT RELEASE pending final editorial review Editorial review comments implemented Final checks implemented FORMAL RELEASE Revision following CCB FORMAL RELEASE Revision following CCB FORMAL RELEASE Revision following CCB FORMAL RELEASE

Release Notes Version 4.5 of the Process Reference Model incorporates changes regarding emphasising the use of this document in conjunction with the terminology in ISO/IEC 15504-1 significant editorial changes to the Software construction process (ENG.6) registered trademark notice. Version 4.5 of the Process Reference Model replaces version 4.4 of the Process Reference Model with immediate effect. Version 2.5 of the Process Assessment Model has been released at the same time and is aligned with Version 4.5 of the Process Reference Model. Any problems or change requests should be reported through the defined mechanism at the www.automotivespice.com web site. These will be addressed by the Change Control Board which meets every 6 months.

The SPICE User Group 2005-2010

Table of Contents 1 Scope ............................................................................................... 8

1.1 Introduction .................................................................................................. 8 1.2 Purpose ......................................................................................................... 8 1.3 Definitions ..................................................................................................... 9 1.4 Terminology .................................................................................................. 9 1.5 Applicable Documents............................................................................... 10 1.6 Warning ....................................................................................................... 10

Statement of compliance .............................................................. 11

2.1 Introduction ................................................................................................ 11 2.2 Primary Life Cycle Processes category ................................................... 12 2.3 Supporting Life Cycle Processes category ............................................. 14 2.4 Organizational Life Cycle Processes category........................................ 15

Process descriptions .................................................................... 16

3.1 Acquisition Process Group (ACQ) ............................................................ 16 3.1.1 ACQ.3 Contract agreement .................................................... 16 3.1.2 ACQ.4 Supplier monitoring ................................................... 16 3.1.3 ACQ.11 Technical requirements ........................................... 17 3.1.4 ACQ.12 Legal and administrative requirements .................. 18 3.1.5 ACQ.13 Project requirements ................................................ 19 3.1.6 ACQ.14 Request for proposals.............................................. 20 3.1.7 ACQ.15 Supplier qualification ............................................... 20 3.2 Supply Process Group (SPL) .................................................................... 21 3.2.1 SPL.1 Supplier tendering ....................................................... 21 3.2.2 SPL.2 Product release ............................................................ 21 3.3 Engineering Process Group (ENG) ........................................................... 22 3.3.1 ENG.1 Requirements elicitation ............................................ 22 3.3.2 ENG.2 System requirements analysis .................................. 23 3.3.3 ENG.3 System architecture design ....................................... 24 3.3.4 ENG.4 Software requirements analysis ................................ 25 3.3.5 ENG.5 Software design .......................................................... 26 3.3.6 ENG.6 Software construction ................................................ 27

The SPICE User Group 2005-2010

3.3.7 3.3.8 3.3.9 3.3.10

ENG.7 Software integration test ............................................ 28 ENG.8 Software testing .......................................................... 29 ENG.9 System integration test .............................................. 30 ENG.10 System testing .......................................................... 31

3.4 Supporting Process Group (SUP) ............................................................. 32 3.4.1 SUP.1 Quality assurance ....................................................... 32 3.4.2 SUP.2 Verification................................................................... 32 3.4.3 SUP.3 Joint review ................................................................. 33 3.4.4 SUP.7 Documentation ............................................................ 34 3.4.5 SUP.8 Configuration management........................................ 35 3.4.6 SUP.9 Problem resolution management .............................. 35 3.4.7 SUP.10 Change request management .................................. 36 3.5 Management Process Group (MAN) ......................................................... 37 3.5.1 MAN.3 Project management .................................................. 37 3.5.2 MAN.5 Risk management ....................................................... 38 3.5.3 MAN.6 Measurement .............................................................. 39 3.6 Process Improvement Process Group (PIM) ........................................... 40 3.6.1 PIM.3 Process improvement .................................................. 40 3.7 Reuse Process Group (REU) ..................................................................... 41 3.7.1 REU.2 Reuse program management..................................... 41

Annex A - Terminology ....................................................................... 42 Annex B - Key Concepts Schematic .................................................. 47 Annex C - Reference Standards ......................................................... 48

The SPICE User Group 2005-2010

1
1.1

Scope
Introduction

The Automotive SPICE Process Reference Model (PRM) has been developed by consensus of the car manufacturers within the Automotive Special Interest Group (SIG) of the joint Procurement Forum/SPICE User Group under the Automotive SPICE initiative. The Automotive SPICE PRM defined in this document is derived from Annex F and H of ISO/IEC 12207 AMD1: 2002 and ISO/IEC 12207 AMD2: 2004. It contains a sub set of the total processes with minor editorial changes together with a number of other changes to reflect consistency in use of terminology and application in the automotive sector. The FULL scope of Automotive SPICE contains ALL the processes from the ISO/IEC 15504 Process Reference Model (PRM). The fact that some processes have not been included within the Automotive SPICE PRM does not mean that they are not valid. Supplier organisations should address all processes relevant to their business needs within their organisation. Where a process is not included within the Automotive SPICE Process Reference Model (PRM) then the relevant process should be included from the ISO/IEC 15504 exemplar Process Assessment Model. The manufacturers will however focus on the set of process defined within the Automotive SPICE PRM when performing supplier capability assessments. 1.2 Purpose

The Automotive SPICE PRM, used with the process capability attributes and rating scheme defined in ISO/IEC 15502-2, provides a common framework for assessing the software process capability of automotive suppliers. The Automotive SPICE PRM is used in conjunction with the Automotive SPICE Process Assessment Model (PAM) when performing an assessment. The Automotive SPICE PAM provides additional indicators of process performance and process capability tailored to the needs of performing assessments of software process capability of automotive suppliers.

The SPICE User Group 2005-2010

1.3 PAM PRM SIG SPICE 1.4

Definitions Process Assessment Model Process Reference Model Special Interest Group Software Process Improvement and Capability dEtermination Terminology

Automotive SPICE follows the following precedence for use of terminology: a. English dictionary for common terms b. ISO/IEC 15504-1 :2004 for assessment related terminology c. IEEE 630 and BS 7925-1 terminology (as contained in Annex A) This document should be read in conjunction with ISO/IEC 15504-1 :2004. Many terms from ISO/IEC 15504-1 :2004 are used throughout the document. Other terminology used is defined below Element One of the parts that makes up a system. An element may comprise hardware, software, mechanical or manual operations. A set of components that are integrated into a larger assembly for the purpose of integration testing. A model comprising definitions of processes in a life cycle described in terms of process purpose and outcomes, together with an architecture describing the relationships between the processes

Integrated software item Process Reference Model

Annex B provides a schematic of key concepts used in the terminology.

The SPICE User Group 2005-2010

1.5

Applicable Documents

a. ISO/IEC 12207 AMD 1: 2002, Software Engineering - Software life cycle processes. b. ISO/IEC 12207 AMD2: 2004, Information Technology - Software life cycle processes. c. ISO/IEC 15504-1: 2004, Software Engineering - Process assessment Part 1: Concepts and Vocabulary d. ISO/IEC 15504-2: 2003, Information Technology - Process assessment Part 2: Performing an Assessment e. ISO/IEC 15504-5: 2006, Information Technology - Process assessment Part 5: An Exemplar Process Assessment Model f. IEEE 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology g. BS 7925-1, Glossary of Terms used in Software Testing h. Automotive SPICE Process Assessment Model 1.6 Warning

This document is subject to revision.

The SPICE User Group 2005-2010

10

2
2.1

Statement of compliance
Introduction

ISO/IEC 15504-2 requires that processes included in a PRM satisfy the following:
"The fundamental elements of a process reference model are the set of descriptions of the processes within the scope of the model. These process descriptions shall meet the following requirements: a) A process shall be described in terms of its Purpose and Outcomes. b) In any description the set of process outcomes shall be necessary and sufficient to achieve the purpose of the process. c) Process descriptions shall be such that no aspects of the measurement framework as described in clause 5 of this International Standard beyond level 1 are contained or implied."

As processes are derived directly from ISO/IEC 12207 AMD 1 Annex F and H supplemented by the ISO/IEC 12207 AMD 2, these requirements are satisfied. The PRM includes processes, which are grouped in three process categories, identical to the process categories defined in ISO/IEC 12207 AMD 1, which are: the Primary life cycle processes category; the Supporting life cycle processes category; the Organizational life cycle processes category. Within a process category, processes are grouped at a second level according to the type of activity they address. The processes included in the same group have a logical relationship as their capabilities are related and contribute to a complementary problematic.

The SPICE User Group 2005-2010

11

2.2

Primary Life Cycle Processes category

The Primary life cycle processes category consists of processes in the PRM that may be used by the customer when acquiring products from a supplier, and by supplier when responding and delivering products to the customer including the engineering processes needed for specification, design, development, integration and testing. The primary life cycle processes category consists of the following groups: the Acquisition process group; the Supply process group; the Engineering process group; The Acquisition process group (ACQ) consists of processes that are performed by the customer, or by the supplier when acting as a customer for its own suppliers, in order to acquire a product and/or service. Any contract performed will be managed by processes in the Management process group (MAN) and executed by the processes in the Engineering process group (ENG).
Table 1 Primary Life Cycle Processes ACQ process group Process Identification ACQ.3 ACQ.4 ACQ.11 ACQ.12 ACQ.13 ACQ.14 ACQ.15 PRM Process name Contract agreement Supplier monitoring Technical requirements Legal and administrative requirements Project requirements Request for proposals Supplier qualification Source ISO/IEC 12207 Amd.2 (F1.2.2) ISO/IEC 12207 Amd.1 (Annex F; F.1.1.3) ISO/IEC 12207 Amd.1 (Annex H; H1.4) ISO/IEC 12207 Amd.1 (Annex H; H1.5) ISO/IEC 12207 Amd.1 (Annex H; H1.7) ISO/IEC 12207 Amd.1 (Annex H; H1.8) ISO/IEC 12207 Amd.1 (Annex H; H1.9)

The Supply process group (SPL) consists of processes performed by the supplier in order to supply a product and/or a service.

The SPICE User Group 2005-2010

12

Table 2 Primary Life Cycle Processes SPL process group Process Identification SPL.1 SPL.2 PRM Process name Supplier tendering Product release Source ISO/IEC 12207 Amd.2 (F1.2.1) ISO/IEC 12207 Amd.2 (F1.2.3)

The Engineering process group (ENG) consists of processes that directly elicit and manage the customer's requirements, specify, implement, or maintain the software product, its relation to the system.
Table 3 Primary Life Cycle Processes ENG process group Process Identification ENG.1 ENG.2 ENG.3 ENG.4 ENG.5 ENG.6 ENG.7 ENG.8 ENG.9 ENG.10 PRM Process name Requirement elicitation System requirements analysis System architectural design Software requirements analysis Software design Software construction Software integration test Software testing System integration test System testing Source ISO/IEC 12207 Amd.1 (Annex F; F.1.3.1) ISO/IEC 12207 Amd.1 (Annex F; F.1.3.2) ISO/IEC 12207 Amd.1 (Annex F; F.1.3.3) ISO/IEC 12207 Amd.1 (Annex F; F.1.3.4) ISO/IEC 12207 Amd.1 (Annex F; F.1.3.5) ISO/IEC 12207 Amd.1 (Annex F; F.1.3.6) ISO/IEC 12207 Amd.1 (Annex F; F.1.3.7) ISO/IEC 12207 Amd.1 (Annex F; F.1.3.8) ISO/IEC 12207 Amd.1 (Annex F; F.1.3.9) ISO/IEC 12207 Amd.1 (Annex F; F.1.3.10)

The SPICE User Group 2005-2010

13

2.3

Supporting Life Cycle Processes category

The Supporting life cycle processes category consists of processes in the PRM that may be employed by any of the other processes at various points in the life cycle.
Table 4 Supporting Life Cycle processes - SUP process group Process Identification SUP.1 SUP.2 SUP.4 SUP.7 SUP.8 SUP.9 SUP.10 PRM Process name Quality assurance Verification Joint review Documentation management Configuration management Problem resolution management Change request management Source ISO/IEC 12207 Amd.1 (Annex F; F.2.3) ISO/IEC 12207 Amd.1 (Annex F; F.2.4) ISO/IEC 12207 Amd.1 (Annex F; F.2.6) ISO/IEC 12207 Amd.1 (Annex F; F.2.1) ISO/IEC 12207 Amd.2 (F2.2) ISO/IEC 12207 Amd.2 (F2.8) ISO/IEC 12207 Amd.2 (F2.11)

The SPICE User Group 2005-2010

14

2.4

Organizational Life Cycle Processes category

The Organizational life cycle processes category consists of processes in the PRM that establish the business goals of the organization and develop process, product, and resource assets which, when used by projects in the organization, will help the organization achieve its business goals. The organizational life cycle processes category consists of the following groups: the Management process group; the Process Improvement process group; the Reuse process group. The Management process group (MAN) consists of processes that contain practices that may be used by anyone who manages any type of project or process within the life cycle.
Table 5 Organizational Life Cycle Processes - MAN process group Process Identification MAN.3 MAN.5 MAN.6 PRM Process name Project management Risk management Measurement Source ISO/IEC 12207 Amd.1 (Annex F; F.3.1.3) ISO/IEC 12207 Amd.2 (F3.1.5) ISO/IEC 12207 Amd.1 (Annex FF.3.1.6)

The Process Improvement process group (PIM) consists of processes performed in order to define, deploy and improve the processes performed in the organizational unit.
Table 6 Organizational Life Cycle Processes - PIM process group Process Identification PIM.3 PRM Process name Process improvement Source ISO/IEC 12207 Amd.2 (F3.3.3)

The Reuse process group (REU) consists of processes performed in order to systematically exploit reuse opportunities in organizations reuse programs.
Table 7 Organizational Life Cycle Processes - REU process group Process Identification REU.2 PRM Process name Reuse program management Source ISO/IEC 12207 Amd.2 (F3.6)

The SPICE User Group 2005-2010

15

3
3.1 3.1.1

Process descriptions
Acquisition Process Group (ACQ) ACQ.3 Contract agreement
Process ID Process Name Process Purpose Process Outcomes ACQ.3 Contract agreement The purpose of Contract agreement process is to negotiate and approve a contract/agreement with the supplier. As a result of successful implementation of this process: 1) a contract/agreement is negotiated, reviewed, approved and awarded to the supplier(s); 2) the contract/agreement clearly and unambiguously specifies the expectations, responsibilities, work products/deliverables and liabilities of both the supplier(s) and the acquirer; 3) mechanisms for monitoring the capability and performance of the supplier(s) and for mitigation of identified risks are reviewed and considered for inclusion in the contract conditions; and 4) proposers/tenderers are notified of the result of proposal/tender selection.

3.1.2

ACQ.4 Supplier monitoring

Process ID Process Name ACQ.4 Supplier monitoring The purpose of the Supplier monitoring process is to monitor the performance of the supplier against agreed requirements. As a result of successful implementation of this process: 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. NOTE: Joint activities to be performed should be mutually agreed between the cutomer and the supplier.

Process Purpose Process Outcomes

The SPICE User Group 2005-2010

16

3.1.3

ACQ.11 Technical requirements

Process ID Process Name ACQ.11 Technical Requirements The purpose of the Technical requirements process is to establish the technical requirements of the acquisition. This involves the elicitation of functional and non-functional requirements that consider the deployment life cycle of the products so as to establish a technical requirement baseline. As a result of successful implementation of this process: 1) the technical requirements, including environment effect evaluation, safety and security requirements where appropriate, are defined and developed to match needs and expectations; 2) the current and evolving acquisition needs are gathered and defined; 3) the requirements and potential solutions are communicated to all affected groups; 4) a mechanism is established to incorporate changed or new requirements into the established baseline; 5) a mechanism for identifying and managing the impact of changing technology to the technical requirements is defined; and 6) the requirements include compliance with relevant standards, including environment effect evaluation, safety and security standards where appropriate. NOTE: ISO/IEC 9126 may be a useful model to elicit technical requirements.

Process Purpose

Process Outcomes

The SPICE User Group 2005-2010

17

3.1.4

ACQ.12 Legal and administrative requirements

Process ID Process Name ACQ.12 Legal and administrative requirements The purpose of the Legal and administrative requirements process is to define the awarding aspects expectations, liabilities, legal and other issues and which comply with national and international laws of contract. As a result of successful implementation of this process: 1) a contractual approach is defined which is compliant with relevant national, international and regulatory laws, guidance and policies; 2) an agreement (contractual) terms and conditions is defined to describe how the supplier will meet the needs and expectations; 3) acceptance criteria and mechanisms for handling of breaches to the fulfillment of contract are established; 4) the rights of the acquirer to assume, modify or evaluate, directly or indirectly Intellectual Property Rights are established; 5) warranties and service level agreements are provided for where applicable; 6) provision for the suppliers to deliver other requirements (e.g. quality plan, escrow arrangements etc.) is defined; and 7) recognized criteria for proprietary, regulatory and other product liabilities issues are established.

Process Purpose

Process Outcomes

The SPICE User Group 2005-2010

18

3.1.5

ACQ.13 Project requirements

Process ID Process Name ACQ.13 Project requirements The purpose of the Project requirements process is to specify the requirements to ensure the acquisition project is performed with adequate planning, staffing, directing, organizing and control over project tasks and activities. As a result of successful implementation of this process: 1) consistency between financial, technical, contract and project requirements is established; 2) requirements for the organisational, management, controlling, and reporting aspects of a project are defined; 3) requirements for adequate staffing of projects by a competent team (e.g. legal, contractual, technical, project competent resources) with clear responsibilities and goals are defined; 4) the needs for exchanging information between all affected parties are established; 5) requirements for the completion and acceptance of interim work products and release of payments are established; 6) potential risks are identified; 7) requirements for ownership of interactions and relationships with suppliers are defined; 8) rights for use and distribution of the product by the customer and supplier are defined; and 9) support and maintenance requirements are established.

Process Purpose

Process Outcomes

The SPICE User Group 2005-2010

19

3.1.6

ACQ.14 Request for proposals

Process ID Process Name ACQ.14 Request for proposals The purpose of the Request for proposals process is to prepare and issue the necessary acquisition requirements. The documentation will include, but not be limited to, the contract, project, finance and technical requirements to be provided for use in the Call For Proposals (CFP)/Invitation To Tender (ITT). As a result of successful implementation of this process: 1) rules are defined for proposal/tender invitation and evaluation which comply with the acquisition policy and strategy; 2) the baseline technical and non-technical requirements are assembled to accompany the CFP/ITT; 3) the agreement (contractual) terms of reference and conditions for CFP/ITT are established; 4) the financial terms of reference for costs and payments for CFP/ITT are defined; 5) the project terms of reference for CFP/ITT are defined; 6) the technical terms of reference for CFP/ITT are defined; and 7) a CFP/ITT is prepared and issued in accordance with acquisition policies and which complies with relevant national, international and regulatory laws, requirements, and policies.

Process Purpose

Process Outcomes

3.1.7

ACQ.15 Supplier qualification

Process ID Process Name ACQ.15 Supplier qualification The purpose of the Supplier qualification process is to evaluate and determine if the potential supplier(s) have the required qualification for entering the proposal/tender evaluation process. In this process, the technical background, quality system, servicing, user support capabilities and etc. will be evaluated. As a result of successful implementation of this process: 1) criteria are established for qualifying suppliers; 2) supplier capability determination is performed as necessary; 3) the suppliers which possess required qualification are short-listed for tender solution(s) evaluation; 4) any shortfalls in capability are identified and evaluated; and 5) any corrective action required by the acquirer is evaluated and performed.

Process Purpose

Process Outcomes

The SPICE User Group 2005-2010

20

3.2 3.2.1

Supply Process Group (SPL) SPL.1 Supplier tendering

Process ID Process Name Process Purpose SPL.1 Supplier tendering The purpose of Supplier tendering process is to establish an interface to respond to customer inquiries and requests for proposal, prepare and submit proposals, and confirm assignments through the establishment of a relevant agreement/contract. As a result of successful implementation of this process: 1) a communication interface is established and maintained in order to respond to customer inquiries and requests for proposal; 2) request for proposal are evaluated according to defined criteria to determine whether or not to submit a proposal; 3) the need to undertake preliminary surveys or feasibility studies is determined; 4) suitable staff are identified to performed the proposed work; 5) a supplier proposal is prepared in response to the customer request; and 6) formal confirmation of agreement is obtained.

Process Outcomes

3.2.2

SPL.2 Product release

Process ID Process Name SPL.2 Product release The purpose of Product release process is to control the release of a product to the intended customer. As a result of successful implementation of this process: 1) the contents of the product release are determined; 2) the release is assembled from configured items; 3) the release documentation is defined and produced; 4) the release delivery mechanism and media is determined; 5) release approval is effected against defined criteria; 6) the product release is made available to the intended customer; and 7) confirmation of release is obtained.

Process Purpose Process Outcomes

The SPICE User Group 2005-2010

21

3.3 3.3.1

Engineering Process Group (ENG) ENG.1 Requirements elicitation

Process ID Process Name Process Purpose ENG.1 Requirements elicitation The purpose of the Requirements elicitation process is to gather, process, and track evolving customer needs and requirements throughout the life of the product and/or service so as to establish a requirements baseline that serves as the basis for defining the needed work products. As a result of successful implementation of this process: 1) continuing communication with the customer is established; 2) agreed customer requirements are defined and baselined; 3) a change mechanism is established to evaluate and incorporate changes to customer requirements into the baselined requirements based on changing customer needs; 4) a mechanism is established for continuous monitoring of customer needs; 5) a mechanism is established for ensuring that customers can easily determine the status and disposition of their requests; and 6) changes arising from changing technology and customer needs are identified, the associated risks assessed and their impact managed. NOTE 1: Requirements elicitation may involve the customer and the supplier. NOTE 2: The agreed customer requirements and evaluation of any changes may be based on feasibility studies and/or cost and time analyses. NOTE 3: An information management system may be needed to manage, store and reference any information gained and needed in defining agreed customer requirements. NOTE 4: Any changes should be communicated to the customer before implementation in order that the impact, in terms of time, cost and functionality can be evaluated. NOTE 5: Agreed customer requirements may result directly in the production of a system or software requirements specification.

Process Outcomes

The SPICE User Group 2005-2010

22

3.3.2

ENG.2 System requirements analysis

Process ID Process Name ENG.2 System requirements analysis The purpose of the System requirements analysis process is to transform the defined customer requirements into a set of desired system technical requirements that will guide the design of the system. As a result of successful implementation of this process: 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 customers requirements baseline are evaluated for cost, schedule and technical impact; and 8) the system requirements are communicated to all affected parties and baselined. NOTE 1: System requirements may be categorized in terms of feasibility and risk. NOTE 2: System requirements may typically include functional, performance, interface, design requirements and verification criteria. Verification criteria define the qualitative and quantitative criteria for verification of a requirement. Verification criteria demonstrate that a requirement can be verified within agreed constraints NOTE 3: Analysis of system requirements for testability includes development of verification criteria.

Process Purpose

Process Outcomes

The SPICE User Group 2005-2010

23

3.3.3

ENG.3 System architecture design

Process ID Process Name ENG.3 System architectural design The purpose of the System architectural design process is to identify which system requirements are to be allocated to which elements of the system. As a result of successful implementation of this process: 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; 5) consistency and bilateral traceability are established 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. NOTE : Definition of system architectural design includes development of verification criteria. Verification criteria define the qualitative and quantitative criteria for verification of a requirement. Verification criteria demonstrate that a requirement can be verified within agreed constraints.

Process Purpose

Process Outcomes

The SPICE User Group 2005-2010

24

3.3.4

ENG.4 Software requirements analysis

Process ID Process Name ENG.4 Software requirements analysis The purpose of the Software requirements analysis process is to establish the software requirements for the system. As a result of successful implementation of this process: 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; 6) consistency and bilateral traceability are established 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 communicated to all affected parties. NOTE 1: Requirements may be categorized in terms of feasibility and risk. NOTE 2: Requirements may typically include functional, performance, interface, design requirements and verification criteria. Verification criteria define the qualitative and quantitative criteria for verification of a requirement. Verification criteria demonstrate that a requirement can be verified within agreed constraints. NOTE 3: Where software is the only system element it is often referred to a software system. NOTE 4: Analysis of software requirements for testability includes development of verification criteria.

Process Purpose Process Outcomes

The SPICE User Group 2005-2010

25

3.3.5

ENG.5 Software design

Process ID Process Name ENG.5 Software design The purpose of the Software design process is to provide a design for the software that implements and can be verified against the software requirements. As a result of successful implementation of this process: 1) a software architectural design is defined that identifies the components of the software and meets the defined software requirements; 2) the software requirements are allocated to the elements of the software; 3) internal and external interfaces of each software component are defined; 4) the dynamic behaviour and resource consumption objectives of the software components are defined; 5) a detailed design is developed that describes software units that can be implemented and tested; 6) consistency and bilateral traceability are established between software requirements and software architectural design; and 7) consistency and bilateral traceability are established between software architectural design and software detailed design. NOTE 1: The software design process should take into account all software components such as customer supplied software, third party software and sub-contractor software. NOTE 2: Definition of software architectural design and detailed design includes development of verification criteria.

Process Purpose

Process Outcomes

The SPICE User Group 2005-2010

26

3.3.6

ENG.6 Software construction

Process ID Process Name ENG.6 Software construction The purpose of the Software construction process is to produce verified software units that properly reflect the software design. As a result of successful implementation of this process: 1) a unit verification strategy is developed for software units consistent with the software design; 2) software units defined by the software design are analyzed for correctness and testability; 3) software units defined by the software design are produced; 4) software units are verified according to the unit verification strategy; 5) results of unit verification are recorded; and 6) consistency and bilateral traceability are established between software detailed design and software units; NOTE 1: Analysis of software units will include prioritization and categorization of software units. NOTE 2: Unit verification will include unit testing and may include static analysis, code inspection/reviews, checks against coding standards and guidelines, and other techniques.

Process Purpose Process Outcomes

The SPICE User Group 2005-2010

27

3.3.7

ENG.7 Software integration test

Process ID Process Name ENG.7 Software integration test The purpose of the Software integration test process is to integrate the software units into larger assemblies, producing integrated software consistent with the software design and to test the interaction between the software items. As a result of successful implementation of this process: 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. NOTE 1: The test specification for software integration includes the test design specification, test procedure specification and test case specifications. NOTE 2: The test results for software integration include the test logs, test incident reports and test summary reports.

Process Purpose

Process Outcomes

The SPICE User Group 2005-2010

28

3.3.8

ENG.8 Software testing

Process ID Process Name ENG.8 Software testing The purpose of the Software testing process is to confirm that the integrated software meets the defined software requirements. As a result of successful implementation of this process: 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; 5) consistency and bilateral traceability are established 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. NOTE 1: The test specification for software testing includes the test design specification, test procedure specification and test case specifications. NOTE 2: The verification is performed according to the test cases NOTE 3: The test results for software testing include the test logs, test incident reports and test summary reports.

Process Purpose Process Outcomes

The SPICE User Group 2005-2010

29

3.3.9

ENG.9 System integration test

Process ID Process Name ENG.9 System integration test The purpose of the System integration test process is to integrate the system elements to produce an integrated system that will satisfy the system architectural design and the customers expectations expressed in the system requirements. As a result of successful implementation of this process: 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; 6) consistency and bilateral traceability are established 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. NOTE 1: The test specification for system integration includes the test design specification, test procedure specification and test case specifications. NOTE 2: The test results for system integration include the test logs, test incident reports and test summary reports.

Process Purpose

Process Outcomes

The SPICE User Group 2005-2010

30

3.3.10

ENG.10 System testing

Process ID Process Name ENG.10 System testing The purpose of the Systems testing process is to ensure that the implementation of each system requirement is tested for compliance and that the system is ready for delivery. As a result of successful implementation of this process : 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; 5) consistency and bilateral traceability are established 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. NOTE 1: The test specification for system testing includes the test design specification, test procedure specification and test case specifications. NOTE 2: The test results for system testing include the test logs, test incident reports and test summary reports.

Process Purpose

Process Outcomes

The SPICE User Group 2005-2010

31

3.4 3.4.1

Supporting Process Group (SUP) SUP.1 Quality assurance

Process ID Process Name Process Purpose SUP.1 Quality assurance The purpose of the Quality assurance process is to provide independent assurance that work products and processes comply with predefined provisions and plans. As a result of successful implementation of this process: 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. NOTE 1: Quality assurance should be coordinated with, and make use of, the results of other supporting processes such as verification, validation, joint review, audit and problem management. NOTE 2: Verification and validation may be subject to quality assurance. NOTE 3: Independent quality assurance should be established as a separate functional role within an organization.

Process Outcomes

3.4.2

SUP.2 Verification
Process ID Process Name SUP.2 Verification The purpose of the Verification process is to confirm that each work product of a process or project properly reflects the specified requirements. As a result of successful implementation of this process: 1) a verification strategy is developed, implemented and maintained; 2) criteria for verification of all required work products are identified; 3) required verification activities are performed; 4) defects are identified, recorded and tracked; and 5) results of the verification activities are made available to the customer and other involved parties.

Process Purpose

Process Outcomes

The SPICE User Group 2005-2010

32

3.4.3

SUP.3 Joint review

Process ID Process Name SUP.4 Joint review The purpose of the Joint review process is to maintain a common understanding with the stakeholders of the progress against the objectives of the agreement and what should be done to help ensure development of a product that satisfies the stakeholders. Joint reviews are at both project management and technical levels and are held throughout the life of the project . As a result of successful implementation of this process: 1) management and technical reviews are held based on the needs of the project; 2) the status and products of an activity of a process are evaluated through joint review activities between the stakeholders; 3) review results are made known to all affected parties; 4) action items resulting from reviews are tracked to closure; and 5) problems are identified and recorded. NOTE 1: Joint review should be performed at specific milestones during project/product development. The scope and the goals of joint review may be different dependent on project/product development phase (for example, in the early stage of a project joint review may be conceptual in order to analyse the customer requirements; in later stages joint review may be concerned with the implementation). NOTE 2: Joint review should be performed to verify different aspects (for example: hardware resources utilization; the introduction of new requirements and new technologies; modification to the working team structure; technology changes).

Process Purpose

Process Outcomes

The SPICE User Group 2005-2010

33

3.4.4

SUP.7 Documentation
Process ID Process Name SUP.7 Documentation The purpose of the Documentation process process is to develop and maintain the recorded information produced by a process. As a result of successful implementation of this process: 1) a strategy identifying the documentation to be produced during the life cycle of the product or service is developed; 2) the standards to be applied for the development of the documentation are identified; 3) documentation to be produced by the process or project is identified; 4) the content and purpose of all documentation is specified, reviewed and approved; 5) documentation is developed and made available in accordance with identified standards; and 6) documentation is maintained in accordance with defined criteria. NOTE: Careful attention should be paid to the customer - supplier relationship and its documents.

Process Purpose Process Outcomes

The SPICE User Group 2005-2010

34

3.4.5

SUP.8 Configuration management

Process ID Process Name SUP.8 Configuration management The purpose of the Configuration management process is to establish and maintain the integrity of all the work products of a process or project and make them available to concerned parties. As a result of successful implementation of this process: 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. NOTE: Items requiring configuration control may include modules, subsystems, libraries, test cases, compilers, data, documentation, physical media, and external interfaces.

Process Purpose

Process Outcomes

3.4.6

SUP.9 Problem resolution management

Process ID Process Name SUP.9 Problem resolution management The purpose of the Problem resolution management process is to ensure that all discovered problems are identified, analyzed, managed and controlled to resolution. As a result of successful implementation of this process: 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.

Process Purpose

Process Outcomes

The SPICE User Group 2005-2010

35

3.4.7

SUP.10 Change request management

Process ID Process Name SUP.10 Change request management The purpose of the Change request management process is to ensure that change requests are managed, tracked and controlled. As a result of successful implementation of this process: 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. NOTE: Analysis should cover costs, risks, impacy, urgency and resource requirements.

Process Purpose Process Outcomes

The SPICE User Group 2005-2010

36

3.5 3.5.1

Management Process Group (MAN) MAN.3 Project management

Process ID Process Name Process Purpose MAN.3 Project management The purpose of the Project management process is to identify, establish, plan, co-ordinate, and monitor the activities, tasks, and resources necessary for a project to produce a product and/or service, in the context of the projects requirements and constraints. 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. NOTE 1: The necessary resources will include - people, development tools, hardware present in the ECU (CPU, RAM, Flash RAM, etc.), test equipment, methodologies. NOTE 2: The skills of the people and the technologies used to develop the project will need to be evaluated and if necessary, training courses, tool upgrades, introduction of new technologies, etc. need to be planned. NOTE 3: Plans for the execution of the project may contain among other elements, work break down structures, responsibilities, schedules, etc..

Process Outcomes

The SPICE User Group 2005-2010

37

3.5.2

MAN.5 Risk management

Process ID Process Name MAN.5 Risk management The purpose of the Risk management process is to identify, analyze, treat and monitor the risks continuously. As a result of successful implementation of this process: 1) the scope of the risk management to be performed is determined; 2) appropriate risk management strategies are defined and implemented; 3) risks are identified as they develop during the conduct of the project; 4) risks are analyzed and the priority in which to apply resources to treatment of these risks is determined; 5) risk measures are defined, applied, and assessed to determine changes in the status of risk and the progress of the treatment activities; and 6) appropriate treatment is taken to correct or avoid the impact of risk based on its priority, probability, and consequence or other defined risk threshold. NOTE 1: Risks may include technical, economic and timing risks. NOTE 2: Risks are normally analysed to determine their probability, consequence and severity. NOTE 3: Major risks may need to be communicated to and monitored by higher levels of management. NOTE 4: Different techniques may be used to analyze a system in order to understand if risks exist, for example, functional analysis, simulation, FMEA, FTA etc..

Process Purpose Process Outcomes

The SPICE User Group 2005-2010

38

3.5.3

MAN.6 Measurement
Process ID Process Name MAN.6 Measurement The purpose of the Measurement process is to collect and analyze data relating to the products developed and processes implemented within the organization and its projects, to support effective management of the processes and to objectively demonstrate the quality of the products. As a result of successful implementation of this process: 1) organizational commitment is established and sustained to implement the measurement process; 2) the measurement information needs of organizational and management processes are identified; 3) an appropriate set of measures, driven by the information needs are identified and/or developed; 4) measurement activities are identified and performed; 5) the required data is collected, stored, analyzed, and the results interpreted; 6) information products are used to support decisions and provide an objective basis for communication; and 7) the measurement process and measures are evaluated and communicated to the process owner. NOTE: Information products are produced as a result analysis of data in order to summarise and communicate information.

Process Purpose

Process Outcomes

The SPICE User Group 2005-2010

39

3.6 3.6.1

Process Improvement Process Group (PIM) PIM.3 Process improvement

Process ID Process Name Process Purpose PIM.3 Process Improvement The purpose of the Process improvement process is to continually improve the organizations effectiveness and efficiency through the processes used and aligned with the business need. As a result of successful implementation of this process: 1) commitment is established to provide resources to sustain improvement actions; 2) issues arising from the organization's internal/external environment are identified as improvement opportunities and justified as reasons for change; 3) analysis of the current status of the existing process is performed, focusing on those processes from which improvement stimuli arise; 4) improvement goals are identified and prioritized, and consequent changes to the process are defined, planned and implemented; 5) the effects of process implementation are monitored, measured and confirmed against the defined improvement goals; 6) knowledge gained from the improvement is communicated within the organization; and 7) the improvements made are evaluated and consideration given for using the solution elsewhere within the organisation. NOTE 1: information sources providing input for change may include: process assessment results, audits, customer's satisfaction reports, organizational effectiveness/efficiency, cost of quality. NOTE 2: the current status of processes may be determined by process assessment

Process Outcomes

The SPICE User Group 2005-2010

40

3.7 3.7.1
Process ID

Reuse Process Group (REU) REU.2 Reuse program management

REU.2 Reuse program management The purpose of the Reuse program management process is to plan, establish, manage, control, and monitor an organizations reuse program and to systematically exploit reuse opportunities. As a result of successful implementation of this process: 1) the reuse strategy, including its purpose, scope, goals and objectives, is defined; 2) each domain is assessed to determine its reuse potential; 3) the domains in which to investigate reuse opportunities, or in which it is intended to practice reuse, are identified; 4) the organization's systematic reuse capability is assessed; 5) reuse proposals are evaluated to ensure the reuse product is suitable for the proposed application; 6) reuse is implemented according to the reuse strategy ; 7) feedback, communication, and notification mechanisms are established, that operate between affected parties; and 8) the reuse program is monitored and evaluated. NOTE 1: Affected parties may include reuse program administrators, asset managers, domain engineers, developers, operators, and maintainance groups. NOTE 2: The quality requirements for re-use work products should be defined.

Process Name Process Purpose

Process Outcomes

The SPICE User Group 2005-2010

41

Annex A - Terminology
Annex A lists the applicable terminology references from IEEE 630, BS 79251 and notes from the FDA General principles of software validation. Annex B provides a schematic of key concepts used in the terminology.

Acceptance tesing Architectural design

BS7925-1 / IEEE610 IEEE610

Baseline

IEEE610

Black box testing Code review

BS7925-1

IEEE610

Coding

IEEE610

Component

BS7925-1

Component testing Defect Design

IEEE610 IEEE610 IEEE610

Detailed design

IEEE610

Formal testing conducted to enable a user, customer, or authorised entity to decide whether to accept a system or component The process of defining a collection of hardware and software components and their interfaces to establish the framework for the development of the system A specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and can be changed only through formal change control procedures. Test case selection based on an analysis of the specification of the component without reference to its internal workings A meeting at which software code is presented to project personnel, mangers, users, customers, or other interested parties for comment or approval The transforming of logic and data from design specifications (design descriptions) into programming language A minimal software or hardware item for which a separate specification is available One of the parts that makes up a system. A component may be hardware or software and may be subdivided into other components Testing of individual components or groups of related components See fault The process of defining the architecture, components, interfaces, and other characteristics of a system or component. The process of refining and expanding the preliminary design of a system or component to the extent that the design is sufficiently complete to be implemented

The SPICE User Group 2005-2010

42

Development testing

IEEE610

Dynamic testing / Dynamic analysis Embedded software Embedded system Error Failure Fault Functional requirement Functional specification Functional testing

BS7925-1 / IEEE610

Formal or informal testing conducted during the development of a system or component, usually in the development environment by the developer A process of evaluating a system or component based on its behaviour during execution Software in an embedded system, dedicated to controlling the specific hardware of the system A system that interacts with the real physical world using actors and sensors A human action that produces an incorrect result A deviation of the system from its expected delivery or service A manifestation of an error in software. A fault, if encountered, may cause a failure The required functional behaviour of a system A document that specifies the functions that a system or component must perform. Often part of a requirements specification Testing that ignores the internal mechanism of a system or component and focuses solely on the outputs generated in response to selected inputs and execution conditions Physical equipment used to process, store, or transmit computer programs or data A process of testing whole, complete products A test level where real hardware is used and tested in a simulated environment A process combining components into larger assemblies Performed to expose faults in the interfaces and in the interaction between integrated components A process of testing individual components one at a time or in combination A test level where the simulation model of the system is tested dynamically in a simulated environment

BS7925-1

BS7925-1 BS7925-1 / IEEE610 BS7925-1 BS7925-1 BS7925-1 IEEE610

IEEE610

Hardware High level testing HiL Hardware in the loop Integration Integration testing Low-level tests MiL Model in the loop

IEEE610 BS7925-1 BS7925-1 BS7925-1 BS7925-1

BS7925-1 BS7925-1

The SPICE User Group 2005-2010

43

Model based development Module

BS7925-1

IEEE610

Preliminary design

IEEE610

Rapid prototyping Regression testing

BS7925-1

BS7925-1

Requirement

IEEE610

Requirements specification

IEEE610

Simulator

BS7925-1

SiL Software in the loop Software

BS7925-1

IEEE610

Software item Static testing/static analysis System

IEEE610 BS7925-1 / IEEE610 IEEE610

A development method where the system is first described as a model. The code is then generated automatically from the models. A program unit that is discrete and identifiable with respect to compiling, combining with other units, and loading. The process of analysing design alternatives and defining the architecture, components, interfaces and timing and sizing estimates for a system or component A test level where a simulated embedded system is tested while connected to the real environment Regression of a previously tested object following modification to ensure that faults have not been introduced or uncovered as a result of the changes made A condition that must be met or possessed by a system or component to satisfy a contract, standard, specification, or other formally imposed documents A document that specifies the requirements for a system or component. Typically included are functional requirements, performance requirements, interface requirements, design requirements, and development standards A device, or computer program, or system used during software verification that behaves or operates like a given system when provided with a set of controlled inputs A test level where the real software is used and tested in a simulated environment or with experimental hardware Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system. Source code, object code, job control code, control data, or a collection of these items A process of evaluating a system or component without executing the test object A collection of components organised to accomplish a specific function or set of functions

The SPICE User Group 2005-2010

44

System testing Test object Test unit Testing

BS7925-1 BS7925-1 BS7925-1 BS7925-1

Traceability

IEEE610

Quality assurance

IEEE610

Quality control Unit Unit test Validation

IEEE610 IEEE610 BS7925-1 IEEE610

Software validation

FDAGeneral principles of software validation

A process of testing an integrated system to verify that it meets specified requirements A system (or part of it) to be tested A set of processes, transactions and/or functions which are tested collectively The process of planning, preparation, execution and analysis aimed at establishing the quality level of a system The degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements The process of verifying ones own work with that of a co-worker A software component that is not subdivided into other components The testing of individual software components The process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements (note) Software validation activities may occur both during, as well as at the end of the software development life cycle to ensure that all requirements have been fulfilled. Since software is usually part of a larger hardware system, the validation of software typically includes evidence that all software requirements have been implemented correctly and completely and are traceable to system requirements. A conclusion that software is validated is highly dependent upon comprehensive software testing, inspections, analyses, and other verification tasks performed at each stage of the software development life cycle. Testing of device software functionality in a simulated use environment, and user site testing are typically included as components of an

The SPICE User Group 2005-2010

45

Verification

IEEE610

Software verification

FDAGeneral principles of software validation

White-box testing

BS7925-1

overall design validation program for a software automated device. In large measure, software validation is a matter of developing a "level of confidence" that the device meets all requirements and user expectations for the software automated functions and features of the device. Measures such as defects found in specifications documents, estimates of defects remaining, testing coverage, and other techniques are all used to develop an acceptable level of confidence before shipping the product. The process of evaluating a system or component to determine whether products of a given development phase satisfy the conditions imposed at the start of that phase (note) Software verification looks for consistency, completeness, and correctness of the software and its supporting documentation, as it is being developed, and provides support for a subsequent conclusion that software is validated. Software testing is one of many verification activities intended to confirm that software development output meets its input requirements. Other verification activities include various static and dynamic analyses, code and document inspections, walkthroughs, and other techniques. Test design techniques that derive test cases from the internal properties of an object, using knowledge of the internal structure of the object

The SPICE User Group 2005-2010

46

Annex B - Key Concepts Schematic

The following schematic has been developed to indicate key concepts in terms of processes and work products that flow through the engineering processes within the Automotive SPICE PRM. It relates to the terminology described in Annex A Terminology. The schematic highlights that a system may consist of hardware, software and mechanics. Software may consist of a number of software components. A software component has a component specification. The lowest level of a software component that is not sub-divided into other components is termed a software unit. Software units are integrated into software items to form the software to be tested. Software may be integrated with hardware and mechanics to form the system to be tested.

Explanation: System work product of a

customer requirements 1.. elicit Are derived 1.. elicit Requirements elicitation System architectural design
Are allocated to

System Integration

proces

Acceptance Testing validates Specifies requirements System 1.. 1.. 1.. 1.. integrates integrates System Integration Are derived from verifies System Testing

System requirements 1.. 1..

verification criteria

elicit

1.. Mechanics requirements 1 specify

1.. Mechanics 1 integrates

uses

Are allocated to

1.. 1 specify 1

1..
Hardware

Hardware requirement s

Validates SW-only systems Are allocated to 1.. Software requiremen 1 specify 1 1.. verifies Software 1 Are derived Software Testing verification criteria

Software design

Is integrated to Softwareitem Software Integration

1.. SoftwareComponent

uses

1 Is integrated to 1.. Software Unit

The SPICE User Group 2005-2010

47

Annex C - Reference Standards

Annex B provides a list of reference standards and guidelines that support implementation of the processes in the PRM. a. IEEE STD 1233-1998 Guide for Developing System Requirements Specifications b. IEEE STD 1471-2000 Recommended Practice for Architectural Description c. IEEE STD 830-1998 Recommended Practice for Software Requirements Specifications d. IEEE STD 829-2008 Standard for Software and System Test Documentation e. IEEE STD 1058-1998 Standard for Software Project Management Plans f. IEEE Std. 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology g. IEEE Std. 828-1998 IEEE Standard for Software Configuration Management Plans h. IEEE Std. 730-1998 IEEE Standard for Software Quality Assurance Plans i. IEEE Std. 1016-1998 IEEE Recommended Practice for Software Design Descriptions

The SPICE User Group 2005-2010

48