23/12/2023

MODÈLES DE CYCLE DE VIE Pr. A. DARGHAM

CLASSIQUES
 23/12/2023

LE MODÈLE EN TUNNEL
Manière imagée de désigner l’absence de tout processus de
développement.
Appelé aussi modèle « code and fixe ».
Le développement est en cours, les gens travaillent, mais
aucune information fiable n’est disponible, ni sur l’état
d’avancement du projet, ni sur la qualité des éléments déjà
développés  adapté pour des petits efforts, avec un nombre
très limité de participants.

LE MODÈLE EN CASCADE
L’un des premiers modèles de cycle de vie logiciel.
Proposé par Royce en 1970 et aussi appelé « modèle linéaire »
 modèle académique par excellence qui a été largement
adopté depuis.
Le résultat de chaque phase est un ensemble de livrables.
Une phase ne peut démarrer que si la précédente est finie.
Il suit l’approche « une fois par étape, chaque étape une fois
».
 23/12/2023

LE MODÈLE EN CASCADE
De manière simple, dans le modèle en cascade :
On détermine les besoins des utilisateurs.
On définit les exigences.
On conçoit le système.
On implémente le système.
On le teste.
On corrige ses erreurs.
On livre le système.
 23/12/2023

LE MODÈLE EN CASCADE

LE MODÈLE EN CASCADE
Le modèle en cascade présente le développement de logiciel
comme une suite de phase qui s’enchaînent dans un
déroulement linéaire.
Le développement en cascade est rythmé par la génération de
documents qui servent de support tangible pour les revues de
validation du passage d’une phase à une autre.
 23/12/2023

LE MODÈLE EN CASCADE
Avantages :
Modèle bien défini, bien structuré et bien étudié.
Facile à utiliser, à comprendre, à planifier et à contrôler.
De nombreux outils de gestion le prennent en charge.
Idéal pour la gestion et le suivi projets.
Efficace lorsque la qualité est plus importante que les coûts et
les délais.
Une bonne documentation du processus.

LE MODÈLE EN CASCADE
Inconvénients :
La plupart (sinon la totalité) des exigences doivent être
connues dès le départ  or les besoins des clients sont très
rarement stables et clairement définis.
Ne s’adapte pas facilement aux changements d’exigences : le
modèle est très sensible aux changements de besoins  refaire
tout le procédé.
Le produit n’est pas disponible pour une utilisation initiale
tant que le projet n’est pas presque terminé.
 23/12/2023

LE MODÈLE EN CASCADE
Inconvénients :
Les risques se décalent vers la fin.
Très faible implication du client.

LE MODÈLE EN CASCADE
Quand est-ce que le modèle est plus approprié ? :
Le projet est similaire à d’autres déjà réalisés avec succès.
Les exigences sont assez stables et bien comprises.
La conception et la technologie sont éprouvées et matures.
La durée du projet est relativement courte.
Le client n’a pas besoin de versions intermédiaires.
 23/12/2023

VARIANTES DU MODÈLE EN CASCADE

Modèle en cascade séquentiel :
Une phase ne débute qu’après la fin de la phase qui la
précède.
Modèle en cascade avec phases superposées :
Une phase peut commencer même si la phase qui la
précède est encore en cours.
Modèle multi-cascades :
On effectue séquentiellement plusieurs fois une cascade.
 23/12/2023

LE MODÈLE EN V
Variante très populaire du modèle en cascade qui fait
l’accent sur la vérification et la validation.
Le modèle en V décompose le cycle de vie linéaire en
deux branches parallèles :
La branche de gauche contient les phases d’analyse des
besoins, de conception et du codage.
La branche de droite contient les phases de tests
fonctionnels, de tests d’intégration et de tests unitaires.

LE MODÈLE EN V
Chaque phase dans la branche de gauche sera vérifiée et
validée par une phase de test dans la branche de droite.
L’enchaînement des phases peut être graphiquement
représenté par la lettre « V », d’où le nom du modèle.
 23/12/2023

LE MODÈLE EN V

LE MODÈLE EN V
Le modèle en V est basé sur un enchaînement de phases
autonomes mettant en correspondance le moment où un
besoin s’exprime et le moment où ce besoin est
approuvable et validable.
Au cours de ce cycle, les étapes liées à l’analyse/conception
du système sont mises en place dans une approche
descendante alors que les étapes de vérification et de
validation sont réalisées dans une approche ascendante.
 23/12/2023

LE MODÈLE EN V
Les tests de composants contrôlent la conception des
composants.
Les tests du système contrôlent la conception du système.
La validation fonctionnelle vérifie les spécifications.
La validation des besoins vérifie l’expression des besoins.

