Qualité
interne des logiciels : trop souvent négligée
La qualité d'un logiciel ne se mesure pas qu'à l'absence de bug. Son aptitude à évoluer sans faire exploser les délais et les budgets rentre aussi en ligne de compte. (Vendredi 28 novembre
2003)
Dell vient d'annoncer le rapatriement aux Etats-Unis
d'un de ses centres de support jusque là implanté en Inde. Ce centre
était dédié aux postes de travail Optiplex et aux ordinateurs
portables de la gamme Latitude. Le niveau de service a été jugé
insuffisant par un nombre de clients suffisamment élevé pour que
le constructeur prenne cette décision pour le moins rare, voire courageuse.
Cet exemple montre à quel point la non-qualité
peut surgir là où on l'attend le moins.
C'est vrai pour le matériel, les services, mais
aussi pour les logiciels, trop souvent perçus comme
des biens immatériels auxquels les normes de qualité
s'appliquent difficilement, ou de façon trop parcellaire,
se limitant par exemple à la seule correction des
bugs.
Qualité
externe : qualité perçue et workflow Pour Carmine Mangione,
expert-formateur en développement logiciel et professeur
à l'Université de Seattle, qui s'exprime
régulièrement dans les colonnes de notre
confrère américain CIO.com, le niveau de
qualité d'un logiciel tient en deux points fondamentaux
: la réponse aux besoins des utilisateurs (fonctionnalités,
workflow, performances, etc.) et le respect des
contraintes de l'entreprise (délais, budgets, etc.).
Seules les sociétés à très
forte notoriété, en position de leadership,
voire de monopole, peuvent se permettre de produire des
logiciels imparfaits sans que cela leur soit préjudiciable
en termes financiers (rentabilité du projet en
lui-même).
Carmine Mangione divise la qualité des développements logiciels
en deux grandes catégories : la qualité externe et la qualité
interne. La qualité externe se rapporte à la valeur perçue
par l'utilisateur mais aussi à la fluidité de l'enchaînement
des processus lors de l'utilisation de la solution. La qualité perçue
correspond à des critères de fiabilité et de stabilité
du logiciel alors que l'enchaînement des processus se rapporte à
la façon dont la solution résout un problème lié aux
tâches quotidiennes de l'utilisateur, compte tenu des spécificités
de son secteur d'activités. Les interfaces ont, pour ce dernier point,
un rôle déterminant.
Carmine Mangione attire l'attention des responsables qualité en pointant
du doigt une confusion trop souvent commise : la politique d'assurance qualité
mise en oeuvre au sein d'une entreprise ne garantit pas forcément la qualité
finale des produits. En effet, l'assurance qualité ne porte que sur l'adéquation
entre les spécifications initiales et le résultat final (le livrable),
sans tenir compte de la pertinence des fonctionnalités eu égard
aux besoins de l'utilisateur.
Qualité
interne : qualité de la conception et aptitude à
évoluer
La qualité interne se focalise sur la capacité
de l'entreprise à apporter des modifications à
une solution existante. Ce peut être l'élimination
de défauts constatés (bugs) mais aussi l'ajout
de nouvelles fonctionnalités. Ce niveau de qualité
est directement lié à la phase de conception
du logiciel et au choix du langage de programmation, compte
tenu de la taille du logiciel et de son environnement
sectoriel.
Une qualité interne dégradée
ne permet pas aux développeurs d'estimer précisément le temps
nécessaire à l'ajout de nouvelles fonctionnalités, ni d'éviter
que ces ajouts ne génèrent des bugs additionnels, eux-mêmes
sources de coûts supplémentaires.
Si la qualité externe est essentielle à l'adoption du produit par
le client, la qualité interne permet à l'entreprise de respecter
ses budgets et, par là même, se garder sa position dans un marché
donné. C'est un aspect des choses trop souvent négligé, comme
quoi la qualité n'est pas toujours là où on l'attend le plus.