03 September 2010

Inscrivez-vous au Flux RSS

Des Tests Exploratoires sous l’angle ergonomique

Posted by jc-Qualitystreet on 8 avril 2010

Les tests exploratoires se définissent comme l’apprentissage, la conception et l’exécution simultanée des tests. Pour faire simple, moins ces activités sont séparées, plus le niveau d’exploration est jugé élevé : on parle alors de tests exploratoires.

Dans l’univers des tests logiciels,  les tests exploratoires se distinguent donc clairement des techniques scénarisées (« scripted tests »), fondés sur des cas de test (valeurs d’entrée / script d’exécution / résultats attendus). Sur les projets IT, ils sont un complément très utile à ces tests « classiquement » scénarisés, notamment niveau interface, pour plus de feedback et peuvent les remplacer efficacement en cas de flou ou d’instabilité dans les exigences.

Aller plus loin… Vers un test exploratoire centré ergonomie

L’approche des tests exploratoires est plutôt récente et en pleine expansion, d’autant qu’elle colle plutôt bien aux nouvelles exigences de tests apparues avec les méthodes Agiles.

Interactive et créative, la démarche est en effet centrée avant tout sur le résultat plutôt que sur la conception, documentation et l’archivage de cas de tests (valeur et principes agiles). Elle se concentre aussi sur le métier de Testeur, ses compétences, son savoir-faire, bref sa valeur ajoutée.

Et l’évaluation cognitive experte dans tout cela, une technique reconnue depuis longtemps en ergonomie des logiciels ? Des tests exploratoires qui intègrent ce volet ergonomie apportent une richesse supplémentaire dans cette quête perpétuelle de la QUALITE et du BON PRODUIT et dans la recherche des défauts. C’est aussi un + pour le testeur dans sa connaissance du produit et des attentes des utilisateurs.

Les bénéfices sont évidents mais nécessitent de la part du testeur une montée en compétences sur sa connaissance des processus cognitifs humains ainsi que sur les principaux critères ergonomiques de conception.

Tester le système du point de vue de l’utilisateur : une raison d’opter pour le test exploratoire

Tests scénarisés vs Tests exploratoires : une question de moment et de STRATEGIE DE TEST. Toutefois, il est clair que s’engager régulièrement, par exemple à chaque sprint (contexte Agile) dans une session de test exploratoire, dans la peau des futurs utilisateurs, est aujourd’hui indispensable.

Concrètement, la technique va consister à simuler les processus utilisateurs en jeu avec le système, et à s’arrêter à chaque étape du processus pour vérifier que l’utilisateur peut enchaîner. Le testeur se met donc à la place de l’utilisateur, accomplit chaque tâche comme celui-ci le ferait, en s’arrêtant et en s’interrogeant à chaque écran :

  • les utilisateurs comprendront-ils quoi faire?
  • les utilisateurs comprendront-ils comment le faire?
  • les utilisateurs comprendront-ils les feedback?

Il va se fonder sur sa connaissance des facteurs humains et des processus cognitifs…

  • Attention
  • Perception et reconnaissance de l’information et des actions
  • Mémorisation
  • Apprentissage
  • Communication
  • Résolution de problème
  • Décision

… et sur des questions types à se poser, comme par exemple :

  • L’action correcte à engager  sera-t-elle évidente pour l’utilisateur ?
  • L’utilisateur va -t-il remarquer que l’action correcte est disponible ?
  • L’utilisateur va-il interpréter la réponse à l’action correctement ?

Une approche toujours structurée mais deux Prérequis pour déterminer l’oracle de test

Une session de test exploratoire obéit à des règles qui la cadrent. Elle est délimitée dans le temps, commence toujours par une charte de session et se termine toujours par un mini rapport de test rassemblant la liste des défauts et des problèmes identifiés ainsi que les principales notes produites.

Les tests exploratoires centrés sur l’ergonomie ont quant à eux deux pré-requis. Outre de très bonnes connaissances en ergonomie, une vision claire et complète des futurs utilisateurs du produit est également nécessaire avant de se lancer dans le test.

