univ-lr.fr

Présentation au sujet: "univ-lr.fr"— Transcription de la présentation:

1

2 pascal.estraillier @ univ-lr.fr
Gestion de Projets Master IMA univ-lr.fr Département Informatique - Laboratoire L3i Université de La Rochelle

3 Description de l’activité (on apprend que sur le terrain)
La gestion de projet Description de l’activité (on apprend que sur le terrain) OBJECTIFS: Introduction de l’activité et de ses caractéristiques Décrire et discuter l’activité de planification Montrer l’utilisation de représentations graphiques dans cette activité

4 Gestion de projet : définitions
Organisation, planification et établissement des échéances d’un projet (logiciel) Regroupement des activités assurant que le logiciel est livré dans les temps en accord avec les exigences des organismes impliqués C’est une activité importante!!! le GL est une activité économique (qui donc implique des contraintes non techniques) Les projets bien gérés échouent parfois, les projets mal gérés échouent toujours

5 Les activités de la gestion de projet
Rédaction de propositions Evaluation du coût des projets Planification et construction de l’échancier du projet Pilotage et révision (contrôle des évolutions) du projet Recrutement et évaluation du personnel Rédaction de rapports et préparation de présentations Observations sur ces activités Elles ne sont pas propres à la gestion de projets logiciels Les techniques d’ingéniérie classique sont applicables au Génie logiciel et vice-versa Les projets complexes (bâtiment etc) souffrent de problèmes similaires à ceux du Génie Logiciel

6 Gestion de projets : les risques
Echecs de projets dûs à des facteurs technique, mais la plupart des échecs viennent aussi des facteurs de gestion causes typique pour l’échec d’un projet: estimation de temps trop basse productivité des programmeurs plus basse que prévue une manque de connaissance de l’avancement actuel, peut-être à cause des comptes inexacts un manque de connaissance des besoins réels on a pas prévoit assez de temps pour concevoir le projet La conception et l’entretien d’une planification sont indispensables

7 Un plan de projet définit (1)
ce qu’on va construire un contexte et sommaire du système, et le but éssentiel (de point de vue de l’entreprise) le processus il faut qu’on choisisse un modèle du cycle de vie cohérent aux objectifs du projet des méthodes ou techniques spéciales et les outils necessaires la structure les rôles et responsabilités des membres d’équipe, et les relations entre l’équipe et autres organisations externes (y compris le client)

8 Un plan de projet définit (2)
les normes, directives et procédures très important pout les projets fait par une contracteur externe il faut identifier les questions de documentation de façon assez précise les activités d’administration les rôles et responsabilités d’équipe de gestion y compris les reports d’avancement et le gestion des risques les risques l’identification et classification des risques au projet et les strategies d’attenuation la qualité comment s’assurer des besoins de la qualité

9 Un plan de projet définit (3)
les ressources le matériel, les outils, et l’appareillage d'essai les types et nombres de personnel requis les lots de travaux la division du travail en morceaux maniable le budget et le programme une allocation des fondes et du temps aux lots de travaux les techniques d’estimation et de traquage le gestion des changements les procédures claires pour s’occuper des changements

10 Principles de base crée de façon itérative et entretenue
on commence par trouvant une piste des besoins vagues aux besoins précis on crée un plan conceptuel du produit chaque fois que les besoins deviennent plus précis, on raffine les estimations et le programme quand les besoins deviennent clairs, on élabore une conception détaillée et une strategie d’exécution et les incorpore dans le plan le plan fournit une structure avec laquelle on peut négocier pour les ressources et le temps nécessaires

11 Il faut se souvenir que …
les premiers estimations des ressource et du programme sont presque toujours inacceptables il faut réduire l’ampleur , augmenter le temps ou les ressources on a toujours besoin des entités avant qu’il soit possible de les avoir Alors : le plan devient un processus de négociation entre les désirs et les ressources du client il faut conclure la négociation aussitôt que possible

12 Les paradoxes du contrôle
si on ajoute des programmeurs au projet, la productivité va presque certainement diminuer “… More fire requires more gasoline, and thus begins a regenerative cycle which ends in disaster” Fred Brooks d’habitude, l’insistance de haute qualité aide à réduire le tempsŝ nécessaire pour achever le projet si on a plus de temps pour le projet, on crée parfois un système moins utile

13 Rédaction de plan de développement du logiciel
Norme DOD-STD-2167A (Software Development Plan) 1) couverture 2) Page de titre 3) Table des matières 4) Domaines d’application 5) Documents cités en références 6) Gestion du développement du logiciel 7) Génie Logiciel 8)Test de qualification officielle 9) Evaluation du produit logiciel 10) Gestion des configurations du logiciel 11)Autres fonctions de développement du logiciel 12) Notes 13) Annexes

14 Permettre une classification rapide et aisée du document
2) Page de titre Numéro de contrôle du document Date Numéro de révision et date Titre Référence du système (<identification>) Référence du contrat (<identification>, <nom du client>) Auteur Authentifié par <donneur d’ordre>, <date> Approuvé par <fournisseur>, <date> Permettre une classification rapide et aisée du document

