TESTS DE DETECTION

 

Tous les profs d'infos savent çà : un bon programme est un programme non-plantable. Quelque soit le type de matériel ou la configuration, le programme devra se terminer par un message d'erreur plutôt que par un bug. En effet, on ne peut pas vraiment dire d'un programme qui détecte qu'il ne va pas fonctionner et qui retourne au DOS sans planter qu'il ne marche pas. Et donc on ne peut pas vraiment demander le remboursement du produit dans un tel cas. Ainsi est-il indispensable de savoir déterminer la configuration hard d'une machine, ainsi que la configuration soft. Mais il est aussi parfois plus important de connaître le type d'utilisateur plutôt que le type de processeur. Or il est possible d'obtenir des renseignements très révélateurs par soft, sans donc qu'il soit nécessaire pour l'acheteur du produit de se livrer à une longue et pénible séance de configuration.

Nous allons passer en revue plusieurs cas où l'utilisateur à une influence qu'il ne soupçonne pas sur le déroulement du programme.

 

1. Securitée adaptative sensitive.

Vous écrivez une interface archi-sursécurisée, mais vous vous demandez à partir de quel niveau de récursion votre routine demandant la confirmation ("Etes-vous sur ? (O/N)") de la confirmation de la confirmation de la confirmation etc de l'effacement du fichier "toto.bak" commence à irriter l'utilisateur.

La solution : déterminer le niveau en fonction de la patience de l'utilisateur évaluée lors du lancement du programme par ce test :

Avant de démarrer quoique ce soit, faites une pause de quelques minutes, et lisez le clavier. Chaque touche pressée rapporte un point, ESPACE ou ENTER rapportent deux points, ESC en rapporte trois, les combinaisons CTRL+C et CRTC+Break en rapportent cinq, et CTRL+ALT+DEL en rapporte dix. En fonction du score obtenu pendant cette pause, le programme détermine la patience de l'utilisateur (plus le score est élevé, moins il faut de récurence dans la confirmation pour effacer un petit fichier).

 

2. Shell intelligent intuitif et personnalisé

Votre patron vous demande de programmer "un shell intuitif et simple, c'est pour les secrétaires elles en ont marre de perdre des fichiers dans leur disque dur, et pis pour moi aussi faut que ca me permette de lancer doom dans C:\RAPPORT.DAT\JEUX\DOOM1\SAVEGAME\DOOM2\BIN, c'est facile je sais pas moi, débrouilles toi".

Comment faire pour que les secrétaires ne perdent plus de fichiers ? Simple : les cantonner à un répertoire (puisque la simple idée de réessayer de leur apprendre quelques commandes vous fait passer une nuit blanche). Et pour le patron alors, comment va t'il aller jouer à DOOM ? Il faut un shell qui s'adapte à l'utilisateur ! Si l'utilisateur est inexpérimenté, il faut lui interdire les commandes CD, MD, RD, etc...

Determiner l'expérience de l'utilisateur est chose aisée. Plusieurs choix s'offrent à vous, nous vous présentons leurs points forts/faibles. Choisissez :

(Note : vous remarquerez pour l'anecdote que le patron est incapable d'avoir installé DOOM lui même. En fait il a découvert ce jeu sur son disque dur alors qu'il cherchait à installer Digger. On ne sait pas qui à installé DOOM. En général il s'agit d'un ancien employé qui ne travaille plus là depuis longtemps. Mais de toute facon personne ne sait comment effacer un fichier)

 

3. Detecteur de compétence.

Vous devez écrire un programme pour une boite, mais vous ne savez pas s'il convient de sécuriser le programme à coup de "Etes-vous sur ?", "F1 pour l'aide" et autres "Cliquez ici je vous prie". En fait, il faudrait que le programme détermine le niveau du responsable informatique de la boite. Pas de problème, ici encore des tests simples permettent de s'en sortir :

 

4. Programmes socio-adaptatifs

Vous êtes l'heureux auteur d'un jeu qui relègue DOOM et Wolf3d au rang de Bubble-Bobble pour vieilles grands mères puritaines. Seul problème : interdire le jeu aux mineurs.

Première chose à tester : le processeur ! Si le joueur dispose d'un ORIC ou d'un VAX, il est probable qu'il ne soit pas née d'hier (il est encore plus probable que le jeu ne tourne pas).

Un autre test est de rechercher des fichiers "*.GIF" et "*.FLI". Ce n'est pas tant le nombre de fichiers qui compte mais plutôt leur localisation. Si vous trouvez le fichier "Z:\WINDOWS\TMP\TEXTES\AVION.GIF", il s'agit en fait du fichier "PAMELA.GIF" renommé et caché dans cette partition secrète du disque dur de son popa par un petit ado de 15 ans. Si vous trouvez plutot "C:\INZEBUTT.FLI" bien classé entre un "CONFIG.SYS" et un "AUTOEXEC.BAT", vous êtes chez une personne plus agée qui s'assume.

Vous pouvez aussi rechercher les autres jeux présents sur le disque. Voici une petite échelle :

 

Si vous en connaissez d'autres, faites savoir.