The Pareto Principle in Software Quality

There are five main ways the Pareto principle can be applied to software development and software quality.

1. Identify the most commonly occurring defects so that they can be fixed. As J.M. Juran said, target the many, not the few. Putting time and energy into fixing these defects will have the greatest return on investment.
2. Identify the most expensive defects based on the cost to fix them or the cost incurred when they occur. Serious defects that crash a user’s system or cause the user to lose all data are the most severe, and these are the defects you should target. Juran called these the vital few.
3. Identify the most common class of error. Are most of the errors the result of typing errors? Are most of the errors logical? Are most defects in the software interface? Identify the most common type of error and focus software quality efforts, debugging and testing on that area.
4. Use the Pareto principal to identify when the defect rate has dropped below the point when it is worth the time and effort to continue looking for defects. Many software development models, such as software quality models that use seeding to generate estimates as to the number of defects a software application will have, create a quandary. Your model may say there should still be a few defects left in the code. When do you stop testing? When you’ve found at least 85% of the predicted software defects, software testing can drop off while major bugs or the most commonly occurring bugs are fixed. When 90% or more of the estimated number of bugs are found, it may no longer be cost effective to keep searching.
5. Prioritize software change requests and enhancements based on demand and need. Choose to make the changes that represent 80% of the user complaints, instead of the easiest one to implement or requested by the most demanding client.