Gérer la Qualité MASTER IPI.NT le 04/11/2015 Laurent DESCAMPS.

Présentation au sujet: "Gérer la Qualité MASTER IPI.NT le 04/11/2015 Laurent DESCAMPS."— Transcription de la présentation:

1 Gérer la Qualité MASTER IPI.NT le 04/11/2015 Laurent DESCAMPS

2 Gérer la Qualité Sans qualité, on aboutit à :
En 1962, la sonde Mariner 1 à destination de la planète Vénus est détruite. Cela était du à une erreur de transcription dans les spécifications du programme de guidage. Le rédacteur a oublié la barre suscrite dans la formule   qui signifie « la n-ième valeur lissée de la dérivée de R dans le temps ». Sans le lissage spécifié par cette barre, le programme réagissait aux variations mineures de vélocité comme aux écarts importants. Les corrections erronées induites menèrent la fusée hors trajectoire, ce qui obligea l'officier de sécurité à commander sa destruction : perte de 135 millions de dollars Lors d’un vol d’essai, au passage de l’équateur un F16 s’est retrouvé automatiquement sur le dos à cause d’un changement de signe de la latitude mal pris en compte En 1997, 2 jours sans courant sur la station MIR : plantage de l’ordinateur qui contrôlait l’orientation des panneaux solaires … sans système de secours

3 Gérer la Qualité Ou encore à :
En 1996, le 1er lancement d’Ariane 5 qui a explosé au décollage : le logiciel gérant la plate forme inertielle a été repris tel quel d’Ariane 4 sans nouvelle validation. Ariane 5 ayant des moteurs plus puissants, elle s’incline plus rapidement qu’Ariane 4 afin de récupérer l’accélération due à la rotation de la Terre. Les capteurs ont bien détecté cette inclinaison mais le logiciel l’a jugé non conforme au plan de tir (d’Ariane 4) et a provoqué l’ordre d’auto destruction. En fait tout se passait bien ! Une perte estimée à 2,5 milliards de francs pour les satellites perdus et un surcout de 1,5 milliards de francs pour les modifications et vérifications indues Le 26 septembre 1983, la 3ème guerre mondiale est évitée de peu. Un satellite russe rencontre un alignement rare de la Terre avec le Soleil, dont la signature infrarouge est interprétée comme un lancement de missiles nucléaires ennemis provenant des États-Unis. Cinq missiles étaient détectés à tort (on l’ignorait à ce moment là). Le lieutenant colonel Stanislav Petrov a réalisé à temps qu'il s'agissait d'une erreur, évitant une catastrophe mondiale. Il a jugé que si les Etats Unis étaient réellement en train d’attaquer, ils ne lanceraient pas cinq missiles mais bien davantage. Les satellites géostationnaires infirmèrent l’information d’une attaque nucléaire et la catastrophe fut évitée de justesse. Après vérification ultérieure on constata que le système de filtrage des images avait été induit en erreur (toutes les situations possibles conduisant à une même image n’ont pas été prises en compte).

4 Gérer la Qualité Ou encore à :
Perte de la sonde ‘Mars Climate Orbiter’ en 1999 après 9 mois de voyage. L'enquête a mis en évidence que certains paramètres avaient été calculés en unités de mesure anglo-saxonnes (en pieds) et transmises telles quelles à l'équipe de navigation, qui attendait ces données en unités du système métrique (en mètres). En définitif : 125 millions de dollars de pertes. Aucune couverture réseau chez Bouygues Telecom le 17 novembre 2004 : les 7 millions d’abonnés ne pouvaient ni passer, ni recevoir d’appels car deux serveurs d’acheminement des appels sont tombés en panne en même temps : l’un était censé être le secours de l’autre ! Perte estimée de 20 millions d’euros. Le 22 décembre 2001, plus de terminaux de paiement (tous commerçants confondus) ne répondaient plus. Les serveurs de la société ATOS étaient saturés et n’avaient pu répondre à un pic de sollicitations. Les demandes d’autorisation mettaient 1/2 heure au lieu de 10 secondes. Dans les grandes surfaces la plupart des clients ont abandonné leurs chariots pleins : des pertes conséquentes pour la grande distribution (non estimées)

5 Gérer la Qualité Ou encore à :
En 1985, le Therac 25, machine de soins à base de radiations, fut à l’origine de plusieurs décès. Le Therac 25 disposait d’un logiciel qui simplifiait les réglages en les automatisant. Il gérait également la sécurité des patients qui ne devaient pas être exposés trop longtemps. Mis en services en 1983, les Therac 25 furent interdits d’utilisation en 1987, le temps ensuite d’introduire des sécurités logicielles conformes aux règlements. Ces sécurités existaient sur les générations précédentes mais elles étaient matérielles. Le modèle 25 réutilisait des routines des modèles précédents dont certaines contenaient des bugs, jusque là invisibles du fait de la redondance des sécurités couplant le matériel au logiciel. Cet appareil causa de nombreux décès, sans parler des irradiations graves mais non fatales. Le logiciel de paie de l’armée (le projet « Louvois ») a été une catastrophe. Enormément de militaires ont eu des retards de paiement et ont même du prendre des crédits à la consommation pour faire vivre leurs familles ou payer les frais de leurs affectations à l’inverse d’autres ont bénéficié de trop-perçus très importants impliquant des remboursements mais aussi le paiement d’impôts qui n’étaient pas dus ! Ce logiciel de paie a été abandonné en 2013 et avait couté 470 millions d’euros.

6 Gérer la Qualité Ou encore à :
Le projet Socrate de la SNCF de 1993 à 2003 (outil de réservation de billet) a été une modernisation ratée. Une mise en production d’un produit conçu pour les compagnies aériennes et mal adapté à la SNCF. Cela a généré de nombreuses grèves parmi le personnel utilisant et de nombreuses insatisfactions et plaintes de clients : La SNCF a inversé en cours de réalisation les priorités du projet l'alimentation du système à partir des « données voyageurs » ont été gravement sous-estimés ; par exemple, le nombre de relations par correspondance introduites dans Socrate n'était que de 4 000, alors qu'il en aurait fallu au moins dix fois plus De nouveaux principes de tarification ont nécessité une modification en catastrophe du cahier des charges de la SNCF La sensibilité de la clientèle aux prix du transport a été mal appréciée La formation du personnel de vente à l'exploitation du système Socrate a beaucoup laissé à désirer Le dialogue de la SNCF avec les associations d'usagers est resté trop strictement formel, et la communication vers le grand public a été défaillante  cout final de 2,1 milliards de francs (plus du double que ce qui était prévu) Exemples Cofidis : Migration Oracle en 2004 et les tests de montée en charge  1 semaine d’inactivité Changement du cœur de gestion en 2006 et le plan de retour arrière  6 mois de SAV

7 Gérer la Qualité Plus généralement : Le constat :
L’absence de démarche qualité dans un projet informatique sanctionne systématiquement ce dernier de retard, de surcoût voire d’échec pur et simple Devoir corriger un élément logiciel sensé être terminé peut augmenter considérablement la charge de réalisation (parfois plus de 100%) Le constat : L’adoption d’une démarche qualité et la mise en place d’un plan d’assurance qualité sont systématiquement avantageuses et doivent donc devenir obligatoire La principale difficulté consiste à donner une réalité à cette démarche et à réussir à en faire une préoccupation banale et naturelle pour chaque intervenant

8 Gérer la Qualité Définitions de la qualité : Conformité à l’exigence négociée avec le client Aptitude d'un produit ou d'un service à satisfaire, au moindre coût et dans les moindres délais, les besoins des utilisateurs (explicites et implicites) Attention à ne pas confondre qualité et fiabilité : la fiabilité est l'aptitude d'un produit, d'un service à maintenir son niveau de qualité dans le temps

