SIST-TP CEN/CLC/TR 17602-80-01:2021
(Main)Space product assurance - Reuse of existing software
Space product assurance - Reuse of existing software
This handbook provides recommendations, methods and procedures that can be used for the selection and reuse of existing software in space software systems.
This handbook is applicable to all types of software of a space system, including the space segment, the launch service segment and the ground segment software (including EGSEs) whenever existing software is intended to be reused within them.
This handbook covers the following topics:
• Software reuse approach including guidelines to build the Software Reuse File
• Techniques to support completion of existing software qualification to allow its reuse in a particular project
• Tool qualification
• Risk management aspects of reusing existing software Existing software can be of any type: Purchased (or COTS), Legacy-Software, open-source software, customer-furnished items (CFI's), etc.
NOTE Special emphasis is put on guidance for the reuse of COTS software often available as-is and for which no code and documentation are often available.
Legal and contractual aspects of reuse are in principle out of scope; how ever guidelines to help in determine the
reusability of existing software from a contractual point of view is provided in [ESA/REG/002].
Any organization with the business objective of systematic reuse may need to implement the organizational reuse processes presented in [ISO12207]. These processes w ill support the identification of reusable software products and components within selected reuse domains, their classification, storage and systematic reuse within the projects of that organization, etc. But these processes are out of scope of this handbook as the handbook is centred on the specific project activities to reuse an existing software product, not part of those organizational reuse processes more oriented to ‘design for reuse’ processes.
In addition, this handbook provides guidelines to be used for the selection and analysis of tools for the development, verification and validation of the operational software.
Raumfahrt-Produktsicherung - Wiederverwendung vorhandener Software
Assurance produit des projets spatiaux - Réutilisation de logiciels existants
Zagotavljanje kakovosti proizvodov v vesoljski tehniki - Ponovna uporaba obstoječe programske opreme
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
01-december-2021
Zagotavljanje kakovosti proizvodov v vesoljski tehniki - Ponovna uporaba
obstoječe programske opreme
Space product assurance - Reuse of existing software
Raumfahrt-Produktsicherung - Wiederverwendung vorhandener Software
Assurance produit des projets spatiaux - Réutilisation de logiciels existants
Ta slovenski standard je istoveten z: CEN/CLC/TR 17602-80-01:2021
ICS:
03.120.99 Drugi standardi v zvezi s Other standards related to
kakovostjo quality
35.080 Programska oprema Software
49.140 Vesoljski sistemi in operacije Space systems and
operations
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
TECHNICAL REPORT
CEN/CLC/TR 17602-80-
RAPPORT TECHNIQUE
TECHNISCHER BERICHT
October 2021
ICS 49.140; 35.240.99
English version
Space product assurance - Reuse of existing software
Assurance produit des projets spatiaux - Réutilisation Raumfahrtproduktsicherung - Wiederverwendung
de logiciels existierender Software
This Technical Report was approved by CEN on 13 September 2021. It has been drawn up by the Technical Committee
CEN/CLC/JTC 5.
CEN and CENELEC members are the national standards bodies and national electrotechnical committees of Austria, Belgium,
Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy,
Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia,
Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom.
CEN-CENELEC Management Centre:
Rue de la Science 23, B-1040 Brussels
© 2021 CEN/CENELEC All rights of exploitation in any form and by any means Ref. No. CEN/CLC/TR 17602-80-01:2021 E
reserved worldwide for CEN national Members and for
CENELEC Members.
Table of contents
European Foreword . 4
Introduction . 5
1 Scope . 6
2 References . 7
3 Terms, definitions and abbreviated terms . 9
3.1 Terms from other documents . 9
3.2 Terms specific to the present document . 9
3.3 Abbreviated terms. 10
4 Overview of the handbook . 11
4.1 Introduction . 11
4.2 Relation to other ECSS Standards . 12
4.2.1 General . 12
4.2.2 Software engineering . 12
4.2.3 Software product assurance . 13
4.2.4 Project management . 13
5 Software reuse approach . 14
5.1 Introduction . 14
5.2 Requirements phase . 16
5.2.1 Overview . 16
5.2.2 Requirements identification . 16
5.2.3 Gap analysis . 17
5.2.4 Derived requirements identification . 18
5.3 Assessment phase . 18
5.3.1 Overview . 18
5.3.2 Assessment . 18
5.3.3 Selection . 20
5.4 Integration phase . 21
5.4.1 Overview . 21
5.4.2 Incoming inspections . 21
5.4.3 Configuration management . 22
5.4.4 Adaptation of the existing software . 22
5.5 Qualification phase . 24
6 Tool qualification . 26
6.1 Introduction . 26
6.2 Tool qualification level . 26
6.3 Tool qualification . 28
7 Techniques to support qualification when reusing existing software . 32
7.1 Introduction . 32
7.2 Verification techniques . 33
7.2.1 Black box techniques . 33
7.2.2 White box techniques . 34
7.3 SW design techniques . 39
7.4 Hardware architecture techniques . 42
7.5 Reverse engineering . 43
7.6 Product service history . 44
7.7 Development process examination . 46
Annex A Content of Software Reuse File (SRF) . 47
Annex B Content of the Product Service History file . 52
Annex C Risk management considerations . 56
C.1 Introduction . 56
C.2 Risk scenarios and mitigation actions . 56
Figures
Figure 4-1: Organization of the handbook . 12
Figure 5-1: Specific reuse activities within project . 15
Figure 6-1: Tool qualification levels . 27
Tables
Table 6-1: Example of combination of classes of methods . 29
Table 7-1: Example of combination of classes of methods . 38
Table B-1 : Anomaly rate estimation . 54
Table B-2 : Anomaly rate versus time . 55
European Foreword
This document (CEN/CLC/TR 17602-80-01:2021) has been prepared by Technical Committee
CEN/CLC/JTC 5 “Space”, the secretariat of which is held by DIN.
It is highlighted that this technical report does not contain any requirement but only collection of data
or descriptions and guidelines about how to organize and perform the work in support of EN 16602-
80.
This Technical report (CEN/CLC/TR 17602-80-01:2021) originates from ECSS-Q-HB-80-01A .
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such
patent rights.
This document has been prepared under a mandate given to CEN by the European Commission and
the European Free Trade Association.
This document has been developed to cover specifically space systems and has therefore precedence
over any TR covering the same scope but with a wider domain of applicability (e.g.: aerospace).
Introduction
This handbook provides guidance on the approach that can be taken when defining the
implementation of activities for the reuse of existing software within a space project.
Existing software is defined in ECSS-Q-ST-80 as follows:
• Any software from previous developments that is used for the project development as is or
with adaptation. It also includes software supplied by the customer for use in the project
development.
• Any software including any software developed outside the contract to which ECSS software
standards are applicable.
• Any software including products such as freeware and open source software products.
In the development of software systems or products, different types of existing software artefacts can
be reused, such as:
• Requirements, when reused early in the software product requirements definition.
• Components, when reused early in the software product architecture definition.
• Modules, when reused at detailed design level.
• Libraries and source code, when reused at coding level.
• Documents, plans, tests, and data are other software items that can be reused.
This handbook adopts a broader interpretation of the term ‘existing software’, and assumes that it can
comprise the ‘reuse’ of tools for the development of any space software product.
Furthermore, the effective reuse existing software is based on the possibility to fully understand it
with respect to properties such as functionality, quality, performance, dependability or safety and to
find and adopt it to the development faster than it otherwise can be constructed.
However, whatever is the level of reuse, the quality of the reused existing software is of utmost
importance, as low quality can easily lead to system failure and thus loss of mission even for the
lowest reuse level. Consequently, significant analyses should be carried out when using existing
software. Furthermore, policies that favour reuse of existing software should be adopted with an
understanding of the complex impacts of using the already available software.
Scope
This handbook provides recommendations, methods and procedures that can be used for the selection
and reuse of existing software in space software systems.
This handbook is applicable to all types of software of a space system, including the space segment,
the launch service segment and the ground segment software (including EGSEs) whenever existing
software is intended to be reused within them.
This handbook covers the following topics:
• Software reuse approach including guidelines to build the Software Reuse File
• Techniques to support completion of existing software qualification to allow its reuse in a
particular project
• Tool qualification
• Risk management aspects of reusing existing software
Existing software can be of any type: Purchased (or COTS), Legacy-Software, open-source software,
customer-furnished items (CFI's), etc.
Special emphasis is put on guidance for the reuse of COTS
software often available as-is and for which no code and
documentation are often available.
Legal and contractual aspects of reuse are in principle out of scope; however guidelines to help in
determine the reusability of existing software from a contractual point of view is provided in
[ESA/REG/002].
Any organization with the business objective of systematic reuse may need to implement the
organizational reuse processes presented in [ISO12207]. These processes will support the identification
of reusable software products and components within selected reuse domains, their classification,
storage and systematic reuse within the projects of that organization, etc. But these processes are out
of scope of this handbook as the handbook is centred on the specific project activities to reuse an
existing software product, not part of those organizational reuse processes more oriented to ‘design
for reuse’ processes.
In addition, this handbook provides guidelines to be used for the selection and analysis of tools for the
development, verification and validation of the operational software.
References
For each document or Standard listed, a mnemonic (used to refer to that source throughout this
document) is proposed in the left side, and then the complete reference is provided in the right one.
EN Reference Reference in text Title
EN 16601-00-01 ECSS-S-ST-00-01 ECSS - Glossary of terms
EN 16602-80 ECSS-Q-ST-80 Space product assurance – Software product assurance
EN 16603-40 ECSS-E-ST-40 Space engineering – Software
BSCC(2004)
ESA software Intellectual Property Rights and
Licensing
DO178B Software considerations in airborne systems and
equipment certification. RTCA DO178B/EUROCAE
ED-12B. Radio Technical Commission for
Aeronautics/European Organization for Civil Aviation
Equipment. 1992.
TR 17602-80-04 ECSS-Q-HB-80-04 Space product assurance - Software metrication
programme definition and implementation
TR 17602-80-02 ECSS-Q-HB-80-02 Space product assurance - Software process assessment
and improvement
ESA/REG/002 General clauses and conditions for ESA contracts
(clauses 41-43).
FAA-COTS
DOT/FAA/AR-01/26 COTS avionics Study, May 2001
FAA-DOT-handbook
DOT/FAA/AR-01/116 Software Service History
Handbook. January 2002. FAA.
FAA-DOT-report
DOT/FAA/AR-01/125 Software Service History report.
January 2002. FAA.
FAA-N8110.91
FAA Notice N 8110.91. Guidelines for the qualification
of software tools using RTCA/DO-178B. 16/01/2001
GSWS
GAL-SPE-GLI-SYST-A/0092. Galileo Software Standard
IEC 61508
Functional safety: safety-related systems. (Parts 1-7) Ed
2.0. 2010
IEEE 1517
IEEE Standard for Information Technology - Software
Life Cycle Processes-Reuse Processes
ISO 12207
Systems and software engineering -- Software life cycle
EN Reference Reference in text Title
processes. Edition: 2. 2008. ISO.
ISO FDIS 26262
Road vehicles -- Functional safety. FDIS Parts 1-10.
2010. ISO.
Terms, definitions and abbreviated terms
3.1 Terms from other documents
For the purpose of this document, the terms and definitions from ECSS-S-ST-00-01 and ECSS-Q-ST-80
apply.
3.2 Terms specific to the present document
3.2.1 asset
item that has been designed for use in multiple contexts
[ISO 24765]
NOTE 1 an asset may be such as design, specification, source code,
documentation, test suites or manual procedures.
NOTE 2 “asset” is used in this handbook as synonym of “existing
software”.
3.2.2 domain engineering
reuse-based approach to defining the scope (i.e., domain definition), specifying the structure (i.e.,
domain architecture), and building the assets for a class of systems, subsystems, or applications
[ISO 24765]
3.2.3 operational software
software product which contributes directly to the mission
[GSWS]
Contractual aspects are not considered in this definition.
3.2.4 reuse
building a software system at least partly from existing pieces to perform a new application
[ISO 24765]
Traditionally achieved using program libraries. Object-oriented
programming offers reusability of code via its techniques of
inheritance and genericity. Class libraries with intelligent browsers
and application generators are under development to help in this
process. Polymorphic functional languages also supports
reusability while retaining the benefits of strong typing.
3.2.5 reuse software
see “existing software” in ECSS-Q-ST-80.
3.3 Abbreviated terms
For the purpose of this document, the abbreviated terms from ECSS-S-ST-00-01 and the following
apply:
Abbreviation Meaning
ESA European Space Agency
FAA U.S. Federal Aviation Authority
PSH product service history
SCMP software configuration management plan
SDP software development plan
SFMECA software failure mode effect and criticality analysis
SFTA software fault tree analysis
SQA software quality assurance
SRF software reuse file
SVVP software verification and validation plan
V&V verification and validation
Overview of the handbook
4.1 Introduction
This clause 4 contains an introduction of the content of this handbook, the intended audience and how
to use this handbook.
The organization of this handbook is reflected in detail in Figure 4-1. This handbook is organized in
ten main parts:
• Section 1. Scope
• Section 2: References
• Section 3: Terms, definitions and abbreviated terms
• Section 4: Overview of the handbook
• Section 5: Software reuse approach
• Section 6: Tool qualification
• Section 7: Techniques to support qualification when reusing existing software
Annexes include detailed information about:
• Annex A: Content of Software Reuse File (SRF)
• Annex B: Content of the Product Service History file
• Annex C: Risk management considerations
Section 3
Section 2
Section 2
Section 1
Terms, definitions and
Normative references
Normative references
Scope
abbreviated terms
Section 4
Section 4
Annex B
Annex B
Overview of the
Overview of the
Content of the Product
Content of the Product
handbook
handbook
Service History file
Service History file
Section 7
Section 7
Section 5
Annex C
Section 5
Annex C
Techniques to support
Techniques to support
Software reuse
Risk m anagement
Software reuse
Risk m anagement
qualification when
qualification when
considerations approach
considerations approach
reusing existing
reusing existing
software
software
Annex A
Annex A
Section 6
Section 6
Content of software
Content of software
Tool qualification
Tool qualification
reuse file (SRF)
reuse file (SRF)
Figure 4-1: Organization of the handbook
4.2 Relation to other ECSS Standards
4.2.1 General
Section 4.2 discusses how this handbook interfaces with other ECSS series, namely the ECSS-Q series
of standards (product assurance), ECSS-E series of standards (engineering) and the ECSS-M series of
standards (management).
The interface of this handbook to the ECSS-Q branch is via ECSS-Q-ST-80; equally, the interface of this
handbook to the ECSS-E branch is ECSS-E-ST-40.
The ECSS-M branch defines the requirements to be applied to the management of space projects.
ECSS-E-ST-40 and ECSS-Q-ST-80 describe how the ECSS-M standards apply to the management of
software projects. In addition, requirements that cannot be found in the M-branch because they are
specific to software product assurance are defined in ECSS-Q-ST-80.
Therefore, this clause contains an analysis of ECSS-E-ST-40 and ECSS-Q-ST-80 requirements related to
the reuse of software in space systems.
4.2.2 Software engineering
The interface of this handbook to the ECSS-E branch is via ECSS-E-ST-40; in turn, the interface of
ECSS-E-ST-40 to this handbook is via the ECSS-Q-ST-80.
ECSS-E-ST-40 covers all aspects of space software engineering from requirements definition to
retirement. It defines the scope of the space software engineering processes, including details of the
verification and validation processes, and their interfaces with management and product assurance,
which are addressed in the management (-M) and product assurance (-Q) branches of the ECSS
system.
ECSS-E-ST-40 contains some specific clauses applicable to projects that intend to reuse software
products from other space projects and third-party “commercial off-the-shelf” products to be part of
the software product
ECSS-E-ST-40 clauses 5.4.2.1 and 5.4.3.7, respectively, invokes clause 6.2.7 of ECSS-Q-ST-80 for
requirements on the use of existing software. Clause 5.4.3.7 of ECSS-E-ST-40 requires the evaluation of
the reuse potential of the software to be performed through the identification of the reuse components
with respect to the functional requirements baseline.
ECSS-E-ST-40 contains a DRD for the Software Reuse File (SRF) as a constituent of the design
justification file (DJF). Its purpose is to document the identification and analysis to be performed on
existing software intended to be reused.
This handbook also provides guidance for gaining confidence of the qualification status of any tool
used for the development, verification or validation of the space operational software. This handbook
will explicitly complement the implementation of ECSS-E-ST-40 tool related clauses, such as: 5.3.2.1
with requirements about development techniques (often supported by the use of tools) and testing
environment, 5.3.2.4 containing requirements about supporting tools for automatic code generation,
5.6.2 mentioning validation tools, 5.8.2.1 mentioning verification tools.
4.2.3 Software product assurance
ECSS-Q-ST-80 Standard defines software product assurance requirements for the development of
software in space projects in order to provide confidence to the customer and to the suppliers that
developed or reused software satisfies the requirements throughout the system lifetime. In particular,
ECSS-Q-ST-80 specifies requirements to ensure the software is developed to perform as expected and
safely in the operational environment meeting the quality objectives agreed for the project.
Clause 6.2.7 in ECSS-Q-ST-80 contains requirements about reuse of existing software and specifies the
term reuse software as it is used in the handbook. This handbook supports the implementation of the
requirements contained in ECSS-Q-ST-80 Clause 6.2.7.
Assessing the impact and deriving extra requirements to ensure any deactivated code or configurable
code, potentially happening when reusing existing software, do not harm the operational software
and system (as required by requirements 6.2.6.5 and 6.2.6.6 of ECSS-Q-ST-80) is also mentioned in this
handbook.
This handbook also provides guidance to cope with the selection of suppliers of existing software as
required ECSS-Q-ST-80 in Clause 5.4.1.2.
As this handbook also provides guidance for gaining confidence in the qualification status of any tool
used for the development, verification or validation of the operational space software, it supports the
implementation of clause 5.6 in ECSS-Q-ST-80, about tools and supporting environment detailing
development environment requirements.
4.2.4 Project management
The ECSS-M branch defines the requirements to be applied to the management of space projects.
ECSS-E-ST-40 and ECSS-Q-ST-80 describe how the ECSS-M series of standards apply to the
management of software projects. In addition, requirements that cannot be found in the M-branch
because they are specific to software product assurance are defined in ECSS-Q-ST-80.
These management-related processes are directly handled in this handbook through the interfaces to
ECSS-E-ST-40 and ECSS-Q-ST-80.
Software reuse approach
5.1 Introduction
Different existing software artefacts can be considered for reuse in each application engineering
processes: requirements analysis, design, coding, integration, testing, installation, maintenance and
operations. Therefore, there are specific activities that should be performed at a very early phase of the
project in order to ensure that the most suitable existing software is considered for reuse in the current
application. The suppliers should assess different options relevant to reuse and new development,
evaluating them with respect to criteria such as risks, cost and benefits. These options include:
a. Purchase an off-the-shelf, COTS software (no source code available) that satisfies the
requirements
b. Develop the software product or obtain the software service internally
c. Develop the software product or obtain the external software service through contract
d. Use open source software products that satisfies the requirements
e. A combination of a, b, c and d above
f. Enhance an existing software product or service
Clause 5 describes the activities to be performed and considerations to be made when reusing existing
software in a project. Choosing between creating the software in-house or reusing existing software is
not an easy decision. This choice should be made very early in the project, when often there is still no
information about the full set of functionalities nor the design. Only when systematic reuse is an
established policy in an organization, reusing existing software can be the starting approach in any
project. The organization would have the reuse-related processes deployed (see [ISO12207]) and any
project would first access the library of existing reusable products to check for any one that could fit
into the project concerned. Nevertheless, no matter what the organizational situation is, a systems
approach should be taken to consider how the existing software will fit into the new software
application to be developed.
The aim of this clause is to define a chronology of events and activities in order to correctly document
the selection, justification and qualification of the existing software to be reused in the current
application. As presented at the Figure 5-1 the phases that should be performed for each reused
existing software item are the following:
• Requirements phase – definition of the requirements to be fulfilled by the existing software
candidates by requirements identification, gap analysis and definition of derived requirements.
• Assessment phase –selection and justification of the best choice according to the identified
requirements from the previous phase and identification of corrective actions.
• Integration Phase – acquisition, inspection, adaptation, configuration management of the
selected reused existing software into the system software of the project.
• Qualification Phase – qualification activities performed on the existing software reused in
parallel to current software development.
Throughout this clause special considerations are made when the
existing software to be reused is what is often identified as COTS:
black box commercially available software for which neither its
source code nor any other development information is available
when acquired. COTS software usage may require considerations
of glue code, architectural mitigation techniques, derived
requirements and COTS software specific integration issues for
checking consistency. Any supplemental software due to COTS
software incorporation in software systems is considered
developmental software to which all of the objectives and
requirements of the project apply.
Customer approval
Modifications
From/to the project
RB requirements
Derived
and
Project (including Reuse activity
requirements
adaptations
quality) requirements
Requirements Assessment
Derived requirements
implementation verification
Integration
Incoming inspection
Asset
Requirements
Candidate assets Asset modifications
Assets documentation
Assets assessment
Qualification
Qualified asset
Figure 5-1: Specific reuse activities within project
All results are documented in the so-called Software Reuse File (SRF), sections of which will be
referred throughout the performance of the different reuse activities detailed below. Annex A of this
handbook presents guidelines following the required SRF DRD content as defined in the Annex N of
ECSS-E-ST-40.
Generally a single SRF document is expected to cover ALL the reused existing software foreseen in the
context of a software project, but it may be appropriate to produce specific SRFs targeted to individual
existing software products when there are large, numerous or complex. It should be noted that
documentation concerning reused or existing software is not simply limited to the (Software Reuse
File) SRF. There are software requirements that call for adequate planning concerning reused software
to be present in the SDP, the SCMP, the SPAP, the SVVP, and the SMP. Furthermore, it is clear that
reused software considerations should be properly covered (if needed) in a wider set of documents
(e.g. SDD, IR, SPR, etc.). Reporting on activities concerning existing software is also expected in the
SPAMR and SW progress reports. Lastly, software supplier should comply also with all SW
requirements relating with configuration management and control of reused software and tools as
described in 5.4.3.
5.2 Requirements phase
5.2.1 Overview
The system’s software requirements definition process identifies software requirements that existing
software should satisfy in compliance with clause 5.2 of the ECSS-E-ST-40 with the aim to put the
existing software in the context of the system requirements allocated to the software (e.g. any FDIR
related concepts/measures/mechanisms built into the reused existing software need to be validated for
compliance with the system-level dependability analysis and requirements). Existing software can
contain more features than the requirements needed by the system under development. A definition
of these features may be available from the supplier or derived from the user manuals, technical
materials, product data etc. Conversely, due to the use of existing software, there can be derived
requirements (e.g. platform dependent requirements, interrupt handling, interface handling, resource
requirements, usage constraints, error handling, partitioning) to be added to the system software
requirements. This is more likely true for COTS.
The following are the activities a project should perform and document within this reuse phase:
a. The requirements to be fulfilled by the reusable existing software should be identified from
project requirements
b. Gap analysis
c. Identification of derived requirements
5.2.2 Requirements identification
The aim is to concentrate on producing a detailed functional description in terms of functional
requirements and features needed for the reused existing software. This could for example be based
on:
• specific next-higher level/customer requirements that map directly to a potential existing
software component (e.g. upper level requirements related specifically to the operating system).
• additional high-level requirements identified directly by the software supplier (e.g. during
specification, architectural or detailed design phase).
• design constraints, performance, budget and timing requirements, target environment
constraints, etc.
The requirements analysis for the reuse of the existing software should be established taking into
account:
• the resources and performances in the operational environment of the original project of the
existing software and the operational functionality to be provided by the current application.
• rules for error handling including the propagation of errors from the existing software.
• non functional requirements, including criticality category level, are identified for the existing
software.
• the description of the operational environment of the application that uses the existing software.
• qualification methods (by inspection, analysis, test, etc.) are detailed.
• maintenance and support requirements.
The software supplier should clearly identify the critical functions from the safety and dependability
analysis that determine the quality level of the reused existing software with respect to the project
requirements. The qualification campaign will need to concentrate on demonstrating that these
identified functions are successfully realized by the reused existing software. When the existing
software is used to cover functionality across various software criticality categories, the requirements
for error-handling and propagation need to be clearly specified, as well as appropriate
protection/partitioning requirements. Qualification activities will need to be performed to avoid that
errors in the existing software at a lower software criticality category do not affect the required higher
criticality category functionality.
Much of the work to achieve a proper functional description (i.e. requirements definition) would be
performed in parallel with the software architectural design activities. The software supplier, faced
with upper level requirements to satisfy through a software (+hardware) solution can choose to
apportion parts of that architecture directly to existing software or to SW components that contain
existing software. It should therefore be entirely possible to identify the functional requirements that
will be needed to be realized by the existing software (as well as other non-functional requirements).
The results of the requirements analysis specifying whether the existing software fulfils the project
requirements should be documented in section <4.1> of the Reuse Software File (SRF) for all criticality
categories, as presented in Annex A of this handbook. It should be provided at SRR and PDR reviews.
As part of this requirements activity, potential existing software candidates that can satisfy the project
requirements should be identified.
All technical and management information available for each existing software candidate should be
collected. The suppliers should ensure also that they collect and document in the SRF the information
related to all identified candidates to be reused (including license agreements, costs, supplier support
policy, maintenance and warranty conditions, and more).
The detailed information about each candidate and its supplier(s) should be documented in section
<4.2> of the Reuse Software File (SRF) for all criticality categories, as presented in Annex A of this
handbook. This information should be provided at SRR and PDR reviews.
5.2.3 Gap analysis
Each candidate existing software documentation - especially specification, if exists - should be
examined, and a coverage analysis should be conducted against the requirements identified (see
clause 5.2.2). The purpose of this analysis is to determine up to which extension the existing software
requirements match the project software requirements and to aid in the comparison of candidates.
All available life cycle data from each candidate should be assessed. A gap analysis should be
performed to analyse the quality level of the existing software with respect to the project
requirements, according to the criticality of the functions intended to be implemented, taking into
account the detailed aspects referred in ECSS-Q-ST-80 clause 6.2.7.4.
In addition, in this gap analysis, the comparison between the software development standards applied
during the development of the existing software (if known) and the software standards applicable to
the current project is to be performed to aid on the later reuse qualification activities to be done.
The gaps identified during this phase should be translated into constraints that can be used as inputs
for a new iteration of the requirement analysis and a further analysis of the impact on the overall
software architecture and design.
The gap analysis for each candidate should be documented in section <5.1> of the Reuse Software File
(SRF) for all criticality categories, as presented in Annex A of this handbook. This information should
be provided at SRR and PDR reviews.
5.2.4 Derived requirements identification
Analysis should be conducted to identify derived requirements. This analysis should include all
existing software functions, needed and unneeded. Derived requirements can be classified as follows:
Requirements to prevent adverse effects of any unneeded functions of any existing
software. This can result in design techniques to work around the integration of the
existing software. The aim is to ensure that any deactivated code is not activated or that
its accidental activation does not harm the operation of the software system as required
in clause 6.2.6.5 of ECSS-Q-ST-80.
Requirements that the selected existing software can impose on the system including
those for preventing adverse effects of needed existing software functions (e.g. input
formatting, call order, initialisation, data conversion, resources, range, checking). This can
result in interface code, coding directives, architecture considerations, resource sizing,
glue-code etc.
Requirements for software containing configurable code. The aim is to ensure that any
unintended configuration cannot be activated at run time or included during code
generation as required in clause 6.2.6.6 of ECSS-Q-ST-80.
These derived requirements should be documented in section <5.2> of the Reuse Software File (SRF)
for all criticality category levels, as presented in Annex A of this handbook. This information should
be provided at SRR and PDR reviews.
5.3 Assessment phase
5.3.1 Overview
The focus of section 5.3 is on the assurance of quality and technical aspects when acquiring existing
software. The existing software assessment phase is comprised of assessment and selection activities.
The results of these activities will be used to full-fill the justification of the choice in the software reuse
file.
5.3.2 Assessment
After requirement phase, the existing software candidate is assessed for their capability to implement
the software requirements, for feasibility and the identification of compensation measures (e.g. delta-
qualification) and for their effects (e.g. cost, schedule) The impact of any unneeded features present in
the existing software should be assessed as well (assessing the impact of any deactivated code or
configurable code, to ensure no harm will be made to the operational software and system, etc.) as
previously mentioned in clause 5.2.4.
The following existing software artefacts should be considered for assessment if available (see clause
6.2.7.4 of ECSS-Q-ST-80):
• system requirements and their corresponding models;
• software requirements documentation;
• software architectural and detailed design documentation;
• forward and backward traceability between system requirements, software requirements,
design and code;
• unit tests documentation and coverage;
• integration tests documentation and coverage;
• validation documentation and coverage;
• verification reports;
• performance;
• operational performances;
• residual non-conformances and waivers;
• user documentation;
• code quality (adherence to coding standards, metrics)
Additionally, for COTS software (often black box with little information about it) the following
aspects should be added to the previous list:
• product availability;
• availability of lifecycle data;
• ease of integration and extent of additional efforts such as glue code, architecture techniques to
mitigate impact integration etc.;
• product service history;
• existing software supplier qualifications such as use of standards, history and length of service,
technical support etc.;
• configuration control including visibility into COTS software supplier’s product version;
• maintenance issues such as patches, retirement, obsolescence and change impact analysis.
The assessment of the potentially reusable existing software should also include the following
activities:
• evaluating the qualification status of these existing software towards projects requirements,
including reusability, safety and dependability;
• performing a risk analysis on re-using these components (see Annex C of this handbook);
• analysing compliance with the organization’s reuse standards;
• analysing consistency with project designs (e.g. software architecture design, database design);
The assessment is performed to evaluate whether the software system can incorporate the existing
software, whether design containment techniques to be used will tolerate identified risks or whether
the implementation of corrective measures will be so costly that the reused existing software
candidate should be rejected. These adaptations and modifications should be well identified when
assessing the candidate reusable products.
The assessments will permit to define what evidence is not provided, and to define the associated
actions to conform to the requirements (including quality requirements). The assessment will support
the definition of the corrective actions required to complement the verification and validation
information of the candidate existing software to meet the applicable project requirements.
The corrective actions can use or include one or more of the techniques introduced in clause 7. When
reverse engineering is not possible to use and life cycle data from previous development are not
available, PSH technique should be used (see claus
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...