16 Janvier 2012

Plan de Gestion de la Documentation et de la configuration - M-9

Identifier et gérer les documents utiles et nécessaires au projet, connaître la configuration et les évolutions du produit

A. Objet

Le déroulement d'un projet génère un grand nombre d'informations qui retracent « l'histoire » du projet sous ses différents aspects.

La collecte et l'actualisation systématiques de ces informations sont des conditions sine qua non de la bonne marche du projet.

Toutes les informations sont consignées dans des documents d'ordre technique, administratif, et contractuel qui constituent la documentation du projet. Pour réussir le projet et limiter les risques liés à l'utilisation incorrecte d'un document ou le temps perdu à chercher une information déjà tracée, chacun de ces documents doit être disponible et accessible rapidement et de façon fiable pour tout acteur du projet.

Le but de la gestion de l'information et de la documentation est de mettre en place les méthodes et procédures nécessaires et suffisantes pour maîtriser les informations utiles pour le projet. En général les principes applicables à un projet sont tracés dans le Plan de Gestion de l'information de la Documentation et de la configuration du projet ou PGDC.

Ces principes de gestion s'appliquent également aux logiciels développé ou utilisés pour le projet.

Le PGDC s'appuie sur la trame de l'annexe A du document « RNC-ECSS-M-40 Configuration and information management ». Pour des raisons pratiques, il est préférable de traiter les chapitres liés à la documentation avant ceux liés à la configuration.

B. Principes d'élaboration

La gestion de l'information et de la documentation s'applique tout au long du déroulement du projet. Il est donc recommandé d'établir les règles de gestion de la partie information/documentation du PGDC en début de phase A.

Quel que soit son niveau d'intervention, chaque équipe projet peut élaborer son propre PGDC en conservant une cohérence avec les règles de gestion de l'information et de la documentation du niveau supérieur.

Le PGDC définit :

  • l'identification, la présentation, l'enregistrement, la diffusion, la mise à jour, le classement et l'archivage des documents émis et reçus par le projet, quel que soit leur type et leur support (note, plan, fax, e-mail, ...) ;
  • le circuit de signature (interne) ou d'approbation (lorsque soumis à un aval externe) ;
  • les règles minimales de suivi des évolutions des documents (documents révisables) dont les documents dits « gérés en configuration ».
  • les règles minimales gestion de configuration, dont le marquage

 

Cette méthode à partir d'un contenu type permet de ne rien omettre, et d'être conforme aux exigences de l'ECSS.

Pour élaborer le PGDC à partir de ce modèle, ne pas hésiter à supprimer les informations de ce guide utiles à la compréhension des chapitres.

Les points spécifiques aux logiciels sont identifiés chaque fois que nécessaire.

C. Contenu type

1. Généralités

L'objectif général du plan de gestion de la configuration et de la documentation est de décrire les règles d'identification et de gestion de la documentation, ainsi que l'identification et la gestion de la configuration du projet (Donner le nom du projet) Les dispositions mises en ouvre doivent garantir aux différents acteurs l'exactitude, l'accessibilité, la fiabilité, la sécurité et la mise à disposition rapide de toute l'information qui leur est utile.

Concernant la gestion de la configuration, ce document décrit l'organisation mise en place en interne et vis-à-vis des partenaires et/ou des fournisseurs, les moyens et les prestations mis en ouvre afin d'être en mesure de livrer un produit dont la définition a été identifiée et les évolutions maîtrisées.

Ce document s'applique à l'ensemble des produits du projet durant les phases de développement et si besoin de maintenance des produits. Ce document est applicable à l'ensemble des produits de responsabilité (Préciser l'entité responsable) durant toutes les phases du projet.

Il s'adresse :

  • aux membres du projet, pour qu'ils connaissent les principes, services, contraintes de la gestion de la configuration et de la documentation ;
  • aux intervenants réalisant le support à la gestion (gestionnaire de documentation, de configuration y compris configuration logicielle).

 

2. Documentation

2.1 Documents de référence

RNC-ECSS-M-ST-40 Management de la Documentation et de la Configuration

Lister, s'ils existent, les autres documents généraux dans l'entreprise ou le métier, sur les principes et la logique de la maîtrise de la documentation et la configuration.

