Mesures objectives de la qualité des logiciels [fermé]

Il existe différents types de qualité qui peuvent être mesurés dans les produits logiciels, par exemple l'adéquation à l'objectif (par exemple, l'utilisation finale), la maintenabilité, l'efficacité. Certains d'entre eux sont quelque peu subjectifs ou spécifiques au domaine (par exemple, de bons principes de conception d'interface graphique peuvent être différents selon les cultures ou dépendre du contexte d'utilisation, pensez à l'utilisation militaire par rapport à l'utilisation par le consommateur).

Ce qui m'intéresse, c'est une forme plus profonde de qualité liée au réseau (ou graphique) des types et à leur interdépendance, c'est-à-dire à quels types chaque type fait-il référence, existe-t-il des clusters d'interconnectivité clairement identifiables architecture à plusieurs niveaux, ou à l'inverse existe-t-il une grosse «boule» de références de type (code «monolithique»). De plus, la taille de chaque type et / ou méthode (par exemple, mesurée en quantité de code d'octet Java ou .Net IL) devrait donner une indication de l'endroit où de grands algorithmes complexes ont été mis en œuvre sous forme de blocs de code monolithiques au lieu d'être décomposés en plus faciles à gérer / à gérer. morceaux.

Une analyse basée sur de telles idées peut être capable de calculer des métriques qui sont au moins un indicateur de qualité. Le seuil exact / les points de décision entre la haute et la basse qualité seraient suspects, par exemple, car par maintenabilité, nous entendons la maintenabilité par les programmeurs humains et donc la décomposition fonctionnelle doit être compatible avec la façon dont les esprits humains fonctionnent. En tant que tel, je me demande s'il peut jamais y avoir une définition mathématiquement pure de la qualité du logiciel qui transcende tous les logiciels possibles dans tous les scénarios possibles.

Je me demande également si c'est une idée dangereuse, que si les procurations objectives de qualité deviennent populaires, les pressions commerciales inciteront les développeurs à poursuivre ces mesures au détriment de la qualité globale (ces aspects de la qualité non mesurés par les procurations).

Une autre façon de penser la qualité est du point de vue de l'entropie. L'entropie est la tendance des systèmes à passer d'états ordonnés à des états désordonnés. Quiconque a déjà travaillé sur un projet logiciel de taille moyenne à grande échelle appréciera le degré de dégradation de la qualité de la base de code au fil du temps. Les pressions commerciales entraînent généralement des changements qui se concentrent sur de nouvelles fonctionnalités (sauf lorsque la qualité elle-même est le principal argument de vente, par exemple dans les logiciels avioniques), et l'érosion de la qualité par des problèmes de régression et une fonctionnalité de `` taille de chaussures '' où elle ne correspond pas bien. une perspective de qualité et de maintenance. Alors, peut-on mesurer l'entropie des logiciels? Et si oui, comment?

C'est une idée dangereuse. Des procurations «objectives» pour la qualité mènent directement à des récompenses de gestion et les développeurs poursuivront ces mesures au détriment de la qualité réelle.

C'est la loi des conséquences imprévues.

La qualité - bien qu'importante - n'est qu'un petit aspect du logiciel. La fonctionnalité et la valeur créées par le logiciel sont bien plus importantes que la qualité.

Toutes les métriques mènent à une activité pour optimiser la métrique. Cela, à son tour, a des conséquences que vous pourriez ne pas vraiment aimer.

Le logiciel est très complexe. Il est difficile de comprendre à quel point c'est vraiment complexe.

