January 16, 2012

Development Plan - M-4

Define the process for developing and qualifying the product (tasks and reviews)

A. Scope

The Development Plan describes the approach set up to carry out the development of a system or product and check its performance. It specifies the logic behind the sequence of the development and verification tasks, the reasons for this logic and the steps taken to control it, taking key events and interfaces into account.

The Development Plan is initiated during phase A. At this stage, it constitutes a preliminary version corresponding to the development of the solution recommended with regard to the CDCF (see E-1) and to the STB (se E-2).

The Development Plan is based on the "RNC-CNES-M-HB-10-504 Etablissement d'un Plan de Développement" RNC document.

B. Fundamentals

The Development Plan is prepared in four stages:

  • identification of the development tasks,
  • identification of constraints,
  • identification of verification and qualification activities,
  • schedule of activities


After having been initiated in phase A, the Development Plan is finalised in phase B, as per the table below. This modifiable document will be regularly updated during the C and D phases.

At this stage, it will constitute the reference version for the development of the product in accordance with the Technical Specification.




C. Typical content

1. Scope

This section lists the main objectives set in terms of performance and deadlines, and describes the hypotheses made for the Development Plan to comply with the upper levels.

It also indicates the scope of application of the Development Plan.


This document applies to all laboratories involved in the project.

2. Documentation

2.1 Applicable documents

This refers to all documents contractually applicable to the product development.


Product Assurance Plan.

2.2 Reference documents

These constitute the bibliography that is necessary in order to prepare the Development Plan.

2.3 Glossary

This defines the terminology and acronyms used in the document.

3. Presentation of the product

A brief description of the product and of its functions will be given here, including in particular the solution principle, its main characteristics, and the new technologies used, if any. A breakdown into major functions, generally relying on different technologies, is recommended (see example).


Product description: the spectrometer shall transform the characteristics of the photons received from a local source, in a given visual field, into digital data.
The characterisation concerns:

  • the energy of the photon,
  • the position of the source in the field of view,
  • the photon detection time.


Concept: the radiation is intercepted by a passive mask, made up of hexagonal pixels, which either blocks the gamma rays or allows them to pass ...

Functional description : The spectrometer is made up of three main functional blocks. The characterisation concerns :

  • optical components, comprising mirrors, filters, and their motor-driven mechanisms
  • the CCD detector, strip, etc., and its proximity electronic components
  • the management and interface electronic components, including the built-in temperature control system.


4. Constraints and risk analysis

4.1 Constraints

The product development is subject to multiple constraints, which are to be identified and integrated into the Development Plan. This paragraph lists the constraints taken into account, and in particular:

  • the inevitable technical constraints induced by or at the upper level;



In order to remain within the weight budget, composite materials shall be used for the structure.

The instrument must not generate an environment (e.g. micro-vibration, magnetic.) over what is given in the specification (to be mentioned)

The performance shall only be guaranteed in an environment (e.g. micro-vibration, magnetic.) whose characteristics shall be mentioned.

  • the organisation constraints (breakdown among collaborators, subcontractors, and their respective responsibilities...);



The Andor laboratory is responsible for the development, qualification and delivery of the BE1 electronic unit.

The "Name" laboratory is responsible for thermal modelling of the development/manufacturing of the "Reference" card, to be qualified according to its specification / qualified on BE1 equipment.

  • the schedule-related constraints (set delivery date, availability date for testing resources...).



The delivery of the scanning mechanism flight model must be compatible with the instrument Development Plan, i.e. must take place in May 99.

4.2 Risk analysis

Prior to drawing up the Development Plan, it is important to conduct, as comprehensively as possible, an analysis of the risks jeopardising the project objectives (performance, costs, deadlines, etc...) and to determine, according to the seriousness of their consequences, the type of events which are unacceptable, or whose probability of occurrence must be below a certain threshold. To this end, the following shall be taken into account:

  • the changes in the expression of need,
  • the product complexity,
  • the importance of the new developments to be started and their deadlines,
  • the uncertainties concerning certain aspects of the project, such as the implementation of new technologies, the availability of specific resources, the procurement times...
  • the participants' skills and resources,
  • etc...


The result will be an analysis of the major risks, ranked according to criticality, and for each one, a definition of their causes, and of the consequences for the program.

The Development Plan must therefore be structured so as to control the main risks by defining the appropriate steps to bring them back to an acceptable level (such as work intended to reduce their probability of occurrence and the seriousness of their consequences or the development of alternative solutions). The Plan must be sufficiently flexible to make it possible to handle feared events, without any major disruption.

4.2.1 Project-related risks

The risks are numerous and varied:

  • risks associated with the project organisation itself: ill-defined responsibilities, complexity of interface management...;
  • risks associated with the management of costs and deadlines: underestimation, falling behind schedule;
  • technical risks having a direct impact on the development;


Every risk may be characterised by the consequences it entails for all aspects of the product development and use:

  • cost increase,
  • late delivery,
  • user dissatisfaction,
  • ...


Risks are identified in the project risk sheets (see MF-5) and analysed in the Preliminary Analysis of Project Risks document (see PAF-2).

Risk-reducing actions shall be identified and managed in the Risk reducing action sheet (see MF-6).

4.2.2 "Technical" or product-related risks

The technical risk analysis is conducted as part of the Dependability studies.

5. Work description

5.1 Development activities

The Development Plan shall present the selected development scenario and its variants, if any, i.e. all the major characteristic elements used to control the progress of the project and to provide assurance that the objectives will be achieved. Based on the work breakdown structure, the supplier presents:

  • the proposed development logic, which must be consistent with the key events, in accordance with the "Progress Logic" applicable to the project.
  • the proposed integration, verification and qualification principles,
  • the main activities and key events.


5.2 Model policy

This paragraph describes the various models to be developed, along with their respective functions:

  • characteristics of the model and of its sub-assemblies,
  • ultimate purpose (qualification, flight.),
  • representativity of each sub-assembly with respect to the flight model (refer to appendix 1).


5.3 Manufacturing and inspections

This section presents all the tasks performed for the manufacturing and inspections of the products intended for delivery to the customer, as well as the duration of these tasks.

It will also present the preparation of the operation phase for the manufactured products (production of training elements, implementation and maintenance).

5.4 Qualification/verification logic

This § in the development plan (which may refer to a separate document) shall justify the validation method planned for the requirements applicable to the product.

Depending on the nature of the project, the paragraph on the qualification/verification logic may deal with the following points:

  • performance,
  • calibration,
  • mechanical and thermal architecture,
  • electrical and IT architecture,
  • software,
  • environmental specifications (EMC, vibration levels.),
  • sub-system,
  • system,
  • interfaces.


This paragraph presents and details:

  • a qualification/verification method for every requirement identified in the Technical Specification (or following from it). The method proposed can be, as appropriate: T: Test; I: Inspection; D: Design; AN: Analyse; O: Other. In the case of tests, the method to be used shall be specified.
  • the means to be implemented to carry out this work, specifying, for each case, whether the means already exists or will have to be created ;
  • the models used ;
  • the target dates for the acquisition of the means, and for milestones, reviews, BTs, CRE (see development schedule M-7) ;
  • The people in charge of the qualification/verification work.


Note: the validation logic shall in particular detail the performances deemed to be critical for the risk analysis, and/or depending on:

  • An environment which cannot be reproduced on the ground
  • Interfaces (mechanical, electrical, software, operational.) for which no representation is planned
  • Validations which can only be made at a higher level
  • ...


This paragraph makes it possible to draw up a qualification/verification matrix to be used for traceability of all the results (see qualification/verification matrix EF-5)


Mechanical qualification:
The mechanical and thermal model for the instrument will be used to check the resistance to vibration during satellite tests.

5.5 Ground facilities

