La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Ingénierie Système Analyse des besoins 3/12/2010 Catherine Letondal

Présentations similaires


Présentation au sujet: "Ingénierie Système Analyse des besoins 3/12/2010 Catherine Letondal"— Transcription de la présentation:

1 Ingénierie Système Analyse des besoins 3/12/2010 Catherine Letondal

2 Plan Lanalyse de besoins dans la démarche A/COO Principes et définitions de base Acteur Cas dutilisation Scénario Etude dun guichet automatique de banque 2

3 Analyse de besoins + diagrammes activité (UC complexes) + organisation UC packages UML Lanalyse de besoins dans la démarche A/COO 3

4 Principes et définitions de base

5 Définition dacteur Un acteur représente un rôle joué par une entité externe (utilisateur humain, dispositif matériel ou autre système) qui interagit avec le système Un acteur peut consulter et/ou modifier directement létat du système, en émettant et/ou en recevant des messages susceptibles dêtre porteurs de données 5

6 Comment identifier les acteurs ? Les utilisateurs humains directs : il faut identifier tous les profils possibles, sans oublier ladministrateur, lopérateur de maintenance, etc. (acteurs principaux) Ex. Internaute, ladministrateur du site, lopérateur mettant à jour le catalogue douvrages, … Les autres systèmes interagissant directement avec le système étudié (acteurs secondaires) Ex. Système de paiement par carte bleue 6

7 Acteur principal ou secondaire Acteur principal Celui pour qui le système produit un résultat observable, une plus-value métier Le système est conçu pour satisfaire les besoins des acteurs principaux ! Acteur secondaire Les autres sollicités par le système pour des informations complémentaires Ils peuvent uniquement consulter ou informer le système lors de lexécution dun service (cas dutilisation) 7

8 Définition dun cas dutilisation Un cas dutilisation décrit la façon dont un ou plusieurs acteurs utilisent un système pour atteindre un but Les cas dutilisation représentent les services rendus par le système – les fonctions - du point de vue de lacteur Ex. « Rechercher des ouvrages », « Gérer son panier », … sont des besoins/buts dun site web de vente de livres 8

9 Comment identifier les cas dutilisation? Pour chaque acteur : Rechercher les différentes intentions métier avec lesquelles il utilise le système Utiliser les observations et les résultats de la conception participative (scénarios, storyboards, prototypes vidéo,...) Déterminer dans le cahier des charges les services fonctionnels attendus du système Nommez les cas dutilisation par un verbe à linfinitif suivi dun complément, du point de vue de lacteur (et non pas du système) 9

10 Comment représenter les acteurs et les cas dutilisation ? Le diagramme de cas dutilisation est un schéma qui montre les cas dutilisation (ovales) reliés par des associations (lignes) à leurs acteurs Chaque association signifie « participe à » Un cas dutilisation doit être relié à au moins un acteur Un acteur secondaire de type « système » peut optionnellement être représenté par une classe 10

11 Scénario Un scénario est une suite spécifique dactions et dinteractions entre un ou plusieurs acteurs et le système dans le contexte dun cas dutilisation Un cas dutilisation contient en général un scénario nominal et plusieurs scénarios alternatifs (qui se terminent de façon normale) ou derreur (qui se terminent en échec) 11

12 Etude dun guichet automatique de banque (GAB)

13 Etapes de lanalyse de besoins Identifier les acteurs Identifier les cas dutilisation Construire le diagramme de cas dutilisation Décrire textuellement les cas dutilisation Décrire les cas dutilisation avec UML Organiser et structurer les cas dutilisation 13

14 Exigences Le GAB offre les services suivants : 1. Distribution dargent à tout porteur de carte de crédit, via un lecteur de carte et un distributeur de billets 2. Consultation de solde de compte, dépôt en numéraire et dépôt de chèques pour les clients porteurs dune carte de crédit de la banque adossée au GAB Noubliez pas non plus que : 3. Toutes les transactions sont sécurisées 4. Il est parfois nécessaire de recharger le distributeur 14

15 Identifier les acteurs du GAB (Phrases 1 et 2) Phrase 1 -> acteur « Porteur de carte » Le lecteur de carte et le distributeur de billets ne sont acteurs car ils font partie du GAB Autre piège : la carte bancaire est externe au système, mais celui qui bénéficie de lutilisation du système est le porteur de carte, pas la carte (éliminer les acteurs « physiques » au profit des acteurs « logiques ») Phrase 2 -> acteur « Client banque » La phrase identifie des services supplémentaires qui ne sont proposés quaux clients de la banque porteurs dune carte de crédit de cette dernière (il sagit donc dun profil différent représenté par un nouvel acteur) 15

