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.

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. :)

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 .

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.