La mesure des métriques de projet logiciel est-elle populaire dans l'industrie d'aujourd'hui?

J'ai rencontré un développeur qui voulait des conseils extérieurs sur le projet de ses équipes. J'ai découvert qu'ils développaient une énorme suite logicielle pour les dirigeants d'entreprises, le chef de projet et les développeurs qui peuvent calculer automatiquement les mesures et les représenter graphiquement par itération.

En tant qu'étudiant issu d'une formation en informatique, je connais très peu les mesures et leur importance, mais mes questions sont les suivantes:

1. La plupart des entreprises ont-elles un moyen, pas nécessairement un programme élégant, pour mesurer des paramètres significatifs?
2. Quelles mesures, uniques ou combinées, vous aident à réduire la portée et les estimations de vos projets?
3. En tant que personne qui analyse les métriques, à quelle fréquence basez-vous vos décisions? C'EST À DIRE. Les tests échoués par semaine augmentent considérablement?
4. Pensez-vous que l'introduction de l'étude des métriques vous a aidé à mieux comprendre le projet?

Je ne sais pas pourquoi mais le projet des développeurs m'a intrigué et je dois en savoir plus. Si y

Certains livres sur les métriques que votre bibliothèque universitaire a probablement incluent des métriques logicielles et des métriques et des modèles en ingénierie de la qualité logicielle . Ces 2 devraient vous donner un point de départ. Dans le monde industriel, très peu d'entreprises ont un programme de mesure métrique.

La plupart des entreprises ont-elles un moyen, pas nécessairement un programme élégant, pour mesurer des paramètres significatifs?

Visual Studio comprend des outils d'analyse de code qui peuvent vous aider à démarrer. La plupart des entreprises n'ont même pas quelque chose pour mesurer la pire mesure possible: des lignes de code. «Il suffit de faire les choses» semble être la force motrice écrasante de l'industrie, et les préoccupations de maintenabilité sont très peu prises en compte par les gestionnaires: «vais-je recevoir ma prime cette année? et "cela se fera-t-il dans le temps que j'ai promis?" Même avec des produits qui se prolongent d'année en année avec des changements incrémentiels, ces 2 préoccupations ont éclipsé les préoccupations des développeurs concernant la maintenabilité et la détection / prévention des bogues.

Quelles mesures, uniques ou combinées, vous aident à réduire la portée et les estimations de vos projets?

Je trouve que la complexité cyclomatique et le couplage sont de bons indicateurs de la façon dont le buggy ou la difficulté de maintenir le code seront. Si la complexité cyclomatique est d'environ 20, je trouve qu'il sera presque impossible de tester (car il aura jusqu'à 2 ^ 20 chemins à travers le code) et devrait être décomposé en morceaux plus petits. Vous ne pouvez pas éliminer la complexité, mais vous pouvez la découper en morceaux plus faciles à gérer.

Si vous recherchez une estimation , vous voudrez probablement étudier les points de fonction .

Le% de couverture de code réduit considérablement chaque itération, alertez-vous vos développeurs du problème

Je trouve que la plupart des gestionnaires se soucient du nombre de check-ins et du nombre de bugs corrigés. Mon manager actuel est opposé aux tests unitaires (il pense que c'est une perte de temps) et mon manager précédent a estimé que le temps passé sur les tests unitaires était du temps qui aurait dû être consacré à l'écrire en premier lieu.

L'argument canonique utilisé par les développeurs est que si vous mesurez quelque chose, c'est seulement ce que vous obtiendrez. Cet argument vient de l'idée que la seule métrique est les lignes de code.

J'étais à une discussion sur les métriques logicielles où l'orateur a fait des remarques perspicaces, à mon humble avis. Ayant peu d'expérience avec ces choses moi-même, j'étais toujours intrigué et inspiré, mais je ne peux pas dire si c'est mal ou bien.

Les idées principales étaient:

• Aucune métrique singulière n'est utile en soi.
• La définition d'un objectif absolu (c'est-à-dire une couverture de code de XX%) n'a pas de sens.
• Une métrique sans historique est utile.

Donc, pour résoudre ce problème:

• Afficher plusieurs mesures, telles que:
  • Nombre de lignes total / modifié
  • Nombre de validations
  • % couverture de code
  • Nombre de tests
  • complexité cyclomatique
  • fichier / package / ... dépendance
  • ...
• Afficher les données de QA / CI:
  
  • # de bugs / améliorations / changements (je pense personnellement que cette catégorisation est importante)
  • # total / ajouté / fixe
• Affichez ces mesures sur des graphiques qui montrent les tendances au fil du temps

De cette façon, lorsque les tickets sont fixés rapidement, on peut voir si la qualité du code baisse. De plus, lorsque peu de choses semblent se produire avec la base de données de bogues, la qualité du code peut augmenter, car des refactorisations sont en cours.

Pour résumer: c'est ce type de comportement dynamique qui est important et qui vous donne des informations plutôt que des données brutes (qui seraient la valeur d'une seule métrique).

Je prévois de mettre des graphiques selon ce schéma sur un téléviseur grand écran à côté de nos lampes à lave connectées CI. ;)