GÉNIE LOGICIEL
A.U. 2020-2021
(SUPPORT DE COURS)
CSCI 260B
UNIVERSITÉ LIBANAISE INTERNATIONALE
MOUSTAPHA MOHAMED SALECK
2
Chapitre III
Les modèles du système
3
1. Modèle en cascade
Le modèle en cascade, ou « waterfall » en anglais, est une
organisation des activités d'un projet sous forme de phases linéaires
et séquentielles, où chaque phase correspond à une spécialisation des
tâches et dépend des résultats de la phase précédente. Il comprend les
phases d'exigences, de conception, de mise en œuvre et de mise en
service.
Chaque phase ne commence qu'une fois les résultats de la phase
précédente validés. Le point fort de cette approche est de garantir
l'existence d'une documentation bien structurée. précédentes en cas
de défauts découverts en aval.
4
1. Modèle en cascade
5
1. Modèle en cascade
Vérification de chaque phase avant de passer à la suivante
Production de documents (délivrables) à l'issue de chaque phase
Chaque phase doit pouvoir nécessairement renvoyer à la phase
précédente en cas de défauts constatés en aval (par exemple, en cas
d'erreur découverte lors des tests, il est nécessaire de retourner à la
phase de programmation)
les exigences et la conception influent sur toutes les phases en aval, de
sorte qu'un retour à ces étapes est souvent nécessaire. Il recommande
enfin le recours à une conception préliminaire. Son modèle révisé reste
toutefois proche au modèle original.
6
1. Modèle en cascade
Le modèle en cascade se base sur des exigences exprimées en début de
projet. Toutefois les exigences et besoins peuvent se montrer
incomplets ou de qualité insuffisante (ambiguïté, incohérence, etc.)
le client peut ne pas être pleinement conscient de ses exigences avant
d'avoir vu le logiciel fonctionner. Ceci peut conduire à revoir la
conception, redévelopper un partie du logiciel, et retester le produit et
donc augmenter les coûts
7
2. Modèle en «V»
Le modèle en V (« V model » ou « Vee model » en anglais) est un
modèle d'organisation des activités d'un projet qui se caractérise par
un flux d'activité descendant qui détaille le produit jusqu'à sa
réalisation, et un flux ascendant, qui assemble le produit en vérifiant
sa qualité. Ce modèle est issu du modèle en cascade dont il reprend
l'approche séquentielle et linéaire de phases.
Il confronte les différents niveaux de test avec les phases de projet
de même niveau. Ceci permet à chaque étape de définir non
seulement les fonctions, mais également les critères de validation.
8
2. Modèle en «V»
9
2. Modèle en «V»
Quand utiliser le cycle V dans la gestion de projet ?
• On peut utiliser le cycle en V dans un projet dont le cahier des charges
ne change pas en cours de route. Par exemple dans des projets lancés à
partir d’un appel d’offres où le client a documenté ses exigences très
clairement.
• Pour choisir le cycle en V comme méthode de gestion d’un projet
logiciel à utiliser, il est recommandé que les conditions suivantes sont
remplies, du moins la majorité :
- La qualité finale du projet est importante
- Les exigences doivent être claires et figées.
10
2. Modèle en «V»
- La technologie choisie pour la réalisation est maîtrisée et déjà
utilisée par l’équipe de développeurs dans le cadre de différents
projets.
- Le projet ne peut pas être réalisé de manière itérative.
- Le coût de développement du projet est défini et fixe.
Les avantages du cycle en V :
• Simple et facile à utiliser.
• Chaque phase a des résultats spécifiques mesurables.
• Les chances de réussite sont plus élevées que pour la méthode en cascade
grâce à l’élaboration d’un plan de test dès le début du cycle de
développement.
11
2. Modèle en «V»
• Fonctionne bien quand les exigences du projet sont facilement
compréhensibles.
• Le cycle en V améliore la qualité et la fiabilité d’un logiciel.
• Il réduit le nombre de retouches grâce à la détection précoce des
défauts (bugs) et des problèmes.
• Il permet une meilleure gestion des risques liés au projet.
• La vérification et la validation du produit dans les premières étapes
du développement garantissent une meilleure qualité.
• Le concept de cycle en V peut être combiné avec d’autres méthodes
de gestion de projet, par exemple la méthode agile ou itérative.
12
3. Modèle en Spiral
le cycle en spirale reprend les étapes du cycle en V, mais prévoit
l’implémentation de versions successives, ce qui permet de mettre
l’accent sur la gestion des risques, la première phase de chaque
itération étant dédiée à ce poste. A ce point il est nécessaire de définir
la notion de prototype.
En effet, on ne fait pas des versions successives d’un même produit
fini, corriger une liste de bugs permet de passer de la béta à la finale
mais pas de la v1 à la v2… Le cycle en spirale prévoit donc la
livraison de prototypes, c’est à dire de versions incomplètes du
produit. Il peut s’agir d’une simple maquette ou même
des wireframes sans aucune fonctionnalité
13
3. Modèle en Spiral
14
3. Modèle en Spiral
Avantages du modèle en spirale :
• Le but premier de ce modèle étant la gestion des risques, ceux-ci
sont logiquement limités.
• L’expertise du client croit à chaque itération du cycle,
l’apprentissage se fait par touche et pas d’un seul bloc.
• Enfin, ce modèle est très adaptatif : si chaque prototype apporte des
fonctionnalités indépendantes, il est possible de changer l’ordre de
livraison des versions.
15
3. Modèle en Spiral
Inconvénients du modèle en spirale :
• le principal défaut du cycle en spirale c’est qu’il n’est adapté qu’aux
projets suffisamment gros, inutile de prévoir la livraison de 5 ou 6
prototypes pour un site vitrine sous WordPress (même si on peut
considérer qu’une maquette puis le site en lui-même constituent 2
cycles complets).
• De plus l’évaluation des risques en elle-même et la stricte application
du cycle de développement peut engendrer plus de coûts que la
réalisation du logiciel. Enfin, ce type de cycle de développement est
complexe, entre les étapes prévues en théorie et celles mises en
pratique il y a une grande différence.
16
4. Modèle itératif
Simplifions un peu le modèle précédent en réduisant le nombre d’étapes du
cycle et séparons les activités des artéfacts (c’est à dire les produits issus de ces
activités). Nous arrivons logiquement au modèle itératif, que vous pouvez voir
ci-dessous.
17
4. Modèle itératif
Avantages du modèle itératif :
• Ce type de cycle de développement est le plus souple de tous ceux
présentés ici : chaque itération permet de s’adapter à ce qui a été
appris dans les itérations précédentes et le projet fini peut varier du
besoin qui a été exprimé à l’origine.
• Comme dans le cycle en spirale, la mise à disposition de livrables à
chaque cycle permet un apprentissage de l’utilisateur final en
douceur.
18
4. Modèle itératif
Inconvénients du modèle itératif :
• le plus gros piège de ce modèle de développement c’est la confiance
qui amène bien souvent à négliger les test d’intégration.
• Ainsi les développeurs livrent une nouvelle fonctionnalité sans se
rendre compte qu’ils ont cassé une chose qui fonctionnait dans les
cycles précédents. Il faut donc que le chef de projet soit
particulièrement vigilant lors de la phase de tests.
19
5. Méthode Agile
En février 2001, les instigateurs des principales méthodes agiles
forment l’Agile Alliance. Leur réflexion aboutit au "Manifesto for
Agile Software development" qui définit 4 valeurs… :
Priorité aux personnes et aux interactions
sur les procédures et les outils
Priorité aux applications fonctionnelles sur
une documentation pléthorique
Priorité de la collaboration avec le client
sur la négociation de contrat
Priorité de l’acceptation du changement sur
la planification
20
5. Méthode Agile
Pas de grande rupture : les méthodes traditionnelles ne sont pas et ne
doivent pas être abandonnées
Elles doivent être peu à peu transformées pour prendre en compte le
signal fort envoyé par le taux d’échec important des projets
informatiques
Toutes pratiques agiles ne sont pas forcément adaptables à tout type
de projet
Lors du démarrage d’un projet, il s’agit donc de définir quelles sont
les pratiques que l’on souhaite appliquer en ayant à l’esprit leur
plus-value pour le projet considéré
