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 :
-
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.
-
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.
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.
|
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.
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].
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 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.
|
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.
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].
|