Sie sind auf Seite 1von 36

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

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 PB-EN-32
Seite 3 von 36
Software Development-Process-Workflows Page 3 of 36
Ausgabe
10, 16 DEC 2021
Issue

2 Software Entwicklungs-Prozess-Abläufe 2 Software Development-Process-Workflows

Der in diesem Prozess dokumentierte Software Life This process documents the software life cycle based
Cycle basiert auf der DO-178 und der internen Pro- on the DO-178 and the internal process definition/
zessdefinition/ Templates und ist gültig für alle Vorha- templates and is valid for all assignments for the de-
ben für die Entwicklung von Softwareprodukten der velopment of software products with software level B to
Software Level B bis E. E.
Diese Prozessbeschreibung basiert auf der DO-178 This process description is based on DO-178 version
Version C. C.
Vorgängerversionen, die Prozesse beinhalten, die auf Previous versions containing processes based on
der DO-178B basieren, können weiterhin für die Ent- DO178B may be continued to be used for new soft-
wicklung von neuer Software genutzt werden, sofern ware development in case the criteria given in the cur-
die Kriterien erfüllt sind, die im AMC20-115 in der ak- rent valid issue of AMC20-115 are met.
tuell gültigen Version definiert sind.

Im Falle, dass die Kapitelidentifikationen für äquivalen- In case where chapter identification differs for equiva-
ten Inhalt zwischen der aktuellen und vorherigen lent content between the current and previous version
DO-178 differieren, sind alle gültigen Kapitelreferenzen of the DO-178, all applicable chapter references are
in den Prozessflussdiagrammen identifiziert; getrennt identified within the workflow diagrams; separated by
durch „/“. “/”.
Die in den DO-178C Ergänzungen DO-331, DO-332 The details addressed by DO-178C supplements
und DO-333 sowie DO-330 adressierten Details sind DO-331, DO-332 and DO-333 as well as DO-330 are
nicht explizit in diesem Software Entwicklungs- not explicit considered within this software develop-
Prozess-Ablauf berücksichtigt, um den Ansatz eines ment-process-workflow in order to keep the overview
DO-178 orientierten Software Life Cycle Überblicks zu approach oriented to the main software life cycle of
wahren. Wenn die Anwendung über die oben geliste- DO-178. If applicable in accordance with the criteria
ten Kriterien gegeben ist, muss der Inhalt entspre- listed above, the content has to be considered, accord-
chend berücksichtigt werden. ingly.

2.1 Software Life Cycle Prozesse 2.1 Software Life Cycle Processes

Software Planungs-Prozess Software Planning Process


Der Software Planungs-Prozess produziert oder selek- The software planning process produces or selects the
tiert die Software Pläne und Standards, welche die software plans and standards that direct the software
Software Entwicklungs-Prozesse und die integralen development processes and the integral processes.
Prozesse regeln.

Software Entwicklungs-Prozesse Software Development Processes


Die Software Entwicklungs-Prozesse produzieren das The software development processes produce the
Software Produkt. Diese bestehen aus den folgenden software product. They consist of the following sub-
Sub-Prozessen: processes:

 Software Requirements-Prozess  software requirements process


 Software Design-Prozess  software design process
 Software Coding-Prozess  software coding process
 Integrations-Prozess  integration process

Integrale Prozesse Integral Processes


Die integralen Prozesse sichern die Fehlerfreiheit, die The integral processes ensure the correctness, control,
Steuerung/Überwachung und das Vertrauen in die and confidence of the software life cycle processes
Software Entwicklungs-Prozesse und des produzierten and their outputs according to the software plans and
Outputs gemäß der Software Pläne und Standards ab. 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 PB-EN-32
Seite 6 von 36
Software Development-Process-Workflows Page 6 of 36
Ausgabe
10, 16 DEC 2021
Issue

COTS Management Prozess COTS Management Process


Im Falle der Verwendung von COTS (Commercial off In the case of COTS (Commercial off the Shelf) prod-
the Shelf) Produkten kommt der COTS Management uct usage the COTS management process becomes
Prozess zur Anwendung. applicable.
Der COTS Management Prozess definiert den Life The COTS management process defines the process
Cycle Prozess und die Daten für ein COTS Manage- life cycle and data for COTS management during the
ment über den kompletten A/C Lebenszyklus. Das A/C life cycle. That includes COTS verification, evalua-
beinhaltet die COTS Verifikation, Bewertung und Aus- tion and selection, security, acquisition, integration and
wahl, Sicherheit, Beschaffung, Integration und Konfigu- configuration management, maintenance and support,
rations-Management, Wartung und Support, organisa- organizational responsibilities, accountability and au-
torische Verantwortlichkeiten nebst Berechtigungen, thority, risk management and identification of artefacts
Risiko Management und die Identifikation von Artefak- to support COTS management.
ten zur Unterstützung des COTS Management.
Der COTS Management Prozess ist im COTS Ma- The COTS management process is described in the
nagement Plan (COTS-MP) beschrieben und gilt für COTS Management Plan (COTS-MP), applicable for
alle Software Embedded COTS und Entwicklungstools. all software embedded COTS and development tools.
Der COTS-MP gilt dann zusätzlich zu diesem Doku- The COTS-MP shall be considered in addition to this
ment. document.

Security Management & Development Prozess Security Management & Development Process
Der Security Management und Development Prozess In case of the project / product specific Statement of
kommt in dem Falle zur Anwendung, in dem das pro- Work (SoW) declares the application of Security
jekt- / produkt-spezifische Statement of Work (SoW) Assurance Requirements (SAR), the Security
die Verwendung der Security Assurance Requirements management and development process becomes
(SAR) vorschreibt. applicable.

Der Security Management und Development Prozess The Security management and development process
definiert den Life Cycle Prozess und die sogenannten defines the process life cycle and project assets for
Projekt Assets für ein Security Management über den security management during the A/C life cycle in order
kompletten A/C Lebenszyklus, um das Produkt ent- to develop the product with the Security Assurance
sprechend des geforderten Security Assurance Level Level (SAL) required, including:
(SAL) zu entwickeln. Das beinhaltet:

 eine Beschreibung der Security Organisation auf  a description of the security organization at corpo-
Unternehmensbereichs- und Projektlevel, rate and project levels,
 eine Beschreibung der Security Infrastruktur auf  a description of the security infrastructure at corpo-
Unternehmensbereichs- und Projektlevel, rate and project levels,
 eine Liste der Security Projekt Assets des Produk-  a list of all security project assets of the product;
tes; inkl. Spezifikation, Designs & Implementierung, incl. specification, design & implementation, verifi-
Verifikation, Validierung und Evaluierungsdaten, cation, validation and evaluation data, guidance
Leitlinien und deren Verfügbarkeit zu den Review, documents and its availability for reviews,
 eine Development Tool Analyse; inkl. des Konfigu-  a development tool analysis; incl. configuration
rationsmanagements management,
 eine COTS Analyse,  a COTS analysis,
 eine Definition des Life Cycle Models; inkl. einer  a definition of the life-cycle model; incl. a conform-
Konformitätserklärung, wie Security berücksichtigt ance claims rationale how to take the security into
wird, um konform zu dem für das Produkt geforder- account in order being compliant with the required
ten SAL zu sein, SAL for the product,
 Gesetzes- und Regulierungsinformation,  laws and regulation information,
 Security Vulnerability Analyse; inkl. Security  Security Vulnerability Analysis; incl. security survey
Kontrollprozeduren procedure
Software Entwicklungs-Prozess-Abläufe PB-EN-32
Seite 7 von 36
Software Development-Process-Workflows Page 7 of 36
Ausgabe
10, 16 DEC 2021
Issue

Der Security Management und Development Prozess The Security management and development process
ist im Security Management und Development Plan is described in the Security Management and Devel-
(SMDP) beschrieben. opment Plan (SMDP).
Der SMDP gilt zusätzlich zu diesem Dokument The SMDP shall be considered in addition to this doc-
ument.

Exportkontrolle Prozess Export control process


Im Fall von Exportvorhaben wie In case of exporting plans like
 Voranfragen, Angebotsanforderungen  advance inquiries, quotation requests
 Kooperations- oder Lizenzvorhaben  cooperation- or licensing projects
 Ausfuhr/Verbringung von Daten  export/ transfer of data
im Sinne der PB-IM-06, ist der Projektleiter vorab zu in the meaning of PB-IM-06, the project leader should
informieren und der Prozess der Exportkontrolle ge- be informed previously and the Export control process
mäß PB-IM-06 zu berücksichtigen. should be taken into account according to PB-IM-06.

2.2 Transitions-Kriterien zwischen Prozessen 2.2 Transition Criteria between Processes

Jeder Software Life Cycle Prozess führt Aktivitäten auf Each software life cycle process performs activities on
Inputs aus, um einen Output zu produzieren. inputs to produce outputs.
Transitions-Kriterien werden verwendet, um zu be- Transition criteria are used to determine whether a
schreiben, ob in einen Prozess eingetreten oder wie- process may be entered or re-entered respective may
der eingetreten respektive ob ein Prozess abgeschlos- be completed.
sen werden kann.
Die Transitions-Kriterien für den Prozess-Einstieg oder The transition criteria for the entering or re-entering of
-Wiedereinstieg sind erfüllt, wenn die Verfügbarkeit der a process are satisfied if the approved and authorized
genehmigten und autorisierten Prozess-Inputs besteht. process-inputs are available.
Der Input eines Prozesses braucht dabei nicht voll- Considering that the input to a process need not be
ständig zu sein bevor der Prozess initiiert werden complete before that process can be initiated, if the
kann, wenn die für diesen Prozess eingeführten Tran- transition criteria established for the process are
sitions-Kriterien erfüllt sind. satisfied.
Wenn ein Prozess auf unvollständigen Input agiert, If a process acts on partial inputs, subsequent inputs to
muss für nachträglichen Input des Prozesses eine the process have to be examined to determine that the
Prüfung erfolgen, um zu bestimmen, ob vorheriger previous outputs of the process are still valid.
Output des Prozesses weiterhin gültig ist.
Die Transitions-Kriterien für den Prozessabschluss The transition criteria for the process completion are
sind erfüllt, wenn die Zielsetzungen des Prozesses und satisfied if the objectives of this process and the objec-
die damit verbundenen Zielsetzungen der integralen tives of the integral processes associated with it are
Prozesse erfüllt sind. Die Bestätigung erfolgt durch den completed and satisfied, too. The compliance is shown
erfolgreichen Abschluss des zugehörigen Reviews / by successfully completion of the related review / quali-
Quality Gates im Status „grün“ oder „gelb“ gemäß QG ty gate in status “green” or “amber” according to QG
Ampelsteuerung der PB-EN-60. traffic light control of PB-EN-60.

Anmerkung: Die Transitions-Kriterien sind für jeden Note: The transition criteria’s for each software life
Software Life Cycle Prozess detailliert im Kapitel 4 cycle process are listed in detail in chapter 4.
aufgeführt.
Software Entwicklungs-Prozess-Abläufe PB-EN-32
Seite 8 von 36
Software Development-Process-Workflows Page 8 of 36
Ausgabe
10, 16 DEC 2021
Issue

2.3 Rollen im Software Life Cycle 2.3 Roles of the Software Life Cycle

Die Aufgaben und Ziele der oben aufgeführten Pro- The activities and objectives of the processes specified
zesse werden den folgenden vier Rollen zugeordnet: above are assigned to the following four roles:
 Implementer  Implementer
 Verifier  Verifier
 Configuration Manager (CM)  Configuration manager (CM)
 Quality Assurance (QA, durch PQR)  Quality assurance (QA, by PQR)

Der Begriff Quality Assurance (QA), der im The term Quality Assurance (QA) that is used within
Zusammenhang mit den Software-Life-Cycle the context of software life cycle processes is used in
Prozessen verwandt wird, wird analog zum Begriff analogy with the term Process Assurance (PA). In this
Process Assurance (PA) genutzt. In diesem context the activities for QA are performed by the
Zusammenhang werden die Aktivitäten zur QA durch Product Quality Responsible (PQR).
die Product Quality Responsible (PQR) ausgeführt.
Die Rolleninhaber sind für die Durchführung der zuge- The role holders are responsible for performance of
ordneten Aktivitäten und die Erreichung der zugeord- their assigned activities and attainability of their
neten Ziele verantwortlich. Die Rollen sind im Detail in assigned objectives. The roles are described in detail
der PB-EN-60 beschrieben. in the PB-EN-60.
2.4 Aufbau der Prozessbeschreibung 2.4 Structure of the Process Description

Für jede Rolle ist ein eigener Workflow beschrieben, For each role its own workflow is described, that repre-
der die jeweiligen Zusammenhänge zwischen den sents the respective coherences between the inputs /
Inputs / Outputs und den Aktivitäten pro Prozessschritt outputs and the activities per process step; considering
darstellt; wobei die Beschreibung der Aktivitäten ledig- that the description of the activities comprises just an
lich eine Übersicht umfasst. Der volle Umfang der Akti- overview. The details of all activities are described in
vitäten ist den angegebenen Referenzen zu entneh- the given references.
men.
Des Weiteren hängen die tatsächlich durchzuführen- Further the actual activities to be performed and
den Aktivitäten und die zu generierenden Outputs outputs to be generated depend on the applicable SW
maßgeblich vom anzuwendenden SW Level ab. Diese level. This dependencies can be found in the
Abhängigkeit ist den referenzierten Normen & Stan- referenced norms & standards, input data respective
dards, den Input Data respektive der Workflow Spalte the workflow column „Applicability by SW Level“
„Applicability by SW Level“ unter Berücksichtigung der considering the precedence in the meaning, that the
Präzedenz zu entnehmen. Dabei übersteuert das je- more specific document overrules the general.
weils speziellere Dokument das Allgemeinere, wobei Thereby, it shall be taken into account that the more
davon auszugehen ist, dass die spezielleren Vorgaben specific rules do not conflict with the general ones.
keinen direkten Widerspruch zu den allgemeineren Finally, the process definition of applicable software
darstellen. Letztendlich gilt für ein spezifisches Projekt plans and standards applies for a specific project. The
die Prozessdefinition in den anzuwendenden Software following hierarchical structure, from specific to
Plänen und Standards. Folgende Hierarchisierung vom general, applies:
Speziellen zum Allgemeinen gilt:

1. Projektspezifische Prozessdefinition (Software


Pläne und Standards) 1. Project specific process definition (software plans
2. Buxtehude interne allgemeine Prozessdefinition and standards)
(PBs, Templates) 2. Buxtehude internal general process definition
3. Spezifikationen (SoW, Spezifikation auf Sys- (PBs, templates)
tem/Equipment Level) 3. Specifications (SoW, specification on system /
4. Airbus Direktiven (ABD0100) equipment level)
5. Internationale Standards (DO-178, CRIs, etc.) 4. Airbus directives (ABD0100)
5. International standards (DO-178, CRIs, etc.)
Software Entwicklungs-Prozess-Abläufe PB-EN-32
Seite 9 von 36
Software Development-Process-Workflows Page 9 of 36
Ausgabe
10, 16 DEC 2021
Issue

Alle vier Workflows sind in Kapitel 3.1 bis 3.4 darge- All four workflows are represented in chapter 3.1 to 3.4
stellt und werden in den nachstehenden Kapiteln ver- and are deepened discussed in the following chapters.
tiefend behandelt. Die einzelnen Workflows sind über The single workflows are synchronized by process
die Prozessschrittnummern respektive den Quality step numbers respectively by the quality gates / re-
Gates / Reviews synchronisiert. views.

Die Synchronisation zum Equipment Entwicklungs- The synchronization with Equipment Development-
Prozess-Ablauf gemäß PB-EN-30 respektive Hardware Process-Workflow according to PB-EN-30 respective
Entwicklungs-Prozess-Ablauf gemäß PB-EN-31 ist aus Hardware Development-Process-Workflow according
Gründen der Redundanzvermeidung nur im Prozess- to PB-EN-31 is only integrated into the workflow dia-
flussdiagramm für den Implementer integriert. Die gram for the implementer due to avoidance of redun-
Synchronisation zum System Validation- und Verifica- dancy. The synchronization with System Validation-
tion-Prozess-Ablauf gemäß PB-EN-40 ist nur im Pro- und Verification-Process-Workflow according to
zessflussdiagramm für die QA detailliert dargestellt, da PB-EN-40 is integrated in detail into the workflow dia-
nur hier der Detailgrad der entsprechenden Prozess- gram for the QA only, hence only this workflow depicts
schnittstelle eine Abbildung findet. Die Workflow- the detail level of respective process interface. In any
Synchronisationen erfolgen jeweils über die Prozess- cases the workflows are synchronized by process step
schrittnummern. numbers.

2.4.1 COTS Management 2.4.1 COTS Management

Der COTS Management Plan (COTS-MP) berücksich- Since, the COTS Management Plan (COTS-MP)
tigt bereits alle Aspekte des COTS Management Pro- already considers all aspects of the COTS
zesses im Sinne von Normen & Standards, Eingangs- management process in terms of norm & standards,
daten, Prozessschritte, Aktivitäten, Ausgangsdaten, input data, process steps, activities, output data, SW
SW Level Abhängigkeit und Tools. Um Redundanzen level application and tools they are not duplicated into
zu vermeiden, finden diese keine erneute Abbildung in the process description of this document to avoid
der Prozessbeschreibung dieses Dokumentes. Ledig- redundancies. Just the way of application of the
lich das Vorgehen zur Anwendung / Gültigkeitserklä- COTS-MP is addressed in the software planning
rung des COTS-MP ist im Software Planungs-Prozess process (see process step (1) of Workflow diagram for
adressiert (siehe Prozessschritt (1) des Prozessfluss- the Implementer, chapter 3.1).
diagramm für den Implementer, Kapitel 3.1).
Um dennoch die Anwendung des COTS-MP kenntlich Nevertheless, in order to indicate the application of the
zu machen, ist dieser in den „Input Data“ aller betroffe- COTS-MP, it is listed as “Input Data” for every applica-
nen Prozessschritte eines jeden Prozessflussdiagrams ble process step of any workflow diagram.
aufgeführt.

2.4.2 Security Management & Development 2.4.2 Security Management & Development

Der Security Management und Development Plan Since, the Security Management and Development
(SMDP) berücksichtig bereits alle Aspekte des Plan (SMDP) already considers all aspects of the
Security Management und Development Prozesses im Security management and development process in
Sinne von Normen & Standards, Eingangsdaten, terms of norm & standards, input data, process steps,
Prozessschritte, Aktivitäten, Ausgangsdaten, Security activities, output data, Security Assurance Level (SAL)
Assurance Level (SAL) Abhängigkeit und Tools. Um application and tools they are not duplicated into the
Redundanzen zu vermeiden, finden diese keine process description of this document to avoid
erneute Abbildung in der Prozessbeschreibung dieses redundancies. Just the way of application of the SMDP
Dokumentes. Lediglich das Vorgehen zur Anwendung / is addressed in the software planning process (see
Gültigkeitserklärung des SMDP ist im Software process step (1) of Workflow diagram for the
Planungs-Prozess adressiert (siehe Prozessschritt (1) Implementer, chapter 3.1).
des Prozessflussdiagramm für den Implementer,
Kapitel 3.1).).
Um dennoch die Anwendung des SMDP kenntlich zu Nevertheless, in order to indicate the application of the
machen, ist dieser in den „Input Data“ aller betroffenen SMDP, it is listed as “Input Data” for every applicable
Prozessschritte eines jeden Prozessflussdiagrams process step of any workflow diagram.
aufgeführt.
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 PB-EN-32
Seite 15 von 36
Software Development-Process-Workflows Page 15 of 36
Ausgabe
10, 16 DEC 2021
Issue

4 Prozessabläufe im Software Life Cycle 4 Process flow of Software Life Cycle

Der Software Life Cycle Prozess definiert und koordi- The software life cycle process defines and coordi-
niert den Planungs-Prozess und die Entwicklungs- nates the planning process and the development pro-
Prozesse. Dabei handelt es sich um iterative Prozes- cesses. It deals with iterative processes which run
se, die inkrementell durchlaufen werden in Abhängig- incrementally depending upon the transition criteria
keit von Transitions-Kriterien und Ergebnissen der and the result of reviews. These processes inclusive
Reviews. Diese Prozesse inklusive der Sub-Prozesse, sub- processes, are accompanied parallel by the inte-
werden parallel durch den Integral-Prozess begleitet. gral processes.

4.1 Software Planungs-Prozess 4.1 Software Planning Process

Die Zielsetzung des Software Planungs-Prozesses ist The objective of the software planning process is the
die Definition der Vorgehensweise und der Hilfsmittel definition of the means and the tools used to develop
zur Herstellung der zu entwickelnden Software. the software.
Die zu entwickelnde Software erfüllt zudem die System In addition the developed software will satisfy the sys-
Requirements und bietet ein Vertrauensniveau, das tem requirements and provide the level of confidence
konform zu den Lufttüchtigkeits- und Vertragsanforde- which is consistent with the airworthiness and contrac-
rungen ist. tual requirements.
Im Software Planungs-Prozess werden die für die In the software planning process the plans and
Entwicklungs- und integralen Prozesse benötigten standards needed for the development and integral
Pläne und Standards erstellt. processes are established.

Rollen, Inputs/Outputs und Aktivitäten Roles, Inputs/Outputs and Activities


Die grundsätzlichen Rollen und Zuständigkeiten sind in The fundamental roles and competencies are defined
Kapitel 2.3 definiert. in chapter 2.3.
Die prozessschritt-spezifischen Inputs/Outputs und The process-step specific inputs/outputs and activities
Aktivitäten sind rollenorientiert im Prozessschritt (1) are defined related to the roles in the process step (1)
der Prozessflussdiagramme aus Kapitel 3 definiert. of workflow diagrams in chapter 3.

Transitions-Kriterien Transition Criteria


Die Bedingungen, um in den Software Planungs- The conditions to enter the software planning process
Prozess einzutreten, sind die Verfügbarkeit der ge- are the availability of approved and authorized process
nehmigten und autorisierten Prozess-Inputs, wie im inputs listed in workflow diagrams of chapter 3.
Prozessflussdiagramm des Kapitels 3 aufgeführt. The software planning process is complete when its
Der Software Planungs-Prozess ist vollständig durch- objectives are satisfied and approved by the perfor-
geführt, wenn seine Zielsetzungen erreicht und durch mance of the software Planning Process Review
das Software Planning Process Review (PPR) im Sta- (PPR) in status “green” or “amber” according to QG
tus „grün“ oder „gelb“ gemäß QG Ampelsteuerung der traffic light control of PB-EN-60.
PB-EN-60 genehmigt worden sind.

Anmerkung: Die Software-Pläne und Standards sollen Note: The software plans and standards shall be
vor dem Starten der Software Entwicklungs-Aktivitäten developed prior to enter any software development
erstellt werden. Einige Software Life Cycle Prozesse activities. Some software life cycle processes may
können vor Beendigung des Software Planungs- begin before completion of the software planning
Prozesses anfangen, wenn die Pläne und Standards process if the plans and standards for the specific
für die spezifischen Prozessaufgaben genehmigt und process activity are approved and authorized.
autorisiert sind.
Software Entwicklungs-Prozess-Abläufe PB-EN-32
Seite 16 von 36
Software Development-Process-Workflows Page 16 of 36
Ausgabe
10, 16 DEC 2021
Issue

4.2 Software Entwicklungs-Prozesse 4.2 Software Development Processes

Die Software Entwicklungs-Prozesse gliedern sich in The software development processes are divided into
die nachfolgenden Sub-Prozesse: the following sub-processes:
 Software Requirements-Prozess  software requirements process
 Software Design-Prozess  software design process
 Software Coding-Prozess  software coding process
 Integrations-Prozess  integration process

4.2.1 Software Requirements-Prozess 4.2.1 Software Requirements Process

Die Zielsetzung des Software Requirements- The objective of the software requirements process is
Prozesses ist die Entwicklung der Software High-Level to develop the software high-level requirements from
Requirements aus den softwarebezogenen System the system requirements of specification(s) on system
Requirements der Spezifikation(en) auf System oder or equipment level allocated to software and to indicate
Equipment Level und die Indikation der „derived“ Soft- the derived software high-level requirements to the
ware High-Level Requirements an den System Safety system safety assessment process.
Assessment Prozess.
Die Software High-Level Requirements sind innerhalb The software high-level requirements shall be docu-
der Software Requirements Data (SRD) zu dokumen- mented within the Software Requirements Data (SRD).
tieren.
Anmerkung: Die Software „derived“ High-Level Note: Software “derived” high-level requirements are
Requirements sind Bestandteil der Software High- included in the software high-level requirements. The
Level Requirements. Durch die Überstellung des SRD indication of the “derived” high-level requirements to
an den Kunden und/oder internem/externem the system safety assessment process is carried out
Fachbereich erfolgt die Indikation der „derived“ High- by SRD transfer to the customer and/or
Level Requirements an den System Safety internal/external department.
Assessment Prozess.

Die Entwicklung der Software High-Level Require- The software high-level requirements shall be
ments hat gemäß der Software Requirements Stan- developed in accordance with the Software
dards (SRS) und des Software Development Plan Requirements Standards (SRS) and the Software
(SDP) zu erfolgen. Development Plan (SDP).

Die Traceability zwischen den Software High-Level The traceability between software high-level require-
Requirements und System Requirements ist mittels ments and system requirements shall be provided into
einer Traceability Matrix gemäß der Software Requi- a traceability matrix in accordance with the Software
rements Standards (SRS) und des Software Develop- Requirements Standards (SRS) and the Software De-
ment Plan (SDP) darzustellen. velopment Plan (SDP).

Falls Parameter Data Items (PDIs) verwendet werden, If Parameter Data Items (PDIs) are used, they shall be
sind diese im Parameter Requirements Data (PRD) zu documented within a separate Parameter Require-
dokumentieren. ments Data (PRD) document.
Rollen, Inputs/Outputs und Aktivitäten Roles, Inputs/Outputs and Activities
Die grundsätzlichen Rollen und Zuständigkeiten sind in The fundamental roles and competencies are defined
Kapitel 2.3 definiert. in chapter 2.3.
Die prozessschritt-spezifischen Inputs/Outputs und The process-step specific inputs/outputs and activities
Aktivitäten sind im Prozessschritt (2) des Prozess- are defined in the process step (2) of workflow diagram
flussdiagramm für den Implementer in Kapitel for the implementer in chapter 3.1.
3.1definiert.
Software Entwicklungs-Prozess-Abläufe PB-EN-32
Seite 17 von 36
Software Development-Process-Workflows Page 17 of 36
Ausgabe
10, 16 DEC 2021
Issue

Transitions-Kriterien Transition Criteria


Die Bedingungen, um in den Software Requirements- The conditions to enter the software requirements
Prozess einzutreten, sind die Verfügbarkeit der ge- process are the availability of approved and authorized
nehmigten und autorisierten Prozess-Inputs, wie im process inputs listed in workflow diagram of
Prozessflussdiagramm des Kapitels 3.1 aufgeführt. chapter 3.1.
Der Software Requirements-Prozess ist vollständig The software requirements process is complete when
durchgeführt, wenn seine Zielsetzungen und die Ziel- its objectives and the objectives of the integral pro-
setzungen der zugehörigen integralen Prozesse erfüllt cesses associated with it are satisfied approved by the
und durch das Software Requirements Review (SRR) performance of the Software Requirements Review
im Status „grün“ oder „gelb“ gemäß QG Ampelsteue- (SRR) in status “green” or “amber” according to QG
rung der PB-EN-60 genehmigt worden sind. traffic light control of PB-EN-60.

4.2.2 Software Design-Prozess 4.2.2 Software Design Process

Die Zielsetzung des Software Design-Prozesses ist die The objective of the software design process is to de-
Entwicklung der Software Low-Level Requirements velop the software low-level requirements and software
und der Software Architektur aus den Software High- architecture from the software high-level requirements
Level Requirements des SRD und die Indikation der of SRD and to indicate the derived software low-level
„derived“ Software Low-Level Requirements an den requirements to the system safety assessment pro-
System Safety Assessment Prozess. cess.
Die Software Low-Level Requirements und die Soft- The software low-level requirements and software
ware Architektur sind innerhalb der Software Design architecture shall be documented within the Software
Description (SDD) zu dokumentieren. Design Description (SDD).

Anmerkung: Die Software „derived“ Low-Level Re- Note: Software “derived” low-level requirements are
quirements sind Bestandteil der Software Low-Level included in the software low-level requirements. The
Requirements. Durch die Überstellung des SDD an indication of the “derived” low-level requirements to the
den Kunden und/oder internem/externem Fachbereich system safety assessment process is carried out by
erfolgt die Indikation der „derived“ Low-Level Require- SDD transfer to the customer and/or internal/external
ments an den System Safety Assessment Prozess. department.

Die Entwicklung der Software Low-Level Requirements The software low-level requirements and software
und der Software Architektur hat gemäß der Software architecture shall be developed in accordance with the
Design Standards (SDS) und des Software Develop- Software Design Standards (SDS) and the Software
ment Plan (SDP) zu erfolgen. Development Plan (SDP).

Die Traceability zwischen den Software Low-Level The traceability between software low-level require-
Requirements und den Software High-Level Require- ments and software high-level requirements shall be
ments ist mittels einer Traceability Matrix gemäß der provided into a traceability matrix in accordance with
Software Design Standards (SDS) und des Software the Software Design Standards (SDS) and the Soft-
Development Plan (SDP) darzustellen. ware Development Plan (SDP).
Rollen, Inputs/Outputs und Aktivitäten Roles, Inputs/Outputs and Activities
Die grundsätzlichen Rollen und Zuständigkeiten sind in The fundamental roles and competencies are defined
Kapitel 2.3 definiert. in chapter 2.3.
Die prozessschritt-spezifischen Inputs/Outputs und The process-step specific inputs/outputs and activities
Aktivitäten sind im Prozessschritt (3) des Prozess- are defined in the process step (3) of workflow diagram
flussdiagramm für den Implementer in Kapitel 3.1 defi- for the implementer in chapter 3.1.
niert.
Software Entwicklungs-Prozess-Abläufe PB-EN-32
Seite 18 von 36
Software Development-Process-Workflows Page 18 of 36
Ausgabe
10, 16 DEC 2021
Issue

Transitions-Kriterien Transition Criteria


Die Bedingungen, um in den Software Design-Prozess The conditions to enter the software design process
einzutreten, sind die Verfügbarkeit der genehmigten are the availability of approved and authorized process
und autorisierten Prozess-Inputs, wie im Prozessfluss- inputs listed in workflow diagram of chapter 3.1.
diagramm des Kapitels 3.1 aufgeführt.
Der Software Design-Prozess ist vollständig durchge- The software design process is complete when its
führt, wenn seine Zielsetzungen und die Zielsetzun- objectives and the objectives of the integral processes
gen der zugehörigen integralen Prozesse erfüllt und associated with it are satisfied approved by the per-
durch das Software Design Review (SDR) im Status formance of the Software Design Review (SDR) in
„grün“ oder „gelb“ gemäß QG Ampelsteuerung der status “green” or “amber” according to QG traffic light
PB-EN-60 genehmigt worden sind. control of PB-EN-60.

4.2.3 Software Coding-Prozess 4.2.3 Software Coding Process

Die Zielsetzung des Software Coding-Prozesses ist die The objective of the software coding process is to de-
Entwicklung des Source Code, der die Software Low- velop the source code that implements the software
Level Requirements und die Software Architektur des low-level requirements and software architecture of
SDD implementiert. SDD.
Die Entwicklung des Source Code hat gemäß der The source code shall be developed in accordance
Software Code Standards (SCS) und des Software with the Software Code Standards (SCS) and the
Development Plan (SDP) zu erfolgen. Software Development Plan (SDP).

Die Traceability zwischen dem Source Code und den The traceability between source code and software
Software Low-Level Requirements ist mittels einer low-level requirements shall be provided into a tracea-
Traceability Matrix gemäß der Software Code Stan- bility matrix in accordance with the Software Code
dards (SCS) und des Software Development Plan Standards (SCS) and the Software Development Plan
(SDP) darzustellen. (SDP).
Rollen, Inputs/Outputs und Aktivitäten Roles, Inputs/Outputs and Activities
Die grundsätzlichen Rollen und Zuständigkeiten sind in The fundamental roles and competencies are defined
Kapitel 2.3 definiert. in chapter 2.3.
Die prozessschritt-spezifischen Inputs/Outputs und The process-step specific inputs/outputs and activities
Aktivitäten sind im Prozessschritt (4) des Prozess- are defined in the process step (4) of workflow diagram
flussdiagramm für den Implementer in Kapitel 3.1 defi- for the implementer in chapter 3.1.
niert.

Transitions-Kriterien Transition Criteria


Generell sind die Bedingungen, um in den Software Normally, the conditions to enter the software coding
Coding-Prozess einzutreten, die Verfügbarkeit der process are the availability of approved and authorized
genehmigten und autorisierten Prozess-Inputs, wie im process inputs listed in workflow diagram of chapter
Prozessflussdiagramm des Kapitels 3.1 aufgeführt, 3.1, considering the following restriction.
allerdings mit folgender Einschränkung.
Die Software Design Description (SDD) muss nicht The Software Design Description (SDD) does not need
komplett vollendet sein, um den Software Coding- to be finished completely in order to enter the software
Process beginnen zu können. Die Software Low-Level coding process. The software low-level requirements
Requirements und die Software Architektur müssen als and software architecture as input for the respective
Eingang für den jeweilig zu erstellenden Source Code source code section associated with it must be devel-
Abschnitt, entwickelt und verifiziert sein. oped and verified.
Der Software Coding-Prozess ist vollständig durchge- The software coding process is complete when its
führt, wenn seine Zielsetzungen und die Zielsetzungen objectives and the objectives of the integral processes
der zugehörigen integralen Prozesse erfüllt sind. associated with it are satisfied.
Software Entwicklungs-Prozess-Abläufe PB-EN-32
Seite 19 von 36
Software Development-Process-Workflows Page 19 of 36
Ausgabe
10, 16 DEC 2021
Issue

4.2.4 Integrations-Prozess 4.2.4 Integration Process

Die Zielsetzung des Integrations-Prozesses ist die The objective of the integration process is to generate
Generierung des Executable Object Codes, der Para- the executable object code, the parameter data item
meter Data Item Dateien und den Linking und Loading files and linking and loading data respective to load the
Daten, sowie das Laden des Executable Object Codes executable object code and parameter data item files
und der Parameter Data Item Dateien in die Zielhard- into the target hardware for HW/SW integration pur-
ware zu HW/SW Integrationszwecken. pose.
Die Generierung des Executable Object Code und der The executable object code and parameter data item
Parameter Data Item Files hat gemäß der Software files shall be generated in accordance with the Soft-
Code Standards (SCS) respektive der Software ware Code Standards (SCS) respective Software Re-
Requirements Standards (SRS) und des Software quirements Standards (SRS) and the Software Devel-
Development Plan (SDP) zu erfolgen. opment Plan (SDP).

Rollen, Inputs/Outputs und Aktivitäten Roles, Inputs/Outputs and Activities


Die grundsätzlichen Rollen und Zuständigkeiten sind in The fundamental roles and competencies are defined
Kapitel 2.3 definiert. in chapter 2.3.
Die prozessschritt-spezifischen Inputs/Outputs und The process-step specific inputs/outputs and activities
Aktivitäten sind im Prozessschritt (5) des Prozess- are defined in the process step (5) of workflow diagram
flussdiagramm für den Implementer in Kapitel 3.1 defi- for the implementer in chapter 3.1.
niert.

Transitions-Kriterien Transition Criteria


Die Bedingungen, um in den Integrations-Prozess The conditions to enter the integration process are the
einzutreten, sind die Verfügbarkeit der genehmigten availability of approved and authorized process inputs
und autorisierten Prozess-Inputs wie im Prozessfluss listed in workflow diagram of chapter 3.1.
des Kapitels 3.1 aufgeführt.
Der Integrations-Prozess ist vollständig durchgeführt, The integration process is complete when its objec-
wenn seine Zielsetzungen und die Zielsetzungen der tives and the objectives of the integral processes as-
zugehörigen integralen Prozesse erfüllt und durch das sociated with it are satisfied approved by the perfor-
Software Test Readiness Review (STRR) im Status mance of the Software Test Readiness Review
„grün“ oder „gelb“ gemäß QG Ampelsteuerung der (STRR) in status “green” or “amber” according to QG
PB-EN-60 genehmigt worden sind. traffic light control of PB-EN-60.

4.3 Integrale Prozesse 4.3 Integral Processes

Folgende integrale Prozesse sind definiert: Following integral processes are defined:
 Software Verifikations-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

4.3.1 Software Verifikations-Prozess 4.3.1 Software Verification Process

Die Zielsetzung des Software Verifikations-Prozesses The objective of the software verification process is to
ist die Detektion und das Berichten von Fehlern die detect and report errors that may have been
potentiell während der Software Entwicklungs- introduced during both the software development
Prozesse und des Software Verifikation-Prozess selbst processes and the software verification process.
auftreten können.
Der Software Verifikations-Prozess beinhaltet dabei The software verification process include the following
die folgenden Prozessschritte: process step:
Software Entwicklungs-Prozess-Abläufe PB-EN-32
Seite 20 von 36
Software Development-Process-Workflows Page 20 of 36
Ausgabe
10, 16 DEC 2021
Issue

 Verifikation der Outputs des Software Require-  Verification of outputs of software requirements
ments-Prozess process
 Verifikation der Outputs des Software Design-  Verification of outputs of software design process
Prozess
 Verifikation der Outputs des Software Coding-  Verification of outputs of software coding process
Prozess
 Verifikation der Outputs des Integrations-Prozess  Verification of outputs of integration process
 Testen der Outputs des Integrations-Prozess  Testing of outputs of integration process
 Verifikation der Verifikations-Prozess Ergebnisse  Verification of verification process results as integral
als integrale Prozessschritte process steps

Die Prozessschritte sind in den folgenden Kapiteln The process steps are detailed in the following chap-
detailliert. ters.

Rollen, Inputs/Outputs und Aktivitäten Roles, Inputs/Outputs and Activities


Die grundsätzlichen Rollen und Zuständigkeiten sind in The fundamental roles and competencies are defined
Kapitel 2.3 definiert. in chapter 2.3.
Die prozessschritt-spezifischen Inputs/Outputs und The process-step specific inputs/outputs and activities
Aktivitäten sind in den Prozessschritten (2-6) des Pro- are defined in the process steps (2-6) of workflow dia-
zessflussdiagramm für den Verifier in Kapitel 0 defi- gram for the verifier in chapter 0.
niert.
Transitions-Kriterien Transition Criteria
Die Bedingungen, um in den Software Verifikations- The conditions to enter the software verification pro-
Prozess einzutreten, sind die Verfügbarkeit der Pro- cess are the availability of process inputs listed in
zess-Inputs, wie im Prozessflussdiagramm des Kapi- workflow diagram of chapter 3.2.
tels 3.2 aufgeführt.
Der Software Verifikations-Prozess ist vollständig The software verification process is complete when its
durchgeführt, wenn seine Zielsetzungen und die Ziel- objectives and the objectives of the integral processes
setzungen der zugehörigen integralen Prozesse erfüllt associated with it are satisfied and approved by the
und durch die Reviews, abgebildet im Prozessflussdi- performance of the associated reviews, as shown in
agramm des Kapitels 3.2, im Status „grün“ oder „gelb“ workflow diagram of chapter 3.2, in status “green” or
gemäß QG Ampelsteuerung der PB-EN-60 genehmigt “amber” according to QG traffic light control of
worden sind. PB-EN-60.
Software Entwicklungs-Prozess-Abläufe PB-EN-32
Seite 21 von 36
Software Development-Process-Workflows Page 21 of 36
Ausgabe
10, 16 DEC 2021
Issue

4.3.1.1 Verifikation der Outputs des Software Re- 4.3.1.1 Verification of outputs of software require-
quirements-Prozess ments process

Die Zielsetzung der Verifikation des Outputs des Soft- The objective of the verification of outputs of software
ware Requirements-Prozess ist zu überprüfen, dass requirements process is to verify that the system re-
die softwarebezogenen System Requirements in Soft- quirements allocated to software have been developed
ware High-Level Requirements entwickelt wurden und into software high-level requirements that satisfy those
diese die System Requirements auch erfüllen respekti- system requirements respective to verify the compli-
ve die Übereinstimmung mit den Software Require- ance with Software Requirement Standards (SRS) and
ment Standards (SRS) und des Software Development Software Development Plan (SDP).
Plan (SDP) sicher zu stellen.
Die Verifikation ist mittels Review und Analyse Aktivitä- The verification shall be done via review and analysis
ten gemäß des Software Verification Plan (SVP; inklu- activities according to Software Verification Plan (SVP;
sive Checkliste) respektive der Software Verification inclusive checklist) respective Software Verification
Cases and Procedures (SVCP) durchzuführen. Vorher Cases and Procedures (SVCP). Prior to that the SVCP
sind die im SVP beschriebenen Review und Analyse shall be developed providing details, supplementary to
Methoden hinsichtlich des Geltungsbereiches und der the description in the SVP, which describes the scope
Tiefe im SVCP zu erweitern. Die Review und Analyse and depth of the review and analysis methods to be
Ergebnisse sind in den Software Verification Results used. The review and analysis result shall be docu-
(SVR) zu dokumentieren. mented into the Software Verification Results (SVR).

Wenn Parameter Data Items (PDIs) verwendet werden If Parameter Data Items (PDIs) are used, the Parame-
müssen die Parameter Requirement Data (PRD) ent- ter Requirement Data (PRD) shall be verified accord-
sprechend des Software Verification Plan (SVP) res- ing to Software Verification Plan (SVP) respective the
pektive den Parameter Verification Cases and Proce- Parameter Verification Cases and Procedures (PVCP).
dures (PVCP) verifiziert werden.

Während dieses Prozessschrittes (2) sind die Software During this process step (2) the software high-level
High-Level Requirements basierten Testfälle und Pro- requirements based test cases / procedures shall be
zeduren gemäß des SVP zu entwickeln und im SVCP developed according to the SVP and documented with-
zu dokumentieren. in the SVCP.
Die Verifikation dieser Software High-Level Require- The verification of these software high-level require-
ments basierten Testfälle und Prozeduren, sowie die ments based test cases and procedures as well as the
dazugehörige Requirements basierte Test Coverage associated requirements-based test coverage analysis
Analyse erfolgt gemäß Kapitel 4.3.1.6 Verifikation der shall be performed according to chapter 4.3.1.6 Verifi-
Verifikations-Prozess Ergebnisse. cation of verification process results.
Software Entwicklungs-Prozess-Abläufe PB-EN-32
Seite 22 von 36
Software Development-Process-Workflows Page 22 of 36
Ausgabe
10, 16 DEC 2021
Issue

4.3.1.2 Verifikation der Outputs des Software De- 4.3.1.2 Verification of outputs of software design
sign-Prozess process

Die Zielsetzung der Verifikation des Outputs des Soft- The objective of the verification of outputs of software
ware Design-Prozess ist zu überprüfen, dass die Soft- design process is to verify that the software high-level
ware High-Level Requirements in die Software Archi- requirements have been developed into software archi-
tektur und Software Low-Level Requirements entwi- tecture and software low-level requirements that satisfy
ckelt wurden und diese die Software High-Level Requi- the software high-level requirements respective to
rements auch erfüllen respektive die Übereinstimmung verify the compliance with Software Design Standards
mit den Software Design Standards (SDS) und des (SDS) and Software Development Plan (SDP).
Software Development Plan (SDP) sicher zu stellen.

Die Verifikation ist mittels Review und Analyse Aktivitä- The verification shall be done via review and analysis
ten gemäß des Software Verification Plan (SVP; inklu- activities according to Software Verification Plan (SVP;
sive Checkliste) respektive der Software Verification inclusive checklist) respective Software Verification
Cases and Procedures (SVCP) durchzuführen. Vorher Cases and Procedures (SVCP). Prior to that the
sind die im SVP beschriebenen Review und Analyse SVCP shall be developed providing details,
Methoden hinsichtlich des Geltungsbereiches und der supplementary to the description in the SVP, which
Tiefe im SVCP zu erweitern. Die Review und Analyse describes the scope and depth of the review and
Ergebnisse sind in den Software Verification Results analysis methods to be used. The review and analysis
(SVR) zu dokumentieren. result shall be documented into the Software
Verification Results (SVR).
Während dieses Prozessschrittes (3) sind die Software During this process step (3) the software low-level
Low-Level Requirements basierten Testfälle und Pro- requirements based test cases / procedures shall be
zeduren gemäß des SVP zu entwickeln und im SVCP developed according to the SVP and documented into
zu dokumentieren. the SVCP.
Die Verifikation dieser Software Low-Level Require- The verification of these software low-level require-
ments basierten Testfälle und Prozeduren, sowie die ments based test cases and procedures as well as the
dazugehörige Requirements basierte Test Coverage associated requirements-based test coverage analysis
Analyse erfolgt gemäß Kapitel 4.3.1.6 Verifikation der shall be performed according to chapter 4.3.1.6 Verifi-
Verifikations-Prozess Ergebnisse. cation of verification process results.

4.3.1.3 Verifikation der Outputs des Software 4.3.1.3 Verification of outputs of software coding
Coding-Prozess process

Die Zielsetzung der Verifikation des Outputs des Soft- The objective of the verification of the outputs of soft-
ware Coding-Prozess ist zu überprüfen, dass die Soft- ware coding process is to verify that the software archi-
ware Architektur und Software Low-Level Require- tecture and software low-level requirements have been
ments in den Source Code entwickelt wurden und die- developed into source code that satisfies the software
ser die Software Architektur und Software Low-Level architecture and software low-level requirements re-
Requirements auch erfüllt respektive die Übereinstim- spective to verify the compliance with Software Code
mung mit den Software Code Standards (SCS) und Standards (SCS) and Software Development Plan
des Software Development Plan (SDP) sicher zu stel- (SDP).
len.
Die Verifikation ist mittels Review und Analyse Aktivitä- The verification shall be done via review and analysis
ten gemäß des Software Verification Plan (SVP; inklu- activities according to Software Verification Plan (SVP;
sive Checkliste) respektive der Software Verification inclusive checklist) respective Software Verification
Cases and Procedures (SVCP) durchzuführen. Vorher Cases and Procedures (SVCP). Prior to that the
sind die im SVP beschriebenen Review und Analyse SVCP shall be developed providing details,
Methoden hinsichtlich des Geltungsbereiches und der supplementary to the description in the SVP, which
Tiefe im SVCP zu erweitern. Die Review und Analyse describes the scope and depth of the review and
Ergebnisse sind in den Software Verification Results analysis methods to be used. The review and analysis
(SVR) zu dokumentieren. result shall be documented into the Software
Verification Results (SVR).
Software Entwicklungs-Prozess-Abläufe PB-EN-32
Seite 23 von 36
Software Development-Process-Workflows Page 23 of 36
Ausgabe
10, 16 DEC 2021
Issue

4.3.1.4 Verifikation der Outputs des Integrations- 4.3.1.4 Verification of outputs of integration pro-
Prozess cess

Die Zielsetzung der Verifikation des Outputs des Integ- The objective of the verification of outputs of
rations-Prozess ist die Generierung des Executable integration process is to verify the generation of the
Object Codes und der Parameter Data Item Files zu executable object code and parameter data item files
überprüfen sowie die Übereinstimmung mit den Soft- as well as to verify the compliance with Software Code
ware Code Standards (SCS) respektive Software Re- Standards (SCS) respective Software Requirements
quirements Standards (SRS) und des Software Deve- Standards (SRS) and Software Development Plan
lopment Plan (SDP) sicher zu stellen. (SDP).
Die Verifikation ist mittels Review und Analyse Aktivitä- The verification shall be done via review and analysis
ten gemäß des Software Verification Plan (SVP; inklu- activities according to Software Verification Plan (SVP;
sive Checkliste) respektive der Software Verification inclusive checklist) respective Software Verification
Cases and Procedures (SVCP) / PDI Verification Cases and Procedures (SVCP) / PDI Verification
Cases and Procedures (PVCP) durchzuführen. Vorher Cases and Procedures (PVCP). Prior to that the
sind die im SVP beschriebenen Review und Analyse SVCP/PVCP shall be developed providing details,
Methoden hinsichtlich des Geltungsbereiches und der supplementary to the description in the SVP, which
Tiefe im SVCP/PVCP zu erweitern. Die Review und describes the scope and depth of the review and
Analyse Ergebnisse sind in den Software Verification analysis methods to be used. The review and analysis
Results (SVR, für PDIs im PAS) zu dokumentieren. result shall be documented into the Software
Verification Results (SVR, for PDIs in PAS).

4.3.1.5 Testen der Outputs des Integrations- 4.3.1.5 Testing of outputs of integration process
Prozess

Die Zielsetzung des Testens des Outputs des Integra- The objective of the testing of outputs of integration
tions-Prozess ist die Demonstration, dass die Software process is to demonstrate that the software satisfies its
ihre Requirements erfüllt und mit hohem Maß sicher zu requirements and to demonstrate with a high degree of
stellen, dass Fehler mit nicht akzeptablen Auswirkun- confidence that errors which could lead to unaccepta-
gen entfernt worden sind. ble failure conditions have been removed.
Die Verifikation ist mittels Hardware/Software Integra- The verification shall be done via hardware/software
tions-Tests, Software Integrations-Tests und Low- integration testing, software integration testing and
Level-Tests gemäß des Software Verification Plan low-level testing according to Software Verification
(SVP) respektive der Software Verification Cases and Plan (SVP) respective Software Verification Cases and
Procedures (SVCP) / PDI Verification Cases and Pro- Procedures (SVCP) / PDI Verification Cases and Pro-
cedures (PVCP), welches die vordefinierten Testfälle cedures (PVCP); including the predefined test cases /
und Prozeduren beinhaltet, durchzuführen. Die Test- procedures. The testing results shall be documented
Ergebnisse sind in den Software Verification Results into the Software Verification Results (SVR, for PDIs in
(SVR, für PDIs im PAS) zu dokumentieren. PAS).
Die Verifikation der Testergebnisse, sowie die dazuge- The verification of the test results as well as the asso-
hörige Structural Coverage Analyse erfolgt gemäß ciated structural coverage analysis shall be performed
Kapitel 4.3.1.6 Verifikation der Verifikations-Prozess according to chapter 4.3.1.6 Verification of verification
Ergebnisse. process results.

Anmerkung: Note:
Gemäß 21.A.33 (b) (c) und AMC 21.A.33 muss vor As per 21.A.33(b)(c) and AMC 21.A.33, before any
Durchführung eines jeden Compliance Test festgestellt compliance test is undertaken it shall be determined as
werden, dass der Prüfling und die Prüfumgebung für a precondition that the test specimen and the test envi-
eine bestimmte Prüfung geeignet sind. Die Konformi- ronment are adequate for a particular test. The con-
tätsprüfung des Prüflings & Prüfumgebung wird durch- formity inspection of the test specimen & test en-
geführt und das Ergebnis als Konformitätserklärung vironment is performed and the result as a statement
dokumentiert innerhalb des Berichts ‚Konformitätser- of conformity documented within the ‘Report Con-
klärung für Prüfling / Umgebung (RCS)‘. formity Statement for Test Specimen / Environment
(RCS)’.
Software Entwicklungs-Prozess-Abläufe PB-EN-32
Seite 24 von 36
Software Development-Process-Workflows Page 24 of 36
Ausgabe
10, 16 DEC 2021
Issue

4.3.1.6 Verifikation der Verifikations-Prozess Er- 4.3.1.6 Verification of verification process results
gebnisse

Die Zielsetzung der Verifikation der Verifikations- The objective of the verification of verification process
Prozess Ergebnisse ist es sicherzustellen, dass die results is to ensure that the software testing was de-
Software Tests fehlerfrei und komplett entwickelt res- veloped and performed accurately and completely;
pektive durchgeführt worden sind; inklusive der Bestä- including the confirmation of the test coverage analy-
tigung der Test Coverage Analyse. sis.
Die Verifikation ist mittels Review und Analyse Aktivitä- The verification shall be done via review and analysis
ten gemäß des Software Verification Plan (SVP; inklu- activities according to Software Verification Plan (SVP;
sive Checkliste) respektive der Software Verification inclusive checklist) respective Software Verification
Cases and Procedures (SVCP) durchzuführen. Vorher Cases and Procedures (SVCP). Prior to that the
sind die im SVP beschriebenen Review und Analyse SVCP shall be developed providing details, supple-
Methoden hinsichtlich des Geltungsbereiches und der mentary to the description in the SVP, which describes
Tiefe im SVCP zu erweitern. Die Review und Analyse the scope and depth of the review and analysis meth-
Ergebnisse sind in den Software Verification Results ods to be used. The review and analysis result shall be
(SVR) zu dokumentieren. documented into the Software Verification Results
(SVR).

4.3.2 Software Configuration-Management-Prozess 4.3.2 Software Configuration Management Process

Der Zielsetzung des SCM Prozesses ist die Konfigura- The objectives of the SCM process is the configuration
tionskontrolle der Software Life Cycle Daten über den control of the software life cycle data throughout the
kompletten Software Life Cycle; dieses beinhaltet: software life cycle; including:

 Configuration Identification  configuration identification


 Baseline und Traceability  baseline and traceability
 Problem Reporting, Tracking und Corrective Action  problem reporting, tracking and corrective action
 Change Control  change control
 Change Review  change review
 Configuration Status Accounting  configuration status accounting
 Archive, Retrieval and Release  archive, retrieval and release
 Software Load Control  software load control
 Software Life Cycle Environment Control  software life cycle environment control

Die SCM Aktivitäten sind gemäß des Software Confi- The SCM activities shall be performed according to
guration Management Plan (SCMP) durchzuführen. Software Configuration Management Plan (SCMP).
Die Ergebnisse der SCM Aktivitäten sowie die Einhal- The SCM activity results and the compliance of the
tung der SCM Aktivitäten gemäß des SCMP sind im SCM activities to the SCMP shall be documented into
Software Configuration Management Record (SCMR) the Software Configuration Management Record
zu dokumentieren. (SCMR).

Rollen, Inputs/Outputs und Aktivitäten Roles, Inputs/Outputs and Activities


Die grundsätzlichen Rollen und Zuständigkeiten sind in The fundamental roles and competencies are defined
Kapitel 2.3 definiert. in chapter 2.3.
Die prozessschritt-spezifischen Inputs/Outputs und The process-step specific inputs/outputs and activities
Aktivitäten sind in den Prozessschritten (2-6) des Pro- are defined in the process steps (2-6) of workflow
zessflussdiagramm für den Configuration Manager diagram for the Configuration Manager (CM) in chap-
(CM) in Kapitel 3.3 definiert. ter 3.3.
Software Entwicklungs-Prozess-Abläufe PB-EN-32
Seite 25 von 36
Software Development-Process-Workflows Page 25 of 36
Ausgabe
10, 16 DEC 2021
Issue

Transitions-Kriterien Transition Criteria


Die Bedingungen, um den Software Configuration- The conditions to enter the software configuration
Management-Prozess einzutreten, sind die Verfügbar- management process are the availability of approved
keit der genehmigten und autorisierten Prozess-Inputs, and authorized process inputs listed in workflow dia-
wie im Prozessflussdiagramm des Kapitels 3.3 aufge- gram of chapter 3.3.
führt.
Der Software Configuration-Management-Prozess ist The software configuration management process is
vollständig durchgeführt, wenn seine Zielsetzungen complete when its objectives are satisfied approved by
erfüllt und durch die Reviews, abgebildet im Prozess- the performance of the associated reviews, as shown
flussdiagramm des Kapitels 3.3, im Status „grün“ oder in workflow of chapter 3.3, in status “green” or “amber”
„gelb“ gemäß QG Ampelsteuerung der PB-EN-60 ge- according to QG traffic light control of PB-EN-60.
nehmigt worden sind.

4.3.3 Software Quality-Assurance-Prozess 4.3.3 Software Quality Assurance Process

Die Zielsetzung des Software Quality-Assurance- The objective of the software quality assurance pro-
Prozesses ist es die Software Life Cycle Prozesse und cess is to assess the software life cycle processes and
deren Outputs zu bewerten, um die Gewährleistung zu their outputs to obtain assurance that the objectives
erhalten, dass die Zielsetzungen erfüllt sind, dass die are satisfied, that deficiencies are detected, evaluated,
Abweichungen ermittelt, ausgewertet, verfolgt und tracked and resolved. Further to provide confidence
gelöst werden. Des Weiteren Vertrauen zu erzeugen, that the software life cycle processes produce software
dass die Software Life Cycle Prozesse Software Life life cycle data (inclusive software product) that con-
Cycle Daten (inklusive des Software Produktes) pro- forms to its requirements by assuring that these pro-
duzieren, welche ihren Anforderungen genügen, indem cesses are performed in compliance with the approved
sichergestellt wird, dass diese Prozesse mit den ge- and authorized software plans and standards.
nehmigten und autorisierten Software Plänen und
Standards übereinstimmen.
Die Software Quality Assurance Aktivitäten sind ge- The software quality assurance activities shall be per-
mäß des Software Quality Assurance Plan (SQAP) formed according to the Software Quality Assurance
durchzuführen. Die Ergebnisse der SQA Aktivitäten Plan (SQAP). The SQA activity results and the compli-
sowie die Einhaltung der SQA Aktivitäten gemäß des ance of the SQA activities to the SQAP shall be docu-
SQAP sind im Software Quality Assurance Record mented into the Software Quality Assurance Record
(SQAR) zu dokumentieren. (SQAR).

Rollen, Inputs/Outputs und Aktivitäten Roles, Inputs/Outputs and Activities


Die grundsätzlichen Rollen und Zuständigkeiten sind in The fundamental roles and competencies are defined
Kapitel 2.3 definiert. in chapter 2.3.
Die prozessschritt-spezifischen Inputs/Outputs und The process-step specific inputs/outputs and activities
Aktivitäten sind in den Prozessschritten (2-6) des Pro- are defined in the process steps (2-6) of workflow dia-
zessflussdiagramm für die Quality Assurance (QA) in gram for the Quality Assurance (QA) in chapter 3.4.
Kapitel 3.4 definiert.

Transitions-Kriterien Transition Criteria


Die Bedingungen, um in den Software Quality- The conditions to enter the software quality assurance
Assurance-Prozess einzutreten, sind die Verfügbarkeit process are the availability of process inputs listed in
der Prozess-Inputs, wie im Prozessflussdiagramm des workflow diagram of chapter 3.4.
Kapitels 3.4 aufgeführt.
Der Software Quality-Assurance-Prozess ist vollstän- The software quality assurance process is complete
dig durchgeführt, wenn seine Zielsetzungen erfüllt und when its objectives are satisfied approved by the per-
durch die Reviews, abgebildet im Prozessflussdia- formance of the associated reviews, as shown in work-
gramm des Kapitels 3.4, im Status „grün“ oder „gelb“ flow diagram of chapter 3.4, in status “green” or “am-
gemäß QG Ampelsteuerung der PB-EN-60 genehmigt ber” according to QG traffic light control of PB-EN-60.
worden sind.
Software Entwicklungs-Prozess-Abläufe PB-EN-32
Seite 26 von 36
Software Development-Process-Workflows Page 26 of 36
Ausgabe
10, 16 DEC 2021
Issue

4.3.3.1 Quality-Gates Tätigkeiten 4.3.3.1 Quality Gates Activities

Quality Gates (z.B. Software Requirements Review) Quality gates (e.g. software requirement review) shall
sind während des gesamten Software Life Cycle be carried out throughout the software life cycle to
durchzuführen, um sicherzustellen, dass die entwickel- ensure that the software life cycle data (inclusive soft-
ten Software Life Cycle Daten (inklusive des Software ware product) being developed satisfy its requirements
Produktes) ihre Anforderungen in entsprechender of acceptable quality and the software life cycle pro-
Qualität erfüllen und dass der Software Life Cycle Pro- cess is performed in compliance with the software
zess gemäß der Software Pläne und Standards durch- plans and standards.
geführt wurde.
Diese Quality Gates schließen eine entsprechende These quality gates shall finish the associated process
Prozessphase ab und genehmigten den Eintritt in die phase and grant access for the following process
folgende Prozessphase. Die nachfolgende Quality phase. The following quality gates shall be performed:
Gates sind auszuführen:

Initiale Softwareentwicklung: Initial software development:

 Planning Process Review (PPR)  Planning Process Review (PPR)


 Software Requirements Review (SRR)  Software Requirements Review (SRR)
 Software Design Review (SDR)  Software Design Review (SDR)
 Software Test Readiness Review (STRR)  Software Test Readiness Review (STRR)
 Software Conformity Review (SCR)  Software Conformity Review (SCR)
 First Delivery Review (FDR)  First Delivery Review (FDR)
 First Flight Review (FFR)  First Flight Review (FFR)
 Compliance Review for Certification (CRC)  Compliance Review for Certification (CRC)
 Delivery Review (DR) for Software Level E  Delivery Review (DR) for software level E
 Production Release Review (PRL)  Production Release Review (PRL)

Entwicklung einer Softwareänderung: Development of a software change:

 Status Review (SR)  Status Review (SR)


 Software Conformity Review (SCR)  Software Conformity Review (SCR)
 Compliance Review for Change Certification  Compliance Review for Change Certification
(CRcC) (CRcC)
 Delivery Review (DR) for Software Level E  Delivery Review (DR) for Software Level E
 Production Release Review (PRL)  Production Release Review (PRL)

Anmerkung: Gemäß der ABD0100.2.4 Kapitel 3.3.6.5 Note: According to ABD0100.2.4 chapter 3.3.6.5
„Schedule of DR for software level E“ soll dieses Re- “Schedule of DR for software level E” this review shall
view vor einer Auslieferung durchgeführt werden, min- be held before a delivery of the equipment, at least
destens vor einer Auslieferung der ersten Version, die before delivery of the first version that shall be applied
für den „In Service“ Betrieb vorgesehen ist. Die Not- in service. The need to repeat this activity on other
wendigkeit der Wiederholung des Reviews für weitere flyable baselines will be considered depending on the
fliegende Baselines hängt vom Fertigstellungsgrad und status of completion of the activities and the im-
der Art der Änderung ab. Dennoch hat die QA hat für portance of the change. However, QA shall assure that
jede fliegende Baseline sicherzustellen, dass ausrei- sufficient verification and assurance activities have
chende Verifikations- und Quality Assurance Aktivitä- been performed on any flyable baseline.
ten durchgeführt worden sind.

4.3.4 Certification-Liaison-Prozess 4.3.4 Certification Liaison Process

Die Zielsetzung des Certification-Liaison-Prozesses ist The objective of the certification liaison process is to
die Kommunikation und Abstimmung mit den zuständi- establish communication and understanding with the
gen Zulassungsdienststellen, um die Zulassung zu competent certification authorities to assist the certifi-
unterstützen. cation process.
Software Entwicklungs-Prozess-Abläufe PB-EN-32
Seite 27 von 36
Software Development-Process-Workflows Page 27 of 36
Ausgabe
10, 16 DEC 2021
Issue

Anmerkung: Zuständige Zulassungsdienststellen kön- Note: For instance, competent certification authorities
nen beispielsweise Behörden, wie die EASA, oder might be either an agency like the EASA or an EASA
auch EASA zugelassene Design Organisationen sein. approved Design Organization.

Während des Certification-Liaison-Prozesses wird der In the certification liaison process the Plan for Software
Plan for Software Aspects of Certification (PSAC), und Aspects of Certification (PSAC) and other requested
weitere angeforderte Daten, an die zuständige Zulas- data are submitted to the competent certification
sungsdienststellen zum Review überstellt. Anmerkun- authorities for review purpose. Issues identified by the
gen seitens der Zulassungsdienststellen sind entspre- certification authorities shall be resolved accordingly to
chend zu korrigieren, um abschließend eine Einigung obtain an agreement on the PSAC.
hinsichtlich des PSAC zu erhalten.

Das Software Accomplishment Summary (SAS) ist zu The Software Accomplishment Summary (SAS) shall
erstellen, um die Übereinstimmung des Software Life be established to provide evidence that the software
Cycle und Daten mit den Software Plänen und Stan- life cycle processes and data satisfy the software plans
dards zu bestätigen. Alle Abweichungen zum abge- and standards. Any differences to the agreed PSAC
stimmten PSAC sind entsprechend im SAS auszuwei- shall be described in the SAS.
sen.
Der Software Configuration Index (SCI) ist zu erstellen, The Software Configuration Index (SCI) shall be estab-
um die Software Produkt- und Software Life Cycle lished to define the software product and software life
Daten Baseline zu definieren. cycle data baseline.
Wenn PDIs verwendet werden, ist zusätzlich ein Pa- If PDIs are used, additionally a Parameter Data Item
rameter Data Item Accomplishment Summary (PAS) Accomplishment Summary (PAS) shall be established.
zu erstellen. Dieser beinhaltet für die PDIs sowohl alle The PAS contains all relevant SAS and SCI aspects
SAS als auch SCI relevanten Aspekte. for the PDIs.
SAS, SCI (ggf. PAS) und weiter angeforderte Daten SAS, SCI (PAS if applicable) and other requested data
werden an die zuständigen Zulassungsdienststellen are submitted to the competent certification authorities
zum Review überstellt. Anmerkungen seitens der Zu- for review purpose. Issues identified by the certification
lassungsdienststellen sind entsprechend zu korrigie- authorities shall be resolved accordingly.
ren.

Für Airbus interne Zwecke ist die Declaration of Design For Airbus internal purpose the Declaration of Design
and Performance (DDP) zum FDR, FFR und and Performance (DDP) shall be established and de-
CRC/DR/CRcC zu erstellen und an den Kunden livered to the customer and/or internal/external de-
und/oder internem/externem Fachbereich auszuliefern, partment at the FDR, FFR and CRC/DR/CRcC if the
wenn das Software Produkt gemäß PB-EN-61 als LRU software product is declared as LRU FLS according to
FLS deklariert ist. Ansonsten erfolgt das über den PB-EN-61. Otherwise it is performed via the Equip-
Equipment Entwicklungs-Prozess gemäß PB-EN-30. ment Development-Process according to PB-EN-30.

Des Weiteren ist in dieser Prozessphase die Schnitt- Further, this process phase includes the definition of
stelle zu den internen System Test gemäß PB-EN-40 interface to the internal system test according to
definiert. PB-EN-40.
Die an den internen System Test zu transferierende The software to be transferred to internal system test
Software ist gemäß des Intermediate Standards, defi- shall be documented according to Intermediate Stand-
niert in ABD0100.2.4; im speziellen Kapitel 4 ard defined in ABD0100.2.4; especially chapter 4
„Documents to be Delivered with Each Intermediate „Documents to be Delivered with Each Intermediate
Standard“, zu dokumentieren. Dafür ist kein spezifi- Standard“. Therefore no specific software life cycle
sches Software Life Cycle Dokument vorgeschrieben. data is defined. The ETemp-451 “SW delivery descrip-
Das ETemp-451 „SW Delivery Description for Interme- tion for intermediate standards” shall be used for doc-
diate Standards“ ist zu Dokumentationszwecken zu umentation purpose.
verwenden.
Rollen, Inputs/Outputs und Aktivitäten Roles, Inputs/Outputs and Activities
Die grundsätzlichen Rollen und Zuständigkeiten sind in The fundamental roles and competencies are defined
Kapitel 2.3 definiert. 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 The process-step specific inputs/outputs and activities
Aktivitäten sind rollenorientiert im Prozessschritt (6) are defined related to the roles in the process step (6)
der Prozessflussdiagramme aus Kapitel 3 definiert. of workflow diagrams in chapter 3.
Transitions-Kriterien Transition Criteria
Die Bedingungen, um in den Certification-Liaison- The conditions to enter the certification liaison process
Prozess einzutreten, sind die Verfügbarkeit der ge- are the availability of approved and authorized process
nehmigten und autorisierten Prozess-Inputs, wie im inputs listed in workflow diagram of chapter 3.
Prozessflussdiagramm des Kapitels 3 aufgeführt.
Der Certification-Liaison-Prozess ist vollständig durch- The software certification liaison process is complete
geführt, wenn sein Zielsetzungen erreicht und diese when its objectives are satisfied approved by the certi-
durch das Zulassungspapier der Luftfahrtbehörde ge- fication statement of the authorities.
nehmigt worden sind.
Software Entwicklungs-Prozess-Abläufe PB-EN-32
Seite 29 von 36
Software Development-Process-Workflows Page 29 of 36
Ausgabe
10, 16 DEC 2021
Issue

4.3.5 Produktions-Transfer-Prozess 4.3.5 Production Transfer Process

Die Zielsetzung des Produktions-Transfer-Prozess ist The objective of the production transfer process is to
es, das gemäß ABD0100 und DO-178 entwickelte transfer the developed software product according to
Software Produkt zur Serienproduktion zu transferie- ABD0100 and DO-178 for series production purpose.
ren.

Der Produktions-Transfer-Prozess ist zur Überstellung The production transfer process shall be performed for
des finalen Software Produktes nach dem CRC / DR production transfer of the final software product after
/CRcC durchzuführen. Er ist des Weiteren für jedes CRC / DR / CRcC. It is also applicable for any inter-
Software Produkt im Kontext des FDR / FFR anzu- mediate software product in terms of FDR and FFR
wenden, wenn die Herstellung und Verteilung offiziell that shall be officially produced and delivered via pro-
über die Produktion erfolgen soll. duction.

Zur eindeutigen Identifikation des Software Produktes For unique identification purpose of the software
und der zugehörigen Integritätsdaten ist das Software product and its associated integrity data the software
Production Release Document gemäß ETemp-514 zu production release document according to ETemp-514
verwenden. Die Daten sind aus dem gültigen Software shall be used. The data shall be taken from the
Configuration Index (SCI, PAS für PDIs) zu überneh- applicable Software Configuration Index (SCI, PAS for
men. PDIs).

Das zu transferierende Software Produkt, die dazuge- The software product to be transferred, its associated
hörigen Integritätsdaten und das Software Production integrity data and the software production release
Release Document sind zur Übertragung in einen spe- document shall be copied into the production transfer
ziellen Austauschordner abzulegen, der ebenfalls im exchange folder according to software production
Software Production Release Document angegeben release document. The production transfer responsible
wird. Der Serienüberleitungs-Verantwortliche ist über shall be informed about the availability of the data.
die Verfügbarkeit der Daten zu informieren.

Anmerkung: Die „Serienüberleitung“ erstellt aus den Note: Within production transfer the official Engineer-
Informationen des Software Production Release ing Change Note (ECN) is generated in Buddy out of
Documents die offizielle Engineering Change Note this software production release document information.
(ECN) in Buddy.

Die korrekte Übertragung der Daten aus dem Software The correctness regarding the incorporation of soft-
Production Release Document in die Engineering ware production release document information into the
Change Note (ECN) in Buddy ist zu überprüfen und Engineering Change Note (ECN) in Buddy shall be
mittels Unterschrift zu bestätigen. checked and approved by signature.

Rollen, Inputs/Outputs und Aktivitäten Roles, Inputs/Outputs and Activities


Die grundsätzlichen Rollen und Zuständigkeiten sind in The fundamental roles and competencies are defined
Kapitel 2.3 definiert. in chapter 2.3.
Die prozessschritt-spezifischen Inputs/Outputs und The process-step specific inputs/outputs and activities
Aktivitäten sind rollenorientiert im Prozessschritt (7) are defined related to the roles in the process step (7)
der Prozessflussdiagramme aus Kapitel 3 definiert. of workflow diagrams in chapter 3.

Transitions-Kriterien Transition Criteria


Die Bedingungen, um in den Produktions-Transfer- The conditions to enter the production transfer process
Prozess einzutreten, sind die Verfügbarkeit der ge- are the availability of approved and authorized process
nehmigten und autorisierten Prozess-Inputs, wie im inputs listed in workflow diagram of chapter 3.
Prozessflussdiagramm des Kapitels 3 aufgeführt.
Des Weiteren muss das DDP (Declaration of Design Further the DDP (Declaration of Design and Perfor-
and Performance) vollständig unterschrieben vorlie- mance) is available with all signatures.
gen.
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 The production transfer process is complete when its
durchgeführt, wenn seine Zielsetzungen erreicht und objectives are satisfied approved by the performance
durch das Production Release Review (PRL) im Status of the associated production release review (PRL) in
„grün“ oder „gelb“ gemäß QG Ampelsteuerung der status “green” or “amber” according to QG traffic light
PB-EN-60 genehmigt worden sind. control of PB-EN-60.
Software Entwicklungs-Prozess-Abläufe PB-EN-32
Seite 31 von 36
Software Development-Process-Workflows Page 31 of 36
Ausgabe
10, 16 DEC 2021
Issue

4.4 Softwareänderungen 4.4 Software Changes

Jede Änderung einer bereits zertifizierten Software Every change of an already certified software will be
wird im Rahmen eines Änderungsprozesses einge- introduced by using a change process. For changes on
bracht. Für Änderungen an PDIs / Konfigurations Da- PDIs / Configuration Files a tailoring of the change
teien ist ein Tailoring des Änderungsprozesses mög- process is possible.
lich.
Der Änderungsprozess ist nicht in den Prozessdia- The modification process has not been shown in the
grammen im Kapitel 3 dargestellt wird jedoch in den process diagrams in chapter 3 but will be described in
folgenden Unterkapitel beschreiben. the following subchapters.

4.4.1 Planung des Änderungsprozesses 4.4.1 Planning of Change Process

Die Zielsetzung der Planung des Änderungsprozesses The objective of the planning of the Change Process is
ist die Compliance der vorherigen Dokumentations- to check the compliance of the previous documentation
Baseline mit den gültigen Zertifizierungsanforderungen baseline with the applicable certification requirements
zu prüfen und zu klären, welche Quality Gates, abhän- and to discuss the need for re-execution of previously
gig von den geänderten Life Cycle Data, erneut durch- performed quality gates depending on the changed life
geführt werden müssen. cycle data.

Rollen, Inputs/Outputs und Aktivitäten Roles, Inputs/Outputs and Activities

Die grundsätzlichen Rollen und Zuständigkeiten sind in The fundamental roles and competencies are defined
Kapitel 2.3 definiert. in chapter 2.3.

Die prozessschritt-spezifischen Inputs ist: The process-step specific inputs is:


- Vorherige Dokumenten-Baseline. - Previous documentation baseline.

Die prozessschritt-spezifischen Aktivitäten sind: The process-step specific activities are:


- Identifikation der Auswirkungen durch die ge- - Identification of the effects resulted by the
plante Softwareänderung und planned software change and
- Erstellung einer Software Change Impact Ana- - Creation of a Software Change Impact Analy-
lyse (SCIA). sis (SCIA).

Die prozessschritt-spezifischen Outputs sind: The process-step specific outputs are:


- Software-Change-Impact-Analyse (SCIA), - Software-Change-Impact-Analysis (SCIA),
- Software Configuration Management Report - Software Configuration Management Report
(SCMR), (SCMR),
- Software Quality Assurance Report (SQAR) - Software Quality Assurance Report (SQAR)
und and
- Review Report. - Review Report.

Transitions-Kriterien Transition Criteria

Die Bedingungen, um in die Planung des Änderungs- The conditions to enter the planning of the software
prozesses einzutreten, sind die Verfügbarkeit der Pro- change process are the availability of the process in-
zess-Inputs: puts:
- Life-Cycle-Daten der Input-Baseline inkl.: - Life-Cycle-Data of Input-Baseline incl.:
o Software Configuration Index (SCI), o Software Configuration Index (SCI),
o Software Accomplishment Summary o Software Accomplishment Summary
(SAS). (SAS).

Die Planung des Änderungsprozesses ist vollständig The planning of the change process has been com-
durchgeführt, wenn seine Zielsetzungen erfüllt und pleted if its objectives are satisfied and approved by
durch ein Software Status Review (SR) im Status performance of a Software Status Review (SR) in sta-
„grün“ oder „gelb“ gemäß QG Ampelsteuerung der tus “green” or “amber” according to QG traffic light
PB-EN-60 genehmigt worden ist. control of PB-EN-60.
Software Entwicklungs-Prozess-Abläufe PB-EN-32
Seite 32 von 36
Software Development-Process-Workflows Page 32 of 36
Ausgabe
10, 16 DEC 2021
Issue

4.4.2 Änderungsprozess 4.4.2 Change Process

Die Zielsetzung des Änderungsprozesses ist die Im- The objective of the Change Process is the implemen-
plementierung der Softwareänderung wie durch die tation of the software change as analyzed and de-
SCIA analysiert und beschrieben. scribed by SCIA.

Rollen, Inputs/Outputs und Aktivitäten Roles, Inputs/Outputs and Activities

Die grundsätzlichen Rollen und Zuständigkeiten sind in The fundamental roles and competencies are defined
Kapitel 2.3 definiert. in chapter 2.3.

Die prozessschritt-spezifischen Inputs sind: The process-step specific inputs are:


- Vorherige Dokumenten-Baseline und - Previous documentation baseline and
- Software-Change-Impact-Analyse (SCIA). - Software Change Impact Analysis (SCIA).

Die prozessschritt-spezifischen Aktivitäten sind: The process-step specific activities are:


- Umsetzung der in der SCIA identifizierten Än- - Implementation of changes identified by SCIA,
derungen, - Adjustment of life cycle documentation where
- Anpassung der Life-Cycle-Dokumente, soweit required and
erforderlich und - Update of SCI and SAS.
- Aktualisierung von SCI und SAS.

Die prozessschritt-spezifischen Outputs sind: The process-step specific outputs are:


- Überarbeitete Life-Cycle-Dokumente, - Re-worked life-cycle-documents,
- Software Configuration Management Report - Software Configuration Management Report
(SCMR), (SCMR),
- Software Quality Assurance Report (SQAR) - Software Quality Assurance Report (SQAR)
und and
- Review Report. - Review Report.

Transitions-Kriterien Transition Criteria

Die Bedingungen, um in den Änderungsprozess einzu- The conditions to enter the planning of the software
treten, sind die Verfügbarkeit der Prozess-Inputs: change process are the availability of the process in-
puts:
- Life-Cycle-Daten der Input-Baseline inkl.: - Life-Cycle-Data of Input-Baseline incl.:
o Software Configuration Index (SCI), o Software Configuration Index (SCI),
o Software Accomplishment Summary o Software Accomplishment Summary
(SAS), (SAS),
- Software-Change-Impact-Analyse (SCIA). - Software-Change-Impact-Analysis (SCIA).

Der Änderungsprozesses ist vollständig durchgeführt, The change process has been completed if its objec-
wenn seine Zielsetzungen erfüllt und durch ein Com- tives are satisfied and approved by performance of a
pliance Review for change Certification (CRcC), oder Compliance Review for change Certification (CRcC),
im Falle von Software Level E durch ein Status Review or in case of software level E a Status Review (SR), in
(SR), im Status „grün“ oder „gelb“ gemäß QG Ampel- status “green” or “amber” according to QG traffic light
steuerung der PB-EN-60 genehmigt worden ist. 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

Das könnte Ihnen auch gefallen