Table des matières TABLE DES MATIÈRES 1. Introduction 3

Transcription

1

2

3 TABLE DES MATIÈRES 1 Table des matières Introduction 3 1 Organisation des tâches Présentation rapide de notre projet Périmètre des autres projets Conception Implémentation Gestion des entrées/sorties Gestion graphique Modèle Intégration des autres projets Administration Coordination Démarche de planification Périmètre de planification Pilotage du projet Périmètre fonctionnel et périmètre de qualification Les risques envisagés Les solutions apportées Méthodes de production et de validation Répartition des groupes Planification des tâches Conception Implémentation Gestion des entrées-sorties Modèle La gestion graphique Administration Intégration Les jalons Livraison Diagramme de Gantt Diagramme de chronologie du projet Conclusion 21 Bibliographie 22

4

5 INTRODUCTION 3 Introduction Dans notre projet de 4ème année, nous nous intéressons à un travail sur la réalité virtuelle. Celle-ci désigne une technique scientifique permettant l immersion et l interaction d un utilisateur dans un monde symbolique. Notre projet porte plus particulièrement sur le développement d un logiciel permettant la coopération de deux utilisateurs dans un univers virtuel composé de legos. Pour le réaliser, nous avons deux salles à notre disposition : une au département informatique de l INSA de Rennes (µrv) et l autre sur le campus de Beaulieu à l Espace des Technologies Innovantes (Immersia). Pour cette dernière, nous l utilisons que ponctuellement car elle est principalement employée par l équipe de recherche INRIA/Irisa, VR4i. Cette équipe est composée de chercheurs et d enseignants-chercheurs, dont nos encadrants à savoir Valérie GOURANTON et Ronan GAUGNE. Pour l autre salle, µrv, le département informatique l a équipé de tout le matériel nécessaire pour faire de la réalité virtuelle. Assurer la mise en place, la maintenance et l administration de cette salle font partie de nos objectifs. La salle µrv est une vitrine technologique de l INSA de Rennes qui vise à établir une collaboration entre enseignement et recherche. De plus, l application permettra de s ouvrir au grand public lors des journées portes ouvertes et mettra en avant le dynamisme du département informatique. Notre application reprendra le projet de l année dernière développé par la promotion précédente. Comme énoncé précédemment, elle permet l interaction entre deux utilisateurs. Le premier, nous l avons appelé coureur. Il sera plongé au cœur d un labyrinthe composé de Legos. Son but sera d atteindre la sortie du labyrinthe en un temps limité. Le deuxième utilisateur, appelé constructeur, devra à tout prix empêcher le coureur de sortir de son labyrinthe. Pour cela, il pourra positionner de nouvelles pièces Legos qui entraveront le coureur pour lui faire perdre un temps précieux. Ces deux modes seront utilisés simultanément par les deux utilisateurs. Un administrateur pourra configurer ces deux modes, dont la gestion de la communication entre le coureur et le constructeur. Le projet s articule autour d autres équipes de 3ème et 5ème année du département informatique : une équipe de 3ème année, sur le même projet ; quatre équipes de 5ème année, une en support de notre projet, et trois autres utilisant la salle. Dans un premier temps, nous présentons dans ce rapport l organisation des tâches de notre projet. Les tâches correspondent aux différentes solutions techniques qui ont été choisies. L objectif de cette partie est de décrire de façon technique et très concise les éléments techniques à implémenter, afin d obtenir un bilan des tâches à planifier. Ce sera une présentation du projet d un point de vue technique. Les points abordés sont les tâches à réaliser lors de la conception, l intégration des modules des autres groupes dans notre projet, les tâches à faire pour l implémentation. Nous exposons dans une deuxième partie, la planification des tâches. Elle détaille dans un premier temps, les hypothèses de la planification ; à savoir la formulation des paramètres essentiels permettant de correctement caractériser notre projet. Ensuite, la démarche de la planification est exposée et indique les volumes horaires estimés des tâches. Les itérations

6 INTRODUCTION 4 et les jalons seront ensuite exprimés ainsi que la répartition des membres du projet en groupes de quatre personnes. Enfin, nous décrivons le détail de la planification de la conception et de l implémentation pour montrer en dernier le diagramme de Gantt au complet avec sa chronologie associée.

