Prozessbeschreibungen PB-EN-32

Process Description Seite 1 von 36

Page 1 of 36
Ausgabe
Software Entwicklungs-Prozess-Abläufe 1, 04 SEP 2009
Issue

Software Development-Process-Workflows Ausgabe

10, 16 DEC 2021
Issue

Inhaltsverzeichnis Seite Table of Contents Page

1 Prozesssteckbrief 2 1 Process Summary 2

2 Software Entwicklungs-Prozess-Abläufe 3 2 Software Development-Process-Workflows 3
2.1 Software Life Cycle Prozesse 3 2.1 Software Life Cycle Processes 3
2.2 Transitions-Kriterien zwischen Prozessen 7 2.2 Transition Criteria between Processes 7
2.3 Rollen im Software Life Cycle 8 2.3 Roles of the Software Life Cycle 8
2.4 Aufbau der Prozessbeschreibung 8 2.4 Structure of the Process Description 8
2.4.1 COTS Management 9 2.4.1 COTS Management 9
2.4.2 Security Management & Development 9 2.4.2 Security Management & Development 9
3 Prozessflussdiagramm des Software Life Cycle 10 3 Workflow diagram of Software Life Cycle 10
3.1 Prozessflussdiagramm für den Implementer 10 3.1 Workflow diagram for the Implementer 10
3.2 Prozessflussdiagramm für den Verifier 11 3.2 Workflow diagram for the Verifier 11
3.3 Prozessflussdiagramm für den CM 12 3.3 Workflow diagram for the CM 12
3.4 Prozessflussdiagramm für die QA 13 3.4 Workflow diagram for the QA 13
3.5 Angewendete Werkzeuge 14 3.5 Utilized Tools 14
4 Prozessabläufe im Software Life Cycle 15 4 Process flow of Software Life Cycle 15
4.1 Software Planungs-Prozess 15 4.1 Software Planning Process 15
4.2 Software Entwicklungs-Prozesse 16 4.2 Software Development Processes 16
4.2.1 Software Requirements-Prozess 16 4.2.1 Software Requirements Process 16
4.2.2 Software Design-Prozess 17 4.2.2 Software Design Process 17
4.2.3 Software Coding-Prozess 18 4.2.3 Software Coding Process 18
4.2.4 Integrations-Prozess 19 4.2.4 Integration Process 19
4.3 Integrale Prozesse 19 4.3 Integral Processes 19
4.3.1 Software Verifikations-Prozess 19 4.3.1 Software Verification Process 19
4.3.2 Software Configuration-Management-Prozess 24 4.3.2 Software Configuration Management Process 24
4.3.3 Software Quality-Assurance-Prozess 25 4.3.3 Software Quality Assurance Process 25
4.3.4 Certification-Liaison-Prozess 26 4.3.4 Certification Liaison Process 26
4.3.5 Produktions-Transfer-Prozess 29 4.3.5 Production Transfer Process 29
4.4 Softwareänderungen 31 4.4 Software Changes 31
4.4.1 Planung des Änderungsprozesses 31 4.4.1 Planning of Change Process 31
4.4.2 Änderungsprozess 32 4.4.2 Change Process 32
5 Mitgeltende Unterlagen 33 5 Associated Documents 33
6 Änderungsverzeichnis 35 6 Record of Revision 35

Erstellt: Geprüft:
Prepared: Checked:
M. Eiserle E. Roeske
End-to-End Quality Management Head of Engineering

Freigegeben
Approved:
A. Siems
Engineering Support
 Software Entwicklungs-Prozess-Abläufe PB-EN-32
Seite 2 von 36
Software Development-Process-Workflows Page 2 of 36
Ausgabe
10, 16 DEC 2021
Issue

1 Prozesssteckbrief 1 Process Summary

Prozessinput Prozessinhalt Prozessoutput

Process input Process content Process output

 SoW, Spezifikation auf Dieses Dokument beschreibt die Funktionen und Abläufe  Software Life Cycle
System / Equipment bei der Entwicklung von Softwareprodukten im Bereich Data gemäß DO-178,
Level Airbus BUX Engineering. DO-330, DO-331,
 Normen/Standards: 1 DO-332, DO-333,
DO-178, DO-330, ABD0100, COTS-MP,
DO-331, DO-332, SMDP
DO-333, CRIs, IPs,  Review-Reports ge-
ABD0100, PB-EN-60, mäß ABD0100 /
PB-EN-61, PB-EN-62, PB-EN-60
PV-EN-63, COTS-MP,
SMDP

 SoW, Specification on
System / Equipment
Level
 Norms/Standards:1
DO-178, DO-330,
DO-331, DO-332,
DO333, CRIs, IPs,
ABD0100, PB-EN-60,
PB-EN-61, PB-EN-62,
PV-EN-63, COTS-MP,
SMDP
This document describes the functions and processes in  Software Life Cycle
order to develop software products within Airbus BUX Data according to
Engineering. DO-178, DO-330,
DO-331, DO-332,
DO-333, ABD0100,
COTS-MP, SMDP
 Review-Reports ac-
cording to ABD0100 /
PB-EN-60

Lieferanten des Geltungsbereich  Engineering Kunden des

Processes Prozesses
Suppliers of the Applicability Customers of the
 Engineering
process process
 interne Fachbereiche Interessens-  Prozesseigner  interne Fachbereiche
gruppen
 externe Fachbereiche  Prozessbeteiligte  externe Fachbereiche
 externer Kunde  externer Kunde

 internal Departments Stakeholders  Process Owner  internal Departments

 external Departments  Process Operator  external Departments
 external Customer  external Customer

Prozesseigner  Leiter Engineering

Process Owner
 Head of Engineering

Für Begriffe und Abkürzungen siehe Abkürzungsverzeichnis

For terms and abbreviations see List of Abbreviations.

1 Über das projektspezifische SoW können noch zusätzliche Normen und Standards definiert sein (z.B. DO-200, DO-248).
Project specific SoW might define additional norms and standards being applicable (e.g. DO-200, DO-248).
 Software Entwicklungs-Prozess-Abläufe
Software Development-Process-Workflows
2 Software Entwicklungs-Prozess-Abläufe
Der in diesem Prozess dokumentierte Software Life
Cycle basiert auf der DO-178 und der internen Pro-
zessdefinition/ Templates und ist gültig für alle Vorha-
ben für die Entwicklung von Softwareprodukten der
Software Level B bis E.
Diese Prozessbeschreibung basiert auf der DO-178
Version C.
Vorgängerversionen, die Prozesse beinhalten, die auf
der DO-178B basieren, können weiterhin für die Ent-
wicklung von neuer Software genutzt werden, sofern
die Kriterien erfüllt sind, die im AMC20-115 in der ak-
tuell gültigen Version definiert sind.
Im Falle, dass die Kapitelidentifikationen für äquivalen-
ten Inhalt zwischen der aktuellen und vorherigen
DO-178 differieren, sind alle gültigen Kapitelreferenzen
in den Prozessflussdiagrammen identifiziert; getrennt
durch „/“.
Die in den DO-178C Ergänzungen DO-331, DO-332
und DO-333 sowie DO-330 adressierten Details sind
nicht explizit in diesem Software Entwicklungs-
Prozess-Ablauf berücksichtigt, um den Ansatz eines
DO-178 orientierten Software Life Cycle Überblicks zu
wahren. Wenn die Anwendung über die oben geliste-
ten Kriterien gegeben ist, muss der Inhalt entspre-
chend berücksichtigt werden.
2.1 Software Life Cycle Prozesse
Software Planungs-Prozess
Der Software Planungs-Prozess produziert oder selek-
tiert die Software Pläne und Standards, welche die
Software Entwicklungs-Prozesse und die integralen
Prozesse regeln.
Software Entwicklungs-Prozesse
Die Software Entwicklungs-Prozesse produzieren das
Software Produkt. Diese bestehen aus den folgenden
Sub-Prozessen:
 Software Requirements-Prozess
 Software Design-Prozess
 Software Coding-Prozess
 Integrations-Prozess
Integrale Prozesse
Die integralen Prozesse sichern die Fehlerfreiheit, die
Steuerung/Überwachung und das Vertrauen in die
Software Entwicklungs-Prozesse und des produzierten
Outputs gemäß der Software Pläne und Standards ab.
PB-EN-32
Seite 3 von 36
Page 3 of 36
Ausgabe
10, 16 DEC 2021
Issue
2 Software Development-Process-Workflows
This process documents the software life cycle based
on the DO-178 and the internal process definition/
templates and is valid for all assignments for the de-
velopment of software products with software level B to
E.
This process description is based on DO-178 version
C.
Previous versions containing processes based on
DO178B may be continued to be used for new soft-
ware development in case the criteria given in the cur-
rent valid issue of AMC20-115 are met.
In case where chapter identification differs for equiva-
lent content between the current and previous version
of the DO-178, all applicable chapter references are
identified within the workflow diagrams; separated by
“/”.
The details addressed by DO-178C supplements
DO-331, DO-332 and DO-333 as well as DO-330 are
not explicit considered within this software develop-
ment-process-workflow in order to keep the overview
approach oriented to the main software life cycle of
DO-178. If applicable in accordance with the criteria
listed above, the content has to be considered, accord-
ingly.
2.1 Software Life Cycle Processes
Software Planning Process
The software planning process produces or selects the
software plans and standards that direct the software
development processes and the integral processes.
Software Development Processes
The software development processes produce the
software product. They consist of the following sub-
processes:
 software requirements process
 software design process
 software coding process
 integration process
Integral Processes
The integral processes ensure the correctness, control,
and confidence of the software life cycle processes
and their outputs according to the software plans and
standards.
 Software Entwicklungs-Prozess-Abläufe PB-EN-32
Seite 4 von 36
Software Development-Process-Workflows Page 4 of 36
Ausgabe
10, 16 DEC 2021
Issue

Die integralen Prozesse laufen parallel zu den eigentli- The integral processes are performed concurrently
chen Software Entwicklungs-Prozessen während des with the software development processes throughout
Software Life Cycle. the software life cycle.

Folgende integrale Prozesse sind definiert: Following integral processes are defined:
 Software Verification-Prozess  software verification process
 Software Configuration-Management-Prozess  software configuration management process
 Software Quality-Assurance-Prozess  software quality assurance process
 Certification-Liaison-Prozess  certification liaison process

Die folgende Abbildung zeigt eine Übersicht über die The following figure depicts an overview of the soft-
Software Life Cycle Prozesse und der integrierten ware life cycle processes and their associated data.
Dokumentation. Die roten Nummern geben das The red numbers indicate the reference chapter of
Referenzkapitel zur DO-178 an, welches den Prozess- DO-178 where the process respective data content is
respektive den Dokumenteninhalt beschreibt. described.

SW Life Cycle Prozesse und Dokument

CERTIFICATION Struktur RTCA DO-178
STATEMENT of
REQUIREMENTS Ref. to DO-178
WORK

System Life Cycle

RTCA DO-178, DO-330, (SoW)

Prozesse
DO-331, DO-332, DO-333
CRIs, IPs
SPEZIFIKATION auf
SYSTEM /
EQUIPMENT LEVEL

SOFTWARE ENTWICKLUNGS-PROZESSE 5.0

Software
Plan for Software Development
Aspects of
Plan
Certification 11.2
11.1
Trace Data 11.21
Software Entwicklungs-Prozesse

Software Life Software Software

Cycle Environment Requirements Rules
Requirements
Config. Index Standards Data
11.6 11.9 Trace Data 11.21 Trace Data 11.21
11.15

Software Design Software Design

Standards Rules Description Parameter Data
Software 11.7 11.10 Trace Data 11.21 Item File
Configuration 11.22
Management Plan
11.4 Software Code
Source Code Executable
Standards Rules
Trace Data 11.11 Object Code
11.8
11.21 11.12
Cases & Results
Software Quality Procedures
Software Test
Assurance Plan Standards
11.5 n/a
Software Software
Software Test
Verification Cases Trace Data Verification Coverage
Verification Plan
and Procedures 11.21 Results Traceability
11.3 11.13 11.14
Integral Prozesse

SOFTWARE PLANUNGS-PROZESS 4.0 SOFTWARE VERIFICATION PROZESS 6.0

Software Software
SOFTWARE CONFIGURATION MANAGEMENT PROZESS 7.0 Configuration Problem Configuration
Management Reports Index
Records 11.16
SOFTWARE QUALITY ASSURANCE PROZESS 8.0 11.18 11.17 Software Quality Software
Assurance Accomplishment
Records Summary
CERTIFICATION LIAISON PROZESS 9.0
11.19 11.20

Abbildung 1: Übersicht der Software Life Cycle Prozesse und Dokumentation

 Software Entwicklungs-Prozess-Abläufe PB-EN-32
Seite 5 von 36
Software Development-Process-Workflows Page 5 of 36
Ausgabe
10, 16 DEC 2021
Issue

SW Life Cycle Processes and Document

CERTIFICATION Structur RTCA DO-178
STATEMENT of
REQUIREMENTS Ref. to DO-178
WORK

System Life Cycle

RTCA DO-178, DO-330, (SoW)

Processes
DO-331, DO-332, DO-333
CRIs, IPs
SPECIFICATION on
SYSTEM /
EQUIPMENT LEVEL

SOFTWARE DEVELOPMENT PROCESSES 5.0

Software
Plan for Software Development
Aspects of
Plan
Certification 11.2
11.1

Software Development Processes

Trace Data 11.21

Software Life Software Software

Cycle Environment Requirements Rules
Requirements
Config. Index Standards Data
11.6 11.9 Trace Data 11.21 Trace Data 11.21
11.15

Software Design Software Design

Standards Rules Description Parameter Data
Software 11.7 11.10 Trace Data 11.21 Item File
Configuration 11.22
Management Plan
11.4 Software Code
Source Code Executable
Standards Rules
Object Code
11.8 Trace Data 11.11
11.21 11.12
Cases & Results
Software Quality Procedures
Software Test
Assurance Plan Standards
11.5 n/a
Software Software
Software Test
Verification Cases Trace Data Verification Coverage
Verification Plan
and Procedures 11.21 Results Traceability
11.3 11.13 11.14

Integral Processes
SOFTWARE PLANNING PROCESS 4.0 SOFTWARE VERIFICATION PROCESSES 6.0

Software Software
SOFTWARE CONFIGURATION MANAGEMENT PROCESS 7.0 Configuration Problem Configuration
Management Reports Index
Records 11.16
SOFTWARE QUALITY ASSURANCE PROCESS 8.0 11.18 11.17 Software Quality Software
Assurance Accomplishment
Records Summary
CERTIFICATION LIAISON PROCESS 9.0
11.19 11.20

Figure 1: Overview Software Life Cycle Processes and Data

Produktions-Transfer-Prozess Production Transfer Process

Zusätzlich zu den Prozessen zur Entwicklung des In addition to the processes for development of the
Software Produktes gemäß ABD0100 und DO-178 software product according to ABD0100 and DO-178 a
existiert der Produktions-Transfer-Prozess zur Überlei- production transfer process exists in order to transfer
tung des entwickelten Software Produktes in die konti- the developed software product into the continuous
nuierliche Serienbetreuung zu Serienproduktionszwe- serial support for series production purpose.
cken.
 Software Entwicklungs-Prozess-Abläufe
Software Development-Process-Workflows
COTS Management Prozess
Im Falle der Verwendung von COTS (Commercial off
the Shelf) Produkten kommt der COTS Management
Prozess zur Anwendung.
Der COTS Management Prozess definiert den Life
Cycle Prozess und die Daten für ein COTS Manage-
ment über den kompletten A/C Lebenszyklus. Das
beinhaltet die COTS Verifikation, Bewertung und Aus-
wahl, Sicherheit, Beschaffung, Integration und Konfigu-
rations-Management, Wartung und Support, organisa-
torische Verantwortlichkeiten nebst Berechtigungen,
Risiko Management und die Identifikation von Artefak-
ten zur Unterstützung des COTS Management.
Der COTS Management Prozess ist im COTS Ma-
nagement Plan (COTS-MP) beschrieben und gilt für
alle Software Embedded COTS und Entwicklungstools.
Der COTS-MP gilt dann zusätzlich zu diesem Doku-
ment.
Security Management & Development Prozess
Der Security Management und Development Prozess
kommt in dem Falle zur Anwendung, in dem das pro-
jekt- / produkt-spezifische Statement of Work (SoW)
die Verwendung der Security Assurance Requirements
(SAR) vorschreibt.
Der Security Management und Development Prozess
definiert den Life Cycle Prozess und die sogenannten
Projekt Assets für ein Security Management über den
kompletten A/C Lebenszyklus, um das Produkt ent-
sprechend des geforderten Security Assurance Level
(SAL) zu entwickeln. Das beinhaltet:
 eine Beschreibung der Security Organisation auf
Unternehmensbereichs- und Projektlevel,
 eine Beschreibung der Security Infrastruktur auf
Unternehmensbereichs- und Projektlevel,
 eine Liste der Security Projekt Assets des Produk-
tes; inkl. Spezifikation, Designs & Implementierung,
Verifikation, Validierung und Evaluierungsdaten,
Leitlinien und deren Verfügbarkeit zu den Review,
 eine Development Tool Analyse; inkl. des Konfigu-
rationsmanagements
 eine COTS Analyse,
 eine Definition des Life Cycle Models; inkl. einer
Konformitätserklärung, wie Security berücksichtigt
wird, um konform zu dem für das Produkt geforder-
ten SAL zu sein,
 Gesetzes- und Regulierungsinformation,
 Security Vulnerability Analyse; inkl. Security
