Projet de fin d'année Logiciel < Mise en oeuvre < > Conclusion >

Bilan

Méthodes de travail

Ce projet est un travail d'équipe pour lequel nous étions six. Pour la plupart d'entre nous, c'était la première fois que nous étions amenés à travailler dans un groupe non réduit à un binôme. Dès le départ, nous avons effectué un certain nombre de choix pour nous faciliter le travail en équipe:

• mise en place d'une liste de diffusion (mailing list) à usage interne.
• création du projet sur SourceForge [15] en particulier pour le service CVS qu'il propose.
• nomination d'un chef de projet qui fixe les objectifs, les étapes et les moyens, qui s'assure de l'harmonisation des liens inter-unités, et qui coordonne les actions.
• nomination d'un responsable communication qui s'assure que l'information circule correctement entre les différents membres de l'équipe, et qui a aussi en charge la rédaction de compte-rendus internes après chaque réunion (qu'elle soit interne, ou bien avec le client ou le responsable pédagogique).

CVS

Afin d'éviter de perdre du temps sur le transfert des modifications des sources entre nous, nous avons donc utilisé le système CVS de partage des sources. Ces dernières étaient ainsi partagées sur une base commune (hébergée sur les serveurs SourceForge auxquels nous accédions avec ssh) appelée le repository. Chaque membre de l'équipe crée ensuite une copie privée des sources (opération checkout) sur laquelle il effectue son travail puis le diffuse en mettant à jour la base commune (opération commit). Les modifications de la base commune génèrent automatiquement un courrier électronique envoyé à tous les membres du groupe qui savent ainsi ce que les autres ont modifié sur les sources; ce message comprends un rapide descriptif de l'objet de la mise à jour saisi par le développeur ainsi qu'un listing des différences induites par la modification (résultat d'un diff -u). Les autres développeurs peuvent ensuite, s'ils le souhaitent, mettre à jour leur copie privée (opération update). On notera que CVS gère très bien la modification simultanée du même fichier par plusieurs personnes (à condition qu'elles touchent des parties différentes du fichier bien sûr). En outre CVS archive toutes les versions de chaque fichier et il est ainsi possible de récupérer les versions antérieures, d'afficher un historique des modifications d'un fichier, etc.

Bilan

Nous n'avons pas regretté nos choix quant à nos méthodes de travail, bien au contraire. Il est d'ailleurs intéressant de constater que ces méthodes qui manquaient au groupe de l'année dernière nous ont permis d'éviter certaines erreurs qu'ils ont commises:

• Le fait d'avoir nommé un coordinateur nous a permis de faire des modules ayant une interface cohérente. Les modules de l'an passé étaient assez incohérents, sans doute parce que la logique de leur organisation et de leur convention (nommage, prototypage, etc.) était pensée par la première personne ayant besoin de ce module; puis cette logique n'était pas communiquée aux autres membres. Lorsque d'autres avaient besoin d'une fonction manquante dans le module par exemple, il l'ajoutait sans chercher à la rendre cohérente avec l'existant.
• L'absence d'outil de partage des sources obligeait chacun à travailler de manière isolée; la démarche pour savoir ce que les autres ont modifié dans le source était coûteuse en temps et donc rédibitoire. Avec le CVS, chacun est informé de toutes les modifications des source, et peut donc ensuite y jeter très facilement un il, tout simplement en lisant les messages électroniques envoyés par le serveur à chaque commit. Souvent des bugs mineurs ont été ainsi découverts lors de la relecture par les autres membres. Il y a un exemple flagrant d'aberration qui aurait été évitée si le groupe de l'année dernière avait utilisé un outil de partage des sources. L'application est constituée de deux exécutables distincts mais qui utilisent des fonctions communes; le source était donc à l'origine divisé en trois morceaux, la partie commune, la partie spécifique au premier exécutable et la partie spécifique au second exécutable. Dans l'urgence de la fin du projet, certains devaient ajouter des fonctions dans les modules communs mais comme ceux-ci étaient aussi en cours de modification par les autres, ils ont dupliqué les fichiers communs pour ajouter dans leur propre copie les routines manquantes. Et finalement, la fusion des modifications effectuée sur ces fichiers communs n'a pas eu lieu.

Répartition des tâches

La répartition des tâches a beaucoup évoluée au cours de la réalisation du projet. En effet, les divers problèmes que nous avons rencontrés obligeaient parfois à revoir les affectations des tâches. En particulier, la toute première répartition que nous avons effectuée s'est rapidement avérée complètement utopique: elle prévoyait un travail parallèle sur les nouvelles fonctionnalités que nous souhaitions ajouter à l'application: gestion des VLANs, création de systèmes de vues, etc. Si elle s'est avérée utopique, c'est parce que nous n'avions pas vraiment étudié le code avant de la faire, et le résultat de cette étude a mis en évidence de graves problèmes dans le projet repris. En effet, l'ensemble manquait énormément de cohérence globale. Et la logique que l'on pouvait espérer trouver dans l'organisation modulaire n'existait pas.

Ensuite, nous avons donc effectué une répartition différente prenant en compte de nouvelles tâches relatives à la réorganisation du code. Pendant quelques semaines, le travail a été d'une part la recherche des informations sur les VLANs pour préparer leur implémentation, et d'autre part la restructuration du code. Au cours de cette période, nous nous sommes familiarisés avec les sources.

Enfin, sur la dernière partie du projet, nous avons eu une répartition stable pour le développement des nouvelles fonctionnalités.

Coordination technique:

Christophe GIAUME.

Communication et documentation:

Yves GALLEN.

Prise en charge des VLANs:

Gaël TESSIER et Yves GALLEN.

Algorithme de fusion (pour les VLANs):

Samuel GUIBERTEAU et Marion PUYOU.

Algorithme de topologie:

Gaël TESSIER.

Interface graphique:

Matthieu ROZIERES.

Valeur ajoutée

En reprenant la terminologie de Brooks dans un des premiers chapitres de [17], ce que nous avons repris ressemblait à un logiciel, alors que ce que nous fournissons s'apparente plus à un système logiciel livrable. En effet, pour ce qui concerne l'aspect logiciel livrable:

• Le logiciel a été documenté; nous avons rédigé deux documentations techniques: le User manual et le Maintainer manual.
• Faute d'avoir accès à d'autres réseaux, les tests se sont limités au réseau de l'ENSEIRB. Cependant, nous avons gardé à l'esprit que l'objectif n'était pas de se contenter de faire un logiciel fonctionnant correctement sur le réseau actuel de l'école.
• Nous avons beaucoup amélioré la portabilité du logiciel. A l'origine, il ne fonctionnait correctement que sous Solaris 7/Sparc. Il tourne désormais également sous GNU/Linux et sous les *BSD.

Quant à l'aspect système logiciel, lors de notre travail de structuration du code, nous nous sommes efforcés de rendre l'ensemble le plus modulaire possible. Par exemple l'interface actuelle est en GTK, mais tout ce qui est relatif à l'interface sans être dépendant de GTK comme le calcul des coordonnées des machines fait l'objet d'un module à part. Ainsi, tout est prêt pour la création d'une interface avec un autre toolkit, QT par exemple.

Avancement

Au niveau de l'interface utilisateur,, un affichage sur plusieurs niveaux de profondeur a été réalisée avec la possibilité d'afficher tel quel l'arbre de topologie liée à un VLAN ou de le fusionner avec d'autres. Plusieurs méthodes de dessin ont été mise à disponibilité. Cependant, l'implémentation de l'affichage de la charge sur les liens du réseau ainsi que la coloration de ceux-ci n'ont pas pu être réalisés faute de temps.

Perspectives

On peut raisonnablement espérer que ce logiciel sera repris par la suite, étant donné qu'il propose des fonctionnalités peu répandues, et qu'il a été mis sur SourceForge [15].

La modularité introduite permet l'ajout de fonctions au niveau de l'interface et de la récupération. Néanmoins, la qualité de programmation de l'interface n'a pas été privilégiée, et un certain travail reste à faire. L'utilisation de Glade dans le projet repris a produit un code lourd et peu agréable à réutiliser. Nous ne nous sommes pas attardé sur ce point, car nous préfèrerions travailler sur la modularité des API de récupération de données.

De plus, l'utilisation de containers GTK pour l'affichage de la topologie est peu adaptée, et il serait préférable d'utiliser des zones de dessins (bien plus rapide lors de l'affichage).

Le programme repris s'appuyait complètement sur la base de donnée, ce qui est assez lourd en terme de communication. Après avoir étudié le volume d'informations de la base, nous avons remarqué qu'il serait plus judicieux de manipuler en mémoire les données recueillies, la base ne servant que d'appui pour le stockage, voire la remplacer par un systeme de sauvegarde dans un format de fichier.

Pour finir, notre programme se limite à l'étude d'un réseau découpé en VLAN dans lequel reseau IP et VLAN sont confondus. Cette distinction supplémentaire permettrait de lever de nombreuses ambiguités concernant le traitement des routeurs IP dans notre algorithme de topologie. Il est a noté que le logiciel Nomad [19] propose cette fonctionnalité.

Remerciement

Nous tenons à remercier M GOUDAL et M PELLEGRINI pour l'aide et les conseils qu'ils nous ont apportés tout au long du projet.

Projet de fin d'année Logiciel < Mise en oeuvre < > Conclusion >