Pour moi, Idiot Proofing signifie simplement s'assurer que l'utilisateur ne peut pas casser un logiciel même s'il a essayé. Par exemple, si une valeur est lue dans une zone de texte et convertie en double, si le logiciel sous-jacent est à l'épreuve des idiots, il ne se cassera pas si l'utilisateur tape une valeur non double.

J'ai récemment rédigé un calendrier de développement et l'un des éléments a été nommé "Interface utilisateur à l'épreuve des idiots". Les gens que je construis avec ce logiciel ont simulé en plaisantant le terme, mais je peux voir où ce terme pourrait réellement déranger les gens.

Quelle est la meilleure façon de le dire?

Si vous incluez "UI idiot preuve" comme un élément de calendrier, alors vous essayez simplement d'ajouter de la qualité par la suite à votre logiciel. Tout système bien conçu validera ses entrées et donnera des conseils clairs aux utilisateurs, bien sûr, ce n'est pas quelque chose qui est mis sur le calendrier en tant qu'élément discret (qui est ensuite soumis à la suppression lorsque le crunch inévitable frappe).

Alternativement, s'il doit s'agir d'un élément discret (je sais comment certaines organisations pensent de la planification), "Interface utilisateur à l'épreuve des idiots" devrait être changé en "Bibliothèque de validation d'entrée" et déplacé au début de la planification.

La validation des entrées utilisateur aurait été un terme professionnel. Je ne vois rien de mal à la preuve idiote si elle est utilisée dans les documents internes.

Le durcissement est un bon mot. Si quelqu'un le demande, dites-lui que le premier logiciel de transmission est généralement écrit pour des scénarios idéaux, et comme les outils en acier, le logiciel doit être «durci» pour une utilisation quotidienne approximative par de vrais clients.

La robustification est un autre bon mot pour cela - vous rendez le code robuste face aux types de défis que les vrais clients vont lui lancer.

Les deux mots semblent cool et industriels, ne blâmez pas les utilisateurs ou les programmeurs et faites passer le message.

BTW, voici la vieille mascotte de Metrowerks, Arnold, le gars qui nous aidait à programmer les Mac à durcir et à renforcer notre code avec un four de traitement thermique, une forge et une enclume et un petit marteau à traîneau:

Programmation défensive

C'est ce qu'on m'a appris. À l'époque où nous devions couper nos propres morceaux de bois.

Si vous voulez être un PC, appelez cela une programmation "anticipative".

Quand j'apprenais, nous l' appelions pare-balles .

La plupart des autres euphémismes que j'ai lus s'appliquent également.

Que diriez-vous du système ou de l'interface utilisateur «tolérant aux pannes»?

La "protection contre les idiots" devrait comprendre les deux

• concevoir l'interface utilisateur de manière à ce qu'elle soit conviviale et amène l'utilisateur à saisir les données de la manière attendue par les programmeurs, et

• tester l'interface utilisateur pour déterminer si l'interface peut être rompue en entrant des valeurs de données inattendues.

Les deux étapes peuvent raisonnablement apparaître dans le calendrier de développement où la conception est vérifiée par un expert en expérience utilisateur et où le code livré est vérifié par un testeur pour garantir que les données non valides sont traitées correctement (pour tout ce qui signifie «correctement» pour votre application).

La protection contre les idiots implique bien plus que la simple validation des entrées. Je n'inclurais même pas une telle chose dans sa définition.

La validation des entrées est un processus par lequel vous nettoyez et validez les données utilisateur pour éliminer les valeurs illégales / absurdes. Cela doit toujours être fait avec toute information provenant de l'extérieur de votre programme afin d'éliminer les évidents ainsi que de vous protéger contre les attaques (par exemple les attaques par injection SQL).

Je considérerais que l'idiot-proofing est un ensemble de logique pour empêcher l'utilisateur de lui causer accidentellement de grands dommages par des moyens autrement légaux.

Par exemple, faire rmrejeter la commande rm -rf /et fermer les variantes n'a rien à voir avec la validation ou l'exactitude. C'est une commande parfaitement valide. Malheureusement, c'est une commande qui pourrait et peut effacer toutes vos données de tous vos disques sous Unix / Linux. Une mise à l'épreuve idiote rejetterait cette commande et suggérerait rm -rf --i-really-mean-this /, ou en mode interactif, que l'utilisateur tape une réponse affirmative après un avertissement.

