ASD-STAN D1/WG12

Date: 2024-11

prEN 9241:2024

Secretariat: BNAE

Aerospace series — Programme management — Execution logic

Luft- und Raumfahrt — Programmmanagement — Ausführungslogik

Série aérospatiale — Management de programme — Logique de déroulement

Contents Page

European foreword 3

1 Scope 4

2 Normative references 5

3 Terms and definitions 5

4 List of acronyms 8

5 Execution logic: end-purpose, concepts and constitutive elements 9

5.1 End-purpose of programme execution logic 9

6 Concepts 9

6.1 Programme execution logic 9

6.2 Execution plan 9

6.3 Constitutive elements of execution logic 10

7 Execution logic construction process 14

7.1 General 14

7.2 Inputs for the execution logic construction process 16

7.3 Description of the execution logic construction activity 17

7.4 Interfaces with the other disciplines 19

7.5 Process output: execution logic 21

8 Execution logic change control 22

8.1 General 22

8.2 Triggers for updating the logic 22

8.3 Impact analysis 23

8.4 Decisions and baselining 23

9 Capitalization and lessons learned about the logic 23

Annex A (informative) Contents of an execution plan 25

Annex B (informative) Example of execution logic for an entire programme 28

B.1 General 28

B.2 Description of phases and milestones 30

Annex C (informative) Examples of specificities to be taken into account 38

C.1 Incrementally realized product 38

C.2 Integration of a commercial off-the-shelf (COTS) product 39

C.3 Integration of a multi-programme product 40

Bibliography 41

European foreword

This document (prEN 9241:2024) has been prepared by ASD-STAN.

This document is currently submitted to the CEN Enquiry.

The scope of the present document is to provide the elements needed for elaborating the programme execution logic and drafting the execution plan for the realization of a product.

NOTE 1 In this document, the term “logic” alone is sometimes used for “execution logic”.

NOTE 2 In this document, the term “product” is used to designate the object of the program concerned, and the term “system” is used to designate the product for anything related to system engineering.

NOTE 3 The product is also considered a “system-of-interest” and its enabling systems are also taken into account.

The execution logic and plan enable customers/suppliers to reach an agreement on how their respective processes and activities can be organized.

The aim is to enable each actor in the programme to manage their activities with sufficient visibility of the sequencing of the other stakeholders’ activities.

This document belongs to the documents supporting EN 9200 relating to the programme management specification.

The present document describes the principles of programme execution logic and defines the corresponding management requirements. This description is supplemented:

— on the one hand, in terms of execution logic principles, by:

o the challenges of a basic logic common to all actors (synchronization);

o the applicable criteria to set up this basic logic;

o the translation of this logic into the programme processes;

— on the other hand, in terms of implementing the execution logic, by:

o the procedures for practical implementation of the management requirements defined in EN 9200;

o adaptations of the logic according to the various constraints and specificities of the programme, and justification of these adaptations;

o the consistency between the basic logic at system level and the logics at subsystem and constituent levels.

The breakdown of clauses as used in this document gives a gradual understanding of the approach to be adopted to construct an execution logic. For instance:

— Clause 5 presents the end-purpose of a programme execution logic as well as the associated basic concepts and the constituents of this logic;

— Clause 6 describes and characterizes the process for building the logic;

— Clause 7 concerns change control to the execution logic;

— Clause 8 concentrates on the importance of capitalization and lessons learned.

This document applies to aeronautical, space and defence programmes. The principles can be extended to other areas of activity.

It applies to realization of a single product, of several samples or of a series. It applies to any customer/supplier level, while ensuring consistency between successive levels.

The principles described concern all programme actors, from initial expression of need through to closure of the programme.

There are no normative references in this document.

For the purposes of this document, the following terms and definitions apply.

ISO and IEC maintain terminology databases for use in standardization at the following addresses:

— ISO Online browsing platform: available at https://www.iso.org/obp/

— IEC Electropedia: available at https://www.electropedia.org/

3.1

life cycle (of a product)

set of successive maturity states that the product takes during the different phases of a programme

Note 1 to entry: States of maturity during which the product is gradually processed are typically: concept, development, realization, use including in-service support, disposal.

Note 2 to entry: The life cycle is generally illustrated as a series of stages, from production (extraction and harvesting of raw materials) to final disposal (disposal or recovery), including manufacturing, packaging, transport, use and recycling or disposal.

Note 3 to entry: Notion not to be confused with life profile.

3.2

life cycle (of a programme)

set of phases that a programme passes through from its initiation to its closure

Note 1 to entry: The phases of the programme are typically: initial expression of need, feasibility, definition, development, production, operation, disposal.

Note 2 to entry: The life cycle is a structured and exhaustive scenario, elaborated as a common reference for all stakeholders concerned and aimed at taking account of all contexts and processes in which the product shall be involved during its life.

3.3

milestone

significant and planned event used to measure the progress of a programme to allow the next phase to start

3.4

execution logic

phased and articulated sequence of activities, tasks and milestones covering the entire lifecycle of the product

Note 1 to article: Execution logic enables each actor to control own activities and coordinate them with those of the other actors.

3.5

phase of a programme

period of a programme, delineated by milestones, during which a coherent and orderly set of activities is performed to achieve an objective

3.6

process

sequence of correlated or interacting activities that transforms inputs into outputs according to one or more defined objectives

Note 1 to entry: The inputs of a process are usually the outputs of other processes.

Note 2 to entry: A process shall be planned and implemented under controlled conditions.

Note 3 to entry: A process is characterized by the following elements:

— object;

— objective(s);

— inputs, including prerequisites;

— results/purposes/effects;

— criteria of success;

— rules;

— constraints;

— definition and organization of activities;

— means (human and technical resources) to be implemented;

— methods to be applied.

Note 4 to entry: The French term “procédé” is generally used in the context of manufacturing processes. A process is called “special process” when the conformity of the outputs cannot be verified by subsequent monitoring or measurement and requires special provisions for process control.

3.7

product

result of activities or processes

Note 1 to entry: Product categories can be services, hardware, software, processed materials, intermediate work products from elementary activities, such as documents, models, etc.

Note 2 to entry: In the frame of a product developed to satisfy a customer’s need, the processes involved are the expression of the need, the establishment of the definition, the industrialization and the production.

Note 3 to entry: The product can be either a final product to be delivered to a customer (aircraft, equipment, etc.) or one of its components. In both cases, it represents the supply due under the contract.

3.8

programme

coordinated set of technical, administrative and financial tasks, intended to design, develop, realize and use a product, satisfying a need under the best performance, quality, cost and time conditions as well as ensuring the support of it and finally the disposal

Note 1 to entry: All or part of a programme can be designated also in the industrial world and in some normative texts by the words “project”, “contract”, etc.

Note 2 to entry: When the notion of programme is associated with an overall system, the notion of sub-programme or project is frequently used when addressing the constituents of this system.

3.9

review

