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

1 ANALYSE DE TÂCHES Eric Fimbel Modifié par Jean-Marc Desharnais Ensuite modifié par Michael McGuffin Département de génie logiciel et des TI.

Présentations similaires


Présentation au sujet: "1 ANALYSE DE TÂCHES Eric Fimbel Modifié par Jean-Marc Desharnais Ensuite modifié par Michael McGuffin Département de génie logiciel et des TI."— Transcription de la présentation:

1 1 ANALYSE DE TÂCHES Eric Fimbel Modifié par Jean-Marc Desharnais Ensuite modifié par Michael McGuffin Département de génie logiciel et des TI

2 2 Quen pensez-vous? Conséquences? Un ingénieur/programmeur qui passe 7+ heures/jour à concevoir et à coder, et 1 heure/jour à utiliser un logiciel de dessin, connais bien les besoins des artistes qui auront à se servir du même logiciel 8+ heures/jour Les raccourcis avec le clavier cest bon pour les experts, pas pour un utilisateur moyen. Les ajouter à la programmation fait perdre du temps Lutilisation des abréviations et des acronymes sauve du temps décriture et de lecture On peut sauver beaucoup de temps et dargent en réduisant les rencontres avec les utilisateurs

3 3 Question Comment peut-on satisfaire les utilisateurs si on ne sait pas ce qu'ils font et comment ils le font ? Une approche centrée utilisateur commence par l'analyse des tâches et des façons de faire actuelles

4 4 Méthode suggérée S'immerger dans le contexte de l'entreprise. – Apprendre sur le domaine et les personnes. Observer les futurs utilisateurs et dialoguer avec eux. Déterminer les tâches qu'ils réalisent et les façons de faire actuelles.

5 5 Contexte d'utilisation de l'analyse de tâches Avant de commencer la conception, et même si possible avant d'établir des spécifications. Dans le cas d'une application d'entreprise. – Partant de procédures partiellement ou pas automatisées. – Partant de procédures réalisées par une application existante. Remarque: lanalyse de tâches en profondeur est peu utile si tous les besoins et fonctionnalités sont pré-établis

6 6 Objectif: construire un "inventaire" contenant plusieurs éléments … 1. Déterminer le domaine et le contexte dans lesquelles on utilisera la future application 2. Déterminer les intervenants (types dutilisateurs) qui réalisent ces tâches, et les caractériser sous forme de profils. Ex: est-ce que les intervenants connaissent les ordinateurs, etc. 3. Déterminer les tâches prescrites (quoi) et réelles (comment), c'est à dire les façons de faire actuelles. 4. Collecter les paramètres de réalisation de chaque tâche par différents intervenants. – Fréquence, temps d'exécution, erreurs, degré de difficulté... 5.Autres …

7 7 1. Domaine de l'application Le domaine décrit l'activité générale pour laquelle l'application sera utilisée. – Exemples de domaines : comptabilité, gestion de portefeuille, conception de circuits imprimés... Il faut se familiariser avec la terminologie et les concepts du domaine – Indispensable pour une compréhension minimum des tâches. – Permet un meilleur dialogue avec les intervenants

8 8 2. Intervenants Personnes jouant un rôle dans la réalisation des tâches. – Aussi appelés agents, acteurs, stakeholders. – Dans un sens plus large, tous ceux qui sont concernés ou touchés par la tâche Exemples: – Responsable – Intervenants qui participent toujours à la tâche – Internes ou externes à l'entreprise – Clients

9 9 Intervenants Donner un profil des intervenants qui utiliseront l'application. Idéalement le plus précis possible, sans être spéculatif. 1. Caractéristiques professionnelles. 2. Caractéristiques socio-démographiques. – Profession, années détudes (en moyenne), langue maternelle Degré de familiarité avec les interfaces graphiques. – Utilisation de logiciels similaires ou dusage général. 4. Degré de familiarité avec le domaine et les tâches. – Exemple: système de support technique (centre dappels). – Intervenant type = technicien(ne), réceptionniste, gérant ?

10 10 Utilité des profils des intervenants Permettent de choisir un style d'interface adapté Exemple. –Technicien(ne) en informatique. –Personnel de bureau.

11 11 3. Description de tâches Les tâches prescrites sont des descriptions théoriques (le « quoi ») – Exemples: maintenir les comptes à payer, faire le suivi du portefeuille des clients … Les tâches réelles caractérisent les détails des façons de faire actuelles (le « comment ») – Exemples: choisir telle option dans tel menu; téléphoner telle personne pour vérifier; comment fait-on lenregistrement des données--qui ou quoi consulte-t-on? Les tâches prévues sont celles qu'on pourra (dans le futur) réaliser totalement ou partiellement avec l'application.

