Function Point

Analysis

49111329.doc Page 1 of 61 12/8/2021

 Table of content

1. Software Estimation – An Introduction...................................................5

What is Software?.....................................................................................5
Software Engineering................................................................................5
Goal of Software Engineering.....................................................................5
Software Development Life Cycle................................................................6
Different Approaches to Software Development Life Cycle..............................7
Software Estimation and Software Development Life Cycle.............................8
Software Estimation – a challenge.............................................................10
2. Understanding Software Estimation.....................................................11
Estimate – Definition...............................................................................11
Components of Software Estimation..........................................................11
Size Estimate..........................................................................................11
Effort Estimate........................................................................................12
Schedule Estimate...................................................................................12
Cost Estimate.........................................................................................12
Hurdles in successful estimation process....................................................12
Estimation methods.................................................................................13
3. Using Function Points.........................................................................15
Function Points.......................................................................................15
Definition...............................................................................................15
Data in motion.....................................................................................15
Data at rest.........................................................................................16
Uses of Function Points............................................................................16
What FPA is unfit for................................................................................17
Types of Function Point Counts.................................................................17
Development Project Function Point Count...............................................17
Enhancement Project Function Point Count..............................................17
Application Function Point Count............................................................18
Function points and software metrics.........................................................18
Advantages of Function Points..................................................................18
Disadvantages of Function Points..............................................................19

49111329.doc Page 2 of 61 12/8/2021

 4. Counting Development Function Points.................................................20
Diagrammatic Representation of FPA.........................................................20
Technology Issues:.................................................................................21
Internet/Intranet Applications................................................................21
Client/Server.......................................................................................21
FPA Steps for Data Functions:...................................................................22
Internal Logical Files................................................................................24
Rating:...............................................................................................24
Standard Documentation:......................................................................24
External Interface Files............................................................................26
Rating.................................................................................................26
Standard Documentation:......................................................................27
Unadjusted Function Points for Data functions............................................28
FPA Steps for Transactional Function Types:...............................................29
DET’s for GUI.......................................................................................30
External Input........................................................................................33
Data Elements:....................................................................................33
Rating:...............................................................................................34
Standard Documentation:......................................................................34
External Output......................................................................................36
Data Elements:....................................................................................37
Rating:...............................................................................................38
Standard Documentation:......................................................................38
External Inquiries....................................................................................40
Data Elements:....................................................................................40
Rating:...............................................................................................42
Standard Documentation:......................................................................42
Unadjusted Function Points for Transaction functions...................................44
Compute Unadjusted Function Points.........................................................46
Rate on 14 General System Characteristics................................................46
Definition:...........................................................................................46
Rating:...............................................................................................46
Tabulating:..........................................................................................47
GSC’s at a Glance:...............................................................................47

49111329.doc Page 3 of 61 12/8/2021

 Considerations for GUI Applications........................................................48
Compute the Adjusted Function Points.......................................................49
5. Other Function Points Extensions.........................................................50
Mark II method.......................................................................................50
Feature Points........................................................................................51
Object Points..........................................................................................51
6. Effort, Cost, Schedule Estimates..........................................................52
Productivity............................................................................................52
Factors impacting Productivity.................................................................53
Size and Effort.....................................................................................53
Schedule and effort..............................................................................53
Quality Versus Effort and Schedule.........................................................53
Other Factors.......................................................................................53
Approach to Effort and schedule Estimation................................................54
Work Breakdown Structure(WBS)...........................................................54
Cost Estimation.......................................................................................55
Understanding Different Costs:..............................................................55
Cost Estimation Sheet...........................................................................56
7. Making the estimation process effective................................................57
A high maturity estimation process............................................................58
Database for Estimation...........................................................................58
Database Contents...............................................................................59
Estimation Tools.....................................................................................59
8. Industry Resources............................................................................60
Brief History:..........................................................................................60
Growth and Acceptance of Function Point Analysis.......................................60
More Information about IFPUG:................................................................60
Weblinks................................................................................................61

49111329.doc Page 4 of 61 12/8/2021

 1. Software Estimation – An Introduction

What is Software?
Software is not merely a set of programs.
Software is a collection of computer programs, procedures,business rules and
associated documentation and data.

Software Engineering
As we are aware, software is not just code but it also includes the data structures
that enable the programs to hold data and manipulate it, and the documents that
describe the system and the use of programs.

A software system is made for problem resolution. Making software begins with
understanding problem statement and then, designing the proposed solution and
implementing the same to solve the problem.

To develop a better quality software system, one must have a systematic

approach towards all engineering activities and all the umbrella activities that
monitor the entire process.

IEEE, (610.12-1990) defines software engineering as

(1) The application of a systematic, disciplined, quantifiable approach to the
development, operation and maintenance of software
(2) The study of approaches as in (1).

Goal of Software Engineering

The common symptoms of projects that fail :
 Delayed schedules
 Inaccurate understanding of user needs
 Inability to deal with changing requirements
 Modules that don’t fit together

49111329.doc Page 5 of 61 12/8/2021

  Software that is hard to maintain and extend
 Late discovery of serious project flaws

The projects usually fail due to root causes like :

 Ad hoc requirements management
 Ambiguous and imprecise communication
 Undetected inconsistencies in requirements, designs, and implementations
 Insufficient testing
 Failure to attack risk

The goal of software engineering is to produce high quality software at low cost.

Software Development Life Cycle

The basic phases in Software Development Process are Requirements Analysis,
Design, Coding and Testing.

The project outputs in Software development effort are :

Requirements document
Project Plan
System Design document
Detailed design document
Test Plan and test report
Final code
Software Manuals
Review reports

A software development process model specifies how these activities are

organised in software development effort to produce desired results.

The software development process has four roles :

1. Provide guidance as to the order of a team’s activities.
2. Specify which deliverables should be developed and when they should be
developed (helps in generation of Work Breakdown Structure)

49111329.doc Page 6 of 61 12/8/2021

 3. Direct the tasks of individual developers and the team as a whole
4. Offer criteria for monitoring and measuring the project’s products and
activities.

Different Approaches to Software Development Life Cycle

Waterfall model
This model suggests a systematic, sequential approach which begins at system
level feasibility study and progresses thru analysis, design ,coding, testing and
maintenance. A project begins with feasibility study. On successfully
demonstrating the feasibility of the project, the requirements analysis and project
planning starts. The design starts after the requirements analysis is complete and
coding begins after the design is complete. Once the programming is completed,
the code is integrated and testing is done. On successful completion of testing,
system in installed. After this, the regular operation and maintenance of the
system takes place.

Prototyping
The waterfall model assumes that the requirements of the system can be frozen
which may not be practically possible. In the prototyping approach, a prototype is
developed based on the currently known requirements. Development of prototype
undergoes informal design, coding and testing phases. Interactions with this
prototype can help customer better understand the requirements of desired
system. Once the clarity on requirements is achieved, the design, coding and
testing phases are followed sequentially as in Waterfall model.

Iterative
Here the basic idea is that the software is developed in increments, each
increment adding some functional capability to the system , till the full system is
implemented. At each step, requirement extensions and design modifications can
be made. Initially, a project control list is created that contains all the tasks that
should be performed to obtain the final implementation. Each step consists of
removing the next step from the list, designing the implementation for the

49111329.doc Page 7 of 61 12/8/2021

 selected task, coding and testing the implementation and performing the analysis