Kontrollprozeduren
PB-EN-32
Seite 6 von 36
Page 6 of 36
Ausgabe
10, 16 DEC 2021
Issue
COTS Management Process
In the case of COTS (Commercial off the Shelf) prod-
uct usage the COTS management process becomes
applicable.
The COTS management process defines the process
life cycle and data for COTS management during the
A/C life cycle. That includes COTS verification, evalua-
tion and selection, security, acquisition, integration and
configuration management, maintenance and support,
organizational responsibilities, accountability and au-
thority, risk management and identification of artefacts
to support COTS management.
The COTS management process is described in the
COTS Management Plan (COTS-MP), applicable for
all software embedded COTS and development tools.
The COTS-MP shall be considered in addition to this
document.
Security Management & Development Process
In case of the project / product specific Statement of
Work (SoW) declares the application of Security
Assurance Requirements (SAR), the Security
management and development process becomes
applicable.
The Security management and development process
defines the process life cycle and project assets for
security management during the A/C life cycle in order
to develop the product with the Security Assurance
Level (SAL) required, including:
 a description of the security organization at corpo-
rate and project levels,
 a description of the security infrastructure at corpo-
rate and project levels,
 a list of all security project assets of the product;
incl. specification, design & implementation, verifi-
cation, validation and evaluation data, guidance
documents and its availability for reviews,
 a development tool analysis; incl. configuration
management,
 a COTS analysis,
 a definition of the life-cycle model; incl. a conform-
ance claims rationale how to take the security into
account in order being compliant with the required
SAL for the product,
 laws and regulation information,
 Security Vulnerability Analysis; incl. security survey
procedure
 Software Entwicklungs-Prozess-Abläufe
Software Development-Process-Workflows
Der Security Management und Development Prozess
ist im Security Management und Development Plan
(SMDP) beschrieben.
Der SMDP gilt zusätzlich zu diesem Dokument
Exportkontrolle Prozess
Im Fall von Exportvorhaben wie
 Voranfragen, Angebotsanforderungen
 Kooperations- oder Lizenzvorhaben
 Ausfuhr/Verbringung von Daten
im Sinne der PB-IM-06, ist der Projektleiter vorab zu
informieren und der Prozess der Exportkontrolle ge-
mäß PB-IM-06 zu berücksichtigen.
2.2 Transitions-Kriterien zwischen Prozessen
Jeder Software Life Cycle Prozess führt Aktivitäten auf
Inputs aus, um einen Output zu produzieren.
Transitions-Kriterien werden verwendet, um zu be-
schreiben, ob in einen Prozess eingetreten oder wie-
der eingetreten respektive ob ein Prozess abgeschlos-
sen werden kann.
Die Transitions-Kriterien für den Prozess-Einstieg oder
-Wiedereinstieg sind erfüllt, wenn die Verfügbarkeit der
genehmigten und autorisierten Prozess-Inputs besteht.
Der Input eines Prozesses braucht dabei nicht voll-
ständig zu sein bevor der Prozess initiiert werden
kann, wenn die für diesen Prozess eingeführten Tran-
sitions-Kriterien erfüllt sind.
Wenn ein Prozess auf unvollständigen Input agiert,
muss für nachträglichen Input des Prozesses eine
Prüfung erfolgen, um zu bestimmen, ob vorheriger
Output des Prozesses weiterhin gültig ist.
Die Transitions-Kriterien für den Prozessabschluss
sind erfüllt, wenn die Zielsetzungen des Prozesses und
die damit verbundenen Zielsetzungen der integralen
Prozesse erfüllt sind. Die Bestätigung erfolgt durch den
erfolgreichen Abschluss des zugehörigen Reviews /
Quality Gates im Status „grün“ oder „gelb“ gemäß QG
Ampelsteuerung der PB-EN-60.
Anmerkung: Die Transitions-Kriterien sind für jeden
Software Life Cycle Prozess detailliert im Kapitel 4
aufgeführt.
PB-EN-32
Seite 7 von 36
Page 7 of 36
Ausgabe
10, 16 DEC 2021
Issue
The Security management and development process
is described in the Security Management and Devel-
opment Plan (SMDP).
The SMDP shall be considered in addition to this doc-
ument.
Export control process
In case of exporting plans like
 advance inquiries, quotation requests
 cooperation- or licensing projects
 export/ transfer of data
in the meaning of PB-IM-06, the project leader should
be informed previously and the Export control process
should be taken into account according to PB-IM-06.
2.2 Transition Criteria between Processes
Each software life cycle process performs activities on
inputs to produce outputs.
Transition criteria are used to determine whether a
process may be entered or re-entered respective may
be completed.
The transition criteria for the entering or re-entering of
a process are satisfied if the approved and authorized
process-inputs are available.
Considering that the input to a process need not be
complete before that process can be initiated, if the
transition criteria established for the process are
satisfied.
If a process acts on partial inputs, subsequent inputs to
the process have to be examined to determine that the
previous outputs of the process are still valid.
The transition criteria for the process completion are
satisfied if the objectives of this process and the objec-
tives of the integral processes associated with it are
completed and satisfied, too. The compliance is shown
by successfully completion of the related review / quali-
ty gate in status “green” or “amber” according to QG
traffic light control of PB-EN-60.
Note: The transition criteria’s for each software life
cycle process are listed in detail in chapter 4.
 Software Entwicklungs-Prozess-Abläufe
Software Development-Process-Workflows
2.3 Rollen im Software Life Cycle
Die Aufgaben und Ziele der oben aufgeführten Pro-
zesse werden den folgenden vier Rollen zugeordnet:
 Implementer
 Verifier
 Configuration Manager (CM)
 Quality Assurance (QA, durch PQR)
Der Begriff Quality Assurance (QA), der im
Zusammenhang mit den Software-Life-Cycle
Prozessen verwandt wird, wird analog zum Begriff
Process Assurance (PA) genutzt. In diesem
Zusammenhang werden die Aktivitäten zur QA durch
die Product Quality Responsible (PQR) ausgeführt.
Die Rolleninhaber sind für die Durchführung der zuge-
ordneten Aktivitäten und die Erreichung der zugeord-
neten Ziele verantwortlich. Die Rollen sind im Detail in
der PB-EN-60 beschrieben.
2.4 Aufbau der Prozessbeschreibung
Für jede Rolle ist ein eigener Workflow beschrieben,
der die jeweiligen Zusammenhänge zwischen den
Inputs / Outputs und den Aktivitäten pro Prozessschritt
darstellt; wobei die Beschreibung der Aktivitäten ledig-
lich eine Übersicht umfasst. Der volle Umfang der Akti-
vitäten ist den angegebenen Referenzen zu entneh-
men.
Des Weiteren hängen die tatsächlich durchzuführen-
den Aktivitäten und die zu generierenden Outputs
maßgeblich vom anzuwendenden SW Level ab. Diese
Abhängigkeit ist den referenzierten Normen & Stan-
dards, den Input Data respektive der Workflow Spalte
„Applicability by SW Level“ unter Berücksichtigung der
Präzedenz zu entnehmen. Dabei übersteuert das je-
weils speziellere Dokument das Allgemeinere, wobei
davon auszugehen ist, dass die spezielleren Vorgaben
keinen direkten Widerspruch zu den allgemeineren
darstellen. Letztendlich gilt für ein spezifisches Projekt
die Prozessdefinition in den anzuwendenden Software
Plänen und Standards. Folgende Hierarchisierung vom
Speziellen zum Allgemeinen gilt:
1. Projektspezifische Prozessdefinition (Software
Pläne und Standards)
2. Buxtehude interne allgemeine Prozessdefinition
(PBs, Templates)
3. Spezifikationen (SoW, Spezifikation auf Sys-
tem/Equipment Level)
4. Airbus Direktiven (ABD0100)
5. Internationale Standards (DO-178, CRIs, etc.)
PB-EN-32
Seite 8 von 36
Page 8 of 36
Ausgabe
10, 16 DEC 2021
Issue
2.3 Roles of the Software Life Cycle
The activities and objectives of the processes specified
above are assigned to the following four roles:
 Implementer
 Verifier
 Configuration manager (CM)
 Quality assurance (QA, by PQR)
The term Quality Assurance (QA) that is used within
the context of software life cycle processes is used in
analogy with the term Process Assurance (PA). In this
context the activities for QA are performed by the
Product Quality Responsible (PQR).
The role holders are responsible for performance of
their assigned activities and attainability of their
assigned objectives. The roles are described in detail
in the PB-EN-60.
2.4 Structure of the Process Description
For each role its own workflow is described, that repre-
sents the respective coherences between the inputs /
outputs and the activities per process step; considering
that the description of the activities comprises just an
overview. The details of all activities are described in
the given references.
Further the actual activities to be performed and
outputs to be generated depend on the applicable SW
level. This dependencies can be found in the
referenced norms & standards, input data respective
the workflow column „Applicability by SW Level“
considering the precedence in the meaning, that the
more specific document overrules the general.
Thereby, it shall be taken into account that the more
specific rules do not conflict with the general ones.
Finally, the process definition of applicable software
plans and standards applies for a specific project. The
following hierarchical structure, from specific to
general, applies:
1. Project specific process definition (software plans
and standards)
2. Buxtehude internal general process definition
(PBs, templates)
3. Specifications (SoW, specification on system /
equipment level)
4. Airbus directives (ABD0100)
5. International standards (DO-178, CRIs, etc.)
 Software Entwicklungs-Prozess-Abläufe
Software Development-Process-Workflows
Alle vier Workflows sind in Kapitel 3.1 bis 3.4 darge-
stellt und werden in den nachstehenden Kapiteln ver-
tiefend behandelt. Die einzelnen Workflows sind über
die Prozessschrittnummern respektive den Quality
Gates / Reviews synchronisiert.
Die Synchronisation zum Equipment Entwicklungs-
Prozess-Ablauf gemäß PB-EN-30 respektive Hardware
Entwicklungs-Prozess-Ablauf gemäß PB-EN-31 ist aus
Gründen der Redundanzvermeidung nur im Prozess-
flussdiagramm für den Implementer integriert. Die
Synchronisation zum System Validation- und Verifica-
tion-Prozess-Ablauf gemäß PB-EN-40 ist nur im Pro-
zessflussdiagramm für die QA detailliert dargestellt, da
nur hier der Detailgrad der entsprechenden Prozess-
schnittstelle eine Abbildung findet. Die Workflow-
Synchronisationen erfolgen jeweils über die Prozess-
schrittnummern.
2.4.1 COTS Management
Der COTS Management Plan (COTS-MP) berücksich-
tigt bereits alle Aspekte des COTS Management Pro-
zesses im Sinne von Normen & Standards, Eingangs-
daten, Prozessschritte, Aktivitäten, Ausgangsdaten,
SW Level Abhängigkeit und Tools. Um Redundanzen
zu vermeiden, finden diese keine erneute Abbildung in
der Prozessbeschreibung dieses Dokumentes. Ledig-
lich das Vorgehen zur Anwendung / Gültigkeitserklä-
rung des COTS-MP ist im Software Planungs-Prozess
adressiert (siehe Prozessschritt (1) des Prozessfluss-
diagramm für den Implementer, Kapitel 3.1).
Um dennoch die Anwendung des COTS-MP kenntlich
zu machen, ist dieser in den „Input Data“ aller betroffe-
nen Prozessschritte eines jeden Prozessflussdiagrams
aufgeführt.
2.4.2 Security Management & Development
Der Security Management und Development Plan
(SMDP) berücksichtig bereits alle Aspekte des
Security Management und Development Prozesses im
Sinne von Normen & Standards, Eingangsdaten,
Prozessschritte, Aktivitäten, Ausgangsdaten, Security
Assurance Level (SAL) Abhängigkeit und Tools. Um
Redundanzen zu vermeiden, finden diese keine
erneute Abbildung in der Prozessbeschreibung dieses
Dokumentes. Lediglich das Vorgehen zur Anwendung /
Gültigkeitserklärung des SMDP ist im Software
Planungs-Prozess adressiert (siehe Prozessschritt (1)
des Prozessflussdiagramm für den Implementer,
Kapitel 3.1).).
Um dennoch die Anwendung des SMDP kenntlich zu
machen, ist dieser in den „Input Data“ aller betroffenen
Prozessschritte eines jeden Prozessflussdiagrams
aufgeführt.
PB-EN-32
Seite 9 von 36
Page 9 of 36
Ausgabe
10, 16 DEC 2021
Issue
All four workflows are represented in chapter 3.1 to 3.4
and are deepened discussed in the following chapters.
The single workflows are synchronized by process
step numbers respectively by the quality gates / re-
views.
The synchronization with Equipment Development-
Process-Workflow according to PB-EN-30 respective
Hardware Development-Process-Workflow according
to PB-EN-31 is only integrated into the workflow dia-
gram for the implementer due to avoidance of redun-
dancy. The synchronization with System Validation-
und Verification-Process-Workflow according to
PB-EN-40 is integrated in detail into the workflow dia-
gram for the QA only, hence only this workflow depicts
the detail level of respective process interface. In any
cases the workflows are synchronized by process step
numbers.
2.4.1 COTS Management
Since, the COTS Management Plan (COTS-MP)
already considers all aspects of the COTS
management process in terms of norm & standards,
input data, process steps, activities, output data, SW
level application and tools they are not duplicated into
the process description of this document to avoid
redundancies. Just the way of application of the
COTS-MP is addressed in the software planning
process (see process step (1) of Workflow diagram for
the Implementer, chapter 3.1).
Nevertheless, in order to indicate the application of the
COTS-MP, it is listed as “Input Data” for every applica-
ble process step of any workflow diagram.
2.4.2 Security Management & Development
Since, the Security Management and Development
Plan (SMDP) already considers all aspects of the
Security management and development process in
terms of norm & standards, input data, process steps,
activities, output data, Security Assurance Level (SAL)
application and tools they are not duplicated into the
process description of this document to avoid
redundancies. Just the way of application of the SMDP
is addressed in the software planning process (see
process step (1) of Workflow diagram for the
Implementer, chapter 3.1).
Nevertheless, in order to indicate the application of the
SMDP, it is listed as “Input Data” for every applicable
process step of any workflow diagram.
 Software Entwicklungs-Prozess-Abläufe PB-EN-32
Seite 10 von 36
Software Development-Process-Workflows Page 10 of 36
Ausgabe
10, 16 DEC 2021
Issue

3 Prozessflussdiagramm des Software Life Cycle 3 Workflow diagram of Software Life Cycle

3.1 Prozessflussdiagramm für den Implementer 3.1 Workflow diagram for the Implementer

No. Norms & Standards Input Data Process Steps Activities Output Data

SOFTWARE WORKFLOW
SOFT WARE PLANNING PROCESS (Development)
DO-178: 4.2 Software Planning Process
Develop the Plan for Software Aspects of Certification (PSAC) inclusive
integration of SW change impact analysis for re-verification purpose in
terms of previously developed software, Software Development Plan
(SDP), Software Requirements Standards (SRS), Software Design
Standards (SDS), Software Code Standards (SCS). Therefore define the
Specifications: SoW, Spec. on means of producing software which will satisfy the system requirements
System / Equipment Level B, C, D, E
and provide the level of confidence which is consistent with airworthiness
DO-178 Plans: COTS-MP, SMDP requirements.
4.0, 2.0, 9.0, 12.0, A-1, A-10 Standards: --- For Quality
Note: Further plans and standards are produced by software workflows
11.1, 11.2, 11.6, 11.7, 11.8 Templates: Gate PSAC (including SW
verification, configuration management, quality assurance.
PSAC (ETemp-052), application change impact
CRIs, IPs SDP (ETemp-055), see analysis), DOT,
In case of COTS is planned to be used, the COTS Management Plan
(1) SRS (ETemp-059), Workflow SDP, CMT,
(COTS-MP) shall be made applicable by application statement and
ABD0100 SDS (ETemp-056), diagram for SRS, CHT
reference within the PSAC.
SCS (ETemp-054), the QA SDS,
Note: Consider the explanation in chapter 2.1 and 2.4.1
PB-EN-60, PB-EN-61, Data: SCS
PB-EN-62 SW change impact analysis PPR NO
ABD0100.2.4 GO In case of the project / product specific Statement of Work (SoW) declares
(ETemp-515) the application of Security Assurance Requirements (SAR), the Security
Quality Gate/Review: Management and Development Plan (SMDP) shall be made applicable by
PPR (ETemp-083) application statement and reference within the PSAC.
Note: Consider the explanation in chapter 2.1 and 2.4.2

DO-178: 9.1 Means of Compliance and Planning

Submit the PSAC and other requested data to the certification authority B, C, D
for review, resolve issues identified by the certification authority and
obtain agreement with the certification authority on the PSAC.
SOFTWARE WORKFLOW/
SOFTWARE DEVELOPMENT PROCESS

DO-178: 5.1.2 Software Requirements Process

DO-178 Develop the Software Requirements Data (SRD), including the software
Specifications: SoW, Spec. on B, C, D, E
5.0, 5.1, 5.5, A-2, high-level requirements from the system requirements of specification on
System / Equipment Level
11.9 system / equipment level according to SDP and SRS. Indicate the derived
Plans: SDP, COTS-MP, SMDP For Quality DOT,
software high-level requirements to the system safety assessment
Standards: SRS Gate SRD CMT,
CRIs, IPs process.
(2) Templates: SRD (ETemp-418),
If Parameter Data Items (PDI) are planned, develop the Parameter
application Traceability Matrix CHT,
PRD (ETemp-708) see (PRD) RMT,
ABD0100 Requirements Data (PRD).
Data: --- SRR NO Workflow MOT
Quality Gate/Review: ABD0100.2.4 GO diagram for
PB-EN-60, PB-EN-61, DO-178: 5.5 Traceability
SRR (Etemp-084) the QA
PB-EN-62 Provide traceability between software high-level requirements and system
requirements according to SDP and SRS.

