25-Comp-B11 Advanced Software Design · Undated paper
Question 3 of 28: Software Metrics, Their Importance, and Their Relationship to Quality
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
Notes on this paper
17-Comp-B11 Advanced Software Design — National Exams, May 2019. 3 hours, closed book exam with two aid sheets allowed (written on both sides), no calculator permitted. The paper is organized into five parts, and candidates were instructed to answer any five (5) questions in Part I, any three (3) in Part II, any four (4) in Part III, any two (2) in Part IV, and any five (5) in Part V — only the first questions answered, in each part, as they appear in the answer book are marked. All questions carry equal weight, so the 19 questions actually marked (5+3+4+2+5 of 28) each count for 100/19 ≈ 5.26% of the paper. All 28 questions are answered below for completeness.
Reference texts: Sommerville, Software Engineering (10th ed., Pearson) — software processes, requirements engineering, design principles, testing, dependability, reuse; Pressman, Software Engineering: A Practitioner's Approach (9th ed.) — supplementary process/metrics/quality coverage; Gamma, Helm, Johnson & Vlissides (GoF), Design Patterns: Elements of Reusable Object-Oriented Software — pattern-language structure, the GoF pattern catalogue, and the "favor object composition over class inheritance" / "program to an interface, not an implementation" principles; Sebesta, Concepts of Programming Languages (12th ed.) — polymorphism, dynamic binding, visibility, encapsulation, interfaces; Bertrand Meyer, Object-Oriented Software Construction — design by contract, preconditions/postconditions/class invariants; Barbara Liskov's 1987 substitutability paper for Question 12; Stroustrup, The C++ Programming Language, for friend/access-control semantics (Question 25).
Question 12 prints “Liskpv substitution principle”, a typo in the paper; it is answered as the Liskov substitution principle.
PART I — General Principles (answer any 5 of 7)
Question 3: Software Metrics, Their Importance, and Their Relationship to Quality (Part I)
A software metric is a quantitative measure of some attribute of a software product, process, or project — for example lines of code, cyclomatic complexity, coupling between objects (CBO), depth of inheritance tree, defect density, or mean time between failures.
Why metrics matter in design. Without a metric, a design attribute such as "complexity" or "coupling" is a subjective, arguable adjective; with one, it becomes a number that can be measured on a candidate design, compared against a threshold or against a competing alternative (Question 5), tracked as the design evolves across iterations, and used to flag modules likely to be defect-prone or hard to maintain BEFORE they cause problems in production.
Relationship to quality. Metrics are the mechanism that OPERATIONALIZES an otherwise abstract quality attribute: cyclomatic complexity approximates testability and understandability, coupling/cohesion metrics approximate modularity and the cost of change, and defect density approximates reliability. A software system "being designed" cannot be objectively judged high-quality without such measures, because quality attributes are themselves qualitative until a metric is attached to each one and a target value is set.