Système de suivi d'un développement logiciel

En milieu professionnel, le développement logiciel s'apparente à une construction d'une maison. On fait des plans à l'avance, et on s'organise pour que tout le monde travaille dans le bon sens. L'important est de pouvoir savoir que le projet avance, de suivre son avancement.

Rien de mieux pour cela que d'organiser un projet autour d'un système de gestion d'exigences, reflet exact du besoin du client. L'important dans un projet informatique est de s'assurer que toutes les exigences sont "couvertes", et que seules les exigences demandées sont implémentées. La liste des exigences n'est que le reflet exhaustif du contrat passé avec le client.

La gestion des exigences est parfois obligatoire notamment lors de marchés publics. Mais, même (et surtout) quand un contrat est ambigüe, n'est pas clair sur chacun des besoin du client, il est important de détailler le contrat en exigences.

Un des meilleurs bouquins que j'ai pu lire sur le sujet est Exploring Requirements: Quality Before Design de Donald C. Gause et Gerald M. Weinberg. Ce qui est intéressant dans ce livre c'est qu'il montre comment faire ressortir toutes les exigences d'un produit et comment les différencier en fonctions, attributs, contraintes, préférences et attentes.

Ainsi, quand on a plusieurs intervenant à faire travailler sur un projet, l'important est de s'assurer que le travail de chacun est lié directement à l'implémentation d'une exigence. La mise en place d'outils de gestion de projet devient inévitable dès qu'on a plus de 2 développeurs simultanés.

Le système d'information de base à mettre en place pour une gestion de projet s'articule autour des types d'outil suivant :

- un gestionnaire d'exigences
- un gestionnaire de tests, de scenarii de test et de plan de tests
- un outil de suivi des anomalies
- un outil pour relier au code les exigences et les anomalies.
- l'intégration de tous ces outils

L'idéal est bien d'intégrer tous ces outils pour avoir une maîtrise de ce qui est développé. Le processus de développement peut alors se décrire comme suit :

- une exigence est rédigée dans le système de gestion des exigences.

- des tests et des scenarii de tests sont rédigés pour cette exigence, permettant de s'assurer qu'elle a été correctement implémentée.

- des plans de test sont construits pour organiser les phases de vérification et de validation.

- quand un développeur veut commiter du code, il indique dans le message de commit la
référence de l'exigence concernée par ce commit.

- quand un test montre qu'il y a un problème, l'anomalie est tracée dans le système de suivi des anomalies.

- quand un développeur corrige l'anomalie dans le code, il indique dans le message de commit la référence de l'anomalie.

L'important dans tout ça est de contraindre le processus pour qu'il soit suivi :

- tout commit doit avoir soit une référence d'exigence, soit une référence d'anomalie
- toute anomalie doit avoir une référence à l'exigence sur laquelle le défaut a été constaté
- tout test doit avoir une référence à l'exigence testée

On peut mettre en place un tel système de suivi du développement logiciel avec de simples outils Open Source :

- Mantis pour le suivi des anomalies,

- Testlink pour le suivi des exigences, des tests, des scenarii de test, des plan de test. Il a l'avantage de s'interconnecter facilement avec Mantis. On peut faire correspondre des bug Mantis avec des tests Testlink.

- scmbug pour relier les commits au référentiels que sont les exigences et les anomalies.

Intégrer Mantis et Testlink est un jeu d'enfant, la mise en place de scmbug elle, est plus difficile (et le sera tant qu'il n'y aura pas d'interface au niveau de Mantis sur laquelle scmbug puisse connecter ses évènements).

Travailler avec un tel système nécessite d'adhérer à cette vision d'implémentation d'exigences. Il est important que chaque développeur comprenne que ce n'est pas contraindre la créativité que de baser le développement sur les exigences.

De toute manière, si vous avez correctement implémenté ce système, le développeur est obligé de préciser sur quelle exigence, ou quelle anomalie il commit son code, le tout est de s'assurer que le code correspond effectivement à ce qu'il prétend. Cela est normalement fait au niveau de l'assurance qualité.