Keine Cache-Version

Caching deaktiviert Standardeinstellung für diese Seite:aktiviert (code LNG204)
Wenn die Anzeige zu langsam ist, können Sie den Benutzermodus deaktivieren, um die zwischengespeicherte Version anzuzeigen.

Cycles de vie d'un logiciel

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

Inhaltsverzeichnis 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.

Inhaltsverzeichnis 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.

Inhaltsverzeichnis 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.

Inhaltsverzeichnis 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.

Inhaltsverzeichnis 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.

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?_escaped_fragment_=

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.