of the partial system obtained after this step and updating the list as a result of
analysis.

Software Estimation and Software Development Life Cycle

Any software order typically follows the following cycle :

(1) Order Acquisition

The marketing team is responsible for this phase. They identify

prospective clients from the marketplace. Once such prospect has a
requirement for software development, marketing team react to it by
initiating the process of Proposal preparation. With the macro-level
knowledge of the requirement, technical support team tries to reach to a
estimate about the size of the software effort. As per the productivity
standards of the organization, the effort and cost for the project
determined. The proposal is then submitted to the client. After the rounds
of negotiation, finally the contract is awarded for software development.

(2) Planning (umbrella activity)

The project plan is developed at the beginning of the job and is

successively refined as the work progresses. The project plan defines the
work and how it will be done. It provides a definition of each major task,
an estimate of the time and resources required and a framework for
management review and control.
It also covers the plan for implementing quality assurance related
activities and configuration management activities.

(3) Order Execution

49111329.doc Page 8 of 61 12/8/2021

 Requirements specification is the starting step for development activities.
During the requirements specification, the goal is to produce a user
requirements specification document. This document forms the basis for
the development and software validation.
There are two basic activities in requirements phase. The first is problem
or requirements analysis. The goal of this activity is to understand
different aspects as the requirements of the problem, its context and how
it fits in the client’s organisation. The second activity is requirements
specification, during which the understood problem is specified and
written, producing user requirement specification (URS).
At the end of URS, a complete picture of the micro-level requirements is
known and hence the effort and cost estimates are revisited to get the
correct picture of the estimates.
The software is then further completed thru high level design, detailed
design, coding and testing.

(4) Order Delivery

When the software is implemented at the customer’s site, the users
come up further defects that were not identified in testing phase or may
come up with further modifications/ enhancement. As a result, the
software undergoes the change. Change management is one of the most
fundamental activities of software engineering. Changes to requirements
drive design and design changes affect the code. For even modest-sized
projects, the number of people involved and the change volume generally
require a formal change management system. Hence, the need for
software configuration management (SCM).
During this phase, estimation is used to determine the impact(size) of the
change and identify addition effort and cost estimates.

(5) Order Closure

When all the software activities as mentioned in the contract are over,
the order is closed after noting the lessons learnt in project database
where the effort and size variances are specifically noted.

49111329.doc Page 9 of 61 12/8/2021

 So as one can see, Software Estimation activity starts during the order acquisition
phase itself. The estimates are then revisited once the order is acquired and the
planning begins for the execution of the project. As more insights about project
scope are gained during the order execution phase, estimates are once again
revisited to check the validity of initial estimates. References to estimation
continues to happen till the order is closed.

Software Estimation – a challenge

The flaws in estimates typically become evident when the project proceeds to the
stages of detailed planning and execution. Improper estimates lead to a variety of
problems for both the software organization and user organization e.g.
a) in case of over estimates, the bidding software organization may lose the
project, because a competing software organization has estimated more
accurately and quoted lower.
b) In case of an under estimate, the software organization will make a loss
and also deadly the delivery of the software.

Estimation often suffers due to incomplete knowledge, lack of time and various
market and business pressures that are directly and indirectly put on the
estimator to arrive at more ‘business acceptable’ estimates.

On the other hand, accurate estimates for the size, effort, schedule and cost
ensure that commitments made to customers and budgets that are allocated are
realistic. This reduces the pressure on the project team to take short-cuts,
thereby increasing the probability of delivering on time, within budget and
fulfilling user requirements.

49111329.doc Page 10 of 61 12/8/2021

 2. Understanding Software Estimation

Estimate – Definition
A tentative judgement of the approximate value, worth, cost, size or other
attributes of significance.

Components of Software Estimation

A simple estimation model relating size, effort, schedule and cost is depicted
below:

User Requirement
Specification
Organisatio
n Project
database
Size Estimation

Effort Estimation
Contractual Other Cost
schedule Component
commitmen s
ts
Schedule Cost Estimation
Estimation

Size Estimate
For a software project, we are interested primarily in estimating the cost and
duration of the project. A project estimate is only as good as the estimate of the
size of the work.

49111329.doc Page 11 of 61 12/8/2021

 Because a project estimate is only as good as the estimate of the size of the work
to be accomplished, sizing represents the project planner’s first major challenge.
In the context of project planning, size refers to a quantifiable outcome of the
software project. Size can be measured in Lines of code or Function Points.

Effort Estimate
The estimate for the manpower that is required for the software product. Along
with the schedule estimate, it determines the team size and effort allocation.
Effort is normally measured in terms of person-days or person-months.
Effort estimate is driven by size and many project related factors such as skill and
capability of the team, the language and platform to be used, the availability and
suitability of the platform, the stability of the team etc.

Schedule Estimate
Schedule is the duration between the start of the project and the end of the
project. This is normally represented in terms of calendar months. It is influenced
by the contractual schedule commitments.

Cost Estimate
This is the estimate of the costs for a software project. A major component of
costs in software project is manpower cost which is based on effort estimation.
Apart from this, there are few additional cost components, e.g. infrastructural
costs, travel, communication facilities, Project specific training, outsourcing
resources.

Hurdles in successful estimation process

1. Estimate in a hurry
2. Ambiguous requirements
3. Lack of historical information
4. Ignorance of the fact that Productivity is inversely related to the size of
the software.
5. Other important factors not considered like

49111329.doc Page 12 of 61 12/8/2021

 a. Availability and stability of the development environment
b. Team Capability and experience
c. Team Stability
d. Maturity of the processes
e. Availability of reusable software components etc.
6. Poor tracking of estimates during project execution

Estimation methods
To reduce the judgemental value of estimation and make it a scientific process,
software estimation needs to be based on estimation methods. The estimation
methods selected should be of following characteristics :
1. Should be able to convert requirements into one or more size estimates.
2. Should specify how effort, schedule and cost can be derived from the size
estimates and other project characteristics.
3. Should take into consideration project specific characteristics like SDLC
followed, skill level, requirements stability, process maturity of the
organization, automation during Software development.
4. Must be person independent
5. Must qualify the estimates with a certain degree of accuracy or tolerance.
6. Must support re-estimation at various phases of SDLC.

Direct method for Software sizing is Lines of code. The indirect method is
Function Points.
Lines of code is a technical measure as it measures the software from the
developer’s point of view and not from the user’s point of view. LOC as a measure
of the system size has various drawbacks.
A system’s LOC cannot be correctly known till the system is developed and LOC
estimates cannot be accurate till the design is complete for any system.
Expressing the size of a project in LOC at an early stage is almost impossible for
large systems.
LOC are more difficult to visualize in modern environments with interactive front
end development and auto generated code.

49111329.doc Page 13 of 61 12/8/2021

 The LOC approach is basically more a developers approach and end user can not
directly relate to it.

With the introduction of more complex systems, and use of visual languages with
the versions of system software changing so rapidly, in initial stages of SDLC
Function Point becomes a preferred method for estimation.

49111329.doc Page 14 of 61 12/8/2021

 3. Using Function Points

Function Points
Human beings solve problems by breaking them into smaller, understandable
pieces. Problems that may initially appear to be difficult are found to be simple
when dissected into their components, or classes. When the objects to be
classified are the contents of software systems, a set of definitions and rules, or a
scheme of classification, must be used to place these objects into their
appropriate categories. Function point analysis is one such technique: FPA is a
method to break systems into smaller components, so they can be better
understood and analyzed. It also provides a structured technique for problem
solving.
There are a variety of different methods used to count function point, like rules
developed by the Alan Albrecht and later revised by the International Function
Point User Group (IFPUG). Another method is Mark II Function Points developed
by Charles Symon. Feature points is another sizing method developed by Capers
Jones.

Definition

Function Point Analysis tries to understand the dynamic relationship between

transactions and data stores. On a conceptual level, function point analysis helps
define two abstract levels of data - data at rest and data in motion.

Data in motion
Data in motion is handled via transactional function types or transactions. All
software applications will have numerous elementary processes or independent
processes to move data. Transactions that bring data from outside the
application domain (or application boundary) to inside that application boundary
are referred to as external inputs. Transactions that take data from a resting

49111329.doc Page 15 of 61 12/8/2021

 position (normally on a file) to outside the application domain (or application
boundary) are referred as either an external outputs or external inquiries.

Data at rest
Applications store information for processing at a later time. Data at rest that is
maintained by the application in question is classified as internal logical files.
Data at rest that is maintained by another application are classified as external
interface files.

Uses of Function Points

1. Function points can be used to establish an inventory of all transactions
and files of a current project or application. This inventory can be used as
a means of evaluation of an application. If an inventory is conducted for a
development project or enhancement project, then this same inventory
could be used to help maintain scope creep and to help control project
growth. Even more important this inventory helps understand the
magnitude of the problem.

2. Function Points can be used to size software applications. Sizing is an

important component in determining productivity (outputs/inputs),
predicting effort, understanding unit cost, so on and so forth.

3. Unlike some other software metrics, different people can count function
points at different times, to obtain the same measure within a reasonable
margin of error. That is, the same conclusion will be drawn from the
results.

4. FPA can help organizations understand the unit cost of a software

application or project. Once unit cost is understood tools, languages,
platforms can be compared quantitatively instead of subjectively. This type
of analysis is much easier to understand than technical information. That
is, a non-technical user can easily understand Function Points.

49111329.doc Page 16 of 61 12/8/2021

 What FPA is unfit for
Performance tuning may or may not have anything to do with functionality.
Performance tuning is more a result of trying to understand application
throughput and processing time. There are better metrics to utilize when
measuring this type of work.

FPA is not useful to size Web Design. FPA is useful to size web development, but
not web design. FPA is concerned with the dynamic relationship between
transactions and files. FPA is not useful in estimating the time it will take to
create graphics, images, page layouts, so on and so forth.

Types of Function Point Counts

There are three different types of function point counts (Development,
Enhancement and Application).

Development Project Function Point Count

Function Points can be counted at all phases of a development project from
requirements up to and including implementation. This type of count is
associated with new development work. Scope creep can be tracked and
monitored by understanding the functional size at all phase of a project.
Frequently, this type of count is called a baseline function point count.

Enhancement Project Function Point Count

It is common to enhance software after it has been placed into production. This
type of function point count tries to size enhancement projects. All production
applications evolve over time. By tracking enhancement size and associated
costs a historical database for your organization can be built. Additionally, it is
important to understand how a Development project has changed over time.

49111329.doc Page 17 of 61 12/8/2021

 Application Function Point Count
Application counts are done on existing production applications. This “baseline
count” can be used with overall application metrics like total maintenance hours.
This metric can be used to track maintenance hours per function point. This is an
example of a normalized metric. It is not enough to examine only maintenance,
but one must examine the ratio of maintenance hours to size of the application to
get a true picture.

Function points and software metrics

In the process of striving for quality thru continuous process improvement,
various metrics are collected using FP for defining baselines for organisation. They
are also considered to be normalizing measure that allows for comparisons
among industry segments.
Common Software Measures are :

Type Metrics Measure

1. Productivity FP / Effort FP per person month
2. Responsiveness FP / Duration FP per calendar
month
3. Quality Defects / FP Defects Density
4. Business Costs / FP Cost per FP

Advantages of Function Points

Advantages of FP as seen by the users of this method are :
1. FP counts are independent of the technology (Operating system, language
and database), developer productivity and methodology used.
2. FP very strongly relates to the requirements gathered from the users
which are the foundation of any software development effort.
3. FP are simple to understand and can be used for scope and requirements
related discussions with the users.

49111329.doc Page 18 of 61 12/8/2021

 4. FP being independent of technology and productivity can be very
effectively used as a software metrics across diverse teams and
technologies.

Disadvantages of Function Points

1. FPAs are subjective in the areas of identification of RETs and ranking
GSCs.
2. According to FPA , by decomposing the functionality of the system and
analyzing each part, then totaling , the total reflects the whole system. It
ignores the integration aspects of combining smaller parts to form a bigger
system.
3. FPA doesnot give due importance to processing logic involving complex
algorithms and calculations.
4. FPA is insensitive to extremes since highest complexity measures remain
the same for very large number of items in that category.

49111329.doc Page 19 of 61 12/8/2021

 4. Counting Development Function Points

Diagrammatic Representation of FPA

User
Requirement
Specification

Identify Data Functions Identify Transaction

Determine Complexity Functions
thru DETs and RETs Determine Complexity
thru DETs, FTRs
Internal Logical Files External Input
External Interface Files External Output
External Enquiry

Compute Unadjusted Function Points (UFP)

Rate on 14 General System Characteristics

Compute Value Adjustment factor (VAF)

Compute Adjusted Function Points (AFP)

It I necessary to establish the boundary or scope of the application to begin with.

In the first two steps based on URS, we identify the various functions in the
system. From the FPA point of view, functions could be either data functions or
transaction functions. Only user requested and user identifiable functions are
identified.

49111329.doc Page 20 of 61 12/8/2021

 The documentations referred to for identifying the scope of the application include
:
 System Specification Documents
 Interface Documents
 Interviews with the users
 User Documentation
 Design Documentation
 Requirements
 Data flow diagrams
 Business flow diagrams

The total process used to size Function Points can be summarized by the following
seven steps :
1. Determine the type of function point
2. Identify Application Boundary
3. Identify all Data Functions and their complexity
4. Identify all transaction functions and their complexity
5. Determine the unadjusted function point count
6. Determine the value adjustment factor
7. Calculate the final FP count.

Technology Issues:

Internet/Intranet Applications
The boundary for an Internet/Intranet application is defined in a similar way for
traditional applications.  For traditional applications the boundary is not drawn
just around the user interface or a group of screens but around the entire
application.  Frequently, Internet/Intranet applications are just extensions to
current and existing applications.  

Client/Server
The boundaries for client/server applications need to be drawn around both the
client and server. The reason is that neither the client nor server supports a
users (or sophisticated) view. That is, one alone does not represent a total

49111329.doc Page 21 of 61 12/8/2021

 application. A complete application needs both data at rest (server) and data in
motion (client).

FPA Steps for Data Functions:

F1.Application documentation
and file rules are used to
FPA for Files
Application Documentation
identify files. F1. Identify Files
Transaction Model

Data Model
F2. Type of File(ILF or EIF)
F2. The application
documentation (transaction FPA Rules
F3. Number of DETs and RETs

model and data model) is

