Session 2

This session turns the scope statement of Session 1 into numbers: how big the Railway Reservation System (RRS) is, how many person-months it needs, how long it will take, how many people to hire, and what it will cost. The manual asks for “any estimation technique”. We use two that fit together: Function Point Analysis (FPA) to measure size from the scope, and the basic COCOMO model to convert size into effort, duration, and cost. A third, quicker method (expert judgement) is used as a cross-check. Session 13 cites these figures when comparing the estimate with the real program, so keep every number exactly as computed here.

Objectives

• Count unadjusted function points for the eight RRS modules from the scope statement.
• Rate the 14 general system characteristics and compute the value adjustment factor.
• Convert adjusted function points to lines of code and apply basic COCOMO (organic mode).
• Derive duration, average staff, and cost in rupees from the effort figure.
• Cross-check the model estimate against an expert judgement estimate and explain the difference.

Problem Statement

Session 2: Estimate the effort and cost required to build the above software. Use any estimation technique.

Concept

Why estimate before design

The project plan (manual section 1.2) needs a delivery deadline, a resource requirement, and a budget before the SRS exists. All three come from an estimate of size and effort. An estimate made from scope is rough (plus or minus 25 percent is normal), so it is revised after the SRS and again after design. The value of this session is the method, which stays the same at each revision.

Function Point Analysis

FPA measures size from what the software does for its users, not from code. Each function in the scope is classified as one of five types and rated simple, average, or complex.

Complexity depends on the number of data elements and files touched. For a scope-level count use a simple rule: one form with a few fields is simple; a form that touches two files is average; a form that touches three or more files or has many rules (route definition, booking with up to 6 passengers and seat allocation) is complex. Each ILF is counted once, in the module that maintains it.

Unadjusted function points (UFP) is the sum of weights. Then 14 general system characteristics (GSC) are each rated 0 to 5 and the value adjustment factor is VAF equals 0.65 plus 0.01 times the sum of ratings. Adjusted function points AFP equals UFP times VAF.

From function points to lines of code

COCOMO needs size in thousands of lines of code (KLOC). Published backfiring tables give an average lines-per-function-point for each language. For Python we use 60 LOC per FP, a conservative figure for a beginner team writing readable code with docstrings.

Basic COCOMO

Basic COCOMO (Boehm, 1981) has three modes. Organic mode is for small teams, familiar problems, and flexible requirements, which describes an MCA project team building a reservation system. The formulas are:

• Effort E equals 2.4 times KLOC to the power 1.05, in person-months (PM)
• Duration D equals 2.5 times E to the power 0.38, in calendar months
• Average staff equals E divided by D

Semi-detached mode (3.0, 1.12, 2.5, 0.35) and embedded mode (3.6, 1.20, 2.5, 0.32) give higher effort and are used for larger or tightly constrained systems. The exponent above 1 means effort grows faster than size, because communication overhead grows with the team.

Expert judgement

An experienced developer looks at each module and states a figure from memory of similar work. It is fast and captures things a model cannot see, but it is only as good as the expert. Using it alongside a model and explaining any gap is normal practice.

Estimation

1. Function count by module

Functions are taken from section 4 of the Session 1 scope statement.

2. Unadjusted function points

Each cell shows the number of functions and, in brackets, their function points.

Check by type: 60 + 44 + 26 + 74 + 10 = 214. Check by module: 23 + 63 + 16 + 25 + 21 + 24 + 25 + 17 = 214.

UFP = 214

3. General system characteristics

VAF = 0.65 + 0.01 × 40 = 0.65 + 0.40 = 1.05

4. Adjusted function points and size

AFP = UFP × VAF = 214 × 1.05 = 224.7, rounded to 225 FP

Size = 225 FP × 60 LOC per FP = 13,500 LOC = 13.5 KLOC

5. Effort, duration, and staff (basic COCOMO, organic mode)

Effort:

E = 2.4 × (KLOC)^1.05
  = 2.4 × (13.5)^1.05

  log10(13.5)          = 1.1303
  1.1303 × 1.05        = 1.1868
  antilog10(1.1868)    = 15.38

E = 2.4 × 15.38 = 36.9 person-months

Duration:

D = 2.5 × (E)^0.38
  = 2.5 × (36.9)^0.38

  log10(36.9)          = 1.5671
  1.5671 × 0.38        = 0.5955
  antilog10(0.5955)    = 3.94

D = 2.5 × 3.94 = 9.85 calendar months, rounded to 10 months

Average staff:

Staff = E / D = 36.9 / 9.85 = 3.75, rounded up to 4 persons

Productivity check: 13,500 LOC / 36.9 PM = 366 LOC per person-month, which is within the 300 to 500 range expected for an organic project in a high-level language.

6. Cost

Rate assumed: Rs 60,000 per person-month, the fully loaded cost (salary, workspace, equipment) of a junior developer in an Indian software services company.

Estimated cost of the RRS: Rs 23,64,000 (about Rs 23.6 lakh), delivered in 10 months by a team of 4.

7. Team plan

Person-months engaged: 10 + 20 + 7 = 37, which matches E = 36.9 PM.

8. Cross-check by expert judgement

Three developers with reservation-system experience were asked to estimate each module in person-months. Their averages:

The FPA share column distributes E = 36.9 PM in proportion to each module’s UFP (for example module 2: 63 / 214 × 36.9 = 10.9).

Comparison: expert judgement gives 34 PM and Rs 20,40,000 for development effort against 36.9 PM and Rs 22,14,000 from COCOMO, a gap of 8 percent. The experts rate Booking higher than FPA does because seat allocation and waitlist logic are hard to get right even though they are one function; they rate Train and Schedule Management lower because it is mostly simple data entry forms. Both figures fall within the plus or minus 25 percent expected at the scope stage. We adopt the COCOMO figure of 36.9 PM because it is the larger and safer one, and record the expert figure as the lower bound.

9. Summary of the estimate

Viva Questions

• Q: Why count function points instead of lines of code directly? A: Function points can be counted from the scope before any code exists, and they do not depend on the language.
• Q: What is the difference between an EO and an EQ? A: An EO contains derived or computed data (a report, a refund amount); an EQ only retrieves stored data (PNR status).
• Q: Why is the Train file counted as complex? A: It groups Train, Route, Coach, and Seat, many data elements across several record types.
• Q: What does VAF do? A: It scales the raw count by up to plus or minus 35 percent for technical factors like performance, online update, and multiple sites.
• Q: Why organic mode? A: Small team, familiar application type, and flexible requirements; embedded mode is for real-time or safety-critical systems.
• Q: Why is the exponent in the effort formula more than 1? A: Effort grows faster than size because communication and integration overhead rise with team size.
• Q: Why is duration not simply effort divided by team size? A: Adding people does not shorten work proportionally; COCOMO derives duration from effort with an exponent of 0.38.
• Q: What would change if the team used C instead of Python? A: LOC per FP would roughly double (about 128), so KLOC, effort, and cost would rise.
• Q: How accurate is this estimate? A: Plus or minus 25 percent at the scope stage; it is revised after the SRS and after design.

Common Mistakes

• Picking a KLOC figure from the air (such as 75 KLOC) with no function count behind it; the examiner asks where the number came from.
• Counting the same ILF in several modules; each file is counted once, in the module that maintains it.
• Using intermediate COCOMO cost drivers with basic COCOMO constants, or mixing constants from two modes.
• Rounding too early; keep two decimals until the final line, then round.
• Quoting cost in dollars with no rate; state the rate per person-month in rupees and show the multiplication.
• Leaving out duration and staff; effort alone does not give a delivery date.

Session Summary

Submit in the lab record:

• The problem statement copied from the manual.
• The function count table (section 1) and the UFP summary table (section 2) totalling 214.
• The 14 GSC ratings with reasons, VAF 1.05, AFP 225, and size 13,500 LOC.
• The COCOMO working for E, D, and staff with logarithm steps shown.
• The cost table with the stated rate, and the expert judgement comparison.
• The summary table (section 9); Session 13 will compare actual code size against it.