systematic review of the results achieved at a given point in a programme to determine their suitability, adequacy and effectiveness to achieve the defined objectives

Note 1 to entry: The review is a decision aid but shall not be confused with decision making.

3.10

system

arrangement of parts or elements that together exhibit a stated behaviour or meaning that the individual constituents do not have

Note 1 to entry: A system is sometimes considered as a product or as the services it provides.

Note 2 to entry: In practice, the interpretation of its meaning is frequently clarified by the use of an associative noun, e.g. aircraft system, weapon system, etc.

Note 3 to entry: A complete system includes all of the associated equipment, facilities, material, computer programs, firmware, technical documentation, services, and personnel required for operations and support to the degree necessary for self-sufficient use in its intended environment.

[SOURCE: ISO/IEC/IEEE 15288:2023, modified — Note 2 to entry incomplete]

3.11

enabling system

system that supports a system-of-interest during the phases of its life cycle

EXAMPLE Production-enabling system, support system, qualification system, infrastructures, deployment system, etc.

Note 1 to entry: Each enabling system has a life cycle of its own.

[SOURCE: ISO/IEC/IEEE 15288:2023, modified — Note 1 to entry incomplete]

3.12

system-of-interest

SOI

system whose life cycle is under consideration

[SOURCE: ISO/IEC/IEEE 15288:2023]

3.13

task

description of what needs to be accomplished, under set conditions, to achieve an expected and identified result

Note 1 to entry: A task corresponds to an elementary action of a process. It uses identified resources which may include personnel, finances, facilities, equipment, techniques and methods.

The execution logic is a component of the management reference common to all actors in the programme. Its end-purpose is to coordinate and synchronize all the activities, taking account of the constraints and compromises made, the expected results (performance, quality, costs, schedule) and the accepted risks.

Programme execution logic is a programme management approach that:

— reflects the product acquisition strategy;

— allows actors to situate their activities and supplies with respect to the overall programme execution;

— identifies and plans the milestones allowing defined goals verification, decision-making and obtaining the data needed for this decision-making.

This logic is part of the execution plan.

The programme execution logic describes the sequencing of its component elements.

This sequencing represents the sequence of:

— actions and work (work packages, activities or tasks);

— milestones and stop points;

— document productions including contractual deliverables.

The execution logic is described for each level of the technical breakdown structure (or work breakdown structure), from the “customer” level of visibility to the work execution levels.

The level of visibility given to each actor within a programme (visibility given to programme actors and/or visibility of the scope of the other programme actors) is to be contractually defined.

The execution logic integrates both the programme’s own work and milestones, and work and milestones interfaced with the programme (external entry and exit points).

The execution logic results from programme execution technical (performance), schedule, budget, resource, strategic (policy, industrial policy, etc.) constraints.

An execution plan is the document drawn up by a supplier in reply to the execution requirements which are applicable and which formalize its execution logic.

An execution plan describes, at product and constituents' level:

— the planned scenario (logical and time-based) for execution and its possible variations, providing the assurance that the objectives will be reached;

— inputs and outputs to the interfaced actors or processes;

— the necessary and allocated human and material resources;

— the schedule;

— the financing commitments.

This execution plan can be stand-alone or completed and detailed by phase, depending on the size of the programme and the industrial strategy, through one or more specific plans such as:

— the development plan (see RG.Aero 000 42);

— the industrialization plan (see RG.Aero 000 48);

— the production plan (see RG.Aero 000 43);

— the integrated logistic support plan (see RG.Aero 000 76);

— the disposal plan.

The supplier ensures that the execution plan and the plans identified in the execution logic are consistent.

Each supplier is responsible for ensuring the synthesis and consistency of its suppliers’ execution plans with each other and with its own execution plan.

NOTE At the level furthest upstream, if the customer finds itself faced with several suppliers, it can be necessary to entrust elaborating and monitoring of the programme execution plan to an entity specifically mandated for this purpose.

An example of an execution plan template is given in Annex A.

Industrial strategy elements

Construction and validation of the execution logic take account of the opportunities and constraints related to the programmes' portfolio and products' portfolio (optimization of multi-programme products – see C.3).

Construction and validation of the execution logic take account of the industrial policies (choice of industrial manufacturers and partners), as well as the European, bilateral or international policies.

Product strategy elements

Construction and validation of the execution logic are also based on the product strategy covered by the products’ portfolio (product family, product renewal and change, complementarity of products, reusability).

They are also to be adapted according to the expected number of items (series production products, unitary products).

Technological strategy elements

During construction and validation of the execution logic, the entry points identified by the technological roadmap are taken into account. This consideration can lead to additional developments such as upstream study programmes.

Overview

The life cycle corresponds to the development of an entity (in particular, a programme, a company, a product or family of products, a process, a system or a solution) from its design to its disposal or dismantling.

The life cycle is a structured and exhaustive scenario, elaborated as a common reference for all parties concerned and aiming to take account of all environments and processes in which the product shall be involved during its life.

Product life cycle

The different states of the product can correspond, for example, to levels of maturity, degrees of achievement towards an availability (readiness level) and to increments or decrements in its capabilities.

As far as possible, transitions between these states are formalized with reviews, the objective of which is to validate the transition from one state to another, in order to provide points of reference for monitoring life cycle changes.

The life cycle takes account of the various missions for which the product has to be used and thus its possible versions or configurations.

The concept of life cycle also extends to all product breakdown levels: each level has its own specific life cycle, the steps of which can be organized differently from those of other levels.

The programme actors agree on significant situations (linked to product states and environments) to be taken into account when structuring the life cycle.

Nature of the product

Construction and validation of the execution logic also depend on the criticality and complexity of the product.

In addition, the software activities require integration into an adapted execution logic as they are very different in nature.

Programme life cycle

The life cycle of a programme is organized into phases that show the projected progress of the programme.

For the different product breakdown levels, the phases may be run in parallel depending on criteria:

— product maturity;

— development duration;

— schedule optimization.

NOTE EN 9277 describes the life cycle of a programme split into phases.

Integration of processes

A process explains how the activities are organized, i.e. their interactions, dependency and independence. A process may also be broken down into sub-processes.

The processes can be executed sequentially, simultaneously, iteratively. They may be invoked by other processes at any time in the life cycle of the programme.

The processes implemented in a programme are the result of adaptation of the following “generic processes”:

— agreement processes;

— company processes;

— programme management processes (see in particular EN 9200);

— technical processes.

Most of the activities associated with a product are grouped into technical processes which can be implemented at all levels of the product breakdown structure (see RG.Aero 000 50, RG.Aero 000 14, EN 9212, EN 9215 and RG.Aero 000 76 in particular).

The purpose of integration of processes is to ensure good consistency of the interfaces of the execution logic with other themes, see 7.4.

Tasks or activities

