Eight Steps To Describe Root Cause Analysis

In this assignment, I select the developing the wrong user interface of the AVP Systems payroll package my risk. Eights steps that I will be using to describe root cause analysis to determine the main cause of the problem.

Step 1: Identify problem: Problem identification is the first and the most important step is used for problem identification by defining a clear problem statement using the five Ws and two Hs(Chemuturi, 2010). Who? Individuals or clients linked with problem What? Developing the wrong user interface When? 21st September 2018 Where? Head office of AVP Systems identified by clients Why? Unacceptable record entries and maintenance How? Result misleading and misrepresents the final outcome. How many? Happens whenever the test is processed.

Step 2; Identify Team: If the problem cannot be solved quickly by an individual, use a team.

Software Engineers, developers, project managers, SQA experts, other professionals(Chemuturi, 2010)

Team made up of five members empowered to change rules.

Project manager is the project champion.

Assign roles and responsibilities.

Step 3: Immediate Action Prior to commencement of action re-validate the defect using a temporary measure until corrective action is implemented(Chemuturi, 2010). Must verify that immediate action was effective and conduct a pilot test to avoid recurrence of problem.(Chemuturi, 2010)

Step 4: Root Cause Team brainstorm possible causes of problem with stakeholders and use fish born diagram or causes of effect diagram for organization(Chemuturi, 2010) and the 5 whys with AVP Systems.

Step 5: Corrective Action Plan

Solutions will be verified to eliminate the problem, personnel’s responsibilities and timelines.

Charts, check sheets, Paretor charts as tools for effectiveness of corrective measure

Verification: the action taken will actually do what is intended free of triggering another problem(Chemuturi, 2010).

Validation: measurable evidence over time show that the action occurred worked without the problem(Chemuturi, 2010).

Step 6: Complete Action Plan

Ensure all planned actions are defined, executed and completed as planned(Chemuturi, 2010).

Verification and validation will reverse if a task is left out.

Plan compromise must be avoided.

Step7: Follow-up Plan

All actions above must be done completed to ensure the root cause.

Quality specialist will use data for testing and ensure compliance(Chemuturi, 2010)

To avoid recurrence of problem, sample data be used to test correctness of result(Chemuturi, 2010)

Step 8: Validate and close the project

Is the result follow-up result accurate?

If problem reoccurred, go back to step 4 for re-evaluation of root cause.

If problem is solved, have a good time with the team for success.

Document, publish team effort, obtain customer satisfaction.

According to (Chemuturi, 2010) preventive measure will be adopted to forestall future occurrence based on diagnosis of the problem using similar forms with same fields on the user interface for comparison. Hence, it also eliminates error on the affected process or the product(Raj Kiran and Ravi, 2008; Chemuturi, 2010).

References:

Chemuturi, M. (2010) ‘Mastering Software Quality Assurance’.

Fitzgerald, B. and Stol, K. J. (2017) ‘Continuous software engineering: A roadmap and agenda’, Journal of Systems and Software. doi: 10.1016/j.jss.2015.06.063.

Goševa-Popstojanova, K. and Trivedi, K. S. (2001) ‘Architecture-based approach to reliability assessment of software systems’, Performance Evaluation. doi: 10.1016/S0166-5316(01)00034-7.

Jelinski, Z. and Moranda, P. (1972) ‘SOFTWARE RELIABILITY RESEARCH’, in Statistical Computer Performance Evaluation. doi: 10.1016/B978-0-12-266950-7.50028-1.

Raj Kiran, N. and Ravi, V. (2008) ‘Software reliability prediction by soft computing techniques’, Journal of Systems and Software. doi: 10.1016/j.jss.2007.05.005.