Procédure d'Assurance Qualité

Documents de Qualité

Cette page présente un résumé des divers documents utilisés dans la procédure d'assurance qualité.

AQ.1 Plan Qualité

Le Plan Qualité a pour objet de définir toutes les mesures qui seront prises afin d'assurer la bonne fin du projet.

Normalement, un Plan Qualité de Référence doit préexister au sein de la société. Il décrit d'une façon générale comment la qualité doit être gérée dans un projet du même type. Il est important de mener une politique de qualité visant à améliorer en permanence de Plan Qualité de Référence en fonction de l'expérience acquise. De cette façon, la qualité générale des projets ira en s'améliorant.

Le Plan Qualité de Référence est souvent accompagné d'un ensemble de formulaires et de documents types qui facilitent la gestion de la qualité dans les projets particuliers.

Le Plan Qualité de Référence sert de base à la rédaction du Plan de Qualité de Projet. Celui-ci décrit la façon particulière dont la qualité sera gérée au cours d'un projet déterminé.

Le Plan de Qualité de Projet peut être commencé très utilement durant la phase commerciale et figurer comme une annexe au contrat. C'est en effet lui qui définit au plus près les droits et les obligations de toutes les parties, ainsi que la façon dont on s'est accordé pour gérer l'ensemble du projet.

En tout état de cause, le Plan de Qualité de Projet doit être finalisé durant la phase préparatoire de prise en charge du projet.

Le Plan de Qualité de Projet est un document de synthèse couvrant toutes les activités du projet. Typiquement, il couvre l'ensemble des sujets suivants; il peut soit les décrire directement, soit se référer à des documents partiels.

 Facteur clef: il est important d'avoir un document de référence unique décrivant l'ensemble des obligations de toutes les parties concernées. Le Plan de Qualité servira aussi de référence commune en cas de litige.

 Facteur clef: le Plan de Qualité sert à mettre d'accord entre elles les différents parties concernées sur les différents aspects de la vie du projet, afin d'éviter au maximum les litiges ultérieurs.

 Etablir la description générale du projet

 Facteur clef: s'assurer que tous les participants aient bien la même compréhension du projet et de ses éléments critiques

 Décrire le projet, ses objectifs, son contexte et son historique

 Contraintes principales du projet: limites budgétaires, contraintes de planning

 Décrire les limites du projet: ce qui ne sera réalisé conformément au contrat

 Identifier les principaux facteurs de risque et de succès

 Etablir le plan du projet

 Décrire les étapes du projet ('project workbreakdown structure')

 A chaque étape, associer:

 un planning, des dates

 des délivrables

 des points de contrôle

   Fixer les responsabilités communes et les dépendances

 Décrire les responsabilités des différentes parties concernées

 En particulier, quand le projet s'inscrit dans un système existant (interfaces), identifier toutes les composantes concernées et décrire l'impact qu'aura le projet sur elles, ainsi que les adaptations nécessaires.

 Facteur clef: la participation du client ou de l'utilisateur est souvent sous-estimée alors qu'elle est un élément critique dans le succès ou l'échec du projet. C'est ici qu'il faut identifier et quantifier quelle devra être sa participation. Voici un ensemble de fonctions nécessitant son intervention active:

 Fournir tout le support matériel nécessaire au développement puis à la mise en production

Locaux, mobilier de bureau

Ordinateurs et équipements

 Fournir l'information nécessaire

Si nécessaire, documenter avec précision les procédures actuelles qui font seulement l'objet d'habitudes ou d'une tradition orale.

Si nécessaire, documenter les applications existantes

 Valider les spécifications détaillées

 Fournir les données de test

 Modifier ou adapter les autres applications en aval et en amont

 Participer aux tests et à la réception

 Modifier, corriger ou adapter les procédures internes

 Participer aux formations; organiser la formation

