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

Status
Not Published
Technical Committee
Current Stage
6055 - CEN Ratification completed (DOR) - Publishing
Due Date
13-Sep-2021
Completion Date
13-Sep-2021

Buy Standard

Technical report
-TP FprCEN/CLC/TR 17602-80-01:2021 - BARVE na PDF-str 17,29
English language
58 pages
sale 10% off
Preview
sale 10% off
Preview

e-Library read for
1 day

Standards Content (sample)

SLOVENSKI STANDARD
kSIST-TP FprCEN/CLC/TR 17602-80-01:2021
01-julij-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: FprCEN/CLC/TR 17602-80-01
ICS:
35.240.99 Uporabniške rešitve IT na IT applications in other fields
drugih področjih
49.140 Vesoljski sistemi in operacije Space systems and
operations
kSIST-TP FprCEN/CLC/TR 17602-80- en,fr,de
01:2021

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------
kSIST-TP FprCEN/CLC/TR 17602-80-01:2021
---------------------- Page: 2 ----------------------
kSIST-TP FprCEN/CLC/TR 17602-80-01:2021
TECHNICAL REPORT
FINAL DRAFT
FprCEN/CLC/TR 17602-
RAPPORT TECHNIQUE
80-01
TECHNISCHER BERICHT
May 2021
ICS 49.140; 35.240.99
English version
Space product assurance - Reuse of existing software

Assurance produit des projets spatiaux - Réutilisation Raumfahrt-Produktsicherung - Wiederverwendung

de logiciels existants vorhandener Software

This draft Technical Report is submitted to CEN members for Vote. 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.

Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are

aware and to provide supporting documentation.

Warning : This document is not a Technical Report. It is distributed for review and comments. It is subject to change without

notice and shall not be referred to as a Technical Report.
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. FprCEN/CLC/TR 17602-80-01:2021 E

reserved worldwide for CEN national Members and for
CENELEC Members.
---------------------- Page: 3 ----------------------
kSIST-TP FprCEN/CLC/TR 17602-80-01:2021
FprCEN/CLC/TR 17602-80-01:2021 (E)
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

---------------------- Page: 4 ----------------------
kSIST-TP FprCEN/CLC/TR 17602-80-01:2021
FprCEN/CLC/TR 17602-80-01:2021 (E)

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

---------------------- Page: 5 ----------------------
kSIST-TP FprCEN/CLC/TR 17602-80-01:2021
FprCEN/CLC/TR 17602-80-01:2021 (E)
European Foreword

This document (FprCEN/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 (FprCEN/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).

This document is currently submitted to the CEN CONSULTATION.
---------------------- Page: 6 ----------------------
kSIST-TP FprCEN/CLC/TR 17602-80-01:2021
FprCEN/CLC/TR 17602-80-01:2021 (E)
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.
---------------------- Page: 7 ----------------------
kSIST-TP FprCEN/CLC/TR 17602-80-01:2021
FprCEN/CLC/TR 17602-80-01:2021 (E)
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.
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; 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.
---------------------- Page: 8 ----------------------
kSIST-TP FprCEN/CLC/TR 17602-80-01:2021
FprCEN/CLC/TR 17602-80-01:2021 (E)
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
---------------------- Page: 9 ----------------------
kSIST-TP FprCEN/CLC/TR 17602-80-01:2021
FprCEN/CLC/TR 17602-80-01:2021 (E)
EN Reference Reference in text Title
processes. Edition: 2. 2008. ISO.
ISO FDIS 26262
Road vehicles -- Functional safety. FDIS Parts 1-10.
2010. ISO.
---------------------- Page: 10 ----------------------
kSIST-TP FprCEN/CLC/TR 17602-80-01:2021
FprCEN/CLC/TR 17602-80-01:2021 (E)
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]
NOTE 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]
NOTE 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.
---------------------- Page: 11 ----------------------
kSIST-TP FprCEN/CLC/TR 17602-80-01:2021
FprCEN/CLC/TR 17602-80-01:2021 (E)
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
---------------------- Page: 12 ----------------------
kSIST-TP FprCEN/CLC/TR 17602-80-01:2021
FprCEN/CLC/TR 17602-80-01:2021 (E)
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
---------------------- Page: 13 ----------------------
kSIST-TP FprCEN/CLC/TR 17602-80-01:2021
FprCEN/CLC/TR 17602-80-01:2021 (E)
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
Annex C Section 5
Section 5
Annex C
Techniques to support
Techniques to support
Software reuse
Risk management
Software reuse
Risk management
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.
---------------------- Page: 14 ----------------------
kSIST-TP FprCEN/CLC/TR 17602-80-01:2021
FprCEN/CLC/TR 17602-80-01:2021 (E)

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.
---------------------- Page: 15 ----------------------
kSIST-TP FprCEN/CLC/TR 17602-80-01:2021
FprCEN/CLC/TR 17602-80-01:2021 (E)
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.
---------------------- Page: 16 --------------
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.