15 4) Domaine d’application
Identification numéro d’identification du projet (éventuellement abréviation) Généralités sur le système Rôle du système faisant l’objet du développement Généralités sur le document Objectif et résumé du contenu du document Liens avec les autres plans plan de gestion des configurations du système plan d’archivage du logiciel plan du programme qualité plan de tests du logiciel plan de gestion technique du système

16 6) Gestion du développement du logiciel
Identification des ressources du projet inventaire des ressources nécessaires (locaux, matériels et logiciels) structure organisationnelle (rôle et responsabilité des acteurs) personnels Echéanciers et jalons (activités (Gantt) et réseau d’activités (Pert)) Gestion des risques (domaines à risques, facteurs, procédures de contrôle et d’urgence) Interface avec les partenaires (contractants associés, sous-traitants) Revues formelles Bibliothèque de développement du logiciel (procédures et méthodes) Processus d’actions correctives et rapports d’anomalies

17 7) Génie Logiciel Organisation des ressources
Structure organisationnelle de développement (autorité et responsabilité des partenaires) personnel (titre et qualification, exigences spécifiques) environnement de génie logiciel (outils automatisés et matériel) Normes et procédures applicables techniques et méthodologies pour chaque étape du cycle de vie fichiers de développement du logiciel (opérations et contraintes, documentation, échéancier, tests et jeux d’essais,...) Logiciel non développé inventaire et justification des logiciels du marché et des logiciels réutilisés envisagés

18 Recrutement du personnel
Problème: il est souvent difficile de recruter le personnel “idéal” sur un projet Budget: impossible de payer les gens à la hauteur de leur qualification Indisponibilité: impossible de trouver des gens ayant l’expérience appropriée sur le marché Stratégie: l’organisation peut souhaiter développer un savoir-faire propre sur un projet logiciel D’après I.Sommerville ©1995

19 Planification d’un projet
Probablement l’une des activités les plus chronophages Activité continue depuis le démarrage du projet jusqu’à la mise à disposition du produit Les planning doivent être régulièrement réactualisés (nouvelles contraintes) (nouvelles données) D’après I.Sommerville ©1995

20 Plans de projet Plan Description Plan qualité
décrit les procédures et standards mis en œuvre pour assurer la qualité du logiciel Plan de validation décrit l’approche, les ressources, les procédures et les échéances (tests, recettes) relatives à la validation du système Plan de gestion de la configuration Décrit les procédures de gestion de la configuration Plan de maintenance Décrit et prévoit les besoins de maintenance du système, les coûts et les efforts requis Plan de formation et de développement Décrit comment le savoir faire et l’expérience des ingénieurs seront développés D’après I.Sommerville ©1995

21 Le processus de planification
Définir les contraintes qui pèsent sur le projet Effectuer une première estimation des paramètres du projet (degrés de liberté) Etablir des échéances et des fournitures TANT QUE le projet n’est pas fini ou annulé FAIRE Etablir un planning du projet Démarrer les activités en fonction de ce planning ATTENDRE (durée déterminée) Faire une revue d’avancement du projet Re-estimer les paramètres du projet Appliquer ces révisions au planning du projet Re-négocier les contraintes et les fournitures (s’il y a lieu) SI problème ALORS démarrer une revue technique et une éventuelle révision FSI FTQ D’après I.Sommerville ©1995

22 Organisation des activités
Critères: L’organisation doit être effectuée en vue de produire des résultats tangibles du point de vue de l’évaluation les échéances marquent la fin d’une activité les fournitures sont des produits délivrés aux “clients” Activités Etude de faisabilité rapport de Analyse des besoins Cahier des charges Maquettage Rapport d’évaluation conception Conception générale Spécification D’après I.Sommerville ©1995 Echéances [+Fournitures]

23 Planification d’un projet
Division du projet en tâches séparées + estimation: des ressources requises pour les mener à bien de la durée nécessaire pour les accomplir Organiser les tâches en parallèle afin d’optimiser la puissance de travail de l’équipe Minimiser la dépendance entre tâches afin de limiter le nombre de tâches critiques suceptibles de retarder le projet Dépend de l’intuition et de l’expérience du chef de projet D’après I.Sommerville ©1995

24 Les problèmes de la planification
Estimation de la complexité d’un problème et du coût du développement de sa solution La productivité n’est pas proportionnelle à la taille de l’équipe Ajouter du personnel à un projet en retard risque fort d’engendrer un retard supplémentaire dû à un surcroit de communications L’inattendu arrive toujours, il faut donc savoir le planifier (et ménager de la marge) D’après I.Sommerville ©1995

