INTRODUCTION A LA GESTION DE PROJETS LOGICIELS

1. INTRODUCTION A LA GESTION DE PROJETS LOGICIELS

2. QUELQUES DONNEES ECONOMIQUES SUR LE COUT DES LOGICIELS VOLUME, EFFORT, DELAI, DUREE DE VIE L'EVOLUTION DE LA DEMANDE L'EVOLUTION DES COUTS NATURE DU RISQUE LOGICIEL

3. QUELQUES COUTS : COMPILATEURS PASCAL - C : 10 HA COBOL - FORTRAN : 80 à 100 HA ADA : 120 à 150 HA SGBD MODELE CODASYL (IDS2, IMS, IDMS, CLIO) : 150 à 200 HA MODELE RELATIONNEL (ORACLE, DB2,...) : 300 à 500 HA 1. VOLUME, EFFORT, DELAI, DUREE DE VIE (1)

4. GRANDS SYSTEMES TEMPS REEL NAVETTE SPACIALE : >1000 HA 2200 KLS 6 ans langage HAL SAFEGUARD : 5000 HA 2260 KLS 7ans langage type pl1 SABRE : 955 HA 960 KLS 10 ans MTTF 55h SYSTEMES D'EXPLOITATION MVS, VMS, GCOS7,... : 2500 à 5000 HA 5000 à 15000 KLS 15 à 20 ans 1.1 VOLUME, EFFORT, DELAI, DUREE DE VIE (2)

5. 1.1 VOLUME, EFFORT, DELAI, DUREE DE VIE (3) • SYSTEMES INDUSTRIELS TYPE MRP • GPAO : 400 HA COBOL • ATELIER FLEXIBLE : 50 à 100 HA PASCAL-C • GRAPHIQUE • 2D 3D : 50 à 150 HA FORTRAN • IA • LISP, PROLOG : 10 à 20 HA • MOTEUR D'INFERENCES: 20 à 30 HA • ATELIER DE GENIE LOGICIEL • ENTREPRISE, EAST : 150 à 200 HA C

6. ELLE RESTE MASSIVE TOUT CE QUI ETAIT ANALOGIQUE DEVIENT DIGITAL ET EST DONC CANDIDAT A ETRE TRAITE PAR ORDINATEUR Gestion électronique de documents et multimédia Images de synthèse, réalité virtuelle Compression de données, son Télécommunications, réseaux... LES SERVICES DEMANDES A L'INFORMATIQUE SONT EN AUGMENTATION CONSTANTE Automatisme et gestion des systèmes complexes (téléphonie, C3I, pilotes automatiques - projet METEOR...) Systèmes à fort volume de données (systèmes de facturation, ERP, PDM…) Systèmes de gestion de la connaissance Portails, places de marché, sécurité, mobilité 2. L'EVOLUTION DE LA DEMANDE

7. INVERSION COMPLETE DES COUTS HARDWARE/SOFTWARE A L'INTERIEUR DES COUTS SOFTWARE, PART DE PLUS EN PLUS GRANDE DES COUTS DE MAINTENANCE EMERGENCE DE LA RE-INGENIERIE DU LOGICIEL LE COUT HUMAIN EST DESORMAIS LE POSTE LE PLUS IMPORTANT 3. L'EVOLUTION DES COUTS

8. 4. NATURE DU RISQUE LOGICIEL • LA SURETE DE FONCTIONNEMENT DES LOGICIELS EST LE PROBLEME N° 1 DU GENIE LOGICIEL • RISQUES HUMAINS • COMMANDES DE VOL DES AVIONS • CONTRÔLE AÉRIEN, FERROVIAIRE, NUCLÉAIRE, etc. • RISQUES ECONOMIQUES • KRACH BOURSIER DE OCTOBRE 87 • EFFONDREMENT DU RESEAU ATT SUR LA COTE US EST • RISQUES SOCIAUX • LE SYSTEME SOCRATE DE LA SNCF • CONFIDENTIALITE DES INFORMATIONS • VIRUS ET "CHEVAUX DE TROIE »

9. GENERALITES

10. 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  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 ÉVÉNEMENT FIN TÂCHES À RÉALISER Logiciel opérationnel Cahier des charges du futur utilisateur RESSOURCES DÉLAI = T2 - T1

11. CYCLE SYSTÈME - CYCLE DE DÉVELOPPEMENT Développement Retrait Faisabilité Définition Nombre de RA/AC Durée Version N°1 Exploitation Réalisation de prototypes Version N°2 Exploitation Cycles de développement Réalisation de maquettes Version N°n Exploitation Durée d’un cycle : > 15-20 ans, mais > 30 pour les grands systèmes technologiques

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

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