DO-178 DO-178: 5.2.2 Software Design Process

B, C, D, E
5.0, 5.2, 5.5, A-2, Develop the Software Design Description (SDD), including the software
Specifications: ---
11.10 low-level requirements and the software architecture from the software
Plans: SDP, COTS-MP, SMDP For Quality DOT,
high-level requirements of SRD according to SDP and SDS. Indicate the
Standards: SDS Gate CMT,
CRIs, IPs derived software low-level requirements to the system safety assessment SDD
(3) Templates: SDD (ETemp-419)
process.
application
Traceability Matrix
CHT,
Data: SRD see RMT,
ABD0100
Quality Gate/Review: SDR NO Workflow MOT
DO-178: 5.5 Traceability
SDR (Etemp-085) ABD0100.2.4 GO diagram for
PB-EN-60, PB-EN-61, Provide traceability between software low-level requirements and software
the QA
PB-EN-62 high-level requirements according to SDP and SDS.

DO-178
5.0, 5.3, 5.5, A-2,
DO-178: 5.3.2 Software Coding Process
11.11 Specifications: ---
Implement the source code from the software low-level requirements and CMT,
Plans: SDP, COTS-MP, SMDP
the software architecture of SDD according to SDP and SCS. CHT,
CRIs, IPs Standards: SCS Software Coding Source Code
(4) Templates: SCS (ETemp-054) Process
B, C, D, E
Traceability Matrix
RMT,
DO-178: 5.5 Traceability MOT,
ABD0100 Data: SDD
Provide traceability between source code and software low-level DET
Quality Gate/Review: ---
requirements according to SDP and SCS.
PB-EN-60, PB-EN-61,
PB-EN-62

PB-EN-30 (5, 4.2)

Executable Object
Code loaded into the
DO-178 Integration Process target hardware,
(SWI, HSI) B, C, D, E
5.0, 5.4, A-2,
Specifications: --- DO-178: 5.4.2 Integration Process
11.12 Linking and loading
Plans: SDP, COTS-MP, SMDP Generate the Executable Object Code from the source code and linking For Quality
data CMT,
Standards: SCS and loading data (including Parameter Data Items, if applicable) according Gate
CRIs, IPs CHT,
(5) Templates: --- to SDP and SCS. Load the Executable Object Code into the target application
(PDI file) MOT,
Data: Source Code, PDI STRR NO hardware for HW/SW integration purpose according to SDP. see
ABD0100 DET
Quality Gate/Review: PB-EN-60 GO Workflow
memory map
STRR (Etemp-224) diagram for
PB-EN-60, PB-EN-61,
the QA
PB-EN-62

PB-EN-30 (6)

END OF SOFTWARE DEVELOPMENT PROCESS

SOFTWARE WORKFLOW CERTIFICATION LIAISON PROCESS (Development)

Specifications: --- PB-EN-40 (4)

Plans: PSAC, SDP, SVP, SCMP,
SQAP, SECI, COTS-MP, SMDP PB-EN-40 (5)
DO-178 Standards: SRS,SDS,SCS,SwTS
B, C, D, E
9.2, A-10, Templates: SAS (ETemp-422), NO „SW delivery
11.20 PAS (ETemp-710), GO description“ of
For Quality
DDP (ETemp-082/-550), SW Intermediate
Gate DOT,
CRIs, IPs delivery desc. (ETemp-451) Standard
(6) Data:
application CMT,
see CHT
ABD0100 Complete software life cycle data SAS
FDR, FFR, CRC, DR NO Workflow
Quality Gate/Review: (PAS)
ABD0100.2.4 GO diagram for
PB-EN-60, PB-EN-61, SCR (ETemp-086), DDP
the QA
PB-EN-62 FDR (ETemp-087),
FFR (ETemp-088),
CRC (ETemp-089) PB-EN-30 (7,8,9)
DR (ETemp-091 for level E only)

END OF CERTIFICATION LIAISON PROCESS

SOFTWARE WORKFLOW
PRODUCTION TRANSFER PROCESS (Development)

This row is intentionally left blank for synchronisation purpose with

PRL
other workflow diagrams. The process step no. 7 is not applicable in --- --- -- ---
PB-EN-60
this workflow diagram for the Implementer.

END OF PRODUCTION TRANSFER PROCESS

 Software Entwicklungs-Prozess-Abläufe PB-EN-32
Seite 11 von 36
Software Development-Process-Workflows Page 11 of 36
Ausgabe
10, 16 DEC 2021
Issue

3.2 Prozessflussdiagramm für den Verifier 3.2 Workflow diagram for the Verifier

No. Norms & Standards Input Data Process Steps Activities Output Data
SOFTWARE WORKFLO W
SOFT WARE PLANNING PROCESS (Verification)
Specifications: SoW, Spec. on DO-178: 4.2 Software Planning Process SVP (including SW
DO-178 Develop the Software Verification Plan (SVP), inclusive integration of SW B, C, D, E
System / Equipment Level change impact
4.0, 12.0, A-1, 11.3 Software Planning change impact analysis for re-verification purpose, and Software Test
Plans: COTS-MP, SMDP analysis),
Process Standards (SwTS). Therefore define the means by which the software For Quality
Standards: --- SwTS DOT,
CRIs, IPs verification process objectives will be satisfied. Gate
Templates: SVR* CMT,
application
SVP (ETemp-060), Note: SwTS development depends on the used test tool environment. It is *Instead of SVR the CHT
ABD0100 see
SwTS (ETemp-184) mandatory for LDRA and RT Tester, only. signature of Technical
PPR NO Workflow Approver on each plan or on
Data: SW change impact analysis Verify the compliance of the Software Plans to DO-178 through review of
PB-EN-60, PB-EN-61, ABD0100.2.4 GO diagram for separat e compliance marix
(ETemp-515) the compliance matrix, part of each Software Plan or the compliance matrix is also suf ficient as
PB-EN-62 the QA
Quality Gate/Review: --- available as separate Document. verificat ion evidence.

SOFTWARE WORKFLOW
SOFTWARE VERIF ICATION PROCESS
DO-178: 6.3.1/6.6 Review and Analysis of the Software High-level
Requirements
Verification of Outputs Review and analyze the SRD (PRD if applicable), incl. software high-level
Specifications: SoW, Spec. on
of SW Requirements requirements according to SVP (incl. checklist) / SVCP in order to show
System / Equipment Level
Process compliance with SRS, SDP and the system requirements. Report the review
Plans: SVP, SDP, COTS-MP,
SMDP and analysis results into the SVR. SVCP,
DO-178:
Standards: SRS, SwTS SW HL-Requirements DO-178: 6.4.2 Requirements based Test Case Selection SVR incl.
6.0, 6.3.1, 6.3.6/6.4.5, 6.4.4.1, B, C, D, E
Templates: based Develop high-level requirements based test cases / procedures according to Checklist „Software
6.4.2, 6.6, A-3, A-7
SVCP (ETemp-420), Test Case/Procedure SVP. Document the test cases / procedures within the SVCP. Develop PDI Requirements Data DOT,
11.13, 11.14 For Quality
SVR (ETemp-421), development based test cases /procedures, if applicable and document them in PDI Review and Analysis CMT,
Checklist “Software Requirements Gate
Verification Cases and Procedure Data (PVCP). Checklist“ / CHT,
CRIs, IPs application
Data Review and Analysis DO-178: 6.3.6/6.4.5 Review and Analysis of the Test Cases / Checklist RMT,
Checklist” (ETemp-060) see
ABD0100 Verification of Procedures „Verification Process MOT,
Checklist “Verification Process Workflow
Verification Process Review and analyze the test cases / procedures (SVCP, PVCP if Results Review and TET
Results Review and Analysis diagram for
PB-EN-60, PB-EN-61, Results applicable) according to the SVP (incl. checklist) / SVCP / PVCP in order to Analysis Checklist“
Checklist” (ETemp-060) the QA
PB-EN-62 show compliance with the SVP / SwTS. Report the review and analysis (PVCP)
PVCP (ETemp-712) results into the SVR, respectively PAS for PDIs.
Data: SRD, SVCP, PVCP,
DO-178: 6.4.4.1 Requirements-Based Test Coverage Analysis
Traceability Matrix SRR NO Perform according to SVP the requirements-based coverage analysis in
Quality Gate/Review: --- ABD0100.2.4 GO
order to confirm that test cases exist for each software high-level
requirement satisfying the criteria of normal and robustness testing. Report
the analysis results into the SVR respectively PAS for PDIs.
DO-178: 6.3.2/6.3.3 Review and Analysis of the Software Low-Level
Verification of Outputs Requirements and the Software Architecture
Specifications: --- of SW Design Process Review and analyze the SDD, incl. software low-level requirements and
Plans: SVP, SDP, COTS-MP, software architecture according to the SVP (incl. checklist) / SVCP in order
SMDP to show compliance with SDS, SDP and the software high-level
DO-178: Standards: SDS, SwTS requirements. Report the review and analysis results into the SVR. SVCP,
6.0, 6.3.2, 6.3.3, 6.3.6/6.4.5, Templates: SW LL-Requirements DO-178: 6.4.2 Requirements based Test Case Selection B, C SVR incl.
6.4.4.1, 6.4.2, A-4, A-7 SVCP (ETemp-420), based Test Case/ Develop low-level requirements based test cases / procedures according to Checklist „Software
Procedure DOT,
11.13, 11.14 SVR (ETemp-421), SVP. Document the test cases / procedures within the SVCP. Develop PDI For Quality Design Description
Checklist “Software Design development CMT,
based test cases /procedures, (PVCP) if applicable. Gate Review and Analysis CHT,
(3) CRIs, IPs Description Review and Analysis DO-178: 6.3.6/6.4.5 Review and Analysis of the Test Cases / application Checklist“ /
Checklist” (ETemp-060) RMT,
Procedures see Checklist MOT,
ABD0100 Checklist “Verification Process Verification of Review and analyze the test cases / procedures (SVCP, PVCP if Workflow „Verification Process
Results Review and Analysis TET
Verification Process applicable) according to the SVP (incl. checklist) / SVCP / PVCP in order to diagram for Results Review and
PB-EN-60, PB-EN-61, Checklist” (ETemp-060) Results show compliance with the SVP / SwTS. Report the review and analysis the QA Analysis Checklist“
PB-EN-62 PVCP (ETemp-712) results into the SVR, respectively PAS for PDIs. (PVCP)
Data: SDD, SVCP, PVCP,
DO-178: 6.4.4.1 Requirements-Based Test Coverage Analysis
Traceability Matrix
Perform according to SVP the requirements-based coverage analysis in
Quality Gate/Review: --- SDR NO
order to confirm that test cases exist for each software low-level
ABD0100.2.4 GO
requirement satisfying the criteria of normal and robustness testing. Report
the analysis results into the SVR, respectively PAS for PDIs.
Specifications: ---
DO-178: Plans: SVP, SDP, COTS-MP,
6.0, 6.3.4, A-5, SMDP DOT,
11.13, 11.14 Standards: SCS DO-178: 6.3.4 Review and Analysis of the Source Code SVCP, CMT,
Templates: SVCP (ETemp-420), Verification of Outputs Review and analyze the Source Code according to the SVP (incl. SVR incl. CHT,
CRIs, IPs SVR (ETemp-421), of SW Coding Process checklist) / SVCP in order to show compliance with the SCS, SDP and the B, C checklist „Source RMT,
(4) Checklist “Source Code Review software low-level requirements / software architecture. Report the review Code Review and MOT,
ABD0100 and Analysis Checklist” (ETemp- and analysis results into the SVR. Analysis Checklist“ DET,
060) CAT
PB-EN-60, PB-EN-61, Data: Source Code, Traceability
PB-EN-62 Matrix
Quality Gate/Review: ---
Specifications: ---
Plans: SVP, SDP, COTS-MP, Verification of Outputs
DO-178: B, C
SMDP of Integration Process
6.0, 6.3.5, 6.6, A-5,
Standards: SCS SVCP,
11.13, 11.14 DO-178: 6.3.5 Review and Analysis of the Outputs of the Integration For Quality DOT,
Templates:SVCP (ETemp-420), SVR incl.
SVR (ETemp-421), Process Gate CMT,
CRIs, IPs Checklist „Outputs of
(5.1) Checklist “Outputs of Integration Review and analyze the Outputs of the Integration Process according to application CHT,
Integration Process
Process Review and Analysis SVP (incl. checklist) / SVCP in order to show compliance with the SCS, see MOT,
ABD0100 Review and Analysis
Checklist” (ETemp-060) SDP. Report the review and analysis results into the SVR. Workflow DET
Checklist“
Data: diagram for
PB-EN-60, PB-EN-61, STRR NO the QA
Executable Object Code, Linking & GO
PB-EN-62 PB-EN-60
Loading Data, Memory Map
Quality Gate/Review: ---
DO-178: 6.4.3 Requirements-Based Testing
Specifications: --- Perform the hardware/software integration testing, the software integration
Plans: SVP, SDP, COTS-MP, testing and the low-level testing to demonstrate both that the software
SMDP satisfies its requirements and with a high degree of confidence that errors
DO178: Standards: SwTS Testing of Outputs of which could lead to unacceptable failure conditions have been removed. RCS
6.0, 6.3.6/6.4.5, 6.4, 6.4.3, Templates: the Integration Report the test results incl. production of test coverage matrix into the SVR. SVCP
6.4.4.2, 6.5, 6.6, A-6, A-7, SVCP (ETemp-420), Process SVR incl. DOT,
11.13, 11.14 SVR (ETemp-421), (SWI-, HSI-, LL- DO-178: 6.5 Traceability B, C, D, E Checklist CMT,
Checklist “Verification Process Testing) Provide traceability between test cases / procedures (SVCP, PVCP if „Verification Process CHT,
applicable) and test results according to SVP. Results Review and RMT,
(5.2) CRIs, IPs Results Review and Analysis
Checklist” (ETemp-060) Analysis Checklist“ / MOT,
ABD0100 RCS (ETemp-719) DO-178: 6.3.6/6.4.5 Review and Analysis of the Test Results Test Coverage DET,
PVCP (ETemp-712) Verification of Review and analyze the test results (SVR, PAS if applicable) according to MaTrix TET
PB-EN-60, PB-EN-61, PAS (ETemp-710) Verification Process the SVP (incl. checklist) / SVCP / PVCP in order to show compliance with (PVCP)
PB-EN-62 Data: Results the SVP / SwTS. Report the review and analysis results into the SVR / PAS. (PAS)
SVCP, PVCP, SVR, PAS, SRD, DO-178: 6.4.4.2 Structural Coverage Analysis
SDD Perform according to SVP the structural coverage analysis in order to show
B, C
Quality Gate/Review: --- which code structure was not exercised by the requirement-based testing.
Report the analysis results into the SVR.
END OF SOFT WARE VERIF ICATION PROCESS
SOFT WARE WORKFLOW CERTIFICATION LIAISON PROCESS (Verification)
PB-EN-40 (4)
DO-178 Specifications: --- Provide input for the of software to be B, C, D, E
PB-EN-40 (5)
9.2, A-10, Plans: PSAC, SDP, SVP, Input for
transferred to internal system test (PB-EN-40) in order to show compliance
11.20 COTS-MP, SMDP „SW delivery
of software verification process activities with Intermediate Standards For Quality
Standards: SwTS NO description“ of
according to definition of ABD0100.2.4. Gate DOT,
CRIs, IPs Templates: SAS (ETemp-422), GO Intermediate
application CMT,
SW delivery desc. (ETemp-451) Standard
DO-178: 9.2 Compliance Substantiation see CHT
ABD0100 PAS (ETemp-710)
For SCR, FDR, FFR, CRC, DR provide input to the Software Workflow
Data: Input for SAS
FDR, FFR,CRC, DR NO Accomplishment Summary (SAS), PAS if applicable, showing compliance of diagram for
PB-EN-60, PB-EN-61, SVCP, PVCP, SVR, PAS GO (Input for PAS)
ABD0100.2.4 the software verification process activities with the PSAC respective SVP / the QA
PB-EN-62 Quality Gate/Review: ---
SwTS and describe any differences.

END OF CERTIFICATION LIAISON PROCESS

SOFTWARE WORKFLOW
PRODUCTION TRANSFER PRO CESS (Verification)

This row is intentionally left blank for synchronisation purpose with

PRL
other workflow diagrams. The process step no. 7 is not applicable in --- --- -- ---
PB-EN-60
this workflow diagram for the Verifier.

END OF PRODUCTION T RANSFER PROCESS

 Software Entwicklungs-Prozess-Abläufe PB-EN-32
Seite 12 von 36
Software Development-Process-Workflows Page 12 of 36
Ausgabe
10, 16 DEC 2021
Issue

3.3 Prozessflussdiagramm für den CM 3.3 Workflow diagram for the CM

