Unit 3: Effort Estimation

I. Orientation — Purpose and Foundations

Software effort estimation predicts the human work, elapsed time, staffing, and cost needed to develop or maintain a software system. It is based on the relationship between the product to be built, the development process, and the project environment. Estimation supports bidding, scheduling, staffing, budgeting, risk management, and feasibility decisions.

• Primary measure: Effort is usually measured in person-hours, person-days, or person-months; cost is derived by multiplying effort by labor rate.
• Size foundation: Estimates commonly begin with software size, measured in lines of code (LOC), function points (FP), objects, use-case points, or story points.
• Effort versus duration: Ten person-months does not necessarily mean ten people working for one month because communication and coordination overhead increase with team size.
• Uncertainty: Early estimates have wider ranges because requirements, architecture, technology, and staffing are not fully known.
• Calibration: A model becomes more useful when its parameters are adjusted using completed projects from the same organization.
• Iterative refinement: Estimates should be revised at requirements, design, implementation, and testing milestones as evidence improves.

II. Estimation Foundations — Meaning and Basis

A. Meaning

Effort estimation is the systematic process of forecasting the work required to produce specified software results under stated constraints.

• Effort: The total labor required, such as 2,400 person-hours for analysis, coding, testing, and management.
• Schedule: The calendar duration, such as 6 months; it is influenced by staffing, dependencies, and productivity.
• Cost: The financial value of effort and resources, commonly calculated as:

Cost = Effort × Labor rate + Other project costs

• Estimate range: A forecast such as 18–24 person-months communicates uncertainty more honestly than a single number.
• Decomposition: A large estimate is divided into work packages, for example requirements, design, implementation, integration, and testing.

B. Problems with Estimation Basis

The quality of an estimate cannot exceed the quality and relevance of the information used as its basis.

• Unstable requirements: A change from 20 to 35 required reports changes both functional size and implementation effort.
• Ambiguous size measures: LOC depends on programming language; the same feature may require 100 Java lines but 30 Python lines.
• Incomplete historical data: A project repository may record final effort but omit overtime, reused components, defect-fixing effort, or management work.
• Non-comparable projects: A web application, safety-critical embedded system, and data pipeline have different productivity and verification demands.
• Technology uncertainty: A new framework or unfamiliar cloud platform may reduce or increase productivity unpredictably.
• Human variation: Skill, team cohesion, turnover, and domain knowledge can change effort even when product size is similar.
• Optimism and pressure: A manager’s desired deadline can contaminate an objective estimate, producing a target rather than a forecast.
• Double counting: Requirements effort, project management, testing, and rework must be defined consistently before comparing projects.

III. Estimation Techniques — Approaches and Selection

Estimation techniques convert product information and project assumptions into an effort forecast; no single technique is reliable in every situation.

• Expert judgment: Experienced engineers estimate by analogy and decomposition; it is fast but vulnerable to bias and memory limitations.
• Analogy estimation: A new project is compared with a similar completed project, then adjusted for size, complexity, technology, and team capability.
• Top-down estimation: The total project is estimated first and distributed among phases; it is useful early but may overlook detailed work.
• Bottom-up estimation: Tasks are identified in a work breakdown structure and summed:

Total effort = Σ effort(task_i)

• Parametric models: A mathematical relationship such as COCOMO derives effort from size and cost drivers.
• Three-point estimation: Optimistic O, most likely M, and pessimistic P values can produce:

Expected effort = (O + 4M + P) / 6

• Agile estimation: Relative story points and velocity forecast completed work, but they do not directly equal person-hours.
• Technique combination: Agreement between expert, analogy, and parametric estimates increases confidence; disagreement identifies assumptions requiring investigation.

IV. Albrecht Function Point Analysis — Functional Size

Albrecht Function Point Analysis (FPA), introduced by Allan Albrecht at IBM in the 1970s, estimates software size from user-visible functionality rather than source code.

A. Albrecht Function Point Analysis

FPA counts five function types and weights them according to complexity to obtain an adjusted function-point count.

• External Inputs (EI): Data entering the system, such as a customer registration form.
• External Outputs (EO): Derived information leaving the system, such as an invoice containing calculated tax.
• External Inquiries (EQ): Input-output interactions involving immediate retrieval, such as searching an account balance.
• Internal Logical Files (ILF): Logical user data maintained by the application, such as a customer database.
• External Interface Files (EIF): Data used by the application but maintained by another system, such as an external tax table.
• Unadjusted Function Points: Each function is classified as simple, average, or complex and multiplied by the standard weight for its type:

UFP = Σ(count_i × weight_i)

• Value Adjustment Factor: Fourteen general system characteristics, including performance, transaction rate, and reusability, are rated from 0 to 5. Their total is TDI:

VAF = 0.65 + 0.01 × TDI
Adjusted FP = UFP × VAF

• Worked example: If UFP = 200 and TDI = 35, then VAF = 1.00 and adjusted size is 200 FP.
• Limitation: Counting requires trained judgment, and the original adjustment factors can introduce subjectivity; modern Function Point standards may use different conventions.

V. Functions Mark II — Function-Oriented Sizing

Functions Mark II (Mark-II FPA) is a function-point method that emphasizes logical transactions and data entities, providing a structured alternative to Albrecht counting.

A. Functions Mark II

Mark-II measures functional size by counting user-recognizable input, output, and entity-reference components.

• Transaction emphasis: A logical transaction represents a complete user-relevant interaction, such as creating an order or retrieving a statement.
• Entity types: Data entities referenced or maintained by transactions contribute to the functional count.
• Component count: A simplified representation is:

Size = a × inputs + b × outputs + c × entity references

Here, a, b, and c are calibrated weights defined by the selected Mark-II counting standard.

• Logical boundary: Counting focuses on what the system does for users, not on screens, program modules, or programming statements.
• Language independence: A function count can be converted to effort without assuming that implementation uses Java, C#, or another language.
• Strength: Its transaction-and-entity view can be effective for information systems with well-defined data processing.
• Limitation: Real-time, algorithmically intensive, or highly nonfunctional requirements may not be fully represented by functional counts alone.

VI. COCOMO Model — Constructive Cost Estimation

The Constructive Cost Model (COCOMO), developed by Barry Boehm in 1981, estimates effort and schedule from software size and project characteristics.

A. COCOMO Model

Basic COCOMO uses an exponential effort equation whose coefficients depend on the project mode.

• Project modes: Organic projects are small and familiar; semidetached projects have mixed experience and complexity; embedded projects face tight hardware, regulatory, or operational constraints.
• Basic effort equation:

E = a × (KLOC)^b

E is effort in person-months, KLOC is thousands of delivered lines of code, and a and b are mode-specific coefficients.

• Development time:

D = c × (E)^d

D is development time in months, while c and d are schedule coefficients.

• Average staffing:

Staff = E / D

• Example: For an organic project using the classic basic coefficients a = 2.4, b = 1.05, and KLOC = 10, effort is approximately 26.9 person-months.
• Interpretation: The exponent b > 1 models diseconomies of scale: larger systems require disproportionately more coordination and integration effort.
• Limitation: KLOC is difficult to estimate early and depends on language, coding style, reuse, and generated code.

B. COCOMO extensions

COCOMO extensions add cost-driver detail and lifecycle sensitivity to improve realism beyond the basic model.

• Intermediate COCOMO: Effort is calculated as:

E = a × (KLOC)^b × EAF

EAF, the Effort Adjustment Factor, is the product of effort multipliers for attributes such as reliability, database size, product complexity, analyst capability, tool support, and schedule pressure.

• Detailed COCOMO: The model applies different effort multipliers and phase distributions to requirements, design, coding, integration, and testing.
• COCOMO II: Designed for modern development, it supports application composition, early design, and post-architecture models, including reuse, prototyping, incremental development, and process maturity.
• COCOMO II post-architecture form:

PM = A × Size^E × Π EM_i

PM is person-months, A is a calibration constant, Size is usually equivalent KSLOC, E reflects scale factors, and EM_i are effort multipliers.

• Scale exponent:

E = B + 0.01 × Σ SF_j

B is a base constant and SF_j are scale factors such as precedentedness, flexibility, architecture resolution, team cohesion, and process maturity.

• Use: Extensions are valuable when project context is known, but unreliable ratings or poor size forecasts still produce misleading results.

VII. AI-based Estimation Tools — Data-Driven Prediction

AI-based estimation tools learn relationships between project attributes and observed effort, supplementing conventional models with statistical or machine-learning methods.

A. AI-based Estimation Tools

These tools typically predict effort from historical project records containing size, requirements, team, technology, defects, schedule, and actual labor.

• Regression models: Linear, polynomial, or regularized regression predicts effort from measurable variables and provides interpretable coefficients.
• Tree-based models: Random forests and gradient boosting capture nonlinear effects, such as a sharp effort increase when complexity and team turnover occur together.
• Neural networks: Useful for large datasets with complex relationships, but they require careful tuning and are less transparent.
• Similarity methods: k-nearest-neighbor estimation finds projects with comparable feature vectors and aggregates their actual effort.
• Data preparation: Missing values, inconsistent units, outliers, and duplicate project records must be corrected before training.
• Evaluation: Mean absolute error (MAE), root mean square error (RMSE), and prediction intervals measure accuracy:

MAE = (1/n) × Σ |actual_i − predicted_i|

• Governance: Predictions should expose influential factors and confidence ranges; historical bias can reproduce unfair or systematically optimistic estimates.
• Practical role: AI should support expert review, assumption checking, and scenario analysis rather than replace accountable estimation.

VIII. NLP-Based Requirement Analysis — Extracting Estimation Inputs

Natural Language Processing (NLP) applies computational linguistic methods to requirements written in ordinary language, helping transform text into structured information for sizing and estimation.

A. Introduction to Natural Language Processing (NLP)-based requirement analysis

NLP-based analysis identifies entities, actions, constraints, and quality attributes in requirement documents before effort is estimated.

• Preprocessing: Tokenization, sentence segmentation, normalization, and removal of irrelevant terms prepare text for analysis.
• Requirement classification: A classifier can distinguish functional requirements, such as “The system shall create an account,” from nonfunctional requirements concerning security or performance.
• Entity and action extraction: In “A clerk approves a loan application,” clerk is an actor, approves is an action, and loan application is a domain entity.
• Ambiguity detection: Terms such as “fast,” “user-friendly,” or “normally” signal requirements needing measurable acceptance criteria.
• Duplicate and similarity detection: Semantic embeddings can identify repeated requirements, preventing double counting during function-point or use-case analysis.
• Sizing link: Extracted actors, transactions, interfaces, and data entities can supply candidate inputs to function-point or machine-learning models.
• Limitations: NLP may misinterpret domain terminology, negation, implied behavior, and cross-sentence dependencies; human validation remains necessary.

IX. Automated Effort Estimation Using Historical Project Data — Continuous Calibration

Automated estimation uses a repository of completed projects to generate repeatable predictions for a new project and improve the model as actual outcomes accumulate.

A. Automated effort estimation using historical project data

The process combines data collection, feature construction, model training, prediction, and post-project recalibration.

• Historical dataset: Each record should connect predictors, such as FP, KLOC, team size, complexity, and duration, with actual effort in a consistent unit.
• Feature engineering: Requirement text may be converted into counts of functions, entities, interfaces, constraints, or embedding vectors.
• Training and validation: Data is divided into training and test sets; time-based validation is preferable when projects evolve chronologically.
• Prediction workflow:

Collect → Clean → Extract features → Train → Validate
→ Predict effort range → Review assumptions → Record actual effort

• Calibration: After delivery, actual effort is compared with prediction; systematic error can update coefficients, feature weights, or model selection.
• Example: If comparable projects average 0.12 person-months per FP and a new system has 150 FP, a baseline forecast is 18 person-months, before adjustments for unfamiliar technology or high reliability.
• Uncertainty reporting: A useful system reports a range, influential variables, comparable projects, and data age rather than presenting an unexplained single value.
• Operational risks: Small samples, changing processes, concept drift, inaccurate timesheets, and survivorship bias can make automated predictions appear more precise than they are.
• Best practice: Combine automated output with expert judgment, document assumptions, monitor prediction error, and prevent estimates from becoming self-fulfilling schedule targets.