Plan de gestion de projet logiciel

Transcription

1 PMP Draft 1 Projet voicecmdr Plan de gestion de projet logiciel Jonathan Benattar Yahn Formanczak David Hadjedj Alan Mace William Marques Dias Morgan Martins Thomas Montagné Denis Ollier Anass Radouani Jérémy Sanhes

2

3 Table des matières 1. Vue d'ensemble Résumé du projet But, périmètre, et objectif Hypothèses et contraintes Livrables du projet Résumé du calendrier et du budget Évolution du plan Références Glossaire Organisation du projet Interfaces externes Structure interne Rôles et responsabilités Plans de gestion Plan de démarrage Plan d'estimation Plan d'embauche Plan d'achats Plan de formation Plan de travail Activités de travail Planning Allocation de ressources Allocation de budget Plan de suivi Plan de suivi des besoins Plan de suivi du planning Plan de suivi du budget Plan de suivi qualité Plan de reporting Plan de collecte des métriques Plan de gestion du risque Plan d'arrêt Plans techniques Processus Méthodes, outils et techniques Développement Documentation Versions Plan de gestion de l'infrastructure Plan de livraison Plans de support Plan de gestion de configuration Plan de vérification et de validation iii

4 PMP Draft Plan de documentation Plan d'assurance qualité Plan de revue et d'audit Plan de résolution des problèmes Plan de gestion des sous-traitants Plan d'amélioration du processus Autres plans iv

5 Liste des illustrations 4.1. Structure interne du projet Matrice de répartition des activités par rôle Work Breakdown Structure pour le projet voicecmdr Diagramme d'activité UML d'une itération du processus PBL Diagramme d'activité UML d'une itération du processus en Y Versions des outils utilisés Règles de contrôle d'accès en écriture au système de gestion de configuration Diagramme d'activité UML d'un cycle de développement v

6 Chapitre 1. Vue d'ensemble 1.1. Résumé du projet But, périmètre, et objectif Le but du projet est de concevoir et implémenter le prototype d un module logiciel permettant de fournir des fonctionnalités de synthèse et de reconnaissance vocale sur terminal mobile, et de fournir une application de démonstration de ce module. Ce sujet a été proposé par la société Frequentiel, une société toulousaine spécialisée dans les technologies d identification et de traçabilité, notamment dans le domaine des RFID. Une telle solution logicielle serait exploitée dans le cadre d un système de gestion de stocks, en permettant aux opérateurs mobiles du système de recevoir et de manipuler vocalement des ordres de mission. Pour plus de détails, on se réfère au document décrivant la spécification des besoins logiciels du projet du projet [6]. L objectif principal du projet est de fournir aux étudiants l expérience d un projet de conception et de développement logiciel d une envergure plus large que les projets habituellement menés dans le cadre d une unité d enseignement. Un second objectif du projet est de fournir à la société Frequentiel une solution logicielle fonctionnelle. Cet objectif reste entièrement secondaire à l objectif pédagogique Hypothèses et contraintes Le projet doit être réalisé en utilisant la plate-forme Java Mobile Edition sur un système d exploitation de type Windows Embedded. Le projet doit être réalisé dans le cadre temporel de l'uv BE COO/POO. Les ressources humaines disponibles sont limitées aux 10 étudiants du groupe. Aucun budget n est disponible. Le projet sera diffusé dans les conditions d'une licence libre de type MIT Licence Livrables du projet Les éléments livrables du projet sont : le plan de gestion de projet logiciel (Software Project Management Plan) au sens du standard IEEE [5] (ce document) ; la spécification des besoins logiciels [6] (Software Requirements Specification) au sens du standard IEEE [3] ; la description de la conception logicielle [1] (Software Design Description) au sens du standard IEEE [4] ; la solution logicielle sous la forme de son code source Résumé du calendrier et du budget 1

7 Vue d'ensemble 1.2. Évolution du plan Les évolutions initiales de ce plan seront soumises à l enseignant encadrant du groupe pour approbation. Toute révision imprévue de ce plan est initiée par le chef de projet, éventuellement à la demande d un tiers. Une révision est prévue après la livraison du premier prototype du projet au client. A l issue de toute révision, ce plan est de nouveau soumis à l enseignant encadrant et diffusé par l intermédiaire du site du projet. Ce plan est placé sous gestion de configuration au même titre que le reste du projet (cf. Section 7.1, «Plan de gestion de configuration» pour plus de détails). 2

8 Chapitre 2. Références [1] Description de la conception logicielle. Projet voicecmdr. [2] IEEE Std , IEEE Standard Glossary of Software Engineering Terminology. [3] IEEE Std , IEEE Recommended Practice for Software Requirements Specifications. [4] IEEE Std , IEEE Standard for Information Technology Systems Design Software Design Descriptions. [5] IEEE Std , IEEE Standard for Software Project Management Plans. [6] Spécification des besoins logiciels. Projet voicecmdr. [7] ypbl methodology: a problem-based learning method applied to Software Engineering. Ernesto Exposito. 3

