Méthode et Procédure

REFERENTIELNORMATIF du CNES

R é f é r e n c e : RNC-CNES-M-40-516V e r s i o n 228 août 2000

Méthode et Procédure

DOSSIER DESCRIPTIF DE LACONFIGURATION D'UN LOGICIEL

(DDC)

APPROBATIONPrésident du CDN ;

date et nom :

METHODE ET PROCEDURE_______

DOSSIER DESCRIPTIF DE LACONFIGURATION D'UN LOGICIEL (DDC)

RNC-CNES-M-40-516Page i.1

Version 228 août 2000

PAGE D'ANALYSE DOCUMENTAIRE

TITRE : DOSSIER DESCRIPTIF DE LA CONFIGURATION D'UN LOGICIEL(DDC)

MOTS CLES : gestion configuration logiciel

RESUME :Ce document s'applique aux logiciels et indique :- ce qu'est un Dossier Descriptif de Configuration,- les exigences de réalisation (contenu type et structure),- des conseils pour satisfaire aux exigences.

SITUATION DU DOCUMENT :Ce document fait partie de la collection des Méthodes et Procédures associées auRéférentiel Normatif du CNES (ECSS et MP).Il est associé à la RNC-CNES-M-40-518, elle même affiliée à RNC-ECSS-M-40.

NOMBRE DE PAGES : 22 LANGUE : Française

Progiciels utilisés / version : Word 97

SERVICE GESTIONNAIRE : Délégation à l'Assurance de la Qualité du Centre Spatial deToulouse (DTS/AQ)

AUTEUR(S) : DATE : 02/02/2000

Didier PECCEU

RELECTURE / CONTROLE :

Pour ACCORD :Le Président du Comité Technique de Normalisation :

© CNES 2000Reproduction strictement réservée à l'usage privé du copiste, non destinée à une utilisationcollective (article 41-2 de la loi n°57-298 du 11 Mars 1957).





PAGES DES MODIFICATIONS

VERSION DATE PAGES MODIFIEES OBSERVATIONS

PR.6 24/06/98 Version de relecture générale

PR.7 25/11/99 Toutes Prise en compte desremarques de AQ, SIF, CSSI,SGC…, plus diversesmodifications visant à clarifieret alléger le contenu.

1.0 2/2/2000 Toutes Normalisation du document

1.1 23/5/2000 1, 2, 4, 5, 8 Prise en compte desremarques de DSO/SG

2 28/08/2000 Nouvelle codification desdocuments





SOMMAIRE

1. INTRODUCTION ......................................................................................................................................................... 1

2. OBJET............................................................................................................................................................................ 1

3. DOMAINE D'APPLICATION .................................................................................................................................... 1

4. DOCUMENTS DE RÉFÉRENCE ............................................................................................................................... 2

5. DOCUMENTS APPLICABLES .................................................................................................................................. 2

6. GLOSSAIRE - TERMINOLOGIE.............................................................................................................................. 2

7. QUELQUES RAPPELS ÉLÉMENTAIRES............................................................................................................... 3

8. PRINCIPES FONDAMENTAUX DU DDC ............................................................................................................... 4

8.1 BUT ET DOMAINE D'APPLICATION DU DDC ........................................................................................................... 48.2 CONFIGURATIONS ET VERSIONS CONCERNÉES ....................................................................................................... 48.3 PRODUCTION DU DDC .......................................................................................................................................... 58.4 LIVRAISON DU DDC.............................................................................................................................................. 58.5 FORME DU DDC.................................................................................................................................................... 58.6 RESPONSABILITÉS ................................................................................................................................................. 68.7 AUTHENTIFICATION DU DDC................................................................................................................................ 68.8 MODULATIONS DE LA FORME ET DU CONTENU DU DDC........................................................................................ 6

9. CONTENU DU DDC..................................................................................................................................................... 7

9.1 PRINCIPES ............................................................................................................................................................. 79.2 THÈMES TRAITÉS................................................................................................................................................... 79.3 SPÉCIFICATION DÉTAILLÉE DES FICHIERS DU DDC................................................................................................ 9



RNC-CNES-M-40-516Page 1


1. Introduction

Ce document fait partie de la collection des Méthodes et Procédures du Référentiel Normatif du CNES.Il appartient à la filiation "Gestion de la Configuration".

Il est associé à la RNC-CNES-M-40-518 "Exigences standards de Gestion de Configuration deslogiciels" (DR2) dont il constitue un complément.

2. Objet

Ce document a pour objet de :

• préciser le but d'un DDC (Dossier Descriptif de Configuration).

