Cycle de base des projets

On parle de cycle parce que la réalisation du travail est effectuée par des itérations sur une série des tâches élémentaires, qui forment le cycle de base. Ce cycle de développement d’applications informatiques doit permettre de :

– bien comprendre les demandes des utilisateurs finaux, – tenir compte des changements du cahier des charges,

– empêcher la découverte tardive de défauts sérieux dans le projet, – traiter au plus tôt tous les points critiques du projet,

– bien communiquer avec le client, – bien maîtriser la complexité, – favoriser la réutilisation,

– définir une architecture robuste et évolutive ou capable de s’adapter, – faciliter le travail en équipe.

Nous pouvons distinguer deux catégories de cycles : les cycles dits « classiques » et les cycles liés à l’émergence de nouvelles méthodes et à la banalisation de la programmation orientée objet.

Les principaux cycles, dits « classiques », sont : – cycle de vie en V (Barry W. Boehm, 1981), – cycle de vie en spirale (Barry W. Boehm, 1986),

Parmi les cycles récents, nous examinerons plus précisément le cycle USDP (Unified Software Development Process).

76 CHAPITRE 6. INGÉNIERIE DES SYSTÈMES D’INFORMATION

6.2.1.1 Cycle en V

Le principe de ce modèle de décomposition en tâches (fig. 6.2) est qu’avec toute décomposition doit être décrite la recomposition, et que toute description d’une partie de code est accom- pagnée de tests qui permettront de s’assurer qu’il correspond à sa description. Des liens forts sont établis pour préparer les dernières phases (validation-vérification) à partir des premières (construction du logiciel), et permettre ainsi d’éviter un écueil bien connu de la spécification du logiciel : caractériser une exigence du client qu’il est impossible de vérifier objectivement après la réalisation (ce qui sous-entend qu’on ne peut assurer la justesse).

On distingue donc deux sortes de dépendances :

– l’enchaînement des activités : se déroule essentiellement de gauche à droite (de la défi- nition du cahier des charges, jusqu’au codage, finissant par la recette de l’application) sachant que chacune des activités est validée et doit respecter son vis-à-vis (cahier des charges et recette, spécifications générales et tests d’intégration, ...) ;

– la préparation des phases ultérieures. Pour passer à l’activité suivante, l’activité en cours doit être complètement terminée.

Fig. 6.2 – Cycle en V

Le cycle en V permet de mettre en correspondance les activités du début de cycle (phase descendante jusqu’au code) et les activités de fin de cycle (phase ascendante jusqu’à la recette). Le principal inconvénient de ce cycle est l’impossibilité de prendre en compte les évolutions possibles du cahier des charges lorsque cette activité est terminée, il n’est pas possible de modifier ces spécifications en cours de réalisation des programmes. Enfin, un autre défaut de ce cycle est la difficulté de proposer, de faire tester ou de montrer à l’utilisateur (le client) des maquettes ou des prototypes lors des premières activités du cycle.

6.2.1.2 Cycle en spirale

Proposé par Boehm en 1986, ce modèle (fig. 6.3) est beaucoup plus général que le précédent. Il tire profit d’une démarche d’analyse des risques dont la prise en compte induit un caractère itératif dans le déroulement des tâches. Chaque cycle de la spirale se déroule en quatre phases : 1. détermination, à partir des résultats des cycles précédents ou de l’analyse préliminaire des besoins, des objectifs du cycle, des alternatives pour les atteindre et des contraintes ; 2. analyse des risques, évaluation des alternatives et, éventuellement maquettage ;

3. développement et vérification de la solution retenue, un modèle « classique » (cascade ou en V) peut être utilisé ici ;

4. revue des résultats et vérification du cycle suivant.

Fig. 6.3 – Cycle de vie en spirale