9 Chapitre 3. Glossaire DGEI INSA PBL Département Génie Électrique et Informatique. Institut National des Sciences Appliquées. Problem-based learning. 4

10 Chapitre 4. Organisation du projet 4.1. Interfaces externes Les interfaces externes du projet correspondent aux acteurs mandatés par la méthodologie ypbl [7]. Le projet est conduit dans le cadre d'une unité d'enseignement au DGEI de l'insa Toulouse et gérée par un coordinateur. Le coordinateur de cette unité d'enseignement est Ernesto Exposito. Le projet est encadré par un instructeur qui a un double rôle : un rôle de support (aider les étudiants à atteindre les objectifs du projet) et un rôle d'évaluation. L'instructeur du projet est Géraldine Vache. Le projet est réalisé pour un client qui désigne un interlocuteur responsable du dialogue avec le groupe pour la phase de recueil des besoins Structure interne Les étudiants participants au projet remplissent l'un des rôles suivant : chef de projet, responsable qualité, responsable informatique et simple développeur. La structure interne du projet est décrite dans la Figure 4.1, «Structure interne du projet». Figure 4.1. Structure interne du projet 4.3. Rôles et responsabilités On définit la répartition des activités du projet par la Figure 4.2, «Matrice de répartition des activités par rôle». 5

11 Organisation du projet Figure 4.2. Matrice de répartition des activités par rôle Chef de projet 1.1. Gestion de projet R Responsable informatique Responsable qualité Développeur Analyse fonctionnelle R P P P Analyse technique R P P P 1.3. Conception R P P P 1.4. Développement R P P P 1.5. Test P P R P 1.6. Release R 2.1. Coordination apprentissage R 2.2. Activités d'apprentissage R P P P 3.1. Gestion de l'infrastructure R 3.2. Support technique R 3.3. Documentation P P R P R: Responsable P: Participe 6

12 Chapitre 5. Plans de gestion 5.1. Plan de démarrage Plan d'estimation Plan d'embauche Les ressources sont limitées aux 10 étudiants du groupe et aucune forme d'embauche n'est prévue Plan d'achats Aucun budget n'est disponible et aucune forme d'acquisition n'est prévue Plan de formation 5.2. Plan de travail Activités de travail Les activités de travail sont définies par la méthodologie ypbl [7]. Ils peuvent être décomposés en 2 processus parallèles : le processus PBL pour le volet pédagogique et le processus en Y pour la partie ingénierie logicielle. On se réfère à la Section 6.1, «Processus» pour plus de détails sur la méthodologie ypbl. On prévoie également des activités de support, notamment : la gestion de l'infrastructure, notamment du système de gestion de configuration et du système de gestion des demandes ; le support technique aux différents membres de l'équipe ; le maintien de la documentation. 7

13 Plans de gestion Figure 5.1. Work Breakdown Structure pour le projet voicecmdr voicecmdr Project 1. Processus en Y 1.1. Gestion de projet 1.2. Analyse 1.3. Conception 1.4. Développement 1.5. Test 1.6. Release Analyse fonctionnelle Analyse technique 2. Processus PBL 2.1. Coordination apprentissage 2.2. Activités d apprentissage 3. Activités de support 3.1. Gestion de l infrastructure 3.2. Support technique 3.3. Documentation Planning Allocation de ressources Allocation de budget 5.3. Plan de suivi Plan de suivi des besoins Plan de suivi du planning Plan de suivi du budget Plan de suivi qualité Plan de reporting Plan de collecte des métriques 8

14 Plans de gestion 5.4. Plan de gestion du risque 5.5. Plan d'arrêt 9

15 Chapitre 6. Plans techniques 6.1. Processus On utilise la méthode ypbl [7], une méthode de développement logiciel dans un contexte de projet éducatif en cours de développement à l'insa Toulouse. Cette méthode est itérative et incrémentale, et se divise en deux processus distincts le processus PBL et le processus en Y. Le processus PBL prévoie que les étudiants et les instructeurs identifient, répartissent et planifient des activités d'apprentissage en rapport avec le projet. Chaque activité d'apprentissage donne lieu à la rédaction d'une recette de cuisine (cookbook) qui présente de manière concise les concepts, les méthodes et les ressources utiles au sujet abordé. Ces cookbooks sont présentés aux autres étudiants et placé sous gestion de configuration au même titre que le reste du projet. Le chef de projet coordonne les activités d'apprentissage pour assurer une couverture complète des besoins du projet. Figure 6.1. Diagramme d'activité UML d'une itération du processus PBL Le processus en Y, ou Two Tracks Unified Process (2TUP) est un processus de développement logiciel itératif et incrémental qui est composé de deux chemins ayant pour but de capturer les besoins fonctionnels et techniques, et d'un chemin centralisé de conception et d'implémentation. On modélise les activités principales du processus par un diagramme d'activité UML. 10

