Concepts :
L'ingénierie de convivialité (également appelée conception centrée sur l'utilisateur) consiste à construire de
meilleurs systèmes en se fondant sur une meilleure compréhension des utilisateurs et en impliquant ces derniers dans le
recueil des exigences, la conception de l'interface utilisateur et les efforts de test. Avant de lire ce concept, vous
devez consulter les concepts de base, décrits dans le Concept :
Conception centrée sur l'utilisateur. Cette page de concept explique comment le processus Rational Unified Process
(RUP) aborde actuellement les techniques d'ingénierie de convivialité.
Rôles
Le processus RUP comporte un certain nombre de rôles dont les responsabilités ont trait à la convivialité. L'analyste système et le spécificateur d'exigences doivent posséder des compétences propres au
recueil et à l'analyse des informations relatives aux utilisateurs, à leurs tâches et à leur environnement, ainsi qu'à
l'enregistrement de ces informations dans les exigences. Ce matériel est revu par le réviseur
de recueil des exigences. Les rôles testeur et analyste de test sont les principaux responsables du test de
convivialité. Le concepteur d'interface utilisateur est chargé de la conception et de
la "mise en forme visuelle" de l'interface utilisateur. L'implémenteur sélectionne et/ou développe des composants d'interface
utilisateur pour construire l'interface utilisable.
Le responsable de projet joue également un rôle clé. Il permet aux
utilisateurs d'être impliqués dans le processus de développement et garantit la mise à disposition, dans l'organisation
de développement, d'un personnel compétent pour la construction de systèmes conviviaux. D'autres rôles, tels que le responsable du déploiement, le développeur de cours et le rédacteur
technique, sont également chargés d'assurer la convivialité du système déployé.
Disciplines
Les sections suivantes décrivent les disciplines de RUP selon les activités et les artefacts les plus importants en
termes de convivialité.
Du point de vue de la convivialité, la discipline de recueil des exigences est axée sur :
-
la compréhension des utilisateurs et de leurs besoins
-
l'identification des cas d'utilisation les plus profitables aux utilisateurs.
Les activités et artefacts spécifiques sont les suivants :
Activité
|
Artefact
|
Contenu ayant trait à la convivialité
|
Recueil des demandes des parties prenantes
|
Demandes des parties prenantes
|
Cette activité consiste à mener des interviews, faire remplir des questionnaires et organiser des
ateliers afin de mieux comprendre l'utilisateur et son environnement. Ses composants sont les
suivants :
Le canevas de l'Artefact : Demande des parties prenantes enregistre un profil utilisateur détaillé,
comprenant la formation de l'utilisateur, ses connaissances informatiques, son expérience,
l'environnement existant, ses attentes, ses objectifs, etc. Il enregistre également une description
des problèmes et des priorités vus par l'utilisateur. Les demandes des parties prenantes
constituent la matière brute à partir de laquelle la vision est compilée.
|
Développer la vision
|
Vision
|
La section Environnement utilisateur du Canevas de vision décrit l'environnement de travail des
utilisateurs, ou ce que la norme ISO appelle Contexte environnement [ISO 13407].
La section Profil utilisateur du Canevas de vision décrit l'expérience de l'utilisateur, sa
formation technique, ses responsabilités, ses critères de réussite, ses livrables, etc. C'est ce
que la norme ISO appelle Contexte utilisateur [ISO
13407].
|
Identifier les acteurs et les cas d'utilisation, Structuration du 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) effectuées par les
utilisateurs (acteurs humains). Il enregistre les similitudes et les relations entre les acteurs, à
l'aide de relations de généralisation. Il fonctionne un peu comme le "Modèle de rôle" de
Constantine [CON99]. Les cas d'utilisation sont structurés et associés les uns
aux autres et aux acteurs, au moyen de relations d'association de communication, d'inclusion, de généralisation et d'extension.
Les ateliers sont un excellent moyen d'impliquer les utilisateurs. Voir : Atelier de cas d'utilisation
|
|
Acteurs
|
Les caractéristiques des acteurs humains sont enregistrées en tant qu'attributs d'acteurs. Ceux-ci
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 du domaine concerné.
-
Le niveau d'expérience de l'acteur en informatique.
-
Les caractéristiques générales de l'acteur, comme son niveau d'expertise (éducation), ses
origines (langue) et son âge.
|
|
Cas d'utilisation
|
Ces artefacts peuvent inclure des cas d'utilisation essentiels, tels qu'ils sont décrits par
Constantine [CON99] (voir Concept : Conception centrée sur l'utilisateur pour plus
d'informations sur les cas d'utilisation essentiels). Les exigences de convivialité spécifiques à un
cas d'utilisation donné peuvent être enregistrées en tant qu'"Exigences particulières" dans la
spécification du cas d'utilisation.
|
Détailler les exigences logicielles
|
Spécifications supplémentaires
|
Les spécifications supplémentaires enregistrent les exigences qui ne sont pas spécifiées dans les cas
d'utilisation. Elles comprennent les exigences de performances et de disponibilité qui peuvent se
trouver étroitement liées à la convivialité. On y trouve les exigences générales de convivialité
applicables à plusieurs cas d'utilisation, accompagnées de la législation et des normes applicables
relatives à la convivialité (voir Concept : Conception centrée sur l'utilisateur pour des informations
plus détaillées sur la législation et les normes relatives à la convivialité).
|
Gestion des dépendances
|
Attributs des exigences
|
A mesure que vous "découvrez" les cas d'utilisation et les exigences de convivialité, vous devez
remarquer leur importance ou leur avantage. Pour ce faire, vous devez consulter les utilisateurs et les
autres parties prenantes. Cet artefact peut également comprendre d'autres attributs, tels que la
fréquence d'exécution d'un cas d'utilisation.
|
Revue des exigences
|
Requête de changement
|
Un effort de développement centré sur l'utilisateur fait participer ce dernier le plus possible à
toutes les revues des exigences.
|
Définition d'un vocabulaire commun
|
Glossaire
|
Cette activité consiste à enregistrer des termes communs spécifiques au domaine de l'utilisateur, afin
de faciliter la communication et la compréhension entre les utilisateurs et le reste de l'équipe de
développement.
|
D'autres techniques peuvent apporter un complément utile à ces activités de recueil des exigences.
-
La réalisation d'un diagramme des affinités [HOL96, BEY98] est une technique au moyen de laquelle chaque information obtenue sur
les utilisateurs et leurs tâches est consignée sur un post-it. Les utilisateurs et les analystes collaborent
afin de regrouper les post-it associés dans des groupes de concepts ou des "affinités". Cette activité permet
de promouvoir une compréhension commune des problèmes, de leur importance relative et de leurs relations.
-
Le classement des cartes [CON99] est
une activité semblable au cours de laquelle les informations consignées sur les cartes d'index sont classées
par groupes. Ces cartes peuvent également être classées par ordre d'importance, de fréquence, etc.
-
La modélisation hiérarchique des tâches [MAY99, CON99] analyse les tâches actuellement effectuées par les utilisateurs et les
classe de façon hiérarchique. La hiérarchie doit refléter la manière dont les utilisateurs perçoivent
actuellement l'organisation de leurs tâches.
Dans cette discipline, un certain nombre d'activités sont axées sur la mise en forme et la conception de l'interface
utilisateur. Celles-ci sont les suivantes :
Activité
|
Artefact
|
Contenu ayant trait à la convivialité
|
Concevoir l'interface utilisateur
|
Storyboard
Carte de navigation
|
Cette activité crée ce que l'on appelle souvent la conception conceptuelle [FER01]. Il s'agit de l'abstraction initiale de l'interface
utilisateur, qui enregistre les principales fenêtres et chemins de navigation présentés. Cette
activité est axée sur les cas d'utilisation qui guident la conception de l'interface utilisateur.
Les cartes de navigation (voir [CON99]) donnent une vue d'ensemble des chemins de navigation
entre les espaces interactifs (écrans, fenêtres et boîtes de dialogue).
|
Création d'un prototype de l'interface utilisateur
|
Prototype d'interface utilisateur
|
Vous pouvez réaliser trois sortes principales de prototypes :
Des dessins (sur papier)
Des bitmaps (outils de dessin)
Des exécutables (interactifs)
Dans la plupart des projets, vous devez utiliser ces trois prototypes, dans l'ordre présenté
ci-dessus.
L'objectif principal d'un prototype d'interface utilisateur est de pouvoir exposer et "tester" à la
fois la fonctionnalité et la convivialité du système, avant le début du vrai dessin et du
développement. Ceci permet de vérifier que vous créez le bon système avant d'investir trop de
ressources et de temps dans le développement.
|
Les techniques suivantes peuvent également se révéler utiles à la conception de l'interface utilisateur :
-
Le classement des cartes [CON99],
décrit précédemment, est utile à la conception de l'interface utilisateur. Chaque élément de menu ou de contenu
est représenté par une carte, puis les utilisateurs classent les cartes dans des groupes logiques.
Les activités d'analyse et de conception suivantes sont complémentaires aux activités décrites ci-dessus :
L'implémentation de l'interface utilisateur suit l'enchaînement d'activités d'implémentation général. Notez que cette
implémentation rentre souvent dans le cadre de l'activité de conception.
Le test de convivialité et le test de
performances lié à la convivialité doivent commencer dès que des maquettes ou des prototypes exécutables de
l'interface utilisateur sont disponibles. Ces tests doivent consister à vérifier les exigences de convivialité et de
performances enregistrées soit dans les spécifications supplémentaires, soit en tant qu'"exigences
particulières" dans le cas d'utilisation.
Les utilisateurs doivent prendre une part importante à l' Activité : Soumission du produit au test bêta, ainsi qu'au test de convivialité final lors de l' Activité :
Gestion du test de réception.
L' Activité : Développer le matériel de support consiste à développer le
matériel d'apprentissage et le matériel de support système afin d'assurer une utilisation réussie du logiciel livré.
La gestion de projet est l'art de trouver le bon équilibre entre les
objectifs en conflit, de gérer les risques et de trouver des solutions aux contraintes, afin d'aboutir à la livraison
réussie d'un produit qui répond à la fois aux besoins des consommateurs (ceux qui paient la facture) et à ceux des
utilisateurs. Du point de vue de l'ingénierie de convivialité, l'activité la plus critique est la Tâche : Définir l'organisation et le personnel du projet. Cette
activité définit la structure organisationnelle, les interfaces externes, ainsi que les rôles et responsabilités. Elle
consiste à définir la mesure dans laquelle les utilisateurs seront impliqués dans le processus de développement et à
décider si les développeurs doivent posséder une certaine expérience concernant les méthodes d'ingénierie de
convivialité.
La discipline d'environnement consiste à définir le processus de
développement que doit suivre un projet ou une organisation. La Tâche
: Développer un plan de développement ( Produit : Plan de développement) définit les techniques d'ingénierie
de convivialité qui seront appliquées, et la manière dont les différents artefacts et activités RUP seront
personnalisées dans le but d'incorporer ces techniques.
La Tâche : Développer les instructions relatives aux projets aboutissant
au Produit : Instructions relatives au projet est une autre activité
importante, qui comprend les instructions relatives à l'interface utilisateur. Ces instructions permettent d'assurer la
cohérence de l'interface utilisateur, ce qui peut constituer un facteur important de convivialité. Elles enregistrent
aussi les principes de convivialité à suivre, tels que les instructions pour les raccourcis, les fonctions "annuler",
les fonctions "quitter" reconnaissables, l'interaction amodale, etc.
Le cycle de vie logiciel du processus RUP se décompose dans le temps en quatre phases séquentielles, chacune étant
conclue par un événement jalon principal ; une phase correspond donc à un intervalle de temps entre deux événements
jalons principaux. A chaque fin de phase, une évaluation est exécutée ( Tâche : Revue des événements jalons du cycle de vie) pour
vérifier si les objectifs de la phase sont atteints. Si le résultat de l'évaluation est satisfaisant, la phase suivante
du projet peut commencer.
Chaque phase peut comporter plusieurs itérations. Une itération est une boucle de développement complète qui produit
une version (interne ou externe) d'un produit exécutable, un sous-ensemble du produit final en développement, qui
évolue de façon incrémentielle d'une itération à l'autre jusqu'à devenir le système final. Cette approche itérative
donne de grands avantages à la convivialité. Elle permet aux utilisateurs d'envoyer très tôt leur retour d'informations
sur la convivialité et évite à l'équipe de s'égarer trop loin dans des solutions qui ne vont pas répondre aux besoins
de l'utilisateur.
L'utilisateur devrait participer à chaque itération, afin de préciser davantage les exigences, d'évaluer les concepts
de conception et de tester/évaluer la convivialité des prototypes de démonstration du bien-fondé de la conception, tout
comme celle du système en évolution.
Les sections suivantes décrivent les critères d'achèvement d'une phase liés à la convivialité, ainsi que les
principales activités de chaque phase.
Les deux objectifs clés de la phase de création
sont les suivants :
-
L'établissement de la portée logicielle du projet et des conditions de limites, incluant une vision d'exploitation,
des critères d'acceptation et ce qui est destiné être dans le produit et ce qui ne l'est pas.
-
La sélection des cas d'utilisation critiques du système et des scénarios d'exploitation primaires qui définiront
les principaux accords de conception.
Du point de vue de l'ingénierie de convivialité, cela revient à donner de l'importance aux activités liées aux
exigences et à la modélisation métier (le cas échéant), c'est-à-dire à :
-
la compréhension des utilisateurs et de leurs besoins
-
l'identification des cas d'utilisation les plus profitables aux utilisateurs.
La phase de création est aussi souvent l'occasion d'explorer une conception
conceptuelle et la création d'un prototype de "démonstration du bien-fondé de la conception". Cela est particulièrement
vrai lorsque les principaux risques du projet sont liés à l'interface utilisateur et à la convivialité. Le test de convivialité et le test de
performances lié à la convivialité doivent commencer dès que des maquettes ou des prototypes exécutables de
l'interface utilisateur sont disponibles.
Le processus RUP étant itératif, les artefacts réalisés lors de la phase de création sont revisités et revus avec les
utilisateurs, afin de gérer la portée et de vérifier que le système en évolution répond bien aux besoins desdits
utilisateurs.
La phase d'élaboration met l'accent sur l'architecture
logicielle, y compris l'architecture de l'interface utilisateur. Elle définit l'interface utilisateur conceptuelle
et implémente les éléments risqués et/ou critiques de la conception de cette interface. Les activités liées à
l'architecture logicielle s'appliquent en général à l'interface utilisateur : il faut évaluer des produits commerciaux,
réfléchir aux possibilités de réutilisation, sélectionner des mécanismes et des patterns, etc.
Cette phase met l'accent sur les activités de conception de l'interface utilisateur et sur les activités de support
provenant de la discipline d'analyse et de conception. L'implémentation et le test sont également des aspects
importants, puisqu'une phase d'élaboration ne s'achève qu'avec la construction d'un système qui fonctionne et peut être
évalué.
Le test de convivialité et le test de
performances lié à la convivialité doivent se concentrer sur toutes les exigences risquées enregistrées soit dans
les spécifications supplémentaires, soit en tant qu'"exigences
particulières" dans le cas d'utilisation.
La phase de construction met l'accent sur l'implémentation de plusieurs cas d'utilisation. Elle
doit pour cela effectuer des ajouts à l'interface utilisateur, tout en restant fidèle au modèle conceptuel de
l'interface, ainsi qu'aux instructions relatives à l'interface utilisateur enregistrées dans les instructions relatives au projet. Le test de convivialité garde son importance majeure au fur et à mesure des ajouts de
fonctionnalités.
Les fonctionnalités à placer dans chaque itération sont choisies en fonction de l'importance qu'y accordent les
utilisateurs.
La phase de transition commence à donner plus d'importance à la discipline de déploiement. Dans un effort de développement centré sur
l'utilisateur, vous ne devriez pas attendre la phase de transition pour impliquer les utilisateurs. Toutefois, ces
derniers continuent de participer, en particulier pour les retours d'informations. Lorsqu'ils ont été impliqués tout au
long du développement, les tests formels bêta et de réception sont souvent considérablement réduits, voire inexistants.
En effet, les retours d'informations détaillés de l'utilisateur ainsi que l'approbation ont eu lieu tout au long de
l'effort de développement.
Le développement du matériel d'apprentissage et de support système est finalisé pendant la phase de transition, mais
devrait, si possible, commencer lors des phases précédentes, afin de permettre le retour d'informations des
utilisateurs.
Dans la phase de transition, vous manipulez un système en fonctionnement et utilisable. Il serait bienvenu de planifier
au moins deux itérations pendant la transition, afin de pouvoir corriger les incidents rencontrés dans l'édition
initiale et intégrer les principaux retours d'informations des utilisateurs.
|