• définir :- le contenu et la forme du DDC- les conditions de sa réalisation et de sa livraison.

Il donne aussi des conseils pour satisfaire les besoins qu'il peut justifier ou illustrer.

3. Domaine d'application

Ce document s'applique à :

• tout Article de Configuration dont la nature est logicielle,

• la description de la configuration lors d'une mise dans la Base d'Archivage ou lors d'une livraisonentre un fournisseur (quel qu'il soit) et un client (typiquement un projet CNES).

• quel que soit son état d'avancement au cours de son cycle de vie (en développement, figé enexploitation, en maintenance ...).

REMARQUES :

Cette MP est applicable en l'état. Néanmoins, en fonction des caractéristiques du projet ou d'un Article,le client (le projet CNES) pourra l'amender, notamment en ce qui concerne la répartition et laprésentation des informations requises dans un ou plusieurs fichiers.

Le domaine d'application pourra être étendu par les utilisateurs. Par exemple en ajoutant un cataloguedes matériels et de leur documentation associée (y compris celle de paramétrage au sein du projet), il estpossible d'appliquer ce document à tout un système informatique dont la partie matérielle n'estconstituée que de matériels "sur étagère". De même on pourra le compléter pour assurer la maîtrise de laconfiguration d'un ou de plusieurs sites d'utilisation du logiciel.





4. Documents de référence

Cette MP est conforme au vocabulaire et aux exigences des documents suivants :

DR1 ISO 10007 Management de la Qualité - Lignes directrices pour la gestion deconfiguration. Ed. 95.

DR2 RNC-CNES-M-40-518

Exigences standards de Gestion de Configuration des logiciels.Édition 02 / Révision 00.

DR3 RNC-ECSS-P-001A

Glossaire des termes.

DR4 RNC-ECSS-M-40 Gestion de la configuration.Édition 02 / Révision 00.

DR5 RNC-ECSS-Q-20-09

Instruction et traitement des anomaliesÉdition A

DR6 RNC-CNES-M-40-502

Instruction et traitement des modificationsÉdition 01 / Révision 00

5. Documents applicables

Aucun

6. Glossaire - Terminologie

Article deConfiguration

Cf. DR2 chapitre 3.1.

Base d'archivage Espace informatique contenant la version adéquate des fichiers permettant defabriquer et tester une version donnée d'un logiciel (contient les fichiers sources,les procédures de génération, les jeux et résultats de test, ...).

DDC Dossier Descriptif de Configuration.

DM Demande de Modification (décrit au moins un besoin d'évolution).

Élément de Suivi Élément papier ou informatique permettant de formaliser le suivi d'un faittechnique. Exemples : FA (Fiche d'Anomalie), DM (Demande de Modification),PM (Proposition de Modification), FC (Fiche de correction), ...

GC Gestion de Configuration.

FA Fiche d'Anomalie (décrit au moins un constat d'anomalie).

FC Fiche de Correction et de Modification (compte rendu des évolutions faites pourprendre en compte un lot de FA et / ou de DM).





7. Quelques rappels élémentaires

La configuration d'un Article de Configuration logiciel est l'ensemble organisé :

- des éléments sources propres à cet Article et à partir desquels celui-ci est fabriqué ou décrit (sourcesdans un ou plusieurs langages informatiques, procédures de génération et d'assemblage,documentation de conception et d'utilisation, etc.).

- des moyens spécifiques nécessaires à sa production, son test ou son exploitation,

- des références des éléments non spécifiques nécessaires à la constitution ou la production del'Article exploitable.

Un logiciel est un Article de Configuration pouvant lui même, s'il est important, être décomposé enArticles de Configuration constitutifs.

La configuration peut être "figée" dans une version donnée archivée dans une Base d'archivage ou êtredans un état évolutif dont le dernier état est appelé, par analogie, "version courante".

Le client doit pouvoir disposer, sur requête ou à la livraison de l'Article concerné, d'un "DossierDescriptif de Configuration" (DDC) décrivant complètement cette configuration (exigence du DR2).

Normalement une livraison porte sur une version précise d'un produit qui typiquement servira deréférence pour la gestion des modifications ultérieures.

La fabrication et l'utilisation d'un produit sont généralement jalonnées de faits techniques faisant l'objetde descriptions formalisées appelées "Éléments de Suivi". Par exemple la FA (Fiche d'Anomalie), la DM(Demande de Modification), etc. Les Éléments de Suivi qui décrivent une anomalie de la configurationou une évolution faite ou à faire, font partie de la configuration de l'Article.





8. Principes fondamentaux du DDC

Les exigences majeures sont encadrées.