7 1 ORGANISATION DES TÂCHES 5 1 Organisation des tâches Avant de planifier les tâches, il faut les définir. C est le sujet de cette première partie. Après avoir présenté rapidement notre projet et ceux en lien avec nous, nous aborderons les tâches de conception, d implémentation et également de coordination. 1.1 Présentation rapide de notre projet Notre application comportera deux utilisateurs agissant différemment et utilisant des périphériques différents. Il convient donc de les traiter séparément. Le premier utilisateur, dit coureur, ne pourra que se déplacer et pivoter. Pour cela, les mouvements du joueurs seront captés par la Kinect. Il regardera l environnement dans lequel évolue son avatar à l aide des lunettes Nvidia et d un vidéoprojecteur, pour une vision stéréoscopique. Le deuxième utilisateur, dit constructeur, pourra se déplacer mais aussi poser des pièces Legos. Il sera plongé dans l environnement grâce au casque Vuzix Wrap 920. Ces actions seront captées à l aide d une WiiMote. Un administrateur sera également indispensable au bon fonctionnement de l application. En effet, il gérera la configuration de l application ainsi que la communication entre les deux utilisateurs. Pour réaliser notre projet, une salle est mise à notre disposition. Elle contient le matériel cité ci-dessus ainsi que trois ordinateurs et un joystick. 1.2 Périmètre des autres projets Un projet de 3ème et quatre projets de 5ème année sont en relation avec le nôtre. Parmi ceux-ci, deux sont étroitement liés à nous. Les autres groupes n ont besoin que de l accès à la salle car leurs projets n ont pas de rapport direct avec notre application. Le groupe de 3ème année réalise un générateur de labyrinthe en lien avec notre application. En effet, les utilisateurs seront plongés au sein d un labyrinthe qui sera utilisé dans notre application. Un groupe de 5ème année travaille sur la communication entre deux ordinateurs à l aide d OpenMASK 1 et sur l interfaçage des différents périphériques mis à notre disposition. Leur travail pourra nous être d une aide précieuse. 1.3 Conception La première tâche que l on va devoir réaliser est la modélisation de notre application. Cela va nous permettre d avoir un développement plus clair et plus rapide. 1. Plateforme de développement 3D

8 1 ORGANISATION DES TÂCHES 6 La première partie de la phase de conception est la définition précise de l architecture interne. L application sera ensuite modélisée à l aide de diagrammes UML 2. Des diagrammes de cas d utilisation, de classes, de séquences, d étatstransitions, de composants et de déploiement seront notamment réalisés. L interfaçage des différents modules devra également être clairement défini. D éventuelles modifications pourront être apportées à la planification suite à cette phase de modélisation. D ores et déjà, un premier diagramme de conception général a été réalisé (cf. figure 1 p. 7). 2. Unified Modeling Language : Langage de modélisation à base de diagrammes très utilisé.

9 1 ORGANISATION DES TÂCHES 7 Figure 1 Architecture logicielle générale

10 1 ORGANISATION DES TÂCHES Implémentation Cette partie présente rapidement la séparation de notre application en différents modules Gestion des entrées/sorties L interactivité de notre application nécessite l utilisation de nombreux périphériques tels que la Kinect, les WiiMotes, les lunettes 3D Nvidia et les lunettes Wuzix Wrap 920. Chacun de ces périphériques est indépendant et nécessite ses propres réglages ainsi que ses propres tests. Leur intégration dans notre logiciel se fait avec OpenMASK et est réalisée de façon indépendante des autres périphériques Gestion graphique La partie graphique contient le développement sous le moteur Ogre3D 3 et de son intégration sous OpenMASK. Elle se concentre sur le rendu des différentes composantes graphiques tel que les pièces Legos, le terrain ou encore l avatar du coureur. De plus, l application comporte aussi quelques interfaces non natives à Ogre3D comme la gestion des menus ou des différentes informations contextuelles, telles que le temps restant ou la pièce courante sélectionnée. La séparation coureur / constructeur se fait à ce niveau. Figure 2 A gauche, le coureur, à droite, le constructeur Modèle Ce module est le cœur de l application. En effet, il gère l ensemble des données et des algorithmes non spécifiques aux matériels ou à un logiciel particulier. Il contient notamment les informations sur le terrain et sur l état des utilisateurs Intégration des autres projets Intégration du projet des 3ème années Cette partie est un programme indépendant effectué par le groupe de 3ème année qui génère un labyrinthe sous format XML 4. Ce fichier sera ensuite 3. Moteur 3D. Il gère le rendu en 3 dimensions des différentes composantes graphiques. 4. Extensible Markup Language : Langage informatique à base de balise souvent utilisés pour le stockage de données.