File Rules F4. Determine Low, Ave, High
used to determine type of
transaction (either external F5. Values Determined
Functional Complexity

interface file or internal F6. All Files are summed to

Tables of Weight obtain UFP for Files.
logical file).

F3. With the help of application documentation (data model) and file rules the
number data elements and record element types are determined.

F4. Each identified file is assigned a value of low, average or high based upon
type, data elements and record types.

F5. A distinct numerical value is assigned based upon type and value (low,
average, or high).

F6. All files are summed to create a file unadjusted function point count.

Data function types represent functionality provided to the user to meet internal
and external data requirements. Internal Logical Files (ILF) and External Interface
Files (EIF) are the two data function types.

49111329.doc Page 22 of 61 12/8/2021

 To determine the complexity of ILFs and EIFs, the number of Data Element Types
(DETs) and Record Element Types (RETs) in each ILF and EIF are identified. A
DET is a user recognizable unique and non-recursive field. (also called Column,
Attribute, Data Field) in the ILF/EIF. A user recognizable sub-group of DETs within
an ILF/EIF is a RET (also called data structure, logical group of fields).
While identifying RETs look for a group of :
1. DETs which are typically updated at the same time
2. DETs that are of interest to different departments in user organization
3. DETs that are repeating groups
4. DETs that describe a sub-entity.

49111329.doc Page 23 of 61 12/8/2021

 Internal Logical Files
An ILF is a group of information stored in the system and maintained by the
system. It should be a user identifiable group. An ILF is a logical grouping of the
data or control information that is stored in the system, used within it and
maintained by it. The user may use it for generating outputs, or in inquiries or
process it using External Inputs.

An ILF should have at least one external output and/or external inquiry. That is,
at least one external output and/or external inquiry should include the ILF as an
FTR. Simply put, information is stored in an ILF, so it can be used later. The EO
or EQ could be from another application.

Rating:
Like all components, ILF’s are rated and valued. The rating is based upon the
number of data elements (DET’s) and the record types (RET’s). The table below
lists both the level (low, average or high) and appropriate value (7, 10 or 15).

Record Element Types Data Elements

(RET)
1 to 19 20 - 50 51 or More
1 RET Low (7) Low(7) Average (10)
2 to 5 RET Low (7) Average (10) High (15)
6 or More RET Average High (15) High (15)
(10)

Standard Documentation:
 Table Layouts
 Database descriptions
 Logical data models
 Field sizes and formats
 Design Documentation
 Functional Specifications

49111329.doc Page 24 of 61 12/8/2021

  User Requirements

49111329.doc Page 25 of 61 12/8/2021

 External Interface Files

An EIF is a unique file that is shared between the system and some external
application(s). It is a user identifiable logical group of data referenced by the
system but not maintained by it.
The data resides entirely outside the application boundary and is maintained by
another applications external inputs. The external interface file is an internal
logical file for another application.

Each EIF included must have at least one transaction, external input, external
output or external inquiry against it. In other words there must at least one
transaction that includes the EIF as a FTR. If the EIF does not have one
transaction, then one must wonder what is the purpose of the EIF and how was
the information retrieved.

Only count the part of the file that is used by the application being counted not
the entire file. The internal logical file, of another application, that you access
may have a large amount of DET’s and RET’s, but only consider the DET’s and/or
RET’s that are used when rating an EIF.

Rating

The table below lists both the level (low, average or high) and appropriate value
(5, 7 or 10 unadjusted function points).

Record Element Types Data Elements

(RET)
1 to 19 20 - 50 51 or More
1 RET Low (5) Low(5) Average (7)
2 to 5 RET Low (5) Average (7) High (10)
6 or More RET Average (7) High (10) High (10)

49111329.doc Page 26 of 61 12/8/2021

 Standard Documentation:

 Table Layouts
 Interface Diagrams
 Database descriptions
 Logical data models
 Field sizes and formats
 Design Documentation
 Functional Specifications
 User Requirements

49111329.doc Page 27 of 61 12/8/2021

 Unadjusted Function Points for Data functions
At the end of this step, the ILF and EIF tables should be filled up.

Unadjusted Function Point Calculation

Internal Logical Files

Sr. No. Name #RETs #DETs Complexity level (Tick one) UFPs
Simple Average Complex
of ILF

Total ILF UFPs

Unadjusted Function Point Calculation

External Interface Files

Sr. No. Name #RETs #DETs Complexity level (Tick one) UFPs
Simple Average Complex
of EIF

Total EIF UFPs

49111329.doc Page 28 of 61 12/8/2021

 FPA Steps for Transactional Function Types:
Each transaction must be an elementary process. An elementary process is the
smallest unit of activity that is meaningful to the end user in the business. It
must be self-contained and leave the business in consistent state.

T1. Application
documentation and transaction
rules are used to identify
transactions.

T2. The application

documentation and
transaction rules are used to
determine type of
transaction (external input,
external output, or external
inquiry).

T3. With the help of application documentation (data model and transaction
model) and transaction rules the number data elements and file type referenced
are determined.

T4. Each identified transaction is assigned a value of low, average or high based
upon type, data elements, and files referenced.

T5. A distinct numerical value is assigned based upon type and value (low,
average, or high).

T6. All transactions are summed to create a transaction unadjusted function

point count.

49111329.doc Page 29 of 61 12/8/2021

 Transaction function types represent the functionality provided to the user to
process data by the application and comprise External Inputs(EI), External
Outputs(EO), and External Inquiries(EQ).

The complexities of EI,EO and EQ are determined by the number of Data Element
Types (DETs) and File Types Referenced (FTRs).

Examples of DET :
External Inputs: Data Input Fields, Error Messages, Calculated Values, Buttons
External Outputs: Data Fields on a Report, Calculated Values, Error Messages,
and Column Headings that are read from an ILF or EIF. Like an EQ and EO can
have an input side and output sides.
External Inquiries: Input Side - field used to search by, the click of the mouse.
Output side - displayed fields on a screen. DET’s for an EQ must come from
either an EIF or ILF.

DET’s for GUI

Using the strict definition of a data element provided by IFPUG’s Counting
Practices Manual. “A data element is a user recognizable, non recursive field.” In
GUI applications, a data element is information that is stored on an internal
logical file or that is used to invoke a transaction.

Radio Buttons
Radio Buttons are treated as data element types. Within a group of, a frame,
radio buttons the user has the option of selecting only one radio button; so only
one data element type is counted for all the radio buttons contained in the frame.

Check Boxes
Check Boxes differ from radio buttons in that more than one check box can be
selected at a time. Each check box, within a frame, that can be selected should
be treated as a data element.

49111329.doc Page 30 of 61 12/8/2021

 Command Buttons
Command buttons may specify an add, change, delete or inquire
action. A button, like OK, may invoke several different types of
transactions.

According to IFPUG counting rules each command button would be counted as a

data element for the action it invokes. In practice this data element will not
impact the rating of the transaction, but it does help understand and dissect a
screen full of transactions.

A button like next may actually be the input side of an

inquiry or another transaction.

For example, a simple application to track distributors could have fields for
Distributor Name, Address, City, State, Zip, Phone Number, and Fax Number.
This would represent seven fields or (seven data elements) and the add
command button would represent the eighth data element. In short, the “add”
external input represents a one external input with eight data elements, the
“change” external input represents another external input with eight (seven data
elements plus the “change” command button), and the “delete” external input
represents the last external input with eight data elements (seven fields plus the
“delete” command button).

