MIAGE MASTER 1 Cours de gestion de projet Session 9 : Risques – Assurance Qualité

Sommaire La gestion des risques Manager par la qualité

Gestion des risques

Principes Les risques ? Quels risques ? Faire des fiches de mission

Principes… Deux manière de piloter un projet : En pratique : Par les délais et les livrables : garantie de livrer quelque chose… mais pour quoi faire ? Par les risques : voir le projet dans son ensemble et stratégie gagnant-gagnant avec le client En pratique : tenue de plusieurs indicateurs de risque tout au long du projet, permettant de remonter les contraintes et les alertes au plus tôt pas de rétro-planification, ayant toujours comme conséquence le sacrifice des phases de tests et de qualification La mise en œuvre pratique passe par la définition de fiches de risques et de tableau de suivi des risques.

Principes… Tout projet doit faire l’objet d’évaluations des risques : En avant-vente (par le responsable de la réponse) identifier les risques aider au GO-NOGO élaborer un plan d’action Au démarrage du projet (par le CP) réévaluer les risques mettre à jour le plan d’action En cours de projet (par le CP) mesurer l’avancement du plan d’action et son efficacité

Etape 1 : Profil de risque L’origine des risques pouvant peser sur une situation de projet est variée. Six facteurs jouent cependant un rôle déterminant La taille du projet : grand projet  large étendue du domaine couvert, qui impose une division du travail, donc un nombre important de personnes. Absence d’un dispositif => perte de la maîtrise du processus de production. La difficulté technique : N’est pas la cause principale des échecs de projets, mais facteur de risque important. Les difficultés techniques sont généralement dues à un manque de compétences sur un sujet nouveau ou à des problèmes de performance du système. Le degré d’intégration : Il agit sur la complexité du projet puisqu’il mesure le degré de dépendance ou d’autonomie du futur système. L’intégration peut se voir en interne par rapport au projet développé, mais aussi en externe par rapport à d’autres applications, ce qui multiplie les contraintes et le nombre total d’acteurs du projet global.

Etape 1 : Profil de risque Suite des facteurs : La configuration organisationnelle : correspond à l’ampleur de l’entreprise touchée par le projet. Le risque provient de la lourdeur des procédures de participation et de décision quand plusieurs grandes entités sont parties prenantes du projet. Pb des conflits qui bloquent les prises de décision. Le changement : Les systèmes de gestion et/ou d’organisation peuvent ne pas avoir été clairement compris comme référence stable et que l’effort de conception / innovation va être important. Les risques de rejet ou de mauvaise définition du futur système sont élevés. L’instabilité de l’équipe de projet : Pose le problème du transfert des connaissances. Lors des modifications de l’équipe, la connaissance implicite accumulée est à reconstituer et les erreurs d’interprétation peuvent avoir des conséquences sur les délais et sur la cohérence de conception.

Etape 1 : résultat

Etape 2 : les facteurs de risque du projet Les risques « incompressibles » doivent être regroupés par domaine. Pour chaque risque identifié, une solution doit être envisagée afin d’y faire face. Afin de pouvoir les anticiper, il est indispensable de les recenser Exemple :

Etape 2 : les facteurs de risque du projet Exemple (suite) :

Le niveau de risque d’un indicateur Chaque indicateur de risque fait l’objet d’une double évaluation : Probabilité d’occurrence : 0 : Aucun (non réaliste) 1 : Peu probable (0-20%) 2 (20-40%) ; 3 (40-60%) ; 4 (60-80%) 5 : quasi certain (80-100%) Niveau de gravité (impact) : 0 : aucun impact (pourquoi l’identifier ??) 1 : impact mineur (ne bloque pas l’application) 2 : gênante : bloque une partie des fonctionnalités mais problème contournable 3 : grave : problème grave nécessitant un plan d’action important 4 : bloquant : problème important qui causera des dérapages du projet 5 : critique : peut causer l’arrêt du projet

Etape 3 : les outils de suivi Au démarrage du projet, on crée autant de fiches de risques que de facteurs de risques identifiés ci avant. Dès lors qu'une difficulté sera soulevée lors de la réalisation du projet, une nouvelle fiche de risque sera mise en place jusqu'au règlement du problème. Ces fiches de risques permettront : de mettre "à plat" un problème et de lancer des actions qui permettront de le résoudre. Le cas échéant, une petite étude peut proposer des solutions et argumenter le bien-fondé de la solution retenue d'historiser l'avancement dans la résolution du problème en spécifiant des réunions d'avancement planifiées et un responsable de l'aboutissement de l'étude. Le but est d'arriver à terme à une résolution satisfaisante pour toutes les parties.

Etape 3 : les outils de suivi Les actions à mettre en œuvre portent sur les facteurs de risque pour en réduire la probabilité de survenue Action de « réduction » des causes pour en réduire l’impact en cas de survenue Action de « contingence » des conséquences pour en accroître la détectabilité Action de « détection » de la survenue du risque Pour chaque action il faut estimer un coût de mise en œuvre (en équivalent j.h) pour comparer les coûts d’impact du risque avec les montants à engager pour réduire ce risque

Etape 3 : les outils de suivi A chaque comité de pilotage ou comité de suivi, on effectue un état des lieux des fiches de risque encore ouvertes. Cette démarche est importante, car elle permet de faire participer tous les acteurs du projet aux tâches sensibles de celui-ci, et ainsi évoluer vers une résolution qui sera satisfaisante à la fois du point de vue technique, fonctionnel et organisationnel. Le coût et le temps pris pour la tenue d'un tel dossier de risque sont sans commune mesure avec ceux d'un risque non maîtrisé. Les fiches, pour être efficaces, doivent tenir sur un format A4, en ayant recours à des pièces jointes. En annexes de chaque fiche, on donne, à chaque révision, le nouvel état de gravité du problème, l'état des travaux et les plans d'action à mettre en œuvre. Ces fiches sont résumées dans un tableau de bord de suivi des risques

Exemple de fiche de risque (partie 1)

Exemple de fiche de risque (partie 2)

Exemple 1

Exemple 1

Exemple 2

Exemple 2

Exemple 2

Exemple Exemple : Le risque d’inondation d’une île de l’océan indien Facteur : Tsunami on ne peut pas agir sur la probabilité qui est faible mais pas nulle on va lancer des actions de contingence qui vont être limitées car phénomène rapide information population sur conduite à tenir on va lancer des actions de détection réseau de surveillance sismique information population sur l’observation de phénomène anormaux Facteur : Elévation du niveau des océans on peut agir sur la probabilité : réduction des causes de la fonte des calottes glaciaires on peut agir sur la contingence car phénomène lent construction de digues déplacement des populations menacées réseau de mesure du niveau des océans et analyse statistique mise en place locale de point de mesure

Exemple Exemple : Le risque d’avalanche dans une station de ski Facteur : météo on ne peut pas agir sur la réduction on peut agir sur la contingence mur anti avalanche plan d’évacuation en cas de danger déclenchements préventifs on doit agir sur la détectabilité analyse régulière des couches de neiges Facteur : les skieurs hors piste on peut agir sur la réduction information sur le danger mesures d’interdiction idem facteur météo on ne traite pas de la sécurité des skieurs hors piste. C’est un autre risque

ESCALADE L’escalade consiste à informer voire impliquer des niveaux hiérarchiques de plus en plus élevés en fonction de l’impact des risques identifiés ou des constats sur le projet. par devoir d’information pour la prise de décision allant au-delà des habilitations du Chef de projet Escalade en fonction de l’impact d’un facteur de risque ou d’une situation plus les impacts sont importants plus la hiérarchie doit être impliquée car : les budgets peuvent être important des décisions ne sont plus du ressort d’un CP Niveau Impact Commentaire 1 Pas de conséquence Coût délai périmètre inchangé 2 Conséquences limitées Coût délai périmètre restent dans les hypothèses basses 3 Conséquence sensible Coût délai périmètre impactés 4 Conséquence critique Arrêt du projet, impact au-delà du projet et/ou perte du client Escalade Pas d’escalade Escalade DP ou Directeur d’unité Escalade Directeur d’unité Escalade DIG-DQG-Juridique Communication Pas de communication Au moins un indicateur de risque à orange dans le reporting projet Projet sensible (rouge) dans le reporting projet Projet sensible au comité des risques

