1. Cycle de Développement du
Logiciel
Realisé par :
CHADAD ABDELMAJID
Université Hassan II Mohammedia Casablanca
Ecole Normale Supérieure de l’Enseignement Technique
ENSET – Mohammedia
Département Mathématiques Informatique
Cycle d’ingénieur Génie du Logiciel et Système Informatique
Distribuées

2. Méthodes Agiles

3. ▪ Les méthodes agiles sont des groupes de pratiques de projets de développement en informatique
(conception de logiciel), pouvant s'appliquer à divers types de projets. Elles ont pour dénominateur
commun l'Agile manifesto. Rédigé en 2001, celui ci consacre le terme d'« agile » pour référencer de
multiple méthodes existantes. Les méthodes agiles se veulent plus pragmatiques que les méthodes
traditionnelles. Elles impliquent au maximum le demandeur (client) et permettent une grande
réactivité à ses demandes. Elles visent la satisfaction réelle du client en priorité aux termes d'un
contrat de développement.
▪ Les méthodes agiles reposent sur une structure (cycle de développement) commune (itérative,
incrémentale et adaptative), quatre valeurs communes déclinées en douze principes communs
desquels découlent une base de pratiques, soit communes, soit complémentaires.
▪ Un mouvement plus large (management agile) couple les valeurs agiles aux techniques de
l'amélioration continue de la qualité (plus particulièrement le Lean). On constate un élargissement
de l'utilisation d'agile à l'ensemble de la structure de l'entreprise

4. En Bref :
Les méthodes agiles se définissent comme des méthodes de
développement de logiciel qui permettent de réduire les risques d’échec,
produire le résultat attendue et de livres des systèmes logiciels de qualité
dans les meilleures délais, pour ceci ces méthodes en plus de la
différentes personnes intervenant dans le projet,

5. Valeurs des Méthodes agiles
Les méthodes agiles prônent 4 valeurs fondamentales

6. Valeurs
▪ L'équipe (« Les individus et leurs interactions, plus que les processus et les outils ») : dans l'optique
agile, l'équipe est bien plus importante que les outils (structurants ou de contrôle) ou les procédures
de fonctionnement. Il est préférable d'avoir une équipe soudée et qui communique, composée de
développeurs (éventuellement à niveaux variables), plutôt qu'une équipe composée d'experts
fonctionnant chacun de manière isolée. La communication est une notion fondamentale.
▪ L'application (« Des logiciels opérationnels, plus qu'une documentation exhaustive ») : il est vital
que l'application fonctionne. Le reste, et notamment la documentation technique, est une aide
précieuse mais non un but en soi. Une documentation précise est utile comme moyen de
communication. La documentation représente une charge de travail importante, mais peut pourtant
être néfaste si elle n'est pas à jour. Il est préférable de commenter abondamment le code lui-même,
et surtout de transférer les compétences au sein de l'équipe (on en revient à l'importance de la
communication).
▪ La collaboration (« La collaboration avec les clients, plus que la négociation contractuelle ») : le
client doit être impliqué dans le développement. On ne peut se contenter de négocier un contrat au
début du projet, puis de négliger les demandes du client. Le client doit collaborer avec l'équipe et
fournir un feed-back continu sur l'adaptation du logiciel à ses attentes.
▪ L'acceptation du changement (« L'adaptation au changement, plus que le suivi d'un plan ») : la
planification initiale et la structure du logiciel doivent être flexibles afin de permettre l'évolution de
la demande du client tout au long du projet. Les premières livraisons du logiciel vont souvent
provoquer des demandes d'évolution.

7. Principes des Méthodes agiles
les 4 valeurs se déclinent en 12 principes généraux communs à toutes les méthodes
agiles