Display of Graphical Images or Icons

A display of a graphical image is simply another data element. An inventory
application, for example, may contain data about parts. It may contain part
name, supplier, size, and weight and include a schematic image of the part. This
schematic is treated as a single data element.

Sound Bytes
Many GUI applications have a sound byte attached. This represents one data
element. The number of notes played is simply recursive information. If the
length of the sound byte increases, then the data element remains one. For
example, you can play the “Star Spangled Banner” for two seconds or four

49111329.doc Page 31 of 61 12/8/2021

 seconds, but you’ll still count the sound bytes as one data element. The longer it
is played the more recursive information it has.

Photographic Images
A photographic image is another data element, and is counted as one. A human
resource application may display employee name, start date, etc. and a
photograph of the employee. The photograph is treated the same as employee
name or employee start date. The photograph is stored and maintained like any
other piece of information about the employee.

Messages
There are three types of messages that are generated in a GUI application: error
messages, confirmation messages and notification messages. Error messages and
confirmation messages indicate that an error has occurred or that a process will be or have
been completed. They are not an elementary or independent process alone, but they are
part of another elementary process. A message that would state, “zip code is required”
would be an example of an error message. A message that would state, “are you sure you
want to delete customer” is an example of a confirmation message. Neither type of
message is treated as a unique external output, but each is treated as a data element for
the appropriate transaction.

On the other hand, a notification messages is a business type message. A

notification is an elementary process, has some meaning to the business user and
is independent of other elementary processes. It is the basis of processing and a
conclusion being drawn. For example, you may try to withdraw from an ATM
machine more money than you have in your account and you receive the dreaded
message, “You have insufficient funds to cover this transaction.” This is the
result of information being read from a file regarding your current balance and a
conclusion being drawn. A notification message is treated as an External Output.

49111329.doc Page 32 of 61 12/8/2021

 External Input
An external input is to be counted for each instance where:
1. the input crosses the external boundary to come into the system
2. it causes some change in the data of the system

An external input has to be unique and not just an extension. If all the fields of a
business transaction cannot fit on one screen and therefore split into two screens,
the two screens count as a single External Input.
EIs may be input to the system through data entry screens, or input in terms of a
electronic files created by some other system.

An EI may reference ILFs (read or insert or update or delete) and EIFs (read
only). An FTR is counted for each ILF maintained by an EI. An FTR is counted for
each ILF or EIF read while processing an EI. A file that is both read and
maintained by the same EI is counted as one FTR for that EI. For example, an
External Input may update an internal logical file, but must also reference a
“security file” to make sure that the user has appropriate security levels. This
would be an example of two FTR’s.

DET is counted as a user recognizable unique and non-recursive field that is

maintained on an ILF by an EI.

Data Elements:
Unique sets of data elements help distinguish external input from other external
input. It is the set of DET’s combined that create the elementary process called
an EI. The following are examples of DET’s.

 Data Input Fields

 Calculated Values that are stored
 Error Messages
 Confirmation Messages
 Recursive fields are only counted as one DET.
 Action keys (command buttons such as OK, Next, so on and so forth)

49111329.doc Page 33 of 61 12/8/2021

  Multiple Action Keys that perform the same function are counted only as one
DET

Rating:
Like all components, EI’s are rated and valued. The rating is based upon the
number of data element types (DET’s) and the file types referenced (FTR’s).
The table below lists both the level (low, average or high) and appropriate value
(3, 4 or 6 unadjusted function points).

Files Type Referenced Data Elements

(FTR)
1-4 5-15 Greater than
15
Less than 2 Low (3) Low (3) Average (4)
2 Low (3) Average (4) High (6)
Greater than 2 Average (4) High (6) High (6)

Standard Documentation:
A good source of information to determine external inputs is Screen Layouts,
Screen Formats & dialogs, and layouts of any input forms. Additional inputs from
other applications should be inventoried here. Inputs from other applications
must update internal logical files of the application being counted.
 Screen Layouts
 Screen Dialogs
 Design Documentation
 Functional Specifications
 User Requirements
 Any Input Forms
 Context Diagrams
 Data Flow Diagrams

49111329.doc Page 34 of 61 12/8/2021

 The following words are associated with external input or “inputs.” While reading
textual document or application description look for these type of words, they
may indicate an add, change or delete aspect of an external input.

Add Modify (change)

Activate Override (change)
Amend (change and delete) Post (add, change and delete)
Cancel Remove (delete)
Change Reactivate (change)
Convert (change) Remit
Create (add) Replace (change)
Delete Revise (change and delete)
Deassign Save (add, change or delete)
Disable Store (add)
Disconnect (change or delete) Suspend (change or delete)
Enable Submit (add, change or delete)
Edit (change) Update (add, change or delete)
Insert ( add and change) Voids (change and delete)
Maintain (add, change, or delete)
Memorize (add)

49111329.doc Page 35 of 61 12/8/2021

 External Output
Typically, reports would be identified as External Outputs.
An External output is to be counted for each instance where :
1. the data crosses the external boundary to leave the system
2. it requires some processing in the system

External Outputs (EO) - an elementary process in which derived data passes

across the boundary from inside to outside. Additionally, an EO may update an
ILF. The data creates reports or output files sent to other applications. These
reports and files are created from information contained in one or more internal
logical files and external interface files.

Derived Data is data that is processed beyond direct retrieval and editing of
information from internal logical files or external interface files. Derived data is
usually the result of algorithms, or calculations. Derived data occurs when one
or more data elements are combined with a formula to generate or derive an
additional data element(s). This derived data does not appear in any FTR
(internal logical file or external interface file).

The definition states that an EO contains information, which derived data passes
across the boundary from inside to outside. Some confusion may arise because
an EO has an input side. The confusion is the definition reads data passes across
the boundary from inside to outside. The input side of an EO is search criteria,
parameters, etc does not maintain an ILF. The information that a cross from
outside to inside (input side) is not permanent data, but it is transient data. The
intent of the information coming from outside the application (input side) is not to
maintain an ILF.

Notification Messages are considered EO’s. A notification message differs from an

error message. A notification message is an elementary process, while an error
message (or confirmation message) is part of an elementary process. A
notification message is the result of some business logic processing. For

49111329.doc Page 36 of 61 12/8/2021

 example, a trading application may notify a broker that the customer trying to
place an order does not have adequate funds in their account.

Derived Data displayed in textual fashion (rows and columns) and graphical
format is an example of two external outputs.

Data Elements:
Unique sets of data elements help distinguish one external output from another.
Keep in mind that a DET is something that is dynamic not a static field (A DET is
a unique user recognizable, non-recursive (non-repetitive) field).
 Error Messages
 Confirmation Messages
 Calculated Values (derived data)
 Values on reports that are read from an internal logical file or external
interface file.
 Recursive values or fields (count only once)
 Generally, do not count report headings (literals) as data elements unless
they are dynamic. That is, if the report headings are read from files that are
maintained they may be DET’s also.
 System generated dates that are on the tops or reports or are displayed are
normally not counted as DET’s. If system generated dates are part of
business information of the external output they should be counted as DET’s.
For example, the date an invoice is printed or the date a check is printed.

Unique FTR’s help distinguish one external output from another. An FTR must be
either an Internal Logical File and/or External Interface File. Each EO must have
at least one FTR (either ILF or EIF). If the EO does not reference at least one
FTR, then where did the information (DET’s) come from?

