How to Measure Software Quality?

The software can be measured in the 'hard' way accordingly.

Software eats the world, all forward-looking organizations declare they are at information businesses and strive for software Quality, but most of them may not know how to define Quality. As the quality, especially software quality is contextual and relative, but still,  there can be a set of guidelines which can help the team to follow the best practices to measure software quality accordingly.

1. Why it’s Hard to Measure Software Quality 

There’s always debate upon quality's subjectivity and objectivity. Should a quality software only conform to its specification to move towards to the objectivity; or should software quality is always some sort of subjectivity, as it is a waste of time, money, and effort to build a product that conforms to its requirement specification if its end-users perceive that the product is less than fit for their view of its intended purpose. 

Software Quality can be subjective; it means various things to the different roles: As the product owner - quality may mean how many features you can deliver that are not buggy and how long does it take. This probably holds true for the customer as well. For a development manager/Scrum Master - it may mean how is the code developed and what are the deployment standards. In other words, is the code flexible and expandable, how long are enhancements taking to complete based on coding standards, automated testing, and unit test coverage? Also, can you build once in an automated fashion and deploy in all environments.  For the developer, it may mean - how easy is it to get started on an assignment? Is there good up to date documentation, preferably automatically created? Is there safeguards in place before you deliver code to an environment that ensures adherence to standards - static code analysis, unit test, automated testing, build pass/fail, style standards. 

Attempting to define quality in terms of metrics is attempting to define objective measures for a subjective attribute; you can measure lots of numbers, but you can't establish a comprehensive set of them. At some point, you have to look away from the metrics and toward your users and their often highly subjective opinions - which is a very Agile thing to do. If you have to choose between zero defects in a product the customer doesn't want, or "too many" defects in a product for which the customer is beating down your door, which is better for you in such circumstances. 

2.  Measure the ‘Health’ of Software Project  

The point is, if you don't know what exactly mean by Software Quality, you will never be able to justify the business value of that. And what you measure gets cared about and only focus on defects is too limiting, Perhaps the good approach is to measure the 'health' of software projects, trending the well-defined metrics to see how you're managing rework, defects, technical debt, automation, documentation and customer satisfaction, to name a few. So the measure is not about counting defects, but about: 

• Analyzing those defects that give you information on where to improve your process, and prevent similar defects in the future 

• Knowing what the quality of the product to be delivered will be, and take action if that quality will be insufficient early at lower costs. 

• Improving collaboration between designer and testers, by having them discuss defects and the measures that they can take to improve quality 

• Helping your stakeholders to balance quality and functionality. Help them to decide when to invest in testing, in reviews, and in defect prevention. 

• Manage your technical debt: Involving the EA early on, provide inputs from an architecture perspective, such as complexity management, reusability., etc. 

3. Measure Software Quality via Two Axes 

So, how shall you measure software quality? Quality is a quantity measured in two dimensions so you may need to measure it on two axes. The technical view (vertically?) and the user view (horizontally?). 

• The user view, measures the degree of satisfaction of all involved, as experienced on actual products. The product is of quality when it does:

1) What the users need it to do
2) The way they want to do it
3) Quickly enough
4) Accurately enough
5) Safely enough
6) Securely enough
7) Economically
8) and when they want it changed it is quick and easy to change

• The technical view: Confirm specification and the characteristics of quality software: What about measures of modularity, reusability, conformance to architectural standards, use of patterns, loose coupling, functional cohesion, testability, accessibility, portability, install-ability, reconfigurability.....  

Software quality is eminently measurable and achievable but only if we use suitably systematic and robust requirements elicitation and product development techniques. These techniques span the full spectrum from agile to well-planning. That whole spectrum requires high levels of training and DISCIPLINE.

Posted in: CIO Debate,IT Performance Management,KPIs,Project Management,Quality