Bilan Efficacité de la méthode ? Pour être efficace, il faut qu’elle soit globale (prestataire + client) : attention aux tabous… Si nécessité d’efficacité des intervenants clients Si identification de tensions client entre services ou entre personnes  Orienter la description des risques et les moyens de contournement de manière consensuelle Associer à la conduite du changement Doit servir de levier pour communiquer efficacement et faire prendre conscience des problèmes potentiels  Support au rôle de conseil

Assurance Qualité Principes

Evolution des approches de qualité Les enjeux de la qualité s’articulent autour des thèmes que sont la compétitivité, l’amélioration des ressources humaines et l’évolution culturelle. La qualité est devenue le centre stratégique de chaque entreprise. Evolution des approches de la qualité :

Qualité : démarche Qualité par l’inspection : coût élevé, ne permet pas de diminuer sensiblement les défaillances. Qualité par le contrôle des processus (lancée par DEMING & JURAN) contribue à anticiper les défauts. Cette appréhension de la qualité fut une première étape d’amélioration transversale des projets complexes. Par la suite fut introduit la criticité du défaut (indice de sévérité, probabilité d’occurrence, probabilité de détection  prémisses de l’anticipation des risques  amélioration de la qualité. Les systèmes ISO de management de la qualité : formalisent le système de référencement de la qualité et proposent une attention toute particulière sur l’organisation. L’objectif est de satisfaire le client en s’appuyant sur un management cohérent, gage d’une entreprise de qualité et donc d’une prestation de qualité.

Management par la qualité : les 10 process principaux Stratégie : objectifs et intégration du projet dans le fonctionnement de l’entreprise Coordination : processus d’intégration qui concernent chaque phase du projet (développement, réalisation, modifications, clôture) Périmètre du projet : assurer le résultat correspondant aux attentes des parties prenantes (spécifications, définition des tâches, maîtrise des activités). Management des délais : enclenchement des tâches, estimation des durées, ordonnancement des tâches et maîtrise du planning Management des ressources et des coûts : planification des ressources, estimation des coûts élémentaires, établissement du budget, maîtrise des coûts. Management de la qualité : planification, assurance de la qualité et maîtrise. Ressources humaines : organiser le projet en explicitant les responsabilités avec une maturation progressive de l’équipe projet Communication : rédaction, collecte, diffusion, traitement et archivage des informations nécessaires aux acteurs du projet Management des risques de projet : à chaque phase, effectuer une identification, quantification, prise en compte, documentation et maîtrise des réponses aux risques

Qualité et informatique Enjeux de la qualité informatique L’informatique devenant un outil de différenciation compétitive, la qualité des applications représente à la fois un enjeu commercial et économique. L’utilisation de méthodes et outils industriels permet de garantir la qualité des applications et de réduire les coûts liés à des opérations à faible valeur ajoutée. Qualité des applications La croissance des applications informatiques orientées client (Web, front-office automatisés,…) fait apparaître de nouveaux critères de qualité, comme la disponibilité du service, la rapidité de consultation, la sécurité des données, la simplicité d’utilisation, la rapidité d’exécution.

Qualité et informatique Qualité du processus de fabrication Les applications en prise directe avec le client - Web, front office - doivent pouvoir être adaptées très rapidement à l’évolution des demandes des clients. Qualité du processus de recette La recette doit être organisée de façon à vérifier le respect des exigences du client. La qualité du processus de recette (dite aussi qualification) conditionne celle des produits informatiques livrés. Nécessité d’industrialiser la phase de recette : absence de méthodes et d’outils  tests à exécuter et à analyser manuellement  risque de ne pas détecter des erreurs est élevé  coût pour le client. Le coût et le délai de la phase de recette représentent des problèmes cruciaux, d’autant que ces phases sont souvent « sacrifiées » pour garantir la fin du projet.

Assurance Qualité En pratique…

Comment mettre en place l’Assurance Qualité L’Assurance Qualité vient en complément d’une démarche de pilotage classique En plus des outils de suivi de projet classiques (tableau de bord d’avancement, suivi des livrables, gestion des comités projets, …), l’Assurance Qualité est basée sur : Un Plan d’Assurance Qualité : documentation des procédures à mettre en place dans le projet : souvent réalisé, peu contraignant Eventuellement, une liste d’objectifs qualité mesurables (SLA): plus contraignant, mais peu d’impact s’ils ne sont pas régulièrement évalués Eventuellement, la conduite d’audits qualité : permettent un suivi fin des objectifs, mais rarement déclenché (temps passé à l’audit est payé par le client)

Les trois parties du PAQ

Le Plan d’Assurance Qualité 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). Buts : homogénéiser et d'assurer une cohérence dans les pratiques des projets améliorer la qualité des produits optimiser les méthodes de travail de capitaliser et partager les expériences.  Pour être efficace, l’Assurance Qualité du projet doit être en accord avec les principes d’Assurance Qualité du client.

