In one way or another, all the previous blogs which draw on Software Engineering Radio podcasts have been moving towards this short post about software quality. In TM354 Software Engineering, software quality is defined as “the extent to which the customer is satisfied with the software product delivered at the end of the development process”. It offers a further definition, which is the “conformance to explicitly stated requirements, explicitly documented development standards, and implicit characteristics that are expected of all professionally developed software”. The implicit characteristics can relate to non-functional requirements, or characteristics such as maintainability and readability.
The Software Engineering Body of Knowledge (SWEBOK) emphasises the importance of stakeholders: “the primary goal for all engineered products is to deliver maximum stakeholder value while balancing the constraints of development, maintenance, and operational cost, sometimes characterized as fitness for use” (SWEBOK v4, 12-2).
The SWEBOK also breaks ‘software quality’ into a number of subtopics: fundamentals, management processes, assurance processes, and tools. Software quality fundamentals relates to software engineering culture and ethics, notions of value and cost, models and certifications, and software dependability and integrity levels.
Software quality
After doing a trawl of Software Engineering Radio, I’ve discovered the following podcast: SE Radio 637: Steve Smith on Software Quality. This podcast is understandably quite wide ranging. It can be related to earlier posts (and podcasts) about requirements, testing and process (such as CI/CD). There are also connects to the forthcoming podcasts about software architecture, where software can be built with different layers. The point about layers relates to an earlier point that was made about the power and importance of abstraction (which means ‘dealing with complexity to make things simpler’). For students who are studying TM354, there is a bit of chat in this podcast about the McCabe complexity metric, and the connection between testing and code coverage.
Towards the end of the podcast (45:20) the connection between organisational culture and quality is highlighted. There is also a link between quality and lean manufacturing approaches, which have then inspired some agile practices, such as Scrum.
Reflections
Software quality is such an important topic, but it is something that is quite hard to pin down without using a lot of words. Its ethereal quality may explain why there are not as many podcasts on this topic when compared to more tangible subjects, such as requirements. Perhaps unsurprisingly, the podcasts that I have found appear to emphasise code quality over the broader perspective of ‘software quality’.
This reflection has led to another thought, which is: software quality exists across layers. It must lie within your user interfaces design, within your architectural choices, within source code, within your database designs, and within your processes.
One of the texts that I really like that addresses software quality is by Len Bass et al. In part II of Software Architecture in Practice, Bass et al. identify a number of useful (and practical) software quality attributes: availability, deployability, energy efficiency, integrability, modifiability, performance, safety, security, testability, and usability. They then later go on to share some practical tactics (decisions) that could be made to help to address those attributes.
As an aside, I’ve discovered a podcast which features Bass, which is quite good fun and worth a listen: Stories of Computer Science Past and Present (2014) (Hanselminutes.com). Bass talks about booting up a mainframe, punched card dust, and the benefit of having two offices.
References
Bass, D. L., Clements, D. P and Kazman, D. R. (2021) Software Architecture in Practice [Online], 4th edn, Upper Saddle River, NJ, Addison Wesley.