-
Les métriques doivent être simples, objectives, faciles à collecter et à interpréter, et difficile à interpréter à
contresens.
-
La collecte des métriques doit être automatisée et non intrusive, c'est-à-dire qu'elle ne doit pas interférer avec
les activités des développeurs.
-
Les métriques doivent contribuer à une évaluation de la qualité au début du cycle de vie, lorsque les efforts
fournis pour améliorer la qualité du logiciel prennent effet.
-
Les valeurs absolues et les tendances des métriques doivent être activement utilisées par le personnel de gestion
et les ingénieurs afin de communiquer la progression et la qualité dans un format cohérent.
-
La sélection d'un ensemble minime ou plus complet de métriques dépendra des caractéristiques et du contexte du
projet : si celui-ci est important ou comporte des exigences strictes en matière de sécurité ou de fiabilité et que
les équipes d'évaluation et de développement sont dûment informées des métriques, il peut être alors utile de
collecter et d'analyser les métriques techniques. Il est possible que le contrat exige la collecte de certaines
métriques ou que l'organisation essaie d'améliorer ses compétences et ses processus dans des domaines particuliers.
Il n'est pas de solution simple convenant à toutes les circonstances : le responsable de projet doit choisir les
éléments appropriés lorsque le plan de mesure est créé. Toutefois, lorsque vous introduisez un programme de
métriques pour la première fois, privilégiez la simplicité.
Les métriques de certains aspects du projet incluent :
-
La progression en termes de taille et de complexité.
-
La stabilité en termes de fréquence de changement des exigences ou de l'implémentation, de la taille ou de la
complexité.
-
La modularité en termes de portée du changement.
-
La qualité en termes de nombre et de type d'erreurs.
-
La maturité en termes de fréquence des erreurs.
-
Les ressources en termes de dépenses réelles par rapport aux dépenses prévues du projet.
Les tendances sont importantes et dans un sens plus importantes à surveiller que toute valeur absolue dans le
temps.
Unité de mesure
|
Objet
|
Exemples de mesures/perspectives
|
Progression
|
Planification des itérations
Complétude
|
-
Nombre de classes
-
SLOC
-
Points de fonction
-
Scénarios
-
Jeux d'essai
Ces mesures peuvent également être collectées par classe et par package
-
Quantité de retravail par itération (nombre de classes)
|
Stabilité
|
Convergence
|
-
Nombre et type de changements (bogue par opposition à l'amélioration ; interface par opposition
à l'implémentation)
Cette mesure peut également être collectée par itération et par package
-
Quantité de retravail par itération
|
Adaptabilité
|
Convergence
"retravail" logiciel
|
-
Heures-personnes moyennes/changement
Cette mesure peut également être collectée par itération et par package
|
Modularité
|
Convergence
"mise au rebut" logicielle
|
-
Nombre de classes/catégories modifiées par changement
Cette mesure peut également être collectée par itération
|
Qualité
|
Planification des itérations
Indicateur de retravail
Critère d'édition
|
-
Nombre d'erreurs
-
Taux de découverte de défauts
-
Densité des défauts
-
Profondeur d'héritage
-
Couplage de classes
-
Taille de l'interface (nombre d'opérations)
-
Nombre de méthodes annulées
-
Taille de la méthode
Ces mesures peuvent également être collectées par classe et par package
|
Maturité
|
Champ d'application/adéquation du test
Robustesse à l'utilisation
|
-
Heures de test/échec et type d'échec
Cette mesure peut également être collectée par itération et par package
|
Profil de dépense
|
Analyse financière
Dépenses prévues par opposition aux dépenses effectuées
|
-
Jours-personnes/classe
-
Personnel à plein temps par mois
-
% du budget dépensé
|
Même les projets les plus insignifiants ont besoin d'être suivis pour savoir s'ils respectent les délais et le budget
et si ce n'est pas le cas, pour réévaluer et déterminer si des changements de portée sont nécessaires. Cet ensemble
minimal de métriques sera, par conséquent, centré sur les métriques de progression.
-
Valeur acquise. Cette unité de mesure permet de réévaluer la planification et le budget du reste du projet, et/ou
d'identifier le besoin d'un changement de portée.
-
Tendances des défauts. Cette unité de mesure permet de déterminer les efforts requis pour corriger des défauts.
-
Tendance de progression du test. Cette unité de mesure permet de déterminer la quantité de fonctionnalités
effectivement réalisées.
Ces dernières sont décrites en détails ci-dessous.
Valeur acquise
La méthode la plus couramment utilisée ([PMI96]) pour mesurer
la progression est l'analyse de la valeur acquise.
La manière la plus simple de mesurer la valeur acquise consiste à faire la somme des efforts estimés à l'origine pour
toutes les tâches accomplies. Un "pourcentage total" peut être calculé pour le projet comme la valeur acquise divisée
par l'effort total estimé en début de projet. La productivité (ou indice de performance) correspond à la valeur acquise
divisée par les efforts réellement fournis dans les tâches accomplies.
Par exemple, supposons que l'effort de codage ait été divisé en plusieurs tâches, pour la plupart à présent accomplies.
L'estimation initiale pour la conclusion des tâches était de 30 jours. L'effort total estimé pour le projet était de
100 jours. Nous pouvons donc conclure que le projet est achevé à environ 30 %.
Supposons que les tâches aient été effectuées bien en dessous du budget escompté, n'exigeant que 25 jours. L'indice de
performance est le suivant : 30 / 25 = 1,2, soit 120 %.
Nous pouvons prévoir que le projet sera conclu à 20 % en dessous du budget et qu'il réduira, par conséquent, nos
estimations.
Considérations
-
L'indice de performance ne doit être utilisé que pour ajuster les estimations de tâches similaires. L'exécution
anticipée des tâches de regroupement des exigences n'implique pas forcément que le codage sera effectué plus
rapidement. Par conséquent, ne calculez l'indice de performance et n'ajustez les estimations que pour des tâches
similaires.
-
Considérez d'autres facteurs. Les tâches futures seront-elles effectuées par un personnel qualifié dans des
conditions similaires ? Les données ont-elles été contaminées par des "observations aberrantes" (tâches sévèrement
surestimées ou sous-estimées) ? Le temps est-il systématiquement enregistré (par exemple, les heures
supplémentaires doivent être incluses, même si elles ne sont pas rémunérées) ?
-
Les estimations des tâches nouvelles justifient-elles déjà l'indice de performance ? Si c'est le cas, les
estimations des nouvelles tâches auront alors tendance à s'approcher de la cible, amenant l'indice de performance à
près de 100 %. Il convient de réévaluer régulièrement toutes les tâches inachevées ou d'adopter la pratique
suivante d'Extreme Programming (XP) [JEF01] -
référez-vous aux estimations d'origine comme des "points" et mesurez les nouvelles tâches aussi en termes de
"points" sans corriger les performances réelles. Les "points" représentent un avantage dans la mesure où il est
possible d'effectuer un suivi des accroissements (ou des diminutions) des performances (rapidité du projet dans la
terminologie XP).
Si les tâches sont vastes (plus de 5 jours) ou si de nombreuses tâches sont partiellement achevées, vous souhaiterez
peut-être les factoriser dans votre analyse. Appliquez un "pourcentage d'exécution" subjectif, multipliez-le par
l'effort estimé de la tâche et intégrez-le à la valeur acquise. Des résultats plus cohérents sont obtenus si des règles
claires concernant l'affectation du pourcentage d'exécution sont définies. Ainsi, l'affectation d'un pourcentage
d'exécution maximum de 80 % à une tâche de codage avant la revue de cette dernière constitue un exemple de règle.
La valeur acquise est abordée en détails dans la section ci-après intitulée Un ensemble complet
de métriques : planning de projet.
Tendance des erreurs
Il est souvent utile d'effectuer un suivi de la tendance des défauts ouverts ou fermés. Ceci permet d'indiquer
approximativement s'il existe un retard significatif dans le travail de correction des défauts et la rapidité avec
laquelle ces défauts peuvent être fermés.
Les tendances de défauts constituent simplement l'une des métriques fournies par Rational ProjectConsole.
Considérations
-
Toutes les demandes de changements n'ont pas le même poids, qu'elles affectent une seule ligne de code ou
entraînent une reconception complète. Pour déterminer leur importance, utilisez quelques-unes des techniques
suivantes :
-
Gardez les observations aberrantes à l'esprit. Les demandes de changements qui requièrent un travail
important doivent être identifiées en tant que telles et enregistrées comme des tâches distinctes, et non
pas regroupées dans un système de débogage général. Si une série de petits correctifs domine la tendance,
pensez à les regrouper afin que chaque demande de changement représente une unité de travail plus
cohérente.
-
Vous pouvez consigner un plus grand nombre d'informations, telles qu'une "catégorie d'effort" subjective
"inférieure à 1 jour", "d'un jour", "inférieure à 5 jours" ou "supérieure à 5 jours".
-
Vous pouvez enregistrer des SLOC planifiés et des SLOC effectués pour chaque demande de changement.
Reportez-vous à la section Un petit ensemble de métriques,
ci-dessous.
-
Une absence de défauts enregistrés peut impliquer un manque de test. Gardez à l'esprit le niveau d'effort de test
lors de l'examen des tendances de défauts.
Tendance de progression du test
La quantité de fonctionnalités intégrées constitue la principale mesure de complétude.
Si chacune des tâches de développement représente un ensemble de fonctions intégrées, un diagramme des tendances de
valeurs acquises peut alors suffire.
La progression peut être communiquée très simplement en recourant à la tendance de progression du test.
Considérations
Certains jeux d'essai peuvent représenter une valeur ou un effort significativement plus important que d'autres. Ne
vous focalisez pas sur ce graphique : il fournit simplement l'assurance d'une progression vers la réalisation des
fonctionnalités.
L'ensemble minimal de métriques précédemment décrit n'est pas suffisant pour de nombreux projets.
Software Project Management, a Unified framework [ROY98], recommande
l'ensemble de métriques suivant pour tous les projets. Notez que ces métriques exigent des lignes de code source (SLOC)
prévues et réelles pour chaque demande de changement, qui requiert le regroupement d'efforts supplémentaires.
Métriques et métriques primitives
SLOC totale
|
SLOCt = Estimation de la taille totale du code. Elle peut changer de manière significative à mesure que
les exigences sont mieux comprises et que des solutions de conception sont développées. Intégrez les
logiciels réutilisés qui font l'objet de changements par l'équipe.
|
SLOC sous configuration
contrôle
|
SLOCc = Référence actuelle
|
Défauts critiques
|
SCO0 = nombre de SCO de type 0 (SCO correspondant à un ordre de modification logicielle, autre terme
désignant une demande de changement)
|
Défauts normaux
|
SCO1 = nombre de SCO de type 1
|
Demandes d'améliorations
|
SCO2 = nombre de SCO de type 2
|
Nouvelles fonctionnalités
|
SCO3 = nombre de SCO de type 3
|
Nombre de SCO
|
N = SCO0 + SCO1 + SCO2
|
Retravail ouvert (rupture)
|
B = SLOC rompues cumulées en raison de SCO1 et SCO2
|
Retravail fermé (correctifs)
|
F = nombre cumulé de SLOC corrigées
|
Effort de retravail
|
E = effort cumulé de correction des SCO de type 0/1/2 SCO
|
Temps d'utilisation
|
UT = heures durant lesquelles une référence donnée a fonctionné dans des contextes d'utilisation
réalistes
|
Métriques de qualité pour le produit fini
Quelques métriques intéressantes supplémentaires peuvent être dérivées de ce petit ensemble de métriques :
Rapport de mise au rebut
|
B/SLOCt, pourcentage de mise au rebut du produit
|
Rapport de retravail
|
E/Effort total, pourcentage d'effort de retravail
|
Modularité
|
B/N, rupture moyenne par SCO
|
Adaptabilité
|
E/N, effort moyen par SCO
|
Maturité
|
UT/(SCO0 + SCO1), temps moyen entre les défauts
|
Maintenabilité
|
(rapport de mise au rebut)/(rapport de retravail), productivité de la maintenance
|
Indicateurs en cours
Stabilité du retravail
|
B - F, rupture par opposition aux correctifs dans le temps
|
Retard de retravail
|
(B-F)/SLOCc, retravail actuellement en cours
|
Tendance de modularité
|
Modularité, dans le temps
|
Tendance d'adaptabilité
|
Adaptabilité, dans le temps
|
Tendance de maturité
|
Maturité, dans le temps
|
Les éléments à mesurer sont les suivants :
-
Le processus - séquence des activités invoquées pour produire le logiciel (et d'autres produits) ;
-
Le produit - produit du processus, y compris le logiciel, les documents et les modèles ;
-
Le projet - totalité des ressources, des activités et des produits du projet ;
-
Les ressources - personnes, méthodes et outils, temps, efforts et budget disponibles pour le projet.
Pour caractériser entièrement le processus, des mesures doivent être effectuées au niveau le plus bas de la tâche
officiellement planifiée. Les tâches seront planifiées par le responsable de projet à l'aide d'un ensemble
d'estimations initiales. Un enregistrement des valeurs réelles dans le temps et des estimations mises à jour effectuées
doit ensuite être conservé.
Métriques
|
Commentaires
|
Durée
|
Temps écoulé pour l'activité
|
Effort
|
Unités d'efforts du personnel (heures-personnel, jours-personnel, ...)
|
Sortie
|
Produits, ainsi que leur taille et quantité (notez que ceci inclut des défauts comme sortie des
activités de test)
|
Utilisation de l'environnement de développement logiciel
|
UC, stockage, outils logiciels, équipement (postes de travail, ordinateurs), produits jetables. Notez
que ces derniers peuvent être collectés pour un projet par la Software Engineering Environment
Authority (SEEA).
|
Défauts, taux de découverte, taux de correction
|
L'effort/temps de réparation total et la mise en rebut/le retravail total (dans la mesure où il est
possible de les mesurer) doivent également être collectés ; ils proviendront probablement des
informations collectées à partir des défauts (considérés comme des produits).
|
Demandes de changements, taux d'imposition, taux de mise au rebut
|
Commentaires sur le temps/les efforts, comme ci-dessus.
|
D'autres incidents pouvant avoir un impact sur ces métriques (texte libre)
|
Unité de mesure dans le sens où elle constitue un enregistrement d'un événement ayant affecté le
processus.
|
Nombre, profil et caractéristiques (dans le temps) des employés
|
|
Mouvements de personnel
|
Unité de mesure utile pouvant expliquer, lors d'une évaluation rétrospective, pourquoi un processus
s'est particulièrement bien ou mal déroulé.
|
Application de l'effort
|
La manière dont les efforts sont employés lors de l'exécution des activités planifiées (par rapport à
laquelle le temps est officiellement enregistré pour la gestion des comptes de coûts de revient) peut
servir à expliquer les variations de productivité. Voici quelques sous-classes d'application de
l'effort :
-
formation
-
familiarisation
-
gestion (par le coordinateur d'équipe, par exemple)
-
administration
-
recherche
-
travail productif : il est utile d'enregistrer cet élément via un artefact et d'essayer de
différencier le temps de 'réflexion' et le temps de saisie, notamment pour des documents. Ceci
indiquera au responsable de projet dans quelle mesure le processus de documentation est imputé
au temps de l'ingénieur.
-
période d'arrêt
-
réunions
-
inspections, visites virtuelles, revues - effort de préparation et de réunion
(quelques-unes de ces dernières seront des activités distinctes, le temps et les efforts qui
leur sont alloués seront enregistrés dans une activité de revue spécifique)
|
Inspections, visites virtuelles, revues (durant une activité, non pas des revues planifiées séparément)
|
Enregistrez leur nombre et leur durée, ainsi que le nombre de questions soulevées.
|
Déviations de processus (évoquées comme des non-conformités, requièrent un changement de projet)
|
Enregistrez leur nombre et leur degré de gravité. Elles indiquent la nécessité d'une formation
supplémentaire, mais également que le processus n'est pas correctement appliqué ou que le mode de
configuration du processus est incorrect
|
Problèmes liés au processus (évoqués comme des défauts de processus, requièrent un changement de
processus)
|
Enregistrez leur nombre et leur degré de gravité. Ces informations sont utiles lors des évaluations
rétrospectives et essentielles pour la Software Engineering Process Authority (SEPA).
|
Les produits du processus RUP sont des documents, des modèles ou des éléments de modèle.
Les modèles sont des séries d'éléments similaires (éléments de modèle). Les métriques recommandées sont donc
répertoriées ici avec les modèles auxquels elles s'appliquent : il est généralement facile de déterminer si une unité
de mesure est appliquée au modèle à part entière ou à un élément. Un texte explicatif est fourni en cas de difficulté.
Caractéristiques du produit
En règle générale, les caractéristiques que nous souhaitons mesurer sont les suivantes :
-
Taille - mesure du nombre d'éléments composant un modèle, la longueur d'un élément, la dimension ou la
masse d'un élément
-
Qualité
-
Défauts - indications qu'un produit ne produit pas les résultats escomptés, n'est pas conforme à
sa spécification ou comporte d'autres caractéristiques indésirables
-
Complexité - mesure de l'engrènement d'une structure ou d'un algorithme : plus la complexité est
élevée, plus la structure est difficile à comprendre et à modifier et il est évident que des structures
complexes sont plus susceptibles d'échouer
-
Couplage - mesure de la profondeur de l'interconnexion des éléments d'un système
-
Cohésion - évalue comment un élément ou un composant répond au besoin d'avoir un objectif unique
et clairement défini
-
Primitivité - degré selon lequel les opérations ou les méthodes d'une classe peuvent être
composées d'autres opérations/méthodes offertes par la classe
-
Complétude - évalue dans quelle mesure un artefact satisfait à toutes les exigences (stipulées ou
induites -le responsable de projet doit clarifier autant que possible les informations et limiter les
risques d'attentes non satisfaites). Nous avons choisi ici de ne pas faire la distinction entre
suffisant et complet.
-
Traçabilité - indication que les exigences d'un niveau donné sont satisfaites par des produits d'un
niveau inférieur et par ailleurs, qu'un produit de niveau quelconque a une raison d'être
-
Volatilité - degré de changement ou d'inachèvement d'un produit en raison de défauts ou d'un changement
des exigences
-
Effort - mesure du travail (unités de personnel-temps) requis pour produire un produit
Toutes ces caractéristiques ne s'appliquent pas à tous les produits : les plus importantes sont élaborées avec le
produit particulier dans les tableaux suivants. Si plusieurs métriques sont répertoriées pour une caractéristique,
toutes sont potentiellement intéressantes, car elles fournissent une description complète de la caractéristique sous
différentes perspectives. Par exemple, lorsque vous considérez la traçabilité des cas d'utilisation, tous doivent
pouvoir être tracés dans un modèle d'implémentation (testé) : entre temps, il sera toujours intéressant pour le
responsable de projet de savoir combien de cas d'utilisation peuvent être tracés dans le modèle d'analyse, afin de
pouvoir mesurer la progression.
Documents
Les métriques recommandées s'appliquent à tous les documents RUP.
Caractéristique
|
Métriques
|
Taille
|
Nombre de pages
|
Effort
|
Unités de personnel-temps pour la production, le changement et la réparation
|
Volatilité
|
Nombres de changements, de défauts, ouverts, fermés ; pages de changement
|
Qualité
|
Mesurée directement via le nombre de défauts
|
Complétude
|
Non mesurée directement : jugement effectué via la revue
|
Traçabilité
|
Non mesurée directement : jugement effectué via la revue
|
Modèles
Exigences
Attributs des exigences
Il s'agit en fait d'un élément de modèle.
Caractéristique
|
Métriques
|
Taille
|
-
nombre d'exigences total (= Nu+Nd+Ni+Nt)
-
nombre à repérer dans les cas d'utilisation ( = Nu)
-
nombre à repérer dans la conception, l'implémentation, le test uniquement ( = Nd)
-
nombre à repérer dans l'implémentation, le test uniquement ( = Ni)
-
nombre à repérer dans le test uniquement ( = Nt)
Notez que ceci permet de séparer les exigences en deux : celles qui seront modélisées par des
cas d'utilisation et celles qui ne le seront pas. On espère que la traçabilité des cas
d'utilisation explique les exigences affectées aux cas d'utilisation pour effectuer un suivi de
la conception, de l'implémentation et du test.
|
Effort
|
-
Unités de personnel-temps (pour la production, le changement et la réparation)
|
Volatilité
|
-
Nombre de défauts et de demandes de changement
|
Qualité
|
-
Nombre d'incidents, par gravité
|
Traçabilité
|
|
Modèle de cas d'utilisation
Caractéristique
|
Métriques
|
Taille
|
-
Nombre de cas d'utilisation
-
Nombre de packages de cas d'utilisation
-
Niveau rapporté de cas d'utilisation (voir le livre blanc, "Estimation des efforts
et de la taille basée sur les cas d'utilisation" du site d'IBM)
-
Nombre de scénarios, total et par cas d'utilisation
-
Nombre d'acteurs
-
Longueur du cas d'utilisation (pages du flux d'événements, par exemple)
|
Effort
|
-
Unités de personnel-temps avec la production, le changement et la réparation
|
Volatilité
|
-
Nombre de défauts et de demandes de changement
|
Qualité
|
-
Complexité signalée (0-5, par analogie avec COCOMO [BOE81] au niveau de la classe ; le champ de complexité
est plus étroit à des niveaux d'abstraction supérieurs - voir le livre blanc "Estimation
des efforts et de la taille en fonction des cas d'utilisation" du site d'IBM)
-
Défauts - nombre de défauts, par degré de gravité (ouvert, fermé)
|
Complétude
|
|
Traçabilité
|
-
Analyse
-
Scénarios réalisés dans le modèle d'analyse/scénarios totaux
-
Conception
-
Scénarios réalisés dans le modèle de conception/scénarios totaux
-
Implémentation
-
Scénarios réalisés dans le modèle d'implémentation/scénarios totaux
-
Test
-
Scénarios réalisés dans le modèle de test (jeux d'essai)/scénarios totaux
|
Conception
Modèle d'analyse
Caractéristique
|
Métriques
|
Taille
|
-
Nombre de classes
-
Nombre de sous-systèmes
-
Nombre de sous-systèmes de sous-systèmes ...
-
Nombre de packages
-
Méthodes par classe, interne, externe
-
Attributs par classe, interne, externe
-
Profondeur de l'arborescence d'héritage
-
Nombre d'enfants
|
Effort
|
-
Unités de personnel-temps pour la production, le changement et la réparation
|
Volatilité
|
-
Nombre de défauts et de demandes de changement
|
Qualité
|
Complexité
|
-
Réponse pour une classe (RFC) : peut être difficile à calculer, car un ensemble complet de
diagrammes d'interaction est nécessaire.
|
Couplage
|
-
Nombre d'enfants
-
Couplage entre objets (sortance des classes)
|
Cohésion
|
|
Défauts
|
-
Nombre de défauts, par degré de gravité, ouverts, fermés
|
Complétude
|
-
Nombre de classes effectives/nombre de classes estimées (identifiées)
-
Traçabilité de l'analyse
(dans un modèle de cas d'utilisation)
|
Traçabilité
|
Non applicable - le modèle d'analyse devient le modèle de conception.
|
Certaines métriques techniques spécifiques-OO ici présentées seront peut-être inconnues : profondeur de
l'arborescence d'héritage, nombre d'enfants, réponse pour une classe, couplage entre les objets, etc. Reportez-vous à
[HEND96] pour plus de détails sur la signification et l'historique de ces métriques.
Une grande partie de ces métriques ont été suggérées à l'origine par Chidamber et Kemerer (voir "A metrics suite for
object oriented design", IEEE Transactions on Software Engineering, 20(6), 1994), mais nous les avons appliquées ici
conformément à [HEND96] et avons préféré la définition de LCOM (manque de cohésion des méthodes)
présentée dans ce travail.
Modèle de conception
Caractéristique
|
Métriques
|
Taille
|
-
Nombre de classes
-
Nombre de sous-systèmes de conception
-
Nombre de sous-systèmes de sous-systèmes ...
-
Nombre de packages
-
Méthodes par classe, interne, externe
-
Attributs par classe, interne, externe
-
Profondeur de l'arborescence d'héritage
-
Nombre d'enfants
|
Effort
|
-
Unité de temps-personnel (pour la production, le changement et la réparation)
|
Volatilité
|
-
Nombre de défauts et de demandes de changement
|
Qualité
|
Complexité
|
-
Réponse pour une classe (RFC) : peut être difficile à calculer, car un ensemble complet de
diagrammes d'interaction est nécessaire.
|
Couplage
|
-
Nombre d'enfants
-
Couplage entre objets (sortance des classes)
|
Cohésion
|
|
Défauts
|
-
Nombre d'incidents, par gravité
|
Complétude
|
|
Traçabilité
|
Nombre de classes dans le modèle d'implémentation/nombre de classes
|
Implémentation
Modèle d'implémentation
Caractéristique
|
Métriques
|
Taille
|
-
Nombre de classes
-
Nombre de fichiers
-
Nombre de sous-systèmes d'implémentation
-
Nombre de sous-systèmes de sous-systèmes ...
-
Nombre de packages
-
Méthodes par classe, interne, externe
-
Attributs par classe, interne, externe
-
Taille des méthodes*
-
Taille des attributs*
-
Profondeur de l'arborescence d'héritage
-
Nombre d'enfants
-
Taille estimée* à l'exécution
|
Effort
|
-
Unités de personnel-temps (production, changement et réparation considérés séparément)
|
Volatilité
|
-
Nombre de défauts et de demandes de changement
-
Rupture* pour chaque modification corrective ou perfective, estimée (avant la correction)
et réelle (à la fermeture)
|
Qualité
|
Complexité
|
-
Réponse pour une classe (RFC)
-
Complexité cyclomatique des méthodes**
|
Couplage
|
-
Nombre d'enfants
-
Couplage entre objets (sortance des classes)
-
Couplage de transfert des messages (MPC)***
|
Cohésion
|
-
Nombre d'enfants
-
Manque de cohésion des méthodes (LCOM)
|
Défauts
|
-
Nombre de défauts, par degré de gravité, ouverts, fermés
|
Complétude
|
|
* Une méthode de mesure de la taille du code doit être choisie, puis appliquée de manière cohérente, comme par exemple,
sans commentaire, non vide. Reportez-vous à [ROY98] pour une
description des mérites et de l'application de 'lignes de code' comme unité de mesure. Reportez-vous également à la
même référence pour la définition d'une 'rupture'.
** L'utilisation de la complexité cyclomatique n'est pas universellement acceptée, notamment lorsqu'elle est appliquée
aux méthodes d'une classe. Reportez-vous à [HEND96] pour une
description de cette unité de mesure.
*** A l'origine issu du document publié par Li et Henry, "Object-oriented metrics that predict maintainability", J.
Systems and Software, 23(2), 1993, et également décrit dans [HEND96].
Test
Modèle de test
Caractéristique
|
Métriques
|
Taille
|
-
Nombre de jeux d'essai, de procédures de test, de scripts de test
|
Effort
|
-
Unités de personnel-temps (production, changement et réparation considérés séparément pour
la production des jeux d'essai, etc.
|
Volatilité
|
-
Nombre d'incidents et de demandes de changement classés par rapport au modèle de test
|
Qualité
|
-
Défauts - nombre de défauts par degré de gravité, ouvert, fermé (il s'agit de
défauts apparaissant dans le modèle de test lui-même, non des défauts soulevés par l'équipe
de test par rapport à d'autres logiciels)
|
Complétude
|
|
Traçabilité
|
-
Nombre de cas d'utilisation signalés comme réussis dans l'évaluation récapitulative du
test/Nombre de jeux d'essai
|
Gestion
Modèle de changement - il s'agit d'un modèle notionnel destiné à une présentation cohérente - les
métriques seront collectées à partir d'un système quelconque permettant de gérer des demandes de changements.
Caractéristique
|
Métriques
|
Taille
|
-
Nombre de défauts, de demandes de changements par degré de gravité et état, également
classés comme nombre de modifications perfectives, nombre de modifications adaptatives et
nombre de modifications correctives.
|
Effort
|
-
Effort de correction des défauts, effort d'implémentation des modifications en unités de
personnel-temps.
|
Volatilité
|
-
Rupture (estimée, effective) pour le sous-ensemble de modèles d'implémentation.
|
Complétude
|
-
Nombre de défauts découverts/nombre de défauts prévus (si un modèle de fiabilité est
utilisé).
|
Planning de projet (section 4.2 du plan de développement
logiciel)
Il s'agit de mesures issues de l'application des techniques de valeur acquise à la gestion de projets ; ensemble,
elles forment ce que l'on appelle les critères des systèmes de contrôle de planification/coûts (C/SCSC). Une
technique de valeur acquise simple est décrite ci-dessus dans la section Un ensemble minimal de métriques. Des analyses plus détaillées peuvent
être effectuées à l'aide de métriques similaires, notamment :
-
BCWS, Coût budgété du travail planifié
-
BCWP, Coût budgété du travail réalisé
-
ACWP, Coût réel du travail réalisé
-
BAC, Budget à l'exécution
-
EAC, Estimation à l'exécution
-
CBB, Base budgétaire du contrat
-
LRE, Dernière estimation révisée (EAC)
facteurs dérivés pour la variation du coût et du planning. Reportez-vous à [ROY98] pour une
description de l'application d'une approche de valeur acquise à la gestion de projets.
Le projet doit être caractérisé en termes de type, de taille, de complexité et de formalité (bien que le type, la
taille et la complexité déterminent généralement la formalité), car ces aspects conditionneront les attentes concernant
les divers seuils pour les mesures de niveau inférieur. D'autres contraintes doivent être signalées dans le contrat (ou
les spécifications). Les métriques provenant du processus, du produit et des ressources engloberont toutes les autres
métriques au niveau du projet. Vous pouvez enregistrer le type et le domaine de projet à l'aide d'une description de
texte, en veillant à ce que des détails soient fournis pour caractériser le projet d'une manière aussi concise que
possible. Enregistrez la taille du projet selon le coût, les efforts, la durée, la taille du code à développer et les
points de fonction à fournir. La complexité du projet peut être décrite, de manière subjective, en plaçant le projet
sur un diagramme illustrant la complexité technique et managériale par rapport à d'autres projets réalisés. [ROY98]. La figure 14-1 illustre ce diagramme.
Les métriques dérivées décrites dans [ROY98], et qui
constituent les principaux indicateurs du responsable de projet, peuvent être obtenues à partir des métriques
regroupées pour le produit et le processus. Celles-ci sont les suivantes :
-
Modularité = rupture moyenne (NCNB*) par modification perfective ou corrective sur le modèle
d'implémentation
-
Adaptabilité = effort moyen par modification perfective ou corrective sur le modèle d'implémentation
-
Maturité = temps de test actif/nombre de modifications correctives
-
Maintenabilité = Productivité de la maintenance/Productivité du développement = [corrections réelles
cumulées/efforts cumulés pour les modifications perfectives et correctives]/[nombre de NCNB estimés à
l'exécution/efforts de production estimés à l'exécution]
-
Stabilité du retravail = ruptures cumulées-corrections cumulées
-
Retard de retravail = [ruptures cumulées-corrections cumulées]/unité NCNB testée
* NCNB est une taille de code sans commentaire, non vide.
L'avancée du planning du projet doit être indiquée à l'aide des métriques d'exécution produit, avec un poids
particulier (d'une perspective valeur acquise), indiquées à la production de logiciel travaillant.
Si un modèle d'estimation, tel que COCOMO (voir [BOE81]) est utilisé,
les divers facteurs d'échelle et les inducteurs de coûts doivent être enregistrés. En effet, ces derniers caractérisent
le projet d'une manière extrêmement détaillée.
Les éléments à mesurer incluent des individus (expérience, compétences, coûts, performances), les méthodes et les
outils (en termes d'impact sur la productivité et la qualité, coûts), le temps, les efforts, le budget (ressources
employées, ressources restantes).
Le profil de dotation doit être enregistré dans le temps, en indiquant le type (analyste, concepteur, etc.), le grade
(ce qui implique des coûts), et l'équipe à laquelle il est affecté. Les deux valeurs, prévisionnelles et réelles,
doivent être enregistrées.
Là aussi, le modèle COCOMO requiert la caractérisation de l'expérience et des capacités du personnel, ainsi que de
l'environnement de développement logiciel, et constitue une excellente infrastructure préfabriquée pour la conservation
de ces métriques.
Les informations sur les dépenses, le budget et la planification proviendront du planning de projet.
|