No. Norms & Standards Input Data Process Steps Activities Output Data
SOFTWARE WORKFLOW
SOFTWARE PLANNING PROCESS (Configuration Management)
DO-178: 4.2 Software Planning Process
Specifications: SoW, Spec. on Develop the Software Configuration Management Plan (SCMP).
DO-178 System / Equipment Level Therefore define the means by which the software configuration
B, C, D, E
4.0, 7.0, 12.0, A-1, A-8, Plans: SCMP, SDP, COTS-MP, management process objectives will be satisfied.
11.4, 11.15, 11.17, 11.18 SMDP SCMP,
For Quality
Standards: --- DO-178: 7.2.9/7.5 Software Life Cycle Environment Control SECI,
Gate
CRIs, IPs Templates: Develop the Software Life Cycle Environment Configuration Index (SECI). SCMR for PPR DOT, CMT,
application
SCMP (ETemp-053), Therefore ensure that the tools used to produce the software are baseline CHT
see
ABD0100 SECI (ETemp-057), identified. Problem Reports,
Workflow
SCMR (ETemp-053) SCI
diagram for
PB-EN-60, PB-EN-61, Data: Outputs of the software DO-178: 7.2 Software Configuration Management Process
PPR NO the QA
PB-EN-62, PV-EN-63 planning process Provide the configuration control of the outputs of the software planning
Quality Gate/Review: --- ABD0100.2.4 GO process according to SCMP. Report the activity results into the SCMR.
Produce the Software Configuration Index (SCI) according to SCMP.

SOFTWARE WORKFLOW
SOFTWARE CONFIGURATION MANAGEMENT PROCESS

DO-178
Specifications: ---
7.0, A-8, B, C, D, E
Plans: SCMP, SDP, COTS-MP,
11.17, 11.18
SMDP
For Quality DOT,
Standards: --- SCMR for SRR
CRIs, IPs Gate CMT,
Templates: Baseline,
application CHT,
SCMR (ETemp-053) Produce the Software Problem Reports,
ABD0100 see MOT,
Data: Outputs of the software Configuration Index (SCI) according to SCMP. SCI
Workflow RMT
requirements process and it’s
PB-EN-60, PB-EN-61, diagram for
integral processes
PB-EN-62, PV-EN-63 SRR NO the QA
Quality Gate/Review: ---
ABD0100.2.4 GO

DO-178
Specifications: ---
7.0, A-8, B, C, D, E
Plans: SCMP, SDP, COTS-MP,
11.17, 11.18
SMDP DO-178: 7.2 Software Configuration Management Process
For Quality DOT,
Standards: --- Provide the configuration control of the outputs of the software design SCMR for SDR
CRIs, IPs Gate CMT,
Templates: process and it’s integral processes according to SCMP. Baseline,
application CHT,
SCMR (ETemp-053) Report the activity results into the SCMR. Produce the Software Problem Reports,
ABD0100 see MOT,
Data: Outputs of the software Configuration Index (SCI) according to SCMP. SCI
Workflow RMT
design process and it’s integral
PB-EN-60, PB-EN-61, diagram for
processes
PB-EN-62, PV-EN-63 the QA
Quality Gate/Review: --- SDR NO
ABD0100.2.4 GO

DO-178
Specifications: ---
7.0, A-8,
Plans: SCMP, SDP, COTS-MP,
11.17, 11.18
SMDP
Standards: --- DO-178: 7.2 Software Configuration Management Process DOT,
CRIs, IPs SCMR for Source
Templates: Provide the configuration control of the outputs of the software coding CMT,
B, C, D, E Code Baseline,
SCMR (ETemp-053) process and it’s integral processes according to SCMP. CHT,
ABD0100 Problem Reports
Data: Outputs of the software Report the activity results into the SCMR. MOT
coding process and it’s integral
PB-EN-60, PB-EN-61,
processes
PB-EN-62, PV-EN-63
Quality Gate/Review: ---

DO-178
7.0, A-8, Specifications: --- B, C, D, E
11.17, 11.18 Plans: SCMP, SDP, COTS-MP,
DO-178: 7.2 Software Configuration Management Process DOT,
SMDP For Quality
Provide the configuration control of the outputs of the integration process SCMR for Integration CMT,
CRIs, IPs Standards: --- Gate
and it’s integral processes according to SCMP. Report the Baseline, CHT,
Templates: application
activity results into the SCMR. Produce the Software Configuration Index Problem Reports, MOT,
ABD0100 SCMR (ETemp-053) see
(SCI) according to SCMP. SCI RMT,
Data: Outputs of the integration Workflow
TET
PB-EN-60, PB-EN-61, process and it’s integral processes diagram for
PB-EN-62, PV-EN-63 Quality Gate/Review: --- STRR NO the QA
PB-EN-60 GO

END OF SOFTWARE CONFIGURATION MANAGEMENT PROCESS

SOFTWARE WORKFLOW
CERTIFICATION LIAISON PROCESS (Configuration Management)

PB-EN-40 (4)
Provide the configuration control and input for the
PB-EN-40 (5)
of software to be transferred to internal system test (PB-EN-
40) in order to show compliance of software configuration management
Specifications: --- process activities with Intermediate Standards according to definition of SCI,
DO-178 Plans: PSAC, SDP, SCMP, NO ABD0100.2.4.
GO SCMR for SCR, FDR,
7.0, 9.2, A-8, A-10 COTS-MP, SMDP DO-178: 7.2 Software Configuration Management Process B, C, D, E
FFR, CRC, DR
11.16, 11.17, 11.18, 11.20 Standards: --- Provide the configuration control of the outputs of the complete software Baseline, DOT,
Templates: life cycle processes according to SCMP. Report the activity results into For Quality
Input for SAS, CMT,
CRIs, IPs SCI (ETemp-423), the SCMR. Produce the Software Configuration Index (SCI), PAS if Gate
(Input for PAS) CHT,
SCMR (ETemp-053), FDR, FFR, CRC, DR applicable, according to SCMP. application
Problem Reports MOT,
ABD0100 SAS (ETemp-422), ABD0100.2.4 NO see
DO-178: 7.2.2: Establish the Software Product Baseline RMT,
PAS (ETemp-710), GO Workflow
Define the software product baseline for the software product in the SCI, System test baseline, TET
PB-EN-60, PB-EN-61, SW delivery desc. (ETemp-451) diagram for
considering instructions for (re-)building the executable object code Input for „SW delivery
PB-EN-62, PV-EN-63 Data: Complete software life the QA
according to SCMP. description“ of
cycle data
DO-178: 9.2 Compliance Substantiation Intermediate Standard
Quality Gate/Review: ---
Provide input to the Software Accomplishment Summary (SAS), PAS if
applicable, showing compliance of the software configuration
management process activities with the PSAC respective SCMP and
describe any differences.

END OF CERTIFICATION LIAISON PROCESS

SOFTWARE WORKFLOW
PRODUCTION TRANSFER PROCESS (Configuration Management)
Produce the Software Production Release document (SPRL) in
compliance with applicable Software Configuration Index (SCI), PAS if
applicable.
Produce the Data Integrity File (e.g CRC-file) in correlation to Executable
Specifications: --- Object Code and in compliance with Software Configuration Index (SCI). B, C, D, E
Plans: COTS-MP, SMDP SPRL,
Copy the Executable Object Code, Data Integrity File, PDI (if applicable)
Standards: --- For Quality Data Integrity File,
and SPRL document into the production transfer exchange folder
PB-EN-60, PB-EN-61, Templates: Gate Executable Object DOT,
according to SPRL document and inform the production transfer
PB-EN-62, PV-EN-63 SPRL (ETemp-514) application Code , CMT,
responsible.
Data: SCI, PAS, Executable PRL NO see SCMR for PRL CHT,
Report the activity results into the SCMR.
Object Code, ECN PB-EN-60 GO Workflow Baseline,
Quality Gate/Review: Check compliance of the Engineering Change Note (ECN) in Buddy, with diagram for Problem Reports
PRL (Etemp-090) the SPRL document the QA
This PRL review shall be performed for production transfer after CRC /
DR. It is also applicable for any intermediate software product in terms of
FDR and FFR that shall be officially produced and delivered via
production.
END OF PRODUCTION TRANSFER PROCESS
 Software Entwicklungs-Prozess-Abläufe PB-EN-32
Seite 13 von 36
Software Development-Process-Workflows Page 13 of 36
Ausgabe
10, 16 DEC 2021
Issue

3.4 Prozessflussdiagramm für die QA 3.4 Workflow diagram for the QA

No. Norms & Standards Input Data Process Steps Activities Output Data
SOFTWARE WORKFLOW
SOFTWARE PLANNING PROCESS (Quality Assurance)

Do178 Specifications: SoW, Spec. on DO-178: 4.2 Software Planning Process

4.0, 8.0, 12.0, A-1, A-9, System / Equipment Level PQR: Develop the Software Quality Assurance Plan (SQAP). Therefore
11.5, 11.19, Plans: SQAP, SDP, COTS-MP, SMDP define the means by which the software quality assurance process
Standards: --- objectives will be satisfied. SQAP
Assurance of DOT,
CRIs, IPs Templates: SQAP (ETemp-058), SQAR
Software Planning B, C, D, E CMT,
SQAR (ETemp-058), Do-178: 4.6, 8.2 Assurance of the Software Planning Process
Process CHT
ABD0100 Data: PSAC, SDP, SVP, SCMP, PQR: Assure that the software plans and standards comply with the PPR Report
SQAP, SECI, SRS, SDS, SCS, SwTS guidelines of system and airworthiness requirements according to SQAP.
PB-EN-60, PB-EN-61, Quality Gate/Review: PPR NO Report the activity results into the SQAR.
PB-EN-62 PPR (ETemp-083) ABD0100 2.4 GO

SOFTWARE WORKFLOW
SOFTWARE QUALITY ASSURANCE PROCESS

Do178
8.0, A-9 Specifications: --- Assurance of
DO-178: 8.2 Software Quality Assurance Process
11.19 Plans: SQAP, SDP, COTS-MP, SMDP Software
PQR: Assure that the software requirements process and it’s associated
Standards: --- Requirements Process
integral processes comply with the approved plans and standards by DOT,
CRIs, IPs Templates: SQAR (ETemp-058) and it’s Integral SQAR
independence according to the SQAP. Report the activity results into the B, C, D, E CMT,
Data: SRD, SCMR, SVCP, SVR, Processes SRR Report
SQAR. CHT
ABD0100 PVCP
Quality Gate/Review:
PB-EN-60, PB-EN-61, SRR (Etemp-084) SRR NO
PB-EN-62 ABD0100 2.4 GO

Do178
8.0, A-9 Specifications: ---
Plans: SQAP, SDP, COTS-MP, SMDP Assurance of DO-178: 8.2 Software Quality Assurance Process
11.19
Software Design PQR: Assure that the software design process and it’s associated integral
Standards: ---
Process and it’s processes comply with the approved plans and standards by DOT,
CRIs, IPs Templates: SQAR (ETemp-058) B, C*, D*, SQAR
Integral Processes independence according to the SQAP. Report the activity results into the CMT,
Data: SDD, SCMR, SVCP, SVR, E* SDR Report
SQAR. CHT
ABD0100 PVCP
Quality Gate/Review:
PB-EN-60, PB-EN-61, SDR (Etemp-085)
SDR NO
PB-EN-62
ABD0100 2.4 GO

Do178
8.0, A-9
Specifications: --- DO-178: 8.2 Software Quality Assurance Process
11.19
Plans: SQAP, SDP, COTS-MP, SMDP Assurance of PQR: Assure that the software coding process and it’s associated
Standards: --- Software Coding integral processes comply with the approved plans and standards by DOT,
CRIs, IPs B*, C*, D*,
Templates: SQAR (ETemp-058) Process and it’s independence according to the SQAP. Report the activity results into the SQAR CMT,
E*
Data: Source Code, SCMR, SVCP, Integral Processes SQAR. CHT
ABD0100
SVR
Quality Gate/Review: ---
PB-EN-60, PB-EN-61,
PB-EN-62

Do178 Assurance of
8.0, A-9 Specifications: --- Integration Process DO-178: 8.2 Software Quality Assurance Process
11.19 Plans: SQAP, SDP, COTS-MP, SMDP and it’s Integral PQR: Assure that the integration process and it’s associated integral
Standards: --- Processes processes comply with the approved plans and standards by DOT,
CRIs, IPs Templates: SQAR (ETemp-058) B*, C*, D*, SQAR
independence according to the SQAP. Report the activity results into the CMT,
Data: Executable Object Code, E* STRR Report
SQAR. CHT
ABD0100 SCMR, SVCP, SVR
Quality Gate/Review: STRR NO
PB-EN-60, PB-EN-61, STRR (Etemp-224) PB-EN-60 GO

PB-EN-62

END OF SOFTWARE QUALITY ASSURANCE PROCESS

SOFT WARE WORKFLOW
CERTIFICATION LIAISON PROCESS (Quality Assurance)
PB-EN-40 (4) DO-178: 8.3 Software Conformity Review
PQR: Assure that the software life cycle
PB-EN-40 (5) processes are completed, software life cycle Input for SAS,
data is completed and the executable object (Input for PAS)
SCR NO
for code is controlled and can be regenerated SQAR,
SW Level E B, C, D*
(DO-178/Ch. 8.3) GO according to SQAP. SCR Report
only FDR Report
DO-178: 9.2 Compliance Substantiation
FDR NO PQR: Provide evidence that the software life
Specifications: --- ABD010 0.2.4 GO cycle process satisfy the software plans and
Plans: PSAC, SDP, SQAP, COTS-MP, standards according to SQAP.
SMDP PB-EN-40 (4) Provide input to the Software Accomplishment
Do178
Standards: --- Summary (SAS), PDI Accomplishment
8.0, 8.3, 9.2, A-9, A-10,
Templates: SQAR (ETemp-058) PB-EN-40 (5) Summary (PAS) if applicable, showing Input for SAS,
11.19, 11.20
SAS (ETemp-422) compliance of the software quality assurance (Input for PAS)
PAS (ETemp-710) SCR SCR process activities with the PSAC respective SQAR, DOT,
CRIs, IPs NO NO B, C, D
(6) Data: (DO-178/Ch. 8.3) GO GO (DO-178/Ch. 8.3) SQAP and describe any differences. SCR Report CMT,
complete software life cycle data FFR Report CHT
ABD0100
Quality Gate/Review: CRC Report
SCR (ETemp-086),
PB-EN-60, PB-EN-61, FFR NO NO DR
FDR (ETemp-087) ABD010 0.2.4 GO GO ABD010 0.2.4 ABD0100.2.4: Schedule of DR for software
PB-EN-62
FFR (ETemp-088), level E
CRC (ETemp-089) PB-EN-40 (4) This review shall be held before a delivery of
DR (ETemp-091 for level E only) the equipment, at least before delivery of the
PB-EN-40 (5) first version that shall be applied in service.
The need to repeat this activity on other flyable Input for SAS,
SCR NO baselines will be considered depending on the (Input for PAS)
(DO-178/Ch. 8.3) GO status of completion of the activities and the E SQAR,
importance of the change. SCR Report
DR Report
CRC
NO GO
PQR: However, assure that sufficient
ABD010 0.2.4 verification and assurance activities have been
performed on any flyable baseline.

END OF CERTIFICATION LIAISON PROCESS

SOFT WARE WORKFLOW
PRODUCTION TRANSFER PROCESS (Quality Assurance)
Specifications: ---
Plans: COTS-MP, SMDP
PQR: Assure that the production transfer process comply with this
Standards: ---
PB-EN-32. Report the activity results into the SQAR.
Templates:
PB-EN-60, PB-EN-61, DOT,
SQAR (ETemp-058) SQAR
PB-EN-62 This PRL review shall be performed for production transfer after CRC / B, C, D, E CMT,
Data: SCI, PAS, SPRL, Data Integrity PRL Report
DR. It is also applicable for any intermediate software product in terms of CHT,
File, Executable Object Code, SCMR, PRL NO FDR and FFR that shall be officially produced and delivered via
ECN PB-EN-60 GO production.
Quality Gate/Review:
PRL (Etemp-090)
END OF PRODUCTION TRANSFER PROCESS
*Applicability by SW Level: These Quality Gates are not required according to ABD0100.2.4 in terms of purchaser / supplier monitoring. They shall be performed supplier internally, only. Tailoring is possible during Software Planning
Process respective Project Release Process according to PB-EN-60.
 Software Entwicklungs-Prozess-Abläufe PB-EN-32
Seite 14 von 36
Software Development-Process-Workflows Page 14 of 36
Ausgabe
10, 16 DEC 2021
Issue

3.5 Angewendete Werkzeuge 3.5 Utilized Tools

Tool Description Abbrev. Usage Actual Tool Distributor

Modelling Tool MOT - Requirements Analysis PTC Integrity PTC
- Software Design Modeler
- Requirement Management
Requirements RMT - Requirements Manage- DOORS IBM
Management Tool ment
Configuration CMT - Configuration Manage- ClearCase IBM
Management Tool ment Buddy Propriitär
Change Management CHT - Problem Reporting ClearQuest IBM
Tool - Quality Gate Management
Documentation Tool DOT - Documentation MS Word Microsoft
MS Visio Microsoft
MS Excel Microsoft
MS Power Point Microsoft
Acrobat Reader Acrobat
Docs Google
Sheets Google
Slides Google
Project Management PMT - Project Management MS Project Microsoft
Tool
(Integrated) Develop- DET - Editor <project specific> <project specific>
ment Environment Tool - Compiler <project specific> <project specific>
- Linker <project specific> <project specific>
- Debugger <project specific> <project specific>
- Builder <project specific> <project specific>
- Profiler <project specific> <project specific>
Code Analysis Tool CAT - Static Code Analyzer <project specific> <project specific>
- Dynamic Memory Sanity <project specific> <project specific>
Checker
- Stack Analyzer <project specific> <project specific>
Test Environment Tool TET - SWI Testing <project specific> <project specific>
- HSI Testing <project specific> <project specific>
- Low Level Testing <project specific> <project specific>
- Coverage Analyzer <project specific> <project specific>
 Software Entwicklungs-Prozess-Abläufe
