MAP DANS UN CONTEXTE DE TECHNOLOGIE DE L'INFORMATION (TI)

Particularités des projets de TI

Dans le domaine des technologies de l’information, il est difficile de planifier un projet dans sa totalité dès le départ, en particulier lorsque l’objectif consiste à créer un ensemble de fonctionnalités logicielles. La nature du travail à effectuer fait en sorte que l’ampleur et la complexité des réalisations n’apparaissent souvent qu’au moment de l’exécution du projet. Par exemple, certains éléments logiciels sont très complexes à faire fonctionner, alors qu’au départ ils ressemblaient à d’autres, déjà produits sans problème. À la difficulté de réalisation des projets logiciels s’ajoutent deux autres éléments. D’une part, le client devra souvent réexaminer ses exigences en cours de route, parce que les objectifs initiaux sont rarement statiques et seront modifiés par de nouveaux apports de l’équipe de développement au client. D’autre part, la moindre erreur de codage ou de design peut altérer le fonctionnement de l’ensemble du système en développement. De plus, les erreurs de codage (bogues) peuvent être particulièrement difficiles à détecter et se traduisent souvent par des retards. La présence de ces difficultés propres aux projets logiciels a longtemps nui à leur réalisation, mais l’apparition de nouveaux langages de programmation a facilité la conception et la mise au point des logiciels.

Pour les projets de développement de logiciels, on utilise trois types d’approche :

• l’approche de gestion traditionnelle : le processus est bien défini, avec une structure et une procédure strictes
• l’approche unifiée : préconise la production d’éléments déterminés dans un ordre précis
• l’approche agile : l’accent est mis sur l’efficacité de l’équipe de développement et la mise en place d’un système flexible

La tendance est aujourd’hui à l’utilisation réfléchie d’éléments provenant de ces trois approches en fonction  des besoins du projet.

Éléments à prendre en considération

La préparation du manuel d'approbation de projet (MAP) dans le contexte de projets de TI reprend nombre d’éléments communs à tous les types de projets. Cependant, certains aspects à traiter sont nouveaux ou présentent des différences avec la gestion de projet traditionnelle : eux seuls seront expliqués en détail. Pour élaborer son MAP, l’ingénieur gestionnaire d’un projet de TI devra de ce fait ajouter des données à ses analyses génériques ou les affiner.

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.

Analyse organisationnelle du projet

Dans l’analyse organisationnelle d’un projet en TI, le choix d’une description fonctionnelle, matricielle ou par projet de la structure dépendra du type de projet et de l’environnement dans lequel il sera exécuté. Dans les trois cas, la planification des ressources et le suivi du travail effectué doivent être adaptés au déroulement de projets logiciels. En effet, il est peu recommandable d’imposer un échéancier rigide avec des livrables fixes et prédéterminés pour le logiciel. Si le projet ne comprend que des éléments logiciels, cela signifie que la gestion du projet dans son ensemble sera uniforme.

Cependant, dans le cas de projets de grande envergure où la partie logicielle ne représente qu’un élément de l’ensemble, il est de la première importance pour l’ingénieur de s’assurer que les éléments devant interagir soient prêts au moment voulu. On doit alors bien cibler les jalons essentiels, bien planifier la durée et le nombre d’itérations, et s’assurer de l’état d’avancement des éléments logiciels pour que tout soit prêt au bon moment. Le gestionnaire doit porter une attention particulière aux retards éventuels et, au besoin, agir sans tarder (réduction des fonctionnalités ou augmentation des ressources humaines) pour que la réalisation du logiciel soit synchronisée avec la réalisation des autres éléments.

Analyse opérationnelle du projet

Dans un projet traditionnel, la création du WBS permet de préparer l’exécution de l’ensemble des tâches à effectuer. Dans le cas de projets logiciels, c’est impossible, parce que seuls des éléments partiels sont prédéterminés. Il est donc primordial de bien planifier le cadre temporel dans lequel évoluera l’équipe. Il faut alors procéder par itérations, en définissant leur nombre et leur durée dès le commencement. Les itérations constituent le cadre rigide du projet, chacune devant démarrer et se terminer dans les temps initialement prescrits. Une itération ne devrait jamais être trop longue ni trop courte. Dans le premier cas, la détermination dynamique des tâches est trop espacée, alors que dans le second, peu de travail est accompli, la majorité du temps étant consacré à multiplier les itérations.