11 1 ORGANISATION DES TÂCHES 9 chargé par le modèle qui initialisera les différentes pièces sur le terrain virtuel géré par le moteur 3D. Intégration du projet des 5ème années Pour que l application soit collaborative, un module dédié à la communication distante entre les différents composants physiques est nécessaire. Ce module spécifique, effectué par le groupe de 5ème année, utilise le protocole de transfert de données TCP/IP pour le partage de l information. Grâce à ce module, les utilisateurs sont capables d émettre et de recevoir les différentes actions qu ils effectuent Administration Le module d administration règle l ensemble des paramètres de configuration des programmes : gestion du terrain, notamment le chargement d une partie pré-enregistrée ; hébergement de l application ; configuration des paramètres réseaux pour la communication distante. 1.5 Coordination Dans le cadre de notre projet, nous sommes amenés à échanger des informations avec les autres groupes, soit via l envoi d s, soit si la situation l exige, par une rencontre inter-groupe. Nos encadrants sont également des intermédiaires puisqu ils supervisent d autres groupes de projet de réalité virtuelle du département informatique.

12 2 DÉMARCHE DE PLANIFICATION 10 2 Démarche de planification Nous introduisons dans cette partie les éléments de planification correspondant aux éléments techniques précédemment évoqués. Nous présentons notre démarche de planification : nous formulons les paramètres clés essentiels à la planification permettant de correctement caractériser notre projet. 2.1 Périmètre de planification Pilotage du projet Notre projet est essentiellement basé sur deux modes de pilotage : à la fois par les délais (jalons de présentations, de rendu de rapport, etc.), et par les ressources car celles-ci sont fixes Périmètre fonctionnel et périmètre de qualification Tout d abord, le périmètre fonctionnel s échelonne sur différents niveaux : stabilité : celle-ci est faible car notre cahier des charges peut encore, avec autorisation préalable, être modifié. précision : la précision est surtout indiquée dans le rapport de spécification fonctionnelle générale. Celui-ci étant réalisé très en amont du projet, certaines fonctionnalités sont présentées d une manière très générale tandis que d autres sont bien renseignées. complétude : bien présente car nous partons de deux projets déjà réalisés. Le niveau attendu pour notre application se décline également en plusieurs échelons : le déploiement de notre application se réalisera dans la salle µrv et éventuellement dans la salle Immersia. l étude de faisabilité a été menée dans le rapport d analyse. les expérimentations de notre application se réaliseront à la fois par des tests classiques et des tests de l application dans la salle µrv. la maintenabilité de l application sera faible ou quasi-inexistante car le projet se termine en Juin la phase de test sera constituée de tests unitaires explicites et automatisés. Plus particulièrement, notre plan de test prévoit la mise en place de tests de non régression, avec une validation pas à pas des fonctionnalités. Les tests se dérouleront sous Windows. Toutefois, le code fourni ne doit respecter aucune certification particulière Les risques envisagés Certains risques sont susceptibles d apparaître au cours de notre projet. Bien qu il soit difficile de les prévoir, nous avons réalisé une analyse succincte quant à la possibilité d apparition de ceux-ci et de leur gravité.

13 2 DÉMARCHE DE PLANIFICATION 11 Risque Probabilité Gravité Indisponibilité du dépôt distant Développement nécessitant plus d heures Projet groupe en support 3INFO non achevé Projet groupe en support 5INFO non achevé Vol de périphérique Panne, perte de périphérique Moyen de prévention Solution Faible Haute - Dépôt local Moyenne Moyenne Moyenne Faible Faible 2.2 Les solutions apportées Moyenne Faible Moyenne Moyenne Haute Méthodes de production et de validation Suivi des tâches planifiées Contacts réguliers avec l équipe Contacts réguliers avec l équipe Gestion régulière des clés Bien entretenir les salles, maintenir des contacts réguliers avec les autres utilisateurs des salles et leurs communiquer d éventuelles remarques concernant le matériel et l entretien Notre projet est constitué de quatre phases relativement importantes. Nous pouvons alors identifier un cycle de production en quatre temps : analyse, élaboration, construction et déploiement. Il est ainsi constitué d itérations permettant d être au plus près des souhaits de nos encadrants. Aussi, notre projet est dirigé par un certain nombre de cas d utilisation, qui eux même dirigeront les tests. L architecture est, quand à elle, détaillée au fur et à mesure que le projet évolue. Toutes ces constatations nous ont menés à l adoption du processus unifié tout au long du projet. Pour le processus de développement, nous prévoyons l utilisation de la méthode SCRUM 5. Celle-ci est bien adaptée à la situation car le développement se déroule en sous-tâches que sont les entrées-sorties, le modèle et l intégration des autres projets. Nous retrouvons donc des «sprints 6» de 15 à 30 jours. 5. La méthode SCRUM est une méthode de développement agile, où les périodes de développement se réalisent en sprints de 20 à 30 jours, qui se terminent par un jalon. Lors de ces jalons, la mise au point d au moins un produit partiel est prévue. 6. Les sprints font référence à la méthode SCRUM. Ils désignent les périodes de 20 à 30 jours entre les itérations. Restructuration des fonctionnalités Création manuelle des fichiers de labyrinthe Élaboration d un système d administration «de secours» Prévenir les encadrants de projet Prévenir les encadrants de projet

