Software Sizing: LOC and Function Point Estimation with Worked Examples

LOC and function points both produce a software size, but they count different things. You cannot substitute one for the other without a stated conversion baseline. This guide completes one estimate from module-level LOC ranges and another from function counts, then shows the correct route from size to effort. Keep the central distinction clear: size, effort and calendar duration are three different quantities.

Software size is an input to estimation, not the schedule itself

Software size quantifies product scope. Effort is work in person-hours or person-months. Duration is elapsed calendar time.

The conversion is size / organisation-specific productivity = effort. Staffing, dependencies and task order then affect duration. Thus, 4,400 LOC is a size, not 4,400 hours; 168 FP is a size, not 168 days.

LOC estimates implementation volume within a stated language and counting convention. Function points count user-visible inputs, outputs, enquiries and logical data groups before code exists. After sizing, Software Estimation and Scheduling: COCOMO, CPM, PERT continues into effort models and network scheduling.

LOC estimation works when the counting rule and module scope are explicit

Here, one LOC means one delivered logical source statement. Blank lines, comments, generated files and third-party library code are excluded. Physical-line counting can differ, so the rule must be explicit.

For four service modules, optimistic O, most likely M and pessimistic P values feed the deliberately chosen formula E = (O + 4M + P) / 6.

The computations are UI (800 + 4(1,200) + 2,000) / 6 = 7,600 / 6 = 1,266.67; API (1,200 + 4(1,700) + 2,500) / 6 = 10,500 / 6 = 1,750; reports (500 + 4(800) + 1,400) / 6 = 5,100 / 6 = 850; and migration (300 + 4(500) + 900) / 6 = 3,200 / 6 = 533.33.

Using unrounded values gives (7,600 + 10,500 + 5,100 + 3,200) / 6 = 26,400 / 6 = 4,400 logical LOC. The displayed values reconcile too: 1,266.67 + 1,750 + 850 + 533.33 = 4,400.

This estimate becomes fragile if the team silently changes the language, reuse assumption, generated-code treatment or statement-counting rule.

Function points count transactions and data functions

Function-point analysis uses five classic types:

• External input (EI): changes internal data or control information.

• External output (EO): sends derived information outside the boundary.

• External enquiry (EQ): retrieves information without significant derived processing.

• Internal logical file (ILF): a user-recognisable logical data group maintained inside the application boundary.

• External interface file (EIF): a user-recognisable logical data group referenced here but maintained by another application.

This classic exam-style weighting table is the worked problem's basis, not a new KnowledgeGate or official-exam rule.

Count against the application boundary and user-recognisable functions. A database table is not automatically an ILF, and a screen is not automatically one EI.

Function Point worked example: from UFP to adjusted FP

Consider a fictional library application. Multiply each function count by its stated complexity weight:

Therefore, UFP = 40 + 40 + 15 + 50 + 15 = 160.

If the prompt supplies the classic value-adjustment method and TDI = 40:

1. VAF = 0.65 + 0.01(TDI)

2. VAF = 0.65 + 0.01(40) = 0.65 + 0.40 = 1.05

3. Adjusted FP = UFP x VAF = 160 x 1.05 = 168 FP

The stopping point matters. If the question asks only for UFP, stop at 160. Continue to 168 FP only when the adjustment formula and TDI are supplied. Do not apply VAF simply because you remember the formula.

A further conversion needs a local assumption. If historical data says 50 logical LOC per FP, then 168 x 50 = 8,400 logical LOC. The value 50 is hypothetical organisational history, not a universal language factor or part of the FP count.

Convert LOC or FP into effort with a matching productivity baseline

For the separate four-module example, supplied historical productivity of 400 logical LOC per person-month gives 4,400 / 400 = 11 person-months. Eleven people do not necessarily finish in one month because task ordering, communication and staffing constrain duration.

For the separate library example, suppose historical productivity is 12 adjusted FP per person-month. Its effort is 168 / 12 = 14 person-months.

Unit discipline prevents nonsense. Divide LOC by LOC productivity and FP by FP productivity. Never divide 4,400 LOC by 12 FP/person-month, never average 11 and 14, and never treat either productivity rate as universal. These examples describe different fictional scopes and baselines.

LOC versus Function Points: choose by lifecycle stage and evidence

LOC is easy to validate against existing code, but can reward verbosity and mishandle reused or generated code. Function points support cross-language comparison, but require trained, consistent counting.

Use the measure named by the question. In practice, prefer the one backed by organisational productivity data. CS Fundamentals for Exams & Placements broadens the route into software engineering and core CS.

Exam-style software-sizing questions fail on units, weights and stopping points

Questions may ask for an expected LOC row, a module total, an EI or ILF classification, UFP, adjusted FP, a supplied FP-to-LOC conversion, or effort from matching productivity.

1. 8 average EIs contribute 8 x 4 = 32 UFP.

2. If UFP = 125 and TDI = 27, then VAF = 0.65 + 0.27 = 0.92, and adjusted size is 125 x 0.92 = 115 FP.

3. At 10 FP/person-month, 115 FP implies 115 / 10 = 11.5 person-months, not 11.5 months.

KnowledgeGate carries about 30 published questions around Software Sizing, Function Points and LOC estimation. Check relevance for your attempt with Software Engineering for GATE: Syllabus and Priority, then use GATE Guidance by Sanchit Sir for the wider GATE CS route.

Software sizing with LOC and Function Points: the short version

Before accepting any answer:

1. Fix the application boundary.

2. Choose LOC or function points.

3. Apply only the stated counting convention and weights.

4. Stop at the quantity requested.

5. Convert size to effort only with a matching historical productivity rate.

The module example totals 4,400 logical LOC. The library example produces 160 UFP, or 168 adjusted FP at TDI = 40. The Software-Engineering course is the focused next step for structured study.