Une structure de gestion de la qualité doit donner un sens aigu de l'intégralité de la qualité et établir une base à des fins d'amélioration. Tribune écrite avec l'aide de Thomas E. Murphy.
Constat - La première étape pour créer une structure de gestion de la qualité consiste à s'assurer que les utilisateurs et l'entité informatique comprennent et s'accordent sur le sens du mot "qualité". - Les entités informatiques doivent établir une façon cohérente de mesurer le succès, tel qu'il est perçu par les utilisateurs. - La qualité ne se mesure pas seulement en termes de défauts, de couverture du code et d'automatisation.
Recommandations
- Mettez en place une approche formelle de gestion de la qualité visà-vis du développement d'applications. - Mettez l'accent sur les perspectives des utilisateurs et des parties prenantes. La satisfaction des clients est la mesure clé de la réussite des projets.
Une piètre qualité logicielle peut avoir un impact négatif sur une entreprise à de nombreux égards, tels que la productivité des utilisateurs, le temps de disponibilité des systèmes, la satisfaction des clients et les coûts du support, des changements apportés aux applications et des opérations métiers. L'amélioration de la qualité des logiciels fournis nécessite une approche fondamentale et formelle qui implique deux composants clés : un mécanisme pour comprendre comment les parties prenantes perçoivent la qualité globale, et un processus que l'équipe en charge des applications utilise pour revoir son code fourni et les résultats du projet à l'origine de sa création ou modification.
Cela nécessite à la fois de réaliser des enquêtes pour savoir comment les utilisateurs perçoivent les données et de développer un processus pour comprendre et documenter les composants de qualité technique et fonctionnelle d'un projet.
De nombreuses entreprises cherchent à améliorer la qualité des logiciels qu'elles fournissent, mais ne savent pas par où commencer. Parfois, ce dilemme est motivé par des commentaires anecdotiques et aléatoires des utilisateurs finaux selon lesquels la qualité de leurs logiciels laisse à désirer, ou le coût pour garantir la qualité est trop élevé. Dans d'autres cas, les entreprises entendent des responsables informatiques constater que, quelle que soit la qualité du logiciel, il y a toujours moyen de l'améliorer. Dans l'un ou l'autre cas, il existe un ensemble basique de pratiques et de métrologies qui donneront à l'équipe en charge des applications une perspective sur la qualité de son travail, ainsi qu'une marche à suivre en vue d'améliorer ses résultats.
Gartner reçoit fréquemment des demandes de la part de clients qui veulent améliorer la qualité des logiciels qu'ils développent et fournissent, ou bien qui veulent savoir où ils se situent en comparaison de leurs concurrents dans l'industrie. Dans certains cas, il s'agit d'une réaction immédiate à une interruption de production majeure après qu'un projet a été remis. Dans d'autres, c'est le résultat de commentaires informels adressés par des responsables métiers à des responsables informatiques, ou le fait que l'entreprise a adopté une méthode d'amélioration de la qualité, telle que la gestion économe ou Six Sigma, et demande à l'entité informatique : "Où en est votre programme ?". Dans d'autres cas encore, les responsables des applications veulent simplement savoir comment être meilleurs dans leur travail. En général, l'entreprise ne pense pas en termes de qualité, mais uniquement en termes de coût et de fourniture des fonctionnalités métiers utiles. Si l'équipe en charge de la qualité fait du bon travail, tout fonctionne "comme il faut" et les personnes se demandent souvent pourquoi il a fallu si longtemps pour parvenir à une telle qualité. En revanche, si le logiciel est défaillant, c'est l'équipe responsable des tests qui est blâmée pour ne pas avoir détecté le problème plus tôt.
La plupart des entreprises sont incapables de définir ce qui constitue un mieux. Lorsqu'elles y parviennent, il s'agit d'une vue incomplète. Il leur faut une approche formelle de la gestion de la qualité qui reconnaît les dimensions clés de la qualité, et un ensemble de mesures qui permettent à l'entreprise d'identifier les domaines à améliorer et de mettre l'accent sur les changements spécifiques qu'elle peut accomplir avec succès.
Dimension 1 : aspect des utilisateurs et des parties prenantes
La qualité est une question de perception. Dans le cas présent, elle est appréciée par le groupe de personnes qui utilisera les logiciels fournis (applications nouvelles ou améliorées). Tout processus de gestion de la qualité doit donc commencer par mettre l'accent sur ces utilisateurs finaux ou acheteurs des logiciels, et les autres parties prenantes qui sont impliquées dans le processus de développement, et il doit aussi être mesurable. Cette mesure doit être faite à deux moments :
- à la fin de chaque projet (ou livraison majeure de fonctionnalité, en cas d'utilisation de méthodes agiles ou itératives). Il doit y avoir une boucle de retour d'informations qui permet à l'équipe en charge des applications de comprendre si son travail est satisfaisant. C'est ce qu'on appelle généralement une revue de projet ou, plus justement, une analyse après projet (remarque : il peut s'agir d'une itération dans les méthodes agiles), quand les données sur les performances du projet sont rassemblées et analysées à des fins d'amélioration. L'un des composants clés de cette pratique de collecte des données est l'enquête de satisfaction. Cette enquête doit être brève (sinon, elle ne sera pas remplie) et faire partie des éléments livrables attendus par le parrain du projet. L'une des questions incluses dans cette enquête doit être : "Le logiciel était-il assez satisfaisant pour être utilisé ?". En général, les réponses doivent être notées sur une échelle de un à sept, par exemple, où 1 correspond à la meilleure note. Dans la vue acceptable, un logiciel zéro défaut est onéreux et nécessaire à certains projets ; toutefois, l'objectif global doit être l'obtention d'un logiciel de suffisamment bonne qualité. Cette attitude reflètera également davantage qu'une vue des défauts traditionnelle. Un logiciel de qualité est un logiciel exploitable. Il possède les fonctionnalités demandées, une documentation et des systèmes d'aide qui sont clairs ;
- annuellement pour les contrats de niveau de service (SLA). Chaque année (ou parfois plus souvent), les SLA relatifs à une application doivent être revus et mis à jour. Encore une fois, la distribution d'une courte enquête doit faire partie de ce processus. L'une des questions clés de cette enquête doit porter sur la perception globale qu'a l'utilisateur de la qualité du travail accompli par le groupe en charge des applications. Le point de vue de l'utilisateur deviendra apparent en examinant les demandes de modification et la charge de travail qui pèse sur le centre de services. Toutes les demandes de commentaires des utilisateurs ne sont pas forcément de mauvais augure. L'entreprise progresse, et une approche agile est conçue dans l'idée qu'une application évoluera comme le fait l'entreprise ; par contre, si une liste de modifications est dressée immédiatement après que le logiciel est livré, c'est qu'il y a manifestement des problèmes au niveau des impératifs et des processus de qualité. Si le centre d'assistance est inondé de questions à propos du logiciel, c'est que ce dernier comporte des défauts en termes de convivialité, de formation et de documentation.
Les utilisateurs et acheteurs de logiciels peuvent ou non avoir des attentes rationnelles, tout au moins aux yeux de ceux qui fournissent ces logiciels. C'est particulièrement vrai lorsqu'il n'existe pas de mesure claire et cohérente de la perception de la qualité. La première étape pour combler cet écart dans les attentes consiste à mesurer les perceptions aussi efficacement que possible pour déterminer si un tel écart existe. C'est seulement une fois que les attentes sont comprises qu'une discussion sur les mesures de correction peut avoir lieu. Il y a un équilibre entre ce que l'équipe de développement peut fournir et prendre en charge, et ce que les utilisateurs sont prêts à payer (et la rapidité avec laquelle la fourniture et la prise en charge peuvent être assurées).
Rappelons que le point de départ réside dans les données. Ici, la clé consiste à comprendre ce qui est jugé acceptable aux yeux de l'utilisateur final, puis à comprendre à combien s'élèvent les coûts "raisonnables" pour ce niveau de qualité et de service. Le processus fonctionne dans les deux sens, mais sans les données, il est impossible de l'entamer et encore moins de le mener à bien.
Viadeo
Contributions 
La continuité d'activité objet d'une nouvelle norme ISO
Georges Epinette
Philippe Vilandrau
Dominique Poussin
Francis Massé
Vous sentez-vous concerné par la valeur du capital immatériel de l'entreprise, logiciels et données notamment ?
