Tribunes

Les trois dimensions de la gestion de la qualité du développement d'applications

---

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.

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

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

Dimension 2 : qualité Fonctionnelle



Dimension 2 : qualité Fonctionnelle

La qualité fonctionnelle détermine dans quelle mesure le logiciel fourni ou utilisé répond aux besoins de l'entreprise, et si les processus utilisés pour ce faire fonctionnent correctement ou non. Ici, il y a deux composants cruciaux, qui sont la mesure et l'amélioration. Tout d'abord, au moment de la revue du SLA ou du projet, des techniques d'enquête doivent être utilisées pour savoir comment l'utilisateur perçoit l'adéquation fonctionnelle. L'enquête de revue du projet doit comporter deux questions clés pour savoir si le logiciel fourni était conforme à ce que l'entreprise voulait et s'il était conforme à ce qui avait été convenu. Dans certains cas, il y aura un écart entre les réponses à ces questions. Au moment de la revue du SLA, il est important d'interroger l'entreprise sur le niveau de fiabilité des processus de fourniture et de support.

Un SLA n'est pas seulement une mesure rétrospective. Les applications doivent être conçues dans un souci de facilité de maintenance et elles doivent être développées et optimisées avec un ensemble de niveaux de service clairement compris et documentés par tous les utilisateurs et fournisseurs. Les performances sont fonctionnelles par nature, mais elles sont généralement considérées comme faisant partie de l'ensemble des impératifs non fonctionnels. Documentez clairement les impératifs non fonctionnels pour chaque projet, et détectez les défauts par rapport à ces impératifs, tout comme vous le feriez avec les impératifs fonctionnels.
Une bonne structure de qualité intégrera un processus robuste de gestion et de suivi des défauts. Au minimum, le suivi des défauts doit commencer en même temps que les tests de type boîte noire (autrement dit, le test d'acceptation ou des systèmes) et se poursuivre tout au long de la période de stabilisation du projet (généralement 30 à 90 jours après le lancement du projet), puis durant le support du logiciel (autrement dit, les défauts signalés qui ne sont pas causés par un logiciel actuellement couvert par la garantie de stabilisation).

Au minimum, le suivi des défauts doit identifier :
- le défaut signalé de manière unique ;
- la gravité du défaut ;
- le nombre de fois où le défaut a été signalé ;
- la phase durant laquelle le défaut a été introduit ;
- la phase durant laquelle le défaut a été découvert ;
- le type de défaut ou la cause première du défaut, ou encore les deux (par exemple, un défaut introduit durant la phase de définition des impératifs peut être un défaut de commission ou d'omission, et la cause première peut être que la personne appropriée n'était pas disponible lorsque les impératifs ont été rassemblés) ;
- le coût de la suppression (facultatif, et peut représenter un trop grand nombre de données).

Il est également nécessaire d'obtenir des données sur le coût des défauts qui perdurent d'une phase à l'autre. Dans un projet itératif ou en cascade, il s'agit du coût pour corriger un défaut qui se propage en aval. Dans un projet agile, il s'agit du coût pour remanier ou corriger le défaut en dehors d'une itération donnée. Pour apporter cette correction, une entreprise doit collecter des données sur le coût du remaniement.

Gartner recommande aux entreprises de rassembler ces données phase par phase. Ainsi, le coût pour corriger un défaut de conception découvert au cours d'un test d'acceptation sera enregistré dans une tâche du plan de projet appelée "remaniement : conception". En comprenant les informations propices à l'endiguement des défauts, l'entreprise peut suivre une approche dirigée sur les domaines nécessitant des améliorations, soutenue par une bonne compréhension de l'impact relatif des différents types de défaut ou d'un remaniement réduit.

La décomposition des données relatives aux coûts et aux défauts ne doit pas être plus détaillée que nécessaire, à savoir les données qui sont utilisables pour apporter des modifications. Il peut être suffisant de comprendre le nombre global de défauts qui ont été rencontrés eu égard aux impératifs, par exemple, ainsi que le coût global de la correction de ces défauts. Par contre, il n'est pas forcément nécessaire de comprendre le coût d'une activité de correction d'un défaut spécifique. Si les données ne sont pas exploitables, elles ne doivent pas être mesurées.

Une fois les données disponibles, des techniques types d'amélioration des processus (diagrammes de Pareto, diagrammes en arête de poisson et autres) doivent être utilisées pour prendre des mesures correctives aux problèmes perçus et aux défauts induits par les données. Notre approche à trois dimensions fournit des conseils sur la manière de structurer les efforts d'amélioration. L'utilisation de ces données pour favoriser des améliorations comporte des implications majeures en termes de coût.

Dimension 3 : qualité technique



Dimension 3 : qualité technique

L'aspect le plus négligé d'une structure de gestion de la qualité est généralement la qualité technique du produit fourni ou pris en charge. Si les efforts d'amélioration de la qualité technique sont menés projet par projet (ou à des moments spécifiques pour les logiciels installés, déterminés par l'analyse périodique du code), les implications ont une portée beaucoup plus grande.

