Des facteurs de risque aux impacts: un chemin complexe mais identifiable
La non qualité d’un logiciel se traduit par des défaillances de natures diverses, qui entravent son fonctionnement de façon inattendue lors de son utilisation.
Ces défaillances peuvent avoir un impact sur le fonctionnement des services dont dépend le bon fonctionnement du logiciel. Ceci concerne non seulement des services qui utilisent directement le logiciel, mais aussi ceux, internes ou externes à l’entreprise, dont l’activité dépend de données fournies par le logiciel, qui peuvent eux aussi pâtir de ces défaillances.
Les causes premières de ces défaillances, ou « facteurs de risque », résident principalement dans les trois phases du processus d’élaboration du logiciel.
- ainsi, un défaut de précision ou de complétude dans l’explicitation des exigences peut entraîner de nombreuses défaillances,
- il en va de même lorsque la conception du logiciel ne prend pas correctement en compte les exigences propres au besoin exprimé ou celles découlant de son intégration au système d’information de l’entreprise et avec des systèmes externes à celle-ci,
- enfin, la mise en œuvre de technologies mal maîtrisées dans la phase de réalisation peut, elle aussi, entraîner des défaillances.
Au regard de ces grands facteurs de risque, on notera que la phase d’expression des exigences, à l’origine du projet, est porteuse de risque pour l’ensemble des défaillances envisageables. Elle doit de ce fait être considérée comme le socle dont la qualité engage celle de l’ensemble du projet de mise en œuvre.
Last but not least, la construction du projet en termes de ressources humaines (compétences en particulier), moyens matériels, budget et planning pourra avoir un effet amplificateur ou réducteur sur ces facteurs de risque, selon que les contraintes qu’elle imposera au projet seront on non supportables.
Les facteurs de risque évoluent aussi avec la complexité du contexte
On pourrait imaginer que les acquis des années passées en termes de compétences techniques et de maîtrise dans la conduite des projets réduisent le risque de non-qualité logicielle, mais ce serait oublier que les technologies sont en constante évolution.
En particulier, les progrès technologiques et normatifs réalisés durant les vingt dernières années ont permis un accroissement significatif des possibilités d’échanges entre systèmes d’information (« inter-opérabilité des applications »). Ainsi, il est désormais habituel de concevoir des applications échangeant des données entre elles, au sein de l’entreprise comme entre les entreprises (« B2B ») ou avec des particuliers (« B2C »).
Ce progrès indéniable présente toutefois un revers important: les effets des défaillances logicielles ont une portée potentielle aussi grande que celle des informations transmises entre les applications.
De même que pour une chaîne, dont « la résistance est celle de son maillon le plus faible », l’impact d’une défaillance logicielle peut désormais excéder les limites de l’entreprise, fragilisant ainsi ses relations avec ses partenaires, entreprises comme clients.
La maîtrise du risque logiciel passe par le contrôle de la qualité
Ainsi, loin d’être un acquis par défaut, la qualité logicielle ne peut être que le résultat d’une maîtrise des risques évoqués plus haut, maîtrise active et consciente, qui passe par un moyen unique : le contrôle de la qualité du logiciel produit.
Ce contrôle est un processus impliquant une confrontation systématique de la production d’une phase donnée avec celle des phases qui la précèdent, afin de détecter au plus tôt des failles dont l’impact en aval pourrait se révéler critique.
Le processus de contrôle de la qualité logicielle, pour être véritablement efficace, doit donc accompagner tout le cycle de mise en œuvre.
Les grandes étapes du Contrôle de la Qualité Logicielle
Le contrôle de la qualité logicielle consiste à poser des « barrières qualité » entre chaque grande phase du processus de mise en œuvre du logiciel.
Ces barrières sont les étapes de vérification des livrables produits par chaque phase. Elles empêchent le passage à la phase suivante tant qu’il subsiste des écarts (erreurs ou omissions) jugés trop importants pour poursuivre. Tout écart détecté entraîne un retour sur la phase concernée, afin d’améliorer le livrable et d’éviter la propagation de cet écart dans les phases suivantes.
Le contrôle de la qualité logicielle est mis en œuvre par une équipe dédiée, qui interagit avec la maîtrise d’ouvrage (MOA) pour les exigences et avec la maîtrise d’œuvre (MOE) pour les aspects relatifs
à la conception et à la réalisation du logiciel.
- la revue des exigences vise à réduire le poids de l’implicite en vérifiant la conformité des exigences explicitées avec les besoins réels,
- la revue de conception vérifie la conformité de la conception de la solution logicielle avec les exigences explicitées et avec les contraintes de son intégration au SI de l’entreprise et aux échanges avec l’extérieur,
- les tests techniques vérifient la conformité du logiciel réalisé avec la conception,
- les tests utilisateur vérifient la conformité du logiciel réalisé avec les exigences explicitées.
Détecter tôt réduit les risques de défaillance et les coûts de correction
Une phase de contrôle qualité peut détecter des écarts dans toute phase projet qui la précède :
- par exemple, un écart détecté au cours des tests utilisateurs peut questionner tout ce qui a été produit entre l’explicitation des exigences et la réalisation du logiciel,
- un écart détecté pendant la revue des exigences aura un coût de correction infiniment moindre que la défaillance résultante, détectée après la réalisation,
- c’est pourquoi la maîtrise des exigences est un facteur déterminant de la réussite des projets.