A task (or an activity) corresponds to an elemental action of a process. It uses identified resources which may include personnel, finances, installations, equipment, techniques and methods. The specific resources (measurement bench, test device, etc.) needed to perform tasks and maintain in operational condition are integrated into the product breakdown structure corresponding to the system-of-interest; an execution logic is associated with them and enables convergence points to be identified.

The tasks plus their schedule and supply characteristics are used to consolidate the execution plan.

For each element on the “functions” or “products” breakdown structure and for each type of activity (engineering, tests, manufacturing, etc.), it is up to the customer to determine the tasks for they wish to obtain a certain level of visibility.

The execution logic reveals the sequencing and the time-related links between the tasks constituting the various processes.

NOTE In this document, the terms “tasks” or “activities” are used interchangeably.

Objectives

Setting up reviews, milestones, stop points and meeting points allows achievement of the expected objectives to be made more reliable, as the programme execution matures. These elements contribute to reduction of programme risks and guarantee better control of expected compliance (see RG.Aero 000 67).

The execution of any programme is marked by a large number of decisions, each of which more or less irreversibly determines the activities of several actors for a given period.

Such decisions can comprise a wide variety of content pertaining to:

— processes: qualification pronouncement, acceptance, authorization from an authority;

— technical choices concerning the product: scenarios, options, variants;

— programme management: start-up, confirmation, re-scheduling or aborting (of tasks, of processes or of the programme);

— configuration management: designation of a baseline configuration.

These scheduled decisions can be taken unilaterally or jointly.

Associated meeting points

Given the challenges and the many actors concerned, each decision or set of decisions requires one or more meeting points which are needed, in addition to taking the actual decisions themselves, for the following:

— evaluation of prior work and conclusions concerning whether the predetermined conditions have been met;

— identification and specification of downstream activities, including their evaluation methods;

— precise definition of expected decisions and of the associated prerequisites;

— scheduling of subsequent meeting points.

The meeting points specifically dedicated to evaluating the progress of work and the conclusions regarding satisfaction of predetermined conditions may be based on reviews (see 6.3.3.4).

Milestones and phases

The scope of the decisions varies widely. A small number of them which more particularly impact the future and the overall economics of the programme are identified as “strategic decisions”. They generally involve the end customer, and the specific meeting points associated with them are by convention identified as programme “milestones”.

These milestones correspond to moments deemed opportune for establishing a clear and consolidated picture of the results obtained, so that the competent authority may decide on whether or not to commit resources to continue the work.

A milestone marks the beginning of a phase, a programme portion dedicated to performing a collection of activities recognized as having to be carried out in a consistent manner with regard to content, objectives and schedule. Consequently, passing a milestone is dependent on:

— assurance that the previously identified objectives have been reached;

— identification or confirmation of the objectives specified for passing the next milestone.

A programme is thus split into phases, the aim of which is to reach a pre-defined maturity state of the product corresponding to a particular programme milestone. This breakdown into phases depends on the level of control expected according to the programme parameters: objectives, inputs, criticality and associated risks in terms of technicality, cost, schedule, contractual relationship, confidence, etc.

The concept of milestones associated with phases is a method of organizing the general execution of a programme which, through step-by-step progress and scheduled strategic decisions (see 6.3.3.2), guarantees that the technical, financial and schedule objectives will be achieved. Identification of milestones allows interim payments from the customer to their supplier to be contractually established.

Reviews

The reviews are presented here as a concept which is an integral part of the execution logic for a programme. Their organization and implementation are covered by a specific recommendation (RG.Aero 000 66). Similarly, the specific characteristics of each of the reviews proposed in the standard logic are detailed in recommendation RG.Aero 000 67.

Reviews are organized on the occasion of meeting points specifically dedicated to evaluating the progress of work and confirming that predetermined conditions have been met.

A review is intended to prepare and enable one or more expected decisions to be made. The purpose of the review is to assist with:

— ruling on the validity of the results in relation to the forecasts and contractual requirements;

— allowing to initiate corrective and/or preventive action in the event of drift or insufficiency;

— materializing the transition to the next step and proposing a decision to pass the corresponding milestone, as applicable.

The customer constructs an initial overall execution logic included in the programme’s management and quality assurance specification, in line with the programme’s acquisition strategy (see 7.2.1).

The supplier then constructs the programme’s execution logic, for its scope of responsibility, based on reference documents including in particular:

— the programme’s management and quality assurance specification;

— the (need) technical specification [(N)TS];

— the description of expected services (with milestones and logic);

— the list of interfaced systems and equipment;

— the lists of applicable documents, reference documents and documents for information;

— the acceptance conditions;

— the administrative and regulatory provisions;

— the specific clauses, particularly the security and safety clauses;

— the contractual and financial conditions.

The execution logic proposed by the supplier is then validated by the customer.

The construction approach of a programme execution logic (see Figure 1) is presented as a process characterized by:

— its inputs;

— a description of the activity: identification, assembly and consolidation of the various basic constitutive elements;

— its output(s): the execution logic obtained and validated by level +1;

— its actors and position with respect to time.

The constitutive elements of the execution logic are presented in 6.3.

Key

	Customer
	n-1 supplier
	n-2 supplier

Figure 1 — Execution logic construction progress

The execution logic is the result of a process that is:

— iterative: the execution logic is constructed by allocating the execution requirements and taking account of each supplier's own internal requirements (including their strategy) at all levels in the contract work breakdown structure (see 7.3.5);

— recursive: consolidation is obtained by integrating the various execution plans, in particular by the loopback of the logics.

The programme execution logic is the result of this consolidation and is updated throughout execution of the programme.

In the approach presented in 7.3, emphasis is placed on assignment of the responsibilities associated with the various activities. Responsibility for the activity is to be distinguished from its execution, which can be on a joint basis (integrated team) or even be entrusted to a third party.

The acquisition strategy is all of the principles and guidelines defined by a customer concerning technologies, cooperation, industrial policy, resources available, support organization, etc. It also includes environmental elements related to the programme (specific infrastructure, external interfaces, etc.) and the support system for an initial period required for commissioning.

These principles and orientations are input data to identify:

— the information to be collected at each step (for example, from candidate suppliers or interfaced programmes);

— the expected maturity at each step;

— the decisions to be taken at each step (commitment of the subsequent step and associated resources, choice of a supplier, a technical solution, a support strategy, etc.).

They therefore specify the conditions to be met for passing each milestone, thereby framing the content, objectives and schedule of the tasks making up the intermediate phases.

The acquisition strategy covers the entire product life cycle, from the initial expression of need up to disposal. It is drawn up from the upstream stages of the programme onwards, and is to be gradually refined according to information collected and decisions taken.

The customer provides its suppliers with the useful data from its acquisition strategy in its requirements (see 7.2.3) included in the management specification.

The supplier has its own objectives as part of its programmes. It is up to the supplier to ensure that the needs and constraints of its stakeholders have been taken into account. The customer is informed of how these are taken into account in the execution logic.

From its acquisition strategy, the customer extracts an initial set of programme execution requirements.

