A14 Std 982.2 Mesures de la science du logiciel (Halstead)

 

Application : « Ces mesures mesurent la complexité du code d’un logiciel, prédisent la longueur d’un programme et permettent d’estimer le temps nécessaire à un programmeur moyen pour mettre en œuvre un algorithme donné. ». Cet ensemble de mesures est un des premières tentatives de quantifier des attributs des artéfacts logiciels. Il s’agit de mesures d’attributs concernant la qualité interne qui s’appliquent pendant la mise en œuvre et la maintenance.

Primitives : « n1 =             Nombre d’opérateurs distincts d’un programme
n2 =              Nombre d’opérandes distinctes d’un programme
N1 =              Nombre total d’occurrences des opérateurs
N2 =              Nombre total d’occurrences des opérandes
S =                 Nombre de Stroud (typique 18 discriminations élémentaire à la seconde »
 

Mise en œuvre : « Une fois que le code a été écrit, cette mesure peut être appliquée pour prédire la difficulté d’un programme et d’autres quantités, en employant les équations de Halstead :
l = n1 + n2                                                 Vocabulaire du programme
L = N1 + N2                                               Longueur observée du programme
Le = n1(Log2 n1) + n2 (Log2 n2)            Longueur estimé du programme
V = L Log2 (n1 + n2)                                Volume du programme
D = (n1/2) (N2/n2)                                   Difficulté du programme
L1 = 1/D                                                      Niveau du programme
E = V/L1                                                      Effort
B = V/3000                                                 Nombre d’erreurs
T = E/S                                                        Temps
 » …

Interprétation : La signification de l et de L est très claire et on peut facilement imaginer leur utilité. Plus le vocabulaire l est grand et plus il y a d’éléments à apprendre et donc plus il y a des possibilités d’erreurs. Pour la longueur observée du programme il n’y a pas de doute non plus que plus on a d’occurrences d’opérateurs et d’opérandes et plus le programme devient volumineux. L’effort est calculé en multipliant le volume pas la difficulté ce qui, si volume et difficulté sont interprétables selon le sens commun, semble correcte.

Considérations : La troisième équation dit que, pour estimer la longueur d’un programme, il faut connaître le vocabulaire, mais on ne peut connaître la richesse du vocabulaire que quand on a fini le codage ce qui rend l’estimation pas très utile.

Pédalogue.

Qualitatif : Je trouve tout cela assez compliqué. Il y a des mesures calculées qui me semblent trop simples et d’autres dont la signification m’échappe.

Quantitatif : Par exemple ?

Qualitatif : Le nombre de défaut B. L’équation dit qu’il y a une proportionnalité directe entre le volume d’un programme et le nombre d’erreurs.

Quantitatif : Normal. Il est évident que plus un programme est long et plus il y a d’erreurs.

Qualitatif : Ce n’est pas cela que je conteste, ce que je conteste c’est l’utilité d’une formule qui néglige tous les autres éléments qui influencent les erreurs et qui introduit la constante 3 000 comme… comme Planck introduisit sa célèbre constante.

Quantitatif : Encore une fois tu veux faire dire à une métrique plus que ce qu’elle veut dire.

Qualitatif : Mais alors, étant donné que le nombre de défauts est quelque chose que l’on peut compter, il suffit d’attendre assez longtemps…

Quantitatif : Attention ! La norme ne parle pas de nombre de défauts mais de nombre d’erreurs. Et on ne peut compter les erreurs qu’indirectement.

Qualitatif : Mais, dis-moi alors, est-ce que il y a une relation de type un à un entre erreur et défaut ?

Quantitatif : Heu… Heu… Oui, je crois que oui.

Qualitatif : Donc, du point de vue des métriques, le nombre d’erreurs est toujours égal au nombre de défauts, la seule différence étant qu’une erreur est un défaut qui n’est pas encore apparu. Si on considère par contre les défauts résiduels, alors il y a vraiment une identité numérique complète entre défauts et erreurs.

Quantitatif : Oui. Je crois que tu as raison.

Qualitatif : Donc si mon erreur est l’oubli d’une exigence j’ai un seul défaut comme si j’échange le Then et l’Else dans un module.

Quantitatif : Heu… Je vois où tu veux en venir. Il est peut-être préférable de considérer B comme le nombre de défauts.

Qualitatif : Je peux donc compter de manière indépendante des métriques d’Halstead le nombre de défauts et vérifier si la formule est bonne. Mais si c’est comme cela, mon intuition me dit qu’on risque de trouver une « constante » tellement variable qu’elle n’est d’aucune utilité pratique.

Quantitatif : Ton intuition peut très bien te tromper.

Qualitatif : Bien sûr. Pour te démontrer ma bonne foi je vais ajouter qu’un intérêt non secondaire des métriques c’est qu’elles obligent à approfondir la signification des concepts employés et de leurs relations. Ce qui n’est pas négligeable dans un domaine si flou. Dans ce cas-ci, par exemple, il faudrait approfondir la signification d’erreur et de défaut et si, du point de vue des métriques de la qualité, ils sont la même chose, alors il faudrait sans doute leur donner un coup de rasoir d’Occam.