Concepts : Ingénierie de la convivialité

Rubriques
Concepts : 

IntroductionHaut de la page

L'ingénierie de la convivialité (appelée aussi conception centrée sur l'utilisateur) porte sur la construction de meilleurs systèmes en comprenant mieux les utilisateurs finaux, et en impliquant les utilisateurs dans le recueil des exigences, la conception de l'interface utilisateur et le test. Les concepts de base sont décrits dans Concepts : Conception centrée sur l'utilisateur, et doivent être lus avant l'étude de ce concept. Cette page de concept explique la façon dont le Rational Unified Process (RUP) traite actuellement les techniques d'ingénierie de la convivialité.

RôlesHaut de la page

Le RUP possède un certain nombre de rôles qui doivent prendre en charge les problèmes liés à la convivialité. L'l'analyste système et les spécificateurs d'exigences doivent posséder des compétences dans la collecte et l'analyse des informations sur les utilisateurs, leurs tâches et leur environnement, et dans l'expression de ces dernières sous forme d'artefacts d'exigences. Ce document fait l'objet d'une révision par le Réviseur de recueil des besoins . Les rôles du ../process/workers/wk_tstr.htm -- This hyperlink in not present in this generated websiteTesteur et de l'../process/workers/wk_tstanl.htm -- This hyperlink in not present in this generated websiteAnalyste de test consistent essentiellement à tester la convivialité. Le concepteur de l'interface utilisateur est responsable de la conception et de la "mise en forme visuelle" de l'interface utilisateur. L'Implémenteur choisit et/ou développe les composants de l'interface utilisateur pour construire une interface utilisateur qui fonctionne.

Le Chef de projet joue aussi un rôle majeur. Il permet aux utilisateurs d'être impliqués dans le processus de développement et s'assure que l'organisation de développement fait appel à du personnel possédant les compétences nécessaires pour construire des systèmes utilisables. D'autres rôles, tels que le ../process/workers/wk_depm.htm -- This hyperlink in not present in this generated websiteResponsable du déploiement, le ../process/workers/wk_crsdv.htm -- This hyperlink in not present in this generated websiteDéveloppeur de supports de cours et le ../process/workers/wk_tchwr.htm -- This hyperlink in not present in this generated websiteRédacteur technique, sont également chargés de veiller à ce que le système déployé soit utilisable.

DisciplinesHaut de la page

Les sections qui suivent décrivent les disciplines du RUP, en termes d'activités et d'artefacts importants pour la convivialité.

ExigencesHaut de la page

Du point de vue de la convivialité, la discipline Exigences s'attache à :

  • établir une compréhension des utilisateurs et de leurs exigences
  • identifier les cas d'utilisation les plus bénéfiques pour les utilisateurs.

Les activités et les artefacts spécifiques sont les suivants :

Activité Artefact Contenu lié à la convivialité
Identifier les demandes des parties prenantes Demandes des parties prenantes

Cette activité comporte une interview des utilisateurs, des questionnaires et des ateliers destinés à mieux comprendre l'utilisateur et l'environnement de l'utilisateur. Elle comprend les étapes ci-dessous :

Le ../webtmpl/templates/req/rup_stkreq.htm -- This hyperlink in not present in this generated websitemodèle pour l'artefact : Demandes des parties prenantes comporte un profil utilisateur détaillé, comprenant le niveau d'étude, les connaissances informatiques, l'expérience, l'environnement actuel, les attentes, les objectifs, etc. Il permet également de saisir une description des problèmes et des priorités du point de vue de l'utilisateur. Les demandes des parties prenantes sont la matière première à partir de laquelle la Vision est compilée.

Développer la vision Vision

La section Environnement de l'utilisateur du canevas Vision décrit l'environnement de travail des utilisateurs finaux, ou ce qu'ISO appelle Contexte environnemental [ISO 13407].

La section Profil de l'utilisateur du canevas Vision décrit le savoir-faire, les connaissances techniques, les critères de réussite, les livrables, etc. de l'utilisateur . C'est ce qu'ISO entend par Contexte utilisateur [ISO 13407].

