Unit 3: Effort Estimation - Subjective Questions

Software effort estimation is the process of predicting the amount of human effort required to develop, test, deploy, and sometimes maintain a software system. Effort is normally expressed in person-hours, person-days, or person-months.

The estimated effort can be represented as:

However, effort and duration are not perfectly interchangeable because adding people does not always reduce development time proportionally.

Objectives of effort estimation:

• Determine the approximate cost of a software project.
• Prepare realistic project schedules and milestones.
• Decide the required team size and skill mix.
• Support project bidding and contract negotiation.
• Allocate resources among competing projects.
• Evaluate project feasibility and profitability.
• Establish a baseline for monitoring and control.

Importance:

Accurate estimation helps management avoid budget overruns, missed deadlines, excessive staffing, and unrealistic customer commitments. It also improves risk management and enables comparison between planned and actual performance. Since exact information is rarely available at the beginning, estimates should be treated as informed predictions and revised as the project becomes better understood.

Software estimation is difficult because the information used as its basis is often uncertain, incomplete, or inconsistent.

Major problems include:

• Incomplete requirements: Early estimates are made before all functional and non-functional requirements are known.
• Changing requirements: Scope changes invalidate assumptions used in the original estimate.
• Unclear size measures: Measures such as lines of code, function points, and story points represent different aspects of size.
• Lack of historical data: New organizations may not have reliable data from comparable projects.
• Non-comparable projects: Differences in technology, domain, team experience, quality requirements, and complexity reduce the usefulness of past data.
• Optimism and bias: Developers may underestimate difficulties, while managers may deliberately reduce estimates to win contracts.
• Productivity variation: Productivity differs across individuals, teams, programming languages, tools, and development environments.
• Ignored non-development work: Meetings, documentation, rework, testing, configuration management, and deployment may be omitted.
• Uncertain risks: Integration failures, staff turnover, security issues, and technical limitations may not be visible initially.
• Confusion between effort and duration: A project requiring 100 person-months cannot necessarily be completed in one month by 100 people.

Therefore, an estimate should clearly state its assumptions, confidence range, estimation date, included activities, and expected risks.

Software effort can be estimated using judgment-based, decomposition-based, algorithmic, and data-driven techniques.

Major techniques are:

1. Expert judgment: Experienced professionals estimate effort using domain knowledge. Techniques such as Delphi reduce individual bias.
2. Estimation by analogy: The new project is compared with similar completed projects, and differences are used to adjust the estimate.
3. Top-down estimation: Total project effort is estimated first and then distributed among phases or components.
4. Bottom-up estimation: Individual tasks or work packages are estimated and combined to obtain total effort.
5. Parametric or algorithmic models: Mathematical models such as COCOMO use software size and cost drivers to calculate effort.
6. Size-based estimation: Software size is measured using LOC, function points, object points, or use-case points and converted into effort.
7. Three-point estimation: Optimistic, most likely, and pessimistic values are combined. A common formula is:

where is optimistic, is most likely, and is pessimistic effort.

8. AI and machine-learning estimation: Models learn relationships between project attributes and actual effort from historical data.

In practice, organizations should use more than one technique, compare the results, document assumptions, and revise the estimate at project milestones.

Top-down estimation begins with an estimate for the complete system, whereas bottom-up estimation begins by estimating individual tasks or components.

Advantages of top-down estimation:

• Suitable during feasibility studies and early planning.
• Considers the project as a complete system.
• Requires less detailed information.

Advantages of bottom-up estimation:

• Produces traceable estimates for individual tasks.
• Encourages participation by the people performing the work.
• Supports detailed scheduling and resource allocation.

A practical approach is to create both estimates. Major differences between them should be investigated before finalizing the project baseline.

Albrecht Function Point Analysis, introduced by Allan Albrecht, measures software size from the functionality delivered to the user. It is largely independent of programming language and can be applied before coding begins.

Step 1: Identify the five function types

• External Inputs: Data or control information entering the application.
• External Outputs: Processed information leaving the application.
• External Inquiries: Input-output requests involving little processing.
• Internal Logical Files: User-recognizable logical data maintained by the application.
• External Interface Files: Logical data used by the application but maintained externally.

Step 2: Classify each function as low, average, or high complexity.

Standard weights:

Step 3: Calculate Unadjusted Function Points

Step 4: Rate the general system characteristics

Fourteen characteristics, such as performance, distributed processing, transaction rate, reusability, and operational ease, are rated from 0 to 5. Their sum is the Total Degree of Influence, denoted by .