8. Principes
1. La plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement
des fonctionnalités à forte valeur ajoutée.
2. Le changement est accepté, même tardivement dans le développement, car les
processus agiles exploitent le changement comme avantage compétitif pour le client.
3. La livraison s’applique à une application fonctionnelle, toutes les deux semaines à
deux mois, avec une préférence pour la période la plus courte.
4. Le métier et les développeurs doivent collaborer régulièrement et de préférence
quotidiennement au projet.
5. Le projet doit impliquer des personnes motivées. Donnez-leur l'environnement et le
soutien dont elles ont besoin et faites leur confiance quant au respect des objectifs.
6. La méthode la plus efficace de transmettre l'information est une conversation en face à
face.

9. 7. L’unité de mesure de la progression du projet est un logiciel fonctionnel (ce qui exclut de
comptabiliser les fonctions non formellement achevées).
8. Les processus agiles promeuvent un rythme de développement soutenable (afin d’éviter la non
qualité découlant de la fatigue).
9. Les processus agiles recommandent une attention continue à l'excellence technique et à la qualité
de la conception.
10. La simplicité et l'art de minimiser les tâches parasites, sont appliqués comme principes
essentiels.
11. Les équipes s'auto-organisent afin de faire émerger les meilleures architectures, spécifications et
conceptions.
12. À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et
ajuste son processus de travail en conséquence
Principes (suite)

10. Exemples de méthodes Agiles
▪ Scrum
▪ RAD (Rapid Application Development)
▪ RUP ()
▪ DSDM (Dynamic systems development method)
▪ XP (Extreme programming)

11. eXtrem Programming
est une méthode agile plus particulièrement orientée sur l'aspect réalisation d'une application,
sans pour autant négliger l'aspect gestion de projet. XP est adapté aux équipes réduites avec des
besoins changeants. XP pousse à l'extrême des principes simples.

12. Cycle de développement
▪ L'Extreme Programming repose sur des cycles rapides de développement (des itérations
de quelques semaines) dont les étapes sont les suivantes :
▪ une phase d'exploration détermine les scénarios client qui seront fournis pendant cette
itération
▪ l'équipe transforme les scénarios en tâches à réaliser et en tests fonctionnels
▪ chaque développeur s'attribue des tâches et les réalise avec un binôme
▪ lorsque tous les tests fonctionnels passent, le produit est livré
▪ Le cycle se répète tant que le client peut fournir des scénarios à livrer. Généralement le
cycle de la première livraison se caractérise par sa durée et le volume important de
fonctionnalités embarquées. Après la première mise en production, les itérations peuvent
devenir plus courtes (une semaine par exemple).

14. Unified Process
Processus unifié (PU ou UP en anglais pour Unified Process) est une méthode de
développement pour les logiciels orientés objets. C’est une méthode générique, itérative
et incrémentale, contrairement à la méthode séquentielle Merise

15. Principes
▪ Le Processus Unifié (UP) est piloté par les cas d’utilisation (eux même guidés par les
risques) centré sur l’architecture, itératif et incrémental.
Le projet sera donc mené selon les besoins et les exigences (fonctionnelles et non
fonctionnelles) : points d’entrée sur lesquels l’analyse des risques va principalement
s’exercer pour organiser les plans d’itération.
▪ Les risques majeurs (souvent liés à l’architecture) seront traités en premier lieu dans le but
de les lever au plus tôt: gestion et pilotage par les risques, de vrais points forts pour la
méthode.
Le Processus Unifié est opposé au cycle de vie en cascade (ou séquentiel) trop figé et
rigide, et se lit selon deux axes: vertical (enchainement de disciplines et d’activités au sein
d’une itération) et horizontal (enchainement dynamique sur l’axe temporel de phases et
d’itérations). On va donc par exemple, tester à chaque itération sans attendre la fin du
projet

17. Modèle en Y

18. Idée de base est: toute évolution imposée au
SI peut se décomposer et se traiter
parallèlement, suivant 2 axes (« 2 tracks ») :
Un axe fonctionnel
Un axe technique
La réalisation du système consiste à
fusionner les résultats des deux branches

19. Recette
Codage et Tests
Conception
détaillées
Conception
préliminaire
Conception
Générique
Capture des
besoins
Technique
Analyse
Capture des
besoins
Fonctionnels
Contraints
fonctionnelles
Contraints
Techniques
Prototype
Branche Fonctionnel Branche Technique

