Publié en mai 2011

L’analyse structurelle du projet (WBS)

Pour un projet logiciel, la totalité et le degré de complexité des tâches ne peuvent être efficacement établis avant d’avoir commencé la création du code. De ce fait, le WBS, qui est un outil essentiel pour l’accomplissement d’un projet, ne peut être réalisé au moment de la préparation du MAP. L’élaboration du WBS doit donc être répartie dans le temps. Le WBS devient évolutif, certaines de ses tâches étant clarifiées au début de chaque itération. Typiquement, on produit un WBS initial qui délimite les deux ou trois premiers niveaux de tâches à accomplir. Puis, au démarrage de chacune des itérations, on détaille un certain nombre de tâches qui sont allouées et exécutées pendant l’itération courante. Les tâches qui sont clairement définies dès le début doivent apparaître dans la version initiale du WBS. Par exemple, les tâches liées au suivi, à l’élaboration de rapports, à la mise à jour des lots de travaux, etc., seront immédiatement précisées, parce qu’elles sont déjà connues et qu’on peut donc décider du moment de leur exécution et désigner le membre de l’équipe qui en sera responsable.

Dans le domaine du logiciel, l’élaboration de cas d’utilisation et de diagrammes de séquences est une pratique qui augmente la qualité et garantit un certain niveau de structure. L’élaboration des cas d’utilisation devrait faire partie des tâches initiales, pour bien représenter les fonctionnalités attendues par le client. L’intérêt des cas d’utilisation est de permettre de discuter avec le client pour s’assurer d’une compréhension mutuelle, de faciliter le repérage des éléments essentiels du système et de déterminer les contrôles de validité pour le fonctionnement du côté usager.

Les diagrammes de séquences sont aussi très utiles lorsqu’il faut déterminer les interactions entre divers modules du logiciel, ou entre le logiciel et des éléments externes. Leur mise au point dépend des éléments techniques dont ils doivent modéliser l’interaction. Il est donc courant de ne pas les préciser (ou peu) au démarrage du projet, sachant qu’ils seront définis avant le début du travail sur les modules.

Pour les projets de logiciel, la valeur de la validation continue du code généré est maintenant reconnue. En conséquence, l’un des premiers éléments à mettre en place est la configuration du système de test, de validation et de suivi du logiciel. L’ensemble des tâches liées à cet aspect devrait toujours être effectué le plus tôt possible. Parmi ces tâches, on note la mise en place du harnais de test automatisé (par exemple, l’utilisation de JUnit sous Java), la gestion du nouveau code (l’outil CruiseControl est particulièrement utile pour l’intégration continue), le suivi de la couverture des tests (par exemple, l’utilisation du module d’extension EclEmma est courant dans l’environnement Eclipse), la mise en place d’un harnais de génération de documentation (par exemple, à l’aide de Doxygen), l’utilisation d’un outil de suivi des bogues (Bugzilla est souvent utilisé, mais certains systèmes de suivi de projet comme dotProject et Trac offrent maintenant des fonctionnalités similaires). De plus, la présence d’un site web commun pour la communication entre les membres de l’équipe de développement fait maintenant partie des outils indispensables au bon déroulement des projets logiciels. La mise en place d’un site web et d’un wiki devrait donc être planifiée dès le lancement du projet.