14. DÉTAIL DU CYCLE DE DÉVELOPPEMENT (3/3) CCD, DCD CCG, DCG CQFD global du projet 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

15. PARAMÈTRES DU MODÉLE CQFD • COÛT • C'EST LE PRIX D'ACQUISITION FIXÉ PAR LE CONTRAT (i.e. nombre d’HA) • QUALITÉ • CE QUI CORRESPOND AUX CARACTÉRISTIQUES NON-FONCTIONNELLES SELON ISO-9126 (i.e. exigences pour satisfaire le contrat de service) • FACILITÉ D'EMPLOI • FIABILITÉ (i.e. Sûreté de fonctionnement) • PERFORMANCE / RENDEMENT • MAINTENABILITÉ (i.e. Maintien en condition opérationnelle - MCO) • PORTABILITÉ (i.e. évolution, migration sur d ’autres plates-formes, réutilisation) • FONCTIONNALITÉ • C'EST LA CARACTÉRISTIQUE CAPACITÉ FONCTIONNELLE SELON ISO-9126 • DIRECTEMENT ISSUE DE L'EXPRESSION DE BESOIN (ANALYSE DES FLUX, ANALYSE FONCTIONNELLE ISSUS DU MODELE D’ENTREPRISE) • EN FIN DE REALISATION CE SONT LES LIGNES DE CODE, OU LES POINTS DE FONCTIONS • DÉLAI • DURÉE DE LA RÉALISATION URPSE

16. 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)

17. 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 • 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 (RAREMENT > 2-3 ANS) • GESTION DE LA COMPLEXITÉ • ASPECTS STATIQUES  CE QUE L'ON VOIT • ASPECTS DYNAMIQUES  CE QUI S'EXÉCUTE

18. INTERACTIONS AVEC L'ENVIRONNEMENT Analyse des risques Evaluation Suivi Maître d'Oeuvre Industriel (MOE) Maître d'Ouvrage (MOA) 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

19. PROCESSUS DE GESTION DE PROJET

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

21. 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 MOA / MOE • POUR 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

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

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

24. EXEMPLE ARBRE PRODUIT / OT (2/2) Expression de besoins (T0) Conception générale (T1) SAISIE SAISIE Conception détaillée (T2) LOGICIEL SAISIE LOGICIEL SAISIE Programmation (T3) Temps Tests unitaires (T4) Intégration (T5) 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 D ’INTÉGRATION DE LOGICIEL 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.

25. 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 • POINTS DE FONCTION, CONSENSUS D'EXPERTS, GROUPE DELPHI

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

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

28. 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, ERGONOMIE  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 NŒUD QUI TRANSMET LE BON MESSAGE AU BON DESTINATAIRE • ACQUITTEMENT DES MESSAGES (Bien Reçu, Bien compris, Bien exécuté) • FILTRAGE ET TEMPORISATION; ÉLIMINATION DU BRUIT

29. LA PLANIFICATION (1/3) • 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? • QUELLE EST LA DUREE TOTALE DU PROJET? • LES GRAPHIQUES DE PLANIFICATION • RÉSEAUX LOGIQUES - PERT • 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

30. LA PLANIFICATION (2/3) • 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 A1 A2 Lien FIN - DÉBUT Lien DÉBUT - DÉBUT Lien FIN - FIN Lien DÉBUT - FIN

31. 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 La documentation de A1 ne peut 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 de la documentation de A1. Programmation de A1 Documentation de A1 EXEMPLE DE LIENS LA PLANIFICATION (3/3)

32. 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'ORDONNANCEMENT REPOND AUX QUESTIONS • COMBIEN DE PERSONNES DOIT-ON / PEUT-ON AFFECTER AU PROJET? • QUELLE EST LA COURBE D ’EFFORT PAR PHASE DU PROJET? • QUELLES SONT LES DATES EFFECTIVES PRÉVISIBLES? • COMENT GERER LES CONGES DE MANIERE OPTIMALE? • QUEL EST L'IMPACT SUR LE PROJET D'UNE PERSONNE SUPPLÉMENTAIRE? DU DÉCALAGE DES CONGÉS DE x OU y ? DE L ’ABSENCE IMPREVISIBLE D ’UNE PERSONNE? • L'ORDONNANCEMENT PROCÈDE PAR SCÉNARIOS • VALIDER DES HYPOTHÈSES, OPTIMISER LES RESSOURCES, MINIMISER LES RISQUES, MAXIMISER LE PROFIT

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

34. 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 (MOA, MOE, 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

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

36. En réalité, le produit est une fonction en escalier LE SUIVI (3/3) Production T / T = K0 Trajectoire réelle Trajectoire estimée Dérive constante T / T = K1 + K2T Dérive croissante Écart en production Accélération de la dérive TA TA Temps Retard calendaire

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