GESTION DE PROJET LOGICIEL

1. GESTION DE PROJET LOGICIEL INTRODUCTION

2. GÉNÉRALITÉS • ORIGINE DANS L'ORGANISATION DES GRANDS CHANTIERS • UNE MOBILISATION GÉNÉRALE, LE PROJET MANHATTAN, LE DÉBARQUEMENT DU 6 JUIN 44, ETC. • LES PROBLÈMES • COMMENT ALLOUER AU MIEUX LES RESSOURCES DISPONIBLES (LA RO À LA RAND Corp.)  ORDONNANCEMENT, MÉTHODE PERT, ETC. • COMMENT ÉVITER QU'UN ÉVÉNEMENT MINEUR GRIPPE UN ÉNORME DISPOSITIF  ANALYSE DE RISQUE, RESSOURCES CRITIQUES, ETC. • COMMENT SYNCHRONISER AU MIEUX DIFFÉRENTES TÂCHES INTERDÉPENDANTES MAIS QUI PEUVENT ÊTRE MENÉES EN //  GESTION OPTIMALE DU TEMPS. PERTURBATIONS T1 T2 ÉVÉNEMENT DÉBUT TÂCHE À RÉALISER ÉVÉNEMENT FIN DÉLAI = T2 - T1 RESSOURCES

3. Modèle générique des tâches en gestion de projet : Le modèle VEST Conformité de la fourniture Conformité de la livraison Pilote de la tâche E S T Tâche projet à effectuer Tâche(s) aval Tâche(s) amont Flux nominal et anomalies imputables à T Flux nominal et demandes de modifications V Validation, vérification, test Par rapport à la FINALITÉ Bilan économique du processus en terme de productivité - rendement (COQ et CONQ)

4. Détail du modèle VEST SUPERVISION Pilote Externe  Responsable projet PE Flux de contrôles et de commandes Pilote Interne  Responsable de tâche PI Domaine des valeurs en entrée Domaine des valeurs en sortie Données du processus Résultats du processus Tâches et/ou activités à effectuer (i.e. fonctions et/ou actions transformant les flux) Contrôles entrées Contrôles sorties Flux d’échanges Flux d’échanges Validation Vérification Test (VVT) État des ressources Protocole Allocation • Les flux d’échanges sont constitués : • éléments du référentiel projet (i.e. des données) • des messages véhiculant des événement susceptibles d ’altérer le déroulement du projet Restitution Stock de ressources nécessaires à l’exécution du processus Flux de ressources allouées/restituées

5. LA VISION TEMPORELLE :CYCLE SYSTÈME - CYCLE DE DÉVELOPPEMENT Développement et MCO Retrait Faisabilité Définition Prototype Compatibilité ascendante des versions successives Expérimentation Version N°1 Exploitation Réalisation de maquettes Réalisation de prototypes Version N°2 Exploitation N Cycles de Développement – Exploitation - Maintenance Validation fonctionnelle et non fonctionnelle au sens informatique Version N°n Exploitation Dominante MCO Validation fonctionnelle et comportements exigés en termes métier de la cible Dominante développement Vérification de la bonne prise en compte des règles architecturales au sein des projets (Revues + Inspections) • Grande variété de types de projets selon la nature des activités et « l’age » du système • Durée d’un cycle : > 15-20 ans, mais > 30 pour les grands systèmes technologiques

6. DÉTAIL DU CYCLE DE DÉVELOPPEMENT (1/3) RETOUR D’EXPÉRIENCE Axe d’évolution Expression de besoin /Exigences Axe d’évolution Processus de DEVELOPPEMENT CdCF-3 Réalisation incrément N°3 CdCF-2 CdCF-1 Réalisation incrément N°2 Réalisation incrément N°1 Qualification Conception Axe d’évolution Qualification • Documents contractuels : • Spécifications techniques de besoin et exigences (fonctionnel et non fonctionnel, en particulier contrat de service pour les usagers en terme d’exigences) Développement Intégration • Fournitures contractuelles : • Kit d’installation, paramétrage et règle de calibrage, doc pour le support, doc utilisateur, etc. • Garantie Assurance Qualité et contrat de service Déploiement, support et MCO

7. DÉTAIL DU CYCLE DE DÉVELOPPEMENT (2/3) Processus de développement Expression de besoin et exigences Mesure de la maturité de l’EB/EC • Défauts propagés • Défauts ajoutés • Défauts détectés EB/EC Conception générale CG Conception détaillée Implémentation CD Programmation et tests unitaires • Taux d’erreurs résiduelles Processus de conception P/TU Intégration (VV&T) Mesure de la maturité (i.e. contrat de service) en exploitation Assurance qualité et activités transverses AQ Nombre de RA/AC VVT Exploitation et support Mesure de la qualité de service Durée