Step 5: Calculate the Value Adjustment Factor

Step 6: Calculate adjusted function points

Function points may then be converted into effort using organizational productivity, such as person-hours per function point.

The standard Albrecht weights are applied to each function type.

Step 1: Calculate Unadjusted Function Points

• External Inputs:
• External Outputs:
• External Inquiries:
• Internal Logical Files:
• External Interface Files:

Therefore:

Step 2: Calculate the Value Adjustment Factor

Given :

Step 3: Calculate adjusted function points

Thus, the adjusted size of the system is approximately:

If the organization has a productivity rate of person-hours per function point, the estimated effort would be person-hours.

Advantages of Function Point Analysis:

• Language-independent: Function points measure delivered functionality rather than source code length.
• Early applicability: They can be estimated from requirements before design and coding.
• User-oriented: The method focuses on inputs, outputs, inquiries, and logical data visible to users.
• Supports productivity analysis: Organizations can compare person-hours per function point across projects.
• Useful for contracts: Function points provide a basis for pricing, benchmarking, and scope control.
• Handles different technologies: Projects implemented in different programming languages can be compared.

Limitations:

• Requires trained counters: Identifying logical functions and complexity levels requires experience.
• Subjectivity: Different analysts may produce different counts for the same requirements.
• Less suitable for algorithm-intensive systems: Scientific, embedded, and real-time systems may involve substantial effort but limited user-visible functionality.
• Dependence on requirement quality: Ambiguous or incomplete requirements lead to unreliable counts.
• Adjustment-factor concerns: Ratings of general system characteristics may be subjective, and some modern standards do not use the historical adjustment step.
• Counting overhead: Detailed counting can be costly for small or rapidly changing projects.

Function Point Analysis is most effective when counting rules are standardized, analysts are trained, and organizational productivity data is available.

Functions Mark II, also called Mark II Function Point Analysis, measures software size by examining logical business transactions. It was developed to improve the representation of information-processing systems in which each transaction receives input, accesses stored entities, and produces output.

A logical transaction is analyzed using:

• Input data element types: Unique data elements entering the system.
• Entity types referenced: Logical entities read or written during processing.
• Output data element types: Unique data elements produced by the transaction.

A commonly used unadjusted Mark II functional size formula is:

where:

• is the total number of input data element types.
• is the total number of entity-type references.
• is the total number of output data element types.

Procedure:

1. Define the application boundary.
2. Identify all user-recognizable logical transactions.
3. Count input data elements for each transaction.
4. Count entities referenced by each transaction.
5. Count output data elements.
6. Apply the Mark II weights and add the results.
7. If required by the adopted method, apply technical-complexity adjustments.
8. Convert the resulting functional size into effort using historical productivity data.

The method emphasizes transaction processing and is particularly useful for management information systems and business applications.

Both methods measure software from a functional user perspective, but they model functionality differently.

Similarities:

• Both are independent of programming language.
• Both can be applied before implementation.
• Both require well-defined functional requirements and application boundaries.
• Both need historical productivity rates to convert functional size into effort.

Key difference: Albrecht FPA separately counts data and transactional functions, whereas Mark II analyzes each logical transaction through its input, processing references, and output. The preferred method depends on organizational standards, available historical data, and the nature of the application.

COCOMO, or the Constructive Cost Model, is an algorithmic model developed by Barry Boehm for estimating software development effort and schedule from source-code size.

The Basic COCOMO effort equation is:

The development-time equation is:

where:

• is effort in person-months.
• is thousands of delivered source-code lines.
• is development time in months.
• , , , and depend on the development mode.

COCOMO modes and coefficients:

Organic mode: Small, relatively simple projects developed by experienced teams in a familiar environment.

Semidetached mode: Medium-sized projects involving mixed team experience and moderate constraints.

Embedded mode: Complex projects developed under tight hardware, software, operational, safety, or regulatory constraints.

The average staffing level may be estimated by:

For an organic-mode project, Basic COCOMO uses:

Given :

Step 1: Calculate effort

Step 2: Calculate development time

Step 3: Calculate average team size

Therefore, the project is estimated to require:

• Effort: approximately person-months
• Development time: approximately months
• Average team size: approximately people

The staffing value is only an average; actual staffing normally changes across requirements, design, coding, testing, and deployment phases.

The three COCOMO levels differ in the number of project factors considered and the level of detail produced.

1. Basic COCOMO

• Uses only software size in and the project mode.
• Provides a quick estimate of total effort and development time.
• Suitable for preliminary estimation.
• Does not explicitly account for team capability, tools, reliability, or hardware constraints.

2. Intermediate COCOMO

• Uses software size, project mode, and an Effort Adjustment Factor.
• The general effort equation is:

• is the product of cost-driver multipliers:

• Cost drivers cover product, hardware, personnel, and project attributes.
• Produces a more realistic estimate than Basic COCOMO.

3. Detailed COCOMO

• Extends Intermediate COCOMO by applying cost drivers to individual development phases or subsystems.
• Allocates effort across activities such as requirements, design, coding, integration, and testing.
• Accounts for differences between modules and lifecycle phases.
• Requires more detailed project information and greater estimation effort.

Thus, Basic COCOMO is simple but coarse, Intermediate COCOMO incorporates project characteristics, and Detailed COCOMO provides phase-sensitive and component-level estimates.

COCOMO cost drivers are project characteristics that increase or decrease the nominal effort predicted from software size. Each driver is assigned a rating such as very low, low, nominal, high, very high, or extra high, and the rating is converted into an effort multiplier.

Major cost-driver categories in Intermediate COCOMO are:

1. Product attributes

   • Required software reliability
   • Database size
   • Product complexity

2. Computer or hardware attributes

   • Execution-time constraints
   • Main-storage constraints
   • Platform volatility
   • Computer turnaround-time constraints

3. Personnel attributes

   • Analyst capability
   • Application experience
   • Programmer capability
   • Platform or virtual-machine experience
   • Programming-language experience

4. Project attributes

   • Use of modern programming practices
   • Use of software tools
   • Required development schedule

The Effort Adjustment Factor is calculated by multiplying all effort multipliers:

The adjusted effort is:

• If , the project requires more effort than the nominal estimate.
• If , favorable project conditions reduce effort.
• If , all drivers are nominal.

Cost drivers make COCOMO more sensitive to actual development conditions than a size-only model.

COCOMO II extends the original COCOMO model to support modern software practices such as reuse, object-oriented development, prototyping, commercial components, iterative processes, and rapid application development.

Why extensions were needed:

The original COCOMO was primarily based on custom software developed using procedural languages and a waterfall-style lifecycle. Modern projects commonly use frameworks, generated code, reusable components, cloud platforms, and incremental development.

Major COCOMO II submodels:

1. Application Composition Model

   • Used during prototyping and user-interface development.
   • Estimates size using object points such as screens, reports, and third-generation language components.
   • Adjusts for reuse to obtain new object points.

2. Early Design Model

   • Used when requirements are known but the architecture is not fully defined.
   • Uses approximate size and a reduced set of effort multipliers.

3. Post-Architecture Model

   • Used after the architecture has been established.
   • Uses detailed scale factors and effort multipliers.

A common COCOMO II effort form is:

where:

Here, are scale factors and are effort multipliers.

Other important extensions include:

• Explicit treatment of software reuse and adaptation.
• Support for source lines of code, function points, and object points.
• Factors for architecture, process maturity, team cohesion, and platform volatility.
• Estimation support at multiple stages of the lifecycle.

Traditional algorithmic models use predefined mathematical relationships, while AI-based tools learn estimation patterns from data.

AI-based tools offer:

• Automatic identification of important project factors.
• Ability to learn complex productivity relationships.
• Continuous improvement from new completed projects.
• Support for anomaly detection and risk prediction.

Limitations of AI tools include:

• Data bias and poor data quality.
• Overfitting to historical projects.
• Limited explainability.
• Concept drift when technologies and practices change.

A hybrid approach can combine an interpretable parametric baseline with AI-based corrections and expert review.

AI-based estimation treats effort prediction as a supervised machine-learning problem. Historical project attributes are used as input features, and actual effort is used as the target value.

Typical process:

1. Collect data: Gather project size, duration, team experience, technology, complexity, reuse, defects, requirements volatility, and actual effort.
2. Clean data: Handle missing values, duplicates, inconsistent units, and extreme outliers.
3. Engineer features: Convert categories into numerical variables and derive features such as team experience scores or requirements-change rates.
4. Split the data: Create training, validation, and test datasets while avoiding leakage from related projects.
5. Train models: Possible algorithms include linear regression, decision trees, random forests, support vector regression, neural networks, and gradient-boosted trees.
6. Tune and validate: Select hyperparameters using cross-validation.
7. Evaluate: Compare predicted and actual effort using suitable error measures.
8. Deploy: Integrate the model with requirement, issue-tracking, or project-management tools.
9. Monitor and retrain: Detect performance degradation and retrain the model using recent projects.

A model may be expressed as:

where is predicted effort and the values are project features.

Human review remains necessary to validate unusual estimates, account for new risks, and prevent blind reliance on historical patterns.

Natural Language Processing, or NLP, is a branch of artificial intelligence that enables computers to analyze, interpret, classify, and generate human language. In software projects, NLP can process requirement documents, user stories, contracts, change requests, and stakeholder feedback.

NLP tasks used in requirement analysis include:

• Tokenization: Dividing requirement text into words, phrases, or sentences.
• Part-of-speech tagging: Identifying nouns, verbs, adjectives, and other grammatical roles.
• Named-entity recognition: Detecting actors, systems, data objects, dates, and business entities.
• Dependency parsing: Identifying grammatical relationships between sentence elements.
• Classification: Categorizing requirements as functional, security, performance, usability, or reliability requirements.
• Similarity analysis: Detecting duplicate or closely related requirements.
• Ambiguity detection: Finding vague expressions such as fast, user-friendly, normally, or sufficient.
• Sentiment and priority analysis: Analyzing stakeholder feedback and urgency.
• Information extraction: Identifying actors, actions, objects, conditions, and constraints.

For example, from the requirement The administrator shall approve a customer account within two hours, an NLP system can extract the actor, action, object, and time constraint.

NLP supports analysts by improving consistency and speed, but domain experts must review the results because business context and implied requirements may not be fully captured automatically.

NLP-based requirement analysis converts unstructured requirement text into measurable features that can be supplied to an effort-estimation model.

Processing workflow:

1. Requirement collection: Import specifications, user stories, use cases, change requests, and acceptance criteria.
2. Text preprocessing: Normalize text, divide it into sentences, tokenize words, and remove irrelevant content.
3. Requirement classification: Classify statements into functional and non-functional categories.
4. Entity and action extraction: Identify actors, business objects, interfaces, actions, data entities, and external systems.
5. Complexity analysis: Detect conditional statements, exception paths, dependencies, calculations, security constraints, and performance requirements.
6. Quality analysis: Identify ambiguity, duplication, inconsistency, and missing information.
7. Feature construction: Generate variables such as requirement count, average sentence complexity, number of actors, interface count, security-requirement count, and semantic novelty.
8. Effort prediction: Submit these features to a regression, ensemble, neural, or hybrid estimation model.

The prediction can be represented as:

where is functional scope, is non-functional complexity, is interface count, is textual complexity, is dependency level, and is requirement volatility.

Benefits: Earlier estimates, faster document analysis, consistent feature extraction, and automatic updates when requirements change.

Challenges: Ambiguous language, domain terminology, incomplete requirements, multilingual documents, limited labeled data, and the need for explainable predictions.

Historical project data provides examples of how project characteristics were related to actual development effort. An automated system learns this relationship and applies it to new projects.

Important historical attributes include:

• Functional size, KLOC, function points, or story points
• Team size, experience, and skill distribution
• Application domain and project type
• Programming language, architecture, tools, and platform
• Number and complexity of requirements
• Reuse and third-party component levels
• Quality, security, reliability, and performance constraints
• Requirement volatility and defect counts
• Actual effort, duration, and cost

Development process:

1. Create a standardized historical project repository.
2. Define a consistent effort boundary, such as whether management and deployment are included.
3. Clean records and convert effort values into common units.
4. Remove duplicate records and investigate abnormal values.
5. Select relevant variables and encode categorical attributes.
6. Train statistical or machine-learning models.
7. Evaluate the models on projects not used during training.
8. Generate point estimates and uncertainty ranges for new projects.
9. Store actual results after project completion.
10. Periodically recalibrate or retrain the model.

The system must prevent data leakage, where information unavailable at estimation time is accidentally used as an input. It should also account for concept drift, because productivity changes as technologies, processes, and organizational practices evolve.

An estimation model should be evaluated using multiple metrics because no single measure completely describes prediction quality.

Let actual effort be , predicted effort be , and the number of projects be .

1. Mean Absolute Error

MAE is easy to interpret and expresses the average absolute error in the original effort unit.

2. Root Mean Squared Error

RMSE gives greater weight to large estimation errors.

3. Mean Absolute Percentage Error

MAPE is scale-independent but becomes unstable when actual effort is close to zero.

4. Coefficient of determination

measures how much variation in effort is explained by the model.

5. Prediction-interval coverage

This measures how often actual effort lies within the predicted uncertainty interval.

Evaluation should use unseen test data or cross-validation. Results should also be examined by project size, domain, technology, and time period to identify systematic underestimation or overestimation.