Rédiger modes d'emplois adaptés aux cas concrets de l'entreprise, vade-mecum et autres documentations pratiques

 Introduire les signalétiques et autres données de base

 Mettre en place l'environnement d'exploitation

 Décrire les limites dans les ressources disponibles: là où l'on sait que la situation n'est pas idéale

Il faut à la fois tenir compte de ces limitations et bien mesurer leur impact négatif sur le projet

 Décrire les activités de réalisation qui seront effectuées au cours du projet

  Inventaire des délivrables

 décrire de façon exhaustive, sous forme d'inventaire, tout ce qui devra être produit ou réalisé durant le projet: réalisations (points de fonction) et documentation.

 spécifications détaillées: décrire la façon dont les spécifications détaillées seront produites et approuvées.

 demandes de modification ('Change Request')

définir la façon dont des demandes spécifiques seront jugées comme à étant l'intérieur du périmètre du projet, ou au contraire, comme réalisables en supplément.

Décrire la façon dont les demandes de modification seront gérées.

 Décrire les procédures et méthodes de réalisation qui seront appliquées,

Montrer dans le Plan de Projet que ces méthodes répondent aux objectifs de qualité, qu'elles sont bien documentées, et bien connues des divers intervenants.

 Décrire les activités de gestion de projet qui seront effectuées au cours du projet

mettre en place les différents organes chargés de la gestion du projet, c'est à dire de faire en sorte que les réalisations prévues soient effectivement réalisées dans les délais et le budget prévus

fixer les comptes-rendus qui devront être produits et leur liste de diffusion

 Décrire les activités d'assurance qualité qui seront effectuées au cours du projet

fixer les objectifs de qualité

fixer les directives pour la façon dont le contrôle qualité devra être effectué, notamment la façon dont les différents tests devront être exécutés, dont la réception sera prononcée, et la façon dont les anomalies seront gérées. Ces directives déterminent la façon dont le Dossier de Réception et le Dossier des non-conformités seront établis par la suite.

En particulier, il est important de définir:

quels statuts de non-conformité entraîneront le refus d'acceptation (erreur bloquante)

quels statuts de non-conformité entraîneront une acceptation sous réserve (erreur légère)

   Assigner les responsabilités individuelles et les ressources humaines

 Chaque partie doit assigner des ressources humaines en nombre et en qualité suffisants pour remplir ses responsabilités et réaliser les activités qui lui sont assignées.

Préciser dans toute la mesure du possible le temps nécessaire, les jours prévus pour les réunions et autres séances de travail, afin que l'engagement de fasse en connaissance de cause.

 Désigner des responsables pour les 3 types d'activités:

activités de réalisation

activités de gestion de projet

activités d'assurance qualité

    Etablir les bases de la gestion documentaire

 Fournir un inventaire des documents contractuels et autres documents de référence

 Préciser les normes pour la production et le référencement des divers documents.

AQ.2 Dossier de Réception - Journal de Réception

 Le Dossier de Réception est la plaque tournante de l'assurance qualité.

 Le Dossier de Réception est basé sur un tableau synoptique appelé Matrice de traçabilité

  La Matrice de Traçabilité part de l' Inventaire des délivrables déjà réalisé: à chaque point de fonction inventorié, on fait correspondre l'ensemble de ses composants.

Les composants incluent aussi la documentation !

  Chaque élément de la matrice de traçabilité doit être testé. Le Dossier de Réception synthétise le résultat de ces tests.

   Le Dossier de Réception doit permettre d'effectuer un double contrôle avant de mettre un composant en production:

   Un point fonction ne peut être mis en production que lorsque tous ses composants ont été réceptionnés.

  Un composant ne peut être mis en production que lorsque tous les points fonctions qu'ils influent ont été complètement réceptionnés.

Cette deuxième remarque est surtout valable en cas de modification de systèmes existants et opérationnels.

Ceci exige donc de suivre les versions des composants, ainsi que les contraintes existant entre les points fonction et les versions de composants.