14 2 DÉMARCHE DE PLANIFICATION 12 Bien que le développement se réalise par itérations, celles-ci sont aussi l occasion de faire le point sur des tâches transverses telles que les réunions, les journées portes ouvertes, la communication avec les autres groupes, etc Répartition des groupes Notre groupe de projet est composé de six personnes, et de deux encadrants. L organisation retenue est la formation de 3 équipes de 4 personnes. Une personne appartient à deux équipes différentes. Ces trois équipes sont respectivement appelées «équipe matériel» (entrées - sorties), «équipe coureur» et «équipe constructeur». D autre part, un directeur de projet est prévu pour chaque phase d évolution du projet. Un ou des responsables sont également désignés pour d autres fonctions secondaires, telles que la documentation en ligne, la planification ou la correction orthographique.

15 3 PLANIFICATION DES TÂCHES 13 3 Planification des tâches Nous reprenons la démarche précédente et les éléments techniques vus antérieurement pour formuler une estimation de la charge. Cette estimation a été fournie par itérations en fonction des contraintes, avec l aide de l outil de planification : Microsoft Project. Nous présenterons enfin le diagramme de Gantt 7 et la chronologie associée, en correspondance avec notre planification. 3.1 Conception La phase de conception est constituée d une unique tâche dédiée à la rédaction du rapport de conception. Nous avons estimé le temps nécessaire à sa rédaction à 75 h. Par ailleurs, un jalon de livraison du rapport a été fixé pour le 10 février Implémentation L implémentation (660h) est subdivisée en deux grandes parties : l une dédiée au développement de la gestion des entrées-sorties et l autre au développement du modèle qui correspond au cœur de l application Gestion des entrées-sorties Nous avons distingué cinq grandes tâches inhérentes au développement des entrées-sorties. Pour rappel, cette phase vise à implémenter l ensemble des composants logiciels nécessaires à la gestion des périphériques. Nous avons estimé la durée de développement à 80 heures, ce qui peut paraître exagéré puisqu il existe d ores-et-déjà des environnements de développement dédiés aux périphériques utilisés (notamment pour la Kinect et la WiiMote). Cependant, les premiers tests que nous avons réalisés sur ces périphériques nous ont montré que les technologies employées, encore jeunes, pouvaient se révéler instables ou complexes à utiliser. Nous avons donc inclus dans la répartition des heures une marge conséquente, pour contrebalancer les éventuels problèmes que nous serions amenés à rencontrer. Nous avons donc réparti le volume horaire de travail de cette manière : «Événements de la Kinect» : 20 h «Événements de la WiiMote» : 20 h «Corrélation lunettes-application» : 8 h «Intégration de l application Ogre3D dans OpenMASK» : 30 h «Collaboration OpenMASK» : 2 h La partie corrélation lunettes-application vise avant tout à vérifier que le matériel est capable de gérer nativement la 3D de l application et les lunettes ; d où un temps de travail estimé relativement faible. De même, la collaboration OpenMASK ne devrait être qu une configuration technique à effectuer. 7. Un diagramme de Gantt permet de visualiser les tâches à réaliser en fonction du temps.

