Software Design and Software Quality

This chapter covers software design principles (abstraction, architecture, modularity, cohesion/coupling, the four design activities) and software quality (McCall's factors, ISO 9126, quality control versus assurance, risk management, reliability), plus estimation and scheduling (COCOMO, LOC/FP-based sizing).

Abstraction, Modularity, Cohesion and Coupling

Modularity decomposes a system into separate, independently-developable modules; information hiding restricts a module's internal design decisions from being visible to (or depended on by) other modules, exposing only a well-defined interface. Cohesion measures how strongly related the responsibilities WITHIN one module are (HIGH cohesion — a module doing one well-defined thing — is the goal); coupling measures how strongly one module DEPENDS ON another (LOW coupling — modules that can be understood, changed and tested largely in isolation — is the goal). The two are related but distinct: a well-designed system aims for high cohesion and low coupling TOGETHER, and it is possible (and bad) to have high cohesion within modules that are nonetheless tightly coupled to each other, or low coupling between modules that are individually incoherent messes.

  • The four design activities named in this sub-item — object-oriented, data, architectural and user-interface design — each address a different concern: OO design settles classes/objects and their relationships, DATA design settles how information is structured and stored, ARCHITECTURAL design settles the overall structure and major components/their relationships, and USER-INTERFACE design settles how a human actually interacts with the system.

Software Quality Factors: McCall and ISO 9126

Two named quality-factor frameworks
FrameworkStructure
McCall's quality factorsGroups factors under three perspectives — PRODUCT OPERATION (correctness, reliability, efficiency, integrity, usability), PRODUCT REVISION (maintainability, flexibility, testability) and PRODUCT TRANSITION (portability, reusability, interoperability) — an older but historically foundational classification.
ISO 9126An international standard naming six top-level characteristics — functionality, reliability, usability, efficiency, maintainability, portability — each broken into sub-characteristics, providing a standardised (rather than one vendor's own) vocabulary for software quality.
⚠️ Quality control and quality assurance are not the same activity
QUALITY ASSURANCE (QA) is PROCESS-focused: a set of planned, systematic activities intended to ensure the process itself is followed correctly and is capable of producing quality software — it is largely preventive. QUALITY CONTROL (QC) is PRODUCT-focused: activities (reviews, testing) that check whether a specific work product meets its quality requirements — it is largely detective, finding defects that have already been introduced. RISK MANAGEMENT identifies, analyses and prioritises risks; RISK MITIGATION, MONITORING AND MANAGEMENT (RMMM) plans go further, specifying concrete steps to reduce a risk's probability/impact (mitigation), tracking indicators that a risk is materialising (monitoring) and executing contingency plans if it does (management).

Software Reliability

Software reliability is the probability of failure-free operation for a specified period under specified conditions — measured by metrics such as MTBF (mean time between failures) and failure rate/intensity, and modelled by growth models that predict how reliability improves as testing continues to find and remove defects.

Software Sizing, Estimation and COCOMO

Software sizing estimates the amount of work up front: LOC-based estimation counts (or predicts) lines of code, simple but sensitive to language and coding style; FUNCTION-POINT (FP) based estimation instead counts user-visible functional elements (inputs, outputs, inquiries, internal/external files) weighted by complexity, giving a size measure that is language-independent and available earlier in the process (function points can be counted from requirements, before a line of code is written).

ℹ️ COCOMO's three modes scale with project size and complexity
The Constructive Cost Model estimates effort (person-months) as a·(KLOC)^b, calibrated by mode: ORGANIC (small, familiar teams on well-understood problems — the lowest exponent), SEMI-DETACHED (intermediate size/familiarity) and EMBEDDED (large, complex, tightly-constrained projects with tight hardware/interface constraints — the highest exponent, since effort grows FASTER than linearly with size for the hardest projects). Effort then feeds a separate formula for development TIME, and the two together drive staffing/scheduling — a time-line chart (a Gantt-style chart) is the standard way to lay out the resulting schedule.

Key takeaways

  • High cohesion within modules and low coupling between them are the joint goal — one without the other is still a bad design.
  • McCall's factors group under operation/revision/transition; ISO 9126 names six international-standard characteristics.
  • Quality assurance is process-focused and preventive; quality control is product-focused and detective — different activities, not synonyms.
  • Function points are language-independent and countable from requirements alone, unlike LOC-based sizing.
  • COCOMO's organic/semi-detached/embedded modes scale effort with project size and constraint tightness, with embedded projects' effort growing fastest with size.

Practice questions (8)

Attempt each one before opening the answer. Every explanation names the tempting wrong option as well as the right one, because that is where marks are lost.

  1. A well-designed module is one that has:

    1. High cohesion within it and low coupling to other modules
    2. Low cohesion within it and high coupling to other modules
    3. No relationship to any other module whatsoever
    4. The maximum possible number of responsibilities in one place
    Show answer

    Answer: A — High cohesion within it and low coupling to other modules

    High internal cohesion (a module doing one well-defined thing) and low external coupling (minimal dependence on other modules) are pursued together as the joint goal of good modular design.
  2. In McCall's quality factors, maintainability, flexibility and testability are grouped under:

    1. Product revision
    2. Product operation
    3. Product transition
    4. None of these categories
    Show answer

    Answer: A — Product revision

    Product revision groups the factors relevant to changing the software after delivery — maintainability, flexibility and testability — as distinct from product operation (using it as-is) and product transition (moving it to a new environment).
  3. Quality assurance, as distinct from quality control, is best described as:

    1. Process-focused and largely preventive
    2. Product-focused and largely detective, checking a specific work product
    3. Identical in every respect to quality control
    4. Concerned only with hardware, never software
    Show answer

    Answer: A — Process-focused and largely preventive

    Quality assurance targets the PROCESS to prevent defects before they occur; the product-focused, detective checking of a specific deliverable (reviews, testing) is quality control's job instead.
  4. Function-point (FP) based sizing, compared to LOC-based sizing, has the advantage that it:

    1. Is language-independent and can be counted from requirements before any code is written
    2. Can only be measured after the entire project is complete
    3. Depends heavily on the programming language chosen
    4. Counts only the number of comments in the code
    Show answer

    Answer: A — Is language-independent and can be counted from requirements before any code is written

    Function points count user-visible functional elements weighted by complexity, which can be identified from the requirements/specification alone — unlike LOC, which cannot be known until code exists and which varies with language/style for the same functionality.
  5. In COCOMO, an EMBEDDED-mode project (large, complex, tightly constrained) has an effort exponent that, compared to an ORGANIC-mode project:

    1. Is higher, so effort grows faster than linearly with size
    2. Is always exactly zero
    3. Is identical for every mode
    4. Is negative, meaning effort decreases with size
    Show answer

    Answer: A — Is higher, so effort grows faster than linearly with size

    The embedded mode's higher exponent in effort = a·(KLOC)^b reflects that the hardest, most tightly-constrained projects see effort grow disproportionately faster as size increases, compared to a simple organic project.
  6. Which of the following are among the four design activities named for this sub-item? (More than one option may be correct.)

    1. Architectural design
    2. User-interface design
    3. Data design
    4. Marketing design
    Show answer

    Answer: A — Architectural design; B — User-interface design; C — Data design

    Object-oriented, data, architectural and user-interface design are the four named activities; marketing is not a software design activity at all.
  7. Name the reliability metric defined as the average time elapsed between one failure and the next.

    Numerical answer — type the value.

    Show answer

    Answer: MTBF

    MTBF (Mean Time Between Failures) is a standard reliability metric alongside failure rate/intensity, and reliability-growth models predict how it improves as testing removes defects.
  8. Information hiding, as a design principle, chiefly means:

    1. A module's internal design decisions are not visible to or depended on by other modules
    2. Every module must expose all of its internal variables
    3. Modules cannot have any interface at all
    4. It is unrelated to modularity
    Show answer

    Answer: A — A module's internal design decisions are not visible to or depended on by other modules

    Information hiding exposes only a well-defined interface while keeping internal decisions private, which is exactly what allows a module's internals to change later without breaking modules that depend only on its interface.