8. DÉTAIL DU CYCLE DE DÉVELOPPEMENT (3/3) CQFD global du projet CCD, DCD CCG, DCG CG CPTU, DPTU CAQ/CG CD CVVT, DVVT CAQ/CD P/TU CAQ/PTU VVT CAQ/VVT AQ globale centralisée CAQ = CAQ/GC + CAQ/CG + CAQ/CD + CAQ/PTU + CAQ/VVT La recherche systématique des défauts se fait préventivement dans toutes les phases du cycle de développement

9. ESPACE MÉTHODOLOGIQUE DE LA GESTION DE PROJET LOGICIEL Axe arbre produit et caractéristiques qualité produit (Cf. ISO/CEI 9126) • 6 caractéristiques principales • FURPSE • + Caractéristiques de l’environnement système • Sécurité, sûreté de fonctionnement, interopérabilité, etc. Axe méthodes d’estimation (Cf. concept CQFD) Axe méthodologies Cycle système et cycle de développement (Cf. ISO/CEI 12207)  Chaque phase a des besoins et des exigences qui lui sont propres en terme CQFD et risques Espace de possibilités de choix très grand donc risque d’inconsistance et d’incomplétude si la maturité du chef de projet est faible (Cf. CMM)

10. PARTICULARITÉS DES PROJETS INFORMATIQUES • LES RÉSULTATS SONT IMMATÉRIELS • RUPTURE DES HABITUDES, CHANGEMENT DE PARADIGME CULTUREL • L'INFORMATIQUE FAIT PARFOIS PERDRE LE SENS COMMUN (  IA) • IMPORTANCE CRUCIALE DES PHASES DE CONCEPTION • PRORIÉTÉS DIFFUSES  PERFORMANCE, SURETÉ DE FONCTIONNEMENT • PRÉSENCE DE FEED-BACKS DÉSTABILISATEURS • DUS À LA VÉRIFICATION / VALIDATION TARDIVE DU TRAVAIL EFFECTUÉ • POIDS DES ACTIONS INDIVIDUELLES DES ACTEURS • FORMATION ET EXPÉRIENCE, SENS DE L'ÉQUIPE SONT IRREMPLACABLES • ENVIRONNEMENT TECHNIQUE / HUMAIN TRÈS LABILE • DEMANDES DE MODIFICATIONS CONTINUELLES (PARFOIS DÉRAISONNABLES) • PERENNITÉ DES TECHNOLOGIES DES PLATES-FORMES (RAREMENT > 2-3 ANS) • GESTION DE LA COMPLEXITÉ • ASPECTS STATIQUES  CE QUE L'ON VOIT (i.e. les référentiels) • ASPECTS DYNAMIQUES  CE QUI S'EXÉCUTE

11. INTERACTIONS AVEC L'ENVIRONNEMENT Analyse des risques Evaluation Suivi Maître d'Œuvre Industriel Maître d'Ouvrage Utilisateurs et/ou Clients Caractéristiques générales, Mission du système Spécification de besoin, choix technologiques Spécification fonctionnelle, Architecture Le Système et ses Exploitants Sous-Traitances & Partenariats LIVRAISON

12. Les différents aspects d’un projet Axes principaux Aspect produit Aspect acteurs&organisation Aspect processus Sont au cœur de l’interaction : processus  produit Aspect cohérence globale du projet Aspect qualité(ISO 9126) Aspect coût Aspect délai Maximiser Minimiser Il faut assurer la cohérence globale des différents aspects des projets qui contribuent à l’acquisition d’un système informatique

13. Profils types d’équipes projet CMM : Capability Maturity Model (cf. Norme ISO 15507 SPICE) PSP : Personal Software Process (Aspects individuels du CMM ; cf. W.Humphrey, A discipline for software engineering)

14. LES FONCTIONS ET LE PROCESSUS DE LA GESTION DE PROJET ÉNUMÉRER TOUS LES TRAVAUX À FAIRE AUSSI PRÉCISEMMENT QUE POSSIBLE STRUCTURATION DÉTERMINER À L'AVANCE LES QUANTITÉS / QUALITÉS DE RESSOURCES NÉCESSAIRES AUX DIFFÉRENTES TÂCHES ESTIMATION AFFECTER LES RESSOURCES RÉELLES, DÉFINIR LES RESPONSABILITÉS, RÉPERTORIER LES CONTRAINTES D'EXÉCUTION LIÉES À L'ENVIRONNEMENT ORGANISATION PLANIFICATION DÉTERMINER LES DATES CLEFS VIS À VIS DU MO ET DU MOI; ANALYSE ET IDENTIFICATION DES RISQUES DÉFINIR L'ENCHAÎNEMENT DANS LE TEMPS DE TOUTES LES TÂCHES, LA SYNCHRONISATION, L'AFFECTATION FINE DES RESSOURCES, LES PRIORITÉS ORDONNANCEMENT MESURER ET CONTRÔLER RÉGULIÈREMENT L'AVANCEMENT RÉEL PAR RAPPORT AUX PRÉVISIONS; RENDRE COMPTE SUIVI

15. LA STRUCTURATION (1/2) • LES PRÉREQUIS: • LE PROCESSUS DE DÉVELOPPEMENT (CYCLE DE VIE) • L'ARCHITECTURE DU SYSTÈME À RÉALISER • N'EST GÉNÉRALEMENT PAS CONNU AU DÉMARRAGE DU PROCESSUS • NOTION D'ARBRE PRODUIT • DÉCOMPOSITION HIÉRARCHIQUE DU SYSTÈME EN CONSTITUANTS • DÉFINIT LES RÈGLES DE VISIBILITÉ • POUR LE MO / MOI • POU LE CONTRÔLE QUALITÉ • POUR LES MEMBRES DE L'ÉQUIPE PROJET • RÔLE FONDAMENTAL DU CHEF DE PROJET ET DE L'ARCHITECTE QUI SONT SOUVENT UNE SEULE ET MÊME PERSONNE • L'ARBRE PRODUIT ÉVOLUE; C'EST UN COMPROMIS POUR PERMETTRE DES VUES PLUS OU MOINS DÉTAILLÉES DE L'ACTIVITÉ SELON LES INTERLOCUTEURS • L'ARBRE PRODUIT EST UN OUTIL DE COMMUNICATION FONDAMENTAL ENTRE TOUS LES ACTEURS DU PROJET • IL STRUCTURE L'INFORMATION DU PROJET

16. LA STRUCTURATION (2/2) • ORGANIGRAMME DES TÂCHES (Work Break-down Structure) • NOMENCLATURE FINE DU PROJET DE FAÇON À POUVOIR ASSIGNER LES TÂCHES INDIVIDUELLES • FORTE ADHÉRENCE AVEC LA GESTION DE CONFIGURATION • TOUS LES RÉSULTATS (LOTS DE TRAVAUX - Work Package / Work Item) DOIVENT ÊTRE RÉPERTORIÉS • DOCUMENTATION • CODE SOURCE ET EXÉCUTABLES • TESTS • DIFFICULTÉS HABITUELLES AVEC CE QUI EST TRANSVERSAL / DIFFUS • PERFORMANCE • SURETÉ DE FONCTIONNEMENT • MATÉRIALISE LES NIVEAUX DE REGROUPEMENT • EN PARTICULIER POUR LES LOTS CONTRACTUELS, L'INTÉGRATION • VA PERMETTRE LA MISE EN PLACE DE LA COMPTABILITÉ ANALYTIQUE DU PROJET (SAISIE DES COÛTS) • COMME L'ARBRE PRODUIT DONT IL EST ISSU, L'OT ÉVOLUE • IL DOIT NÉANMOINS ÊTRE ASSEZ STABLE POUR PERMETTRE UN SUIVI COHÉRENT

17. EXEMPLE ARBRE PRODUIT / OT (1/2) SAISIE TRAITEMENT 1 TRAITEMENT 2 TRAITEMENT 3 TRAITEMENT 4 ÉDITION C'EST LE RÉSULTAT DE L'ARCHITECTURE DU PRODUIT (Vision synchronique —> le résultat)

18. EXEMPLE ARBRE PRODUIT / OT (2/2) Expression de besoin (T1) SAISIE SAISIE Conception (T2) SAISIE SAISIE Programmation (T3) Temps Tests unitaires (T4) TRAITEMENT 1 TRAITEMENT 1 TRAITEMENT 1 TRAITEMENT 1 TRAITEMENT 1 TRAITEMENT 1 TRAITEMENT 1 TRAITEMENT 1 TRAITEMENT 1 TRAITEMENT 1 TRAITEMENT 1 TRAITEMENT 1 TRAITEMENT 1 TRAITEMENT 2 TRAITEMENT 3 TRAITEMENT 4 ÉDITION ÉDITION ÉDITION ÉDITION C'EST LE RÉSULTAT DU CYCLE DE DÉVELOPPEMENT DU PRODUIT (Vision DIACHRONIQUE / FEUILLAGE —> l'évolution dans le temps) LE PLAN INTÉGRATION PEUT REGROUPER, SELON LA STRATÉGIE ADOPTÉE : S, T1, E PUIS T2, T3, T4 ; ou T1, T2, T3 ET T4 PUIS S ET E, etc.

19. L'ESTIMATION (1/2) • ÉLÉMENT FONDAMENTAL DU CONTRÔLE DES COÛTS • RÉPOND AUX QUESTIONS : • COMBIEN CA VA COUTER? • QUEL EST LE DÉLAI DE RÉALISATION PRÉVISIBLE? • LES ALÉAS DE L'ESTIMATION • L'EXPÉRIENCE DU CHEF DE PROJET / ARCHITECTE • LA COMPLEXITÉ TECHNIQUE (STATIQUE, DYNAMIQUE) DU PROJET • LE CONTRÔLE DE L'ENVIRONNEMENT (ORGANISATION, TECHNOLOGIQUE) • L'OPTIMISME NATUREL ET L'IRRÉALISME DES INDIVIDUS; L'ATTITUDE FACE À L'ERREUR • LES MODÈLES • ANALYTIQUES  COCOMO • REPOSENT SUR L'IDÉE QUE LE NOMBRE DE LIGNES DE CODE SOURCE EST UNE BONNE APPROXIMATION DE LA QUANTITÉ DE TRAVAIL À FOURNIR • EMPIRIQUE • "FUNCTION POINT", CONSENSUS D'EXPERTS, GROUPE DELPHI

20. L'ESTIMATION (2/2) EXPRESSION DE BESOIN Délai généralement très court (qq semaines) entre la remise du cahier des charges et le devis initial, même pour de très gros projets. 1ÈRE ESTIMATION (GROSSIÈRE) DEVIS INITIAL ÉTUDE FONCTIONNELLE RÉ-ESTIMATION (MOINS GROSSIÈRE) Délai et charge de travail pouvant représenter 5 à 10% de la réalisation pour de très gros projets. Réalisation de maquettes PRÉ-ÉTUDE TECHNIQUE ÉTUDE TECHNIQUE COMPLÈTE ESTIMATION FINALE (TRÈS PRÉCISE) RÉALISATION SUIVI DE LA RÉALISATION

21. Les conditions préalables de l’estimation • Le périmètre et les frontières du projet sont connus • Nomenclature des processus qui font l’objet de l’estimation • Le processus de développement est défini • Emploi intelligent des normes internationales : • IEEE 1220 : le processus système global • ISO 12207 : le processus de développement logiciel • ISO 9126 : les caractéristiques qualité produit • ISO 15504 SPICE : la maturité des organisations • Choisir quelques métriques incontestables • Volume de programmation ; Comptage des points de fonctions • Volume et nombre de tests ; nombre de défauts découverts • Taux de retouches et maturité des référentiels

22. Coût Fixé par le client dès le début. Le coût détermine l’effort jugé nécessaire pour réaliser le logiciel ; s’exprime en hommean ou en hommemois.  Le paramètre coût peut être imposé par le MOA Qualité Dépend des actions du chef de projet MOE, et en particulier de l'effort de vérification, validation et test (VVT); en théorie, elle est fixée dès que le plan qualité est approuvé, généralement en début de projet (Cf. Check-up FURPSE).  Il est particulièrement malvenu et maladroit de réviser la qualité à la baisse en cas de retard ! La VVT est fonction de ce qui est réellement exécuté par la plate-forme (i.e. les instructions écrites+celles générées). Délai Fixé par le client qui en général synchronise le travail avec d'autres projets ; le délai peut varier en cours de projet.  Pour tout projet il existe un délai optimum « temps de cuisson ». Fonctionnalités Caractérise le service rendu (i.e. fonctions offertes) proposé par le maître d’œuvre à son client ; les fonctionnalités peuvent souvent être négociées en contre partie du coût et du délai ; s’expriment en nombre de points de fonctions (PF) ou en nombre de milliers de lignes source (KLS).  On ne compte que ce qui est réellement écrit par les programmeurs. Les grandeurs fondamentales CQFD(selon le Vade-mecum du chef de projet)

23. Le cadre méthodologique de l’estimation Cycle de vie système/logiciel Modèle d’estimation C/ effort Q/ mesurée F/ livrées D/ réactivité Architecture produit/système • Stratégie VV&T • Contrat de service, • Coût/efficacité de l’intégration • Maturité : • Système cible besoins stabilisés, • Environnement système  maturité des technologies, • Équipes de développement  maturité des acteurs, courbes d’expérience. • Connaissance des • scénarios d’emploi, • flux d’information

