Les processus de développement ou cycles de vie du logiciel

Dans cet article faisons un état des lieux plus détaillé des cycles de vie les plus importants et les plus couramment utilisés. Après une présentation des cycles classiques comme ceux en Cascade ou en V, seront présentées des méthodes plus récentes basées sur l’agilité.

Les Classiques

Cycle en Cascade

Le cycle en cascade est typiquement un cycle de développement prédictif. Provenant du bâtiment, il part du principe que la construction nécessite, en général, un enchaînement logique ; la couverture d’une maison ne peut pas être effectuée sans avoir préalablement fait les fondations. Il définit une démarche de développement séquentiel (figure 2.9) où chaque phase conduit à la production d’un ou plusieurs livrable(s) qui doivent être validés avant d’être utilisés lors de la phase suivante.

Le modèle en cascade nécessite la définition d’un planning détaillé qui énonce toutes les étapes et réalisations attendues. Différentes activités d’analyse, de conception, d’implantation, de tests et d’intégration sont effectuées afin de converger vers l’obtention du système logiciel final.



Initialement, le modèle en cascade est un cycle de développement purement séquentiel, cependant, diverses possibilités d’itération ou de retour vers les phases amont ont ensuite été intégrées au modèle. Ces itérations permettent de vérifier les produits obtenus au fil du développement et ainsi fournir plus de souplesse à la conception.

Cycle en V

Le cycle en V est l’un des cycles les plus connus et utilisés (figure 2.10). C’est un cycle de type prédictif qui a été défini pour remédier aux lacunes du cycle en cascade qui manque de réactivité face aux erreurs découvertes lors de la conception, du développement ou encore de l’analyse. La structure en V du cycle a l’avantage de mettre en vis à vis les activités de développement et de tests permettant de mieux préciser les documents à
partager entre ces phases, notamment les rapports de tests et les modifications qu’il est nécessaire d’apporter pour corriger les erreurs. Ainsi, lors de la phase montante du cycle, toutes les réalisations doivent être testées et validées.


Depuis les années 80, le cycle en V est considéré comme un standard du développement logiciel et de la gestion de projet dans les industries. A la suite du cycle en V sont apparues diverses variantes telles que, par exemple, le cycle en W qui propose d’effectuer deux cycles en V successivement, le premier servant à la conception d’un prototype de l’application, le second à construire l’application finale.

Cycle en Y

Dans son principe, le cycle de développement en Y, est proche du cycle en cascade dont il reprend l’aspect descendant. Son intérêt est de séparer les préoccupations concernant les aspects fonctionnels liés au domaine métier et les aspects techniques liés aux solutions technologiques à employer pour la mise en oeuvre.

Avec le MDA, un cycle en Y orienté modèle a été proposé afin de séparer les spécifications fonctionnelles (PIM) et les spécifications techniques (PSM). Cette approche a pour avantage de fournir un modèle plus rationnel de la gestion des modèles et de l’utilisation des transformations de modèles employées lors de la phase de conception pour faire coïncider les modèles techniques et fonctionnels (employés également lors de la phase d’implantation sous la forme de génération de code).

Cycle en Spirale

Défini par Barry Boehm, le cycle en spirale est une approche itérative du cycle de développement en V. Ainsi, il en reprend l’essentiel des concepts en s’articulant autour de quatre phases importantes (figure 2.12) : la détermination des objectifs, la détermination des risques, le développement et les tests et enfin la planification de l’itération suivante.




Par contre, à l’inverse du cycle en V, le modèle en spirale met un focus plus important sur l’analyse et la résolution des risques. Ceci est nécessaire car au fur et à mesure des itérations, la réalisation devient de plus en plus conséquente. Il est donc important d’évaluer correctement le risque à chaque itération sachant que toute erreur sera d’autant plus difficile à corriger que le développement sera avancé.

Pre-agilité

Cycle avec Prototypage Rapide (RAD)

Proposé dés la fin des années 1980, le cycle de développement avec Prototypage Rapide (Rapid Application Development aussi appelé semi-itératif) se situe entre une approche prédictive et une méthode agile dans le sens où il s’agit de l’une des premières approches à introduire la notion d’itération au sein du processus de développement. La méthode RAD se structure ainsi autour de cinq phases :