12 12 4. Paramètres de réalisation des tâches Ces paramètres caractérisent la façon dont une même tâche est réalisée par différents intervenants. – Il est fréquent que différentes personnes réalisent une même tâche, même si théoriquement elle est assignée à un seul intervenant. – Une tâche donnée sera réalisée plus ou moins bien par différents intervenants. Paramètres importants: – Fréquence à laquelle différents intervenants réalisent une tâche. – Performances de chacun, i.e., temps d'exécution, taux d'erreur... – Degré de difficulté de la tâche pour différents intervenants.

13 13 5. Autres choses à noter… -Vocabulaire du domaine, termes employées, concepts, etc. -Outils, équipements, accessoires utilisés ou produits lors des tâches: –Exemples : photocopieuse, déchiqueteuse, stylo, bloc-notes, facture, etc.... -Les opérations de base formant les tâches: –Aussi appelées : actions élémentaires. –Exemple: transmettre, payer, rechercher,...

14 14 Décomposition des tâches 1. Décomposer selon le niveau d'agrégation (ou granularité). – Exemple. s'identifier (granularité grossière, forte agrégation) – Exemple. cliquer le champ "login", taper "login"... (granularité fine). Problème: déterminer le niveau de détail. – On pourrait descendre jusqu'aux gestes élémentaire.

15 15 Décomposition des tâches Examiner les tâches et leur décomposition en sous-tâches (étapes) pour vérifier si on a la situation suivante: La tâche a des sous-tâches (étapes) en commun avec d'autres tâches. –Exemple : s'identifier –Exemple : signer un document. On considère les sous-tâches communes comme de possibles opérations de base.

16 16 Détermination des opérations de base Considérer qu'une tâche est une opération de base dans l'une ou l'autre des situations suivantes: 1. Tout utilisateur peut réaliser la tâche sans formation. 2. Il est peu important que la tâche réussisse ou non. –C'est à dire qu'on a des alternatives pour obtenir le même résultat. Quand c'est le cas, la tâche en question est considérée comme une opération de base (et ajoutée comme telle au glossaire).

17 Comment recueillir les données 17

18 18 Observation directe des activités Observer lagent pendant son travail. – Identifier: outils utilisés, comportement de lutilisateur, comportement des technologies, les communications liées au travail, les procédures de prise de décisions, les intrants et extrants des tâches, les problèmes rencontrés par lutilisateur, etc. – Tip: demander à l'agent de verbaliser (« talk aloud ») – Noter le verbal et non-verbal. Tip: essayer de se faire oublier. – Définir clairement l'objectif (PAS espionner, mais comprendre). – Minimiser les questions et interférences. – Les appareils d'enregistrement : plus objectifs, mais peuvent être mal perçus, et génèrent beaucoup de données

19 19 Observation directe des activités Avantages. – Collecte de données sur le travail réel. – Recueillir des données non accessibles autrement. Désavantages. – Lobservation change la façon dont la tâche est faite. – Lobservation permet rarement de recueillir des données sur les exceptions. – Demande certaines connaissances pour comprendre ce qui se fait.

20 Autres techniques dobservation … Un journal (« diary ») qui est entretenu par un intervenant – Permet une étude longitudinal peu couteux – Demande beaucoup de discipline de la part de lutilisateur Caméra vidéo cachée Techniques ethnographiques – Devenir un utilisateur 20

21 21 Entrevues et questionnaires Personnes à interroger – Employé, superviseur, etc. Préparer lentrevue/le questionnaire – Définir des objectifs clairs. – Préparer sa stratégie et ses questions. Types: – Dirigiste: questions fermées (quand, comment, combien de fois). – Non-dirigiste: questions ouvertes (permettre des développements). – Libre: laisser l'interviewé aborder les sujets qui l'intéresse

22 22 Entrevues et questionnaires Avantages – Permet de recueillir beaucoup de données sur les perceptions des tâches Désavantages – Données non rigoureuses – Biais des interviewés – Naccède pas aux parties inconscientes du travail (automatismes)


Télécharger ppt "1 ANALYSE DE TÂCHES Eric Fimbel Modifié par Jean-Marc Desharnais Ensuite modifié par Michael McGuffin Département de génie logiciel et des TI."

Présentations similaires


Annonces Google