Identifier les acteurs et les cas d'utilisation, Structurer le modèle de cas d'utilisation, Détailler un cas d'utilisation Modèle de cas d'utilisation

Le modèle de cas d'utilisation décrit les tâches (cas d'utilisation) exécutées par les utilisateurs (acteurs humains). Il permet la saisie des similarités et des relations entre les acteurs, en utilisant des relations de généralisation. Les acteurs sont liés aux cas d'utilisation par des relations de type "Ceci ressemble au "modèle de rôle" de Constantine" [CON99]. Les cas d'utilisation sont structurés et liés les uns aux autres et aux acteurs par le biais de relations d'association de communication, d'inclusion, de généralisation et d'extension.

Les ateliers sont une excellente façon d'impliquer l'utilisateur. Voir : ../process/workguid/wg_ucwsh.htm -- This hyperlink in not present in this generated websiteAtelier de cas d'utilisation

 

Acteurs

Les caractéristiques des acteurs humains sont saisies comme des attributs d'acteurs. Ces caractéristiques comprennent :

  • Le champ de responsabilités de l'acteur.
  • L'environnement physique dans lequel l'acteur utilisera le système.
  • Le nombre d'utilisateurs représentés par cet acteur.
  • La fréquence d'utilisation du système par cet acteur.
  • Le niveau de connaissances de l'acteur dans le domaine concerné.
  • Le niveau d'expérience de l'acteur en informatique.
  • Les caractéristiques générales de l'acteur, comme son niveau de savoir-faire (formation), ses origines (langue) et son âge.
 

Cas d'utilisation

Il peut s'agir des cas d'utilisation essentiels tels que décrits par Constantine [CON99] (voir Concepts : Conception centrée sur l'utilisateur pour une discussion des cas d'utilisation essentiels). Les conditions de convivialité spécifiques pour un cas donné peuvent être saisies comme des "exigences spéciales" dans la ../webtmpl/templates/req/rup_ucspec.htm -- This hyperlink in not present in this generated websitespécification du cas d'utilisation.
Détailler les exigences logicielles

Spécifications supplémentaires

