Modèle en spirale : le modèle de gestion des risques pour le dé­ve­lop­pe­ment logiciel

Le dé­ve­lop­pe­ment de nouveaux logiciels pose un grand défi à toutes les parties prenantes. Plus l’ap­pli­ca­tion à dé­ve­lop­per est complexe, plus il est difficile d’organiser clai­re­ment le processus de dé­ve­lop­pe­ment et le rendre maî­tri­sable dans sa com­plexité. C’est pourquoi on recourt ha­bi­tuel­le­ment à des plans détaillés étape par étape, également connus sous le nom de modes opé­ra­toires. Ceux-ci sub­di­vi­sent le processus de dé­ve­lop­pe­ment en phases de taille rai­son­nable dé­li­mi­tées dans le temps et dans leur contenu. L’un des modèles les plus connus, spé­cia­le­ment axé sur la réduction des risques, est celui qu’on appelle le modèle en spirale, qui date de 1986.

Après avoir présenté pour la première fois en 1986 sa méthode pour dé­ve­lop­per des ap­pli­ca­tions complexes, l’ingénieur logiciel américain Barry W. Boehm fit paraître son modèle dans la pu­bli­ca­tion A Spiral Model of Software De­ve­lop­ment and En­han­ce­ment en 1988 et dans un cadre également plus large. Dans cette pu­bli­ca­tion, il décrit le modèle en spirale comme une al­ter­na­tive possible au modèle en cascade établi jusqu’alors et qui servait en même temps de base ex­pé­ri­men­tale. Au contraire du modèle en cascade, le modèle en spirale ne part pas du principe que les tâches du dé­ve­lop­pe­ment logiciel doivent être or­ga­ni­sées de manière linéaire, mais de manière itérative. Les phases ne se déroulent pas de manière unique, étape par étape, mais en plusieurs fois, en suivant une spirale. À travers cette ré­pé­ti­tion cyclique, le projet avance re­la­ti­ve­ment lentement vers les objectifs fixés, mais en con­tre­par­tie le risque que le processus de dé­ve­lop­pe­ment échoue est dras­ti­que­ment réduit au moyen de contrôles réguliers.

Les problèmes survenant dans le cadre du processus de dé­ve­lop­pe­ment d’un logiciel peuvent avoir des con­sé­quences très variées sur le projet dans son ensemble. Il faut s'at­tendre dans tous les cas à une aug­men­ta­tion des coûts, à des efforts sup­plé­men­taires et à un retard dans la sortie du logiciel - des facteurs qui peuvent vite se trans­for­mer en problème exis­ten­tiel, surtout pour les petits éditeurs. Avec son approche in­cré­men­tielle et itérative - qui comprend aussi une éva­lua­tion régulière des risques sous forme d'ébauches de prototype, d’analyses ou de si­mu­la­tions - le modèle en spirale est censé éviter les scénarios de ce genre ou, du moins, en atténuer les ré­per­cus­sions négatives. Le projet logiciel suit donc con­ti­nuel­le­ment le cycle du modèle en spirale jusqu'à l’état final, en passant nor­ma­le­ment par les quatre étapes suivantes :

Un cycle-type dans le modèle en spirale commence par la dé­ter­mi­na­tion des objectifs à associer aux dif­fé­rentes étapes in­di­vi­duelles du processus de dé­ve­lop­pe­ment. Il peut ici s’agir par exemple d’améliorer des per­for­mances ou d’étendre des fonc­tion­na­li­tés. Dans le même temps, il convient de définir des al­ter­na­tives pour la mise en œuvre (con­cep­tion A vs. con­cep­tion B par exemple) et de dé­ter­mi­ner le cadre général ainsi que les coûts ou le temps de travail né­ces­saire.

L’étape suivante cor­res­pond à l’éva­lua­tion des al­ter­na­tives, dans laquelle les objectifs et le cadre général servent de valeurs de référence. Dans cette phase du cycle du modèle en spirale, le but est d’iden­ti­fier les zones d’in­cer­ti­tude, c’est-à-dire les zones du projet qui com­por­tent un risque non né­gli­geable pour l’avan­ce­ment du projet de dé­ve­lop­pe­ment. Ensuite a lieu l’éla­bo­ra­tion de la stratégie la moins risquée et la plus éco­no­mique, où des méthodes telles que le pro­to­ty­page, les si­mu­la­tions, les tests d’éta­lon­nage, les modèles d'analyse et les sondages d’usagers peuvent être employées.

