Module 4
Albrecht Function Point Analysis (FPA)
FP = U FP ∗ V AF
Purpose: Measures software size based on the functionality delivered to the
user, independent of programming language.
Process:
1. Count user inputs, outputs, inquiries, files, and external interfaces.
2. Classify them by complexity (low/avg/high) and assign weights.
3. Adjust with a “complexity/value adjustment factor” based on 14 general
system characteristics (e.g., performance, reusability).
Outcome: Total Function Points (FP) → converted to effort or cost using
productivity rates.
Objective of FPA:
Encourage early approximation – estimate project size and effort from
functional requirements before detailed design or coding begins.
Support project management – provide a stable basis for planning,
scheduling, budgeting, and tracking progress.
Enable comparative analysis – allow productivity and quality comparisons
across different teams, technologies, or organizations.
Improve cost–benefit analysis – give a clear, quantifiable measure of
delivered functionality to weigh against development and operational costs.
Align with business objectives – focus on user-recognized functions so
estimates reflect the real value delivered to the business.
General System Factors – 14:
Data Communications – degree of distributed or networked data.
Distributed Data Processing – need for distributed computing resources.
Module 4 1
Performance – response-time or throughput requirements.
Heavily Used Configuration – extent of use of hardware or system resources.
Transaction Rate – expected volume or frequency of transactions.
Online Data Entry – proportion of data entered online.
End-User Efficiency – requirements for user-friendly interfaces.
Online Update – need for real-time file updates.
Complex Processing – computational or algorithmic complexity.
Reusability – degree to which code or components must be reusable.
Installation Ease – ease of conversion and installation of the system.
Operational Ease – requirements for automated operation or simple
maintenance.
Multiple Sites – deployment across multiple physical locations.
Facilitate Change – ability to support future changes or enhancements.
Function Points Mark II
FP = (0.58 ∗ N ip) + (1.66 ∗ N enquires) + (0.26 ∗ N op)
Purpose: Measures software size based on the transaction and data
movements focusing on logical user functionality.
Differences:
Focuses on logical transactions (inputs → processing → outputs).
Module 4 2
Uses three data types—Inputs, Outputs, and Entities Referenced—with
simpler weighting.
Eliminates the 14 complexity adjustment factors for greater consistency.
Object Points
Purpose: Estimation technique tailored for object-oriented or 4GL (fourth-
generation language) development and GUI-driven applications.
Process:
Counts:
Screens (User Interfaces)
Reports
3GL Components
Weights each by complexity and adjusts for reuse and productivity to get
New Object Points (NOP), which are converted to person-months.
COCOMO Model (Constructive Cost Model)
Purpose: A parametric model to estimate effort (person-months) and
schedule based on software size in thousands of delivered source lines of
code (KDSI/KLOC).
Versions:
Basic COCOMO
Module 4 3
Intermediate COCOMO: Adds cost drivers (product, platform, personnel,
project).
Detailed COCOMO: Adds phase-wise effort distribution.
Inputs: Estimated size of the code and cost driver ratings (complexity,
reliability, team experience).
Output: Effort, development time, and staffing levels.
Module 4 4