Choosing among five alternatives — and the framework that puts value, not feature parity, at the centre of every choice.
| § | Topic | Minutes |
|---|---|---|
| I. | Five alternatives — build, buy, reuse, OSS, SaaS | 15 |
| II. | Reuse economics — the COCOMO II reuse model | 15 |
| III. | The decision matrix — weighted criteria | 15 |
| IV. | Value-Based Software Engineering (VBSE) | 20 |
| — | Discussion: Build/Buy on a real component | 10 |
| V. | Stakeholder value & the win-condition map | 20 |
| HW11, questions | 15 |
| Option | Definition | Trade-off |
|---|---|---|
| Build (in-house) | Develop and own the code internally. | Max control, max cost. |
| Buy (commercial) | License or buy a packaged product. | Predictable cost, vendor dependence. |
| Reuse | Adapt an existing internal component. | Low cost, integration friction. |
| Open-source (OSS) | Adopt a community-maintained codebase. | Zero licence fee, real maintenance burden. |
| SaaS | Subscribe to a hosted service. | Variable cost, lowest control. |
Most real decisions are blends: buy the core + build customisations + integrate OSS pieces + run on SaaS infrastructure. Pure choices are rare and usually unwise.
When reusing an existing component, COCOMO II computes equivalent KSLOC, weighted by the three integration components:
ASLOC = adapted source lines · AA = assessment / assimilation (0–8) · SU = software understanding (10–50) · DM = design modification % · CM = code modification % · IM = integration modification %.
In practice, reusing a 50K-line library can cost 30–60% of what writing it from scratch would. "Free" reuse is myth; the question is just how much friction.
| Criterion | Weight | Build | Buy | OSS | SaaS |
|---|---|---|---|---|---|
| 5-yr TCO (low = high score) | 25 | 4 | 7 | 9 | 6 |
| Time to value | 20 | 3 | 7 | 8 | 10 |
| Control / flexibility | 15 | 10 | 5 | 8 | 4 |
| Compliance fit | 15 | 10 | 7 | 6 | 5 |
| Vendor-lock risk | 10 | 10 | 5 | 8 | 4 |
| Talent availability | 15 | 5 | 8 | 7 | 9 |
| Weighted total | 5.85 | 6.55 | 7.85 | 6.40 |
Decision matrices are most useful for surfacing weights. Disagreement about weight is usually disagreement about strategy — and that's a productive conversation to have.
Boehm & Sullivan, 2000 — stakeholders before specifications.
A pure feature-parity comparison ignores value. VBSE asks: "value to whom, in which time horizon, at what risk?"
In pairs (4 minutes), fill in a four-row decision matrix (TCO, time-to-value, control, lock-in) for the two options.
| Stakeholder | Win condition | Conflict with… |
|---|---|---|
| End user | Frictionless feature | Security team |
| Engineering | Maintainable code | Marketing's launch date |
| Sales | Demo-able by Q3 | Engineering quality |
| Compliance | Auditable trail | End-user simplicity |
| Finance | Forecastable cost | Variable AI spend |
A decision is "WinWin" when every stakeholder achieves at least the minimum they consider acceptable. If a stakeholder cannot win even minimally, the decision is unstable — it will be relitigated.
Sometimes the right alternative is the one that keeps options open:
Real-option thinking accounts for the value of waiting and learning. The minimum-NPV alternative may not be the best if it forecloses future flexibility.
For 40 years the SEE canon has assumed humans write the code. In the next two lectures, we look at what changes — and what doesn't — when AI writes much of it.
Dr. Zhijiang Chen
Software Engineering Economics · Summer 2026
frostburg-state-university.github.io/bju