Software Process Management according to IATF 16949

By Roxana Rohde | Consultant at iProcess LLC | 23. January 2021

Roxana is a consultant who is helping automotive R&D executives to achieve better software and better product quality through application of process models like Automotive SPICE.


The objectives of this paper are to:

  • Understand the IATF 16949 Requirements related to Embedded Software
  • Get a good overview of Automotive SPICE, and
  • Learn where and how to get started

OTA Processes Compliant

IATF 16949, the automotive quality management standard for automotive industry, introduced specific requirements for products with software or embedded software.

Considering that electronics and software have grown significantly over the years, “In 2010, some vehicles had about ten million software lines of code (SLOC); by 2016, this expanded by a factor of 15, to roughly 150 million lines.”, the new IATF requirements were definitely needed.

What exactly is required by IATF 16949?

1. If the organization is responsible for developing software or products with embedded software for automotive then the organization is required to perform capability assessment(s) – see clause Development of products with embedded software and to perform the assessment(s) at regular intervals, e.g. as part of the internal audit program – see clause Internal Audit Program

2. If the organization has suppliers responsible for developing software or products with embedded software for automotive then the organization is required to include software capability assessment results as supplier criteria – see clause Supplier selection process and to assess or request self-assessment results of supplier as controlling externally provided processes, products and services – see clause Automotive product-related software or automotive products with embedded software

Capability Assessment Models

There are two capability assessment models applicable:

1. CMMI® (Capability Maturity Model Integration) is “a globally-recognized set of best practices that enable organizations to improve performance, key capabilities, and critical business processes” – see for details.

2. Automotive SPICE® (Software Process Improvement and Capability determination) contains “(…) specific guidance available for the basis of process design and assessment in the Automotive Industry.” – see for details.

For this article, the focus will be on Automotive SPICE® only. It is the model that iProcess uses as basis for software process improvements.

Introduction to Automotive SPICE

Automotive SPICE is a framework for designing and assessing software development processes. It covers numerous processes such as system and software engineering, management, acquisition, supporting processes such as change request management, quality assurance etc.

If the model is implemented correctly, it will lead to better processes and better product quality. Besides, it helps to improve the cooperation among the complex supply chain and between globally distributed development and engineering centers.

Automotive SPICE and ISO 26262 Functional Safety have a strong relationship.

Automotive SPICE History

The model evolved from an ISO project and was published originally as ISO/IEC TR 15504.

It was first used in the car industry in 2001 with the decision of OEM software initiative group (SIG) to evaluate suppliers in software and electronics sectors.

Automotive software initiative group included AUDI AG, BMW Group, Daimler AG, Fiat Auto S.p.A., Ford Werke GmbH, Jaguar, Land Rover, Dr. Ing. h.c. F. Porsche AG, Volkswagen AG and Volvo Car Corporation.

Automotive SPICE® is a registered trademark of the Verband der Automobilindustrie e.V. (VDA)

Automotive SPICE Structure

Capability dimension

Automotive SPICE has six capability levels:

  • Level 0
  • Level 1
  • Level 2
  • Level 3
  • Level 4
  • Level 5
Capability Levels of ASPICE Structure

Process dimension

Processes are grouped based on the type of activity they engage and are classified into primary life cycle processes (system engineering, software engineering, acquisition and supply processes), organizational life cycle processes (management, reuse and process improvement processes) and supporting life cycle processes (supporting processes). The following tables list the processes in each category:

Table with System and Software Engineering Processes

Figure 2 – System and Software Engineering Processes

Table with Acquisition and Supporting Processes

Figure 3 – Acquisition and Supporting Processes

Supply and Management Processes

Figure 4 – Supply and Management Processes

Reuse and Process Improvement Processes

Figure 5 – Reuse and Process Improvement Processes

The System Engineering group (SYS)
which consist of processes addressing the elicitation and management of customer and internal requirements, the definition of systems architecture and the integration and testing at systems level.

The Acquisition process group (ACQ)
consist of processes that are done by the customers, or by the supplier when acting as a customer for its own suppliers, when acquiring products or services.

Supporting process group (SUP)
covers processes that may be utilized by any of the other processes at various points in the life cycle.

The Management process group (MAN)
consists of processes addressing the management of the project or program.

A subset of highly significant processes assessed within the automotive industry is known as VDA Scope.

  • List of processes in VDA Scope
  • ACQ.4 Supplier Monitoring
  • SYS.2 System Requirements Analysis
  • SYS.3 System Architectural Design
  • SYS.4 System Integration and Integration Test
  • SYS.5 System Qualification Test
  • SWE.1 Software Requirements Analysis
  • SWE.2 Software Architectural Design
  • SWE.3 Software Detailed Design and Unit Construction
  • SWE.4 Software Unit Verification
  • SWE.5 Software Integration and Integration Test
  • SWE.6 Software Qualification Test
  • MAN.3 Project Management
  • SUP.1 Quality Assurance
  • SUP.8 Configuration Management
  • SUP.9 Problem Resolution Management
  • SUP.10 Change Request Management

Determining the process capability

The rating is based on a two-dimensional approach. Individual processes receive their own rating. If, for example, Process one receives level 2, Process two receives level 0, Process three receives level 1 etc. then to determine the capability we will not calculate the average of the three processes in this case. The assessment results will showcase all processes with their individual rating.

Process assessment model relationship

(reused without modifications from Automotive SPICE PAM v3.1)

In order to determine the capability and process achievements an assessment is used to gather the objective evidence.

Audit vs Assessment

Audit Definition

ISO 19011 defines an audit as a systematic, independent, and documented process for obtaining audit evidence and evaluating it objectively to determine the extent to which audit criteria are fulfilled.

Assessment Definition

According to VDA, a software process assessment can be defined as the disciplined examination of the software processes used by an organization, based on the process model. The primary objective is to measure the maturity of those processes (…).

Difference between Assessment and Audit

While audits and assessments have a lot of common elements, some of the major differences are listed below:



End-to-end business processes

Product development with focus on projects

Abstract processes

Detailed development processes

Pass/Fail in terms of requiring certification

No certification; evaluation done according to 6 capability levels via assessment with report available for results

Fixed scope

Adaptable scope, depending on selectable processes and capabilities

Table 2 Audit versus Assessment

Mapping Automotive SPICE to PDCA

Overview of PDCA Cycle

Plan, Do, Check and Act (PDCA) is one of the simplest models that describe the steps to process improvement. There are four steps: Plan, Do, Check and Act.


This involves the selection of the need to implement the change, definition of the current status and opportunity for improvement, planning of how monitoring the progress and effectiveness will be done and finally the goals and objectives of the plan are documented.


This involves implementation of what has been planned. Also, documentation is required of what is being implemented.


Monitoring the progress and effectiveness of the change according to the plan, record the observation and compare with the original data of the objectives. Did the plan and its implementation actually work?


If the plan and its implementation worked, action will be taken to scale up the process improvement throughout the organization; if the plan did not return the expected results, then this step will identify the root causes and define the needed corrective actions.

PDCA Steps

Figure 7 – PDCA Cycle

Approaching Automotive SPICE from the PDCA perspective the following mapping could result:


Automotive SPICE Processes

Plan set objectives, resources needed to deliver results based on customer’s requirements, identify risks and opportunities

  • MAN.3 Project Management
  • SYS.1 Requirements Elicitation (if the case)
  • SYS.2 System Requirements Analysis/SWE.1 Software Requirements Analysis

Do implement what was planned

  • SYS.3 System Architectural Design
  • SWE.2 Software Architectural Design
  • SWE.3 Software Detailed Design and Unit Constructions

Check monitor and measure processes and the resulting products and services against requirements, objectives, plans etc.

  • SWE.4 Software Unit Verification
  • SWE.5 Software Integration and Integration Test
  • SWE.6 Software Qualification Test
  • SYS.5 System Integration and Integration Test
  • SYS.6 System Qualification Test
  • SUP.1 Quality Assurance

Act take actions to improve performance.

  • SUP.1 Quality Assurance
  • SUP.9 Problem Resolution Management
  • SUP.10 Change Request Management

The purpose is to demonstrate that in order to comply with a model such as Automotive SPICE, the organization doesn’t have to start from scratch, but from the existing processes, especially if a quality management system is in place.

Getting Started with Automotive SPICE

Similar to PDCA cycle, an Automotive SPICE Improvement project will have the following format:

  • Gap Analysis
    select project(s) and perform an Automotive SPICE Assessment
  • Improvement Plan
    define and prioritize corrective actions, select processes for improvement
  • Reassessment
    evaluation of results and lessons learned

For the improvement project to be successful, consider the following:

  • Automotive SPICE is a bottom-up approach with focus on product development
  • Levels in Automotive SPICE are building on top of each other (e.g. Level 2 cannot be achieved if Level 1 is not fully achieved)
  • There is no Automotive SPICE certification provided, compliance is demonstrated via assessment
  • Additional effort has to be planned for the project team(s) to work on the improvement actions
  • Management commitment is crucial in this type of projects
  • Improvement has to be a continuous effort


IATF requires that if the organization is responsible for developing software or products with embedded software for automotive then the organization shall perform capability assessment(s). The assessments should be done at regular intervals as part of the internal audit program. Requirements are also valid for the organization’s suppliers responsible for developing software or products with embedded software. Suppliers have to be assessed/self-assessed in order to determine the capability of supplier’s development processes.

Automotive SPICE PAM v3.1
IATF 16949, 1st Edition, 1 October 2016
ISO 9001, 5th Edition, 2015-09-15

Schedule free consultation

Schedule free consultation

Let's stay connected

Follow us on LinkedIn