Le Plan d’Assurance Qualité Les deux niveaux de l’Assurance Qualité : 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 ; (document nommé PAQ client ou Manuel d’Assurance Qualité) 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 Qualité Projet (PQP) par projet.  C’est un document contractuel dans la relation client - prestataire En pratique, et par abus de langage, on réalise un PAQ par projet, et peu de clients disposent de leurs normes internes d’Assurance Qualité

Le Plan d’Assurance Qualité Principes d’élaboration Le PAQ s'élabore lors de l’initialisation du projet. 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 PAQ. Il doit rester un document synthétique. Après validation par le chef de projet et le responsable qualité de la DSI, le PAQ peut être diffusé à toutes les parties prenantes (Maîtrise d'ouvrage, Maîtrise d'œuvre, équipes projets…) pour application. Le PAQ 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.

Exemple de PAQ Source : CNRS : http://www.dsi.cnrs.fr/conduite-projet/phasedeveloppement/qualite/pacq/basdevqual.htm 1. OBJET ET CARACTERISTIQUES DU PLAN D'ASSURANCE ET CONTROLE QUALITE 1.1 OBJECTIFS DU PLAN Définir les objectifs du document 1.2 DOMAINE D'APPLICATION Projet, Système d’information, marché, domaine métier, … 1.3 RESPONSABILITES DE REALISATION ET DE SUIVI DU PLAN Qui crée le PAQ, qui le met à jour, qui contrôle 1.4 DOCUMENTS APPLICABLES ET DOCUMENTS DE REFERENCE 1.4.1 Documents applicables : Documents contractuels 1.4.2 Documents de référence : Guides méthodologiques, manuels de développement, plans de nommage, … 1.5 CRITERES ET PROCEDURE D'EVOLUTION DU PACQ Ce qui justifie une évolution du PAQ, comment appliquer une évolution de PAQ 1.6 PROCEDURE DE DEROGATION AU PACQ Peut on déroger au PAQ ? Si oui, faut il mettre à jour ? Qui valide la dérogation ? 2. TERMINOLOGIE 2.1 GLOSSAIRE DES TERMES Termes métier 2.2 ABREVIATIONS Abréviations et acronymes

Exemple de PAQ 3. SYSTEME QUALITE MIS EN ŒUVRE POUR LE PROJET 3.1 OBJECTIFS ET ENGAGEMENTS QUALITE DU PROJET Objectifs propres au projet, établis par le client 3.2 MESURE DE LA QUALITE (PROPRIETES ET METRIQUES) Liste des critères qualité, échelle de valeur, niveau à atteindre (voir suite) 3.3 DOCUMENTATION QUALITE DU PROJET Types de documents gérés au titre de l’Assurance Qualité : PAQ, Procédures, Guides méthodologiques, Plans types 3.4 ACTIVITES D'ASSURANCE ET DE CONTROLE DE LA QUALITE 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. Exemples : 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 A LA QUALITE DU PROJET Destinataires de chaque type de document

