Software quality and why it matters
This is the first post in a series of blog posts concerning software quality. In this post I will establish some basic terminology, discuss the basics of software quality and provide links to the other posts in this series.
What is software quality?
In these posts I will use the term software quality to refer to how well the non-functional requirements of a software system is implemented. Functional requirements are clearly expressed business needs that define what a system is supposed to do, e.g. the system should be able to calculate the VAT of an invoice. Non-functional requirements instead deals with how a system implements it’s functionality, e.g. the system should be build in a way that makes it easy to test and verify.
The most difficult thing in the software industry is actually figuring out exactly what to build. The reasons for this are many. One is that although you have a business need, that need might be fulfilled in several different ways. To make a good choice between the options you have you need to consider pros and cons of the different solutions which can be hard in complex environments. Even worse is the problem that humans are habitual thinkers, meaning that we often overlook a lot of very viable solution alternatives simply because we haven’t thought about it that way before.
Software quality isn’t easy
Just because figuring out what to build is the most difficult part it does not mean that building software with good quality is easy. A lot of man hours and money is spent each year on software quality. The biggest investments on software quality seems to be made on systems that have already acquired quality problems. Prevention is way cheaper than fixing the problem after the fact, much like most people would generally prefer to prevent heart disease as opposed to getting a heart transplant. But how come so many projects end up producing software with quality problems? One important reason is that companies tend to spend much more time on clarifying functional requirements than non-functional requirements. Another is that some companies falsely regard the implementation of non-functional requirements to not be important in the pursue of business success.
What it takes to reach business goals once, twice, trice
In order to reach the business goals that the software was created to fulfill the software of course need some functionality, but it also needs some quality. One example is execution speed or performance. In a global market with lots of competition a business with a slow responding website will not be able to compete with businesses that have faster websites that otherwise have similar offerings. However, software quality also affects the ability to fulfill new business goals down the road. If a software is successful and delivers good value to its owners there is a good chance that the owners wants more good things from the software. If adding such functionality to the software becomes very difficult due to the way the system was implemented it might be too expensive to be worth it, or take too long time to make the necessary modifications. In these situations quite a few businesses have seen their competition race ahead while they themselves are stuck in status quo.
The following list of posts (that will be updated frequently) treats the most important software quality aspects, one at the time. In addition to that I will also produce a separate post on how these different aspects affect one another.
- Availability (TBA)
- Reliability (TBA)
- Usability (TBA)
- Testability (TBA)
- Maintainability (TBA)
- How software quality attributes relate (TBA)
Note: I’m writing these posts as part of my work in the Akropolis book project that is managed by the Swedish chapter of IASA.