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

12

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?

redcalx
la source
Je suis d'accord avec S. Lott. Dans la vie, il y a souvent une différence entre «comment ça devrait être» et «comment c'est». Je souhaite que plus de gens sur cette planète aient surmonté leur approche des «bonnes intentions» et regardé attentivement «comment c'est». En plus de mauvaises incitations, il y aura un faux sentiment de sécurité dangereux. Combinez cela avec des gens qui essaient de jouer au système (ce qui est naturel car ils essaient TOUJOURS d'améliorer leurs conditions (monétaires ou autres)), et vous obtenez une situation de merde. Il n'est pas surprenant que les krachs du marché «une fois par millénaire» se produisent une fois toutes les deux décennies.
Job

Réponses:

20

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é.

S.Lott
la source
3
"Toutes les mesures mènent à une activité pour optimiser la mesure." Je pense que c'est trop souvent vrai. Cependant, cela ne devrait pas l'être. Les mesures devraient, comme je l'ai mentionné dans mes derniers paragraphes, guider la gestion. Trop souvent, cependant, les décisions sont prises exclusivement en raison et pour les chiffres, sans comprendre la signification des chiffres et les risques et compromis associés à la décision.
Thomas Owens
3
"Cependant, ça ne devrait pas l'être." Expliquez comment les gens peuvent être invités à ne pas optimiser leurs récompenses. Trouvez un exemple unique de comportement humain où les récompenses culturelles (basées sur toutes sortes de structures sociales folles) ne sont pas primaires, primordiales et la chose la plus importante que les gens poursuivront. Tout ce qui implique «devrait» ou «ne devrait pas» doit être évalué par rapport à ce que les gens font vraiment. Ils optimisent vraiment leurs récompenses. Si les mesures font partie des récompenses, les gens optimisent les mesures. Veuillez ne pas utiliser «devrait» pour décrire les comportements des gens.
S.Lott
2
@Thomas Owens: "Vous n'avez tout simplement aucune récompense à optimiser en fonction des métriques". Ca c'est drôle. Comment allez-vous les garder si secrets? Une fois que j'ai découvert que votre code a été accepté plus tôt que le mien, je veux savoir comment la direction a décidé que votre module était terminé et que le mien ne l'était pas. Une fois que je trouverai la métrique qui "guide" cette décision, je jouerai totalement les métriques pour être fait dès que vous. S'il n'y a pas de métrique que je puisse jouer, alors je verrai que la décision était arbitraire, la direction vous aime mieux que moi, et je quitterai parce qu'il n'y a pas de norme de performance que je puisse percevoir.
S.Lott
2
@Thomas Owens: "Je n'ai jamais vu de métriques conduire à des récompenses". Les incitations culturelles existent dans toutes les situations où deux personnes ou plus travaillent ensemble. "Les individus sont reconnus pour leurs performances". Une métrique de complexité cyclomatique devient un objectif. Si vous atteignez votre objectif de complexité cyclomatique plus rapidement que moi, il y a des récompenses culturelles: vous êtes plus "productif" que moi. Je dois jouer ma métrique de complexité pour apparaître aussi "productif" que vous.
S.Lott
2
@Thomas Owens: "C'est une question de fierté personnelle". C'est un excellent exemple d'un système de récompense culturelle. Les métriques peuvent fausser cela en raison des conséquences inattendues de pouvoir créer une métrique esthétique qui ne correspond pas au bon code. Vous avez fourni un excellent exemple de récompenses culturelles qui peuvent être faussées par des mesures.
S.Lott
4

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.

Michael Borgwardt
la source
3

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.

