Suite du Chapitre 1 :

Modèles de Cycles de Vie

des Logiciels
Youcef Hammal
Cours de Génie Logiciel

1
 1) Notion de Cycle de Vie
• Le GL perçoit la fabrication des programmes comme un
processus à étapes ordonnancées selon une certaine
logique d’enchaînement.
• Le cycle de vie du logiciel est constitué de l'ensemble
des étapes successives de la fabrication depuis la
commande du logiciel par le maître d'ouvrage jusqu'à
sa mise en exploitation et lancement de la maintenance.
• A chaque étape, une ou plusieurs activités de
développement sont appliquées.
• Il y a différents modèles des cycles de vie qui diffèrent
au niveau de la logique d'enchaînement des étapes.
• Remarque : Un modèle est une représentation abstraite
qui se focalise sur les caractéristiques importantes,
2
 Notion de Cycle de Vie (2)
• On distingue dans tout cycle de vie deux sous cycles
internes :
 Cycle de développement comprenant les activités suivantes :
Analyse, Conception, Codage et Tests,
 Cycle de maintenance comprenant les activités suivante:
Exploitation et maintenance (corrective, adaptative et
évolutive).
• Quant aux modèles de cycles de vie, on distingue trois
classes, chacune se distingue des autres selon sa
logique d’enchaînement des étapes et la participation
des clients au processus de développement :
• Modèles linéaires
• Modèles évolutifs
• Modèles Hybrides.
 Modèles Linéaires de Cycles de Vie
• Modèles linéaires : le système logiciel est développé dans
sa totalité en appliquant les étapes de manière
séquentielle. Le client intervient uniquement au début et à
la fin du cycle de développement.
• Exemples : Modèles en Cascade et en V.
• Avantage : ils permettent de développer des logiciels
avec un bon ratio qualité/coût, quand les besoins sont
claires, stables, faciles à cerner.
• Inconvénient : Les erreurs de définition des besoins sont
détectées tardivement par le client. Quand les besoins du
client sont ambigus, difficiles à cerner et volatiles, ce taux
est très élevé qui induisent des coûts et des délais de
correction exorbitants, conduisant parfois à l’abandon du
projet
4
 Modèles évolutifs de Cycles de Vie
• Modèles évolutifs : pour pallier le problème de définition
des besoins, le projet est réalisé en appliquant plusieurs
cycles de développement, en faisant intervenir le client
pendant au moins un cycle de développement.
• Exemples : Modèles par prototypage, par incréments, en
spirale.
• Avantage : Les erreurs de définition des besoins sont
détectées par le client pendant les premières étapes de
développement. Cela permet de développer des logiciels
de bonne qualité, quand les besoins du client sont
ambigus, difficiles à cerner et volatiles.
• Inconvénient : Ces modèles sont coûteux en termes de
délais et budgets De plus ils nécessitent un personnel de
développement qualifié afin d’éviter des risques liés.
5
 Modèles Hybrides de Cycles de Vie
• Dans l’approche évolutive du développement :
• Les produits logiciels sont souvent de meilleure qualité.
• Cependant, le coût est toujours très élevé.
• Le contrôle et l’intégration du changement, surtout dans
le cas des grands systèmes, sont souvent plus difficiles.
• La meilleure solution pour les grands systèmes,
peut être composée de plusieurs approches
• En se basant sur l’analyse du risque, on choisit
l’approche appropriée pour chaque sous-système:
• Utilisation du prototypage pour les sous systèmes ayant
des spécifications à hauts risques.
• Modèle linéaire pour les parties bien connues (besoins
6
stables et clairs).
 2) Modèle en Cascade
• modèle proposé par Royce :

7
 Analyse et définition des Besoins
• Cette étape comporte deux activités fortement liées dont
les documents produits forment le cahier des charges:
Analyse des besoins et la spécification globale.
• Dans la 1ère activité, on étudie le domaine de l'application, ainsi que
l'état actuel de l'environnement du futur système afin d'en déterminer
les frontières, le rôle, les ressources disponibles et requises, les
contraintes d'utilisation et de performance, etc.
• Cette étude est menée en collaboration avec les experts du domaine
d'application et les futurs utilisateurs.
• Quant à la spécification, son rôle est d'établir une première description
du futur système en se basant sur les données de l'analyse des
besoins ainsi que des considérations techniques et de faisabilité
informatique.
• Son résultat est une description de ce que doit faire le logiciel
(fonctionnalités) en évitant des décisions prématurées de réalisation.
8
 Conception du système
