Exemples de joug Poka en mécanique. Exemples de détection d'erreurs
- Traduction
Salut tout le monde! Je m'appelle Alexey Grezov, développeur de Server Team Badoo. Chez Badoo, nous essayons toujours de rendre notre code facile à maintenir, à développer et à réutiliser, car ces paramètres déterminent la rapidité et l'efficacité avec lesquelles nous pouvons implémenter n'importe quelle fonctionnalité. Une façon d’atteindre cet objectif est d’écrire du code qui ne permet tout simplement pas de commettre des erreurs. L'interface la plus stricte ne vous permettra pas de vous tromper sur l'ordre de son appel. Montant minimal états internes garantit les résultats attendus. L'autre jour, j'ai vu un article qui décrit exactement comment l'utilisation de ces méthodes facilite la vie des développeurs. J'attire donc votre attention sur la traduction d'un article sur le principe du « poka-yoke ».
À travailler ensemble Avec le code dans une équipe de taille moyenne à grande, vous avez parfois des difficultés à comprendre et à utiliser le code des autres. Il existe différentes solutions à ce problème. Par exemple, vous pouvez accepter de suivre certaines normes de codage ou d’utiliser un framework connu de toute l’équipe. Cependant, cela ne suffit souvent pas, surtout lorsque vous devez corriger un bug ou ajouter une nouvelle fonctionnalité à un ancien code. Il est difficile de se rappeler à quoi étaient destinées les classes spécifiques et comment elles étaient censées fonctionner, individuellement ou ensemble. Dans de tels moments, vous pouvez accidentellement ajouter Effets secondaires ou des erreurs sans même s'en rendre compte.
Ces erreurs peuvent être découvertes lors des tests, mais il existe une réelle chance qu’elles se retrouvent en production. Et même s'ils sont identifiés, l'annulation du code et sa correction peuvent prendre beaucoup de temps.
Alors, comment pouvons-nous empêcher cela ? En utilisant le principe du « poka-yoke ».
Qu’est-ce que le poka-yoke ?
Poka-yoke est un terme japonais qui se traduit en anglais par « anti-erreur » (protection contre les erreurs), et dans la version russe, il est mieux connu sous le nom de « protection contre un imbécile ». Le concept est né du Lean Manufacturing, où il fait référence à tout mécanisme permettant à l’opérateur de l’équipement d’éviter les erreurs.
En plus de la fabrication, le poka-yoke est souvent utilisé dans l'électronique grand public. Prenons par exemple une carte SIM qui, en raison de sa forme asymétrique, ne peut être insérée dans l'adaptateur que avec le bon côté vers le haut.
L'exemple inverse (sans utiliser le principe poka-yoke) est le port PS/2, qui a la même forme de connecteur pour le clavier et la souris. On ne peut les distinguer que par leur couleur et il est donc facile de les confondre.
Le concept poka-yoke peut également être utilisé en programmation. L'idée est de rendre les interfaces publiques de notre code aussi simples et claires que possible, et de générer des erreurs dès que le code est mal utilisé. Cela peut paraître évident, mais en réalité, nous rencontrons souvent du code qui ne fait pas cela.
Veuillez noter que le poka-yoke n'est pas destiné à empêcher les abus intentionnels. Le but est uniquement d’éviter les erreurs accidentelles, et non de protéger le code d’une utilisation malveillante. D'une manière ou d'une autre, tant que quelqu'un a accès à votre code, il pourra toujours contourner les fusibles s'il le souhaite vraiment.
Avant de discuter des mesures spécifiques visant à rendre le code plus résistant aux erreurs, il est important de savoir que les mécanismes poka-yoke peuvent être divisés en deux catégories :
- prévention des erreurs
- détection d'erreur.
Les mécanismes de prévention des erreurs sont utiles pour éliminer les erreurs à un stade précoce. En simplifiant au maximum les interfaces et les comportements, nous veillons à ce que personne ne puisse accidentellement utiliser notre code de manière incorrecte (rappelez-vous l'exemple de la carte SIM).
En revanche, les mécanismes de détection d’erreurs sont extérieurs à notre code. Ils surveillent nos applications pour suivre erreurs possibles et prévenez-nous d'eux. Un exemple pourrait être logiciel, qui détermine si le périphérique connecté au port PS/2 est du bon type et, dans le cas contraire, indique à l'utilisateur pourquoi il ne fonctionne pas. Un tel logiciel ne pourrait pas prévenir erreur, puisque les connecteurs sont les mêmes, mais cela peut découvrir elle et signalez-le.
Nous examinerons ensuite plusieurs techniques que nous pouvons utiliser pour prévenir et détecter les erreurs dans nos applications. Mais gardez à l’esprit que cette liste n’est qu’un point de départ. En fonction de l'application spécifique, des mesures supplémentaires peuvent être prises pour rendre le code plus résistant aux erreurs. Il est également important de s'assurer qu'il est logique d'implémenter du poka-yoke dans votre projet : selon la complexité et la taille de votre application, certaines mesures peuvent s'avérer trop coûteuses par rapport au coût potentiel des erreurs. C'est donc à vous et à votre équipe de décider quelles mesures vous conviennent le mieux.
Exemples de prévention des erreurs
Déclaration de types
Anciennement connues sous le nom de Type Hinting dans PHP 5, les déclarations de type sont un moyen simple d'éviter les erreurs lors de l'appel de fonctions et de méthodes dans PHP 7. En attribuant des types spécifiques aux arguments d'une fonction, il devient plus difficile de perturber l'ordre des arguments lors de l'appel. cette fonction.
Par exemple, considérons une notification que nous pouvons envoyer à un utilisateur :
identifiant utilisateur = $ identifiant utilisateur ; $this->sujet = $sujet ; $this->message = $message; ) fonction publique getUserId() ( return $this->userId; ) fonction publique getSubject() ( return $this->subject; ) fonction publique getMessage() ( return $this->message; ) )
Sans déclarations de type, vous pouvez accidentellement transmettre des variables du mauvais type, ce qui peut interrompre votre application. Par exemple, nous pourrions supposer que $userId devrait être une chaîne alors qu’en fait il pourrait s’agir d’un entier.
Si nous transmettons le mauvais type au constructeur, l'erreur passera probablement inaperçue jusqu'à ce que l'application essaie de faire quelque chose concernant la notification. Et à ce stade, nous recevrons très probablement une sorte de message d'erreur cryptique dans lequel rien n'indiquera à notre code où nous transmettons string au lieu de int . Par conséquent, il est généralement préférable de forcer l’arrêt de l’application le plus tôt possible afin de détecter de telles erreurs le plus tôt possible au cours du développement.
Dans ce cas particulier, nous pouvons simplement ajouter une déclaration de type - PHP s'arrêtera et nous avertira immédiatement avec une erreur fatale dès que nous tenterons de passer un paramètre du mauvais type :
identifiant utilisateur = $ identifiant utilisateur ; $this->sujet = $sujet ; $this->message = $message; ) fonction publique getUserId() : int ( return $this->userId; ) fonction publique getSubject() : string ( return $this->subject; ) fonction publique getMessage() : string ( return $this->message; ) )
Notez que par défaut, PHP essaiera de convertir les arguments invalides en leurs types attendus. Pour éviter que cela ne se produise et ne génère une erreur fatale, il est important d'activer le typage strict (strict_types). Pour cette raison, déclarer des types scalaires n’est pas une forme parfaite de poka-yoke, mais c’est un bon point de départ pour réduire les erreurs. Même si le typage fort est désactivé, les déclarations de type peuvent toujours fournir une indication sur le type attendu pour l'argument.
De plus, nous avons déclaré les types de retour pour nos méthodes. Cela facilite la détermination des valeurs auxquelles nous pouvons nous attendre lors de l'appel d'une fonction particulière.
Des types de retour bien définis sont également utiles pour éviter plusieurs instructions switch lors du traitement des valeurs de retour, car sans types de retour explicitement déclarés, nos méthodes peuvent renvoyer des types différents. Ainsi, quelqu'un utilisant nos méthodes devra vérifier quel type a été renvoyé dans un cas particulier. Évidemment, il est possible d’oublier les instructions switch, ce qui entraînera des erreurs difficiles à détecter. Mais ils deviennent beaucoup moins courants lors de la déclaration du type de retour d'une fonction.
Objets de valeur
Le problème que les déclarations de type ne peuvent pas résoudre est que le fait d'avoir plusieurs arguments dans une fonction permet de mélanger l'ordre des arguments lors de son appel.
Lorsque les arguments sont de types différents, PHP peut nous avertir que l'ordre des arguments n'est pas dans l'ordre, mais cela ne fonctionnera pas si nous avons plusieurs arguments du même type.
Pour éviter les erreurs dans ce cas, nous pourrions envelopper nos arguments dans des objets valeur :
class UserId ( private $userId; public function __construct(int $userId) ( $this->userId = $userId; ) public function getValue() : int ( return $this->userId; ) ) class Subject ( private $subject; fonction publique __construct(string $subject) ( $this->subject = $subject; ) fonction publique getValue() : string ( return $this->subject; ) ) class Message (private $message; public function __construct(string $message ) ( $this->message = $message; ) public function getMessage() : string ( return $this->message; ) ) class Notification ( /* ... */ public function __construct(UserId $userId, Subject $subject , Message $message) ( $this->userId = $userId; $this->subject = $subject; $this->message = $message; ) fonction publique getUserId() : UserId ( /* ... */ ) fonction publique getSubject() : Sujet ( /* ... */ ) fonction publique getMessage() : Message ( /* ... */ ) )
Nos arguments étant désormais d’un type très spécifique, il est presque impossible de les confondre.
Un avantage supplémentaire de l'utilisation d'objets valeur par rapport à la déclaration de types scalaires est que nous n'avons plus besoin d'activer le typage fort dans chaque fichier. Et si nous n’avons pas besoin de nous en souvenir, nous ne pourrons pas l’oublier.
Validation
Lorsque nous travaillons avec des objets de valeur, nous pouvons encapsuler la logique de validation de nos données dans les objets eux-mêmes. De cette façon, nous pouvons empêcher la création d’un objet de valeur avec un état invalide, ce qui pourrait causer des problèmes à l’avenir dans d’autres couches de notre application.
Par exemple, nous pourrions avoir une règle selon laquelle tout UserId doit toujours être positif. Nous pourrions évidemment le vérifier à chaque fois que nous recevons un UserId en entrée, mais d'un autre côté, il peut aussi être facilement oublié à un endroit ou à un autre. Et même si cet oubli entraîne une erreur réelle dans une autre couche de notre application, il peut être difficile de comprendre ce qui n'a pas fonctionné à partir du message d'erreur, ce qui rend le débogage plus difficile.
Pour éviter des erreurs comme celle-ci, nous pourrions ajouter une validation au constructeur UserId :
class UserId ( private $userId; public function __construct($userId) ( if (!is_int($userId) || $userId< 0) { throw new \InvalidArgumentException("UserId should be a positive integer."); } $this->identifiant utilisateur = $ identifiant utilisateur ; ) fonction publique getValue() : int ( return $this->userId; ) )
De cette façon, nous pouvons toujours être sûrs que lorsque nous travaillons avec l'objet UserId, il a le bon état. Cela nous évitera de devoir vérifier constamment les données à différents niveaux de l'application.
Notez que nous pourrions ajouter ici une déclaration de type scalaire au lieu d'utiliser is_int , mais cela nous obligerait à activer le typage fort partout où UserId est utilisé. Si cela n'est pas fait, PHP essaiera de convertir d'autres types en int chaque fois qu'ils seront transmis en tant que UserId . Cela pourrait poser un problème puisque nous pourrions, par exemple, transmettre une variable flottante, qui pourrait être la mauvaise variable puisque les ID utilisateur ne sont généralement pas flottants. Dans d'autres cas où nous pourrions, par exemple, travailler avec l'objet Price, la désactivation du typage fort peut entraîner des erreurs d'arrondi car PHP convertit automatiquement les variables float en int .
Immutabilité
Par défaut, les objets en PHP sont passés par référence. Cela signifie que lorsque nous apportons des modifications à un objet, celui-ci change instantanément dans toute l'application.
Même si cette approche présente des avantages, elle présente également certains inconvénients. Regardons un exemple de notification envoyée à un utilisateur par SMS et e-mail :
interface NotificationSenderInterface ( public function send(Notification $notification); ) class SMSNotificationSender implémente NotificationSenderInterface ( public function send(Notification $notification) ( $this->cutNotificationLength($notification); // Envoyer un SMS... ) /** * S'assure que la notification ne dépasse pas la longueur d'un SMS. */ fonction privée cutNotificationLength(Notification $notification) ( $message = $notification->getMessage(); $messageString = substr($message->getValue(), 160) ; $notification->setMessage(new Message($messageString)); ) ) classe EmailNotificationSender implémente NotificationSenderInterface ( fonction publique send(Notification $notification) ( // Envoyer un e-mail ... ) ) $smsNotificationSender = new SMSNotificationSender() ; $emailNotificationSender = new EmailNotificationSender(); $notification = new Notification(new UserId(17466), new Subject("Notification de démonstration"), new Message("Message très long... plus de 160 caractères.")); $smsNotificationSender->envoyer($notification); $emailNotificationSender->envoyer($notification);
Étant donné que l’objet Notification est transmis par référence, cela a créé un effet secondaire involontaire. En raccourcissant la longueur du message dans SMSNotificationSender, l'objet Notification associé a été mis à jour dans toute l'application, de sorte que le message a également été tronqué lors de son envoi ultérieur à EmailNotificationSender.
Pour résoudre ce problème, rendons l'objet Notification immuable. Au lieu de fournir des méthodes définies pour y apporter des modifications, ajoutons des méthodes qui font une copie de la notification d'origine avant d'apporter ces modifications :
classe Notification ( fonction publique __construct(...) ( /* ... */ ) fonction publique getUserId() : UserId ( /* ... */ ) fonction publique withUserId(UserId $userId) : Notification ( $c = clone $this; $c->userId = clone $userId; return $c; ) fonction publique getSubject() : Sujet ( /* ... */ ) fonction publique withSubject(Subject $subject) : Notification ( $c = clone $this; $c->subject = clone $subject; return $c; ) fonction publique getMessage() : Message ( /* ... */ ) fonction publique withMessage(Message $message) : Notification ( $c = clone $ ceci; $c->message = clone $message; return $c; ) )
Désormais, lorsque nous apportons des modifications à la classe Notification, telles que le raccourcissement de la longueur du message, elles ne sont plus appliquées dans l'ensemble de l'application, ce qui permet d'éviter divers effets secondaires.
Notez cependant qu’en PHP il est très difficile (voire impossible) de rendre un objet véritablement immuable. Mais pour rendre notre code plus résistant aux erreurs, il suffira d'ajouter des méthodes « immuables » au lieu de méthodes définies, puisque les utilisateurs de la classe n'auront plus besoin de penser à cloner l'objet avant d'apporter des modifications.
Renvoyer des objets nuls
Parfois, nous rencontrons des fonctions et des méthodes qui peuvent renvoyer une valeur ou null . Et ces valeurs de retour nulles peuvent présenter un problème, car les valeurs devront presque toujours être vérifiées pour null avant de pouvoir faire quoi que ce soit avec elles. Encore une fois, c’est facile à oublier.
Pour éliminer le besoin de vérifier les valeurs de retour, nous pourrions plutôt renvoyer des objets nuls. Par exemple, nous pouvons avoir un ShoppingCart avec ou sans remise :
interface Discount ( fonction publique applyTo(int $total); ) interface ShoppingCart ( fonction publique calculateTotal() : int; fonction publique getDiscount() : ?Discount; )
Lors du calcul du coût final d'un ShoppingCart, avant d'appeler la méthode applyTo, il faut désormais toujours vérifier si la fonction getDiscount() renvoie : null ou une remise :
$total = $shoppingCart->calculateTotal(); if ($shoppingCart->getDiscount()) ( $total = $shoppingCart->getDiscount()->applyTo($total); )
Ne pas effectuer cette vérification entraînera un avertissement PHP et/ou d'autres effets secondaires lorsque getDiscount() renvoie null .
En revanche, ces contrôles peuvent être évités si l'on renvoie un objet nul alors qu'aucune remise n'est accordée :
class ShoppingCart ( fonction publique getDiscount() : Discount ( return !is_null($this->discount) ? $this->discount: new NoDiscount(); ) ) class NoDiscount implémente Discount ( public function applyTo(int $total) ( return $total; ) )
Désormais, lorsque nous appelons getDiscount(), nous obtenons toujours un objet Discount, même s'il n'y a pas de remise. De cette façon, nous pouvons appliquer la réduction au total même s'il n'y en a pas, et nous n'avons plus besoin de l'instruction if :
$total = $shoppingCart->calculateTotal(); $totalWithDiscountApplied = $shoppingCart->getDiscount()->applyTo($total);
Dépendances facultatives
Pour les mêmes raisons que nous souhaitons éviter les valeurs de retour nulles, nous souhaitons nous débarrasser des dépendances facultatives en rendant simplement toutes les dépendances obligatoires.
Prenons par exemple la classe suivante :
class SomeService implémente LoggerAwareInterface ( public function setLogger(LoggerInterface $logger) ( /* ... */ ) public function doSomething() ( if ($this->logger) ( $this->logger->debug("... "); ) // faire quelque chose si ($this->logger) ( $this->logger->warning("..."); ) // etc... ) )
Il y a deux problèmes :
- Nous devons constamment rechercher un enregistreur dans notre méthode doSomething().
- Lors de la configuration de la classe SomeService dans notre conteneur de services, quelqu'un peut oublier de configurer un enregistreur, ou même ne pas savoir que la classe a la capacité de le faire.
Nous pouvons simplifier le code en faisant de LoggerInterface une dépendance obligatoire :
class SomeService ( public function __construct(LoggerInterface $logger) ( /* ... */ ) public function doSomething() ( $this->logger->debug("..."); // faire quelque chose $this-> logger->avertissement("..."); // etc... ) )
Désormais, notre interface publique est moins lourde, et chaque fois que quelqu'un crée une nouvelle instance SomeService, il sait que la classe nécessite une instance LoggerInterface, il ne peut donc pas oublier de la spécifier.
De plus, nous avons éliminé le besoin de vérifier constamment la présence d'un enregistreur, ce qui rend doSomething() plus facile à comprendre et moins susceptible aux erreurs chaque fois que quelqu'un le modifie.
Si nous voulions utiliser SomeService sans enregistreur, nous pourrions appliquer la même logique que pour renvoyer un objet nul :
$service = nouveau SomeService (nouveau NullLogger());
En fin de compte, cette approche a le même effet que l'utilisation de la méthode facultative setLogger(), mais simplifie notre code et réduit le risque de bogues dans le conteneur d'injection de dépendances.
Méthodes publiques
Pour rendre le code plus simple à utiliser, il est préférable de limiter le nombre de méthodes publiques dans les classes. Le code devient alors moins déroutant et nous sommes moins susceptibles d'abandonner la compatibilité ascendante lors du refactoring.
Une analogie avec les transactions permettra de réduire au minimum le nombre de méthodes publiques. Prenons par exemple le transfert d’argent entre deux comptes bancaires :
$compte1->retirer(100); $compte2->dépôt(100);
Bien que la base de données des transactions puisse garantir que les retraits sont annulés si le dépôt ne peut pas être effectué (ou vice versa), elle ne peut pas nous empêcher d'oublier d'appeler soit $account1->withdraw() ou $account2->deposit() , ce qui entraînerait à une opération incorrecte.
Heureusement, nous pouvons facilement résoudre ce problème en remplaçant les deux méthodes distinctes par une méthode transactionnelle :
$compte1->transfert(100, $compte2);
En conséquence, notre code devient plus fiable, puisqu’il sera plus difficile de se tromper en complétant partiellement une transaction.
Exemples de détection d'erreurs
Les mécanismes de détection des erreurs ne sont pas conçus pour prévenir les erreurs. Ils ne devraient nous alerter des problèmes que lorsqu’ils sont découverts. La plupart du temps, ils se trouvent en dehors de notre application et vérifient le code à certains intervalles ou après des modifications spécifiques.
Tests unitaires
Les tests unitaires peuvent être un excellent moyen de garantir le bon fonctionnement du nouveau code. Ils permettent également de garantir que le code fonctionne toujours correctement après que quelqu'un ait refactorisé une partie du système.
Puisqu'on peut oublier de faire des tests unitaires, il est recommandé d'exécuter automatiquement des tests lorsque des modifications sont apportées à l'aide de services tels que Travis CI et GitLab CI. Ils permettent aux développeurs d'être avertis en cas de problème, ce qui permet également de garantir que les modifications apportées fonctionnent comme prévu.
En plus de détecter les erreurs, les tests unitaires sont d'excellents exemples d'utilisation de parties spécifiques du code, ce qui évite les erreurs lorsque quelqu'un d'autre utilise notre code.
Rapports de couverture des tests de code et tests de mutation
Comme nous pouvons oublier d'écrire suffisamment de tests, il est utile lors des tests de générer automatiquement des rapports de couverture de code à l'aide de services tels que Coveralls. Chaque fois que la couverture de notre code diminue, Coveralls nous envoie une notification afin que nous puissions ajouter les tests manquants. Grâce à Coveralls, nous pouvons également comprendre comment la couverture du code évolue au fil du temps.
Une autre façon de nous assurer que nous disposons de suffisamment de tests unitaires consiste à utiliser des tests de mutation, par exemple en utilisant Humbug. Comme leur nom l'indique, ils vérifient si notre code est suffisamment couvert par les tests en modifiant légèrement le code source puis en exécutant des tests unitaires, qui devraient générer des erreurs dues aux modifications apportées.
Grâce aux rapports de couverture de code et aux tests de mutation, nous pouvons garantir que nos tests unitaires sont suffisants pour éviter les erreurs.
Analyseurs de codes statiques
Les analyseurs de code peuvent détecter les bogues dans notre application dès le début du processus de développement. Par exemple, les IDE comme PhpStorm utilisent des analyseurs de code pour nous alerter des erreurs et nous donner des indices lorsque nous écrivons du code. Les erreurs peuvent aller de simples erreurs de syntaxe à du code en double.
En plus des analyseurs intégrés à la plupart des IDE, nous pouvons inclure des analyseurs tiers et même personnalisés dans le processus de création de nos applications pour identifier des problèmes spécifiques. Une liste partielle des analyseurs adaptés aux projets PHP peut être trouvée sur GitHub.
Enregistrement
Contrairement à la plupart des autres mécanismes de détection d'erreurs, la journalisation peut aider à détecter les erreurs dans une application pendant son exécution en production.
Bien entendu, cela nécessite que le code écrive dans un journal chaque fois que quelque chose d’inattendu se produit. Même lorsque notre code prend en charge les loggers, nous pouvons les oublier lors de la configuration de l'application. Par conséquent, les dépendances facultatives doivent être évitées (voir ci-dessus).
Si la plupart des applications conservent au moins quelques logs, les informations qui y sont écrites deviennent vraiment intéressantes lorsqu'elles sont analysées et contrôlées à l'aide d'outils comme Kibana ou Nagios. Ils peuvent fournir un aperçu des erreurs et des avertissements qui se produisent dans notre application lorsque les utilisateurs l'utilisent activement, plutôt que lorsqu'elle est testée.
Ne supprimez pas les erreurs
Même lors de la journalisation des erreurs, il arrive que certaines d’entre elles soient supprimées. PHP a tendance à continuer à fonctionner lorsqu'une erreur « récupérable » se produit. Cependant, les erreurs peuvent être utiles lors du développement ou du test de nouvelles fonctionnalités, car elles peuvent indiquer des erreurs dans le code. C'est pourquoi la plupart des analyseurs de code vous avertissent lorsqu'ils détectent que vous utilisez @ pour la suppression des erreurs, car cela peut masquer des erreurs qui réapparaîtront inévitablement une fois l'application utilisée.
Généralement, il est préférable de définir le niveau error_reporting de PHP sur E_ALL pour garantir que même les plus petits avertissements soient signalés. Cependant, veillez à enregistrer ces messages quelque part et à les cacher aux utilisateurs afin qu'aucune information sensible sur l'architecture de votre application ou sur les vulnérabilités potentielles ne soit exposée aux utilisateurs finaux.
En plus de error_reporting , il est important de toujours inclure strict_types pour empêcher PHP d'essayer automatiquement de convertir les arguments de fonction en leur type attendu, car cela peut conduire à des erreurs difficiles à trouver (telles que des erreurs d'arrondi lors de la conversion de float en int).
Utilisation en dehors de PHP
Puisque le poka-yoke est plus un concept qu’une technique spécifique, il peut également être appliqué dans des domaines non PHP.
Infrastructure
Au niveau de l'infrastructure, de nombreuses erreurs peuvent être évitées en créant un environnement de développement partagé identique à l'environnement de production, à l'aide d'outils tels que Vagrant.
L'automatisation du déploiement d'applications à l'aide de serveurs de build tels que Jenkins et GoCD peut aider à éviter les erreurs lors du déploiement des modifications de l'application, car le processus peut impliquer de nombreuses étapes, dont certaines sont faciles à oublier.
API REST
Lors de la création d'une API REST, vous pouvez implémenter poka-yoke pour rendre l'API plus facile à utiliser. Par exemple, nous pouvons garantir que nous renvoyons une erreur chaque fois qu'un paramètre inconnu est transmis dans l'URL ou dans le corps de la requête. Cela peut sembler étrange puisque nous voulons évidemment éviter de casser nos clients API, mais il est généralement préférable d'alerter les développeurs utilisant notre API en cas d'utilisation abusive dès que possible afin que les bugs soient corrigés dès le début du processus de développement.
Par exemple, nous pourrions avoir un paramètre de couleur dans notre API, mais une personne utilisant notre API pourrait accidentellement utiliser le paramètre de couleur. Sans aucun avertissement, ce bug pourrait facilement se retrouver en production avant que les utilisateurs finaux ne le remarquent.
Pour savoir comment créer des API qui ne vous poseront aucun problème, lisez Créer des API que vous ne détesterez pas.
Configuration des applications
Presque toutes les applications nécessitent une certaine forme de personnalisation. Le plus souvent, les développeurs fournissent autant de paramètres par défaut que possible, ce qui simplifie la configuration. Cependant, comme dans l'exemple de couleur et de couleur, il est facile de se tromper sur les paramètres de configuration, ce qui entraîne le retour inattendu de l'application aux valeurs par défaut.
De tels moments sont difficiles à suivre, car l'application ne déclenche pas l'erreur en tant que telle. Et la meilleure façon d'être averti en cas de configuration incorrecte est simplement de ne fournir aucune valeur par défaut et de générer une erreur dès que le paramètre de configuration est manquant.
Prévenir les erreurs des utilisateurs
Le concept poka-yoke peut également être utilisé pour prévenir ou détecter les erreurs des utilisateurs. Par exemple, dans un logiciel de comptabilité, le numéro de compte saisi par l'utilisateur peut être vérifié à l'aide d'un algorithme de chiffre de contrôle. Cela vous évitera de saisir un numéro de compte comportant une faute de frappe.
Conclusion
Bien que poka-yoke ne soit qu'un concept et non un ensemble spécifique d'outils, il existe divers principes que nous pouvons appliquer au code et au processus de développement pour éviter les erreurs ou les détecter tôt. Très souvent, ces mécanismes seront spécifiques à l'application elle-même et à sa logique métier, mais il existe plusieurs techniques et outils simples qui peuvent être utilisés pour fiabiliser n'importe quel code.
La principale chose à retenir est que même si nous voulons éviter les bugs en production, ils peuvent être très utiles pendant le développement et nous ne devons pas avoir peur de les initier le plus tôt possible pour les rendre plus faciles à suivre. Ces erreurs peuvent être générées soit par le code lui-même, soit par des processus distincts qui s'exécutent séparément de l'application et la surveillent en externe.
Pour réduire davantage le nombre d'erreurs, nous devons nous efforcer de garantir que les interfaces publiques de notre code sont aussi simples et compréhensibles que possible.
Mots clés:
- PHP
- taper une allusion
- validation
Le système, développé par S. Shigeo, ingénieux dans sa simplicité et son effet obtenu, repose sur l'idée d'établir une relation entre les erreurs possibles et les défauts qui en découlent. S. Shigeo a séparé la cause de l'effet - l'erreur du défaut, prouvant que la première mène au second. L’idéologie du système Poka Yoke est aussi simple qu’ingénieuse : les erreurs ne doivent pas conduire à des défauts.
Poka Yoke est un système qui permet de détecter les erreurs dans le processus de production, évitant ainsi l'apparition de défauts de fabrication.
L'utilisation du système développé par S. Shigeo garantit une qualité de produit à 100%, mais seulement s'il est possible d'éviter les erreurs dans le processus de production.
Au début de ses activités de recherche, S. Shigeo était un ardent partisan de l'utilisation de méthodes statistiques pour le contrôle de la qualité, mais au fil du temps, il en a perdu ses illusions. Les méthodes qu'il a développées, et notamment le système Poka Yoke, permettent de prévenir l'apparition de défauts, alors que les méthodes statistiques ne peuvent que les reconnaître et les mesurer. Après que les unités de production de Matsushita Electric, qui ont mis en œuvre le système Poka Yoke, ont fonctionné sans défaut pendant sept mois en 1977, S. Shigeo a finalement abandonné l'utilisation de méthodes statistiques de contrôle qualité, et le système qu'il a développé a prouvé son efficacité dans la pratique. Le succès du système n’est pas dû au hasard. L'utilisation du système Poka Yoke améliore considérablement l'efficacité du processus de production, contribuant ainsi à réduire les déchets et les coûts, facteurs critiques lors de l'évaluation des performances de toute organisation.
Bien plus tôt, en 1969, alors qu'il travaillait chez Toyota, S. Shigeo a développé le système « d'échange de matrice en une minute » (SMED) - un changement d'équipement rapide, qui peut réduire considérablement les temps d'arrêt de production et augmenter la flexibilité du processus de production.
Lorsque les temps d'arrêt de production sont réduits grâce à l'utilisation du SMED et que les produits fabriqués ont la garantie zéro défaut, il devient possible d'utiliser efficacement les systèmes Just-in-time et Kanban, que S. Shigeo a mis en œuvre avec succès dans de nombreuses entreprises.
STRUCTURE
Le cours électronique contient 4 chapitres, qui comprennent 17 conférences, 14 ateliers et 60 questions d'auto-test.
Temps d'étude 20 heures.
Autres noms de la méthode : « Poka-yoke », « Prévention des erreurs invisibles ».
Objectif de la méthode
Augmenter la valeur d'usage des produits en évitant les erreurs dans la production existante.
L'essence de la méthode
Le concept de prévention des événements indésirables provoqués par une erreur humaine est simple. Si vous évitez leur apparition dans la production existante, la qualité sera élevée et les modifications seront minimes. Cela conduit à une satisfaction accrue des clients et en même temps à une réduction des coûts de production.
Plan d'action
1. Former une équipe de spécialistes : représentants de la direction, du service qualité, du service technique et de la production.
2. Identifiez les problèmes qui nécessitent des solutions et les raisons de leur existence.
3. Développer des mesures pour améliorer la production et prévenir les risques d'erreurs, guidés par les règles d'utilisation de la méthode poka-yoke.
4. Éliminez les erreurs potentielles en utilisant des montages, des instruments et des équipements améliorés dans le processus de production.
Caractéristiques de la méthode
La version moderne du contrôle des erreurs, connue sous le nom de poka-yoke1, est née au Japon pour améliorer la qualité des produits en évitant les erreurs dans la production existante. Auparavant, les experts japonais utilisaient le terme baka-yoke. La traduction littérale du terme « baka-yoke » est « protection contre la bêtise », en d'autres termes, il s'agit d'un dispositif de protection grâce auquel les défauts ne se forment tout simplement pas. Il convient de noter que les principales dispositions de ce concept ont été largement utilisées par Ford dès 1908.
Il existe de nombreux moyens et techniques pour prévenir les erreurs, depuis de simples modifications et modifications apportées aux processus de fabrication des équipements et des produits, jusqu'à une modernisation sérieuse de la conception des produits.
Un exemple d'utilisation d'une technique simple de protection contre les erreurs
En atelier, malgré toutes les statistiques, marquages et contrôles, deux erreurs identiques se répètent sans cesse : lors de la pose d'un bloc, la pièce A se retrouve souvent dans la fenêtre 2, et vice versa, la pièce B se retrouve dans la fenêtre 1.
Une technique simple de détection des erreurs - le poka-yoke - vous permet de trouver une solution qui rend toute erreur impossible. Les configurations de la fenêtre 1 et de l'élément de montage A sont tellement modifiées qu'un remplacement lors de l'installation est même théoriquement impossible.
Règles d'application des techniques de protection contre les erreurs
1. Rapprochez-vous le plus possible de la source du problème, de l'endroit où le problème s'est réellement produit et de l'endroit où il peut réapparaître.
2. Introduire immédiatement tous les types de contrôles et mesures nécessaires pour éviter que le problème ne se reproduise.
3. Lors du développement et de la conception, utilisez des méthodes et des techniques complexes pour éliminer les problèmes et, en production, utilisez des solutions simples et rapides.
4. Les améliorations de la production doivent être réalisées rapidement, sans analyses complexes et de manière à ce que tout le monde soit impliqué dans la résolution des problèmes communs et l'élimination des incohérences.
Avantages de la méthode
L'application cohérente de diverses méthodes et techniques de prévention des erreurs peut réduire considérablement leur nombre, ce qui contribue à réduire les coûts et à accroître la satisfaction des clients.
Inconvénients de la méthode
La résistance à l’introduction forcée de dispositifs de contrôle des erreurs dans la production existante fait souvent échouer les efforts visant à améliorer le processus.
résultat attendu
Haute valeur de consommation des produits.
Méthode juste à temps
Juste à temps (eng. Juste à temps, exactement à l'heure) - l'un des piliers fondamentaux du système de production Toyota, une méthode d'organisation de la production. Cela consiste dans le fait qu'au cours du processus de production, les pièces nécessaires à l'assemblage apparaissent sur la chaîne de production exactement au moment où elles sont nécessaires, et dans la quantité strictement requise. En conséquence, une entreprise qui met systématiquement en œuvre ce principe élimine les temps d’arrêt, minimise les stocks ou peut les réduire à zéro. Les principales caractéristiques sont de ne disposer que des fournitures nécessaires en cas de besoin ; améliorer la qualité jusqu’au « zéro défaut » ; réduire le temps de cycle en réduisant le temps d'équipement, la taille de la file d'attente et la taille des lots de production ; modifier progressivement les opérations elles-mêmes ; et réaliser ces activités à moindre coût.
La méthode du juste à temps a été inventée en 1954. chez Toyota Corporation. Elle est née des restrictions économiques qui prévalaient alors au Japon. Comme le Japon disposait de peu de ressources naturelles et de prix immobiliers très élevés, il était nécessaire que les entreprises japonaises n'autorisent pas d'activités inutiles, telles que les entrepôts pour d'importants stocks de marchandises éventuellement excédentaires.
Applications du JIT
· JIT dans la zone de production - couvre le processus de production contrôlé par JIT ;
· JIT dans le domaine des fournitures ;
· JIT dans le domaine des ventes - fournit des fournitures à de nombreux consommateurs qui soumettent leurs demandes aux systèmes d'information en ligne.
La direction japonaise réalise le principe du juste à temps en évitant systématiquement trois composantes indésirables :
MURI - excédent
MUDA - pertes
MURA – déséquilibre
Les avantages de cette méthode peuvent être déterminés :
· Réduction des coûts pour l'entretien des stocks de l'entrepôt (magasins, matériel d'entrepôt, location de locaux d'entrepôt, etc.).
· Réduire le temps de traitement des commandes(en raison de la réduction de la taille des lots, du temps de changement et des temps d'arrêt).
· Meilleur approvisionnement en matériaux, pièces et produits semi-finis en raison de la localisation des fournisseurs plus proches des fabricants (en outre, plus d'emplois, développement régional).
· Planification à long terme pour les fournisseurs et une meilleure commercialisation des marchandises.
· Rationalisation de la production par la spécialisation des fournisseurs sur les marchandises commandées, etc.
Problèmes d'application possibles :
· Coûts élevés du transport et de l'aménagement des itinéraires de transport (charge élevée sur l'itinéraire, possibilité d'embouteillages, bruit dû au transport).
· Forte dépendance à l'égard d'un seul fournisseur (si les délais de livraison ne sont pas respectés, des pertes de production sont possibles).
· Forte dépendance à l'égard du respect de la qualité des matériaux fournis (coûts de contrôle à l'arrivée, réclamations).
· Un échange constant d'informations est requis (obligation de confirmer la situation financière du fournisseur et du fabricant).
· Amendes élevées pour les fournisseurs en raison du non-respect des délais de livraison, forte dépendance à l'égard d'un seul consommateur.
· La nécessité pour les fournisseurs de rapprocher la production et les entrepôts des consommateurs.
· Pertes importantes pour les fournisseurs dues à la spécialisation dans les situations de crise.
Projet de cours dans la discipline
"Moyens et méthodes de management de la qualité"
(études extra-muros)
Exigences
(Volume approximatif : 20-30 pages (hors demandes de certification QMS), format papier A4, taille de police 14 (Times New Roman), interligne – 1.)
Introduction(0,5 – 1 page).
Partie théorique
1. Gestion. La qualité comme objet de gestion
2. Brève description des versions actuelles des normes de la série ISO 9000 (9000, 9001, 9004).
3. Aspects théoriques de l'utilisation des outils et méthodes de gestion de la qualité nécessaires à la réalisation de la section 2 des travaux (brièvement, principales dispositions et étapes).
3.1 Mission de l'entreprise.
3.2 Objectifs de l'entreprise.
3.3 Base théorique pour mener une analyse SWOT et une analyse PEST.
3.4 Fondements théoriques pour déterminer les paramètres de qualité et évaluer la qualité d'un produit/service.
3.5 Fondements théoriques de l'analyse AMDEC.
3.6 Fondements théoriques pour la construction du schéma d'Ishikawa.
3.7 Fondements théoriques pour la construction d'un diagramme de Pareto.
3.8 Caractéristiques générales du concept Lean Manufacturing
3.9 Base théorique de la méthode Poka-Yoke
Partie pratique
1 . Brève description de l'entreprise . Fournir une description de l'entreprise, y compris les informations suivantes : historique, structure organisationnelle, domaines d'activité, gamme et caractéristiques des produits fabriqués/services fournis, informations sur le système de gestion de la qualité (le cas échéant), description de la ou des unités impliquées. en matière de qualité, perspectives et stratégie de développement) .
2 . Mission d'entreprise. Formuler la mission de l'entreprise sélectionnée.
3. Objectifs de l'entreprise.
3.1 Développer une structure hiérarchique d'objectifs, en fonction de la structure organisationnelle, indiquant les objectifs de croissance de l'entreprise, conformément aux exigences clés. Indiquez les dirigeants responsables de la division de l'entreprise pour la mise en œuvre de ces objectifs. Inscrire les résultats obtenus dans le tableau 1.
Tableau 1. Matrice des objectifs de l'entreprise
3.2 Construire un arbre d’objectifs sur une période d’un an auquel la direction de l’entreprise est confrontée pour mener à bien la mission (Figure 1).
Riz. 1 Représentation structurelle simplifiée de l'arbre des objectifs
4. Analyse SWOT/PEST
Effectuer une analyse SWOT (ou PEST, facultative) de l’entreprise. Remplissez la matrice appropriée en fonction des résultats de l'analyse.
Formuler des conclusions basées sur les résultats de l’analyse. Élaborer des recommandations pour l'entreprise sur la base des résultats de l'analyse.
5. Caractéristiques des paramètres de qualité du produit/service.
Sélectionnez un produit/service à analyser. Décrire la liste des paramètres de qualité des produits (services) et leurs exigences.
6.Analyse AMDEC
Pour compléter cette section, les informations sur le produit/service sélectionné dans la section 5 sont utilisées.
6.1 Déterminer la liste des défauts potentiels (incohérences) du produit (service) sélectionné à la section 5. Pour chaque défaut potentiel, déterminez une liste de conséquences. Déterminer l'indicateur complexe S, caractérisant le niveau global de toutes les conséquences de chaque défaut potentiel (non-conformité) pour le consommateur, sur une échelle de 10 points (1 est le niveau minimum de conséquences ou leur absence, 10 est le niveau maximum de conséquences).
6.2 Pour chaque défaut, identifier une liste de causes potentielles. Plusieurs causes potentielles peuvent être identifiées pour un même défaut. Pour chaque cause d'un défaut, déterminez O, la probabilité de son apparition, sur une échelle de 10 points (1 - peu probable, 10 - inévitable).
6.3 Pour chaque défaut potentiel et chaque cause potentielle, déterminer le score de difficulté de détection D sur une échelle de 10 points (10 – défaut pratiquement indétectable, 1 – défaut détectable de manière fiable).
6.4. Pour chaque défaut potentiel et chaque cause potentielle, calculez le numéro de priorité du risque PFR à l'aide de la formule (1). PPR peut prendre des valeurs de 1 à 1000. Remplissez le tableau 2.
PFR =S*O*D (1)
PHR - numéro de risque prioritaire ;
S - degré de conséquences d'un défaut potentiel ;
O - Probabilité d'occurrence
Tableau 2. Défauts potentiels (non-conformités) du produit (service) ___________________
| Non. | S Degré de conséquences sur une échelle de 10 points (1 est le niveau minimum, 10 est le maximum) | O Probabilité d'occurrence sur une échelle de 10 points (1 - peu probable, 10 - inévitable) | D Difficulté de détection sur une échelle de 10 points (10 – défaut pratiquement indétectable, 1 – défaut détectable de manière fiable). | PCHR | |||
| 1.1 | 1.1.1 | ||||||
| 1.1.2 | |||||||
| … | |||||||
| 1.2 … | 1.2.1 | ||||||
| 1.2.2 | |||||||
| … | |||||||
| … | .. | ||||||
| .. | |||||||
| … | |||||||
| 2.1 | 2.1.1 | ||||||
| 2.1.2 | |||||||
| … | |||||||
| 2.2 | 2.2.1 | ||||||
| 2.2.2 | |||||||
| … | |||||||
| … | .. | ||||||
| .. | |||||||
| … | |||||||
| … |
6.5 Dresser une liste des défauts/raisons pour lesquels la valeur PPR dépasse 100 (le niveau PPR maximum autorisé).
6.6 Pour la liste compilée, élaborer des mesures préventives, notamment :
Mesures visant à réduire les conséquences d'un défaut (non-conformité) S ;
Mesures visant à prévenir les causes de non-conformité potentielle O ;
Mesures visant à augmenter le degré de fiabilité de la détection des défauts D ;
Remplissez le tableau 3.
Tableau 3. Mesures pour prévenir les défauts potentiels dont le PPD dépasse 100 (valeur admissible).
| Non. | Défauts potentiels (non-conformités) | Liste des conséquences potentielles d'un défaut (non-conformité) | Causes potentielles de défaut (non-conformité) | PCHR | Mesures préventives | ||
| Mesures pour réduire les conséquences d'un défaut (non-conformité) S | Mesures pour prévenir les causes de non-conformité potentielle O | Mesures visant à améliorer la fiabilité de la détection des défauts D | |||||
| 1.1 | 1.1.1 | ||||||
| 1.1.2 | |||||||
| … | |||||||
| 1.2 … | 1.2.1 | ||||||
| 1.2.2 | |||||||
| … | |||||||
| … | .. | ||||||
| .. | |||||||
| … | |||||||
| 2.1 | 2.1.1 | ||||||
| 2.1.2 | |||||||
| … | |||||||
| 2.2 | 2.2.1 | ||||||
| 2.2.2 | |||||||
| … | |||||||
| … | .. | ||||||
| .. | |||||||
| … | |||||||
| … |
7.« Méthodes simples » de gestion de la qualité (diagramme d'Ishikawa, diagramme de Pareto).
Schéma Ishikawa
Analyser les raisons des défauts du produit/service sélectionné. Remplissez le tableau 5.
Tableau 4. Raisons des défauts du produit/service ___________________
| Catégories de raisons | Raisons de la 1ère commande | Raisons de la 2ème commande | Raisons de 3ème commande |
| 1. | 1.1 | 1.1.1 | 1.1.1.1 |
| 1.1.12 | |||
| 1.1.1.3 | |||
| 1.1.2 | 1.1.2.1 | ||
| 1.1.2.2 | |||
| 1.1.2.3 | |||
| 1.1.3 | 1.1.3.1 | ||
| 1.1.3.2 | |||
| 1.1.3.3 | |||
| … | … | ||
| 1.2 | 1.2.1 | 1.2.1.1 | |
| 1.2.1.2 | |||
| 1.2.1.3 | |||
| 1.2.2 | 1.2.2.1 | ||
| 1.2.2.2 | |||
| 1.2.2.3 | |||
| 1.2.3 | 1.2.3.1 | ||
| 1.2.3.2 | |||
| 1.2.3.3 | |||
| … | … | ||
| 1.3 | 1.3.1 | 1.3.1.1 | |
| 1.3.1.2 | |||
| 1.3.1.3 | |||
| 1.3.2 | 1.3.2.1 | ||
| 1.3.2.2 | |||
| 1.3.2.3 | |||
| 1.3.3 | 1.3.3.1 | ||
| 1.3.3.2 | |||
| 1.3.3.3 | |||
| … | … | ||
| … | |||
Construisez un diagramme d’Ishikawa en y affichant les données du tableau 4.
Tirer et décrire des conclusions basées sur les résultats de son analyse.
diagramme de Pareto
7.2.1 Analysez le schéma d'Ishikawa à l'aide du diagramme de Pareto - sélectionnez les raisons les plus significatives conduisant à 80 % des défauts du produit/service, sur lesquelles vous devez vous concentrer. Pour ce faire, il est nécessaire de construire le tableau 5. La base de construction du tableau 5 est la dernière colonne du tableau 4 - les raisons de cette dernière (2ème, 3ème...nème ordre, identifiées lors de l'analyse des raisons du produit défectueux /service)
Tableau 5. Raisons des défauts du produit/service ___________________
| Évaluez chaque raison sur une échelle de 10 points en fonction du degré de son influence sur le règlement du mariage (10 est le degré maximum, 1 est le degré minimum) | |
| 1.1.1.1 | |
| 1.1.12 | |
| 1.1.1.3 | |
| 1.1.2.1 | |
| 1.1.2.2 | |
| 1.1.2.3 | |
| 1.1.3.1 | |
| 1.1.3.2 | |
| 1.1.3.3 | |
| … | |
| 1.2.1.1 | |
| 1.2.1.2 | |
| 1.2.1.3 | |
| 1.2.2.1 | |
| 1.2.2.2 | |
| 1.2.2.3 | |
| 1.2.3.1 | |
| 1.2.3.2 | |
| 1.2.3.3 | |
| … | |
| 1.3.1.1 | |
| 1.3.1.2 | |
| 1.3.1.3 | |
| 1.3.2.1 | |
| 1.3.2.2 | |
| 1.3.2.3 | |
| 1.3.3.1 | |
| 1.3.3.2 | |
| 1.3.3.3 | |
| … | |
Tableau 6. Données permettant de construire un diagramme de Pareto lors de l'analyse des défauts d'un produit/service ___________________
| Causes de la nième (dernière) commande | Notez chaque raison sur une échelle de 10 points (à partir du tableau 4), classée par ordre décroissant d'importance. | Poids (importance) de chaque raison, % | Poids cumulé (importance) de chaque raison, % |
| 1.1.1.1 | |||
| 1.1.12 | |||
| 1.1.1.3 | |||
| 1.1.2.1 | |||
| 1.1.2.2 | |||
| 1.1.2.3 | |||
| 1.1.3.1 | |||
| 1.1.3.2 | |||
| 1.1.3.3 | |||
| … | |||
| 1.2.1.1 | |||
| 1.2.1.2 | |||
| 1.2.1.3 | |||
| 1.2.2.1 | |||
| 1.2.2.2 | |||
| 1.2.2.3 | |||
| 1.2.3.1 | |||
| 1.2.3.2 | |||
| 1.2.3.3 | |||
| … | |||
| 1.3.1.1 | |||
| 1.3.1.2 | |||
| 1.3.1.3 | |||
| 1.3.2.1 | |||
| 1.3.2.2 | |||
| 1.3.2.3 | |||
| 1.3.3.1 | |||
| 1.3.3.2 | |||
| 1.3.3.3 | |||
| … | |||
| TOTAL | 100% |
7.2.3 Construire un diagramme de Pareto selon les données du tableau 6, identifier graphiquement les raisons à l'origine de 80 % des défauts.
Analysez le diagramme de Pareto et tirez des conclusions. Développer des mesures correctives/préventives pour éliminer/prévenir chaque cause.
Application de la méthodologie Poka-Yoke (Lean Manufacturing Concept)
Pour répondre à ce point, la liste des défauts/raisons générée à la clause 6.5 pour lesquels la valeur PPR dépasse 100 (le niveau PPR maximum admissible) est utilisée, ainsi que partiellement les données des tableaux 2 et 3.
8.1 Déterminer le niveau de priorité des problèmes - les classer en fonction du niveau estimé de RH
8.2 Remplissez le tableau 7.
Tableau 7. Application de la méthodologie Poka-Yoke pour se protéger contre d'éventuelles non-conformités avec un niveau de PFR > 100
Conclusion(0,5 – 1 page).
Définition Poka-yoke (japonais - protection contre les erreurs) - dispositifs ou procédures qui empêchent l'apparition de défauts dans les processus de production.
Poka-yoke. Exemple 2. Une photocellule qui se déclenche si une personne franchit (ou vice versa, ne franchit pas) une ligne de contrôle invisible. Par exemple, un assembleur doit nécessairement prendre et utiliser une certaine pièce.
Types d'erreurs humaines Oubli Manque de compréhension des raisons Sous-estimation Inexpérience Réticence Inattention Lenteur Manque de normes Surprise Intentionnalité
Sources de défauts Opération manquée Erreurs d'usinage Erreur de positionnement des pièces Pièces manquantes Mauvaises pièces Usinage de la mauvaise pièce Opération incorrecte Erreurs de configuration Installation incorrecte de l'équipement Utilisation d'outils ou de montages incorrects Fukushima-1.
Exemple de solution : Traitement de la coulée Problème : Pièces non traitées Solution : Changement de la goulotte pour identifier les pièces défectueuses Description du processus : Les pièces coulées sont traitées sur une machine automatique et transférées au processus suivant via la goulotte. Avant amélioration : Si une pièce non traitée arrive par la goulotte, la machine suivante dans le processus s'arrête anormalement et peut être endommagée. Dessin tiré du livre « Poka-Yoke. Améliorer la qualité des produits en évitant les défauts"
Exemple de solution à un problème : traitement de fonderie Après amélioration : Pour arrêter une pièce non usinée, une méthode a été développée qui prend en compte la différence de sa forme géométrique par rapport à la pièce usinée. La goulotte a été modifiée pour que la pièce non usinée s'arrête dans un bloc installé dans la goulotte et ne coule pas dans la machine suivante. Cela a évité les pannes de machines. Dessin tiré du livre « Poka-Yoke. Améliorer la qualité des produits en évitant les défauts"