Le cycle en spirale est basé sur la mise à disposition de la MOA d’un prototype évolutif, exécutable et donc évaluable. À chaque évolution du prototype, il est possible d’identifier les problèmes, et de prendre en compte les corrections nécessaires lors de la prochaine itération. Les risques sont alors identifiés, évalués et gérés beaucoup plus tôt dans le projet. Cette démarche que l’on peut assimiler à des essais/erreurs, apporte une contribution progressive à la qualité de l’expression des besoins en l’étalant sur une période plus longue du projet. Mais cette évaluation permanente autour des prototypes impose une communication forte entre l’ensemble des acteurs du projet (client, utilisateur, développeur...), afin de vérifier et de valider le prototype à chaque itération. Il faut un effet mémoire, ou capital de connaissances, sur le produit de la part des équipiers, qui ait une certaine pérennité, pour assurer une progression efficace.

6.2.1.3 Cycle émergeant

Au cours des années 90, de nouvelles méthodes de conduite de projet ont vu le jour, sous l’impulsion des technologies orientées objet qui connaissaient un succès notable. La méthode USDP est une des premières méthodes de développement qui utilise explicitement le modèle comme trait d’union (les diagrammes d’UML).

L’approche d’une solution obéit aux principes du cycle en spirale. Des tâches d’un cycle de base sont répétées pour acquérir une connaissance progressive dans l’espace de formulation du problème, et dans celui de la proposition de solutions. Les différents états d’avancement du projet sont modélisés par quatre temps (phases en anglais) : de la modélisation du contexte et de la capture des besoins jusqu’à la mise en place d’une version chez le client. A chaque temps (les colonnes « phases » de la figure 6.4), la charge de travail du cycle de base se distribue différemment entre les tâches.

Nous retrouvons l’enchaînement des différentes phases de USDP dans la figure fig. 6.4. L’objectif de cette nouvelle méthode est d’améliorer les points suivants :

1. un développement itératif du logiciel : il est important de montrer à la MOA l’état d’avancement du projet, des délivrables. Ceci doit permettre de mieux maîtriser les risques inhérents au développement en les levant au plus tôt ;

78 CHAPITRE 6. INGÉNIERIE DES SYSTÈMES D’INFORMATION

Fig. 6.4 – Démarche projet : méthode USDP

2. gérer les exigences : toutes les fonctionnalités du résultat souhaité doivent faire partie d’une ou plusieurs exigences ;

3. une architecture logicielle adaptée : il faut privilégier une construction du logiciel par assemblage de composants ;

4. adopter une modélisation graphique : il est nécessaire d’utiliser les diagrammes UML afin de mieux communiquer et de manière plus rigoureuse entre développeurs et utilisateurs ; 5. vérifier la qualité en continue : le respect des exigences doit être effectué tout au long

du projet de développement ; 6. gérer les demandes de changement.

Cette méthode orchestre donc différents éléments :

– les disciplines : analyse & design, développement, tests, gestion de projet, etc.,

– les phases et les délivrables de chaque phase : inception, élaboration, construction et transition,

– les acteurs du projet : analystes, développeurs, testeurs, managers, etc.,

– les artefacts : les différents modèles de document comme support de chaque discipline (modèle de document pour identifier et détailler les exigences du futur par exemple). Le déroulement de chaque phase (inception, élaboration, construction et transition) se solde par un délivrable :

– la phase d’inception établit la faisabilité du projet : à partir de la liste des exigences, nous évoquons les possibilités de réussite ou d’échecs de chacune. Il s’agit de répondre aux questions suivantes :

– que va faire le système, définition du périmètre fonctionnel ? – quelle sera l’architecture générale du système ?

– quels seront les principaux rôles au sein du projet ?

– quels vont être les délais, coûts, moyens, ressources à déployer ?

– réaliser les premières analyses du système,

– planifier les principales tâches de la construction du système, – éliminer les risques liés à cette phase.

– la phase de construction bâtît le système : il est temps de finaliser le développement et de vérifier la conformité du code aux exigences ;

– la phase de transition aborde l’environnement utilisateur : il s’agit de préparer les phases de déploiements, de mise en service du système chez le client.

Les deux dimensions de la méthode USDP permettent de suivre un processus intégré étayé par les modèles, les artefacts et les acteurs, afin d’obtenir le produit souhaité.