Qualité logicielle

En informatique et en particulier en génie logiciel, la qualité logicielle est une appréciation globale d'un logiciel, basée sur de nombreux indicateurs ^[1].

La complétude des fonctionnalités, la précision des résultats, la fiabilité, la tolérance de pannes, la facilité et la flexibilité de son utilisation, la simplicité, l'extensibilité, la compatibilité et la portabilité, la facilité de correction et de transformation, la performance, la consistance et l'intégrité des informations qu'il contient sont tous des facteurs de qualité^[2].

Un logiciel est un produit qui ne se détériore pas et qui est continuellement modifié. La qualité d'un logiciel dépend entièrement de sa construction, la qualité logicielle est par conséquence un sujet central en génie logiciel. Une appréciation globale de la qualité tient autant compte des facteurs extérieurs, directement observables par l'utilisateur, que des facteurs intérieurs, observables par les ingénieurs lors des revues de code ou des travaux de maintenance.

Les problèmes de qualité des logiciels, connus depuis les années 1960, sont par ailleurs à l'origine du génie logiciel : la science de la création de logiciels, y compris toutes les difficultés qui y sont liées - respects des coûts, des délais, du cahier des charges et du niveau de qualité^[3].

Il existe un référentiel de certification du système de management de la qualité en entreprise, en matière d’ingénierie du logiciel le TickIT.

Indicateurs de qualité logicielle

La norme ISO 9126 définit six groupes d'indicateurs de qualité des logiciels^[4] :

• la capacité fonctionnelle. c'est-à-dire la capacité qu'ont les fonctionnalités d'un logiciel à répondre aux besoins explicites ou implicites des usagers. En font partie la précision, l'interopérabilité, la conformité aux normes et la sécurité ;

• la facilité d'utilisation, qui porte sur l'effort (le peu d') nécessaire pour apprendre à manipuler le logiciel. En font partie la facilité de compréhension, d'apprentissage et d'exploitation et la robustesse - une utilisation incorrecte n'entraîne pas de dysfonctionnement ;

• la fiabilité, c'est-à-dire la capacité d'un logiciel de rendre des résultats corrects quelles que soient les conditions d'exploitation. En font partie la tolérance de pannes - la capacité d'un logiciel de fonctionner même en étant handicapé par la panne d'un composant (logiciel ou matériel) ;

• la performance, c'est-à-dire le rapport entre la quantité de ressources utilisées (moyens matériels, temps, personnel), et la quantité de résultats délivrés. En font partie le temps de réponse, le débit et l'extensibilité - capacité à maintenir la performance même en cas d'utilisation intensive ;

• la maintenabilité, qui porte sur l'effort (le peu d') nécessaire en vue de corriger ou de transformer le logiciel. En font partie l'extensibilité, c'est-à-dire le peu d'effort nécessaire pour y ajouter de nouvelles fonctions ;

• la portabilité, c'est-à-dire l'aptitude d'un logiciel de fonctionner dans un environnement matériel ou logiciel différent de son environnement initial. En font partie la facilité d'installation et de configuration pour le nouvel environnement.

Chaque caractéristique contient des sous-caractéristiques. Il y a 27 sous-caractéristiques.

Les différents indicateurs sont parfois conflictuels, ou au contraire complémentaires : une augmentation de la capacité fonctionnelle a un impact négatif sur la performance, la maintenabilité et la fiabilité. Tandis qu'une augmentation de la fiabilité, la maintenabilité ou de la disponibilité ont un impact positif sur l'utilisabilité. En outre, une augmentation de la maintenabilité a un impact négatif sur la performance^[5].

La crise du logiciel

Un phénomène de baisse des prix du matériel informatique et d'augmentation des prix du logiciel, accompagné d'une baisse de la qualité des logiciels a été identifié à la fin des années 1960 et nommé la « crise du logiciel ». Cette crise s'apparente aujourd'hui à une maladie chronique de l'industrie du logiciel, dont les symptômes sont les suivants :

• les délais de livraison des logiciels sont rarement tenus, le dépassement de délai et de coût moyen est compris entre 50 et 70 % ;
• la qualité du logiciel correspond rarement aux attente des acheteurs, le logiciel ne correspond pas aux besoins, il consomme plus de moyens informatiques que prévu, et tombe en panne ;
• les modifications après coup des logiciels coûtent cher, et sont à l'origine de nouveaux défauts. Les adaptations sont bien souvent une nécessité du fait de l'évolution des produits et des attentes des utilisateurs ;
• il est rarement possible de réutiliser un logiciel existant pour en faire un nouveau produit de remplacement, l'amortissement du coût de développement initial est ainsi rendu impossible^[6].