1. L’initialisation pendant laquelle le périmètre du projet et les ressources nécessaires à celui-ci sont définis. Le travail à effectuer est alors organisé par thèmes.
2. Le cadrage qui va définir les besoins et les fonctionnalités du produit. Cette phase est effectuée lors de réunions se basant sur des techniques d’animation spécifiques.
3. La conception des modèles nécessaires à l’élaboration du système logiciel proprement dit. Le client est fortement impliqué dans cette phase puisqu’il a pour rôle de valider les modèles proposés.
4. La construction du système logiciel par l’équipe de développement par une approche itérative selon les fonctionnalités demandées. Le client est toujours présent afin de valider les différentes réalisations.
5. La finalisation est une phase de validation globale du livrable final par le client.

Ainsi, les deux premières phases se placent dans une approche descendante comme celle en V ou en Cascade. Par contre, à partir de la troisième phase, le cycle de développement devient itératif en permettant d’alterner conception et validation. De plus, avec l’intégration du client dans le développement, cette démarche fournit plus de réactivité.

La méthode RAD est pionnière dans l’utilisation de l’itération et d’une intégration plus importante du client dans le processus de développement. A ce titre, elle peut être considérée comme initiatrice des méthodes agiles qui sont fondamentalement tournées vers ces concepts. Les paragraphes suivants présentent les démarches et cycles proposant une approche agile du développement.

Unified Process UP

Tout comme RAD, UP est un cycle de développement qui se positionne entre les approches prédictives et les approches agiles. Ce cycle de vie est né de l’approche orientée objet issue de la collaboration de Ivar Jacobson, Grady Booch et James Rumbaugh. L’approche UP tente de rationaliser les processus de développement logiciel en fournissant un guide de bonne pratique fondé sur six points :

1. Avoir une démarche incrémentale et itérative pilotée par les risques et les cas d’utilisation.
2. Avoir une gestion rigoureuse des exigences.
3. Centrer le développement sur l’architecture.
4. Faire une modélisation graphique des exigences.
5. Contrôler en permanence la qualité.
6. Contrôler les changements éventuels à effectuer.

Ces six bonnes pratiques prônées par UP sont en l’occurrence ce qui permet de rattacher ce cycle de développement aux méthodes agiles. En effet, contrairement aux démarches de développement classiques, UP oriente naturellement le développement pour que celui-ci soit à même de répondre aux changements.
UP définit une démarche de développement intégrant les neuf disciplines majeures nécessaires au développement : la modélisation métier, la définition des exigences, l’analyse et la conception, l’implantation, les tests, le déploiement, la gestion des changements, la gestion du projet et enfin la prise en compte de l’environnement. Basé sur ces disciplines qui seront employées à chaque itération, le processus de développement va alors pouvoir suivre les quatre phases du processus qui consistent en :

1. Le début dont l’objectif est d’unifier les points de vue de chacune des disciplines sur l’ensemble du projet.
2. L’élaboration qui a pour objectif de définir et de valider l’ensemble des modèles permettant la conception du système logiciel.
3. La construction qui doit fournir une version documentée et fonctionnelle du logiciel.
4. La transition dont le but est de finaliser le système.

Avec Unified Software Process Metamodel (USPM), les démarches de développement se sont orientées vers la modélisation des processus en suivant le credo issu de la publication de Lee Osterweil : Software processes are software too. Traduit littéralement que les processus de développement de logiciel sont aussi une forme de logiciel. Cette publication montre la nécessité de maîtriser le processus de développement en modélisant sa structure et son évolution.

L'agilité

L’extreme programming

L’extreme programming est à proprement parler une approche agile qui propose des itérations courtes impliquant au maximum le client et cherche à recentrer le développement sur la composante humaine en revalorisant les bonnes pratiques de développement telles que le binomage, la définition au plus court de tests fonctionnels permettant de valider l'application, la promotion de styles ou de pattern d'écriture de code.
XP fonctionne autour de 5 valeurs fondamentales souvents reprise dans les approches agiles plus récentes:

• Communication
• Feedback
• Simplicite
• Courage
• Respect

Scrum

Développée en 1993, Scrum est une approche agile qui met en avant l’intérêt des petites équipes de développement. Dans ces petites équipes, sont avant tout recherchées les compétences multidisciplinaires et la capacité d’intégration sociale des acteurs. Dans Scrum, les itérations appelées Sprint sont planifiées sur quatre semaines maximum. Ces itérations sont axées sur les besoins définis par le client qui constituent alors le référentiel de travail.
Les besoins sont hiérarchisés par degré d’importance et développés selon les priorités définies par le client. Chaque jour constitue une itération pendant laquelle une réunion est organisée pour établir l’état d’avancement du projet et de vérifier que les fonctionnalités et les délais sont bien respectés.



