Comment savoir si un logiciel est bon ou mauvais sur la base de mesures empiriques?

On me demande actuellement d'examiner un projet qui a terminé le développement principal il y a cinq mois, mais qui présente toujours un niveau élevé de défauts. Ce qui se passe pour environ 10 défauts résolus, nous relevons au moins 4 et dans certains cas 8 défauts.

Je crois que les pratiques de codage chez le fournisseur sont médiocres et il y a un accord général à ce sujet. Cependant, je me demande s'il y a un problème structurel avec le logiciel? La densité des défauts est une mesure utile, mais plus si le logiciel de base est mal écrit, alors tout ce que fait le vendeur est de déplacer le problème.

Dans l'infrastructure, il est plus défini si quelque chose est mal construit, quelles mesures pouvez-vous utiliser pour le logiciel à côté des défauts par LOC?

Le produit est en phase de réparation des défauts depuis 4 mois et n'a toujours pas résolu suffisamment de défauts critiques. Nous n'injectons pas de nouvelles fonctionnalités, nous résolvons simplement les problèmes de régression.

Cela indique un problème de qualité de développement, qui n'est pas satisfait. Cependant, si le produit lui-même est fondamentalement défectueux, c'est un problème différent. Le problème étant que la base de code principale a été mal écrite et que la documentation est limitée, tous les développeurs externes font passer le problème de A à B. Une fois que les équipes de développement internes prendront le relais, je crains de devoir fondamentalement réécrire le code dans le rendre fonctionnel.

Ainsi, lorsque vous acceptez un produit d'un tiers et que vous êtes invité à le soutenir, quels critères d'acceptation utiliseriez-vous pour définir des normes?

En plus de demander à notre développeur principal de faire un examen par les pairs du code par version, vous ne savez pas quoi faire d'autre?

Non.

La qualité du logiciel est vraiment difficile à mesurer objectivement. Assez dur pour qu'il n'y ait pas de solution. Je m'abstiens dans cette réponse de m'attarder sur la question de savoir s'il peut y avoir une solution, mais simplement de souligner pourquoi il serait vraiment difficile d'en définir une.

Raisonnement par statu quo

Comme Kilian Foth l'a souligné, s'il existait une mesure simple pour un "bon" logiciel, nous l'utilisions tous et tout le monde l'exigerait.

Il existe des projets dans lesquels les gestionnaires ont décidé d'appliquer certaines mesures. Parfois cela a fonctionné, parfois non. Je n'ai connaissance d'aucune corrélation significative. Les logiciels de systèmes particulièrement critiques (pensez aux avions, aux voitures, etc.) ont beaucoup d'exigences de métriques pour "assurer" la qualité SW - Je ne connais aucune étude montrant que ces exigences se traduisent réellement par une qualité supérieure, et j'ai une expérience personnelle de la contraire.

Raisonnement par contre-espionnage

Déjà évoqué par Kilian, et plus généralement formulé comme "chaque métrique peut et sera jouée".

Que signifie jouer une métrique? C'est un jeu amusant pour les développeurs: vous vous assurez que les valeurs métriques sont vraiment bonnes, tout en faisant des trucs vraiment merdiques.

Disons que vous mesurez les défauts par LOC. Comment vais-je jouer ça? Facile - ajoutez simplement plus de code! Créez un code stupide qui entraîne une non-opération sur 100 lignes et tout à coup, vous avez moins de défauts par LOC. Le meilleur de tous: vous avez en fait diminué la qualité du logiciel de cette façon.

Les lacunes des outils sont abusées, les définitions sont étirées à leur maximum, des façons complètement nouvelles sont inventées ... en gros, les développeurs sont vraiment des gens intelligents et si vous n'avez qu'un seul développeur dans votre équipe qui s'amuse à jouer des métriques, alors vos métriques seront discutables.

Cela ne veut pas dire que les métriques sont toujours mauvaises - mais l'attitude de l'équipe envers ces métriques est cruciale. En particulier, cela implique que cela ne fonctionnera pas bien pour une relation de sous-traitant / fournisseur tiers.

Raisonnement par mauvais ciblage

Ce que vous voulez mesurer, c'est la qualité du logiciel. Ce que vous mesurez, c'est une ou plusieurs mesures.

Il y a un écart entre ce que vous mesurez et ce que vous pensez que cela vous dira. Cet écart est même énorme.

