Concept: Métriques
Les métriques correspondent aux nombres utilisés comme mesure des normes de qualité pour la comparaison d'éléments ou de périodes différents.
Relations
Eléments connexes
Description principale

Pourquoi mesurer ?

Nous procédons à des mesures principalement pour prendre le contrôle d'un projet et donc pour être en mesure de le gérer. Ces mesures nous permettent d'évaluer où nous nous situons par rapport aux objectifs définis dans notre plan, en termes d'avancement, de qualité, de conformité aux exigences, etc.

Nous procédons aussi à des mesures afin de pouvoir mieux estimer l'effort, le coût et la qualité des nouveaux projets, en nous appuyant sur l'expérience acquise. Pour finir, nous effectuons des mesures afin d'évaluer la manière dont nous pourrions améliorer certains aspects clés des performances du processus dans le temps, afin de voir quels sont les effets des changements.

Mesurer certains aspects clés d'un projet induit des coûts non négligeables. Nous ne mesurons donc pas n'importe quel facteur sur le simple postulat que nous pouvons le faire. Nous devons définir des objectifs très précis pour cet effort et ne rassembler que les mesures qui nous permettent d'atteindre ces objectifs.

Il existe deux types d'objectifs :

  1. Objectifs de la gestion des connaissances : ils sont exprimés à l'aide de verbes tels que évaluer, prévoir, surveiller. Il est utile de mieux comprendre votre processus de développement. Par exemple, vous pouvez être amené à évaluer la qualité du produit, obtenir des données afin de prévoir l'effort de test, surveiller la couverture de test ou suivre les changements apportés aux exigences.
  2. Les objectifs de changement ou de réalisation : ils sont exprimés à l'aide de verbes tels que augmenter, réduire, améliorer ou réaliser. Vous voulez généralement savoir comment les choses changent ou s'améliorent au cours du temps, d'une itération à l'autre, d'un projet à l'autre.

Exemples :

  • Surveiller l'avancement par rapport au plan
  • Améliorer la satisfaction client
  • Améliorer la productivité
  • Améliorer la prévisibilité
  • Augmenter la réutilisation

