Cycle de développement 76854 31458684 2008-07-10T08:48:09Z Ir4ubot 296177 transition du param 2 vers le param date du modèle:sources {{sources|date=date inconnue}} Il existe différents types de '''cycles de développement''' entrant dans la réalisation d'un [[logiciel]]. Ces cycles prendront en compte toutes les étapes de la [[Conception de logiciel|conception d'un logiciel]]. ==Les grandes familles== ===Modèle en cascade=== [[Image:Cycle de developpement en cascade.JPG|thumb|300px|Les phases du cycle en cascade]] Le [[modèle en cascade]] est hérité du de l'industrie du [[BTP]]. Ce modèle repose sur les hypothèses suivantes : * on ne peut pas construire la toiture avant les fondations ; * les conséquences d'une modification en amont du cycle ont un impact majeur sur les coûts en aval (on peut imaginer la fabrication d'un moule dans l'industrie du plastique). Les phases traditionnelles de développement sont effectuées simplement les unes après les autres, avec un retour sur les précédentes, voire au tout début du cycle. Le processus de développement utilisant un cycle en cascade exécute des phases qui ont pour caractéristiques : * de produire des livrables définis au préalable ; * de se terminer à une date précise ; * de ne se terminer que lorsque les livrables sont jugés satisfaisants lors d'une étape de validation-vérification. ===[[Cycle en V]]=== [[Image:cycle de developpement en v.jpg|thumb|300px|Les phases du cycle en V]] Le modèle du cycle en V a été imaginé pour pallier le problème de réactivité du modèle en cascade. Ce modèle est une amélioration du modèle en cascade qui permet en cas d'anomalie, de limiter un retour aux étapes précédentes. Les phases de la partie montante, doivent renvoyer de l'information sur les phases en vis-à-vis lorsque des défauts sont détectés afin d'améliorer le logiciel.<br /> De plus le cycle en V met en évidence la nécessité d'anticiper et de préparer dans les étapes descendantes les « attendus » des futures étapes montantes : ainsi les attendus des tests de validation sont définis lors des spécifications, les attendus des tests unitaires sont définis lors de la conception, etc. Le cycle en V est devenu un standard de l'industrie du [[développement de logiciel]] et de la [[gestion de projet]] depuis les [[années 1980]]. ===[[:en:Spiral model|Cycle en spirale]]=== Le développement reprend les différentes étapes du cycle en V. Par l'implémentation de versions successives, le cycle recommence en proposant un produit de plus en plus complet et dur. Le cycle en spirale met cependant plus l'accent sur la gestion des risques que le cycle en V. En effet, le début de chaque itération comprend une phase d'analyse des risques. Ceci est rendu nécessaire par le fait que, lors d'un développement cyclique, il y a plus de risques de devoir défaire à la N<sup>e</sup> itération ce qu'on a fait à la N-X<sup>e</sup>. ===Cycle semi itératif=== Le cycle semi-itératif a pour origine les travaux de James Martin publiés à partir de 1989 dans diverses revues Nord Américaines. Il fut totalement formalisé en 1991 dans le livre RAD ([[Développement rapide d'applications]]). A partir de 1994, des travaux complémentaires menés en France (RAD2) et en Angleterre ([[DSDM]]) apportèrent des spécialisations aux techniques basiques initiales. L’adoption par RUP Rational [[Unified Process]] d’IBM consacra l’apogée de ce cycle toujours en vigueur dans les projets conséquents. Dans le cycle semi-itératif les deux premières phases classiques (top down, par la structure) consistent en l’expression des besoins et la conception de la solution. C’est lors de la troisième et dernière grande phase, la construction du produit (bottom up, par le besoin)) que la notion d’itérations courtes intervient (ressources : http://www.rad.fr/phasprin.htm). C'est vers 2001 avec l'apparition de plusieurs méthodes dont ASD, FDD, Crystal, Scrum ou [[extreme programming]] et la vision uniformisée de leurs auteurs dans le cadre du [[Manifeste Agile]] (Agile Manifesto) et de l' [[Agile Alliance]], que le cycle, théoriquement complètement itératif fut généralisé. La notion de "théoriquement" exprimant une réserve basée sur le fait que toutes ces approches débutent par deux phases séquentielles, courtes mais bien réelles, d'exploration et de planning. [[Image:Cyclesemi.gif]] ===[[:en:Iterative and incremental development|Cycle itératif]]=== [[Image:Modèle Itératif.PNG|thumb|300px|Les phases du Cycle itératif]] On sépare les activités des [[artéfacts]], un artéfact étant le produit issu d'une activité. Ainsi, on applique un cycle de type [[roue de Deming]] sur la production d'une documentation, d'un code, d'un test, etc. Rapportée à une activité de type gestion de projet, la première phase sera celle de * la faisabilité : l'acceptation d'un nouveau besoin * l'élaboration : on imagine comment on va le réaliser * la fabrication : construction * la transition : tout est mis en œuvre pour livrer au client Le cycle itératif '''n'est pas''' une [[bijection]] avec le cycle en V du type * faisabilité = [[spécification]]s * élaboration = [[Architecture informatique|Architecture]] * fabrication = [[développement prototype]] * transition = [[Test (informatique)|tests]] Sachant que chaque itération ne dépasse '''jamais''' huit semaines, cette tactique est donc impossible. En fait, l'idée est de livrer au plus tôt quelque chose qui puisse être testé par le client. On peut en effet réaliser plusieurs itérations sur une documentation telle que l'architecture. De la même manière, si un document n'est qu'un artéfact parmi d'autres, il ne faut pas obtenir un document complet. On préfèrera utiliser la [[Distribution de Pareto|loi de Pareto]] : ne pas passer 80% de l'effort sur les 20% restant. La différence entre un PDCA et une itération est la durée : elle doit être courte et régulière alors qu'une [[roue de Deming]] appliquée à une organisation de 300 personnes prend plusieurs mois, voire plusieurs années. ==Comparaison des approches Cascade, V et Itératif== Le cycle en V a pour origine l'Industrie Lourde. La particularité de ce milieu est que la phase qui suit nécessite bien plus de ressources que la précédente. <br/> Par exemple, pour fabriquer un objet en [[Matière plastique]], # un [[bureau d'étude]] va concevoir le produit, # puis des empreintes de moules seront usinées et placées dans des carcasses pour recevoir de la matière plastique par [[Moulage par injection|injection]] # et une fois que le prototype est correct, on passe à une phase de production. Il faut savoir que pour un objet simple tel qu'un gobelet en plastique, la conception est une affaire d'une poignée de semaines (soit quelques milliers d'[[euro]]s) alors qu'un moule (empreinte + carcasse) nécessite plusieurs mois de fabrication et plusieurs centaines de milliers d'euros. Par conséquent, dans un tel contexte, pour bien [[gestion de projet|gérer son projet]], il est important de ne pas négliger la validation de chaque étape sous peine de le voir déraper. Ce phénomène intervient sur des chantiers logiciels réunissant des dizaines voire des centaines de personnes. Les décisions de l'équipe de direction ou d'architecte de projet impactent tellement d'ingénieurs pour de telles durées qu'il vaut mieux s'assurer de la validité de chaque étape. Par ailleurs, pour limiter l'[[entropie]] (désordre) du système constitué par l'équipe-projet, il est nécessaire de formaliser par des documents (voire des outils) * les [[processus (gestion de la qualité)|processus]] * les [[besoin]]s * les [[spécification|spécifications logicielles]] * l'[[architecture logicielle]] * les [[Test (informatique)|tests]] Dans le cas d'un projet logiciel impliquant une douzaine de personnes pendant une à deux années, la configuration n'est plus la même ; en effet, avec de tels projet on dispose : * d'une plus grande réactivité due à ** une proximité géographique ** une facilité (relative) de communication * d'un facteur de coût limité entre chaque étape Aussi, il est possible de s'orienter vers des [[:Catégorie:Méthode de développement logiciel|méthodes de développement]] dites ''[[Méthode agile|agiles]]'' en diminuant le formalisme et en multipliant le nombre de cycles (fonctionnement itératif). ==Quelques méthodologies== [[Image:TaxonomieMéthodologies.PNG|thumb|300px|Taxonomie des méthodologies]] * [[Développement rapide d'applications]] * [[eXtreme Programming]] * [[Scrum]] * [[Unified Process|RUP]] * [[2TUP]] * [[Merise (informatique)|Merise]] * [[SADT]] * [[HERMES]] ==Voir aussi== * [[Méthode agile]] * [[:Catégorie:Méthode de développement logiciel]] * [[Qualité des systèmes informatiques]] {{Portail informatique}} [[Catégorie:Méthode de développement logiciel]] [[Catégorie:Programmation informatique]] [[Catégorie:Gestion de projet]] [[da:Softwareudviklingsproces]] [[de:Vorgehensmodell zur Softwareentwicklung]] [[en:Software development process]] [[es:Ciclo de desarrollo]] [[he:מתודולוגיית פיתוח תוכנה]] [[it:Ciclo di vita del software]] [[ja:ソフトウェア開発工程]] [[ko:소프트웨어 개발 프로세스]] [[lt:Programų kūrimo gyvavimo ciklo modelis]] [[nl:Softwareontwikkelmethode]] [[no:Programvareutviklingsprosess]] [[pt:Processo de desenvolvimento de software]] [[ru:Цикл разработки программного обеспечения]] [[ta:மென்பொருள் பொறியியல் வழிமுறை]] [[zh:项目生命周期]]