Let’s start with some basics about software quality.
BasicsSoftware quality can be described as: how well we meet some requirements. It is often related to a business value. Is the customer satisfied with the product the paid for?
Customers are often people and what satisfies him will differ, therefore requirements for the product are well defined. The result is some form of minimum quality for the product that both the customer is satisfied with and the product developer can fulfill.
Requirements can be divided in two parts:
- functional requirements
- non-functional requirements
Non-functional requirements refer to quality that is not directly visible to the customer, like maintainability and efficiency. Compared to functional requirements, these are “soft”. These are often results from architectural decisions and developers coding practices. Measurement of these requirements can be difficult and needs to put in context to give a meaningful value.
What is good?Back to the second question, what is good? Maybe it’s easier to define the opposite. If something is good, it can also be “non-good”. We can call it bad. If the quality is bad, it does not behave as we are expecting. The requirements are not fulfill. The customer is not satisfied.
If the requirements instead are fulfill, then the customer should be satisfied of the quality. We can then define that if we meet the quality for something we have agreed on then it is good!
What about non-functional requirements? What if the code
- has extremely long source code files
- has functions that are pages long
- is really hard to understand
- only a part of it are covered with tests
- is so tight coupled that even dynamite won’t separate it
- needs extremely much memory and cpu
Yes it can!
The solution can be to use more hardware or increase the development time with a factor X. It won’t be cheep but the customer will be satisfied.
Or maybe there is another solution...
If it’s not good, how do we reach to that point?For functional requirements it’s easier to reach good quality because they have been agreed on with the customer. They are on paper. They can be measured.
Non-functional requirements are more trickier because the limit for “good” is something we state our self. We don’t agree with the customer who the product shall look inside. It more about how much work are we willing to put down for a product?
If it's good, can it be any better?I just claimed that the customer can be satisfied and the functional requirements are fulfill, even if the internal structure is a mess. He will probably not be overwhelmed. The good parts will weight more than the bad parts, as specified in the requirements.
But what if the internal structure (code) would be
- easy to understand
- easy to change
- easy to test
- cpu and memory efficient
Can we improve it?Back to the end question, software quality - can we improve it?
Yes we can!
By having good quality on the internal structure the product cost will decrease and improvements of the functional requirements are easier to implement.