It is then up to the supplier to evaluate these requirements and confront them with its own strategy and its own environment.

The programme execution requirements are formally expressed in the management specification.

These requirements in particular concern:

— the programme perimeter: “point of origin”, intermediate steps adopted, end of programme, interfaced programmes;

— the meeting points, milestones and associated reviews;

— the perimeter of the activities requested of the supplier;

— the documents and input and output methods for each of the phases;

— the procedures for passing milestones;

— the conditions applicable to elaborating, consolidating, accepting and updating the execution plan;

—  the overall schedule constraints.

These requirements specify the conditions whereby each party shall break down all of the activities that are imposed on it, and set up meeting points at its own level, taking account of the higher-level constraints. The link between these various levels is through agreed meeting points, monitored by the higher level.

The breakdown of all of the activities into milestones and phases constitutes the template for the execution logic.

If there is a standard execution logic, predetermined according to products, services and/or the organization, this is incorporated in order to initiate construction of the execution logic for the programme.

However, using a standard logic requires adaptation to the programme’s specific characteristics, risks and opportunities.

Each supplier or candidate supplier notes the requirements of its customer. If necessary, the supplier has its customer specify the nature and scope of the decisions that the customer reserves the right to take, the content of the expected supplies (data and justifications) and the reviews necessary for passing each milestone.

The supplier demonstrates to the customer that each requirement related to the construction of the execution logic has been taken into account in the execution logic submitted to the customer for validation.

In particular, the supplier demonstrates to the customer that the overall schedule constraints have been taken into account in the execution logic.

The supplier can then begin to draw up its execution plan.

In the work breakdown structure, each supplier lists the activities for which it is responsible, identifies their inputs and outputs, their links, their durations, how they sequence together and arranges these activities into processes which are themselves organized and interfaced together.

For each process, the supplier identifies the meeting points needed to measure progress and take the relevant decisions.

Overall, these meeting points can correspond:

— to the inputs/outputs of process internal activities which determine execution (see 7.3.4);

— to the inputs/outputs of the process itself, in particular those from and towards processes interfacing with it (see 7.3.4);

— to the outputs of the activities deemed necessary to pass the milestones specified by its customer.

In addition to the reviews associated with the milestones, the customer and supplier shall contractually agree on other reviews to be conducted as part of the programme.

Identification of the constitutive activities of the processes and scheduling of the meeting points are carried out at the same time, to ensure that they are consistent.

The supplier positions the identified meeting points with respect to the specified milestones and characterizes them in terms of:

— decisions to be taken;

— products and documents to be delivered;

— conditions to be met in this respect;

— reviews to be conducted.

It positions the activities and processes accordingly, while checking that their inputs and outputs are consistent with each other and with the specified milestones. It thus details the content of the various phases. In order to keep a meeting point, it can be necessary to identify the intermediate outputs of a process; synchronization is sometimes at the level of activities belonging to different processes.

Taking account of the above elements, its own constraints and the resources it envisages mobilizing at each moment, the supplier defines a target schedule for each activity and evaluates the flexibility it has for overall trade-offs at the process and phase levels.

The schedule of meeting points and their characteristics are written up in the execution plan.

General

On the basis of its own execution strategy, and in particular of the structure of the network of suppliers it intends to contact, the supplier (acting as a level n customer) identifies and positions in the execution plan the decisions and actions for which it is responsible in its relationship with each of its (level n-1) suppliers, plus the corresponding meeting points. It deduces and specifies its customer requirements (see 7.2.3).

The construction approach (see 7.1 – Figure 1) therefore follows a double path in the customer/ supplier network:

— the level n execution logic is broken down into requirements for level n-1;

— the level n-1 execution logic may result in constraints on the level n execution logic and requires modifications to the higher and/or collateral level(s).

These double paths (iterations) are performed:

— firstly on the execution logics;

— secondly on the execution plans.

The execution plans proposed in reply by the suppliers are successively aligned and consolidated by their customers in their own execution plans, after negotiating any compromises with both the suppliers and their upstream customer.

Consolidation of execution logics and alignment of execution plans

After iterations for consolidation of the execution logic, each actor constructs their execution plan.

As for the construction of the execution logic, the level n execution plan constitutes a set of requirements for developing and establishing level n-1 execution plans. The level n-1 execution plan can result in constraints on the higher and/or collateral level execution plans.

Each supplier draws up a proposal for an execution plan based on the validated logic and its own constraints. This proposal is validated by the customer, which ensures consistency with:

— its own plan;

— those of its other suppliers.

This validation is conducted in order to identify compatibility problems, particularly in terms of inputs/outputs (outside expectations, constraints, supplies), schedule (important meeting points), and risks. Each compatibility problem is jointly addressed by the customer with the affected supplier(s) and escalated and addressed at the higher level if necessary.

After handling all of the identified problems, the affected execution plans are reorganized.

The process described above may require several iterations between execution plans and execution logics.

The execution plans are set up as baseline plans as the desired consistency is achieved. Deviations will be identified and analysed on the basis of these baseline plans during subsequent monitoring.

Organization of the document system

Each stakeholder has its own document system. For certain programmes, a common document system is established with visibility and access rules.

In any case, construction of the execution logic is organized with the document system architecture so as to ensure traceability and management of document versions.

The product documentary system is also consolidated in the product breakdown structure.

The document system ensures consistency and traceability between the documents elaborated at level n and the downstream levels.

The documents elaborated at a level n are based on the corresponding documents of the downstream level.

The life cycle of the product constituents, mentioned in the product breakdown structure, shall be synchronized with the life cycle of the product. For example, the definition of these constituents shall have been qualified, and they shall have been manufactured and accepted so that they are delivered to the customer “on time” for integration.

The execution logic and the work breakdown structure are constructed in parallel.

While the execution logic lays out the sequence and time-related links between the activities constituting the various processes, the work breakdown structure ranks the activities according to the function or product breakdown structure and classifies them according to the industrial organization and/or types of activity (engineering, testing, manufacturing, etc.), for example.

Construction of the work breakdown structure follows the rules explained in RG.Aero 000 30. The main elements of this construction interact extensively with the execution logic.

Many areas affect construction of the execution logic. The constraints generated by these areas are considered:

— either between the programme managers and the managers of the area concerned;

— or within the framework of a collaborative approach (integrated programme team).

Some key interfaces are given below.

Quality assurance ensures that the choices made regarding execution logic in order to attain the programme's objectives will effectively be implemented, following applicable procedures and measures, and will be able to meet the contractually applicable requirements for all products, services and activities, throughout execution of the programme (see RG.Aero 000 87).

The contribution of quality assurance to construction and monitoring of the execution logic is primarily in terms of:

— documents:

o by quality view on programme documents;

o by establishment of a quality assurance plan for each supplier. The quality assurance activities to be taken into account when constructing the execution logic are explained in this plan, approval of which by the customer is a significant event in the execution logic;

