Want to improve software quality based on fact and statistics?

4 min readDec 21, 2022

The software industry has an intention of sometimes being low-quality and unreliable, which is fair in some cases due to many factors. One of the main reasons for bad quality is that measuring quality is not so good.

Metrics like cost per defect and lines of code make the truth look different and hide how quality software is. Software measures leave out essential data, use risky metrics, and need to be more to show how sound methods like static analysis, inspections, and testing work.

One of the main reasons for bad quality is that measuring quality is not so good.

What will be the crucial aspects of not having quality software?

Two crucial aspects have an impact on the software’s quality. Defect potentials, also known as “reopened bugs,” are the total amount of bugs that may occur in requirements, architecture, design, code, and documents, as well as poor fixes which are also known as “reopened bugs” and are new bugs that arise after bugs are fixed.

The primary cause of this problem is the lack of adequate, quick unit tests that can determine whether or not new patches have broken anything in the current domain.

I believe that is the second most important metric is the number of problems found and fixed in software before it is sent to clients. It is also called DRE (DEFECT REMOVAL EFFICIENCY).

This means that Defect Removal Efficiency (DRE) lets the development team eliminate bugs before the product is released. DRE is calculated by comparing the number of bugs found by testers and software testing with the number of bugs found by customers.

DRE’s formula: DRE = (Number of defects found internally/ Number of defects found internally + Number of defects found externally) × 100.

The credits for this metric belong to IBM Inc. They came up with the metrics of defect potentials and defect removal efficiency (DRE) around 1970. Today, we can for sure say that it is used by many technology companies, insurance companies, banks, and other businesses with large software organizations. Let’s try to analyze and review some statistics.

The ranges of DRE from a sample of 1,000 software projects are shown in the chart and table above. The available software, web, cloud, and IT projects were in the instance.

You can see that high DRE only happens sometimes. This is a shame because projects with a DRE score of 95% or higher finish faster and cost less than those with a score of 85% or less.

But the most important economic fact about high quality is that projects with a DRE score of 97% or more are done faster and cost less than projects with a DRE score of 90% or less. This is because projects with a low DRE don’t do pre-test inspections or static analysis. Their test schedules are at least twice as long as those with a high DRE.

Poor quality causes a lot of big projects to be canceled.

Poor quality causes a lot of big projects to be canceled.

Recommendations

I believe the main gaps come from companies needing to invest significant software quality training for engineers. I’ve seen that some good education companies have actual, measurable data on where software bugs come from, how many bugs there are, how to stop bugs from happening or DRE levels. But they put money into learning more about software quality so that the process of making software works well. I would suggest taking classes from companies like Construx, QAI, and SANS Institute like Penzle QA Engeering Team does.

Still, they would probably only talk about one thing, like static analysis or testing that is done automatically. Even though the courses are helpful for everyone on their own. But companies must use best practices as standard methods and procedures when vertically making software.

Statistics per course and effort

Finally

I have found something surprising when you look at how hard people in software engineering work. A lot of the work that goes into software engineering is basically a “waste of time” because it involves working on projects that won’t be finished or fixing bugs that shouldn’t be there in the first place.

As a software engineer, I wrote this article for myself and then for other engeeners. I hope we will take these lessons from this fact with the next project and take defect prevention removal, reusability, and risk analysis more seriously than I do now.

Best luck!

You can find appendix following this link.

Originally published on https://www.linkedin.com/pulse/want-improve-software-quality-based-fact-statistics-admir-mujki%25C4%2587/

References: