REPUBLIQUE DU CAMEROUN REPUBLIC OF CAMEROON

Paix – Travail – Patrie Peace – Work – Fatherland

-.-.-.- -.-.-.-
UNIVERSITÉ DE YAOUNDÉ I UNIVERSITY OF YAOUNDÉ I
Faculté des Sciences Faculty of Sciences
Département d'Informatique Department of Computer Science
B.P. 812 Yaoundé P.O. Box 812 Yaoundé

INF2013: INTRODUCTION AU GENIE LOGICIEL ET AU SYSTÈME

D’INFORMATION

Chapitre 2 : Cycles de vie de développement logiciel

Sommaire
1. Introduction ............................................................................................................................. 3
2. Les activités du cycle de vie de développement logiciels ....................................................... 3
2.1. La spécification logicielle................................................................................................ 3
2.2. La conception et l’implémentation logiciel ..................................................................... 5
2.3. La validation logicielle .................................................................................................... 8
2.4. L’évolution logiciel ....................................................................................................... 10
3. Les modèles de cycles de vie de développement logiciel...................................................... 11
3.1. Le modèle en cascade .................................................................................................... 11
3.2. Le modèle incrémental .................................................................................................. 12
3.3. Le modèle en V ............................................................................................................. 13
3.4. Le modèle en spirale ...................................................................................................... 14
4. Conclusion ............................................................................................................................. 15
 1. Introduction

Un processus de développement logiciel encore appelé cycle de vie de développement

logiciel est un ensemble d'activités qui mène à la production d'un produit logiciel. Ces
activités peuvent impliquer le développement de logiciels à partir de zéro dans un langage
de programmation. L'origine de ce découpage provient du constat que les erreurs ont un
coût d'autant plus élevé qu'elles sont détectées tardivement dans le processus logiciel. Le
cycle de vie permet de détecter les erreurs au plus tôt et ainsi de maîtriser la qualité du
logiciel, les délais de sa réalisation et les coûts associés. L'objectif d'un tel découpage est
de permettre de définir des jalons intermédiaires permettant la validation du développement
logiciel, c'est-à-dire la conformité du logiciel avec les besoins exprimés, et la vérification
du processus de développement, c'est-à-dire l'adéquation des méthodes mises en œuvre.

2. Les activités du cycle de vie de développement logiciels

Bien qu’il existe plusieurs modèles de cycles de vie de développement logiciels, quatre
activités fondamentales sont communes à la plupart de ces modèles : il s’agit de la
spécification logicielle, le développement logiciel (conception + implémentation logiciel),
la validation logicielle et l’évolution logiciel. La manière dont ces activités sont menées
dépend du type de logiciel, des personnes et des structures organisationnelles impliquées.
Il n'y a pas de bonne ou de mauvaise façon d'organiser ces activités.

2.1. La spécification logicielle

La spécification logicielle ou ingénierie des besoins est le processus consistant à

comprendre et à définir les services requis d’un système logiciel à développer et à identifier
les contraintes liées à son fonctionnement et à son développement. L’ingénierie des besoins
est une étape particulièrement critique du processus logiciel car les erreurs à ce stade
conduisent inévitablement à des problèmes ultérieurs lors de la conception et la mise en
œuvre du système. Le processus d'ingénierie des besoins est illustré à la figure 1. Ce
processus conduit à la production d'un document des exigences encore appelé spécification
du système. Les exigences sont généralement présentées à deux niveaux de détail dans ce
document. Les utilisateurs finaux et les clients ont besoin d'un énoncé de haut niveau des
exigences ; les développeurs ont besoin d'une spécification système plus détaillée.

Le processus d'ingénierie des exigences comprend quatre phases principales :

• L’étude de faisabilité : Une estimation est faite pour savoir si les besoins des
utilisateurs identifiés peuvent être satisfaits en utilisant les technologies logicielles
et matérielles disponible. L'étude examine si le système proposé sera rentable d'un
point de vue commercial, s'il peut être développé dans le cadre d’un certain nombre
de contraintes budgétaires et s’il est pratiquement et technologiquement réalisable.
Une étude de faisabilité doit être relativement bon marché et rapide. Le résultat
devrait éclairer la décision de procéder ou non à une analyse plus détaillée.

