A summary of the authoritative work on software construction
20. The Software-Quality Landscape
20.1 Characteristics of Software Quality
External characteristics of software reviewed: correctness, usability, efficiency, reliability, integrity, adaptability, accuracy, and robustness. There is some overlap between them, but they have different shades of meaning. They are the only kind of software characteristic that users care about.
Internal characteristics of software reviewed: maintainability, flexibility, portability, reusability, readability, testability, and understandability. Similar to external characteristics, they overlap. Indeed there’s even overlap between external and internal characteristics themselves. Some make life easier for the user or programmer (e.g., focusing on correctness hurts robustness). However, the relations between the characteristics change when different projects are taken into account.
20.2 Techniques for Improving Software Quality
Software quality assurance is a planned and systematic program of activities designed to ensure a system has the desired characteristics. You can’t just focus on the product, you have to focus on the development process as well.
To further the quality of your software, you must set software quality objectives and make the quality activity explicit. Without setting objectives, the product and development teams will work to maximize characteristics other than the ones actually wanted. It is imperative that problems are caught at the lowest cost/earliest stage.
The organization must show the developers through explicit quality steps that quality is a priority. Too often quality is perceived as a secondary goal. Quick and dirty programming is the rule rather than the exception.
Foundations of Software Quality
- Testing strategy: can provide a detailed assessment of a product’s reliability. However, it is often relied upon too much to assess and improve quality
- Software engineering guidelines: should control the character of the software as it is developed. This applies to all development activities: problem definition, requirements development, architecture, construction, and system testing.
- Informal technical reviews: include desk-checking design and code, walking through the code with peers, or “code review.”
- Formal technical reviews: are a quality gate. Quality gates should be used to transition between the different stages of the software development lifecycle. The gate doesn’t mean 100% complete or frozen. Just good enough to support the downstream activities. A gate can be an inspection, peer review, customer review, or an audit.
- External audits
Setting Objectives (468)
Programmers can’t respond to a set of objectives that frequently change or are impossible to meet. A study conducted by Gerald Weinberg and Edward Schulman found that developers respond to clear expectations in regards to code quality objectives. However, when the objectives conflict then it’s generally not possible (or impossible) to do well on all of them.