Cela arrive tout le temps dans toutes sortes d'entreprises autour de nous. Avez-vous déjà vu des décisions basées sur des KPI (indicateurs clés de performance)? C'est juste le même problème - vous voulez qu'une entreprise se porte bien, mais vous mesurez autre chose.

Raisonnement par quantifiabilité

Les métriques peuvent être mesurées. C'est la seule raison pour laquelle nous traitons avec eux. La qualité des logiciels, cependant, va bien au-delà de ces entités mesurables et a beaucoup de choses très difficiles à quantifier: dans quelle mesure le code source est-il lisible? Dans quelle mesure votre conception est-elle extensible? À quel point est-il difficile pour les nouveaux membres de l'équipe de s'engager? etc.

Ne juger la qualité d'un logiciel que par des mesures et fermer les yeux sur les éléments de qualité que vous ne pouvez pas quantifier ne fonctionnera certainement pas bien.

Éditer:

Sommaire

Permettez-moi de souligner que ce qui précède consiste à juger objectivement si un logiciel est bon ou mauvais en fonction de mesures. Cela signifie qu'il ne dit rien sur la question de savoir si et quand vous devez appliquer des mesures.

En fait, c'est une implication unidirectionnelle: de mauvaises métriques impliquent un mauvais code. Unidirectionnel signifie qu'un mauvais code ne garantit pas de mauvaises mesures, pas plus que de bonnes mesures ne garantissent un bon code. D'un autre côté, cela signifie en soi que vous pouvez appliquer des mesures pour juger un logiciel - lorsque vous gardez cette implication à l'esprit.

Vous mesurez le logiciel A et les mesures s'avèrent vraiment mauvaises. Vous pouvez alors être certain que la qualité du code est mauvaise. Vous mesurez le logiciel B et les mesures sont correctes, alors vous n'avez aucune idée de la qualité du code. Ne vous laissez pas berner en pensant que "metrics good = code good" quand c'est vraiment juste "code good => metrics good".

En substance, vous pouvez utiliser des métriques pour trouver des problèmes de qualité, mais pas la qualité elle-même.

Oui, vous pouvez dire que le code a des problèmes de qualité en examinant les mesures dans une certaine mesure.

Plus précisément, exécutez un outil d'analyse de complexité sur la base de code et vous aurez une idée de si le code est bon ou mauvais.

Par exemple, vous pouvez exécuter le moniteur source .

Ce que cela vous dira, c'est la complexité du code. Je peux vous dire que tous les systèmes problématiques que j'ai rencontrés avaient de mauvais chiffres. Complexité sur 10s à 100s des méthodes bien au-dessus des limites acceptables. Des chiffres terribles. Terrible complexité, imbrication, profondeur, etc. Cela entraînera beaucoup de problèmes, un taux de défaut élevé et constant, des changements difficiles à réaliser, sans casser autre chose, etc.

Une autre chose est les défauts. Au fil du temps, le système devrait se stabiliser. Idéalement, les nouveaux défauts devraient tendre vers zéro ou s'aplanir à un faible nombre, ce qui signifie que les défauts nouveaux et actuels devraient diminuer avec le temps.

L'intrigue devrait ressembler à ceci:

Défauts au fil du temps

S'ils restent constants ou augmentent, le logiciel n'est pas bon. Vos 4 mois seulement, donc je lui donnerais encore quelques mois à un an. Après 6 mois à un an, si vous aviez un flux constant de défauts, alors c'est de mauvaise qualité. Votre équipe a développé une autre boule de boue .

Prochains tests. Est-ce que tu les as? Si non, alors moins de qualité, plus de bugs, plus de churn. Si vous les avez, des mesures telles que la couverture du code sont bonnes pour avoir une idée de la quantité de code couverte, mais elles ne mesureront pas la qualité . J'ai vu d'excellents chiffres de couverture de code, mais les tests réels étaient de la merde. Ils ne testaient aucun comportement ou fonctionnalité du système. Les développeurs venaient de les écrire pour améliorer les numéros de mesure pour la gestion. Il faut donc passer des tests et ils doivent être bons. Les mesures de couverture de code en elles-mêmes ne sont pas un indicateur de qualité.

