Chapter 10: Software Quality
- Capability Maturity Model Integration
- CoSQ Cost of Software Quality
- Commercial Off-the-Shelf Software
- Failure Mode and Effects Analysis
- Fault Tree Analysis
- Quality Function Deployment
- Software Process Improvement
- Software Quality Assurance
- Software Quality Control
- Software Quality Management
- Total Quality Management
- Verification and Validation
What is software quality, and why is it so important that it is included in many knowledge areas (KAs) of the SWEBOK Guide?
One reason is that the term software quality is overloaded. Software quality may refer: to desirable characteristics of software products, to the extent to which a particular software product possess those characteristics, and to processes, tools, and techniques used to achieve those characteristics. Over the years, authors and organizations have defined the term quality differently. To Phil Crosby, it was “conformance to requirements” . Watts Humphrey refers to it as “achieving excellent levels of “fitness for use” . Meanwhile, IBM coined the phrase “market-driven quality,” where the “customer is the final arbiter” [3*, p8].
More recently, software quality is defined as the “capability of software product to satisfy stated and implied needs under specified conditions”  and as “the degree to which a software product meets established requirements; however, quality depends upon the degree to which those established requirements accurately represent stakeholder needs, wants, and expectations” . Both definitions embrace the premise of conformance to requirements. Neither refers to types of requirements (e.g., functional, reliability, performance, dependability, or any other characteristic). Significantly, however, these definitions emphasize that quality is dependent upon requirements.
These definitions also illustrate another reason for the prevalence of software quality throughout this Guide: a frequent ambiguity of software quality versus software quality requirements (“the -ilities” is a common shorthand). Software quality requirements are actually attributes of (or constraints on) functional requirements (what the system does). Software requirements may also specify resource usage, a communication protocol, or many other characteristics. This KA attempts clarity by using software quality in the broadest sense from the definitions above and by using software quality requirements as constraints on functional requirements. Software quality is achieved by conformance to all requirements regardless of what characteristic is specified or how requirements are grouped or named.
Software quality is also considered in many of the SWEBOK KAs because it is a basic parameter of a software engineering effort. For all engineered products, the primary goal is delivering maximum stakeholder value, while balancing the constraints of development cost and schedule; this is sometimes characterized as “fitness for use.” Stakeholder value is expressed in requirements. For software products, stakeholders could value price (what they pay for the product), lead time (how fast they get the product), and software quality.
This KA addresses definitions and provides an overview of practices, tools, and techniques for defining software quality and for appraising the state of software quality during development, maintenance, and deployment. Cited references provide additional details.
The breakdown of topics for the Software Quality KA is presented in Figure 10.1.