The elementary process associated with an external output may update an

internal logical file or external interface file. For example, the elementary process
that produces a payroll check may include an update to a file to set a flag to
indicate that the payroll check was produced. This is not the same as
maintaining the file. Maintained is the process of modifying data (adding,

49111329.doc Page 37 of 61 12/8/2021

 changed and deleting) via an elementary process (via an External Input). The
primary intent of an EO is not to maintain an ILF.

Rating:
Like all components, EO’s are rated and valued. The rating is based upon the
number of data elements (DET’s) and the file types referenced (FTR’s). The
rating is based upon the total number of unique (combined unique input and
out sides) data elements (DET’s) and the file types referenced (FTR’s) (combined
unique input and output sides). DET’s and FTR’s were discussed earlier. The
table below lists both the level (low, average or high) and appropriate value (4, 5
or 7 unadjusted function points).

File Types Referenced Data Elements

(FTR)
1-5 6-19 Greater than
19
less than 2 Low (4) Low (4) Average (5)
2 or 3 Low (4) Average (5) High (7)
Greater than 3 Average (5) High (7) High (7)

Standard Documentation:
 Report Layouts
 Design Documentation
 Functional Specifications
 User Requirements
 Database descriptions
 Field Sizes and Formats
 Graphical Report Layouts

The following words are associated with an “external outputs.” While reading
textual documents or application descriptions look for these types of words. They
may indicate an external output.

Browse Reports

49111329.doc Page 38 of 61 12/8/2021

 Display Request
Get Retrieve
On-lines Seek
Output Select
Print View
Query

49111329.doc Page 39 of 61 12/8/2021

 External Inquiries
EQ is a unique combination of an input and an output where the input causes the
immediate generation of the output. An EQ implies data retrieval.
EQ implies
1. no change is made to any internal data
2. the processing and output generation resulting from the input is
immediate.

External Inquiry (EQ) - an elementary process with both input and output
components that result in data retrieval from one or more internal logical files
and external interface files. The input process does not update or maintain any
FTR’s (Internal Logical Files or External Interface Files) and the output side does
not contain derived data.
There are a lot of commonalities between an EO and EQ. Both have input and
output sides, but an EQ cannot have derived data. An EQ cannot update an ILF.
An EQ is basically a read from a FTR

Data Elements:
Unique sets of data elements help to distinguish one external inquiry from
another external inquiry.

 Input Side
 Click of a the mouse
 Search values
 Action keys (command buttons)
 Error Messages
 Confirmation Messages (searching)
 Clicking on the an action key
 Scrolling
 Recursive fields are counted only once.
 Outside
 Values read from an internal logical file or external interface file

49111329.doc Page 40 of 61 12/8/2021

  Color or Font changes on the screen
 Error Messages
 Confirmation Messages
 Recursive fields are counted only once.
 The combined (unique) total input and outside DET’s are used when rating
EQ’s.

Like an EI, action keys that perform the same function but appear multiple times
are counted as only one DET.

Error Messages and confirmation messages can and do occur on either the input
side and/or output side. If a user initiates a search and a message is displayed,
“please wait searching” is an example of a confirmation message on the input
side. The message “all fields must be populated” is another example of an
error message on the input side. On the other hand, if the message is
“customer not found” is an example of an error message on the output side.
That is, the input side contained no problems. The database was searched and
the “error” has occurred on the output side of the transaction.

Unique FTR’s help distinguish one external inquiry from another external inquiry.
Every EQ must have at least one associated FTR (either ILF or EIF). If the EQ
does not have an associated FTR, then where did the information (DET’s that
appear on the EQ) come from?

Both the input side and output side must be considered when evaluating the
FTR’s used by an external inquiry. Normally they are the same but there are
instances where they may not be the same. The combined total should be used
when evaluating an EQ. For example, a security check may be done on the input
side of an external inquiry. The security check is done to make sure the user of
the application has the appropriate level of authority to view the data.

49111329.doc Page 41 of 61 12/8/2021

 Rating:
Like all components, EQ’s are rated and valued. Basically, an EQ is rated (Low,
Average or High) like an EO, but assigned a value like and EI. The rating is
based upon the total number of unique (combined unique input and out sides)
data elements (DET’s) and the file types referenced (FTR’s) (combined unique
input and output sides). If the same FTR is used on both the input and output
side, then it is counted only one time. If the same DET is used on both the input
and output side, then it is only counted one time.

Functional rating table (shared table between EO and EQ)

File Types Referenced Data Elements
(FTR)
1-5 6-19 Greater than
19
less than 2 Low (3) Low (3) Average (4)
2 or 3 Low (3) Average (4) High (6)
Greater than 3 Average (4) High (6) High (6)

EQ’s can contain business data, control data and rules based data.

Business Applications: An example of Business data is customer names,

addresses, phone number, so on and so forth. An example of Rules Data is a
table entry that tells how many days a customer can be late before they are
turned over for collection.
Drop Down List (a listing of customers by name) would be an example of an EQ.
A screen full of customer address information would be an example of an EQ.

Standard Documentation:
 Screen Layouts
 Design Documentation
 Functional Specifications
 Table Layouts
 User Requirements
 Database descriptions

49111329.doc Page 42 of 61 12/8/2021

  Pick lists
 Field sizes and formats

The following words are associated with an “external inquiry.” While reading
textual document or application description look for these type of words. They
may indicate an external inquiry.
Browse Query
Display Scan
Extract Seek
Fetch Select
Find Show
Get View
Drop Down Reports
Lists
Look Ups
On-lines
Output
Pick Lists
Print

49111329.doc Page 43 of 61 12/8/2021

 Unadjusted Function Points for Transaction functions
At the end of this step, the EI,EO and EQ tables should be filled up.

Unadjusted Function Point Calculation

External Inputs(EIs)

Sr. No. Name #FTRs #DETs Complexity level (Tick one) UFPs
Simple Average Complex
of EI

Total EI UFPs

Unadjusted Function Point Calculation

External Output (EO)

Sr. No. Name #FTRs #DETs Complexity level (Tick one) UFPs
Simple Average Complex
of EO

Total EO UFPs

Unadjusted Function Point Calculation

49111329.doc Page 44 of 61 12/8/2021

 External Inquries (EQ)

Sr. No. Name #FTRs #DETs Complexity level (Tick one) UFPs
Simple Average Complex
of EQ

Total EQ UFPs

49111329.doc Page 45 of 61 12/8/2021

 Compute Unadjusted Function Points
The unadjusted function points for the system is calculated as follows :

UFP = UFPEI + UFPEO+ UFPEQ + UFPILF + UFPEIF

Rate on 14 General System Characteristics

Describe and define the concepts necessary to rate the General System
Characteristics (GSC’s) to determine the overall Value Adjustment Factor (VAF).
Multiplying the VAF by the unadjusted function point count equals the “adjusted
function point count.” Up to this point in time only the unadjusted function point
count has been discussed.

Definition:
The value adjustment factor (VAF) is based on 14 general system characteristics
(GSC’s) that rate the general functionality of the application being counted. Each
characteristic has associated descriptions that help determine the degrees of
influence of the characteristics.

Rating:
The degrees of influence range on a scale of zero to five, from no influence to
strong influence. Each characteristic is assigned the rating based upon detail
descriptions provided by the IFPUG 4.1 Manual. The ratings are:

