What Is a Function Point Calculator?

A function point calculator sizes software from the outside in. Instead of counting lines of code, it counts the functions the system exposes to its users and to other systems — inputs, outputs, inquiries, internal files and interface files — weights each one by its complexity, and adjusts the total for the project characteristics that make delivery harder. The result is a technology-independent number that can be turned into effort, cost, duration and code size.

That independence is the point. Five hundred function points is five hundred function points whether it is built in Java, Python or COBOL, so estimates from a completed project in one stack can be compared with a planned project in another, which is what makes function point analysis the basis of benchmark repositories such as ISBSG.

How It Works

The count starts with the five component types. An external input is a transaction that maintains data or changes system behaviour; an external output is a transaction that presents derived data; an external inquiry is a retrieval that presents data without changing it; an internal logical file is a group of data the system maintains; and an external interface file is data the system references but does not own. Each component is graded low, average or high complexity, which in the IFPUG method depends on the number of data element types and record types it touches.

The complexity grades carry published weights: 3, 4 or 6 points for an external input, 4, 5 or 7 for an output, 3, 4 or 6 for an inquiry, 7, 10 or 15 for an internal logical file and 5, 7 or 10 for an interface file. Multiplying each count by its weight and adding the results gives the unadjusted function point total, which is the pure size of the system.

The adjustment that follows covers the fourteen general system characteristics, from data communications and distributed processing through performance, transaction rate, reusability and multiple installation sites. Each is rated from 0 to 5, the ratings add up to a total degree of influence of 0 to 70, and the value adjustment factor is 0.65 plus one percent of that total, giving a multiplier between 0.65 and 1.35. Multiplying size by the factor yields adjusted function points. Effort then comes from your delivery rate in function points per person-month, cost from a blended rate per person-month, and duration from the two-thirds power law that relates them.

Understanding Your Results

The primary card is the adjusted function point count with the unadjusted total and the value adjustment factor behind it. The three-stat bar adds the raw size, the effort in person-months and the estimated cost.

The breakdown table shows what each component type contributed, the unadjusted total, the influence total and the factor it produced, the adjusted count, the delivery rate, effort, cost, code size in the selected language, the nominal schedule from the cube-root rule, the team size that schedule implies, the cost per function point and which component type dominates the count. The summary panel repeats the headline numbers.

Handling the result well matters more than the arithmetic. Treat the delivery rate as the calibration knob: an eight-function-point-per-person-month team and a fifteen-function-point-per-person-month team produce estimates that differ by a factor of two from identical counts. The rate itself should come from your own completed work rather than from an industry average, since it absorbs staff seniority, tooling, process overhead and the amount of unfamiliar technology in the project. Recount after the design is fixed, and use the difference between the two counts as a measure of how much the requirements were still moving.