2.2 Documents applicables

Lister les procédures internes à l'entreprise, permettant de traiter la documentation, la configuration, y compris les règles de sécurités, s'il y en a.

Citer, s'il en existe, le ou les documents « client » qui donnent des principes minimaux à respecter dans la gestion de documentation ou de configuration

2.3 Terminologie utilisée

Seront définis ici tous les termes, sigles et autres abréviations employés.

3. Management

3.1 Organisation

L'organisation du projet et le rôle de chacun des acteurs sont en général décrits dans une note d'organisation.

Si c'est le cas, ne pas répéter dans le PGDC ces informations, mais renvoyer à la Note d'Organisation du projet.

3.2 Responsabilités

Le chef de projet est responsable de la documentation et de la configuration de son projet.

Si la charge le justifie, le chef de projet est assisté dans ses tâches de gestion par un ou des membres de l'équipe projet ou par des intervenants spécialistes du domaine de gestion considéré.

Le Responsable de Gestion de la Configuration et de la Documentation (Fonctions usuelles - à ne conserver que ce qui est utile) :

  • Propose le PGDC et le met à jour, si besoin, au cours du projet.
  • S'assure vis-à-vis du projet de l'application du plan et du respect des procédures de gestion de documentation et de configuration par l'équipe
  • Administre la bibliothèque du projet (base documentaire), et si besoin l'outil de GC.
  • Anime le processus de gestion de configuration.
  • Assure le contrôle de la configuration.

 

Le documentaliste :

  • Est responsable du classement et de l'archivage (en général sur un outil informatique) des documents devant être conservés,
  • S'assure que leur consultation est possible au cours du temps, sans ambiguïté sur le niveau d'acceptation et d'applicabilité,
  • Garantit la conservation de leur intégrité.

 

Le Responsable de configuration logicielle (si nécessaire) :

  • Réalise le contrôle (en particulier du DDC et des procédures de génération) et met à disposition les différents articles de configurations livrés au projet ou développés au sein de l'équipe projet.
  • Archivage les articles de configuration logiciels livrés ou produits, incluant la mise en configuration des codes source des logiciels, et des procédures et moyens de production du produit installable.
  • Génère, au besoin, des produits logiciels installables, à partir des logiciels archivés.
  • Livre à partir de l'espace de référence les produits pour l'équipe de développement ou le client.

 

3.3 Politique, Directives et Procédures

Ce plan est écrit conformément à l'ECSS-M-ST-40.

Lister, s'il y en a, les autres contraintes internes ou externes qui s'appliquent à ce plan.

3.4 Sécurité

L'objectif est de définir les niveaux de protection adaptés au contexte du projet. Pour définir le bon niveau d'un contenu, il convient de se poser des questions simples.

L'information (document, logiciel .) ne nécessite aucune restriction d'accès, elle peut circuler librement sur Internet et être échangé en clair par messagerie non sécurisée => l'information est classée « Publique ».

L'information (document, logiciel .) mérite de rester bornée à une communauté identifiée, mérite l'usage de messagerie sécurisée ou de serveur d'échange de type ftp mais ne nécessite pas de protection de type cryptographique => l'information est classée Diffusion Limitée au projet.

Au-delà, de ce niveau, il est important de définir en concertation avec le client, le partenaire ou le fournisseur, les moyens adaptés aux échanges et à la conservation des données.

Décrire ici, les niveaux de sensibilité et les principes de protection retenus.

La sensibilité d'un contenu est proposée par l'auteur et arbitrée par l'autorité décisionnelle.

Bonne pratique :

Lorsqu'un document mérite protection, il est important de l'indiquer explicitement par un tampon ou un bandeau précisant le niveau de confidentialité.

Ce niveau est normalement rappelé sur chaque « page », le minimum est de le faire en couleur sur la première page du fichier.

4. Gestion de l'information / documentation

4.1 Identification

Elle a pour but de faciliter la gestion de la documentation du projet.

Le PGDC indique les règles d'identifications retenues pour les documents produits et reçus au titre du projet.

Une bonne identification se caractérise par :

  • un numéro unique, une chaîne de caractères, ou une nomenclature,
  • une version et/ou une date de version.

 