Software Development-Process-Workflows
4 Prozessabläufe im Software Life Cycle
Der Software Life Cycle Prozess definiert und koordi-
niert den Planungs-Prozess und die Entwicklungs-
Prozesse. Dabei handelt es sich um iterative Prozes-
se, die inkrementell durchlaufen werden in Abhängig-
keit von Transitions-Kriterien und Ergebnissen der
Reviews. Diese Prozesse inklusive der Sub-Prozesse,
werden parallel durch den Integral-Prozess begleitet.
4.1 Software Planungs-Prozess
Die Zielsetzung des Software Planungs-Prozesses ist
die Definition der Vorgehensweise und der Hilfsmittel
zur Herstellung der zu entwickelnden Software.
Die zu entwickelnde Software erfüllt zudem die System
Requirements und bietet ein Vertrauensniveau, das
konform zu den Lufttüchtigkeits- und Vertragsanforde-
rungen ist.
Im Software Planungs-Prozess werden die für die
Entwicklungs- und integralen Prozesse benötigten
Pläne und Standards erstellt.
Rollen, Inputs/Outputs und Aktivitäten
Die grundsätzlichen Rollen und Zuständigkeiten sind in
Kapitel 2.3 definiert.
Die prozessschritt-spezifischen Inputs/Outputs und
Aktivitäten sind rollenorientiert im Prozessschritt (1)
der Prozessflussdiagramme aus Kapitel 3 definiert.
Transitions-Kriterien
Die Bedingungen, um in den Software Planungs-
Prozess einzutreten, sind die Verfügbarkeit der ge-
nehmigten und autorisierten Prozess-Inputs, wie im
Prozessflussdiagramm des Kapitels 3 aufgeführt.
Der Software Planungs-Prozess ist vollständig durch-
geführt, wenn seine Zielsetzungen erreicht und durch
das Software Planning Process Review (PPR) im Sta-
tus „grün“ oder „gelb“ gemäß QG Ampelsteuerung der
PB-EN-60 genehmigt worden sind.
Anmerkung: Die Software-Pläne und Standards sollen
vor dem Starten der Software Entwicklungs-Aktivitäten
erstellt werden. Einige Software Life Cycle Prozesse
können vor Beendigung des Software Planungs-
Prozesses anfangen, wenn die Pläne und Standards
für die spezifischen Prozessaufgaben genehmigt und
autorisiert sind.
PB-EN-32
Seite 15 von 36
Page 15 of 36
Ausgabe
10, 16 DEC 2021
Issue
4 Process flow of Software Life Cycle
The software life cycle process defines and coordi-
nates the planning process and the development pro-
cesses. It deals with iterative processes which run
incrementally depending upon the transition criteria
and the result of reviews. These processes inclusive
sub- processes, are accompanied parallel by the inte-
gral processes.
4.1 Software Planning Process
The objective of the software planning process is the
definition of the means and the tools used to develop
the software.
In addition the developed software will satisfy the sys-
tem requirements and provide the level of confidence
which is consistent with the airworthiness and contrac-
tual requirements.
In the software planning process the plans and
standards needed for the development and integral
processes are established.
Roles, Inputs/Outputs and Activities
The fundamental roles and competencies are defined
in chapter 2.3.
The process-step specific inputs/outputs and activities
are defined related to the roles in the process step (1)
of workflow diagrams in chapter 3.
Transition Criteria
The conditions to enter the software planning process
are the availability of approved and authorized process
inputs listed in workflow diagrams of chapter 3.
The software planning process is complete when its
objectives are satisfied and approved by the perfor-
mance of the software Planning Process Review
(PPR) in status “green” or “amber” according to QG
traffic light control of PB-EN-60.
Note: The software plans and standards shall be
developed prior to enter any software development
activities. Some software life cycle processes may
begin before completion of the software planning
process if the plans and standards for the specific
process activity are approved and authorized.
 Software Entwicklungs-Prozess-Abläufe
Software Development-Process-Workflows
4.2 Software Entwicklungs-Prozesse
Die Software Entwicklungs-Prozesse gliedern sich in
die nachfolgenden Sub-Prozesse:
 Software Requirements-Prozess
 Software Design-Prozess
 Software Coding-Prozess
 Integrations-Prozess
4.2.1 Software Requirements-Prozess
Die Zielsetzung des Software Requirements-
Prozesses ist die Entwicklung der Software High-Level
Requirements aus den softwarebezogenen System
Requirements der Spezifikation(en) auf System oder
Equipment Level und die Indikation der „derived“ Soft-
ware High-Level Requirements an den System Safety
Assessment Prozess.
Die Software High-Level Requirements sind innerhalb
der Software Requirements Data (SRD) zu dokumen-
tieren.
Anmerkung: Die Software „derived“ High-Level
Requirements sind Bestandteil der Software High-
Level Requirements. Durch die Überstellung des SRD
an den Kunden und/oder internem/externem
Fachbereich erfolgt die Indikation der „derived“ High-
Level Requirements an den System Safety
Assessment Prozess.
Die Entwicklung der Software High-Level Require-
ments hat gemäß der Software Requirements Stan-
dards (SRS) und des Software Development Plan
(SDP) zu erfolgen.
Die Traceability zwischen den Software High-Level
Requirements und System Requirements ist mittels
einer Traceability Matrix gemäß der Software Requi-
rements Standards (SRS) und des Software Develop-
ment Plan (SDP) darzustellen.
Falls Parameter Data Items (PDIs) verwendet werden,
sind diese im Parameter Requirements Data (PRD) zu
dokumentieren.
Rollen, Inputs/Outputs und Aktivitäten
Die grundsätzlichen Rollen und Zuständigkeiten sind in
Kapitel 2.3 definiert.
Die prozessschritt-spezifischen Inputs/Outputs und
Aktivitäten sind im Prozessschritt (2) des Prozess-
flussdiagramm für den Implementer in Kapitel
3.1definiert.
PB-EN-32
Seite 16 von 36
Page 16 of 36
Ausgabe
10, 16 DEC 2021
Issue
4.2 Software Development Processes
The software development processes are divided into
the following sub-processes:
 software requirements process
 software design process
 software coding process
 integration process
4.2.1 Software Requirements Process
The objective of the software requirements process is
to develop the software high-level requirements from
the system requirements of specification(s) on system
or equipment level allocated to software and to indicate
the derived software high-level requirements to the
system safety assessment process.
The software high-level requirements shall be docu-
mented within the Software Requirements Data (SRD).
Note: Software “derived” high-level requirements are
included in the software high-level requirements. The
indication of the “derived” high-level requirements to
the system safety assessment process is carried out
by SRD transfer to the customer and/or
internal/external department.
The software high-level requirements shall be
developed in accordance with the Software
Requirements Standards (SRS) and the Software
Development Plan (SDP).
The traceability between software high-level require-
ments and system requirements shall be provided into
a traceability matrix in accordance with the Software
Requirements Standards (SRS) and the Software De-
velopment Plan (SDP).
If Parameter Data Items (PDIs) are used, they shall be
documented within a separate Parameter Require-
ments Data (PRD) document.
Roles, Inputs/Outputs and Activities
The fundamental roles and competencies are defined
in chapter 2.3.
The process-step specific inputs/outputs and activities
are defined in the process step (2) of workflow diagram
for the implementer in chapter 3.1.
 Software Entwicklungs-Prozess-Abläufe
Software Development-Process-Workflows
Transitions-Kriterien
Die Bedingungen, um in den Software Requirements-
Prozess einzutreten, sind die Verfügbarkeit der ge-
nehmigten und autorisierten Prozess-Inputs, wie im
Prozessflussdiagramm des Kapitels 3.1 aufgeführt.
Der Software Requirements-Prozess ist vollständig
durchgeführt, wenn seine Zielsetzungen und die Ziel-
setzungen der zugehörigen integralen Prozesse erfüllt
und durch das Software Requirements Review (SRR)
im Status „grün“ oder „gelb“ gemäß QG Ampelsteue-
rung der PB-EN-60 genehmigt worden sind.
4.2.2 Software Design-Prozess
Die Zielsetzung des Software Design-Prozesses ist die
Entwicklung der Software Low-Level Requirements
und der Software Architektur aus den Software High-
Level Requirements des SRD und die Indikation der
„derived“ Software Low-Level Requirements an den
System Safety Assessment Prozess.
Die Software Low-Level Requirements und die Soft-
ware Architektur sind innerhalb der Software Design
Description (SDD) zu dokumentieren.
Anmerkung: Die Software „derived“ Low-Level Re-
quirements sind Bestandteil der Software Low-Level
Requirements. Durch die Überstellung des SDD an
den Kunden und/oder internem/externem Fachbereich
erfolgt die Indikation der „derived“ Low-Level Require-
ments an den System Safety Assessment Prozess.
Die Entwicklung der Software Low-Level Requirements
und der Software Architektur hat gemäß der Software
Design Standards (SDS) und des Software Develop-
ment Plan (SDP) zu erfolgen.
Die Traceability zwischen den Software Low-Level
Requirements und den Software High-Level Require-
ments ist mittels einer Traceability Matrix gemäß der
Software Design Standards (SDS) und des Software
Development Plan (SDP) darzustellen.
Rollen, Inputs/Outputs und Aktivitäten
Die grundsätzlichen Rollen und Zuständigkeiten sind in
Kapitel 2.3 definiert.
Die prozessschritt-spezifischen Inputs/Outputs und
Aktivitäten sind im Prozessschritt (3) des Prozess-
flussdiagramm für den Implementer in Kapitel 3.1 defi-
niert.
PB-EN-32
Seite 17 von 36
Page 17 of 36
Ausgabe
10, 16 DEC 2021
Issue
Transition Criteria
The conditions to enter the software requirements
process are the availability of approved and authorized
process inputs listed in workflow diagram of
chapter 3.1.
The software requirements process is complete when
its objectives and the objectives of the integral pro-
cesses associated with it are satisfied approved by the
performance of the Software Requirements Review
(SRR) in status “green” or “amber” according to QG
traffic light control of PB-EN-60.
4.2.2 Software Design Process
The objective of the software design process is to de-
velop the software low-level requirements and software
architecture from the software high-level requirements
of SRD and to indicate the derived software low-level
requirements to the system safety assessment pro-
cess.
The software low-level requirements and software
architecture shall be documented within the Software
Design Description (SDD).
Note: Software “derived” low-level requirements are
included in the software low-level requirements. The
indication of the “derived” low-level requirements to the
system safety assessment process is carried out by
SDD transfer to the customer and/or internal/external
department.
The software low-level requirements and software
architecture shall be developed in accordance with the
Software Design Standards (SDS) and the Software
Development Plan (SDP).
The traceability between software low-level require-
ments and software high-level requirements shall be
provided into a traceability matrix in accordance with
the Software Design Standards (SDS) and the Soft-
ware Development Plan (SDP).
Roles, Inputs/Outputs and Activities
The fundamental roles and competencies are defined
in chapter 2.3.
The process-step specific inputs/outputs and activities
are defined in the process step (3) of workflow diagram
for the implementer in chapter 3.1.
 Software Entwicklungs-Prozess-Abläufe
Software Development-Process-Workflows
Transitions-Kriterien
Die Bedingungen, um in den Software Design-Prozess
einzutreten, sind die Verfügbarkeit der genehmigten
und autorisierten Prozess-Inputs, wie im Prozessfluss-
diagramm des Kapitels 3.1 aufgeführt.
Der Software Design-Prozess ist vollständig durchge-
führt, wenn seine Zielsetzungen und die Zielsetzun-
gen der zugehörigen integralen Prozesse erfüllt und
durch das Software Design Review (SDR) im Status
„grün“ oder „gelb“ gemäß QG Ampelsteuerung der
PB-EN-60 genehmigt worden sind.
4.2.3 Software Coding-Prozess
Die Zielsetzung des Software Coding-Prozesses ist die
Entwicklung des Source Code, der die Software Low-
Level Requirements und die Software Architektur des
SDD implementiert.
Die Entwicklung des Source Code hat gemäß der
Software Code Standards (SCS) und des Software
Development Plan (SDP) zu erfolgen.
Die Traceability zwischen dem Source Code und den
Software Low-Level Requirements ist mittels einer
Traceability Matrix gemäß der Software Code Stan-
dards (SCS) und des Software Development Plan
(SDP) darzustellen.
Rollen, Inputs/Outputs und Aktivitäten
Die grundsätzlichen Rollen und Zuständigkeiten sind in
Kapitel 2.3 definiert.
Die prozessschritt-spezifischen Inputs/Outputs und
Aktivitäten sind im Prozessschritt (4) des Prozess-
flussdiagramm für den Implementer in Kapitel 3.1 defi-
niert.
Transitions-Kriterien
Generell sind die Bedingungen, um in den Software
Coding-Prozess einzutreten, die Verfügbarkeit der
genehmigten und autorisierten Prozess-Inputs, wie im
Prozessflussdiagramm des Kapitels 3.1 aufgeführt,
allerdings mit folgender Einschränkung.
Die Software Design Description (SDD) muss nicht
komplett vollendet sein, um den Software Coding-
Process beginnen zu können. Die Software Low-Level
Requirements und die Software Architektur müssen als
Eingang für den jeweilig zu erstellenden Source Code
Abschnitt, entwickelt und verifiziert sein.
Der Software Coding-Prozess ist vollständig durchge-
führt, wenn seine Zielsetzungen und die Zielsetzungen
der zugehörigen integralen Prozesse erfüllt sind.
PB-EN-32
Seite 18 von 36
Page 18 of 36
Ausgabe
10, 16 DEC 2021
Issue
Transition Criteria
The conditions to enter the software design process
are the availability of approved and authorized process
inputs listed in workflow diagram of chapter 3.1.
The software design process is complete when its
objectives and the objectives of the integral processes
associated with it are satisfied approved by the per-
formance of the Software Design Review (SDR) in
status “green” or “amber” according to QG traffic light
control of PB-EN-60.
4.2.3 Software Coding Process
The objective of the software coding process is to de-
velop the source code that implements the software
low-level requirements and software architecture of
SDD.
The source code shall be developed in accordance
with the Software Code Standards (SCS) and the
Software Development Plan (SDP).
The traceability between source code and software
low-level requirements shall be provided into a tracea-
bility matrix in accordance with the Software Code
Standards (SCS) and the Software Development Plan
(SDP).
Roles, Inputs/Outputs and Activities
The fundamental roles and competencies are defined
in chapter 2.3.
The process-step specific inputs/outputs and activities
are defined in the process step (4) of workflow diagram
for the implementer in chapter 3.1.
Transition Criteria
Normally, the conditions to enter the software coding
process are the availability of approved and authorized
process inputs listed in workflow diagram of chapter
3.1, considering the following restriction.
The Software Design Description (SDD) does not need
to be finished completely in order to enter the software
coding process. The software low-level requirements
and software architecture as input for the respective
source code section associated with it must be devel-
oped and verified.
The software coding process is complete when its
objectives and the objectives of the integral processes
associated with it are satisfied.
 Software Entwicklungs-Prozess-Abläufe
Software Development-Process-Workflows
4.2.4 Integrations-Prozess
Die Zielsetzung des Integrations-Prozesses ist die
Generierung des Executable Object Codes, der Para-
meter Data Item Dateien und den Linking und Loading
Daten, sowie das Laden des Executable Object Codes
und der Parameter Data Item Dateien in die Zielhard-
ware zu HW/SW Integrationszwecken.
Die Generierung des Executable Object Code und der
Parameter Data Item Files hat gemäß der Software
Code Standards (SCS) respektive der Software
Requirements Standards (SRS) und des Software
Development Plan (SDP) zu erfolgen.
Rollen, Inputs/Outputs und Aktivitäten
Die grundsätzlichen Rollen und Zuständigkeiten sind in
Kapitel 2.3 definiert.
Die prozessschritt-spezifischen Inputs/Outputs und
Aktivitäten sind im Prozessschritt (5) des Prozess-
flussdiagramm für den Implementer in Kapitel 3.1 defi-
niert.
Transitions-Kriterien
Die Bedingungen, um in den Integrations-Prozess
einzutreten, sind die Verfügbarkeit der genehmigten
und autorisierten Prozess-Inputs wie im Prozessfluss
des Kapitels 3.1 aufgeführt.
Der Integrations-Prozess ist vollständig durchgeführt,
wenn seine Zielsetzungen und die Zielsetzungen der
zugehörigen integralen Prozesse erfüllt und durch das
Software Test Readiness Review (STRR) im Status
„grün“ oder „gelb“ gemäß QG Ampelsteuerung der
PB-EN-60 genehmigt worden sind.
4.3 Integrale Prozesse
Folgende integrale Prozesse sind definiert:
 Software Verifikations-Prozess
 Software Configuration-Management-Prozess
 Software Quality-Assurance-Prozess
 Certification-Liaison-Prozess