8.1 But et domaine d'application du DDC

1. Le Dossier Descriptif d'une Configuration doit décrire la configuration réelle d'un Article deConfiguration.

2. Le DDC est applicable à tout logiciel et à chacun de ses éventuels Articles constitutifs.

3. Il donne le contenu ou l'accès à toutes les informations décrivant complètement la configuration del'Article.

La configuration réelle est la configuration applicable complétée de l'ensemble des écarts connus entrecelle-ci et la réalité de l'Article.

Le DDC est destiné à de multiples utilisations, notamment :

• pour apprécier le degré de complétude et de cohérence d'uneconfiguration.

• pour s'assurer (généralement lors d'une réception) qu'un Articleest :. le bon Article : nom, identification de sa SpécificationTechnique de Besoin, etc.. au bon niveau d'évolution : version de l'Article et descomposants, corrections effectuées, etc.

• pour aider l'intégration de l'Article dans son contexte opérationnel en connaissant :. sa composition et les éléments qui ont évolué (programmes, documentation existante, etc.),. les anomalies ouvertes, les restrictions d'utilisation, .... les instructions détaillées de mise à jour par rapport à la version antérieure, et l'environnementnécessaire, etc.

8.2 Configurations et versions concernées

1. La configuration décrite doit correspondre à une version parfaitement identifiée d'un Articledonné.

2. La configuration applicable d'une nouvelle version de l'Article doit aussi être définie par différenceavec une version "de référence" parfaitement identifiée et connue du client.

Le nom de la version concernée doit être donné en clair en début de DDC.Dans le cas d'un état de configuration à un instant donné, alors que celle-ci est en cours d'évolution, onparlera de "version courante".

En l'absence de directive contraire du client, la version de référence est la dernière version livrée auclient et acceptée par lui.





8.3 Production du DDC

La production doit :

1. s'effectuer essentiellement à partir des données présentes dans la Base d'Archivage de laconfiguration de l'Article (c'est à dire à partir des sources et des Éléments de Suivi, et non d'uneautre référence).

