2.1 Software Metrics

What is a software metric?

A software metric is a quantitative measure of an attribute of a software product, process, or project. Lord Kelvin's famous quote applies:

"If you cannot measure it, you cannot improve it."

Software engineering uses metrics to:

1. Estimate effort and cost (planning)
2. Track progress (monitoring)
3. Compare alternatives (decision making)
4. Improve future projects (post-mortems and benchmarking)

---

Classification — Product, Process, Project (IPU-favoured)

Exam tip: "Classify software metrics with examples" is a frequent short-answer question. Memorise the 3-category structure and 2–3 examples for each.

---

Direct vs Indirect metrics

A second classification, orthogonal to product/process/project, distinguishes how a metric is obtained. Direct metrics are measured directly without any inference — Lines of Code is counted by a tool, defects are counted in the bug tracker, effort is counted in person-hours logged. They are unambiguous but rarely tell the whole story. Indirect metrics are derived from direct measurements through a formula — defect density (defects ÷ KLOC), productivity (LOC ÷ person-months), MTBF (total uptime ÷ failure count), maintainability index (a composite of Halstead, McCabe and LOC). Indirect metrics are usually more useful for management decisions because they normalise raw counts — a project with 100 bugs is alarming if it is 5,000 LOC and unremarkable if it is 500,000 LOC; defect density tells you which it is.

---

Why measure? (Five purposes of metrics — DeMarco)

Tom DeMarco's classic taxonomy of metric uses:

1. Sizing — estimate the size of the software (LOC, FP)
2. Costing — estimate effort and money required (COCOMO)
3. Scheduling — break work into time slots
4. Quality — defect density, MTBF
5. Productivity — LOC/person-month, FP/person-month

---

Properties of a useful metric

Not every measurable thing is a useful metric. A good metric should be:

---

Common product metrics — quick reference

Size

• LOC (Lines of Code) — physical or logical lines
• KLOC — Kilo-LOC = 1,000 lines
• Function Points (FP) — Albrecht's measure
• Halstead's measures — vocabulary, length, volume, difficulty

Complexity

• Cyclomatic Complexity (McCabe) — number of independent paths through code; V(G) = E − N + 2
• Cognitive complexity — modern variant for human readability
• Nesting depth — max levels of nested control statements

Quality

• Defect density — defects per KLOC
• Defect removal efficiency (DRE) — % of bugs found before release
• MTBF (Mean Time Between Failures) — hours between failures
• MTTR (Mean Time To Repair) — hours to fix and redeploy

Maintainability

• Maintainability Index (MI) — composite metric (Halstead Volume + Cyclomatic + LOC + comment ratio)
• Comment density — fraction of lines that are comments

---

Common process & project metrics

---

Key Terms — Lesson 2.1

The vocabulary below is what appears in every Unit II PYQ on metrics, and is the basis for the size, cost, and risk lessons that follow.

Software Metric — A quantitative measure of an attribute of a software product, process, or project. Metrics are the basis of measurement-driven engineering — without them, claims about quality, productivity, or improvement are unfalsifiable.

Product Metric — A metric that measures the software artefact itself — its size (LOC, FP), its complexity (cyclomatic complexity, Halstead volume), its quality (defect density), its maintainability (MI, comment density). Product metrics are collected during and after development by inspecting the code or running tools on it.

Process Metric — A metric that measures the development process across multiple projects — defect-removal efficiency, requirements stability, time-to-fix, test coverage, code-review effectiveness. Process metrics drive organisational learning — they tell you whether the way you build software is improving.

Project Metric — A metric that measures a specific in-flight project — schedule slippage, cost variance, effort spent, current defect count, percentage of features delivered. Project metrics drive operational management decisions — when to add resources, when to cut scope, when to raise an alarm.

Direct Metric — A metric measured directly from the artefact without any derivation — LOC (counted by a tool), defects (counted in the bug tracker), effort (counted in time logs). Direct metrics are simple but rarely interpretable on their own.

Indirect (Derived) Metric — A metric computed from one or more direct metrics — defect density (defects per KLOC), productivity (LOC per person-month), MTBF, maintainability index. Indirect metrics normalise raw counts and are the preferred tool for management decisions.

LOC (Lines of Code) / KLOC — The simplest size metric: the count of source-code lines. Physical LOC counts every line including blanks and comments; logical LOC counts only executable statements. KLOC is "kilo-lines of code" (1,000 LOC). LOC is widely criticised but universally used because it is cheap to collect.

Function Point (FP) — A language-independent size metric introduced by Allan Albrecht (IBM, 1979) that counts the business functionality delivered — external inputs, external outputs, external inquiries, internal logical files, external interface files — weighted by complexity. FP is the standard alternative to LOC and is the basis of intermediate COCOMO II's "FP-based mode."