24. À partir de quoi fait-on une estimation : les 4 grandeurs caractéristiques C Q F D Perturbations « Usine » logicielle Processus de développement F, Q F', Q' F : fonctionnalités en tant que besoin Q : qualité de service (QOS) en tant qu’exigences F' : fonctions livrées en langage informatique (+ documentation et tests) Q' : qualité de service (QOS) effectivement mesurée (Disponibilité, courbe de maturité, taux de défauts) Ressources C sur une durée D {savoir-faire, expérience de l’équipe, management et organisation}

25. Dynamique des processus Indicateur d’avancement du processus (+ critère de terminaison) Forme mathématique d’une courbe en S Volume de code (Couverture C1 95%) 2ème estimation Approximation linéaire Pentes quasi identiques 1ère estimation Défauts résiduels Expression différentielle Retard final Retard de programmation Effort L’effort de vérification n’est pas proportionnel au volume de programmation  Attention à l’amplification due à la forme de la courbe en S

26. Délai optimum : L’effectif augmente comme l’inverse de la compression  ! Les communications augmentent comme N2 ou 2N !!! Conclusion : le rendement s’effondre Compression des délais (1/2) Effectif N/ p2 N p1 D/3 2D/3 Délai D D Compression 

27. Variation de la pente de la courbe de montée en charge : Capacité à assurer la montée en charge ??!! Communications ??!! Compression des délais (2/2)

28. L'ORGANISATION (1/2) • PARAMÈTRE TRÈS IMPORTANT MAIS ÉMINEMENT VARIABLE • UNE ORGANISATION INADAPTÉE EST UNE CONDITION SUFFISANTE D'ÉCHEC • LE BUT D'UNE ORGANISATION EST DE PRENDRE DES DÉCISIONS • ELLE PEUT ÊTRE: • CENTRÉE SUR LE PRODUIT • HIÉRARCHIQUE • CHAQUE PROJET EST TOTALEMENT AUTONOME • MATRICIELLE • CHAQUE PROJET PREND SES RESSOURCES DANS DES CENTRES DE COMPÉTENCES TECHNIQUES ET LES PARTAGE AVEC D'AUTRES PROJETS • CENTRÉE SUR LA SATISFACTION DU CLIENT • ORGANISATION EN RÉSEAU • TOUTE LA MÉTROLOGIE ET LE SUIVI SONT ORIENTÉS EN FONCTION DU BUT RECHERCHÉ • SAVOIR VIVRE ET S'ADAPTER • STRATÉGIES COOPÉRATIVES

29. L'ORGANISATION (2/2) • L'ORGANISATION EST UNE «MACHINE» À COMMUNIQUER • COMMUNICATION FORMELLE • STRUCTURE DE L'ACTIVITÉ  SYNTAXE • SENS / FINALITÉ DE L'ACTIVITÉ  SÉMANTIQUE • PERTINENCE  PRAGMATIQUE • COMMUNICATION INFORMELLE • VERBALE, EXPÉRIENCE, PARADIGME CULTUREL • ÉCRITE • BRUIT • TOUT CE QUI N'EST PAS DIRECTEMENT UTILE AU PROJET • RÉGULATION • ÉLIMINATION DES PARASITES PAR INTRODUCTION DE FILTRES ET DE REDONDANCES • ATTENTION À LA DUALITÉ SYSTÈME / MÉTASYSTÈME • LE CHEF DE PROJET EST UN NOEUDLE BON MESSAGE AU BON DESTINATAIRE • ACQUITTEMENT DES MESSAGES (Bien Reçu, Bien compris, Bien exécuté) • FILTRAGE ET TEMPORISATION; ÉLIMINATION DU BRUIT

30. LA PLANIFICATION (1/2) • PREND EN COMPTE LES CONTRAINTES • LOGIQUES (CYCLE DE VIE) • TEMPORELLES (JALONS / MILESTONES) • MÉTHODE DE CALCUL POUR PLACEMENT OPTIMAL • ALGORITHMES RO • DÉPENDENCE ENTRE ACTIVITÉS • Voir le détail en annexe A1 A2 Lien FIN - DÉBUT Lien DÉBUT - DÉBUT Lien FIN - FIN Lien DÉBUT - FIN

