Before I started my research on Software Quality I defined a couple of criteria a good definition of Software Quality should fulfil:
-
The definition should be simple so that all involved people can understand it, not just software engineers.
-
Ideally it makes sense intuitively because I want it to be helpful in complex cases.
-
And it should be flexible. Different products have different requirements. A good definition works reasonably well for most products.
Wikipedia provides a collection of different definitions, among others one by CISQ based on the ISO 25000:2005 quality model called SQuaRE, consisting of five quality-attribute-like "major characteristics". Without having spent several hundres of US dollars for the ISO standard and without having read it, the standard looks complicated. Perhaps it is flexible, but doesn’t feel particularly intuitive.
When I read "quality is a perceptual, conditional and somewhat subjective attribute and may be understood differently by different people" (Wikipedia) I began to understand why Software Quality is such a challenging topic. Naively I originally assumed that there would be a small set of widely-accepted principles like SOLID for object-oriented programming.
The situation gets worse when we try to measure Software Quality. Measurements feel objective, even though the measured topic might be subjective. So I gave up on a universal Software Quality definition. Giving up on Software Quality itself is not an option. It’s too important a topic.
In a follow-up article I’ll present a subjective Software Quality definition aiming to address my criteria and a model to reason about the quality of a concrete product.