16 3 PLANIFICATION DES TÂCHES 14 Nota : la partie «intégration de l application Ogre3D dans OpenMASK» nécessite la réalisation de la tâche «gestion graphique» détaillée ci-après Modèle La phase modèle de la planification vise à développer le cœur même de l application, ce qui explique le volume horaire important accordé à cette partie (250 h). Les macro-tâches du modèle macro-tâche coureur (95h) : elle est constituée d une première tâche «construction du modèle» (25h) et d une seconde «déplacement et interactions» (70h) macro-tâche constructeur (115h) : elle constituée des même tâches que celles du coureur mais possède en plus une tâche de «gestion des pièces» de 20h. Les autres tâches Nous avons également spécifié d autres tâches dans la phase «modèle» : «gestion du temps» (20h) «gestion du son» (20h) La gestion graphique La phase «gestion graphique» (160h) vise à implémenter l interface hommemachine (IHM) de l application. Les tâches de la gestion graphique tâche «Ogre3D» (122h) : cette phase est dédiée exclusivement à l affichage 3D, tâche «interface graphique» (38h) : cette tâche vise à implémenter les menus de l application Administration Nous avons décidé d accorder un volume horaire conséquent (60h) à cette phase de développement dans la mesure où elle concerne la configuration et la communication entre les applications, opération qui peut nécessiter l apprentissage de nouvelles connaissances Intégration Notre projet nécessite à la fin de son développement d être fusionné avec deux autres projets de 3ème et 5ème année, ce qui explique une période de test conséquente.

17 3 PLANIFICATION DES TÂCHES 15 Les tâches de l intégration (110h) tâche «intégration du projet de 3ème année» (25h) tâche «intégration du projet de 5ème année» (25h) tâche «test d intégration» (20h) tâche «recette» (40h) : les différents acteurs du projet se rencontrent afin de vérifier que le produit est conforme au cahier des charges Les jalons Trois jalons ont été définis dans la phase d implémentation : «interactions entre utilisateur et matériel» pour le 24 février 2012 «immersion dans un monde en 3D» pour le 16 mars 2012 «applications constructeur et coureur finales» pour le 27 avril Livraison La phase livraison (90h) est constituée de trois tâches : l une dédiée à la rédaction du rapport final (30h), une seconde pour la réalisation de la présentation finale (30h) et une dernière consacrée à la rédaction de la documentation du projet (30h). L important volume horaire dédié à cette tâche, nous permet d avoir une marge de manœuvre en cas de retard lors du développement. Nous avons défini trois jalons : «livraison du rapport final» pour le 30 mai 2012 «livraison du projet» pour le 31 mai 2012 «présentation finale» pour le 31 mai Diagramme de Gantt

18

19 3 PLANIFICATION DES TÂCHES 17 Figure 3 Diagramme de Gantt

20 3 PLANIFICATION DES TÂCHES 18

21 3 PLANIFICATION DES TÂCHES Diagramme de chronologie du projet Figure 4 Diagramme de Chronologie du projet

22

23 CONCLUSION 21 Conclusion Notre projet porte sur la réalisation d une application ludique utilisant la salle de réalité virtuelle du département informatique. Elle mettra en jeu deux utilisateurs interagissant au sein d un univers virtuel. Le premier utilisateur, appelé coureur, doit sortir d un labyrinthe en Legos en un temps limité. Le deuxième utilisateur, appelé constructeur, doit empêcher le coureur de sortir avant la fin du temps imparti. Pour planifier cette application, nous avons d abord séparé les différentes tâches à réaliser. La modélisation de l application, l implémentation et la livraison sont les principales étapes du projet. Celui-ci s intègre dans un ensemble plus large et des tâches d intégration de composants applicatifs d autres projets seront nécessaires. En effet, plusieurs groupes de 3ème et 5ème année travaillent également autour de la salle µrv et sont en support de notre projet. Une fois ces tâches définies, il nous a fallu les planifier. Pour cela, des volumes horaires ont été estimés pour chaque tâche. Ces tâches ont ensuite été ordonnées, aboutissant à un diagramme de Gantt. La mise en place de jalons témoigne, par des changements de versions, de l utilisation de la méthode SCRUM du développement agile. Enfin, une première estimation des charges prévisionnelles a pu être évaluée. Une charge d environ 825 heures devra être au réalisée pour finaliser notre projet. La planification initiale réalisée nous permettra de suivre une ligne directive claire.

24 RÉFÉRENCES 22 Bibliographie Références [1] Dépôt officiel du projet, disponible sur https ://forge.insarennes.fr/redmine/projects/microrv/ [2] Site de Microsoft Project, disponible sur http :// [3] Cours de gestion de projet, par M. Thierry ROGER [4] Projet de l an passé, disponible sur http ://l3g0.net [5] Bruno Arnaldi, Pascal Guitton et autres auteurs, Le traité de la réalité virtuelle, Volume 1,2,3,4, Mines Paris (Sciences mathématiques et informatiques) [6] Site officiel d OpenMask, disponible sur http :// [7] Site officiel d Ogre3D, disponible sur http :// [8] Site officiel d OpenNI, disponible sur http ://openni.org [9] Site de VRGeeks, disponible sur http :// [10] Site NVidia, disponible sur http ://