— reviews: by checking the establishment, the implementation and the effectiveness of the corresponding corrective/preventive action plans. The specific reviews stipulated in the quality assurance plan shall be taken into account in the execution logic;

— milestones: by checking the decisions (passing of milestones) taken following the corresponding reviews and compliance with the pre-determined criteria;

— phases and processes: by checking activities and tasks, and the conformity of their results.

Configuration management covers decisions concerning “configuration baselines” in the life cycle of the product(s) (see EN 9223‑100). These decisions are prepared during configuration reviews at which the configuration documents, their associated justifications and their links with the programme execution logic are examined.

The identification of the configuration baselines is taken into account in the execution logic. A configuration baseline is identified at each of these steps.

Risk management and opportunity management (see EN 9239) are reflected in construction of the execution logic as soon as the programme is set up, with:

— identification and characterization of the risks to be controlled and of the opportunities to be seized during the programme (type, probability of occurrence and severity);

— planning of actions and key steps in risk management and opportunity management to be integrated into the execution logic;

— determination of the specific conditions to be met for passing each milestone (see 7.2.1);

— development of alternative logics in the event of certain risk factors or opportunity factors arising.

The procurement strategy is a determining factor in creation of the programme.

It determines the constraints that will be taken into account in construction of the execution logic, in particular:

— long lead procurement;

— single source;

— critical constituents, components or materials;

— European (e.g. REACh) or international (e.g. ITAR) limitations.

These constraints are taken into account during dedicated meetings or reviews:

— either between the programme managers and the purchasing managers;

— or within the framework of a collaborative approach (integrated programme team).

Taking legal constraints into account in the organization of a programme is a key element in construction of the logic. For example:

— regulatory authorization requests (construction permit, licence, etc.);

— conformity with environmental requirements;

— administrative deadlines.

These constraints are taken into account during dedicated meetings or reviews:

— either between the programme managers and the legal managers;

— or within the framework of a collaborative approach (integrated programme team).

Safety and dependability are major criteria for passing milestones and meeting points (see EN 9227‑1).

The safety and dependability managers for the programme validate the major relationships of the programme logic. This validation of the major relationships generates additional dedicated activities (analysis, review, verification) to be integrated into the execution logic.

These activities are integrated into the execution logic during dedicated meetings or reviews:

— either between the programme managers and the safety and dependability managers;

— or within the framework of a collaborative approach (integrated programme team).

Validation of the execution logic by the programme manager is the output of the construction process for this execution logic.

This validation is pronounced on the basis of the verification, by the programme quality manager and by the programme architect, of all the components of the execution logic for the entire programme.

This validation triggers a breakdown of the logic tree and its application in contractual terms at each level.

Application of the logic at each level allows incorporation of the execution plan(s) into a contract.

An example of an execution logic is given in Annex B.

The programme management plan describes the programme management procedures in accordance with the rules stated in the programme management specification (see EN 9200).

The management plan describes the procedures to be followed for any change to the execution logic or plan.

Execution of the programme or part of the programme is managed relative to its execution plan. Despite being referenced at the start of the programme, the execution plan and the execution logic may change.

There are different types of triggers for updating the logic: internal triggers within the programme and external triggers.

Internal triggers may be related to:

— a change to the need, technologies or the environment;

— detected and corrected logic errors;

— deviations that have become uncontrolled in the execution schedules;

— detected and corrected product design errors;

— readiness hypotheses about technologies or components that prove to be incorrect;

— the appearance of previously identified internal risk factors;

— the appearance of previously identified internal opportunity factors.

External triggers may be related to:

— a change in priority of the programme in relation to other programmes;

— a change in interface with one or more other programmes;

— deviations that have become critical in the execution schedules of other linked programmes;

— a change of strategy;

— technology changes;

— a change to the programme’s industrial environment;

— the appearance of previously identified external risk factors;

— the appearance of previously identified external opportunity factors;

— a geopolitical, political or sociological change;

— regulatory, societal or environmental changes.

The triggers for updating the programme logic are subject to continuous or periodic monitoring depending on the programmes (continuous in large programmes, periodic in smaller programmes). Among other things, this monitoring relates to checking the validity of the hypotheses on which the logic is based.

Just as construction of the programme logic is iterative and recursive (see 7.1), monitoring for updating triggers can be recursive (from the whole to the detail) and bottom-up (from the detail to the whole).

Each situation or event that triggers an update of the logic is subject to an analysis that determines the advantages and disadvantages of the decision to update the logic, and of the decision to not update the logic.

This analysis relates to any variants that have been previously identified in construction of the execution logic.

This analysis, conducted at the different levels of the industrial organization, relates to impacts on schedule, costs, the scope of deliverables, the quality of deliverables, risks and the expected value of the decision to be taken (see 8.4): modification decision, or decision not to modify the logic.

This analysis is conducted with and by those who were involved in construction of the logic (see Clause 7).

The decision to update the programme logic is taken at the highest level concerned (beyond this level the other levels are not affected by the update).

Once this decision is taken, it is communicated (for information) to the upper levels and is the subject of update requests to the lower levels.

Once all of the updates have been made, verified and validated, the new logic is subject to baselining (version, date and traces of the decision and of validations).

Baselining of the update to all or part of the logic of a programme can have an impact on current or future contracts: negotiation of these amendments is part of the impact analysis (8.3), incorporation of these amendments into a contract is part of the baselining step.

Lessons learned are formalized at each of the following steps:

— at the end of construction of the execution logic;

— during execution, each time trigger situations or events occur that have resulted in or could have resulted in the logic being updated;

— at the end of the programme.

These lessons learned are coordinated by an identified entity (for example the quality service) and documented with and by the programme stakeholders.

Lessons learned capitalization about the execution logic leads to updates of:

— logic models;

— logic construction and validation processes;

— standard update trigger elements (situations or events).

1. 
   (informative)
   
   Contents of an execution plan

Below is a proposed structure for an execution plan to be adapted to the specific context of the contract(s) and the product complexity.

Table A.1 — Contents proposal for an execution plan

1. 
   (informative)
   
   Example of execution logic for an entire programme
   1. General

The example below (see Figure B.1 and subclause B.2) corresponds to a representative case of certain aeronautical and defence programmes. This is a product:

— designed to meet an identified and broadly stabilized need (replacement of an obsolescent older product, variants that may have been scheduled during series production);

— calling on technologies which are essentially well-controlled (bounded degree of innovation);

— primarily “physical” (in which any software components work for implementation of the product);

— reproducible in medium or high numbers (a few dozen to several thousand, or even far more) and at a medium output rate (deployment spread over several months or even several years, with varying overlap between the end of production time and the beginning of the service life);

— for which the development and realization cycle includes the development and realization cycles of the sub-assemblies into the product;

— for which development on the one hand and series production on the other, as well as the associated loopback processes can take place independently, without any particular constraints concerning the overall schedule or deployment of common resources or means (development samples for example).

