le motif en spirale c'est un archétype du processus de développement d'applications. Il repose sur l'hypothèse que le développement logiciel est un cycle itératif qui se répète jusqu'à ce que les objectifs fixés soient atteints. Il a la capacité de gérer le grand nombre de risques pouvant survenir lors du développement de tout logiciel.
C'est l'un des modèles les plus importants pour soutenir la gestion des risques. Comme son nom l'indique, ce modèle est représenté en forme de spirale, où les différentes étapes du modèle sont réparties dans différents cycles. Le nombre de cycles dans le modèle n'est pas fixe et peut varier d'un projet à l'autre.
Index des articles
Le modèle en spirale a été défini par le mathématicien américain et professeur de génie logiciel Barry Boehm. Après avoir présenté son concept en 1986 pour le développement d'applications complexes, il publie son modèle en 1988 dans un cadre plus complet dans son article «Un modèle en spirale de développement et d'amélioration de logiciels".
Une partie de cette publication de 1988 a représenté graphiquement le modèle en spirale, montrant pleinement à quoi ressemble le processus de développement de logiciel de manière spirale et soutenu par des cycles..
Boehm est connu pour ses nombreuses contributions à l'ingénierie logicielle, telles que le modèle de coût constructif (COCOMO), le modèle en spirale du processus logiciel, l'approche G-Theory (gagnant-gagnant) pour la détermination et la gestion des exigences du logiciel..
Dans sa publication, Boehm a décrit le modèle en spirale comme une alternative possible au modèle de cascade précédemment établi, qui a également servi de base à sa pratique..
Le modèle en spirale n'a pas été le premier à discuter du développement cyclique, mais il a été le premier à expliquer pourquoi l'itération est importante. Comme prévu à l'origine, il a été ciblé sur de grands projets complexes dont les itérations vont généralement de 6 mois à 2 ans..
Ce modèle ne suppose pas que les tâches de développement logiciel sont conçues de manière linéaire, contrairement au modèle en cascade, mais les considère comme des tâches itératives.
Ce modèle cyclique a influencé l'architecture d'ingénierie logicielle basée sur un modèle (MBASE) et la programmation extrême.
Ce qui différencie grandement ce modèle des autres modèles de processus logiciels, c'est qu'il reconnaît explicitement les risques. Ainsi, il réduit considérablement l'échec des grands projets logiciels en évaluant à plusieurs reprises les risques et en vérifiant à chaque fois le produit en cours de développement..
Ce modèle informatique contient des composants de presque tous les autres modèles du cycle de vie du logiciel, tels que le modèle en cascade, le modèle de prototypage, le modèle itératif, le modèle évolutif, etc..
Pour cette raison, il est capable de gérer presque tous les types de risques que les autres modèles ne gèrent généralement pas. Cependant, en raison du si grand nombre de composants, ce modèle est beaucoup plus complexe que les autres modèles de développement logiciel..
Chaque tour de la spirale représente un cycle complet, par lequel passent toujours les quatre quadrants, représentant les quatre étapes du modèle..
Au fur et à mesure que la taille de la spirale augmente, les progrès réalisés augmentent également. Par conséquent, les étapes ne sont pas exécutées une seule fois, mais plusieurs fois, sous la forme d'une spirale..
Bien que cette répétition cyclique fasse que le projet se rapproche lentement des objectifs fixés, le risque d'échec du processus de développement est fortement minimisé..
Les quatre étapes ne mettent en œuvre que les objectifs de base d'un cycle, mais elles n'ont pas à se manifester à chaque cycle.
L'ordre de chaque cycle n'est pas non plus strictement déterminé. Par conséquent, le modèle peut être combiné à tout moment avec d'autres modèles.
Il est assez flexible, car les processus de définition des objectifs, d'analyse des risques, de développement et de planification sont effectués séparément pour chaque phase du projet..
Il est considéré comme un métamodèle car il inclut les autres modèles. Par exemple, si la spirale était d'un seul cycle, elle représenterait le modèle en cascade, car elle intègre l'approche graduelle de ce modèle classique.
Il utilise également l'approche du modèle de prototypage, car au début de chaque cycle, il assemble un prototype pour gérer les risques..
De plus, il est compatible avec le modèle évolutif, car les itérations de la spirale peuvent être considérées comme des niveaux évolutifs, à travers lesquels le système final est construit..
Les exigences système sont définies avec le plus de détails possible, y compris les performances, les interfaces matérielles / logicielles, les indicateurs clés de succès, etc. et examiner les objectifs à associer au cycle de développement actuel.
En outre, différentes alternatives pour sa mise en œuvre sont examinées, telles que build vs. acheter, réutiliser des composants existants ou sous-traiter, etc..
De même, des restrictions telles que le coût, le calendrier et les interfaces, la consommation de temps, etc. sont déterminées..
Toutes les alternatives proposées sont évaluées. Les objectifs et contraintes servent de références déterminantes pour sélectionner la meilleure solution.
De plus, les risques pouvant nuire à la réussite du projet sont identifiés, tels que le manque d'expérience, les nouvelles technologies, les délais serrés, les processus déficients, etc..
Enfin, des méthodes telles que le prototypage, les simulations, les modèles analytiques et les enquêtes auprès des utilisateurs sont utilisées..
Tout le développement nécessaire est effectué, en utilisant la technologie et la solution sélectionnées. À chaque itération, une meilleure version de l'application est créée.
Le code réel est écrit et testé plusieurs fois jusqu'à ce que le résultat souhaité soit atteint, qui servira ensuite de base aux futures étapes de développement.
À la fin d'un cycle, la planification du suivant commence. Cette planification pourrait être de continuer normalement avec le projet si l'objectif du cycle était atteint, compte tenu de la définition de l'objectif suivant.
Il pourrait également s'agir de trouver d'autres solutions, si l'étape précédente de développement s'avérait défectueuse. La stratégie existante pourrait être remplacée par l'une des alternatives précédemment définies ou par une nouvelle. Avec cela, une nouvelle tentative pour atteindre l'objectif donné serait lancée..
L'armée des États-Unis a adopté le modèle en spirale pour le développement et la mise à jour du programme de modernisation des systèmes de combat du futur (SCF)..
Officiellement lancés en 2003, les FSC ont été conçus pour équiper les troupes de véhicules connectés en temps réel à un réseau de champs de bataille extrêmement rapide et flexible..
Le projet a été divisé en quatre spirales de développement d'environ deux ans chacune. Spiral 1 devait démarrer en 2008 et livrer des prototypes à utiliser et à évaluer..
Après avoir terminé Spiral 1, Spiral 2 devait commencer en 2010. Le développement du produit final devait être livré en 2015..
En août 2005, Boeing a annoncé l'achèvement de la première étape importante du projet, à savoir la révision fonctionnelle des systèmes. Boeing et Science Applications International Corporation étaient les co-chefs de file du projet.
Cependant, pour octobre 2005, le Pentagone a recommandé de retarder le projet en raison de l'impact élevé sur les coûts de la guerre en Irak et de l'aide de l'ouragan Katrina..
Le projet a été annulé en 2009 après l'apparition de coupes budgétaires, sans pouvoir prouver les avantages du modèle en spirale dans cette mission.
Grâce à ce type de structure, les problèmes entre la conception et les exigences techniques du logiciel sont tacitement éliminés, grâce à des contrôles périodiques..
Les risques sont analysés à chaque étape du produit avant d'aller plus loin. Cela permet de surmonter ou d'atténuer les risques potentiels.
Tous les employés bénéficient de la grande importance de l'analyse des risques dans ce modèle, ce qui représente peut-être leur plus grand avantage par rapport aux autres modèles de processus.
L'évaluation régulière des risques gagne en valeur lors de l'utilisation de nouveaux environnements techniques, qui sont généralement associés à un potentiel de risque particulier en raison de l'absence de valeurs empiriques.
Les clients sont impliqués dans chaque étape du projet, jusqu'à ce que le projet soit terminé. Par conséquent, différents commentaires peuvent être recueillis pour améliorer la prochaine version du projet..
De plus, une rétroaction peut être obtenue à tout moment en raison de l'avancée en spirale. Ainsi, les clients et les utilisateurs peuvent être intégrés dès le début dans le processus de développement.
Il est particulièrement populaire et important pour les projets de grande envergure et complexes, où le contrôle budgétaire est une priorité pour les clients et les développeurs. Vous avez un contrôle maximal sur les coûts, les ressources et la qualité du projet logiciel.
Cela peut être assez coûteux car il nécessite un haut niveau d'expertise pour l'analyse des risques. De plus, les projets prennent beaucoup de temps à se développer, ce qui peut augmenter les frais généraux.
Une gestion préalable très active et complexe du projet est nécessaire, où chaque cycle est continuellement et soigneusement contrôlé et documenté.
Il est comparativement plus complexe que les autres modèles, car il existe de nombreux cycles, chacun passant par des étapes différentes, augmentant ainsi l'effort du processus de documentation..
La connaissance de l'analyse et de la gestion des risques, souvent indisponibles, est essentielle.
La gestion du temps est difficile car le nombre de cycles est inconnu. De plus, le processus de développement peut être retardé à tout moment si des décisions importantes doivent être prises dans un cycle ou par des actions supplémentaires lors de la planification du cycle suivant..
Il n'est pas toujours favorable d'effectuer de nombreuses étapes de développement logiciel car, malgré la polyvalence des tests, les parties inachevées du programme peuvent atteindre le système fini..
En conséquence, il existe toujours le risque que toute erreur ou incohérence conceptuelle affecte le produit final..
Personne n'a encore commenté ce post.