GESTION DE PROJET LOGICIEL

Présentation au sujet: "GESTION DE PROJET LOGICIEL"— Transcription de la présentation:

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 T Tâche projet à effectuer S Tâche(s) amont Tâche(s) aval 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 PE PI Domaine des valeurs en entrée
SUPERVISION Flux de contrôles et de commandes PE Pilote Externe  Responsable projet Pilote Interne  Responsable de tâche PI Domaine des valeurs en entrée Données du processus Résultats du processus Domaine des valeurs en sortie 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 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 Allocation 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
Faisabilité Définition Développement et MCO Retrait 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 : > ans, mais > 30 pour les grands systèmes technologiques

6 DÉTAIL DU CYCLE DE DÉVELOPPEMENT (1/3)
RETOUR D’EXPÉRIENCE Expression de besoin /Exigences Axe d’évolution Processus de DEVELOPPEMENT Axe d’évolution 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 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 Qualification 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 VVT Nombre de RA/AC 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 CCG, DCG CCD, DCD 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 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
STRUCTURATION ÉNUMÉRER TOUS LES TRAVAUX À FAIRE AUSSI PRÉCISEMMENT QUE POSSIBLE ESTIMATION DÉTERMINER À L'AVANCE LES QUANTITÉS / QUALITÉS DE RESSOURCES NÉCESSAIRES AUX DIFFÉRENTES TÂCHES ORGANISATION AFFECTER LES RESSOURCES RÉELLES, DÉFINIR LES RESPONSABILITÉS, RÉPERTORIER LES CONTRAINTES D'EXÉCUTION LIÉES À L'ENVIRONNEMENT PLANIFICATION DÉTERMINER LES DATES CLEFS VIS À VIS DU MO ET DU MOI; ANALYSE ET IDENTIFICATION DES RISQUES ORDONNANCEMENT DÉFINIR L'ENCHAÎNEMENT DANS LE TEMPS DE TOUTES LES TÂCHES, LA SYNCHRONISATION, L'AFFECTATION FINE DES RESSOURCES, LES PRIORITÉS SUIVI MESURER ET CONTRÔLER RÉGULIÈREMENT L'AVANCEMENT RÉEL PAR RAPPORT AUX PRÉVISIONS; RENDRE COMPTE

15 LA STRUCTURATION (1/2) LES PRÉREQUIS: NOTION D'ARBRE PRODUIT
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 ÉTUDE TECHNIQUE COMPLÈTE SUIVI DE LA RÉALISATION
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 : le processus de développement logiciel ISO 9126 : les caractéristiques qualité produit ISO 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 Les grandeurs fondamentales CQFD (selon le Vade-mecum du chef de projet)
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.

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 Processus de développement
À 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 Compression des délais (1/2)
Effectif Délai optimum : L’effectif augmente comme l’inverse de la compression  ! Les communications augmentent comme N2 ou 2N !!! Conclusion : le rendement s’effondre N/ p2 N p1 D/3 2D/3 Délai D D Compression 

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

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 de A1 Tests unitaires de A1 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

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: PÉRIODICITÉ
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) 1er cas Dérive constante : T / T = K0
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 Défini Créé En cours Actif Terminé Démantelé Suspendu La livraison des résultats de la tâche est effectuée conformément aux objectifs qualité du projet 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 Cas 1 T2 successeur de T1 avec un intervalle  > 0 Temps  = 0 T1 Cas 2 T2 successeur de T1 avec un intervalle  = 0 T2  < 0 T1 Cas 3 T2 successeur de T1 avec un intervalle  < 0 (recouvrement) T2 T1 Cas 4 T1 et T2 synchronisées sur leur F respective T2 T1 Cas 5 T2 complètement inclue dans T1 avec marges T2 T1 Cas 6 T1 et T2 synchronisées sur leur D respectif T2 T1 Cas 7 T1 et T2 totalement synchronisées (correspond à cas 5 sans marge) 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
Données d’entrée 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 à : 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