4.3.1 Software Verifikations-Prozess
Die Zielsetzung des Software Verifikations-Prozesses
ist die Detektion und das Berichten von Fehlern die
potentiell während der Software Entwicklungs-
Prozesse und des Software Verifikation-Prozess selbst
auftreten können.
Der Software Verifikations-Prozess beinhaltet dabei
die folgenden Prozessschritte:
PB-EN-32
Seite 19 von 36
Page 19 of 36
Ausgabe
10, 16 DEC 2021
Issue
4.2.4 Integration Process
The objective of the integration process is to generate
the executable object code, the parameter data item
files and linking and loading data respective to load the
executable object code and parameter data item files
into the target hardware for HW/SW integration pur-
pose.
The executable object code and parameter data item
files shall be generated in accordance with the Soft-
ware Code Standards (SCS) respective Software Re-
quirements Standards (SRS) and the Software Devel-
opment Plan (SDP).
Roles, Inputs/Outputs and Activities
The fundamental roles and competencies are defined
in chapter 2.3.
The process-step specific inputs/outputs and activities
are defined in the process step (5) of workflow diagram
for the implementer in chapter 3.1.
Transition Criteria
The conditions to enter the integration process are the
availability of approved and authorized process inputs
listed in workflow diagram of chapter 3.1.
The integration process is complete when its objec-
tives and the objectives of the integral processes as-
sociated with it are satisfied approved by the perfor-
mance of the Software Test Readiness Review
(STRR) in status “green” or “amber” according to QG
traffic light control of PB-EN-60.
4.3 Integral Processes
Following integral processes are defined:
 software verification process
 software configuration management process
 software quality assurance process
 certification liaison process
4.3.1 Software Verification Process
The objective of the software verification process is to
detect and report errors that may have been
introduced during both the software development
processes and the software verification process.
The software verification process include the following
process step:
 Software Entwicklungs-Prozess-Abläufe
Software Development-Process-Workflows
 Verifikation der Outputs des Software Require-
ments-Prozess
 Verifikation der Outputs des Software Design-
Prozess
 Verifikation der Outputs des Software Coding-
Prozess
 Verifikation der Outputs des Integrations-Prozess
 Testen der Outputs des Integrations-Prozess
 Verifikation der Verifikations-Prozess Ergebnisse
als integrale Prozessschritte
Die Prozessschritte sind in den folgenden Kapiteln
detailliert.
Rollen, Inputs/Outputs und Aktivitäten
Die grundsätzlichen Rollen und Zuständigkeiten sind in
Kapitel 2.3 definiert.
Die prozessschritt-spezifischen Inputs/Outputs und
Aktivitäten sind in den Prozessschritten (2-6) des Pro-
zessflussdiagramm für den Verifier in Kapitel 0 defi-
niert.
Transitions-Kriterien
Die Bedingungen, um in den Software Verifikations-
Prozess einzutreten, sind die Verfügbarkeit der Pro-
zess-Inputs, wie im Prozessflussdiagramm des Kapi-
tels 3.2 aufgeführt.
Der Software Verifikations-Prozess ist vollständig
durchgeführt, wenn seine Zielsetzungen und die Ziel-
setzungen der zugehörigen integralen Prozesse erfüllt
und durch die Reviews, abgebildet im Prozessflussdi-
agramm des Kapitels 3.2, im Status „grün“ oder „gelb“
gemäß QG Ampelsteuerung der PB-EN-60 genehmigt
worden sind.
PB-EN-32
Seite 20 von 36
Page 20 of 36
Ausgabe
10, 16 DEC 2021
Issue
 Verification of outputs of software requirements
process
 Verification of outputs of software design process
 Verification of outputs of software coding process
 Verification of outputs of integration process
 Testing of outputs of integration process
 Verification of verification process results as integral
process steps
The process steps are detailed in the following chap-
ters.
Roles, Inputs/Outputs and Activities
The fundamental roles and competencies are defined
in chapter 2.3.
The process-step specific inputs/outputs and activities
are defined in the process steps (2-6) of workflow dia-
gram for the verifier in chapter 0.
Transition Criteria
The conditions to enter the software verification pro-
cess are the availability of process inputs listed in
workflow diagram of chapter 3.2.
The software verification process is complete when its
objectives and the objectives of the integral processes
associated with it are satisfied and approved by the
performance of the associated reviews, as shown in
workflow diagram of chapter 3.2, in status “green” or
“amber” according to QG traffic light control of
PB-EN-60.
 Software Entwicklungs-Prozess-Abläufe
Software Development-Process-Workflows
4.3.1.1 Verifikation der Outputs des Software Re-
quirements-Prozess
Die Zielsetzung der Verifikation des Outputs des Soft-
ware Requirements-Prozess ist zu überprüfen, dass
die softwarebezogenen System Requirements in Soft-
ware High-Level Requirements entwickelt wurden und
diese die System Requirements auch erfüllen respekti-
ve die Übereinstimmung mit den Software Require-
ment Standards (SRS) und des Software Development
Plan (SDP) sicher zu stellen.
Die Verifikation ist mittels Review und Analyse Aktivitä-
ten gemäß des Software Verification Plan (SVP; inklu-
sive Checkliste) respektive der Software Verification
Cases and Procedures (SVCP) durchzuführen. Vorher
sind die im SVP beschriebenen Review und Analyse
Methoden hinsichtlich des Geltungsbereiches und der
Tiefe im SVCP zu erweitern. Die Review und Analyse
Ergebnisse sind in den Software Verification Results
(SVR) zu dokumentieren.
Wenn Parameter Data Items (PDIs) verwendet werden
müssen die Parameter Requirement Data (PRD) ent-
sprechend des Software Verification Plan (SVP) res-
pektive den Parameter Verification Cases and Proce-
dures (PVCP) verifiziert werden.
Während dieses Prozessschrittes (2) sind die Software
High-Level Requirements basierten Testfälle und Pro-
zeduren gemäß des SVP zu entwickeln und im SVCP
zu dokumentieren.
Die Verifikation dieser Software High-Level Require-
ments basierten Testfälle und Prozeduren, sowie die
dazugehörige Requirements basierte Test Coverage
Analyse erfolgt gemäß Kapitel 4.3.1.6 Verifikation der
Verifikations-Prozess Ergebnisse.
PB-EN-32
Seite 21 von 36
Page 21 of 36
Ausgabe
10, 16 DEC 2021
Issue
4.3.1.1 Verification of outputs of software require-
ments process
The objective of the verification of outputs of software
requirements process is to verify that the system re-
quirements allocated to software have been developed
into software high-level requirements that satisfy those
system requirements respective to verify the compli-
ance with Software Requirement Standards (SRS) and
Software Development Plan (SDP).
The verification shall be done via review and analysis
activities according to Software Verification Plan (SVP;
inclusive checklist) respective Software Verification
Cases and Procedures (SVCP). Prior to that the SVCP
shall be developed providing details, supplementary to
the description in the SVP, which describes the scope
and depth of the review and analysis methods to be
used. The review and analysis result shall be docu-
mented into the Software Verification Results (SVR).
If Parameter Data Items (PDIs) are used, the Parame-
ter Requirement Data (PRD) shall be verified accord-
ing to Software Verification Plan (SVP) respective the
Parameter Verification Cases and Procedures (PVCP).
During this process step (2) the software high-level
requirements based test cases / procedures shall be
developed according to the SVP and documented with-
in the SVCP.
The verification of these software high-level require-
ments based test cases and procedures as well as the
associated requirements-based test coverage analysis
shall be performed according to chapter 4.3.1.6 Verifi-
cation of verification process results.
 Software Entwicklungs-Prozess-Abläufe
Software Development-Process-Workflows
4.3.1.2 Verifikation der Outputs des Software De-
sign-Prozess
Die Zielsetzung der Verifikation des Outputs des Soft-
ware Design-Prozess ist zu überprüfen, dass die Soft-
ware High-Level Requirements in die Software Archi-
tektur und Software Low-Level Requirements entwi-
ckelt wurden und diese die Software High-Level Requi-
rements auch erfüllen respektive die Übereinstimmung
mit den Software Design Standards (SDS) und des
Software Development Plan (SDP) sicher zu stellen.
Die Verifikation ist mittels Review und Analyse Aktivitä-
ten gemäß des Software Verification Plan (SVP; inklu-
sive Checkliste) respektive der Software Verification
Cases and Procedures (SVCP) durchzuführen. Vorher
sind die im SVP beschriebenen Review und Analyse
Methoden hinsichtlich des Geltungsbereiches und der
Tiefe im SVCP zu erweitern. Die Review und Analyse
Ergebnisse sind in den Software Verification Results
(SVR) zu dokumentieren.
Während dieses Prozessschrittes (3) sind die Software
Low-Level Requirements basierten Testfälle und Pro-
zeduren gemäß des SVP zu entwickeln und im SVCP
zu dokumentieren.
Die Verifikation dieser Software Low-Level Require-
ments basierten Testfälle und Prozeduren, sowie die
dazugehörige Requirements basierte Test Coverage
Analyse erfolgt gemäß Kapitel 4.3.1.6 Verifikation der
Verifikations-Prozess Ergebnisse.
4.3.1.3 Verifikation der Outputs des Software
Coding-Prozess
Die Zielsetzung der Verifikation des Outputs des Soft-
ware Coding-Prozess ist zu überprüfen, dass die Soft-
ware Architektur und Software Low-Level Require-
ments in den Source Code entwickelt wurden und die-
ser die Software Architektur und Software Low-Level
Requirements auch erfüllt respektive die Übereinstim-
mung mit den Software Code Standards (SCS) und
des Software Development Plan (SDP) sicher zu stel-
len.
Die Verifikation ist mittels Review und Analyse Aktivitä-
ten gemäß des Software Verification Plan (SVP; inklu-
sive Checkliste) respektive der Software Verification
Cases and Procedures (SVCP) durchzuführen. Vorher
sind die im SVP beschriebenen Review und Analyse
Methoden hinsichtlich des Geltungsbereiches und der
Tiefe im SVCP zu erweitern. Die Review und Analyse
Ergebnisse sind in den Software Verification Results
(SVR) zu dokumentieren.
PB-EN-32
Seite 22 von 36
Page 22 of 36
Ausgabe
10, 16 DEC 2021
Issue
4.3.1.2 Verification of outputs of software design
process
The objective of the verification of outputs of software
design process is to verify that the software high-level
requirements have been developed into software archi-
tecture and software low-level requirements that satisfy
the software high-level requirements respective to
verify the compliance with Software Design Standards
(SDS) and Software Development Plan (SDP).
The verification shall be done via review and analysis
activities according to Software Verification Plan (SVP;
inclusive checklist) respective Software Verification
Cases and Procedures (SVCP). Prior to that the
SVCP shall be developed providing details,
supplementary to the description in the SVP, which
describes the scope and depth of the review and
analysis methods to be used. The review and analysis
result shall be documented into the Software
Verification Results (SVR).
During this process step (3) the software low-level
requirements based test cases / procedures shall be
developed according to the SVP and documented into
the SVCP.
The verification of these software low-level require-
ments based test cases and procedures as well as the
associated requirements-based test coverage analysis
shall be performed according to chapter 4.3.1.6 Verifi-
cation of verification process results.
4.3.1.3 Verification of outputs of software coding
process
The objective of the verification of the outputs of soft-
ware coding process is to verify that the software archi-
tecture and software low-level requirements have been
developed into source code that satisfies the software
architecture and software low-level requirements re-
spective to verify the compliance with Software Code
Standards (SCS) and Software Development Plan
(SDP).
The verification shall be done via review and analysis
activities according to Software Verification Plan (SVP;
inclusive checklist) respective Software Verification
Cases and Procedures (SVCP). Prior to that the
SVCP shall be developed providing details,
supplementary to the description in the SVP, which
describes the scope and depth of the review and
analysis methods to be used. The review and analysis
result shall be documented into the Software
Verification Results (SVR).
 Software Entwicklungs-Prozess-Abläufe
Software Development-Process-Workflows
4.3.1.4 Verifikation der Outputs des Integrations-
Prozess
Die Zielsetzung der Verifikation des Outputs des Integ-
rations-Prozess ist die Generierung des Executable
Object Codes und der Parameter Data Item Files zu
überprüfen sowie die Übereinstimmung mit den Soft-
ware Code Standards (SCS) respektive Software Re-
quirements Standards (SRS) und des Software Deve-
lopment Plan (SDP) sicher zu stellen.
Die Verifikation ist mittels Review und Analyse Aktivitä-
ten gemäß des Software Verification Plan (SVP; inklu-
sive Checkliste) respektive der Software Verification
Cases and Procedures (SVCP) / PDI Verification
Cases and Procedures (PVCP) durchzuführen. Vorher
sind die im SVP beschriebenen Review und Analyse
Methoden hinsichtlich des Geltungsbereiches und der
Tiefe im SVCP/PVCP zu erweitern. Die Review und
Analyse Ergebnisse sind in den Software Verification
Results (SVR, für PDIs im PAS) zu dokumentieren.
4.3.1.5 Testen der Outputs des Integrations-
Prozess
Die Zielsetzung des Testens des Outputs des Integra-
tions-Prozess ist die Demonstration, dass die Software
ihre Requirements erfüllt und mit hohem Maß sicher zu
stellen, dass Fehler mit nicht akzeptablen Auswirkun-
gen entfernt worden sind.
Die Verifikation ist mittels Hardware/Software Integra-
tions-Tests, Software Integrations-Tests und Low-
Level-Tests gemäß des Software Verification Plan
(SVP) respektive der Software Verification Cases and
Procedures (SVCP) / PDI Verification Cases and Pro-
cedures (PVCP), welches die vordefinierten Testfälle
und Prozeduren beinhaltet, durchzuführen. Die Test-
Ergebnisse sind in den Software Verification Results
(SVR, für PDIs im PAS) zu dokumentieren.
Die Verifikation der Testergebnisse, sowie die dazuge-
hörige Structural Coverage Analyse erfolgt gemäß
Kapitel 4.3.1.6 Verifikation der Verifikations-Prozess
Ergebnisse.
Anmerkung:
Gemäß 21.A.33 (b) (c) und AMC 21.A.33 muss vor
Durchführung eines jeden Compliance Test festgestellt
werden, dass der Prüfling und die Prüfumgebung für
eine bestimmte Prüfung geeignet sind. Die Konformi-
tätsprüfung des Prüflings & Prüfumgebung wird durch-
geführt und das Ergebnis als Konformitätserklärung
dokumentiert innerhalb des Berichts ‚Konformitätser-
klärung für Prüfling / Umgebung (RCS)‘.
PB-EN-32
Seite 23 von 36
Page 23 of 36
Ausgabe
10, 16 DEC 2021
Issue
4.3.1.4 Verification of outputs of integration pro-
cess
The objective of the verification of outputs of
integration process is to verify the generation of the
executable object code and parameter data item files
as well as to verify the compliance with Software Code
Standards (SCS) respective Software Requirements
Standards (SRS) and Software Development Plan
(SDP).
The verification shall be done via review and analysis
activities according to Software Verification Plan (SVP;
inclusive checklist) respective Software Verification
Cases and Procedures (SVCP) / PDI Verification
Cases and Procedures (PVCP). Prior to that the
SVCP/PVCP shall be developed providing details,
supplementary to the description in the SVP, which
describes the scope and depth of the review and
analysis methods to be used. The review and analysis
result shall be documented into the Software
Verification Results (SVR, for PDIs in PAS).
4.3.1.5 Testing of outputs of integration process
The objective of the testing of outputs of integration
process is to demonstrate that the software satisfies its
requirements and to demonstrate with a high degree of
confidence that errors which could lead to unaccepta-
ble failure conditions have been removed.
The verification shall be done via hardware/software
integration testing, software integration testing and
low-level testing according to Software Verification
Plan (SVP) respective Software Verification Cases and
Procedures (SVCP) / PDI Verification Cases and Pro-
cedures (PVCP); including the predefined test cases /
procedures. The testing results shall be documented
into the Software Verification Results (SVR, for PDIs in
PAS).
The verification of the test results as well as the asso-
ciated structural coverage analysis shall be performed
according to chapter 4.3.1.6 Verification of verification
process results.
Note:
As per 21.A.33(b)(c) and AMC 21.A.33, before any
compliance test is undertaken it shall be determined as
a precondition that the test specimen and the test envi-
ronment are adequate for a particular test. The con-
formity inspection of the test specimen & test en-
vironment is performed and the result as a statement
of conformity documented within the ‘Report Con-
formity Statement for Test Specimen / Environment
(RCS)’.
 Software Entwicklungs-Prozess-Abläufe
Software Development-Process-Workflows
4.3.1.6 Verifikation der Verifikations-Prozess Er-
gebnisse
Die Zielsetzung der Verifikation der Verifikations-
Prozess Ergebnisse ist es sicherzustellen, dass die
Software Tests fehlerfrei und komplett entwickelt res-
pektive durchgeführt worden sind; inklusive der Bestä-
tigung der Test Coverage Analyse.
Die Verifikation ist mittels Review und Analyse Aktivitä-
ten gemäß des Software Verification Plan (SVP; inklu-
sive Checkliste) respektive der Software Verification
Cases and Procedures (SVCP) durchzuführen. Vorher
sind die im SVP beschriebenen Review und Analyse
Methoden hinsichtlich des Geltungsbereiches und der
Tiefe im SVCP zu erweitern. Die Review und Analyse
Ergebnisse sind in den Software Verification Results
(SVR) zu dokumentieren.
4.3.2 Software Configuration-Management-Prozess
Der Zielsetzung des SCM Prozesses ist die Konfigura-
tionskontrolle der Software Life Cycle Daten über den
kompletten Software Life Cycle; dieses beinhaltet:
 Configuration Identification
 Baseline und Traceability
 Problem Reporting, Tracking und Corrective Action
 Change Control
 Change Review
 Configuration Status Accounting
 Archive, Retrieval and Release
 Software Load Control
 Software Life Cycle Environment Control
Die SCM Aktivitäten sind gemäß des Software Confi-
guration Management Plan (SCMP) durchzuführen.
Die Ergebnisse der SCM Aktivitäten sowie die Einhal-
tung der SCM Aktivitäten gemäß des SCMP sind im
Software Configuration Management Record (SCMR)
zu dokumentieren.
Rollen, Inputs/Outputs und Aktivitäten
Die grundsätzlichen Rollen und Zuständigkeiten sind in
Kapitel 2.3 definiert.
Die prozessschritt-spezifischen Inputs/Outputs und
Aktivitäten sind in den Prozessschritten (2-6) des Pro-
zessflussdiagramm für den Configuration Manager
(CM) in Kapitel 3.3 definiert.
PB-EN-32
Seite 24 von 36
Page 24 of 36
Ausgabe
10, 16 DEC 2021
Issue
4.3.1.6 Verification of verification process results
The objective of the verification of verification process
results is to ensure that the software testing was de-
veloped and performed accurately and completely;
including the confirmation of the test coverage analy-
sis.
The verification shall be done via review and analysis
activities according to Software Verification Plan (SVP;
inclusive checklist) respective Software Verification
Cases and Procedures (SVCP). Prior to that the
SVCP shall be developed providing details, supple-
mentary to the description in the SVP, which describes
the scope and depth of the review and analysis meth-
ods to be used. The review and analysis result shall be
documented into the Software Verification Results
(SVR).
4.3.2 Software Configuration Management Process
The objectives of the SCM process is the configuration
control of the software life cycle data throughout the
software life cycle; including:
 configuration identification
 baseline and traceability
 problem reporting, tracking and corrective action
 change control
 change review
 configuration status accounting
 archive, retrieval and release
 software load control
 software life cycle environment control
The SCM activities shall be performed according to
Software Configuration Management Plan (SCMP).
The SCM activity results and the compliance of the
SCM activities to the SCMP shall be documented into
the Software Configuration Management Record
(SCMR).
Roles, Inputs/Outputs and Activities
The fundamental roles and competencies are defined
in chapter 2.3.
The process-step specific inputs/outputs and activities
are defined in the process steps (2-6) of workflow
diagram for the Configuration Manager (CM) in chap-
ter 3.3.
 Software Entwicklungs-Prozess-Abläufe
Software Development-Process-Workflows
Transitions-Kriterien
Die Bedingungen, um den Software Configuration-
Management-Prozess einzutreten, sind die Verfügbar-
keit der genehmigten und autorisierten Prozess-Inputs,
wie im Prozessflussdiagramm des Kapitels 3.3 aufge-
führt.
Der Software Configuration-Management-Prozess ist
vollständig durchgeführt, wenn seine Zielsetzungen
erfüllt und durch die Reviews, abgebildet im Prozess-
flussdiagramm des Kapitels 3.3, im Status „grün“ oder
„gelb“ gemäß QG Ampelsteuerung der PB-EN-60 ge-
nehmigt worden sind.
4.3.3 Software Quality-Assurance-Prozess
Die Zielsetzung des Software Quality-Assurance-
Prozesses ist es die Software Life Cycle Prozesse und
deren Outputs zu bewerten, um die Gewährleistung zu
erhalten, dass die Zielsetzungen erfüllt sind, dass die
Abweichungen ermittelt, ausgewertet, verfolgt und
gelöst werden. Des Weiteren Vertrauen zu erzeugen,
dass die Software Life Cycle Prozesse Software Life
Cycle Daten (inklusive des Software Produktes) pro-
duzieren, welche ihren Anforderungen genügen, indem
sichergestellt wird, dass diese Prozesse mit den ge-
nehmigten und autorisierten Software Plänen und
Standards übereinstimmen.
Die Software Quality Assurance Aktivitäten sind ge-
mäß des Software Quality Assurance Plan (SQAP)
durchzuführen. Die Ergebnisse der SQA Aktivitäten
sowie die Einhaltung der SQA Aktivitäten gemäß des
SQAP sind im Software Quality Assurance Record
(SQAR) zu dokumentieren.
Rollen, Inputs/Outputs und Aktivitäten
Die grundsätzlichen Rollen und Zuständigkeiten sind in
Kapitel 2.3 definiert.
Die prozessschritt-spezifischen Inputs/Outputs und
Aktivitäten sind in den Prozessschritten (2-6) des Pro-
zessflussdiagramm für die Quality Assurance (QA) in
Kapitel 3.4 definiert.
Transitions-Kriterien
Die Bedingungen, um in den Software Quality-
Assurance-Prozess einzutreten, sind die Verfügbarkeit
der Prozess-Inputs, wie im Prozessflussdiagramm des
Kapitels 3.4 aufgeführt.
Der Software Quality-Assurance-Prozess ist vollstän-
dig durchgeführt, wenn seine Zielsetzungen erfüllt und
durch die Reviews, abgebildet im Prozessflussdia-
gramm des Kapitels 3.4, im Status „grün“ oder „gelb“
gemäß QG Ampelsteuerung der PB-EN-60 genehmigt
worden sind.
PB-EN-32
Seite 25 von 36
Page 25 of 36
Ausgabe
10, 16 DEC 2021
Issue
Transition Criteria
The conditions to enter the software configuration
management process are the availability of approved
and authorized process inputs listed in workflow dia-
gram of chapter 3.3.
The software configuration management process is
complete when its objectives are satisfied approved by
the performance of the associated reviews, as shown
in workflow of chapter 3.3, in status “green” or “amber”
according to QG traffic light control of PB-EN-60.
4.3.3 Software Quality Assurance Process
The objective of the software quality assurance pro-
cess is to assess the software life cycle processes and
their outputs to obtain assurance that the objectives
are satisfied, that deficiencies are detected, evaluated,
tracked and resolved. Further to provide confidence
that the software life cycle processes produce software
life cycle data (inclusive software product) that con-
forms to its requirements by assuring that these pro-
cesses are performed in compliance with the approved
and authorized software plans and standards.
The software quality assurance activities shall be per-
formed according to the Software Quality Assurance
Plan (SQAP). The SQA activity results and the compli-
ance of the SQA activities to the SQAP shall be docu-
mented into the Software Quality Assurance Record
(SQAR).
Roles, Inputs/Outputs and Activities
The fundamental roles and competencies are defined
in chapter 2.3.
The process-step specific inputs/outputs and activities
are defined in the process steps (2-6) of workflow dia-
gram for the Quality Assurance (QA) in chapter 3.4.
Transition Criteria
The conditions to enter the software quality assurance
process are the availability of process inputs listed in
workflow diagram of chapter 3.4.
The software quality assurance process is complete
when its objectives are satisfied approved by the per-
formance of the associated reviews, as shown in work-
flow diagram of chapter 3.4, in status “green” or “am-
ber” according to QG traffic light control of PB-EN-60.
 Software Entwicklungs-Prozess-Abläufe
Software Development-Process-Workflows
4.3.3.1 Quality-Gates Tätigkeiten
Quality Gates (z.B. Software Requirements Review)
sind während des gesamten Software Life Cycle
durchzuführen, um sicherzustellen, dass die entwickel-
ten Software Life Cycle Daten (inklusive des Software
Produktes) ihre Anforderungen in entsprechender
Qualität erfüllen und dass der Software Life Cycle Pro-
zess gemäß der Software Pläne und Standards durch-
geführt wurde.
Diese Quality Gates schließen eine entsprechende
Prozessphase ab und genehmigten den Eintritt in die
folgende Prozessphase. Die nachfolgende Quality
Gates sind auszuführen:
Initiale Softwareentwicklung:
 Planning Process Review (PPR)
 Software Requirements Review (SRR)
 Software Design Review (SDR)
 Software Test Readiness Review (STRR)
 Software Conformity Review (SCR)
 First Delivery Review (FDR)
 First Flight Review (FFR)
 Compliance Review for Certification (CRC)
 Delivery Review (DR) for Software Level E
 Production Release Review (PRL)
Entwicklung einer Softwareänderung:
 Status Review (SR)
 Software Conformity Review (SCR)
 Compliance Review for Change Certification
(CRcC)
 Delivery Review (DR) for Software Level E
 Production Release Review (PRL)
Anmerkung: Gemäß der ABD0100.2.4 Kapitel 3.3.6.5
„Schedule of DR for software level E“ soll dieses Re-
view vor einer Auslieferung durchgeführt werden, min-
destens vor einer Auslieferung der ersten Version, die
für den „In Service“ Betrieb vorgesehen ist. Die Not-
wendigkeit der Wiederholung des Reviews für weitere
fliegende Baselines hängt vom Fertigstellungsgrad und
der Art der Änderung ab. Dennoch hat die QA hat für
jede fliegende Baseline sicherzustellen, dass ausrei-
chende Verifikations- und Quality Assurance Aktivitä-
ten durchgeführt worden sind.
4.3.4 Certification-Liaison-Prozess
Die Zielsetzung des Certification-Liaison-Prozesses ist
die Kommunikation und Abstimmung mit den zuständi-
gen Zulassungsdienststellen, um die Zulassung zu
unterstützen.
PB-EN-32
Seite 26 von 36
Page 26 of 36
Ausgabe
10, 16 DEC 2021
Issue
4.3.3.1 Quality Gates Activities
Quality gates (e.g. software requirement review) shall
be carried out throughout the software life cycle to
ensure that the software life cycle data (inclusive soft-
ware product) being developed satisfy its requirements
of acceptable quality and the software life cycle pro-
cess is performed in compliance with the software
plans and standards.
These quality gates shall finish the associated process
phase and grant access for the following process
phase. The following quality gates shall be performed:
Initial software development:
 Planning Process Review (PPR)
 Software Requirements Review (SRR)
 Software Design Review (SDR)
 Software Test Readiness Review (STRR)
 Software Conformity Review (SCR)
 First Delivery Review (FDR)
 First Flight Review (FFR)
 Compliance Review for Certification (CRC)
 Delivery Review (DR) for software level E
 Production Release Review (PRL)
Development of a software change:
 Status Review (SR)
 Software Conformity Review (SCR)
 Compliance Review for Change Certification
(CRcC)
 Delivery Review (DR) for Software Level E
 Production Release Review (PRL)
Note: According to ABD0100.2.4 chapter 3.3.6.5
“Schedule of DR for software level E” this review shall
be held before a delivery of the equipment, at least
before delivery of the first version that shall be applied
in service. The need to repeat this activity on other
flyable baselines will be considered depending on the
status of completion of the activities and the im-
portance of the change. However, QA shall assure that
sufficient verification and assurance activities have
been performed on any flyable baseline.
4.3.4 Certification Liaison Process
The objective of the certification liaison process is to
establish communication and understanding with the
competent certification authorities to assist the certifi-
cation process.
 Software Entwicklungs-Prozess-Abläufe
Software Development-Process-Workflows
Anmerkung: Zuständige Zulassungsdienststellen kön-
nen beispielsweise Behörden, wie die EASA, oder
auch EASA zugelassene Design Organisationen sein.
Während des Certification-Liaison-Prozesses wird der
Plan for Software Aspects of Certification (PSAC), und
weitere angeforderte Daten, an die zuständige Zulas-
sungsdienststellen zum Review überstellt. Anmerkun-
gen seitens der Zulassungsdienststellen sind entspre-
chend zu korrigieren, um abschließend eine Einigung
hinsichtlich des PSAC zu erhalten.
Das Software Accomplishment Summary (SAS) ist zu
erstellen, um die Übereinstimmung des Software Life
Cycle und Daten mit den Software Plänen und Stan-
dards zu bestätigen. Alle Abweichungen zum abge-
stimmten PSAC sind entsprechend im SAS auszuwei-
sen.
Der Software Configuration Index (SCI) ist zu erstellen,
um die Software Produkt- und Software Life Cycle
Daten Baseline zu definieren.
Wenn PDIs verwendet werden, ist zusätzlich ein Pa-
rameter Data Item Accomplishment Summary (PAS)
zu erstellen. Dieser beinhaltet für die PDIs sowohl alle
SAS als auch SCI relevanten Aspekte.
SAS, SCI (ggf. PAS) und weiter angeforderte Daten
werden an die zuständigen Zulassungsdienststellen
zum Review überstellt. Anmerkungen seitens der Zu-
lassungsdienststellen sind entsprechend zu korrigie-
ren.
Für Airbus interne Zwecke ist die Declaration of Design
and Performance (DDP) zum FDR, FFR und
CRC/DR/CRcC zu erstellen und an den Kunden
und/oder internem/externem Fachbereich auszuliefern,
wenn das Software Produkt gemäß PB-EN-61 als LRU
FLS deklariert ist. Ansonsten erfolgt das über den
Equipment Entwicklungs-Prozess gemäß PB-EN-30.
Des Weiteren ist in dieser Prozessphase die Schnitt-
stelle zu den internen System Test gemäß PB-EN-40
definiert.
Die an den internen System Test zu transferierende
Software ist gemäß des Intermediate Standards, defi-
niert in ABD0100.2.4; im speziellen Kapitel 4
„Documents to be Delivered with Each Intermediate
Standard“, zu dokumentieren. Dafür ist kein spezifi-
sches Software Life Cycle Dokument vorgeschrieben.
Das ETemp-451 „SW Delivery Description for Interme-
diate Standards“ ist zu Dokumentationszwecken zu
verwenden.
Rollen, Inputs/Outputs und Aktivitäten
Die grundsätzlichen Rollen und Zuständigkeiten sind in
Kapitel 2.3 definiert.
PB-EN-32
Seite 27 von 36
Page 27 of 36
Ausgabe
10, 16 DEC 2021
Issue
Note: For instance, competent certification authorities
might be either an agency like the EASA or an EASA
approved Design Organization.
In the certification liaison process the Plan for Software
Aspects of Certification (PSAC) and other requested
data are submitted to the competent certification
authorities for review purpose. Issues identified by the
certification authorities shall be resolved accordingly to
obtain an agreement on the PSAC.
The Software Accomplishment Summary (SAS) shall
be established to provide evidence that the software
life cycle processes and data satisfy the software plans
and standards. Any differences to the agreed PSAC
shall be described in the SAS.
The Software Configuration Index (SCI) shall be estab-
lished to define the software product and software life
cycle data baseline.
If PDIs are used, additionally a Parameter Data Item
Accomplishment Summary (PAS) shall be established.
The PAS contains all relevant SAS and SCI aspects
for the PDIs.
SAS, SCI (PAS if applicable) and other requested data
are submitted to the competent certification authorities
for review purpose. Issues identified by the certification
authorities shall be resolved accordingly.
For Airbus internal purpose the Declaration of Design
and Performance (DDP) shall be established and de-
livered to the customer and/or internal/external de-
partment at the FDR, FFR and CRC/DR/CRcC if the
software product is declared as LRU FLS according to
PB-EN-61. Otherwise it is performed via the Equip-
ment Development-Process according to PB-EN-30.
Further, this process phase includes the definition of
interface to the internal system test according to
PB-EN-40.
The software to be transferred to internal system test
shall be documented according to Intermediate Stand-
ard defined in ABD0100.2.4; especially chapter 4
„Documents to be Delivered with Each Intermediate
Standard“. Therefore no specific software life cycle
data is defined. The ETemp-451 “SW delivery descrip-
tion for intermediate standards” shall be used for doc-
umentation purpose.
Roles, Inputs/Outputs and Activities
The fundamental roles and competencies are defined
in chapter 2.3.
 Software Entwicklungs-Prozess-Abläufe PB-EN-32
Seite 28 von 36
Software Development-Process-Workflows Page 28 of 36
Ausgabe
10, 16 DEC 2021
Issue

Die prozessschritt-spezifischen Inputs/Outputs und
Aktivitäten sind rollenorientiert im Prozessschritt (6)
der Prozessflussdiagramme aus Kapitel 3 definiert.
Transitions-Kriterien
Die Bedingungen, um in den Certification-Liaison-
Prozess einzutreten, sind die Verfügbarkeit der ge-
nehmigten und autorisierten Prozess-Inputs, wie im
Prozessflussdiagramm des Kapitels 3 aufgeführt.
Der Certification-Liaison-Prozess ist vollständig durch-
geführt, wenn sein Zielsetzungen erreicht und diese
durch das Zulassungspapier der Luftfahrtbehörde ge-
nehmigt worden sind.
The process-step specific inputs/outputs and activities
are defined related to the roles in the process step (6)
of workflow diagrams in chapter 3.
Transition Criteria
The conditions to enter the certification liaison process
are the availability of approved and authorized process
inputs listed in workflow diagram of chapter 3.
The software certification liaison process is complete
when its objectives are satisfied approved by the certi-
fication statement of the authorities.
 Software Entwicklungs-Prozess-Abläufe