La durée habituelle des itérations dans les projets de logiciel est de deux ou trois semaines. Elles durent parfois plus longtemps, si l’équipe est gérée de façon matricielle et que ses membres ont des responsabilités dans plusieurs projets exécutés en parallèle.

Chaque itération doit contenir un certain nombre de tâches prédéterminées en plus des tâches décidées en cours d’exécution. Par exemple, chaque itération doit s’amorcer par une évaluation du travail accompli, un repérage des nouvelles tâches à entreprendre et une évaluation de leur durée. Chaque membre de l’équipe se voit attribuer une ou plusieurs tâches pour la durée de l’itération. À la fin de chaque itération, une version exécutable du système logiciel doit être obtenue, pour permettre de valider le chemin parcouru. Lorsqu’un grand nombre de tâches est recensé au début d’une itération, elles doivent être hiérarchisées.

Il est préférable de rencontrer le client au début de chaque itération pour lui expliquer l’état du projet et obtenir son avis sur la hiérarchisation des prochaines tâches. Cette façon de procéder est intégrée dans la méthode Scrum.

L’une des tâches essentielles de chaque itération est la mise à jour des risques, d’autant qu’ils sont rarement statiques dans les projets logiciels. Puisqu’il existe toujours des questions ouvertes jusqu’à ce que le logiciel soit fonctionnel, les risques fluctuent selon les éléments réalisés au cours de chaque itération. Avant d’établir la priorité des tâches à accomplir lors d’une itération, les risques techniques associés aux éléments logiciels devraient toujours être réévalués, le choix des tâches étant ensuite décidé pour tenter de réduire les risques les plus graves.

Après que la ventilation des itérations dans le temps ait été faite, il est primordial de statuer sur les principaux jalons du projet. Ces derniers représentent des livrables précis, habituellement liés à une décision de poursuite ou d’arrêt (go/no-go decision) du projet. Des périodes de validation, pour évaluer les jalons essentiels du projet, doivent être instaurées. Ces jalons sont habituellement établis à rebours, en déterminant à partir des derniers livrables les éléments essentiels à leur atteinte. Un plan de contingence devrait être mis en place dès le début du projet pour chaque jalon fondamental. Ainsi, s’il n’est pas atteint, un jalon devrait nécessairement déclencher un profond remaniement du déroulement du reste du projet.

Ressources

LIENS ET RÉFÉRENCES 

• BUGZILLA
• CRUISE CONTROL
• DOXYGEN
• ECLEMMA
• ECLIPSE
• JACOBSON, Ivar, The Essential Unified Process, 2008
• JUNIT
• SCRUM
• TRAC
• BECK, K., Extreme Programming explained – Embrace change, Addison-Wesley, 1999
• BECK, K., Test-Driven Development, Addison-Wesley, 2003
• BOOCH, G., Object-Oriented Analysis and Design with Applications, Redwood City, Benjamin Cummings, 1993
• BROOKS, F.P., The Mythical Man-Month, Addison-Wesley, 1975
• JACOBSON, I., CHRISTENSON, M., JONSSON, P., et OVERGAARD, G., Object-Oriented Software Engineering : A Use Case Driven Approach, Addison-Wesley, 1992
• KRUCHTEN, P., Introduction au Rational Unified Process, Paris, Eyrolles, 2000
• MAGUIRE, S., Debugging the Development Process, Redmond, Microsoft Press, 1994
• MCCARTHY, J., Dynamics of Software Development, Redmond, Microsoft Press, 1995
• MCCONNELL, S., Code Complete, Redmond, Microsoft Press, 1993
• RUMBAUGH, J., BLAHA, M., PREMERLANI, W., EDDY, F., et LORENSEN, W., Object-Oriented Modeling and Design, Englewood Cliffs, Prentice Hall, 1991
• RUMBAUGH, J., JACOBSON, I., et BOOCH, G., The Unified Modeling Language Reference Manual (2e éd.), Addison-Wesley, 2004
• SUBRAMANIAM, V., et HUNT, A., Practices of an Agile Developer, Raleigh, The Pragmatic Programmers, 2006
• WYSOCKI, R.K., Effective Project Management (5e éd.), Indianapolis, Éditions Wiley, 2009