LE MODÈLE EN V
Avantages :
Met l’accent sur la vérification et la validation  ce qui
permet d’accroître la qualité du logiciel.
Facile à planifier dans une gestion de projets.
Facile à utiliser.
Chaque livrable doit être vérifiable et validable.
Permet de tester ce qui devait être fait et non ce qui a été
fait.
 23/12/2023

LE MODÈLE EN V
Inconvénients :
Ne gère pas explicitement les changements des
spécifications.
Ne contient pas d’activités d’analyse de risque.

LE MODÈLE EN V
Quand l’utiliser ?
Quand le produit à développer a de très hautes exigences
de qualité.
Quand les besoins sont connus à l’avance.
Quand les technologies à utiliser sont bien maîtrisées.
 23/12/2023

LE MODÈLE ITÉRATIF
Le logiciel est développé en plusieurs étapes itératives, toutes
planifiées et contrôlées.
Chaque étape itérative comprend les activités caractéristiques :
analyse, conception, codage, test.
Chaque étape itérative corrige et améliore le système existant
en fonction des défauts détectés lors de l’utilisation.
Les versions itératives sont internes  non publiées en
externe.
La version itérative finale est le produit complet.
 23/12/2023

LE MODÈLE ITÉRATIF

PROCESSUS ITÉRATIF
 23/12/2023

LE MODÈLE ITÉRATIF
La plupart des projets comportent au moins 3 itérations avant
une sortie publique finale (mais il peut y avoir plus).
Dans les méthodes itératives modernes, la durée recommandée
d’une itération est comprise entre 1 et 6 semaines.
Le logiciel résultant de chaque itération n’est pas un prototype,
mais un sous-ensemble du système final.

LE MODÈLE ITÉRATIF
 23/12/2023

LE MODÈLE ITÉRATIF
Les modèles itératifs favorisent une combinaison de priorités
basées sur les risques et sur les clients.
Le modèle itératif basé sur les risques sélectionne les
éléments les plus risqués et les plus difficiles pour les
premières itérations.
De cette manière, les risques les plus élevés sont détectés et
atténués le plus tôt possible.
Le modèle itératif basé sur le client implique que le choix des
fonctionnalités pour la prochaine itération émane du client.

LE MODÈLE ITÉRATIF
De cette manière, le client pilote le projet, itération par
itération, en demandant les fonctionnalités qu’il juge
actuellement les plus utiles.
L’application des deux approches est très utile :
Les clients n’apprécient pas toujours ce qui est techniquement
difficile ou risqué.
En revanche, les développeurs n’apprécient pas toujours ce
qui a une grande valeur commerciale.
 23/12/2023

LE MODÈLE ITÉRATIF
Les modèles itératifs utilisent le concept de timeboxing.
Il consiste à fixer la date de fin de l’itération et à la respecter
strictement.
S’il apparaît finalement que les demandes choisies pour
l’itération ne peuvent pas être satisfaites dans le délai imparti,
alors la portée est réduite (en remettant les demandes de priorité
inférieure sur la liste de souhaits), afin que le système partiel en
croissance se termine toujours dans un état stable et testé à la
date de fin d’itération initialement prévue.

LE MODÈLE ITÉRATIF
 23/12/2023

AVANTAGES
Permet une validation régulière avec le client de l’avancée.
L’équipe est motivée et le client pilote le projet.
Facile de modifier les demandes futures.
Facile d’ajouter des fonctionnalités.
Tiens en compte les risques.

INCONVÉNIENTS
Pas toujours possible à mettre en place.
Demande plus d’attention et d’implication de l’ensemble des
acteurs du projet.
Il doit être compris par tous : clients, utilisateurs,
développeurs, testeurs, documentalistes.
Tous doivent organiser leur travail en conséquence.
 23/12/2023

QUAND L’UTILISER ?
Lorsque les exigences sont définies clairement et faciles à
comprendre.
Lorsque l’application logicielle est volumineuse.
Lorsqu’il y a une nécessité de changements à l’avenir.
 23/12/2023

LE MODÈLE PAR PROTOTYPAGE

En général, un prototype est le tout premier exemplaire ou le
modèle d’un produit.
En génie logiciel, un prototype logiciel est un modèle d’un
logiciel à réaliser.
Son objectif est d’exposer les fonctionnalités du futur logiciel
à son client.

LE MODÈLE PAR PROTOTYPAGE

Un prototype logiciel servira donc à deux choses :
Pour le client, c’est un moyen concret pour évaluer le futur
logiciel.
Pour l’équipe de développement, c’est un moyen pour tester
les fonctions d’usage et repérer les failles du logiciel.
 23/12/2023

LE MODÈLE PAR PROTOTYPAGE