Les spécifications supplémentaires permettent la saisie des exigences non spécifiées dans les cas d'utilisation. Celles-ci comprennent les exigences en matière de disponibilité et de performance qui peuvent être étroitement liés à la convivialité. Les exigences générales en matière de convivialité applicables à plusieurs cas d'utilisation sont saisies ici, ainsi que la législation et les normes de convivialité applicables (voir Concepts : Conception centrée sur l'utilisateur pour obtenir des détails sur la législation et les normes en matière de convivialité).
Revoir les exigences Demande de changement Un effort de développement axé sur l'utilisateur fait participer autant que possible les utilisateurs à toutes les revues des exigences.
Définir un vocabulaire commun Glossaire Définit les termes de vocabulaire communs spécifiques au domaine de l'utilisateur pour faciliter la communication et la compréhension entre les utilisateurs et le reste de l'équipe de développement.

Il existe certaines autres techniques qui peuvent être ajoutées aux activités ci-dessus concernant les exigences.

    • La création de graphiques par affinité [HOL96, BEY98] est une technique qui consiste à placer chaque information concernant les utilisateurs et leurs tâches sur un papillon adhésif amovible. Les utilisateurs et les analystes collaborent pour réunir les papillons connexes par groupes conceptuels ou " affinités". Cette activité permet d'avoir une compréhension commune des problèmes, de leur importance relative et de leurs rapports.
    • Le tri de fiches [CON99] est une activité similaire dans laquelle les informations figurant sur des fiches sont organisées en groupes. Il est également possible de trier les fiches par ordre d'importance, de fréquence, etc.
    • La modélisation hiérarchique des tâches [MAY99, CON99] analyse les tâches actuellement exécutées par les utilisateurs et les organise pour former une hiérarchie. La hiérarchie doit refléter la façon dont les utilisateurs comprennent l'organisation de leurs tâches.

Analyse et conception Haut de la page

Un certain nombre d'autres activités dans cette discipline s'attachent à la mise en forme et à la conception de l'interface utilisateur. Elles sont énumérées ci-dessous :

Activité

Artefact

Contenu lié à la convivialité

Concevoir l'interface utilisateur

Storyboard

Carte de navigation

Cette activité consiste à créer ce qu'on appelle une "conception conceptuelle" [FER01]. Il s'agit de la première abstraction de l'interface utilisateur elle-même, qui définit les principaux chemins de navigation et fenêtres présentés à l'utilisateur. Cette activité porte surtout sur les cas d'utilisation qui pilotent la conception de l'interface utilisateur.

Les cartes de navigation, voir[CON99], donnent une vue d'ensemble des chemins de navigation entre des espaces d'interaction (écrans, fenêtres et boîtes de dialogue).

Prototyper l'interface utilisateur Prototype d'interface utilisateur

Il existe trois types de prototypes principaux :

Dessins (sur papier)
Bitmaps (outil de dessin)
Fichiers exécutables (interactif)
Dans la plupart des projets, vous devez utiliser ces trois prototypes, dans l'ordre indiqué ci-dessus.

L'intérêt essentiel de la création d'un prototype d'interface utilisateur consiste à être capable d'exposer et de tester à la fois la fonctionnalité et la convivialité du système avant de lancer réellement la conception et le développement. De cette façon, vous pouvez être sûr que vous construisez le système qui convient avant de dépenser trop d'argent et de ressources pour le développement.


Les techniques qui suivent peuvent s'avérer également utiles pour concevoir l'interface utilisateur :

    • Le tri de fiches [CON99], décrit précédemment, est également utile pour concevoir l'interface utilisateur. Chaque élément du menu ou élément de contenu est représenté par une fiche, puis les utilisateurs organisent les fiches en groupements logiques.

En plus des activités décrites ci-dessus, les activités d'analyse et de conception indiquées ci-dessous sont à utiliser en complément pour la conception de l'interface utilisateur :

Activité

Artefact

Contenu lié à la convivialité

Analyse de cas d'utilisation Classe d'analyse,
Réalisation de cas d'utilisation

Voir également les documents suivants :

Conception de classe

Cette activité utilise les résultats de la conception et du prototypage de l'interface utilisateur et conçoit les classes. Contrairement aux prototypes, il ne s'agit pas d'une interface utilisateur conceptuelle abstraite : l'objectif recherché est de représenter la conception du système livré.

Voir également les principes et conseils suivants :

Principes et conseils : Concevoir des applications Web avec UML


Implémentation Haut de la page

L'implémentation de l'interface utilisateur suit l'enchaînement d'activités d'implémentation de base. Notez que l'implémentation de l'interface utilisateur est souvent effectuée dans le cadre de l'activité de conception.

Test Haut de la page

Les tests de convivialité, y compris les ../process/workflow/test/co_perfo.htm -- This hyperlink in not present in this generated websitetests de performance liés à la convivialité, doivent débuter aussitôt qu'il y a des maquettes ou des prototypes exécutables de l'interface utilisateur. Les tests doivent comporter la vérification des exigences liées à la convivialité et à la performance, définies dans les spécifications supplémentaires ou comme des "exigences spéciales" dans la ../webtmpl/templates/req/rup_ucspec.htm -- This hyperlink in not present in this generated websitespécification du cas d'utilisation.

Déploiement Haut de la page

Les utilisateurs doivent être fortement impliqués dans les activités de test ../process/workflow/deployme/wfs_dep10.htm -- This hyperlink in not present in this generated websiteDétails de l'enchaînement d'activités : Test bêta du produit, ainsi que dans les tests de convivialité finaux, dans le cadre de ../process/workflow/deployme/wfs_dep3.htm -- This hyperlink in not present in this generated websiteDétails sur l'enchaînement d'activités : Gérer le test d'acceptation.

Les activités ../process/workflow/deployme/wfs_dep2.htm -- This hyperlink in not present in this generated websiteDétails de l'enchaînement d'activités : Développer le matériel de support comprennent le développement du matériel de formation et du matériel de support du système pour permettre aux utilisateurs finaux de se servir du produit logiciel fourni.

Gestion de projet Haut de la page

La ../process/workflow/ovu_mgm.htm -- This hyperlink in not present in this generated websitegestion de projet est l'art de savoir trouver un équilibre entre des objectifs contradictoires, de gérer les risques et de surmonter les contraintes, pour fournir un produit qui réponde aux besoins à la fois des clients (ceux qui règlent les factures) et des utilisateurs. Vu sous l'angle de l'ingénierie de la convivialité, l'activité la plus importante est Activité : Définir l'organisation du projet et le personnel. Cette activité définit la structure organisationnelle, les interfaces externes, ainsi que les rôles et responsabilités. Cela implique de définir à quel point les utilisateurs seront impliqués dans le processus de développement et de déterminer si les développeurs doivent posséder une expérience des méthodes d'ingénierie de la convivialité.

Environnement Haut de la page

La ../process/workflow/ovu_env.htm -- This hyperlink in not present in this generated websitediscipline Environnement inclut la définition du processus de développement que doit suivre un projet ou une organisation. L'../process/activity/ac_devca.htm -- This hyperlink in not present in this generated websiteActivité : Développer un cas de développement (../process/artifact/ar_devcs.htm -- This hyperlink in not present in this generated websiteArtefact : Cas de développement) définit les techniques d'ingénierie de la convivialité à appliquer, et la façon dont les différents artefacts et activités RUP seront personnalisés pour intégrer ces techniques.

Une autre activité importante est ../process/activity/ac_dvlprjspcgdl.htm -- This hyperlink in not present in this generated websiteActivité : Développer les principes et conseils spécifiques au projet, qui crée l'../process/artifact/ar_projspecgls.htm -- This hyperlink in not present in this generated websiteArtefact : Principes et conseils pour le projet, contenant des principes et conseils pour l'interface utilisateur. Ces principes et conseils contribuent à assurer la cohérence de l'interface utilisateur, ce qui peut représenter une aide importante pour la convivialité. Ils permettent aussi de définir les principes de convivialité à suivre, par exemple les principes et conseils pour les raccourcis, les fonctionnalités "d'annulation", les sorties reconnaissables, les interactions non modales, etc.

Développement itératif et phases Haut de la page

Le cycle de vie logiciel du RUP est décomposé dans le temps en quatre phases fonctionnelles, chacune d'elles s'achevant par un jalon majeur ; chaque phase correspond à un laps de temps entre deux jalons principaux. Une évaluation est effectuée à chaque fin de phase. pour déterminer si les objectifs de la phase ont été remplis. Une évaluation satisfaisante permet au projet de passer à la phase suivante.

On peut trouver à l'intérieur de chaque phase plusieurs itérations. Une itération est une boucle de développement complète qui débouche sur la livraison (interne ou externe) d'un produit exécutable, un sous-ensemble du produit final en développement, qui évolue de manière incrémentielle d'une itération à l'autre pour devenir le système final. La convivialité profite largement de cette approche itérative. Elle permet aux utilisateurs de fournir un retour précoce sur la convivialité, et évite de progresser trop loin sur une voie qui ne répondra tout simplement pas aux besoins des utilisateurs.

L'utilisateur doit être impliqué dans chaque itération, pour affiner davantage les exigences, pour évaluer les concepts de conception et pour tester/évaluer la convivialité à la fois des prototypes de justification du projet et du système en évolution.

Les sections qui suivent décrivent les critères d'achèvement de la phase liés à la convivialité pour chaque phase et les principales activités pour chaque phase.

Création Haut de la page

La phase de création comporte deux objectifs majeurs :

  • Définition de la portée et des frontières du projet, ce qui comprend une vision opérationnelle, des critères d'acceptation, les éléments qui doivent figurer dans le produit et ceux qui ne sont pas utiles.
  • Identification des cas d'utilisation importants du système, les scénarios de fonctionnement majeurs à partir desquels seront définis les compromis de conception.

Du point de vue de l'ingénierie de la convivialité, cela implique de se concentrer sur les activités de modélisation métier et de définition des exigences liées à :

  • l'établissement d'une compréhension des utilisateurs et de leurs besoins
  • l'identification des cas d'utilisation qui sont les plus avantageux pour les utilisateurs.

En outre, la phase de création est souvent un moment propice pour se pencher sur conception conceptuelle et le prototypage de "la démonstration du bien-fondé du projet". Ceci est vrai notamment lorsque les risques principaux du projet sont liés à l'interface utilisateur et aux questions de convivialité. Les tests de convivialité, y compris les ../process/workflow/test/co_perfo.htm -- This hyperlink in not present in this generated websitetests de performance liés à la convivialité, doivent débuter aussitôt qu'il y a des maquettes ou des prototypes exécutables de l'interface utilisateur.

Elaboration Haut de la page

Comme RUP est un processus itératif, les artefacts créés dans la phase de création sont revus et révisés avec les utilisateurs de façon à gérer la portée et de s'assurer que le système répond aux besoins de l'utilisateur.

Dans la phase d'élaboration, l'accent est mis sur l'architecture logicielle - y compris l'architecture de l'interface utilisateur. L'interface utilisateur conceptuelle est définie, et les éléments comportant des risques et/ou les éléments cruciaux de la conception de l'interface utilisateur sont implémentés. Les activités liées à l'architecture du système s'appliquent généralement à l'interface utilisateur - ce sont des produits prêts à utiliser qui doivent être évalués, des considérations sur la réutilisation, une sélection des mécanismes et des patterns, etc.

Cette phase met en relief les activités de conception de l'interface utilisateur, ainsi que les activités de support, dans la discipline Analyse et conception. On a également recours à l'implémentation et aux tests puisque l'achèvement de l'élaboration nécessite la construction d'un système en état de fonctionnement, lequel doit pouvoir être évalué.

Les tests de convivialité et les ../process/workflow/test/co_perfo.htm -- This hyperlink in not present in this generated websitetests de performance liés à la convivialité, doivent se concentrer sur les exigences risquées définies dans les spécifications supplémentaires, ou en tant que'"exigences spéciales" dans la ../webtmpl/templates/req/rup_ucspec.htm -- This hyperlink in not present in this generated websiteSpécification du cas d'utilisation.

Construction Haut de la page

Dans la phase de Construction, l'accent est mis sur l'implémentation de cas d'utilisation supplémentaires. Cela implique des opérations d'ajout dans l'interface utilisateur, tout en restant fidèle au modèle conceptuel de l'interface utilisateur et aux principes et conseils pour l'interface utilisateur définisdans ../process/artifact/ar_projspecgls.htm -- This hyperlink in not present in this generated websitePrincipes et conseils spécifiques au projet. Les tests de convivialité continuent à être très importants lors de l'ajout de nouvelles caractéristiques.

Le choix des fonctionnalités à intégrer dans chaque itération repose sur la valeur qu'elles représentent pour les utilisateurs.

Transition Haut de la page

Dans la phase de transition, on commence à s'intéresser davantage à la discipline de ../process/workflow/ovu_dep.htm -- This hyperlink in not present in this generated websitedéploiement. Dans un effort de développement axé sur l'utilisateur, il ne faut pas attendre la phase de transition pour impliquer l'utilisateur. Toutefois, l'utilisateur continue à être impliqué, essentiellement pour apporter un retour d'information. Lorsque l'utilisateur a été impliqué tout au long du développement, les tests bêta et d'acceptation formels sont souvent réduits au minimum, voire inexistants. Au lieu de cela, des retours d'information détaillés et des approbations sont sollicités tout au long de l'effort de développement.

Le développement du matériel de formation et du matériel de support du système est finalisé au cours de la phase de transition, mais il doit être lancé, si possible, dans les phases précoces, de façon à permettre à l'utilisateur de fournir un retour d'informations.

A l'issue de la phase de transition, vous disposez d'un système opérationnel que les utilisateurs finaux peuvent utiliser. Il est bon de planifier au moins deux ou trois itérations pour la phase de transition ; ainsi, il est possible de corriger les problèmes survenus dans la version initiale et d'intégrer les principaux retours d'information des utilisateurs.



RUP (Rational Unified Process)   2003.06.15