Ces objectifs de gestion généraux ne se traduisent pas facilement en mesures. Il nous faut les traduire en des sous-objectifs plus petits (ou objectifs d'action) qui identifient les actions que les membres du projet doivent entreprendre pour atteindre l'objectif. Il convient également de s'assurer que les personnes impliquées comprennent les avantages.

Exemples

L'objectif d'« amélioration de la satisfaction client » se décomposerait comme suit :

  • Définir la satisfaction client
  • Mesurer la satisfaction client, sur plusieurs éditions
  • Vérifier que la satisfaction augmente

L'objectif d'« augmentation de la productivité » se décomposerait comme suit :

  • Mesurer l'effort
  • Mesurer l'avancement
  • Calculer la productivité sur plusieurs itérations ou projets
  • Comparer les résultats

Certains des sous-objectifs (mais pas tous) imposeraient ensuite de collecter certaines mesures.

Exemple

« Mesurer la satisfaction client » peut découler de

  • Sondage client (dans le cadre duquel le client donne des notes aux différents aspects)
  • Nombre et gravité des appels reçus par le numéro d'urgence d'assistance client.

Pour plus d'informations, consultez [AMI95].

Nous vous conseillons d'organiser ces objectifs par organisation, par projet et par besoin technique. Vous obtenez ainsi un cadre pour l'amélioration évoquée ci-dessus.

Besoins d'une organisation en termes de mesures

Une organisation a besoin de connaître (et éventuellement d'améliorer) ses coûts unitaires, de raccourcir ses phases de modélisation (délais de commercialisation) tout en fournissant des produits d'une qualité connue (objective et subjective) et en répondant aux exigences en matière de maintenance. Une organisation peut, de temps en temps (ou même en permanence), avoir besoin d'améliorer ses performances pour rester compétitive. Pour réduire les risques, une entreprise doit connaître le niveau de compétences et d'expérience de son personnel, et s'assurer qu'elle dispose des autres ressources et capacités pour se montrer concurrentielle dans le domaine qu'elle a choisi. Une organisation doit être en mesure de mettre en place de nouvelles technologies et de déterminer le rapport coût-avantages de cette technologie. Le tableau suivant répertorie quelques exemples des types de mesures qui sont pertinents pour ces besoins, pour une organisation de développement d'application.

Facteur

Métrique

Coût unitaire Coût par ligne de code, coût par point de fonction, coût par cas d'utilisation. Effort normalisé (sur une partie définie du cycle de développement, du langage de programmation, d'une classe de personnel, etc.) par ligne de code, point de fonction ou cas d'utilisation. Il est à noter que ces mesures ne sont généralement pas de simples nombres - elles dépendent de la taille du système à livrer et de la souplesse du calendrier.
Temps de construction Temps écoulé par ligne de code ou par point de fonction. Il est à noter que ce facteur dépend également de la taille du système. Le calendrier peut aussi être raccourci par l'ajout de personnel, mais jusqu'à un certain point seulement. La capacité de gestion d'une organisation détermine exactement où se situe la limite.
Densité des anomalies dans le produit livré Anomalies (découvertes après la livraison) par ligne de code ou par point de fonction.
Qualité subjective Facilité d'utilisation, acceptation du produit par le client. Bien que ces paramètres soient flous, des méthodes permettant d'essayer de les quantifier ont été élaborées.
Facilité de maintenance Coût annuel par ligne de code ou par point de fonction.
Profil de compétences, profil d'expérience Il est fort à parier que le service des ressources humaines possède, sous une forme ou une autre, une base de données recensant les compétences et les expériences.
Capacités technologiques
  • Outils - une organisation doit savoir quels outils sont utilisés de manière universelle et quel est le niveau d'expertise requis pour ceux qui ne sont pas utilisés de manière régulière.
  • Maturité du processus - où l'organisation se situe-t-elle sur l'échelle du modèle CMM du Software Engineering Institute (SEI), par exemple ?
  • Capacité dans le domaine - dans quels domaines d'applications l'organisation est-elle en mesure de se montrer performante ?
Mesures d'amélioration du processus
  • Effort et temps d'exécution du processus.
  • Taux d'anomalies, statistiques d'analyse causale, taux de résolution des problèmes, déchets et éléments retravaillés.

Besoins du projet en termes de mesures

Un projet doit répondre aux critères suivants avant d'être livré :

  • capacités fonctionnelles et non fonctionnelles obligatoires
  • contraintes techniques diverses
  • contraintes budgétaires et liées au calendrier
  • certaines caractéristiques de transition, opérationnelles ou de maintenance

Le responsable de projet doit pouvoir voir s'il s'oriente bien vers ces objectifs, qui sont développés dans le tableau suivant afin de donner une idée des éléments à envisager lorsque l'on réfléchit aux mesures liées au projet :

Facteur

Effort et budget liés au projet
  • Comment le projet évolue-t-il en termes d'effort et de coût par rapport au plan ?
Calendrier du projet
  • Le projet atteint-il ses jalons ?
Transition/Installation
  • Les exigences en termes d'effort, de coût et de compétences sont-elles raisonnables ?
Fonctionnement
  • Les exigences prévisionnelles en matière d'effort et de compétences sont-elles supportables par le client ?
Maintenance/Facilité de prise en charge
  • Les exigences prévisionnelles en matière d'effort et de compétences sont-elles acceptables pour le client ?
Exigences fonctionnelles
  • Les exigences sont-elles valables et complètes ?
  • Les exigences sont-elles allouées à une itération ?
  • Les exigences sont-elles réalisées conformément au plan ?
Exigences non fonctionnelles
  • Performances
    • Le système répond-il aux exigences en matière de temps de réponse, de rendement et de temps de reprise ?
  • Capacité
    • Le système peut-il gérer le nombre d'utilisateurs simultanés requis ? Le site Web peut-il gérer le nombre de consultations par seconde requis ? L'espace de stockage des enregistrements clients requis est-il suffisant ?
  • Facteurs de qualité
    • Fiabilité : quelle est la fréquence tolérée des incidents système et que constitue un incident système ?
    • Convivialité : le système est-il facile et plaisant à utiliser ? Combien de temps cela prend-il pour apprendre à s'en servir et quelles sont les compétences nécessaires ?
    • Tolérance aux pannes/robustesse/résilience/tenue : le système peut-il continuer à fonctionner en cas d'échec ? Le système peut-il gérer les entrées invalides ? Le système est-il capable d'opérer une reprise sur incident automatique après un arrêt anormal ?
  • Exigences d'ingénierie spécialisées
    • Sécurité : le système peut-il fonctionner sans présenter de risques pour les biens ou les personnes (tangibles et intangibles) ?
    • Sécurité/confidentialité : le système protège-t-il les données sensibles contre tout accès non autorisé ? Le système est-il protégé contre les accès malveillants ?
    • Impact sur l'environnement : le système répond-il aux critères environnementaux ?
  • Autres exigences réglementaires ou légales
  • Contraintes
    • Environnement externe : le système est-il capable de fonctionner dans l'environnement recommandé ?
    • Ressources, hôte, cible : le système répond-il à ses contraintes en matière d'UC, de mémoire, de langage, d'environnement matériel/logiciel ?
    • Utilisation de logiciels commerciaux (COTS) ou autres logiciels existants : le système répond-il à ses contraintes en matière de réutilisation ?
    • Disponibilité et compétences du personnel : le système peut-il être généré, avec le nombre et le type d'employés disponibles ?
    • Prise en charge/compatibilité de l'interface : le système peut-il prendre en charge l'accès nécessaire à ou depuis d'autres systèmes ?
    • Réutilisabilité : qu'est-il prévu afin d'assurer la réutilisabilité du système ?
    • Normes imposées : le système et la méthode de développement sont-ils conformes ?
    • Autres contraintes de conception (architecturales ou algorithmiques, par exemple) :  le système fait-il appel au style architectural requis ? Les algorithmes recommandés sont-ils utilisés ?

Voici donc une liste détaillée, mais non exhaustive, des facteurs dont le responsable de projet doit tenir compte. Nombre de ces facteurs nécessiteront de collecter et d'analyser des mesures, d'autres nécessiteront également de développer des tests spécifiques (permettant de déduire des mesures) afin de répondre aux questions posées.

Besoins techniques en mesures

Un grand nombre des besoins du projet ne disposeront pas de mesures directes, et même pour ceux qui en disposent, il peut ne pas être aisé de déterminer ce qu'il convient de faire ou de changer pour les améliorer. Les attributs de niveau inférieur porteurs de qualité peuvent être utilisés pour accroître la qualité par rapport à divers attributs de qualité de niveau supérieur tels que ceux identifiés dans la norme ISO 9126 (caractéristiques et mesure de la qualité des logiciels) et ceux mentionnés ci-dessus dans les besoins liés au projet. Ces mesures techniques ont des caractéristiques (structurelles et comportementales) d'ingénierie et des effets d'ingénierie (couvrant le processus et le produit), qui contribuent aux besoins en termes de mesures au niveau du projet. Les attributs du tableau ci-dessous ont été utilisés pour dériver un échantillon de mesures pour les produits et le processus RUP. Il est possible de les consulter dans Instructions relatives au produit : Métriques.

Qualité

Attributs

Qualité des exigences
  • Volatilité : fréquence des changements, fréquence de mise en place de nouvelles exigences
  • Validité : s'agit-il des bonnes exigences ?
  • Exhaustivité : manque-t-il certaines exigences ?
  • Exactitude de l'expression : les exigences sont-elles correctement formulées ?
  • Clarté : les descriptions sont-elles compréhensibles et dépourvues de toute ambiguïté ?
Qualité de la conception
  • Couplage :  quelle est l'étendue des connexions entre les éléments du système ?
  • Cohésion : les composants ont-ils tous une finalité unique et bien définie ?
  • Caractère primitif : les méthodes ou les opérations d'une classe peuvent-elles être construites à partir d'autres méthodes ou opérations de cette classe ? Si tel est le cas, elles ne sont pas primitives (caractéristique souhaitée).
  • Exhaustivité : la conception réalise-t-elle complètement les exigences ?
  • Volatilité : fréquence des changements architecturaux.
Qualité de l'implémentation
  • Taille : où l'implémentation se situe-t-elle par rapport à la taille minimale (pour résoudre le problème) ? L'implémentation satisfera-t-elle à ses contraintes ?
  • Complexité : le code présente-t-il des difficultés ou une complexité du point de vue algorithmique ? Est-il difficile à comprendre ou à modifier ?
  • Exhaustivité : l'implémentation réalise-t-elle de manière fidèle l'intégralité de la conception ?
Qualité du test
  • Couverture : le test contrôle-t-il bien le logiciel ? Toutes les instructions sont-elles bien exécutées par un ensemble de tests ? Le test contrôle-t-il de nombreux chemins au sein du code ?
  • Validité : les tests eux-mêmes reflètent-ils bien les exigences ?
Qualité du processus (au niveau le plus bas)
  • Taux d'anomalies, origine des anomalies : quelle incidence ont les anomalies d'une tâche et quelles en sont les causes ?
  • Effort et durée : quelle durée et quel effort humain une activité nécessite-t-elle ?
  • Productivité : par unité d'effort humain, que produit une activité ?
  • Qualité des produits : quel est le taux d'anomalies des produits d'une tâche ?
Efficacité du changement de processus/d'outil (idem que pour la qualité du processus, mais pourcentages de changement plutôt que valeurs totales) :
  • Taux d'anomalies, origine des anomalies
  • Effort et durée
  • Productivité
  • Qualité des produits

Pour un traitement approfondi des concepts liés aux métriques, voir [WHIT97].

Qu'est-ce qu'une métrique ?

On distingue deux types de métriques :

  • Une métrique est un attribut mesurable d'une entité. L'effort lié à un projet, par exemple, est une mesure (c'est-à-dire, une métrique) de la taille d'un projet. Pour pouvoir calculer cette métrique, il vous faudrait additionner toutes les réservations de fiches de temps des employés relatives au projet.
  • Une métrique primitive est une donnée brute utilisée pour calculer une métrique. Dans l'exemple ci-dessus, les réservations de fiche de temps sont les métriques primitives. Une métrique primitive est généralement une métrique qui existe dans une base de données mais qui n'est pas interprétée de manière isolée.

Chaque métrique est composée d'une ou plusieurs métriques collectées. En conséquence, chaque métrique primitive doit être clairement identifiée et sa procédure de collecte définie.

Les métriques permettant de prendre en charge le changement ou les objectifs de réalisation sont souvent des « premières dérivées » dans le temps (ou des itérations du projet). Ce qui nous intéresse, c'est une tendance et non la valeur absolue. Pour « améliorer la qualité », nous devons vérifier que le niveau résiduel d'anomalies connues diminue dans le temps.

Canevas

Canevas pour une métrique

Nom Nom de la métrique et synonymes connus.
Définition Les attributs des entités qui sont mesurés à l'aide de cette métrique, la manière dont cette métrique est calculée et les métriques primitives à partir desquelles elle est calculée.
Objectifs Liste des objectifs et des questions relatifs à cette métrique, accompagnée de quelques explications sur la raison pour laquelle cette métrique est collectée.
Procédure d'analyse Utilisation prévue de cette métrique. Préconditions pour l'interprétation de la métrique (plage valide d'autres métriques, par exemple). Valeurs ou tendances cibles. Modèles de techniques d'analyse et outils à utiliser. Hypothèses implicites (de l'environnement ou des modèles, par exemple). Procédures d'étalonnage. Archivage.
Responsabilités Personne(s) en charge de la collecte et du regroupement des données, de la préparation des comptes-rendus et de l'analyse de données.

Canevas pour une métrique primitive

Nom Nom de la métrique primitive
Définition Description sans ambiguïtés de la métrique par rapport à l'environnement du projet
Procédure de collecte Description de la procédure de collecte. Outil de collecte des données et format à utiliser. Moments du cycle de développement où les données sont collectées. Procédure de vérification à utiliser. Lieu de stockage des données, format, précision.
Responsabilités Personne(s) en charge de la collecte des données. Personne(s) en charge de la vérification des données.

Tâches liées aux métriques

Il existe deux tâches :

  • Définir le plan de mesure
  • Collecter les mesures

La définition du plan de mesure s'effectue une fois par cycle de développement - lors de la phase de création, dans le cadre de l'activité de planification générale, ou parfois dans le cadre de la configuration du processus du plan de développement. Le plan de mesure peut être révisé, comme n'importe quelle autre section du plan de développement logiciel, à tout moment dans le cycle de développement du projet.

La collecte des mesures s'effectue de manière répétée, au moins une fois par itération et parfois plus fréquemment (chaque semaine sur une itération s'étalant sur plusieurs mois, par exemple).

Les métriques collectées font partie du document d'évaluation d'état, qui est utilisé dans l'évaluation de l'avancement et de la santé du projet. Elles peuvent également être accumulées pour une utilisation ultérieure dans les estimations et tendances de projet dans toute l'organisation.

Comment les métriques sont-elles utilisées ?

Estimation

Le responsable de projet est confronté aux problèmes de planification (affecter des ressources aux tâches avec des budgets et des calendriers). L'effort et le calendrier sont évalués à partir d'une estimation de ce qui doit être produit, ou l'inverse (les ressources et le calendrier sont fixes, c'est pourquoi il convient d'estimer ce qui peut être produit). L'estimation est généralement liée au calcul des besoins en ressources s'appuyant sur d'autres facteurs (généralement la taille et la productivité), à des fins de planification.

Prédiction

La prédiction ne diffère que légèrement de l'estimation, et consiste généralement au calcul de la valeur future d'un facteur à partir de sa valeur actuelle et d'autres facteurs ayant une influence. Par exemple, sur la base d'un échantillon de données de performances, il est utile de savoir (prédire) comment le système fonctionnera à pleine charge, ou dans une configuration dégradée ou marquée par une restriction des ressources. Les modèles de prédiction de la fiabilité utilisent les données des taux d'anomalies afin de prédire quand le système atteindra certains niveaux de fiabilité. Ayant planifié une activité, le responsable de projet aura besoin de données à partir desquelles prédire les dates d'exécution et l'effort d'exécution.

Evaluation

L'évaluation permet d'établir la position actuelle à des fins de comparaison avec un seuil, d'identification de tendances, de comparaison de plusieurs alternatives ou comme base pour l'estimation ou la prédiction.

Pour plus d'information sur les métriques dans la gestion de projet, lire [ROY98].