Classic Software Quality Metrics

Software quality is a multidimensional concept. The multiple professional views of product quality may be very different from popular or nonspecialist views. Moreover, they have levels of abstraction beyond even the viewpoints of the developer or user. Crosby, among many others, has defined software quality as conformance to specification.^[2] However, very few end users will agree that a program that perfectly implements a flawed specification is a quality product. Of course, when we talk about software architecture, we are talking about a design stage well upstream from the program's specification. Years ago Juran^[3] proposed a generic definition of quality. He said products must possess multiple elements of fitness for use. Two of his parameters of interest for software products were quality of design and quality of conformance. These separate design from implementation and may even accommodate the differing viewpoints of developer and user in each area.

Two leading firms that have placed a great deal of importance on software quality are IBM and Hewlett-Packard. IBM measures user satisfaction in eight dimensions for quality as well as overall user satisfaction: capability or functionality, usability, performance, reliability, installability, maintainability, documentation, and availability (see Table 3.1). Some of these factors conflict with each other, and some support each other. For example, usability and performance may conflict, as may reliability and capability or performance and capability. IBM has user evaluations down to a science. We recently participated in an IBM Middleware product study of only the usability dimension. It was five pages of questions plus a two-hour interview with a specialist consultant. Similarly, Hewlett-Packard uses five Juran quality parameters: functionality, usability, reliability, performance, and serviceability. Other computer and software vendor firms may use more or fewer quality parameters and may even weight them differently for different kinds of software or for the same software in different vertical markets. Some firms focus on process quality rather than product quality. Although it is true that a flawed process is unlikely to produce a quality product, our focus here is entirely on software product quality, from architectural conception to end use.