SlideShare une entreprise Scribd logo

Processus_Unifie_et_Approche_Agile chapitre 1.pptx

sdfgh

1  sur  88
Télécharger pour lire hors ligne
Processus Unifié et Approche
Agile
Introduction
Processus Unifié
Approche Agile
Processus Unifié et Approche
Agile
Introduction
Processus Unifié
Approche Agile
1. Génie Logiciel
2. Un logiciel de qualité
3. Projet logiciel
4. Cycle de vie d’un logiciel
5. Méthode et Processus
6. UML (rappel)
7. Conclusion
3
Génie Logiciel
4
 Ensemble de méthodes, techniques et outils pour
la conception, la production et la maintenance de
systèmes informatiques complexes.
 Ces méthodes connaissent, au même titre que les
technologies mises en œuvre une évolution
permanente.
 Elles sont incluses dans un domaine des sciences
de l’ingénieur (formalisation, séparation de
problèmes, modularité, abstraction, prévision des
changements, etc.)
Un logiciel de qualité
5
 La crise du logiciel des années 70 est provoquée
par :
 l'impossibilité de maîtriser la sureté des logiciels
(pannes nombreuses)
 l'inflation des délais de développement
 De bonnes techniques de développement logiciel
deviennent nécessaires.
 facteurs externes
 facteurs internes
Un logiciel de qualité
6
 Utilité :
 Utilisabilité :
 Robustesse (fiabilité) :
 Extensibilité :
 Compatibilité :
 Efficacité :
 Intégrité (sécurité) :
Publicité

Recommandé

Contenu connexe

Similaire à Processus_Unifie_et_Approche_Agile chapitre 1.pptx

sûreté de fonctionnement du logiciel
 sûreté de fonctionnement du logiciel sûreté de fonctionnement du logiciel
sûreté de fonctionnement du logicielEs-sahli bilal
 
1_Assurance_Qualit_et_Gnie_Logiciel.ppt
1_Assurance_Qualit_et_Gnie_Logiciel.ppt1_Assurance_Qualit_et_Gnie_Logiciel.ppt
1_Assurance_Qualit_et_Gnie_Logiciel.ppthbadir
 
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
 
Cours1_Architecture_Logicielle.ppt
Cours1_Architecture_Logicielle.pptCours1_Architecture_Logicielle.ppt
Cours1_Architecture_Logicielle.pptSylia3
 
UML Part1-Introduction Mansouri
UML Part1-Introduction MansouriUML Part1-Introduction Mansouri
UML Part1-Introduction MansouriMansouri Khalifa
 
Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Erradi Mohamed
 
Chp1 - Introduction à l'AGL
Chp1 - Introduction à l'AGLChp1 - Introduction à l'AGL
Chp1 - Introduction à l'AGLLilia Sfaxi
 
2.2 cycles de vie
2.2 cycles de vie2.2 cycles de vie
2.2 cycles de vieHarun Mouad
 
Architecture logicielle #1 : introduction
Architecture logicielle #1 : introductionArchitecture logicielle #1 : introduction
Architecture logicielle #1 : introductionJean Michel
 
Prototype rapport
Prototype rapportPrototype rapport
Prototype rapportInes Ouaz
 
Cycle de développement du logiciel
Cycle de développement du logicielCycle de développement du logiciel
Cycle de développement du logicielMajid CHADAD
 
NightClazz Build Tools & Continuous Delivery
NightClazz Build Tools & Continuous DeliveryNightClazz Build Tools & Continuous Delivery
NightClazz Build Tools & Continuous DeliveryZenika
 
qualité logicielle (8).pdf
qualité logicielle (8).pdfqualité logicielle (8).pdf
qualité logicielle (8).pdfNoamHaythem
 
les metriques de processus, de produit et de qualité
les metriques de processus, de produit et de qualitéles metriques de processus, de produit et de qualité
les metriques de processus, de produit et de qualitésoregh
 
E-business - développement
E-business - développementE-business - développement
E-business - développementManon Cuylits
 
Gl slides-cours-1
Gl slides-cours-1Gl slides-cours-1
Gl slides-cours-1Sami Neili
 

Similaire à Processus_Unifie_et_Approche_Agile chapitre 1.pptx (20)