Un code mal structuré qui est développé selon des normes de codage médiocres et est extrêmement complexe ou comporte de grandes quantités de code mort aura pour conséquences :
- une baisse globale de la productivité pour les futures améliorations ;
- une capacité limitée à favoriser les objectifs de réutilisation ;
- une hausse des défauts de régression ;
- le risque d'un manque d'évolutivité et de problèmes de stabilité en aval.

Ces problèmes sont particulièrement aigus lorsque le développement et la maintenance du code sont externalisés, ou dans les situations où le développement et la maintenance sont effectués par deux groupes différents. Le problème ici est de se retrouver avec un code médiocre qui fonctionne. Si nous ne sommes pas suffisamment cyniques pour suggérer que c'est intentionnel de la part d'un tiers, nous sommes sûrs que, si cela se produit, les coûts de l'amélioration et de la maintenance des logiciels seront plus élevés tout au long de la durée de vie de l'application et qu'il sera plus difficile de déplacer le support de l'application en interne ou vers un autre tiers.

Le processus de suppression des défauts de qualité technique se déroule généralement à l'aide d'un outil d'analyse du code, dans le cadre du processus de génération ou sous forme de tâche de pré-enregistrement. Un vaste ensemble d'outils est disponible ;

la plupart des outils sont spécifiques du langage ou peuvent mettre l'accent uniquement sur des types de problèmes spécifiques. Bien que la norme ISO/CEI 9126 soit disponible pour la qualité des logiciels, aucun des produits sur le marché ne la prend en charge.

De nombreux éditeurs proposent des options commerciales ou en code source ouvert pour mesurer les défauts logiciels, notamment :
- Black Duck Software ;
- Cast Software ;
- Coverity ;
- Klocwork ;
- McCabe Software ;
- Metrixware ;
- Omnext ;
- Parasoft ;
- Sonar.

Dans un effort de développement interne, combinez l'utilisation de l'outil avec un processus d'inspection ou de revue par les pairs pour favoriser la prévention des défauts. Lorsque vous faites appel à des fournisseurs tiers, l'utilisation de cet outil doit faire partie du processus d'acceptation entre le fournisseur et ses clients. Cela peut également inclure d'aller au-delà de la qualité pour étudier les questions relatives au code source ouvert ou autres problèmes potentiels liés aux licences.

Points clés

- Il est souvent impossible de mesurer la qualité des logiciels telle qu'elle est vue par les utilisateurs finaux, sauf via des mesures de la perception, telles que des enquêtes d'opinion.
- La qualité a un prix, et les logiciels qui doivent se conformer à des niveaux de service plus élevés coûteront presque toujours plus cher à développer que les logiciels qui doivent se conformer à des exigences de niveau de service inférieures.
- Les équipes en charge des applications doivent mesurer la qualité technique et la qualité fonctionnelle. Or, la plupart des équipes qui mesurent la qualité se concentrent uniquement sur l'aspect fonctionnel.
- Le suivi des défauts et l'analyse et la suppression des causes premières sont des composants cruciaux d'un processus de gestion de la qualité en interne.

Légende des acronymes

SLA Contrat de niveau de service (Service Level Agreement)

Article rédigé par

Matthew Hotle, Vice président au cabinet Gartner

Matthew Hotle est vice président au cabinet de recherche et consulting Gartner. Il conseille les DSI et directeurs informatiques sur leur stratégie de gouvernance des applications.