Cycles de vie d'un logiciel
Il existe plusieurs manières de modéliser le cycle de vie d'un logiciel :
- Modèle de la cascade
- Programmation exploratoire
- Prototypes
- Modèle de la spirale
- Transformations formelles
- Système modulaire
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.
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.
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.
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.
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 :
- 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
- analyse des risques, évaluation des alternatives et, éventuellement maquettage
- développement et vérification de la solution retenue, un modèle classique (cascade ou en V) peut être utilisé ici
- 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.
English translation
You have asked to visit this site in English. For now, only the interface is translated, but not all the content yet.If you want to help me in translations, your contribution is welcome. All you need to do is register on the site, and send me a message asking me to add you to the group of translators, which will give you the opportunity to translate the pages you want. A link at the bottom of each translated page indicates that you are the translator, and has a link to your profile.
Thank you in advance.
Document created the 13/04/2005, last modified the 03/02/2021
Source of the printed document:https://www.gaudry.be/en/analyse-cycle-logiciel.html
The infobrol is a personal site whose content is my sole responsibility. The text is available under CreativeCommons license (BY-NC-SA). More info on the terms of use and the author.
