The b(ack)log

Working towards software quality

Software quality remains to be an illusive topic. It’s hard to define, measure or enforce.

One way to to define software quality is how well functional and non functional requirements are met. This implies that requirements exists and are accurate. It also implies that the quality of the software changes whenever the requirements change! This is typically the type of software quality that will keep your manager and your client happy, for the time being…

For software that will be used and modified after the initial requirements have been satisfied (most software fall into this category), quality needs to be measured on a deeper level. Aspects like maintainability, changeability, testing, etc comes into play. This however remains hard to measure and enforce.

There are however certain things that contributes to software quality that aren’t that hard to measure or implement. Here is a list with some of those things:

It may be worthwhile to elaborate on topics such as requirements, design and documentation. These are things that can cause considerable overhead when done incorrectly. It a good idea to approach requirements, designs and documentation as tools that are used to arrive at a certain point. As such they contribute to the quality of the software, but does not necessarily represents the system in its current state.

Having all of the above mentioned things in place will not equate to high quality software. It still remains something that needs to be propagated and pursued by all involved parties.