Le modèle par prototypage (ou modèle évolutif) est un modèle
itératif orienté essais/erreurs et basé sur l’évolution de prototypes
exécutables.
À chaque itération, un livrable (prototype) est fournit (au lieu de
documents dans les modèles en cascade).
Le prototype est évalué par le client qui donne son feedback et
l’équipe adapte le prototype selon les besoins du client.
Quand le prototype satisfait le client, le code est normalisé selon les
standards et les bonnes pratiques.

PROCESSUS PAR PROTOTYPAGE

 23/12/2023

AVANTAGES
Le client a une idée concrète du système avant son achèvement.
Le client est placé devant des situations d’utilisation concrètes qui
lui permettent de mieux structurer ses besoins et de les
communiquer à l’équipe de développement.
Le client s’implique activement dans le processus de
développement.
Le client est partenaire du projet et prend sa part de
responsabilité dans le nouveau système.

AVANTAGES
La probabilité de produire un système acceptable est grande.
L’équipe de développement est plus fortement motivé du fait
de la proximité de l’objectif et de l’interaction avec le client.
 23/12/2023

INCONVÉNIENTS
Processus très lent et coûteux (les outils de prototypage sont un
peu chers).
Le système est mal documenté.
Le système peut avoir de sérieux problèmes d’intégration.
Le système a une forte probabilité d’être difficile à maintenir.
Le prototypage implique un code faiblement structuré.
Aucune garantie que le processus s’arrête toujours.
Processus très difficile à planifier.

QUAND L’UTILISER ?
Quand les besoins sont instables et/ou nécessitent des
clarifications.
Peut être utilisé avec le modèle en cascade pour l’élicitation des
besoins.
Quand des livraisons rapides sont exigées.
 23/12/2023

LE MODÈLE INCRÉMENTAL
Le développement du logiciel est réalisé par étapes d’expansion.
La première étape est le système de base.
Chaque étape d’expansion étend le système existant et fait l’objet
d’un projet distinct  incrément.
Un incrément du logiciel est un sous-ensemble du logiciel
complet, qui consiste en un petit nombre de fonctionnalités.
Chaque incrément est une construction partielle du logiciel.
 23/12/2023

PROCESSUS INCRÉMENTAL

LE MODÈLE INCRÉMENTAL
Dans le modèle incrémental, on trie les spécifications par priorités et
on les regroupe dans des groupes de spécifications.
Chaque incrément implémente un ou plusieurs groupes jusqu’à ce
que la totalité du produit soit finie.
Dans un premier temps un logiciel noyau est développé, puis
successivement, les incréments sont développés et intégrés.
Chaque incrément est développé selon l’un des modèles de cycle de
vie.
 23/12/2023

AVANTAGES
Développement de fonctionnalités à risque en premier.
Chaque incrément donne un produit fonctionnel.
Possibilité de livraisons et de mises en service après chaque
incrément.
Utilise l’approche « diviser pour régner », ce qui permet de réduire
la complexité de développement logiciel.
Les intégrations sont progressives.
L’effort est constant dans le temps par opposition au pic pour
spécifications détaillées pour les modèles en cascade ou en V.

INCONVÉNIENTS
Exige une bonne planification et une bonne conception.
Exige une vision sur le produit fini pour pouvoir le diviser en
incréments.
La remise en cause du noyau de départ ou des incréments
précédents peut entraîner l’échec du projet.
Possibilité d’avoir des problèmes d’intégration.
Le coût total du système peut être très élevé.
 23/12/2023

QUAND L’UTILISER ?
Quand la plupart des spécifications sont connues à l’avance et
vont être sujettes à de faibles évolutions.
Quand on veut rapidement un produit fonctionnel.
Pour des projets de longues durées.
Pour des projets impliquant de nouvelles technologies.
 23/12/2023

LE MODÈLE EN SPIRAL
Le modèle de développement en spirale a été proposé en 1988
par Boehm.
C’est un modèle itératif incrémental qui met l’accent sur la
gestion des risques et le prototypage.
Il fournit des incréments sous forme de cycles.
À la fin de chaque cycle, on détermine les objectifs du cycle
suivant.
Chaque cycle est composé des mêmes activités que du modèle
en cascade.

LE MODÈLE EN SPIRAL
Le modèle en spirale s’inscrit dans une relation contractuelle
entre le client et le fournisseur.
De ce fait les engagements et les validations présentent un
caractère formalisé.
Chaque cycle donne lieu à une contractualisation préalable,
s’appuyant sur les besoins exprimés lors du cycle précédent.
 23/12/2023

PROCESSUS EN SPIRALE

PHASES D’UN CYCLE EN SPIRALE

Chaque cycle du processus en spirale se déroule en 4 phases :
Détermination des objectifs.
Analyse des risques.
Développement & tests.
Planification de la prochaine itération.
 23/12/2023

DÉTERMINATION DES OBJECTIFS

