Cycle de Développement du
Logiciel
Realisé par :
CHADAD ABDELMAJID
Université Hassan II Mohammedia Casablanca
Ecole Normal...
Méthodes Agiles
▪ Les méthodes agiles sont des groupes de pratiques de projets de développement en informatique
(conception de logiciel), ...
En Bref :
Les méthodes agiles se définissent comme des méthodes de
développement de logiciel qui permettent de réduire les...
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,...
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...
7. L’unité de mesure de la progression du projet est un logiciel fonctionnel (ce qui exclut de
comptabiliser les fonctions...
Exemples de méthodes Agiles
▪ Scrum
▪ RAD (Rapid Application Development)
▪ RUP ()
▪ DSDM (Dynamic systems development met...
eXtrem Programming
est une méthode agile plus particulièrement orientée sur l'aspect réalisation d'une application,
sans p...
Cycle de développement
▪ L'Extreme Programming repose sur des cycles rapides de développement (des itérations
de quelques ...
Unified Process
Processus unifié (PU ou UP en anglais pour Unified Process) est une méthode de
développement pour les logi...
Principes
▪ Le Processus Unifié (UP) est piloté par les cas d’utilisation (eux même guidés par les
risques) centré sur l’a...
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...
Recette
Codage et Tests
Conception
détaillées
Conception
préliminaire
Conception
Générique
Capture des
besoins
Technique
A...
▪ Du coté de la branche fonctionnelle :
- Capture des besoins fonctionnels : elle aboutit à un modèle des besoins focalisé...
Une forme en Y
branche fonctionnelle
- Capture des besoins
fonctionnels : elle aboutit à un
modèle des besoins focalisé
su...
Apport de modèle en Y
Capitalisation de la
connaissance de
l’entreprise
investissement
pour le moyen et
long terme
Capital...
Apport de modèle en Y
▪ Branche gauche : elle capitalise les connaissances de l’entreprise et représente donc un
investiss...
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 q...
Définition de
besoin brut
Conception de
haute niveau
Vérification des
flux logiques
Maquette
Spécification
Conception du
s...
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 . P...
Inconvénient de Modèle en W
▪ Modèle simplifié la réalité des faits. En pratique, il existe plusieurs relations
entre les ...
Cycle de développement du logiciel
Cycle de développement du logiciel
Prochain SlideShare
Chargement dans…5
×

Cycle de développement du logiciel

338 vues

Publié le

Cycle de développement du logiciel

Publié dans : Logiciels
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
338
Sur SlideShare
0
Issues des intégrations
0
Intégrations
6
Actions
Partages
0
Téléchargements
10
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Cycle de développement du logiciel

  1. 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. 2. Méthodes Agiles
  3. 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. 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. 5. Valeurs des Méthodes agiles Les méthodes agiles prônent 4 valeurs fondamentales
  6. 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. 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. 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. 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. 10. Exemples de méthodes Agiles ▪ Scrum ▪ RAD (Rapid Application Development) ▪ RUP () ▪ DSDM (Dynamic systems development method) ▪ XP (Extreme programming)
  11. 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. 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. 13. 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
  14. 14. 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
  15. 15. Modèle en Y
  16. 16. 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
  17. 17. 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
  18. 18. ▪ 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é
  19. 19. 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
  20. 20. 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
  21. 21. 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.
  22. 22. Modèle en W
  23. 23. 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
  24. 24. 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
  25. 25. 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
  26. 26. 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

×