Thomas Owens
la source
Le problème avec le fan-in / out est qu'il donne deux nombres par module / classe (ou autre) et ignore donc une partie de la structure organisationnelle plus profonde de la façon dont les modules sont connectés. Par exemple, vous pourriez avoir un petit cluster de modules hautement connectés liés à un niveau logique, et vous vous attendriez à ce que les connexions entre les niveaux soient minimales (en comparaison), représentant une interface / un contrat bien défini entre les niveaux. Je pense que nous sommes heureux que certains modules soient fortement connectés (par exemple les méthodes / classes d'assistance couramment utilisées), mais en fonction de la «structure» de la connectivité (c'est mon hypothèse).
redcalx
@locster Vous voudrez probablement l'étendre et noter, par exemple, dans quels packages les classes auxquelles vous êtes connecté se trouvent. classes en dehors de mon package, ou classes Z dans ce package particulier. Si vous voyez un déploiement entre les modules de votre modèle de données et les modules de votre interface utilisateur, cela pourrait être un indicateur d'un problème. Vous devez creuser un peu plus profondément que les chiffres bruts.
Thomas Owens
3

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.

Chris Walton
la source
2

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.

Emploi
la source
+1 pour la référence du livre Nassim Taleb. Le raisonnement / l'épistémologie imparfait étant sur la chaîne de causalité pour la faible qualité.
redcalx
@locster, votre commentaire m'a fait penser à l'opérateur du pipeline F # :). Vous commencez par «Nassim Taleb livre reference» mais terminez par «chaîne de causalité pour faible qualité» (au lieu de «chaîne de causalité de faible qualité»). Tout comme en anglais, nous aimons parfois avoir deux façons de dire les choses, nous pourrions préférer cela dans un langage de programmation aussi.
Job
1

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?

John R. Strohm
la source
Pour être maintenable, nous avons besoin que le code soit en morceaux humains, donc une métrique SLOC semble assez bonne de ce point de vue. Cependant, pour une taille donnée, vous pourriez avoir un nombre variable de chemins uniques (selon la complexité cyclomatique) et je dirais que plus de chemins est un proxy pour moins facilement compréhensible. Par conséquent, je dirais que CC ajoute probablement / une / valeur supplémentaire au SLOC, tant que vous autorisez une certaine flexibilité, des exceptions à la règle, etc. Autrement dit, n'appliquez pas strictement CC.limits / objectifs.
redcalx
1
@locster: Étant donné deux modules 100 SLOC, un avec un CC de 47 est susceptible d'avoir plus de problèmes qu'un avec un CC de 3. Cependant, pour le code du monde réel, en grande quantité, on constate que les modules courts ont tendance à avoir un faible CC et les modules longs ont tendance à avoir un CC élevé, au point que connaître le SLOC vous donne une très bonne idée du CC, et vice versa. C'est ce que l'on entend par «très fortement corrélé». COMME TEL, sur du code réel, tout avantage que vous obtenez en remarquant CC = 47 est PLUS FACILEMENT obtenu en remarquant SLOC = 1500. (Les nombres sont tirés au hasard, le principe est le même.)
John R. Strohm
Oui, je suis d'accord qu'ils auront tendance à être fortement corrélés, bien que la relation soit généralement non linéaire. Par exemple, un score CC est à peu près LOC élevé à une certaine puissance. Donc, d'un point de vue psychologique, le score CC peut devenir très grand très rapidement, tandis que le score SLOC associé semble juste «un peu plus élevé». Oui, je sais que je m'accroche aux pailles ici :)
redcalx
@locster: Je fais cela depuis plus de 30 ans. Ces jours-ci, je vois régulièrement des routines de flux de conscience, qui continuent indéfiniment pendant quelques centaines de SLOC, sans raison. Au cours de toutes ces années, j'ai vu exactement une (1) routine qui avait réellement besoin de plus d'une page de code d'imprimante (environ 60 lignes). Tout le reste aurait pu être pris en compte de manière assez rentable, et la lisibilité et la fiabilité ont considérablement augmenté. (Cela ne compte pas les grosses machines d'état. Elles peuvent être un problème dans ce domaine, mais elles sont RARES.)
John R. Strohm
-2

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.

Sean McMillan
la source