Daylight Démarche ergonomique et RUP Daylight 2001 Démarche ergonomique et RUP 1/1
Synthèse Ce document est une synthèse des travaux effectués par Daylight, sur la prise en compte des problématiques ergonomiques dans le Processus Unifié (UP) et plus particulièrement dans l outil associé Rational Unified Process (RUP). Etat Juillet. 2001 Document de travail version 0.01 1 ère version Sept. 2001 Document de travail version 0.06 axes d évolution RUP intégrant l ergonomie Oct. 2001 Validée version 0.07 intégration des évolutions RUP V 2001A.04.00 Diffusion La diffusion ou reproduction de ce document est autorisées sous réserve que le document soit conservé en l état, notamment pour les mentions relatives aux auteurs et copyright. Mots clés Processus Unifié, UP, RUP, Ergonomie, Utilisabilité, démarche centrée utilisateur, UML, Cas d'utilisation, Use-case. Auteurs Dominique Causse - Daylight. Contributeurs Christian Pian - Daylight, Odile Carron - Daylight. Daylight 2001 Démarche ergonomique et RUP 2/2
Table de matière 1. Introduction 4 1.1 Objet du document 4 1.2 Terminologie utilisée dans ce document 4 1.3 Avertissement 4 1.4 Utilisation et reproduction 4 1.5 Contact, remarques 4 2. Conception d interfaces utilisateurs et RUP 5 2.1 Conception d interface utilisateur dans RUP 5 2.2 Problèmes soulevés par l approche mise en oeuvre dans RUP 5 2.3 RUP, un processus centrée architecture plutôt qu utilisateur 6 2.3.1 Les concepts de l approche centrée utilisateur 6 2.3.2 Vers un renforcement de l approche centrée utilisateur dans RUP? 7 3. Les «use-case» 8 3.1 Des définitions multiples 8 3.2 Un point de vue qui a évolué 8 3.3 Des cas d utilisation «essentiels» 8 4. Prise en compte de l approche ergonomique dans RUP 9 4.1 Définir une démarche centrée utilisateur 9 4.2 Un nouveau rôle 10 4.3 Etendre le champ d intervention 11 4.4 Vue synthétique du rôle d ergonome 13 4.5 Un niveau de guidage à renforcer 14 5. Mise en œuvre progressive 14 6. Annexe 15 6.1 Bibliographie 15 6.2 Traduction française de la terminologie utilisée 16 Daylight 2001 Démarche ergonomique et RUP 3/3
1. Introduction 1.1 Objet du document Ce document est une synthèse des travaux effectués par Daylight, sur la prise en compte des problématiques ergonomiques dans le Processus Unifié (UP) et plus particulièrement dans l outil associé Rational Unified Process (RUP). Les points abordés sont : - analyse des activités de conception d interfaces utilisateurs dans RUP ; - problématique de mise en œuvre des cas d utilisation pour la conception d interface ; - axes d adaptations de RUP pour mieux prendre en compte la dimension ergonomique de la conception d interface logicielle. 1.2 Terminologie utilisée dans ce document Démarche centrée utilisateur Une démarche centrée utilisateur englobe tous les aspects d une démarche de conception en les articulant autour du besoin des utilisateurs. Elle implique généralement une approche itérative et la mise en œuvre de techniques ergonomiques. Utilisabilité L utilisabilité est définie dans L ISO 9241[ISO 9241] comme «la mesure dans laquelle un produit peut être utilisé par des utilisateurs particuliers pour réaliser un objectif définit avec efficacité, efficience, et satisfaction dans un contexte précis d utilisation». Le terme d utilisabilité est beaucoup plus employé que celui d ergonomie dans le monde anglosaxon. Autres termes Ce document utilise abondamment la terminologie RUP. La documentation RUP étant pour le moment uniquement disponible en anglais, une traduction des termes les plus utilisés dans ce document est donnée en annexe. Les autres termes sont définis dans le glossaire de RUP. 1.3 Avertissement Ce document est réalisé par les consultants de Daylight. Il est appelé à évoluer en fonction des différents apports et retour d expérience et n a rien «d officiel». Il n engage en rien Rational ni Daylight. Ses sociétés ne seraient être tenues pour responsable de la mise en œuvre des démarches présentées dans ce document. RUP est un produit développé et commercialisé par Rational Software. La version actuelle de ce document se base sur la version 2001A.04.00 de RUP et n intègre pas les dernières évolutions. Ce sera l objet d un autre document. 1.4 Utilisation et reproduction La diffusion ou reproduction de ce document est autorisées sous réserve que le document soit conservé en l état, notamment pour les mentions relatives aux auteurs et copyright. 1.5 Contact, remarques Pour toutes vos remarques, contributions, informations complémentaires, ou pour une mise à jour du présent document vous pouvez contacter l auteur à l adresse dominique.causse@daylight.fr. Daylight 2001 Démarche ergonomique et RUP 4/4
2. Conception d interfaces utilisateurs et RUP Ce chapitre donne un éclairage sur la prise en compte des problématiques ergonomiques dans RUP. 2.1 Conception d interface utilisateur dans RUP Krutchen, principal architecte du produit Rational Unified Process (RUP), définit plusieurs activités liées à la conception des interfaces utilisateurs ([Kruchten 2000] et le chapitre 5 de [Harmelen 2001]) : développer la charte ergonomique de projet (user-interface-guidelines) ; modéliser l interface utilisateur ; prototyper l interface utilisateur ; Il définit aussi un rôle, le concepteur d interface utilisateur (user interface designer). Ce dernier est responsable de plusieurs artefacts : lesacteurs; le «use-case storyboard» ; un prototype de l interface utilisateur ; les classes frontières ; la charte ergonomique de projet ; [RUP] Dans la version actuelle de RUP, les activités de conception d interface sont regroupées dans deux enchaînements de tâches (workflow) : le recueil des besoins (requirement workflow) et plus précisément la dernière étape de ce dernier, pour affiner la définition du système (Refine the System Definition). Cette étape permet de modéliser et prototyper l interface, des spécifications supplémentaires permettent de plus de préciser les contraintes d utilisabilités mais cet artefact n est pas sous la responsabilité directe du concepteur d interface ; la gestion des environnements pour la charte ergonomique du projet ; 2.2 Problèmes soulevés par l approche mise en oeuvre dans RUP La conception d interface limitée à l expression des besoins Une des critiques qui revient souvent sur la mise en oeuvre dans RUP de la conception d interface utilisateur est la restriction des activités de conception d interface au workflow recueil des besoins. Une démarche centrée utilisateur se doit en effet, de couvrir l ensemble des étapes du processus. Daylight 2001 Démarche ergonomique et RUP 5/5
Kruchten argumente que cette restriction ne limite pas le rôle de concepteur d interface à une phase particulière du projet, du fait de la nature itérative du processus. Cependant l expérience montre que les problématiques d utilisabilité apparaissent tout le long du processus à différentes étapes d une même itération. Pour certain auteur, le positionnement du prototype dans le cadre du workflow recueil des besoins pose un autre problème. En effet, l expression des besoins vient généralement avant l élaboration d une solution dont le prototype fait partie. Le risque est de se fermer trop tôt dans une solution. Il faut cependant noter que dans RUP, le prototype est l une des dernières étapes de ce workflow. Remarque : La dernière version de RUP V. 2001A.04.00 comprend un nouveau roadmap «Usability Engineering». Cependant ce document ne remet pas en cause la discussion ci-dessus. Pour une discussion plus complète se reporter au chapitre suivant. Un rôle qui ne couvre que partiellement les aspects d utilisabilités Dans RUP, le rôle de concepteur d interface utilisateur est plus proche d un «ingénieur IHM» dans la terminologie française que d un ergonome. Il doit modéliser et définir visuellement l interface, mais pas nécessairement fournir des compétences en ergonomie et en utilisabilité sauf éventuellement dans le cas du prototypage. Un des rares documents qui répertorie les critères d utilisabilité de l interface, l artefact spécifications supplémentaires, est sous la responsabilité de l analyste système, le concepteur d interface utilisateur n est même pas cité dans les rôles amenés à intervenir sur ce document. Dans une 1ère approche pour couvrir les développements d application Web [Rational WP 99], un rôle de directeur artistique (creative designer) avait été ajouté, mais toujours pas de rôle ayant en charge les aspects d utilisabilité. De ce fait, il n existe pas de rôle clairement définit pouvant prendre en charge les aspects liés à l utilisabilité d une interface. Remarque : La dernièreversionderup V. 2001A.04.00 comprend un nouveau roadmap «Usability Engineering». Cependant ce document ne modifie pas le rôle du concepteur d interface et ne remet pas en cause la discussion ci-dessus. Pour une discussion plus complète se reporter au chapitre suivant. 2.3 RUP, un processus centrée architecture plutôt qu utilisateur UP est un processus «centré-architecture»,itératif, se basant largement sur la modélisation UML et faisant référence à un ensemble de «meilleures pratiques» issus de l expérience Rational dans le domaine du génie logiciel. Mais les concepts d'utilisabilité ou d approche centrée utilisateur ne sont que très partiellement intégrés. 2.3.1 Les concepts de l approche centrée utilisateur Il existe un document dans RUP décrivant les «concepts» de l approche centrée utilisateur[rup User-Center-Design], qui reprend de façon théorique cette dernière. Mais elle n est mise en œuvre que partiellement dans la version actuelle de RUP. Le document s appuie sur quatre concepts issus de Gould [Gould 1988] : réflexion centrée sur les utilisateurs ; intégration avec le design ; tester l interfaceauplustôt; conception itérative. Ces quatre points sont analysés ci-dessous. Réflexion centrée sur les utilisateurs,l intégration des utilisateurs dans le processus est peu développée dans RUP et plusieurs techniques ergonomiques doivent venir compléter les «workshop» existant (Requirement Workshop, Use-Case-Analysis Workshop,..) dont aucun ne fait explicitement référence aux problématiques d utilisabilité : RUP reconnaît clairement cet aspect Daylight 2001 Démarche ergonomique et RUP 6/6
«In the Rational Unified Process, workshops are used at several key stages, but these must be complemented by the kinds of activities Gould describes if an accurate picture is to be formed.» [RUP User-Centered-Design] Intégration avec le design, RUP propose de créer un modèle du domaine reprenant les concepts et la terminologie des utilisateurs lors de l expression des besoins. Certaines des classes du domaine deviendront des classes frontières du système. Cependant cette approche est difficile à mettre en œuvre. Dans la pratique les modèles du domaine réalisés par les analystes sont souvent éloignésdumodèle conceptuel des utilisateurs. Au sens de l ergonomie cognitive, le modèle conceptuel de l utilisateur est la façon dont ce dernier se représente le comportement d un système tandis que le modèle du domaine se concentre sur l organisation ou la façon dont le système fonctionne - ensemble de classes et d objets du système favorisant la réutilisation, nécessaires au bon fonctionnement du logiciel. Cette difficulté est mise en avant par William Hudson [Harmelen 2001]. Tester l interface au plus tôt dans RUP ce point est pris en compte dans l activité prototypage de l interface utilisateur dans le cadre du workflow recueil des besoins. C est un des rares moments ou l on envisage explicitement l intervention d un expert en utilisabilité, mais uniquement en tant qu expert externe au projet pouvant donner un avis sur l interface (ce point n est d ailleurs pas développé dans RUP). Mais en dehors de l activité de prototypage, RUP ne précise pas à quel moment mettre en oeuvre les tests d utilisabilité: «Each project team needs to consider these challenges against the unique project environment they are working within, and arrive at the appropriate timing, method and approach to usability testing» [RUP Usability Testing]. Remarque : Cette imprécision est en partie corrigée dans le roadmap «Usability Engineering» [RUP Usability Engineering], qui fait référence à ces tests d utilisabilité dans les dernières phases de construction et de transition, mais en dehors de document ce point n'est pas développé. Conception itérative, Cet aspect ne pose pas de problème avec RUP qui s appuie largement sur une démarche itérative. Pour une analyse complémentaire de la mise en œuvre de démarches ergonomiques ou de techniques favorisant l utilisabilité des logiciels développés dans RUP, on peut se référer à la série d article de David Anderson [Anderson 2001, 10/1999, 2/1999] ou aux travaux de Constantine et Lockwood [Constantine 1999]. 2.3.2 Vers un renforcement de l approche centrée utilisateur dans RUP? L avant dernière version de RUP avait était l occasion de l ajout d un document «concept d utilisabilité»associé au workflow recueil des besoins [RUP User-Centered-Design]. La dernière versionderup V. 2001A.04.00 comprend quant à elle un nouveau roadmap «Usability Engineering» [RUP Usability Engineering]. Ce dernier document développe comment les techniques ergonomiques sont mises en œuvre dans RUP. Il a deux mérites importants à nos yeux : La 1 ère est de mettre en avant les problématiques ergonomiques. Dans la version précédente le document concepts d utilisabilitéétait associé au workflow recueil des besoins, alors que ce dernier document apparaîtdèslaprésentation du Processus, rubrique «Overview». La deuxième est d envisager explicitement le rôle des techniques d utilisabilité dans tous les workflow et phase du processus. Cependant ce document ne remet pas en cause l analyse précédente. En effet il n y a toujours pas de rôle dédiéàl utilisabilité et si l impact des techniques ergonomiques dans les autres workflow est envisagé,iln induit pas de modification dans les activités actuelles du processus ou dans les rôles, voir même dans les artefacts. Daylight 2001 Démarche ergonomique et RUP 7/7
3. Les «use-case» RUP s appuie largement sur la modélisation UML et notamment sur les cas d utilisation (use-case) qui permettent d assurer la tracabilité entre l ensemble des modèles. Ces derniers sont notamment utilisés dans l enchaînement des tâches liés au recueil des besoins lors du quel la majeure partie des activités de conception d interface prennent place dans RUP. Les cas d utilisations comme support à la modélisation d une interface utilisateur posent cependant de nombreux problèmes. Ces différents points sont revus rapidement ci-dessous. 3.1 Des définitions multiples Les cas d utilisations ont été mis en œuvre par Ivar Jacobson à la fin des années 80, pour décrire le comportement d un système du point de vue de l utilisateur. Mais le flou sur la description de leur mise en œuvre a permis un nombre important d interprétation. Une des 1ère définition est donnée par Jacobson : «Un cas d utilisation est une façon spécifique d utiliser le système en utilisant certaine partie des fonctionnalités. Un cas d utilisation constitue une séquence complète d interaction qui prennent place entre un acteur et le système» [Jacobson 1992] UMLtentedepréciser cette définition: «la spécification d une séquence d actions, incluant des variantes et séquences d erreurs, qu un système, un sous-système ou une classe réalisent en interagissant avec des acteurs externes (au système)» [Rumbaugh 1999].» UP met l accent sur la valeur ajouté pour l utilisateur «Un cas d utilisation spécifie une séquence d actions, avec ses variantes, pouvant être effectuée par le système et produisant un résultat satisfaisant pour un acteur particulier» [Jacobson al. 2000] 3.2 Un point de vue qui a évolué Malgré l accent mis sur la «satisfaction d un acteur» dans UP, les cas d utilisation se sont progressivement éloignésdel approche originelle centréesur«l usage» pour aller vers une approche plus centréesurl architecture (system-centric). Les auteurs de UP mettent surtout en avant le système : «le modèle des cas d utilisation saisit tous les besoins fonctionnels du système» [Jacobson al. 2000] et non de l utilisateur! Cela peut apparaître anodin, mais le point de vue pris a des impacts importants pour l emploi des cas d utilisation lors de la réalisation des interfaces utilisateurs. Un des problèmes rencontrés vient de l introduction de la notion d acteur, - «Someone or something, outside the system that interacts with the system» [Glossaire RUP] - qui a entraîné un nombre important de confusion entre les différents concepts : utilisateurs, rôles et acteurs. Le fait notamment qu un acteur peut être un utilisateur ou un autre systèmefaitperdredevulerôle pouvant être joué par un utilisateur humain. Pour cette raison Constantine et Lockwood préfèrent parler de «rôle utilisateur» i.e. un rôle joué par un «acteur humain», à distinguer d un «acteur système» [Constantine 1999]. 3.3 Des cas d utilisation «essentiels» Constantine et Lockwood ont par ailleurs développé une nouvelle forme de cas d utilisation les cas d utilisation essentiels (essentiel use-case) [Constantine 1999]. L idée et de prendre un point de vue différent lors de l élaboration des use-case en mettant l accent sur les intentions de l utilisateur - plutôt que la liste des actions effectuées par l utilisateur et les responsabilités du système - plutôt que les réponses du système. L objectif est de mettre l accent sur les besoins des utilisateurs et de ne pas prendre en comptes les contraintes d implémentation afin de ne pas figer à priori l interface utilisateur. Daylight 2001 Démarche ergonomique et RUP 8/8
«A single, discrete, complete, meaningful, and well-defined task of interest to an external user in some specific role or roles in relationship to a system, comprising the user intentions and system responsibilities in the course of accomplishing that task, described in abstract, technology-free, implementation-independent terms using the language of the application domain and of external users in role.» [Constantine 1999] Cette approche est citée rapidement dans UP [Jacobson al. 2000] et dans les concepts RUP [RUP User-Centered-Design] ainsi que dans le guide RUP pour la réalisation des «storyboard» : «Start by clarifying the use case itself - not its user interface. Start by keeping the description independent of the user interface, especially if the use case is unexplored. This will help you capture the essence of the use case, similar to the "essential use cases" described in Concepts: User-Centered Design. Then, later on, as the use case is understood, the flow of events - storyboard can be augmented with user interface and usability aspects» [RUP Guidelines: Use- Case Storyboard ] Mais la description de la mise en œuvre des cas d utilisation essentiels reste limitée et peut facilement passer inaperçue par les concepteurs utilisant RUP. 4. Prise en compte de l approche ergonomique dans RUP Il existe des possibilitésréelles de mettre en oeuvre une approche centrée utilisateur en s appuyant sur RUP, mais cette approche n est que partiellement intégrée rendant difficile sa mise en œuvre systématique. Gulliksen, Göransson et Lif [Harmelen 2001] ont analysé plusieurs grands projets utilisant RUP. Leur conclusion est que dans l état actuel, les seuls projets ayant réussis à prendre en compte correctement les aspects d utilisabilité sont ceux ayant intégré un expert en utilisabilité rompu aux différentes techniques ergonomiques. A l opposé les projets ayant eu des problèmes importants d utilisabilité ne disposaient pas d un support de la méthode suffisant. L utilisabilité d une interface a été reconnue comme un enjeu important pour la réussite d une application, notamment dans le cas des sites web, tant pour des aspects de coût, de manque à gagner, que de risque, par l ensemble des acteurs du marché. Après ce constat deux orientations peuvent être prises, développer une nouvelle méthode tels que User Interface Modeling - UIM de Gulliksen, Göransson et Lif [Harmelen 2001] ou Usage Center Design développé par Constantine et Lockwood [Constantine 1999], ou tenter de s appuyer sur les méthodes existantes pour qu elles prennent mieux en compte les approches centrés-utilisateur. De part les possibilités existantes dans RUP permettant de mettre en œuvre des démarches centréutilisateur même si elles sont insuffisantes, et des évolutions actuelles de RUP, il nous semble plus intéressant dans l état d adopter la 2 ème approche. La mise en œuvre dans RUP des évolutions proposées ci-dessous, peut se faire progressivement. L évolution d un processus de développement pose en effet de nombreux problèmes tels que la disponibilité des ressources, la formation ou tout simplement l évolution d une culture d entreprise. 4.1 Définir une démarche centrée utilisateur L ISO 13407, Human-Centered Design Process for Interactive Systems - [ISO 13407], définit quatre principes de bases, devant être respectés par les approches centrées-utilisateur : - une répartition appropriée des fonctions entre système et utilisateurs, -l implication active des utilisateurs, - des solutions interactives de Design, -lamiseenœuvre de groupes interdisciplinaires Daylight 2001 Démarche ergonomique et RUP 9/9
Une des problématiques relevéslorsdel analyse précédente est que, malgré un grand nombre de possibilités de support de ces différents aspects d une démarche centréesurl utilisateur, il n existe pas d approche clairement définie, guidant suffisamment les équipes de projet pour mettre en œuvre ces techniques. Nous explorerons ci-dessous les solutions pouvant permettre d améliorer la prise en comptes d une démarche ergonomique dans RUP. Certaines de ces solutions sont inspirés des auteurs tels que William Hudson, d autres sont issues de l expérience des consultants Daylight dans la réalisation de projets internet ou intranet faisant intervenir systématiquement des ergonomes. Les axes explorés sont : l intégration d un rôle prenant en charge clairement les aspects d utilisabilité dans les équipes de projets ; étendre le champ d intervention de ce nouveau rôle au-delà du recueil des besoins ; l introduction explicite de nouvelles activités et techniques liées aux problématiques d utilisabilité ; la mise en œuvre systématique des cas d utilisation essentiels ; Ces évolutions sont en cours de test sur des projets pilotes et évolueront selon les retours d expériences et les remarques sur le présent document. 4.2 Un nouveau rôle Un 1er axe de travail pour mieux intégrer la problématique ergonomique dans RUP est de définir un nouveau rôle, distinct du concepteur d interface utilisateur (UIDesigner) actuellement présent dans RUP : Le rôle doit avoir des compétences reconnues en ergonomie que ce soit en terme de maîtrise des standards et pratiques (bonnes et mauvaises) du marché, de connaissance de la charte ergonomique de l entreprise mais surtout des techniques ergonomiques tels que l analyse à partir de grille de critères, l observation des utilisateurs en contexte,. permettant de faciliter l élaboration d une interface répondant aux critères d utilisabilité ; Il peut reprendre certaines activités du concepteur d interface à sa charge tels que le prototypage et la rédaction de la charte ergonomique de projet, par contre il laisse au concepteur d interface ou à l analyste la responsabilité des cas d utilisation et de l identification des classes frontières ; il intervient en tant que support aux équipes de projet tout le long du processus. Généralement ce type de rôle ne travaille pas en solitaire mais plutôt dans le cadre d équipe pluridisciplinaire : ergonomes, analyste, directeur artistique, utilisateur final et stakeholder (commanditaire ou intervenants tel que traduits dans [Jacobson al. 2000]). Ce dernier point nous paraît particulièrement important, l expérience nous a montré que les problèmes de choix sur la mise en œuvre d une fonctionnalité en terme d interface ne sont pas tous régléslorsdel expression des besoins. Ce profil est proche de celui donnéélaboré par Gulliksen, Göransson et Lif [Harmelen 2001]. Il correspond aussi à la réalité du terrain. C est le cas des projets internet réalisés par Daylight mais aussi par de nombreuse société que se soit en France ou aux Etats Unis. La dénomination de ce rôle (ou travailleur tel que traduit dans [Jacobson al. 2000] ) peut rester concepteur d interface utilisateur, mais il nous semble que cela risque de porter à confusion et n insiste pas suffisamment sur la compétence en utilisabilité ou en ergonomie. Nous proposons donc de dénommer ce rôle simplement «ergonome» ou «usable expert» en anglais tels que généralement dénommé sur le marché actuel. Daylight 2001 Démarche ergonomique et RUP 10/10
4.3 Etendre le champ d intervention Le concepteur d interface intervient dans RUP uniquement lors de l enchaînement d activité liée à l expression des besoins et de façon plus sommaire dans le cadre des environnements. Le concepteur d interface utilisateur dans RUP aujourd hui : Disciplines Requirements Environment Objectif de la Disciplines Expression des besoins pour le système à réaliser Préparation de l environnement projet Activité du concepteur d interface utilisateur Modéliser l interface Prototyper l interface Rédiger la charte ergonomique Remarques : Dans la dernière version de RUP [RUP Usability Engineering] les activitésetles artefacts important pour l utilisabilité d une application sont développés pour l ensemble des disciplines, mais ne sont pas sous la responsabilité directe ou indirecte du concepteur d interface utilisateur. Nous proposons dans le paragraphe suivant d étendre le périmètre d action de l ergonome à l ensemble du processus de développement. Son rôle peut être plus ou moins important selon les différents workflow, mais sa disponibilité notamment en support aux équipes de projet nous paraît indispensable pour assurer la réussite des projets ayant une forte composante d interactivité et en particulier des projets internet ou intranet. De nombreuses techniques ergonomiques peuvent être déployées sur un projet. Leur mise en œuvre dépend de facteurs tels que : L ampleur du projet ; Les enjeux ; La cible utilisateur (disponibilité par exemple) ; Les contrainte en délais et coût La disponibilité en terme de support (ergonome, techniques documentées, ) ; Une analyse des différentes techniques mise en œuvres et des fréquences d utilisation est donné par William Hudson dans [Harmelen 2001]. Elles vont de l évaluation d expert, au prototypage en passant par l observation des utilisateurs, l analyse des tâches, l analyse de contexte, l analyse critériologiques, la mise en œuvre de «focus group»,lescasd utilisation essentiels, la rédaction de charte ergonomique,. Certaines de ces techniques peuvent donner lieu à une activitéàpart entière, mais la plupart viennent s intégrer dans des activités existantes de RUP. La mise en œuvre de ces activités dans les différents workflow est présentée ci-dessous. Daylight 2001 Démarche ergonomique et RUP 11/11
L ergonome, un champ d intervention plus étendu : Disciplines Business modeling Requirements Objectif de la Discipline Elaboration de la vision Objectif et Cible Rentabilité Expression des besoins pour le système à réaliser Activités et techniques mises en œuvre par l ergonome Définir le profil et le contexte utilisateur en mettant à jour les artefacts : "business vision, business actor, glossary " Affiner la cible et profils des utilisateurs, observation sur site Si besoin mise en œuvre de focusgroup en relation avec le marketing Analyse critériologique d applications ou de sites existant Valider les principales règles et orientations devant être respectées par l interface en mettant à jour les artefacts : "actors, supplementary specification, storyboard, charte ergonomique, " Analyse des tâches Storyboard Intégration avec le design graphique Prototypage de l interface (papier et électronique) Définition du système de navigation (pour les applications web notamment) Analysis and design Spécification du système Support aux analystes et validation des spécifications de l interface Implementation Code exécutable Support aux équipes de développements Test Recette Tester l utilisabilité Analyse d application existante pour identifier les points à améliorer Observation et expérimentation sur le prototype check-list / analyse critériologique évaluation d experts sur l exécutable finalisé Environment Préparation de l environnement projet Rédiger la charte ergonomique et éventuellement préciser le rôle de l ergonome et la mise en œuvre des techniques ergonomique dans l artefact "Development case" Il nous semble aussi intéressant de systématiser l utilisation des «cas d utilisation essentiels» [Constantine 1999] afin de limiter les problèmes identifiés au chapitre précédent. L objectif est en effet de ne pas imposer un mode d implémentation à priori. Cependant cette activité n est pas nécessairement sous la responsabilité de l ergonome, même s il peut y participer. Daylight 2001 Démarche ergonomique et RUP 12/12
4.4 Vue synthétique du rôle d ergonome Le schéma suivant représentelerôle d ergonome, les activités et les artefacts associésdécrits cidessus. Charte ergonomique d'entreprise glossaire de projet cas d'utilisation essentiel analyste directeur artistique développeur Ergonome Définir le profil utilisateur Tester l'utilisabilité Prototyper l'interface Rédiger la charte ergonomique de projet Support aux équipes de projet stakeholder modifie utilisateur O O O acteurs spécifications complémentaires d'utilisabilité prototype dossier de test d'utilisabilité charte ergonomique de projet Daylight 2001 Démarche ergonomique et RUP 13/13
4.5 Un niveau de guidage à renforcer Au-delà de l intégration d un nouveau rôle et l identification d activités ou de techniques ergonomiques devant ou pouvant être mises en œuvre, il est nécessaire d améliorer le support de ces approches par un guidage plus explicite dans le processus. C est en effet un des points faibles identifiés lors des chapitres précédents. Ce-ci revient à adapter RUP pour : ajouter explicitement le rôle d ergonome (ainsi que directeur artistique et infographiste pour les sites web) ; faire apparaître clairement son rôle dans les différentes activités dont il est responsable ou dans les quels il intervient ; identifiés ces activités dans les workflow correspondant ; compléter les artefacts ou les mettre à jours ; ajouter des guides expliquant les techniques ergonomiques pouvant être mises en œuvre ; Ce travail est en cours au sein de Daylight, l objectif étant d obtenir un «canevas» associéàun «road map» permettant d intégrer rapidement cette approche dans RUP. 5. Mise en œuvre progressive L adaptation d un processus de développement logiciel se fait généralement progressivement. C est d ailleurs la préconisation de Rational pour la mise en œuvre de RUP dans une organisation. Les axes d évolution cité ci-dessus peuvent facilement être mis en œuvre en plusieurs étapes. Un exemple de déploiement progressif est le suivant. L identification du rôle d ergonome est un bon début et même si son niveau d intervention est relativement réduit dans un 1 er temps, il permet de mettre l accent sur les aspects d utilisabilité d une interface et peut jouer efficacement le rôle de support auprès des équipes de projet ; Progressivement, son rôle peut être mieux identifié dans RUP et son intégration aux équipes de projet plus naturelle ; Le niveau de guidage peut être lui aussi progressivement renforcé dans RUP, afin de ne pas reposer uniquement sur l intervention de l ergonome, mais plutôt de sensibiliser progressivement et toujours les équipes de projets aux problématiques d utilisabilités; Des formations de type sensibilisation aux problématiques d utilisabilité (enjeux, risques, coûts ), ou de mise en œuvre des cas d utilisation essentiels doivent venir renforcer ce dispositif ; Comme pour toute mise en œuvre de RUP, l adaptation du processus doit aussi prendre en compte les spécificités des projets et la culture d entreprise. Daylight 2001 Démarche ergonomique et RUP 14/14
6. Annexe 6.1 Bibliographie Ouvrages et articles [Armour al.2001] Advanced Use Case Modeling F Armour, G Miller Addison Wesley 2001 [Constantine1999] Software for Use Larry L. Constantine, Lucy A.D. Lockwood Addison Wesley 1999 [Gould 1988] How to Design Usable Systems J. D. Gould Handbook of Computer Interaction 1988 [Harmelen 2001] Object Modeling and User Interface Design M.V. Harmelen Addison Wessley 2001 [ISO 13407] Human-Centered Design Process for Interactiv Systems ISO 13407 1999 [ISO 9241] Software Ergonomics for office work with visual display terminals ISO 9241 1998 [Jacobson 1992] Object-Oriented Software Engineering: A Use Case Driven Approach I.Jacobson, M Christerson, P Jonsson, G. Övergaard Addison-Wesley 1992 [Jacobson al. 2000] Le Processus Unifié de développement logiciel I.Jacobson, G. Booch, J.Rumbaugh Ed.Eyrolles 2000 [Kruchten 2000] The Rational Unifed Process an Introduction, Second Edition P. Kruchten Addison Wesley 2000 [Pian et co. 2002] Techniques ergonomiques pour la conception d interfaces Christian Pian et co. Daylight 2002 [Rumbaugh 1999] The unified Modeling Language Reference Manual J.Rumbaugh I.Jacobson, E. Booch, Addison-Wesley 1999 Ressources en lignes [Anderson 2001] UI Rupture Uidesign.net David Anderson jan. 2001 http://www.uidesign.net/2000/opinion/uirupture.html [Anderson 10/1999] Use Cases still considered Dangerous David Anderson oct. 1999 http://www.uidesign.net/1999/imho/oct_imho.htm/ [Anderson 2/1999] Are Use Cases the death of good UI Design? David Anderson feb. 1999 http://www.uidesign.net/1999/imho/feb_imho.html/ [Foruse-1] The Usability Challenge: Can UML and the Unified Process Meet It? Larry Constantine http://www.foruse.com/ [Foruse-2] Structure and Style in use cases for user interface design Larry Constantine Daylight 2001 Démarche ergonomique et RUP 15/15
http://www.foruse.com/ (un des chapitres du livre "Object Modeling and User Interface Design") [Ratioanl Edge Rational Edge Magazine en ligne qui aborde un certain nombre de sujets complémentaires. www.therationaledge.com [RUP User-Centered-Design] Concept : User-Centered Design RUP, rubrique Concepts du Requirement Discipline v. 2000 et suivant [RUP Usability Testing] Concept : Usability Testing RUP, rubrique Concepts de Testing Discipline v. 2000 et suivant [RUP Usability Engineering] Roadmap : Usability Engineering RUP, rubrique Roadmap de Overview v. 2001A.04.00 [Rational WP 99] Building Web Solution with the Rational Unified Process White paper 1999 http://www.rational.com/products/whitepapers/101057.jsp 6.2 Traduction française de la terminologie utilisée La plupart de ces traductions sont issues du livre «Le Processus Unifié de développement logiciel» [Jacobson al. 2000]. Boundary classes - classes frontières Essential Use case cas d utilisation essentiel Requirements recueil des besoins Usability utilisabilité Use case cas d utilisation User interface designer - concepteur d interface utilisateur Workflow enchaînement des tâches. Dans la dernière version de RUP, pour les principaux workflow le terme est devenu disciplines. Daylight 2001 Démarche ergonomique et RUP 16/16