Software Development-Process-Workflows
4.3.5 Produktions-Transfer-Prozess
Die Zielsetzung des Produktions-Transfer-Prozess ist
es, das gemäß ABD0100 und DO-178 entwickelte
Software Produkt zur Serienproduktion zu transferie-
ren.
Der Produktions-Transfer-Prozess ist zur Überstellung
des finalen Software Produktes nach dem CRC / DR
/CRcC durchzuführen. Er ist des Weiteren für jedes
Software Produkt im Kontext des FDR / FFR anzu-
wenden, wenn die Herstellung und Verteilung offiziell
über die Produktion erfolgen soll.
Zur eindeutigen Identifikation des Software Produktes
und der zugehörigen Integritätsdaten ist das Software
Production Release Document gemäß ETemp-514 zu
verwenden. Die Daten sind aus dem gültigen Software
Configuration Index (SCI, PAS für PDIs) zu überneh-
men.
Das zu transferierende Software Produkt, die dazuge-
hörigen Integritätsdaten und das Software Production
Release Document sind zur Übertragung in einen spe-
ziellen Austauschordner abzulegen, der ebenfalls im
Software Production Release Document angegeben
wird. Der Serienüberleitungs-Verantwortliche ist über
die Verfügbarkeit der Daten zu informieren.
Anmerkung: Die „Serienüberleitung“ erstellt aus den
Informationen des Software Production Release
Documents die offizielle Engineering Change Note
(ECN) in Buddy.
Die korrekte Übertragung der Daten aus dem Software
Production Release Document in die Engineering
Change Note (ECN) in Buddy ist zu überprüfen und
mittels Unterschrift zu bestätigen.
Rollen, Inputs/Outputs und Aktivitäten
Die grundsätzlichen Rollen und Zuständigkeiten sind in
Kapitel 2.3 definiert.
Die prozessschritt-spezifischen Inputs/Outputs und
Aktivitäten sind rollenorientiert im Prozessschritt (7)
der Prozessflussdiagramme aus Kapitel 3 definiert.
Transitions-Kriterien
Die Bedingungen, um in den Produktions-Transfer-
Prozess einzutreten, sind die Verfügbarkeit der ge-
nehmigten und autorisierten Prozess-Inputs, wie im
Prozessflussdiagramm des Kapitels 3 aufgeführt.
Des Weiteren muss das DDP (Declaration of Design
and Performance) vollständig unterschrieben vorlie-
gen.
PB-EN-32
Seite 29 von 36
Page 29 of 36
Ausgabe
10, 16 DEC 2021
Issue
4.3.5 Production Transfer Process
The objective of the production transfer process is to
transfer the developed software product according to
ABD0100 and DO-178 for series production purpose.
The production transfer process shall be performed for
production transfer of the final software product after
CRC / DR / CRcC. It is also applicable for any inter-
mediate software product in terms of FDR and FFR
that shall be officially produced and delivered via pro-
duction.
For unique identification purpose of the software
product and its associated integrity data the software
production release document according to ETemp-514
shall be used. The data shall be taken from the
applicable Software Configuration Index (SCI, PAS for
PDIs).
The software product to be transferred, its associated
integrity data and the software production release
document shall be copied into the production transfer
exchange folder according to software production
release document. The production transfer responsible
shall be informed about the availability of the data.
Note: Within production transfer the official Engineer-
ing Change Note (ECN) is generated in Buddy out of
this software production release document information.
The correctness regarding the incorporation of soft-
ware production release document information into the
Engineering Change Note (ECN) in Buddy shall be
checked and approved by signature.
Roles, Inputs/Outputs and Activities
The fundamental roles and competencies are defined
in chapter 2.3.
The process-step specific inputs/outputs and activities
are defined related to the roles in the process step (7)
of workflow diagrams in chapter 3.
Transition Criteria
The conditions to enter the production transfer process
are the availability of approved and authorized process
inputs listed in workflow diagram of chapter 3.
Further the DDP (Declaration of Design and Perfor-
mance) is available with all signatures.
 Software Entwicklungs-Prozess-Abläufe PB-EN-32
Seite 30 von 36
Software Development-Process-Workflows Page 30 of 36
Ausgabe
10, 16 DEC 2021
Issue

Der Produktions-Transfer-Prozess ist vollständig
durchgeführt, wenn seine Zielsetzungen erreicht und
durch das Production Release Review (PRL) im Status
„grün“ oder „gelb“ gemäß QG Ampelsteuerung der
PB-EN-60 genehmigt worden sind.
The production transfer process is complete when its
objectives are satisfied approved by the performance
of the associated production release review (PRL) in
status “green” or “amber” according to QG traffic light
control of PB-EN-60.
 Software Entwicklungs-Prozess-Abläufe
Software Development-Process-Workflows
4.4 Softwareänderungen
Jede Änderung einer bereits zertifizierten Software
wird im Rahmen eines Änderungsprozesses einge-
bracht. Für Änderungen an PDIs / Konfigurations Da-
teien ist ein Tailoring des Änderungsprozesses mög-
lich.
Der Änderungsprozess ist nicht in den Prozessdia-
grammen im Kapitel 3 dargestellt wird jedoch in den
folgenden Unterkapitel beschreiben.
4.4.1 Planung des Änderungsprozesses
Die Zielsetzung der Planung des Änderungsprozesses
ist die Compliance der vorherigen Dokumentations-
Baseline mit den gültigen Zertifizierungsanforderungen
zu prüfen und zu klären, welche Quality Gates, abhän-
gig von den geänderten Life Cycle Data, erneut durch-
geführt werden müssen.
Rollen, Inputs/Outputs und Aktivitäten
Die grundsätzlichen Rollen und Zuständigkeiten sind in
Kapitel 2.3 definiert.
Die prozessschritt-spezifischen Inputs ist:
- Vorherige Dokumenten-Baseline.
Die prozessschritt-spezifischen Aktivitäten sind:
- Identifikation der Auswirkungen durch die ge-
plante Softwareänderung und
- Erstellung einer Software Change Impact Ana-
lyse (SCIA).
Die prozessschritt-spezifischen Outputs sind:
- Software-Change-Impact-Analyse (SCIA),
- Software Configuration Management Report
(SCMR),
- Software Quality Assurance Report (SQAR)
und
- Review Report.
Transitions-Kriterien
Die Bedingungen, um in die Planung des Änderungs-
prozesses einzutreten, sind die Verfügbarkeit der Pro-
zess-Inputs:
- Life-Cycle-Daten der Input-Baseline inkl.:
o Software Configuration Index (SCI),
o Software Accomplishment Summary
(SAS).
Die Planung des Änderungsprozesses ist vollständig
durchgeführt, wenn seine Zielsetzungen erfüllt und
durch ein Software Status Review (SR) im Status
„grün“ oder „gelb“ gemäß QG Ampelsteuerung der
PB-EN-60 genehmigt worden ist.
PB-EN-32
Seite 31 von 36
Page 31 of 36
Ausgabe
10, 16 DEC 2021
Issue
4.4 Software Changes
Every change of an already certified software will be
introduced by using a change process. For changes on
PDIs / Configuration Files a tailoring of the change
process is possible.
The modification process has not been shown in the
process diagrams in chapter 3 but will be described in
the following subchapters.
4.4.1 Planning of Change Process
The objective of the planning of the Change Process is
to check the compliance of the previous documentation
baseline with the applicable certification requirements
and to discuss the need for re-execution of previously
performed quality gates depending on the changed life
cycle data.
Roles, Inputs/Outputs and Activities
The fundamental roles and competencies are defined
in chapter 2.3.
The process-step specific inputs is:
- Previous documentation baseline.
The process-step specific activities are:
- Identification of the effects resulted by the
planned software change and
- Creation of a Software Change Impact Analy-
sis (SCIA).
The process-step specific outputs are:
- Software-Change-Impact-Analysis (SCIA),
- Software Configuration Management Report
(SCMR),
- Software Quality Assurance Report (SQAR)
and
- Review Report.
Transition Criteria
The conditions to enter the planning of the software
change process are the availability of the process in-
puts:
- Life-Cycle-Data of Input-Baseline incl.:
o Software Configuration Index (SCI),
o Software Accomplishment Summary
(SAS).
The planning of the change process has been com-
pleted if its objectives are satisfied and approved by
performance of a Software Status Review (SR) in sta-
tus “green” or “amber” according to QG traffic light
control of PB-EN-60.
 Software Entwicklungs-Prozess-Abläufe
Software Development-Process-Workflows
4.4.2 Änderungsprozess
Die Zielsetzung des Änderungsprozesses ist die Im-
plementierung der Softwareänderung wie durch die
SCIA analysiert und beschrieben.
Rollen, Inputs/Outputs und Aktivitäten
Die grundsätzlichen Rollen und Zuständigkeiten sind in
Kapitel 2.3 definiert.
Die prozessschritt-spezifischen Inputs sind:
- Vorherige Dokumenten-Baseline und
- Software-Change-Impact-Analyse (SCIA).
Die prozessschritt-spezifischen Aktivitäten sind:
- Umsetzung der in der SCIA identifizierten Än-
derungen,
- Anpassung der Life-Cycle-Dokumente, soweit
erforderlich und
- Aktualisierung von SCI und SAS.
Die prozessschritt-spezifischen Outputs sind:
- Überarbeitete Life-Cycle-Dokumente,
- Software Configuration Management Report
(SCMR),
- Software Quality Assurance Report (SQAR)
und
- Review Report.
Transitions-Kriterien
Die Bedingungen, um in den Änderungsprozess einzu-
treten, sind die Verfügbarkeit der Prozess-Inputs:
- Life-Cycle-Daten der Input-Baseline inkl.:
o Software Configuration Index (SCI),
o Software Accomplishment Summary
(SAS),
- Software-Change-Impact-Analyse (SCIA).
Der Änderungsprozesses ist vollständig durchgeführt,
wenn seine Zielsetzungen erfüllt und durch ein Com-
pliance Review for change Certification (CRcC), oder
im Falle von Software Level E durch ein Status Review
(SR), im Status „grün“ oder „gelb“ gemäß QG Ampel-
steuerung der PB-EN-60 genehmigt worden ist.
PB-EN-32
Seite 32 von 36
Page 32 of 36
Ausgabe
10, 16 DEC 2021
Issue
4.4.2 Change Process
The objective of the Change Process is the implemen-
tation of the software change as analyzed and de-
scribed by SCIA.
Roles, Inputs/Outputs and Activities
The fundamental roles and competencies are defined
in chapter 2.3.
The process-step specific inputs are:
- Previous documentation baseline and
- Software Change Impact Analysis (SCIA).
The process-step specific activities are:
- Implementation of changes identified by SCIA,
- Adjustment of life cycle documentation where
required and
- Update of SCI and SAS.
The process-step specific outputs are:
- Re-worked life-cycle-documents,
- Software Configuration Management Report
(SCMR),
- Software Quality Assurance Report (SQAR)
and
- Review Report.
Transition Criteria
The conditions to enter the planning of the software
change process are the availability of the process in-
puts:
- Life-Cycle-Data of Input-Baseline incl.:
o Software Configuration Index (SCI),
o Software Accomplishment Summary
(SAS),
- Software-Change-Impact-Analysis (SCIA).
The change process has been completed if its objec-
tives are satisfied and approved by performance of a
Compliance Review for change Certification (CRcC),
or in case of software level E a Status Review (SR), in
status “green” or “amber” according to QG traffic light
control of PB-EN-60.
 Software Entwicklungs-Prozess-Abläufe PB-EN-32
Seite 33 von 36
Software Development-Process-Workflows Page 33 of 36
Ausgabe
10, 16 DEC 2021
Issue

5 Mitgeltende Unterlagen 5 Associated Documents

Die nachfolgenden Dokumente gelten jeweils in der The following documents apply in the current form.
aktuellen Form.
PB-EN-30 Equipment Entwicklungs-Prozess- PB-EN-30 Equipment Development-Process-
Abläufe Workflows

PB-EN-31 Hardware Entwicklungs-Prozess- PB-EN-31 Hardware Development-Process-

Abläufe Workflows

PB-EN-40 System Validation & Verification PB-EN-40 System Validation & Verification
Prozess-Abläufe Process-Workflows

PB-EN-50 Serienüberleitung / Serienbetreuung PB-EN-50 Production transfer / Series support

PB-EN-60 Qualitätsmanagement im AIRBUS PB-EN-60 Quality Management at AIRBUS BUX

BUX Engineering Engineering

PB-EN-61 Partnummerndefinition PB-EN-61 Partnumber definition

PB-EN-62 Prozess zur Organisation der PB-EN-62 Process for Organisation of

Entwicklungsdokumente Engineering Documentation

PB-IM-06 Exportkontrolle am Standort PB-IM-06 Export Control at Buxtehude site

Buxtehude

PV-EN-63 Verbesserungsprozess PV-EN-63 Improvement Process

ABD0100 Equipment- Design General Re- ABD0100 Equipment- Design General

quirements for Suppliers Requirements for Suppliers

DO-178 EUROCAE/ED-12 RTCA/DO-178 DO-178 EUROCAE/ED-12 RTCA/DO-178

Software Considerations in Airborne Software Considerations in Airborne
Systems and Equipment Certification Systems and Equipment Certification

DO-330 EUROCAE/ED-215 / RTCA/DO-330 DO-330 EUROCAE/ED-215 / RTCA/DO-330

Software Tool Qualification Software Tool Qualification
Considerations Considerations

DO-331 EUROCAE/ED-218 / RTCA/DO-331 DO-331 EUROCAE/ED-218 / RTCA/DO-331

Model-Based Development and Model-Based Development and
Verification Verification

DO-332 EUROCAE/ED-217 / RTCA/DO-332 DO-332 EUROCAE/ED-217 / RTCA/DO-332

Object-Oriented Technology and Object-Oriented Technology and
Related Techniques Related Techniques

DO-333 EUROCAE/ED-216 / RTCA/DO-333 DO-333 EUROCAE/ED-216 / RTCA/DO-333

Formal Methods Formal Methods

AMC20-115 Acceptable Means of Compliance; AMC20-115 Acceptable Means of Compliance;

Airborne Software development Airborne Software development
Assurance using EUROCAE ED-12 Assurance using EUROCAE ED-12
and RTCA DO-178 and RTCA DO-178
 Software Entwicklungs-Prozess-Abläufe PB-EN-32
Seite 34 von 36
Software Development-Process-Workflows Page 34 of 36
Ausgabe
10, 16 DEC 2021
Issue

TBCKE- COTS Management Plan (COTS-MP) TBCKE- COTS Management Plan (COTS-MP)
5921/12 5921/12

ECYE- Security Management and ECYE- Security Management and

6133/13 Development Plan (SMDP) 6133/13 Development Plan (SMDP)
EASA Part 21 Airworthiness and Environmental Certi- EASA Part 21 Airworthiness and Environmental Certi-
fication fication
 Software Entwicklungs-Prozess-Abläufe PB-EN-32
Seite 35 von 36
Software Development-Process-Workflows Page 35 of 36
Ausgabe
10, 16 DEC 2021
Issue

6 Änderungsverzeichnis 6 Record of Revision

Ausgabe / Issue Datum / Date Änderungsgrund / Reason for Revision

5 30.01.2015 - Anpassung Unterschriftenseite
- Anpassung 1.Verfahrenssteckbrief /
- Kapitel 6 neu
- Anpassung komplett an KPB-EN-32

- Revision of signature page

- Revision of 1.Procedure summary
- Chapter 6 new
- Revision of all according to KPB-EN-32
6 02.12.2015 - Einführung der DO-178C (Kapitel 2, 2.1, 2.4, 3.1, 3.2, 3.3, 3.4, 4.2.4,
4.3.1.4, 4.3.4, 4.3.5, 5)
- Anpassung an Vorgaben der PB-IM-01 (Verfahren -> Prozess, …)

- Introduction of DO-178C (chapter 2, 2.1, 2.4, 3.1, 3.2, 3.3, 3.4, 4.2.4,
4.3.1.4, 4.3.4, 4.3.5, 5)
- Update according to PB-IM-01 (procedure -> process, …)

7 08.02.2018 - Anpassung des Logo

- Anpassung an die gültige Version des AMC20-115 (Kapitel 2)
- Änderung der Produktbezeichnung von „ARTiSAN RT Studio“ zu „PTC
Integrity Modeler“ incl. Anpassung des Distributors(Kapitel 3.5)
- Harmonisierung des deutschen und englischen Textes (Kapitel 4.1)

- Adaption of Logo
- Adaption to valid version of AMC20-115 (Chapter
- 2)
- Change of product identification from ARTiSAN RT Studio“ to „PTC
Integrity Modeler“ incl. Adaption of Distributor (Chapter 3.5)
- Harmonization of German and English text (Chapter 4.1)

8 29.10.2018 - Anpassung Unterschriftenseite

- Kapitel 2.1 Exportkontrolle Prozess eingefügt
- Kapitel 5 PB-IM-06 referenziert

- Revision of signature page

- Chapter 2.1 Export control process added
- Chapter 5 PB-IM-06 referenced
9 20.04.2020 - Anpassung an neue Organisation
- Einführung neuer PDI Dokumente
- Einführung Softwareänderungsprozess
- Kleinere Korrekturen

- Adaptation to new organization

- Introduction of new PDI documents
- Introduction of process for software changes
- Minor corrections
 Software Entwicklungs-Prozess-Abläufe PB-EN-32
Seite 36 von 36
Software Development-Process-Workflows Page 36 of 36
Ausgabe
10, 16 DEC 2021
Issue

10 16.12.2021 - Anpassung Unterschriftenseite

- Kapitel 2.3 PQA ersetzt durch PQR, DQA Rolle entfernt
- Kapitel 3&4 Referenzen generalisiert wegen Einführung der
ABD0100g2
- Kapitel 3.1/4.3.1.5 RCS eingeführt wegen Konformität zu 4.3.7 EU
Part 21 Requirement 21.A.33(b)(c);
- Kapitel 3.4 Google Tools hinzugefügt
- Kapitel 5 Referenz Part 21 eingefügt

- Adaptation Signature Page

- Chapter 2.3 PQA replaced by PQR, DQA role removed
- Chapter 3&4 References generalized due to introduction of
ABD0100g2
- Chapter 3.1/4.3.1.5 RCS introduced due to conformity to 4.3.7 EU Part
21 Requirement 21.A.33(b)(c);
- Chapter 3.4 Google Tools added
- Chapter 5 Referenz Part 21 added