Figure 1 : Le processus d’ingénierie des besoins

• Le recueil et l’analyse des exigences : Il s'agit du processus de dérivation des

exigences du système par l'observation des systèmes existants, des discussions avec
 les utilisateurs potentiels et les acheteurs, l'analyse des tâches, etc. Cela peut
impliquer le développement d'un ou plusieurs modèles de système et prototypes.
Ceux-ci aident l'analyste à comprendre le système à spécifier.

• La spécification des exigences : Il s’agit de l'activité de traduction des

informations recueillies au cours l'analyse des besoins en un document définissant
un ensemble d'exigences. Deux types d'exigences peuvent être inclus dans ce
document. Les exigences utilisateurs sont des déclarations abstraites des exigences
du système pour les clients et utilisateurs finaux du système et les exigences
systèmes qui sont des descriptions plus détaillées des fonctionnalités à fournir.

• La validation des exigences : Lors de Cette activité, les exigences sont vérifiées
relativement à leur réalisme, leur cohérence et leur exhaustivité. Au cours de ce
processus, des erreurs dans le document des exigences sont inévitablement
découvertes. Il doit ensuite être modifié pour corriger ces derniers.

Bien entendu, les activités du processus d’ingénierie des exigences ne sont pas
simplement exécutées dans un ordre strict. L'analyse des exigences se poursuit pendant la
définition et la spécification, et de nouvelles exigences apparaissent tout au long du
processus. Par conséquent, les activités d'analyse, de définition et de spécification sont
entrelacées.

2.2. La conception et l’implémentation logiciel

La phase d’implémentation du processus développement logiciel est le processus de

conversion d'une spécification système en un système exécutable. Cette tache implique
toujours au préalable une phase de conception logiciel. La conception logicielle est une
description de la structure du logiciel à implémenter, des données qui font partie du
système, des interfaces entre les composants du système et, parfois, des algorithmes
utilisés.
 Le processus de conception peut impliquer le développement de plusieurs modèles du
système à différents niveaux d'abstraction. La figure 2 présente le modèle général du
processus de conception logiciel incluant un ensemble d’activité et de livrables associés :

• La conception architecturale : Les sous-systèmes constituant le système et leurs

relations sont identifiés et documentés.

• Spécification abstraite pour chaque sous-système : une spécification abstraite

des services et contraintes sous lesquelles de chaque sous-système doit fonctionner
est produite.

• Conception de l'interface pour chaque sous-système : les interfaces de chaque

sous-système avec les autres sous-systèmes est conçue et documentée. Cette
spécification d'interface doit être sans ambiguïté car elle permet aux sous-systèmes
d'être utilisé sans connaissance de leur fonctionnement internes.

• Conception des composants : Les services sont alloués aux composants et les
interfaces de ces composants sont conçues.

• Conception de la structure de données : Les structures de données utilisées dans

la mise en œuvre du système sont conçues en détail et spécifiées.

• Conception d'algorithmes : Les algorithmes utilisés pour fournir les services sont
conçus en détail et spécifiés

Le développement d'un programme (programmation ou codage) pour l’implémentation

d’un système découle naturellement des processus de conception du système. Bien que
certaines classes de programmes, telles que les systèmes critiques, soient généralement
conçues en détail avant le début de toute implémentation, il est plus courant que les
dernières étapes de conception et de développement de programme soient entrelacées. La
programmation est une activité personnelle et il n'y a pas de processus général
généralement suivi. Certains programmeurs commencent avec des composants qu'ils
Figure 2 : Modèle générale du processus de conception logiciel
Comprennent, les développent, puis passent à des composants moins bien compris.
D'autres adoptent l'approche inverse, laissant les composants familiers pour la fin parce
qu'ils savent comment les développer. Certains développeurs aiment définir les données au
début du processus, puis les utiliser pour piloter le développement du programme ; d'autres
laissent des données non spécifiées aussi longtemps que possible.

2.3. La validation logicielle

La validation logicielle ou, plus généralement, la vérification et la validation

