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

9

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

project-management metrics Russ K
la source

Réponses:

6

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.

Tangurena
la source
Merci pour la réponse détaillée et les liens pertinents. À titre de suivi: 1. Pourquoi un gestionnaire se soucierait-il du nombre d'inscriptions? Peut-être que notre définition d'un enregistrement est différente. 2. Que voulez-vous dire par lignes de code étant la pire métrique? Le pire, car il ne donne aucune bonne indication sur le projet?
Russ K
@Russ, un développeur qui n'archive pas le code, sera considéré comme ne fonctionnant pas. LOC est pire en ce qu'il est trivial de jouer. Jetez un œil à la différence entre le style d'indentation K&R et Allman: en.wikipedia.org/wiki/Indent_style . Le style Allman donnera un nombre de LOC plus élevé simplement en mettant l'ouvert {sur une ligne distincte. Avis de non-responsabilité: je déteste le style K&R car je peux rarement trouver le match ouvert {sans passer trop de temps à jouer à Where's Waldo.
Tangurena
In the industrial world, very few companies have any sort of metric measurement program at all.Toute entreprise ayant une cote CMMI de 2 ou plus aura un programme d'analyse des mesures / métriques en place. La collecte de mesures et de métriques est une exigence de niveau de maturité 2. Le niveau de maturité CMMI 4 nécessite une gestion de projet quantitative, basée sur ces mesures et mesures, ainsi que des éléments comme l'analyse des causes profondes pour agir sur les problèmes identifiés. Il existe un grand nombre d'organisations cotées CMMI niveau 4 (ou 5).
Thomas Owens
2

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

Macke
la source
Bien placé. J'ai lu beaucoup d'articles sur la façon dont les mesures seules sont inutiles, comme vous l'avez mentionné, et l'histoire est importante. Merci d'avoir pris le temps de répondre.
Russ K