UNIT 2 Software project cost and effort estimation

Software project cost and effort estimation, in software

engineering, is the process of predicting the total time,
resources (people), and financial cost required to develop a
software system, essentially calculating the "workload"
needed to complete a project throughout its lifecycle, taking
into account various factors like complexity, size, and team
capabilities.
Key points about software project cost and effort estimation:
Goal:
To provide a realistic prediction of how much time and
money a project will take to develop, allowing for better
project planning and budgeting.
Factors considered:
 Project size (lines of code, function points)
 Complexity of features
 Team experience and skill level
 Development methodology
 Historical data from similar projects

Techniques used to predict Software project cost and

effort estimation
• Lines of Code
• Function point analysis,
• COCOMO etc.
 Lines of Code (LOC) :
Lines of Code (LOC) is possibly the simplest among all
metrics available to measure project size.
Consequently, this metric is extremely popular.
This metric measures the size of a project by counting
the number of source instructions in the developed
program.
While counting the number of source instructions,
comment lines, and header lines were ignored.
It determines the LOC count at the end of a project is
very simple.
However, accurate estimation of LOC count at the
beginning of a project is a very difficult task.
It is programming language dependent

Example of Line of Code :

void selSort(int x[], int n) {

//Below function sorts an array in ascending order
int i, j, min, temp;
for (i = 0; i < n - 1; i++) {
min = i;
for (j = i + 1; j < n; j++)
if (x[j] < x[min])
 min = j;
temp = x[i];
x[i] = x[min];
x[min] = temp;
}
}
So, now If LOC is simply a count of the number of lines
then the above function shown contains 13 lines of
code (LOC). But when comments and blank lines are
ignored, the function shown above contains 12 lines of
code (LOC).

Functional Point(FP)
Function Point (FP) is an element of software development
which helps to approximate the cost of development early
in the process. It may measure functionality from user’s
point of view.

They are widely accepted as an industry standard for

functional sizing.

FP metric proposed by Albrecht in 1983.

This metric overcomes many of the shortcomings of the
LOC metric.
Since its inception in the late 1970s, the function point
metric has steadily gained popularity.
The function point metric has several advantages over
the LOC metric.
One of the important advantages of the function point
metric over the LOC metric is that it can easily be
computed from the problem specification itself.
Using the LOC metric, on the other hand, the size can
accurately be determined only after the product has
fully been developed.
Function point and LOC are measurement units for the
size of the software.
The size of the software that is dependent on
development is necessary to come up with accurate
estimates of the effort, cost, and duration of a project

Difference between LOC and Function Point :

Function Point (FP) Line of Code (LOC)
Function Point metric
LOC metric is based on
is specification-
analogy.
based.
Function Point metric
LOC metric is dependent on
is language
language.
independent.
Function Point metric LOC metric is design-
is user-oriented. oriented.
Function Point metric
It is changeable to FP (i.e.
is extendible to Line
backfiring)
of Code.
 Function Point is LOC is used for calculating
used for data the size of the computer
processing systems program
Function Point can be LOC is used for calculating
used to portray the and comparing the
project time productivity of programmers.

In general, people prefer the functional size of software

indicated as Function Point for one very important reason, i.e,
the size expressed using the Function point metric stays
constant in any case and whichever language or languages
are used.

Function Point is typically broken down into five major

components:

1. External Inputs (EI)

2. External Outputs (EO)
3. External Inquiries (EQ)
4. Internal Logical Files (ILF)
5. External Interface Files (EIF)

These components describe the various types of

interactions a system has with its environment, including
the way the system processes and stores information.
Here’s an explanation of each component with examples:

1. External Inputs (EI)

Definition: External Inputs refer to user inputs or data
received from outside the system that are processed by the
system. This includes the data entered into the system or
commands given to it to perform specific functions.

Example:

A user fills out a registration form in a web application