C’est là que les PERSONAS interviennent car pour se mettre dans la peau de ses utilisateurs, il faut bien les connaitre : leurs buts, les déclencheurs de leurs actions, leurs influences, leurs freins ou les bonnes surprises !

Agile CMMI : Voyage d’un coach agile au cœur de la gestion des exigences-REQM

Posted by jc-Qualitystreet on 6 octobre 2009

Première étape de mon parcours au travers d’un référentiel Agile CMMI, et premier billet d’une longue série qui s’adresse en priorité à mes lecteurs AGILISTES, aux praticiens CMMI et à ceux qui s’intéressent de prés ou de loin à l’amélioration des processus.

Ma posture est celle d’un coach agile qui accompagne une organisation cherchant à atteindre, pour diverses raisons, le niveau de maturité 3 CMMI, mais souhaitant garder un mode de fonctionnement agile fondé sur des pratiques SCRUM et XP.

Voici donc REQM, “Gestion des exigences“, l’un des 7 domaines du Niveau de maturité 2, dont l’intention est de « gérer les exigences des produits et composants de produits du projet et d’identifier les incohérences entre ces exigences et les produits d’activité du projet ».

La gestion des exigences (REQM) est avec RD (Développement des exigences) la base de ce qu’on appelle l’Ingénierie des exigences, des activités ô combien cruciales dans les projets informatiques. Les exigences sont fonctionnelles (« ce que les système doit faire ») ou non fonctionnelles (attributs de qualités, par exemple fondés sur l’ISO 9126).

Au programme, REQM dans une perspective Agile CMMI :

  1. Quels sont les objectifs spécifiques à satisfaire OBLIGATOIREMENT?
  2. Quelles sont les pratiques spécifiques initialement recommandées, et comment l’agilité se marrie-t-elle avec celles-ci?
  3. Quels sont les objectifs génériques à satisfaire OBLIGATOIREMENT ( Niveau 2 & 3), et comment se positionne l’agilité sur les pratiques génériques initialement recommandées?

1 OBJECTIF(S)SPECIFIQUES A SATISFAIRE OBLIGATOIREMENT POUR CMMI

REQM SG1 : Gérer les exigences
OK AGILE CMMI

Un seul objectif à satisfaire mais il est de taille. Les exigences sont gérées, et les incohérences avec les plans du projet et les produits développés sont identifiées.  C’est l’objectif à atteindre, et l’agilité le permet largement.

2 PRATIQUES(S)SPECIFIQUES DE REFERENCE RECOMMANDEE POUR CMMI

Il s’agit des pratiques recommandées dans le modèle théorique. Non imposées, elles servent souvent de guide pour ceux qui démarrent leur projet d’amélioration des processus mais peuvent être remplacées par des pratiques alternatives, contextualisées à l’entreprise, pourvu qu’elle permettent d’atteindre l’objectif fixé. L’idée pour nous est de prouver qu’avec un process Agile, vous gérez les exigences !

REQM-SP1.1 Développer une compréhension commune des exigences et de leur signification avec ceux qui les ont fournies.
OK AGILE CMMI

L’agilité se retrouve bien dans cette pratique qu’elle pourrait faire sienne. Les ateliers de travail, les face à face, pour construire de manière collaborative une Vision PARTAGEE, et un Backlog de produit, ESTIME et PRIORISE vont dans ce sens. La réunion de lancement en fait partie. Les critères d’acceptation portant sur chaque User Story (élément du Backlog) prolongent cet effort de compréhension commune et concourent  à l’atteinte de l’objectif.
Qui : Product Owner, Equipe
Quoi : Vision, Backlog de produit, Réunion de lancement, Réunion d’estimation, Réunion de planification, User Stories

REQM-SP1.2 Obtenir des participants au projet leur engagement sur les exigences.
OK AGILE CMMI

Engagement et responsabilisation : voilà des points forts des méthodes Agiles. La réunion de planification (à chaque début de sprint) est un moment où l’équipe s’engage collectivement sur la réalisation, durant le sprint, d’une partie du Backlog de produit (et user stories). Chaque jour, les membres de l’équipe s’engagent sur la réalisation d’une tâche pour construire les user stories : c’est le Daily Scrum.
Qui : Equipe, ScrumMaster
Quoi : Réunion de planification (CR PPT ou Wiki), Daily Scrum

REQM-SP1.3 Gérer les modifications aux exigences au fur et à mesure de leur évolution en cours de projet.
OK AGILE CMMI
 

Maintien et contrôle des exigences : c’est aussi l’objectif du Backlog de produit, qui vit et évolue au fur et à mesure de l’avancée du projet.  Il est actualisé à la fin de chaque Sprint (suite à la réunion de fin de sprint).. Historiser les versions du Backlog est très pertinent dans un contexte CMMI.
Le changement dans les exigences peut se traduire aussi au niveau des user stories (éléments du Backlogde produit). Mettre à jour, faire vivre, la partie « Conversation » de l’User Stories est déjà une pratique en place chez beaucoup d’équipes.
Le burndown chart montre concrètement au quotidien ce qui est réalisé, et les changement éventuels survenus.
Au final, ce qui compte ici, c’est UN BACKLOG DE PRODUIT ET DES USER STORIES à JOUR.
Qui : Product Owner, Equipe
Quoi : Backlog de produit, User stories, Burndown Chart, Réunion de fin de sprint (CR PPT ou Wiki)

REQM-SP1.4 Maintenir une traçabilité bidirectionnelle entre les exigences et les produits d’activité.
OK AGILE CMMI
 

On s’en fait une montagne, et pourtant …il suffit d’envisager la fonction développée et présentée en DEMO comme la barquette de viande vendue au supermarché. Le  cas échéant, on doit  pouvoir remonter toute la chaine, et mesurer les enjeux collatéraux. Pour les végétariens, vous vez aussi la métaphore du Petit Poucet J  Le quatuor (Backlog de produit - User Stories - Tâches - Produit Développé) assure un système de suivi des exigences souple et performant, se concrétisant dans la démo de fin de sprint.  CMMI attend une matrice de traçabilité des exigences. Les feuilles de calcul et les outils du marché gérant les Backlog de produit permettent d’atteindre cet objectif.
Qui : Product Owner - Equipe
Quoi : Backlog de produit, Démo, Réunion de fin de sprint (CR PPT ou Wiki)

REQM-SP1.5 Identifier les incohérences entre les plans du projet et les produits d’activité d’une part et les exigences d’autre part.
OK AGILE CMMI

Cette pratique est un vrai point fort de l’Agilité. Elle s’effectue de manière continue, dans la collaboration, durant tout le sprint avec comme clé de voute les critères d’acceptation définis pour chaque User story mais aussi grâce aux daily scrum. La démo de fin de sprint est un RDV formel  permettant de déterminer ce qui a été fait ou pas, ce qui est bien fait de ce qui ne l’est pas.  Ce RDV qui donne lieu potentiellement à des actions correctives et à l’actualisation du Backlog de produit. FEEDBACK ET ADAPTATION.
Qui : Product Owner - Equipe - ScrumMaster
Quoi : Backlog de produit, User Stories, Daily Scrum, Démo, Réunion de fin de sprint (CR PPT ou Wiki)

3 OBJECTIF(S) GENERIQUES A SATISFAIRE OBLIGATOIREMENT POUR CMMI, et PRATIQUES ASSOCIEES

REQM GG1 : Réaliser les objectifs spécifiques
OK AGILE CMMI

En somme pour REQM, les exigences doivent être gérées (renvoie à REQM SG1 : Gérer les exigences)

REQM GG2 : Institutionnaliser le processus en tant que processus discipliné
OK AGILE CMMI

Là cela devient intéressant… Cet objectif n’est pas le plus simple à atteindre ; il est pourtant nécessaire dans les contextes CMMI et Agile CMMI.   Il ne nécessite pas forcement une adaptation des pratiques Agiles, mais plutôt un élargissement de celle-ci à l’entreprise :  « J’ai réussi un projet agile, et je souhaiterais capitaliser et faire en sorte que mes autres projets en bénéficient ». Des expériences que je capitaliserais à nouveau pour les améliorer.
Je vous parle donc de PROCESS AGILE, Capitalisation et amélioration continue. Je vous parle donc d’ENTREPRISE AGILE…  C’est dans l’ère du temps non ?