The example of execution logic described in this annex is structured into seven phases, each of which, excluding the first, is initiated by milestones. Starting a phase or part of a phase is determined by passing a milestone, corresponding to a decision to be taken by the customer and generally following a specific review.

Figure B.1 — Example of execution logic for an entire programme

• 1. Description of phases and milestones
     1. Initial expression of need phase

This phase consists in identifying, bringing together and validating the need to be met by the programme and the bases on which it is launched by the customer.

This phase, the beginning of which is not always clearly defined, and which is the sole responsibility of the customer, is particularly important in guaranteeing the subsequent efficiency and economics of the programme.

The customer expresses its need in terms of expected service, timeframe and envelope of resources to be allocated. It explains this need in terms of what is necessary and sufficient (doing away with anything implicit), possibly iteratively.

To do this, the customer draws up a review of the upstream studies (or has it drawn up) in order to summarize the available information and identify the context to be considered in the light of the planned timeframe (changes in the existing equipment population, the threat and the competition, the operating environment, the actors and operators concerned, the accessible resources and technologies, etc.).

On the basis of these, it is recommended that the customer performs a functional analysis of its need (or equivalent), in order to identify the product service functions. This expected service is supplemented by other objectives and constraints identified by the customer (costs, deadlines, use of upstream studies, specified interfaces, etc.).

Once identified and justified (need validation process), the need is expressed in the initial functional performance specification (FPS) and the associated justifications are recorded.

An initial function-breakdown structure approach is realized, and an initial work breakdown structure is built (see RG.Aero 000 30).

The customer draws up and formalizes its acquisition and risk control strategies and conducts an initial assessment of risks identified at its level, including those induced by the chosen acquisition strategy.

It translates its risk control strategy into measurable objectives to be checked at the main programme progress milestones.

All the above elements are summarized by the customer in a launch file which, as necessary, will be enclosed to back up its decision to launch the feasibility phase and the programme more generally.

The main processes implemented are:

— the first part of the expression of need process;

— the first part of the need validation process;

— a part of the (upstream) design process which will lead to an upstream studies summary.

Milestone M0: feasibility phase launch

The initial expression of need phase ends with a mission definition review (MDR), the role of which is, prior to the beginning of the feasibility phase, to ratify the broad outlines of the initial FPS and to confirm that all the elements needed to take the launch decision are available and formalized. This review also enables evaluation of the need to set up a programme.

The decision to launch the feasibility phase constitutes programme milestone M0. This decision takes shape in the conclusion of one or more contractual documents ordering said feasibility studies from the chosen designer(s)/manufacturer(s), after making use of the conclusions of the MDR and checking the presence and validation of the initial FPS.

• • 1. Feasibility phase

This programme phase consists in exploring the different conceivable concepts meeting a need expressed in terms of objectives to be attained (performance, cost, schedule).

During this phase, the following are implemented:

— the second part of the expression of need process, leading to the preliminary (N)TS (see EN 9208) and possibly to updating of the initial FPS;

— the second part of the need validation process, the results of which are integrated into the feasibility file;

— a second part of the upstream design process, which leads to the feasibility file (file describing the possible solutions which meet the expression of need and arguing in favour of the proposed solution).

At the end of the phase, it enables:

— each concept studied to be presented in draft form associated with a financial proposal (costs and schedule) for the definition phase;

— the technical and industrial feasibility to be evaluated and the critical elements of each concept (performance, cost, schedule, technical and economic supportability, uncertainties to be cleared up) to be highlighted with regard to the specified objectives (elements put together in a feasibility file);

— for each concept considered to be “feasible”, an assurance that the measurable objectives agreed for milestone M1 in the risks management plan, are reached, for example:

o all the significant risks have been identified, evaluated and located, using the adopted acceptability criteria;

o each unacceptable risk has been mitigated to an acceptable level;

o each non-minor acceptable risk is the subject of an appropriate action plan, for which the monitoring indicators are given in an ad hoc progress report;

o the demonstrated performance margins (technical, cost, schedule) in relation to the specified programme objectives are compatible with the associated risks, with a suitable confidence interval;

— the function-breakdown structure to be frozen, a provisional product breakdown structure to be established and the work breakdown structure to be enriched;

— for the subsequent phase, the concept (or possibly concepts) considered as meeting or able to meet the specified objectives, to be proposed, plus, as necessary, the associated designer(s)/manufacturer(s);

— the updated requestor need to be formalized, in particular containing:

o a frozen FPS, on the basis of which changes are managed using configuration management;

o a preliminary version of the (N)TS, backed up by an updated need traceability document (requirements justification file - RJF) if necessary.

Milestone M1: definition phase launch

All the elements brought together during the feasibility phase are examined during a system requirements review (SRR) or a feasibility review (FR), confirming that the conditions stipulated for the decision to launch the definition phase have been met or, on the contrary, leading to a request for an extension to the feasibility phase or cessation of the programme.

The definition phase is initiated by milestone M1; the choice of concept(s) is decided after analysing the conclusions of the SRR or the FR, and checking the pertinence and validity of the reference FPS and the preliminary (N)TS.

• • 1. Definition phase

These programme phase consists in examining the chosen concept(s) in order to lead to a solution architecture such as to satisfy the expressed need and in which the uncertainties are identified and deemed compatible with the decision to launch development.

During this phase, the supplier:

— more closely examines the technical solution corresponding to the previously chosen concept, and evaluates its performance (technical/cost/deadlines);

— manages the risks in accordance with the chosen management plan and updates the ad hoc progress report;

— ensures that the measurable objectives agreed for milestone M’2 in the risks management plan have been reached, for example:

o the risks assessment already carried out is confirmed and updated if necessary (as is therefore the management plan);

o the agreed action plan monitoring indicators are in conformity with the planned progress reports, if necessary updated according to deviations detected and proven to be acceptable;

o the margins with respect to specified objectives, re-assessed according to the acquired results, are compatible with the risks with a suitable confidence interval;

— consequently, with the customer, updates the management plan and the risks management baseline for the development phase;

— with the customer, freezes the “reference” (N)TS (output from the third part of the expression of need process);

— draws up the downstream (N)TS s and if possible the breakdown structure to be followed for all the specifications;

— ends the need validation process and updates the need traceability document which is to be examined during a specification review;

— initiates the definition qualification process;

— brings together the elements making up the “development launch file”. This file, drawn up under the customer’s responsibility, in particular comprises the reference (N)TS, the work breakdown structure and the documents prepared by the supplier, in particular:

o the management plan associated with the development plan;

o the downstream level (N)TSs;

o the preliminary definition data file (DDF) (output from the preliminary design process);

o the reference definition justification plan (DJP) and the preliminary test plan;

o the preliminary definition justification dossier (DJD).

Milestone M’2: development phase launch