Après l’analyse des risques, place au dé­ve­lop­pe­ment logiciel à pro­pre­ment parler, une phase toujours ca­rac­té­ri­sée par des risques résiduels relatifs. Si des risques liés aux per­for­mances ou aux in­ter­faces uti­li­sa­teur ou encore des risques con­cer­nant le contrôle des in­ter­faces internes pèsent sur le processus de dé­ve­lop­pe­ment, une stratégie de dé­ve­lop­pe­ment évolutive est d’abord possible, dans laquelle le projet est spécifié plus pré­ci­sé­ment et les pro­to­types optimisés. Le code est écrit et testé plusieurs fois jusqu’à obtenir le résultat voulu, lequel servira ensuite de base à faible risque pour les étapes de dé­ve­lop­pe­ment ul­té­rieures.

Avec la fin d’un cycle commence déjà la pla­ni­fi­ca­tion du cycle suivant. Il peut s’agir de l’avan­ce­ment régulier du projet, si l’objectif du cycle a été atteint et l’objectif suivant doit être défini. Mais il peut s’agir également de trouver des solutions, si l’étape de dé­ve­lop­pe­ment pré­cé­dente ne s’est pas déroulée comme prévu. Ainsi, par exemple, la stratégie suivie jusqu’alors peut être remplacée par l’une des al­ter­na­tives déjà définies au préalable ou bien par une nouvelle al­ter­na­tive. Avec celle-ci, il est ensuite possible de démarrer une nouvelle tentative pour atteindre l’objectif fixé.

Le dé­ve­lop­pe­ment logiciel selon le modèle en spirale est apprécié surtout pour les projets complexes de grande taille, dans lesquels la maîtrise du budget revêt une im­por­tance cruciale, tant pour le client que la société de dé­ve­lop­pe­ment. Toutes les parties prenantes profitent ici de la place centrale de l'analyse des risques, qui constitue pro­ba­ble­ment le principal avantage du modèle en spirale comparé aux autres modes opé­ra­toires. L'éva­lua­tion régulière des risques s'avère en par­ti­cu­lier payante lorsque sont déployés des en­vi­ron­ne­ments tech­niques novateurs qui, en règle générale, sont associés à un potentiel de risque élevé à cause d'une absence de valeurs em­pi­riques.

La structure cyclique fait partie elle aussi des points forts du modèle. D’une part, les conflits entre la partie con­cep­tion et les exigences tech­niques sont quasiment exclus grâce aux contrôles réguliers. D'autre part, il est à tout moment possible de re­cueil­lir et tenir compte des retours d’in­for­ma­tion en raison de la pro­gres­sion en forme de spirale. Ainsi, le client comme les uti­li­sa­teurs peuvent être impliqués dès le début dans le processus de dé­ve­lop­pe­ment. Néanmoins, la condition préalable pour jouir de ces avantages est une gestion de projet très active, puisque les dif­fé­rents cycles doivent être at­ten­ti­ve­ment et cons­tam­ment sur­veil­lés et do­cu­men­tés.

En outre, les nom­breuses petites étapes du dé­ve­lop­pe­ment logiciel selon le modèle en spirale ne pré­sen­tent pas que des avantages, puisque malgré une foule de tests, il n’est pas rare que des bouts de programme inachevés se re­trou­vent dans le système de pro­duc­tion. En con­sé­quence, il existe toujours le risque que d’éven­tuelles erreurs ou éventuels défauts de con­cep­tion soient présents également dans le produit final. Par ailleurs, des retards dans le dé­ve­lop­pe­ment peuvent avoir lieu à tout moment si au sein d’un cycle ou au moment de planifier le cycle suivant des décisions im­por­tantes portant sur la suite du processus doivent être prises.

Le tableau ci-dessous ré­ca­pi­tule les avantages et les in­con­vé­nients du modèle en spirale :