Les cycles de développement

Your Content Goes Here

20/05/2019

7min

Les différents cycles de développement

 

Introduction

 

Lors de la réalisation d’un logiciel, les équipes techniques et managériale doivent avant toute chose définir quelle typologie de cycle de développement elles doivent adopter. Un cycle définit toutes les étapes qui vont être mises en place lors de la conception d’un logiciel. Il existe aujourd’hui 5 familles de cycles : 

 

    1. Les modèles en cascade 

    1. Les cycles en V 

    1. Les cycles en spirales 

    1. Les cycles en semi-itératif 

    1. Cycle itératif 

 

Le modèle en cascade

 

La démarche des modèles en cascade est simpliste. Imaginez le courant d’une rivière dévalant les Alpes. Mis à part les saumons, rien ne peut remonter une rivière, surtout pas son courant. Maintenant, imaginez que le courant entraîne des rochers, chacun de ces rochers étant une étape du développement. Une fois que le premier rocher est emporté, il lui devient impossible de remonter le courant.  Il est donc impossible (ou presque) de revenir en arrière une fois une étape terminée.  

 

Le modèle en cascade est connu comme étant l’approche la plus basique du développement. Aujourd’hui, elle s’oppose à toutes les méthodologies dites « Agiles ». Les phases du développement selon un cycle en cascade se décomposent ainsi :  

 

    1. Analyse

    1. Conception

    1. Élaboration/Développement  

    1. Implémentation des fonctionnalités  

    1. Évaluation / Maintenance 

 

Contrairement aux méthodes Agiles, le modèle en cascade est immuable et n’autorise aucun chevauchement des étapes ni modification structurelle des différentes phases. Cet inconvénient est un véritable frein à la créativité des développeurs en ce sens où une fois la phase test atteinte, il est quasiment impossible de revenir sur ses pas et de modifier les éléments mal implémentés lors des phases précédentes. 

 

Les avantages d’un cycle en cascade prennent parfois le pas sur les inconvénients, notamment lorsque des projets sont soumis à des deadlines particulièrement proches. Ce processus permet en effet l’assurance de terminer le projet à une date précise en respectant des patrons (livrables) prédéfinis. Seules les revues de projets peuvent faire varier ses phases. 

 

Modèle en cascade

 

Les cycles en V

 

De moins en moins utilisés par les chargés de projet au détriment des méthodes agiles, les cycles en V font preuve d’un manque d’adaptabilité. Conçu à l’origine (années 80) afin de pallier les soucis de réactivité du modèle en cascade, les risques qu’entraînent l’adoption d’un modèle de cycle en V (souplesse limitée, communication oubliée, feedback inexistant) l’entraîne peu à peu vers une chute inéluctable au profit des méthodes Agiles. 

 

Les cycles en V peuvent cependant correspondre à des profils particuliers d’entreprises telles que celles qui externalise leur phase de développement projet, les (tout) petits projets considérant moins d’une année de cycle complet ou les projets à très faibles risques – CAD ne comprenant pas trop de caractéristiques techniques. 

 

Généralement, trois acteurs apparaissent lors d’un projet Cycle en V : le chef de projet, un MOA (maitrise d’ouvrage) et un MOE (maitrise d’œuvre). Cependant, il serait plus juste d’en déterminer 5 : Chef de projet, MOA, MOE, Architecte, et équipe de développement. Ces trois contributeurs vont ensuite suivre un schéma structurel découpé en 9 phases distinctes : 

 

    1. Analyse des besoins  

    1. Spécifications  

    1. Conception architecturale 

    1. Conception détaillée 

    1.  Réalisation 

    1. Tests unitaires

    1. Tests d’intégration  

    1. Test de validation  

    1. Recette fonctionnelle

 

S’il est important de préciser que les cycles en V permettent une meilleure visibilité budgétaire et temporelle par le traitement global des paramètres du projet, ils possèdent aussi de trop nombreux désavantages pour être utilisés sur de nombreux projets. 

 

 

Le modèle en spirale

 

Barry Boehm définissait le modèle en spirale dans son article détaillé « A Spiral Model of Software Development and Enhancement », en français : « Un modèle en spirale de développement et d’amélioration de logiciels ». Le modèle en spirale reprendre presque trait pour trait les différentes étapes du cycle en V (voir modèle précédent) bien que leur créateur a toujours cherché à les distancier.

 

Par ailleurs, certaines caractéristiques sont bien distinctes notamment dans le fait que les cycles en spirales intime l’implémentation des multiples versions successives afin de limiter les risques. Ainsi, la première phase de toutes les itérations est spécifique à la gestion des problèmes.  

 

Prototype ? Vous connaissez ce terme ? Il est utilisé dans divers contextes et secteurs particuliers mais se rapproche surtout de celui de l’automobile ou de la robotique dans lequel les prototypes sont des versions béta du projet final et en aucun cas des versions abouties successives*. En somme, il n’existe pas plusieurs versions du produit fini mais des rectifications de ces versions afin d’arriver à un seul produit de qualité finale.  

 

*(Prototype = versions incomplètes d’un produit, soit Béta  –> version finale et non V1 –> V2). 

 

Dans un objectif de limitation des risques, le modèle en spirale fait le travail puisqu’il permet une meilleure visibilité pour le client qui rejoint des livrables à chaque itération. Contrairement aux cycles en cascade et en V, la spirale permet de changer l’ordre de livraison des versions et ainsi d’adopter un comportement plus adaptable lors de l’implémentation des fonctionnalités.

 

Cependant, il est à noter que ce type de modèle n’est pas adapté au petits projets qui ne réclame pas tant de prototypes. Prenez un site statique, son cahier des charges ne sera pas adapté à ce type de modèle puisqu’il ne demandera point trop de fonctionnalités. De manière absolue, le cycle en spirale peut se révéler très complexe à l’utilisation par son nombre d’étapes parfois trop conséquent pour la compréhension commune des différents collaborateurs. 

 

Cycles en spirale

 

Les cycles semi-itératifs

 

Bien que traités depuis longtemps dans la sphère des génies logiciels avec notamment l’œuvre de James Martin entamée en 1989 et finalisée par la création du livre RAD (Rapid-Application Development) qui détermina la véritable fracture entre les anciennes méthodes (Cascade, en V, Spirale) et l’arrivée des méthodes Agiles.  

 

Un cycle semi-itératif se détermine par trois phases – bien que les deux premières aient en point commun la formulation des besoins et la conception d’une solution – réparties en deux catégories : Top Down (structuration) et Bottom Up (le besoin, l’objectif). C’est uniquement dans la troisième phase que la notion d’itérations courtes apparaît. 

 

Cycle semi itératif

 

Très vite, la multiplication des techniques itératives a permis l’émergence d’un schéma populaire regroupés dans le Manifeste Agile et ouvrant la porte à de nombreuses méthodes telles que Scrum, l’eXtreme Programming ou encore FDD. 

 

Les cycles itératifs/incrémentaux

 

L’adoption des cycles itératifs est actuellement la logique chez les porteurs de projets. On dit d’un projet qu’il est itératif lorsqu’il comporte 6 étapes : 

 

    1. L’expression des besoins : le client détaille de façon précise ses attentes et ses besoins les plus essentiels tout en étant mis au courant que certaines modifications risquent d’être apportées lors du processus de développement. 

    1. La rédaction des spécifications du projet : la partie des ingénieurs informatiques va traduire en langage informatique les besoins du client afin de pouvoir les générer de façon technique sur les phases suivantes. 

    1. Le développement 

    1. La validation / les tests : l’ensemble des tests visant à être certains que la réponse aux besoins d’origines est adéquate.  

    1. Évaluation du travail / bilan : phase essentielle de chaque itération, elle consiste à lister l’ensemble des problèmes rencontrer lors des précédentes étapes. 

    1. Déploiement / livrables : envoi des rendus au client.