Gestion de Projet

1. Gestion de Projet Gestion de Projet Contact: Yossi Gal, Email:y-gal@ti.com, Téléphone: 04 9322-2339

2. A propos du cours • Objectif: Sensibiliser les étudiants à l'utilisation d'une méthodologie pour gérer les projets informatiques. • Durée: Cours et TP durant lesquelles seront exposés les concepts de base de la méthodologie, et ensuite la mise en pratique à travers des TP en classe et sur machine. Il y aura également des séances de soutenance des projets. • Support de Cours: Copie des présentations et liste des taches. • Présence: Cours et TP sont obligatoires. La gestion du projet est une part importante dans la note globale du projet d'entreprise.

3. Plan Du Cours • Les Concepts de Base • Les Composants de Base d ’un Projet • Les Documents de la méthodologie • La liste des taches par activité • TP/Planning avec MS Project • Questions/Contacts

4. Les Concepts de Base • Introduction • La problématique des Systèmes d ’Informations et des Projets Informatiques • C’est quoi une Méthodologie et a quoi sert - elle ? • Un Processus Immature/Un Processus Mature • SEI - Software Engineering Institute, CMM et les 5 Niveaux de Maturité • Avant et Après la mise en place d’une méthodologie • La pyramide de la qualité

5. Introduction • Objectif: Définir et appliquer un ensemble de règles et de procédures pour la conduite des projets informatiques. • La méthodologie est basée sur les Concepts de Base développés par le  Software Engineering Institute (SEI) . • Et sur une application pratique le  Software Process Improvement  (SPI) utilisé à Texas Instruments pour la gestion des projets informatiques. • Le guide de référence pour cette méthodologie est le Software Process Handbook (SPH). • La Méthodologie s ’intéresse au Processus (La qualité de la Démarche) et non au contenu qualitatif du Produit

6. La problématique des Systèmes d ’Informations • Produire des systèmes d ’information présente toujours des aspects problématiquesà l’entreprise • Les Systèmes sont devenus un facteur clé dans la stratégie des entreprises • De fortes demandes relatives à la réduction du cycle de vie, la réduction des coûts, et l ’amélioration de la qualité • Changement rapides des technologies de l’Information et Augmentation continue dans la complexité des produits • Les entreprises font de plus en plus appel à la sous-traitance pour développer et maintenir leur systèmes d’informations (Outsourcing).

7. La Problématique des Projets Informatiques • La majorité des projets réalisés dans les grandes entreprises américaines n’ont que 42% des fonctionnalités d’origines • 53% des projets de développement dépassent leur budget initial dans une proportion de 90% ou plus • Seuls 16% des projets se terminent dans les temps et dans la limite du budget alloué • La maintenance des Projets est complexe et coûte chère à l ’entreprise. • Les Informaticiens n’ont pas à leur disposition des guides de référence avec des méthodes et des standards faciles à utiliser et complètement automatisés.

8. C’est quoi une méthodologie ? • C ’est une approche qui se focalise sur les activités et les procéduresà mettre en place afin de pouvoir délivrer des solutions logicielles pour l ’entreprise avec un haut niveau de qualité, dans les délais et les budgets prévus. • La méthode s ’intéresse à la qualité de la gestion du projet et àl'amélioration continue du processus mis en place pour la gestion des projets • Les solutions logicielles incluent la planification, le développement, la réutilisation, l’acquisition, l’évaluation, l’intégration, le renginnering, la portabilité, la maintenance, le Prototypage et la sous-traitance des projets informatiques.

9. A quoi sert une méthodologie • A comprendre comment les logiciels sont réellement développés • A prévoir et contrôler la qualité de ces logiciels, leur cycle de vie et leur budget • A pouvoir faire des estimations correctes en ce qui concerne les coûts et les bénéfices des solutions informatiques • A optimiser et valoriser l’utilisation du capital humain et matériel de l’entreprise • A mettre en place un programme d’amélioration continue utilisant l’expérience acquise dans le passé au service des développements futurs.

10. La Maturité d’un Processus • Un processus Peut être • Mature Ou • Immature

11. Un processus Immature • Improvisé, peu contrôlé, voir même chaotique • Fortement dépendant de ses exécutants, des talents individuels et des efforts héroïques qu ’ils sont prêts à consentir. • Très souvent on obtient des résultats imprévisibles • Les Tests et les revues de projets sont très réduits • Pas d’évaluation des charges, des délais et des coûts • Les erreurs des étapes passées ne sont pas exploitées pour l’amélioration des étapes ultérieurs • Le projet est subi et non géré

