Real quality for real engineers

F or decades, experts have struggled to define quality. Edwards Deming said that the only definition of quality that mattered was the consumer's. 1 Joseph Juran said that quality was fitness for use. 2 Philip Crosby provided the strictest definition of quality as " conformance to requirements. " 3 Conformance to requirements Although they differ on the details , quality experts agree that the customer's view of requirements is critically important. For that reason, I've found Crosby's definition of " conformance to requirements " to be the most useful definition in examining software quality. Taking into account many software projects' tendency to elicit some but not all of the customer's complete requirements, " requirements " cannot be interpreted solely as the written requirements. Requirements must also include implicit re-quirements—those that the customer assumes regardless of whether the development team happens to write them down. Thus, the working definition of quality that I use is " conformance to requirements, both stated and implied. " The " ities " of software quality In addition to specific functional requirements , software quality is also affected by common nonfunctional characteristics that are often referred to as the " ities. " The ities that affect software's internal quality (quality visible to the software's developers) include maintainability, flexibility, portability, re-usability, readability, scalability, testability, and understandability. The ities that affect the software's external quality (visible to the customer) include usability, reliability, adaptability , and integrity, as well as correctness, accuracy, efficiency, and robustness. 4 Some of these characteristics overlap, but all have different shades of meaning that are desired more in some cases and less in others. The attempt to maximize certain characteristics invariably conflicts with the attempt to maximize others. Figure 1 presents a summary of the ways in which external quality characteristics affect each other. These characteristics will be prioritized differently on different projects, which means the software quality target is always changing. Finding an optimal solution from a set of competing, changing objectives is challenging , but that's part of what makes software development a true engineering discipline. From product quality to project quality When software people refer to quality, we usually refer to the quality of the software product we are producing. From a management perspective, however, customers also have requirements for projects. I think it's reasonable to draw an analogy from products to projects, conceiving project quality as conformance to requirements, both …