31. LA PLANIFICATION (2/2) • LA PLANIFICATION RÉPOND AUX QUESTIONS • QUELLES SONT LES DATES LOGIQUEMENT POSSIBLES? • QUELLES SONT LES MARGES? DATES AU PLUS TÔT / AU PLUS TARD? • QUELLES SONT LES ACTIVITÉS À MARGE NULLE? • QUELLE EST L'INCIDENCE SUR LE PLAN GLOBAL D'UN RETARD SUR TELLE ACTIVITÉ À MARGE NULLE? • COMMENT GÉRER AU MIEUX LES CONGÉS? • LES GRAPHIQUES DE PLANIFICATION • RÉSEAUX LOGIQUES • C'EST LE GRAPHE DES TÂCHES À EXÉCUTER • SPECTACULAIRE, MAIS PEU UTILE EN PRATIQUE • GANTT • DONNE LA VISION CALENDAIRE DES ACTIVITÉS • C'EST L'OUTIL FONDAMENTAL DU CHEF DE PROJET

32. EXEMPLE DE LIENS Programmation + TU de A1 Intégration de A1 La programmation de A1 et A2 DOIT démarrer au même instant Programmation + TU de A1 Programmation + TU de A2 La programmation de A1 et A2 DOIT se terminer au même instant, par exemple pour être intégrés simultanément Programmation + TU de A1 Programmation + TU de A2 Les tests unitaires de A1 ne peuvent pas démarrer avant le début de la programmation, mais la programmation ne peut pas être déclarée terminée avant la fin des tests unitaires de A1 Programmation de A1 Tests unitaires de A1

33. L'ORDONNANCEMENT (1/2) • L'ORDONNANCEMENT PREND EN COMPTE • LA GESTION DU TEMPS CALENDAIRE • LA GESTION DES RESSOURCES HUMAINES • EN QUANTITÉ  IL Y A x DÉVELOPPEURS DE DISPONIBLES • EN QUALITÉ  FORMATION, EXPÉRIENCE • LA GESTION DES AUTRES RESSOURCES • MATÉRIEL, APPAREILS, OUTILS LOGICIEL, AGL, DÉTACHEMENT D'UN EXPERT, ... • L'ORDONNANCEMENTCOMBIEN DE PERSONNES DOIT-ON / PEUT-ON AFFECTER SUR LE PROJET? • QUELLES SONT LES DATES EFFECTIVES PRÉVISIBLES? • QUEL EST L'IMPACT D'UNE PERSONNE SUPPLÉMENTAIRE? DU DÉCALAGE DES CONGÉS DE x OU y ? • QUELLE EST LA COURBE DE CHARGE PAR PHASE DU PROJET? • L'ORDONNANCEMENT PROCÈDE PAR SCÉNARIOS • VALIDER DES HYPOTHÈSES, OPTIMISER LES RESSOURCES, MINIMISER LES RISQUES, MAXIMISER LE PROFIT

34. L'ORDONNANCEMENT (2/2) • LES RÉSULTATS PRINCIPAUX • PLANNING DÉTAILLÉ DES PERSONNES • GÉNÉRATION DU GANTT • ANTICIPATION ET PRÉVISION • COURBE DE CHARGE DES DIFFÉRENTES RESSOURCES • REND VISIBLE LES ASPECTS CINÉMATIQUES ET DYNAMIQUES DU DÉVELOPPEMENT • ANALYSE ET OPTIMISATION DE LA COURBE DE CHARGE • QUELQUES PHÉNOMÈNES INTÉRESSANTS • MONTÉE EN CHARGE  SEUILS D'IMPOSSIBILITÉ • APPRENTISSAGE, EXPÉRIENCE  ON A LA CHARGE, MAIS PAS LA PRODUCTIVITÉ • TURNOVER  BISEAUX • SEUIL / RATIO D'ENCADREMENT  EN DÉÇA D'UN CERTAIN SEUIL, LES PROBLÈMES NE SONT PLUS TRAITÉS • AMÉLIORATION DE LA COURBE • LISSAGE  ON DÉPLACE LES ACTIVITÉS À L'INTÉRIEUR DE LEUR MARGE POUR MINIMISER LES RUPTURES + OU - • NIVELLEMENT  ON DÉCALE LES ACTIVITÉS JUSQU'À TROUVER UNE RESSOURCE DISPONIBLE; ON SORT DES DÉLAIS IMPARTIS