Revues de code, les effectuez-vous? Sinon, moins de qualité. Ceci est particulièrement important avec les développeurs juniors. Si vous êtes agile, ajoutez simplement une tâche de révision de code à votre histoire appelée "révision de code". Si la direction veut suivre les chiffres, vous aurez besoin d'un outil qui suit les critiques comme Crucible . Je pense que les numéros de révision de code ou les métriques ne sont pas si importants ici, à part le fait qu'ils devraient faire partie de votre processus. Tous les enregistrements ne nécessitent pas d'examen. Mais les revues peuvent aider à s'assurer que les gens ne réinventent pas la roue ou n'écrivent pas de code que les autres ne peuvent pas comprendre et / ou maintenir.

Enfin, il vous suffira d'évaluer le code, aucune métrique ne vous aidera. Chaque projet de code problématique avait ces qualités:

• Structures de données médiocres. Tout est une chaîne, ou XML est transmis partout et analysé partout, des objets divins, ou des structures de données inutilement complexes ou génériques, pas de modèle de domaine.
• Manque d'organisation ou de structure, tout projet non trivial devrait avoir une division ou une superposition qui sépare la logique. Jetez un oeil ici ... Si vous ne voyez pas ce type d'organisation ou de séparation (mélange de logique partout) alors le système sera plus difficile à maintenir et à comprendre.
• Au-dessus des abstractions. Parfois, l'inverse est vrai, le système est trop abstrait. Si tout est une interface et une classe abstraite, ou si vous devez naviguer à travers une tonne de classes de type "wrapper" de classe, la qualité sera mauvaise car les nouveaux développeurs ne pourront pas naviguer à travers le ballonnement d'objet.
• Code difficile à comprendre. Si vous êtes un développeur chevronné et que vous regardez un code difficile à comprendre, il y aura des problèmes de qualité. Ma métrique personnelle est que si je regarde du code et qu'il est difficile de le suivre ou me fait me sentir stupide, ou j'ai l'impression de perdre beaucoup de cycles cérébraux pour comprendre la logique, alors c'est du mauvais code. Si les développeurs chevronnés ont du mal à suivre, alors imaginez ce que ce sera pour les nouveaux développeurs. Ils introduiront des problèmes.

Mon conseil serait de faire une analyse de complexité sur le code. Ne partagez pas les résultats, au lieu de cela, effectuez une enquête indépendante (regardez le code) et déterminez la santé globale de la base de code. À partir de cela, formez un plan d'action et essayez de corriger certaines des zones complexes du code.

Ce qui est triste avec les métriques, c'est que vous pouvez finir par améliorer les valeurs résultantes de vos métriques, mais pas la qualité destinée à être mesurée par elles ...

Dans Visual Studio, il existe un paramètre pour traiter les avertissements du compilateur comme des erreurs. Maintenant, certaines personnes ne comprennent pas les avertissements et, pour obtenir le code compilé, utiliseront des astuces simples (comme «avertissement de désactivation de programme» ou ajout d'un mot clé «nouveau» à une fonction / propriété masquant un membre non virtuel d'une base classe).

Si vous avez accès au code source, vous pouvez exécuter une analyse de code statique. Pour les projets .Net, vous pouvez utiliser par exemple FxCop ou ReSharper InspectCode. Lorsqu'ils sont utilisés correctement par l'équipe de développement, les outils aideront à améliorer la qualité. Mais bien sûr, certains "correctifs" pour supprimer les avertissements sans les comprendre sont possibles.

Vous pouvez regarder les tests automatisés / UnitTests: quelle est la couverture du code? Mais la couverture à elle seule ne vous dira pas si les tests vérifient réellement le code, ou s'ils l'ont simplement exécuté une fois.

La recherche de la haute qualité est une attitude qui peut être soutenue par de nombreux outils et leurs métriques, mais les métriques sans l'attitude des développeurs n'aident pas.

Une chose que vous devriez regarder en plus de collecter une métrique comme l'injection de défauts est de déterminer la source des défauts. Elle est souvent liée à la spécification.

Fondamentalement, c'est une erreur dans la spécification, une ambiguïté dans la spécification, laissée aux implants pour décider ou est-ce un bug dans l'implémentation.

Une approche plus qualitative consiste à se demander si le logiciel est utile? Si vous regardez bien, vous pouvez trouver des défauts dans n'importe quel logiciel. Cependant, si cela fonctionne assez bien pour gagner de l'argent, ce ne sera peut-être pas si mal.

En bas, il n'y a aucun moyen de savoir.

