Chapter 1 Gestion de projet

1.1 Gestion de configuration

Ce projet a été réalisé en Java. Pour utiliser la version compilée fournie, un Java Runtime Environment dans une version supérieure ou égale à 1.4.0 est nécessaire. Pour un développeur souhaitant compiler le programme, un Java Development Kit dans une version supérieure ou égale à 1.4.0 est nécessaire ainsi que JavaCC dans une version supérieure ou égale à 2.1. Pour bénéficier de toutes les facilités de la recompilation automatique du projet il est préférable d'avoir installé le programme make (seul GNU Make a été testé dans sa version 3.80). La compilation et l'exécution du projet ont été testés sous Linux et Windows avec succès.

1.2 Organisation générale

Dans cette section nous allons présenter le projet tel qu'il s'est déroulé. Nous partons du principe que la fiche projet est connue du lecteur.

1.2.1 Planning

Du point de vue de l'organisation, le projet s'est déroulé correctement, bien que le temps nous ait manqué pour mener à bien toutes les opérations de suivi de projet (nous en reparlerons plus loin). Toutefois nous n'avons pu tenir le planning prévisionnel. Nous avons réalisé deux diagrammes de Gantt, au début du projet et à la fin. Ceux-ci se trouvent en annexe A page ??.

1.2.2 Répartition des tâches

Le découpage en modules relativement indépendants et l'utilisation de techniques de programmation adéquates (paradigme visiteur) nous a permis de travailler en quasi-autonomie. Ainsi, seuls les modules d'analyse lexicale et syntaxique et de gestion de la mémoire furent indispensables pour commencer le développement des autres modules. Pour les autres modules interdépendants, un travail préalable d'organisation et de spécification, notamment au niveau de l'interface, nous a permis d'établir des bases communes pour lancer nos développements en parallèle. Par exemple, le développement des modules de compilation et d'interprétation JaJaCode a commencé simultanément, bien que le deuxième ait besoin du premier pour fonctionner. Avant tout développement, nous avons défini nos structures de données ainsi l'équipe d'interprétation a pu créer un exemple des données produites par le compilateur et commencer son développement sans que celui-ci ne fonctionne. Pour résumer nous pouvons dire que l'équipe a travaillé avec une grande autonomie pour chacun des modules mais avec des spécifications élaborées en commun qui ont permis une interconnexion facile au moment de l'interfaçage.

1.3 Organisation du travail

1.3.1 Outils

Comme prévu dans la fiche projet, nous avons utilisé un ensemble d'outils pour faciliter le travail en commun : CVS, liste de diffusion, réunions fréquentes, messageries instantanées. Malheureusement le serveur CVS mis à disposition par l'IUP n'a pas très bien fonctionné. Au bout de deux semaines, le logiciel WinCVS ne nous indiquait plus les fichiers modifiés et ceux qui ne l'étaient pas, ce qui a rendu son utilisation pénible et inutile. Nous avons alors décidé d'utiliser la liste de diffusion créée pour le projet pour échanger les fichiers sources. La liste de diffusion a été un vecteur très important pour le développement du projet. Elle nous a permis de

Échanger facilement nos fichiers.
Faire circuler rapidement les informations (questions, idées ...)
Faire remonter rapidement les bugs (sans attendre de voir la personne concernée et en gardant une trace datée)

Nous avons également utilisé les moyens de communication classiques : les réunions. Celles-ci étaient fréquentes entre les modules, par exemple pour décider de la communication entre deux modules. Ces réunions étaient généralement informelles. Nous avons également fait environ tous les mois une réunion avec tous les membres de l'équipe pour faire le point sur les travaux achevés, en cours et à venir. Ces réunions avaient pour but de tenir informés tous les membres de l'équipe sur l'évolution du projet. Deux comptes rendus de réunion se trouvent en annexe B. Enfin, nos documentations, rapport et compte-rendus de réunion ont été réalisés grâce à L^AT_EX. Nous utilisons L^AT_EX car il permet d'avoir rapidement un affichage de grande qualité quelque soit le support utilisé. De plus, l'intégration des parties de rapport réalisées par les différentes équipes est grandement facilitée par l'utilisation de ce format car il évite les problèmes liés à la gestion de la mise en page.

1.3.2 Méthodes

Pour faciliter le travail d'interfaçage nous avons accordé une grande importance aux spécifications de chacun des modules. Ces spécifications ont été directement intégrées au code source, via une documentation JavaDoc. Ainsi, l'équipe chargée de l'interfaçage n'as pas eu a autopsier le code source de chaque module pour comprendre son fonctionnement. fonctionnait techniquement. La répartition en module est très forte au niveau conceptuel (séparation du travail en sous-équipes), mais également au niveau physique . Chaque module se trouve dans un répertoire contenant :

Les fichiers du module indispensables à sa compilation;
Les fichiers de test;
Les éventuels fichiers de ressource (images, ...);
Le fichier Makefile.

Et à chaque module/répertoire correspond un package Java. Pour gérer tout le projet, nous avons fait une très forte utilisation de fichiers Makefile en particulier pour faciliter la recompilation des sources. En effet, l'ordre de compilation des packages est important. Gérer ces dépendances à la main est fastidieux et implique que chaque personne désirant compiler le projet sache comment les modules interagissent. Pour pallier ce problème nous avons utilisé la puissance du Makefile, notamment les dépendances entre règles. Chaque module contient un fichier Makefile qui permet

de compiler le package (règle build);
de nettoyer les fichiers temporaires de la compilation (règle clean);
de nettoyer les fichiers produit par la compilation, dans la plupart des cas les binaires (règle mrproper);

Un exemple de fichier Makefile se trouve en annexe C page ??. Pour coordonner et surtout ordonner le tout, nous avons un Makefile global qui gère la dépendance entre les modules. Ce fichier est présent à l'annexe C. Avec cet outil il suffit de récupérer l'archive du projet, de taper make à la racine du projet puis make run pour compiler puis exécuter l'application.

1.4 Problèmes rencontrés

Paradoxalement c'est un outil sensé faciliter le travail en commun qui nous a posé le plus de problèmes : CVS. En effet, son utilisation n'est pas des plus aisées, et le fait que les membres de l'équipe n'y étaient pas habitués a induit un certain temps d'apprentissage. Une fois cette étape franchie et les concepts de la gestion de version intégrés nous n'avons plus eu la possibilité d'utiliser l'outil pour toutes les raisons évoquées en 1.3.1. Nous avons également rencontré des difficultés au niveau des informations distillées au sujet du projet, notamment concernant certaines règles de compilation, ainsi par exemple pour l'instruction delarray du JaJaCode.

1.5 Soyons constructifs

Le projet de compilation d'IUP3 est autant un projet de compilation qu'un projet de gestion de projet . Dans cette optique il pourrait être intéressant de mettre à disposition des groupe un serveur de projet qui permettrait l'utilisation d'un logiciel de suivi de versions (CVS) et d'un logiciel de suivi de bug (Bugzilla). Avec la possibilité de crier une liste de diffusion voire un site Web pour le projet à la façon d'un Wiki. En fait cela ressemblerait aux plate-formes de développement de logiciels libres telles que www.sourceforge.net ou savannah.gnu.org.