The end-goal when bringing a product to market is having a fully developed, defect free product. To achieve this goal, problem resolution is an excellent way to eliminate issues that arise during development. Because every problem is different, formulating a procedure that ensures quality and consistency through the application of identifying and resolving such issues is critical. Procedures focused on problem resolution are best formulated around the Plan-Do-Study-Act (PDSA) methodology. This is an overview to guide you through the PDSA methodology as it relates to hardware/software systems.
 
1. Plan: Experiment for Problem Resolution
Begin by creating a series of test experiments aimed at identifying and resolving a problem reported or experienced in your product. Gather information by asking questions to determine the criticality and urgency of the issue. Identify the exact product and version in which the problem is occurring – this includes associated hardware, software and/or firmware. Review the results of prior experiments to drill down to the next logical step to identify the root cause and appropriate resolution.

Utilize the information you’ve gathered to define the problem. Assemble a team familiar with the product and issue. Define the issue as a gap between the current condition and the target condition. Gather and analyze source material to determine how this issue occurred. This information may include log files, diagnostic reports, witness accounts, environment, and actions taken by the product user.

Identify a method in which the team can recreate the issue, replicating the environment in which the condition occurred. With random or infrequent failures, this step is vital as a solution may not be found otherwise. Keep in mind that all failures may not be replicable on demand and an environmental setup that can produce a failure with some reasonable frequency may have to suffice.
 

2. Do: Implement the Experiment
In a controlled, methodical, well documented manner, begin to implement the experiment you created. Set up the experiment using the base software/firmware and hardware that is used. Name each experiment with the date version and test number, or description. Document each experiment in an organized manner, i.e. spreadsheet or table, allowing for quick tracking and analysis. Each test should be fully documented siting successes, failure, and grey areas. Don’t trust your memory! You’d be surprised how easy it is to forget how many clicks were needed or an exact sequence of events.

Unsuccessful experiments can be just as important as a successful one. It may imply that an assumption was false and can therefore be eliminated. Add these findings to the test documentation and continue to reanalyze. Successful experiments typically imply that the assumptions are correct, possibly identifying partial solutions or the complete resolution.

 
3. Study: Analyze Experiment Results
After a few rounds of experiments, pause to analyze the results that were performed. This will help in determining if additional rounds of experiments are required, or if the root-cause of the issue was found. Many times, a solution to a problem requires multiple corrections in multiple locations, therefore continual monitoring of the effects and results will help narrow down a resolution. This iterative process will identify partial solutions which can lead to additional experiments that identify areas required to fully implement a solution. At minimum, each experiment should lead the team to determine a simple true or false. No experiment is a failure. Each experiment offers information that was previously unknown.

Once a solution is found, another iteration is performed with just the solution. Upon final resolution, all enhancements must be tested as a complete solution. Many times, solutions to problems are found in various components of the system that appear to be totally unrelated. When combining these solutions that appear to be unrelated, new issues may occur. Therefore, testing of the complete solution is necessary and may reenter the process for final testing and study. Stress testing may be necessary and long-term testing is certainly required. Depending on the criticality of the product, the issue identified may be tested anywhere from days to months, possibly under extreme conditions.

 
4. Act: Implement and Adjust
Act is the adoption of change(s) to the software base on resolution of the issue or problem. There are two major components based on the results of experimentation, results, conclusions reached, and verification that a solution corrects the original issue without introducing new issues. First, introduce the correction, adjust the plan, and reconfirm through the plan the issue was corrected. Next, identify any additional issues, steps, and processes related to the original problem that should be addressed. Finally, document and report the root cause of the issue to all stakeholders including industry regulators, management, and investors, offering peace of mind that the issue is now resolved.

 
For more details on problem resolution, contact Precision Systems, Inc. today. One of our experienced engineering consultants will be happy to review this guide and provide direction as necessary.

Precision Systems Contact Info: 215-672-1860 | info@psi-software.com