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:
- forums de discussions
- tâches
- anomalies (bugs)
- besoins <--> conception <--> implémentation
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:
- libellé
- auteur
- date
- références: ici, une méthode (appartenant
à une classe, elle-même
apartenant à un paquetage), et un besoin (Cas d'Utilisation
probablement)
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 ...