Lecon 1.1
Lecon 1.1Lecon 1.1
Lecon 1.1
 
GL
GLGL
GL
 
sûreté de fonctionnement du logiciel
 sûreté de fonctionnement du logiciel sûreté de fonctionnement du logiciel
sûreté de fonctionnement du logiciel
 
1_Assurance_Qualit_et_Gnie_Logiciel.ppt
1_Assurance_Qualit_et_Gnie_Logiciel.ppt1_Assurance_Qualit_et_Gnie_Logiciel.ppt
1_Assurance_Qualit_et_Gnie_Logiciel.ppt
 
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...
 
Cours1_Architecture_Logicielle.ppt
Cours1_Architecture_Logicielle.pptCours1_Architecture_Logicielle.ppt
Cours1_Architecture_Logicielle.ppt
 
UML Part1-Introduction Mansouri
UML Part1-Introduction MansouriUML Part1-Introduction Mansouri
UML Part1-Introduction Mansouri
 
Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016
 
Chp1 - Introduction à l'AGL
Chp1 - Introduction à l'AGLChp1 - Introduction à l'AGL
Chp1 - Introduction à l'AGL
 
CM processus-unifie
CM processus-unifieCM processus-unifie
CM processus-unifie
 
2.2 cycles de vie
2.2 cycles de vie2.2 cycles de vie
2.2 cycles de vie
 
Architecture logicielle #1 : introduction
Architecture logicielle #1 : introductionArchitecture logicielle #1 : introduction
Architecture logicielle #1 : introduction
 
Prototype rapport
Prototype rapportPrototype rapport
Prototype rapport
 
Cycle de développement du logiciel
Cycle de développement du logicielCycle de développement du logiciel
Cycle de développement du logiciel
 
NightClazz Build Tools & Continuous Delivery
NightClazz Build Tools & Continuous DeliveryNightClazz Build Tools & Continuous Delivery
NightClazz Build Tools & Continuous Delivery
 
Fichier récupéré 1
Fichier récupéré 1Fichier récupéré 1
Fichier récupéré 1
 
qualité logicielle (8).pdf
qualité logicielle (8).pdfqualité logicielle (8).pdf
qualité logicielle (8).pdf
 
les metriques de processus, de produit et de qualité
les metriques de processus, de produit et de qualitéles metriques de processus, de produit et de qualité
les metriques de processus, de produit et de qualité
 
E-business - développement
E-business - développementE-business - développement
E-business - développement
 
Gl slides-cours-1
Gl slides-cours-1Gl slides-cours-1
Gl slides-cours-1
 

Plus de informatiquehageryah (13)

Cours-Intelligence-artificielle-55.pdf
Cours-Intelligence-artificielle-55.pdfCours-Intelligence-artificielle-55.pdf
Cours-Intelligence-artificielle-55.pdf
 
cours1-2-vision-bklog.pdf
cours1-2-vision-bklog.pdfcours1-2-vision-bklog.pdf
cours1-2-vision-bklog.pdf
 
chapitre 1 SI.pdf
chapitre 1 SI.pdfchapitre 1 SI.pdf
chapitre 1 SI.pdf
 
Fortinet [Enregistrement automatique].pptx
Fortinet [Enregistrement automatique].pptxFortinet [Enregistrement automatique].pptx
Fortinet [Enregistrement automatique].pptx
 
fortinet et sécurité.pdf
fortinet et sécurité.pdffortinet et sécurité.pdf
fortinet et sécurité.pdf
 
01-introduction.ppt
01-introduction.ppt01-introduction.ppt
01-introduction.ppt
 
Plan_GE_22_06.docx
Plan_GE_22_06.docxPlan_GE_22_06.docx
Plan_GE_22_06.docx
 
Algebre-de-Boole-et-Simplifications.pdf
Algebre-de-Boole-et-Simplifications.pdfAlgebre-de-Boole-et-Simplifications.pdf
Algebre-de-Boole-et-Simplifications.pdf
 
architecture des calculateurs (2).pdf
architecture des calculateurs (2).pdfarchitecture des calculateurs (2).pdf
architecture des calculateurs (2).pdf
 
c4.pdf
c4.pdfc4.pdf
c4.pdf
 
