Bilan de la planification du projet NavInc

Transcription

1 Florian BASTIEN Fabien CORNIC Antoine DESPRES François DROUMAGUET Bastien PRZYBYLSKI Bilan de la planification du projet NavInc Jean-Louis PAZAT Nikolaos PARLAVANTZAS

2 SOMMAIRE CHAPITRE 1 DÉROULEMENT DU DÉVELOPPEMENT ) Fonctionnement et partage du travail ) Première phase du développement : du 1 er au 31 mars ) Deuxième phase du développement : du 1 er avril au 25 mai CHAPITRE 2 GESTION DU PROJET ) Ordonnancement des tâches ) Méthode de suivi de projet

3 CHAPITRE 1 DÉROULEMENT DU DÉVELOPPEMENT 1.1) Fonctionnement et partage du travail Tout au long du développement, nous avons essayé de suivre la planification des tâches qui avait été établie en décembre Lors de cette phase, nous avions analysé les risques qui pouvaient entrainer du retard sur la réalisation du projet. Le risque majeur était la réutilisation du logiciel Traveling Salesman (logiciel libre de navigation, réutilisable pour le développement d applications de type GPS). Si cette réutilisation n avait pas été possible, nous n aurions pas pu réaliser le démonstrateur. Un autre risque important était la maîtrise de la technologie OSGi. Si nous n avions pas trouvé de tutoriel sur l Internet, nous aurions mis beaucoup plus de temps pour développer notre architecture orientée services. Le développement a été divisé en deux parties. L équipe TS, avec Antoine, François et Bastien, s est occupée de la réutilisation du logiciel Travelling Salesman. L équipe OSGi, avec Fabien et Florian, s est occupée de la réalisation du mécanisme d adaptation dynamique. La mise en commun du travail (l intégration des services dans l application) a été réalisée par les deux équipes. Ce partage des tâches en deux équipes n était pas prévu dans la planification. Nous avons fait ce choix par rapport à l analyse des risques sur la réutilisation de Traveling Salesman. Ainsi, pendant que l équipe TS essayait de réutiliser Traveling Salesman, l équipe OSGi développait le mécanisme d adaptation dynamique. De cette manière nous n avons pas rencontré de véritable blocage dans la phase de développement. Dans le pire des cas, si Traveling Salesman n avait pas pu être réutilisé, nous aurions quand même développé le mécanisme d adaptation dynamique (il aurait alors manqué la partie «démonstrateur»). 3

4 1.2) Première phase du développement : du 1 er au 31 mars L équipe TS, chargée de la réutilisation de Traveling Salesman, a essayé de faire fonctionner en vain le logiciel. Les problèmes rencontrés avaient été anticipés dans l analyse des risques. Ainsi, d autres pistes ont été explorées pour pouvoir utiliser Traveling Salesman dans notre projet. Cela a induit un retard, par rapport à la planification, sur le développement des services utilisant Traveling Salesman. L équipe OSGi, chargée du développement du mécanisme d adaptation dynamique, devait initialement utiliser ipojo. Après plusieurs tentatives nous n avons pas réussi à utiliser cette technologie pour notre projet. Nous avons ainsi décidé de développer notre propre mécanisme d adaptation. Cette décision n a pas entraîné de retard et la planification du mois de mars a été respectée. À la fin du mois de mars, toute la base du projet était développée. L IHM principale était fonctionnelle et le gestionnaire de services permettait l adaptation dynamique en fonction du contexte. Le premier scénario, la perte et le remplacement du service de cartographie, pouvait être testé. En revanche, aucun développement utilisant Traveling Salesman n avait été réalisé. 1.3) Deuxième phase du développement : du 1 er avril au 25 mai 2010 À la fin de la première phase nous avions quasiment terminé le gestionnaire de services. Les autres composants de l application pouvaient alors se greffer aisément. L équipe TS a réussi à mettre au point une version utilisable de Traveling Salesman sous forme de service. Le développement des services utilisant Traveling Salesman a pu alors commencer. C est à ce moment que nous n avons plus respecté la planification. Compte tenu du temps qu il restait, nous devions annuler le développement des services de lieux d intérêts et de monitoring. En revanche, tous les autres services ont été développés. L équipe OSGi s est principalement occupée d intégrer les services utilisant Traveling Salesman dans l application. Elle a également amélioré le mécanisme d adaptation en le rendant plus générique et a géré le déroulement des scenarii. 4