Bonnes pratiques :

Eviter d'utiliser l'année dans la composition du numéro unique ou de la nomenclature d'un document. La date de version est suffisante.

Il est préférable également d'éviter d'utiliser des acronymes de structures ou des initiales d'auteur. En effet, les structures peuvent évoluer et l'auteur d'une mise à jour (version n+1) peut être différent de l'auteur de la version précédente.

Les autres informations nécessaires à l'identification peuvent être utilisées ou non dans la composition de la référence d'un document. Ces informations sont sous forme de noms explicites, d'acronymes ou de codes dont la traduction est définie dans le PGDC. Ces éventuels identifiants doivent être compréhensibles des clients ou coopérants et serviront à composer les méta données des « technical data packages » TDP d'échange / diffusion, selon les prescriptions de l'ECSS-M40 :

  • L'identifiant du projet
  • L'identifiant du produit ou du noud de l'arborescence auquel se rapporte le document
  • Le type de document (Exemples : Compte Rendu, Note technique, Dossier de contrôle d'interface, Spécification technique de besoin).
  • Le nom de la société, laboratoire, consortium,.qui émet le document

 

Bonnes pratiques :

Les identifiants des produits ou des nouds de l'arborescence technique doivent avoir, si possible, du sens aussi bien en interne qu'en externe. Il est mieux de se concerter avant entre coopérants ou entre clients et fournisseurs pour faciliter les échanges ultérieurs.

4.2 Format des données

Le PGDC décrit les systèmes d'informations, les formats type, les logiciels... utilisés pour la création, la revue, l'approbation, le stockage, la livraison et l'archivage des données. Il indique le type de format qui prévaut en cas de conversion.

Bonnes pratiques :

Pour le format « opposable », ou « de référence » choisir un format stable et portable de type PDF normalisé (PDF/A ou /B). Conserver les autres formats pour faciliter les mises à jour ou l'utilisation (format tableur).

Définir une présentation type des documents, afin de les rendre homogènes et de faciliter le travail des acteurs techniques.

Ne pas oublier : l'approbateur d'un document est responsable du niveau de classification, mais aussi de la diffusion, de l'identification ... comme il l'est de la qualité du contenu.

Elaboration ou évolution d'un document.

L'élaboration d'un document doit permettre son utilisation et son classement dans le temps.

Un document évolue à partir de la dernière version validée (sauf exception explicite) et enregistrée dans l'espace documentaire de référence du projet (et non pas à partir des copies des auteurs ou de leur secrétariat).

Le document est constitué des parties suivantes :

  • Une page de garde permettant d'identifier clairement le document et comportant :
    • sa référence avec sa version et sa date de version
    • le titre du document
    • sa classification (niveau de sensibilité du contenu)
    • les autres données d'identification : projet, produit, société...
    • les noms des rédacteurs et approbateurs
    • son statut et les visas des approbateurs en l'absence de signature numérique
    • L'applicabilité (si cette information est pertinente, indiquer les modèles, séries, matériels auquel s'applique,.), l'appartenance à un référentiel géré en configuration
  • Eventuellement (inutile pour un CR) une ou plusieurs pages complémentaires comportant :
    • la référence du marché pour les contributions externes,
    • le sommaire
    • les documents utilisés pour rédiger le document
    • l'historique des modifications indiquant l'origine de l'évolution (e.g. les DM/PM traitées) et la nature des évolutions successives (eg chapitres impactés).

 

Le corps du document :

  • toutes les pages du document portent la même version.
  • les modifications apportées sur un document sont repérées, par exemple par un trait vertical en marge

 

Une liste de diffusion à jour ou simplement l'auditoire visé (les diffusions peuvent être gérées de manière centralisée et donc déportée des documents eux-mêmes).

4.3 Processus

Lorsque la note d'organisation du projet ne le précise pas, le PGDC définit :

  • les personnes du projet responsables de l'approbation des documents livrables par un fournisseur.
  • le processus d'approbation et les enregistrements traçant cette approbation.
  • les responsables techniques ayant autorité pour traiter des flux d'informations avec les coopérants et les clients.
  • Les processus et traces de demandes d'accords sur des documents livrables à un client (par exemple : bordereau d'acceptation...).

 

