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

MIAGE MASTER 1Cours de gestion de projet

Session 9 : Risques – Assurance Qualité

1

MIAGE 1: Cours de gestion de projetSession 9 : Gestion des risques , Assurance Qualité

Sommaire

• La gestion des risques

• Manager par la qualité

2

3

Gestion des risquesGestion des risques


• Les risques ? Quels risques ?

Principes


Principes…

• Deux manière de piloter un projet : – 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.

5


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)• réévaluer les risques• 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.

7


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.

8


Etape 1 : résultat

9


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 :

10


Etape 2 : les facteurs de risque du projet

• Exemple (suite) :

11


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

12


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.

13



• 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



• 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

15


Exemple de fiche de risque (partie 1)

16


Exemple de fiche de risque (partie 2)

17


Exemple 1

18


Exemple 1

19


Exemple 2

20


Exemple 2

21


Exemple 2

22


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

• on va lancer des actions de détection– 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

• on peut agir sur la contingence– 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

1Pas de

conséquenceCoût délai périmètre

inchangé

2Conséquences

limitéesCoût délai périmètre restent dans les hypothèses basses

3Conséquence

sensibleCoût délai périmètre

impactés

4Consé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

26

27

Assurance QualitéPrincipes

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é :

28


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é.

29


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

30


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.

31


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.

32

33

Assurance QualitéEn pratique…

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)

34


Les trois parties du PAQ

35

Définition et respect des procédures AQ

Définition des procédures de pilotage par phase projet

Suivi des critères de qualité du projet

OK

KO

L'Assurance Qualité


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.

36



• 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é

37



• 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.

38


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

39


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

40


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.

41


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

42


Critères de qualité standards

• Exemples de critères qualité :

43

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


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

MAINTENABILITEAssurer 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

44


Exemple 1

• Identification des alertes qualité

45

0

2

4

6

Analyse de la qualité

Respect des délais (pour livrables)

Qualité des livraisons, quantité d'anomalies

Délais de correction (VA)

Démarche pro-active et travail collaboratif (note /20)

Engagements de suivi de projet (respectprocédures de pilotage)

Qualité du transfert de compétences, implicationgroupement (note /20)

Respect du processus de facturation


Exemple 2 : partie analytique

46

N° 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

=> Valeur : 5

Taux de régression fonctionnelle par rapport au nombre d'incidents

Moins de 10% de retour sur incidents

=> Valeur : 3

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

47