MODULE No 22

Titre : Software Design Manifesto

But : Montre une manière de considérer la conception des interfaces personne-machine qui est loin de celle classique des informaticiens

Antécédents : Module 21

Corps :

Voici quelques éléments tirés de Software Design Manifesto (premier chapitre du livre Bringing Design to Software, sous la direction de Terry Winograd, édité par Addison-Wesley).

Attention. Ici le terme « Design » (Conception en français) n’est pas employé comme dans la norme ISO 12207 où il indique l’activité qui permet de donner une structure au logiciel pour satisfaire les exigences. Ici il s’agit de la conception de ce qui apparaît, de ce avec quoi on interagit. Nous limitons la signification de « conception » à la description de l’IPM même si l’auteur de Software Design Manifesto ne serait pas d’accord. Fin Attention

• De gros problèmes continuent à exister par rapport aux IPM (Et ce ne sont sûrement pas les informaticiens qui savent les voir ou le corriger : ils minimisent trop facilement les difficultés des autres utilisateurs).
• Les compagnies essaient surtout de stabiliser les produits. Ce qui demande moins d’investissements (au départ) et moins de créativité (toujours).
• L’utilisateur n’ose pas se révolter et pense que c’est sa faute si l’ordinateur ne fonctionne pas bien. Il y a une espèce de « terrorisme » entretenu par les experts incapables de penser qu’il n’existe pas que leur domaine.
• Il faut reconnaître le rôle central du concepteur de l’IPM. Ce qui n’est pas facile à faire à cause de la position des ingénieurs du logiciel.
• Jusqu’à présente ce sont souvent les informaticiens qui ont conçu les IPM (comme si les ingénieurs concevaient l’esthétique des autos… mais les informaticiens ne sont pas formés pour cela…). Depuis quelques années (surtout pour les sites WEB) les graphistes ont toujours plus de poids, mais il y a encore beaucoup de route à faire…
• Il faut repenser les fondements de la réalisation du logiciel.
• Le Designer du logiciel (trouver un autre nom ?) doit être celui qui a la pleine responsabilité du produit.
• Dans les entreprises il faut ouvrir des carrières pour ce genre de personnes. Ça doit être une profession à part entière.
• Il faut développer des outils pour le designer (la place de l’ingénieur du logiciel est là où l’on développe les outils pour aider à concevoir les IPM).
• Le concepteur doit avoir une formation technique pour pouvoir dialoguer avec les informaticiens.

Relations entre IPM et domaine

Voici une structure très simple (sans doute trop simple) pour voir comment départager les fonctions entre ingénieur du logiciel et concepteur de l’IPM :

Exemple : Une fenêtre pour entrer le nom d’utilisateur et le mot de passe (fenêtre très, très compliquées, n’est-ce pas ?) :

Le designer dans le sens du Manifesto conçoit la fenêtre (nombre de champs, position, couleur, boutons, etc.). Pour concevoir la bonne fenêtre il doit étudier les utilisateurs dans leur milieu de travail pour bien saisir leur rôle, leurs tâches et leurs approches.

L’ingénieur du logiciel conçoit et code les programmes responsables de la gestion des événements causés par l’interaction avec la fenêtre. L’ingénieur du logiciel doit répondre à des questions comme les suivantes avant de coder son application :

1. Quels modules gèrent les micro-événements associés à l’interface (clique de la souris, déplacement de la boîte, clique sur le bouton, changement de champ) ?

2. Quels sont les événements qui concernent l’application ? Fin de l’entrée du nom et du mot de passe ? Tout le reste est alors fait au niveau des modules d’interface ? Qui et où stocker les informations avant de les passer au « domaine » ?

3. Et la couche dialogue ? Que fait-elle ? Est-ce que sa seule responsabilité est de diminuer la charge fonctionnelle du domaine ou est-ce qu’elle fixe aussi les règles d’interaction?

Conséquent : avoir une idée du partage des responsabilités entre le concepteur de l’IPM et le concepteur des programmes.

Note 01 :