Vérification et approbation

Avant diffusion officielle, tout document doit faire l'objet d'une autorisation formelle afin de garantir à l'utilisateur la validité des informations qu'il contient.

En interne

Tous les documents sont approuvés, selon les règles de délégation définies dans le projet.

Décrire les règles d'approbation et les délégations, s'il y en a.

L'approbation doit être vérifiable sans ambiguïté par un acteur du projet. Décrire les moyens de vérifier l'approbation (par exemple l'état dans un espace de référence).

Vis-à-vis d'un client

Tout ce qui touche (fait évoluer, altère, n'est pas conforme.) au référentiel client applicable par le projet doit impérativement recueillir son aval avant toute utilisation. L'objectif est de traiter les impacts techniques (sur les performances, la mission, ...) et contractuels (coûts, délais, conditions particulières).

Le client est à prendre au sens large. Par exemple le Responsable Scientifique d'une mission (PI) est un client.

Il est important de conserver la trace de l'accord du client.

Décrire les mécanismes de sollicitation des accords et de conservation des traces. Penser à faciliter aux acteurs projet l'accès à l'état d'acceptation des données soumises à l'aval d'un tiers.

Vis-à-vis d'un coopérant

Tout ce qui touche le référentiel commun doit faire l'objet d'une relecture commune (lors de points d'avancement par exemple) ou d'un processus d'accord entre les coopérants. Le but est d'éviter de découvrir trop tard des impacts d'évolutions locales sur un projet.

Il est important de formaliser l'accord multipartites et d'en conserver la trace.

Décrire les mécanismes d'acceptation et de conservation des traces. Penser à faciliter aux acteurs projet l'accès à l'état d'acceptation des données.

Remarque

Pour tous les autres documents échangés dans le cadre du projet, même si ces documents n'attendent pas d'accord ou d'approbation formelle, encourager les commentaires sur ces documents est une bonne pratique.

4.4 Système d'information

Ce chapitre décrit les moyens et les outils mis en ouvre pour assurer la mise à disposition rapide, fiable et, si besoin sécurisée, de l'information aux acteurs du projet.

Lister au moins les outils de gestion de documentation et de gestion de configuration (y compris si limités à des espaces serveurs).

Les moyens de diffusion retenus en interne comme en externe sont décrits (réseaux, serveurs ftp, messagerie sécurisée ou non, envoi de CD-Rom...).

Penser à traiter les aspects :

  • accès par l'équipe projet aux référentiels techniques « valide » du projet = ensemble des dernières versions des documents approuvés, des logiciels développés, état de la vie des DM, FA, dérogations,...
  • fiabilité du référentiel (garantie de non altération),
  • réutilisation des contenus, en particulier pour les mises à jour,
  • conservation des données (archivage et de restauration),
  • mécanismes d'accès aux données sensibles (classifiées) et durée de classification,
  • durées de conservation et les méthodes de destruction des données

 

4.5 Méthode de livraison

Le PGDC décrit les méthodes mise en ouvre pour livrer les documents au format ISO limité aux besoins du spatial et décrit dans l'annexe sur le modèle à appliquer de l'ECSS-M-40.

Le Technical Data Package est composé d'un zip comportant le fichier .xml normalisé qui emporte les données d'identification des fournitures (pour les documents ce sont celles de l'identification) et au minimum les fichiers stables des données transmises. Pour faciliter l'usage des TDP, il existe une note interne CNES donnant des exemples de l'usage de balises xml et des champs obligatoires ou fortement recommandés.

Le Bordereau d'envoi peut être remplacé par la structure des méta données du TDP (titre du TDP) et la liste des méta données par contenu (liste du TDP), associé à un mécanisme de checksum, dont le mode de calcul et la valeur sont transmis séparément du TDP.

Rappel : la transmission sans protection sur Internet (messagerie, serveur d'échange non sécurisé) est à proscrire pour les données techniques qui ne sont pas de niveau public.

4.6 Signature numérique

Si la signature numérique conforme à l'exigence ECSS-M-ST-40 est la norme au sein de l'équipe projet, il est important de définir auprès du client ou du coopérant les dispositions pratiques à appliquer. Par exemple :

  • Lorsque le destinataire applique déjà la signature numérique, mettre en ouvre les dispositifs de reconnaissance mutuelle de clés.
  • Lorsque le destinataire ne pratique pas encore la signature numérique, définir un processus fiable de livraison des données approuvées ou à valider et identifier le site de publication des clés publiques de l'entreprise pour effectuer en cas de doute, les vérifications minimales utiles.

 

4.7 Gestion des actions

La gestion des actions par le projet est décrite dans le M-12

5. Gestion de Configuration

5.1 Généralités

La Gestion de Configuration (GC) a pour but de maîtriser les caractéristiques d'un système et de ses composantes et donc sa description technique et les évolutions et écarts volontaires ou non qui affectent successivement cette description.

La configuration d'un produit est l'ensemble des caractéristiques que le projet juge nécessaires et suffisantes de maîtriser (donc de gérer) pour maîtriser ce produit. Ces caractéristiques sont généralement gérées dans des documents écrits selon un point de vue particulier (spécification, conception, réalisation, utilisation...) dont l'étendue varie en fonction de l'activité effective du projet sur ce produit (achat, intégration, fabrication, conception,...).

La configuration concerne aussi bien la description théorique du produit ("configuration applicable"), que celle effective de chacun des exemplaires disponibles ("configuration appliquée").

Le contenu de ces 2 types de configuration est le suivant :

Configuration applicable (produit attendu ou « as design ») :

  • Référentiel donnant la définition technique du produit (spécifications, plans.) dans des documents dits « configurés » dont on suit les évolutions de façon formalisée (DM/PM).
  • Ecarts approuvés (évolutions décidées - Demandes de Modifications approuvées et lancées - typiquement en Commissions de Modification) et non encore incorporés dans le corpus configuré.
  • Ecarts acceptés avant réalisation (Déviations ou RFD).

 

Configuration appliquée (produit obtenu ou "as built") :

  • Référentiel applicable
  • Documents descriptif de réalisation ou de son résultat : livrets suiveurs (log book), CIDL (Configuration Item Data List), résultats et preuves de calibration ou de contrôle...
  • Ecarts constatés entre le référentiel applicable et le produit réel :
    • anomalies présente (identifiées et suivies par des "Fiches d'Anomalie" pouvant déboucher sur des corrections, des retouches, des évolutions ou des dérogations).
    • dérogations acceptées (anomalies conservées en l'état ou corrigées avec un procédé dérogatoire également nommées RFW), et les limitations d'emploi éventuelles.

 

Les dispositions de gestion de la configuration applicable sont décrites dans le présent document.

Si les principes de gestion des anomalies sont donnés dans la Plan d'Assurance Produit du projet, identifier le PAP dans la partie configuration appliquée.

En complément du PGDC, dans le cas des logiciels, ne pas oublier :

  • la liste des articles de configuration du projet (préciser si besoin la référence de la liste).
  • la ou les procédures spécifiques de gestion et d'exploitation des logiciels mise en ouvre dans le cadre du projet (préciser si besoin la référence de la procédure spécifique).

 

5.2 Identification de la configuration

Principes

Le succès d'un projet repose sur une succession d'étapes permettant de garantir une marche maîtrisée vers le produit attendu, et en cas de difficulté, de corriger à temps ce qui doit l'être sans attendre que les difficultés n'en génèrent davantage.

Chaque étape a :

  • pour objectif d'élaborer une contribution essentielle au projet (typiquement d'abord la spécification technique, puis la conception technique, puis., puis l'intégration, enfin la validation).
  • pour conclusion : la revue de sa production afin de s'assurer qu'elle est complète, cohérente, conforme aux attentes (en particulier avec les résultats des étapes précédentes).

 

Les principes de la gestion de configuration reposent sur l'établissement de référentiels successifs de la configuration des produits (matériels et logiciels). Ces référentiels représentent l'état approuvé des exigences et de la conception à une étape donnée et constituent le point de départ des évolutions de ces mêmes produits pour l'étape suivante.

Le référentiel de configuration est composé de descriptifs approuvés.

Avant de pouvoir être prise en compte, toute modification d'une caractéristique d'un produit spécifiée ou mise en évidence dans ce référentiel configuré doit faire l'objet d'une procédure de modification formelle faisant intervenir les acteurs des disciplines concernées, les clients ou le coopérant, si besoin.

Une configuration de référence est constituée d'un ensemble de documents, plans, plans process, matrices d'exigences...) décrivant les caractéristiques à gérer d'un produit. Cet ensemble est désigné de façon formelle comme la référence de la configuration, à une étape clé du cycle de vie du produit.

Bonnes pratiques :

Figer le premier référentiel de configuration au plus tard à la fin de la phase B du projet.

Le référentiel configuré comporte au minimum, les Spécifications Techniques de Besoin de chacun des articles de configuration, les dossiers de contrôle des interfaces, les exigences techniques ayant un impact sur le dimensionnement, la fabrication ou le codage, les performances, les conditions d'emploi...

Marquage

Les dispositions de marquage des produits matériels et logiciels sont décrites dans le PGDC.

Le marquage des produits matériels doit être solidaire du produit, permettre de l'identifier sans ambiguïté, de trouver simplement son référentiel de définition, de fabrication et de contrôle. Les dispositions de marquage doivent tenir compte de la taille du produit et de ses conditions d'emploi. S'il existe des exigences de niveau client, en tenir compte. Le marquage, en général reprend :

  • Un identifiant du fabricant,
  • le code du produit,
  • le modèle,
  • un numéro de série.

 

Le marquage et l'identification des logiciels sont intégré au produit logiciel, ce qui garantit la « solidarité ». Les rubriques du marquage logiciel sont :

  • le nom de l'article,
  • la version de l'article,
  • le Dossier Descriptif de Configuration, (fichier normalisé).
  • le marquage des fichiers ASCII,
  • le marquage du nom de version dans les binaires exécutables,
  • le cartouche de traçabilité des fichiers ASCII.

 

Bonnes pratiques :

Pour le logiciel, le nom de version est porté par le cartouche, cette information est nécessaire et suffisante. Pour éviter de complexifier la gestion, il faut éviter d'inclure le numéro de version dans le nom des fichiers qui compose les articles de configuration du logiciel.

Un dossier de Configuration (DDC) contient au moins :

  • le nom de version ;
  • la « version de référence », c'est-à-dire la version à partir de la quelle le logiciel à été modifié (version n-1) ;
  • la liste de Fait technique (FT) prit en compte depuis la version de référence (DM/FA) ;
  • les dépendances du logiciel et leurs versions (logiciels « externes » nécessaires au fonctionnement pour le développement, la génération et l'exploitation) ;
  • la procédure de génération et d'installation ;
  • la liste des fichiers modifiés / supprimés / ajoutés.

 

Il faut éviter de recourir à des droits logiciels trop élevés (root par exemple) pour les générations, installations et l'exploitation. En effet, même si ce niveau de droits simplifie le développement, ils présentent des risques dans l'utilisation et la maintenance du logiciel.

Il est conseillé d'automatiser les marquages des logiciels, lorsque de nombreux fichiers sont manipulés.

5.3 Contrôle de la configuration

Principe

Garantir, à tout moment, la cohérence entre l'état réel du produit et son référentiel descriptif de configuration. Pour ce faire, il convient de disposer d'un processus formel pour identifier, évaluer, décider, réaliser les évolutions proposées et mettre à jour le référentiel des évolutions acceptées et appliquées.

Gestion des modifications

Le processus de gestion des modifications est décrit au PGDC. Il comporte au moins les étapes suivantes :

  • initialisation ou formalisation de la demande de modification.
  • accord sur l'opportunité de la demande de modification par le projet & instruction de la demande de modification, en particulier sur les impacts amont et aval.
  • décision d'application ou non. Si la décision d'appliquer est prise cela entraîne l'évolution de la configuration applicable du produit.
  • réalisation et vérification, si la décision d'appliqué a été prise.

 

1. Initialisation

La Demande de Modification (DM) peut provenir :

  • du « niveau supérieur », client ou coopérant => définir dans le PGDC les informations nécessaires et suffisantes pour caractériser une demande (liste des champs/rubriques obligatoires et champs complémentaires). S'assurer que les champs définis sont utilisables pour les demandes « internes ».
  • de l'équipe projet en interne => privilégier la formalisation par l'émetteur du besoin. Limiter au juste besoin les champs indispensables à l'émission du besoin (si possible champs obligatoires communs avec ceux échangés avec un client)
  • du « niveau inférieur » composantes ou fournisseur => définir les rubriques indispensables aux échanges.

 

2. Accord sur le besoin & Instruction

En cas d'accord sur une DM, l'instruction (parfois nommée PM) doit impérativement traiter les aspects impacts clients, coopérants ou fournisseur.

S'il existe des impacts sur

  • Les interfaces amont ou aval,
  • Les performances,
  • Les coûts ou délais en amont ou en aval,

 

Il est indispensable avant d'entrer en phase de réalisation, d'avoir l'accord des autres parties.

En cas de désaccord, il est recommandé de tracer les raisons du refus avant de clore la DM.

Notes :

  • les DM ayant des impact amont sont parfois dites de classe 1 ou de classement majeure.
  • Les accords ou avis des tiers sur les DM avec des impacts amont ou aval sont à formaliser et à conserver aussi rigoureusement que les accords sur les documents soumis à approbation externe.
  • Le processus d'instruction s'appuie en général sur des avis multiples, penser à décrire comment les avis sont sollicités pour faciliter le travail de l'instructeur technique.

 

3. Décision

Lorsque l'analyse est terminée, l'instructeur technique présente les avantages, impacts, difficultés, et options possibles. l'accord ou avis des tiers (dans le cas d'impacts amont ou aval) de l'application.

La décision d'appliquer ou non est formalisée. Cette formalisation peut se faire au moyen d'un processus organisé de « commissions de modifications ».

4. Réalisation et vérification

La réalisation et la vérification comportent une phase technique proprement dite et une phase de mise à jour des référentiels. Ces étapes ne sont pas toujours réalisables simultanément, ni réalisées par les mêmes personnes. Il est donc important de tracer pas à pas le réalisé et le reste à faire dans le suivi des évolutions acceptées.

Gestion des anomalies

La gestion des anomalies est présentée dans le PAP, conformément au document RNC-ECSS-Q-ST-10-09.

Sinon, décrire le processus dans le PGDC. Le processus est similaire au processus de traitement des DM en prenant en compte les points suivants :

  • Les anomalies sont en général « subies » on parle de constat et non pas de demande.
  • La correction doit être évaluée comme une instruction de DM
  • S'il est préférable de vivre avec une anomalie, mais que cette anomalie a un impact amont ou aval, il faut informer (aval) ou demander l'accord formel (amont). Cet accord est tracé au moyen d'une dérogation.
  • Les anomalies corrigées sont passées en revue lors des Bilans techniques et commissions de revue des essais.

 

Gestion des dérogations

Le Cycle de vie de la dérogation reprend les 3 premières étapes de celui d'une Modification, avec un impact « client » ou « coopérant ». Les principaux écarts sont :

1 - Initialisation

En général, la dérogation a pour origine une anomalie dont l'acceptation en l'état est demandée par un fournisseur à son client.>/p>

2 - Instruction

L'instruction doit impérativement traiter l'aspect périmètre (si il y a plusieurs produits) et limitations d'emploi des produits touchés.

3 - Décision :

La décision implique l'accord du client.

Il n'y a pas de réalisation et en général, pas de mise à jour de référentiel. L'état final de la dérogation qui a l'accord du client est « accepté ». La dérogation peut être limitée dans le temps ou à un domaine d'emploi ; elle peut ne porter que sur x produits parmi N. Toutes ces informations doivent être tracées de façon explicite.

Formulaires de modification et de dérogation

Il n'est pas nécessaire de définir des formulaires à proprement parler.

Il faut définir les champs ou rubriques nécessaires aux échanges d'informations relatifs aux modifications (DM) aux anomalies (FA) et aux dérogations (DR).

Les champs nécessaires aux échanges sont donnés dans la fiche FM-4 du GNS.

Les projets CNES sont également en mesure, si besoin, de fournir un fichier d'import au format Excel propre à un projet pour faciliter les imports de données.

Il faut également définir le processus traçant les demandes d'acceptation et formalisant ces acceptations.

La signature unitaire des faits techniques (DM/PM, DR, FA) est un moyen et pas un but. La trace au moyen de compte rendus explicite donnant l'état d'acceptation de plusieurs faits techniques (par exemple CR de commission) est souvent bien plus efficace.

5.4 Maîtrise des interfaces

Le PGDC reprend, ici, les principes mis en ouvre par le projet pour alerter, demander l'accord des clients ou coopérants ou solliciter l'avis d'un fournisseur chaque fois qu'une demande de modification, une anomalie, ... a un impact sur le référentiel « client » ou partagé avec un coopérant ou applicable à un fournisseur.

Le PGDC traite également ici les principes d'alerte interne, lorsque le projet est décomposé en produits distincts, traités par des équipes tout ou partie différentes.

5.5 Maîtrise des fournitures

Les fournitures sont listées dans le CCTP (M-2), les livrables AIT (I-14), le RCI (AP-13), le Livret Suiveur (AP-14).

Les détails étant déjà traités dans des formats spécifiques, se focaliser dans le PDGC sur le processus de décision et les points-clé organisés pour faciliter les livraisons.

Les revues de livraison concernent les divers aspects matériels et logiciels, tests de qualification, mesures, complétude de la documentation, y compris le Livret Suiveur, le DDC logiciel ainsi que les manuels d'installation, d'utilisation et de maintenance.

Les revues de livraison gagnent à être formalisées par une réunion formelle avec tous les enregistrements nécessaires.

5.6 Gestion des états de configuration

Le système de composition des états de configuration est décrit ici.

Ce système doit être simple, adapté au contexte du projet et facile à utiliser par les acteurs du projet.

Cela peut être un outil informatique spécifique à défaut un tableur ou un fichier géré par un responsable désigné. Un cahier d'enregistrement peut également faire l'affaire, si gérer un fichier est source de problèmes.

Pour faciliter la création des livrets suiveurs ou des DDC, les états de configurations sont traités par articles de configuration et font apparaître deux parties distinctes :

1) Le référentiel de configuration applicable :

  • Pour chaque document, plan, matrice,... approuvé et configuré, au minimum : le titre, la référence, version et date de version.
  • Les évolutions approuvées ET non encore intégrées au référentiel ci-dessus : les références et titres, si possible les produits et référentiels touchés. Leur état d'application dans le produit (cet état fait le lien entre applicable et appliqué).
  • Les dérogations acceptées : les références, titres, descriptifs, modèles touchés et limitations d'emploi.

 

2) Le référentiel de configuration appliqué :

  • Les anomalies constatées et non encore corrigées : les références, titres, descriptifs, produits touchés, et si possible les impacts potentiels, la criticité...
  • Les procédures de fabrication et de tests déroulées : référence, titre, date, version, du modèle (procédure source) ET les procédures réellement déroulées (celles utilisées, enrichie des annotations et des relevés de mesures, de contrôle et d'essais).

 

Evidemment toutes les informations listées dans l'état de configuration doivent être accessibles à l'équipe projet et faciles d'accès.

5.7 Vérification de la configuration

Décrire les dispositions prises pour vérifier la configuration.

Ces vérifications sont au minimum nécessaires pour préparer les étapes clés du projet :

  • les revues, dont l'objectif est, en général, de faire le point d'avancement d'une phase et d'autoriser la suivante. L'état de configuration est la référence de départ de la phase suivante.
  • lors des Bilans Techniques. Le BT identifie et fige la configuration applicable avant de démarrer la fabrication ou les essais. Ce qui facilite, ensuite, le traitement des écarts de production ou des anomalies rencontrées en essais.

 

5.8 Audit

Renvoyer aux dispositions décrites au niveau du PAP, si elles existent. Sinon lister les fréquences des audits sur les activités de gestion de configuration et documentation et la logique de déclenchement.

5.9 Gestion des données techniques

Se reporter au chapitre Système d'Information ou décrire les spécificités de la gestion et de l'enregistrement des données techniques.

Formulaires

Activités / documentation