Topics in this domain
- Project Roles and Governance
- PMBOK Phases
- Gantt, PERT, Critical Path
- Function Point Analysis
- Earned Value and Project Risk
- Business Case and Feasibility
- Benefits Realization
- SDLC Phases Overview
- Requirements Definition
- System Design
- Waterfall vs. Iterative vs. Prototyping
- Agile
- DevOps and DevSecOps
- RAD, CASE, Low-Code
- Build, Coding Standards, Code Review
- Testing Levels: Unit, Integration, System, UAT
- Regression, Sociability, Parallel, Pilot Testing
- Defect Management
- Data Migration and Conversion
- Change-Over: Parallel, Phased, Abrupt
- Go-Live Readiness and Acceptance
- Post-Implementation Review
- Input Controls
- Processing Controls
- Output Controls
- Data Integrity and ACID
- EDI and E-Commerce Controls
Function Point Analysis
How big is this system?
Before you can estimate the cost and time of building software, you need to know how big the job is.
A builder estimates a house by its floor area, not by counting bricks after it’s built. Function points are the “floor area” of software: a measure of how much the system does for its users, which you can count from the requirements before any code exists.
There are two common ways to measure software size:
- Lines of code (SLOC): easy to count once the code exists, but depends on the programming language and isn’t known until late in the project.
- Function points: count the functionality delivered to users. Available from the requirements, and the same whatever language is used.
The five things you count
| Component | Meaning | Examples |
|---|---|---|
| External inputs | Data or instructions coming into the system | Order entry screen, incoming file |
| External outputs | Information going out after processing | Invoices, management reports |
| External inquiries | Simple input-and-response look-ups | “Find customer by name” |
| Internal logical files | Data the system maintains | Customer master, order tables |
| External interface files | Data the system uses but another system maintains | A product catalogue from another system |
From count to estimate
- Count the five components.
- Weight each as low, average or high complexity.
- Adjust the total for general system characteristics, such as demanding performance, distributed processing or complex calculations.
- Convert function points into effort and cost using the organisation’s historical productivity, such as hours per function point.
Example. Early in a project, the requirements show 20 inputs, 15 outputs, 10 inquiries, 8 internal files and 3 interfaces. Weighted and adjusted, that’s about 400 function points. Past projects took about 8 hours per function point, so effort is estimated at around 3,200 hours, to be refined once the design is done.
Strengths and limits
Strengths: available early; doesn’t depend on the language; good for comparing productivity across projects.
Limits: counting takes training and judgement; it suits business applications better than real-time or maths-heavy software; and the conversion to effort is only as good as the historical data.
Other estimation approaches include expert judgement, comparison with similar past projects, and models such as COCOMO (which uses lines of code).
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Estimation technique based on user functionality | Function point analysis |
| Main advantage of FPA over lines of code | Can be done early; independent of programming language |
| What FPA counts | Inputs, outputs, inquiries, internal files, external interface files |
| Why lines of code is poor for early estimates | The code doesn’t exist yet and size depends on the language |
In short
- Function point analysis (FPA) measures software size by the functionality delivered to users, regardless of programming language.
- It counts five things: external inputs, external outputs, external inquiries, internal logical files and external interface files.
- Each is weighted by complexity, and the total can be adjusted for general system characteristics.
- Function points can be counted from requirements, so FPA supports early estimates.
- Lines of code (SLOC) depends on the language and is only known late, so it's poor for early estimates.
- Size becomes effort and cost using historical productivity data.
Exam traps
- FPA measures size from the user's perspective, not the code's.
- You can't count lines of code before the code is written.
- Function points measure size; turning size into effort needs historical data.
Slides
Click the slide and use the arrow keys. F toggles full screen.
The five things you count