Qualité du logiciel, une notion polysémique

Nous avons tous déjà été confrontés à des logiciels de mauvaises qualité, ou même des logiciels d'apparente bonne qualité, mais imparfaits. Combien de fois avons-nous râlé contre un logiciel de traitement de texte après qu'il nous a fait perdre plusieurs pages de travail non enregistré... Et tout cela au 21ème siècle ! Que l'on soit utilisateur, client, développeur ou même patron du développeur, notre conception de la qualité du logiciel diffère. Cet article est l'occasion d'un tour d'horizon (non-exhaustif) des principales attentes de chacun.

L'Utilisateur

Sa définition de la qualité du logiciel est la plus facile à cerner, puisque nous sommes tous utilisateur de logiciels. Ci-dessous, quelques-unes de ses attentes.

  • Simplicité

Facilité d'utilisation et d'apprentissage... Ce sont les fameuses "UX" et "UI", soit l'expérience utilisateur et l'interface utilisateur, dont l'importance est aujourd'hui en constante augmentation, et qui font référence à la fois à l'ergonomie et à l'esthétique.

Les développeurs ont parfois tendance à négliger ces aspects, qui comptent pourtant énormément aux yeux des utilisateurs.
On peut prendre en exemple une célèbre application de météo française, qui au gré de ses mises à jour a noyé les utilisateurs sous des fonctionnalités inutiles. Son utilisation est devenue complexe et peu intuitive, ce qui lui a fait perdre des utilisateurs. Ceux-ci se sont alors tournés vers des applications avec moins de fonctionnalités, mais plus simples.

  • Performance

  • Absence de défaut

Le Client

  • ROI

Le client représente l'entité qui "paye", par exemple un chef d'entreprise qui commande un logiciel qui va être utilisé pour améliorer la gestion de ses produits. Sa principale préoccupation est le "ROI", ou Retour sur Investissement.

Le client doit prendre en compte à la fois les coûts et les gains associés au logiciel. Grâce à ce dernier, les opérations menées doivent être plus performantes qu'avant – qu'elles aient été menées sans logiciel ou avec un autre. Parallèlement au coût d'acquisition, il faut prendre garde au coût de possession. Celui-ci est dû à l'entretien du logiciel, parfois coûteux.

  • Conformité

Le client a une double exigence de conformité. Il faut bien sûr que le logiciel soit conforme aux exigences réglementaires (comptables, fiscales, santé...). Mais en tant qu'acheteur il s'intéresse aussi au respect du cahier des charges. Que le logiciel soit développé spécifiquement ou acheté sur étagère, il est important de vérifier sa conformité aux demandes ou à la description qui en est faite. Dans le cadre d'un produit vendu sur étagère, la description est trop souvent négligée ou non réaliste, ce qui peut par la suite entraîner des désaccords entre acheteur et vendeur.

  • Sécurité

De nombreux clients ont besoin d'assurer la confidentialité des données traitées. Ils souhaitent au minimum une identification pour chaque utilisateur... Ce qui est un critère de qualité pour le client mais est généralement ressenti comme une contrainte par les utilisateurs.

  • Robustesse

L'appréhension de la robustesse est liée à l'absence de défaut, mais elle est surtout présente au niveau stratégique. Elle est principalement liée au comportement du logiciel et de l'infrastructure informatique en cas de panne : le temps de travail qui va être perdu (RPO) et le temps que le logiciel va mettre pour récupérer le travail effectué en cas de crash (RTO).

Le client attend aussi du logiciel une capacité à détecter les défauts. Il s'agit de bloquer une manœuvre si l'utilisateur a fait une erreur, où si l'un des fichiers est faux (un problème de format, par exemple). S'ils ne sont pas repérés, ce type de défaut peut prendre de l'ampleur et entraîner de réels coûts pour l'entreprise.

  • Adéquation

Le logiciel doit bien sûr être en adéquation aux besoins et aux processus métier. Ce besoin est partagé par les utilisateurs.

Le Développeur

Le développeur s'intéresse à la qualité interne du logiciel. Il lui sera plus facile d'agir sur un logiciel bien conçu.

  • Lisibilité

La façon dont le code est écrit, commenté, structuré... Sans contexte, il est très difficile de comprendre un bout de code. Le développeur redécouvre constamment le code, y compris celui qu'il a lui-même écrit. C'est toujours un effort car même si l'écriture parait évidente sur le moment, elle ne l'est plus quand il faut le relire quelques temps plus tard. La qualité initiale du code en lui-même ne suffit pas à éviter la relecture, car il y a toujours de nouvelles fonctionnalités à rajouter pour lesquelles il faut se replonger dans le code.
C'est pour cela qu'il faut améliorer la lisibilité du code, en rajoutant des commentaires et en définissant par écrit à quoi correspond exactement chaque composant logiciel.

  • Facilité de diagnostic

Il s'agit de mesurer l'effort à déployer pour comprendre d'où vient le défaut et comment le corriger. Elle est apportée par les tests existants, leur complétude et, comme pour la lisibilité du code, la définition de ce à quoi ils correspondent. La plupart des développeurs se basent sur leur mémoire et leur connaissance du code. Ils pourraient être beaucoup plus efficaces en améliorant la qualité du code et de sa documentation.

  • Testabilité

La première condition pour tester le code est de savoir à quoi sert chaque composant logiciel : il n'y a pas de test sans spécification. Il faut ensuite que le logiciel soit structuré pour être facilement testable. Il y a toujours bénéfice à automatiser les tests, ce qui nécessitera la constitution d'un harnais de test et sera facilité par la mise en oeuvre de techniques telles que l'inversion de dépendance ou le mocking.

  • Maintenabilité

C'est la facilité avec laquelle on peut corriger un défaut ou ajouter une nouvelle fonctionnalité. Un facteur important est d'éviter les duplications de code, ce qui permettra de circonscrire les modifications de code lors des opérations de maintenance. À ce propos nous vous conseillons l'excellent ouvrage Refactoring de Martin Fowler.

Le Patron

L'employeur du développeur est un acteur souvent oublié, et pourtant très présent. Ses attentes et besoins, bien que légitimes, sont souvent en opposition avec ceux des autres acteurs. Il est plus intéressé par la qualité du projet logiciel que par la qualité du logiciel en lui-même.

  • Rapidité

Le chef d'entreprise souhaite livrer le logiciel au client au plus vite, d'une part parce que la rapidité de livraison peut être facteur de la satisfaction du client, et d'autre part pour une raison financière. Plus vite la commande est livrée, plus vite elle sera facturée.
Cela peut poser des problèmes pour la qualité au niveau du développeur : si le code écrit est en apparence juste, il arrive plus d'une fois que l'employeur livre la fonctionnalité... Même si les tests ne sont pas finis. Cela peut entraîner par la suite des défauts et donc des surcoûts.

  • Transparence

L'employeur veut pouvoir savoir où en est exactement le projet à n'importe quel moment.

  • Faibles coûts

Infographie de la qualité du logiciel attendue à la qualité perçue by JPI-Conseil

 

Avec tous ces points de vue, est-il possible de faire un logiciel qui soit de qualité pour tous ?

Le logiciel parfait n'existe pas. L'essentiel pour le développeur est de répondre à ses propres exigences de qualité, tout en restant au plus près des attentes des clients et utilisateurs. Pour cela, il est important de sans cesse communiquer. Les attentes doivent être clairement explicitées dès le départ, et réajustées au fil du projet... Cela permet d'éviter les découvertes (trop) tardives et difficilement rattrapables. On a ainsi une perception de la qualité finale plus proche de la qualité attendue.

Pas de commentaire.

Ajouter un commentaire