Post on 11-Sep-2018
Sommaire 1. Introduction
1.1 Objet du document 1.2 Contexte du projet 1.3 Nom du projet 1.4 Membres de l’équipe
2. Le périmètre du projet 2.1 Les enjeux et objectifs du projet 2.2 Les domaines traités 2.3 Les livrables du projet 2.4 Les contraintes de réalisation
3. Découpage du projet 3.2.2 Work Breakdown Structure (WBS)
4. Coordination 4.1 Gestion de la communication
5. Planning du projet 5.1 Planning prévisionnel 5.2 Planning réel 5.3. Planning d’ordonnancement des tâches
5.3.1 IHMMAIN 5.3.2 IHMTable 5.3.3 Communication 5.3.4 Gestion et traitement des données
6. Évaluation des charges 6.1. Réalisation du dossier de conception 6.3. Développement 6.4. Intégration
7. Gestion des risques 7.1 Identification, évaluation et quantification des risques 7.2 Stratégie de gestion des risques
8. Gestion de la qualité 9. Déroulement du projet
9.1 Processus décisionnel 9.1.1 ClientServeur vs PeerToPeer 9.1.2 Gestion du profil 9.1.3 Connexion 9.1.4 Fenêtre principale 9.1.4 Lancement d’une partie 9.1.5 Déconnexion & hearthbeat
9.2 Liste des autres décisions prises
1
1. Introduction
1.1 Objet du document Ce document constitue le plan de management de projet (PMP) qui documente l’ensemble des actions nécessaires pour définir, préparer, intégrer et coordonner l’ensemble des plans d’action nécessaires pour mener le projet à bien. Il définit comment le projet sera réalisé, suivi et contrôlé, et mené à bien jusqu’à terminaison, en lui associant les activités et ressources nécessaires. Il fait l’objet d’une validation indispensable à la mise en œuvre du projet et d’actualisations (révisions) qui surviendront au fil des changements et évolutions du projet. Le plan de management de projet est toujours réalisé avec les parties prenantes du projet et les acteurs chargés de sa bonne réalisation (responsables des lots de travaux et acteurs experts) et du suivi de sa gestion (équipe projet). Le chef de projet devra savoir mobiliser autour de sa réalisation. C’est sa principale condition d’efficacité. Le PMP est toujours associé aux autres documents et plans qui contribueront à la réussite du projet. Parmi lesquels certains documents indispensables (référentiels périmètre, ressources, délais, coûts) et d’autres qu’il est recommandé de lui associer : plan de management des risques, de la qualité, des ressources, des délais, des coûts, de la communication, des approvisionnements.
1.2 Contexte du projet Dans le cadre de l’UV LO23, portant sur le thème de la gestion de projet informatique, nous devons réaliser, en équipe d’environ 20 personnes, une application PC de jeu de poker multijoueur.
1.3 Nom du projet Faisant partie d’une UV de notre cursus d’ingénieur à l’Université de Technologie de Compiègne, le projet porte le nom de la matière concernée ainsi que son utilité : Poker_Game_LO23
1.4 Membres de l’équipe Le projet ici présenté est découpé en quatre groupes.
IHMMain : Victor LECLERC (directeur), Frédéric CUNI (manageur), JeanBaptiste (développeur), Romain DI FATTA (étude, qualité), Paul Jenny (conception),
IHMTable : Thibault Brocheton (directeur), Yaya Tambadou (manageur), Quentin Pena (développeur), Bastien Fremondiere (étude), Gabrielle Rit (conception),
Gestion et traitement des données : Harold Carrel Billiard (directeur), Ying(manageur), Rémy(développeur), Jianghan (conception), Marouane (qualité),
3
Communication : Guillaume VASSAL (directeur), JeanCôme (manageur), Cedric BACHE (développeur), Victor (étude), Raphael K (conception), Raphael B (qualité).
2. Le périmètre du projet
2.1 Les enjeux et objectifs du projet
Le projet a pour but de réaliser une application de jeu de poker en ligne. Un utilisateur, désirant jouer au poker, se connecte sur l’application, s’identifie et se retrouve sur la page principale de l’application. Il peut voir ainsi les joueurs connectés sur le même serveur que lui, peut ajouter et gérer une liste de contact et peut créer ou rejoindre une partie de poker en tant que joueur ou spectateur.
2.2 Les domaines traités Les domaines traités dans le cadre de ce projet est en premier lieu la gestion d’un projet informatique. Étant une équipe nombreuse, nous devons coordonner nos connaissances, notre communication ainsi que notre aptitude à travailler en équipe. De plus nous pourrons également renforcer nos connaissances en développement objet et conception UML.
2.3 Les livrables du projet Le premier livrable du projet est daté au 13 octobre et comprend tout ce qui est relatif à la conception du projet, le découpage des tâches, les diagrammes UML, ainsi que les futures tâches à réaliser. Le deuxième et dernière partie de livrables, devra être rendue le 5 janvier 2016. Celle ci est constituée d’une soutenance sur la fin du projet, du plan de management final, du dossier de réalisation ainsi que des codes sources et des exécutables du projet.
2.4 Les contraintes de réalisation Comme évoqué précédemment, le projet est réalisé par une équipe assez nombreuse, ce qui peut rendre difficile l’avancement du projet : problème de communication, d’écoute, d’entente. Une contrainte de temps est aussi stipulée pour ce projet :
Dossier de conception et plan de management de projet : 19 Octobre 2015 Plan de management final, dossier de réalisation, codes sources et exécutables : 5
Janvier 2016 Soutenance : 5 Janvier 2016
4
3. Découpage du projet
3.1 Découpage temporel Le découpage temporel nous a permis de répartir dans le temps, la production ainsi que les ressources, c’est à dire le travail a effectuer. Nous avons opté pour un découpage temporel constitué de trois phases à savoir :
● Phase de conception ● Phase de développement ● Phase d’intégration et de tests
Chaque phase est composée d’activités, chacune définie par des tâches à effectuer. Chaque élément de la décomposition est associé à un livrable, et des dates de début et de fin.
3.1.1 Phase de conception Les activités de la phase de conception, réalisée dans un premier temps sont :
● Étude du cahier des charges ainsi que du besoin ● Réalisation des diagrammes usecases ● Réalisation des diagrammes de séquences ● Réalisation des maquettes
3.1.2 Phase de développement
Après la phase de conception, chaque sousgroupe a identifié des tâches à effectuer et à développer. Un compterendu hebdomadaire de l'avancement a été réalisé en chaque début de séance. Ce dernier nous a permis d’évaluer la charge de travail restante pour chaque sousgroupe et de régler des difficultés intergroupe et intragroupe.
3.1.3 Phase d’intégration et de tests Nous avons opté pour une intégration continue après trois semaines de développement. Comme évoqué précédemment, en début de séance un compte rendu des fonctionnalités réalisées par module est évoqué pour mettre en exergue les fonctionnalités que nous pouvions intégrer durant la séance. Pour ce faire, les membres intégrateurs de chaque groupe se réunissaient pour intégrer le travail précédemment sélectionné. Ainsi, nous avons définis également un planning de développement afin d’intégrer des blocs fonctionnels, et permettre de sortir des versions prealpha. L’intérêt de l’intégration continue est de pouvoir intégrer tout le code de manière progressive, et ainsi de rendre accessible à tous les groupes ce qui a été réalisé par les différents groupes.
5
C’était notamment primordial concernant les classes d’objets crées par l’équipe Data, qui étaient nécessaires à chacun des groupes. En contrepartie, l’intégration continue a mobilisé au moins un membre de chaque équipe pendant tous les TD consacrés au développement, ce qui est coûteux en terme de charge de travail. Durant l’intégration, des tests d’intégration ont également été effectué pour vérifier la cohérence et la fonctionnalité du travail. En cas de problème de fonctionnement, le code relatif à ces fonctionnalités a été modifié, intégré et testé.
3.1.4 Cycle de développement L’ensemble ordonnancé des phases du projet s’appelle le cycle de vie du projet. Ainsi le cycle de vie est par conséquent un cycle en spirale.
Le développement en spirale reprend les différentes étapes du cycle en V. Par l'implémentation de versions successives, le cycle recommence en proposant un produit de plus en plus complet et robuste. En effet, compte tenu des intégrations successives au sein du projet, nous avons réalisé par conséquent plusieurs cycle en V, proposant ainsi une version de l’application plus complète et fonctionnelle après chaque intégration.
6
3.2 Découpage structurel
Le découpage structurel permet d’organiser le travail en fonction de la structure du produit. Il a été fait de la manière suivante : 4 sous groupes ont été créés :
● IHMMain ● IHMTable ● Gestion et traitement des données ● Communication
Chaque sous groupes est constitué à son tour :
● d’un directeur de projet ● d’un manageur ● d’un concepteur ● d’un développeur ● d’un responsable qualité ● d’un responsable d’étude
3.2.1 Organisation : Ressource Breakdown Structure (RBS)
Le découpage structurel normalisé cidessous réprensente le découpage du projet en sous groupe, chacun découpé à leur tour.
7
3.2.2 Work Breakdown Structure (WBS) Le découpage temporel normalisé cidessous correspond à une décomposition sous forme arborescente des différentes activités à mener pour parvenir au produit final.
4. Coordination
4.1 Gestion de la communication La communication du projet est gérée sur différents niveaux. Tout d'abord, au niveau de l’ensemble du groupe, nous communiquons par mail et via le drive pour les informations les plus importantes que tout le monde doit recevoir. Nous avons également mis en place un slack, un chat instantané comportant un channel général et des channels propres à chaque sousgroupe. Ensuite, au sein des différents groupes de développement, le manager est en charge de mettre en place une communication efficace pour permettre la transmission d'information la plus efficace possible. En général, le manager dispose des numéros de téléphone de chaque membre de son équipe. Enfin, il existe aussi une communication entre les différents groupe qui est réalisée par les directeurs. Les outils utilisés sont :
Les mails (Mailing list) Un slack Les outils de communication du drive sur lequel sont rassemblés nos documents de
gestion de projet.
8
5. Planning du projet
5.1 Planning prévisionnel
15/09/2015 Répartition en sousgroupes, planification
Conception
22/09/2015 Diagramme cas d'utilisation + Séquence
29/09/2015 Séquence
06/10/2015 Séquence + Classe
13/10/2015 Finalisation du rendu
20/10/2015
Développement
27/10/2015 Vacances
03/11/2015
10/11/2015 Mardi transformé en Samedi
17/11/2015
24/11/2015
01/12/2015
Intégration
08/12/2015
15/12/2015
22/12/2015 Préparation soutenance
29/12/2015 Vacances
05/01/2016 Soutenance
9
5.2 Planning réel
15/09/2015 Répartition en sousgroupe, planification
Conception
22/09/2015 Diagramme cas d'utilisation + Séquence
29/09/2015 Séquence
06/10/2015 Séquence + Classe
13/10/2015 Finalisation du rendu
20/10/2015
Développement + Intégration
27/10/2015 Vacances
03/11/2015
10/11/2015 Mardi transformé en Samedi
17/11/2015
24/11/2015
01/12/2015
08/12/2015
15/12/2015
22/12/2015 intégration finale
29/12/2015 Vacances
05/01/2016 Soutenance
10
5.3. Planning d’ordonnancement des tâches
5.3.1 IHMMAIN Diagramme de GANT sur l’ensemble du projet.
11
5.3.2 IHMTable
Diagramme de Gantt du développement
Oct Nov Dec Janv
Tâches 20 3 10 7 24 1 8 15 22 5
Configuration Git
Interface de la table
Formulaire création de table
Intégration
Interfaces
Animation des cartes
Ajout des images de l'interface
Chat
Bouton Lancement de la partie
Placement des joueurs
Mise en forme graphique (CSS)
Ajout emplacement de l'avatar des joueurs
Rédaction des livrables
12
5.3.3 Communication Diagramme de Gant du développement.
5.3.4 Gestion et traitement des données Diagramme de GANTT sur l’ensemble du projet.
6. Évaluation des charges L'évaluation des charges est réalisée en plusieurs parties. Une première partie générale comprenant essentiellement la réalisation du dossier de conception. Ensuite, une seconde
13
partie comprenant le développement qui doit être faite par chacun des groupes, et enfin une partie intégration et lancement de projet qui est générale.
6.1. Réalisation du dossier de conception
● Diagramme de cas d'utilisation : 1 TD ce qui représente 3h/étudiant ● Diagramme de séquence : 3 TD ce qui représente 9h/étudiant ● Diagramme de classe : Réalisé par le groupe "DATA" => 4h/étudiant du groupe ● Diagramme de classe des autres groupes => 1h/étudiant du groupe ● Ecriture du dossier de conception => 2h/responsable conception ● Relecture du dossier => 4h
6.3. Développement
La phase de développement a durée 8 TD + une séance de 2 heures supplémentaires, ce qui représente dès lors 26h/étudiant, + des séances d’intégrations prévus le jeudi soir + du travail personnel. Groupe IHM Main Pour l’ensemble des membres du groupe, le travail personnel réalisé en dehors des séances est estimé à 2h/semaines. Des réunions tout au long du semestre durent également effectuées pour avancer au mieux sur le projet. Généralement, ces réunions se déroulaient le mardi avant la séance de TD, durant la séance du deuxième groupe de TD. Donc, en moyenne, l’évaluation des charges est portée à 47h/étudiant. Groupe IHM Table Nous estimons la charge de travail des membres à 3h/semaine lors des 4 dernières semaines, ce qui en plus des 3 heures par TD nous amène à 48h/etudiant. Cependant, il est à noter que notre directeur s’est particulièrement investi dans ce projet, et a donc beaucoup plus travaillé que ne l’indique cette moyenne. Groupe Communication Nous avons tout d’abord réalisé plusieurs réunions tous ensemble au début du projet pour réaliser le modèle conceptuel et le serveur. Nous pouvons comptabiliser que ces réunions nous prenaient 3h/personne par semaine en début de réalisation (7 semaines). Ensuite, une fois le serveur et le client mis en place, notre travail était simplifié, nous avons alors travaillé chacun de notre coté, nous pouvons donc estimer ce travail à 1h par semaine.
14
S’ajoute à cela les séances d’intégration supplémentaires, que l’on peut compter comme 1h par semaine jusqu'à la fin de la réalisation. En moyenne, l’évaluation des charges par personne est de 44h/étudiant. Groupe Data Nous avons effectué des réunions de 2 heures chaque lundi soir, lors de laquelle le directeur et les responsables qualité et conception étaient présent, ainsi qu’une présence partielle des autres membres du groupe. A cela s’ajoute le travail personnel effectué par chaque membre, variant en fonction des semaines, mais estimé à environ 2h par semaine sur l’ensemble du projet pour chaque membre. Cela amène le total à environ 49h/étudiant en moyenne.
6.4. Intégration L’intégration était réalisée par les responsable intégrateur pendant les séances de TD, au total 6 TD, mais également pendant la séance supplémentaire de 2h le mardi 22 décembre, ainsi que deux jeudi en soirée durant 2h. L’évaluation des charges de l’intégration est donc portée à 24h/responsable intégration.
7. Gestion des risques
7.1 Identification, évaluation et quantification des risques Les risques que nous avons identifié au sein du projet sont :
● La répartition des charges de travail: Déséquilibre des charges de travail (mal évaluées) entre les groupes amenant un retard de certains groupes sur les autres.
● La communication : ○ Problèmes d'intégration au moment de rassembler les différents projets des
différents groupes par manque de communication. ○ Non communication au sein d'un même groupe réduisant donc sa productivité
fortement. ● Les technologiques:
○ Non respect des normes de développement et des technologies choisies ○ Mauvaise utilisation des outils de versionnage (ici GitHub)
● Autres : ○ Accidents naturels/humain à l'un des membres du groupe ou aux outils
permettant le développement du logiciel ○ Non aboutissement de la réalisation de toutes les fonctionnalités demandées
dans le cahier des charges
15
7.2 Stratégie de gestion des risques
La première chose à considérer pour ce projet est la communication. Si celleci est mise en place correctement, une partie des problèmes peuvent être résolus. En effet, dès qu'un problème est détecté, il doit être rapidement remonté et toutes les personnes concernées doivent être mises au courant. Ensuite, si la communication se fait correctement les différentes décisions seront prises de manière plus efficace. Les solutions pouvant être mises en oeuvre sont:
● La rencontre des différents membres de chaque groupe chaque semaine pour faire le point sur l'avancement du projet.
● La rencontre de tous les directeurs pour mettre en commun les problèmes rencontrés dans chaque groupe et faire passer les messages efficacement.
● La rédaction de compte rendu suite à chaque réunion et chaque TD accessible à tous, pour que tout le monde puisse être au courant de l'avancement.
● La mise à l’écart de certaines fonctionnalités jugées optionnelles pour permettre de finir la réalisation du projet dans les délais.
Ensuite, en cas de problème interne à un groupe, c'est au manageur de tenter au maximum de régler les conflits. Étant donné que nous sommes dans une réalisation étudiante, sans réels chefs de projets, il est intéressant d'utiliser un management participatif.
Les décisions prisent doivent être justifiées et notées sur le document "Décisions prises" présent sur le drive.
16
8. Gestion de la qualité
Pour la gestion de la qualité nous avons opté pour l’utilisation de SonarQube, qui est un logiciel en libre service permettant de mesurer la qualité du code source en continu. Le logiciel de qualité précédent permet :
● d’identifier des duplications de code ● de mesurer le niveau de documentation ● de vérifier le respect des règles de programmation ● de détecter des bugs potentiels ● d’évaluer la couverture du code par les tests unitaires ● d’analyser la répartition de la complexité ● d’analyser le design et l'architecture de l’application
Au sein de chaque sousgroupe, des responsables qualités ont été sélectionné dans le but de travailler continuellement sur les facteurs de qualités suivants :
● Fonctionnel ❖ pertinence : aptitude à répondre au problème posé ❖ adéquation : adéquation du produit à l'organisation cliente ❖ généralité : aptitude à répondre à des problèmes plus larges
● Utilisation ❖ maniabilité : aptitude à être convivial et facile d'emploi ❖ fiabilité : aptitude à accomplir ses fonctions sans défaillance ❖ efficience : aptitude à minimiser les ressources utilisées ❖ confidentialité : aptitude à être protégé contre tout accès à des personnes
nonautorisées ❖ couplabilite : aptitude à interagir avec d'autres systèmes (interopérabilité)
● Maintenance ❖ maintenabilité : facilité à localiser et corriger des erreurs résiduelles ❖ adaptabilité : aptitude à évoluer facilement ❖ portabilité : facilité à transférer dans un autre environnement
● Economique ❖ efficacité : rapport des coûts effectifs et d'utilisation par rapport au gain
Une Javadoc est également générée permettant de créer une documentation d'API en format HTML depuis les commentaires présents dans un code source en Java. Javadoc est le standard industriel pour la documentation des classes Java. La plupart des IDEs créent automatiquement la javadoc HTML.
17
9. Déroulement du projet
9.1 Processus décisionnel
9.1.1 ClientServeur vs PeerToPeer Au début du développement, un choix s’offrait à nous entre une application réalisée en Peer To Peer ou bien en client/serveur. L’application en Peer To Peer avait pour avantage de ne réaliser qu’une “application” locale, pouvant communiquer avec les autres applications. L’application en client/serveur était plus simple à développer : un seul serveur gère le jeu et synchronise de manière efficace les différentes applications locales. Cette solution possède aussi des risques de goulot d’étranglement en cas de traffic important, et cela nécessitait de développer deux applications. Nous avions tout d’abord des connaissances plus poussées pour la solution client/serveur. Ensuite, il nous paraissait plus logique qu’un serveur fasse le maître du jeu, il ne nous paraissait pas forcément logique qu’un client fasse le déroulement du jeu, et cela simplifiait la synchronisation. Nous avons fait le choix de faire communiquer le serveur seulement avec les interfaces de data, qui elles même communiquent avec les IHM.
Le serveur communique par le biais de ObjectOutputStream et ObjectInputStream qui sont des classes java permettant des objets sérialisés à travers des socket. Nous avons crée un classe message, possédant deux méthodes process(). L’une est destinée au serveur, lorsqu’il reçoit un message provenant d’un client, il exécute le process du message. L’autre est à destination du client, lorsqu’il reçoit un message, il exécute le process du message. Nous passons en paramètre de ces process les thread qui envoient le message, cela permet au serveur de répondre directement au client s’il en a besoin ou bien au client de répondre au serveur. Les messages peuvent aussi avoir en attributs des objets qui doivent être sérialisables pour pouvoir transiter sur le réseau. Nous avons donc décidé de rendre tous les objets sérialisables.
18
9.1.2 Gestion du profil Le profil local de l'utilisateur est synchronisé avec un profil temporaire sur le serveur. A chaque modification du profil, le serveur en est informé. Il n'y a que le profil local stocké sur la machine de l'utilisateur. Dès qu'un utilisateur souhaite voir un profil, il envoie une requête au serveur qui lui renvoie le profil de l’utilisateur concerné. Un utilisateur peut aussi modifier son profil. Cela provoquera une modification en local, mais aussi informera le serveur de cette modification.
9.1.3 Connexion Tout d’abord, le client doit choisir un serveur. Il en existe un par défaut, mais il peut aussi en ajouter un, s’il a connaissance d’un serveur actif. Ensuite lorsqu’il se connecte, l’application locale vérifie directement ses identifiants en local, puis, s’ils sont bon, le connecte au serveur. L'utilisateur est reconnu sur le serveur par un UUID unique. Lorsqu’il est connecté, il reçoit la liste des tables actives et des joueurs connectés qu’il affiche.
9.1.4 Fenêtre principale Dès qu'il y a une mise a jour coté serveur (création d’une table, lancement d’une table, connexion d’un joueur, etc..) on notifie tous les utilisateurs du changement. Cela pose un problème au niveau du nombre de notifications circulant sur le réseau à chaque modification, mais permet une synchronisation efficace.
9.1.4 Lancement d’une partie Un utilisateur peut rejoindre une table lorsqu’elle est active mais qu’elle n’a pas débutée. Le créateur de la partie peut décider de lancer la table s’il y a un nombre de joueurs suffisant avec lui. Cela envoie alors à tous les autres utilisateurs une demande pour savoir s’ils sont prêts. Si tous les joueurs indiquent qu’il sont prêt, la partie peut commencer.
9.1.5 Déconnexion & hearthbeat Un utilisateur a plusieurs possibilités pour se déconnecter. Il peut tout d’abord quitter l’application de manière conventionnelle en appuyant sur le bouton quitter. A ce moment, un message est envoyé au serveur, sa socket et fermée, et tous les utilisateurs en sont informé. Il
19
peut aussi quitter l’application de manière brutale en cliquant sur la croix rouge (alt F4). A ce moment là, l’action est repérée par IHM Main et le serveur est pareillement informé de la déconnexion de l’utilisateur. Enfin, si par exemple la connexion d’un utilisateur se termine (coupure internet), le serveur doit avoir un moyen de savoir si l’utilisateur est déconnecté ou non. Pour cela, nous utilisons le principe du hearthbeat. De manière régulière, chaque client envoie au serveur un ping pour le signifier de sa présence. Le serveur enregistre ces ping et les stockent dans une liste. Si le serveur n’a pas reçu de ping dans un intervalle de temps équivalent à 10 fois la fréquence d’envoi (cela permet de réguler de manière correcte même s’il y a de la latence), alors il considère que l’utilisateur s’est déconnecté et le fait quitter la partie/l’application. Cela permet d’avoir une communication dans un seul sens pour gérer les utilisateurs connectés.
9.2 Liste des autres décisions prises
9.2.1 Choix technologiques Langages de programmation : Java version : 1.8 IDE : Intellij IDEA Serveur : Développé en java par le groupe COM. (socketServer, thread, objectInputStream) UML : Modelio
9.2.2 Outils de management
Gestionnaire de version : Git A chaque séance, une branche d’intégration est crée pour mettre en commun le code de tous les groupes. A la fin de l’intégration, les besoins sont remontés aux différents groupes. Outils de communications:
Slack utilisé pour échanger des informations relatifs au développement. Google Drive pour entreposer des documents mails, téléphones
20