REQM-GP2.1 Établir et maintenir une directive organisationnelle traitant du processus Gestion des exigences…
OK AGILE CMMI

C’est un élément incontournable de mon Process Agile. Je m’appuie généralement sur le sponsor pour travailler cette directive qui vient d’en haut. Le plus souvent, elle reste générique (les méthodes agiles) mais on peut aborder brièvement, c’est mieux, la  gestion « agile » des exigences (développement et gestion). C’est en quelque sorte officialiser  le process Agile dans l’entreprise.
Qui : Coach Agile, Sponsor, Direction, Equipes

REQM-GP2.2 Planifier le processus Gestion des exigences…
OK AGILE CMMI

Une adaptation des pratiques agiles est nécessaire puisqu’on doit introduire pour chaque projet un plan de projet ou charte projet qui décrira dans les grandes lignes le Qui, Quoi, Quand, Ou  du projet. Je conseille aux équipes de le faire en Sprint 0 et demande au ScrumMaster de s’en charger. C’est un petit doc, commun à beaucoup de domaines de process CMMI (exigences, risques, qualité …). C’est court, PPT, Word ou Wiki.
Qui : ScrumMaster.

REQM-GP2.3 Fournir les ressources adéquates pour le processus Gestion des exigences…
OK AGILE CMMI

Preuve doit être donnée que les ressources adéquates (humaines, outils …) ont été fournies.  Dans notre cas, cela passe entre autres par le choix de l’outil de Backlog, et par la désignation d’un Product Owner (disponible). Cette pratique m’est très utile car elles la question des moyens est souvent un facteur d’échec des projets agiles. Avec cette pratique, on gagne en maturité. Cette activité fait partie intégrante du rôle du ScrumMaster, en Sprint 0. Donc pas de problème.
Qui : ScrumMaster.

REQM-GP2.4 Assigner la responsabilité et l’autorité pour mettre en œuvre le processus Gestion des exigences…
OK AGILE CMMI

C’est une composante du Process Agile, à inclure dans le Plan de projet. Qui fait quoi ? Cela revient à décrire brièvement  le rôle de Product Owner …
Qui : ScrumMaster.

REQM-GP2.5 Former les personnes qui mettent en œuvre ou soutiennent le processus Gestion des exigences…
OK AGILE CMMI

Cela fait partie de mon travail de coach Agile. Dans ce cas précis, cela passe par la mise en place de formations et ateliers dédiés au Product Owner, aux testeurs, à l’équipe.
Qui : Coach Agile.

REQM-GP2.6  Placer les produits d’activité identifiés du processus Gestion des exigences au niveau de contrôle approprié…
OK AGILE CMMI

Comme sur tous les projets informatiques … Il s’agit du niveau de configuration d’éléments comme le Backlog de produit ou les User Stories. Les CR de réunions de planification ou de sprint rentrent aussi dans cette catégorie.
Qui : Product Owner, ScrumMaster.

REQM-GP2.7  Identifier et impliquer les parties prenantes concernées par le processus Gestion des exigences…
OK AGILE CMMI

Un petit tableau dans le Plan de projet fait en Sprint 0 est tout à fait pertinent. Le Product Owner est l’acteur principal sur laquestion mais, l’équipe (en particuliers les testeurs) est fortement partie-prenante. Business analysts, Ergonomes, Utilisateurs… sont aussi concernés.
Qui : ScrumMaster.

REQM-GP2.8 Suivre et contrôler le processus Gestion des exigences …
OK AGILE CMMI

Cette pratique consiste à suivre l’avancement des activités de gestion des exigences sur la base d’indicateurs. La fin du sprint est un jalon essentiel avec la collecte de données : sur les user stories (Done / Ready), le burndown chart, les changement sur les stories…. Cela fait partie « par défaut » des attributions du ScrumMaster.
Qui : ScrumMaster

REQM-GP2.9  Évaluer objectivement  le respect du  processus Gestion des exigences…
OK AGILE CMMI

Relié aussi au GP2.2. C’est du QA. Le ScrumMaster est le garant de la bonne application du Process Agile sur le projet. Cela fait partie « par défaut » de ses attributions. Maintenant attention, le Process Agile est adaptatif…
Qui : ScrumMaster.