20. ▪ Du coté de la branche fonctionnelle :
- Capture des besoins fonctionnels : elle aboutit à un modèle des besoins focalisé sur le métier des utilisateurs. Elle
minimise le risque de produire un système inadéquat avec les besoins des utilisateurs. De cette capture, la MOE
consolide les spécifications et en vérifie la cohérence et l’exhaustivité.
-Analyse : étude des spécifications afin de savoir ce que le système va réellement réaliser en termes de métier. Découpage
en composants.
Du coté de la branche technique :
-Capture des besoins techniques : recensement des outils, des matériels et des technologies à utiliser ; des contraintes
(temps de réponse maximal, contraintes d’intégration avec l’existant) -> tout cela va aboutir à une première conception
de l’architecture technique
-Conception générique : Découpage en composants nécessaires à la construction de l’architecture technique. Il est
généralement conseillé de réaliser un prototype pour assurer la validité de l’architecture.
Cette étape permet de minimiser l’incapacité de l’architecture technique à répondre aux contraintes opérationnelles
Enfin, la branche du milieu :
-Conception préliminaire : étape délicate durant laquelle on intègre le modèle d’analyse dans l’architecture technique. Le
but ici est de savoir dans quel composant technique on met nos fonctionnalités issues de l’analyse.
-Conception détaillée : conception de chaque fonctionnalité
-Etape de codage : phase de programmation de ces fonctionnalités, avec des tests au fur et à mesure
-Etape de recette : phase de validation des fonctions du système développé

21. Une forme en Y
branche fonctionnelle
- Capture des besoins
fonctionnels : elle aboutit à un
modèle des besoins focalisé
sur le métier des utilisateurs.
Elle minimise le risque de
produire un système
inadéquat avec les besoins des
utilisateurs. De cette capture,
la MOE consolide les
spécifications et en vérifie la
cohérence et l’exhaustivité.
-Analyse : étude des
spécifications afin de savoir ce
que le système va réellement
réaliser en termes de métier.
Découpage en composants.
branche du milieu
-Conception préliminaire : étape délicate
durant laquelle on intègre le modèle
d’analyse dans l’architecture
technique. Le but ici est de savoir dans
quel composant technique on met nos
fonctionnalités issues de l’analyse.
-Conception détaillée : conception de
chaque fonctionnalité
-Etape de codage : phase de
programmation de ces fonctionnalités,
avec des tests au fur et à mesure
-Etape de recette : phase de validation
des fonctions du système développé
branche technique
-Capture des besoins techniques :
recensement des outils, des matériels et
des technologies à utiliser ; des
contraintes (temps de réponse maximal,
contraintes d’intégration avec l’existant)
-> tout cela va aboutir à une première
conception de l’architecture technique
-Conception générique : Découpage en
composants nécessaires à la
construction de l’architecture technique.
Il est généralement conseillé de réaliser
un prototype pour assurer la validité de
l’architecture.
Cette étape permet de minimiser
l’incapacité de l’architecture technique à
répondre aux contraintes opérationnelles

22. Apport de modèle en Y
Capitalisation de la
connaissance de
l’entreprise
investissement
pour le moyen et
long terme
Capitalisation
d’un savoir-faire
technique
investissement
pour le court et
moyen terme

23. Apport de modèle en Y
▪ Branche gauche : elle capitalise les connaissances de l’entreprise et représente donc un
investissement pour le moyen et long terme. Les fonctionnalités du SI sont en effet
indépendantes des technologies utilisées.
▪ Branche droit : elle capitalise le savoir-faire technique de l’entreprise et représente donc un
investissement pour le court et moyen terme. Les techniques développées pour le système
peuvent l’être de manière indépendante des fonctions à réaliser
▪ Le modèle en Y apporte une réponse aux contraintes de changement continuel imposées aux SI
de l’entreprise :
- Changement de technologies : en effet, une entreprise qui maintiendrait son modèle fonctionnel
peut le réaliser sous différentes technologies : il suffit de « greffer » une nouvelle architecture
technique pour mettre à jour un système existant.
-Ajout de fonctionnalités : en effet, on peut réutiliser une architecture technique
▪ Pour résumer, il permet à la fois de capitaliser la connaissance métier sur la branche gauche et de
réutiliser un savoir-faire technique sur la branche droite. En d’autres termes, un meilleur
contrôle sur les capacités d’évolution et de correction de tels systèmes.