9 Gérer la Qualité La démarche qualité consiste à instaurer un ensemble de procédures qui permettront d'établir et de vérifier son aptitude à fournir des produits satisfaisants pour ses clients L’objectif est donc d’identifier les processus mis en oeuvre, leurs inputs et leurs produits, ainsi que les interactions entre eux. Cette analyse en processus permet de modéliser le fonctionnement de l'entreprise, et ainsi de décrire les flux d'information et de matières qui la parcourent, et en fin de compte ce que chaque acteur d'un processus doit recevoir pour effectuer sa mission, et ce qu'il doit livrer au processus suivant à l'issue de celle-ci, Pour que le résultat soit à la mesure de l'attente, il faut encore que la méthode soit appliquée avec suffisamment de réalisme et de sobriété pour ne pas introduire plus de désordre qu'elle n'est censée en supprimer

10 Gérer la Qualité Pour atteindre la qualité, il faut un processus qualité Déterminer pour chacune des données de sortie (les livrables de mon projet), les composantes du processus qui, par leur défaillance ou leur absence, pourraient empêcher le processus de générer cette donnée Exemples : des tests de non régression, une expertise technique, un outil de qualification, des indicateurs de performance … Besoins utilisateurs Moyens Acteurs Méthodes Objectifs Processus Fournisseurs (faisabilité, cahiers des charges, normes, méthodes …) Processus Clients (exploitation des livrables) Processus Données De sortie Données d’entrée Livrables du projet

11 Gérer la Qualité Il faut, pour maitriser ce processus :
Toujours formaliser les exigences des clients Identifier et afficher le ou les objectifs à atteindre Décrire le processus (cad décrire l’activité ou l’ensemble d'activités qui utilise des ressources pour convertir des éléments d'entrée en éléments de sortie possédant une valeur ajoutée) Définir les rôles, missions et objectifs de chacun Mesurer et contrôler les actions de chacun En résumé : 1 - Ecrivez ce que vous voulez faire 2 - Faites ce qui est écrit 3 - Prouvez que vous le faites 4 - Eprouvez ce vous avez fait

12 Gérer la Qualité Le PDCA : appelé également la roue de Deming
La méthode comporte 4 étapes, chacune entraînant l'autre, et visant à établir un cercle vertueux Sa mise en place doit permettre d'améliorer sans cesse la qualité : Plan : définir ce que l’on va faire, Do : le faire, Check : contrôler, mesurer ce qu’on fait, Act : normaliser pour améliorer ce qu’on fait,

13 Gérer la Qualité

14 Gérer la Qualité La méthode PEC : Je Planifie : les délais, les ressources, les moyens, les coûts J’ Exécute : je réalise conformément aux exigences négociées et formalisées Je Contrôle : je teste, je simule, je réalise un pilote et je vérifie C’est également un cycle itératif, tendant à améliorer continuellement la qualité

15 Gérer la Qualité La qualité doit être avant tout la résultante d’actions préventives et non pas d’actions correctives. Pour que le résultat soit à la mesure de l'attente, il faut encore que la méthode soit appliquée avec suffisamment de réalisme et de sobriété pour ne pas introduire plus de désordre qu'elle n'est censée en supprimer.

16 Gérer la Qualité Dans un projet informatique, on peut identifier trois thématiques principales de mesure de la qualité : Qualité technique : les normes, les méthodes, les compétences … Qualité relationnelle : les circuits de communication, la circulation de l’information … Qualité organisationnelle : les procédures, les rôles et missions …

17 La qualité technique Composer l’équipe en fonction des compétences techniques et/ou fonctionnelles requises Eviter les rôles de composition, les formations sur le tas … ou prévoyez alors des tâches et des charges pour y remédier !

18 La qualité technique La qualité technique s’appuie essentiellement sur : des normes et des méthodes Pour le développement (conception, architecture, cycle de développement, méthodologie, ergonomie …) Pour l’archivage, la gestion des sauvegardes … des moyens de contrôle : niveau et fréquence de contrôle : par des revues de code, du développement en binôme, du prototypage … niveau et fréquence de validation : conception de jeux et plans de tests qu’ils soient unitaires, d’assemblage ou utilisateurs

