Question 8 of 9: Software Quality

Question 8: Software Quality (a) 4, (b) 6, (c) 10 — 20 marks

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

(a) Software Quality Management

Software quality management is the set of organizational activities that ensure a software product meets both its explicit specifications and reasonable implicit standards of professional practice (well-structured, maintainable, adequately documented) — independently of whether the product's functional behaviour is correct. It sits alongside, but is distinct from, project management: it is concerned with the quality of the process and the product, not with delivering it on time or on budget.

(b) The Three Main Activities of Software Quality Management

Quality assurance establishes the organizational procedures and standards that should lead to high-quality software (coding standards, review procedures, process definitions). Quality planning selects, from the general organizational standards, the specific quality procedures and standards applicable to a particular project, and defines the target quality attributes and how they will be assessed. Quality control ensures that the project actually follows its quality procedures and standards as work proceeds — through activities such as reviews and audits — and feeds discrepancies back for correction.

(c) Why Internal-to-External Attribute Relationships Are Hard to Validate

Internal attributes (program size, cyclomatic complexity, number of procedure parameters, nesting depth) can be measured directly and objectively from the code itself, with no ambiguity about their value. External attributes (maintainability, reliability, usability) are properties of how the software behaves in use, over time, in the hands of real maintainers or users — they can only be assessed indirectly, and only after the system has been in service long enough for the property to manifest (maintainability, in particular, can typically only be judged retrospectively, by observing how much effort successive changes actually took).

Establishing a valid relationship between the two therefore runs into several compounding difficulties. First, external attributes depend on many confounding factors that have nothing to do with the internal metric being studied — maintainability, for instance, is heavily influenced by documentation quality, the skill and familiarity of the specific maintainer, tool support, and organizational process, so any correlation between "program size" and "maintainability" measured across different systems is contaminated by all of these other variables and it is difficult to isolate the internal metric's true, independent contribution. Second, external attributes are often not directly measurable at all, only assessed by proxy (e.g. maintainability proxied by "hours logged against change requests," which itself is affected by how change requests happen to be recorded); a study is then really validating a relationship between an internal metric and a proxy, and the proxy's own validity as a stand-in for the real external attribute is a further, usually untested, assumption. Third, the relationship, even where real, may not be simple or monotonic — a larger program is not always less maintainable if the extra size is well-modularized, so a study that only looks for a simple linear correlation between raw size and maintainability can fail to detect a real but more complex relationship, or can detect a spurious one driven by a third factor that happens to correlate with both.