Beruflich Dokumente
Kultur Dokumente
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
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
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
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
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.
Prozesse
DO-331, DO-332, DO-333
CRIs, IPs
SPEZIFIKATION auf
SYSTEM /
EQUIPMENT LEVEL
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
Processes
DO-331, DO-332, DO-333
CRIs, IPs
SPECIFICATION on
SYSTEM /
EQUIPMENT LEVEL
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
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.
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:
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.
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
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
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)
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.
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
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.
No. Norms & Standards Input Data Process Steps Activities Output Data
SOFTWARE WORKFLOW
SOFTWARE PLANNING PROCESS (Quality Assurance)
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
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.
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.
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
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
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
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
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.
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).
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
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.
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).
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:
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).
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).
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:
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.
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
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.
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
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.
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.
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 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
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.
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 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
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-40 System Validation & Verification PB-EN-40 System Validation & Verification
Prozess-Abläufe Process-Workflows
TBCKE- COTS Management Plan (COTS-MP) TBCKE- COTS Management Plan (COTS-MP)
5921/12 5921/12
- 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, …)
- 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)