MR1-IDIAG 2020-2021 Dorsaf Aribi

Cycle de vie du logiciel

1 Définition du cycle de vie logiciel et ses différentes
phases :
Le cycle de vie du logiciel est la description d’un processus couvrant
les phases de création d’un produit, distribution sur un marché et
disparition.
Le but de ce découpage est de maı̂triser les risques, maı̂triser au mieux
les délais et les coûts et obtenir une qualité conforme aux exigences.

Le cycle de vie du logiciel comprend généralement a minima les acti-

vités suivantes :

• Définition des objectifs consistant à définir la finalité du projet et son

inscription dans une stratégie globale.
• Analyse des besoins et faisabilité c’est-à-dire l’expression, le recueil
et la formalisation des besoins du demandeur (le client) et de l’ensemble
des contraintes.
• Conception générale Il s’agit de l’élaboration des spécifications de
l’architecture générale du logiciel.
• Conception détaillée consistant à définir précisément chaque sous-
ensemble du logiciel.
• Codage (Implémentation ou programmation soit la traduction
dans un langage de programmation des fonctionnalités définies lors de
phases de conception.
• Tests unitaires permettant de vérifier individuellement que chaque
sous-ensemble du logiciel est implémentée conformément aux spécifications.
• Intégration dont l’objectif est de s’assurer de l’interfaçage des différents
éléments (modules) du logiciel. Elle fait l’objet de tests d’intégration
consignés dans un document.
• Qualification (ou recette) c’est-à-dire la vérification de la conformité
du logiciel aux spécifications initiales.
• Documentation visant à produire les informations nécessaires pour
l’utilisation du logiciel et pour des développements ultérieurs.
• Mise en production
• Maintenance comprenant toutes les actions correctives (maintenance
corrective) et évolutives (maintenance évolutive) sur le logiciel.

2 Les modèles de cycle de vie :

2.1 Modèle en cascade
Le modèle en cascade met l’accent sur le fait que chacune des phases
d’un projet doit être terminée, et ses livrables passés en revue et va-

1
lidés, avant que la phase suivante ne puisse commencer.

Ce modèle exclut les allées et venues entre le cahier des charges et la

conception du produit, ce qui peut être un inconvénient majeur pour
certains projets.

2.2 Modèle en V
Le modèle en V met l’accent sur les tests : un plan de test est préparé
avant l’implémentation pour chaque niveau de spécifications. Les tests
sont faits à chaque niveau, conformément au plan.
Les tests doivent d’abord confirmer la conformité aux spécifications
conceptuelles et techniques des  unités  (ou  modules ) qui ont
été développés.
Puis il faut tester la conformité aux spécifications conceptuelles et
techniques du  système  résultant de l’intégration de tous les mo-
dules et, le cas échéant, du contenu.
Finalement, il faut tester la conformité au cahier des charges du pro-
duit complet.
Comme c’est le cas dans le modèle en cascade, le modèle en V exclut
les allées et venues entre le cahier des charges et la conception du
produit.

2
2.3 Modèle en spirale
Le modèle en spirale est un processus itératif qui met l’accent sur
l’analyse et la résolution des risques.
Les risques sont évalués au début du cycle puis minimisés par la
production de multiples prototypes soumis au client pour test et
évaluation.
Le cahier des charges peut être ajusté pour tenir compte de ce qui
est techniquement réalisable (ou pas).
Plus la spirale compte de tours, plus le coût du projet est élevé !

3
2.4 Modèle incrémental
Le modèle incrémental, qui implique une application répétée du modèle
en cascade, peut être utilisé pour des projets de développement qui
sont exécutés avec de multiples itérations.
Chaque itération fournit une version du logiciel qui fonctionne (à
tester...), qui évolue ainsi par incréments vers le produit final, en li-
mitant le risque d’écart par rapport au cahier des charges.