• Après avoir décomposé le système en parties matériel et
logiciel selon l'analyse des besoins, on s'occupe dans cette
étape à enrichir la description du logiciel de détails
d'implémentation afin d'aboutir à une description très
proche d'un programme. Elle se déroule souvent en deux
étapes : conception architecturale et conception détaillée.
• L'étape de conception architecturale consiste à décomposer
le logiciel en composants plus simples en précisant les
interfaces et les fonctions de chaque composant.
• L'étape de conception détaillée fournit pour chaque
composant une description de la manière dont les fonctions
du composant sont réalisées : algorithmes, représentations
des données.
9
 Réalisation et tests unitaires
• Cette activité consiste à passer du résultat de la
conception détaillée à un ensemble de
programme ou de composants de programmes.
• Notons que tout en développant les
composants d'un logiciel, les tests unitaires sont
menés pour permettre de vérifier que ces
unités répondent à leurs spécifications.

10
 Tests d'intégration du système
• L'intégration consiste à assembler les
composants du logiciel pour obtenir un système
exécutable (avec la possibilité de gérer
plusieurs variantes du logiciel).
• Ensuite, on réalise des tests globaux et des
tests d’acceptation avec le client pour être sûr
que les besoins logiciels ont été satisfaits.
• Après quoi, le système est livré au client.

11
 Mise en exploitation et Maintenance
• Normalement, c'est l'étape la plus longue dans le cycle de vie du
logiciel.
• Une fois que le système est installé et mis en service, l'activité
maintenance intervient pour corriger les erreurs éventuelles qui n'ont
pas été découvertes lors des phases antérieures et/ou aussi améliorer
la réalisation des unités du système et à augmenter ses fonctionnalités
au fur et à mesure que de nouveaux besoins apparaissent.

12
 Particularité de la Maintenance :
• Cette étape peut entraîner des changements dans toutes les étapes
précédentes : l'analyse des besoins, la conception et la réalisation
du système ou mettre en évidence la nécessité de faire des tests
supplémentaires.
• Généralement les coûts de la maintenance des systèmes dont la
durée de vie est longue, dépasse de loin les coûts de
développement d'un facteur qui peut aller de 2 à 4.
• Exemple : le coût de développement d'un système avionique était
de 30 dollars/instruction et le coût de maintenance de 4000
dollars/instruction
• La plus grosse part de ces coûts provient des modifications des
besoins et non pas des erreurs. D'où l'importance de couvrir au
mieux la définition des besoins des utilisateurs. A cet effet, d'autres
variantes du modèle du cycle de vie plus évolutives ont été
proposées.
13
 Tableau (Boehm, 1975) des coûts approximatifs
relatifs à chaque étape :
Type de système coût de la phase (%)
Besoins/Conception Réalisation Test
Systèmes de commande 46 20 34
Systèmes embarqués 34 20 46
Systèmes d'exploitation 33 17 50
Systèmes scientifiques 44 26 30
Systèmes de gestion 44 28 28

• Il ressort de ce tableau que coûts les plus importants sont liés aux
activités de spécification/conception et de tests.
• Une réduction des coûts de développement peut être obtenue en
entreprenant des efforts supplémentaires au niveau de ces étapes de
début et de fin de ce cycle.
14
 Remarques sur le modèle en cascade :
• Bien que les étapes de vie en cascade apparaissent
comme un enchaînement séquentiel de phases
distinctes, en réalité ces étapes se recouvrent et
provoquent des retours d'information.
• L'un des buts de l'étape de tests est de s'assurer que le
système construit répond aux attentes des utilisateurs.
Cette activité s'appelle la validation. Par contre la
vérification (l'autre activité apparentée à la validation)
consiste à s'assurer que les descriptions successives du
logiciel et le logiciel lui-même satisfont la spécification
globale.
• N,B : Les erreurs de définitions des besoins sont détectés
par le client tardivement pendant le test d’acceptation,
c.a.d, à la fin du cycle de développement,
 3) Modèle en V
• Dans ce modèle, les premières étapes du
développement du logiciel, doivent préparer, pour les
étapes finales, les données liées aux activités de
validation et de vérification (V&V).
• L'idée de ce modèle est qu'avec la décomposition, la
recomposition doit être décrite et que toute description
d'un composant est accompagnée des tests qui
permettront de s'assurer qu'il correspond à description.

16
 Modèle en V

• Les flèches continues reflètent l'enchaînement séquentiel des étapes du modèle

de la cascade.
• Les flèches discontinues représentent le transfert d'une partie des résultats de
l'étape de départ vers une étape d'arrivée pour être utilisée directement.
• Exemple: à l'issue de la conception architecturale, le plan d'intégration et les jeux
de test d'intégration doivent être complètement décrits. 17
 Approches évolutives :
Maquettage & Prototypage
• La principale difficulté de l’activité de validation est due à
l’imprécision des besoins et des caractéristiques du
système à développer
• Cette approche consiste donc à produire rapidement une
prototype qui constitue une ébauche du futur système :
première version minimale et exécutable.
• Avec cette approche, on est capable de corriger le cahier
des charges:
• définir plus explicitement et de manière plus cohérente les
besoins des usagers,
• de détecter les fonctions manquantes,
• identifier et améliorer les fonctions complexes, comme elle permet
de démontrer la faisabilité et l’utilité de l’application. 18
 4) Approches évolutives :
Maquettage & Prototypage
• Un prototype répond à des objectifs différents : on
cherche à construire un système éventuellement très
incomplet, mais dans son dimensionnement réel de
façon à pouvoir faire des essais en vraie grandeur.
• On détermine d'abord un ensemble minimum de
fonctions elles-mêmes incomplètes de façon à
réaliser rapidement un premier incrément du logiciel
dont on se sert pour analyser son fonctionnement.
• L'utilisateur fournit en retour des informations au
concepteur qui modifie le prototype. Ce processus
d'évolution de prototypes continue jusqu'à ce que
l'utilisateur soit satisfait du système livré.
19

• .
Prototype non jetable / prototype
jetable) :
• Faut-il garder et faire évoluer le prototype vers le futur
système voulu ou bien jeter le prototype et développer le
dernier en se basant sur le cahier des charges corrigé ?
• Si l’on opte pour le prototype jetable, celui-ci est
abandonné et le logiciel réel est construit à partir de zéro.
• Jeter le prototype est dû aux imperfections propres à tout
prototype car la rapidité de développement est souvent
réalisée au détriment de la maintenabilité du logiciel.
• La réponse dépend en grande partie de la maintenabilité
du prototype (facilité de le corriger et de le faire évoluer).
• Les contraintes de délai et de budget viennent ensuite
comme facteurs secondaires.
20
 5) Modèle par incréments :
• Dans ce type de modèle, un seul sous ensemble des
composants d’un système est développé à la fois :
• un noyau est tout d’abord développé,
• puis des incréments sont successivement développés et
intégrés.
• Le développement de chaque incrément est un des
processus classiques.
• Notons qu’il peut aussi y avoir un chevauchement entre
les différents processus de développement de ces
incréments.

21
 Avantages de modèle par
incréments :
• Chaque développement est moins complexe,
• Les intégrations sont progressives,
• Il peut y avoir des livraisons et des mises en services
après chaque intégration d’incrément.
• Il permet de bien lisser (répartir) dans le temps l’effort de
développement et les effectifs par rapport à ce qu’on
rencontre dans les modèles en cascade et en V.

22
 Risques liés au modèle par
incréments :
• Risques liés au modèle :
• Mauvais choix du noyau,
• Mauvaise décomposition du système en incréments,
• Mauvaise définition des interfaces entre incréments,
 Ces risques peuvent causer des erreurs lors de
l’intégration des incréments.
• Solutions :
• La spécification du noyau, des incréments et de leurs interactions
doit être faite globalement au début du projet.
• Les incréments doivent être aussi indépendants que possible
aussi bien fonctionnellement qu’au niveau des calendriers de
développement.

23
 6) Modèle en Spirale (Boehm,
1988) :
• Modèle dit "en spirale" est plus général que les
précédents et qui met l'accent sur une activité particulière :
l'analyse de risques.
• Il s’applique principalement aux systèmes très complexes
et novateurs.
• Chacune des activités de développement est réalisée en
suivant un cycle multi-étapes où :
• les objectifs et les contraintes ainsi que les alternatives doivent
être énumérés et précisés au départ.
• Ensuite chaque alternative subit une série d’examens et
d’analyses de risque en faisant largement appel à la technique
du prototypage et ce, afin de choisir la solution optimale en termes
d’atteinte d’objectifs et satisfaction des contraintes.
24
 Risques majeurs rencontrés lors du développement
des systèmes logiciels complexes
Les risques majeurs du Solutions suggérées
développement de logiciel

Défaillance du personnel Embauche de personnel de haut niveau, adéquation entre

profil et fonction, esprit d’équipe, formation mutuelle …

Calendrier et budget irréalistes Estimation détaillée des coûts et délais, développement

incrémental, réutilisation …

Développement de fonctions Analyse de l’organisation, analyse de la mission, formulation

mal appropriées des concepts opérationnels, revues d’utilisateurs, …

Développement d’interfaces Maquettage, scénarios et revues d’utilisateurs, analyse des

utilisateurs mal appropriées tâches

Volatilité des besoins Seuil élevé de modification, masquage d’information,

développement incrémental où les derniers incréments sont
les plus changeants.
Problèmes de performances Simulations, modélisations, essais et mesures, maquettage.
Exigences démesurées par Analyses techniques de faisabilité, maquettage.
rapport à la technologie.
25
• Un développement de ce modèle commence par une
analyse préliminaire de besoins qui est affinée au cours
des premiers cycles, en prenant en compte les
contraintes et l’analyse des risques.
• Le modèle utilise systématiquement des maquettes, qui
durant ces cycles sont de nature exploratoire.
• Les troisièmes quadrants des cycles suivants
correspondent à de la conception, les choix étant guidés
par des maquettes expérimentales.
• Le dernier cycle se termine par la fin d’un processus
classique.
Modèle en Spirale (2)
 Modèle en Spirale (3)
• Selon le schéma ci-dessous, chaque cycle de la spirale
se déroule en quatre phases représentées par des
quadrants :
1. Détermination des objectifs du cycle, des alternatives pour les
atteindre, des contraintes, à partir des résultats des cycles
précédents ou s'il n’y a pas, d’une analyse préliminaire des
besoins,
2. Analyse des risques, évaluation des alternatives,
éventuellement maquettage,
3. Développement et vérification de la solution retenue (une
portion de développement classique où on peut appliquer un
des modèles précédents),
4. Revue des résultats et planification du cycle suivant.

28
 Modèle en Spirale (4)
• Lors de la phase de définition des besoins, plusieurs
variantes du cahier des charges sont élaborées qui
correspondent à des solutions satisfaisant différemment
les contraintes imposées par les besoins du client.
• Dans la 2ème étape du cycle, chacune des solutions est
ensuite expérimentée et analysée à l’aide du
prototypage. Ceci permet d’en choisir le cahier des
charges le plus adéquat et de le raffiner encore plus
dans la troisième étape.
• Dans la 4ème étape, le plan de développement y afférent
est élaboré en guise de préparation du cycle prochain
portant sur la conception architecturale du système
correspondant au cahier des charges retenu.
 Modèle en Spirale (5)
• Il est clair qu’un tel modèle s’applique aux
systèmes novateurs et très complexes car:
• son coût est très élevé,
• la mise en œuvre de modèle demande des
compétences et un effort important.
• En plus, il s’agit d’un modèle moins expérimenté que
les précédents et est moins documenté.
 7) Modèles Hybrides
• On décompose le grands système en plusieurs
sous/ systèmes,
• En se basant sur l’analyse du risque, on choisit
l’approche appropriée pour chaque sous-système:
• Utilisation du prototypage pour les sous systèmes ayant
des spécifications à hauts risques.
• Modèle linéaire pour les parties bien connues (besoins
stables et clairs).

31
 Exercices
1. Citer les quatre principaux facteurs de qualité d’un logiciel
(applicables à toutes les catégories de logiciels). Proposer deux
autres facteurs et dire dans quelles circonstances, ces deux
derniers deviennent – ils plus importants que les autres ?
2. Expliquer pourquoi le modèle de cascade ne devient pas approprié
pour le développement de certains logiciels. Justifier.
3. Établir un tableau montrant pour chacune des étapes du modèle en
V du cycle de vie des logiciels, les documents à délivrer en sortie.
4. Citer les points forts et les points faibles de chacun des modèles en
V et à incréments.
5. Comparer le prototypage jetable par rapport au prototypage non
jetable.
6. Montrer, pour chaque modèle de cycle de vie, les domaines
d’application les plus appropriés.
32