25 Diagrammes et graphes d’activités www.er.uqam.ca/nobel/d201020/
Notations graphiques & planification d’un projet Un graphe d’activité indique: les inter-dépendances entre tâches dans le projet: les tâches ne doivent pas être trop courtes ordre de grandeur: de quelques jours à deux semaines le chemin critique entre les tâches Le diagramme indique: les responsables des tâches les dates de début et fin de ces tâches estimées (a priori) réelles (mesurées) Tableau de bord d’un projet D’après I.Sommerville ©1995

26 Exemple: Graphe des activités
Chemin critique D’après I.Sommerville ©1995 Gros projets => hiérarchisation de s tâches

27 Le graphique PERT «Program Evaluation and Review Technique»
aussi connu comme «planification par recherche du chemin critique» (Critical Path Planning) une exemple d’un réseau «activité sur noeud» le poids de chaque noeud est la durée d’activité une flèche d’un noeud A à un noeud B dit qu’il faut que A termine avant que B commence Gagne le contrat (0) Création du plan des tests (5) Conception de IUG (7) Codage de IUG (15) Testage de IUG (3) La bière (1) Étude d’usagers(5)

28 Une graphique PERT nous donne
le premier moment pour commencer une tâche étude d’usager - jour 0 conception d’interface - jour 5 le dernier moment pour commencer une tâche (sans délai inutile) création du plan de tests - jour 23 la date optimale de la terminaison du projet 31 jours ces valeurs ne sont pas tout à fait évidentes à partir du graphique; alors on a besoin d’une autre répresentation Gagne le contrat (0) Création du plan des tests (5) Conception de IUG (7) Codage de IUG (15) Testage de IUG (3) La bière (1) Étude d’usagers(5)

29 Le diagramme de Gantt représente la durée de chaque activité sur une graduation horaire on représente la précedence par la position de tâche: une tâche commence juste après les tâches nécessairement précendentes on peut voir la marge de chaque tâche si une tâche a de la marge, on peut la commencer plus tard que nécessaire les tâches sans marge sont sur le chemin critique les tâches ou activités avec une longeur de zero sont représentées comme jalons par exemple, le livraison d’un document

30 Exemple, diagramme de Gantt

31 activités sur le chemin critique
De PERT à Gantt Jours 5 10 15 20 25 30 dernier moment de commencement possible (22) 5 Gagne le contrat Étude d’usagers 5 Plan de tests 5 marge Conception d’IUG 7 Codage d’IUG 15 Testage d’IUG 3 Le bière 1 activités sur le chemin critique

32 Les outils il y a beacoup d’outils de planification qui peut crée ces graphiques, surtout le diagramme de Gantt par exemple, voir le progiciel ProjeX pour Excel à

33 Exemple: Diagramme d’affectation du personnel
D’après I.Sommerville ©1995

34 9) Evaluation du produit logiciel
Organisation et ressources Procédures et outils d’évaluation Produits de la sous-traitance Enregistrement des évaluations Evaluations de produits liées à une activité

35 10) Gestion des configurations du logiciel
Identification et rédaction des caractéristiques fonctionnelles et physique des articles de configuration organisation et ressources identification de configuration (documents pour le référentiel) procédures de maîtrise des configurations suivi des états des configurations audits de configuration jalons de la gestion des configurations

36 Organisation du travail, remarque 1
Le processus de développement est une suite d’opérations séquentielles parfois parallélisables entre elles Réalisation (ascendante) diminution du “parallélisme” Conception (descendante) augmentation du “parallélisme” STR (2,3) STR (2,2) STR (2,1) Analyse STR (3) STR (2) STR (1) Cahier des charges Intégration Module (1) Module (2) Module (3) Module (2,1) Module (2,2) Module (2,3) Application

37 Organisation du travail, remarque 2
Il est possible de “pipe-liner” le processus de développement en fonction des numéro de version des composants réalisation intégration éval. perf. module v0.0 module v0.1 module v0.2 module v0.3 module v0.4

38 Organisation du travail, remarque 3
“L’enfer, c’est les autres” Le travail en équipe implique une discipline Support par des outils (AGL) partage de données non respect des règles “turn over”

39 Points clefs Une bonne gestion de projet est essentielle pour réussir
La nature du logiciel pose des problèmes particuliers de gestion Les chefs de projet ont différents rôles mais le plus important consiste en la planification, l’estimation et la mise en place d’échéances Planification et estimation sont des activités itératives et continues pendant toute la durée du projet Une échéance est une date “prévisible” pour la présentation d’un rapport à la hiérarchie Utilisation de techniques graphiques pour faciliter l’activité d’évaluation

40 Conclusion: être un “chef de projet”
Difficile Compréhension des aspects techniques du projet (surtout s’il est vaste) Rapport à la hiérarchie (gestion des délais, coûts, évaluations diverses etc.) Beaucoup de “paperasse” Comment s’en sortir Etre un bon “public relation” Maintenir la cohésion d’une équipe Savoir se faire “respecter” Avoir une bonne culture informatique “sentir” les bonnes solutions faire des choix techniques sans appréhender un problème dans les détails