A la fin de chaque Sprint, une réunion établissant le bilan des réalisations est menée afin d’établir l’efficacité de l’équipe et les éventuelles améliorations qui doivent être apportées. La finalité d’un Sprint est de présenter un démonstrateur au client afin que celui-ci puisse valider les réalisations. Scrum définit un certain nombre d’acteurs qui vont intervenir lors de la mise en oeuvre du processus :

1. Le ScrumMaster a pour rôle d’aider les acteurs du développement à communiquer au sein de l’équipe ainsi qu’avec le client. Il doit s’assurer que la philosophie et les pratiques de Scrum sont correctement suivies. Par contre son rôle n’est pas à confondre avec celui du chef de projet dont il est plutôt un conseillé.
2. Le Client ou Product Owner est lui aussi acteur du développement, il a pour rôle de définir les besoins. Il doit également définir les priorités dans les fonctionnalités à réaliser. Ainsi, il participe activement à l’élaboration du produit en suivant les étapes de sa réalisation afin de pouvoir en valider la finalité.
3. Enfin, l’Équipe qui est constituée de l’ensemble des corps de métiers nécessaires à l’élaboration du produit. Ces métiers sont classiquement ceux rencontrés lors des développements logiciels classiques (Développeur, Analyste, Testeur, etc.)

Pour finir, la méthode Scrum s’appuie sur la notion de Visibilité pour qualifier et quantifier les résultats de l’équipe. Des critères de validation doivent exister afin de définir si une fonctionnalité a été complètement réalisée ou non. Des critères d’Inspection doivent être définis afin de déterminer l’existence d’écarts entre la réalisation concrète et l’objectif final. Enfin, la notion d’Adaptation permet, lors d’écarts trop importants détectés pendant des Inspections, de modifier la gestion interne de l’équipe afin d’éviter que ces écarts ne s’amplifient. Ces critères permettront alors de gérer de la dette techniques ou encore d'évaluer la vélocité de l'équipe de développement afin de planifier au mieux les contenus des livraisons futurs

On peut noter que Scrum et XP sont deux approches très proches (on note d’ailleur une forte proximité des valeurs vehiculés) qui cherchent l’une comme l’autre a remettre la vie du développeur au centre du processus. Cependant Scrum a une volonté plus marqué de fournir un processus formellement établi pour gérer le cycle de vie du logiciel alors que XP s'intéresse plus sur les bonnes pratiques. Généralement les equipes de développement pratiquant l’une pratique préférablement la seconde.

Lean

Le lean est une approche de gestion de production développé par Toyota dans les années 90. Avec un héritage assumé issu du Taylorisme, le lean se définit dans une recherche d'accroissement de la productivité, de la qualité et d'une réduction systématique du gaspillage.

Dans les approches agiles, si XP a pour propos de mettre en avant des valeurs humaines et si Scrum a pour objet de recentrer le processus autour de la production des éléments a plus haute valeur, le Lean complète ces approches en visant l’optimisation des processus eux même.

Pour cela, le lean va se focaliser sur 7 règles qui servent d’axes de progressions (qui sont probablement des questions systématiques aux rétrospectives de sprints):

1. comment reduire les dechets? (temps perdus, réduction de dette technique, etc…)
2. comment améliorer la monté en compétences?
3. decider au plus tard
4. livrer au plus tot
5. valoriser l’equipe
6. la qualité commence des la conception
7. avoir toujours une vision du logiciel dans sa globalité (maintenir le recul)

Conclusion

Les processus de développement sont nombreux et si historiquement l'approche en V a été adoptée majoritairement, les nouvelles approches comme les approches agiles tendent a s'imposer comme étant des solutions plus dynamique et adaptées aux changements actuel. Je reviendrais plus dans le détail des approches telles que Scrum et Lean qui mérite au vue de leur présence actuel d'être approfondie. De la même manière, ces dernières années, au delà des processus de développement, on a pu voir émerger le DevOps dont le but est de regarder au delà des équipes de développement en prenant en considération l'ensemble des besoins des acteurs agissant de près ou de loin dans la livraison du produit au client. Il me semble que même si cela déborde du cadre des processus de développement de l'équipe logicielle, celle ci doit prendre en compte ces nouvelles préoccupations et cela a forcément un impact sur leur activité