16 Identifier les acteurs du GAB (Phrases 3 et 4) Phrase 3 -> toutes les transactions sont sécurisées, mais par qui ? Pas par le GAB, sinon par 2 nouveaux acteurs (daprès la réponse dun expert métier) : « Système dautorisation global Carte Bancaire» : pour les transactions de retrait « Système dinformation » : pour autoriser toutes les transactions effectués par un client avec sa carte de la banque Phrase 4 -> acteur « Opérateur de maintenance » Le GAB nécessite des actions de maintenance telles que le rechargement en billets du distributeur, la récupération de cartes avalées, etc. 16

17 Identifier des cas dutilisation du GAB Porteur de carte – Retirer de largent Client banque – Consulter le solde de son compte courant – Déposer du numéraire – Déposer de largent Opérateur de maintenance – Recharger le distributeur – Maintenir létat opérationnel Système dautorisation (Sys. Auto.) – Néant Système dinformation (SI) banque – Néant Acteurs principaux (ceux pour qui les cas dutilisation produisent un résultat observable) Acteurs secondaires (les autres participants des cas dutilisation sollicités pour des informations complémentaires) 17

18 Construire le diagramme de cas dutilisation (préliminaire) Dautres solutions existent Ne perdez trop de temps avec les détails des diagrammes de cas dutilisation Diagramme utile pour montrer le périmètre du système 18

19 Décrire les cas dutilisation 19

20 Description textuelle dun cas dutilisation Sommaire didentification (obligatoire) – Inclut titre, résumé, dates de création et de modification, version, responsable, acteurs… Description des scénarios (obligatoire) – Décrit le scénario nominal, les scénarios alternatifs, les scénarios derreur, les préconditions et les postconditions Exigences non fonctionnelles (optionnel) – Fréquence, volumétrie, disponibilité, fiabilité, intégrité, confidentialité, performances, concurrence, etc. Précise également les contraintes dIHM comme des règles dergonomie, une charte graphique, etc. 20

21 Décrire textuellement les cas dutilisation (ex. « Retirer de largent » ) Sommaire didentification Titre : Retirer de largent Résumé : ce cas dutilisation permet à un Porteur de carte, qui nest pas client de la banque, de retirer de largent, si son crédit hebdomadaire le permet. Acteurs : Porteur de la carte (principal), Système dautorisation (secondaire) Date de création : 01/11/09Date de mise à jour : 15/11/09 Version : 1.6Responsable : Luis Basora 21

22 Décrire textuellement les cas dutilisation (ex. « Retirer de largent » ) Description des scénarios Préconditions La caisse du GAB est alimentée (il reste au moins un billet !). Aucune carte ne se trouve déjà coincée dans le lecteur. La connexion avec le Système Scénario nominal 1. Le Porteur de carte introduit sa carte dans le le lecteur de cartes du GAB. 2. Le GAB vérifie que la carte introduite est bien une carte bancaire. 3. Le GAB demande au Porteur de carte de saisir son code didentification. 4. Le Porteur de carte saisit son code didentification. 5. Le GAB compare le code code didentification avec celui qui est codé sur la puce de la carte. 6. Le GAB demande une autorisation au Système dautorisation. 7. Le Système dautorisation donne son accord et indique le crédit hebdomadaire. 8. … 8. Le porteur de carte prend les billets et le ticket. 22

23 Décrire textuellement les cas dutilisation (ex. « Retirer de largent » ) Enchaînements alternatifs A1 : code didentification provisoirement erroné Lenchaînement A1 démarre au point 5 du scénario nominal. 6. Le GAB indique au Porteur de carte que le code est erroné, pour la première ou deuxième fois. 7. Le GAB enregistre léchec sur la carte. Le scénario nominal reprend au point 3. … Enchaînements derreur E1 : carte non-valide Lenchaînement E1 démarre au point 2 du scénario nominal. 3. Le GAB indique au Porteur que la carte nest pas valide (illisible, périmée, etc.), la confisque ; le cas dutilisation se termine en échec. … 23

24 Décrire textuellement les cas dutilisation (ex. « Retirer de largent » ) Postconditions La caisse du GAB contient moins de billets quau début du cas dutilisation (le nombre de billets manquants est fonction du montant du retrait). Une transaction de retrait a été enregistrée par le GAB avec toutes les informations pertinentes (montant, numéro de carte, date, etc.). Les détails de la transaction doivent être enregistrés aussi bien en cas de succès que déchec. Exigences non fonctionnelles ContraintesDescriptif Temps de réponse Linterface du GAB doit réagir en lespace de 2 secondes au maximum. ConcurrenceNon applicable (mono-utilisateur). Disponibilité7j/7, 24h/24. Labsence de papier pour les tickets ne doit empêcher les retraits. Intégrité Les interfaces du GAB doivent être très robustes pour prévenir le vandalisme. ConfidentialitéLa comparaison du code didentification saisi sur le clavier du GAB avec celui de la carte doit être fiable à