16 Plans techniques Figure 6.2. Diagramme d'activité UML d'une itération du processus en Y Gestion de projet Analyse fonctionelle Analyse technique PMP SRS Conception SDD Développement Test Release Produit Itération 6.2. Méthodes, outils et techniques Développement La méthodologie de développement en Y que l'on utilise dans le cadre de ce projet est décrite dans la Section 6.1, «Processus». Le langage de programmation utilisé est le langage Java dans ses différentes éditions. L'environnement de développement intégré utilisé est Eclipse. On utilise le client Subversion TortoiseSVN pour accéder au serveur de gestion de configuration Documentation La documentation est rédigée dans le format Docbook. Les illustrations vectorielles sont fournies au format Portable Document Format (PDF). Les illustrations bitmap sont fournies au format Portable Network Graphics (PNG). On utilise une chaîne de travail composée de Docbook XSL, Saxon et Apache FOP pour tranformer la documentation vers le format Portable Document Format (PDF). 11

17 Plans techniques Versions Les versions des outils utilisés sont définis dans le tableau de la Figure 6.3, «Versions des outils utilisés» Outil Figure 6.3. Versions des outils utilisés Version Java JDK 6 Update 17 Eclipse TortoiseSVN DocBook 5.0 DocBook XSL Saxon Apache FOP (Galileo) 6.3. Plan de gestion de l'infrastructure Les outils collaboratifs et le serveur de gestion de configuration sont fournis par l'entreprise Google, Inc. dans le cadre de son service Google Code Hosting. Le projet est conduit sur les ordinateurs personnels des membres du groupe, qui sont administrés directement par leurs utilisateurs. Le responsable informatique nommé par le groupe est responsable de la mise en place et de la maintenance des outils collaboratifs et du serveur de gestion de configuration. Le responsable informatique met à disposition des membres du groupe les outils utilisés dans le cadre du projet sous la forme d'un package cohérent. Le responsable informatique fournit également un service de support technique aux membres du groupe Plan de livraison A l'issue de chaque itération du processus ypbl, une livraison formelle des éléments livrables de l'itération est effectuée, au cours de laquelle le groupe effectue une présentation de ses principales fonctionnalités, en regard de la spécification des besoins logiciels réalisée. 12

18 Chapitre 7. Plans de support 7.1. Plan de gestion de configuration On utilise le système de gestion de configuration Subversion, fourni par le service Google Code Hosting. Le travail de chacun des membres du groupe s'effectue sur une branche du projet correspondant au module en cours d'implémentation. Quand le travail sur un module atteint un niveau de complétion suffisant, le développeur effectue une demande de revue. Le responsable qualité effectue alors une revue du code (cf. Section 7.5, «Plan de revue et d'audit»), et si le résultat de cette revue et positif, intégre le travail effectué à la branche principale du projet. A l'issue d'une itération, le code est indentifié par un tag du numéro de version correspondant. Les règles de contrôle d'accès (non implémentées par le service Google Code Hosting) sont décrites dans la Figure 7.1, «Règles de contrôle d'accès en écriture au système de gestion de configuration». Figure 7.1. Règles de contrôle d'accès en écriture au système de gestion de configuration Chemin /trunk/ /branches/[nom-module] /tags/ Ecriture Chef de projet, Responsable qualité Développeur travaillant sur le module Chef de projet, Responsable qualité Le responsable informatique a un accès complet au système dans son rôle de maintenance Plan de vérification et de validation 7.3. Plan de documentation 7.4. Plan d'assurance qualité 7.5. Plan de revue et d'audit Une revue de code est effectuée par le responsable qualité chaque fois que le travail sur un module du logiciel atteint un niveau de complétion suffisant pour être intégré dans la branche principale du système de gestion de configuration. Ce processus est modélisé par la Figure 7.2, «Diagramme d'activité UML d'un cycle de développement». 13

19 Plans de support Figure 7.2. Diagramme d'activité UML d'un cycle de développement Développeur Travail dans 1 branche Requête revue Commentaires Responsable qualité Revue [faux] Revue positive [vrai] Intégration dans la branche principale Si le responsable qualité évalue que le code ne satisfait pas aux normes du projet (cf. Section 7.4, «Plan d'assurance qualité»), il rejette la demande d'intégration à la branche principale et demande au développeur d'effectuer certaines modifications à son code et un nouveau cycle démarre Plan de résolution des problèmes 7.7. Plan de gestion des sous-traitants 7.8. Plan d'amélioration du processus 14

20 Chapitre 8. Autres plans 15