12. Un processus mature • Bien défini et bien documenté • Totalement contrôlé, avec des plans, le suivi de ces plans, leur communication aux équipes du projet et à la direction • Des Rôles et des Responsabilités clairs et bien définis • La qualité, les coûts et les délais sont prévisibles et mesurables • Se focalise sur l’amélioration du processus • Fait un bon usage des nouvelles technologies • Conduit à un Projet Géré et non subi

13. SEI - Software Engineering Institute • Le SEI est un groupe de recherche à l ’université Carnegie Mellon en Pennsylvanie, USA. • A défini des méthodes pour l’amélioration de la qualité • Et 5 niveaux de maturité des processus informatiques • L’évaluation du niveau de maturité, le déroulement des activités, et les domaines clés du processus sont documentés dans le CMM: Capability Maturity Model

14. Automatisé Optimise (5) Amélioration du Processus Quantitatif contrôlé (4) Processus Mesuré Qualitatif Défini (3) Processus bien Compris Géré Reproductible (2) Repetabilite des Taches CMM Les 5 Niveaux d Maturité Objectif Initial (1) Imprévisible, Peu Contrôlé

15. Avant Ecrivons les spécifications, établissons des plans et regardons ce que ça donne, ça va peut être marcher, après tout C ’est le problème de la direction Les équipes agissent en silos isolés sans véritable communication. La direction n’est pas au courant de ce qui se passe dans le projet, ce qui compte c ’est que ça soit fait Éléments clés: le hasard, Projet Subi Après L’équipe du projet sait comment le projet va se dérouler du début jusqu ’a la fin, passant d ’une attitude passive à une attitude pro-active. Les équipes ont une terminologie commune et des procédures de communication La direction supporte le projet, en plus des résultats, elle s’intéresse à la façon dont le projet fonctionne. Éléments clés: Rien n’est laissé au hasard. Projet Contrôlé. Avant et Après la mise en place d’une méthodologie

16. Politique de la Qualité Philosophies Manuel De la Qualité Quoi Quoi, Qui Documentation au niveau du Département Quoi, Qui, Quand, Ou, Comment Niveau Service, Projet, groupes fonctionnels (plans, Schémas, Instructions Opérationnelles) La pyramide de la qualité

17. Les Composants de Base d ’un Projet • Le Guide De Référence méthodologique (SPH) • Les éléments de base du SPH • ISO 9000, SEI/CMM, SPH • Les Activités de la méthodologie

18. DOWN HOME RECIPES Le guide de référence méthodologique (SPH) • Qu’est que le SPH • Un guide de référence méthodologique pour les développement de solutions logiciels utilisé à Texas Instruments • Il inclut la liste des éléments du processus d’informatisation qui doivent être pris en compte dans la gestion d ’un projet • Le SPH n ’est pas • une recette de cuisine, il ne décrit pas comment exécuter les activités clés d ’un projet • Il dit ce qu’il faut faire, mais pas comment le faire

19. Construc tion Acqui sition Config uration Gestion des Risques Tests Valid ations Pré Étude Proto Typage Metri ques Design Archit ecture Document Formation Qualité Revues Speci fications Estimat ions Installa tion Deploy ement Coor dination Inter Projets Planning Les éléments de base du SPH Définition Exécution Production Contrôle ... A composer selon les besoins ...

20. 1. Dites Ce Que vous faites 2. Faites Ce que vous dites 3. Documentez Ce que vous avez fait 4. Verrouiller les résultats obtenus 5. Améliorer le processus ISO 9000 • Standard International pour la qualité, • Certification ISO 9001, 9000-3

21. Standards ISO 9000 SEI SPH CMM ISO 9000, SEI/CMM, SPH

22. Les Activités de la méthodologie • Comité de Pilotage • Etapes deValidation (ATP) • Revues de Projets, Minutes, Liste des Actions • Gestion des Risques , Assurance Qualité , Gestion de Configuration, Méthodes d’Estimation • Jeux d’Essai, Plans de Test et Procédures de Test • Coordination avec d’autres projets • Documentation: Utilisateur, Technique • Formation pour les équipes de Développement, pour les Utilisateurs • Collection des Métriques • Documentation de la Démarche, Leçons Apprises

