Cycle de développement (logiciel)
Pour les articles homonymes, voir cycle de développement.
Il existe différents types de cycles de développement entrant dans la réalisation d'un logiciel. Ces cycles prennent en compte toutes les étapes de la conception d'un logiciel.
Ce cycle de développement est aussi utilisé dans l'industrie aéronautique et spatiale pour définir des systèmes, ou des sous systèmes embarqués ou au sol qu'ils incluent ou pas de l'informatique.
Les grandes familles
modifier
Modèle en cascade
modifier
Le modèle en cascade[1] est issu du développement de logiciels.
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 (sanctionnée quelquefois par une revue de projet).
Cycle en V
modifier
Le modèle du cycle en V[2] 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. Dans les projets délicats, chaque phase démarre par une réunion de lancement (kick off).
De plus le cycle en V met en évidence la nécessité d'anticiper et de préparer durant 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. La revue de projet de chaque phase est ainsi facilitée.
Cycle en spirale
modifierLe 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 robuste.
Le cycle en spirale[3] 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. Celle-ci est rendue nécessaire par le fait que, lors d'un développement cyclique, il y a plus de risques de défaire, au cours de l'itération, ce qui a été fait au cours de l'itération précédente.
Cycle semi-itératif
modifier
Le cycle semi-itératif a pour origine les travaux de James Martin publiés à partir de 1989 dans diverses revues Nord Américaines. Ce cycle de développement fut totalement formalisé en 1991 dans le livre RAD[4] (Développement rapide d'applications). À partir de 1994, des travaux complémentaires menés en France (RAD2)[réf. nécessaire] et en Angleterre (DSDM) apportèrent des spécialisations aux techniques basiques initiales. L’adoption par Rational Unified Process[5] d’IBM et par le processus unifié consacra l’apogée de ce cycle toujours en vigueur dans les projets importants.
Dans le cycle semi-itératif les deux premières phases classiques (top down, par le besoin) 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 la structure) que la notion d’itérations courtes intervient[6]. C'est vers 2001 avec l'apparition de plusieurs méthodes dont ASD, FDD, Crystal, Scrum[7] ou l'extreme programming[8] et la vision uniformisée de leurs auteurs dans le cadre du Manifeste Agile (Agile Manifesto) et de l'Agile Alliance, que le cycle semi-itératif fut généralisé. Toutes les méthodes Agiles débutent par des phases séquentielles, courtes mais bien réelles, d'exploration, d'architecture et de planning. Un usage totalement itératif de ces méthodes n'est cependant pas exclu mais ne peut s'appliquer qu'à de très petits projets[réf. nécessaire].
Cycle itératif
modifier
On sépare les activités des artéfacts, un artefact é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 composant, d'un test, etc.
Rapportée à une activité de type gestion de projet, les phases sont :
- 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écifications ;
- élaboration = architecture ;
- fabrication = développement prototype ;
- transition = tests.
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
modifier
Le cycle en cascade a pour origine le développement de logiciels complexes, nécessitant des équipes importantes et un développement de briques ou lots.
Dans un tel contexte, pour bien gérer son projet, il est important de ne pas négliger la validation de chaque étape sous peine de le voir déraper[1].
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 de l'architecte projet affectent 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
- les besoins
- les spécifications logicielles
- l'architecture logicielle
- les tests
- la revue de projet aux niveaux sous-systèmes et système.
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 projets 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 méthodes de développement dites agiles en diminuant le formalisme et en multipliant le nombre de cycles (fonctionnement itératif).
Quelques méthodologies
modifier
Références
modifier- Winston W. Royce. Managing the Development of Large Software Systems. IEEE Wescon, p. 1-9, 1970
- John McDermid et Knut Ripken. Life cycle support in the ADA environment. University Press, 1984.
- Barry W. Boehm. A Spiral Model of Software Development and Enhancement. IEEE Computer, 21(5), p. 61-72, 1988.
- James Martin. Rapid Application Development. Macmillan Coll. Div., 1991.
- Philippe Kruchten. The Rational Unified Process: An Introduction. Addison-Wesley, Longman Publishing, Co., Inc. Boston, Massachusetts, 2000.
- « rad.fr/phasprin.htm »(Archive.org • Wikiwix • Archive.is • Google • Que faire ?).
- Ken Schwaber et Mike Beedle. Agile Software Development with SCRUM. Prentice Hall, Upper Saddle River, New Jersey, 2001.
- Kent Beck. Extreme Programming Explained: Embrace Change. Addison-Wesley Professional, Longman Publishing Co., Inc. Boston, Massachusetts, 1999.
Voir aussi
modifierArticles connexes
modifier- Gestion de projet
- Revue de projet
- Méthode agile
- Chaîne d'outils Devops
- Qualité des systèmes informatiques
- Feature freeze
Liens externes
modifier- Notices dans des dictionnaires ou encyclopédies généralistes :
