Support for Quality-Based Design and Inspection

• Authors: Ilkka Tervonen
• Venue: IEEE Software
• Year: 1996

Debate using relevant, domain-specific quality terms is a mark of mature theory and expertise in a particular area. Wine connoisseurs and movie critics use domain-specific quality terms that even novices are at least partly familiar with. What about software? Is software engineering mature enough so that software designers can use quality terms in discussions with their peers? Do inspectors of software artifacts evaluate them in terms of quality? Is the final software product advertised in such terms? Do customers understand the quality-based advantages of competing products?Most software engineers agree that there is too much variety in quality terms. Quality models such as Software Quality Metrics and Goal Question Metric and standards such as the IEEE Quality Metrics Methodology and ISO 9126 provide a quality terminology, but they tend to be too rigid or abstract, and of course they cannot guarantee that their terminology will be learned and used.This prevents software engineers from understanding the role of quality in practice: how to state quality goals, how to justify alternative solutions in quality terms, and how to evaluate the achievement of quality in alternative solutions. How do we solve this problem? In theory, the solution is easy. We need an appropriate quality model, a software-development method that uses this quality model, a supporting tool, and adequate training in the use of the method and tool. In practice, we all know how difficult this is.I propose to use a consistent quality structure for designing and inspecting software artifacts. This structure is based on a quality model that I call SQM synthesis because of my numerous modifications to the original Software Quality Metrics model.