Cycles de vie d'un logiciel

Table des matières

Il existe plusieurs manières de modéliser le cycle de vie d'un logiciel :

Table des matières Haut

Modèle de la cascade (Waterfall approach)

Dans ce modèle,  chaque phase se termine à une date précise par la production de certains documents ou logiciels qui doivent impérativement satisfaire aux critères pour passer à la phase suivante.

Nous pouvons décomposer le modèle en 5 phases, du plus général (concept) au plus précis (code):

Analyse des besoins
(Requirements analysis and definition)
En consultation avec l'utilisateur, le programmeur détermine les besoins et les buts à atteindre.
A la fin de cette phase, le client valide (ou refuse) le projet.
Conception générale
(System and software design)
Le programmeur détermine (en fonction de l'environnement matériel et logiciel) les grandes lignes de conduite à adopter.
Implémentation
(Implementation and unit testing)
Le programme est décomposé en une série d'unités qui réalisent différentes tàches. Chaque unité est mise en code.
A la fin de cette phase, subit une validation pour vérifier qu'elle respecte ses propres spécifications et qu'elle exécute la tàche qui lui incombe.
Intégration
(Integration and system testing)
L'ensemble des unités est intégré dans le programme pour former le logiciel demandé. C'est donc l'ensemble, et les interactions entre les différentes unités qui sont testés.
A la fin de cette phase le logiciel est livré au client, validé par ce dernier.
Installation et maintenance
(Operation and maintenance)
Cette phase est (normalement) la plus longue. Le logiciel est en production, et l'utilisateur peut découvrir certains défauts ou manquements qui nécessiteront des réajustements. Comme cette partie est censée durer, elle comporte les opérations de maintenance.

Table des matières Haut

Remarques

En pratique, ce modèle n'est pas respecté à la lettre, car les délais ont forcé les développeurs à effectuer des recouvrements (overlapping) entre les différentes phases.

De plus, le modèle original ne comportait pas de possibilité de retour en arrière. Celle-ci a été rajoutée ultérieurement, une étape ne remettant en cause que l'étape précédente (Iteration in the waterfall model).

Si trop de retours en arrière entraînent un risque de dépassement des délais, certains aspects d'une des phases sont gelés, afin de poursuivre quand même.

Table des matières Haut

Modèle de programmation exploratoire

Un modèle exploratoire n’est pas destiné à fonder directement une décision de gestion opérationnelle, et encore moins à être fourni clef en main à un gestionnaire. Ce type de modèle est employé pour approfondir la connaissance du système modélisé, provoquer des questions, des réflexions, et peut donc, indirectement, se trouver à l’origine de négociations ou réflexions qui conduiront à prendre des décisions de gestion.

Ce type de modèle permet de programmer sans que les spécifications soient clairement établies au départ.

Le logiciel est très rapidement mis à la disposition de l'utilisateur. De nombreuses petites modifications interviennent au fil des problèmes rencontrés jusqu'au moment où le programme fonctionne correctement. Ce type de programmation se rapproche de l'intelligence artificielle, où l'apprentissage se fait par la découverte des erreurs, et l'analyse des possibilités d'optimisation.

Table des matières Haut

Modèle à prototypes

Ce type de modèle propose à l'utilisateur différents prototypes. Il n'est plus question ici d'une multitude de petites modifications, mais bien d'un nombre plus ou moins déterminé d'étapes, chaque étape présentant un produit au client.

Table des matières Haut

Modèle en spirale

Proposé par B. Boehm en 1988, ce modèle est beaucoup plus général que le précédent, et met l'accent sur l'activité d'analyse des risques.

Chaque cycle de la spirale se déroule en quatre phases :

  1. détermination, à partir des résultats des cycles précédents ou de l'analyse préliminaire des besoins, des objectifs du cycle, des alternatives pour les atteindre et des contraintes
  2. analyse des risques, évaluation des alternatives et, éventuellement maquettage
  3. développement et vérification de la solution retenue, un modèle classique (cascade ou en V) peut être utilisé ici
  4. revue des résultats et vérification du cycle suivant.

L'analyse préliminaire est affinée au cours des premiers cycles. Le modèle utilise des maquettes exploratoires pour guider la phase de conception du cycle suivant. Le dernier cycle se termine par un processus de développement classique.

Ce modèle a été moins expérimenté que les deux précédents. Sa mise en œuvre demande de grandes compétences et devrait être limitée aux projets innovants à cause de l'importance qu'il accorde à l'analyse des risques. Néanmoins, ce dernier concept peut être appliqué aux autres modèles.

Document créé le 13/04/2005, dernière modification le 03/02/2021
Source du document imprimé : https://www.gaudry.be/analyse-cycle-logiciel.html

L'infobrol est un site personnel dont le contenu n'engage que moi. Le texte est mis à disposition sous licence CreativeCommons(BY-NC-SA). Plus d'info sur les conditions d'utilisation et sur l'auteur.