REQM-GP2.10 Revoir l’état du processus Gestion des exigences avec la hiérarchie et résoudre les problèmes…
OK AGILE CMMI

C’est à la fois donner de la visibilité et  remonter des problèmes potentiels à la hiérarchie. C’est justement le rôle du ScrumMaster (le « Chien de berger ») qui doit aussi protéger l’équipe et faire remonter, les obstacles éventuels soulevés par l’équipe (par exemple en Daily Scrum). Il peut s’appuyer sur des éléments du radiateur d’informations, burndown chart et fiches de Sprint pour donner de la visibilité à sa hiérarchie sur cette question des exigences.
Qui : ScrumMaster, Product Owner, Hiérarchie

REQM GG3 : Institutionnaliser le processus en tant que processus ajusté
OK AGILE CMMI

Comme précédemment, pas facile mais nécessaire (pour la maturité 3). On est plus que jamais dans du Process Agile…on est dans du standard mais dans une perspective qui me plaît bien, c’est à dire adaptative et non figée, fondée sur l’amélioration continue.

REQM-GP3.1 Établir et maintenir un processus Gestion des exigences ajusté
OK AGILE CMMI

Une description du processus Agile « standard » de l’entreprise doit être disponible .Elle servira de référence, mais sera ajustée à chaque projet (cela doit être prouvé).  On est en plein dans de l’AGILITE en CONTEXTE.
Définir le Process Agile standard, de manière collaborative et participative (jamais seul !)cela fait partie de mon travail.
L’adaptation au projet : c’est le boulot du ScrumMaster avec l’équipe et le Product Owner.
Qui : Coach Agile, les ScrumMaster, les Product Owner, les Equipes

REQM-GP3.2 Collecter l’information d’amélioration du processus Gestion des exigences
OK AGILE CMMI

Le projet doit se servir de retour d’expérience à la fois pour le Process Standard et pour les autres. C’est très agile, c’est très adaptatif (niveau organisation), et c’est la base de l’amélioration continue. Les agilistes doivent se féliciter de cette pratique.
Qui : Agile, les ScrumMaster, les Product Owner, les Equipes

Une autre référence sur la sujet : Flex”i”MMI

Stratégie de test, Qualité et Agilité: la Vision qui change tout

Posted by jc-QualityStreet on 11 mars 2009

On dit toujours que l’agilité met l’accent sur la qualité. C’est vrai :

  • des pratiques telles que l’intégration continue, les tests unitaires, les tests de recette, le pair programming mais aussi une volonté évidente d’automatisation jouent indéniablement sur la qualité du produit logiciel…
  • le client sur site et de courtes itérations, pour plus de collaboration et de feedback permettent de s’assurer que le “bon produit” est développé…
  • Avec l’ajout d’un regard Lean et d’une approche ergonomique, le compte est souvent bon…

ET POURTANT dans les faits, stratégie de test et testeurs ont du mal à se retrouver dans les projets Agiles, comme si toute une approche qualité était occultée, menée de manière anarchique, sans ligne directrice…
ça doit changer; ça va changer !

VERS UNE NOUVELLE VISION DES TESTS DANS LES PROJETS AGILES… trois éléments déterminants

Intégrer les testeurs dans l’équipe Agile et enrichir leur rôle (à la fois plus proches et au service de l’équipe mais aussi en soutien fort du Product Owner, du Métier). Cette alerte Agile (Où sont les testeurs) allait dans ce sens, et les résultats sont le plus souvent probants.

Donner un nouvel élan à la stratégie de test dans une dynamique agile. La stratégie de test se doit d’abord d’être envisagée dans une dimension high level en Sprint 0 pour l’ensemble de la version (une version, c’est entre 3 et 6 mois). Ensuite, le challenge du testeur est de l’ajuster en contexte à chaque début de sprint, en fonction du contenu du sprint à venir et de ce qui a été qualifié de Done au sprint précédent. A ce niveau, on va à l’essentiel : la stratégie de test, niveau sprint a la particularité d’être à la fois synthétique et trés précise !