Halstead's Software Science Metrics — A 1977 family of metrics by Maurice Halstead computed from the operators and operands in the code: vocabulary (n = n₁ + n₂), length (N = N₁ + N₂), volume (V = N · log₂ n), difficulty, effort, and estimated bugs. Halstead's metrics tie code size to predicted effort and defect counts.

Cyclomatic Complexity (V(G)) — Thomas McCabe's 1976 metric for the number of linearly independent paths through a piece of code's control-flow graph: V(G) = E − N + 2 (or equivalently P + 1, where P is the number of predicate decisions). High V(G) (>10) signals code that is hard to test and is a candidate for refactoring.

Cognitive Complexity — A 2018 SonarSource metric that, unlike McCabe's V(G), penalises deeply nested constructs more heavily because they are harder for humans to read. Cognitive complexity is the modern complement to cyclomatic complexity for code-review and refactoring decisions.

Defect Density — The number of defects discovered per KLOC (or per function point), measured over a period — typically the first year after release. Industry benchmarks: ~10 defects/KLOC for ordinary commercial software, ~1 for safety-critical, ~0.05 for NASA Shuttle flight software.

Defect Removal Efficiency (DRE) — The percentage of defects found and removed before release — DRE = defects-found-before-release / (defects-found-before-release + defects-found-after-release). DRE above 95% is the IBM-era target; world-class teams reach 99%+.

MTBF (Mean Time Between Failures) — The average operating time between two consecutive failures. MTBF is a reliability metric; higher is better. Used heavily for production-system SLAs ("99.9% uptime" ≈ 8.7 hours of downtime per year ≈ MTBF dependent on incident rate).

MTTR (Mean Time To Repair / Recover) — The average time taken to diagnose and fix a failure and restore service. MTTR is a maintainability metric; lower is better. Modern DevOps culture often substitutes "Mean Time To Recovery" — the time from incident to restored service, regardless of whether the root cause is fixed.

Maintainability Index (MI) — A composite metric introduced by Coleman (1994): MI = 171 − 5.2·ln(V) − 0.23·CC − 16.2·ln(LOC) [+ 50·sin(√(2.4·CM))], where V is Halstead volume, CC is cyclomatic complexity, LOC is lines of code, and CM is comment ratio. Higher is better; values are typically 0–100 with anything below ~65 considered worrying.

Productivity — Output per unit of effort — typically LOC per person-month or FP per person-month. Productivity is the headline metric for software economics and the input to almost all cost-estimation models (including COCOMO).

Schedule Variance / Cost Variance — Earned-value management metrics. Schedule Variance = (Earned Value − Planned Value) — negative means behind schedule. Cost Variance = (Earned Value − Actual Cost) — negative means over budget. Both are project metrics, tracked through the build phase.

Code Churn — The number of LOC added, modified, or deleted in a code base over a defined period (sprint, week, release). High churn signals codebase instability — common in early-stage products, alarming in mature ones. Microsoft Research famously correlated high churn with high defect rates.

Goodhart's Law — "When a measure becomes a target, it ceases to be a good measure." If management rewards LOC, developers write verbose code; if it rewards bug counts, testers under-report. The law is the fundamental warning for anyone using software metrics — measure to understand, not to incentivise.

Hawthorne Effect — The tendency of people to behave differently when they know they are being observed. Applies as much to software measurement as to factory work: even neutrally collecting metrics can change developer behaviour, sometimes for better, sometimes worse.

Benchmarking — Comparing a project's or team's metrics against published industry references — ISO/IEC 25023 quality benchmarks, ISBSG (International Software Benchmarking Standards Group) productivity data, NASSCOM-published Indian-industry benchmarks. Benchmarking provides external grounding for what counts as "good."

---

Study deep: metric pitfalls

1. "Goodhart's Law": When a measure becomes a target, it ceases to be a good measure. If management rewards LOC, developers write verbose code. If they reward bug counts, testers don't report borderline issues. Metrics must drive understanding, not behaviour gaming.

1. LOC is famously misleading. A 100-line elegant solution may be better than a 1000-line clunky one. Yet LOC remains the most-used metric because it is easy to count automatically.

1. The 'Hawthorne effect' applies to software too. Programmers behave differently when they know they are measured. Even which metrics you collect can bias behaviour.

1. Composite metrics hide trade-offs. The Maintainability Index combines four metrics into one number. A low MI does not tell you which of the four components is the problem.

1. Industry benchmarks help. Standardised metrics (FP, ISO/IEC 25023) enable comparison across companies and industries. The Indian context: NASSCOM and ISACA-India publish industry benchmarks for productivity and defect density.

PYQ pattern: "What are software metrics? Classify them with examples." — Define metric, list 3 categories (product/process/project) with 2–3 examples each. End with a sentence on direct vs indirect.