Introduction

Génie Logiciel
Chapitre 3 : Cycle de vie d’un logiciel et modèles de cycle de
vie

Table des matières

1. Cycle de Vie du logiciel.......................................................................................................................2
1.1. Définition.....................................................................................................................................2
1.2. Étapes du cycle de vie..................................................................................................................2
1.2.1. Étude d’opportunité ou étude préalable...............................................................................3
1.2.2. Analyse des besoins..............................................................................................................3
1.2.3. Spécification..........................................................................................................................4
1.2.4. Conception............................................................................................................................5
1.2.5. Implémentation ou Programmation...................................................................................13
1.2.6. Tests unitaires et d’intégration............................................................................................13
1.2.7. Installation..........................................................................................................................15
1.2.8. Maintenance.......................................................................................................................15
2. Les modèles de cycle de Vie.............................................................................................................17
2.1. Le Modèle en cascade (Waterfall)..................................................................................................18
2.1.1. Les avantages du Modèle en cascade.........................................................................................19
2.1.2. Les inconvénients du Modèle en cascade...................................................................................19
2.2. Le Modèle en V..........................................................................................................................20
2.2.1. Les avantages du modèle en V................................................................................................21
2.2.2. Les inconvénients du modèle en V..........................................................................................21
2.3. Le Modèle par prototypage.......................................................................................................22
2.3.1. Les types de prototypage....................................................................................................22
2.4. Le Modèle en spirale..................................................................................................................23
2.5. Le Modèle par incrément...........................................................................................................24

Chapitre 3 : Cycle de vie d’un logiciel et Modèles de Cycle de vie Page 1 sur 24
1. Cycle de Vie du logiciel
1.1. Définition
Cycle de vie : Ensemble des étapes de la réalisation, de l’énoncé des besoins à
la maintenance ou retrait du logiciel.
L’origine du découpage de la vie d’un logiciel en étapes provient du constat que
les erreurs ont un coût d’autant plus élevé qu’elles sont détectées tardivement
dans le processus de réalisation. Le cycle de vie permet de détecter les erreurs
le plus tôt possible et ainsi de maîtriser la qualité du produit, les délais de sa
réalisation, et les coûts associés.
Le cycle de vie est la période de temps s’étalant du début à la fin du processus
du logiciel, il commence avec la proposition ou la décision de développer un
logiciel et se termine avec sa mise hors service.

1.2. Étapes du cycle de vie

Nous allons voir par la suite qu’il existe de nombreux modèles de cycle de vie et
dans chacun d’eux, on y retrouve toujours certaines étapes précises.
- Étude d’opportunité (par des économistes) ;
- Définition et analyse des besoins ; élaboration du cahier des charges(par le
commanditaire) ;
- Spécification (par les informaticiens) ;
- Conception architecturale et élaboration des tests d’intégration ;
- Conception détaillée et élaboration des tests unitaires ;
- Programmation ou codage ;
- Tests unitaires et d’intégration (validation et vérification) ;
- livraison (Implantation chez le commanditaire) ;
- Maintenance, formation des utilisateurs, évolution ;
- Retrait.

Chapitre 3 : Cycle de vie d’un logiciel et Modèles de Cycle de vie Page 2 sur 24
Ne pas voir ces étapes comme se succédant de façon linéaire. En effet, il y a en
général des retours vers les phases précédentes, si les tests ne réussissent pas
ou si les besoins du MOA évoluent.

1.2.1. Étude d’opportunité ou étude préalable

Le développement est précédé d’une étude d’opportunité ou étude préalable.
Cette a pour objectif de répondre aux questions du genre :
- Pourquoi développer le logiciel ?
- Comment procéder pour faire ce développement ? ;
- Quels sont les moyens nécessaires pour sa mise en œuvre ?;
Cette phase d’étude préalable comprend à la fois des aspects techniques et de
gestion. Parmi les tâches techniques, nous pouvons citer :
- Dresser un état de l’existant et faire une analyse de ses forces et de ses
faiblesses ;
- Identifier les idées ou besoins de l’utilisateur ;
- Formuler des besoins potentiels ;
- Faire des études de faisabilité ;
- Planifier la transition entre l’ancien logiciel et le nouveau ;
- Finaliser l’énoncé des besoins de l’utilisateur.

1.2.2. Analyse des besoins

Remarque importante : Il arrive que l’on regroupe la phase d’analyse et la phase de
spécification dans une seule et même phase ou alors qu’on les sépare comme nous allons le
faire ici. Une explication à cet état de chose est que les besoins sont exprimés par le client en
langage naturel (français ou anglais), mais il se trouve que des ambiguïtés liées à l’utilisation
de ces langages poussent les informaticiens à être encore plus précis dans cette analyse des
besoins via des langages appropriés d’où la notion de spécification.

L’objectif de cette phase est de comprendre les besoins du client. Le but de

cette phase est de produire un cahier des charges. Elle définit (phase d’analyse

Chapitre 3 : Cycle de vie d’un logiciel et Modèles de Cycle de vie Page 3 sur 24
des besoins) les objectifs généraux, l’environnement du futur système, les
ressources disponibles, les contraintes de performance…
Il est important qu’elle ne définisse que les caractéristiques essentielles du
logiciel pour laisser la place aux décisions de conception.
Durant la phase d’analyse, on produit également une version provisoire des
manuels d’utilisation et d’exploitation du logiciel.

1.2.3. Spécification
La phase de spécification a pour objectifs :
- de définir de façon claire ce que doit faire le logiciel (fonctionnalités détaillées,
exigences de qualité, interface …) ;
- de clarifier le cahier des charges, en supprimant les ambiguïtés et les
contradictions ;
Une spécification comporte les éléments suivants :
- description de l’environnement du logiciel ;
- spécification fonctionnelle : qui définit toutes les fonctions que le logiciel doit
offrir ;
- comportement en cas d’erreurs ;
- performance requises (temps de réponse, encombrement de la mémoire,
sécurité de fonctionnements ;
- interfaces avec l’utilisateur ;
- interfaces avec d’autres logiciels ;
Remarques importantes :

Chapitre 3 : Cycle de vie d’un logiciel et Modèles de Cycle de vie Page 4 sur 24
- Pour les gros systèmes, il est difficile de formuler une spécification définitive.
C’est pourquoi on supposera que les besoins initiaux du système sont
incomplets et inconsistants ;
- La définition des besoins et la spécification des besoins constituent des
moyens de description à différents niveaux de détails, s’adressant à différents
lecteurs ;
- La définition des besoins est un énoncé en langage naturel, des services que le
système est sensé fournir à l’utilisateur. Il doit être écrit de manière à être
compréhensible par les décideurs côté client et côté contractant, ainsi que par
les utilisateurs et acheteurs potentiels du système ;
- La spécification des besoins est un document structuré qui énonce les services
de manière plus détaillée. Ce document doit être suffisamment précis pour
servir de base contractuelle entre le client et le fournisseur du logiciel. On
utilise pour cela, des techniques de spécification formelle pour rédiger un tel
document, mais selon le bagage technique du client ;
- Il est difficile de détecter l’inconsistance et l’incomplétude d’une spécification
lorsqu’elle est décrite dans un langage naturelle non structuré. Il faut toujours
imposer une structuration lors de la définition des besoins ;

1.2.4. Conception
Après la phase d’analyse, suit directement la phase de conception qui peut être
décomposée en 2 phases successives :
- conception générale, conception globale, conception préliminaire, conception
architecturale ;
- conception détaillé.

Chapitre 3 : Cycle de vie d’un logiciel et Modèles de Cycle de vie Page 5 sur 24
[Link]. La conception générale
Si nécessaire, il faut commencer par l’ébauche de plusieurs variantes de
solutions et choisir celle qui offre le meilleur rapport entre coûts et avantages.
La conception générale consiste en :
- la décomposition du système en sous-systèmes ;
- la définition des interfaces et des liens entre ces différents composants ;
Ce processus de structuration doit être poursuivi jusqu’à ce que tous les
éléments du document de spécification soient pris en compte. Le résultat de
cette phase est un document de conception générale.
Durant cette phase de conception générale, il faut également préparer la phase
d’intégration. A cet effet, il faut élaborer un plan d’intégration, y compris un
plan de test d’intégration.

[Link]. La conception détaillée

La conception détaillée affine la conception générale. Elle commence par
décomposer les entités découvertes lors de la conception générale en entités
plus élémentaires. Cette décomposition doit être poursuivie jusqu’au niveau où

Chapitre 3 : Cycle de vie d’un logiciel et Modèles de Cycle de vie Page 6 sur 24
les entités sont faciles à implémenter et à tester, c’est-à-dire jusqu’à ce qu’elles
correspondent à des composants logiciels élémentaires.
Chacun de ces composants logiciels doit être décrit en détail : son interface, ses
algorithmes, le traitement des erreurs, ses performances, la représentation des
données.. L’ensemble de ces descriptions constitue le document de conception
détaillée.
Pendant cette phase de conception détaillée, il faut préparer la vérification des
composants logiciels élémentaires qui feront l’objet de la phase des tests
unitaires. Le résultat est consigné dans un document appelé plan de tests
unitaires. Il peut arriver qu’à cette phase, qu’il faille compléter le plan
d’intégration car de nouvelles entités ont pu être introduites pendant la
conception détaillée.
Pour résumer pour cette phase :
- Détailler le fonctionnement des composants ;
- Définir quelques algorithmes, la représentation des données, la gestion des
erreurs… ;
- Élaborer des tests unitaires pour s’assurer que les composants réalisés sont
bien conformes à leurs descriptions ;
- Résultat :

• Un dossier de conception détaillée ;

• Un dossier de tests unitaires ;

• Un dossier de définition d’intégration logiciel.

[Link]. La conception détaillée

La composante la plus importante de la qualité d’une conception est la
maintenabilité. C’est en maximisant la cohésion à l’intérieur des composants et
en minimisant le couplage entre ces composants que l’on parviendra à une
conception maintenable.

Chapitre 3 : Cycle de vie d’un logiciel et Modèles de Cycle de vie Page 7 sur 24
Quelques qualités d’une bonne conception
COHÉSION
La cohésion d’un composant permet de mesurer la qualité de sa structuration.
Un composant devrait implémenter une seule fonction logique ou une seule
entité logique. La cohésion est une caractéristique désirable car elle signifie que
chaque entité ne représente qu’une partie de la résolution du problème.
La cohésion représente le degré avec lequel une classe a une seule
responsabilité unique et spécifique. Une classe faiblement cohésive est donc
une classe qui effectue à elle seule des actions diverses et variées.

• La cohésion doit sa faire entre modules dans un composant, entre

services dans un module : « qui se ressemble s’assemble »

• L’idée est de vérifier que nous rassemblons bien dans une classe des
méthodes cohérentes, qui visent à réaliser des objectifs similaires.
Quelques explications sur la cohésion
package [Link];

import [Link];

import [Link];

import [Link];

import [Link];

import [Link];

public class A {

public String manageUser(final String login, final String password)

throws ClassNotFoundException, SQLException {

String uiMessage = "";

final User user = new User();

// first check user parameters

final boolean isParametersValid =  && !

[Link](password)

Chapitre 3 : Cycle de vie d’un logiciel et Modèles de Cycle de vie Page 8 sur 24
 && ( [Link]() > 3 ) ;

// then retrieve everything from database

if (isParametersValid) {

[Link]("[Link]");

final String url = "jdbc:postgresql://localhost:5433/CBDB";

final String dbUser = "cashbird";

final String dbPassword = "cashbird";

final Connection connection = [Link](url, dbUser,

dbPassword);

final Statement statement = [Link]();

final ResultSet resultSet = [Link](

"SELECT * FROM utilisateur WHERE login='" + login + "' AND password = '" +

password+"'");

while([Link]()){

[Link]([Link]("FIRSTNAME"));

[Link]([Link]("LASTNAME"));

[Link](true);

[Link]();

[Link]();

// finally format GUI message

if ([Link]()) {

uiMessage = "M. " + [Link]() + " " + [Link]() + ",

bienvenue chez NETAPSYS !";

}else {

uiMessage = "login ou mot de passe incorrect !";

return uiMessage;

}else {

uiMessage = "Vous devez renseignez tous les champs !";

return uiMessage;

Chapitre 3 : Cycle de vie d’un logiciel et Modèles de Cycle de vie Page 9 sur 24
Que fait ce code ? Il permet à un utilisateur de récupérer ses informations
(nom, prénom) d’une base de données, à partir de son login et mot de passe.
On commence par valider le login et le mot de passe, ensuite on récupère les
informations de la base de données, et enfin on les formatte pour retourner à
notre utilisateur un message user-friendly.
Cette classe A n’est pas cohésive : Elle effectue à elle seule des opérations qui
n’ont pas de lien direct entre elles : validation, vérification dans la base,
formatage.
Dans la pratique, on aspirera à avoir des composants aussi cohésifs que
possible. Une méthode amusante qui permet de savoir si un composant est
fortement cohésif est d’essayer de lui donner un nom évocateur. Si l’on y arrive
difficilement, c’est qu’il y a de fortes chances qu’il ne soit pas.
En essayant ce petit exercice sur notre classe A, on se rend compte qu’il n’est
pas si aisé de lui trouver un nom évocateur ; un nom bizarre pourrait être
UserValidatorRetrieverFormator…
Pour rendre notre conception plus cohésive, nous pouvons par exemple
décomposer notre classe en diverses classes pour que chacune d’elles est un
rôle spécifique et unique : UserManager, UserCredentialChecker, UserDao,
GuiMessageFormatter.
Constantine et Youdon identifient en 1979, sept niveaux de cohésion présentés
ci-dessous, du plus fort au plus faible.
- La cohésion fonctionnelle : la meilleur de toute

• le module assure une seule fonction

• tous les élements du composant contribuent à atteindre un seul

objectif( si un élément est supprimé, l’objectif ne sera pas atteint)

• Exemple : M1 = calcul solution ; M2 = imprime la solution.

- La cohésion séquentielle :

• Dans ce type de cohésion, la sortie d’un élément est utilisée en entrée

d’un autre (l’ordre des actions est important)

• Exemple : Saisir, Traiter, Imprimer.

Chapitre 3 : Cycle de vie d’un logiciel et Modèles de Cycle de vie Page 10 sur 24
- La cohésion de communication : bonne

• Lorsque tous les éléments d’un composant travaillent sur les mêmes
données ;

• exemple : M1 = calculer et imprimer les résultats.

- La cohésion procédurale : passable

Dans ce cas, les éléments d’un composant constituent une seule
séquence de contrôle.
- La cohésion temporelle : médiocre
On l’obtient quand dans un même composant sont regroupés tous les éléments
qui sont activés au même moment, par exemple l’initialisation du programme.
- La cohésion logique : la moins mauvaise

• Tous les éléments d’un composant effectuent des opérations semblables

comme par exemple, un module qui édite tous les types de transactions.

• Les composants ainsi constitués sont difficiles à modifier.

- La cohésion occasionnelle : la plus mauvaise

Le découpage en module conduit à ce qu’une fonction se retrouve assurée par
plusieurs modules. Dans ce cas, il n’y a pas de relation entre les éléments du
composant.
COUPLAGE
Le couplage est relatif à la cohésion. C’est une indication de la force
d’interconnexion des différents composants d’un système. En générale, des
modules sont fortement couplés lorsqu’ils utilisent des variables partagées ou
lorsqu’ils échangent des informations de contrôle.
Une entité (fonction, module, classe, package, composant) est couplée à une
autre si elle dépend d’elle.
Couplage faible

• Désigne une relation faible entre plusieurs entités (classes, composants)

permettant une grande souplesse de programmation, de mise à jour.

Chapitre 3 : Cycle de vie d’un logiciel et Modèles de Cycle de vie Page 11 sur 24
 • Chaque entité peut ainsi être modifiée en limitant l’impact du
changement au reste de l’application.
Couplage forte

• au contraire, tisse un lien puissant qui rend l’application plus rigide à

toute modification de code.

Chapitre 3 : Cycle de vie d’un logiciel et Modèles de Cycle de vie Page 12 sur 24
LA COMPREHENSIBILITE
Pour modifier un composant dans une conception, il faut que celui qui est
responsable de cette modification comprenne l’opération effectuée par ce
composant. Cette compréhensibilité dépend d’un certain nombre de
caractéristiques :
- La cohésion. Le composant peut-il être compris sans que l’on ne fasse
référence à d’autres composants ?
- L’appellation. Les noms utilisés dans les composants sont-ils significatifs ? Des
noms significatifs reflètent les noms des entités du monde réel que l’on
modélise.
- La documentation. Le composant est-il documenté de manière à ce que l’on
puisse établir une correspondance claire entre le monde réel et le composant ?
- La complexité. Les algorithmes utilisés pour implémenter le composant sont-
ils complexes ?

1.2.5. Implémentation ou Programmation

Après avoir achevé la conception détaillée, on peut passer à la phase
d’implémentation, également appelée phase de construction, de réalisation, ou
phase de codage. Lors de cette phase, la conception détaillée est traduite dans
un langage de programmation.
On choisit ici l’environnement de développement, du/des langage(s) de
programmation, des normes de développement.

1.2.6. Tests unitaires et d’intégration

Tout comme la phase d’analyse et de spécification, cette phase peut être
divisée en 2, en testant d’abord les composants les plus fins avant d’effectuer

Chapitre 3 : Cycle de vie d’un logiciel et Modèles de Cycle de vie Page 13 sur 24
des tests au niveau de l’intégration des composants. Nous allons ici présenter
les 2 types de tests.
Les objectifs de cette phase sont les suivants :
• Validation : assurer que les besoins du client sont satisfaits (au niveau de
la spécification, du produit fini) ;
◦ Concevoir le bon logiciel
• Vérification : assurer que le logiciel satisfait à sa spécification
◦ Concevoir le logiciel correctement.

Tests Unitaires
Lors des tests unitaires, on évalue chaque composant individuellement pour
s’assurer qu’il est conforme à la conception détaillée. Si ce n’est pas encore fait,
il faut élaborer à cette phase un jeu de données de test pour chaque
composant.
Il faut ensuite exécuter le composant avec ce jeu, comparer les résultats
obtenus aux résultats attendus, et consigner le tout dans le document des tests
unitaires. S’il s’avère qu’un composant contient des erreurs, il est renvoyé à son
auteur, qui devra diagnostiquer la cause de l’erreur puis corriger le composant.
Le test unitaire de ce composant est alors à reprendre.

Tests d’intégration
Après effectué avec succès les tests unitaires de tous les composants, on peut
procéder à leur assemblage, qui est effectué pendant la phase d’intégration.

Chapitre 3 : Cycle de vie d’un logiciel et Modèles de Cycle de vie Page 14 sur 24
Pendant cette phase, on s’assure que les composants développés s’emboîtent
bien les uns avec les autres, c’est ce que l’on appelle test d’intégration.

1.2.7. Installation
Après avoir intégré le logiciel, on peut l’installer dans son environnement
d’exploitation ou dans un environnement qui simule cet environnement
d’exploitation, et le tester pour s’assurer qu’il se comporte comme requis dans
la spécification élaborée à la phase d’analyse.
Les tests effectués dans cette phase prennent des noms variés selon leur
nature. On parle parfois de validation. Si l’on veut insister sur le fait que ces
tests doivent précéder la décision du MOA d’accepter ou non le logiciel, on
utilise les termes test d’acceptance, test de recette ou test de réception. En
réalité, il s’agit de montrer le comportement et les performances du logiciel
dans son environnement d’exploitation réel, ainsi le terme test d’exploitation
est d’usage.

1.2.8. Maintenance
La maintenance d’un logiciel est nécessaire pour corriger les défauts, améliorer
les performances, adapter le logiciel à un nouvel environnement, répondre à de
nouveaux besoins ou à des besoins modifiés. On distingue 3 grands types de
maintenance : la maintenance corrective, la maintenance perfective, la
maintenance adaptative. Sauf pour des corrections mineures, la maintenance
exige en fait que le cycle de développement soit réappliqué, même si c’est sous
une forme simplifiée.
Maintenance corrective : identifier et corriger les erreurs trouvées après la
phase de livraison.
Il faut cependant, faire attention au fait que :
- La plupart des corrections introduisent des nouvelles erreurs ;
- Les coûts de correction augmentent exponentiellement avec le délai de
détection
- La correction exige aussi une étude d’impact des modifications

Chapitre 3 : Cycle de vie d’un logiciel et Modèles de Cycle de vie Page 15 sur 24
La maintenance corrective donne lieu à de nouvelles livraison (release)
Maintenance adaptative : adapter le logiciel aux changements dans
l’environnement (format des données, environnement d’exécution )
Cette maintenance consiste à adapter le logiciel pour qu’il continue à remplir
son rôle compte tenu de l’évolution :
- des environnements d’exécution ;
- des fonctions à satisfaire ;
- des conditions d’utilisation.
Ex : Changement de SGBD, de systèmes d’exploitation.
Maintenance perfective or d’extension : améliorer les performances, ajouter
des fonctionnalités, améliorer la maintenabilité du logiciel.
La maintenance perfective donne lieu à de nouvelles versions.

Une fois qu’une version modifiée du logiciel a été développée, il faut bien
entendu la distribuer. De plus, il est en général nécessaire de fournir à
l’exploitant du logiciel une assistance technique et un support de consultation.
On peut dire que la maintenance et le support su logiciel comprennent les
tâches suivantes :
- effectuer des dépannages pour des corrections mineures ;
- réappliquer le cycle de développement pour des modifications importantes ;
- distribuer les mises à jour ;
- fournir l’assistance technique et un support de consultation ;
- maintenir un journal des demandes d’assistance et de support.

A un moment donnée, il peut arriver que l’on décide de mettre le logiciel hors
service. Les tâches correspondantes sont accomplies durant la phase de retrait
et comprennent :
- avertir les utilisateurs ;

Chapitre 3 : Cycle de vie d’un logiciel et Modèles de Cycle de vie Page 16 sur 24
- effectuer une exploitation en parallèle du logiciel à retirer et de son
successeur ;
- arrêter le support du logiciel.

2. Les modèles de cycle de Vie

Un cycle de vie d’un logiciel est un ordonnancement des différentes étapes du
processus de développement. Les étapes du cycle de vie que nous avons défini
dans la première partie de cette leçon sont indépendantes de tout modèle et
de toute méthode de développement.
Nous allons à présent voir les particularités des divers modèles et comment il
permette les enchaînements des différentes étapes du cycle de vie d’un logiciel.

Chapitre 3 : Cycle de vie d’un logiciel et Modèles de Cycle de vie Page 17 sur 24
2.1. Le Modèle en cascade (Waterfall)
Le modèle en cascade est l’un des tout premier modèle à avoir été élaboré. Il
est l’oeuvre de Winston Royce qui l’a mis sr pied en 1970. Pour bien
comprendre le modèle en cascade, il faut savoir que ce dernier s’inspire du
monde du BTP, dans lequel on ne peut pas construire la toiture avant les
fondations et que les conséquences d’une modification en amont du cycle ont
un impact majeur sur les coûts en aval.
Le modèle en cascade est basé sur 2 éléments fondamentaux :
- On ne peut pas passer à l’étape suivante tant que la précédente n’est pas
terminée.
« inutile de monter les murs tant que les fondations ne sont pas coulées »
- La modification d’une étape a un impact important sur les étapes à venir.
Lors de processus, chaque phase doit être définie précisément, c’est-à-dire,
qu’il correspond au cahier des charges écrit ultérieurement, et possède une
date d’échéance fixe. Lorsque l’étape est validée, le processus continue sinon
l’étape est refaite.

Pas de validation
intermédiaire.

Haut rique : erreur

couteuse

- Chaque phase se termine à une date précise par la production de certains

documents ou logiciels.
- Les résultats sont définis sur la base des interactions entre étapes et activités,
ils sont soumis à une revue approfondie. On ne passe à la phase suivante que si
les résultats sont jugés satisfaisant.

Chapitre 3 : Cycle de vie d’un logiciel et Modèles de Cycle de vie Page 18 sur 24
- L’activité d’une étape se réalise avec les résultats fournies par l’étape
précédente ; ainsi chaque étape sert de contrôle effectué lors de l’étape
précédente.
- Chaque phase ne peut remettre en cause que la phase précédente ce qui dans
la pratique s’avère insuffisant.
- L’élaboration des spécifications est une phase particulièrement critique : les
erreurs de spécification sont généralement détectées au moment des tests,
voire au moment de la livraison du logiciel à l’utilisateur. Leur correction
nécessite alors de reprendre toutes les phases du processus.

2.1.1. Les avantages du Modèle en cascade

- Simple
- Logique
- Bien adapté pour des petits systèmes et donc les spécifications sont fixes
- Contrôle facile
- Facilité de planification des étapes et des délais
- Accent sur la documentation et la structure
- Idéal pour les projets logiciels stables.

2.1.2. Les inconvénients du Modèle en cascade

- Très faible tolérance à l’erreur (les anomalies sont détectées tardivement) qui
induit automatiquement un coût important en cas d’anomalie
- Mal adapté à des systèmes complexes (processus de développement rarement
séquentiel)
- Les tests s’appliquent à l’application globale (pas de validation des besoins)
- Difficultés de définir tous les besoins dès le début du projet
- Délai assez long pour voir quelque chose.

Chapitre 3 : Cycle de vie d’un logiciel et Modèles de Cycle de vie Page 19 sur 24
2.2. Le Modèle en V
Le cycle en V est un paradigme du développement informatique. Il décrit les
étapes essentielles du développement d’un logiciel, le cycle de vie du projet. Il
est représenté par un V dont la branche descendante contient toutes les étapes
de la conception du projet, et la branche montante toutes les étapes de tests
du projet. La pointe du V, quant à elle, représente la réalisation concrète du
projet, le codage. En effet, chaque étape d’une branche a son pendant dans
l’autre branche, c’est-à-dire qu’une étape de conception correspond à une
étape de test qui lui est spécifique. A tel point qu’une étape de test peut être
élaborée dès que la phase de conception correspondante est terminée,
indépendamment du reste du projet.

- Il est dérivé du modèle en cascade, il montre non seulement l’enchaînement

des phases successives, mais aussi les relations logiques entre phases plus
éloignées ;
- Ce modèle fait apparaître que le début du processus de développement
conditionne ses dernières étapes ;
- Il est adapté aux projets de taille et de complexité moyenne ;
- La première branche correspond à un modèle en cascade classique. Toute
description d’un composant est accompagnée de définitions de tests ;
- La seconde branche correspond à des tests effectifs effectués sur des
composants réalisés ;
- L’intégration est ensuite réalisée jusqu’à l’obtention su système logiciel final ;

Chapitre 3 : Cycle de vie d’un logiciel et Modèles de Cycle de vie Page 20 sur 24
2.2.1. Les avantages du modèle en V
- La préparation des dernières phases (validation-vérification) par les premières
(construction du logiciel), permet d’éviter d’énoncer une propriété qu’il est
impossible de vérifier objectivement après la réalisation ;

2.2.2. Les inconvénients du modèle en V

- Malheureusement, ce modèle est rarement utilisé tel quel et le V est souvent
déséquilibré, tantôt côté analyse, tantôt côté recette et la marge d’erreur est
bien souvent proportionnelle à la marge de liberté prise par rapport au modèle
théorique.
- Manque de souplesse comme pour le modèle en cascade. En effet, de nos
jours, il n’est pas possible de nos jours d’appliquer ce modèle de manière
stricte. Le cycle en V devrait plutôt être vu comme un modèle standardisé, un
fonctionnement idéal vers lequel on voudra tendre. On peut le comparer au
modèle OSI en réseaux qui définit 7 couches alors que le modèle TCP-IP qui est
le plus utilisé n’a que 4 couches.
Le plus gros problème de ce modèle est que dans la réalité il est quasiment
impossible d’obtenir des spécifications fonctionnelles qui se suffisent à elles-
mêmes et qui ne seront pas impactées par la suite. C’est souvent pendant
l’implémentation du produit que l’on identifie les cas limites et les problèmes
conceptuels. Dans ce cas, une stricte application de ce modèle forcerait à
reprendre le cycle depuis le début, en intégrant au niveau fonctionnel les
remontées d’ordre technique.
- Construit-on le bon logiciel ? Le logiciel est utilisé trop tard.
• Il faut attendre longtemps pour savoir si on a construit le bon logiciel ;
• Il est difficile d’impliquer les utilisateurs lorsqu’un logiciel utilisable n’est
disponible qu’à la dernière phase
- Idéal uniquement quand les besoins sont bien connus, quand l’analyse et la
conception sont claires.

Remarque : La différence entre le modèle en cascade et le modèle en V est que

dans le modèle en cascade, les activités de tests sont effectués après les
activités de développement, alors que dans le modèle en V les activités de test
Chapitre 3 : Cycle de vie d’un logiciel et Modèles de Cycle de vie Page 21 sur 24
commence dès la première étape. En d’autres termes, le modèle en cascade est
un processus continu tandis que le modèle en V est un processus simultané. Si
les besoins des utilisateurs sont fixes, le modèle en cascade est approprié, mais
si les besoins des utilisateurs changent très souvent, il faut lui préférer le
modèle en V.

2.3. Le Modèle par prototypage

Il est parfois difficile de formuler une esquisse des besoins, surtout lorsque l’on
connaît peu le domaine. Dans ce cas, on ne peut pas espérer définir les besoins
de manière définitive avant le début du développement du logiciel. Un modèle
de processus basé sur le prototypage se révèle alors plus approprié que le
modèle classique de la cascade.
- Le prototypage permet de contourner la difficulté de la validation liée à
l’imprécision des besoins et caractéristiques du système à développer. Cela veut
dire que lorsqu’il est difficile d’établir une spécification détaillée, on a recours
au prototypage qui est considéré, dans ce cas, comme un modèle de
développement de logiciels.
- Le modèle de prototypage est souhaitable pour les projets où les besoins
• ne sont pas clairement définis
• peuvent changer avec le temps
- Le prototypage permet le développement rapide d’une ébauche du futur
système (ni performance, ni fonctionnalités, ni qualité)
- Le prototypage permet d’écrire une première spécification et de réaliser un
sous-ensemble du produit logiciel final. Ce sous-ensemble est alors raffiné
incrémentalement jusqu’à obtenir le produit final.

2.3.1. Les types de prototypage

Il existe 2 types de prototypage :
- prototype jetable : squelette du logiciel qui n’est crée que dans un but et dans
une phase particulière du développement. C’est une maquette exploratoire

Chapitre 3 : Cycle de vie d’un logiciel et Modèles de Cycle de vie Page 22 sur 24
développée pour mieux comprendre les besoins du client, évaluer différentes
solutions, etc. Développé rapidement et jeté ensuite.
- prototype évolutif : conservé tout au long du cycle de développement. Il est
amélioré et complété pour obtenir le logiciel final.

2.4. Le Modèle en spirale

Pour corriger les travers de la démarche linéaire sont apparues des méthodes
dites en spirales, proposé par B. Boehm en 1988, où les risques quels qu’ils
soient, sont constamment traités au travers de bouclages successifs :
- Chaque spire confirme et affine les spires précédentes en menant des activités
de même nature simultanément ;
- L’analyse ou la conception ne sont plus effectuées dans une seule phase ou
étape mais sont conduites en tant qu’activités qui se déroulent sur de multiples
phases ;
- Le nombre de cycles est variable selon que le développement est classique ou
incrémental ;
- Ce modèle est utilisé pour des projets dont les enjeux (risques) sont
importants.
Chaque cycle de la spirale se déroule en quatre phases :
1. Un cycle de la spirale commence par l’élaboration d’objectifs tels que la
performance, la fonctionnalité. On énumère ensuite les différentes manières de
parvenir à ces objectifs, ainsi que les contraintes. On évalue ensuite chaque
alternative en fonction des objectifs.
2. L’étape suivante évalue les risques pour chaque activité, comme l’analyse
détaillée, le prototypage, la simulation.
3. Après avoir évalué le risque, on choisit un modèle de développement pour le
système. Par exemple, si les principaux risques concernent l’interface
utilisateur, le prototypage évolutif pourrait s’avérer un modèle de
développement approprié. Le modèle en cascade est approprié si le principal
risque identifié concerne l’intégration des sous systèmes. Il n’est pas nécessaire
d’adopter un seul modèle à chaque cycle de la spirale ou même pour

Chapitre 3 : Cycle de vie d’un logiciel et Modèles de Cycle de vie Page 23 sur 24
l’ensemble d’un système. Le modèle de la spirale englobe tous les autres
modèles.
4. La situation est ensuite réévaluée pour déterminer si un développement
supplémentaire est nécessaire, auquel il faut planifier la prochaine étape.

2.5. Le Modèle par incrément

Dans les autres modèles étudiés précédemment, un logiciel est décomposé en
composants développés séparément et intégrés à la fin du processus. Dans le
modèle par incréments, seul un sous ensemble est développé à la fois. Dans un
premier temps un logiciel noyau est développé, puis progressivement, les
incréments sont développés et intégrés. Chaque incrément peut être
développé selon un des modèles étudié précédemment.

Avantages
- chaque incrément est moins complexe ;
- les intégrations sont progressives ;
- possibilité de livraisons et de mises en service après chaque incrément ;
- meilleur lissage du temps et de l’effort de développement à cause de la
possibilité de recouvrement des différentes phases. L’effort est constant dans le
temps contrairement au pic pour les spécifications détaillées rencontrés dans
les modèles en cascade ou en V.
Risques
- La remise en cause du noyau de départ ;
- la remise en cause des incréments précédents ;
- l’impossibilité d’intégrer un nouvel incrément.

Chapitre 3 : Cycle de vie d’un logiciel et Modèles de Cycle de vie Page 24 sur 24