Chapter 10: Software Quality

From SWEBOK
Revision as of 12:17, 29 August 2015 by Daniel Robbins (Talk | contribs)

Jump to: navigation, search


Acronyms
CMMI
Capability Maturity Model Integration
CoSQ
CoSQ Cost of Software Quality
COTS
Commercial Off-the-Shelf Software
FMEA
Failure Mode and Effects Analysis
FTA
Fault Tree Analysis
PDCA
Plan-Do-Check-Act
PDSA
Plan-Do-Study-Act
QFD
Quality Function Deployment
SPI
Software Process Improvement
SQA
Software Quality Assurance
SQC
Software Quality Control
SQM
Software Quality Management
TQM
Total Quality Management
V&V
Verification and Validation
Introduction

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” [1]. Watts Humphrey refers to it as “achieving excellent levels of “fitness for use” [2]. 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” [4] 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” [5]. 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.

Figure 10.1: Breakdown of Topics for the Software Quality KA
Breakdown of Topics for Software Quality

The breakdown of topics for the Software Quality KA is presented in Figure 10.1.