Concept: Ingénierie de convivialité
Ces instructions décrivent l'ingénierie de convivialité. 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 finals et en impliquant ces derniers dans le recueil des exigences, la conception de l'interface utilisateur et les efforts de test.
Description principale
Concepts : 

Introduction

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é.

Recueil des exigences

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.

Analyse et conception

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 :

Activité

Artefact

Contenu ayant trait à la convivialité

Analyse des cas d'utilisation Classe d'analyse
Réalisation des cas d'utilisation

Voir aussi :

Conception des classes

Cette activité utilise les résultats de la conception et du prototypage de l'interface utilisateur pour concevoir les classes. Contrairement aux prototypes, il ne s'agit pas d'un travail de brouillon conceptuel sur l'interface utilisateur, mais d'un travail destiné à représenter la conception du système livré.

Voir aussi les instructions suivantes :

Instructions : Conception d'applications Web avec UML


Implémentation

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.

Test

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.

Déploiement

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é.

Gestion de projet

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é.

Environnement

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.

Développement itératif et phases

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.

Création

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.

Elaboration

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.

Construction

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.

Transition

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.