Tâche: Planifier les phases et les itérations
Cette tâche explique comment planifier les phases et itérations d'un projet et consiste entre autres à identifier les objectifs, à déterminer la durée, le nombre d'itérations, etc.
Objet

Objectifs de cette tâche :

  • Estimation de la portée, de l'effort et du coût globaux du projet.
  • Développement d'un plan général pour le projet, avec mise en évidence des principaux jalons et des livrables clés dans le cycle de vie du produit.
  • Définition d'un ensemble d'itérations au sein des phases du projet et identification des objectifs de chacune de ces itérations.
  • Préparation du planning et du budget du projet.
  • Développement du plan de ressources du projet.
  • Définition des tâches pour la bonne exécution du projet.
Relations
RôlesPrincipal: Complémentaire: Auxiliaire:
EntréesObligatoire: Facultatif:
  • Aucun
Externe:
  • Aucun
Sorties
Etapes
Estimation du projet
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

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.

Définition des jalons des phases du projet
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 partie du plan de développement logiciel, créée au début du projet (phase de création), sert de "feuille de route" globale pour le projet.

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.

Pour plus d'informations sur la manière de définir la durée des itérations et leur nombre, voir les Instructions : Plan de développement logiciel.

Définition des objectifs des jalons
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 
Jalon 
Objectif 
Création  Jalon des objectifs du cycle de vie Affectation de ressources au projet 
Elaboration  Jalon de l'architecture du cycle de vie Stabilisation de l'architecture du produit 
Construction  Jalon de la capacité opérationnelle initiale Achèvement du développement du produit 
Jalon de la commercialisation du produit Déploiement réussi 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éfinition du nombre, de la durée et des objectifs des itérations au sein des phases
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. Pour plus d'informations sur la manière de définir la durée des itérations et leur nombre, voir les  Instructions : Plan de développement logiciel. Un certain nombre de canevas d'itération peuvent être appliquées, selon le type de projet, le domaine du problème et le degré de nouveauté de ce domaine de problème (voir aussi Concept : 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, ils sont exprimés en termes d'exhaustivité fonctionnelle et de qualité.

Ajustement des dates et de la portée des jalons
Objet Préciser les estimations grâce aux 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étermination des exigences du projet en termes de ressources
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éveloppement du plan de clôture du projet
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 correspond à la série de tâches réalisées pour garantir que la clôture du projet s'effectuera correctement, en s'assurant que toutes les unités de mesure et l'expérience acquise sont bien enregistrées pour un éventuel usage ultérieur.

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é de manière formelle au client.

Définition des tâches de clôture

Tout d'abord, répertoriez dans votre plan les tâches que vous effectuerez au cours de 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 produits 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.

l'identification des participants aux tâches de clôture

Identifiez ensuite dans votre plan les personnes qui seront impliquées dans chacune de ces tâches de clôture.

Définition du planning des tâches de clôture

Définissez enfin le planning des tâches de clôture. Généralement, ce détail est ajouté au plan de développement logiciel vers la fin du projet.



Propriétés
Plusieurs occurrences
Commandé par les événements
En cours
Facultatif
Planifié
Réitérable
Considérations clés

La planification du projet est l'étape où le responsable de projet instancie (et par la suite gère l'exécution de) un processus de livraison spécifique (voir Produit : Processus de développement) pour le projet. On appelle souvent cela promulgation de processus.

Un processus "instancié" est un plan de projet/itération/activité applicable (il inclut les activités réelles et les produits d'un projet en cours). Un processus de livraison peut être instancié en important un processus de livraison à partir de Rational Method Composer dans Rational Portfolio Manager (RPM) puis en exécutant un travail d'instanciation en copiant les activités et les tâches qui sont paramétrées comme isRepeatable ou hasMultipleOccurences, en créant des produits réels, en attribuant des ressources réels à des rôles, etc. 

Plus d'informations