Y a-t-il un travail dans l'application des mesures de complexité Halstead pour déterminer la qualité du logiciel?

En 1977, Maurice Howard Halstead a présenté ses mesures de complexité pour les systèmes logiciels , qui comprenaient des mesures du vocabulaire du programme, de la longueur du programme, du volume, de la difficulté, de l'effort et d'un nombre estimé de bogues dans un module. Selon Wikipedia, la difficulté est liée à la difficulté de comprendre le programme lors de sa lecture ou de son écriture et l'effort peut être traduit en temps nécessaire pour coder une application où Time = (Effort / 18) secondes.

Une mesure est inutile à moins que les données et les calculs ne concernent un aspect du développement logiciel. Cependant, je n'ai trouvé aucun travail qui indique qu'une difficulté d'une certaine valeur ou plus tend à une augmentation statistiquement significative des défauts ou une relation entre la difficulté et le temps de lecture du code (une difficulté de N donne une moyenne de M heures passées comprendre la base de code) ou toute analyse de la possibilité de calculer le temps après coup comme étant utile pour déterminer la qualité (d'autant plus que le temps d'écriture aurait déjà dû être enregistré comme une mesure). Je suis particulièrement intéressé par l'estimation des bogues de Halstead (qui n'est pas mentionnée sur Wikipedia) - le nombre de bogues dans une application peut être estimé par Volume / 3000 ou Effort ^ (2/3) / 3000.

Je cherche deux choses:

Quelqu'un a-t-il utilisé les mesures de complexité logicielle de Halstead dans une application réelle pour évaluer la qualité du logiciel? Dans l'affirmative, comment les avez-vous appliqués et se sont-ils révélés être une mesure utile, valide et / ou fiable?
Existe-t-il des recherches universitaires sous forme d'enquêtes, d'analyses ou d'études de cas qui discutent de la validité (ou de l'invalidité) des mesures de complexité Halstead lorsqu'elles sont appliquées à la qualité des logiciels?
Existe-t-il des recherches universitaires sous forme d'enquêtes, d'analyses ou d'études de cas qui démontrent l'utilisation des lignes de code source (SLOC) pour calculer quelque chose de similaire aux métriques Halstead de volume, difficulté, effort, temps et bogues? Je soupçonne que le volume pourrait simplement correspondre à un compte SLOC et la difficulté pourrait correspondre à la complexité cyclomatique (et peut-être d'autres mesures). Je sais également que mesurer l'effort, la productivité ou le temps dans le SLOC est potentiellement trompeur.

quality metrics measurement

— Thomas Owens
source

Vous allez avoir du mal à trouver des résultats au cours des 15 dernières années, car le travail de métrologie de Halstead a été fait plus comme il y a 30 à 40 ans, et la forte corrélation avec le SLOC a été découverte presque immédiatement. (Ceci est de mémoire, à partir d'une conférence d'un nouveau doctorant à UT Austin vers 1977.)

— John R. Strohm

Merci pour ça. Je mettrai à jour la question et recentrerai mon travail sur les fils plus anciens.

— Thomas Owens

Réponses:

Microsoft Research a effectué certains travaux dans ce domaine. Consultez cette page: http://research.microsoft.com/en-us/people/nachin/ . Bien que n'étant pas spécifiquement basé sur Halstead, Nachi et son équipe ont fait des recherches en utilisant Halstead, la complexité cyclomatique, la désabonnement au code et d'autres mesures pour évaluer le risque relatif et la fragilité pour apporter des modifications dans les domaines du code. Il y a aussi un article intéressant sur la façon dont l'efficacité organisationnelle joue également un grand rôle, mais c'est hors sujet. :)

— nithins
source

Je vais devoir lire certains d'entre eux. Certainement quelque chose qui m'intéresse, mais je suis (au moins en ce moment), particulièrement intéressé par Halstead, donc je vais me concentrer là-dessus. J'ai mis en signet le site afin que je puisse le lire quand j'aurai plus de temps, mais voici un +1 pour le moment.

— Thomas Owens

Il a été démontré que la complexité cyclomatique de McCabe, sur du code réel, est très fortement corrélée avec le SLOC brut, au point qu'il n'y a aucune valeur incrémentielle dans son calcul.

— John R. Strohm

Il existe de nombreuses études de ce type. Google est ton ami.

Les mesures de Halstead sont tombées en disgrâce lorsqu'il a été démontré que toutes étaient fortement corrélées avec les SLOC bruts (lignes de code source). À ce stade, il devient plus facile de mesurer le SLOC et d'en finir avec.

Voici un résultat de Google Livres .

— John R. Strohm
source

Je fais des recherches sur Google depuis avant de poser cette question et je n'ai pas encore trouvé d'articles publiés ou d'autres sources fiables. De plus, je ne vois pas comment une métrique liée au SLOC peut être médiocre. SLOC / temps est une mauvaise mesure de la productivité, mais d'autres mesures basées sur SLOC sont généralement considérées comme valides, un exemple étant les défauts / SLOC.

— Thomas Owens

@Thomas: Ce n'est pas que les métriques de Halstead sont "liées" au SLOC, c'est qu'elles sont fortement corrélées. Statistiques 102. Dire que Y et X sont fortement corrélés signifie que le rapport Y / X est essentiellement constant pour tous les ensembles de données. Dans ce cas, il est inutile de mesurer Y s'il est plus facile de mesurer X, car Y ne vous dit vraiment rien de ce que vous ne savez pas déjà de X.

— John R. Strohm

Ça a du sens. Les métriques de Halstead sont basées sur le nombre d'opérateurs et d'opérandes distincts et totaux. Il est de bon sens qu'un programme plus long aura plus d'opérateurs / opérandes au total et aura plus probablement d'opérateurs / opérandes plus distincts. Les métriques de volume et de difficulté peuvent être obtenues en utilisant SLOC au lieu d'opérateurs / opérandes. Cependant, cela ne traite pas de la validité, des applications et du sens (ou du manque de sens) des mesures d'effort, de temps et de bogues. Même lorsqu'ils sont calculés avec SLOC au lieu d'opérateurs / opérandes, ces mesures indiquent-elles quelque chose de significatif sur le système?

— Thomas Owens

SLOC est plus facile à compter et probablement plus utile. Les estimations du SLOC sont utilisées par plusieurs techniques d'estimation des coûts, suivies dans le PSP et le TSP, et peuvent être utilisées dans d'autres mesures telles que la densité des défauts. Cela, pour moi, dit que compter SLOC pourrait être mieux que compter les opérateurs / opérandes. Deuxièmement, et sans réponse jusqu'à présent, la validité des métriques d'effort, de temps et de bogues, quelles que soient les mesures utilisées pour les calculer. Je suis d'accord que les calculer avec SLOC pourrait être mieux, mais même si je le faisais, cela signifierait-il quelque chose?

— Thomas Owens

@ThomasOwens: Probablement pas. Si l'effort, le temps et les bogues sont tous fortement corrélés au SLOC, cela vous indique que tous les programmes d'une taille donnée prennent environ le même temps et le même effort et ont le même nombre de bogues. Les deux premiers sont sur lesquels est basée l'estimation du SLOC (par exemple COCOMO) et reviennent à dire que l'eau est humide. Le troisième ne vous aide pas vraiment.

— John R. Strohm

Le fait que le volume de Halstead soit corrélé avec le SLOC est intéressant mais limité. Statistiques de base: la corrélation linéaire n'est pas transitive. X en corrélation avec Y, Y en corrélation avec Z NE SIGNIFIE PAS que X est en corrélation avec Z.

— user1704475
source

Lorsque X et Y sont simplement corrélés, et Y et Z sont simplement corrélés, oui, X et Z ne sont pas nécessairement corrélés, en raison des niveaux de bruit relativement élevés dans les deux premières corrélations. Lorsque X et Y sont fortement corrélés, et Y et Z sont fortement corrélés, il y a très, très peu de bruit impliqué, et il devient hautement probable dans tous les cas que X et Z se révèlent corrélés.

— John R. Strohm