24. Modèle en W

25. Paul Herzlich introduit l'approche modèle W en 1993 . Le modèle W tente de combler
les lacunes dans le modèle V . Plutôt que de se concentrer sur les étapes spécifiques de
l'essai dynamique , comme le modèle V fait , le modèle W se concentre sur les produits
de développement eux-mêmes . Essentiellement , toutes les activités de développement
qui donne un produit de travail est « ombre » par une activité de test . Le but de
l'activité de test est précisément de déterminer si les objectifs d'une activité de
développement ont été atteints et le livrable répond à ses exigences . Dans sa forme la
plus générique , le modèle W présente un cycle de développement standard avec
chaque étape de développement reflétée par une activité de test . Sur le côté gauche ,
en général , les résultats attendus d'une activité de développement (par exemple ,
écrire exigences ) est accompagnée par une activité de test " tester les exigences " et
ainsi de suite . Si une organisation a un ensemble différent de stades de développement
, le modèle W est facilement adapté à la situation. La chose importante est la suivante:
le modèle W de test se concentre spécifiquement sur les risques liés aux produits de
préoccupation à l'endroit où le test peut être plus efficace

26. Définition de
besoin brut
Conception de
haute niveau
Vérification des
flux logiques
Maquette
Spécification
Conception du
système
Conception du
composant
Code du
composant
Test du
composant
Test du système
Test d’
acceptation

27. Avantages de Modèle en W
▪ Dans le modèle W l'importance des tests et l'ordre des activités pour les tests sont
clairs . Parallèlement au processus de développement , dans un sens plus strict , un
autre processus - le processus de test - est effectuée . Ce n'est pas la première a
commencé après le développement est terminé .
▪ La division stricte entre les tâches constructives sur le côté gauche et les tâches les
plus destructeurs sur le côté droit qui existe dans le modèle en V est abolie . Dans le
modèle W , il est clair qu'une telle division entre les tâches n'est pas raisonnable et
que la coopération plus étroite entre les activités de développement et de test doit
exister. Dès le début du projet et suivants les testeurs et les développeurs sont
chargés de missions et sont considérés comme un partenariat d'égalité des droits .
Au cours de la phase de test, le développeur est responsable de l'élimination des
défauts et la correction de la mise en œuvre . La collaboration précoce et la
coopération étroite entre les deux groupes peuvent souvent en pratique éviter les
réunions de conflit .
▪ Le modèle W se rapproche de la pratique où les dépenses d'essai est donnée à 40% et
plus . Le modèle met clairement en évidence le fait que le test est plus que juste la
construction , l'exécution et l'évaluation des cas de test

28. Inconvénient de Modèle en W
▪ Modèle simplifié la réalité des faits. En pratique, il existe plusieurs relations
entre les différentes parties d'un processus de développement. Cependant, il est
nécessaire pour un modèle simple si toutes les personnes impliquées dans un
projet de les accepter. C'est aussi une raison pour laquelle le V-modèle simple si
souvent utilisé dans la pratique.
▪ Les modèles de développement de logiciels présentées ne précisent pas les
dépenses nécessaires pour les ressources qui doivent être affectées aux activités
individuelles. Toujours dans le W-modèle, il semble que les différentes activités
ont une exigence égale pour les ressources (temps, personnel, etc ) Dans la
pratique, ce n'est certainement pas le cas. Dans chaque projet aspects les plus
importants peuvent varier et ainsi donc l'allocation des ressources est peu
susceptible d'être égale dans toutes les activités. Pour les applications très
critiques les activités de test ont certainement pondération supérieure ou au
moins égale pondération avec d'autres activités