19 La qualité technique 2 méthodes peuvent nous servir à construire notre démarche « qualité » La méthode Mc Call Le modèle de Mc Call est né en 1977 au cours d'une étude pour l'US AIR FORCE Mc Call détermine une approche de la qualité à partir de la définition de caractéristiques externes au projet (appelés facteurs de qualité) et internes au projet ( appelés critères de qualité) qui soient mesurables (par des métriques). Il a donc défini 23 critères répartis sur 11 facteurs  chaque critère correspond à au moins une métrique Le modèle de Mc Call différencie utilisateur et réalisateur (chacun a ses critères de qualité) La norme ISO 9126 La norme ISO 9126, "Technologies de l’Information : Qualités des produits logiciels", définit et décrit : une série de caractéristiques qualité d’un produit logiciel (caractéristiques internes et externes, caractéristiques à l’utilisation) qui peuvent être utilisées pour spécifier les exigences fonctionnelles et non fonctionnelles des clients et des utilisateurs chaque caractéristique est détaillée en sous-caractéristique, et pour chacune d’elle, la norme propose une série de mesures à mettre en place pour évaluer la conformité du produit développé par rapport aux exigences formulées.

20 La qualité technique la méthode Mc CALL Les 11 facteurs de qualité peuvent être classés en 3 catégories LES CARACTERISTIQUES OPERATIONNELLES conformité aux besoins : le produit fait-il ce que je souhaite? fiabilité : le fait-il correctement dans tous les cas? efficacité : utilise-t-il au mieux le matériel, le réseau, la BDD ? intégrité : est-il protégé contre les intrusions ? a-t-il un niveau de sécurité suffisant? facilité d’emploi : au niveau de l’apprentissage, de la mise en œuvre, de la préparation des données, de l’interprétation des résultats LA CAPACITE D'EVOLUTION - maintenabilité : facilité avec laquelle on peut localiser et corriger les erreurs - souplesse : facilité de modification et d’évolution (adaptation à de nouveaux besoins) - testabilité : effort requis pour le tester L'ADAPTABILITE portabilité : peut-on utiliser le logiciel sur une autre machine? réutilisabilité : peut-on réutiliser des parties du logiciel dans d’autres applications, interopérabilité : facilité d’interfaçage avec un autre système (“ouverture”). Les facteurs de qualité peuvent avoir une influence les uns sur les autres  par exemple les facteurs suivants diminuent l’efficacité: - l’intégrité (nécessité d’introduire des vérifications) - la facilité d’emploi (nécessité d’introduire des interfaces sophistiquées) - la maintenabilité (sacrifie l’efficacité pour la lisibilité) - la portabilité (les structures portables ne sont pas nécessairement les plus efficaces) - la testabilité, la souplesse, la réutilisabilité, l’interopérabilité

21 La qualité technique la méthode Mc CALL
Mac Call définit donc 23 critères perceptibles par l’informaticien qui permettent d’évaluer dans quelle mesure les 11 facteurs de qualité perceptibles par le client sont atteints  Cf. schéma sur diapo suivante Sur ce schéma sont indiqués les liaisons qui existent entre les 11 facteurs de qualité (colonne de droite) et les 23 critères associés à ces facteurs (colonne de gauche) On notera à quel point le critère de modularité est important

22 Facteurs Critères

23 La qualité technique La norme ISO 9126
La CAPACITE FONCTIONNELLE : Ensemble d'attributs portant sur l'existence d'un ensemble de fonctions et leurs propriétés données. Les fonctions sont celles qui satisfont aux besoins exprimés ou implicites La FIABILITE : Ensemble d'attributs portant sur l'aptitude du logiciel à maintenir son niveau de service dans des conditions précises et pendant une période déterminée La FACILITE D’UTILISATION : Ensemble d'attributs portant sur l'effort nécessaire pour l'utilisation et sur l'évaluation individuelle de cette utilisation par les utilisateurs Le RENDEMENT : Ensemble d'attributs portant sur le rapport existant entre le niveau de service d'un logiciel et la quantité de ressources utilisées, dans des conditions déterminées La MAINTENABILITE : Ensemble d'attributs portant sur l'effort nécessaire pour faire des modifications données La PORTABILITE : Ensemble d'attributs portant sur l'aptitude de logiciel à être transféré d'un environnement à l'autre