35. LE SUIVI (1/3) • SUIVRE UN PROJET, C'EST: • MESURER L'ÉTAT RÉEL DU PROJET • COMPARER LE RÉEL ET LES PRÉVISIONS • ANALYSER LES ÉCARTS, LEURS RAISONS, LES TENDANCES • PRODUIRE LES SYNTHÈSES ET LES RAPPORTS D'AVANCEMENT POUR LES DIFFÉRENTS ACTEURS (MO, MOI, Direction Générale, ACQ,...) • PROPOSER DES ACTIONS CORRECTRICES • PRODUIRE UN NOUVEAU PLANNING • CONSERVER LES HISTORIQUES • PÉRIODICITÉ • À AJUSTER EN FONCTION DE LA TAILLE, DE L'AVANCEMENT, DES RISQUES, ... CAR C'EST UNE OPÉRATION LOURDE • UNE TROP GRANDE FRÉQUENCE EST À ÉVITER • BRUIT DE FOND CONSIDÉRABLE, BUREAUCRATIE • LE CHEF DE PROJET FAIT DE LA GESTION DE PROJET ET NE S'OCCUPE PLUS DU PROJET

36. LE SUIVI (2/3) • ANALYSE DES RETARDS • ON NE PRODUIT PAS À LA VITESSE INITIALEMENT PRÉVUE • ON A SOUS-ESTIMÉ LA DIFFICULTÉ • LES RESSOURCES N'ONT PAS ÉTÉ ALLOUÉES AU NIVEAU PRÉVU • MACHINE, QUALIFICATION ET FORMATION DES DÉVELOPPEURS • L'ENVIRONNEMENT GÉNÉRE TROP DE PERTURBATIONS • MANQUE DE SOLIDARITÉ / DÉSACCORDS AU SEIN DE L'ÉQUIPE DE RÉALISATION • ON A SOUS-ÉVALUÉ LA CHARGE DE TRAVAIL ET / OU LES RESSOURCES NÉCESSAIRES AU PROJET • IL FAUT RÉESTIMER EN FONCTION • DE LA MEILLEURE CONNAISSANCE QUE L'ON A DU PROJET • DES RÉSULTATS OBTENUS • DE SCÉNARIOS PLUS RÉALISTES • LA PRÉCISION DE L'ESTIMATION DOIT S'AMÉLIORER AU FUR ET À MESURE DE L'AVANCEMENT • LA DÉRIVE • LE COEFFICIENT DE RETARD EST CONSTANT • LE COEFFICIENT DE RETARD AUGMENTE

37. LE SUIVI (3/3) Production (Selon le type de tâche) Trajectoire réelle observée 1er cas Dérive constante : T / T = K0 Problème de productivité Trajectoire initiale estimée 2ème cas Dérive croissante : T / T = K1 + K2T Problème de complexité non maîtrisée (Il s’agit en fait d’une courbe en S ; l’accélération de la dérive fait que la production stagne sur l’asymptote de la courbe, le projet ne progresse plus). Écart en production TA TA TB Temps normalisé (analogue à un effort) Retard calendaire Accélération de la dérive

38. LES FACTEURS HUMAINS • C'EST LE FACTEUR ESSENTIEL DE LA GESTION DE PROJET • QUELQUES CAUSES SUFFISANTES D'ECHEC • LES DONNÉES SONT UTILISÉES POUR JUGER LES PERSONNES • LES TÂCHES / RESPONSABILITÉS NE SONT PAS CLAIREMENT ATTRIBUÉES • LES MÉTRIQUES ADOPTÉES SONT BUREAUCRATIQUES ET NE MESURENT PAS LES ASPECTS ESSENTIELS DE L'ACTIVITÉ • ÊTRE NÉGATIF ET CULPABILISER SANS CESSE LES COLLABORATEURS • NE PAS TENIR COMPTE DES INFORMATIONS REMONTÉES PAR L'ÉQUIPE • NE PAS TENIR L'ÉQUIPE INFORMÉ DE L'AVANCEMENT Les données ne sont pas des mesures au sens mathématiques; elles doivent toujours être interprétées. Elles doivent être: PRÉCISES FIDÈLES RÉGULIÈREMENT COLLECTÉES La rétroaction sur l'équipe est indispensable pour améliorer le processus. EQUIPE 1 FOIS PAR SEMAINE CHEF DE PROJET ENVIRONNEMENT

39. Annexe 1 Aspects combinatoires liés à la décomposition hiérarchique des tâches et à l’ordonnancement des activités

40. Types et états d’une tâche • Deux catégories principales de tâches • Tâches qui délivrent un élément du référentiel projet • Exemple : un document de conception, un module de programmation, un jeu de tests, etc. • Tâches qui délivrent une appréciation résultant de la satisfaction ou non d’un ou plusieurs critères qualité  événement de terminaison, franchissement d’une étape, etc. • Exemple : le document à été relu par un expert, le programme a été inspecté, tel série de tests a été exécutée, etc. • État d’une tâche • En cours de réalisation • Cet état peut lui même se subdiviser en différents état (défini, créé, démarré, … ) • Terminé (en fonction d’un certain critère), d’où la gradation : • Validée (la tâche satisfait les critères VVT et S du modèle VEST) • Intégrée (en fonction des niveaux d’intégration requis par l’intégration système) • Recettée (satisfaction des critères de l’organisation cible) • Livrée (satisfaction des critères d’exploitation et de maintenance) • Utilisée (au moins 1 site utilise le livrable de la tâche)

