04/05/2005

Démarche qualité du CDCDémarche qualité du CDC

07 avril 2006

2 / 32

Les plans d’applicationLes plans d’application

Plan spécifique au CDC Plan de Développement du CDC – A réaliser

Plans communs CDC et CMC Plan d’Assurance et Contrôle Qualité – A compléter Plan de Gestion de Configuration – A compléter

04/05/2005

Plan de contrôle et d’assurance qualitéPlan de contrôle et d’assurance qualité

Référentiel qualité du projet Arborescence de développement Nomenclature des programmes IDL Fiches produit Règles de codage Tests Gestion des modifications et des anomalies Gestion de la documentation

4 / 32

Référentiel Qualité CNES Référentiel Qualité CNRS Procédures internes laboratoires Spécification d'assurance

qualité pour les laboratoires du CMC

Dispositions simplifiées d’assurance qualité pour le développement des logiciels.

Instruction et traitement des modifications - Edit. 2, Rev. 0

Instruction et traitement des anomalies - Version 3

Plan d'assurance et contrôle qualité

Gestion de la documentation des projets informatiques

Bilan qualité Revue qualité fournisseur Protocole de réception interne Fiches de liaison Suivi des risques Planification et suivi de projet

Gestion de la documentation interne

Application au SSU Assurance Qualité du Projet

Plan de développement du CDC Plan de développement logiciel du CMC Plan d’assurance et contrôle qualité (PACQ) Plan de gestion de configuration (PGC) Procédures Modèles de document

▼

Référentiel qualité du projetRéférentiel qualité du projet

5 / 32

Qualité : Une arborescence de Qualité : Une arborescence de développement communedéveloppement commune

Arborescence de développement à définirsrc/….README INSTALLMakefile

6 / 32

Chaque IHM (=process) est identifiée

Code du laboratoire responsable (1 caractère) ayant pour modalités : L pour Marseille (LAM) M pour Meudon (LESIA) I pour IAS O pour OMP

Nom de l’IHM (20 caractères)

Qualité : une nomenclature pour chaque Qualité : une nomenclature pour chaque programme IDL (1)programme IDL (1)

7 / 32

Chaque programme IDL est décrit dans une fiche produit.

Un document regroupe l’ensemble des fiches produit. Il a pour titre « Répertoire des fiches produits » et sera livré à l’industriel lors de la recette Laboratoires->Industriel

Qualité : fiches produitQualité : fiches produit

8 / 32

Projet Corot Mission Center

Fiche descriptive de produit

Code du produit :

VIA_M_sismowind Libellé du produit : Définition du produit :

Définir le fenêtrage grande fenêtres ; Définir le fenêtrage des étoiles qui seront observées en mode mission ; Définir les positions des fenêtres de fond de ciel, leurs dimensions et le binning ; Définir les positions des fenêtres ASAP ; Vérifier la faisabilité de la programmation proposée.

Nom du binaire : sismowind.sav Exigences particulières portant sur le produit : Paramètres initiaux Paramètres évolutifs Paramètres finaux Durée de réalisation estimée : 4 mois Dont durée des tests estimée : 1 mois

Date prévisionnelle de fourniture : 15 mai 2005

Date contractuelle de livraison : 15/10/05 Date réelle de livraison :

Auteur du produit : Philippe Baron Laboratoire : LESIA

Responsable du produit : Michel Auvergne Responsable de la vérification : Emmanuel Grolleau

Activités et procédés à appliquer :

P R O D U I T

P R O D U C T I O N

Mettre une croix lorsque la phase est achevée Préparation Production Vérification Validation Mise à disposition

Chef d’équipe Développeur Resp. produit &Ing. Qualité

Chef d’équipe

Resp. Gest. Conf.

0.1

9 / 32

Un tableau de règles de codage IDL est présenté sur http://corotsol.obspm.fr/web-cdc/outils.html

Les règles sont divisées en trois catégorie:Obligatoires (à mettre en œuvre pour les développements

futurs comme passés)Fortement recommandées (à mettre en œuvre pour les

développements futurs)Recommandées (laissées à la libre appréciation du

développeur)

Qualité : Règles de codage (1)Qualité : Règles de codage (1)

10 / 32

Les règles obligatoires sont essentiellement des règles de présentation du code qui imposent l’utilisation d’en-têtes standards au niveau du projet pour les routines (procédures et fonctions), les modules et les fichiers batch.

En-têtes présentés sur le serveur http://corotsol.obspm.fr/web-cdc/outils.html

L’utilisation de ces en-têtes permet la création automatique (via make_html_help) d’un fichier html présentant l’objectif et le mode d’utilisation de chaque procédure IDL.

Qualité : Règles de codage (2)Qualité : Règles de codage (2)

11 / 32

