Function Point analysis (ファンクションポイント法) estimates development size by turning the number and complexity of a system's functions into points.
Count functions
Weight by complexity
Sum to get the FP count
Convert to effort using productivity
Divide the FP count by the size one person can handle in a month (productivity) to get the person-months needed (effort).
4 / 4
You count the functions users can see, such as inputs, outputs, files and inquiries, weight each by its complexity, and add them up; the resulting score is the FP count, which serves as the development size. Because it counts functions rather than how they are built, the result depends little on the programming language, and the count can be made as soon as a list of functions exists. The effort needed (the amount of work, in units such as person-months) is found by dividing this size by the productivity taken from past results (the size one person can handle per month).
AnalogyIt is like judging how much work a dinner will take not by the size of the pot, but by how many dishes you will make and how hard each one is.
How to remember"Function" here means a feature, not a function in program code: you count the chunks of functionality users can see.
Exam points
ExamFunction Point analysis (ファンクションポイント法) derives size from the number and difficulty of functions such as inputs, outputs and files. It is a different thing from counting lines of source code.
ExamWhat Function Point analysis estimates first is development size. Development time and effort (工数) are results derived from that size, not inputs for estimating it.
Mix-upThe bottom-up method (積み上げ法) breaks the work into small tasks, estimates the effort for each and adds them up. It differs from Function Point analysis in that it counts tasks, not functions.
Analogy-based estimation (類推見積法) estimates size and effort from the actual results of past projects that resemble the development about to begin.
The actual size, effort and cost of a similar project serve as the yardstick, and the figures are inferred after adjusting for how this project differs. It gives a rough estimate quickly, even before the details are settled. On the other hand, for a new kind of development with no similar precedent, the basis for the estimate itself becomes weak.
AnalogyIt is like looking at what a similar trip cost you last year to get a rough idea of this year's travel budget.
How to rememberIn the Japanese name, 類 means "similar" and 推 means "infer": the method infers from similar precedents.
Exam points
ExamAnalogy-based estimation (類推見積法) takes little time or money to carry out. The trade-off is that it is less accurate than methods that build up from detailed tasks.
ExamAnalogy-based estimation suits the planning stage, before details are settled, when a rough cost figure is needed in a short time.
ExamThe accuracy of an estimate (見積り) rises as development moves forward and more information is fixed. The rough estimate at the start of planning is the least precise.
Relative estimation (相対見積) does not estimate work directly in time; instead it sizes a task by how many times as large it is as a chosen reference task.
Task
Compared with the reference task
Value given
Task P
Used as the reference
2
Task Q
About twice the reference
4
Task R
About half the reference
1
You pick one reference task, then compare each other task with it, as a multiple or a fraction, and give it a value. In agile development this ratio is usually expressed in story points, a unit kept separate from time. It rests on the idea that people judge more easily by comparing two things than by naming an amount outright.
AnalogyIt is like skipping the scale and holding one bag in each hand to decide that this one is about twice as heavy.
How to rememberThe opposite of relative is absolute, the same pair as grading on a curve versus grading against a fixed standard.
Exam points
Mix-upThe values given in relative estimation (相対見積) are ratios to a reference task, not absolute amounts that can be read straight off as hours or person-months.
Analogy-based estimation vs. Relative estimation
Aspect
Analogy-based estimation
Relative estimation
Key differenceWhat it compares against
Other projects from the past
A reference task within the same development
Main use
Roughly estimating the overall cost early in planning
Sizing tasks in agile development by comparing them with each other
Key points
Function Point analysis turns the amount of functionality into points, so differences in programming language affect it little.
Analogy-based estimation suits rough early-planning estimates, but its basis is weak for development with no similar precedent.
Estimates become more accurate as development progresses and more information becomes available.
Effort is found by dividing size by productivity.
Relative estimation expresses a task's size as a ratio to a reference task rather than in time.