Issue: March/April 2002 | PDF
Real Quality For Real Engineers
For 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 requirements
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, reusability, 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.
Figure 1. Interactions between product quality external characteristics.
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 stated and implied. Customers’ functional requirements for projects draw from a small number of possible attributes, namely schedule, resources, cost, and quality of the product produced. In some cases, a customer might prioritize cost higher
in others, schedule or product quality.
Additionally, project quality includes nonfunctional requirements such as
- Efficiency: Minimal use of schedule, budget, and staff to deliver a particular software product.
- Flexibility: The extent to which the project can be modified to deliver software other than that for which the project was originally intended or to respond to changes in project goals.
- Improvability: The degree to which project experiences can be fed back into the project to improve project performance.
- Predictability: The degree to which a project’s cost, schedule, and product quality outcomes can be forecast in advance.
- Repeatability: The degree to which the project after the current project can be conducted using practices similar to those used on the current project.
- Robustness: The degree to which the project will continue to function in the presence of stressful environmental conditions.
- Sustainability:The duration for which a project can continue using its current practices.
- Visibility:The ability of a customer to accurately determine project status and progress.
These project characteristics interplay with each other just as the software quality attributes do. Figure 2 shows the interactions. In addition to the interactions shown in Figure 2, some of these project quality characteristics tend to support or undermine the various product characteristics summarized in Figure 1.
Figure 2. Interactions between project quality characteristics.
Different projects have different priorities among efficiency, flexibility, improvability, and the other characteristics shown in Figure 2. An established business might place high values on efficiency, predictability, improvability, and repeatability. A start-up company might place a higher value on robustness and visibility; it might not value sustainability and repeatability at all. This suggests that there isn’t one best definition of project quality for all projects; the best definition depends on the project’s consumers and those consumers’ specific project requirements.
Real Engineering
One difference between a craftsman and an engineer is that a craftsman defines quality on his own terms, whereas an engineer defines quality through his customers’ eyes. The craftsman settles into a way of working that suits him personally, while the engineer adapts his approach on each project to best satisfy his customer’s requirements.
Software engineering purists argue that software should always be produced to the highest level of quality, by which they mean the highest levels of product quality. End-user requirements certainly should be considered, but the organization that builds and sells the software is another consumer whose requirements must be taken into account. The product characteristics that constitute quality to the end user do not necessarily satisfy the software-developing organization’s project quality requirements.
As Deming pointed out in Out of the Crisis, different consumers can have different definitions of quality for the same product, and this applies as much to project quality as it does to product quality. The project team, manager, and sponsoring organization can all be considered consumers of a project. A manager might consider a project to have high quality if it provides good visibility, robustness, and repeatability. The project team might value efficiency, improvability, and sustainability. The sponsoring organization might value predictability and flexibility.
A manager who factors product quality into the project plans but ignores project goals takes an abridged view of software quality. One hallmark of engineering work is the constant balancing of trade-offs. With the extensive trade-off decisions required to balance both software product attributes and software project goals, software personnel have abundant opportunities to hone their engineering skills in this area.
References
- 1. W. Edwards Deming, Out of the Crisis, MIT Press, 2000.
- 2. J.M. Juran, Juran’s Quality Handbook, McGraw-Hill, 1998.
- 3. P.B. Crosby, Quality Is Free: The Art of Making Quality Certain, Mentor Books, 1992.
- 4. S. McConnell, Code Complete, Microsoft Press, 1993.
Editor: Steve McConnell, Construx Software | More articles