Même des choses "évidentes" comme la couverture du code de test unitaire peuvent perdre du temps. Pour atteindre 100%, il peut être nécessaire de créer des tests qui sont en fait plus complexes que le code trivial testé. Une couverture à 100% peut entraîner un coût inacceptable. [L'alternative au code trivial, petit et rarement utilisé est le test par inspection. Mais cela ne correspond pas au jeu des métriques à 100%.]

Un autre exemple est la complexité cyclomatique. C'est l'une des meilleures mesures de la qualité du code. Mais il peut être joué en créant de nombreuses petites fonctions qui peuvent être plus difficiles à lire (et plus difficiles à maintenir) qu'une fonction plus grande. Vous vous retrouvez dans des revues de code où vous convenez qu'il peut ne pas être très lisible mais qu'il atteint le seuil de complexité.

Je me demande également si c'est une idée dangereuse, que si les procurations objectives de qualité deviennent populaires, les pressions commerciales inciteront les développeurs à poursuivre ces mesures au détriment de la qualité globale (ces aspects de la qualité non mesurés par les procurations).

Bingo, et pas de "si" à ce sujet. C'est ce qu'on appelle "dysfonction de mesure" et a été observé et écrit à plusieurs reprises Joel a écrit un article à ce sujet en 2002 faisant référence à un livre d'un professeur de Harvard.

Cela ne signifie pas que de telles mesures sont inutiles, mais qu'il ne faut jamais baser explicitement les incitations ou les politiques sur de telles mesures de proxy. Si vous souhaitez améliorer la qualité, une métrique proxy avec une très mauvaise valeur est probablement un bon point de départ. Mais vous ne pouvez pas conclure que la qualité est bonne simplement parce que toutes vos mesures ont de grandes valeurs.

Ce qui m'intéresse, c'est une forme plus profonde de qualité liée au réseau (ou graphique) des types et à leur interdépendance, c'est-à-dire à quels types chaque type fait-il référence, existe-t-il des clusters d'interconnectivité clairement identifiables architecture à plusieurs niveaux, ou à l'inverse existe-t-il une grosse «boule» de références de type (code «monolithique»).

Cela ressemble à un fan-in et fan-out. Fan-in compte le nombre de modules qui appellent un module donné et fan-out compte le nombre de modules appelés par un module donné. Un signe d'avertissement à utiliser serait des modules qui ont un grand fan-in et un grand fan-out, car cela pourrait indiquer une mauvaise conception et une cible clé pour la refactorisation ou la refonte.

De plus, la taille de chaque type et / ou méthode (par exemple, mesurée en quantité de code d'octet Java ou .Net IL) devrait donner une indication de l'endroit où de grands algorithmes complexes ont été mis en œuvre sous forme de blocs de code monolithiques au lieu d'être décomposés en plus faciles à gérer / à gérer. morceaux.

Une mesure simple serait des lignes de code. Vous pouvez le décomposer en lignes de code totales sur l'ensemble du projet et en lignes de code par module (peut-être en utilisant des modules de tailles différentes). Vous pouvez l'utiliser comme indicateur d'avertissement indiquant que vous devez examiner des modules particuliers. Un livre sur les mesures et les mesures de la qualité logicielle discute de certains travaux qui indiquent que la relation entre les taux de défauts et la taille des modules est curviligne, où le défaut moyen par KSLOC est fourni avec des modules d'une taille comprise entre 175 et 350 SLOC.

Quelque chose d'un peu plus complexe serait la complexité cyclomatique, qui est conçue pour indiquer la testabilité, la compréhensibilité et la maintenabilité d'un système. La complexité cyclomatique compte le nombre de chemins indépendants à travers une application ou un module. Le nombre de tests, et donc l'effort nécessaire pour produire et exécuter les tests, est fortement lié à la complexité cyclomatique.

Le seuil exact / les points de décision entre la haute et la basse qualité seraient suspects, par exemple, car par maintenabilité, nous entendons la maintenabilité par les programmeurs humains et donc la décomposition fonctionnelle doit être compatible avec la façon dont les esprits humains fonctionnent.

Je ne suis pas sûr que ce soit le cas.

Par exemple, des recherches suggèrent que la mémoire de travail d'un humain ne peut contenir que 7 objets plus / moins 2 . Ceci est probablement intéressant pour mesurer le fan-in et le fan-out - si je travaille dans un module, et qu'il est connecté à plus de ~ 7 autres modules, je ne serai probablement pas en mesure de suivre exactement ce que ceux-ci d'autres modules sont dans ma tête.

Il y a également eu des travaux sur la mise en relation des défauts avec des métriques telles que la complexité cyclomatique. Étant donné que vous souhaitez minimiser les défauts de votre système, vous pouvez identifier les points qui nécessitent davantage de tests d'effort ou de refactorisation, comme identifié par une complexité cyclomatique élevée.

Je me demande également si c'est une idée dangereuse, que si les procurations objectives de qualité deviennent populaires, les pressions commerciales inciteront les développeurs à poursuivre ces mesures au détriment de la qualité globale (ces aspects de la qualité non mesurés par les procurations).

C'est le cas de toutes les mesures ou mesures. Ils doivent être utilisés pour comprendre le système et prendre des décisions éclairées. La phrase «vous ne pouvez pas gérer ce que vous ne pouvez pas mesurer» me vient à l'esprit. Si vous voulez un logiciel de haute qualité, vous avez besoin de quelques mesures et mesures pour évaluer cette qualité. Cependant, il y a un revers à cela. Vous ne pouvez pas gérer exclusivement par les chiffres. Vous pouvez utiliser les chiffres pour prendre des décisions éclairées, mais vous ne pouvez pas prendre une décision uniquement parce que les chiffres le disent.

Il existe des mesures ou des proxys pour bon nombre des qualités qui vous intéressent:

1. Lignes de code
2. Fan in, fan out
3. Taux d'erreur pour 1 000 lignes de code
4. Complexité cyclomatique
5. Couverture de code
6. Couverture du point de décision
7. Ratio d'erreurs corrigées / introduites par les activités de maintenance
8. Analyse des points de fonction

Il y a quelques problèmes avec tous ces éléments:

1. Travail en cours pour optimiser la métrique - une tendance universelle; massivement exacerbé si l'une des mesures est utilisée comme base d'évaluation ou de récompense pour les équipes ou les individus.
2. Je ne connais aucune métrique sans contexte. Cela implique qu'aucune comparaison n'est possible entre les magasins - uniquement au sein des magasins, au fil du temps. Les mesures issues de ces comparaisons sont toujours utiles - "produisons-nous le code plus correctement maintenant qu'il y a un an".

L'effet total de ces problèmes est que des paramètres tels que ceux-ci ne sont susceptibles d'être utiles que dans une culture plus large - comme le TQM, l'assurance qualité (pas le contrôle), l'amélioration continue, le kaizan, etc. Il est nécessaire de définir des éléments à la fois de la culture et comment il doit changer. Si vous en avez une définition, des métriques comme celles-ci deviennent des outils essentiels pour aider à améliorer la qualité du code, les pratiques de travail, la productivité, etc. Sans ce contexte plus large, les métriques généreront du travail pour optimiser la métrique; deviendra l'outil du beancounter pour augmenter la productivité et diminuer les coûts; et deviendra un obstacle à jouer par le personnel de développement.

Vous pourriez être obsédé par les métriques, ou vous pourriez être obsédé par les meilleures personnes, outils, pratiques d'ingénierie et d'assurance qualité que vous pouvez vous permettre. Je serais beaucoup plus heureux d'avoir plusieurs génies paranoïaques de l'assurance qualité qui ont lu "Fooled by Randomness" et qui aiment automatiser qu'un tas de rapports joliment formatés avec des nombres.

Il y a ce problème fondamental avec les mesures.

Presque toutes les métriques proposées se sont révélées, dans le monde réel sur du code réel, être fortement ou très fortement corrélées avec des SLOC bruts (lignes de code source).

C'est ce qui a tué les statistiques de Halstead, dans les années 1970. (Par accident, un jour, vers 1978, j'ai assisté à une conférence d'un nouveau doctorant sur les paramètres de Halstead, dans laquelle il l'a souligné.)

Plus récemment, la complexité cyclomatique de McCabe s'est révélée être très fortement corrélée avec le SLOC brut, au point que le gars qui a fait l'étude se demandait à voix haute si la métrique de McCabe nous disait quelque chose d'utile du tout.

Nous savons depuis des décennies que les grands programmes étaient plus susceptibles d'avoir des problèmes que les petits. Nous savons depuis des décennies que les gros sous-programmes étaient plus susceptibles d'avoir des bugs que les petits. Pourquoi avons-nous besoin de mesures arcaniques pour nous le dire, lorsque regarder quatre pages d'imprimante réparties sur une table devrait être suffisamment convaincant?

Compte tenu de toutes les autres réponses ici, je me sens un peu idiot avec cette petite. Jetez un œil à Crap4j , qui essaie de classer les méthodes en java en fonction de leur puanteur. (Le projet semble abandonné.)

Il utilise une combinaison de complexité cyclomatique et de couverture de test. Comme toutes les autres mesures, il est jouable.