Exemple de PAQ 4. CONDUITE DE PROJET 4.1 ORGANISATION DU PROJET Organigramme des missions assurées au sein du projet (liens hiérarchiques et fonctionnels) Description des rôles et responsabilités : chef de projet, adjoint, responsable d'équipe, ... 4.2 PRESENTATION DES ACTIVITES COUVERTES PAR LE PROJET Organigramme des différentes activités qui sont nécessaires au projet (ex : PBS) 4.3 PLANIFICATION ET SUIVI DU PROJET Définit l’interlocuteur privilégié du client ainsi que les comités projet nécessaires (pilotage, suivi, groupes de travail), … 5. DEMARCHE DE DEVELOPPEMENT DU SYSTEME D'INFORMATION 5.1 CYCLE DE DEVELOPPEMENT Méthode appliquée : V, W, RAD, Agile, … 5.2 DESCRIPTION DES ETAPES En fonction de la méthode : définition des étapes ou des itérations 6. GESTION DE LA DOCUMENTATION 6.2 IDENTIFICATION DE LA DOCUMENTATION Normalisation du codage des documents Principe de versionning majeur/mineur 6.3 SAUVEGARDE ET ARCHIVAGE Structure des dossiers de sauvegarde, droit d'accès, périodicité, procédure d'archivage.

Exemple de PAQ 7. GESTION DE LA CONFIGURATION LOGICIELLE 7.1 RESPONSABILITES Qui est responsable de la GCL ? Lien avec les développeurs ? Synchro client ? 7.2 IDENTIFICATION DES ELEMENTS 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. 7.3 CYCLE DE VIE ET ETATS DES ELEMENTS méthodes de gestion des versions, révisions, modalités de vérification et de validation. 7.4 SAUVEGARDE ET ARCHIVAGE Procédure de sauvegarde et de restauration 8. GESTION DES MODIFICATIONS Identifier ce qui relève du correctif (inclus dans la prestation) de l’évolutif (bons de commande supplémentaires) Evolutif : fonctionnel, adaptatif, performances Délais de prise en compte des modifications, notamment correctives : selon le niveau de gravité 9. CONTROLE DES FOURNISSEURS 9.1 DOCUMENTS DE LIAISON Liste des documents : Compte Rendu de Comité, Fiche de liaison, Demande d'intervention, Procès verbal de réception, PV de recette. Identification des procédures associées (déclenchement, tâche associée, émetteur, destinataires, engagements, …) 9.2 DESCRIPTION DES DOCUMENTS Modèles de ces documents

Critères de qualité standards Exemples de critères qualité : 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. 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é

Exemples de métriques associées aux critères 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

Exemple 1 Identification des alertes qualité

Exemple 2 : partie analytique Désignation Elément de mesure Valeur QU01 Respect des délais concernant les livrables Ecart entre la date de remise d'un livrable et la date prévue. NB : une date de livraison d'un livrable rejeté par la FMP n'est pas prise en compte Pas de livrable majeur livré => Valeur : 3 QU02 Assurer la conduite du changement en interne Note donnée par l'équipe informatique pour l'évaluation de la qualité du travail collaboratif avec le groupement 15 Note concernant la conduite du changement : degré de satisfaction et sentiment d’autonomie des intervenants FMP 17 => Valeur : 4,5 QU03 Assurer la conduite du changement en externe Note demandée au groupe de travail utilisateur 16+16 => Valeur : 5 QU04 Continuité de l’ergonomie, non régression fonctionnelle Automatismes gardés pour l’utilisateur (touches fonction, gestion des erreurs, …) : taux d’incidents relatifs au non respect des automatismes Pas de problèmes d’ergonomie Taux de régression fonctionnelle par rapport au nombre d'incidents Moins de 10% de retour sur incidents QU05 Qualité des livrables et respect des procédures (PAQ) Evaluation de la qualité des livrables : taux de remarques bloquantes ou graves émises par la FMP sur les livrables majeurs Livrables acceptés, avec peu de remarques => Valeur : 4 Respect des délais concernant les procédures de pilotage 2 jours de retard => Valeur : 2

Exemple 2 : partie graphique Vue instantanée : permet le positionnement par rapport aux objectifs mini/maxi Vue historisée