25 Décrire textuellement les cas dutilisation (ex. « Retirer de largent » ) Besoins IHM Les dispositifs dentrée/sortie à la disposition du Porteur de carte doivent être : Un lecteur de carte bancaire Un clavier numérique avec des touches « validation », « correction » et « annulation » Un écran pour laffichage des messages du GAB Des touches autour de lécran pour sélectionner un montant de retrait parmi ceux qui sont proposés Un distributeur de billets Un distributeur de tickets 25

26 Décrire les cas dutilisation avec UML La description textuelle est indispensable, car elle permet de communiquer facilement avec les utilisateurs En revanche, le texte présente des désavantages : il est difficile de montrer comment les enchaînements se succèdent, ou à quel moment les acteurs secondaires sont sollicités Il est recommandé de compléter la description textuelle par un ou plusieurs diagrammes dynamiques UML, tels que les diagrammes de séquence ou les diagrammes dactivités 26

27 Diagrammes UML dynamiques les plus utilisés pour les cas dutilisation Pour illustrer des scénarios particuliers Pour documenter les cas dutilisation 27

28 Ex. Diagramme dactivité du cas dutilisation « Retirer de largent » 28

29 Diagrammes de séquence système 29 traduction directe dun scénario de use case le diagramme UC sert plutôt à représenter les liens entre acteurs et use case le DSS : lien UC (paradigme fonctionnel) et modèles OO début du diagramme dinteraction

30 Ex. Diagramme de séquence système du scénario nominal « Retirer de largent » 30

31 Servez-vous des cas dutilisation pour définir vos itérations ! Dans le cadre dun développement itératif et incrémental, il est très utile de recourir au découpage en cas dutilisation pour définir les itérations À cet effet, il convient en premier lieu didentifier les cas dutilisation les plus critiques en termes de gestion des risques Ces cas dutilisation devront être traités prioritairement afin de lever au plus tôt les risques majeurs. Il sera également demandé au client daffecter une priorité fonctionnelle à chaque cas dutilisation, afin de livrer dabord les cas dutilisation les plus demandés. Ces deux critères pouvant être contradictoires, la décision du découpage en itérations incombe au chef de projet, qui doit le faire valider par le client 31

32 Exemple de découpage du projet en itérations Cas dutilisationRisquePrioritéItératio n Retirer de largent hauthaute1 Consulter le solde de son compte courant moyenhaute2 Déposer de largent hautmoyenne2 Recharger le distributeur bashaute3 Maintenir létat opérationnel bashaute3 À chaque cas dutilisation, on peut affecter : un risque (haut, moyen, bas), une priorité fonctionnelle (haute, moyenne, basse). 32

33 Conseils méthodologiques Pas plus de 20 cas dutilisation de base – Ne pas tomber dans le piège de la granularité trop fine Le plus important est la description textuelle et lidentification des scénarios (la robustesse du système en dépend) Nabusez pas des relations entre cas dutilisation (surtout extension) : – Diagrammes difficiles à lire pour les experts métier Soyez agiles et itératifs ! – Faire évoluer les cas dutilisation et les diagrammes à travers les itérations – DSS pour les scénarios choisis pour litération suivante (seulement les scénarios nominaux et les alternatifs les plus complexes) – Avancez en parallèle dans lélaboration du modèle du domaine et de larchitecture 33

34 34 EME de lanalyse fonctionnelle et acteurs Identifier les éléments extérieurs en relation avec le système : physique, technique, humain, économique La relation est un lien physique ou virtuel Question typique : Limite du système ? Exemple : pilote de lavion ? Exemples : Utilisateurs, environnement, normes, législation … system EME1 EME2 EME3

35 35 Fonctions de lanalyse fonctionnelle et use cases FonctionCritèreNiveauFlexibilité PF 1: Permettre aux passagers découter une station radio sélectionnée. Niveau sonore Uniformisation du niveau sonore dans lhabitacle jusquà 90 DB 12,5% décart entre chacune des places + ou - 5% + ou – 10% PF 2: Permettre à lopérateur de sélectionner une station radio pour lécouter. Facilité de sélection Taux derreur Nombre de manipulations nécessaire : <=2 Moins dune fois sur 10 Non 1 fois sur 20 PF 3: Permettre à lopérateur de contrôler la restitution sonore de la station radio sélectionnée. Facilité de contrôle Précision Nombre de manipulations nécessaire : <=2 Précision de + ou – 1 DB Non Précision de + ou – 2 DB

36 36 eFFBD de lanalyse fonctionnelle et diagrammes de séquences


Télécharger ppt "Ingénierie Système Analyse des besoins 3/12/2010 Catherine Letondal"

Présentations similaires


Annonces Google