2. être automatisée autant qu'il est possible pour garantir la fiabilité des informations, et minimiser letravail d'obtention (gains en coût et délai car l'élaboration du DDC est une tâche très récurrente).

3. être effectuée à partir des dernières données à jour correspondant à l'Article et après gel en versionde la configuration de celui-ci dans sa Base d'archivage.

8.4 Livraison du DDC

1. La livraison doit contenir la totalité du DDC, même s'il accompagne un produit livré partiellement(sauf accord du Responsable de la Gestion en Configuration destinataire).

8.5 Forme du DDC

Pour permettre une utilisation facile et efficace par ses destinataires, le DDC doit remplir les exigencessuivantes :

1. Le DDC est un dossier informatique contenant des fichiers sources lisibles sur les plates-formesde gestion et d'exploitation du client.

2. Les fichiers respectent les règles de Gestion des Configurations du projet, en particulier seséventuelles règles de marquage.

3. Le fichier d'identification (cf. "ddc.txt" plus loin dans le texte) et tous ceux qui contiennent uneinformation évolutive par rapport à une version donnée de l'Article (par exemple l'état des anomaliesconnues) doivent indiquer la version de l'Article concerné puis la date d'élaboration desinformations.

Les règles de marquages sont décrites dans DR2 (par exemple utilisation du marqueurs $ID$). Lecartouche de traçabilité n'est pas demandé.

Par défaut l'implémentation suivante sera retenue :

Objet Implémentation ObservationNom du dossier répertoire "ddc" directement attaché à

l'Article.Livré dans l'arborescence de l'Articlelorsque celui-ci est livré.

Format des fichiers texte Ascii.Noms des fichiers Cf. noms standards § 9.2Marquage desfichier

Marquage en première ligne.Version Article + date contenu en 2° ligne.

Cf. exigences générales dans DR2.





8.6 Responsabilités

1. Le DDC est élaboré par le Responsable de Gestion de la Configuration du fournisseur de l'Article, etsous la responsabilité de son chef de projet.

Lorsqu'un logiciel est archivé par le Service de Gestion de Configuration du CNES, celui-ci incorpore leDDC dans la configuration de l'Article avant d'en geler la version. Il peut ajouter des informations sousforme de fichiers complémentaires (exemples : fichiers ajoutés ou modifiés dans la base, moyens utiliséspour générer le logiciel…), mais aucun fichier du fournisseur n'est altéré.

8.7 Authentification du DDC

Sur demande explicite du client, le fournisseur devra fournir tout ou partie des éléments suivants :

• La copie papier du fichier introductif, signée par le chef de projet du fournisseur ou son délégataire.

• Le verrouillage du fichier introductif par une clé de contrôle à fournir au client.

• Le scellement de l'ensemble des fichiers (en vue d'un contrôle d'intégrité ultérieur éventuel).

8.8 Modulations de la forme et du contenu du DDC

En cas de besoin avéré, le client et le fournisseur pourront décider d'une forme de DDC plus élaborée(par exemple utilisation du Web) ou plus simple (par exemple un fichier unique) que celle proposée danscette MP, tout en en respectant les exigences fondamentales.

En standard, le DDC couvre la configuration complète du logiciel qu'il accompagne éventuellement,même si une partie seulement de cette configuration est livrée ou que celle-ci comporte des fichierssources ou des éléments transformés (typiquement des exécutables).

Dans le cas où contractuellement tous les éléments sources ou de test ou d'outillage spécifiques dulogiciel ne sont pas livrés, le DDC devra ne laisser aucune ambiguïté sur le statut "livré" ou "non livré"de tout élément apparaissant dans la liste des éléments de la configuration.

Dans certains cas, et sur demande ou autorisation formelle du client, le DDC pourra ne couvrir que laconfiguration des seuls éléments livrés, ou se limiter aux seules informations pertinentes du point de vuede l'utilisateur du produit (donc exclure les dérogations de méthodes de réalisation, les références auxdocuments de conception, etc.).





9. Contenu du DDC

9.1 Principes

Comme vu au § 8.1, le DDC donne l'accès à toutes les informations décrivant complètement laconfiguration d'un Article. Pour ce faire il donne une partie de l'information, de façon claire etstructurée, et référence les documents contenant le reste de l'information.

En particulier le DDC contient les informations non présentes dans les documents référencés :- informations de détail sans objet dans ces documents. Exemple : fichiers constitutifs, ...- informations évolutives non souhaitables dans la documentation standard. Exemple : versions de tellebibliothèque avec lesquelles cette version de l'Article est compatible ; comment la montée de niveaud'une base existante doit être réalisée avec cette nouvelle version, etc.- informations de dernière minute qui n'ont pu être introduites dans la documentation standard. Exemple: description d'une restriction d'utilisation, modalité particulière d'installation ou d'utilisation, etc.

1. Lorsqu'un Article comporte un composant de type Article, le DDC de ce "composant" n'est pasintégré dans celui du "composé".

2. Aucune duplication d'information ne doit être faite.

Lorsqu'un Article est exclusivement composé d'Articles ayant chacun un DDC, des regroupements defichiers peuvent être faits avec l'accord du client (exemple : les moyens de production).

Les duplications risquent d'apparaître, d'une part entre le DDC d'un Article donné et les documents qu'ilréférence (en particulier ceux de définition), et d'autre part entre le DDC de cet Article "A" et celui d'unArticle "B" dont "A" serait un composant ou un composé.

9.2 Thèmes traités

Le tableau ci-après donne :- la liste des thèmes couverts et une brève spécification du contenu attendu.- le nom court standard des fichiers correspondant à ces thèmes

Le nom réel d'un fichier pourra être le nom court, ou le nom long équivalant indiqué au § 9.3.Dans tous les cas il faut ajouter le suffixe du type concerné (".txt" par défaut, et omis dans la colonne dutableau pour raison d'économie de place).

Les parenthèses indiquent les noms longs lorsqu'ils peuvent contenir dans la colonne.Les crochets indiquent des fichiers facultatifs.

Un fichier dont le contenu informatif est conjoncturellement vide sera néanmoins livré en indiquantdedans qu'aucune information n'existe (par exemple aucune FA connue). Par contre, un fichier qui esttoujours vide dans le cadre d'un projet donné n'est pas livré. Cela doit être mentionné dans le fichierintroductif "ddc.txt".





Thème Fichier (*.txt) ContenuIdentification

du DDCde l'Article

des thèmes traités

ddc - titre, auteur et date d'édition du DDC- fiche d'identité de l'Article (libellé, rôle, société réalisatrice, etc.)- autres thèmes traités (Modification, Documentation, ...)- liste des fichiers composant le DDC.

Instructions détailléesde prise en compte

dans "ddc" ougenins

Comment, à partir du support livré, récupérer les éléments livrés,générer ce qu'il convient (exécutables, documents…), obtenir unlogiciel prêt à être installé, personnalisé, et utilisé (conformément auManuel d'Installation, le cas échéant).Pour cela donne les avertissements notables et renvoie plutôt vers 2fichiers qui détaillent les tâches de génération et d'installation.