(V&V) a pour but de montrer qu'un système est conforme à ses spécifications et que le
système répond aux attentes du client achetant le système. Plus spécifiquement, La
vérification fait référence à l'ensemble des activités qui garantissent que le logiciel
implémente correctement une fonction spécifique. La validation fait référence à un
ensemble différent d'activités qui garantissent que le logiciel qui a été construit est traçable
jusqu'au client exigences. Ce processus englobe un certain nombre d’activité (les audits,
l’examen de la documentation, l’examen de la base de données, l’analyse des algorithme…
etc.) donc le plus important est l’activité de tests logiciels.

Sauf pour les petits programmes, les systèmes ne doivent pas être testés comme une
seule unité monolithique. La figure 3 montre un processus de test en trois étapes où les
composants du système sont testés, le système intégré est testé et, enfin, le système est testé
avec les données du client. Les étapes du processus de test sont :

• Les tests des composants ou test unitaires : Les composants individuels sont
testés pour s'assurer qu'ils fonctionnent correctement. Chaque composant est testé
indépendamment, sans autres composants du système. Les composants peuvent être
des entités simples telles que des fonctions ou des classes d'objets, ou peuvent être
des regroupements cohérents de ces entités.
Figure 3 : Les phase de tests dans le processus de développement logiciels
 • Les tests d’intégration système : Les composants sont intégrés pour constituer le
système. Ce processus concerne la recherche d'erreurs résultant d'interactions
imprévues entre les composants et de problèmes d'interface de composants. Pour
les grands systèmes, il peut s'agir d'un processus en plusieurs étapes dans lequel les
composants sont intégrés pour former des sous-systèmes qui sont testés
individuellement avant d'être eux-mêmes intégrés pour former le système final.

• Les tests d'acceptation : Il s'agit de la dernière étape du processus de test avant

que le système ne soit accepté pour une utilisation opérationnelle. Le système est
testé avec des données fournies par le client du système plutôt qu'avec des données
de test simulées. Les tests d'acceptation peuvent révéler des erreurs et des omissions
dans la définition des exigences système, car les données réelles exercent le système
de différentes manières par rapport aux données de test. Les tests d'acceptation
peuvent également révéler des problèmes d'exigences lorsque les installations du
système ne répondent pas vraiment aux besoins de l'utilisateur ou lorsque les
performances du système sont inacceptables.

2.4. L’évolution logiciel

La flexibilité des systèmes logiciels est l'une des principales raisons pour lesquelles de
plus en plus de logiciels sont incorporés dans de grands systèmes complexes.
Contrairement aux systèmes matériels, les modifications peuvent très facilement être
apportées au logiciel à tout moment pendant ou après le développement du système.
Historiquement, il y a toujours eu une scission entre le processus de développement logiciel
et le processus d'évolution logiciel encore appelé maintenance logicielle. Des gens
considèrent le développement logiciel comme une activité créative où un système logiciel
a été développé d'un concept initial à un système opérationnel.

Cette distinction entre développement et maintenance devient de plus en plus

pertinente. Peu de systèmes logiciels sont désormais des systèmes complètement
nouveaux, et il est beaucoup plus logique de considérer le développement et la maintenance
comme un continuum. Plutôt que deux processus distincts, il est plus réaliste de penser
l’ingénierie logiciel comme un processus évolutif où le logiciel est continuellement modifié
au cours de sa durée de vie en réponse à l'évolution des exigences et des besoins des clients.

3. Les modèles de cycles de vie de développement logiciel

3.1. Le modèle en cascade

Le cycle de vie en cascade peut être utilisé lorsqu’un projet est relativement simple,
c’est-à-dire lorsqu’on a la quasi-certitude que les besoins ou exigences n’évolueront pas en
cours de projet. En pratique, une étape ne démarre que si la précédente est terminée et
validée. La nature séquentielle du modèle en cascade ne permet pas de revenir en arrière,
d'annuler ou de modifier des aspects d’une étapes du cycle de développement déjà réalisé.
Ce modèle est le mieux adapté lorsque les développeurs ont déjà conçu et développé des
logiciels similaires dans le passé et connaissent tous ses domaines.

Figure 4 : Modèle en cascade

 3.2. Le modèle incrémental

En se référant à la figure 5, le modèle incrémental ou itératif applique des séquences

linéaires de manière échelonnée au fur et à mesure que le temps du calendrier progresse.
Chaque séquence linéaire produit un « incrément » livrable du logiciel. Par exemple, un
logiciel de traitement de texte développé en utilisant le paradigme incrémental peut fournir
des fonctions de base de gestion de fichiers, d'édition et de production de documents dans
le premier incrément ; des capacités d'édition et de production de documents plus
sophistiquées dans le deuxième incrément ; vérification de l'orthographe et de la grammaire
au troisième échelon ; et capacité de mise en page avancée dans le quatrième incrément.

Lorsqu'un modèle incrémental est utilisé, le premier incrément est souvent un produit
de base. Autrement dit, les exigences de base sont satisfaites, mais de nombreuses
fonctionnalités supplémentaires (certaines connues, d'autres inconnues) ne sont pas livrées.
Le produit principal est utilisé par le client ou fait l'objet d'un examen détaillé. À la suite
de l'utilisation et / ou de l'examen, un plan est développé pour le prochain incrément. Le
plan traite de la modification du produit principal pour mieux répondre aux besoins du
client et de la fourniture de fonctionnalités et de fonctionnalités supplémentaires. Ce
processus est répété après la livraison de chaque incrément, jusqu'à ce que le produit
complet soit produit.

Figure 5 : Modèle en incrémental ou itératif

 3.3. Le modèle en V

L'inconvénient majeur du modèle de cascade est que nous ne passons à l'étape suivante
que lorsque la précédente est terminée et qu'il n'y a aucune chance de revenir en arrière si
quelque chose ne va pas dans les étapes ultérieures. Le modèle en V vient offrir une
solution à cette limite. Il fournit des moyens de tester le logiciel à chaque étape du cycle.
À chaque étape, des plans de test et des cas de test sont créés pour vérifier et valider le
produit conformément aux exigences de cette étape. Par exemple, lors de l'étape de collecte
des exigences, l'équipe de test prépare tous les cas de test en correspondance avec les
exigences. Plus tard, lorsque le produit est développé et est prêt pour les tests, les cas de
test de cette étape vérifient la validité du logiciel par rapport aux exigences à ce stade.

Figure 6 : Modèle en V
 3.4. Le modèle en spirale

Le modèle en spirale, initialement proposé par Boehm en 1988, est un modèle de

processus logiciel évolutif qui couple la nature itérative du prototypage avec les aspects
contrôlés et systématiques soit du modèle séquentiel linéaire soit modèle en V. Il offre le
potentiel de développement de versions incrémentielles du logiciel. En utilisant le modèle
en spirale, le logiciel est développé dans une série de versions incrémentielles. Au cours
des premières itérations, la version incrémentielle peut être un modèle papier ou un
prototype. Au cours des itérations ultérieures, des versions de plus en plus complètes du
système d'ingénierie sont produites.

Un modèle en spirale est divisé en un certain nombre d'activités cadre, également

appelées régions de tâches. En règle générale, il existe entre trois et six régions de tâches.
La figure 7 illustre un modèle en spirale qui contient six régions de tâches :

• Communication client - tâches requises pour établir une communication efficace

entre le développeur et le client.

• Planification : tâches requises pour définir les ressources, les délais et autres
informations relatives au projet.

• Analyse des risques - tâches requises pour évaluer les risques techniques et de
gestion.

• Ingénierie : tâches requises pour créer une ou plusieurs représentations de

l'application.

• Construction et la livraison - tâches requises pour construire, tester, installer et

fournir un soutien aux utilisateurs (documentation et formation)

• Évaluation des clients - tâches requises pour obtenir les commentaires des clients
en fonction de l'évaluation des représentations logicielles créées pendant la phase
d'ingénierie et mises en œuvre pendant la phase d'installation.
 Figure 7 : Modèle en spirale

4. Conclusion

Ce chapitre nous ayant permis dans un premier temps d’appréhender la notion de cycle
de vie de développement logiciel et de comprendre pourquoi est-ce qu’il est nécessaire de
découper le processus de développement logiciel en ensemble d’activités vérifiables et
validables, nous avons ensuite présenté les activités les est plus récurrentes du processus
de développement logiciels et pour finir, nous avons identifié et présenté les principaux
modèles génériques de cycle de vie de développement logiciel. Dans le chapitre suivant
nous avons aborderons dès lors en détail la première du cycle de développement à savoir
l’ingénierie des besoins logiciels.