0 Not present, or no influence

1 Incidental influence
2 Moderate influence
3 Average influence
4 Significant influence
5 Strong influence throughout

49111329.doc Page 46 of 61 12/8/2021

 Tabulating:
Once all the 14 GSC’s have been answered, they should be tabulated using the
IFPUG Value Adjustment Equation (VAF) --

14
VAF = 0.65 + [( å Ci) / 100]
i =1
where: Ci = degree of influence for each General System Characteristic
. i = is from 1 to 14 representing each GSC.
å = is summation of all 14 GSC’s.

GSC’s at a Glance:

General System Brief Description

Characteristic
1. Data communications How many communication facilities are there to
aid in the transfer or exchange of information
with the application or system?
2. Distributed data How are distributed data and processing
processing functions handled?
3. Performance Did the user require response time or
throughput?
4. Heavily used How heavily used is the current hardware
configuration platform where the application will be
executed?
5. Transaction rate How frequently are transactions executed daily,
weekly, monthly, etc.?
6. On-Line data entry What percentage of the information is entered
On-Line?
7. End-user efficiency Was the application designed for end-user
efficiency?
8. On-Line update How many ILF’s are updated by On-Line
transaction?
9. Complex processing Does the application have extensive logical or
mathematical processing?
10. Reusability Was the application developed to meet one or
many user’s needs?

49111329.doc Page 47 of 61 12/8/2021

 11. Installation ease How difficult is conversion and installation?
12. Operational ease How effective and/or automated are start-up,
back up, and recovery procedures?
13. Multiple sites Was the application specifically designed,
developed, and supported to be installed at
multiple sites for multiple organizations?
14. Facilitate change Was the application specifically designed,
developed, and supported to facilitate change?

Considerations for GUI Applications

GSC items such as Transaction Rates, End User Efficiency, On Line Update, and Reusability
usually value higher for GUI applications than on traditional applications. On the other
hand, Performance, Heavily used configuration, multiple sites, will value lower for GUI
applications than traditional applications.

49111329.doc Page 48 of 61 12/8/2021

 Compute the Adjusted Function Points
For a development project, the function point count is computed as

AFP = UFP x VAF

Where,
AFP = Adjusted Function Point
UFP = Unadjusted function point
VAF = Value Adjustment Factor

Function Point Calculation Summary is then prepared as follows :

Function Point Calculation Summary

VAF =
Function Type # of Functions UFPs AFP = UFP x VAF
Internal Logical Files (ILF)
External Interface Files
Sub-Total for Data
Functions
External Input
External Output
External Inquiry
Sub-total for Transaction
functions
Total for System

49111329.doc Page 49 of 61 12/8/2021

 5. Other Function Points Extensions

Mark II method
This method was developed by Mr. Charles Symons in 1988.
Mark II treats the system as a collection of logical transactions, where a logical
transaction is triggered by a unique event. Each logical transaction consists of
 Input across the boundary (input data elements)
 Processing involving stores data within the boundary (number of entities
referred)
 Output back across the boundary (output data elements)
Each logical transaction is computed as :
Weight for input elements (Wi) x Number of input data elements
+ Weight for entities referenced (We) x Number of entities referenced
+ Weight for output elements (Wo) x Number of output data elements

For Version 1.3 of the model ,

Wi = 0.58, We = 1.66, Wo = 0.26

Sum this for all logical transactions to get MkII Function Point Index.

Six more GSC are defined viz.

15. Requirements of other applications
16. Security, Privacy and Auditability
17. User training
18. Direct use by third parties
19. Documentation

Using these 19 GSCs, degree of influence is calculated.

To compute Adjusted MkII Function Point , Technology Complexity Adjustment

(TCA) is calculated.
TCA = 0.65 + C * (sum of degree of influence for the characteristics)
Where C = 0.005.

49111329.doc Page 50 of 61 12/8/2021

 Adjusted MkII Function Point = MkII FPI * TCA.

Feature Points
The feature point method is a superset of the function point method. It is used
widely for scientific systems.
It makes use of an additional component , Algorithms , adding to the set of the
five FP components. The algorithm component is assigned a weighted value of 3.
When using this method, IFPUG values attached to internal files are reduced.

Object Points
In the object point model, the term object is used for objects like screens, reports
and 3GL componenets.
Screens are classified on the number of views and sources while reports are
classified based on the number of sections and sources. Weight are used for all
three types to determine the total object point count.

Once the object points are obtained, the percentage reuse is estimated.
Depending on the percentage reuse, the New object points (NOP) are computed
next.

NOP = (Object points) x (100- %reuse) / 100

This model closely works with COCOMO II model of effort estimation.

49111329.doc Page 51 of 61 12/8/2021

 6. Effort, Cost, Schedule Estimates
Once the software size is known, the next step in estimation process is to
determine the effort it will take to make the software and the calendar time that
is required to complete the project. To determine the effort required, productivity
of the organization is required to be known.

Productivity
The definition of productivity is the output-input ratio within a time period with
due consideration for quality.

Productivity = outputs/inputs (within a time period, quality considered)

The formula indicates that productivity can be improved by (1) by increasing

outputs with the same inputs, (2) by decreasing inputs but maintaining the same
outputs, or (3) by increasing outputs and decreasing inputs change the ratio
favorably.

The output of a software project is functionality or function points. The input is

the effort required to develop the functionality.

Software Productivity = Function Points / Effort of project team

Many organizations over the years build up productivity rates for Function Points
per person month/person day for the various development environments they
work on and then use these productivity figures from effort estimation. Many
research organizations like Software Productivity Research publish productivity
figures for the use by software industry.

49111329.doc Page 52 of 61 12/8/2021

 Factors impacting Productivity

Size and Effort

Data from many projects has shown that productivity and size are inversally
proportional to each other. As the size of the software increases, the number of
components of the software and the interfaces among these components also
increase. Thereby, affecting the productivity adversely.

Schedule and effort

Schedule is estimated by assuming a team size and dividing the estimated effort
by the assumed team size. The basic principle is man and months are not
interchangeable. As the team size grows, communication channels increase
thereby generating more noise between knowledge transfer.
Also, software activities require specific skills hence the tasks are not
interchangeable easily.

Quality Versus Effort and Schedule

If high quality software is desired, then the software engineering process followed
to build the software needs to be more systematic & rigorous. That means :
1. A higher effort and longer schedule is required to incorporate the quality
related activities like reviews, testing which are required to produce high
quality software.
2. A undue reduction in effort and schedule will result in poorer quality of
software. This is due to less time allotted to the quality activities to
manage the schedule for completing life cycle activities.

Other Factors
In addition to above factors, following are some of the factors which also have
significant impact on the productivity.
1. Availability and stability of development environment
2. Team skill, capability and experience
3. Process maturity
4. Employee turnover
5. Software reusability etc.

49111329.doc Page 53 of 61 12/8/2021

 So, any estimation model we select must take into consideration
1. inversely proportionate relationship between size & effort
2. impact of schedule underestimation on productivity
3. expected software quality attributes
4. impact of other factors on productivity

Approach to Effort and schedule Estimation

Bottom-up estimation technique takes the realm of Project planning. The project
is broken into smaller activities and tasks. An effort is made for each lower level
task. The effort estimates of all low level tasks are added to give estimate for the
phase and the project.

