The poka yoke system consists of 100% inspection and use of poka yoke devices. The inspection process provides detection, and poka yoke provides feedback and corrective actions. Poka yoke measures must be customized. Although numerous examples of poka yoke for manufacturing exist,[25], [26], [27] software examples are not as well documented. Tables 9.2 and 9.3 list poka yoke measures. Understanding causes of mistakes is important in devising poka yoke measures. But almost all mistakes are caused by human errors:[28]
Table 9.2. Common Poka Yoke Measures in Enterprise Software Development
Type of Poka Yoke Approach | Examples of Typical Poka Yoke Measures |
|---|
Preventing human | Designing components with unique signatures: This is done by errors carefully documenting software components or library programs so that the user knows what he is getting. The Java language has a capability called introspection that allows the using program to ask an object what it does and how it does it, to prevent such errors. Using linking procedures that respect signatures: The program can be given preambles that will prevent them from being misused, and objects can hide data and protect methods so that using programs cannot change or modify them in error. Use of error flags: Signaling an error condition by an error flag or exception so that an error handler can prevent transaction failure or database corruption. Root cause analysis and corrective measures required before work resumes: This is done in business applications by careful input editing and rejection of suspicious transactions to an exception file that is examined by a human expert, corrected, and reprocessed later. |
Warning about sources of defects | Component labeling and documentation: Documenting, classifying, and labeling software components. Determinate component hierarchies: Object hierarchies and object interfaces like Java uses. Flagging hierarchy violations: Java can do this if the object class is properly specified. |
Designing preventive mechanisms | Eliminating error-prone components: Use well-tested computer Library programs or classes or components. Amplification of human senses: Robotic and neural net programming technology. Redundancy in design (backup systems): Coding several versions of an algorithm to handle a variety of data input. Simplification by using fewer components: This is a major goal of program design; it is called reusability. Enhancing product producibility and maintainability: Design programs so that they are lucid, easily understood, and easily maintained and modified, typically by programmers much less experienced than the original authors. Selecting components that are proven: This is a very important aspect of reusable programs and is one of the main goals of object-oriented programming. |
Bug-prevention mechanisms | "Next operation as customer": All programmers thoroughly test their own work. Test prior work before adding any more value: Don't add anything to a program that has not been tested and may have faults. Test early and frequently. Install programmer's command: Real-time check or "automatic program correction." Use object-oriented programming: This helps avoid errors. Get rid of defect-prone software: If a software unit exceeds an error threshold, throw it out and let a different developer do the recoding. Early errors predict late errors. Statistical sampling can predict how many faults are left, but it cannot locate them. (The preceding steps cannot eliminate bugs, but they leave fewer and less complicated errors.) |
Preventive inspections | Source inspection: To check process errors and correct them at the source. Self-check inspection: Self-check by the software developer and fixing the product before handing it over. Successive check methods: Checks by the next person in the process and correcting problems before proceeding. |
Table 9.3. Examples of Poka Yoke in a DFTS Process
DFTS Phase | Common "Defects" | Mistakes That Cause Them | Mistake-Proofing Measures |
|---|
Requirements development | Erroneous requirements development | User can't express requirements clearly
User undervalues or overexpects
User changes application requirements frequently | QFD-based requirements development |
Design | Over-designing or a wrong design may result in the following: | Features are added/asked for because they are easy to add/ask for Inadequate communication between users and developers | QFD-based requirements development Team-based development led by application and programming leaders with the system architect as conflict revolver Taguchi Methods for design optimization FMEA/FTA for risk appraisal |
Coding | Programming bugs | Simple oversights on the part of programmers Misunderstanding of specifications Inexperience | Coding standards and hierarchy controls Team walkthroughs More-precise specifications Improved programmer training |
Test | Cannot check all the data paths | Application is too complex | More componentization More hierarchy levels |
Evluation | Inconsistent results | Incomplete testing criteria | Improved testing standards and procedures |
Verification | Results are not verifiable | Incomplete or defective test data and/or procedures | Better test plan |
Validation | Cannot make program produce correct result from verified test data | Error(s) during development | Error analysis to isolate process stage(s) where error(s) likely were made |
Implementation | Inconsistencies with two or more cooperating programs | Mistakes in human and machine communication | Error isolation by staged testing of partial results |
Integration | Individually correct components will not work together | Inconsistent or poorly specified interstitial component communications | Systematic review of component/object method invocation |
Maintenance | Lack of customer satisfaction | Maintenance programmer inadequacy vis-à-vis programmer creator | Training Adequate documentation Supervision |