Tout ce qui est destructeur pour le système doit être à l'abri des idiots. Tout ce qui pourrait causer de l'embarras pourrait également être un candidat (par exemple, "êtes-vous sûr de vouloir envoyer cet e-mail sans pièce jointe même si vous en avez mentionné un dans votre texte?", Et "êtes-vous sûr de vouloir envoyer cet e-mail au toute l'entreprise? ")

L'Idiot-proofing est une collaboration entre l'AQ (essayant d'être le meilleur idiot) et le Développement (essayant d'anticiper tous ces scénarios et de les concevoir autour d'eux).

En ce qui concerne un synonyme plus convivial , puis-je suggérer une "analyse destructrice du chemin de code" ou "activer les commentaires des utilisateurs pour les opérations critiques". Quoi que vous l'appeliez, vous devriez vraiment le démarrer le plus tôt possible dans le processus de conception.

"Sanity Checking" a tendance à bien fonctionner assez souvent ...

Appelez cela "ajouter des Poka-yokes à l'interface utilisateur". http://en.wikipedia.org/wiki/Poka_yoke

«Gestion des erreurs» ou «validation des entrées» seraient d'autres termes que j'utiliserais pour décrire ce que vous décrivez. Bulletproof serait un autre terme que je pourrais voir utilisé dans certains cercles car l'idée ici est de rendre le logiciel suffisamment robuste pour gérer presque tout. Rock solid serait une autre expression d'argot que je pourrais imaginer que quelqu'un veuille utiliser ici aussi.

"Epreuvage de scénario le plus défavorable". Parce que, en tant que développeurs, nous savons tous que si cela peut être fait, alors ce sera fait . Il vous suffit donc d'être prêt à gérer la pire des situations avec votre logiciel.

Les mesures de sécurité ne sont pas seulement un moyen de protéger les utilisateurs contre les cyber-invasions extérieures, mais aussi contre eux-mêmes. Nous vivons dans un monde imparfait avec des utilisateurs imparfaits.

Le placage à l'or est le terme poli (et à consonance très positive) que j'utilise lorsque je parle d'améliorer l' expérience de l' interface utilisateur de quelque manière que ce soit (GUI ou autre).

La protection contre les idiots, comme vous le dites, est la plus grande partie de ce processus, ainsi que les améliorations de conception ou de flux de travail (pensez à la reconnaissance des commentaires des utilisateurs finaux).

L'idée ici est que vous pouvez utiliser ce terme librement dans l'environnement de travail et qu'il est considéré comme un processus précieux (une fois terminé) par la direction et les utilisateurs, même si cela peut prendre un certain temps (et donc généralement coûter de l'argent).

de nombreux autres termes liés à ce processus (souvent en fin de cycle) le font ressembler à ce processus:

• implique que les utilisateurs (souvent la gestion ;-) sont stupides
• est difficile à réaliser
• a peu de valeur nette

En associant l'or au processus (le métal équivaut généralement à la «valeur» plutôt qu'au «coût»), j'ai vu le processus passer de la dépense à l'investissement dans la mentalité de certains gestionnaires.

C'est comme déclarer ouvertement que jusqu'à ce que cela soit fait, ce morceau d'acier maladroit n'est pas encore un bijou. Mais une fois que c'est plaqué ... alors c'est précieux.

Le plus souvent utilisé en relation avec les processus de fabrication, mais je pense que Poka-Yoke est un très bon ajustement :

"[poka yo-ke] est un terme japonais qui signifie" sécurité intégrée "ou" protection contre les erreurs "

Il était à l'origine décrit comme baka-yoke, mais comme cela signifie "à toute épreuve" (ou "idiot-proofing"), le nom a été changé en poka-yoke plus doux.

Plus largement, le terme peut faire référence à toute contrainte de mise en forme de comportement conçue dans un produit pour empêcher un fonctionnement incorrect de l'utilisateur. "

Un terme courant dans les grands magasins est également l'assurance qualité (AQ) .

C'est un terme général et vague que vous pouvez modeler selon votre propre signification spécifique dans votre cycle de sortie.

Nous l'appelons Human Proofing. Nous sommes tous des idiots.