Objet
  • Estimer la portée, l'effort et le coût global du projet.
  • Développer un plan à gros grains pour le projet, en se concentrant sur les événements jalons principaux et les principaux livrables du cycle de vie du produit.
  • Définir un ensemble d'itérations à l'intérieur des phases du projet, et identifier les objectifs de chacune de ces itérations.
  • Développer le planning et le budget du projet.
  • Développer un plan de ressources pour le projet.
  • Définir les activités pour la bonne exécution du projet.
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 :   

Estimer le projet Haut de la page

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 :

  1. Estimer la taille du produit.
  2. Estimer l'effort et le coût global du projet
  3. Appliquer les contraintes et les priorités (par exemple, le nombre d'employés, la date de livraison, le budget)
  4. Sélectionner le planning, l'effort et l'estimation de coût optimaux

Estimer 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 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.

Définir les événements jalons de la phase du projet Haut de la page

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 :

  • L'expérience sur des projets de nature ou de domaine similaires.
  • Le degré de nouveauté.
  • Les contraintes environnementales spécifiques comme le temps de réponse, la distribution et la sécurité.
  • La maturité de l'organisation.

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.

Définir les objectifs jalons Haut de la page

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.

Définir le nombre, la durée et les objectifs des itérations à l'intérieur des phasesHaut de la page

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é.

Préciser les dates et la portée des événements jalons Haut de la page

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 :

  • Le nombre de cas d'utilisation identifiés.
  • La complexité des cas d'utilisation déjà étudiés.
  • Les risques identifiés, qu'ils soient techniques ou commerciaux.
  • La métrique par point de fonction ou cas d'utilisation.
  • Le résultat de tout prototypage.

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.

Déterminer les exigences du projet en terme de ressources Haut de la page

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.

Développer le plan de clôture du projet Haut de la page

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 :

  • Tous les produits du projet ont été achevés et stockés sous contrôle de configuration
  • Le test d'approbation a été achevé et le produit a été formellement accepté par le client
  • Le produit a été livré/fourni formellement au client

Définir les activités de clôture

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 :

  • Une réunion post-mortem pour le projet
  • Le développement d'un compte-rendu de post-mortem
  • Les revues de fin de projet du personnel
  • L'archivage des artefacts du projet
  • La ré-affectation de l'équipe du projet
  • L'ajout de la métrologie du projet à la base de données historique de votre organisation pour les estimations des futurs projets.

Identifier les participants aux activités de clôture

Identifiez ensuite dans votre plan les personnes qui seront impliquées dans chaque activité de clôture.

Définir le planning des activités 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)   2003.06.15