Pour la question d'origine (avant la réponse philosophique): qu'est-ce que le produit est censé faire et le fait-il? La mesure par nombre / densité de défauts n'est pas suffisante. Je ne pouvais pas dire s'il s'agissait d'une bibliothèque ou d'une application, de la taille de la base de code, de la taille du domaine problématique ni de la gravité des défauts. Par exemple, le fait de ne pas gérer l'un des 123 formats d'entrée pourrait être un défaut trivial ou un bouchon de présentation, selon l'importance du format qui n'est pas correctement géré. Et mieux que rien est un standard élevé.

Hypothèse que je fais pour cette question: il y a une différence entre le code et le logiciel. Je définis le logiciel comme ce qu'un client / utilisateur utilise pour résoudre un problème, alors que le code est le matériau de construction du logiciel.

Le logiciel ne peut être mesuré que subjectivement. Autrement dit, la métrique qui importe pour les logiciels est de savoir si les gens l'utilisent pour résoudre un problème. Cette métrique dépend du comportement des autres, d'où sa subjectivité. Remarque: Pour certains problèmes, un logiciel peut être très utile et donc considéré comme de haute qualité (Excel pour les calculs), mais pas comme un logiciel de qualité pour un problème différent (Excel pour la lecture de fichiers MP3).

Le code peut (généralement) être mesuré avec des métriques empiriques . Mais l'interprétation n'est pas «oui / non» pour la qualité, ni même vraiment sur une échelle de «0 à N». Les mesures sont mesurées par rapport à une norme. Ainsi, les métriques peuvent trouver des domaines de préoccupation définis par la norme, mais l'absence de domaines de préoccupation n'est pas la preuve qu'il s'agit d'un code de qualité. Par exemple, des métriques utiles: Compile-t-il? Non -> Pas de qualité. Oui -> ???. Répond-il au test unitaire? Non? Peut être? (parce que le code de qualité du test unitaire est-il?), Oui -> ???.

Donc, comme l'a montré la preuve d'incomplétude de Godel pour les axiomes des mathématiques (c'est-à-dire qu'il existe des déclarations mathématiques qui ne peuvent pas être prouvées vraies ou fausses pour un ensemble fini d'axiomes), je ne pense pas que nous pourrions jamais réellement répondre '' est-ce que cette qualité code?' pour chaque morceau de code. Intuitivement, il y a probablement une correspondance entre les métriques logicielles pour répondre à la qualité et les axiomes mathématiques pour répondre comme vrais ou faux.

Une autre façon de faire valoir cet argument consiste à entrer dans le langage naturel. William Shakespeare, Lewis Carroll et Mark Twain étaient tous des écrivains à succès, et aimés de beaucoup pour la qualité de leurs écrits. Pourtant, quelle norme de grammaire, de vocabulaire, de style ou de voix pourrions-nous appliquer pour les classer systématiquement plus haut que les élèves de 12e année choisis au hasard? Et, alors qu'il peut être possible de créer une mesure synthétique pour ces trois, comment évalueriez-vous le Livre de Jean (KJV), JRR Tolkien, Homer, Cervantes, etc.? Ajoutez ensuite Burroughs, Faulkner, Hemingway, Sylvia Plath, etc. La métrique ne fonctionnera pas.

Je mesurerais cela en vérifiant (et en recherchant les écarts dans) leur processus.

Je chercherais des preuves d'un processus à livrer qui impliquait un contrôle de source central, un système de construction central et un processus qui garantissait que le code était testé avant l'intégration dans la branche publiée.

Je chercherais également des preuves de la façon dont ils ont modifié leurs processus en réponse à des situations où des défauts ont traversé leur processus de publication.

S'ils ne parviennent pas à passer ce niveau d'audit, vous ne pouvez pas vous attendre à ce qu'ils fournissent des versions fiables et cohérentes.

S'ils réussissent cet audit et améliorent continuellement leur processus, la cohérence de leurs résultats s'améliorera probablement avec le temps.

Si cela ne le résout pas, il est probable qu'ils aient un problème d'architecture de code qui rend l'extension et le test de leur base de code actuelle problématique, auquel cas il n'y a pas de bonnes options.

Si vous recherchez des mesures entièrement automatisées, je recommande ces types: Software Improvement Group

Il s'agit essentiellement d'un agrégat de diverses métriques qui peuvent être automatiquement extraites du code source (comme, la couverture des tests unitaires, la taille de la fonction, l'intrication de classe, la duplication, LOC, etc.). Ces valeurs sont ensuite converties en 1 à 5 étoiles.

Ils ont également un livre décent décrivant toutes leurs mesures dans la pratique qui vaut la peine d'être lu: «Construire un logiciel maintenable» .