An introduction to the discipline that asks not can we build it, but should we — and at what cost.
By the end of today you should know what software engineering economics is, why an engineer should care, and how the next sixteen sessions will unfold.
| § | Topic | Minutes |
|---|---|---|
| I. | What is software engineering economics? | 15 |
| II. | Why every engineer needs economic literacy | 15 |
| III. | Boehm's seven-step framework | 20 |
| IV. | The decisions economics informs | 15 |
| V. | A motivating example: Build or Buy? | 15 |
| VI. | Course roadmap, expectations, assessment | 20 |
| Discussion, homework, questions | 10 |
"Every software decision is, in the end, an economic decision."
— after Barry W. Boehm, 1981
Software Engineering Economics applies the methods of economic analysis to decisions about the development, acquisition, evolution, and operation of software systems.
It was systematised in 1981 by Barry W. Boehm in the eponymous textbook — the same volume that gave us the original COCOMO model.
| Resource | What it is | How software people under-count it |
|---|---|---|
| Money | Budget, op-ex, licences, infra. | Spreadsheets hide the long tail of run-time cost. |
| Time | Calendar weeks, engineer hours, compute seconds. | Optimism bias on every estimate ever made. |
| People | Engineers, designers, PMs, support. | Counting heads, ignoring context-switching cost. |
| Compute | CPU, GPU, memory, bandwidth, tokens. | "Free" until the first cloud bill arrives. |
| Attention | Cognitive load on users and on engineers. | Treated as infinite; in fact the binding constraint. |
— Tokens, GPU-time, and inference-latency are 2020s additions to a canon written in 1981.
Software engineering economics is the study of how to make good software decisions when resources are scarce.— working definition for this course
"Engineers are not paid to write code. They are paid to deliver value."
| The technical question | The hidden economic question |
|---|---|
| Should we refactor this module? | Is the future cost saving worth the present rework? |
| Microservices, or monolith? | Which architecture minimises five-year total cost of ownership? |
| Should we adopt this new framework? | Does the productivity gain exceed migration cost? |
| Build it, or buy a SaaS product? | Which alternative has the better Net Present Value? |
| How much testing is enough? | What level of defect risk are we economically willing to accept? |
| Should we adopt an AI coding assistant? | Does the productivity gain cover licence + token + verification cost? |
Polishing one module while the system around it loses money.
Engineering for users that may never arrive — burning capital that revenue can't yet justify.
Saving a small effort now, paying a large cost later. The "five-minute fix" that fossilises.
Continuing a failing initiative because it has consumed so much already.
This course gives you the vocabulary and the discipline to recognise — and resist — each of these in your own work.
A discipline so general that it works for a $10K tooling decision and a $10M platform investment alike.
| # | Activity | Example, in the AI age |
|---|---|---|
| 01 | Establish objectives | "Reduce ticket resolution time by 30% in 12 months." |
| 02 | Identify alternatives | Hire more agents · deploy an AI assistant · outsource. |
| 03 | Define assumptions & constraints | Budget < $500K; PII cannot leave the cluster. |
| 04 | Build cost models | Estimate ticket volume, labour cost, token spend, ramp time. |
| 05 | Evaluate quantitatively | Compute NPV, IRR, payback for each option. |
| 06 | Sensitivity & risk | What if volume grows 50%? if API prices rise 30%? |
| 07 | Iterate & decide | Choose, document, set review checkpoints. |
We will return to this framework in every remaining lecture.
Should we start? How big? How risky? NPV, payback, COCOMO II, Monte Carlo.
Build vs. buy vs. SaaS · monolith vs. microservices. TCO, VBSE.
Testing, review, observability; technical debt now or later. Defect-cost curve.
Retire, rewrite, or leave alone. Maintenance economics, rewrite break-even.
Self-host vs. API · AI coding assistant · pricing AI products. Token economics, productivity ROI.
Lectures 12 & 13 are dedicated to family ⑤.
We will not yet solve this. We will solve it together in Lecture V.
Two equally plausible alternatives, very different cash-flow shapes. Without the time value of money, you cannot tell them apart.
| Alternative | One-time cost | Annual op cost | Useful life |
|---|---|---|---|
| A. Build in-house with Elasticsearch | $ 120,000 | $ 30,000 | 5 years |
| B. Subscribe to a SaaS search vendor | $ 20,000 | $ 80,000 | 5 years |
At an opportunity cost of capital of 10%, which alternative is cheaper in present-value terms?
Which alternative would you recommend — and what single factor is driving your gut?
Heavy upfront, light run-time.
Light upfront, heavy run-time.
We will revisit your gut in Lecture V — with numbers. Try not to flip your vote between now and then.
Each lecture page on the course site carries: objectives · key formulas · worked examples · in-class exercises · homework.
| Component | Weight |
|---|---|
| Participation & in-class quizzes | 15% |
| Homework assignments (~6) | 25% |
| Group project & presentation | 30% |
| Final exam (closed book) | 30% |
| Total | 100% |
| A | 90 + |
| B | 80 – 89 |
| C | 70 – 79 |
| D | 60 – 69 |
| F | below 60 |
Late work: −10% per day, three-day maximum.
/submissions/HW1/<your-name>.pdf. Late submissions: −10%/day.Dr. Zhijiang Chen
Software Engineering Economics · Summer 2026
frostburg-state-university.github.io/bju