S’appuyer sur le génialissime modéle de Brian Marick (signataire de l’Agile Manifesto et Star de la qualité logiciel) pour formaliser cette stratégie de tests. A chaque sprint, piocher son type de tests dans tel ou tel quadrant. Un modèle, trés visuel, instantanément compréhensible et trés parlant non seulement par le spécialiste QA qui sommeille en vous, mais aussi par toute personne impliquée dans un projet informatique.
gile Testing Quadrants Brian MArick
4 quadrants qui à eux seuls guideront l’ensemble de votre stratégie:

  1. Tests orientés Technologie en soutien de l’équipe (ex : Tests unitaires et approche TDD , le plus automatisé possible)
  2. Tests orientés Business en soutien de l’équipe (ex: les tests sur storyboard, les tests fonctionnels pour vérifier les critères d’acceptation du Product Owner: l’approche de conception centrée utilisateurs et l’ergonome y trouvent leu compte)
  3. Tests orientés Business pour critiquer le produit (c’est avant tout du manuel, à tout moment ou en End Game pour le systéme complet en test d’acceptation. L’approche ergonomique ressort encore : quand on vous dit qu’il faut faire des Tests Utilisateurs !)
  4. Tests orientés Technologie pour critiquer le produit (des tests essentiels qui se doivent d’être outillés et qui peuvent nécessiter la présence de spécialistes, perf / sécurité; souvent en End Game hormis simulations)
gile Testing Quadrants Brian MArick

5 S … Dorénavant … C’est promis !

Posted by jc-QualityStreet on 16 février 2008

Le principe de base est qu’un environnement propre et bien rangé contribue à la réalisation d’un travail efficace et de qualité.

Bon, à 35 ans c’est parfois difficile de changer ses habitudes, mais avec un peu d’autodiscipline et de rigueur, croyez-moi on y arrive… et puis, tout ce qui peut éviter de me faire perdre du temps est le bienvenu…

La pratique des 5 S (Seiri, Seiton, Seiso, Seiketsu, Shitsuke) est une méthode d’organisation japonaise précisément du Toyota Production System (TPS), initié par Taiichi Ohno (DG de Toyota); TPS dont Mary et Tom Poppendieck, se sont inspirés dans le cadre du développement logiciel avec leur “Lean Software Development“, que j’ai déjà évoqué dans d’autres billets.

LES 5S:

Seiri (Débarrasser)
Débarrasser son espace de travail de l’inutile, garder l’essentiel : une première étape incontournable. C’est la fin des bureaux encombrés, des armoires pleines, des disques durs engorgés. Pour cela, il suffit de se fier à la fréquence d’utilisation !

Seiton (Mettre en ordre)
Organiser son espace de travail de façon efficace. Une place pour chaque chose et chaque chose à sa place ! Quand on cherche quelque chose, on le trouve vite ! C’est vital pour ses propres dossiers, ça l’est aussi sur un projet ou pour la GESTION des connaissances de l’entreprise.

Seiso (Nettoyer)
Un travail propre se réalise avec des outils propres. Il s’agit donc de nettoyer son poste de travail le plus régulièrement possible.

Seiketsu (Standardiser)
Maintenir l’ordre et la propreté; cela passe par des règles (de rangement, d’indexation notamment) claires, évidentes … et connues de tous si on se place une nouvelle fois au niveau d’un projet ou de l’entreprise.

Shitsuke (Encourager les efforts)
Maintenir ces principes jours après jours, années après années… et même essayer de les améliorer. C’est souvent le plus difficile, et la dessus que j’ai toujours “dérapé” … jusqu’à maintenant !!

Tout cela paraît facile, et ça l’est, alors allons-y. Et pour se motiver davantage, rappelons que ces 5S sont les fondamentaux, le point de départ, vers les autres principes du Toyota Production System et du Lean software Development, des principes qui ont prouvé leur efficience. On pourrait citer par exemple:

  • Réduire les stocks (ou plutôt les tâches non réalisées ou en cours de réalisation, les bugs …)
  • Éliminer les sources de gaspillage (c’est à dire toutes les activités qui n’apportent pas de valeur au client … anomalies, situations d’attente, fonctionnalités inutiles)
  • Favoriser l’apprentissage et adopter une démarche d’amélioration continue
  • Livrer vite mais à un niveau de qualité élevé (cycle de développement courts favorisant le feedback)