Exemple:

Le Point Fonction PF1 (modification du format de date Y2K dans la facturation) a 3 composants: modification de la table 'Factures', modification du programme de facturation, modification du programme d'impression des factures.

Le Point Fonction PF2 (modification du programme de relance Clients) a 3 composants:modification de la table 'Factures', modification du programme d'impression des relances clients, utiliser le nouveau formulaire pré-imprimé.

Le Point Fonction PF3 (conversion de l'historique factures) a 2 composants: modification de la table 'Factures', programme de conversion de l'historique factures.

Il est évident que les 3 Points de Fonction devront être mis en service ensemble, quand tous leurs composants auront été réceptionnés.

Souvent, on pourra donc regrouper les Points de Fonction interdépendants en une 'révision' ou en un 'projet'.

Le dossier de réception permet aussi de procurer un cadre objectif bien défini pour l'évaluation et la gestion des non-conformités: les erreurs sont évaluées suivant leur importance sur le bon fonctionnement du point fonction. La pondération est effectuée de commun accord entre le fournisseur et le client ou l'utilisateur selon des règles prédéfinies dans le Plan de Qualité

 Quand tous ses composants sont réceptionnés, le Dossier de Réceptions acte le résultat final des tests du point de fonction; signatures.

  Le Dossier de réception est complété par un Journal de réception; celui-ci contient un document détaillé pour chaque point à réceptionner, faisant partie de la matrice de traçabilité

 Inventaire des éléments testés pour le composant: écrans de saisie, formules de calcul, rapports en sortie, données en sortie, enchaînement des sous-fonctions, etc.

Les composants sont souvent des programmes. Ici, il faut détailler chaque point de la procédure, afin que tout soit testé en détail.

 Description de la façon dont les tests doivent être ou ont été effectués: référence à un jeu de tests, ou tests sur des données réelles; opérations à effectuer, etc.

 Nom des personnes intervenant dans le test et pour le redressement des non-conformités éventuelles

 Historique des tests: date, résultat, actions à entreprendre, date planning pour le redressement des non-conformités éventuelles

 Résultat final des tests du composant; signatures

 Le document synthétique de réception comporte les informations suivantes:

 Inventaire des points fonction testés, à comparer avec la matrice de traçabilité

 Synthèse des tests des points fonctions: date, résultat, nombre de tests exécutés

 Signature pour l'acceptation globale, avec clauses de réserves éventuelles.

AQ.3 Dossier des Tests de Validation Interne.

Le Dossier des Tests de Validation Interne est similaire au Dossier de Réception .

Il n'est habituellement pas transmis au client ou à l'utilisateur. Les seules personnes responsables de ces tests appartiennent donc à l'équipe de développement.

AQ.4 Dossier des non-conformités

A l'issue de la réception, les non-conformités résiduelles sont inventoriées dans le Dossier des non-conformités.

Il s'agit bien sûr des non-conformités non-bloquantes, pour lesquelles le statut d'erreur permet une acceptation sous réserve.

Le Dossier des non conformités est similaire au Dossier de Réception . Le seul but du dossier des non-conformités est de mettre clairement en évidence ce qui reste à livrer.

AQ.5 Dossier de suivi des modifications

Le Dossier de suivi des modifications est utilisé dans une application en cours d'exploitation.

Il est assez semblable au Dossier de Réception .

On insistera particulièrement sur les liens entre les composants modifiés, toujours critiques dans ce cas. Un bon outil de gestion des versions peut être utile.

On ajoutera les données suivantes:

 nom des demandeurs

 raison de la modification

  le cas échéant, identifier en fonction du demandeur et de la raison s'il s'agit de la correction d'une erreur, d'une réparation sous garantie, et à quel budget le coût de la modification doit être imputé.

 priorité

 évaluation du coût et des ressources nécessaires

 délai / date de mise en service.