L’approche classique du projet

Le modèle en cascade est une référence

Le modèle en cascade est le standard incontournable de la gestion de projet. Bien que souvent opposé aux méthodes agiles ou critiqué par leurs promoteurs, il continue à s’appliquer avec un taux de réussite certain.

Ce modèle qui repose sur une succession de phases est d’une logique simplissime. Chaque phase débute à l’achèvement de la précédente de façon à développer et enrichir un livrable en élaboration progressive. Ainsi, les spécifications sont la traduction de l’expression de besoins, le code source devient la matérialisation des spécifications, les tests sont réalisés sur un programme assemblé (on pourrait dire compilé), le logiciel est déployé et installé une fois le programme qualifié à l’issue des tests, etc.

Ce modèle de développement est au moins aussi ancien que la programmation informatique elle-même. Et ce constat amène deux remarques objectives.

Tout d’abord, un modèle de développement n’est pas une méthode de gestion de projet. Un enchaînement de phases, d’activités et de tâches, aussi logique soit-il, ne vaut pas suivi du planning, gestion des aléas ou prise de décision.

Deuxièmement, l’ancienneté de ce modèle et la persistance de son usage témoignent certes de son adéquation à une certaine typologie de projet, mais aussi par différence de ses limites.

Ces deux remarques aident à positionner respectivement le modèle en cascade et les méthodes agiles. Ces dernières ne s’inscrivent pas en opposition complète, puisqu’elles intègrent en partie l’enchaînement des phases du modèle en cascade.

Il est donc utile de bien maîtriser la conduite d’un projet selon une approche classique, d’abord pour l’appliquer à la typologie de projet idoine...

Les phases du projet

1. L’expression de besoins et le cahier des charges

Ces deux termes sont analogues, bien qu’en pratique une expression de besoins soit le point de départ à l’élaboration d’un cahier des charges plus complet.

Comme nous l’avons déjà évoqué, le cahier des charges est plus souvent décrié qu’encensé. Et pourtant, il s’agit d’un document indispensable à la réalisation d’un projet. Le principal problème lié à sa rédaction tient dans l’interprétation réputée équivoque que l’on pourrait lui prêter, suivant que l’on est du côté de la maîtrise d’ouvrage ou de la maîtrise d’œuvre. En effet, les clients rencontrent parfois de réelles difficultés à exprimer clairement leurs besoins (on entend même parfois que la meilleure expression correspond au logiciel réalisé). Il arrive aussi que, rompus à l’exercice, les clients restent délibérément flous dans leurs réponses, cherchant ainsi à maximiser leurs marges de manœuvre et à différer leurs choix.

La société en charge de la réalisation poursuit précisément l’objectif opposé : plus vite elle identifie le périmètre de la solution, meilleur sera le rendement du projet, par le truchement de la capitalisation du savoir-faire.

La situation paraît donc inextricable, et pourtant elle s’impose rapidement car le cahier des charges reste la principale annexe technique d’un contrat de développements informatiques.

Il apparaît clairement que les incompréhensions proviennent du caractère « figé » prêté au cahier des charges. Il serait une fin en soi. Or il n’en est rien et la solution tient dans une autre lecture de la remarque faite ci-dessus. Si la meilleure expression d’un besoin client est supportée par un logiciel, elle n’est qu’une dérivation d’un ensemble de spécifications qui découlent toutes du cahier des charges.

Autrement dit, le cahier des charges n’est nullement un document figé mais plutôt...

Le développement du projet de pilotage d’activité

Jérôme est tout à fait à son aise dans l’organisation du développement du logiciel de pilotage d’activité. Il organise une réunion pour toute l’équipe projet au cours de laquelle il rappelle les modalités de codage, de tests et de déploiement. Le planning étant serré, les développeurs devront se conformer strictement à ces recommandations.

1. Organisation du développement

a. La gestion du code source et des éléments de travail

Le code source est partagé au moyen du logiciel Azure DevOps, suivant la méthodologie Agile-Scrum. Chaque itération porte sur l’ensemble des demandes (requirements) et anomalies (bugs) à réaliser au cours de la période (sprint ou itération).

Les développeurs récupèrent la dernière version d’un module de code source avant de procéder à des modifications. En fin de journée, ils archivent dans la mesure du possible leurs modifications et vérifient avant et après que les projets compilent toujours sans erreur.

À chaque opération d’archivage, il faut associer l’identifiant de l’élément de travail puis mettre à jour le statut : actif, en cours, terminé, corrigé… Les testeurs sont chargés de contrôler ces statuts et peuvent fermer les points ou bien les rouvrir. Les points réalisés sont enfin basculés sur une sous-itération en cours, afin que les testeurs puissent déterminer le périmètre d’une version.

L’exécution des tests unitaires est une condition préalable à la validation d’un élément de travail (terminé ou corrigé). Les modalités particulières de tests sont par ailleurs intégrées aux éléments de travail par les développeurs.

b. La documentation

Le code est commenté suivant les normes établies pour le langage de programmation. Jérôme insiste sur la qualité des commentaires et leur pertinence vis-à-vis du code qu’ils décrivent.

Des outils d’extraction automatique sont appliqués...