24 La qualité technique La norme ISO 9126
L’ISO a défini dans sa norme 9126 un modèle liant les qualités internes d’un logiciel à ses qualités externes, ainsi qu’un ensemble de mesures les capturant Ce modèle indique un lien de causalité entre des caractéristiques internes et des caractéristiques externes d’un produit, mais ne permet toutefois pas de les prédire, ni de connaître « bonnes » et « mauvaises » plages de valeurs

25

26 La qualité sur votre projet
Quels peuvent être les critères et facteurs de qualité de votre projet ?

27 La qualité relationnelle
Le chef de projet est le point nodal du projet. C’est à lui de gérer et d’administrer la communication autour de son projet. C’est par la communication qu’il fait vivre son projet et qu’il peut le promouvoir. La qualité relationnelle porte essentiellement sur : la communication au sein des équipes contributrices la communication auprès du client et des utilisateurs la communication à l’extérieur du projet (direction, partenaires, collègues …) La communication doit toujours se faire à bon escient

28 La qualité relationnelle
La communication doit être à 360 degrés : chacun doit savoir ce que l’autre fait Patron (rendre compte) Communiquer Collègues (partager les problèmes / les solutions) Clients (répondre à ses besoins, lui expliquer les problèmes) Collaborateurs (donner du sens, partager les objectifs, les critères de qualités attendus …)

29 La qualité organisationnelle
La qualité organisationnelle est assurée par la mise en place d’un Plan d’Assurance Qualité Ce plan permet de cadrer les projets dans l’environnement concerné (normes, standards, méthodes, etc ... )

30 La qualité organisationnelle
Avant d’aborder le projet en tant que tel, le client et le prestataire élaborent un Plan d ’Assurance Qualité qui a pour but de définir les modalités permettant de travailler ensemble et donc d’assurer le bon déroulement et la réussite du projet En effet, la réussite d'un projet s'apprécie généralement par : la conformité de ses résultats à ceux attendus le respect des délais et du budget le respect des responsabilités de chacun Un Plan d’Assurance Qualité est relatif aux différents projets d’un client. Il est réalisé pour l’élaboration des produits désirés par un client. Il présente les activités propres à assurer les objectifs qualité requis par un client.

31 La qualité organisationnelle
Il existe habituellement 3 niveaux de «plan qualité» Le manuel d’assurance qualité (niveau le plus haut ) décrivant les principes de qualité généraux au sein d’une société Le plan d’assurance qualité (niveau intermédiaire) : régit les principes de qualité entre un client et un fournisseur Le plan qualité projet (niveau le plus bas) : régit les principes de qualité relatif aux spécificités d’un projet

32 La qualité organisationnelle
Les objectifs d’un PAQ : 1 - Donner à la maîtrise d’ouvrage l'assurance de la qualité de l'élaboration des produits 2 - Fixer les droits de la maîtrise d’ouvrage, mais aussi ses devoirs, en matière de suivi de la qualité 3 - Donner à tous les participants du projet les procédures, règles et méthodes applicables 4 - Donner au responsable de la qualité les éléments lui permettant d'organiser son plan d'actions de prévention, de communication et de contrôle

33 La qualité organisationnelle
A - Présentation générale du projet Ce document commence par une présentation générale du projet qui rappelle le contexte du marché et les éléments importants du contrat en particulier les droits et les obligations du prestataire et du client Ensuite, il décrit l’objet et le but des différents chantiers Il présente les différents environnements et les différentes plateformes de travail (les serveurs, les systèmes d’exploitations…)

