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.
Deutsche Übersetzung
Sie haben gebeten, diese Seite auf Deutsch zu besuchen. Momentan ist nur die Oberfläche übersetzt, aber noch nicht der gesamte Inhalt.Wenn Sie mir bei Übersetzungen helfen wollen, ist Ihr Beitrag willkommen. Alles, was Sie tun müssen, ist, sich auf der Website zu registrieren und mir eine Nachricht zu schicken, in der Sie gebeten werden, Sie der Gruppe der Übersetzer hinzuzufügen, die Ihnen die Möglichkeit gibt, die gewünschten Seiten zu übersetzen. Ein Link am Ende jeder übersetzten Seite zeigt an, dass Sie der Übersetzer sind und einen Link zu Ihrem Profil haben.
Vielen Dank im Voraus.
Dokument erstellt 13/04/2005, zuletzt geändert 03/02/2021
Quelle des gedruckten Dokuments:https://www.gaudry.be/de/analyse-cycle-logiciel.html
Die Infobro ist eine persönliche Seite, deren Inhalt in meiner alleinigen Verantwortung liegt. Der Text ist unter der CreativeCommons-Lizenz (BY-NC-SA) verfügbar. Weitere Informationen auf die Nutzungsbedingungen und dem Autor.