Auparavant minoritaire, le coût du logiciel en 1965 représentait 50 % du coût total d'un système informatique. En 1985 la part du logiciel est de 80 % et les coûts dus à la correction des défauts dans les logiciels (maintenance) représente jusqu'à trois quarts du coût total d'acquisition, un excédent dû uniquement à la mauvaise qualité du logiciel lors de sa livraison.

Selon une étude réalisée en 1994 par le Standish Group, 53 % des logiciels créés sont une réussite mitigée : le logiciel est opérationnel, cependant le délai de livraison n'a pas été respecté, les budgets n'ont pas été tenus, et certaines fonctionnalités ne sont pas disponibles. Le dépassement des coûts est en moyenne de 90 %, et celui des délais de 120 %, et la qualité moyenne est estimée à 60 %^[7].

Raisons du manque de qualité des logiciels

Un logiciel étant un bien immatériel, les seules représentations observables du logiciel sont le code source, l'interface utilisateur et la documentation (spécification). La quantité de code source (nombre de lignes) est rarement connu, ce qui entraîne souvent une sous-estimation de la complexité du logiciel.

Pour chaque module d'un logiciel il existe de nombreuses conditions d'utilisation. La combinaison des différentes conditions d'utilisation des différents modules d'un logiciel amène une explosion combinatoire, et lors de sa construction un logiciel n'est jamais contrôlé dans la totalité des conditions d'utilisation qu'il rencontrera durant son exploitation; ceci pour des raisons pratiques (coût et durée des travaux).

Une autre raison est qu'il n'y a pas de lien entre un défaut mineur et majeur, et une modification mineure ou majeure. Et l'effort de détérioration d'un logiciel n'est pas proportionnel à l'effort de construction. Un défaut mineur peut entrainer un incident majeur, et nécessiter une correction mineure. Dans l'incident du vol 501 d'Ariane 5, une correction mineure aurait suffi à éviter la destruction de la fusée. De même une modification mineure d'un logiciel peut le mettre hors d'usage; un phénomène largement exploité par les virus informatiques^[8].

Pour être considéré comme produit de qualité par l'usager, un logiciel doit répondre aux besoins exprimés explicitement par l'usager aussi bien qu'aux besoins implicites (non exprimés). Or les vœux implicites évoluent avec le marché, et il arrive bien souvent que des vœux implicites des usagers ne soient pas connus des ingénieurs logiciels^[9].

Amélioration de la qualité

En génie logiciel, la recherche d'abstraction, de dissimulation, de structuration, d'uniformité, de complétude et de confirmabilité sont des mesures destinés à améliorer la qualité du logiciel, en factorisant le code, c'est-à-dire en n'écrivant qu'une fois des instructions similaires. Cela permet que les modifications soient le plus locales possibles. Cette factorisation concerne les structures de données elles-mêmes (notamment par l'usage des classes et de l'héritage), et les traitements (par l'usage des boucles, fonctions et procédures). Un gain complémentaire de réduction du code source est apporté par le polymorphisme et la liaison dynamique (qui éliminent les « procédures aiguillage ») en programmation objet.

La modularité, c'est-à-dire la qualité d'un logiciel d'être découpé en de nombreux modules, permet l'abstraction et la dissimulation. Associée avec un couplage faible, elle vise à augmenter la maintenabilité du logiciel en diminuant le nombre de modules touchés par des éventuelles modifications, ainsi que la fiabilité en diminuant l'impact que l'échec d'un module peut avoir sur les autres modules.

En jargon de programmation, un plat de spaghetti désigne un logiciel de mauvaise qualité au couplage trop fort et au code source difficile à lire, dans lequel toute modification même mineure demande un intense travail de programmation.

L'abstraction vise à diminuer la complexité globale du logiciel en diminuant le nombre de modules et en assurant l'essentiel. Elle peut également apporter une uniformité du logiciel qui augmente son utilisabilité en facilitant son apprentissage et son utilisation.

La dissimulation vise à séparer complètement les détails techniques du logiciel de ses fonctionnalités selon le principe de la boîte noire, en vue d'améliorer sa maintenabilité, sa portabilité et son interopérabilité.

La structuration des instructions et des données rend clairement visible dans le code source les grandes lignes de l'organisation des instructions et des informations manipulées, ce qui améliore sa maintenabilité et facilite la détection des bugs^[10].

De nombreux langages de programmation soutiennent, voire imposent l'écriture de code source selon les principes de structuration, de modularité et de dissimulation. C'est le cas des langages de programmation structurée et de programmation orientée objet.

Notes et références

Voir aussi

• Bug informatique
• Logiciel
• Génie logiciel
• Qualité des données
• Consortium for IT Software Quality
• TickIT

Lien externe

• Portail de la qualité logicielle

• Portail de la programmation informatique