Work Breakdown Structure(WBS)

The WBS becomes the basis for bottom-up estimation approach. While
constructing the software WBS, there are two hierarchies to consider.
1. Product hierarchy
2. Process hierarchy

The process used to build WBS is iterative. The WBS gives us the tasks that need
to be estimated and scheduled. Effectiveness of WBS depends on the
completeness of the task list. Apart from the normal project activities and
components, one should include
1. Preparation and review of documents activity
2. Project planning and tracking
3. Client interactions
4. Project specific training

Having obtained this task list, each task is then estimated. The inter task
interdependencies are next understood using techniques like PERT-CPM and
schedule is made taking into account the effort required for the task and
dependencies between tasks.

49111329.doc Page 54 of 61 12/8/2021

 Cost Estimation

Understanding Different Costs:

A fixed cost is a cost that remains constant, in total, regardless of changes in
activity. Consequently as the activity rises or falls fixed costs remain constant.
The capital expenditure on PC’s for a software project is considered a fixed cost.
Salaries paid to software develops can be treated as fixed costs for the
organization because the salaries remain constant and must be paid regardless of
productivity levels. A variable cost is a cost that varies, in total, in direct
proportion to changes in the level of activity. The activity can be expressed in
many ways such as number of hours. Software metrics are concerned with
project costs and not overall organizational costs. Hence software development
has very low fixed costs, but very high variable costs.

Overhead costs are those cost that cannot be directly attributed to a particular
software project. For example, the cost to keep the LAN up in running is an
overhead cost. Executive salaries would be another example of overhead costs
since their salaries cannot be attributed to a specific project.

Average cost is total cost divided by to number of units produced. Total costs
for a project divided by the number of function points gives us the dollars per
function point. Average hours are the total number of hours divided by the total
number of function points, which yields hours per function point. Marginal cost
is the change in total cost attributable to a one-unit change in output. Another
characteristic is that as software projects become large marginal cost goes up.
That means that unit costs rises as software projects become larger. There are
not many economies of scale with the development of software.

When software projects are estimated all direct and indirect costs need to be
included in the cost of the software project. Direct materials are those materials
that are directly related to the development of a software project. Indirect
materials are those materials that are not directly related to the cost of the

49111329.doc Page 55 of 61 12/8/2021

 software development project. An example of indirect costs is the cost to run and
maintain an internal network. Direct labor is labor costs that can be traced to an
individual task associated with the development, maintenance or enhancement of
a software product. Indirect labor cannot be traced to a specific task associated
with the software project.

Cost Estimation Sheet

Component Item Quantity in Rate/ Cost Remarks

person- Person-day
days
Personnel Programmer/Tester
Resources
Analyst/Designer
Project Leader
Project Manager
Quality team
Hardware
Software
Communication
Travel & Stay
Project team
training
Other items External
Consultant
Recruitment
Books/magazines
Conveyance

Subtotal
Add Buffer
Total

49111329.doc Page 56 of 61 12/8/2021

 7. Making the estimation process effective
Organisations process maturity governs the effectiveness and maturity with which
they handle estimation. Typically, organizations at level 1 of maturity start with
little or no procedures for estimation. With more experience and project
difficulties, the need to have better processes for estimation is felt and the
processes are established and improved.

Estimation Process improvement

Improvement of estimation process has three dimentions :
1. Estimates calculation
This covers estimating size, effort, cost and schedule and reviewing these
estimates in a project at the project initiation phase.
2. Monitoring and tracking estimates
This covers the monitoring and tracking estimates as the project
progresses and take action. Metrics collected on size, effort and schedule
variance thru project status reports and milestone reports.
3. Estimation process establishment
This includes setting up of consistent estimation processes, measuring the
capability of these processes, re-using data from estimation database,
bringing in new technology into the estimation process and managing
changes to the process in a controlled manner.

The process of estimation can be made more effective as follows :

1. Active participation of Sr. Management thru reviews of estimation related
activities for process compliance.
2. Independent SQA group reviews estimation related activities for process
compliance.
3. Identification of person responsible for estimation, for tracking the actual
data against planned and for re-estimation.
4. Tools required to facilitate estimation, to track actual data and to re-
estimate are explicitly defined, made available and used.

49111329.doc Page 57 of 61 12/8/2021

 5. Persons performing estimation and its tracking are trained in the
application domain and the estimation process.
6. Tools and resources are made available to be able to maintain up-to-date
database of the past projects that is used for estimation.

A high maturity estimation process

Process improvement

Estimation Processes
Procedures, Templates,
Organisationwide
Guidelines, Checklists,
Database of projects
Tools/methods

Size Estimation
Monitoring and tracking
Effort Estimation Estimate
estimates thru Project
Schedule Estimation
status meetings
Cost Estimation

Database for Estimation

To have the effective estimation done, past project data and statistics are of
immense help. The database used for estimation could be :
1. Industry-wide database of completed software projects

49111329.doc Page 58 of 61 12/8/2021

 2. Database of organisation’s own completed projects

Database Contents
Following is the type of data an organization should build to develop organization-
wide database of completed projects. This data is gathered by projects during the
project tracking and also at the project closure.
1. Project Application domain
2. Project deliverables
3. Project life cycles and phases
4. Project development platform
5. Project Size (estimated and actual)
6. Project effort (estimated and actual)
7. Project schedule (estimated and actual)
8. Project Characteristics (GSM related)
9. Project task breakdown
10. Project development approach
11. Risk related information
12. Quality related data

Estimation Tools
Tool Website
Function Point Workbench www.spr.com
PQMPlus www.uptweb.com
Function Point Manager www.abtcorp.com

49111329.doc Page 59 of 61 12/8/2021

 8. Industry Resources

Brief History:
Function Point Analysis was developed first by Allan J. Albrecht in the mid 1970s.
It was an attempt to overcome difficulties associated with lines of code as a
measure of software size, and to assist in developing a mechanism to predict
effort associated with software development. The method was first published in
1979, then later in 1983. In 1984 Albrecht refined the method and since 1986,
when the International Function Point User Group (IFPUG) was set up, several
versions of the Function Point Counting Practices Manual have been published by
IFPUG.

Growth and Acceptance of Function Point Analysis

The acceptance of Function Point Analysis continues to grow. This is indicated by
the growth of the International Function Point User Group (IFPUG). Since 1987
membership in IFPUG has grown from 100 members to nearly 600 members in
1997. Additionally, in less than six years conference attendance has grown from
125 in 1988 to over 300 by 1997. Examination of IFPUG clearly indicates that the
majority of its is members are from North America, but Function Point analysis
growth outside North America is strong. This is evident by the growing number
of function point organizations worldwide. There are numerous affiliate
organizations of IFPUG. There are affiliate organizations in Italy, France,
Germany, Austria, India, The Netherlands, Australia, Japan, and several other
countries.

More Information about IFPUG:

More information about joining IFPUG, conferences, committees can be obtained
by contacting the IFPUG.
Website: www.IFPUG.Org
Email: [email protected]

49111329.doc Page 60 of 61 12/8/2021

 Weblinks
www.softwareMetrics.com
www.qaiindia.com
www.iso.ch
www.sei.cmu.edu
www.isbsg.org.au (Benchmarking)

This document takes the inputs from FPA counting manual by IFPUG.

49111329.doc Page 61 of 61 12/8/2021