"How big is this project?" — the question every estimation method tries, and often fails, to answer.
| § | Topic | Minutes |
|---|---|---|
| I. | Why estimate? Why is it hard? | 10 |
| II. | LOC — uses and abuses | 10 |
| III. | IFPUG Function Points | 30 |
| IV. | Value Adjustment Factor (VAF) | 10 |
| V. | Use-Case Points & modern variants | 10 |
| — | Discussion: estimate a famous product | 10 |
| VI. | Estimation biases — and the group project | 25 |
| HW8, questions | 5 |
Every NPV starts with someone writing a cost number. Without estimation, there is no economics.
Estimation accuracy varies wildly — by factors of 2× to 4× in industry studies. Yet estimating is still better than not estimating.
Use LOC as a downstream output (the COCOMO input), not an upstream estimate. Estimating in LOC before any code is written is guessing.
A language-neutral measure of software size, computed from what the system does rather than how it's implemented. Counted from a specification — usable before any code is written.
Five "function types" are counted, then weighted by complexity:
| Type | What it is | Weight range |
|---|---|---|
| EI — external input | User or system data entering the boundary | 3 / 4 / 6 |
| EO — external output | Data sent out of the system (report, response) | 4 / 5 / 7 |
| EQ — external inquiry | A direct read with no derivation | 3 / 4 / 6 |
| ILF — internal logical file | Data the system maintains internally | 7 / 10 / 15 |
| EIF — external interface file | Data referenced, maintained elsewhere | 5 / 7 / 10 |
| Function | Type | Complexity | Weight | UFP |
|---|---|---|---|---|
| Add book | EI | average | 4 | 4 |
| Search catalogue | EQ | average | 4 | 4 |
| Borrow book | EI | average | 4 | 4 |
| Generate monthly report | EO | high | 7 | 7 |
| Catalogue (book master) | ILF | average | 10 | 10 |
| Member roster | ILF | low | 7 | 7 |
| Borrowing log | ILF | average | 10 | 10 |
| External vendor catalogue feed | EIF | average | 7 | 7 |
| Total UFP | 53 |
14 General System Characteristics, each rated 0 (no influence) through 5 (essential):
data communications · distributed data processing · performance · heavily used configuration · transaction rate · online data entry · end-user efficiency · online update · complex processing · reusability · installation ease · operational ease · multiple sites · facilitate change
For our library module, sum the GSC ratings = 35 → VAF = 0.65 + 0.35 = 1.00 → AFP = 53 × 1.00 = 53 AFP.
Counts actors (weighted by interaction complexity) and use-cases (weighted by number of steps), then adjusts for technical and environmental factors. Designed for projects whose specification lives in UML or modern equivalents.
FP and UCP usually correlate well within a domain. Use whichever fits your team's specification style; pick one and stick to it across the term.
For your group project, choose FP or UCP — not both. Consistency across alternatives matters more than which method you pick.
In pairs (4 minutes), enumerate the function types of WeChat as you understand them. Don't try to be exhaustive — pick 15 representative functions. Compute UFP.
The exact number doesn't matter. The exercise of negotiating it is what calibrates a team's estimating instincts.
You imagine the happy path. Reality is a sum of small disasters. Counter: reference-class forecasting.
The first number set the budget; later analysis only nudges it. Counter: estimate before discussing.
"This time will be different." It rarely is. Counter: add a 25%–50% buffer; refuse the smaller number.
An estimate WITH bias-correction is an honest estimate. Without it, you are agreeing to a number you do not believe.
In teams of 3–4, choose a software product (real or hypothetical). Produce a complete economic analysis containing:
Brief, rubric, and team-formation form on the course site. Teams must be registered by Lecture 11.
Dr. Zhijiang Chen
Software Engineering Economics · Summer 2026
frostburg-state-university.github.io/bju