S3. Management de l’informatique
Plan du thème n°4. LA QUALITE DES PROJETS INFORMATIQUES Travail à faire :
Question 1. A partir du document 1, intitulé :
« La qualité : une notion évolutive et complexe », répondez aux 2 questions suivantes :
- 1.1. Quels sont les apports de la qualité totale (et du principe d’amélioration continue) à la maîtrise des projets informatiques ? (faites une courte recherche complémentaire sur ces notions si besoin)
- 1.2. Qu’est-ce que le plan d’assurance qualité et pourquoi est-il difficile à mettre en œuvre au sein des projets informatiques selon A. Fernandez ?
Question 2. A partir du document 2 et pour conclure cette première partie des enseignements,
rédigez une synthèse
1relative à la qualité des projets informatiques : Pour cela, efforcez-vous de répondre aux questions suivantes et d’illustrer votre propos (par des exemples trouvés sur le net
2) : - Pourquoi la qualité des projets informatiques
3est-elle une préoccupation relativement récente ? - En quoi la qualité des projets logiciel est-elle plus problématique ou plus complexe que celle des
projets industriels par exemple ?
- Un projet peut-il, en général, respecter simultanément tous les facteurs & critères de qualité ? Qui doit alors définir ceux-ci, contrôler leur respect ?
- Quel diagnostic, une entreprise gérant ses projets de systèmes d’information peut-elle faire grâce au modèle « CMM-I » ? (faites une courte recherche sur ce modèle si besoin) ?
- Selon A. Lefebvre, pourquoi faut-il privilégier une démarche corrective plutôt que préventive pour les projets informatiques (et donc quelles sont les limites des méthodes décrites précédemment) ?
Document 1. La qualité : une notion évolutive et complexe
Les nouvelles normes ISO 90004 sont les héritières de l’évolution de la notion de qualité en management. Au début du XXe siècle, dans les entreprises « fordistes » où l’OST est mise en œuvre, le contrôle de la qualité passe essentiellement par une inspection visuelle opérée en fin de chaîne de production : la qualité se réduit alors à la vérification de la conformité du produit au standard prédéfini par le bureau d’étude. Elle est confiée au contremaître et, en aucun cas, à l’opérateur lui-même. En outre, il n’est pas question d’évaluer la qualité du processus de
1 Une réponse structurée avec une courte introduction (la problématique) et une conclusion vous permettant d’exprimer un point de vue par exemple.
2Voir notamment :
http://www.mines.u-nancy.fr/~tisseran/cours/qualite-logiciel/qualite_logiciel.html Mais aussi des revues en ligne telles que : www.01net.com
3 Vous pouvez restreindre votre étude aux projets de système d’information ou projets logiciel à l’instar de C. Morley
4 prenant effet au 01/01/2004
« Si un maçon a construit une maison et que celle-ci n’est pas suffisamment solide et que la maison s’écrase et tue ses occupants, le maçon devra être tué »
Code d’Hammourabi, roi de Babylone, 17 s. av. notre ère
fabrication, conçu et développé par les ingénieurs du bureau des méthodes.
Pourtant, dès 1950, des ingénieurs de la General Electric, dont A.V.
Feigenbaum, forment des responsables américains et des homologues japonais à une nouvelle conception de la qualité (voir encadré intitulé : « la JUSE ») qui prendra tout son sens dans le système « toyotiste » dénommée la « qualité totale ». On y affirme que la qualité ne se réduit pas aux produits mais à l’ensemble du processus de production et à toute l’entreprise, du service de R&D à la mise sur le marché (en passant par l’approvisionnement, le marketing, les fonctions de support telles que la comptabilité et la finance, l’informatique…). En outre, tout le personnel doit être associé à la recherche d’une amélioration continue.
Mais, si dès 1947, les spécialistes du management décident de réunir leurs savoirs et d’édicter des règles à suivre permettant à des entreprises de se faire certifier par des organismes indépendants afin de se distinguer aux yeux de leurs clients, c’est en 2000 que les leçons de la qualité totale semblent enfin retenues. Entre temps, il aura fallu de nombreuses dérives procédurières pour comprendre qu’il ne suffit pas de tout décrire et de tout vérifier a posteriori pour « gagner la partie » ! L’esprit de la « qualité totale » est économique : si la qualité est coûteuse, la non-qualité l’est davantage encore ; la meilleure façon d’être rentable pour une entreprise est de faire bien du premier coup. Il est préférable de supprimer la plupart des contrôles si cela permet de responsabiliser les acteurs (P.B. CROSBY le prétendait dès 1961 en tant que directeur qualité d’ITT) afin qu’ils repèrent préventivement et continûment les sources de non-qualité. « Ainsi, des normes de spécification,
on est passé à des normes modélisant l’attente de l’utilisateur, ce qui permet d’éviter que la norme subisse la même obsolescence que la technologie (ex : KODAK), puis à des normes portant sur la gestion de la qualité dans l’entreprise (ISO 9000) ».
Pour C. Morley5, la qualité d’un projet de système d’information6 se gère dans le même esprit : le management de projet fait l’objet d’une norme spécifique (ISO10006) et la qualité doit être négociée entre le maître d’ouvrage et le maître d’œuvre, au sein d’un plan d’assurance qualité, afin que les responsabilités de chacun soient clarifiées :
« D'abord, on définit des normes et on vérifie la conformité. Puis, on découvre que le nombre de dysfonctionnements est élevé, on améliore alors le processus de développement. Enfin, on s'aperçoit que les clients ne sont pas satisfaits par des produits techniquement bons et que les attentes doivent être prises en compte. Ni le client, ni le fournisseur ne peuvent attendre la livraison pour découvrir que le produit n’est pas satisfaisant. L'un et l'autre ont intérêt à préciser les facteurs qui serviront de base à l'appréciation de la qualité. Cela conduit à une négociation devant aboutir à un compromis. En effet, quand le client cherche à préciser les critères de jugement, il est conduit à identifier des fonctionnalités qui s'ajoutent à l'expression brute du besoin (une aide en ligne par exemple) ainsi que des procédés de production (utilisation d'un atelier de génie logiciel par exemple). Ces fonctionnalités et ces procédés induisent souvent une charge supplémentaire (coûts, délais). Il faut donc trouver un compromis entre le niveau des exigences et le prix consenti.
Au maître d'ouvrage (le client) [project owner en anglais], il appartient de définir les facteurs qualité qui caractérisent le produit attendu, au maître d' oeuvre (le fournisseur) [project manager], de définir les facteurs qualité du processus de développement à mettre en oeuvre pour produire ce qui a été convenu, c'est-à-dire des fonctionnalités assorties d'un couple coût-délai ».
5 « Management d’un projet SI », Dunod, 2003
6 développement d’un logiciel spécifique, intégration d’un progiciel, projet de maintenance informatique évolutive…
La « JUSE » ou Japanese Union Scientists and Engineers est une association d’ingénieurs américains &
japonais, constituée après la seconde guerre mondiale, dont les travaux relatifs à la qualité font toujours référence, qu’il s’agisse de la roue de Deming, représentative du principe d’amélioration continue (ou Kaïsen en japonais), du diagramme causes-effet d’Ishikawa d’analyse d’un défaut de qualité (en
« arête de poisson »), par exemple.
A. Fernandez7 est beaucoup plus critique à l’égard de la démarche qualité entreprise au sein des projets informatiques. Pour lui, la définition de la qualité de l’AFNOR est ambiguë et cette ambiguïté est à l’origine de bien des problèmes :
« - Un ingénieur de développement : “On a bossé comme des malades pour tenir les délais, et au final ils ne sont pas contents !”
- Un utilisateur : “Ils n’ont rien compris de ce que l’on voulait ! ”
Dès le lancement du projet, il existe une incompréhension capitale entre les donneurs d’ordres, futurs utilisateurs du système, et les prestataires, maîtres de l’art, chargés de la réalisation. Par manque de dialogue, ces incompréhensions initiales tendent à devenir chroniques au fur et à mesure de l’avancement du projet. Par principe, les clients et les prestataires n’ont pas la même notion de la performance.
Ils ne visent pas la même cible : le client attend une solution offrant des services originaux, adaptée à ses modes de fonctionnement et contribuant à une prise d’avantage concurrentiel. Le prestataire souhaite limiter les risques et reproduire ce qu’il a déjà fait auparavant et qu’il connaît bien. Son optique de performance est de l’ordre de la recherche de la standardisation et de la reproductibilité. Le désaccord est fondamental. Aussi exhaustifs que puissent être les cahiers des charges, contrats et autres documents initiaux, cette incompréhension initiale ne sera pas résolue simplement.
L’incompréhension permanente entre les clients commanditaires du projet et les ingénieurs en charge de la réalisation est vraisemblablement la principale cause des insatisfactions réciproques, une fois le système livré.
(…) Il n’est plus raisonnable de se focaliser sur la maximisation de l’habituel tripôle : délais, budgets et qualité – ce dernier paramètre étant le plus souvent sacrifié aux dépens des deux premiers. Quelle peut bien être l’utilité d’un système, achevé dans les temps et sans trop de dépassement
de budget, qui, bien que juridiquement conforme au contrat initial, ne répond pas aux attentes réelles du client ? Il est peut-être temps maintenant de changer de référentiel, pour placer la notion de valeur des services rendus au regard du client au premier plan des préoccupations.
En fait, c’est peut-être le concept de qualité qui mérite un bain de
jouvence. Confiné depuis trop d’années au cœur d’un processus de normalisation procédural, il en a perdu toute substance.
Il faut vraisemblablement dès à présent en réformer l’acception usuelle et revenir au sens originel. Car, c’est bien le concept de qualité qui, porteur d’un sens bien plus profond que ne pourraient le laisser supposer les pratiques en vigueur, répond à cette notion de valeur pour le client.
En bâtissant un référentiel fédérateur autour de cette notion rénovée de la qualité, on augmentera sérieusement les chances de délivrer au final les services attendus. Client et prestataire pourront alors communiquer en se fondant sur des références de performance communes. Les deux cibles, dont nous parlions ci-dessus, tendent ainsi à se confondre. »
7 « Les secrets de la conduite de projet », éditions d’organisation, 2003
Selon l’AFNOR, la qualité se définit comme « l’aptitude d’un processus, d’un produit ou d’un service à répondre au besoin de son utilisateur ».
source : A-M Hugues / Génie logiciel
_______________________________________________
Document 2. La gestion de la qualité des projets logiciels
« La qualité des systèmes d’information (SI) est une préoccupation relativement récente. Les 1ères normes relatives au logiciel sont apparues au début des années 1970 aux Etats-Unis sous l’impulsion des militaires, puis de l’IEEE8. (…) La notion de qualité des logiciels est issue des industries aéronautiques et spatiales, préoccupées de fiabilité. A la fin des années 1980, l’importance des budgets informatiques, la place des applications informatiques dans le fonctionnement des entreprises, la part dominante consacrée à la maintenance des logiciels et les problèmes rencontrés dans la plupart des grands projets informatiques ont porté la qualité des SI au rang des préoccupations majeures dans les entreprises.
La partie logicielle d’un SI présente des caractéristiques qui marquent la problématique de sa qualité : il est immatériel, reproductible, il nécessite une maintenance et possède une dimension subjective. (…)
Personne n’a jamais vu un logiciel, on ne le perçoit qu’à travers les représentations que sont le code et la documentation. (…) Cela demande un effort d’abstraction important. (…) La qualité étant définie par l’aptitude d’un produit ou d’un service à satisfaire les besoins des utilisateurs, une des grandes difficultés en SI, est d’identifier les utilisateurs et leurs besoins, a fortiori implicites.
La reproduction en série d’un logiciel ne pose aucun problème. Le processus de fabrication est unitaire ce qui est profondément différent des industries de masse où s’est ancrée la réflexion qualité. (…) Pour un logiciel, tout l’effort doit porter sur la conception et la mise au point du modèle9.
(…) Le coût d’un logiciel ne se limite pas au coût du développement mais doit tenir compte du coût de maintenance. Différentes études ont montré que lorsqu’une erreur coûte 1 € si elle est détectée à l’étape de
8Institute of Electronics and Electrical Engineers
9 Les projets d’intégration de progiciels de gestion aussi sont uniques car il faut adapter les progiciels au SI spécifique de l’entreprise utilisatrice !
conception, elle en coûtera près de 40 à la réalisation et plus de 100 en maintenance corrective.
(…) La qualité perçue comporte, outre sa dimension objective qui est la conformité au cahier des charges, une dimension subjective dépendant du contexte relationnel. Cet aspect fait qu’une partie de la qualité d’un SI, comme dans le domaine des services, est concomitante à la production et ne se retouche pas a posteriori10. »
« La norme ISO 9126 (reprise par la norme française NFZ 67133) a énoncé six critères de qualité permettant de décrire, de manière communicable (sinon mesurable), la qualité
d'un logiciel (que l'on spécifie, contrôle, achète, etc.). Ces six caractéristiques sont les suivantes11 :
1) Capacité fonctionnelle (functionality) : les fonctions correspondant aux besoins exprimés ou implicites sont-elles présentes ? Cette capacité fonctionnelle peut être décomposée en aptitude, interopérabilité, conformité aux règlements, respect des normes, etc.
2) Facilité d'utilisation ( usability ) : quel est l'effort requis pour utiliser le logiciel ? Cette facilité est définie par rapport à un ensemble d'utilisateurs potentiels. Elle peut être décomposée en facilité de compréhension, facilité d’apprentissager, facilité d’exploitation.
3) Fiabilité (reliability) : quelle est l'aptitude du logiciel à maintenir son niveau de service dans des conditions précises et pendant une période déterminée ? Elle peut ê décomposée en maturité, tolérance aux fautes, possibilité de récupération, etc.
4) Rendement, efficience (efficiency) : quel est le rapport entre le niveau de service offert par le logiciel et la quantité des ressources utilisées (matériel, autres logiciels, personnes…) dans un contexte déterminé. Elle peut être décomposée en temps de réponse, débit, etc., rapporté à des quantités de ressources consommées.
5) Maintenabilité (maintenability) : quel est l'effort nécessaire pour apporter des modifications (corrections, amélioration fonctionnelle, changement organisationnel, changement de spécification, etc.) ? Cela peut être décomposé en : facilité d'analyse, modularité, stabilité, facilité de test, etc.
6) Portabilité (portability) : quelle est l'aptitude du logiciel à être transféré dans un autre environnement technologique: matériel ou logiciel de base différents ? Cette caractéristique peut se décomposer en facilité d'adaptation, facilité d'installation, interchangeabilité, etc.
On notera que ces caractéristiques de la qualité sont essentiellement des caractéristiques du produit (et des services qu'il offre). Dans le cadre général des normes ISO 9000, il est également nécessaire d'évaluer la qualité des processus aboutissant au logiciel, c'est-à-dire la qualité de la démarche de projet allant de l'étude préalable à la maintenance. Les travaux classiques de T. Forse qualifient le processus de production à l'aide de trois indicateurs : - la capacité à estimer (les besoins, les temps, etc.) ;
- la capacité à produire (écriture des spécifications, des programmes) ;
- l’efficacité dans l'utilisation des techniques (outils logiciels de conception et de développement).
Les aspects les plus sensibles dans la conduite du processus d'élaboration et d'implantation du logiciel nous paraissent être :
- la capacité d'analyse et validation des besoins (comprendre et vérifier la demande);
- la maîtrise méthodologique (connaissance des concepts et des démarches) ;
10 « management des projets systèmes d’information » C. Morley, Dunod, 2003.
11 La norme s’inspirent des travaux de Boehm-McCall
- la maîtrise technologique (connaissance des langages et des techniques de programmation) ; - l'efficacité des procédures de test et réceptions.
La figure 37 présente les principaux facteurs de la qualité d'un logiciel. Ces différents facteurs peuvent être décomposés en critères de qualité avec des métriques associées12 ».
« la démarche consiste donc, au cours du dialogue entre MOE et MOA, à expliciter les facteurs correspondant à la qualité attendue, puis à préciser les critères correspondants et enfin à déterminer les métriques8 » (les critères sont mesurables). Ceux-ci sont alors consignés dans un plan d’assurance qualité contractuel.
L’ intérêt de la démarche est de permettre au MOA & au MOE « d’expliciter les attentes qualité des acteurs, ceux qui utilisent le SI et ceux qui le font vivre (exploitation et maintenance). Par ailleurs, la démarche fait apparaître d’éventuelles contradictions dans les exigences, résultant de la présence de facteurs antinomiques13. Elle oblige donc à faire des choix, à hiérarchiser les facteurs (pour ne retenir que ceux qui satisferont réellement le client ?)10 ».
Le PAQ précise également qui contrôle la qualité et à quel moment du projet (le DSI du client pour les études, les utilisateurs au moment de la mise en service…), le PAQ pouvant naturellement évoluer avec le projet.
« La gestion de la qualité des logiciels a été longtemps réduite à une démarche « curative » limitée au contrôle a posteriori, de la conformité des programmes aux spécifications du cahier des charges. L’évolution des niveaux de maturité des entreprises concernant la gestion de projet SI (ou modèle de maturité CMM-I14, présenté dans le tableau ci-dessous), conduit aujourd’hui à combiner démarche préventive (en négociant des PAQ) et démarche curative (tests de qualification et maintenance), l’idéal étant que des erreurs, des dysfonctionnements constatés puissent ne pas être reproduits dans un projet ultérieur15. »
Cependant, sur ce dernier point les experts ne sont pas unanimes. A. Lefebvre, vice-président du groupe SQLI, développe un point de vue très critique à l’égard des méthodes de développement des projets informatiques16 (voir : http://solutions.journaldunet.com/0105/010504_decrypt_methodes2.shtml ). En effet, même si les méthodes de conception ont formalisé des règles,
des techniques, une démarche, réutilisables en partie ou en totalité sur
chaque projet,
l’application de la méthode ne garantit jamais à 100% l’obtention du résultat escompté.
12 En général, il est difficile de contrôler si un facteur qualité est bien respecté ou s’il ne l’est pas, tandis que les critères associés à ce facteur sont eux mesurables, donc aisément vérifiables. D’après R. Reix, « Management des SI », Vuibert, 2004.
13 Qu’on ne peut obtenir simultanément.
14 http://www.01net.com/article/259747.html
15 R. Reix, « Management des SI », Vuibert, 2004.
16 A l’exception d’eXtrem Programming