34 La qualité organisationnelle
B - Plan d’organisation du projet Le PAQ présente les différentes responsabilités et les différents acteurs du projet Il définit la mission et la contribution de chacun des acteurs dans le projet (les responsabilités principales de la maîtrise d’ouvrage et de la maîtrise d’œuvre)  cette répartition des responsabilités peut être résumée éventuellement par un organigramme Ensuite, le PAQ aborde l’aspect organisationnel du projet en définissant l’organisation du projet client et l’organisation du projet prestataire Il s’agit dans ce paragraphe de définir les tâches qui doivent être assurée par chaque intervenant. L’habitude veut que le client se charge des tests et des validations tandis que le prestataire s’occupe des études et de la réalisation.

35 La qualité organisationnelle
B - Plan d’organisation du projet Le PAQ s’intéresse ensuite au management du projet, il définit les différentes structures de suivi du projet (il s’agit d’habitude du groupe projet et du comité de pilotage) Le comité de pilotage a pour mission de traiter les aspects majeurs ou contractuels du projet, il suit l’avancement général du projet et prend les décisions sur les points qui lui sont soumis par le groupe projet Le groupe projet assure la coordination opérationnelle du projet. Il s’assure des points suivants : · planification détaillée de la phase en cours, · affectation des tâches aux différents acteurs, · vérification de la bonne tenue des échéances, · traitement de toute difficulté rencontrée par une des parties (disponibilité de ressources humaines ou matérielle, évolutions ou incidents de toute nature) · coordination des taches de la maîtrise d’œuvre, Le PAQ définit aussi la composition et le fonctionnement de ces 2 entités (fréquence des réunions, méthode de travail de travail…)

36 La qualité organisationnelle
C - Plan de conduite du projet Dans cette partie, le PAQ explique les méthodes utilisées et les outils de conception, de réalisation, de suivi et de pilotage. Elle définit aussi les différents environnements de travail et leur rôle dans l’évolution du projet. D’habitude dans les grands projets informatiques, on met en place à minima trois environnements : l’environnement de développement : permet de développer / de coder les fonctionnalités attendues l’environnement de recette ou de test : permet de tester et de valider les développements l’environnement de production ou d’exploitation : c’est l’environnement réel d’exploitation des fonctionnalités développées Dans ce plan, on aborde aussi la démarche et le plan de réalisation du projet. Ce qui se traduit par la description des différentes phases du projet : lancement du projet conception détaillée réalisation test validation formation

37 La qualité organisationnelle
D - Plan de gestion du projet Ce plan explique le processus de gestion du projet qui met en œuvre les processus de : gestion des livraisons gestion des questionnements gestion des anomalies gestion des modifications gestion des risques gestion des incidents gestion des plans d’action gestion des options à lever gestion des sauvegardes …

38 La qualité organisationnelle
E - Plan d’obtention de la qualité Cette partie du PAQ définit les dispositions d'assurance qualité mises en œuvre dans le projet, afin d'obtenir et assurer la qualité des livrables, c'est-à-dire les moyens de contrôler la conformité aux attentes du client On y décrit les dispositions générales qui permettent la maîtrise de la conception et la maîtrise de la réalisation, les gages d’obtention de la qualité requise de l’application à mettre en place  tout ce qui concerne les méthodes de tests, le contrôle et le suivi des anomalies ou dysfonctionnements constaté

39 La qualité organisationnelle
F - Les normes de développement Il s’agit souvent d’un document qui accompagne le Plan d ’Assurance Qualité projet  il est plutôt dédié à la phase de réalisation du projet Ce document explique et définit les normes de nommage, de stockage, de sauvegarde et d’implémentation des différents livrables de la phase de réalisation (les différents objets, modules, programmes, les tables et colonnes de la base de données, les requêtes, les documents d’études, les documents techniques …)

40 La qualité organisationnelle
Conclusion Le Plan d ’Assurance Qualité est un outil très répandu dans le domaine du service informatique. Il facilite le travail de tous les protagonistes du projet. Néanmoins, sa seule présence n’est pas suffisante pour assurer la réussite totale du projet. En effet, le respect des éléments du PAQ, la bonne entente et la bonne communication entre le prestataire et le client ainsi que la documentation de chaque intervention sont des éléments importants qui contribuent au succès.