Objet
|
Estimer l'ampleur du travail requis pour livrer le projet.
Sélectionner le meilleur planning possible pour répondre aux contraintes du projet.
|
Pendant la phase de création, nous vous conseillons de préparer des estimations du travail
prévu dans le projet (pour une discussion générale de l'estimation d'un projet logiciel voir [BOE81], [PUT92], et [MCO96]). L'estimation d'un projet logiciel se base sur des calculs complexes, pour
cette raison, nous n'évoquerons pas ici le contexte technique détaillé. L'estimation suit un processus en quatre étapes
:
-
Estimer la taille du produit.
-
Estimer l'effort et le coût global du projet
-
Appliquer les contraintes et les priorités (par exemple, le nombre d'employés, la date de livraison, le budget)
-
Sélectionner le planning, l'effort et l'estimation de coût optimaux
Estimation de la taille du produit
Ce sont les données les plus importantes du processus d'estimation. Si vous ne pouvez pas estimer l'ampleur du travail
à effectuer, tout planning de projet que vous créerez sera sans doute loin de la réalité. Deux approches pour estimer
la taille du produit logiciel peuvent être utilisées tôt dans le projet : le dimensionnement par analogie, et le
dimensionnement par analyse. Bien sûr, plus tard dans le projet (pendant la phase d'élaboration), vous pouvez préparer
des estimations ascendantes plus rigoureuses basées sur une structure détaillée de ventilation du travail du projet.
Dimensionnement par analogie
Lorsque vous estimez l'ampleur du projet en utilisant l'approche de dimensionnement par analogie vous comparez le
nouveau projet que vous allez développer à des produits (d'une taille connue) développés lors de projets préalables.
Nous vous conseillons de comparer plusieurs caractéristiques des produits comparés, comme le nombre de cas
d'utilisation métier, le nombre d'acteurs, la taille et la complexité de la base de données, et une estimation du
nombre de programmes en ligne et en lot.
En comparant ces caractéristiques vous pouvez estimer la taille relative du nouveau produit par rapport aux anciens,
puis utiliser la taille connue des anciens produits pour calculer la taille estimée du nouveau produit. Souvenez-vous
qu'il est important de comparer des produits d'une complexité similaire, développés en utilisant des approches
analogues dans la mesure où des variations, par exemple dans le niveau de détails de la description des cas
d'utilisation, peuvent invalider vos comparaisons.
Dimensionnement par analyse
Plus tard dans la phase de création, vous aurez probablement réuni assez d'informations sur le nouveau produit pour
utiliser des techniques analytiques pour estimer la taille du produit. Ces techniques se basent sur une description
fonctionnelle du produit logiciel disponible (par exemple, dossier de spécifications du logiciel, document sur
l'architecture logicielle) et appliquent les règles standards de comptage afin de déterminer une mesure de taille à
partir de ces descriptions. La technique la plus connue est probablement le comptage des points de fonction, bien qu'un
certain nombre d'autres mesures aient été développées, y compris les points de caractéristiques (une modification des
points de fonction pour application aux systèmes en temps réel) et les points d'objets de prévision (mesure pour les
systèmes orientés objet basés sur une analyse des complexités et des hiérarchies de classe).
Des livres blancs sont également disponibles sur le site Web IBM, et
décrivent les méthodes d'estimation de taille basées sur les cas d'utilisation. En utilisant ces documents, soyez
conscient que pour faire des estimations initiales de taille basées sur les cas d'utilisation, vous devez
procéder à un étalonnage pour respecter le style de cas d'utilisation de votre organisation, car les cas d'utilisation
peuvent varier largement en terme de niveau d'abstraction et de style selon les organisations, et même à l'intérieur
d'une organisation. Une fois l'étalonnage fait, il est important de conserver le style standard choisi pour l'écriture
des cas d'utilisation, sinon les estimations de taille peuvent s'avérer complètement erronées.
Estimation de l'effort et des coûts globaux du projet
L'effort en termes de ressources humaines et le planning global pour un projet peuvent être calculés à partir de
l'estimation de la taille du produit en utilisant des modèles scientifiques établis. Les deux modèles principaux
utilisés aujourd'hui sont le Constructive Cost Model (COCOMO) développé par Barry Boehm, et la méthodologie Putnam
élaborée par Larry Putman. Ces deux modèles ont été validés par rapport aux données de l'industrie. Pour plus
d'informations sur la dernière version de COCOMO, consultez le site Web COCOMOII.
Outre les données sur la taille, l'autre donnée cruciale est la mesure de la productivité de l'équipe. Cette valeur
détermine l'effort global du projet. Le planning global du projet est lié de façon non linéaire à l'effort global.
Malheureusement les modèles sont mathématiquement complexes, il est donc conseillé d'utiliser les outils logiciels pour
vous aider dans vos calculs.
Application des contraintes et des priorités
La majorité des projets dépendent de contraintes (par exemple, l'expédition doit se faire à une date précise ou le coût
ne peut dépasser 850 000 $) ou de priorités (par exemple, produit voulu le plus tôt possible). Selon une taille
déterminée de produit, ils sont influencés par les ajustements à la taille de l'équipe. En fait, la relation entre la
taille de l'équipe et le planning n'est pas linéaire, vous devrez donc utiliser les modèles scientifiques pour générer
un certain nombre de scénarios basés sur des tailles d'équipe variables. Il est très utile d'utiliser un logiciel
d'estimation automatisé pour cet exercice.
Choix du planning, de l'effort et des estimations de coût optimaux
Maintenant que vous possédez une gamme de scénarios pour le projet, révisez et sélectionnez le scénario qui correspond
le mieux aux besoins de votre projet. Cela vous donne une vision initiale de la durée globale proposée du projet ; et
indique la taille de l'équipe et le budget nécessaires.
|