This is the first post, of more to come, about my thesis and the software quality model I have developed.
First I will explain in what context my thesis is placed. This post will focus on decisions made to actually form a ‘new’ model (actually, derived from…).
For my thesis I have investigated how to improve quality of a software product. The first step was to choose one of the five perspectives on quality, given by Garvin (see here for more information). The product based perspective is chosen for scoping reasons. With that perspective in mind, three software quality models where evaluated:
The first, and one of the most known models, is the model of Boehm (literally translated ‘the tree of Boehm’):
The second model was from Willmer and the third from Bemelmans. Basically Willmer takes Boehms model and took it a bit further in order to translate customer desires into metrics. Bemelmans takes a whole different approach: He takes three main characteristics: “requirements for usage”, “requirements for maintenance” and “requirements for product information”. Which each have their own sub-characteristcs. (though it does not look like a tree like Boehm, as it only has one dimension).
One model actually caught the attention because it tends to ‘translate’ customer language into a developer language. The basic idea is that a software quality characteristic is mapped with a metric. Unfortunately the book I had did not tell how to translate this. Also, there was a need to translate customer language into software quality characteristics. This was something that was not being explained either.
So how does the translation look like? Imagine a matrix, where at the left several software quality characteristics are given (for every row). And at the top, every column is a metric. With some means you could assign metrics to characteristics and get a basic idea what is important.
Taking the ‘translation matrix’ of Willmer as a starting point, I have developed a model that actually does three things:
1st. It translates customer language into software quality characteristics. Not only that, but it also gives a % of relevance. (more on that later).
2nd. The actual translation from characteristics to metrics. This looks a lot like how Willmer does this, but it also has a % per metric per characteristic.
3rd. The interpretation of metrics. This is where things get really concrete. Here the actual scoring is defined. How will the metric LOC be interpreted?
With these three, it is possible to actually ‘calculate’ the total quality of a software product, with the ‘product based perspective’ of Garvin in mind! (So, it does not tell you how to improve your processes. Nor does it tell you how customers experience the website).
So how do you use this model? Using the “Plan/Do/Check/Act” (Circle of Deming) as basis, the suggested plan is:
– First ‘define’ quality. (Plan)
– Meassure and analyse (Do)
– Evaluate (Check)
– Change definition / software (Act)
In my next posts I will explain briefly how the model looks like.
