Gestion de Projet

1
Gestion de Projet

• Gestion de Projet
• Contact
• Yossi Gal, Emaily-gal_at_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
• Cest 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 dune
  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 à
  lentreprise
• 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
  lInformation 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 dinformations (Outsourcing).

7
La Problématique des Projets Informatiques

• La majorité des projets réalisés dans les grandes
  entreprises américaines nont que 42 des
  fonctionnalités dorigines
• 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 nont pas à leur disposition
  des guides de référence avec des méthodes et des
  standards faciles à utiliser et complètement
  automatisés.

8
Cest 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, lacquisition, lévaluation,
  linté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 lutilisation du
  capital humain et matériel de lentreprise
• A mettre en place un programme damélioration
  continue utilisant lexpérience acquise dans le
  passé au service des développements futurs.

10
La Maturité dun 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 lamé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 lamé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 lamé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
Les 5 Niveaux d Maturité
Objectif
Initial (1) Imprévisible, Peu Contrôlé
15
Avant et Après la mise en place dune méthodologie

• 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 nest 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 sintéresse à la façon dont le
  projet fonctionne.
• Éléments clés Rien nest laissé au hasard.
  Projet Contrôlé.

16
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
Le guide de référence méthodologique (SPH)

• Quest 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
  dinformatisation 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 quil faut faire, mais pas comment le
  faire

19
Les éléments de base du SPH
Définition
Exécution
Production
Contrôle
... A composer selon les besoins ...
20
ISO 9000

• Standard International pour la qualité,
• Certification ISO 9001, 9000-3

21
ISO 9000, SEI/CMM, SPH
22
Les Activités de la méthodologie

• Comité de Pilotage
• Etapes de Validation (ATP)
• Revues de Projets, Minutes, Liste des Actions
• Gestion des Risques , Assurance Qualité , Gestion
  de Configuration, Méthodes dEstimation
• Jeux dEssai, Plans de Test et Procédures de Test
• Coordination avec dautres 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 dInstallation et de Support
• Le Document du plan de Formation
• Lanalyse
• 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 lessentiel des
  éléments rassemblés au cours de la phase initiale
  du projet.
• Donne un aperçu global du projet et de lobjectif
  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 sarrê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
  quelles peuvent avoir sur le projet sils
  venaient à se réaliser.
• résume les risques principaux en citant pour
  chaque risque sa probabilité, son niveau dimpact
  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 didentifier 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 lorganisation du projet, cest à 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
  lobjet dune procédure écrite et formelle.

29
Le Document de L Assurance Qualité

• Le plan dassurance 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
  daudit 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 dacceptance utilisateurs
• Les Procédures de Tests et les jeux dessais
• Le rapport des tests et la liste des actions
  correctives

32
Le Document du plan dInstallation et de Support

• Le plan dinstallation 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 dintervention 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 lensemble 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 lassurer
• Il doit également contenir le chiffrage des coûts
  de lensemble de la formation et du matériel

34
Le Document de L analyse Fonctionnelle Détaillée

• Lanalyse 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 limplémentation
• Il précise les spécifications du produit une fois
  terminé, il peut sapparenter à 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 lutilisateur
  avant le passage a l étape suivante (Conception
  Technique)

35
Le Document de La Conception Technique

• Ce document couvre larchitecture Technique du
  projet
• Il fait référence à larchitecture 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 lutilisateur 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é à lutilisateur et
  son contenu ne fait quexpliquer le
  fonctionnement du logiciel de telle sorte que
  lutilisateur non informaticien puisse
  lutiliser.
• 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 dInstallation
• 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 destimation
• 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 dessais
• Définir le plan dinstallation 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 lAnalyse 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 dinterface avec
  dautres 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 lacceptation 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 lanalyse des spécifications
• Identifier la documentation utilisateur
• Documenter les besoins en formation et lapproche
  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 lobtention
  de lATP1
• 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 lapplication
• 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 dInstallation 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 dInstallation 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 dacceptance
• Documenter les résultats des tests
• Collecter les erreurs des tests et les autres
  métriques

47
Les Taches de la phase dInstallation

• Finaliser la liste de vérification pour
  linstallation
• Conduire les validations de la configuration
• Conduire la revue de mise en production
• Demander lautorisation pour la mise en prod
  (ATP3)
• Procéder à lInstallation
• Finaliser et Exécuter le plan dinstallation 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 dinstallation 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 dutilisation
  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

51
Questions ?
Contact Yossi Gal, Emaily-gal_at_ti.com, Téléphone
04 9322-2339