SlideShare une entreprise Scribd logo
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
Méthodes Agiles
▪ 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
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,
Valeurs des Méthodes agiles
Les méthodes agiles prônent 4 valeurs fondamentales
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.
Principes des Méthodes agiles
les 4 valeurs se déclinent en 12 principes généraux communs à toutes les méthodes
agiles
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.
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)
Exemples de méthodes Agiles
▪ Scrum
▪ RAD (Rapid Application Development)
▪ RUP ()
▪ DSDM (Dynamic systems development method)
▪ XP (Extreme programming)
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.
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).
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
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
Modèle en Y
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
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
▪ 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é
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
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
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.
Modèle en W
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
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
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
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

Contenu connexe

Tendances

TD4-UML-Correction
TD4-UML-CorrectionTD4-UML-Correction
TD4-UML-Correction
Lilia Sfaxi
 
cycle de vie
cycle de vie cycle de vie
cycle de vie
Shili Mohamed
 
Méthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiquesMéthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiquesSirine Barguaoui
 
Support soutenance PFE 11 juillet 2016 - EMSI - SIEMENS - Université de Borde...
Support soutenance PFE 11 juillet 2016 - EMSI - SIEMENS - Université de Borde...Support soutenance PFE 11 juillet 2016 - EMSI - SIEMENS - Université de Borde...
Support soutenance PFE 11 juillet 2016 - EMSI - SIEMENS - Université de Borde...
Soufiane KALLIDA
 
UML Part 3- diagramme de séquences mansouri
UML Part 3- diagramme de séquences mansouriUML Part 3- diagramme de séquences mansouri
UML Part 3- diagramme de séquences mansouri
Mansouri Khalifa
 
gestion de magasin vente matériels informatique
gestion de magasin vente matériels informatiquegestion de magasin vente matériels informatique
gestion de magasin vente matériels informatiqueOussama Yoshiki
 
Méthodes agiles: Scrum et XP
Méthodes agiles: Scrum et XPMéthodes agiles: Scrum et XP
Méthodes agiles: Scrum et XP
Youness Boukouchi
 
UML : Diagrammes de cas d'utilisation -- modele detaille -- 15
UML : Diagrammes de cas d'utilisation -- modele detaille -- 15UML : Diagrammes de cas d'utilisation -- modele detaille -- 15
UML : Diagrammes de cas d'utilisation -- modele detaille -- 15
megaplanet20
 
Chp1 - Introduction à l'AGL
Chp1 - Introduction à l'AGLChp1 - Introduction à l'AGL
Chp1 - Introduction à l'AGL
Lilia Sfaxi
 
TD1-UML-correction
TD1-UML-correctionTD1-UML-correction
TD1-UML-correction
Lilia Sfaxi
 
Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016
Erradi Mohamed
 
