Comment définir la Qualité Logicielle ?
La mise en œuvre d’une application informatique résulte d’un processus dont l’objectif est de traduire un ensemble de besoins opérationnels dans une solution logicielle apte à satisfaire ces besoins.
Ce processus consiste en trois étapes successives de traduction du besoin initial, destinées à produire successivement :
- une expression formalisée du besoin sous forme d’exigences, fonctionnelles et non-fonctionnelles,
- la conception d’une application informatique propre à satisfaire ces exigences tout en respectant les contraintes du système d’information dans lequel la solution logicielle doit être implantée,
- le logiciel réalisé résultant de cette conception.
Au cours de ce processus, l’objectif est qu’il n’y ait aucune perte entre chaque étape de traduction, afin d’aboutir à un parfait recouvrement entre les exigences exprimées, la conception applicative issue de ces exigences et le logiciel réalisé sur la base de cette conception.
Une telle situation répondrait à la définition première de la qualité :
« la Qualité, c’est la Conformité aux Exigences »
Même dans un cas aussi idéal, une question subsiste quant à la conformité des exigences exprimées sur le papier avec les besoins bien réels de l’utilisateur.
En effet, si l’on n’a pas pris la précaution de s’assurer d’une telle conformité, une solution logicielle parfaitement conforme à sa conception, elle même parfaitement conforme aux exigences exprimées, pourrait s’avérer parfaitement inutilisable.
C’est pour cette raison que nous nous sommes approprié la définition de l’AFNOR, selon laquelle :
la Qualité d’un produit, réside dans sa capacité à satisfaire les exigences exprimées et implicites du consommateur.
Identifier les causes de non-qualité pour apprécier le risque logiciel
Assez loin de cette vision idyllique d’une conformité parfaite, la réalité montre bien souvent des écarts plus ou moins importants entre ce qui est souhaité et ce qui a pu être réalisé. La qualité n’est alors que partielle, à l’image du recouvrement des trois composantes issues du processus.
On pourrait envisager de se satisfaire d’un degré de qualité partiel de la solution logicielle réalisée. Encore faudrait-il pour cela être capable de mesurer le degré de cette qualité et de s’assurer que les écarts de conformité observés ne sont pas préjudiciables au fonctionnement des entités utilisatrices de cette solution.
Or, c’est précisément dans ces écarts que vont se loger les risques de dysfonctionnement applicatif, certains d’entre eux pouvant engendrer des conséquences plus ou moins handicapantes pour les utilisateurs, voire pour l’entreprise elle-même.
Dans le tableau ci-dessous, nous avons recensé, qualifié et classé les risques les plus importants résultant des écarts possibles entre les trois composantes de la mise en œuvre d’un logiciel.