c5.pdf
c5.pdfc5.pdf
c5.pdf
 
c2.pdf
c2.pdfc2.pdf
c2.pdf
 
c1.pdf
c1.pdfc1.pdf
c1.pdf
 

Processus_Unifie_et_Approche_Agile chapitre 1.pptx

  • 1. Processus Unifié et Approche Agile Introduction Processus Unifié Approche Agile
  • 2. Processus Unifié et Approche Agile Introduction Processus Unifié Approche Agile
  • 3. 1. Génie Logiciel 2. Un logiciel de qualité 3. Projet logiciel 4. Cycle de vie d’un logiciel 5. Méthode et Processus 6. UML (rappel) 7. Conclusion 3
  • 4. Génie Logiciel 4  Ensemble de méthodes, techniques et outils pour la conception, la production et la maintenance de systèmes informatiques complexes.  Ces méthodes connaissent, au même titre que les technologies mises en œuvre une évolution permanente.  Elles sont incluses dans un domaine des sciences de l’ingénieur (formalisation, séparation de problèmes, modularité, abstraction, prévision des changements, etc.)
  • 5. Un logiciel de qualité 5  La crise du logiciel des années 70 est provoquée par :  l'impossibilité de maîtriser la sureté des logiciels (pannes nombreuses)  l'inflation des délais de développement  De bonnes techniques de développement logiciel deviennent nécessaires.  facteurs externes  facteurs internes
  • 6. Un logiciel de qualité 6  Utilité :  Utilisabilité :  Robustesse (fiabilité) :  Extensibilité :  Compatibilité :  Efficacité :  Intégrité (sécurité) :
  • 7. Un logiciel de qualité 7  Utilité : le logiciel doit correspondre aux besoins des utilisateurs,  Utilisabilité : facilité d'apprentissage et d'utilisation,  Robustesse (fiabilité) : aptitude à fonctionner dans des conditions non prévues au cahier des charges, dysfonctionnement du logiciel,  Extensibilité : facilité avec laquelle de nouvelles fonctionnalités peuvent être ajoutées .
  • 8. Un logiciel de qualité 8  Compatibilité : facilité avec laquelle un logiciel peut être combiné avec d’autres,  Efficacité : utilisation optimale des ressources matérielles (processeur, mémoires, équipements réseau,…),  Intégrité (sécurité) : aptitude d’un logiciel à se protéger contre des accès non autorisés.
  • 9. Un logiciel de qualité 9  Re-utilisabilité :  Vérifiabilité :  Portabilité :  Lisibilité et Modularité
  • 10. Un logiciel de qualité 10  Re-utilisabilité : aptitude d’un réutilisé, en tout ou en partie, logiciel à être pour d’autres aptitude d’un logiciel à être testé applications,  Vérifiabilité : (optimisation de la préparation et de la vérification des jeux de tests),  Portabilité : aptitude d’un logiciel à être transféré dans des environnements logiciels et matériels différents,  Lisibilité et Modularité
  • 11. Projet logiciel 11  Un projet est un ensemble d’actions effectuées par des personnes morales ou physique pour atteindre un objectif, limité par une date, possédant un coût.  Conduite et direction du projet :  Organisation méthodologique,  Gestion des personnes impliquées,  Gestion technique,  Gestion de moyens, etc.
  • 12. Projet logiciel 12  Capture des besoins:  Conception:  Réalisation :  Validation :  Maintenance :
  • 13. Projet logiciel 13  Capture des besoins: réalisation du cahier des charges, spécifications fonctionnelles et non fonctionnelles des besoins,  Conception: architecture du logiciel, modèles de conception,  Réalisation : implémentation du code  Validation : intégration et déploiement et j’aurais un logiciel livrable,  Maintenance.
  • 14. Projet logiciel Comment piloter un projet de développement comportant ces étapes ? 14
  • 15. Cycle de vie d’un logiciel 15  Toutes les phases de développement du logiciel, de l'établissement des besoins du client jusqu'à l'achèvement du logiciel en tant que produit commercial.  Ces phases sont organisées selon des modèles qui permettent de guider l’ingénieur dans ses activités.  Modèles linéaires (en cascade, …)  Modèles non linéaires (spirale, itératif,…)
  • 16. Cycle de vie d’un logiciel (modèle en cascade) Analyse et spécification des besoins Conception Implémentation Test Livraison et maintenance  Linéaire, flot descendant.  Retour limité à une phase en amont.  Validation des phases par des revues. 16
  • 17. Cycle de vie d’un logiciel (modèle en cascade) Analyse et spécification des besoins Conception Implémentation Test Livraison et maintenance  Délais longs pour voir quelque chose qui tourne.  Test de l’application globale uniquement à la fin.  Difficulté de définir tous les besoins au début du projet. 17
  • 18. Cycle de vie d’un logiciel (modèle en V) 18
  • 19. Cycle de vie d’un logiciel 19 (Problèmes et solutions - modèles linéaires)  Une anomalie détectée dans une phase aval de la cascade peut remettre en cause des travaux validés.  La levée tardive des facteurs à risques.  Non prise en compte de l’évolution des besoins pendant le cycle.  Modèle théoriquement parfait, mais inadapté aux humains.
  • 20. Cycle de vie d’un logiciel (Problèmes et solutions - modèles linéaires)  Utilisés seulement quand les exigences sont bien connues et non sujettes à modification.  Encore assez populaires et souvent utilisés par les non spécialistes. 20
  • 21. Cycle de vie d’un logiciel (modèle en spirale) 21
  • 22. Méthode et Processus 22  Une méthode est une démarche reproductible permettant d’obtenir des solutions fiables à un problème donné.  En GL, on trouve des méthodes:  de développement  de conduite de projet  d’assurance et de contrôle qualité  etc.
  • 23. Méthode et Processus 23  Un processus définit qui fait quoi à quel moment et de quelle façon pour atteindre un certain objectif.  Un processus fournit les directives nécessaires pour le développement d’un logiciel de qualité.  Un processus implique la présence des clients, utilisateurs, développeurs et responsables.  Un processus suit l’évolution (des technologies, des outils, des ressources, etc)
  • 24. Méthode et Processus 24  Deux approches méthodologiques du développement de logiciels sont en concurrence :  L’approche fonctionnelle ou classique (1970)  Analyse fonctionnelle hiérarchique,  Liée à la programmation structurée.  L’approche orientée objets (1990)  Approche avec grande cohérence (données/traitements),  Lier le monde des objets au monde de l’application ,  Encapsulation, abstraction, réutilisation, modularité, extensibilité, etc.
  • 26. UML (rappel)  UML (Unified Modeling Language ou langage unifié de modélisation) est un langage graphique destiné à la modélisation de systèmes et de processus[1].  Méthode: comment utiliser le langage de modélisation (recueil des besoins, analyse, conception, mise en œuvre, validation, ...) [1] Fien VAN DER HEYDE Laurent DEBRAUWER 26
  • 27. UML (rappel) UML Structuration Comportement Relation Diagramme Cas d’utilisation, classe, composant, … Groupement Package, modèle , sous-système… 27 interaction, machine d ’états… Association, dépendance, génération… De Cas d’utilisation, de séquence, de classes, d’activité, de déploiement, …
  • 29. UML (rappel)  Les cas d’utilisation servent de fil conducteur pour l’ensemble du projet. 29
  • 40. UML (rappel) 40  UML n'est qu'un langage de modélisation et non une méthodologie à part entière.  UML définit des notations utiles dans toutes les étapes du développement d'un logiciel, de l'analyse des besoins à la livraison de celui-ci, mais il ne propose aucune démarche spécifique pour mener ce développement à terme.
  • 42. Travail à faire 42  Choisir un projet dont sa réalisation demande l’intervention d’au moins deux acteurs.  Déterminer le cahier des charges  Donner une première vision de:  Diagrammes statiques  Maquettes IHM  Rapport + présentation
  • 43. Processus Unifié et Approche Agile Introduction Processus Unifié Approche Agile
  • 44. Plan 44 1. Introduction 2. Les phases du Processus Unifié 3. Caractéristiques du Processus Unifié 4. Les 4 « P » du développement logiciel 5. Les enchaînements d’activités principaux
  • 45. Introduction 45  La création des logiciels de imposants et complexes.  On cherche des logiciels:  plus adoptés à nos besoins,  répondent aux exigences du marché,  dans des délais fixes,  avec des coûts réduits,  mieux documentés,  … plus en plus
  • 46. Introduction 46  « Le processus unifié (Unified Process) est un processus de développement logiciel, c’est-à-dire qu’il regroupe les activités à mener pour transformer les besoins d’un utilisateur en système logiciel » (Jacobson, Booch, Rumbaugh 1999).  Le résultat de la fusion des méthodes Objectory d'Ivar Jacobson, Booch de Grady Booch et OMT de James Rumbaugh, enrichi de nombreux apports issus des travaux d'élaboration du standard UML et du produit commercial RUP (Rational Unified Process).
  • 47. Introduction 47  Le PU utilise le langage UML pour la création des plans d’élaboration du logiciel.  Le PU ne fait pas partie intégrante du standard UML.  Utilisé pour le développement orienté objet de logiciel.  Le PU est :  piloté par les cas d’utilisation,  centré sur l'architecture,  itératif et incrémental.
  • 48. Les phases du PU 48  Le PU répète une série de cycles constituant la vie du système.  Un cycle conduit à la livraison d’une version du produit.  Un cycle s’articule autour de 4 phases:  Étude préliminaire  Élaboration  Construction  Transition
  • 49. Les phases du PU Chaque cycle de développement du PU est géré comme un projet ayant 4 phases. Chaque phase s’achève par un jalon définit par un ensemble d’artefacts. Etude préliminaire Elaboration Construction Transition Cycle 1 Cycle 2 Cycle 3 49
  • 50. Les phases du PU - artefact 50  Un élément d’information produit ou modifié dans le cadre du processus de développement (document, diagramme, compte rendu de réunion, code source, modèle de base de données, etc.)  Artefacts qui dépendent de l’activité de gestion de projet.  Artefacts qui sont directement issus du travail de fabrication du logiciel.
  • 51. Les phases du PU – phase 1 Etude préliminaire Elaboration Construction Transition Vision  Cette phase traduit l’idée en une vision du produit fini .  Elle répond aux questions suivantes :  Que va faire le système pour ses utilisateurs ?  A quoi peut rassembler l’architecture du système ?  Quels sont l’organisation et les coûts de ce produit? 51
  • 52. Les phases du PU – phase 2 Etude préliminaire Elaboration Construction Transition Vision Architecture  Concevoir une architecture de référence,  Formuler les cas d’utilisation pour couvrir environ 80% des besoins fonctionnels,  Faire une planification complète (temps, personnel, budget).  Le jalon est une architecture de base en justifiant les choix architecturaux. 52
  • 53. Les phases du PU – phase 3 Etude préliminaire Elaboration Construction Transition Vision Architecture  Mettre en œuvre tous les cas d’utilisation en accord avec les clients.  La phase la plus coûteuse qui conception , test et intégration, etc.  Le jalon est une version du produit. englobe le codage, la Version bêta 53
  • 54. Les phases du PU – phase 4 Etude préliminaire Elaboration Construction Transition Vision Architecture  Cette phase couvre le test du produit en version bêta .  Les anomalies et les défauts constatés par l’équipe de test sont prises en considération.  La formation des utilisateurs, la préparation des manuels d’utilisation, la mise en place d’une équipe de maintenance.  Le produit est déployé chez le client. Version bêta Produit livré 54
  • 55. Les phases du PU Besoins Analyse Conception Implémentation T ests Phases Etude Pré Élaboration Construction Transition Activités 55 principales
  • 56. Caractéristiques de Processus Unifié (itératif et incrémental) 56  Découper le travail en plusieurs parties qui présentent des mini-projets.  Une itération contient toutes les activités, conduit au développement d’un certain nombre de UC.  Les itérations donnent lieu à un incrément.  Un incrément correspond à une avancée dans les différents stades de développement.
  • 57. Caractéristiques de Processus Unifié (itératif et incrémental) Besoins Analyse Conception Implémentation T ests Phases Itérations Création Élaboration Construction Transition It. 1 It. n It. 2 … … … … … It. n-1 Activités 57 principales
  • 58. Caractéristiques de Processus Unifié (itératif et incrémental) 58  Gestion de la complexité.  Prise en compte des modifications de besoins.  Apprentissage rapide de la méthode.  Maîtrise précoce des risques.  …
  • 59. Caractéristiques de Processus Unifié (piloté par les UC) 59  Un outil de spécification des besoins du système.  Un outil pour guider le processus de développement.  Les cas d’utilisation sont:  détaillés par l’analyse  réalisés par la conception  concrètement implémentés par les développeurs  vérifiés par les scénarios de test
  • 60. Caractéristiques de Processus Unifié (piloté par les UC) Cas d’utilisation Modèle d’analyse Modèle de conception Modèle de déploiement Modèle d’implémentation Modèle de test spécifié par réalisé par distribué par implémenté par vérifié par 60
  • 61. Caractéristiques de Processus Unifié (piloté par les UC) 61  Support de communication entre utilisateurs et concepteurs.  Assurent la traçabilité de toute décision de conception.  Fournissent une vision commune aux participants du projet.  …
  • 62. Caractéristiques de Processus Unifié (centré sur l’architecture) 62  Une architecture décrit les différentes vues des modèles du système à construire.  Une architecture représente les aspects dynamique et statique du système.  Une architecture est un lien pour les membres du projet:  Une architecture émerge des besoins exprimés à travers les cas d’utilisation.  Elle complète les cas d’utilisation.
  • 63. Caractéristiques de Processus Unifié (centré sur l’architecture) 63  Dans un premier temps, choisir une architecture qui définit les parties générales de l’application.  Ceci mène à la construction d’une ébauche.  Dans un deuxième temps, stabiliser l’architecture autour des fonctions essentielles.  Ceci mène à la construction d’une architecture référence.  Dans un troisième temps, l’architecture continue à se stabiliser dans les itérations suivantes.
  • 64. Caractéristiques de Processus Unifié (centré sur l’architecture) 64  Comprendre le système,  Organiser le développement,  Favoriser la réutilisation,  Faire évoluer le système.
  • 65. Les 4 « P » du développement logiciel Processus Personnes Outils Produit Projet Automatisation Template 65 Participants Résultat
  • 66. Les 4 « P » du développement logiciel 66  Personnes: les architectes, développeurs, testeurs, la direction, les utilisateurs, les clients.  Projet: élément d’organisation à travers lequel est géré le développement du logiciel.  Produit: ensemble des artefacts créés au cours du cycle de vie du projet.  Processus: offre un cadre générique à la création de projet.
  • 67. Les enchaînements d’activités principaux Besoins Analyse Conception Implémentation T ests Phases Itérations Etude Pré Élaboration Construction Transition It. préliminaire It. n … … … … … It. n-1 Activités 67 principales
  • 68. Les enchaînements d’activités principaux -Expression des besoins-  Décrire les exigences que doit respecter le système avec précision pour parvenir à un accord entre le client et les développeurs. 68
  • 69.  La modélisation du domaine  La saisie des objets les plus importants dans le contexte du système.  Le diagramme du domaine est décrit avec le langage UML à travers le diagramme de classe contenant les classes essentielles.  La modélisation du métier consiste à décrire les processus métier existants ou perçus afin de les comprendre. 69 Les enchaînements d’activités principaux -Expression des besoins-
  • 70. Les enchaînements d’activités principaux -Expression des besoins- 70
  • 71.  Modèle des cas d’utilisation  Représenter les cas d’utilisation  Classer les cas d’utilisation par priorité  Décrire en détail les cas d’utilisation Les enchaînements d’activités principaux -Expression des besoins- 71
  • 72. Les enchaînements d’activités principaux -Expression des besoins- 72  La gestion locale est un traitement classique alors le risque est faible pour ce cas.  Les réservations en ligne nécessitent une architecture plus complexe alors le risque est plus élevé.  Le ménage des chambres entraîne des ressources alors le risque est moyen. 1. Réserver une chambre sur le site, 2. Gérer la chambre à nettoyer, 3. Réserver une chambre dans le local, 4. ….
  • 73. Les enchaînements d’activités principaux -Expression des besoins- 73  CU : Réserver une chambre  Portée : système de réservation  Acteur principal : Gérant  Intervenants et intérêts : Client, Chaîne hôtelière  Préconditions : une chambre est libre pour la période désirée  Garanties minimales : rien ne se passe  Garanties en cas de succès : la chambre est réservée  Scénario nominal 1. Description du scénario……..
  • 74. Les enchaînements d’activités principaux -Expression des besoins- 74  Compléter la description en représentant les diagrammes de séquence système, diagrammes d’activité.  Préparer des maquettes IHM (si nécessaire) pour l’évaluer auprès du client.  Recenser les besoins non fonctionnels dans une liste.
  • 75. Les enchaînements d’activités principaux -Expression des besoins- 75
  • 76. Les enchaînements d’activités principaux -Expression des besoins- 76
  • 77. Les enchaînements d’activités principaux -Expression des besoins- 77
  • 78. Rôle des besoins dans le cycle de vie du logiciel 78  L’expression des besoins s’étale sur plusieurs incréments de développement.  Chaque itération apporte de nouveaux cas d’utilisation ou des détailles des cas d’utilisation existants.  La capture des besoin s’effectue principalement au cours des phases d’étude préliminaire et d’élaboration.  Identification de la plupart des cas d’utilisations durant la phase d’étude préliminaire.  La mise à jour des cas d’utilisation durant la phase de l’élaboration.  Le reste de besoins est formulé et implémenté durant la phase de construction.
  • 79. Les enchaînements d’activités principaux Besoins Analyse Conception Implémentation T ests Phases Itérations Etude Pré Élaboration Construction Transition It. n … … … … … It. n-1 Activités 79 principales It. préliminaire
  • 80.  L'analyse se consacre à l'analyse des besoins décrits dans l'expression de ces derniers, en les affinant et en les structurant.  Réalisation des cas d’utilisation par des objets/ classes d’analyse pour préparer la conception.  Un point de départ pour l’analyse architecturale en décomposant le système. 80 Les enchaînements d’activités principaux -Analyse-
  • 81. Les enchaînements d’activités principaux -Analyse- 81
  • 82. Les enchaînements d’activités principaux -Analyse- 82 Modèle des cas d’utilisation Modèle d’analyse Langage du client Langage du développeur Vue externe du système Vue interne du système Structuré par les cas Structuré par les classes et les paquetages Sert à définir un contrat entre le client et les développeurs Sert à comprendre le système Informel Cohérent , non redondant Capture les fonctions du système et ce qui conditionne l’architecture Esquisse la manière de réaliser les fonctions dans le système et leur répartition dans des classes
  • 83.  Le modèle d’analyse est un modèle d’objet conceptuel.  Un modèle d’analyse structure les besoins et les exigences dans le langage des développeurs pour faciliter la compréhension, la modification.  Une première ébauche du modèle de conception constituant une entrée essentielle pour l’élaboration du système. 83 Les enchaînements d’activités principaux -Analyse (modèle d’analyse)-
  • 84.  Une classe d’analyse représente une ou plusieurs classes et/ou sous systèmes. Les enchaînements d’activités principaux -Analyse (modèle d’analyse)- 84
  • 85.  Une classe frontière modélise l’interaction entre le système et ses acteurs.  Elles présentent des fenêtres, des formulaires, des interfaces de communication, des terminaux et des API.  Elles n’ont pas besoin de décrire la réalisation physique de l’interaction.  Elle est liée à au moins un acteur. 85 Les enchaînements d’activités principaux -Analyse (modèle d’analyse)-
  • 86.  Une classe entité modélise les informations de longue durée et souvent de nature persistante.  Elles présentent des objets gérés par le système.  Elles font apparaître une structure de données logique .  Elles offrent une meilleure compréhension des informations dont le système dépend. 86 Les enchaînements d’activités principaux -Analyse (modèle d’analyse)-
  • 87.  Une classe de contrôle représente la coordination, le 87 contrôle séquencement, les transactions et le d'objets.  Elles modélisent la dynamique du système .  Elles servent souvent à encapsuler le contrôle associé à un cas d’utilisation spécifique. Les enchaînements d’activités principaux -Analyse (modèle d’analyse)-
  • 88. Les enchaînements d’activités principaux -Analyse (modèle d’analyse)- 88