A Universal Technique to Improve Software Quality

Everyone wants to improve software quality as much as possible, provided that it does not slow down delivering new functionality.

It just so happens that there is a single technique that can dramatically improve the quality of software development.  In this article, you will learn two key fundamentals:

  1. Knowledge of software size helps to improve software quality
  2. The process of sizing software helps to improve software quality
  3. This technique can find and help you eliminate 7-10% of all defects before coding.

Let us start with some fundamentals about software development.  All software has defects (bugs).  The bugs may be caused by poor coding or they may be caused by something else.  Perhaps we got the requirements wrong,  perhaps we misunderstood the requirements, perhaps we missed some important requirements.

Quite often requirements are the root cause of software bugs.  But we rarely spend the time looking at the requirements quality.  Why?  It’s important but rarely urgent.   Reviewing and refining requirements is almost never considered a critical activity on a project plan.  I have seen some very poor requirements being used “just so the developers can get started”.  But this is an inefficient process and will lead to significant unnecessary rework and delays.

Improve Software Quality by Knowing the Size

If you have worked with software sizing before, you’ll also know that the defect potential (the likely number of defects/ mistakes) in requirements is predictable.   This single piece of knowledge can guide you to be more efficient. It can inform you to introduce just the optimum amount of effort into requirements quality before coding, removing requirements bugs, before coding starts.

Example

Nowadays a typical car has about 5 million lines of code.  From historical data, we know that is likely to equate to about 100,000 function points (ISO measure of software size).  Also from historical data we know that there is (on average) a defect potential of 0.7 – 1.0 requirements defects per function point.  Thus there will (have) been 100,000 requirements defects.  If you track the number of defects found and removed, you can determine approximately how many are remaining.  Furthermore if you perform requirements reviews and examinations to find and fix requirements defects early, you will reduce the requirements defects that are carried forward when coding starts.

Knowing how many defects are potentially there informs you how much work you need to do to remove them.  If you optimise your (requirements) QA work targeting (not 100% but) 95% defect removal, then you will be on-track for a lean and efficient delivery.

For example, if you use ScopeMaster to examine and test your requirements before coding, you could probably find about 50,000 of these defects (50%) and avoid them reaching the developers.  Just imagine how much more efficient your developers would be if they started with requirements that had 50% fewer defects?

Valid Quality Metrics from Knowing the Software Size

Note CFP = COSMIC Function Points

Improve Software Quality with Functional Sizing

Improving quality with the process of sizing

The process of formal functional sizing is ideal for clarifying functional intent i.e. ambiguities.  Occasionally different terms are used but actually mean the same thing.  By examining the functional users and object types being handled by the users across a set of requirements, you can easily spot inconsistencies.   If two functions perform the same action on an object you might have a duplicate requirement.   If you have an object that should be fully maintained by your software, but your requirements are missing a critical data maintenance function, you may well have a missing requirement.  If a requirement involves many functional steps, it might be too complicated to code, it might need simplifying, we might consider this a complexity defect.  Collectively these five categories of requirements defect represent about 40% of all potential defects.  These defects are likely to be exposed by process of functional sizing.  Manual sizing of requirements is therefore an efficient and worthwhile QA activity.  Automated sizing from requirements with ScopeMaster is even more effective and thorough.  It will detect and report on these defects faster and more thoroughly than humans might achieve manually.

Conclusion

We have shown in this article that both the knowledge of functional size AND the process of sizing will improve software quality dramatically.  Specifically, 7-10% of all software bugs can be removed through the (automated) process of software sizing.  Then, knowledge of sizing can help optimise QA activities to help remove the remaining bugs.