Détermination des objectifs (en terme de fonctionnalités, de
performances, de coûts ...etc).
Enumération des différentes manières possibles de parvenir à
ces objectifs, ainsi que les contraintes (coûts, plannings).
Évaluation des alternatives en fonction de l’objectif :
développer, réutiliser, acheter, sous-traiter, …etc.

ANALYSE DES RISQUES

Identification des risques : technologie non maîtrisées, équipe
peu expérimentée, planning trop serré, …etc.
Evaluation des risques : voir si les risques peuvent impacter le
projet et à quel degré.
 23/12/2023

DÉVELOPPEMENT & TESTS

Choix d’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 peut être le plus 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 l’ensemble d’un système  le modèle de
la spirale englobe tous les autres modèles.

PLANIFICATION DE LA PROCHAINE
ITÉRATION
Un planning de l’itération.
Un plan de tests.
 23/12/2023

PROCESSUS EN SPIRALE

PRINCIPAUX RISQUES
Défaillance de personnel  embauche de haut niveau, formation
mutuelle, leaders, adéquation profil/fonction, ...
Calendrier & budgets irréalistes  estimation détaillée,
développement incrémental, réutilisation, élagage des besoins, ...
Développement de fonctions inappropriées  revues
d’utilisateurs, manuel d’utilisation précoce, ...
Développement d’interfaces utilisateurs inappropriées 
maquettage, analyse des tâches, …
Volatilité des besoins  développement incrémental de la partie la
plus stable d’abord, masquage d’information, ...
 23/12/2023

PRINCIPAUX RISQUES
Problèmes de performances  simulations, modélisations, essais
et mesures, maquettage, …
Exigences démesurées par rapport à la technologie  analyses
techniques de faisabilité, maquettage, ...
Tâches ou composants externes défaillants  audit des sous-
traitants, contrats, revues, analyse de compatibilité, essais et
mesures, ...

AVANTAGES
Prise de décision anticipée de l’inaccessibilité du projet.
Identification rapide et anticipée des risques.
Savoir que les plus gros risques sont éliminés donne un bon
sentiment  motivation de l’équipe.
Impacts minimaux des risques sur le projet.
Fonctions critiques développées en premier.
Feedback rapide du client.
Une évaluation continue du procédé.
 23/12/2023

INCONVÉNIENTS
L’évaluation des risques peut prendre beaucoup de temps.
Le modèle est très complexe.
La spirale peut s’éterniser.
Les développeurs doivent être réaffectés pendant les phases de
non-développement.
Les objectifs ne sont pas souvent faciles à formuler.

QUAND L’UTILISER ?
Quand le risque du projet est considérable.
Quand le prototypage est exigé.
Quand les spécifications ne sont pas stables.
Pour les nouveaux produits.
Quand le projet implique de la recherche et de l’investigation.
 23/12/2023

RUP : RATIONAL UNIFIED PROCESS

RUP : Rational Unified Process.
Démarche de développement qui est souvent utilisé
conjointement au langage UML.
RUP est :
Piloté par les cas d’utilisation.
Centré sur l’architecture.
Itératif & incrémental.
 23/12/2023

RUP EST ITÉRATIF & INCRÉMENTAL

Chaque itération prend en compte un certain nombre de cas
d’utilisation.
Les risques majeurs sont traités en priorité.
Chaque itération donne lieu à un incrément et produit une
nouvelle version exécutable.

RUP EST PILOTÉ PAR LES CAS

D’UTILISATION
La principale qualité d’un logiciel est son utilité :
Adéquation du service rendu par le logiciel avec les besoins des
utilisateurs.
Le développement d’un logiciel doit être centré sur l’utilisateur.
Les cas d’utilisation permettent d’exprimer ces besoins :
Détection et description des besoins fonctionnels.
Organisation des besoins fonctionnels.
 23/12/2023

RUP EST CENTRÉ SUR L’ARCHITECTURE

La modélisation du système sous plusieurs perspectives
indépendantes et complémentaires.
Architecture en couches et vues.

RUP EST CENTRÉ SUR L’ARCHITECTURE

 23/12/2023

VUES DU SYSTÈME
Vue cas d’utilisation :
Description du système comme un ensemble de transactions du
point de vue de l’utilisateur.
Vue logique :
Créée lors de la phase d’élaboration et raffinée lors de la phase
de construction.
Utilisation de diagrammes de classes, de séquences, ...

VUES DU SYSTÈME
Vue composants :
Description de l’architecture logicielle.
Vue déploiement :
Description de l’architecture matérielle du système.
Vue implémentation :
Description des algorithmes, code source.
 23/12/2023

ORGANISATION EN PHASES DU
DÉVELOPPEMENT
Initialisation :
Définition du problème.
Elaboration :
Planification des activités, affectation des ressources, analyse.
Construction :
Développement du logiciel par incréments successifs.
Transition :
Recettage et déploiement.