;+; BEGINNING OF PROCEDURE;=======================================================================; BEGINNING OF HEADING;=======================================================================; NAME          : ; VERSION       : ; AUTHOR        :; CREATION DATE : ; DESCRIPTION   : ;=======================================================================; CALLING SEQUENCE;=======================================================================; type, param1 ; (IN) Parameter 1 description; type, param2 ; (OU) Parameter 2 description; type, param3 ; (OP) Parameter 3 description;=======================================================================; USED COMMONS;    COMMON <common_name> (common_file);; INCLUDED FILES;    @<include_file1_name> ; @<include_file2_name>;; EXTERNAL FUNCTIONS; <function1_name> ;  <function2_name>;; ALGORITHM;;   ; CHANGE:; <DD/MM/YY> ; <author> ; <change_description>;=======================================================================; END OF HEADING;=======================================================================;-;=======================================================================; BODY;=======================================================================Code de la procédure;=======================================================================; END OF PROCEDURE;=======================================================================

Caractères + et – pour make_html_help.pro

12 / 32

Auteur du produit

Développement du produit

Responsable du produit

Vérification de l’application des règles de codage Création du bilan de conformité aux règles de codage

V E R I F I C A T I O N

Livraison du produit et du bilan de conformité aux règles de codage

Examen du bilan de conformité aux règles de codage Examen éventuel du code source

Acceptation Refus

Chef de projet logiciel & Responsable qualité laboratoires

V A L I D A T I O N

Incorporation du produit sur le serveur de production

Retour du produit pour amélioration

▼ ▼

▼

◄

Qualité : Règles de codage (3) Qualité : Règles de codage (3) Procédure de vérification et de validation de la conformité aux Procédure de vérification et de validation de la conformité aux règles de codagerègles de codage

13 / 32

Les tests unitaires sont à la charge des développeurs.

Les tests d’intégration, de validation et de non régression sont élaborés en accord avec le chef de projet logiciel et le responsable qualité laboratoires.

Les tests sont numérotés séquentiellement pour chaque produit. Les fichiers

de tests sont placés dans le répertoire « test » de chaque produit.

Chaque test doit faire l’objet d’une fiche de test. Le numéro d’identification du test est composé comme suit :

<CODE_PRODUIT>.T<Numéro_chronologique>

U pour les tests unitaires (e.g. : test d’un programme IDL sans se préoccuper de son interaction avec la structure d’accueil);

I pour les tests d’intégration (e.g. : tests de l’intégration d’un programme IDL dans la structure d’accueil et test de l’enchaînement de plusieurs programme IDL);

N pour les tests de non régression (e.g. : tests suivant une correction ou une modification);

Exemple : VIA_M_findstars.T02

Qualité : Les tests (1)Qualité : Les tests (1)

14 / 32

FICHE DE TEST N° Test : Responsable : Date de test : Titre : Détail des tests Résultats attendus Résultats obtenus Conforme Objectif : Mode opératoire : Données : Environnement :

Oui

Non

Observations :

Qualité : Les tests (2)Qualité : Les tests (2)

15 / 32

Les modifications peuvent être de natures différentes :

adaptation ou évolution du périmètre fonctionnel, technologique ou organisationnel ;

correction suite à une non-conformité (anomalie dans le logiciel).

Qualité : Gestion des modifications et Qualité : Gestion des modifications et des anomalies (1)des anomalies (1)

16 / 32

Processus de gestion des demandes d’évolution et des constats d’anomalie

Constat d’anomalie

Demande d’évolution Analyse et évaluation par :

le comité de modification ou la commission de traitement

des anomalies.

Recherche de la cause

Réalisation des

corrections/modifications Confirmation de l’anomalie

Vérification des corrections/modifications

Clôture

Qualité : Gestion des modifications Qualité : Gestion des modifications et des anomalies (2)et des anomalies (2)

17 / 32

Titre du document : Titre

Réf. : COR_XXXXX Edition : X Date : JJ/MM/AAAA Révision : Y Pages : 2 Etat : (travail|terminé|vérifié|validé|archivé)

Réf. secrétariat :

Laboratoire d’Etudes Spatiales et d’Instrumentation pour l’Astrophysique tel : +33 (0)1 45 07 77 37 fax : +33 (0)1 45 07 71 44, 5 Place J. Janssen 92195 MEUDON FRANCE

OBSPM - LABO Réf. : COR_XXXXX Edit. : X Date : JJ/MM/AAAA CoRoT Rév. : Y Page : : 2/2

Qualité : Gestion de la documentation, modèle Qualité : Gestion de la documentation, modèle de présentation standard (documents livrables)de présentation standard (documents livrables)

18 / 32

CDC interfaces Labos/CNES Corotsky Exodat Patrons Sur-échantillonnage

Procédures d’échanges à définir…

A ajouter : A ajouter : Définition des échangesDéfinition des échanges

19 / 32

Utilisation d’un logiciel de modélisation de base de données (Case Studio)

Versioning du schéma (et du contenu de la base) Procédure de création de la base Règles d’intégrité

A ajouter : A ajouter : ArchivageArchivage

20 / 32

COR_51_AQ_LESIA_2 Plan de développement logiciel pour la contribution des laboratoires

au segment sol utilisateur.

XXXXXPlan de développement du CDC

COR_51_AQ_LESIA_1 Plan d’assurance et contrôle qualité pour les laboratoires du

segment sol CoRoT.

RNC-CNES-Q-80-534 Règles et recommandations pour l’utilisation du langage IDL –

version 1

DocumentsDocuments

04/05/2005

Plan de gestion de configurationPlan de gestion de configuration

Utilisation de l’outil CVS Quelques règles

22 / 32

Utilisation de l’outil CVS pour la gestion de configuration et le partage des sources et des documents.Versioning des sources IDLPartage des sources IDL entre les laboratoires

(Installation de CVS au LAM avec un lien direct sur le serveur CVS du LESIA)

Installation à l’IAS à prévoir ?

Gestion de configuration (1)Gestion de configuration (1)

23 / 32

Quelques règles : Les noms des procédures et fonctions IDL doivent être

composés uniquement de minuscules.

Caractères interdits dans les noms de fichiers (donc les noms de procédures ou de fonctions IDL)

* \ / [ ] : " ' ? @ $ * | \ ; " ' ? < > ` & ^ = ( ){ } Tous les caractères dont le bit de poids fort est à 1 (les caractères

accentués, ceux comportant des trémas et le "ç" en font partie) L'espace (car difficilement manipulable) - + ~ , (en début de nom seulement)

Gestion de configuration (3)Gestion de configuration (3)

04/05/2005

Plan de développement du CDCPlan de développement du CDC

Le contexte Schéma fonctionnel Les équipements Organigramme Technique du Projet Les livraisons Le macro-planning

25 / 32

Le LESIA de l'Observatoire de Paris ;

L’Observatoire Midi Pyrénées (OMP) ;

L’Institut d’Astrophysique Spatiale (IAS) ;

Le Laboratoire d’Astrophysique de Marseille (LAM) ;

Contexte : les laboratoires Contexte : les laboratoires impliqués dans le SSUimpliqués dans le SSU

26 / 32

Schéma fonctionnelSchéma fonctionnel

Responsable CDC : Annie Baglin Responsable technique : Sylviane Chaintreuil

Traitement N1-N2 Astéro - Réza Samadi (LESIA) Exoplanètes – Laurent Jorda (LAM) Intégration – Emmanuel Grolleau (LESIA) Production des données – Sylviane Chaintreuil (LESIA)

Archivage et distribution des données Responsable scientifique – Frédéric Baudin (IAS) Responsable technique – Jean Luc Orcesi (IAS)

Fournitures au CMC Corotsky – Stéphane Charpinet, Josiane Cuvilo (OMP) Exodat – Christian Surace (LAM) Patrons - Antoine Llebaria- Pascal Guterman (LAM) Alarmes, sur-échantilonnage - Pierre Barge (LAM)

Diffusion publique des données CoRoT Astronomes (Centre de Données de Strasbourg) Grand public (Outreach) – Enrique Solano (LAEFF)

27 / 32

Les équipementsLes équipements

Traitement N1-N2 (LESIA)Serveur de développement (CVS, IDL 6.2)Serveur de productionServeur de sauvegarde (ARKEIA)

Archive (IAS)A définir

Communication inter-labosA définir (Renater, exigences spécifiques ?)

28 / 32

CoRoT –CDC

Fournitures au CMC

Chaîne de traitement N1/N2

Archivage Gestion de projet

Production des patrons Exo

Spécification de la chaîne de traitement N1/N2

Spécification de la BD

Management du projet

Implémentation de la BD

Gestion de la qualité

Extractions Exodat

Initialisation de la BD

Gestion de la configuration

CoRoTSKY

Développement des process : astéro-sismologie exoplanète

Interface utilisateur

Gestion de la documentation

Outil d’alarmes pour le sur-échantillonage

Test des process de la chaîne de traitement N1/N2

Diffusion publique des données

Intégration des process de la chaîne de traitement dans la structure d’accueil

Communauté scientifique

Test de la chaîne de traitement intégrée

Grand public

Production des données

Org

anig

ram

me

Tec

hniq

ue d

u P

roje

tW

ork

Pac

kage

s

29 / 32

Les livraisonsLes livraisons

Traitement N1-N2Recette interne avant passage sur serveur de production

Fournitures au CMCCorotsky, Exodat, Patrons, alarmes :

procédures d’échange avec le CMC à définir

30 / 32

PlanningPlanning