5 Software quality
In very abstract terms, the quality of an artefact, whether it is software or otherwise, relates to the presence of positive characteristics of the artefact which will satisfy stakeholders’ needs and expectations in a particular real-world context. Quality also relates to the absence of negative characteristics which may harm or frustrate stakeholders and fail to meet their needs and expectations in that context. It follows that quality is not an absolute property: it can only be judged and measured with reference to stakeholders’ needs and expectations within their context. This is particularly true of software, which is more often than not developed to address real-world problems as part of much wider systems, usually involving people, processes and other forms of technology.
So quality has to do with fitness for purpose, and the hallmark of a good quality product is that its diverse stakeholders are satisfied with it both now and in the foreseeable future. Managing software quality is then a continuous process aimed at ensuring that the software’s fitness for purpose is maintained throughout the software’s life-cycle.
Failure to attain fitness for purpose can have disastrous consequences, as witnessed by the many examples of software failure which have been reported over the years.
Activity 8
Do a web search on software failures. What did you find?
Discussion
You may have found plenty of high-profile software failures reported by the media and in the academic literature. We found a long list of postings and articles. For instance, Lake (2010) summarised 11 ‘epic’ software failures attributable to deliberate decisions by programmers (rather than, say, faults or malicious attacks), in fields ranging from space exploration and telecommunications systems, in which the loss was mainly financial, to medical and aviation applications, in which the result was a catastrophic loss of lives.
Activity 9
What do you think the quality expectations for an air traffic control software system might be? What about those for a personal diary mobile app?
Discussion
As lives depend on it, an air traffic control system will need to be highly dependable and safe to operate, and provide accurate and reliable information in real time which can be readily interpreted and understood by highly trained people – particularly the air traffic controllers who need to direct pilots. Lack of integrity of data or unavailability of the system could have catastrophic consequences.
Some aspects of dependability – such as data integrity and reliability – would also be desirable but not nearly as critical in a personal diary app. Ease of use would also be desirable as the app is likely to be used by people with all levels of skills.
While quality expectations might be different in different domains, there is a common need to build quality into product design, to increase the likelihood that the product is fit for purpose. Here is yet another role for software development processes: while there is no absolute guarantee, process quality is likely to lead to product quality, and the concern for achieving and maintaining quality needs to permeate all software activities throughout the software life-cycle.
Note: this is in line with Hall and Rapanotti’s view of assurance as a key factor in the development process.
Related to software quality is a distinction which is often made between the functional and non-functional characteristics that fit-for-purpose software should exhibit. Many such characteristics have been identified and variously classified in the literature.
Note: ISO/IEC 9126-1:2001, an international standard for software product quality, provides one such classification.
Some of these characteristics – those which are most relevant to this course – are listed below.
- Functional fitness determines the extent to which a system does what the customer wants and needs.
- Usability determines the effort required to learn about, operate, prepare input for and understand the output of a system – that is, how easy the system is to use.
- Flexibility determines the effort required to modify an operational system – that is, how easily the system can be changed while in service.
- Testability determines the effort required to test a system to ensure that it carries out its intended function – that is, how easily the system can be tested to show that the customer’s requirements have been met.
- Reusability determines the extent to which a system (or system component) can be reused in other applications – that is, how easy it is to reuse some of the software to make future developments more cost-effective.
Activity 10
Based on your own experience and practice, in what way do you think the various activities forming part of the software development process may impact on the quality of the released product?
Discussion
You may have covered some of the following points.
In analysis, validation of problem understanding and of what is required of the system is key to quality, as this determines both the desired functionalities of the system and its many non-functional characteristics. Eliciting knowledge directly from stakeholders, e.g., users or businesspeople, and discussing our assumptions explicitly with them would increase confidence in the accuracy of our understanding.
During design and implementation, following tried-and-tested approaches, good practice and sound principles increases the chance of achieving high-quality software. Access to experienced developers able to review the software is also a way to maximise quality all round.
Comprehensive and systematic testing is essential to reduce the rate of occurrence of software defects and generally verify overall software correctness. Various levels of testing exist – some involving a wide range of stakeholders, including end users. In some domains – for instance, safety-critical applications – the involvement of independent certification authorities might also be required.
In maintenance, it is important to track and correct defects in the software which become apparent after deployment, possibly providing end users with means to report errors easily or make suggestions for product improvement.
Finally, while an appropriate investment in quality processes is important to software quality, a quality culture is also required: an organisational environment in which the concern for quality is highly valued and where there is support for developers who care for all aspects of quality – even the less tangible ones such as code readability or adequacy of documentation. A quality culture is characterised by highly professional behaviour and ethical decision-making on the part of those involved in the process, and by the allocation of an adequate level of resources for specific activities which contribute to software quality: it is widely acknowledged that some software failures can be traced back to excessive pressure from management to release a product which had not been properly verified and validated, or to situations where developers were forced to cut corners in the interest of quicker delivery. A quality culture implies an effective and mature use of estimation, planning and risk management, and an integrated view of both human-related and hard technological issues.