41. États d’un processus et/ou d’une tâche projet Le processus est interrompu pour une raison quelconque mais de durée brève par rapport à la durée nominale du processus Interrompu Les ressources attribuées à la tâche sont restituées au projet, ou réaffectées à un autre projet. + Archivage de l’historique On sait précisément ce qu’il y a à faire et comment le faire Les ressources nécessaires au déroulement de la tâche sont attribuées En cours Actif Terminé Défini Créé Démantelé La livraison des résultats de la tâche est effectuée conformément aux objectifs qualité du projet Suspendu Le processus est suspendu pour une raison quelconque mais de durée significative par rapport à la durée nominale du processus  Histoire de ce processus = gestion du projet correspondant

42. État d’un groupe de tâches • Une tâche T est le résultat du couplage de 2 tâches T1 et T2 • Problème : T1 et T2 sont dans différents état de Début (D) / Fin (F), quel est l’état D / F de T ? • Cela revient à énumérer tous les types de dépendances qui peuvent exister entre T1 et T2 • Exemples : • la dépendance FinDébut correspond à l’état où T2 ne peut commencer que si et seulement si T1 est terminée (ou inversement) • la dépendance Fin Fin correspond à l’état ou T2 ne peut être déclarée F, que si et seulement si T1 est elle même F (et inversement) • Le nombre de mapping {D,F},{D,F}  {D,F} est égal à 16, mais comme il y a symétrie des tâches, il n’y a que 8 mapping intéressants • Exemple : • Le mapping T1{D,F},T2{D,F}  D correspond à la situation où le couplage de T1  T2 n’est pas fini, quand bien même les tâches unitaires le soient ; dans le cas de tâches de programmation cela correspondrait à la propriété d’être intégrée (c’est une 3ème tâche) • Piège : attention à la sémantique des liens de dépendances implémentée dans les outils de gestion de projet

43. Relations temporelles et recouvrement entre 2 tâches  > 0 T1 T2 T2 successeur de T1 avec un intervalle  > 0 Cas 1 Temps  = 0 T1 T2 successeur de T1 avec un intervalle  = 0 Cas 2 T2  < 0 T1 T2 successeur de T1 avec un intervalle  < 0 (recouvrement) Cas 3 T2 T1 T1 et T2 synchronisées sur leur F respective Cas 4 T2 T1 T2 complètement inclue dans T1 avec marges Cas 5 T2 T1 T1 et T2 synchronisées sur leur D respectif Cas 6 T2 T1 T1 et T2 totalement synchronisées (correspond à cas 5 sans marge) Cas 7 T2 Exercice : Interpréter les mapping {D,F} en termes de relation temporelles ?

44. Sémantique des liens de dépendance selon le PMI • Le Project Management Institute (PMI) recommande les 4 dépendances suivantes entre 2 tâches T1 T2 : • Fin-Début • T1 doit être finie pour que T2 puisse démarrer • Fin-Fin • T1 doit être finie avant que T2 puisse finir (T2 est finie si et seulement si T1 est finie) • Début-Début • T1 doit démarrer avant que T2 puisse démarrer (T2 démarre si et seulement si T1 est déjà démarrée) • Début-Fin • T1 doit démarrer avant que T2 puisse se terminer (T2 est finie si et seulement si T1 a déjà démarrée) • On peut imaginer d’autres types de dépendance et de synchronisation • Faire attention à la sémantique proposée par les outils de gestion de projet • Dans la réalité, le couplage peut également impliquer 3 tâches, ou plus ! Mais les outils ne considèrent que les couplages simples de 2 tâches.

45. Couplage de modules et valeurs de véritéAnalogie avec les tâches projets • Pour 2 modules M1 et M2 il y a 16 fonctions logiques telles que • Pour n modules, le nombre de fonctions est • Si la logique est modale, avec une valeur de vérité correspondant à indéfini, on a un nombre de fonctions égal à : Données d’entrée Couplage M1M2 M1 M2 {V,F} {V,F} {V,F} • Moralité : il suffit de changer le mode de couplage(sans modifier la programmation) pour observer des comportements très différents en cas de défaillance