Organisation et gestion d un projet logiciel

Organisation et gestion d un projet logiciel Master CCI 2006-2007 Génie Logiciel - ORGANISATION DE PROJET - P.Y. CUNIN, I. PARISSIS

Activités s de gestion Les acteurs Quels sont les rôles? Quelles sont les responsabilités s? Estimation Combien de temps va durer le projet? Quel effort sera nécessaire n (budget)? Répartition de la durée e et de l effort l le long du cycle de vie? Planification Quelles sont les tâches nécessaires? n Combien de temps durera chaque tâche? Quel effort sera consacré à chaque tâche? Quelles ressources? Qui fait quoi et quand? Suivi Le planning est-il bien respecté? 2

Acteurs d un d projet Master CCI 2006-2007 Génie Logiciel - ORGANISATION DE PROJET - P.Y. CUNIN, I. PARISSIS

Un objectif Qu est est-ce qu un un «projet»? Défini en termes de fournitures Un délaid Des moyens Projet vs Activité 4

Acteurs principaux d un d projet Maîtrise d ouvrage d (MOA) Maîtrise d ouvrage d délégud guée e (MOAd( MOAd) Maîtrise d œd œuvre (MOE) Maîtrise d œd œuvre délégud guée e (MOEd( MOEd) 5

MOA (maîtrise d'ouvrage), MOAd (... délégud guée) MOA = Entreprise ou service «client» La société X décide d de faire développer d un logiciel de gestion des congés s de son personnel. MOAD = Personne ayant en charge le suivi du projet pour le compte e du client (par exemple un responsable produit) La société X décide d de faire développer d un logiciel de gestion des congés s de son personnel. Madame A. YYY. est chargée e de cette opération ration. 6

MOE (maîtrise d'œuvre), MOEd (chef de projet) MOE = Entreprise ou service ayant pris l engagement l de réaliser r le projet pour le MOA La société X décide d de faire développer d un logiciel de gestion des congés s de son personnel. Madame A. YYY est chargée e de cette opération.elle lance un appel d offres. d Elle sélectionne la société de services ABLogiciels. MOEd = Personne chargé par le MOE pour mener le projet Liaison client (MOA délégud gué) Evaluation ressources Gestion projet (éventuellement( assisté par un contrôleur) Décision de passage d une d étape du CV à une autre ABLogiciels nomme Monsieur Z chef de projet. 7

Canaux de communication MOA Maître d ouvrage MOE Maître d œuvre MOAd Maître d ouvrage délégué MOEd Maître d œuvre délégué (chef de projet) Utilisateurs Equipe projet 8

Schéma récursif (sous-traitance MOA Maître d ouvrage MOA MOE Maître d ouvrage d oeuvre MOE Maître d oeuvre MOAd Maître d ouvrage délégué MOAd MOEd Maître Maître d œuvre d ouvrage délégué (chef délégué de projet) MOEd Maître d œuvre délégué (chef de projet) 9

MOAd vs. MOEd Rôles complémentaires mentaires mais opposés MOAd Le meilleur produit au meilleur prix (pour le client) MOEd Le meilleur produit en respectant le budget et les engagements de délaid Cause fréquente d éd échec d un d projet: MOAd = MOEd 10

Equipes Equipe qualification validation Equipe projet Chef de projet Experts du domaine technique du projet Analystes Architectes Développeurs Intégrateurs Testeurs Développe les plans de test d intd intégration, système, acceptation (avec chef de projet et client) Equipe qualité Généralement affectée à plusieurs projets Aide à la mise en œuvre de l Assurance l Qualité Organise le Contrôle de la qualité Avertit le Chef de projet en cas de problème constaté Très s souvent réduite r à un "responsable qualité" 11

Estimation Master CCI 2006-2007 Génie Logiciel - ORGANISATION DE PROJET - P.Y. CUNIN, I. PARISSIS

Pourquoi mesurer et estimer? Pourquoi les voitures ont des compteurs de vitesse? Pourquoi se pèsep se-t-on? Combien de personnes font construire une maison sans avoir une idée i e de la taille de la maison? Comment un constructeur communique-t-il il à propos d'une maison et de son coût t de construction? Cela est nécessaire n pour prévoir, contrôler et piloter 13

Portée e de la métrologiem Evaluer la charge à consacrer au développement d logiciel Seulement une partie du "coût" total du logiciel (hors vente, commercialisation, maintenance, formation,...) Par la même occasion, évaluer la productivité du développementd Attention à ne pas provoquer un rejet Une pratique pragmatique, basée e sur l'expérience Mais aussi, un besoin de rationalité et de méthodes m afin de ne pas dépendre uniquement de l'expérience 14

Quelques considérations préliminaires Tout n'est pas "objectif". Il y a des composantes organisationnelles, financières, stratégiques,... La loi de Parkinson "Le travail s'étend jusqu'à remplir tout le temps alloué à son exécution cution" La loi de Brooks "Ajouter du personnel à un projet en retard ne fait que le retarder" Les aspects mercantiles sont souvent prépond pondérants "Quel prix le client est-il prêt à payer?" Une synthèse se de l'ensemble adapté à chaque projet 15

Historique de la mesure : 1 ère vague 16

Historique de la mesure : 2ème 2 vague 17

Estimation toujours approximative Estimation Basée e sur Expérience du chef de projet Modèles d estimationd Elaborés à partir de la collecte de données issues de plusieurs projets Classification Modèles statiques à une variable à plusieurs variables Modèles dynamiques 18

Modèles statiques à une variable Modèles d estimationd Ressource = f(variable) Ressource : effort, durée, taille équipe, doc variable : LOC («( lines of code»), effort, Exemple : étude de Walston & Felix (1977) 60 projets de 4000 à 400000 LOC, 12 à 12000 hm E = 5,2 x L 0.91 (E : hm, L : KLOC) D = 4,1 x L 0.36 (D : mois) D = 2,47 x E 0.35 DOC = 49 x L 1.01 (DOC : pages de doc) (source : Software Engineering, R. Pressman) Modèles statiques à plusieurs variables Calcul d une d ressource en fonction de plusieurs caractéristiques ristiques Dynamiques L estimation de la ressource dépend d du temps 19

Modèles connus Function point Putnam COCOMO 20

Function Point (FP)( Norme de fait dans l'informatique de gestion Méthode prédictive, avant le développement d et indépendante de la technologie Elle repose sur la décomposition d technique initiale des fonctionnalités s du projet Se concentre sur les fonctionnalités s dont il faut établir la liste, leur complexité et leur nombre 5 caractéristiques ristiques prises en compte 1. les entrées es (ex. les formulaires de saisie remplis par l'utilisateur) 2. les sorties (ex. les vues et les états fournis par l'application à l'utilisateur) les interrogations (ex. requêtes,,consultation menu, consultation aide, a...) 3. les 4. les groupes de données internes (ex. entités s dans une base de données) 5. les interfaces externes (ex. les fichiers externes partagés) 21

Function Point (FP)( : La méthodem Pour chaque fonction, déterminer d le nombre de composantes et la complexité de chacune Exemple : Pour le groupe de données internes on utilise le modèle conceptuel de données et on comptabilise les tables et les relations Soit une table 1 associée à deux autres par une relation "1 to many". La table 1 a 25 champs, la table 2 a 6 champs et la table 3 a 4 champs. On a 3 composantes. c < 20 éléments 1 relation Basse 2 à 5 relations Basse 6 relations et plus Moyenne 20-50 éléments Basse Moyenne Haute > 50 éléments Moyenne Haute Haute Composantes Complexité basse Complexité moyenne Complexité haute internes 7 10 15 externes 5 7 10 entrées es 3 4 6 sorties 4 5 7 interrogations 3 4 6 Table 1 est de complexité moyenne. Table 2 et 3 sont de complexité faible On pondère chaque entité/composante au moyen de la table des points et on somme pour obtenir le nombre des points de fonction bruts PFB Dans l'exemple : les entités s internes donnent un total de 24 (10+7+7) 22

FP : Ajustement, charge de travail Le total des points bruts est ajusté en fonction de 14 facteurs (notés s de 0 à 5) Transmission des données Configuration Convivialité Réutilisation Installations multiples, portage Distribution Taux de transaction Mise à jour en temps réelr Facilité d'implantation Facilité des modifications, maintenance Performance Entrées des données en temps réelr Complexité du traitement Simplicité d'utilisation Chaque note indique si le facteur introduit de la complexité (0 simple, 5 complexe) On fait la somme des 14 notes et on calcule le facteur de complexit xité technique FCT = 0,65 + 0,01 x Σ i=1..14 facteur i On calcule le nombre total de points de fonctions ajustés s PFA PFA = PFB x FCT A partir du nombre de jour*homme par point de fonction JHPF (connu nu par expérience) on obtient la charge de travail : Charge de travail = PFA x JHPF 23

Le modèle de Putnam Optimiser la charge au cours du développement d et maîtriser la relation entre raccourcissement du projet et augmentation de la charge Dynamique à plusieurs variables 2 principes : l effectif optimal de l'équipe de développement d à un temps t doit être proportionnel à la charge de travail restante l efficacité de l él équipe de développement d s ams améliore avec le temps La charge instantanée e au temps t est la dérivd rivée e de la charge cumulée. On obtient une courbe de distribution de la charge (courbe( de Rayleigh- Norden) qui est une courbe exponentielle négativen Le sommet de la courbe indique le nb maximal de personnes travaillant sur le projet en ETP (équivalent( temps plein). Il est atteint dans des délais fonction d'un paramètre C représentatif de la complexité 24

Courbe de Rayleigh - Norden 25

charge en ETP Courbe de Rayleigh - Norden Besoins Spécification Conception & développement Opération - maintenance nb2 Validation - test nb1 Conception - codage durée 26

Le modèle de Putnam Issu d éd études sur de gros projets (>30ha) L = C x E 1/3 D 4/3 C : cte technologique (2000-11000) de complexité D : durée e (années) L : lignes de code E : effort (h.années) On peut déduire d duire : E = L 3 /(C 3 x D 4 ) l effectif de pointe une fois estimées la charge totale et la date de réceptionr la charge totale du projet quand le maximum des effectifs et le temps de développement sont atteints. l impact de la variation de la durée e de développement d sur la difficulté du projet. Exemple : Un raccourcissement du temps de 10% suppose une augmentation de la charge totale de 40% 27

CoCoMo (Constructive Cost Model Barry Boehm) Modèle statique à une variable dans sa version de base (DSI : Delivered Source Instructions) Couvre le cycle de vie de la spécification (i.e. après s analyse de besoins) à la livraison Versions Version 1 parue en 1981 Nouvelle version (COCOMOII) définie en 1997 et finalisée e en 2001 http://sunset.usc.edu/research/cocomoii 28

Niveaux de COCOMO Le niveau indique la complexité du modèle et sa précision Base E = f(dsi) Intermédiaire Paramètres de coût t (statique à plusieurs variables) Sophistiqué Paramètres de coût t pour chaque étape du développement d (dynamique) 29

COCOMO de base : trois «modes de développementd veloppement» Le mode de développement d reflète la difficulté du projet «Organic» petits projets, petite équipe expériment rimentée, e, besoins «souples» «Semidetached» «Embedded» projets moyens, équipe hétérogh rogène entre «organic» et «embedded» logiciels embarqués, contraintes de développement d et d opd opération très s fortes. 30

ip8 Choix du mode de développementd Organic Semidetached Embedded Définition des besoins Très bonne Bonne Générale Expérience dans le domaine Très forte Bonne Faible Contraintes de développ. - Faibles Moyennes Fortes opération Contraintes d interface Faibles Moyennes Fortes Développement parallèle de Faible Moyen Intensif matériel ou procédures d utilisation Besoin d architectures ou Faible Moyen Fort algorithmes innovants Besoin de livraison rapide Faible Moyen Fort Taille du logiciel <50 KDSI <300 KDSI toute taille 31

Diapositive 31 ip8 Animation ip; 05/11/2004

Equations du modèle de base Mode Effort (hmois) Durée (mois) Organic 2,4 KDSI 1,05 2,5 Effort 0,38 Semidetached 3,0 KDSI 1,12 2,5 Effort 0,35 Embedded 3,6 KDSI 1,20 2,5 Effort 0,32 32

ip9 Application sur projets de tailles variées 2 KDSI 8 KDSI 32 128 512 KDSI KDSI KDSI Effort (MM) Organic 5.0 21.3 91 392 Semidetached 6.5 31 146 687 3250 Embedded 8.3 44 230 1216 6420 Productivité (DSI/MM) Organic 400 376 352 327 Semidetached 308 258 219 186 158 Embedded 241 182 139 105 80 Durée (mois) Organic 4.6 8 14 24 Semidetached 4.8 8.3 14 24 42 Embedded 4.9 8.4 14 24 41 Taille moyenne équipe Organic 1.1 2.7 6.5 16 Semidetached 1.4 3.7 10 29 77 Embedded 1.7 5.2 16 51 157 33

Diapositive 33 ip9 Animation : faire passer en rouge les points à souligner ip; 05/11/2004

Variation Effort / taille M*M Embedded 6000 5000 4000 3000 Semidetached 2000 1000 Organic 100 200 300 400 500 600 KDSI 34

Variation Durée e / Taille 36 30 24 18 mois Embedded Semidetached 12 6 Organic 100 200 300 400 500 600 KDSI 35

30 24 18 12 6 mois Variation Durée e / Effort Organic Semidetached 36 Embedded 1000 2000 3000 4000 5000 6000 MM 36

Répartition de l effortl par étape du CV Mode Etape 2 KDSI 8 KDSI 32 KDSI 128 KDSI 256 KDSI Organic Analyse de besoins 6 6 6 6 Spécification 16 16 16 16 Implantation 68 65 62 59 Conception 26 25 24 23 Codage et test unitaire 42 40 38 36 Intégration et test 16 19 22 25 Semidetached Analyse de besoins 7 7 7 7 7 Soit E l effort du projet consacré aux étapes de Spécification, Programmation, Intégration et test Spécification 17 17 17 17 17 Implantation 64 61 58 55 52 Conception 27 26 25 24 23 Codage et test unitaire 37 35 33 31 29 16% de E sont consacrés à l étape de Spécification 68% de E sont consacrés à l étape de Programmation 26% de E sont consacrés à l étape de Conception 42% de E sont consacrés à l étape de Codage et test unitaire 16% de E sont consacrés à l étape d Intégration et test Intégration et test 19 22 25 28 31 Embedded Analyse de besoins 8 8 8 8 8 Spécification 18 18 18 18 18 Implantation 60 57 54 51 48 Conception 28 27 26 25 24 Codage et test unitaire 32 30 28 26 24 Intégration et test 22 25 28 31 34 6% de E est ajouté pour l étape d Analyse de besoins 37

ip12 Répartition de la durée par étape du CV Mode Etape 2 KDSI 8 KDSI 32 KDSI 128 KDSI 256 KDSI Organic Analyse de besoins 10 11 12 13 Spécification 19 19 19 19 Implantation 63 59 55 51 Intégration et test 18 22 26 30 Semidetached Analyse de besoins 16 18 20 22 24 Spécification 24 25 26 27 28 Implantation 56 52 48 44 40 Intégration et test 20 23 26 39 32 Embedded Analyse de besoins 24 28 32 36 40 Spécification 30 32 34 36 38 Implantation 48 44 40 36 32 Intégration et test 22 24 26 28 30 38

Diapositive 38 ip12 Couleurs;exemple ip; 05/11/2004

Répartition de l effortl par activité (Embedded mode) Activité Etape Analyse besoins Spécification Codage Intégration & test KDSI 2 8 32 2 8 32 2 8 32 2 8 32 Analyse besoins 50 48 46 10 10 10 3 3 3 2 2 2 Conception 12 13 14 42 42 42 6 6 6 4 4 4 Codage 2 4 6 10 11 12 55 55 55 32 36 40 Préparation test 2 3 4 4 5 6 3 3 4 4 4 5 V&V 6 7 8 6 7 8 8 9 10 38 28 25 Gestion projets 16 14 12 15 13 11 9 8 7 10 9 8 Assurance Q 5 4 4 4 3 3 8 7 7 10 9 9 Documentation 7 7 6 9 9 8 7 7 6 9 9 8 39

Insuffisance du modèle de base COCOMO intermédiaire 1 projet sur 3 conforme au modèle à un coefficient de 1,3 près 2 projets sur 3 conformes au modèle à un coefficient de 2 près Nécessité de paramètres supplémentaires (autres que la taille estimée du logiciel) 40

15 paramètres supplémentaires CoCoMo intermédiaire Paramètres "produit" fiabilité (RELY), taille BD (DATA), complexité (CPLX) Paramètres "matériel" performances (TIME), contraintes mémoire moire (STOR), volatilité (évolution pendant développement) machine virtuelle (VIRT), temps de retour (entre soumission d une d tâche par le programmeur et la réponse r du système, TURN) Paramètres "personnel" qualité programmeurs (PCAP), qualité analystes (ACAP), expérience application (AEXP), expérience du matériel (VEXP), expérience langage (LEXP) Paramètres "projet" méthodes modernes (MODP), outils de GL (TOOL), planning contraint (délai, SCED) Chaque paramètre peut varier de «very low» à «extra high».. A chaque valeur est associé un poids correcteur. Calcul d un d coefficient correcteur par combinaison des poids associés à chaque paramètre( tre(«effort Adjustment Factor») à appliquer sur le résultat r du modèle de base. 41

CoCoMo intermédiaire Exemple de poids affectés à des facteurs de coût Très s basse basse nominale haute Très s haute Extra haute Fiabilité RELY Complexité CPLX Contr. exéc. en temps TIME Contr.sur délai SCED 0.82 0.92 1.00 1.10 1.26 0.73 0.87 1.00 1.17 1.34 1.74 1.00 1.11 1.29 1.63 1.43 1.14 1.00 1.00 1.00 42

COCOMO II COCOMO conçu u pour des développementsd de bout en bout Aujourd hui, les logiciels sont rarement conçus sans réutiliser : Une version existante Des composants existants COCOMO II prend en compte ces aspects La variable d entrd entrée e du modèle (DSI) est affinée DSI développd veloppéeses DSI modifiées DSI réuitilisées http://sunset.usc.edu/research/cocomoii 43

COCOMO, critiques Facteurs non pris en compte : Volatilité des besoins Disponibilité du personnel Qualité du management Qualité de l'interface homme-machine machine Etudes sur les écarts entre l estimation l du nombre de lignes de code et la valeur réelle r déviation moyenne est de 64% de la taille réelle r seulement 25% des estimations sont à 25% de la taille réelle. r Une étude sur les outils logiciels d estimation d a montré qu ils ne font pas mieux, la déviation d pouvant aller de 100 à 200% 44

Conclusion Estimer le coût t du projet pour le fournisseur puis décider d du prix facturé au client L estimation algorithmique du coût t est difficile puisqu elle repose sur des estimations des attributs du logiciel final Importance des modèles d estimation d du coût t du logiciel pour le management : moyen de comparaison entre plusieurs options de développement Le temps requis pour développer d un projet ne se réduit r pas à une fonction simple de la taille de l équipe de projet Chaque organisation doit déterminer d ses propres attributs et ses propres multiplicateurs en fonction de ses spécificit cificités, ses priorités s et ses contraintes (capitalisation de l'expérience, constitution d'une base de données statistiques sur le projets,...) 45

Planification-suivi Master CCI 2006-2007 Génie Logiciel - ORGANISATION DE PROJET - P.Y. CUNIN, I. PARISSIS

Estimation Objectifs Déterminer l ensemble l de "tâches" avec un niveau de détail d suffisant Estimer l effort l nécessaire n pour l accomplissement l de chaque "tâche" Les tâches La définition d et le contenu d'une tâche dépendent d du cycle de vie choisi. une itération dans le cas du processus unifié une (partie de) phase/étape dans le cas d'un cycle de vie en V ou en cascade un incrément dans un cycle de vie incrémental En général g une tâche correspond à la réalisation r d'une fourniture intermédiaire ou finale, interne ou externe Difficultés Produire des données quantitatives à partir d informations d qualitatives imprécises Dans un premier temps il est inutile de rechercher une grande précision, les estimations étant destinées à être ajustées lors du suivi 47

Décomposition des tâches Exemple de décomposition (cycle de vie classique) T1 : Analyse besoins T2 : Définition D spécifications T3 : RéalisationR T3.1 : Conception globale T3.2 : Conception détailld taillée, codage et test unitaire T.3.2.1 : Module A T.3.2.2 : Module B T3.3 : Intégration et test T4 : Livraison 48

Plan Planification Définir l ordre l des tâches : graphe de précédence Déterminer la durée e du projet Affecter des ressources Produire le planning Suivi Technique de représentation graphique de l avancementl 49

ip14 Planification: graphe de précédence Point de départ d Décomposition du projet en tâches Graphe de précédence (ou réseau) r Tâches Liens entre tâches A B C D 50

Diapositive 50 ip14 Rappel : tâche =? ip; 05/11/2004

ip15 A A A A A B B B B B Types de liens Début début La tâche B ne peut commencer qu apr après s le début de la tâche A Début fin La tâche B ne peut se terminer qu apr après s le début de la tâche A Fin début (très s courant) La tâche B ne peut commencer qu apr après s la fin de la tâche A Fin fin La tâche B ne peut se terminer qu apr après s la fin de la tâche A Début début et fin - fin La tâche B ne peut commencer qu apr après s le début de la tâche A et ne peut se terminer qu apr après s la fin de A. 51

Diapositive 51 ip15 Insèrer exemple ip; 05/11/2004

Liens Un lien permet de déclencher d une tâche et non pas de synchroniser deux tâches Exemple : B ne peut commencer qu apr après s le début d de A; A ne peut se terminer qu apr après s la fin de B A B A : arrangements intérieurs B : peinture "Boucle" est souvent due à une mauvaise définition d des tâches B A A A : arrangements préliminaires A : arrangements finaux B : peinture 52

Planification: déterminer la durée e du projet Point de départ d : graphe de précédence durée e des tâches estimée e (cf. p.ex. CoCoMo) B 20j A 10j D 10j C 10j 53

Planification «début-fin au plus tôt» A C B Calcul du chemin critique A 10j D B C 20j 10j Diagramme de Gantt A D 10j Planification «début-finfin au plus tard» B C D 0j 10j 20j 30j 40j -40j -30j 10j -20j -10j 30j 40j Date de débutd «au plus tôt» Date de débutd but«au plus tard» 54

Marges et chemin critique Marge d une tâche date de début d au plus tard date de début d au plus tôt Marge = décalage potentiel d une tâche A 10j B 20j D 10j Marge(A) = Marge(B) = Marge(D) = 0j C 10j Marge(C) = 10j Chemin critique : ensemble des tâches de marge nulle Sur l exemple : A, B, D 55

Marges et chemin critique (suite) Le chemin critique détermine la durée minimale du projet,, sans prendre en compte l affectation de ressources Marge totale d une tâche Durée dont une tâche peut être décalée sans décaler la fin du projet Marge libre d une tâche Durée dont une tâche peut être décalée sans en décaler aucune autre 56

Marge négative Une marge peut être négative, si la durée du projet est imposée Lors de la planification au plus tard,, on tient compte de le date de fin imposée Exemple : durée imposée de 35j pour le réseau ci-dessous Marge négative = incohérence entre durées es,, liens, dates Eliminer les marges négatives avant l affectation de ressources B 20j A 10j D 10j C 10j 57

Les ressources d un d projet Planification : affecter les ressources Caractéristiques ristiques d une d ressource Description Type, nom,... Ressources humaines Ressources logicielles Disponibilité Temps plein - partiel Fixe - variable Ressources matérielles Trois paramètres (2 à fixer) Intensité : % de la disponibilité totale Charge (effort) Durée 58

Disponibilité d une ressource Ressources humaines Sur 52 x 5 = 260 jours de l année déduireduire : 10 jours fériés 25 à 30 jours de congés 5 jours maladie 5-10 jours formations (hors projet) 10 jours vie sociale (CE, syndicats, ) 40 jours de support à d autres projets il reste entre 145 et 180 jours à travailler sur un projet précis Ressources logicielles et matérielles Bien penser à la réservation r / commande Évaluer les risques associés 59

élevé Ressources humaines Degré de participation Ingénieur «senior» Codage Ingénieur «junior» faible Chef de projet Besoins Spécification Conception & développement Intégration - test 60

Plan de charge Point de départ : planning + affectation de ressources A B C D 0j 10j 20j 30j 40j 50j 100% R1 0% R1 A 100% R2 B 100% C 100% D 100% R2 100% 0% 61

Nivellement Rendre le planning conforme à la disponibilité des ressources Nécessaire quand une ressource est utilisée plus que sa disponibilité ne le permet Décaler les tâches en surcharge Calculer le nouveau planning Nivellement à durée fixe La durée des tâches n est pas modifiée Nivellement à charge fixe La durée des tâches peut diminuer (attention!!!) ou augmenter 62

Respect des dates Date de fin antérieure à la date demandée e par le client OK Date de fin postérieure à la date demandée e par le client mais on peut se ramener au cas précédent si on ajoute des ressources Problème MOE Date de fin postérieure à la date demandée e par le client quelle que soit la quantité de ressources affectées es Problème MOA 63

Suivi du planning Des réunions d avancement régulières Vérification du respect du planning Réajustement du planning En pratique Les réunions d avancement ne doivent pas être trop espacées mais pas trop fréquentes non plus... Le temps passé à suivre l avancement fait partie du projet! Pour les projets standards : toutes les deux à quatre semaines (correspond à une itération dans le processus unifié) 64

Suivi: diagramme dates-dates Diagramme synthétique tique donnant un aperçu u pertinent de l avancementl Exemple A B C D t0 fa fa2 fa1 fc fc2 fc1 fb fb2 fb1 fd fd2 fd1 RA1 RA2 65

A B C D t0 fa fa2 fa1 fc fc2 fc1 fb fb2 fb1 fd fd2 fd1 66

t0 fa fa2 fa1 fc fc2 fc1 fb fb2 fb1 fd fd2 fd1 67

t0 fa fc fb fd t0 fa1 fc1 fb1 fd1 futur passé Le projet converge si les courbes des tâches se rapprochent de la ligne du présent t0 fa2 fc2 fb2 fd2 présent 68

Diagramme dates-dates date d'avancement jalon rendu de jalon 69

Diagramme dates-dates Les lignes bleues représentent les dates d'avancement (écrites en bleue) Les lignes mauves représentent la prévision pour le jalon correspondant. A l'intersection des jalons et des dates d'avancement, on trouve des points bleus. Les lignes vertes correspondent à un rendu de jalon. Par exemple rendu du cahier des charges fonctionnel. Lorsqu'une ligne verte reprend la couleur mauve, le client n'a pas accepté le jalon. C'est pour cela qu'il est replanifié. Un jalon "ligne verte" entre deux points bleus est accepté. Pour l'exemple les jalons sont (de haut en bas) : Version finale [En cours de validation] Version beta [Accepté] Cahier des charges technique [Accepté] Maquette Interface graphique [Accepté] Cahier des charges graphique [Accepté] Cahier des charges fonctionnel [Accepté] Cahier des charges [Accepté] 70