5 Au final, nous avons réalisé quatre des six scenarii initialement prévus. Scenarii développés : Déroulement normal : l utilisateur demande l affichage d une carte. Déroulement normal : l utilisateur demande le calcul d un itinéraire. Adaptation proactive : perte et remplacement du service de cartographie. Adaptation réactive : passage sous un tunnel (remplacement du service de géolocalisation pour permettre la transmission des données sous le tunnel). Scenarii non développés : Niveau de carburant bas (le logiciel indique à l utilisateur où se trouve la station service la plus proche). Niveau de mémoire faible (suppression des données non utilisées récemment pour libérer de la mémoire). Les scenarii non développés sont liés à l abandon du développement des services de monitoring. Pour les mettre en place il faudrait développer deux services ; un pour gérer le niveau de la mémoire du module de guidage et un pour gérer le niveau d essence du véhicule. Avec les quatre scenarii développés nous pouvons montrer la composition de services ainsi que l adaptation dynamique proactive et réactive. Nous avons ainsi répondu au cahier des charges fixé au début du projet. 5

6 CHAPITRE 2 GESTION DU PROJET 2.1) Ordonnancement des tâches La table ci-dessous représente l ordonnancement réel des tâches pendant la phase de développement du projet. Les tâches situées sur une même ligne ont été réalisées en parallèle. Développement du Gestionnaire de services Développement de l'ihm principale Développement du service Console Recherches sur la réutilisation de traveling salesman Recherche et développement du service de géolocalisation Première phase du développement (sans traveling salesman) Développement du service Administration Développement du service de gestion de données Développement du service de cartographie Développement du service de localisation Développement du service de routage Développement du service d'horloge Deuxième phase du développement (avec traveling salesman) Développement du service de navigation Ordonnancement réel des tâches On voit clairement que cet ordonnancement ne respecte pas la planification initiale. Cela est lié au risque de réutilisation de Traveling Salesman. Nous avons choisi de nous concentrer sur cette réutilisation dès le début du développement plutôt que de suivre la planification. Ainsi les services utilisant Traveling Salesman ont été développés avec du retard. À noter que si nous avions suivi la planification, nous aurions été coincés au moment de l intégration des services utilisant Traveling Salesman dans l application. Cette opération aurait pris plus de temps et par conséquent aurait 6

7 entraîné un retard sur l intégralité du projet. Nous pouvons donc affirmer que nous avons pris la bonne décision dès le début du développement. 2.2) Méthode de suivi de projet Nous pensions utiliser Microsoft Project pour faire notre suivi de projet avec le diagramme de Gantt de la planification. Cependant, les choix faits au début du développement impliquaient trop de changements par rapport à la planification. La mise à jour quotidienne des informations sous MS Project aurait nécessité la charge de travail complète d une personne. Or nous ne pouvions pas nous permettre d affecter une personne à temps complet pour faire le suivi du projet. Par conséquent, nous avons choisi de ne pas utiliser l outil MS Project pour le suivi. À la place, nous avons fait des réunions régulières (en dehors de celles prévues avec nos encadreurs) pour faire le bilan du travail effectué et du travail à faire. Nous avons planifié des phases d intégration et de tests pour mettre en commun le travail des deux équipes de développement. Ce fonctionnement nous a permis de synchroniser les choix de développement entre les deux équipes. Ainsi la programmation était homogène et il y avait une bonne communication entre les deux groupes. 7