Université de Technologie de Compiègne   

  

LO23 Plan de management de projet 

  

  

04 Janvier 2016  

                    

 

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 IHM­MAIN 5.3.2 IHM­Table 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 Client­Serveur 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 

9.2.1 Choix technologiques 9.2.2 Outils de management 

     

2 

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. 

­ IHM­Main : Victor LECLERC (directeur), Frédéric CUNI (manageur), Jean­Baptiste                 (développeur), Romain DI FATTA (étude, qualité), Paul Jenny (conception), 

­ IHM­Table : 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), Jean­Cô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 use­cases ● 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 sous­groupe a identifié des tâches à effectuer et à                             développer. Un compte­rendu 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                           sous­groupe et de régler des difficultés inter­groupe et intra­groupe.   

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                       pre­alpha. 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 : 

● IHM­Main ● IHM­Table ● 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é ci­dessous 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é ci­dessous 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                           sous­groupe.  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 sous­groupes, 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 sous­groupe, 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 IHM­MAIN   Diagramme de GANT sur l’ensemble du projet.  

     

11 

 5.3.2 IHM­Table 

 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 celle­ci 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 sous­groupe, 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                       

non­autorisé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 Client­Serveur 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