The facilities used for development of the product will be described in this section. These are:

  • mechanical equipment, MGSE,
  • electrical equipment, EGSE,
  • optical equipment, OGSE.


Precise details shall be provided concerning the means to be specifically developed for the manufacture of the product, including the means of transport.

The development plans for these specific means shall be made applicable here.


The MGSE elements required for mechanical testing are:

  • a specific structure for integration of the camera,
  • three theodolites,
  • a calibration bench,
  • a transport container,
  • ...


5.6 Technology validation

This paragraph will give the list and the validation logic for the critical technologies identified. The technology qualification elements will be provided for all technologies. Technological qualification sheets will be drawn up for new technologies (see Technological Qualification Sheet PAF-1) as the work progresses. These sheets will be completed during special meetings and will require that the criticality identification, the test plan to be applied and the result acceptance be agreed upon.

6. Development schedule

The development schedule is used for the sequencing of tasks with regard to key events set by the upper and lower levels, such as reviews, delivery dates... It also indicates the objectives to be reached during each phase.

It usually comes in the complementary forms of a block diagram and a bar chart schedule:

  • the bar chart schedule displays the calendar of activities (such as reviews, tests, deliveries of models and equipment..., key events in the running of the project which must be covered by a precise description);
  • the block diagram defines the logic of their sequencing; it will be presented in the Assembly, Integration and Test Plan (PAIE).


7. Description of supplies

This section lists the supplies to be delivered at the upper level, along with the corresponding delivery dates and associated entry hypotheses and constraints.

There are three types of supplies:

  • models to be delivered to the customer,
  • non-model means to be delivered to the customer,
  • associated documentation.


D. Model policy

1. Model definition

In the course of the project, the product is subjected to several physical modelling operations, which essentially consist of:

  • the identification model, IM,
  • the structural and thermal model, STHM,
  • the qualification model, QM,
  • the flight model, FM.


Note: Extra mock-ups can be initialised to reinforce the feasibility trustworthiness of the development of an instrument.

1.1 Identification model

This is built with electrical and mechanical components representative of the flight model, but with standard components and with no equipment redundancy.

Its purpose is to check the definition, the electrical interfaces and the resistance to EMC.

1.2 Structural and thermal model

Its mechanical and thermal components are representative of the flight model in terms of weight, volume and inertia.

It is used to check the behaviour of the product in a mechanical and thermal environment.

1.3 Qualification model

This is representative of the flight model, including the definition of the components.

It is used for the qualification of the product and the validation of the assembly methods and integration procedures.

1.4 Flight model

Complies with the qualified definition. Any departure from the qualified definition must be covered by a qualification justification.

It is subjected to acceptance testing and carries out the actual mission.

2. Alternative approach

In the context of a scientific project, and considering the costs and deadline constraints, not all the type models defined above will be systematically made.

Alternative approaches may be considered, which consist in combining several objectives on a single model.

Three solutions may therefore be proposed:

  1. IQM; FM; (and STHM if need be)
  2. IM; QFM; (STHM recommended)
  3. IQFM; (STHM strongly recommended)

In 1), the IQM is a ground model called "protosol". The equipment components are standard level; this model is not launched.

In 2), the QFM is a flight model called "protovol".

In 3), the IQFM is a unique model, similar to "protovol".

The table in the next page shows the three solutions grouped together according to two trends:

  • IQM + FM very close to the IM + QM philosophy due to being fully compatible with the verification logic, but less costly ;
  • IM + QFM or IQFM.


These two solutions are only differentiated by minimum cost motivations. The preoccupations concerning the build-up in stress and fatigue on the ground by models fit for launching are identical.

Note: Depending on the physical breakdown of the instrument, the sub-assemblies may have different development logics linked to their criticality.

With a microscope, for instance:

Mechanism very critical: IM; QM; FM

Electronics non-critical: IM; QFM





RisksActivities get out of step
Development Plan
Product risk sheet


Activities / documentation

Published in: