Phase de développement  -  Qualité

glossairetélécharger pour imprimercontact
puceorange.gif (570 octets)





 
Plan d'assurance et contrôle qualité
Gestion de la documentation des projets informatiques
Bilan qualité
Revue qualité fournisseur
Protocole de réception interne
Protocole de réception externe (site pilote)
Fiches de liaison

puceorange.gif (570 octets)Plan d'Assurance et Contrôle de la Qualité

1. Objet et domaine d’application
2. Documents de référence
3. Abréviations et terminologie
4. Principes d’élaboration
5. Contenu type du document

1- Objet et domaine d’application

Le plan d'assurance qualité est un document énonçant les pratiques, les moyens et la séquence des activités liées à la qualité spécifiques à un produit, un projet ou un contrat particulier (Extrait de la norme ISO 8402:1994).

La démarche qualité à la DSI a pour but d'homogénéiser et d'assurer une cohérence dans les pratiques des projets afin d'améliorer la qualité des produits, d'optimiser les méthodes de travail, de capitaliser et partager les expériences. Elle s'appuie sur la définition, la stabilisation et la documentation des activités de développement des produits de la DSI, à deux niveaux :

  • niveau référentiel : il s'agit des procédures, plans types et guides méthodologiques communs à la DSI ; ces documents sont regroupées dans le site de conduite de projet de la DSI ;
  • niveau spécifique : il s'agit de l'application de ces procédures de manière spécifique dans chaque projet ; ces dispositions font l'objet d'un Plan d'Assurance et Contrôle Qualité (PACQ) par projet.

Le PACQ est un document rédigé pour chaque projet. Il est spécifique au projet considéré. C'est un document contractuel entre le maître d'œuvre et la maîtrise d'ouvrage.

2 - Documents de référence

3 - Abréviations et terminologie

cf Glossaire " Conduite de projet Systèmes d’information "

DSI = Direction des Systèmes d'Information
PACQ = Plan d'Assurance et Contrôle Qualité

4 - Principes d’élaboration

Le PACQ s'élabore lors du démarrage de la phase de développement du projet. Il est rédigé par le correspondant qualité DSI du projet en collaboration avec le chef de projet et le responsable qualité de la DSI.
Dans la pratique, il importe de se limiter aux dispositions les plus pertinentes pour le projet considéré et de veiller à la facilité d'utilisation du PACQ. Il doit rester un document synthétique renvoyant en tant que de besoins aux procédures, guides méthodologiques du site de conduite de projet de la DSI.
Après validation par le chef de projet et le responsable qualité de la DSI, le PACQ peut être diffusé à toutes les parties prenantes (Maîtrise d'ouvrage, Maîtrise d'œuvre, équipes projets…).
Le PACQ peut être remis à jour à chaque étape d'avancement du projet. Dans ce cas, il sera soumis à l'acceptation des interlocuteurs les plus directement concernés.

Remarque : Citer un document applicable implique que le responsable qualité contrôlera son application pendant le projet.

5 - Contenu type du document

Les textes entourés du caractère # sont à remplacer en fonction du projet.

1. OBJET ET CARACTERISTIQUES DU PLAN D'ASSURANCE ET CONTROLE QUALITE

1.1 Objectifs du plan
Ce paragraphe indique les objectifs du plan d'assurance et de contrôle de la qualité : buts, partenaires et finalités poursuivies. L'exemple donné ci-dessous est à reprendre en intégralité.

Exemple

Le plan d'assurance et contrôle qualité vise à décrire les dispositions prises par la DSI pour obtenir la qualité du logiciel définie en accord avec la maîtrise d'ouvrage.

Ce PACQ définit les méthodes, l'organisation et les activités d'assurance et de contrôle de la qualité spécifique au projet #nom du projet#.

L'utilisation de ce PACQ doit permettre d'atteindre les objectifs suivants :

  • constituer une référence commune à tous les membres de l'équipe projet. Il permettra d'assurer une bonne cohérence et une homogénéité dans les méthodes de travail.
  • garantir la qualité du produit et des prestations. ). Cette qualité s'exprime par des critères de qualité à respecter dans le cadre de ce projet qui sont détaillées au paragraphe 3.5 : Mesures de la qualité (propriété et métrique).
  • définir les procédures à suivre, les outils à utiliser, les normes à respecter, la méthodologie de développement du produit et les contrôles prévues pour chaque activités.

Nota : Le PACQ est un document de travail qui s'adapte au projet auquel il s'applique. Pour cette raison, certaines activités peuvent ne pas être précisées dans cette édition : elles portent alors la mention "A définir ultérieurement". Ce document sera alors complété en fonction du besoin.

 
1.2 Domaine d'application
Ce paragraphe permet d'identifier les systèmes et logiciels concernés par le PACQ. Il est spécifique à chaque projet et son contenu doit donc être adapter en fonction du contexte.

Exemple

Les dispositions décrites dans ce plan d'assurance et de contrôle de la qualité couvrent les processus de développement (depuis l'établissement du cahier des charges jusqu'à la diffusion sur les sites utilisateurs) aussi bien que les fournitures (documentation interne au projet, documentation utilisateur et application logicielle).


1.3 Responsabilité de réalisation et de suivi du plan
Donner ici les responsabilités des différents acteurs avec leurs rôles (définition, rédaction, diffusion, validation, mise en œuvre et suivi du plan) et leurs limites. Ce paragraphe est à reprendre en intégralité.

Exemple

L'établissement et les mises à jour du plan ainsi que le suivi de son application sont de la responsabilité du responsable qualité projet. Il est assisté dans cette tâche par la cellule qualité de la DSI. La coordination des actions à entreprendre pour la bonne exécution du plan relève de la responsabilité du chef de projet et du chef du bureau #nom du bureau#.


1.4 Documents applicables et documents de référence

1.4.1 Documents applicables
Lister ici l'ensemble des documents applicables : documents dont l'application est imposée et vérifiable (ex : procédures, normes…). Ce paragraphe pourra être adapter en fonction des projets dans le cas ou les documents mis en ligne sur le site de conduite de projet de la DSI ne seraient pas suffisants.

Exemple

L'ensemble des procédures et plans types applicables au projet se trouve sur le site de conduite de projet de la DSI à l'adresse suivante : http://www.dsi.cnrs.fr/conduite-projet/

En plus de ces documents il faut ajouter :

- #référence du document#
- #nom du document#
- #chemin d'accès : CNRS/DSI/…)#


1.4.2 Documents de référence
Lister les documents de référence : documents permettant d'effectuer le développement mais qui ne sont pas imposés (ex : guides méthodologiques…). Ce paragraphe pourra être adapter en fonction des projets dans le cas ou les documents mis en ligne sur le site de conduite de projet de la DSI ne seraient pas suffisants.

Exemple

L'ensemble des guides méthodologiques mis à la disposition des projets se trouve sur le site de conduite de projet de la DSI à l'adresse suivante : http://www.dsi.cnrs.fr/conduite-projet/

En plus de ces documents il faut ajouter :

- #référence du document#
- #nom du document#
- #chemin d'accès : CNRS/DSI/…)#


1.5 Critères et procédure d'évolution du PACQ
Ce paragraphe permet de définir les critères et la procédure d'évolution du PACQ. L'exemple donné ci-dessous est à reprendre en intégralité.

Exemple

Les mises à jour du plan doivent être justifiées par une amélioration des conditions de déroulement du projet ou de la qualité des fournitures. La cellule qualité de la DSI doit être tenue au courant des évolutions.

Le responsable qualité du projet est chargé des mises à jour du plan. Après validation par le chef de projet et le chef de bureau #nom du bureau#, il s’assure de sa diffusion auprès de l’équipe projet.

En cas de modification de dispositions applicables au titulaire, ces modifications lui sont soumises pour accord, puis acceptées par le comité contractuel.


1.6 Procédure de dérogation
Décrire ici les modalités de dérogation au PACQ. Ce paragraphe est commun à tous les projets. Il est à reprendre intégralement.

Exemple

Les membres de l'équipe projet sont tenus de se conformer aux dispositions décrites dans le plan d'assurance et de contrôle qualité. En cas de non-application de ces dispositions, une demande de dérogation doit être faite auprès du chef de projet et du chef de bureau #nom du bureau#.

 

2. TERMINOLOGIE

2.1 Glossaire des termes
Lister ici l'ensemble des termes communs au projet. Les principaux termes sont donnés dans le glossaire du site de conduite de projet de la DSI. Cette base commune de termes sera amenée à s'enrichir et pourra donc être adapter en fonction des besoins du projet.

Exemple

L'ensemble des définitions des termes associés au projet se trouve sur le site de conduite de projet de la DSI à l'adresse suivante : http://www.dsi.cnrs.fr/conduite-projet/glossaire.htm

Définitions supplémentaires liées à la particularité du projet :

- #Mot à définir# #Définition#
- #Mot à définir# #Définition#


2.2 Abréviations
Définir ici l'ensemble des abréviations spécifiques au PACQ. Les principales abréviations sont données dans le glossaire du site de conduite de projet de la DSI. Les abréviations spécifiques au projet peuvent faire l'objet d'un paragraphe complémentaire.

Exemple

L'ensemble des abréviations se trouve sur le site de conduite de projet de la DSI à l'adresse suivante : http://www.dsi.cnrs.fr/conduite-projet/glossaire.htm

Abréviations supplémentaires :

- #Abréviation# #Définition#
- #Abréviation# #Définition#

 

3. SYSTEME QUALITE MIS EN ŒUVRE POUR LE PROJET

3.1 Objectifs et engagements qualité du projet
Il s'agit de décrire ici les principaux objectifs et engagements qualité du projet. Ce paragraphe est à adapter en fonction des spécificités du projet.

Exemple

Les Directions de la maîtrise d'ouvrage d'XLAB et la Direction des Systèmes d'Information attendent du titulaire du marché de T.M.A. qu'il mette en œuvre les dispositions permettant de garantir au système XLAB :

  • la disponibilité,
  • la performance technique,
  • le respect des engagements contractuels de pilotage.

Chacun de ces trois objectifs est détaillé dans le paragraphe ci-après en terme de paramètres, d'engagements qualité, de propriétés et de métriques.


3.2 Mesures de la qualité (propriété et métrique)
Ce paragraphe permet de décrire les paramètres retenus pour atteindre les objectifs et les engagements qualité définis au paragraphe précédent. Il est à adapter en fonction des spécificités du projet. La qualité d'une prestation, d'un projet ou d'un produit se mesure par rapport à des paramètres.

Paramètre

Définition

Critères y contribuant

Fiabilité Aptitude avec laquelle il fonctionne sans défaillance pour une durée donnée (robuste, constant, etc.) - Disponibilité

- Robustesse

- Sécurité

Efficacité Aptitude avec laquelle il fonctionne avec un optimum de ressources et de temps

- Bonne utilisation des ressources machines (CPU, mémoire, ...)

Sécurité

(Intégrité)

Aptitude avec laquelle il est protégé contre les altérations ou les accès non autorisés (protégé, confidentiel, etc.). - Disponibilité

- Intégrité

- Confidentialité

Convivialité Effort requis pour l'apprentissage et le dialogue homme/machine et la documentation (compréhensible, maniable, documenté, etc.). - Ergonomie

- Facilité d'utilisation

- Facilité d'apprentissage

Réutilisabilité Aptitude avec laquelle il peut être utilisé dans de multiples applications (paramétrable, modulaire, indépendant, etc.) - Modularité

- Indépendance logiciel et matériel

- Niveau de paramétrage

Interopérabilité Aptitude avec laquelle il peut communiquer ou interagir avec d'autres systèmes (interfaçable, compatible) - Compatibilité

- Banalité des communications

- Banalité des données

Portable Effort requis pour le transférer d'un environnement à un autre. La portabilité peut être vue sous ses deux aspects :

- intégrable sur d'autres systèmes d'exploitation

- intégrable sur d'autres machines.

- Modularité

- Indépendance logiciel et matériel

Testabilité Effort requis pour s'assurer de son bon fonctionnement (jeu d'essais et vérification de résultats) - Modularité

- Automatisation des tests

- Facilité d'analyse des résultats

Corrigibilité Effort requis pour localiser et corriger une erreur (lisibilité, traçabilité, accessibilité, etc.) - Qualité de la documentation

- Règle de présentation et de nommage

- Modularité

- Traitement des erreurs

Adaptabilité Effort requis pour l'amélioration, à spécifications inchangées ou pour le modifier afin de répondre à de nouvelles versions du système d'exploitation. - Perfectibilité

- Flexibilité

- Modularité

- Niveau de paramétrage

Par paramètre, on définit les engagements qualité, les propriétés et les métriques permettant d'apprécier les objectifs souhaités.

Exemple

Les paramètres de qualité applicables au projet sont :

Paramètres

Engagements qualité

Propriétés

Métrique(s)

FIABILITE

Garantir la fiabilité du système Disponibilité

Indisponibilité du système, relative à une anomalie, inférieure à 8 heures cumulées par trimestre.

Livrer chaque version du système avec un minimum d'anomalies

Aucune anomalie bloquante recensée dans les versions diffusées auprès des utilisateurs.

SECURITE

Garantir la sécurité du système et la confidentialité des informations traitées. Utilisation et intégrité des données

Les bases réelles ne devront pas être utilisées pour les tests.

Des extractions partielles peuvent être effectuées par le CNRS en masquant l'identification des dossiers.

MAINTENABILITE

Assurer la maintenabilité et la réversibilité du système Lisibilité, exhaustivité et cohérence de la documentation technique associée à chaque version A chaque version , l’ensemble de la documentation technique est conforme, exhaustive et cohérente avec la version de référence du système, avec un taux maximum de 5% par rapport à une liste de contrôle à définir lors de la prise en main.
Taux de satisfaction des équipes du CNRS lors de l'exécution du poste de réversibilité technique Au moins trois quarts des personnels concernés considèrent que les prestations ont été correctement exécutées (exhaustivité, pertinence).

CORRIGIBILITE

Garantir la réactivité requise en cas de demandes de modifications.

Respect du délai de correction des anomalies bloquantes arrêté par le CNRS.

Livraison des versions intermédiaires pour réception par le CNRS, selon délai arrêté.

Respect du délai de livraison et des choix effectués par le CNRS pour les versions semestrielles Livraison des versions semestrielles selon délai arrêté, avec d’une part traçabilité totale entre les demandes de modification et les modifications réalisées, d’autre part traçabilité totale entre les tests de non-régression et les rapports de test.

EFFICACITE

 

CONVIVIALITE

     


3.3 Documentation qualité du projet
Ce paragraphe permet de définir la documentation qualité mise en place sur le projet. L'exemple qui suit est à reprendre en intégralité.

Exemple

La documentation qualité mise en place pour le projet #nom du projet# est structurée en trois niveaux de documentation : le PACQ, des procédures ou guides méthodologiques et des plans types.

Documentation

Fonction

Plan d'Assurance et Contrôle Qualité

Le PACQ définit les spécificités du projet et adapte les principes généraux du système qualité de la DSI. Il fait référence autant que possible aux procédures ou guides méthodologiques existants.

Procédures

Les procédures décrivent dans le détail et par thème le fonctionnement du système qualité et les méthodes en vigueur.

Guides méthodologiques

Les guides méthodologiques expliquent comment procéder pour réaliser les différentes tâches d'un projet (méthodes, techniques, outils, ...).

Plans types

Les plans types sont des modèles de documents, prêts à être utilisés par les acteurs d'un projet.

 

Architecture documentaire qualité du projet



3.4 Activités d'assurance et de contrôle de la qualité
Ce paragraphe décrit les activités d'assurance et de contrôle qualité appliquées sur le projet. L'exemple qui suit est à reprendre en intégralité.

Exemple

Chaque membre de l'équipe projet est tenu de respecter les dispositions décrites dans le PACQ et de vérifier l'adéquation du produit (document ou code) avec les normes en vigueur sur le projet (Autocontrôle).

Les activités du responsable assurance qualité projet se déroulent tout au long du projet. Elles sont de deux types :

  • les activités d'assurance qualité qui permettent de définir au plus tôt les principes qualités du projet et d'anticiper d'éventuels problèmes. Ces activités sont importantes au début du projet et dans une moindre importance au début des phases.
  • les contrôles qualité qui vérifient régulièrement que les procédures sont comprises et correctement appliquées. En cas de non-conformités réelles ou potentielles, il propose des actions correctives ou préventives. Il est chargé ensuite de suivre le déroulement de ces recommandations.

Le chef de projet est responsable de l'application du PACQ. Il valide les recommandations émises par le responsable qualité en cas de non-conformités constatées.

Activités qualité

 

Type d'activité

Descriptif de l'activité

Assurance qualité

Elaboration du PACQ

Interface avec la cellule qualité de la DSI

Participe aux revues internes DSI (revues de fin de phases)

Information de l'équipe projet sur les procédures en vigueur

Contrôle qualité

Relecture des documents projet

Contrôle de la bonne application des procédures applicables

Réalisation d'audits de contrôle (bilan qualité et revue qualité fournisseur)

Suivi des actions correctives ou préventives

 

3.5 Documents relatifs à la qualité du projet
Ce paragraphe permet de lister l'ensemble des documents relatifs à la qualité du projet. L'exemple qui suit est à reprendre en intégralité.

Exemple

 

Nom

Producteur

Périodicité

Destinataires

Missions

Plan d'assurance et contrôle qualité - resp. qualité

début de projet

- chef de projet

- équipe projet

- validation

- action (application)

Dossier de suivi qualité (bilans, CR revues) - resp. qualité

tout au long du projet

- chef de projet

- équipe projet

- validation

- information, action

 

4. CONDUITE DE PROJET

4.1 Organisation du projet
Décrire l'organigramme des missions assurées au sein du projet (liens hiérarchiques et fonctionnels) ainsi que les rôles et responsabilités : chef de projet, équipe projet… Le guide méthodologique "Pilotage des systèmes d'informations : instances et acteurs" donne les règles fondamentales et les recommandations au niveau de l'organisation et du rôle des acteurs intervenant dans un projet. Si le projet respecte l'organisation préconisée dans ce guide, ce paragraphe pourra se limiter à un renvoie à ce dernier.

En fonction des particularités du projet, cette organisation pourra être modifier. Dans ce cas, ce paragraphe devra faire l'objet d'une description détaillée.

Exemple

L'organisation du projet #nom du projet# respecte celle décrite dans le document "Pilotage des systèmes d'informations : instances et acteurs" qui se trouve sur le site de conduite de projet de la DSI à l'adresse suivante : http://www.dsi.cnrs.fr/conduite-projet/principes/intances-acteurs/Default4.htm


4.2 Présentation des activités couvertes par le projet
Ce paragraphe est spécifique à chaque projet. Il permet de présenter sous la forme d'un ou plusieurs organigrammes, l'ensemble des activités qui sont nécessaires au projet. Cette partie sera donc à adapter en fonction des particularités du projet.


4.3 Planification et suivi du projet
Ce paragraphe permet de décrire les méthodes de planification et de suivi utilisées dans le projet.
Le guide méthodologique "Suivi de projet" donne des recommandations au niveau de la planification et du suivi de projet. Si le projet respecte ces recommandations, ce paragraphe pourra se limiter à un renvoie à ce dernier.
Dans le cas ou les méthodes de planification et de suivi de projet ne sont pas celles données dans le guide méthodologique, ce paragraphe devra faire l'objet d'une description détaillée.
L'exemple donné ci-dessous est à reprendre intégralement lorsque les recommandations données dans le guide de suivi de projet sont respectées.

Exemple

Le chef de projet est chargé de la planification et du suivi du projet. Les principales tâches et jalons du projet sont gérés dans le planning global du projet.

Pour le suivi des travaux internes, des réunions périodiques sont organisées entre le chef de projet et les membres de l’équipe. Un journal de bord est tenu et permet de garder une trace des informations communiquées, des problèmes rencontrés, des décisions prises, des responsables désignés pour mener à bien les actions et la date de réalisation de l’action.

Pour le suivi des travaux avec l'équipe titulaire du marché, deux comités sont mis en place :

  • un comité contractuel
  • un comité opérationel

Le détail de l'organisation mise en place pour la planification et le suivi du projet se trouve sur le site de conduite de projet de la DSI à l'adresse suivante : http://www.dsi.cnrs.fr/conduite-projet/phasedefinition/gestion-de-projet/planification-suivi-projet/Default2.htm

 

5. DEMARCHE DE DEVELOPPEMENT DU SYSTEME D'INFORMATION

5.1 Cycle de développement
Ce paragraphe permet de décrire la méthodologie de développement du système d'information. Deux types de développement peuvent être utilisés :

  • le développement spécifique,
  • le développement avec un progiciel de gestion intégrée.

Ces deux types de développement sont décrit dans le détail sur le site de conduite de projet de la DSI à l'adresse suivante : http://www.dsi.cnrs.fr/conduite-projet/phasedeveloppement/presentation/default.htm

Ce paragraphe est à adapter en fonction du type de développement retenu. Il se limitera à une représentation schématique du cycle de développement utilisé et à un renvoie au site de conduite de projet de la DSI.

Exemple
Le cycle de développement mis en place pour le projet #nom du projet# est celui d'un développement spécifique. Il suit les principes donnés sur le site de conduite de projet de la DSI (http://www.dsi.cnrs.fr/conduite-projet/phasedeveloppement/presentation/default.htm)

Le cycle de développement de ce projet est organisé tel que représenté par le schéma ci-dessous :

:


Les étapes du cycle de développement sont détaillées dans le chapitre suivant.


5.2 Description des étapes
Ce paragraphe permet de détailler les étapes du cycle de développement. Chaque étape est décrite dans un tableau qui regroupe les informations suivantes :

  • description de l'étape,
  • tâches à réaliser,
  • responsabilités,
  • méthodes, langages, outils (matériels et logiciels utilisés),
  • fournitures attendues (logiciel, documentation).

Ce paragraphe est à adapter en fonction des particularités du projet. Il indique principalement les dispositions détaillées spécifiques au projet de développement. Le rédacteur devra s'attacher à respecter les recommandations données sur le site de conduite de projet de la DSI notamment sur tout ce qui concerne le déroulement des étapes ( voir http://www.dsi.cnrs.fr/conduite-projet/phasedeveloppement/presentation/default.htm ) et les livrables attendus ( voir http://www.dsi.cnrs.fr/conduite-projet/phasedeveloppement/qualite/gestion-doc/Default2.htm ).

Exemple
La description des étapes est donnée sous forme de tableaux :

ETUDE PREALABLE

Description de la phase

  • Définir les besoins en terme d'évolutions fonctionnelles et techniques par rapport au système existant

Actions entreprises

  • identifier les évolutions fonctionnelles, techniques et organisationnelles à apporter au système d'information,
  • animer des groupes de travail afin d’identifier les besoins et la terminologie,
  • formaliser ces expressions de besoins (grands principes d'organisation, description des procédures et actes de gestion inclus dans le périmètre fonctionnel, principales règles de gestion),
  • identifier des propositions de solutions pour l'intégration dans le système existant,
  • faire valider cette expression de besoins et ces propositions de solutions par les instances de pilotage du projet.

Outils

Visio pour le schéma des procédures.

Règles et standards applicables spécifiques au projet

Sans Objet

Fournitures de l'étape

Nom

Responsabilités

Destinataires

Missions

Dossier d'étude préalable
  • Chef de projet
  • Equipe de spécification
  • resp qualité
  • chef de projet
  • comités
  • vérification
  • validation
  • validation

 

6. GESTION DE LA DOCUMENTATION
Ce paragraphe permet de décrire les règles de gestion de la documentation du projet. Le guide méthodologique "Gestion de la documentation des projets informatiques" donne les méthodes pour référencer, classer, organiser de manière homogène l'ensemble de la documentation relative au projet.
Ce paragraphe fera référence à ce guide pour tout ce qui est :

  • responsabilités,
  • cycle de vie et état des documents,
  • présentation et structure de la documentation,
  • outils de gestion de la documentation,
  • classement de la documentation.

L'exemple donné ci-dessous est à reprendre en intégralité.

Exemple

La documentation d'un projet a une importance primordiale, comme outil de dialogue entre les membres de l’équipe projet et les intervenants extérieurs (membres des structures de pilotage, chef du bureau, sous-traitants...). Ce chapitre précise les règles de gestion de la documentation mises en œuvre dans les projets. Les dispositions prévues sont conformes aux recommandations émises dans le guide méthodologique "Gestion de la documentation des projets informatiques" pour tout ce qui est :

  • responsabilités,
  • cycle de vie et état des documents,
  • présentation et structure de la documentation,
  • outils de gestion de la documentation,
  • classement de la documentation.

Ce guide est accessible à l'adresse suivante : http://www.dsi.cnrs.fr/conduite-projet/phasedeveloppement/qualite/gestion-doc/Default2.htm


6.1 Identification de la documentation
Décrire ici les règles d'identification propres au projet.


6.2 Sauvegarde et archivage
Décrire ici les procédures de sauvegarde et d'archivage propres au projet :

  • structure des dossiers de sauvegarde, droits d'accès,
  • périodicité,

Exemple

La sauvegarde des fichiers est faite quotidiennement par l'administration du serveur (conservée pendant 30 jours puis mensuellement sur un an).

 

7. GESTION DE LA CONFIGURATION LOGICIEL

7.1 Responsabilités
Ce paragraphe décrit les responsabilités pour le processus de gestion de la configuration logiciel du projet. Il est à adapter en fonction des spécificités du projet.

Exemple

La gestion en configuration des composants logiciel pendant le développement jusqu'à l'établissement du procès-verbal de réception définitive est de la responsabilité de l'équipe de TMA.

Une fois la livraison définitive effectuée par l'équipe de TMA, l'équipe de réception est chargée de gérer la configuration de l'application.


7.2 Identification des éléments
Décrire ici l'ensemble des éléments impactés par le processus de gestion de la configuration. (liste des composants logiciels de l'application, des moyens de développement et de tests, règles de constitution des identifiants, liaisons entre les différents éléments).
Ce paragraphe est à adapter en fonction des spécificités du projet.

Exemple

Les éléments logiciel à gérer en configuration sont tous les composants nécessaires à la génération de l'exécutable puis à l'exécution de l'application.


7.3 Cycle de vie et états des éléments
Ce paragraphe permet de décrire :

  • les méthodes de gestion des versions, révisions,
  • les modalités de vérification et de validation.

Il est à adapter en fonction des spécificités du projet.

Exemple

Les espaces de configuration sont les suivants :

  • réalisation : contient les composants en cours de développement. Cet espace est géré par l'équipe de TMA
  • échange TMA-DSI : contient les livraisons effectuées par l'équipe de TMA (zone tampon provisoire).
  • réception interne : contient la dernière version livrée par l'équipe de TMA.
  • réception externe : contient la dernière version installée sur site pilote.
  • diffusion : contient la dernière version de l'application diffusée aux utilisateurs.
  • échange DSI-TMA: contient les livraisons effectuées vers l'équipe de TMA (zone tampon provisoire).

Chaque version de l'application diffusée sur le site utilisateur est identifiée par 3 indices : X.YZ, avec

- X = numéro de version de l'application, démarre à 1, est incrémenté lors d'évolutions importantes de l'application (règles d'organisation par exemple)

- Y = indice de révision d'une version, démarre à 0, est incrémenté lors d'évolutions fonctionnelles ou d'adaptations (règles de gestion par exemple)

- Z = "sous-indice" de révision d'une révision, démarre à 0, est incrémenté lors de la correction d'anomalies de fonctionnement.

Exemple : la version 1.1 est la première version (sous-ensemble 1) de l'application diffusée aux utilisateurs. La version contenant le sous-ensemble 2 est la V1.2.


7.4 Sauvegarde et archivage
Décrire dans ce paragraphe les méthodes de sauvegarde et d'archivage pour le processus de gestion de la configuration logiciel.
Ce paragraphe est à adapter en fonction du projet.

Exemple

Les espaces de configuration sont organisés de la manière suivante dans le répertoire BUZET/projets :

XLAB/SSII : espace de REALISATION

XLAB/ ECHANGE/DSI-SSII : espace d’ECHANGE DSI-TMA

XLAB/ECHANGE/SSII-DSI : espace d’ECHANGE TMA-DSI

XLAB/DSI/Vx.x/RCI : espace de RECEPTION INTERNE

XLAB/DSI/Vx.x/MO/SITES_PILOTES : espace de RECEPTION EXTERNE

XLAB/DSI/Vx.x/VERSIONDIFFUSEE : espace de DIFFUSION

Les droits d'accès de l'équipe de TMA sont les suivants :

XLAB / SSII : tous types

XLAB / ECHANGE : tous types

Les droits d'accès des membres du projet DSI sont les suivants :

XLAB / DSI : tous types

XLAB / ECHANGE : tous types

XLAB / SUIVI : tous types


8 GESTION DES MODIFICATIONS
Ce paragraphe permet de décrire le processus de gestion des modifications du projet.
La procédure "Gestion des modifications" décrit dans le détail ce processus qui est applicable à tous les projets de la DSI.
L'exemple donné ci-dessous est à reprendre en intégralité.

Exemple

Les demandes de modifications font l'objet de procédures de gestion spécifiques.

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 ou dégradation de la base de production).

Ces activités sont mises en œuvre lors du développement initial d'un système d'information ou à chaque itération de développement d'une nouvelle version en phase de MAINTENANCE/EVOLUTION.

Le processus de gestion des modifications est complètement décrit dans la procédure en vigueur à la DSI. Cette procédure est accessible à l'adresse suivante: ../../../phasemaintenance/technique/gestion-modification/default.htm


9. CONTROLE DES FOURNISSEURS
Ce paragraphe permet de décrire les relations DSI-Fournisseurs et les modalités de suivi ou de contrôle dans le cas d'achats de prestations intellectuelles pour la production d'un nouveau système d'information ou pour la maintenance d'une application existante.

La procédure "Maîtrise des achats" définie dans le détail ce processus.

Exemple

Le projet #nom du projet# sous-traite la TMA de son application, c'est-à-dire les travaux liés aux spécifications techniques, à la réalisation, aux tests, à la mise en œuvre du système sur site pilote et au maintien en conditions opérationnelles du système.

Les obligations du titulaire du marché de TMA sont exprimées par le CNRS/DSI dans les pièces du marché : CCAP, CCTP.

Ce chapitre récapitule les documents utilisés dans les relations entre la DSI et l'équipe de TMA.

La procédure "Maîtrise des achats" détaille le processus de maîtrise des achats en vigueur à la DSI. Cette procédure est accessible à l'adresse suivante : http://www.dsi.cnrs.fr/conduite-projet/developpement/gestion-projet/achats/Default.htm


9.1 Documents de liaison
Donner ici la liste des documents de liaisons. Cette liste pourra être adapter en fonction des projets.

Exemple

 

REFERENCE DU DOCUMENT

TITRE DU DOCUMENT

ACTEURS

CO_aammjj.doc

Compte Rendu de Comité opérationnel

titulaire ® équipe DSI

CC_aammjj.doc

Compte Rendu de Comité contractuel

titulaire ® équipe DSI

FL_aammjj.doc

Fiche de liaison

équipe DSI « titulaire

DI_apl_xxxnnn.doc

Demande d'intervention pour une évolution ou une adaptation (refonte technique)

équipe DSI ® titulaire

MDA_apl_xxxnnn.doc

Modification de document applicable

équipe DSI ® titulaire

PDA_apl_xxxnnn.doc

Précision de document applicable

titulaire ® équipe DSI

OS_aammjj.doc

Notification d’un ordre de service

équipe DSI ® titulaire

PVL-xxxxx-xx.doc.

Procès verbal de réception

équipe DSI ® titulaire


9.2 Description des documents
Décrire ici de manière succincte les objectifs de chacun des documents de liaisons.

Exemple

- Compte-rendu de comité opérationnel (formulaire fourni par la DSI, Word) :
Ce document, à la charge du chef de projet du titulaire, rend compte de l’avancement du projet, des actions et risques en cours... sur une période donnée. Il doit être diffusé 2 jours avant les réunions de comité opérationnel. Il est étudié pendant le comité. Il est mis à jour après la réunion du comité par le chef de projet du titulaire en fonction des décisions prises en comité et est soumis à validation par la DSI dans les 3 jours qui suivent la réunion.
Il est référencé comme suit : CO_AAMMJJ

- Compte-rendu de comité contractuel (formulaire fourni par la DSI, Word, avec en annexe des tableaux de synthèse financière fournis par la PRM) :
Ce document, à la charge du chef de projet du titulaire, est le compte-rendu de chaque comité contractuel. Il est soumis à validation par la DSI dans les 3 jours qui suivent la réunion du comité.
Il est référencé comme suit : CC_AAMMJJ

- Fiche de liaison (formulaire fourni par la DSI, Word) :
Cette fiche est une fiche multifonctions permettant de formaliser et tracer des demandes d'information ou de conseil au titulaire. Elle peut s'adresser à plusieurs personnes (destinataires ou copies) et contient la date de réponse souhaitée.

- Demande d'intervention - DI (formulaire fourni par la DSI, Word) :
Cette fiche matérialise la demande d'intervention à analyser par le titulaire.

Elle est complétée par le titulaire et retournée à la DSI. Elle est visée par le chef de projet et le titulaire lorsqu'il y a accord sur le contenu, l'analyse et éventuellement le chiffrage et les délais.

- Modification de document applicable - MDA (formulaire fourni par la DSI, Word) :
Cette fiche permet à la DSI d'apporter des modifications à des documents applicables par l'équipe du titulaire, sans avoir à rééditer les documents en question, mais en prévoyant l'impact sur les charges et délais de réalisation. En particulier, les MDA sont utilisées pour modifier le cahier des charges (ensemble de DI en cours de réalisation).

- Précision de document applicable - PDA (formulaire fourni par la DSI, Word) :
Cette fiche permet à l’équipe de TMA de lever des imprécisions ou des ambiguïtés, de faire valider une interprétation des spécifications du cahier des charges qui leur a été confié. Elle est envoyée à l'équipe DSI qui confirme ou compléte l’expression de la précision faite par le titulaire et la lui renvoie visée.

- Lettre de notification d'un ordre de service ou d'une commande (formulaire fourni par la DSI) :
Ce document permet à la DSI de notifier l'exécution de travaux au titulaire.

- Procès verbal de réception définitive ou provisoire (formulaire fourni par la DSI, Word) :
Cette fiche exprime que l’équipe DSI a bien contrôlé la livraison ou les travaux du titulaire, et que ceux-ci s’avèrent corrects.

htpage.gif (1527 octets) glossairetélécharger pour imprimercontact