and submits it.
In an e-commerce application, a user inputs payment
details (credit card number, shipping address) to complete
a purchase.
Explanation: The act of the user providing data (like
filling a form) is an external input that will be processed
by the system to perform further actions.

2. External Outputs (EO)

Definition: External Outputs refer to the data that the
system provides to users or external systems after
processing an external input. This includes reports,
confirmation messages, or any result that is sent back to
the user.

Example:

After submitting the registration form, the user receives a

"Welcome" message or confirmation.
A customer receives an order confirmation email after
completing the purchase in an e-commerce system.
Explanation: The system generates a result or response
based on the user’s input or action, such as an order
summary or a receipt. This is categorized as an external
output.

3. External Inquiries (EQ)(Database interaction happens)

Definition: External Inquiries represent the interactions
where the system retrieves or queries information from its
database or other systems, without performing significant
processing. These involve read-only operations that
typically return data in response to user requests.

Example:

A user queries the available inventory of a product in an

online store.
A person searches for flight availability on an airline
booking system.
Explanation: These are simple requests where the system
performs a lookup operation, returning information such
as product availability or flight details, without changing
any data in the system.

4. Internal Logical Files (ILF)

Definition: Internal Logical Files are user-defined,
persistent data files that are maintained within the system.
These files are typically used for storing application data
that needs to be accessed or modified over time.

Example:

A customer database in a CRM system.

An inventory management system where stock details
(quantity, price) are stored.
Explanation: These are the core data entities that the
system keeps and manages internally, such as customer
records or product inventories, which are used to perform
operations on the system.
5. External Interface Files (EIF)
Definition: External Interface Files are files or data that
the system accesses from external sources or systems.
These are typically non-modifiable by the system and are
used for integration with other systems or services.

Example:

A billing system that retrieves payment data from an

external financial service provider's database.
A weather application that pulls data from an external
weather data service.
Explanation: These are external data sources that the
system reads from but does not maintain or modify, like
an external weather API or a third-party payment
processor system.

Function Point Analysis :

Step 1: Calculate Counting Functional Point (F)

F = 14 * scale

Why the Number 14?

The number 14 comes from the 14 general characteristics

that represent various aspects of system complexity, such
as:
1. Data communications
2. Distributed functions
3. Performance requirements
4. Heavily used configuration
5.Transaction rate
6. On-line data entry
7. End-user efficiency
8. On-line update
9. Complex processing
10. Reusability
11. Installation ease
12. Operational ease
13.Multiple sites
14. Facilitate change

Scale varies from 0 to 5 according to character of

Complexity Adjustment Factor (CAF).

Below table shows scale:

0 - No Influence
1 - Incidental
2 - Moderate
3 - Average
4 - Significant
5 - Essential

Step 2: Calculate Complexity Adjustment Factor (CAF)

CAF = 0.65 + ( 0.01 * F )

Step 3: Calculate Unadjusted Function Points (UFP)

This TABLE is required to find UFP

Function Units Low Avg High

EI 3 4 6
EO 4 5 7
EQ 3 4 6
ILF 7 10 15
EIF 5 7 10

Multiply each individual function point to corresponding

values in TABLE.

Step 4: Counting Function Point (FP):

FP = UFP * CAF

Example: Problem
Question: Given the following values, compute function
point when all complexity adjustment factor (CAF) and
weighting factors are average.

User Input = 50
User Output = 40
User Inquiries = 35
User Files = 6
External Interface = 4

Explanation:

Step-1: As complexity adjustment factor is average (given

in question), hence,
scale = 3.
F = 14 * 3 = 42

Step-2:
CAF = 0.65 + ( 0.01 * 42 ) = 1.07

Step-3: As weighting factors are also average (given in

question) hence we will multiply each individual function
point to corresponding values in TABLE.

UFP = (50*4) + (40*5) + (35*4) + (6*10) + (4*7) = 628

Step-4:
Function Point = 628 * 1.07 = 671.96