Outils de collaboration pour un projet de développement
© 2003 Jean-Marc Vanel

e-mail: Envoyer vos commentaires
Ma page d'accueil


[question posée dans new:fr.comp.developpement ]
Je participe à un projet de développement en simulation, avec du C++, du Java, du Perl, du XML+XPath+XSLT, etc ...
Nous sommes 8 personnes + 2 ou 3 "commerciaux".
Il n'y a pas d'infrastructure de communication/documentation.
Il y a Clear Case pour le versionnement des sources, un peu lourd ...

Le besoin que je ressens:
- forums de discussions, avec des liens si possible bidirectionnels avec les délivrables, sources, specs, conception (UML), retro-documentation (Javadoc, Doxygen)
- gestion des tâches ( liens idem + liaison avec versionnement: telle mise à jour CVS correspond à l'accomplissement d'une tache)
- gestion des anomalies (encore liens + liaison CVS)
- moteur de recherche avec mots-clés sur tout le contenu, y compris base CVS: les modifs de telle période sur tel répertoire avec tels mots dans le libellé ou dans la modif
- peut-être visualisation de l'arborescence des documents et de leurs liens
- pouvoir assurer la traçabilité entre besoins <--> conception <--> implémentation, et les discussions alentour, peut-être avec un identifiant unique du cas d'utilisation figurant dans conception et implémentation

Il y a :
- TikiWiki (http://sourceforge.net/projects/tikiwiki/), qui n'est pas dédié développement
- plusieurs choses en cherchant sf.net avec TOUS les mots:
    "software development management"
- http://maven.apache.org/ : ça a l'air d'un truc assez lourd qui s'occupe trop
    de build et pas assez de communication
- sourceforge, en version à déployer (rappel: notre projet n'est pas open source :-( )
    * assez bon pour les forums et les tâches, mais pas beaucoup de liens, et quelle est la facilité de déploiement?
- CVSWeb: uniquement vue de l'arborescence des répertoires (pas par dates ou par auteur), OK pour les diffs, mais pas de requêtes

Des idées et retours d'expériences?



Voici les développements de ces idées : collabCode

En fait, comme toujours, il y  a des outils qui font certaines choses pour leur compte, mais rien d'intégré. Et chacun de ces outils est monolithique et pas modulaire. Les différents aspects doivent être gérés ensemble, au moins pour les hyperliens et les requêtes:
Une façon révolutionnaire de faire serait de construire ce super-outil de collaboration (appelons-le collabCode ) autour d'une base de données unique (XML probablement, mais peut-être orientée objet). Mais on  voit tout de suite le problème avec le source, et la conception UML.
Pour le source, il faudrait avoir un bon AST (Abstract Syntax Tree). Un bon AST, récent et open source est celui d'Eclipse (org/eclipse/jdt/core/dom). Il y a aussi Alma, un effort français et presque mono-développeur mais qui est multi-languages  dès le départ. Bien sûr, des outils aussi divers que Source Navigator (de RedHat), ArgoUML (un éditeur UML), Doxygen, PMD ( analyseur de source Java), JavaML, etc, ont des capacités de représentation de code Java. Cependant il faut penser aux fonctionalités souhaitées et à la performance ... On n'a probablement pas besoin d'avoir accès dans tous les modules de collabCode à toute la profondeur de l'arbre syntaxique. Dans le forum de discussion, par exemple, on fera référence à une ligne de code dans une version CVS d'une classe, et cela suffit pour être non-ambigu. On voit donc se profiler la possibilité d'intégrer des outils tels que CVS, Eclipse, et pourquoi pas des forums de discussion déjà existants. Il n'est pas sûr qu'on ait besoin de cette super-base de données unique. Le versionnement est très important, et il ne faut pas réinventer la roue. Cependant il serait souhaitable de pouvoir faire des requêtes telles que: trouver toutes les mises à jour sur telle période ayant auteur, mots spécifiés dans le libellé, répertoire(s), etc, spécifiés.
Pour UML, il faudrait bien comprendre quels sont les apports de UML 2.0 (cf article dans Dr Dobb's Journal d'août 2003). Il faut que j'essaye EMF (Eclipse Modelling Framework).
Pour intégrer des logiciels prévus pour être monolithiques, je me dis que la Programmation Orientée Aspect pourrait être un moyen.

En fait, pour avancer, il faut bien sûr préciser quelques Cas d'Utilisation. Partons du Forum de discussion. Moi, dévelopeur, je veux mettre mon grain de sel à propos d'une méthode, qui pourrait être restructurée pour mieux satisfaire tel besoin. Je veux donc publier une note pour démarrer un arbre (fil) de discussion sur ce sujet. Naturellement, on pourra retrouver cette note et ce fil de discussion par:
Déjà on voit qu'il faut donner une possibilité simple pour faire référence à une méthode et un besoin quand on crée la note. Par exemple un glisser-déposer (DnD) depuis Eclipse pour un élément de langage tel qu'une méthode, un DnD depuis ArgoUML ou autre pour un cas d'utilisation.
Mais si on suit le fil des évènements, il va se passer que quelqu'un (moi peut-être) va se proposer pour le faire. D'où création d'une tâche dans le contexte cette discussion.

Toujours suivant les évènements, après restructuration, la méthode de départ a été renommée, déplacée, éclatée, etc. Il faudrait avoir, après restructuration, une traçabilité de cette discussion à partir de la nouvelle structure de code + conception . En fait tout peut changer, besoins <--> conception <--> implémentation, et il faut pouvoir maintenir des références sémantiques dans ce monde mouvant ...

Un point obligatoire de nos jours, c'est de pouvoir exporter en XML (et dans un XML de bonne qualité) tout ou partie des données (discussions, tâches, etc). Un import serait souhaitable, il y a de nombreux outils de gestion de tâche, par exemple MrProject qui sauve en XML.

A SUIVRE ...