Activité :
|
Objet
|
|
Rôle : Chef de projet | |
Fréquence : Une fois par projet. | |
Etapes
|
|
Artefacts d'entrée : | Artefacts de sortie : |
Guides d'utilisation de l'outil : |
Détails sur l'enchaînement des activités : |
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 :
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 lesite 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.
Estimer l'effort et les 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 principaux modèles utilisés aujourd'hui sont le COnstructive COst MOdel (COCOMO) développé par Barry Boehm, et la méthodologie Putnam de Larry Putnam. 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, voir le site Web de 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.
Appliquer les contraintes et les 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.
Sélectionner un planning, un effort et des estimations de coûts 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.
Objet | Définir les points sur lesquels la progression du projet est évaluée de façon formelle. Attribuer un effort et des coûts estimés à chaque phase. |
Le plan de développement logiciel définit tout d'abord les dates et la nature des événements jalons (voir Phases). Cette section du plan de développement logiciel sert de "calendrier de lancement" global au projet et est créée au début du projet (phase de création).
Pour planifier les phases pour un projet dans le cycle de développement initial, vous devrez peut-être élaborer des hypothèses au sujet des événements jalons en vous basant sur :
En utilisant des estimations basées sur votre propre expérience dans d'autres projets de même nature, vous créez le budget initial du projet en attribuant les portions de l'effort et des coûts globaux estimés à chaque phase du projet.
Objet | Définir les critères à partir desquels les phases sont estimées. |
Chaque événement jalon est focalisé sur un livrable spécifique ; chacun d'entre eux fournit un point de transition bien défini vers la prochaine phase.
Phase |
Evénement jalon |
Objectif |
---|---|---|
Création | Objectif de cycle de vie | Attribuer des ressources au projet |
Elaboration | Architecture de cycle de vie | Stabiliser l'architecture du produit |
Construction | Capacités opérationnelles initiales | Terminer le développement du produit |
Transition | Livraison du produit | Réussir le déploiement du produit |
Chaque événement jalon représente un obstacle crucial que le projet doit surmonter ; à chaque événement jalon le projet est confronté à une décision oui/non.
Objet | Déterminer combien d'itérations seront programmées pour chaque phase du projet. Déterminer l'attribution relative du travail entre les itérations. Déterminer les objectifs pour chaque itération. |
Une fois définie la durée des phases du projet, vous devez déterminer le nombre d'itérations et leur durée. Il existe un certain nombre de modèles d'itérations qui peuvent être appliqués, selon le type de projet, le domaine du problème et la nouveauté du domaine du problème (voir aussi Concepts : Itération).
Chaque itération produit un livrable, c'est-à-dire un version représentant un produit exécutable utilisé pour évaluer la progression et la qualité. Dans la mesure où chaque itération a une cible différente, la fonctionnalité et l'exhaustivité du produit de l'itération sont variables. Les objectifs de l'itération doivent être assez précis pour évaluer, à la fin de l'itération, si les objectifs de celle-ci ont été atteints. Dans les premières itérations, les objectifs sont généralement exprimés en termes de risques limités ; dans les itérations suivantes, les objectifs sont exprimés en termes d'exhaustivité fonctionnelle et de qualité.
Objet | Préciser les estimations basées sur les informations disponibles à la fin de la phase de création |
Vers la fin de la phase de création, les phases peuvent être planifiées avec plus de précision en prenant en considération :
Ce plan très approximatif est mis à jour pendant la phase d'élaboration. Il sert de base pour l'élaboration du reste du plan de projet.
Objet | Définir le nombre et types de ressources requises pour ce projet, attribués par phase/itération. |
Selon votre estimation de l'effort et le planning du projet qui en découle, vous pouvez à présent définir les ressources requises pour mener à bien le projet. Pour chaque phase/itération, identifiez les rôles devant être impliqués et le nombre de chacun d'entre eux.
Objet | Développer le plan pour une bonne clôture du projet. |
Le plan de clôture du projet est documenté dans Section 5.6 Plan de clôture du plan de développement logiciel. La clôture du projet est la série d'activités effectuées afin de garantir une bonne clôture du projet, en s'assurant que la métrologie et les leçons apprises sont consignées pour référence future.
Le processus de clôture commence quand les conditions suivantes ont été remplies :
Tout d'abord, listez dans votre plan les activités que vous effectuerez pendant la clôture du projet. Elles comportent généralement les éléments suivants :
Identifiez ensuite dans votre plan les personnes qui seront impliquées dans chaque activité de clôture.
Définissez ensuite le planning des activités de clôture. Généralement, ce détail est ajouté au plan de développement logiciel vers la fin du projet.
RUP (Rational Unified Process)
|