Présentation PFE : Mise en place d’une solution de gestion intégrée (OpenERP...
Présentation PFE :  Mise en place d’une solution de gestion intégrée (OpenERP...Présentation PFE :  Mise en place d’une solution de gestion intégrée (OpenERP...
Présentation PFE : Mise en place d’une solution de gestion intégrée (OpenERP...
Mohamed Cherkaoui
 
Methodes de gestion de projets - introduction au processus unifié
Methodes de gestion de projets - introduction au processus unifiéMethodes de gestion de projets - introduction au processus unifié
Methodes de gestion de projets - introduction au processus unifié
Mireille Blay-Fornarino
 
Metrique
MetriqueMetrique
Metrique
Amine AOUNZOU
 
Diagramme d'activité en UML
Diagramme d'activité en UMLDiagramme d'activité en UML
Diagramme d'activité en UML
Mireille Blay-Fornarino
 
Chp4 - Diagramme de Séquence
Chp4 - Diagramme de SéquenceChp4 - Diagramme de Séquence
Chp4 - Diagramme de Séquence
Lilia Sfaxi
 
2.2 cycles de vie
2.2 cycles de vie2.2 cycles de vie
2.2 cycles de vieHarun Mouad
 
TD2 - UML - Correction
TD2 - UML - CorrectionTD2 - UML - Correction
TD2 - UML - Correction
Lilia Sfaxi
 
Uml 2 pratique de la modélisation
Uml 2  pratique de la modélisationUml 2  pratique de la modélisation
Uml 2 pratique de la modélisation
Nassim Amine
 

Tendances (20)

TD4-UML-Correction
TD4-UML-CorrectionTD4-UML-Correction
TD4-UML-Correction
 
cycle de vie
cycle de vie cycle de vie
cycle de vie
 
Méthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiquesMéthodes agiles vs méthodes classiques
Méthodes agiles vs méthodes classiques
 
Support soutenance PFE 11 juillet 2016 - EMSI - SIEMENS - Université de Borde...
Support soutenance PFE 11 juillet 2016 - EMSI - SIEMENS - Université de Borde...Support soutenance PFE 11 juillet 2016 - EMSI - SIEMENS - Université de Borde...
Support soutenance PFE 11 juillet 2016 - EMSI - SIEMENS - Université de Borde...
 
UML Part 3- diagramme de séquences mansouri
UML Part 3- diagramme de séquences mansouriUML Part 3- diagramme de séquences mansouri
UML Part 3- diagramme de séquences mansouri
 
gestion de magasin vente matériels informatique
gestion de magasin vente matériels informatiquegestion de magasin vente matériels informatique
gestion de magasin vente matériels informatique
 
Méthodes agiles: Scrum et XP
Méthodes agiles: Scrum et XPMéthodes agiles: Scrum et XP
Méthodes agiles: Scrum et XP
 
UML : Diagrammes de cas d'utilisation -- modele detaille -- 15
UML : Diagrammes de cas d'utilisation -- modele detaille -- 15UML : Diagrammes de cas d'utilisation -- modele detaille -- 15
UML : Diagrammes de cas d'utilisation -- modele detaille -- 15
 
CM processus-unifie
CM processus-unifieCM processus-unifie
CM processus-unifie
 
Chp1 - Introduction à l'AGL
Chp1 - Introduction à l'AGLChp1 - Introduction à l'AGL
Chp1 - Introduction à l'AGL
 
TD1-UML-correction
TD1-UML-correctionTD1-UML-correction
TD1-UML-correction
 
Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016
 
Présentation PFE : Mise en place d’une solution de gestion intégrée (OpenERP...
Présentation PFE :  Mise en place d’une solution de gestion intégrée (OpenERP...Présentation PFE :  Mise en place d’une solution de gestion intégrée (OpenERP...
Présentation PFE : Mise en place d’une solution de gestion intégrée (OpenERP...
 
Methodes de gestion de projets - introduction au processus unifié
Methodes de gestion de projets - introduction au processus unifiéMethodes de gestion de projets - introduction au processus unifié
Methodes de gestion de projets - introduction au processus unifié
 
Metrique
MetriqueMetrique
Metrique
 
Diagramme d'activité en UML
Diagramme d'activité en UMLDiagramme d'activité en UML
Diagramme d'activité en UML
 
Chp4 - Diagramme de Séquence
Chp4 - Diagramme de SéquenceChp4 - Diagramme de Séquence
Chp4 - Diagramme de Séquence
 
2.2 cycles de vie
2.2 cycles de vie2.2 cycles de vie
2.2 cycles de vie
 
TD2 - UML - Correction
TD2 - UML - CorrectionTD2 - UML - Correction
TD2 - UML - Correction
 
Uml 2 pratique de la modélisation
Uml 2  pratique de la modélisationUml 2  pratique de la modélisation
Uml 2 pratique de la modélisation
 

Similaire à Cycle de développement du logiciel

Management de projet (agilité et design thinking)
Management de projet (agilité et design thinking)Management de projet (agilité et design thinking)
Management de projet (agilité et design thinking)
David VALLAT
 
Management de projet 2
Management de projet 2Management de projet 2
Management de projet 2
David VALLAT
 
Agilité et les méthodes agiles - Synthèse Synertal
Agilité et les méthodes agiles - Synthèse SynertalAgilité et les méthodes agiles - Synthèse Synertal
Agilité et les méthodes agiles - Synthèse Synertal
Claude Emond
 
Méthodes agile
Méthodes agileMéthodes agile
Méthodes agile
ISSAE Cnam Liban
 
Gestion de projet #2 : méthodes
Gestion de projet #2 : méthodesGestion de projet #2 : méthodes
Gestion de projet #2 : méthodes
Jean Michel
 
Aborder la transition vers l'agilité
Aborder la transition vers l'agilitéAborder la transition vers l'agilité
Aborder la transition vers l'agilité
Christophe Addinquy
 
Les méthodes Agiles - Introduction
Les méthodes Agiles - IntroductionLes méthodes Agiles - Introduction
Les méthodes Agiles - Introduction
Tremeur Balbous
 
conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...
Sid Ahmed Benkraoua
 
Prototype rapport
Prototype rapportPrototype rapport
Prototype rapport
Ines Ouaz
 
ppt sur la Méthode Agile (adaptative).pdf
ppt sur la Méthode Agile (adaptative).pdfppt sur la Méthode Agile (adaptative).pdf
ppt sur la Méthode Agile (adaptative).pdf
imenhamada17
 
Methodes agiles-rad-xp-477-noy52y
Methodes agiles-rad-xp-477-noy52yMethodes agiles-rad-xp-477-noy52y
Methodes agiles-rad-xp-477-noy52y
jesmien CH
 
Expression des besoins pour le SI
Expression des besoins pour le SIExpression des besoins pour le SI
Expression des besoins pour le SI
Nouhaila ALAMI
 
12 agile
12 agile12 agile
12 agile
MiisterSifdin1
 
Rad
RadRad
ERP, Pret A Implanter Mode D’Emploi Cours 10
ERP, Pret A Implanter  Mode D’Emploi Cours 10ERP, Pret A Implanter  Mode D’Emploi Cours 10
ERP, Pret A Implanter Mode D’Emploi Cours 10
jeandescoteaux
 
Formation Agile Scrum
Formation Agile ScrumFormation Agile Scrum
Formation Agile Scrum
Mohamed IBN ELAZZOUZI
 
Réussir son analyse des besoins dans la conduite d'un projet informatique (2007)
Réussir son analyse des besoins dans la conduite d'un projet informatique (2007)Réussir son analyse des besoins dans la conduite d'un projet informatique (2007)
Réussir son analyse des besoins dans la conduite d'un projet informatique (2007)
Ardesi Midi-Pyrénées
 
Methode Agile
Methode Agile Methode Agile
Methode Agile
JEAN-GUILLAUME DUJARDIN
 

Similaire à Cycle de développement du logiciel (20)

Management de projet (agilité et design thinking)
Management de projet (agilité et design thinking)Management de projet (agilité et design thinking)
Management de projet (agilité et design thinking)
 
Management de projet 2
Management de projet 2Management de projet 2
Management de projet 2
 
Agilité et les méthodes agiles - Synthèse Synertal
Agilité et les méthodes agiles - Synthèse SynertalAgilité et les méthodes agiles - Synthèse Synertal
Agilité et les méthodes agiles - Synthèse Synertal
 
Méthodes agile
Méthodes agileMéthodes agile
Méthodes agile
 
Gestion de projet #2 : méthodes
Gestion de projet #2 : méthodesGestion de projet #2 : méthodes
Gestion de projet #2 : méthodes
 
Aborder la transition vers l'agilité
Aborder la transition vers l'agilitéAborder la transition vers l'agilité
Aborder la transition vers l'agilité
 
Lecon 1.1
Lecon 1.1Lecon 1.1
Lecon 1.1
 
Les méthodes Agiles - Introduction
Les méthodes Agiles - IntroductionLes méthodes Agiles - Introduction
Les méthodes Agiles - Introduction
 
conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...
 
Prototype rapport
Prototype rapportPrototype rapport
Prototype rapport
 
ppt sur la Méthode Agile (adaptative).pdf
ppt sur la Méthode Agile (adaptative).pdfppt sur la Méthode Agile (adaptative).pdf
ppt sur la Méthode Agile (adaptative).pdf
 
Methodes agiles-rad-xp-477-noy52y
Methodes agiles-rad-xp-477-noy52yMethodes agiles-rad-xp-477-noy52y
Methodes agiles-rad-xp-477-noy52y
 
Expression des besoins pour le SI
Expression des besoins pour le SIExpression des besoins pour le SI
Expression des besoins pour le SI
 
CM processus agile
CM processus agileCM processus agile
CM processus agile
 
12 agile
12 agile12 agile
12 agile
 
Rad
RadRad
Rad
 
ERP, Pret A Implanter Mode D’Emploi Cours 10
ERP, Pret A Implanter  Mode D’Emploi Cours 10ERP, Pret A Implanter  Mode D’Emploi Cours 10
ERP, Pret A Implanter Mode D’Emploi Cours 10
 
Formation Agile Scrum
Formation Agile ScrumFormation Agile Scrum
Formation Agile Scrum
 
Réussir son analyse des besoins dans la conduite d'un projet informatique (2007)
Réussir son analyse des besoins dans la conduite d'un projet informatique (2007)Réussir son analyse des besoins dans la conduite d'un projet informatique (2007)
Réussir son analyse des besoins dans la conduite d'un projet informatique (2007)
 
Methode Agile
Methode Agile Methode Agile
Methode Agile
 

Plus de Majid CHADAD

What is docker
What is dockerWhat is docker
What is docker
Majid CHADAD
 
Sauvegarder bases donnes sur lecteur réseau
Sauvegarder bases donnes sur lecteur réseauSauvegarder bases donnes sur lecteur réseau
Sauvegarder bases donnes sur lecteur réseau
Majid CHADAD
 
Présentation Exchange 2010
Présentation Exchange 2010Présentation Exchange 2010
Présentation Exchange 2010
Majid CHADAD
 
Rapport MS Exchange 2010
Rapport MS Exchange 2010Rapport MS Exchange 2010
Rapport MS Exchange 2010
Majid CHADAD
 
Uml examen
Uml  examenUml  examen
Uml examen
Majid CHADAD
 
Gl examen
Gl  examenGl  examen
Gl examen
Majid CHADAD
 
Hirens boot Remove Windows Password
Hirens boot Remove Windows PasswordHirens boot Remove Windows Password
Hirens boot Remove Windows Password
Majid CHADAD
 
Plan de sauvegarde automatique sous sql server
Plan de sauvegarde automatique sous sql serverPlan de sauvegarde automatique sous sql server
Plan de sauvegarde automatique sous sql server
Majid CHADAD
 
Rémuneration
RémunerationRémuneration
Rémuneration
Majid CHADAD
 
Virtualisation
VirtualisationVirtualisation
Virtualisation
Majid CHADAD
 
Installation apache mandriva
Installation apache mandrivaInstallation apache mandriva
Installation apache mandriva
Majid CHADAD
 
Système RAID
Système RAIDSystème RAID
Système RAID
Majid CHADAD
 
Attaque metasploite
Attaque metasploiteAttaque metasploite
Attaque metasploite
Majid CHADAD
 
PostgreSQL
PostgreSQLPostgreSQL
PostgreSQL
Majid CHADAD
 
Merise+ +exercices+mcd+-+corrigés
Merise+ +exercices+mcd+-+corrigésMerise+ +exercices+mcd+-+corrigés
Merise+ +exercices+mcd+-+corrigésMajid CHADAD
 

Plus de Majid CHADAD (15)

What is docker
What is dockerWhat is docker
What is docker
 
Sauvegarder bases donnes sur lecteur réseau
Sauvegarder bases donnes sur lecteur réseauSauvegarder bases donnes sur lecteur réseau
Sauvegarder bases donnes sur lecteur réseau
 
Présentation Exchange 2010
Présentation Exchange 2010Présentation Exchange 2010
Présentation Exchange 2010
 
Rapport MS Exchange 2010
Rapport MS Exchange 2010Rapport MS Exchange 2010
Rapport MS Exchange 2010
 
Uml examen
Uml  examenUml  examen
Uml examen
 
Gl examen
Gl  examenGl  examen
Gl examen
 
Hirens boot Remove Windows Password
Hirens boot Remove Windows PasswordHirens boot Remove Windows Password
Hirens boot Remove Windows Password
 
Plan de sauvegarde automatique sous sql server
Plan de sauvegarde automatique sous sql serverPlan de sauvegarde automatique sous sql server
Plan de sauvegarde automatique sous sql server
 
Rémuneration
RémunerationRémuneration
Rémuneration
 
Virtualisation
VirtualisationVirtualisation
Virtualisation
 
Installation apache mandriva
Installation apache mandrivaInstallation apache mandriva
Installation apache mandriva
 
Système RAID
Système RAIDSystème RAID
Système RAID
 
Attaque metasploite
Attaque metasploiteAttaque metasploite
Attaque metasploite
 
PostgreSQL
PostgreSQLPostgreSQL
PostgreSQL
 
Merise+ +exercices+mcd+-+corrigés
Merise+ +exercices+mcd+-+corrigésMerise+ +exercices+mcd+-+corrigés
Merise+ +exercices+mcd+-+corrigés
 

Cycle de développement du logiciel

  • 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
  • 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).
  • 13.
  • 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
  • 16.
  • 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.
  • 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