The definition phase ends with the preliminary design review (PDR), the aim of which is to check that the concept chosen at product level is optimized in terms of performance, cost and schedule and is able to meet the specified objectives, in particular the system (N)TS. The review shall therefore provide elements to help with the decision of launching the development phase, request an extension to the definition phase or stop the programme and consequently:

— ratify the reference system (N)TS;

— if applicable, adopt the solution concept;

— approve the system architecture;

— on the basis of these elements, ratify the “development configuration baseline”;

— ratify the programme organization, including the execution logic.

The development phase begins with passing milestone M'2 which ratifies the proposed PDR and validates the reference (N)TS.

• • 1. Development phase
       1. General

This phase consists in a detailed examination of the chosen solution in order to lead to a qualified and producible definition of the deliverable products.

Within this phase, several sub-phases as described below are identified, all of which are the subject of launch decisions and intermediate milestones:

— detailed design;

— realization of development samples;

— qualification and industrialisation.

• • • 1. Detailed design sub-phase

This sub-phase consists of a detailed examination of the chosen solution in order to lead to a validated definition with a view to manufacturing the development samples.

The following processes are implemented:

— the detailed design process, which will lead to the detailed DDF (of the product and of each development sample);

— the first part of the preparation for operation process, which will in particular lead to the preliminary user file (UF);

— continuation of the definition qualification process, which will lead to the detailed DJD and the test documentation necessary for the qualification tests (finalized test plan, etc.);

— the industrialization process which will lead to the preliminary manufacturing and inspection files (MIFs) (see EN 9212).

All the documents produced during this sub-phase are subject to configuration management.

Milestone M”2: development samples realization sub-phase launch

All the documents drawn up during the detailed design are examined during the critical design review (CDR). The aim of this review is to:

— examine the product detailed definition with a view to realizing the samples(s) needed for testing and which are part of the qualification process;

— determine whether the detailed design process objectives have been reached and confirm the content and progress of the qualification and possibly the industrialization processes.

The sub-phase begins with passing milestone M”2 which ratifies the CDR choices.

• • • 1. Development samples realization sub-phase

This sub-phase consists in realizing the development samples and debugging them for the qualification trials.

The production process is applied when realizing the development samples and readying them for presentation for qualification testing (instrumentation, debugging tests, adjustments, etc.). The acceptance process is applied to the development samples and leads to production of the inspection report for each sample.

The files produced during the previous sub-phase are updated and completed.

The development sample documentation is realized.

The definition qualification process continues with drafting of the qualification test programmes and finalization of the associated procedures, all of which leads to a test readiness file.

In the meantime, the preparation for operation and industrialization processes (running-in the industrial means of production when manufacturing the development samples) continue. The latter leads to updating of the product MIFs.

The development samples and corresponding documentation are subject to configuration management.

Milestone M”’2: qualification sub-phase launch

The development samples realization sub-phase ends with the test readiness review (TRR). This review shall allow examination of the realized configuration of these samples and the progress of their development, and a decision on whether they are sufficiently representative of the expected definition and whether the conditions have been met to subject them to representative qualification tests (presentation for qualification testing).

The qualification testing sub-phase begins with passing milestone M”’2, which ratifies the conclusions of the RAE.

• • • 1. Qualification and industrialization sub-phase

Sub-phase consisting in submitting the development samples to the qualification tests and in making the industrial means of production suitable for series production.

During this sub-phase, the following are implemented:

— continuation of the definition qualification process leading to qualification testing in line with the DJP and the results of these tests (qualification test reports) and finalized by updating the DJD;

— continuation of the detailed design process, leading to the reference detailed DDF;

— continuation of the preparation for operation process, which will lead to updating the UF and logistic and operational support (including training resources and services);

— continuation of the industrialization process leading to setting up and complete validation of the production and inspection resources and methods, updating the MIFs (including acceptance procedures).

Verifications that contribute to qualification and commissioning are planned as of the upstream phases. The various verifications to be made in order to qualify and commission the product are scheduled and assigned to the different steps in the execution logic.

Milestone M3: production phase launch

Following the previous sub-phase the qualification review (QR) is held. The aim of this review is to check that the product definition meets all the requirements of the (N)TS and that it is producible, by:

— analysing the definition’s adequacy with the requirements of the (N)TS and checking its producibility;

— analysing the DJD and comparing it with the expected justifications in the DJP;

— checking that any residual risks are mitigated to a level compatible with qualification pronouncement.

In short, the QR shall provide the elements allowing qualification to be pronounced on the product for which production is to be launched.

The production readiness review (PRR) takes place at the same time, allowing in particular a decision on whether the product is reproducible, after examination of the MIFs and their associated justifications; it can authorize series production.

The production phase begins with passing milestone M3 which implies acceptance of the conclusions of the qualification reviews and the production readiness review.

• • 1. Production phase

This programme phase consists in realizing and supplying the ordered products to the user, in conformity with the defined status, along with the means necessary for their operation.

Three processes can be identified within this production phase:

— the series production process which corresponds to:

o manufacturing of products, including the necessary procurements;

o supply of the products;

o realization and provision of the means necessary for operation;

— continuation of the preparation for operation process, which leads to finalization of the reference UF (including maintenance documentation) and the product logbook (PL);

— the acceptance (loopback) process during which the following are drafted:

o the first item acceptance report;

o the individual inspection register (IIR).

In the event that debugging and demonstrations are performed on the first series items, the production phase includes a sub-phase for restoring the configuration of these items.

Milestone M4: operation phase launch

The documents drawn up during the above phase are examined during the first article critical inspection (FACI), and then the operation readiness review (ORR). The respective objectives of these reviews are:

— for the FACI:

o to analyse the conformity of one of the first series items with the qualified product definition;

o to check the ability of the production means to guarantee the reproducibility of the qualified definition;

o to ratify the MIF for series production;

o to allow supply of the products to the customer;

— for the ORR:

o to check that the operation environment (logistic and operational support, training) has been set up and procured in accordance with the established documents;

o to check the compatibility of this environment with the delivered products;

o to enable the customer to declare the operation readiness of the product, which determines the beginning of its operational life.

NOTE Depending on the circumstances, a formal support readiness review enabling the first two points above to be checked will be carried out prior to the ORR.

Milestone M4 which ratifies the conclusions of these two reviews, enables the product to be supplied to the customer and then commissioned.

• • 1. Operation phase

Programme phase during which the product and the means necessary for the operational mission execution are commissioned, utilized and supported.

In parallel with the operation process and the associated updating of the PL for the items delivered, the following processes continue, sometimes late on into the operation phase:

— design and definition qualification processes (definition changes);

— production process (items still to be delivered, application of changes to the delivered items) and corresponding acceptance (IIR and PL).

The process of lessons learned from users is implemented throughout this phase.

Milestone M5: disposal decision

This decision can concern partial or total disposal.

• • 1. Disposal phase

This programme phase consists in preparing and carrying out, in a coordinated manner and in accordance with the regulations in force, the entire or partial termination of the operation of the product and the dismantling of the products and the associated means.

