ISO 14300-1:2001
(Main)Space systems - Programme management - Part 1: Structuring of a programme
Space systems - Programme management - Part 1: Structuring of a programme
Systèmes spatiaux — Management de programme — Partie 1: Structuration d'un programme
General Information
Relations
Frequently Asked Questions
ISO 14300-1:2001 is a standard published by the International Organization for Standardization (ISO). Its full title is "Space systems - Programme management - Part 1: Structuring of a programme". This standard covers: Space systems - Programme management - Part 1: Structuring of a programme
Space systems - Programme management - Part 1: Structuring of a programme
ISO 14300-1:2001 is classified under the following ICS (International Classification for Standards) categories: 49.140 - Space systems and operations. The ICS classification helps identify the subject area and facilitates finding related standards.
ISO 14300-1:2001 has the following relationships with other standards: It is inter standard links to ISO 14300-1:2011. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
You can purchase ISO 14300-1:2001 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of ISO standards.
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 14300-1
First edition
2001-05-15
Space systems — Programme
management —
Part 1:
Structuring of a programme
Systèmes spatiaux — Management de programme —
Partie 1: Structuration d'un programme
Reference number
©
ISO 2001
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not
be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this
file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat accepts no liability in this
area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters
were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event
that a problem relating to it is found, please inform the Central Secretariat at the address given below.
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic
or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or ISO's member body
in the country of the requester.
ISO copyright office
Case postale 56 � CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.ch
Web www.iso.ch
Printed in Switzerland
ii © ISO 2001 – All rights reserved
Contents Page
Foreword.iv
Introduction.v
1 Scope .1
2 Normative references .1
3 Terms and definitions .2
4 Abbreviated terms .2
5 Programme management specification and plan.2
6 Work breakdown structure .4
7 Programme organization .6
8 Programme phasing and planning.9
9 Cost and schedule management.19
10 Configuration management.23
11 Integrated logistics support .24
12 Documentation and information management.26
13 Risk management .30
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO
member bodies). The work of preparing International Standards is normally carried out through ISO technical
committees. Each member body interested in a subject for which a technical committee has been established has
the right to be represented on that committee. International organizations, governmental and non-governmental, in
liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical
Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.
Draft International Standards adopted by the technical committees are circulated to the member bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this part of ISO 14300 may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights.
International Standard ISO 14300-1 was prepared by Technical Committee ISO/TC 20, Aircraft and space vehicles,
Subcommittee SC 14, Space systems and operations.
ISO 14300 consists of the following parts, under the general title Space systems — Programme management:
� Part 1: Structuring of a programme
� Part 2: Product assurance
iv © ISO 2001 – All rights reserved
Introduction
This part of ISO 14300 provides an overview and requirements of space programme management with the overall
objective of optimizing performance, costs and schedules and of minimizing the risks.
Programme management is an integral element of any programme, but, in space, it is particularly important due to
the following:
� specific environmental conditions in space;
� need for a high level of performance;
� limited number of models;
� limited access to the product during operations;
� quasi-impossibility of repairing in the case of failure during flight;
� often high complexity of the organization;
� associated high costs involved.
The deployment of this standardized common set of programme management requirements should encourage and
facilitate international space co-operation.
INTERNATIONAL STANDARD ISO 14300-1:2001(E)
Space systems — Programme management —
Part 1:
Structuring of a programme
1 Scope
This part of ISO 14300 addresses the space programme management requirements, applicable through a top-
down approach in a contractual relationship between customers and suppliers. The applicable requirements for
product assurance are given in ISO 14300-2.
This part of ISO 14300 is intended to be used as a basis when establishing and negotiating customer programme
management requirements, and guiding the supplier’s responses.
It permits:
� a clear definition of the roles, responsibilities and authorities of the different customers and suppliers;
� coherence between their activities;
� communication capability between them;
� stable and rigorous programme organization;
� and, as far as possible, standardization of the rules applicable to various programmes.
It still allows for supplier flexibility in its implementation and tailoring.
2 Normative references
The following normative documents contain provisions which, through reference in this text, constitute provisions of
this part of ISO 14300. For dated references, subsequent amendments to, or revisions of, any of these publications
do not apply. However, parties to agreements based on this part of ISO 14300 are encouraged to investigate the
possibility of applying the most recent editions of the normative documents indicated below. For undated
references, the latest edition of the normative document referred to applies. Members of ISO and IEC maintain
registers of currently valid International Standards.
ISO 9000:2000, Quality management systems — Fundamentals and vocabulary.
ISO 9001:2000, Quality management systems — Requirements.
ISO 10007:1995, Quality management — Guidelines for configuration management.
1)
ISO 14300-2:— , Space systems — Programme management — Part 2: Product assurance.
1) To be published.
3 Terms and definitions
For the purposes of this part of ISO 14300, the terms and definitions given in ISO 9000 apply.
4 Abbreviated terms
CCB Configuration control board
CDR Critical design review
CI Configuration item
CM Configuration management
DF Design data file
EIDP End item data package
FS Functional specification
ILS Integrated logistic support
LSA Logistic support analysis
PDR Preliminary design review
PRR Preliminary requirements review
QR Qualification review
TS Technical specification
WBS Work breakdown structure
WPD Work package description
5 Programme management specification and plan
5.1 General
The attainment of quality throughout programme execution is the overall goal of management.
The requirements stated in ISO 9001 shall be taken into account by any company involved in a space programme.
When a level 0 customer (the first level in the contractual line issuing a contract) intends to make this part of
ISO 14300 a condition of a contract, this customer shall include in the solicitation (request for proposal, invitation to
tender, request for quotation, etc.) a dedicated programme management specification for its application by lower
level customers and suppliers.
The application of the management requirements from the level 0 customer to the lowest level of suppliers in the
contract chain shall be consistent with the criticality, complexity and cost of the product to be supplied. Thus,
suppliers of less critical products may seek to have fewer requirements. Nonetheless, the continuity and the
coherence of the programme requirements shall be maintained. Selection and tailoring of this part of ISO 14300 is
needed at the customer level. Any adaptation of this part of ISO 14300 shall be based on specific objectives and
constraints.
2 © ISO 2001 – All rights reserved
At a given level, the supplier shall adapt the management requirements contracted with his own customer to his
own suppliers. The customer can consequently fulfil his own obligations towards the next higher level (see
Figure 1).
The suppliers shall prepare a management plan in order to comply with the dedicated management specification,
received from their customer.
Figure 1 — Establishing programme management rules
5.2 Programme management specification
Depending on the nature of the programme or the programme phase, the programme management specification
shall be issued by the level 0 customer and may include additional requirements or, on the contrary, certain
elements which may be deleted with regards to this part of ISO 14300.
It is intended, as far as possible, that the wording of clauses 5 to 13 and the content of ISO 14300-2 be integrated
directly into any programme management specification, i.e. for harmonization or depending on the negotiated
applicability.
Each supplier of a given level acts as a customer towards his own suppliers and has to specify the management
requirements in the relevant contracts through a specific document or through the statement of work itself.
5.3 Programme management plan
In response to this programme management specification, each supplier concerned prepares a programme
management plan which contains descriptions of main activities, implementation methods and general procedures
with respect to its organization.
Existing supplier policies, procedures and other management controls should be used, where appropriate, and in
this case should be made available to his direct customer.
The supplier is encouraged to tailor any specified requirement that may provide more effective scheduling or
reduce costs without loss in compliance to the intent of the requirement. Such tailored requirements should be
individually identified within the supplier’s programme management plan to facilitate review by the customer.
The programme management plan shall be submitted to the customer for acceptance. The plan, as accepted by
the customer, becomes the basis for determining compliance with the customer programme management
requirements.
6 Work breakdown structure
6.1 General
The programme work breakdown structure (WBS) is the reference system for programme management data which:
� ensures the coherence between technical, documentary, administrative and financial activities of the whole
programme;
� identifies the responsibilities and authorities of each supplier.
The rules to be observed when producing, modifying and using the programme WBS are specified hereafter.
6.2 Objectives
The programme WBS is the structured and comprehensive breakdown of the whole programme. On the basis of
2)
the product tree (see 6.4.3) or the function tree (see 6.4.2), it identifies the tasks and principal resources required
to complete products intended to satisfy the expressed requirements.
This breakdown is achieved in a consistent way at different levels of responsibility and authority.
The programme WBS is used as a common reference for the level 0 customer and the suppliers so as to identify all
tasks required to entirely complete the programme, regardless if these tasks are:
� on the programme budget or not;
� under the responsibility and authority of the suppliers or other organizations.
The programme WBS ensures management, planning, performance and control of all tasks implied by the
programme.
2) Principal resources include the development of all hardware and software (e.g. test benches, tools) necessary for the
programme and also the resources required for the adaptation or the reuse of existing means, that means all those whose
unavailability may be a constraint for the programme.
4 © ISO 2001 – All rights reserved
6.3 Responsibility and authority for development
Each supplier shall:
� develop the product tree for his own supplies and limit it to interfaces with his own customer and suppliers;
� express his requirements concerning the establishment of the WBS to his suppliers.
These requirements are in particular associated with the programme organization (see clause 7) and the
configuration items, CIs (see clause 10).
6.4 Rules for defining the WBS
6.4.1 Main aspects
The coding of tasks, resources and products (and possibly, functions) shall be unique and constant in time.
The tasks to be performed have to be linked to each level of the product tree (see 6.4.3).
As long as the system’s product tree has not been defined, it is possible to associate tasks with functions of the
function tree (see 6.4.2).
The principal resources to be used to accomplish each task shall be clearly identified.
When the resources involved in the programme have to be developed (specific resources), they shall be
considered in the same way as the products to be provided.
6.4.2 Function tree
The function tree gives the framework of system performance by breaking it down into functions. Each function can
be decomposed into subfunctions, independent of the products involved.
It is possible to link tasks to functions at the early stages of the programme, i.e. at least up to the system definition
phase (phases 0, A and B, see 8.2).
At the system level, the function tree assures coherence of the whole system and the configuration control.
6.4.3 Product tree
The product tree gives the top-down framework of the product by breaking down the system into elements, i.e. from
the system, to subsystem, to equipment, to component level where appropriate.
All product tree elements are under configuration control, the identifiers have to be consistent with all related work
packages and documentation.
The product approach is based on apriori knowledge or knowledge gained since the programme started
concerning the products to be provided.
The product tree has to be established at the end of phase B (see 8.2.4) at the latest.
Products indicated in the product tree shall include, as a minimum, each product having a TS.
6.4.4 Tasks
The tasks can be described in work package description (WPD).
NOTE A WPD is the information associated with tasks and work packages.
Each task is mainly characterized by:
a) the customer/supplier relationship;
b) a unique and identified person or organization in charge;
c) its content, including:
� a title,
� an objective (e.g. qualification test),
� a description with excluded tasks, if necessary,
� a task type (design, production, product assurance, management, tests, etc.);
d) its link to an element (product or function);
e) its planning constraints, including:
� a planned duration,
� one (or several) input event(s) and data,
� one (or several) output event(s) and data,
� possibly, intermediate events (key events for the task);
f) its conditions of performance;
g) the resources required for its performance.
The resources used shall be associated with the task which implement them.
6.5 Management rules for changes
Changes in the WBS shall not modify its organization, so as not to disrupt programme management.
Each added product, function, resource or task shall be given a new identification (re-use of identifiers having
already been used at any other stage shall not be allowed).
The changes take into account the modifications of mandatory services and/or requirements which shall be
accomplished in compliance with the contractual specifications (modification of clauses, riders, etc.).
7 Programme organization
7.1 General
The implementation of a programme organization is required to ensure consistent programme performance and to
control programme execution.
This clause defines the organizational principles (organization at customer and industrial levels for programme
management) and specifies the organizational requirements concerning information circuits, internal and external
to the programme and its environment.
6 © ISO 2001 – All rights reserved
On the basis of contractual data, this clause is used by the different programme suppliers as a definition model and
for implementation of the respective organization at each level.
7.2 Principles
The organization to be implemented shall take into account the programme phases concerned, the nature of the
tasks to be performed and the associated responsibility and authority levels.
The preparation, definition and implementation of the programme organization shall be planned in compliance with
programme phasing (see 8.2).
The choice of the simplest and most effective management programme as well as contractual relationships shall be
made taking into account the specific programme aspects, whether it be a national or an international one.
The person in charge of the definition and implementation of the programme organization shall be identified.
The responsibilities and authorities for programme management and contracting shall be identified so as to
anticipate contractual and legal incidences.
Each programme organization shall be coherent in contractual and technical terms.
If the programme is associated with other programmes, responsibilities and authorities regarding interface definition
and management shall be specified and taken into account when implementing the programme organization.
7.3 Organizational requirements
7.3.1 General
The programme phases requiring an effective implementation of programme organization (feasibility, definition,
development, production, utilization) shall be specified. The programme change may lead to modifications of the
implemented organization during programme execution.
When several suppliers jointly play a common role, the responsibilities and authorities of each of them shall be
defined. When a supplier simultaneously plays several roles in the same programme, they shall be clearly defined
and carried out separately. For effectiveness, however, one single authority may supervise them.
Each supplier shall identify and assign the main responsibilities and authorities for the programme and implement
the internal organization in order to satisfy the contractual requirements.
Each customer and supplier are bound to play the roles both has been assigned for throughout the programme.
When several external organizations and/or internal departments are involved, the responsibilities and authorities
of each of them and their interfaces shall be clearly documented and the appropriate measures shall be taken to
ensure their co-ordination. These measures shall in particular define the nature of the information to be exchanged
between customers and suppliers.
7.3.2 Requirements
The roles of the programme suppliers shall be explicitly defined and, in particular, the programme organization shall
indicate who is in charge of each activity, required by the specific programme management specification, i.e.:
� programme management;
� contract management;
� cost and schedule control;
� engineering;
� procurement;
� ILS;
� product assurance;
� configuration and documentation management.
The interfaces and relationships with company management should be indicated. The application of the
management rules and their effectiveness for the performed or subcontracted programme activities shall be verified
according to planned and documented audits, analysis of indicators and/or reviews, as contractually defined.
7.4 Information and communication
7.4.1 Information circuits
Rules governing the organization of information circuits shall:
� define the list and role of the programme customers and suppliers;
� specify the information to be exchanged between customers and suppliers and the schedule of exchanges.
The mode of establishment, of change and application shall be stated.
7.4.2 Progress reports
For the supplier(s) and customer, the purpose of these reports consists in evaluating the work progress regarding
technical, performance, commercial, schedule aspects.
The content and periodicity of these reports shall be contractually defined. Progress meetings should be held only if
necessary.
7.4.3 Customer’s prerogatives
When this part of ISO 14300 is made part of an agreement between a customer and a supplier, the agreement
should establish the appropriate degree to which the customer will:
� monitor the application of the management requirements by the supplier;
� conduct or participate in audits or reviews of the supplier;
� be informed of the progress made by the supplier in design, manufacturing, inspection, and test.
The prerogatives needed by the customer in order to accomplish these tasks should be established by provisions
of the agreement. These provisions should cover:
� customer visits to the premises of the direct supplier;
� provisions that should be included in the direct supplier's agreements with lower level suppliers regarding visits
of higher level customers;
� the designation of permanent or non-permanent representatives, resident at the supplier's premises;
� the delegation of all or parts of these prerogatives to national surveillance organizations, or to other specified
organizations.
8 © ISO 2001 – All rights reserved
7.4.4 Action items management
Throughout the programme activities, the actions resulting from relations with the customer (e.g. meetings,
exchange of mail, key events, reviews) and/or those determined by the supplier as part of the application of the
management rules shall be controlled. Each action is defined by a form of identification, a clear and unambiguous
wording, an applicant, a person responsible for its completion and the corresponding deadlines (fixed date or
programme event).
The final status shall be formally expressed and accepted by the applicant on presentation of the applicable
justifications.
7.4.5 Technical and management indicators
From the start of the programme onwards, technical and management indicators, in particular highlighting
developments in product quality and the organizational functioning shall be formally defined, implemented, put to
use and updated throughout the programme activities. In case of significant unfavourable developments, measures
shall be taken according to the analysis of results.
These indicators are defined between the customer and the supplier and shall remain confidential.
8 Programme phasing and planning
8.1 General
The objective of programme phasing and planning is to minimize the technical, scheduling and economical risk of
3)
the programme by introducing phases of which the ends are marked by formal milestones . By implementing this
objective, the progress of the programme can be controlled with respect to cost, schedule and technical objectives.
This objective is achieved by breaking the product life cycle into distinct phases which are interlinked. The
objectives and work content of each phase shall be clearly defined.
Each milestone consists of a formal review process interrelated with technical baselines subject to configuration
management (CM). The results of this process are formalized by appropriate documentation.
The number of phases and their objectives should be defined at the start of the programme. They should also be
tailored to minimize risks from cost, scheduling and technical problems that can compromise the success of the
programme.
The composition and content of the phases shall be determined by the level 0 customer using the programme
management specification based on this part of ISO 14300 and shall be appended to the contract.
8.2 Programme phasing
8.2.1 Principles
The phasing may be broken down into seven phases. The start of a phase coincides with crossing a milestone, at
which time a decision is taken by the level 0 customer (or his highest authority) at a given system level. This usually
occurs after a specific review assessing the work results of the current phase, the provisions for the next phase and
the identified risks.
The crossing of milestones at lower levels shall be decided by the relevant customers, after the relevant reviews.
3) A milestone is a significant event or stage marking the end of a phase of development in the programme.
The purpose of a review is to perform a critical evaluation by a team not directly involved in the activities and with
the aim of helping to:
� assess the validity of the technical elements in relation to the predictions and the contractual requirements;
� enable corrective and/or preventive actions to be carried out in the case of drift or inadequacy;
� mark thetransitiontothefollowingstage;
� decide to cross the concerned milestone.
8.2.2 Mission analysis phase (phase 0 or pre-phase A)
This phase consists of an initial definition of the mission and of a preliminary assessment of the concepts needed
for consideration in the feasibility phase.
This phase results in:
� the identification and the characterization of the mission;
� an initial evaluation of needed performance, risks, requirements, and objectives, e.g. dependability and safety;
� an initial assessment of the manufacturing and operational constraints, including environmental conditions;
� the identification of possible solutions with the associated critical issues, taking in account the lessons learned
from current space programmes;
� an initial evaluation of the elements of the programme (organization, costs, schedules).
The results of these activities are summarized in a transition phase 0 to phase A document including a provisional
functional specification (FS) which serves as the basis of the decision to initiate the feasibility phase.
8.2.3 Feasibility phase (phase A)
8.2.3.1 Objectives
This phase of the programme consists in exploring the various possible concepts so as to meet the defined
objectives (performance, costs, schedules).
This phase results in:
a) the function tree being issued;
b) the user’s objectives being formally defined in:
� a reference FS,
� a preliminary issue of the TS at the system level;
c) the presentation of each concept examined in a pre-design associated with a financial proposal (costs and
schedules) for the definition phase;
d) the estimation of technical and manufacturing feasibility and the emphasis on the critical elements of each
concept (performance, risks, costs, schedules, technical and support costs).
10 © ISO 2001 – All rights reserved
8.2.3.2 Documentation
This phase results in the drafting of a “transition phase A to phase B document” under the responsibility and
authority of the level 1 customer.
These documents shall emphasize in particular:
� the feasibility of proposals to meet the anticipated requirements;
� the general description of these proposals, indicating the main elements for each one (performance, costs,
schedules, risks) and the one recommended;
� the organization of subsequent phases (structures, resources, etc.) and in particular those elements allowing
the start of the definition phase (WBS, costs, schedules, etc.).
The authority responsible for the milestone crossing may require that phase A results be examined in their entirety
or at least partially during a review called the “preliminary requirements review”.
8.2.4 Definition phase (phase B)
8.2.4.1 Objectives
This phase consists of selecting one proposal for development among those proposed at the end of the feasibility
phase and in specifying the necessary requirements.
This phase starts by crossing the milestone corresponding to the acceptance of phase A results.
This phase results in:
� the comparison of performance and risks (regarding technical/cost/schedule aspects) of the technical solutions
previously selected to be studied;
� the establishment of the TS at the system level;
� the establishment of the TS at the first level and whenever possible in compliance with the function tree as
inputs to all specifications;
� the evaluation of the dependability and the safety characteristics;
� the choice of the proposal for development, in particular taking into account the financial aspects of the
proposal;
� the issue of the “transition phase B to phase C document”.
8.2.4.2 Documentation
8.2.4.2.1 General
The following documents, written under the responsibility and authority of the level 1 customer, shall be compiled
with the TS and the documents drafted by the supplier:
� the management plan and the development plan;
� the WBS (see clause 6);
� the first level TS and, whenever possible, the associated technical clauses;
� the preliminary design data file (DF) and the justification for it.
8.2.4.2.2 Transition phase B to phase C documents
These documents in particular emphasize:
a) all the necessary requirements listed in the TS. This TS shall be compared with anticipated requirements. The
purpose of this comparison is to verify that there is no incoherence between anticipated requirements, defined
by the user in the reference FS, and the technical and contractual requirements expressed in the TS;
b) the proposed design of the solution, which has been sufficiently examined in compliance with the
requirements. This design is, in general, described in a preliminary DF and defines the architecture of the main
components. This design shall facilitate the identification of the various critical points in the product
development and manufacturing;
c) the organization of the development phase with:
� the organization of the project,
� the schedule for completion, including key events,
� the methods allowing the various identified risks to be kept under control;
d) the justification of the estimated cost of the development phase.
8.2.4.2.3 Development plan
At the end of phase B, the development plan shall be drafted by the level 1 customer, taking into account the
requirements of his customer and with the elements of his own suppliers. This development plan shall describe the
phasing rationale used to carry out satisfactorily the development of the products under his responsibility and
authority and in particular:
� the task sequence of the project;
� the mandatory steps (key events);
� the significant stages in development progress and of the design verification (document issue, manufacturing
of models, tests, reviews, etc.).
When approved by the level 0 customer, it becomes the document for management and follow-up of the work.
8.2.4.3 Reviews
8.2.4.3.1 System requirement review
During phase B, a system requirement review should be held in order to:
� examine the compatibility of the system framework and the allocation of performance to the lower level of the
products;
� examine the compatibility of interfaces;
� review the system TS and allow the start of work on subsystems.
12 © ISO 2001 – All rights reserved
8.2.4.3.2 Preliminary design review
The authority responsible for the milestone crossing may request that the “transition phase B to phase C document”
be examined during a review called “preliminary design review” (PDR). The purpose of this review is to approve the
system TS, the frame of the system, the associated lower TSs and the development plan.
NOTE 1 Phase A and B activities are iterative and tend to clarify progressively requirements thus making possible solutions
more evident.
NOTE 2 If there are several level 1 suppliers, then arrangements should be made to ensure the consolidation and coherency
of level 0.
8.2.5 Development (phase C) and production (phase D) phases
8.2.5.1 Merger of phases C and D
Phases C and D may be merged into one unique C/D phase if the programme leads to the manufacturing of a
single flight unit or of a very small quantity of product.
The choice shall be determined by the level 0 customer.
8.2.5.2 Integrated C/D phase
This programme phase consists of making a detailed study of the solution selected upon completion of the
definition phase and subsequently manufacturing qualification model(s) and flight model(s). The purpose of this
phase is to obtain a qualified design of the deliverable products required for system operation and support.
This integrated phase starts by the milestone crossing of the PDR and corresponds to the acceptance of “transition
phase B to phase C documents” issued during the previous phase.
This phase shall include, as a minimum, the tasks necessary to complete the designed state of the system and of
each of its components (critical design reviews, CDR).
On the basis of the verifications made during this phase and during qualification tests, the qualification process
shall show that this design meets the specified requirements (qualification review, QR).
Product design qualification and flight model acceptance complete the C/D phase.
8.2.5.3 Separate development (phase C) and production (phase D) phases
8.2.5.3.1 Development phase (phase C)
This programme phase consists of making a detailed study of the proposal selected upon completion of the
definition phase. The purpose of this phase is to obtain a qualified design for the mass production of deliverable
products required for system operation and support.
Phase C starts by the milestone crossing of the PDR and corresponds to the acceptance of the “transition phase B
to phase C documents” issued during the previous phase.
This phase shall include, as a minimum, the tasks necessary to complete the designed state of the system and of
each of its components (CDRs).
During this development phase, the “production plan” is established by the supplier and gives the general
manufacturing schedule at the highest level of the WBS. It includes the elements provided by its own suppliers. The
manufacturing plan shall be issued under the responsibility and authority of the level 1 customer and, once issued,
marks the start of the following phase.
The production plan defines a production cycle of one element which is to be used as a reference. Consequently,
any risks due to disturbances on the standard production line can be established.
This plan outlines the mass production scheme (see 9.3) and specifies the key events, as follows, that may be
selected for stages of payment and follow-up scheduling:
� manufacturing preparation;
� procurement;
� manufacturing start;
� technical evaluations prior to acceptance tests;
� final acceptance.
The qualification process started during the development phase shall be based on verification made throughout the
development phase as well as qualification tests. Results from the qualification process shall demonstrate that the
product design meets the specified requirements and that it can be produced.
Qualification of the product design marks the end of the development phase (QR, qualification review).
8.2.5.3.2 Production phase (phase D)
This phase consists of manufacturing and delivering to the user the production ordered in compliance with the
designed stage of the product.
It starts with the milestone crossing corresponding to the acceptance of the “production plan” issued during the
previous phase.
Two processes may be identified within this production phase: the mass production process and the acceptance
process for each finished product after a performance check by a pre-shipment review. This pre-shipment review
authorizes the shipment of the product after checking its conformity with respect to the project objectives
(performances, configuration and waivers) and the operational status of the system.
For reasons of scheduling, some procurements may be started prior to the production phase.
8.2.5.4 Utilization phase (phase E)
During this phase, the system and the resources required to fulfil its operational mission are put into service, used
and supported.
The acknowledgement by the system user of its fitness for use conditions the beginning of its operational life.
8.2.5.5 Disposal phase (phase F)
This phase consists of the preparation and completion, in a co-ordinated way and in conformity with the applicable
rules, of the complete or partial discontinuance of system operation and dismantling of the products and associated
resources.
NOTE 1 This phase starts with a decision of complete or partial disposal.
NOTE 2 The dismantled products can be destroyed, stored, transformed or assigned to another utilization within the
framework of other programmes.
NOTE 3 This phase may lead to establishing a historical record and an analysis of the programme (performances upon
completion, life cycle cost, statistics, etc.).
14 © ISO 2001 – All rights reserved
8.3 Product stages — Associated processes and documents
8.3.1 General
The set of successive product stages is usually called the product “life cycle”. The different product stages, in
relation to the phases of the programme, are indicated in Figure 2.
For a given intermediate level, the transition from the specified stage to the designed stage is a complex process or
a number of processes progressively incorporating the design formulated at the lower level. The transition from a
given stage to the following one is achieved by applying one or several processes as shown in Figure 3.
The different product stages are described in 8.3.2 to 8.3.6 and illustrated in Figure 2.
These stages shall be identified and recorded in the documentation system specified in clause 12.
As soon as a given product stage is attained, the CM procedure shall be implemented in accordance with
clause 10.
8.3.2 Functional stage
This product stage defines and implements the service functions expected from the product.
This stage originates following the customer’s request and is expressed in a FS or any other similar document.
The purpose of the FS, drafted under the customer’s responsibility and authority, consists in expressing the
customer’s requirements in terms of the service functions expected from the product. Both the constraints of
utilization, and flexibility, in the various phases shall also be explicitly expressed in this document.
The FS shall be drafted progressively and justified in respect to the initial customer request based on results from
studies performed during the process of determining requirements.
The FS and its associated justifications are to be managed in accordance with the customer's in-house procedure.
The functional stage is completed once the FS is issued. The FS becomes the reference FS at the end of phase A.
8.3.3 Specified stage
This product stage is initiated once the reference FS or the TS of the higher level is established. It consists of
processes for establishing a preliminary design and in further defining requirements. The results shall be recorded
in the TS.
The purpose of the TS drafted under the customer’s responsibility and authority is to define requirements in terms
compatible with the reference FS or the TS of the higher level and to describe the selected concept taking into
account the performance, cost and schedule requirements. It shall therefore express:
� the functional requirements associated with the various features of the projects planned taking into account
environmental conditions;
� the dependability and safety requirements;
� the requirements concerning interfaces;
� the requirements concerning design and production (prescribed or prohibited proposals, standards, etc.);
� the requirements concerning qualification and acceptance related to the verifications to be provided by the
supplier.
FS Functional specification PRR Preliminary requirements review
TS Technical specification PDR Preliminary design review
DF Design data file CDR Critical design review
EIDP End item data package QR Qualification review
LB Log book
Continuous lines correspond to product stages
Figure 2 — Relationships between programme phases and product stages
16 © ISO 2001 – All rights reserved
FS Functional specification
TS Technical specification
DF Design data file
Figure 3 — Approved configurations
Results of the studies and tests performed when issuing the TS shall make it possible to compare the TS with the
reference FS or the TS of the higher level.
The corresponding documents shall be compiled in a justification file of the TS.
The reference specified stage is achieved by the approval of the TS which takes into account the concept selected
for development.
8.3.4 Designed stage
8.3.4.1 General
This stage is initiated once a set of data can be established to fully identify the design of the product for
manufacturing, inspection, use and support processes. It is expressed in the DF drafted by the supplier.
The designed stage is established once the DF is approved after qualification (called qualified DF).
8.3.4.2 Design data file
The DF shall show the levels corresponding to the requirements associated with operation, maintenance and
logistics and in particular identify:
� all supply items;
� all elements separable in use and/or deliverable as spares;
� the regrouping of products based on elements defined separately;
� the specific designs adapted to specific situations (situations concerning packaging, storing, delivery, standard
or specific utilization, etc.) as well as changes allowing a switch from
...
NORME ISO
INTERNATIONALE 14300-1
Première édition
2001-05-15
Systèmes spatiaux — Management de
programme —
Partie 1:
Structuration d'un programme
Space systems — Programme management —
Part 1: Structuring of a programme
Numéro de référence
©
ISO 2001
PDF – Exonération de responsabilité
Le présent fichier PDF peut contenir des polices de caractères intégrées. Conformément aux conditions de licence d'Adobe, ce fichier peut
être imprimé ou visualisé, mais ne doit pas être modifiéà moins que l'ordinateur employéà cet effet ne bénéficie d'une licence autorisant
l'utilisation de ces polices et que celles-ci y soient installées. Lors du téléchargement de ce fichier, les parties concernées acceptent de fait la
responsabilité de ne pas enfreindre les conditions de licence d'Adobe. Le Secrétariat central de l'ISO décline toute responsabilité en la
matière.
Adobe est une marque déposée d'Adobe Systems Incorporated.
Les détails relatifs aux produits logiciels utilisés pour la créationduprésent fichier PDF sont disponibles dans la rubrique General Info du
fichier; les paramètres de création PDF ont été optimisés pour l'impression. Toutes les mesures ont été prises pour garantir l'exploitation de
ce fichier par les comités membres de l'ISO. Dans le cas peu probable où surviendrait un problème d'utilisation, veuillez en informer le
Secrétariat central à l'adresse donnée ci-dessous.
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publication ne peut être reproduite ni utilisée sous quelque
forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans l'accord écrit de l’ISO à
l’adresse ci-aprèsouducomité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 56 � CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax. + 41 22 749 09 47
E-mail copyright@iso.ch
Web www.iso.ch
Imprimé en Suisse
ii © ISO 2001 – Tous droits réservés
Sommaire Page
Avant-propos.iv
Introduction.v
1 Domaine d'application.1
2Références normatives .1
3Termesetdéfinitions.2
4Termesabrégés .2
5Spécification et plan de management d’un programme.2
6 Organigramme des tâches.4
7 Organisation d’un programme .7
8 Logique de déroulement d’un programme .9
9 Management des coûts et des délais .20
10 Gestion de la configuration .23
11 Soutien logistique intégré.25
12 Gestion de la documentation et de l’information.27
13 Management des risques.31
Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes nationaux de
normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est en général confiéeaux
comités techniques de l'ISO. Chaque comité membre intéressé par une étudealedroit de fairepartie ducomité
technique créé à cet effet. Les organisations internationales, gouvernementales et non gouvernementales, en
liaison avec l'ISO participent également aux travaux. L'ISO collabore étroitement avec la Commission
électrotechnique internationale (CEI) en ce qui concerne la normalisation électrotechnique.
Les Normes internationales sont rédigées conformément aux règles données dans les Directives ISO/CEI, Partie 3.
Les projets de Normes internationales adoptés par les comités techniques sont soumis aux comités membres pour
vote. Leur publication comme Normes internationales requiert l'approbation de 75 % au moins des comités
membres votants.
L’attention est appelée sur le fait que certains des éléments delaprésente partie de l’ISO 14300 peuvent faire
l’objet de droits de propriété intellectuelle ou de droits analogues. L’ISO ne saurait être tenue pour responsable de
ne pas avoir identifié de tels droits de propriété et averti de leur existence.
La Norme internationale ISO 14300-1 a étéélaborée par le comité technique ISO/TC 20, Aéronautique et espace,
sous-comité SC 14, Systèmes spatiaux, développement et mise en œuvre.
L'ISO 14300 comprend les parties suivantes, présentées sous le titre général Systèmes spatiaux — Management
de programme:
� Partie 1: Structuration d'un programme
� Partie 2: Assurance produit
iv © ISO 2001 – Tous droits réservés
Introduction
La présente partie de l'ISO 14300 présente une vue d'ensemble du management d’un programme spatial et les
exigences associées dans le but d'optimiser les performances, les coûts et les délais et de minimiser les risques.
Le management de programme est inhérent à tout programme, mais, dans le domaine de l'espace, il est
particulièrement important dû:
� aux conditions d’environnement particulières à l'espace;
� au besoin d’obtenir des performances de haut niveau;
� au nombre limité de modèles récurrents;
� à l'accès limité au produit pendant les opérations;
� à la quasi-impossibilité de réparation en cas d’incident pendant le vol;
� à la complexité souvent très importante de l’organisation;
� aux coûts élevés associés.
La mise en œuvre d’un ensemble normalisé d’exigences de management de programme devrait encourager et
faciliter la coopération internationale dans le domaine de l'espace.
NORME INTERNATIONALE ISO 14300-1:2001(F)
Systèmes spatiaux — Management de programme —
Partie 1:
Structuration d'un programme
1 Domaine d'application
La présente partie de l'ISO 14300 établit les exigences de management d’un programme spatial applicables dans
les relations contractuelles entre les clients et les fournisseurs, dans une démarche descendante. Les exigences
applicables à l’assurance produit sont données dans l’ISO 14300-2.
La présente partie de l'ISO 14300 est à utiliser comme base pour l’établissement et la négociation des exigences
de management de programme du client, et pour orienter les réponses du fournisseur.
Elle permet:
� une définition claire des rôles, des responsabilités et des autorités des différents clients et fournisseurs;
� une cohérence entre leurs activités;
� une capacité de communication entre eux;
� une organisation du programme stable et rigoureuse;
� et, dans la mesure du possible, la normalisation des règles applicables à différents programmes.
Elle permet une flexibilité du fournisseur dans sa mise en œuvre et son adaptation.
2Références normatives
Les documents normatifs suivants contiennent des dispositions qui, par suite de la référence qui y est faite,
constituent des dispositions valables pour la présente partie de l'ISO 14300. Pour les références datées, les
amendements ultérieurs ou les révisions de ces publications ne s’appliquent pas. Toutefois, les parties prenantes
aux accords fondés sur la présente partie de l'ISO 14300 sont invitées à rechercher la possibilité d'appliquer les
éditions les plus récentes des documents normatifs indiqués ci-après. Pour les références non datées, la dernière
édition du document normatif en référence s’applique. Les membres de l'ISO et de la CEI possèdent le registre des
Normes internationales en vigueur.
ISO 9000:2000, Systèmes de management de la qualité— Principes essentiels et vocabulaire.
ISO 9001:2000, Systèmes de management de la qualité— Exigences.
ISO 10007:1995, Management de la qualité— Lignes directrices pour la gestion de configuration.
1)
ISO 14300-2:— , Systèmes spatiaux — Management de programme — Partie 2: Assurance produit.
3 Termes et définitions
Pour les besoins de la présente partie de l'ISO 14300, les termes et définitions donnés dans l'ISO 9000
s'appliquent.
4 Termes abrégés
AC Article de configuration
ASL Analyse du soutien logistique
CdCF Cahier des charges fonctionnel
DD Dossier de définition
DU Documentation utilisateur
FDLT Fiche de description de lots de travaux
LS Livret suiveur
OT Organigramme des tâches
PRR Revue préliminaire des exigences
RCD Revuecritiquededéfinition
RCI Registre de contrôle individuel
RDP Revue de définition préliminaire
RQ Revue de qualification
SLI Soutien logistique intégré
STB Spécification technique de besoin
5Spécification et plan de management d’un programme
5.1 Généralités
L’obtentiondelaqualité tout au long de l’exécution du programme est l’objectif du management dans son
ensemble.
Les exigences stipulées dans l'ISO 9001 sont supposées être prises en compte par les sociétés impliquées dans
les programmes spatiaux.
Lorsqu’un client de niveau 0 (le premier niveau émettant un contrat dans la chaîne contractuelle) a l’intention de
fairede laprésente partie de l'ISO 14300 une condition contractuelle, il doit inclure dans sa demande (demande de
proposition, appel d’offres, demande de cotation, etc.) une spécification de management du programme dédiée
pour qu’elle soit appliquée par tous les clients et fournisseurs de rang inférieur.
L’application des exigences depuis le client de niveau 0 jusqu’au rang le plus bas des fournisseurs dans la chaîne
contractuelle doit être compatible avec la criticité du produit à fournir, sa complexité et son coût, et donc un
1) À publier.
2 © ISO 2001 – Tous droits réservés
allégement des exigences appliquées aux fournisseurs de produits moins critiques peut être recherché.
Cependant, la continuité et la cohérence des exigences du programme doivent être maintenues. La sélection et
l’adaptation de la présente partie de l'ISO 14300 est exigée au niveau du client. Toute adaptation de la présente
partie de l'ISO 14300 doit être fondée sur des objectifs et des contraintes spécifiques.
En fonction du contrat reçu de son propre client, le fournisseur, à un niveau donné, doit adapter les exigences de
management à ses propres fournisseurs, mais de façon à pouvoir respecter ses propres obligations envers son
client (voir Figure 1).
Les fournisseurs doivent préparer un plan de management, afin de répondre à la spécification de management
reçue de leur client.
Figure 1—Établissement des règles de management d’un programme
5.2 Spécification de management d’un programme
Selon la nature du programme ou de la phase du programme, la spécification de management de programme doit
être émise par le client de niveau 0 et, partant de la présente partie de l'ISO 14300, peut inclure des exigences
additionnelles, ou, au contraire, certains éléments peuvent être supprimés.
Visant à l’harmonisation et selon l’applicabilité négociée, la formulation des articles 5 à 13 ci-après et le contenu de
l'ISO 14300-2 sont destinés àêtre directement intégrés, autant que possible, dans toute spécification de
management de programme.
Chaque fournisseur à un niveau donné joue le rôle de client pour ses propres fournisseurs et doit spécifier les
exigences de management dans les contrats considérés, dans un document spécifique ou dans les clauses
techniques.
5.3 Plan de management d’un programme
En réponse à cette spécification de management de programme, chaque fournisseur concerné prépareunplande
management du programme, qui contient la description des principales activités, des méthodes de mise en œuvre
et des procédures générales relatives à son organisation.
Les politiques et procédures existantes chez le fournisseur et autres moyens de management peuvent être utilisés
s’ils sont appropriés, et, dans ce cas, il convient qu’elles soient consultables par le client.
Le fournisseur est encouragéà recommander les adaptations à chaque exigence spécifiée, là où une variation, en
conformité avec les conditions spécifiées, répond à l’intention de l’exigence et peut permettre une meilleure
planification des délais ou des économies pour le programme. De telles adaptations des exigences doivent être
identifiées dans le plan de management du fournisseur afin de faciliter leur revue par le client.
Le plan de management du programme doit être soumis au client pour acceptation. Le plan, accepté par le client,
devient la référence pour la détermination du respect des exigences de management du programme.
6 Organigramme des tâches
6.1 Généralités
L'organigramme des tâches (OT) du programme est le système de référence des données de management du
programme qui:
� assure la cohérence entre les activités techniques, documentaires, administratives et financières de tout le
programme;
� identifie les responsabilités et autorités de chaque fournisseur.
Les règles à observer pour établir, modifier et utiliser l’OT sont spécifiées ci-après.
6.2 Objectifs
L’OT du programme est la décomposition structurée et complète de tout le programme, analysant, sur la base de
l’arborescence produit (voir 6.4.3) ou de l’arborescence fonction (voir 6.4.2), les tâches et les ressources
2)
principales requises pour finaliser les produits satisfaisant aux exigences exprimées.
L’organigramme est réalisé de manière homogène aux différents niveaux de responsabilité et d’autorité.
L’OT du programme est utilisé comme une référence commune et unique pour le client niveau 0 et les
fournisseurs, pour identifier toutes les tâches requises pour réaliser le programme (exhaustivité), que les tâches
soient:
� imputées au budget du programme ou non;
� de la responsabilité et de l'autorité des fournisseurs ou d’autres organismes.
2) Les ressources principales incluent le développement de tous les produits matériels ou logiciels (bancs d’essai, outillages)
nécessaires pour le programme et aussi les ressources requises pour l’adaptation ou la réutilisation de moyens existants, ceux
dont l’indisponibilité serait une contrainte pour le programme.
4 © ISO 2001 – Tous droits réservés
L’OT du programme permet d’assurer la gestion, la planification, l’exécution et le contrôle de toutes les tâches
impliquées par le programme.
6.3 Responsabilité et autorité pour l’établissement de l’organigramme des tâches
Chaque fournisseur doit:
� établir l‘arborescence produit pour ses propres fournitures, en la limitant aux interfaces avec son client et ses
propres fournisseurs;
� exprimer ses exigences concernant l’établissement de l’OT à ses fournisseurs.
Ces exigences sont associées en particulier avec l’organisation du programme (voir article 7) et les articles de
configuration, AC (voir article 10).
6.4 Règles pour l’établissement de l’OT
6.4.1 Aspects principaux
La codification des tâches, des ressources et des produits (et, éventuellement, des fonctions) doit êtreuniqueet
constante dans le temps.
Les tâches à réaliser doivent être liées à chaque niveau de l’arborescence produit (voir 6.4.3).
Tant que l’arborescence produit du système n’est pas définie, il est possible d’associer les tâches aux fonctions de
l’arborescence fonction (voir 6.4.2).
Les ressources principales à utiliser pour la réalisation de chaque tâche doivent être indiquées de façon claire.
Si des ressources impliquées dans le programme sont à développer (ressources spécifiques), elles doivent être
considérées de la même façon que les produits à fournir.
6.4.2 Arborescence fonction
L’arborescence fonction est la structure résultant de la décomposition des performances du système en fonctions.
Chacune d’entre elles peut être décomposée en sous-fonctions, indépendamment du produit lui-même.
Le rattachement des tâches aux fonctions est particulièrement adapté au début du programme, c'est-à-dire jusqu’à
la phase de définition du système (phases 0, A et B, voir 8.2).
Au niveau système, l’arborescence fonction permet d’assurer la cohérence du système ainsi que la maîtrisedela
configuration.
6.4.3 Arborescence produit
L’arborescence produit décrit la structure descendante du produit, c'est-à-dire depuis le niveau du système lui-
même, jusqu’au niveau sous-systèmes, équipements, composants, de manière appropriée.
Tous les éléments de l’arborescence produit sont soumis au contrôle de configuration, leurs identifiants sont
compatibles avec les lots de travaux et la documentation associée.
L’approche produit est basée sur une connaissance a priori, ou acquise, depuis le début du programme, des
produits à fournir.
L’arborescence produit doit être établie, au plus tard, àlafindelaphaseB(voir8.2.4).
Les produits à faire apparaître dans l’arborescence produit doivent comprendre, au minimum, chaque produit
faisant l’objet d’une STB.
6.4.4 Tâches
Les tâches peuvent être décrites dans la fiche de description de lot de travaux (FDLT).
NOTE La FDLT contient les informations associées aux tâches et aux lots de travaux.
Chaque tâche est caractérisée principalement par:
a) la relation client/fournisseur;
b) une personne ou organisation unique et identifiée;
c) son contenu, incluant:
� un titre,
� un objectif (par exemple un essai de qualification),
� une description indiquant les tâches exclues, si nécessaire,
� le type de tâche (étude, production, assurance produit, management, essai, etc.);
d) son lien à un constituant (produit ou fonction);
e) ses contraintes de planification, incluant:
� la duréeprévue,
� l’événement(s) d’entrée(s) et les données correspondantes,
� l’événement(s) de sortie(s) et les données correspondantes,
� si nécessaire, des événements intermédiaires (événements clés);
f) ses conditions d’exécution;
g) les ressources requises pour son exécution.
Les ressources doivent être associées à la tâche qui les met en œuvre.
6.5 Règles pour le management des évolutions de l’OT
Les évolutions dans l’OT ne doivent pas modifier sa structure, afin de ne pas interrompre le management du
programme.
Chaque produit, fonction, ressource ou tâche ajoutés doit être associéà une nouvelle identification (l’emploi
d’identificateurs déjà utilisés à une étape précédente n’est pas admis).
Les évolutions prennent en compte les modifications des services et/ou des exigences obligatoires qui doivent être
accomplis conformément aux spécifications contractuelles (modification des clauses, correctifs, etc.)
6 © ISO 2001 – Tous droits réservés
7 Organisation d’un programme
7.1 Généralités
La mise en œuvre d’une organisation du programme est requise afin d’assurer la cohérence et le contrôle de
l’exécution du programme.
Le but de cet article est de définir les principes d’organisation (organisation aux niveaux du client et de l’industrie
pour le management du programme) et de spécifier les exigences d’organisation concernant les circuits
d’information, internes et externes au programme et à son environnement.
Sur la base des données contractuelles, ce paragraphe est utilisé par les différents fournisseurs du programme
commeunmodèle pour la mise en œuvre de l’organisation à chaque niveau.
7.2 Principes
L’organisation à mettre en œuvre doit prendre en compte les phases concernées du programme, la nature des
tâches à exécuter et les niveaux de responsabilité et d’autorité associés.
La préparation, la définition et la mise en œuvre de l’organisation du programme doivent être prévues
conformément aux phases du programme (voir 8.2).
Le mode de management le plus simple et le plus efficace de même que les relations contractuelles retenues
doivent être déterminées en prenant en compte les aspects spécifiques du programme, que ce soit au niveau
national ou international.
Leresponsabledeladéfinition et de la mise en œuvre de l’organisation du programme doit être identifié.
Les responsabilités et autorités de management du programme et de passation des contrats doivent être
identifiées afin de prévoir les incidences contractuelles et juridiques.
Chaque organisation de programme doit être cohérente en termes contractuels et techniques.
Si le programme est associéà d’autres programmes, les responsabilités et autorités concernant la définition des
interfaces et le management doivent être spécifiées et prises en compte dans la mise en œuvre de l’organisation
du programme.
7.3 Exigences d’organisation
7.3.1 Généralités
Les phases du programme exigeant la mise en œuvre efficace d’une organisation de programme (faisabilité,
définition, développement, production, utilisation) doivent être spécifiées. Les évolutions du programme peuvent
conduire à des modifications à appliquer à l’organisation, pendant la réalisation du programme.
Quand plusieurs fournisseurs jouent, conjointement, un rôle similaire, leurs responsabilités et autorités respectives
doivent être définies. Quand un fournisseur joue simultanément plusieurs rôles dans le même programme, ces
rôles doivent être clairement définis et exécutés de manière distincte. Pour des raisons d’efficacité, cependant, une
autorité unique peut les contrôler.
Chaque fournisseur doit identifier et assigner les responsabilités et autorités principales et mettre en œuvre
l’organisation interne afin de satisfaire aux exigences contractuelles.
Chaque client et fournisseur est censé jouer le rôle qui lui a été assigné pendant tout le programme. Quand
plusieurs organisations externes et/ou départements internes sont impliqués, les responsabilitéset autoritésde
chacun et leurs interfaces doivent être clairement documentées et les mesures appropriées prises afin d’assurer
leur coordination. Ces mesures doivent en particulier définir la nature des informations àéchanger entre clients et
fournisseurs.
7.3.2 Exigences
Les rôles des fournisseurs du programme doivent être définis explicitement et, en particulier, l’organisation du
programme doit indiquer le responsable de chaque activité requise par la spécification de management du
programme, c'est-à-dire:
� management du programme;
� management des contrats;
� maîtrise des coûts et des délais;
� ingénierie;
� achats;
� SLI;
� assurance produit;
� gestion de la configuration et de la documentation.
Les interfaces et les relations avec le management de la société doivent être indiquées. L’application des règles de
management et leur efficacité en ce qui concerne les activités du programme exécutées ou sous-contractées
doivent être vérifiées par des audits planifiés et documentés, par analyse d’indicateurs et/ou par revues, suivant les
dispositions contractuelles.
7.4 Information et communication
7.4.1 Circuits d’information
Des règles régissant l’organisation des circuits d’information doivent:
� définir la liste et le rôle des clients et des fournisseurs du programme;
� spécifier les informations àéchanger entre les acteurs et le calendrier des échanges.
Les modalitésd’établissement, d’évolution et d’application de ces règles doivent être précisées.
7.4.2 Rapports d’avancement
Pour le fournisseur et le client, le but de ces rapports consiste en l’évaluation de l’avancement des activités
concernant les aspects techniques et commerciaux, la performance et les délais du programme.
Le contenu et la périodicité de ces rapports doivent être définis contractuellement. Les réunions d’avancement
doivent avoir lieu seulement si nécessaire.
7.4.3 Prérogatives du client
Lorsque l’applicationdelaprésente partie de l'ISO 14300 fait l’objet d’un accord entre un client et un fournisseur, il
convient que cet accord établisse le niveau approprié auquel le client veut:
� contrôler l’application des exigences de management chez le fournisseur;
� conduire ou participer à des audits ou à des revues du fournisseur;
� être informé de l’avancement de la conception, de la fabrication, des inspections et des essais.
8 © ISO 2001 – Tous droits réservés
Il convient que les prérogatives nécessaires au client pour accomplir les tâches ci-dessus soient précisées par les
modalitésdel’accord client-fournisseur. Il convient que ces dispositions couvrent:
� la visite des locaux du fournisseur direct;
� la définition des modalités à inclure dans les accords du fournisseur direct avec les fournisseurs de rang
inférieur concernant les visites de client de niveau supérieur;
� la désignation de représentants permanents ou non, résidant dans les locaux du fournisseur;
� la délégation de tout ou partie de ses prérogatives à des organisations nationales de surveillance ou à d’autres
organisations spécialisées.
7.4.4 Gestion des actions
À travers les activités du programme, les actions résultant des relations avec le client (par exemple les réunions,
échange de courrier, événements clés, revues) et/ou celles déterminées par le fournisseur comme partie de
l’application des règles de management doivent être maîtrisées. Chaque action est définie par un identificateur, un
libellé clair et non ambigu, un demandeur, un responsable de son achèvement et les délais d’aboutissement (date
fixe ou événement du programme).
La finalisation de l’action doit être formalisée et acceptée par le demandeur sur présentation des justificatifs
correspondants.
7.4.5 Indicateurs techniques et de management
Depuis le début du programme, des indicateurs techniques et de management, en particulier ceux mettant en
évidence la qualité du produit et le fonctionnement de l’organisation, doivent être formellement définis, mis en
œuvre, utiliséset mis à jour à travers les activités du programme. Dans le cas d’indications significativement
défavorables, des dispositions doivent être prises en fonction de l’exploitation des résultats.
Ces indicateurs sont définis entre le client et le fournisseur et doivent rester confidentiels.
8 Logique de déroulement d’un programme
8.1 Généralités
L’objectif de la logique de déroulement du programme est de minimiser les risques techniques, économiques et de
délais du programme en introduisant des phases et des jalons formalisés, permettant de montrer que l’avancement
du programme est maîtrisé vis-à-vis des objectifs techniques, de coûts et de délais.
Cet objectif est atteint en découpant le cycle de vie du produit en phases distinctes, liées entre elles et dont les
objectifs et le contenu doivent être clairement définis.
Chaque jalon consiste en un processus formel de revue, en corrélation avec les configurations de référence
soumises à la gestion de configuration. Les résultats sont consignés dans une documentation appropriée.
Le nombre de phases et leurs objectifs doivent être définis au début du programme et peuvent être adaptés pour
minimiser les risques techniques, de coûtetde délai pouvant compromettre le succès du programme.
La composition et le contenu des phases doivent être déterminés par le client de niveau 0 dans la spécification de
management jointe au contrat et basée sur la présente partie de l'ISO 14300.
8.2 Phasage d’un programme
8.2.1 Principes
Le déroulement peut être structuré en sept phases. Le démarrage d’une phase coïncide avec le franchissement
d’un jalon, décision prise par le client de niveau 0 (ou son autorité supérieure) à un niveau système donné.Cela
intervient généralement à la suite d’une revue spécifique évaluant les résultats des activitésdelaphase qui se
termine, les prévisions de la phase suivante et les risques identifiés.
Le franchissement des jalons pour les niveaux inférieurs est soumis à la décision des clients concernés.
Le but d’une revue est d’effectuer une vérification critique par une équipe non directement concernéepar les
activitéset vise à aider à:
� évaluer la validité des éléments techniques en relation avec les prévisions et les exigences contractuelles;
� faciliter l’application des actions correctives et/ou préventives en cas de dérive ou d’insuffisance;
� matérialiser la transition vers l’étape suivante;
� décider de franchir le jalon concerné.
8.2.2 Phase d’analysedemission (phase0ou préphase A)
Cette phase consiste en une première définition de la mission à effectuer et en une première évaluation des
concepts à considérer dans la phase de faisabilité.
Les résultats des activités effectuées pendant cette phase sont:
� l’identification et la caractérisation de la mission;
� une première expression des performances requises et des objectifs à atteindre, par exemple sûreté de
fonctionnement et sécurité;
� une évaluation initiale des contraintes opérationnelles et de production, y compris les conditions
d’environnement;
� l’identification des solutions possibles avec les points critiques associés, en prenant en compte le retour
d’expérience des programmes spatiaux en cours;
� une première appréciation des éléments programmatiques (organisation, coûts, délais).
Les résultats des ces activitéssont résumés dans un document de transition de la phase 0 à la phase A, incluant
un cahier des charges fonctionnel (CdCF) provisoire, comme base de décision d’initialisation de la phase de
faisabilité.
8.2.3 Phase de faisabilité (phase A)
8.2.3.1 Objectifs
Cette phase du programme consiste en l’exploration de plusieurs concepts possibles, en conformité avec les
objectifs exprimés (performance, coûts, délais).
Elle permet, à la fin de la phase:
a) l’édition de l’arborescence fonction;
10 © ISO 2001 – Tous droits réservés
b) de définir formellement les objectifs de l’utilisateur dans:
� un CdCF de référence,
� une version préliminaire de la STB au niveau du système;
c) la présentation de chaque concept examiné dans un avant-projet associéà une proposition financière (coûts
et délais) pour la phase de définition;
d) l’estimation de la faisabilité technique et delafabricationainsi quel’identification des points critiques de
chaque concept (performance, coûts, délais, technique et coût du soutien).
8.2.3.2 Documentation
Cette phase se termine par l’établissement d’un document de transition phase A à phase B sous la responsabilité
et l'autorité du client de niveau 1.
Ces documents doivent en particulier souligner:
� la faisabilité des solutions qui répondent aux exigence prévues;
� la description générale des solutions possibles, en indiquant les éléments principaux de chaque solution
(performance, coûts, délais, risques) et la recommandation d’une solution proposée;
� l’organisation des phases suivantes (structures, ressources, etc.) et, en particulier, les éléments qui permettent
le démarrage de la phase de définition (OT, coûts, délais, etc.).
L’autorité responsable du franchissement du jalon peut exiger que les résultats de la phase A soient examinés
entièrement ou partiellement pendant une revue dite «revue préliminaire des exigences» (PRR).
8.2.4 Phase de définition (phase B)
8.2.4.1 Objectifs
Cette phase du programme consiste à choisir, parmi les solutions retenues à l’issue de la phase de faisabilité,celle
à développer, et à spécifier les exigences à respecter.
Elle débute par le franchissement du jalon associéà l’acceptation des résultats de la phase A.
Elle permet:
� d’étudier les solutions techniques retenues précédemment, de comparer leurs performances et risques (aux
plans techniques, coûts, délais);
� de figer la STB au niveau du système;
� d’établir les spécifications techniques de besoin de premier niveau et, si possible, l’arborescence fonction à
respecter par l’ensemble des spécifications;
� d’évaluer les caractéristiques de sûreté de fonctionnement et de sécurité;
� de décider la solution à développer, compte tenu notamment de la proposition financière correspondante;
� de constituer le document de transition de la phase B à la phase C.
8.2.4.2 Documentation
8.2.4.2.1 Généralités
Les documents suivants, établis sous la responsabilité et l’autorité du client de niveau 1, doivent être rassemblés
avec la STB et les documents établis par le fournisseur:
� le plan de management, y compris le plan de développement;
� l’OT (voir article 6);
� les STB de premier niveau et, si possible, les clauses techniques associées;
� le dossier de définition (DD) préliminaire et sa justification associée.
8.2.4.2.2 Documents de transition de la phase B à la phase C
Ces documents doivent, en particulier, souligner:
a) l’expression correcte et complète des exigences au moyen de la STB. Cette STB doit être comparée aux
exigences prévues afin de vérifier qu’il n’y a aucune incohérence entre les exigences prévues et définies par
l’utilisateur dans le CdCF de référence et les exigences techniques et contractuelles exprimées dans la STB;
b) la définition d’une solution ayant été suffisamment examinée et qui doit respecter les exigences. Cette
définition est décrite, en général, dans un DD préliminaire, qui définit en particulier l’architecture des
constituants principaux. Cette définition doit permettre l’identification des différents points critiques dans le
développement et dans la production;
c) l’organisation de la phase de développement avec:
� l’organisation des tâches à exécuter,
� les délais d'achèvement, incluant les événements clés,
� les méthodes qui permettent aux différents risques identifiésd’être maîtrisés;
d) la justification des coûts estimésdelaphasede développement.
8.2.4.2.3 Plan de développement
À la findelaphaseB,leplan de développement, établi par le client de niveau 1, et prenant en compte les
exigences de son client et les éléments de ses propres fournisseurs, doit décrire la logique du déroulement de la
phase permettant d’effectuer de manière satisfaisante le développement des produits sous sa responsabilité et son
autorité et, en particulier:
� l’enchaînement des tâches;
� les étapes obligatoires (événements clés);
� les points d’avancement significatifs du développement et de la vérification de la définition (émission de la
documentation, fabrication des modèles, essais, revues, etc.).
Après approbation par le client de niveau 0, il devient le document de management et de suivi de l’activité.
12 © ISO 2001 – Tous droits réservés
8.2.4.3 Revues
8.2.4.3.1 Revue des exigences système
Pendant la phase B, il convient d'effectuer une revue des exigences système pour:
� examiner la compatibilité de l’architecture du système et les allocations de performances aux niveaux
inférieurs de l’arborescence produit;
� examiner la compatibilité des interfaces;
� examiner la STB du système et permettre le démarrage des activités des sous-systèmes.
8.2.4.3.2 Revue de définition préliminaire
L’autorité responsable du franchissement du jalon peut demander que le document de transition de la phase B à la
phase C soit examiné pendant une revue dite «revuededéfinition préliminaire» (RDP). Elle a pour but d'approuver
la STB système, l’architecture du système, les STB de niveau inférieuretleplandedéveloppement.
NOTE 1 Les activités de la phase A et de la phase B présentent un caractère itératif à mesure que les exigences deviennent
plus claires et que les concepts de solutions possibles apparaissent.
NOTE 2 S’il y a plusieurs fournisseurs de niveau 1, il doit exister des dispositions permettant la consolidation et la cohérence
à assurer au niveau 0.
8.2.5 Phases de développement (phase C) et de production (phase D)
8.2.5.1 Fusion des phases C et D
Les phases C et D peuvent être réunies dans une phase unique C/D, si le programme consiste dans la fabrication
d’un seul exemplaire de vol ou d’une très petite quantité.
Le choix est à déterminer par le client de niveau 0.
8.2.5.2 Phase C/D intégrée
Cette phase du programme consiste en une étude détailléedela solution sélectionnéesuite à l’achèvement de la
phase de définition et dans la fabrication du ou des modèles de qualification et de vol afin d’atteindre une définition
qualifiée des produits livrables requis pour les opérations et le soutien du système.
Elle débute par le franchissement du jalon de la RDP, qui représente l’acceptation des documents de transition de
la phase B à la phase C, établis pendant la phase précédente.
Elle inclut, au moins, les tâches permettant l’achèvement de l’état défini du système et de chacun de ses
constituants (revues critiques de définition, RCD).
Sur la base des vérifications effectuées pendant la phase et des essais de qualification, le processus de
qualification permet de démontrer que la définition répond aux exigences spécifiées (revue de qualification, RQ).
La qualification de la définition du produit et l’acceptation du modèle de vol terminent la phase C/D.
8.2.5.3 Phases séparées de développement (phase C) et de production (phase D)
8.2.5.3.1 Phase de développement (phase C)
Cette phase du programme consiste en une étude détailléedelasolutionsélectionnée aprèsl’achèvement de la
phase de définition, afin d’aboutir à une définition qualifiée adaptée à la production en série des produits livrables
requis pour les opérations et le soutien du système.
Elle débute par le franchissement du jalon de la RDP, qui représente l’acceptation des documents de transition de
la phase B à la phase C, diffusés pendant la phase précédente.
Elle doit inclure, au moins, les tâches permettant l’achèvement de l’état défini du système et de chacun de ses
constituants (RCD).
Pendant cette phase de développement, le plan de production, qui permet le démarrage de la phase suivante, doit
être émis, sous la responsabilité et l’autorité du client de niveau 1. Établi par le fournisseur, le plan de production
présente le calendrier général de production au premier niveau de l’OT.Ilinclutles éléments indiqués par ses
fournisseurs.
Il indique un cycle de production type d’un exemplaire de la série, utilisé comme référenceafind’analyser les
risques en cas de perturbation dans la production normale.
Il indique la logique de production générale de la série (voir 9.3) et spécifie les événements clés qui peuvent être
sélectionnéscomme étapes de suivis financier et calendaire:
� préparation de la fabrication;
� achats;
� démarrage de production;
� évaluations techniques avant les essais de réception;
� réception finale.
Le processus de qualification, commencé pendant la phase de développement, doit être basé sur les vérifications
effectuées pendant la phase de développement et les essais de qualification. Les résultats du processus de
qualification permettent de démontrer que la définition répond aux exigences spécifiées et qu’elle est productible.
La qualification de la définition du produit termine la phase de développement (revue de qualification, RQ).
8.2.5.3.2 Phase de production (phase D)
Cette phase consiste en la fabrication et la livraison à l’utilisateur des produits commandés et correspondant à
l’état défini.
Elle débute par le franchissement du jalon qui représente l’acceptation du plan de production, émis pendant la
phase précédente.
Deux processus peuvent être identifiés au sein de cette phase de production: le processus de production de la
série et le processus de réception pour chaque produit livrable après tenue d’une revuedeprétransport, qui
autorise le transport du produit aprèsvérification de sa conformité vis-à-vis des objectifs de la mission
(performances, configuration et dérogations) et de l’état opérationnel du système.
Pour des raisons de délais, certains achats peuvent être lancés avant la phase de production.
14 © ISO 2001 – Tous droits réservés
8.2.5.4 Phase d’utilisation (phase E)
Pendant cette phase du programme, le système et les ressources requises pour répondre à la mission
opérationnelle sont mises en service, utilisées et soutenues.
La reconnaissance de l’aptitude de l’emploi par l’utilisateur du système conditionne le début de sa vie
opérationnelle.
8.2.5.5 Phase de retrait de service (phase F)
Cette phase consiste en la préparation et l’achèvement, d’une manière coordonnéeet en conformité aux règles
applicables, de l’arrêt complet ou partiel de l’utilisation opérationnelledusystème et le démantèlement des produits
et ressources associés.
NOTE 1 Cette phase débute avec une décision de retrait de service complet ou partiel.
NOTE 2 Les produits démantelés peuvent être détruits, stockés, transformés ou appelés à d’autres utilisations dans le cadre
d’autres programmes.
NOTE 3 Cette phase peut aboutir à l’établissement d’un historique et à une synthèse du programme (performances à
l’achèvement, coût global, statistiques, etc.).
8.3 États successifs d’un produit — Processus et documents associés
8.3.1 Généralités
L’ensemble des états successifs d’un produit s’appelle couramment «cycle de vie».Les états différents du
système, relativement aux phases du programme, sont indiqués à la Figure 2.
Pour un niveau intermédiaire donné, le passage de l’état spécifiéà l’état défini fait l’objet d’un processus complexe
ou d’un ensemble de processus tenant compte de l’acquisition progressive de la définition aux niveaux inférieurs.
Le passage d’un état donnéà l’état suivant s’obtient par l’application d’un ou de plusieurs processus, comme
montréà la Figure 3.
La description de tous les états du produit est donnéeen8.2.6.2 à 8.2.6.6 et représentée à la Figure 2.
Ces états de référence doivent être identifiés et enregistrés dans un système documentaire conformément aux
exigences de l’article 12.
Dèsqu’une référence liée à un état du produit est atteinte, la procédure de gestion de la configuration doit être
appliquée selon les conditions définies dans l’article 10.
8.3.2 État fonctionnel
Il correspond aux fonctions de service exigées d’un produit.
Son origine se trouve dans la demande du client et s’exprime dans un CdCF ou document similaire.
Le but du CdCF, écrit sous la responsabilité et l'autorité du client, consiste en l’expression des exigences du client,
en tant que fonctions de service exigées. Les contraintes dans les diverses phases d’utilisation et les flexibilités
doivent aussi être indiquées explicitement dans ce document.
Les résultats des études exécutées pendant le processus d’expression du besoin doivent permettre l’établissement
progressif du CdCF et de sa justification par rapport à la demande initiale.
Le CdCF et ses justifications associées sont gérées selon une procédure interne du client.
L’état fonctionnel est achevé grâce à l’émission d’un CdCF, qui devient le CdCF de référence à la findela
phase A.
CdCF Cahier des charges fonctionnel PRR Revue préliminaire des exigences
STB Spécification technique de besoin RDP Revue de définition préliminaire
DD Dossier de définition RCD Revue criti
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...