23. Les Documents de la Méthodologie La Pré-étude • Le Document de Pré-Étude • Le Document de La gestion des Risques La Planification: • Le Document de La Gestion de la configuration • Le Document de L ’Assurance Qualité • Le Document de La Planification • Le Document du plan des Tests • Le Document du plan d’Installation et de Support • Le Document du plan de Formation L’analyse: • Le Document de L ’analyse Fonctionnelle Détaillée • Le Document de La Conception Technique La Construction: • Le Document de construction • La documentation Utilisateur

24. Le Document de Pré-Étude • Le document de pré-étude regroupe l’essentiel des éléments rassemblés au cours de la phase initiale du projet. • Donne un aperçu global du projet et de l’objectif principal à atteindre • Décrit les besoins initiaux exprimés par les utilisateurs • définit le produit à concevoir en citant ses principales caractéristiques et ses fonctionnalités. • Résume les différentes approches étudiées pour résoudre le problème, met en évidence les points forts et les limites de chaque solution étudiée, et propose la solution à choisir

25. Le Document de Pré-Étude (2) • Décompose le projet en éléments atomiques facilement estimables, mesurables et gérables • Etablit les charges, les coûts et les délais en appliquant les méthodes d ’estimation sur les composants de base du projet • Etablit la répartition budgétaire du coût total du projet sur la durée totale du projet • Etablit un planning de livraison de fonctions principales avec un ordre de priorité proposé et qui pourra être modifié par les utilisateurs. • Doit être validé par les utilisateurs avant de passer à l ’étape suivante du projet. • En cas de non acceptation, le projet s’arrête.

26. Le Document de La gestion des Risques • Le plan de gestion des risques est le document qui gère les risques attachés au projet. • Identifie les risques et les conséquences qu’elles peuvent avoir sur le projet s’ils venaient à se réaliser. • résume les risques principaux en citant pour chaque risque sa probabilité, son niveau d’impact sur le projet, la priorité avec laquelle il doit être traite, les facteurs contribuants à sa réalisation ainsi que des solutions préventives pour réduire la probabilité du risque ou au moins les conséquences de son impact sur le projet. • Faire prendre conscience au chef du projet et à son équipe, des obstacles qui peuvent entraver le bon déroulement du projet.

27. Le Document de La Gestion de la configuration • Le plan de la configuration est le document qui se focalise sur le contrôle du développement, de la sauvegarde, des mises à jours des programmes. • Il permet d’identifier tous les objets du projet (Programmes, Documents). • Il établit des standards de nomenclature concernant les releases, les objets, le langage de programmation et autres outils utilisés. • Il participe à la maintenabilité des produits du projet et permet de constituer toutes les releases du projet. • Il décrit l’organisation du projet, c’est à dire l’équipe qui participe au projet et les rôles de chacun.

28. Le Document de La Gestion de la configuration (2) • Il établit la liste des outils utilisés au cours du projet (Word, Excel, Lotus Note, PowerPoint etc..…), les méthodes d ’analyse et les langages de programmation. • Au niveau du code il va définir des standards d’écriture que le développeurs doivent respecter. • Il décrit la procédure de sauvegarde des Objets du projet, en constituant un référentiel de base (Baseline). • Il décrit aussi la procédure de mise a jour des objets (Check in/Check out). • Tout changement à l ’un des objets du projet fait l’objet d’une procédure écrite et formelle.

29. Le Document de L ’Assurance Qualité • Le plan d’assurance qualité établit les droits et les devoirs du projet en ce qui concerne la qualité. • Il décrit les vérifications (Audits) que doit effectuer le responsable qualité pour s ’assurer que le projet agit selon la méthodologie. • Ce document décrit la liste des taches qui doivent être effectuer par le projet, les dates d’audit planifiées et la procédure à suivre en cas de litige entre le responsable qualité et le projet. • Chaque inspection donne suite à un rapport avec la W3 liste (quoi, qui, quand) et au suivi des actions • Le responsable qualité doit être indépendant du projet

30. Le Document de La Planification • Le dossier de planification contient le planning de tout le projet. • Généralement il est documenté a travers un outil de planification (MSProject, ProjectWorkbench,..) • Il doit contenir au minimum: • Le Gantt des tâches (Tache/date début/date fin/délais). • Le récapitulatif des ressources disponibles , utilisées. • Le récapitulatif du coût total du projet. • Et éventuellement le chemin critique

31. Le Document du plan des Tests • Le plan des tests décrit les différents types de tests qui doivent être effectués, quand ils doivent être effectués et par qui. • 4 types de tests • Les tests unitaires • Les Tests d'Intégration • Les tests de non-régression • Les tests systèmes • Les Tests d’acceptance utilisateurs • Les Procédures de Tests et les jeux d’essais • Le rapport des tests et la liste des actions correctives

32. Le Document du plan d’Installation et de Support • Le plan d’installation et de support décrit l'ensemble des procédures nécessaires à la mise en production, ainsi que les procédures nécessaires pour la maintenance du produit installé • Il inclut la configuration matérielle et logicielle à mettre en place pour pouvoir installer le produit fini • Il décrit les procédures de conversion des données • il définit les procédures d’intervention en cas de problèmes • il référence le plan de configuration pour les procédures de sauvegarde et de baseline

33. Le Document du plan de Formation • Le plan de formation décrit l’ensemble du dispositif à mettre en place pour • la formation de l'équipe du projet aux techniques nécessaires au développement du projet, • Et la formation des utilisateurs sur le logiciel développé • Ce plan détaille le matériel nécessaire à ces formations, ainsi que les organismes internes et externes qui doivent l’assurer • Il doit également contenir le chiffrage des coûts de l’ensemble de la formation et du matériel

34. Le Document de L ’analyse Fonctionnelle Détaillée • L’analyse fonctionnelle détaillée ou les spécifications détaillées font suite au document de pré-étude, le complètent et le détaillent • Il est destiné directement aux utilisateurs. • Son but est de décrire les comportements fonctionnelles visibles du logiciel sans se soucier des techniques qui vont être utilisées pour l’implémentation • Il précise les spécifications du produit une fois terminé, il peut s’apparenter à un cahier des charges. • Il décrit en détail les différents menus, fenêtres, règles de gestion en plus des performances et contraintes du produit fini. • Ce document doit être approuvé par l’utilisateur avant le passage a l étape suivante (Conception Technique)

35. Le Document de La Conception Technique • Ce document couvre l’architecture Technique du projet • Il fait référence à l’architecture globale du logiciel en décrivant les formes, des menus, les Contrôles, etc… • Il décrit les interfaces internes et externes au projet • Il décrit les outils de programmation utilisés et la façon dont ils sont utilises pour implémenter les fonctions requises dans les spécifications fonctionnelles. • Il décrit également la structure des données et la logique de programmation. • Il a pour vocation de diriger l’équipe de développement dans les différentes étapes du codage.

36. Le Document de construction • Le document de construction inclut la liste des objets du projet constituant la release • Cette liste contient le nom des objets, leur version, la taille, la date de dernière mise a jour, etc … • Par Objet du projet on entend les documents, les formes, les modules principaux et tous les exécutables (DLL, ActivesX, Les java beans, Les Applets et Servlets, …) et les communications (fax, mails, ..) • Il ne contient pas le code des programmes qui eux se trouvent dans les répertoires de développement.

37. La documentation Utilisateur • La documentation Utilisateur a pour objet de guider l’utilisateur dans l ’utilisation du logiciel. • Elle se compose d ’une aide en ligne, du manuel d ’utilisation et du guide de référence • Il est exclusivement destiné à l’utilisateur et son contenu ne fait qu’expliquer le fonctionnement du logiciel de telle sorte que l’utilisateur non informaticien puisse l’utiliser. • Il n ’explicite que les fonction implémentées et non tout ce qui a été décrit dans les spécifications ou dans le document technique. • Il peut être utilisé comme support de formation pour les utilisateurs du logiciel

38. Les Taches par activité • Les Taches de la phase de planification • Les Taches de la phase de Spécifications • Les Taches de la phase de conception Technique • Les Taches de la phase de Construction • Les Taches de la phase des tests • Les Taches de la phase d’Installation • Les Taches pour la phase de Maintenance

39. Les Taches de la phase de planification (1) • Adapter et dimensionner les activités clés de la méthodologie à la taille du projet • Définir les méthodes d’estimation • Définir la Coordination inter-projets • Créer les Dossiers du Projet • Définir la gestion des Risques • Définir la gestion de la Configuration • Définir le plan Assurance Qualité • Définir le Plan des tests et les jeux d’essais • Définir le plan d’installation et de Support • Définir le Plan de Formation • Définir les Métriques a collecter • Définir le Référentiel de Base (Baseline Repository) • Définir les Objectifs et les besoins des utilisateurs (SOW)

40. Les Taches de la phase de planification (2) • Procéder a l’Analyse des solutions alternatives • Préparer le WBS (Work Breakdown Structure) initial et Estimer la taille, les charges, les délais et les coûts du projet. • Identifier le coordinateur des utilisateurs, le Chef du projet et l'équipe du projet • Mettre en place les groupes d’interface avec d’autres projets, le comité de pilotage • Mettre en place un planning de rencontres avec les utilisateurs. Définir les revues de direction (types, fréquences, format). Définir et mettre en place le plan des revues du projet • Organiser l'équipe des tests • Définir l'environnement des tests • Communiquer les plans à l'équipe du projet

41. Les Taches de la phase de planification (3) • Finaliser le Document de Pré-Étude • Générer des rapports sur l'état du projet • Obtenir l’acceptation du projet par la direction (ATP0) • Collecter • la taille des objets du projet • la charge de travail, • Les délais • les jalons, • les coûts, • la stabilité des changements aux spécifications • Et autres indicateurs ...

42. Les Taches de la phase de Spécifications • Commencer l’analyse des spécifications • Identifier la documentation utilisateur • Documenter les besoins en formation et l’approche générale de la formation • Rédiger le cahier des charges (Spécifications) • Conduire la revue de spécifications • Conduire la revue de direction pour l’obtention de l’ATP1 • Collecter les métriques relative à • la taille des produits, • la Charge de travail, • les jalons importants, • les coûts • Et le niveau de la stabilité des spécifications

43. Les Taches de la phase de conception Technique (1) • Définir et Documenter les charges nécessaires pour le Prototypage ainsi que sa faisabilité • Revoir et mettre à jour les besoins utilisateurs • Développer et démontrer un Model de l’application • Définir les taches hors Prototypage • Documenter les résultats du Prototypage • Conduire la revue préliminaire de la conception Technique • Rédiger le document la conception Technique • Revoir et mettre a jour le plan de formation • Définir la Documentation utilisateur préliminaire • Revoir et mettre a jour le plan d’Installation et de Support • Conduire la revue critique de la conception Technique

44. Les Taches de la phase de conception Technique (2) • Demander la validation ATP2 • Collecter les métriques pour • Les délais, • les spécifications déjà implémenter, • la taille des produits, • la charge de travail, • Les jalons importants, • Les coûts constates • Et la stabilité des spécifications

45. Les Taches de la phase de Construction • Développer et revoir le code • Définir les procédures de tests • Rédiger la documentation utilisateur • Constituer le matériel de Formation et conduire les séances initiales • Conduire les tests unitaires, les tests de non-Régression • Revoir et mettre a jour le plan d’Installation et de Support • Collecter • L'évolution des délais détaillés, • Les spécifications déjà implémentées, • La taille des objets, • La charge de travail, • Les jalons importants, • Les coûts, • Et la stabilité des spécifications

46. Les Taches de la phase des tests • Conduire les tests d'Intégration • Conduire les tests de non-Régression • Vérifier le matériel de Formation • Conduire les tests systèmes • Conduire les tests d’acceptance • Documenter les résultats des tests • Collecter les erreurs des tests et les autres métriques

47. Les Taches de la phase d’Installation • Finaliser la liste de vérification pour l’installation • Conduire les validations de la configuration • Conduire la revue de mise en production • Demander l’autorisation pour la mise en prod (ATP3) • Procéder à l’Installation • Finaliser et Exécuter le plan d’installation et de Support • Conduire la Revue de Poste-Installation • Collecter les métriques ….

48. Les Taches pour la phase de Maintenance • Revoir et mettre a jour le plan d’installation et de Support • Définir et Exécuter les procédures de maintenance • Revoir et prioritiser la liste des requêtes mises en attente pour la prochaine version

49. TP/Planning avec MS Project • Base de travail: 1 projet de 6 mois, 2 a 3 personnes. Votre Projet ou le Projet Proposé(Voir Document :TP) • Identification des phases, taches, étapes de validation • Estimation de la charge de travail (sur Excel) • Création du Projet sur Ms Project, paramètres Projet • Saisie des taches, date début, durées • Affectation des ressources • Visualisation du Gantt, taux d’utilisation ressources • Calcul du coût total du Projet • PERT • Actualisation

50. TP/Planning avec MS Project (suite) Phases • Pré-Étude Planification • Spécifications • Conception Technique • Construction • Testes • Installation • Maintenance Documents • SOW • SPP • SRS • SDD • UDOC • TDOC • TPL/TPR • ISP Étapes de Validation • ATP0 • ATP1 • ATP2 • ATP3 Revues • CDR • Code Review • PRR • PIR