NOTE 1 Dismantled equipment can be destroyed, stored, transformed or reassigned to other uses in other programmes.

NOTE 2 This phase can lead to establishment of a programme history and summary (performance achieved, total cost, statistics, etc.).

1. 
   (informative)
   
   Examples of specificities to be taken into account
   1. Incrementally realized product

Specific problem

Whatever the reasons (cost, schedule, difficulty satisfying the need, available technologies, etc.), the aim here is to examine and then realize successive versions of the product, taking account of the need gradually, but ensuring continuity of operation.

Elements to be adapted: milestones, phases

The need, as known at the beginning of the programme, is taken into account through the phases of a standard logic as described in Annex B. The feasibility phase applies to the entire known need and can be used to schedule the incremental approach (successive versions of the product) to meet the need while taking account of priorities, deadlines, costs and available technologies. Each version of the product then follows the execution logic relative to the unit or series product as applicable, from the definition phase to the disposal phase.

Depending on the scale of the changes to the need over time, it may be necessary to rerun the feasibility phase if the impact of the definition of the new version is such as that the solution concept changes.

Example of adaptation of logic

Figure C.1 — Example of logic for an incrementally realized product

Documents

A reference FPS and a master plan presenting the changes to the need taken into account in the various versions envisaged, situating each version in terms of technical content, schedule and economics, are available at the end of the feasibility phase. This master plan will also change in order to summarize execution logics of all the versions and highlight the transitions between the disposal phase of a version in service and service entry of the next version.

At the end of the definition phase, the reference (N)TS of the product version considered is available.

• 1. Integration of a commercial off-the-shelf (COTS) product

Specific problem

COTS are products or components that have already been developed for another programme or are already in a supplier’s catalogue.

For some of these COTS, in particular hardware or software playing an essential role in the product, it is recommended to designate them as configuration items with a view to integration into the product. The use of COTS as an alternative to development of specific products leads to savings in terms of both money and procurement times.

This requires significant monitoring in the customer/supplier relationship so as to collect and maintain the characteristics of each COTS.

In this case, a decision of this nature implies exploring possible alternatives and a comparative evaluation, at least summary, of one or more of them. With respect to these alternatives, specific development shall remain a possible fall-back, at least until the feasibility and overall benefit of one of the competing solutions has been finally confirmed.

Whenever possible, using a formal consultation is recommended to clarify and decide between the possible options.

All these activities are to be taken into account in good time in the execution logic.

Use of a COTS may also be stipulated by outside constraints from a customer (who wishes to standardize certain constituents of its installed base) or the market (when the development cycle of a constituent proves to be incompatible with the target cycle for the higher order constituent, for example).

Integration of a COTS instead of development of a specific constituent is in any case dependent on the acquisition strategy.

Once adopted, a COTS is considered as a constraint when it is integrated. Both for the interfacing constituents and for the product itself, its external specifications become design input data.

Changes to COTS are subject to specific monitoring and appropriate management.

Elements to be adapted:

Process

Based on the (N)TS (used as a consultation specification) of the COTS, the procurement process comprises the following direct activities:

— consultation of potential suppliers;

— evaluation of their bids and selection of the best of the bids deemed satisfactory;

— qualification for operation in the product;

— ordering and acceptance of the chosen COTS.

Throughout the previous steps, the purpose of evaluating the COTS is to determine whether what is offered by the supplier meets the need, to determine the cost of the COTS, its procurement time and its longevity. This evaluation enables the choice of COTS (which shall then be characterized, if necessary) to be justified, and its integration to be prepared by looking for compatibility between the expected product functions and the functions likely to be provided by the COTS.

Documents

The expression of need for the COTS is written up in an (N)TS, which is the consultation basis.

The COTS is defined by the DDF (or its elements enclosed by the supplier with its bid), possibly supplemented by specificities to be introduced into the technical purchase specification (TPS) if an order is placed.

A DJD is produced to prove that the definition of the COTS meets the expressed need [(N)TS].

Adaptation of the standard diagram

Figure C.2 — Example of logic for a COTS

Comment

In the definition phase, it is also necessary to ensure that the functions that are not required but present in the COTS are compatible with the product functions. These unrequired functions may provide opportunities.

• 1. Integration of a multi-programme product

Specific problem

Some products are developed separately with a view to implementation in different upper-level systems.

Owing to its integration into different upper-level systems, such a product is dealt with as constituents of these systems and its configuration management is in a multi-user mode.

Elements to be adapted

Integration of a product into an upper-level system (or systems) requires adaptation of either the product or the system concerned itself. In the first case, it is recommended to deal with the adaptation of a product of this type as a sub-programme in its own right, whose own logic is constructed in such a way as to be harmonized with that of the programmes and systems concerned. The schedule, content and criteria for the decisions to be taken by all parties are defined accordingly and meeting points and ad hoc reviews are arranged as necessary between these logics.

Bibliography

EN 9100, Quality Management Systems — Requirements for Aviation, Space and Defence Organizations

EN 9200, Aerospace series — Programme management — Guidelines for project management specification

EN 9208, Aerospace series — Programme management — Expression of need — Guidance on and format for (Need) Technical Specification

EN 9212,^[1] Aerospace series — Industrialization — Guidelines for establishing the manufacturing and inspection file and the associated justifications

EN 9215, Programme Management — Definition justification and qualification — A guide to drawing up the definition justification plan and of the definition justification dossier

EN 9223‑100, Programme Management — Configuration Management — Part 100: A guide for the application of the principles of configuration management

EN 9227‑1, ¹ Aerospace series — Programme management — Guide to dependability and safety control

EN 9239, Aerospace series — Programme management — Recommendations to implement risk management and opportunity management

EN 9277, Aerospace series — Programme Management — Guide for the management of Systems Engineering

ISO/IEC/IEEE 15288:2023, Systems and software engineering — System life cycle processes

RG.Aero 000 14, Definition of a product — Guidelines for establishing definition data file

RG.Aero 000 30, Programme management — Work breakdown structure establishment

RG.Aero 000 42, Guide for establishing and implementing a development plan

RG.Aero 000 43, Guide for establishing and implementing a production plan

RG.Aero 000 48, Guide for establishing and implementing an industrialization plan

RG.Aero 000 50, Programme management — Technical control of the definition and realization of a product — Concepts, processes, methods and documentary system

RG.Aero 000 61, Programme management — Cost and schedule management in programme phasing

RG.Aero 000 66, General guidelines for the organization, use and implementation of programme reviews

RG.Aero 000 67, Reviews in programme phasing and scheduling — Positioning and characteristics

RG.Aero 000 76, Programme management — Recommendations for the implementation of the integrated logistic support

RG.Aero 000 87, Quality system applicable in the aerospace field — Model for quality assurance of repair stations

1.  Published as ASD-STAN prEN at the date of publication of this document, available at:
   https://www/asd-stan.org/. ↑