Moyens requis pourdévelopper / générer /exploiter

Moyens, oumoy-dvlmoy-xpl

moy-gc

- Inventaire (nom, version, fournisseur, rôle) des moyens matérielset logiciels nécessaires (système d'exploitation, compilateurs,librairies, progiciels…).

- Détail de la configuration utilisée pour la génération du logiciel.Modificationsapportées

dans "ddc" oumodif

Version de référence, puis récapitulatif des changements notables(en particulier d'interfaces externes).

par rapport à uneversion de référence

fa-couv(ertes)dm-couv(ertes)dr-supprdelta-rf

[ls-fc]

Liste et éventuellement résumé de tous les Éléments de Suivi quijustifient cette version. En particulier :- Anomalies corrigées.- Évolutions fonctionnelles, adaptations et améliorations effectuées.- Dérogations supprimées (ie plus en vigueur).- Différences ("delta") entre les 2 versions dans la Base d'Archivage : liste des fichiers ajoutés, supprimés et modifiés.- Liste des FC (si Fiches de Correction utilisées dans le projet).

État desFaits Techniquesconnus en cours

etat-faetat-dmou etat-ftetat-dr

Liste (numéro, auteur, date, libellé …) des Éléments de Suivi :- Anomalies (avec gravité et parades éventuelles),- Demandes de Modification non closes (avec priorité),- Dérogations acceptées ou en attente de décision

Composition :- composants ls-ref

ls-xpl

Liste (nom, version, statut ajouté / supprimé / modifié) :- des fichiers sources dans la Base d'archivage.- des fichiers / modules sur site d'exploitation.

- documentsls-doc-fls-doc-uls-doc-d

Liste et version applicable de la documentation de :- spécification contractuelle du produit et du processus,- utilisation,- définition & réalisation.

Informationscomplémentaires

[AD] Selon demande du projet. Exemple : avertissements à l'utilisateur,différences concernant un point particulier...





9.3 Spécification des noms de fichier

Thème Nom court Nom longIdentification ddc ddcInstructions de prise encompte

genins

generationinstallation.

Moyens requis pourdévelopper / générer /exploiter

Moyens ou :moy-dvlmoy-xplmoy-gc*

moyens-developpementmoyens-exploitationmoyens-gestion-configuration

Modificationsapportées

dans "ddc" ou modif dans un chapitre du fichier "ddc" ou :modification .

par rapport à uneversion de référence

fa-couvdm-couvdr-supprdelta-rf[ls-fc]

fa-couvertesdm-couvertesdr-suppriméesdelta-reference*[liste-fc]

État desFaits Techniquesconnus en cours

etat-ft , ou :etat-fa

etat-dmetat-dr

ou etat-ft ou :etat-faetat-dmetat-derogations

Composition :- composants

ls-ref*ls-xpl

liste-reference*liste-exploitation

- documents ls-doc-fls-doc-uls-doc-d

liste-doc-referentiel-fonctionnelliste-doc-utilisateurliste-doc-definition

Inf. complémentaires / /

Les noms de fichier sont en minuscules, sans accent ni de blanc.

Plusieurs fichiers peuvent avoir un contenu propre au fournisseur et un contenu propre au client. C'est lecas notamment de ceux repérés par un *. Dans ce cas, le client le client et/ou le fournisseur identifierales siens par un suffixe correspondant à son code émetteur (par exemple "moy-gc-cn.txt" est issus duCNES).

9.4 Spécification du contenu et de la forme des fichiers du DDC

Les fichiers sont présentés dans l'ordre alphabétique de leur nom court.

Pour chacun d'eux est indiqué tout ou partie des éléments suivants :- son nom et son objet (dans le cartouche), et quelques commentaires si utile.- le contenu minimal requis (liste des informations attendues quand elles ont un sens pour le projet),- la présentation type (celle-ci n'étant cependant pas imposée),- l'ordre de tri par défaut (lorsqu'un tri est utile).La 1ère ligne de marquage n'est pas rappelée, sauf pour le premier (en prenant celle prévue pardéfaut).





ddc.txt fichier d'identification du DDC et du logiciel.

Ce fichier est appelé "Descriptif-produit" dans les projets anciens, notamment Spot et Hélios.

Seules quelques rubriques sont évolutives et doivent être mises à jour par le Responsable de la Gestionen Configuration avant toute livraison.

Le nom de certaines rubriques est volontairement "verbeux" de façon à pouvoir exécuter des rechercheset traitements informatiques automatiques (exemple "Code Article" et "Code Version").

Le cas échéant, on notera l'inexistence permanente ou temporaire de certains fichiers,comme par exemple la liste des composants matériels spécifiques.

Contenu type :

Marqueur (typiquement $ID$)

Dossier Descriptif de Configuration, fait :le : <date>par : <nom de l'auteur>selon spécification : <RNC-CNES-M-40-516 Ed.X>

Sommaire des thèmes traités (Modification, Documentation, ...) et renvoi vers les fichierscomplémentaires.

Identification de l'ArticleCode Article: <code, s'il en existe un>Libellé Article : <nom en clair du produit correspondant>Code OT : <code OT>Criticité Article : <criticité>Confidentialité Article : <confidentialité>Rappel de la fonction : <descriptif succinct de 2 ou 3 lignes>Fournisseur 1ere version : <fournisseur>

Identification de la versionDate Version: <JJ/MM/YYYY>Code Version: <version>Libellé Version: <indique la nature de la version en la situant par rapport à

un évènement clé tel qu'une revue, le début d'une phase de test...Exemple "version soumise à RCD">.

État Version: <niveau de validation subi, niveau d'opérabilité, etc.>.Justification : <Résumer le pourquoi de l'existence de cette version>.Type de configuration : <(complète ou non / produit utilisable ou non, etc.)>Fournisseur version : <fournisseur>

Instruction de prise en compteGénération : <notes importantes + référence procédure>Assemblage : <notes importantes + référence procédure>Composants liés : <dans le cas d'un projet multi Articles, indiquer la liste et la version

des autres Articles nécessaires à la production de celui-ci. Lesmoyens externes au projet sont cités dans les fichiers "moyens">

Observations diverses : <SO (sans objet) ou indiquer toute remarque utile>.





MoyensDéveloppement <cf fichier moy-dvl.txt>GC <cf fichier moy-gc.txt>Exploitation <cf fichier moy-xpl.txt>

Modifications

Version de référence : <identification claire de la version d'origine de l'Articlemême si c'est la précédente>

Résumé des modifications : <répercussions pour l'utilisateur (par exemple ajout d'une fonctionintéressante, amélioration des performances de x %, modification de l'interface, ...Si utile, indiquer la localisation des modifications (tels modules ou fonctions)Eventuellement déporter l'information dans un fichier "modif.txt" de forme et contenu libres>.

Identification des modifications :Corrections : <liste ou cf fichier fa-couvertes.txt>Modifications : <liste ou cf fichier dm-couvertes.txt>Dérogations supprimées : <liste ou cf fichier dr-suppr.txt>

Fichiers impactés : <liste ou cf delta-ref.txt>

Etat des faits techniquesAnomalies : <liste ou cf fichier etat-fa.txt>Demandes de Modification : <liste ou cf fichier etat-dm.txt>Dérogations : <liste ou cf fichier etat-dr.txt>

Etat de la référence :Base d'archivage : <cf fichier ls-ref.txt>Site d'exploitation : <cf fichier ls-xpl.txt>

Documentation :- fonctionnelle : <liste ou cf "ls-doc-f.txt">- d'utilisation : <liste ou cf "ls-doc-u.txt">- de définition : <liste ou cf "ls-doc-d.txt">

Chiffres caractéristiques <toutes données utiles ou requises, telles quetaille mémoire centrale, PROM et disque occupée,temps nominal de traitement (min, moy, max), …>

Autres thèmes imposés (cf § 9.2)

Informations complémentaires. <Autres informations définies au niveau projet>

Présentation : on pourra s'inspirer de l'exemple donné ci dessus, tout en mettant en évidence leschapitres.





delta-ref.txt Liste des fichiers ajoutés, supprimés et modifiés.

Contenu minimal : nom du composant, état de présence ou version dans la version de référenceet celle documentée.

Tri par défaut : ordre alphanumérique des composants (fichiers et répertoires).Présentation : une référence par ligne

(comme le ferait un listage récursif trié par une commande standard du système)

Exemple (3 fichiers, respectivement modifié, ajouté, supprimé) :Fichier Ref Versionchemin/toto.c 1.2 1.3chemin/tutu.c - 1.0chemin/titi.c 1.5 -

Remarques :

Les composants pourront aussi être présentés (toujours triés) dans 3 chapitres distincts : suppressions,modifications, ajouts.

Ce fichier peut être réduit à la liste des éléments supprimés si le fichier "ls-ref" est complété pourcontenir la version des fichiers dans la version de référence de l'Article et la version documentée. Dansce cas, il peut même être supprimé, sur accord du CNES, si l'Article concerné ne fait jamais l'objet d'unelivraison partielle.

dm-couvertes.txt Liste des modifications effectuées par rapport à la version de référence.

Contenu minimal : référence client, émetteur, date d'émission, titre de chaque demande.

Tri par défaut : par référence client.Présentation : un bloc de une ou deux lignes par demande.

dr-suppr.txt Liste des dérogations qui ne sont plus en vigueur (qui ont été supprimées).

Contenu minimal : référence client, émetteur, date d'émission, titre de chaque dérogation.

Tri par défaut : par type d'impact s'il est géré (tri selon la gravité décroissante d'impact sur leclient), puis par référence client.

Présentation : un bloc de une ou deux lignes par dérogation.

etat-dm.txt Liste des demandes de modifications ouvertes (à faire ou à décider) à la date degénération de ce fichier.

Contenu minimal : référence client, état (acceptée ou à décider), date émission, auteur/ Sté,titre, priorité ou planification.

Tri par défaut : par état/priorité/référence client.Présentation : une référence par bloc de 1 ou 2 lignes.





etat-fa.txt Liste des anomalies ouvertes (à statuer ou à corriger dans une versionultérieure) à la date de génération de ce fichier.

Contenu minimal : référence client, état (confirmée ou non, correction planifiée, ...),date émission, auteur/ Sté,titre, gravité, contournement (ou sa référence).

Tri par défaut : par gravité/référence.Présentation : une référence par bloc de 1 ou 2 ligne(s).

etat-dr.txt Liste des dérogations ouvertes (en vigueur ou à décider) à la date de générationde ce fichier.

Contenu minimal : numéros client [et fournisseur], état (en instruction, accordée, refusée, etc.),date émission, auteur/ Sté,titre,impact sur procédé de développement, utilisation du produit, qualité du produit.

Tri par défaut : impact puis par référence.Présentation : une référence par bloc de 1 ou 2 ligne(s).

fa-couvertes.txt Liste des anomalies déclarées corrigées par rapport à la version de référence.

Contenu minimal : référence client, émetteur, la date, le libellé des anomalies.Tri par défaut : par référence.Présentation : une anomalie au plus traitée par ligne. Le numéro de FC peut être ajouté.

gen.txt Notes concernant la génération et l'assemblage d'un produit installable.

Contenu : instructions de génération des binaires et de tout élément transformé à partir dessources, et d'assemblage du produit destiné à l'installation sur une cible particulière.Remarque : dans les cas simples, un paragraphe du "ddc.txt" suffira.

ins.txt Notes concernant l'installation du logiciel.

Contenu : Il est souhaitable que le Manuel d'Installation, qui fait l'objet d'un accord duCNES, comprenne les principes d'installation, et que le fichier ins.txt en contienne les détails respectantces principes mais susceptibles d'évoluer d'une version à l'autre.





ls-doc-d.txt Liste de la documentation de conception, de réalisation et de test.

Contenu minimal : référence, version, date d'émission, titre, organisme auteur,autres attributs demandés par le client.

Tri par défaut : ordre alphanumérique.Présentation : un document au plus par ligne.

Remarque :tout document ne relevant pas des catalogues ls-doc-u et ls-doc-f doit se trouver dans ls-doc-d.

ls-doc-f.txt Liste la documentation du référentiel fonctionnel (spécifications + contraintespour développer l'Article).

Contenu minimal, tri par défaut et présentation : cf. fichier "ls-doc-d.txt".

Remarque : tout ce qui définit le "contrat" entre le fournisseur et le client est dans ce fichier (donc lesdocuments de spécification de l'Article et du processus d'obtention, notamment les spécifications demanagement du CNES et du fournisseur, dont les "plans" de développement, d'Assurance Qualité, deGestion de Configuration, etc.)

ls-doc-u.txt Liste de la documentation livrée à l'utilisateur final.

Contenu minimal, tri par défaut et présentation i : cf. fichier "ls-doc-d.txt".

ls-fc.txt Liste ou contenu des FC par rapport à la version de référence.

Contenu minimal : référence des FA et DM prises en compte, et fichiers impactés par chaque FC.

Tri par défaut : code FC (si de tels codes sont gérés).Présentation : un bloc de une ou plusieurs lignes par FC.

Si le fournisseur respecte scrupuleusement l'exigence de DR2 concernant les cartouches de traçabilité, cefichier peut être restreint aux seules informations non automatiquement déductibles par le client à partirdes cartouches (cas de fichiers issus d'outils ne permettant pas l'adjonction des cartouches, ou desdocuments sans cartouche de même type). Une telle simplification doit être clairement indiquée en têtedu fichier ls-fc.txt ou dans le ddc.txt. Il peut aussi être sans objet si les fichiers fa- et dm-couvertes, oud'autres, donnent une information équivalente claire.

ls-ref.txt Liste et version des composants dans la Base d'archivage.

Contenu minimal : nom et version du composant.

Tri par défaut : par ordre alphanumérique des composants.Présentation : un composant par ligne.





Remarques :

• Généralement le composant est un fichier ou un répertoire. Dans le cas d'un Article composéd'Articles, il s'agit de ces Articles plus quelques composants (ne serait-ce que les jeux de test).

• Le nom d'un fichier est, soit précédé de son chemin informatique, soit listé dans un répertoire dont lechemin est indiqué.

• Selon l'outillage du fournisseur, la version pourra être déduite du marquage ou être remplacée par uneclé de contrôle (checksum par défaut).

• Ce fichier peut aussi englober les informations de delta-ref (dans ce cas et avec accord du CNES, cedernier pourra ne pas être fourni).D'autres attributs utiles pourront y être indiqués (si l'outillage le permet). Par exemple l'identificationdes éléments non livrés.

ls-xpl.txt Liste des composants que l'on doit obtenir après installation sur un sited'utilisation (exécutable, fichiers de paramètres, fichiers de messages,...).

Contenu minimal : référence, version, rôle, ... autres attributs utiles ou demandés par le projet.

Tri par défaut : par référence.Présentation : un élément par ligne.

Remarque : la version pourra être complétée ou remplacée par une clé de contrôle informatique acceptéepar le client (calcul de checksum par exemple).

Remarque : ce fichier sert essentiellement à vérifier qu'une installation a bien donné ce qui est prévu, àvérifier les évolutions ultérieures soit en cours d'utilisation soit lors d'une mise à jour d'un site, et àpermettre des mises à jour partielles mieux maîtrisées par le client.

moy-dvl.txt Moyens généraux (matériels et logiciels standards ou spécifiques externes auprojet) utilisés pour le développement ou la génération du produit.

Contenu minimal : nom du moyen, version, fournisseur, domaine d'utilisation requise, rôle& observation.

Tri par défaut : aucun (plutôt organiser par nature de ressource).Présentation : tableau.

Exemple : D / G indiquent qu'un moyen est nécessaire respectivement au Développement ou à laGénération.

outil version fournisseur D/G rôle & observationHP 9000 /750 H-P OO ordinateur de développement du sous-système XHP-UX 9.0a H-P OO operating system de développt des versions 2icompilateur C 3.2.5 H-P OO compilateur CMonitor 1.4 Indus-XX On moniteur de tests unitairesAS2 2.3, 2.4 Logiqual n n analyseur de code

(sous-système X testé en 2.3, et Y en 2.4)





moy-gc.txt Identifie la configuration de la Gestion de Configuration.

Contenu minimal : liste des fichiers du logiciel de base (librairies du système, des compilateurs, etc)utilisés pour générer les produits dérivés des sources (exécutables, documents composites, etc).

Tri par défaut : au choix du fournisseur.Présentation : aucune contrainte si ce n'est sa stabilité dans le temps pour permettre d'établir

les évolutions de contenu de manière automatique.

Remarque : fichier susceptible d'être émis par le fournisseur et le CNES (donc 2 fichiers distincts).Permet la recherche de causes possibles lorsqu'un programme "non modifié" ne marche plus "commeavant". Doit être obtenu par un script agréé par le CNES.

moy-xpl.txt Moyens non inclus dans le produit livré mais nécessaires pour l'utiliser.

Contenu minimal : nom du moyen, version, fournisseur, rôle

Tri par défaut : alphabétique ou par naturePrésentation : un moyen par ligne ; informations tabulées en colonnes.

Peut être fusionné avec"moy-dvl.txt". Mais la mise dans un fichier séparé rend l'information plus lisibleet permet une alerte automatique à la livraison. Il est souhaitable que tout changement imposant untravail important chez l'exploitant soit également signalé dans le fichier "ddc.txt" ou soit commenté dansle présent fichier.

REFERENTIEL NORMATIF REALISE PAR :Centre Spatial de Toulouse

Délégation à l'Assurance de la Qualité18 Avenue Edouard Belin

31401 TOULOUSE CEDEX 4

Tél : 05 61 27 31 31 - Fax : 05 61 27 31 79

CENTRE NATIONAL D'ETUDES SPATIALES

Siège social : 2 pl. Maurice Quentin 75039 Paris cedex 01 / Tel. (33) 01 44 76 75 00 / Fax : 01 44 46 76 76RCS Paris B 775 665 912 / Siret : 775 665 912 00082 / Code APE 731Z