Upload
jules-legrand
View
109
Download
2
Embed Size (px)
Citation preview
1
RÉALISÉ PAR: HAJJI JIHED
MANEL BELHADJ AHLEM LIMEM
LES TECHNIQUES POUR L’ELICITATION DES EXIGENCES
2
PLAN
I. IntroductionII. ButIII. TechniquesIV. Avantages/ InconvénientsV. Conclusion
3
INTRODUCTION
Enjeux des années 80: qualité/performance des produits 90: la pression sur les coûts Années 2000: délais qui préoccupent les industriels.
Le besoin d’accélérer les processus de conception impose l’utilisation de plate forme collaborative: la mise à disposition d’un espace de communication numérique entre les acteurs du processus.
Conséquences: + Partage des données structurelles et physiques du
système , les données projet. -Perte de temps dans le projet inhérent à la nature même
des exigences : complexes, floues, incomplètes et évolutives.
4
ÉLICITATION DES EXIGENCES
La complexité, l’imprécision et l’incomplétude peuvent être traitée selon nous par les méthodologies d’élicitation du besoin.
Elicitation des exigences: propriété concernant la capacité à faire sortir, émerger, découvrir les besoins de l’ensemble des clients .
5
BUT
Elicitation des exigences: capturer les besoins du client raffiner la compréhension du problème déterminer les limites de la solution identifier les contraintes à respecter. Déterminer les techniques d’acquisition Produire un premier document
6
POSITION DE L’ELICITATION DANS L’ETUDE D’UN PROJET
7
TECHNIQUES
Les concepteurs ont besoin de méthodes performantes pour pouvoir développer une activité:
Analyse des parties prenantes Analyse de systèmes existants Remue-méninge Sessions Joint Application Design (JAD) Entrevues Prototypage Cas d’usage et scénarios Analyse de risques
8
ANALYSE DES PARTIES PRENANTES(1)
Analyse des parties prenantes: L’analyse des parties prenantes est l’outil
identifiant les besoins et les préoccupations des différentes parties concernées. Client: Personne qui paye le développement du logiciel
Utilisateur: expert du système actuel et du système compétiteur
Acheteur: Personne qui paye le logiciel une fois développé
Expert du domaine: connait le travail et l’environnement d’utilisation
Ingénieur logiciel: Expert qui connait la technologie et le processus
Autres : Inspecteur, Spécialiste en études de marchés, Avocat..
9
ANALYSE DES PARTIES PRENANTES(2)
les étapes:
Établir la vision ou l’objectif Recueillir les renseignements Identifier explicitement toutes les personnes et
organisations, internes et externes Classer les parties prenantes Déterminer l’intérêt ou l’effet de l’enjeu Établir leur position et leur importance Déterminer les parties prenantes clés Développer un plan d’action.
10
EXEMPLEANALYSE DES PARTIES PRENANTES
11
ANALYSE DES PARTIES PRENANTES(3)
Avantages: importance trop grande accordée aux outils
analytiques questions trop vastes ou trop complexes pour
les décideurs portée de l’étude trop grande certaines parties prenantes sont laissées de
côté pas d’appartenance locale pas d’engagement face à la mise en oeuvre.
12
ANALYSE DE SYSTÈMES EXISTANTS(1)
Analyse de systèmes existants: Déterminer les vraies habitudes des
utilisateurs, les activités fréquentes, et l’importance relative des tâches et services
découvrir des améliorations possibles découvrir les fonctionnalités patrimoniales Étapes:
étude de documentation disponible Observations Questionnaires Entrevues
13
ANALYSE DE SYSTÈMES EXISTANTS(2)
14
ANALYSE DE SYSTÈMES EXISTANTS(3)
Etapes: Recueillir l'information sur l'existant et sur les attentes par rapport au
futur. Décrire et évaluer les fichiers existants Se procurer la documentation sur les données actuelles. Décrire et évaluer l'infrastructure d'organisation du système
informatique existant Décrire et évaluer les procédures. Décrire et évaluer les ressources technologiques du système existant. Recenser les défauts de sécurité. Résumer la description et l'évaluation des systèmes informatiques
existants (principaux faits saillants, avantages, inconvénients). Définir et chiffrer le plan d'amélioration à court terme de l'existant pour
des problèmes urgents. Définir le plan pour la sécurité de l'existant. Vérifier la cohérence de l'ensemble.
15
ANALYSE DE SYSTÈMES EXISTANTS(4)
Avantages : la méthode réduit les problèmes
d’incompréhension entre les deux catégories d’acteurs (analystes et utilisateurs ).
Inconvénients : L’utilisation de cette méthode présente le
risque de ne pas percevoir les évolutions souhaitables dans le système d’information.
16
REMUE-MÉNINGE
Remue-méninge (brainstorming): la récolte d'idées nombreuses et originales.
principes: la suspension du jugement la recherche la plus étendue possible. règles :• Ne pas critiquer.• S'attendre à des idées extravagantes ;tout est
possible (« freewheeling »).• Rebondir (« hitchhike ») sur les idées exprimées.• La quantité est plus importante que la qualité.
17
EXEMPLE (BRAINSTORMING)
Des universitaires veulent créer une entreprise de formation multimédia. Pour développer leur clientèle, ils décident de faire un remue-méninges. Ils demandent à deux amis de faire l’animation et le secrétariat de la rencontre. L’animateur rappelle le but de la rencontre Il rappelle les règles du remue-méninges Il laisse au groupe une période de réflexion silencieuse (5 mn
pour mettre leurs idées sur papier) Il invite chaque participant à exprimer une idée à la fois Le secrétaire note et numérote les idées. Il leur demande ensuite de regrouper les idées. Les participants sont ensuite invités à classer les suggestions
par ordre d’importance ou d’intérêt .
18
REMUE-MÉNINGE
19
REMUE-MÉNINGE
Avantages:
utile à la résolution des problèmes peut être utilisé par tous les élèves et encourage la participation aide les élèves à accepter d'autres points de vue peut fournir rapidement de nombreuses idées ou suggestions permet d'éviter les arguments puisque les commentaires négatifs ne sont pas
autorisés ne nécessite aucun équipement ou matériel spécial
Inconvénients:
la prise de notes peut ralentir le cours des idées tend à être bruyant si les élèves s'excitent un élève bavard peut dominer la discussion pour réussir, nécessite un bon animateur et un bon secrétaire il est difficile de ne pas juger
20
SESSIONS JOINT APPLICATION DESIGN
Sessions Joint Application Design (JAD): Utilisation d’aides visuelles pour améliorer la compréhension
Étapes : Planification: utilisée pour l’élicitation (remue-méninges) Conception: utilisée pour concevoir le logiciel
Rôle : Dirigeant de session Analyste Promoteur exécutif Représentants des utilisateurs Représentants du département d’informatique Spécialistes
21
ENTREVUES
Entrevues: Demande de la préparation et une bonne gestion de la
communication.objectifs:
Découvrir :l’information de façon précise et efficace
Documenter : l’information servant à la modélisation et l’analyse des exigences Rassurer :l’interlocuteur que sa compréhension du sujet a été entendue,
explorée , et prise en considération.
étapes: Planification et préparation Session d’entrevue Consolidation de l’information Suivi
22
ENTREVUES
Connaissance d’une entreprise lors d’une entrevue d’information avec un employeur :
▪ Quelle est la mission de votre entreprise?▪ Quel est l'historique de votre entreprise?▪ Quelles professions retrouve-t-on dans votre entreprise?▪ Quelles sont les perspectives de développement de
votre entreprise?▪ Quelles sont les opportunités d’emploi dans votre
entreprise?▪ Quel est l’organigramme de votre entreprise?▪ Quel environnement de travail offre votre entreprise?
23
ENTREVUES
24
ENTREVUES
Avantages : - Donne une crédibilité à l’information reçue. - Personnifie la source des informations. - Transmet rapidement et efficacement l’information. - Suscite la réflexion. - Favorise une recherche plus approfondie des informations. - Provoque des réactions spontanées. - Augmente la compréhension par la possibilité de clarification des
réponses - Peut être utilisée dans plusieurs contextes. Inconvénients : - Demande beaucoup de préparation de la part de l’intervieweur. - S’attarde parfois à une première impression désagréable. - Passe parfois à côté du message principal. - Ne différencie pas l’information objective de l’information subjective. - Se heurte parfois au manque d’expérience de l’intervieweur.
25
PROTOTYPAGE
Prototypage: découvrir les fonctionnalités, discuter les interfaces utilisateurs et de convivialité établir des priorités. Principe: la production d'un logiciel est le résultat d'un processus
cyclique d'évolution progressive d’une forme simple vers une forme complexe, chaque cycle d'évolution fournissant un prototype de plus en plus élaboré et de plus en plus proche du système à produire.
catégories: évolutif jetable
26
PROTOTYPAGE(EXEMPLE)
Développement d'un système expert :évolutif évolutif
27
PROTOTYPAGE(EXEMPLE)
Prototype d'un analyseur syntaxique avec une grammaire réduite : jetable
28
PROTOTYPAGE
Avantages : -un gain de temps - un gain d’argent - faciliter l’implantation du SI et la collaboration des utilisateurs - trouver les modèles les plus appropriés aux styles cognitifs des utilisateurs - une identification plus « concrète » des besoins en information des utilisateurs - améliorer la communication entre analystes et utilisateurs ; - une meilleure implication des utilisateurs durant le processus de
développement, ce qui conduit à une meilleure satisfaction Inconvénients : - la méthode s’avère difficilement applicable dès que les projets prennent de
l’envergure - le contrôle, la maîtrise de cette approche de développement ne sont pas
aisés ; - le développement de prototypes peut exiger l’acquisition de ressources
informatiques sophistiquées.
29
CAS D’USAGE ET SCÉNARIOS
Cas d’usage : Un cas d’usage: séquence typique d’actions
qu’entreprend un utilisateur afin d’accomplir une tâche donnée
Scénarios: Un scénario (selon UML) est une instance d’un cas-type Décrit le flux des évènementsTypes: Scénario « tel quel » Scénario visionnaire Scénario d’évaluation Scénario de formation
30
CAS D’USAGE ET SCÉNARIOS
Règles d'écriture des scénarios: Décrire l'activité : "quoi" pas "comment " Rester simple Décomposer avec <<uses>> or <<extends>> Autonomie Ne pas mélanger les cas d'utilisation Style direct Pas d'ambiguité ("très", "plutot", "peu", "souvent",
"en général") Un scénario est une transaction Il y a un début et une fin Il est exécuté complètement ou pas du tout
31
CAS D’USAGE ET SCÉNARIOS(EXEMPLE)
32
CAS D’USAGE ET SCÉNARIOS
Avantages: correction de la spécification relativement aux besoins modéliser le domaine du problème (UML). Distinguer la modélisation du problème et la conception de
la solution identifier (et corriger) les erreurs ou les omissions s'assurer de l'implication et la compréhension des parties
prenantes
Inconvénients:o difficulté avec les systèmes complexeso masquent les règles métier derrière les interactions
acteurs / système
33
CONCLUSION
Les principales caractéristiques de notre approche peuvent être résumées comme suit. Besoins/élicitation des besoins d’une part, spécification/élaboration de spécifications d’autre part sont clairement identifiés.
34
BIBLIOGRAPHIE
http://fr.wikipedia.org http://fr.wikipedia.org http://www.cours.polymtl.ca/log3410/la
boratoires/Lab_Ete10/log3410%20E2010%20Lab1%20v1-0.pdf
http://tel.archives-ouvertes.fr/docs/00/43/58/78/PDF/rapportThesis.pdf
http://www.google.fr/#hl=fr&source=hp&q=technique+d%27elicitation+des+exigences&aq=f&aqi=&aql=&oq=&gs_rfai=&fp=c6754f687e3a6a87
35
MERCI POUR VOTRE ATTENTION