D’ailleurs en parlant de Lean, je vous engage tous, à faire sur vos derniers projets, juste pour voir, une petite cartographie des flux de valeurs (la fameuse “Value stream map“) mais là, c’est une autre histoire !

ISO 9126, SQuaRE : Qualité, Utilisabilité … et une aubaine pour l’Ergonome

Posted by jc-QualityStreet on 7 novembre 2007

L’ISO 9126 « Software Product Quality » (2001) et l’ISO SQuaRE « Software Product Quality Requirement and Evaluation » (2005) (fusion de 9126 et 14598, son volet évaluation) font partie de ces normes qu’il est bon de connaître quand on travaille dans le développement de logiciels ou plus largement dans la conception de services interactifs.
MàJ du 08/11/2007 : Pour une définition plus précise de l’ergonomie et de l’utilisabilité, jetez-un oeil à ce billet ”Ergonomie = Utilité + Utilisabilité”

L’essentiel pour moi, Ergonome

  • La mise en avant de l’Utilisabilité (facilité d’utilisation) : c’est l’une des 6 caractéristiques du modèle de qualité
  • La présence de l’Attractivité en plus de sous caractéristiques plus classiques : c’est la reconnaissance de l’esthétisme, de l’affect, du “beau” au niveau de l’interface… élément qui fait régulièrement débat
  • L’introduction (forme révisée) du concept de “Quality in use” avec 4 caractéristiques : Efficacité, Efficience, Sûreté, Satisfaction… mon “Ergonomie en 3 mots” pourrait pourquoi pas, se transformer en une “ergonomie en 4 mots”
  • La mise en oeuvre des mesures

En bref
ISO 9126 et ISO SQuaRE fournissent un modèle, fait de caractéristiques et sous-caractéristiques, permettant de lier les qualités externes d’un logiciel à ses qualités internes, et introduisent fort justement (même si on a tendance à l’oublier) le concept de “Quality in use” (« the user’view of the quality of the software product when it is used in a specific environment and a specific context of use ») : une vraie porte ouverte vers les Tests Utilisateurs et l’observation en contexte.

6 caractéristiques de qualité (avec un focus sur l’Utilisabilité)

  1. Capacité fonctionnelle
  2. Fiabilité
  3. UTILISABILITE (en anglais, “usability” qu’on peut traduire aussi par “facilité d’utilisation”, c’est à dire un “Ensemble d’attributs portant sur l’effort nécessaire pour l’utilisation et sur l’évaluation individuelle de cette utilisation par un ensemble défini ou implicite d’utilisateurs”) : Facilité de compréhension, Facilité d’apprentissage, Opérabilité, Attractivité, Conformité aux standards d’ergonomie
  4. Rendement
  5. Maintenabilité
  6. Portabilité

Pourquoi ça m’intéresse ? Qu’est ce que ces normes m’apportent ?

  • La qualité des produits est mon leitmotiv, ce vers quoi je tends…
  • Ces normes sont à elles seules le symbole de la convergence de plusieurs disciplines de l’ingénierie
  • C’est la reconnaissance de ma propre discipline, l’Ergonomie, de mon rôle et de mon expertise (en particulier sur les questions relatives à la facilité d’utilisation), cela peut légitimer mon intervention
  • C’est un point d’entrée idéal pour l’ingénierie des exigences (du recueil à la gestion des exigences en passant par l’analyse du besoin): j’utilise ces caractéristiques pour qualifier les exigences fonctionnelles et non fonctionnelles recueillies
  • Cela facilite ma collaboration avec les services QA (Quality Assurance) et sur un projet avec un Responsable de test
  • Il existe un lien fort avec des domaines de processus CMMI, niveau 2 et 3, je pense notamment à RD “Développement des exigences”, REQM “Gestion des exigences”, VER “Vérification”, VAL “Validation”, TS “Solution technique”, MA “Mesure et Analyse” …
Get Adobe Flash playerPlugin by wpburn.com wordpress themes