Estimating project effort on the base of Early

Function Points (EFP) method.

? Method overview
The Function Points method is a method for estimating effort of developing software
projects. The method is adjusted mainly for estimating effort of developing user
interfaces. The method essence can be described as follows.

The EFP method is based on identifying software objects at different levels of detail.
There are the following levels: summary, intermediate, and detailed (listed from the
lesser level to the greater one). To achieve the desirable accuracy, the identification of
the objects is to be implemented at possibly more detailed level. Bearing in mind that
the EFP method at the lesser levels of detail (summary and intermediate) lies very
closely to the expert estimation method and has very little advantage in comparison
with the latest, the detailed level is strongly recommended for usage.

They distinguish the following objects of the EFP method: Logical Data and
Functionalities.

Logical Data (LD) are groups of logical related data elements.

A Functionality is a set of actions performed by the system, enabling the user to

attain a business objective.

Each EFP object (both logical data and functionality) is classified on a scale of
complexity. The Logical Data are classified as Simple, Average, Complex, Low
Multiplicity and High Multiplicity in accordance with amount of Information Objects,
Data Element Types (DETs), and Record Element Types (RETs) that are included in
the LD specified. Here, Information Object is a user identifiable group of logically
related data; Record Element Type is user recognizable sub-group of data elements
within an Information Object; Data Element Type is a unique user recognizable,
non-repetitive field or GUI element.

Functionalities are classified, in order of magnitude, as Functional Primitive

(corresponds to detailed level), Microfunction (corresponds to detailed level), Function
(corresponds to intermediate level), and Macrofunction (corresponds to summary
level) in accordance with amount of functional primitives that are included in the
functionality specified, where a Functional Primitive (fP) is the smallest process,
performed with the aid of the software system, with autonomy and significance
characteristics, that allows the user to attain a unitary business objective at the
operational level. There are three types of Functional Primitives: Primitive Input (PI),
Primitive Output (PO) and Primitive Inquiry (PQ).

In accordance with the identified complexity, each of EFP objects is associated with
a set of three FP values (minimum, average and maximum) based on the universal
statistical table provided by the IFPUG97 standard (see below). After the EFP objects
are identified and rated all the function points are to be summed. Note that minimum,
average and maximum function points are to be summed separately, specifying
 a range of validity of the estimation in terms of so-called Unadjusted Function
Points (UFPs).

After the final sum of Unadjusted Function Points is derived the Value Adjustment
Factor (VAF) is to be calculated to take into account the degree of influence of
General System Characteristics (GSCs) . The degrees of influence range on a
scale of zero to five, from no influence to strong influence (see ). Once all the 14
GSCs have been answered, they should be tabulated using the IFPUG Value
Adjustment Equation. The final Function Point count (amount of so-called adjusted
function points - AFPs) is obtained by multiplying the UPF by the VAF.

In such a way, the algorithm of estimating project effort will be described as follows:

1. Classifying Logical Data and identifying the Information Objects.

2. Identifying complexities of the Logical Data and assigning the specified sets of
Function Point values to the Information Objects identified.

3. Classifying Functionalities.

4. Identifying complexities of the Functionalities and assigning the specified sets of

Function Point values to the Functionalities identified.

5. Calculating final number of Unadjusted Function Points (UFP) by summation of

the Function Point values associated with all the identified objects including both
Information Objects and Functionalities.

6. Calculating Value Adjustment Factor (VAF) by using Value Adjustment Equation

(see ).

7. Calculating number of Adjusted Function Points (AFP) by multiplying UFP by VAF.

8. Calculating Source Lines of Code (SLOC) of the application on the base of

Adjusted Function Points by using the conversion ratio table.

9. Entering the number of SLOC into the COCOMOII model to calculate Waterfall
Phase Distribution for the project to be developed.

? Classifying Logical Data

The first purpose of classifying Logical Data is to identify the Information Objects,
and the second one is to associate the Logical Data with suitable set of Function
Point values.

An Information Object is a logical, or user identifiable group of data or control

information that fulfills specific user requirements. This means that the physical
implementation of the data does matter not so much as its logical manifestation.
Consider the point at which a group of data ceases to be individual elements of data
(fields, etc.) and starts to satisfy unique requirements of the application. For example,
a database system may contain several tables, each of which has very specific roles.
It may be the case that each table is an Information Object.

According to the above, the Logical Data are classified as Simple (corresponds to
detailed and intermediate level), Average (corresponds to detailed and
intermediate level), Complex (corresponds to detailed and intermediate level), Low
 Multiplicity (corresponds to summary level) and High Multiplicity (corresponds to
summary level) in accordance with amount of Information Objects, Data Element
Types (DETs), and Record Element Types (RETs) that are included in the LD
specified. In particular, at summary level of detail, complexity of Logical Data
depends on how many Information Objects are present in the project (see Table 1). At
detailed (or, idem, intermediate) level of detail, the amount of RETs and DETs
included in Information Objects determines complexity of Logical Data. In the latest
case, each Information Object must be separately identified as simple, average or
complex (see Table 2) and associated with suitable set of Function Point values that
will be summed later.

Note that they dont distinguish detailed level and intermediate level with
reference to Logical Data.

Table 1
Complexity of Logical Data (LD) Number of Information Objects included

Low Multiplicity 2-4

High Multiplicity 5-8

Table 2

Record Element Data Element Types (DET)

Types (RET)

1 to 19 20 - 50 51 or More

1 RET Simple Simple Average

2 to 5 RET Simple Average Complex

6 or More RET Average Complex Complex

To obtain the set of Function Point values corresponding to the Logical Data classified,
use the following table:
Table 3

LD Min. Avg. Max.

Simple 5 6 7

Average 8 9 10

Complex 13 14 15

Low Multiplicity 14 18 22

High Multiplicity 27 39 51
? Classifying Functionalities
According to the above, Functionalities are classified, in order of magnitude, as
Functional Primitive (corresponds to detailed level), Microfunction (corresponds to
detailed level), Function (corresponds to intermediate level), and Macrofunction
(corresponds to summary level) in accordance with amount of functional primitives
that are included in the functionality specified.

Functional Primitive (fP) is the smallest process, performed with the aid of the
software system, with autonomy and significance characteristics, that allows the user
to attain a unitary business objective at the operational level. It is meaningless, from
the user's point of view, to proceed to further useful decomposition of a Functional
Primitive. There are three types of Functional Primitives: Primitive Input (PI), Primitive
Output (PO) and Primitive Inquiry (PQ).

Primitive Input (PI) - is an elementary process in which data crosses the boundary of
the application from outside to inside. This data may come from a data input screen,
for example. If a Primitive Input adds, changes and deletes (maintains) information on
an Information Object, then this represents three primitive inputs. When filling any
input form by enabling/disabling checkboxes, selecting radio-buttons, filling text fields
and so on and clicking OK you implement only one Primitive Input. Primitive Inputs
(especially change and delete) may be preceded by a Primitive Inquiry (see below).
For example, if you want to select a parameter from a drop-down list you have to
implement one Primitive Inquiry (accessing the drop-down list specified) and one
Primitive Input (selecting the parameter needed from the list followed by clicking OK).

Primitive Inquiry (PQ) - an elementary process with both input and output components
that result in data retrieval from one or more Information Objects. The input process
does not update any Information Object and the output does not contain derived
data. A Primitive Inquiry cannot have calculated values or derived data. This
characteristic distinguishes a Primitive Inquiry from a Primitive Output. For example,
accessing a drop-down parameter list or list of CDs names that are present in the
database is a Primitive Inquiry.

Primitive Outputs (PO) - an elementary process in which derived data passes across
the boundary of the application from inside to outside. Additionally, a PO may update
an Information Object. The data may create reports or output files sent to other
applications. These reports and files are created from information contained in one or
more Information Objects. Derived Data is data that is processed beyond direct
retrieval and editing of information from Information Objects. 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 Information Object. Unlike other
primitives POs almost always contain business data. For example, Notification
Messages are considered POs, because a notification message is the result of some
business logic processing. (For 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.

*Note that 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.

To obtain the set of Function Point values corresponding to the Function Primitives,
use the following table:
 Table 4

FP Min. Avg. Max.

PI 4 5 7

PO 5 6 6

PQ 4 5 7

Microfunction (mF) is the set of 4 standard Functional Primitives: Create, Read,

Update and Delete (CRUD) of elementary data in one or more Information Objects.
Dont confuse these primitives with ones described above (PI, PQ, and PO). Usually,
CRUD primitives are associated with the term "Management of...", meaning that any
particular Information Object should be subject to all the described operations to make
it possible to usefully employ the software application.

* In fact, microfunction lies between detailed and intermediate levels of detail.

However, when estimating project effort, using microfunctions provides acceptable
accuracy.

To obtain the set of Function Point values corresponding to Microfunction, use the
following table:

Table 5

Min. Avg. Max.

mF 16 18 20

A Function (F) is a set of Functional Primitives and can be likened to an

operational sub-system of the application in order to allow for an organized whole
responding to the users' objectives to be achieved. A Function can be Small, Medium
or Large depending on whether it groups an estimated particular number of Functional
Primitives, as described in tab. 6:

Table 6

Function fPs included

Small 5-12

Medium 13-19

Large 20-25

* Note that Function corresponds to intermediate level of detail and is not

recommended for usage when detailed level is accessible.

To obtain the set of Function Point values corresponding to a Function, use the
following table:
 Table 7

F Min. Avg. Max.

Small 45 56 67

Medium 73 91 109

Large 106 133 160

A Macrofunction (MF) is a set of medium Functions, and sometimes can constitute

a whole development project on its own. It may be likened to a relevant sub-system of
the overall Information System of the user's organization. A macrofunction can be
Small, Medium or Large depending on whether it groups an estimated particular
number of Functions, as described in tab. 8:

Table 8
Macrofunction #Fs included

Small 2-3

Medium 4-7

Large 8-12

To obtain the set of Function Point values corresponding to a Macrofunction, use the
following table:

Table 9
F Min. Avg. Max.

Small 151 215 280

Medium 302 431 560

Large 603 861 1119

* Note that Macrofunction corresponds to summary level of detail and is not

recommended for usage when detailed or intermediate level is accessible.
? Calculating Value Adjustment Factor
According to the above the Value Adjustment Factor (VAF) is based on 14 general
system characteristics (GSCs) that rate the general functionality of the application
being counted. According to the above 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. They
ratings are:

0 Not present, or no influence

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

Once all the 14 GSCs have been answered, they should be tabulated using the
IFPUG Value Adjustment Equation

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 GSCs.

Brief description of the General System Characteristic is contained in the table 10:

Table 10

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 processing How are distributed data and processing functions
handled?

3. Performance Did the user require response time or throughput?

4. Heavily used configuration How heavily used is the current hardware 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 internal information objects 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 users needs?

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?

* For more details on the General System Characteristics, see the IFPUG 4.1 Manual created on
the base of IFPUG standards.

? Calculating Source Lines of Code (SLOC) of

the application on the base of Adjusted
Function Points counting
The Function Points have to be converted to source lines of code in the implementation
language (Ada, C, C++, Pascal, etc.) by multiplying the number of Function Points by
conversion ratio suited to the programming language specified.

To determine the conversion ratio suited to the language specified, use the following table:

Table 11
 Table 11

* Note, that in case of multi-language project you have to calculate SLOC for each used language
separately.

? Using use-case model of the project for

estimating effort on the base of EFP method
ALTHOUGH THE EFP METHOD IS NOT ASSOCIATED WITH USE-CASE MODEL, THE
LATEST COULD BE VERY POWERFUL SUPPLEMENTARY TOOL FOR APPLYING THE
METHOD TO ESTIMATING PROJECT EFFORT.
The main problem consists in extracting use cases of suitable level of detail from Statement of
Work provided by customer. All the information needed for understanding the required internal
behavior of the system is to be captured.

The customer generally finds information about what happens inside the system uninteresting, so
the use-case descriptions may leave such information out. In these cases, the use-case description
reads like a black-box description, in which internal details on what the system does in response
to an actors actions is either missing or very summarily described. To find the objects which
perform the use case, you need to have the white-box description of what the system does from
an internal perspective. (Rational Unified Process)

The following example obtained from Rational Unified Process illustrates how black-box
description is transformed into white-box description.

Example
 In the case of an Automated Teller Machine (ATM), the customer of the system may
prefer to say

"The ATM validates the Bank Customers card." black-box description that could
be contained in the Statement of Work (IK) -

to describe the user authentication behavior of the system. While this may be sufficient
for the customer, it gives us no real idea of what really happens inside the ATM to
validate the card.

In order to form an internal picture of how the system really works, at a sufficient level
of detail to identify objects, we may need additional information that must be
obtained from the customer (IK). Taking the ATM card validation activity as an
example, the expanded description would read as:

"The ATM sends the customers account number and the PIN to the ATM Network to
be validated. The ATM Network returns success if the customer number and the PIN
match and the customer is authorized to perform transactions, otherwise the ATM
Network returns failure." - white-box description (IK)

On the base of white-box description the flow of events is to be drawn. The latest is a base for
identifying the Functionalities. In the example above, the event The ATM sends the customers
account number and the PIN to the ATM Network to be validated is to be identified as Primitive
Input (PI) because the process in which data (account number and the PIN) crosses the boundary
of the application from outside to inside is present. The event The ATM Network returns success
if the customer number and the PIN match and the customer is authorized to perform transactions,
otherwise the ATM Network returns failure is to be identified as Primitive Output (PO), because a
notification message that is the result of some business logic processing (in this case, process of
authorization) is to be sent.

* Note that effort of realizing business logic that lies in the example between PI and PO is not
estimated, because, as mentioned above, the method is intended for estimating effort of
developing of user interfaces.

* NB Business logic may be realized in programming language that differs from that of user
interface.

According to Rational Unified Process, The internal behavior of the system should be
unambiguously, so that it is clear what the system must do. It is not necessary to define the
elements within the system (objects) that are responsible for performing that behavior just a clear
definition of what needs to be done. In order to determine whether a use-case description is
satisfactory in aspect of applying the EFP method, examine the description by asking the
question "what does it mean for the system to do that thing? If what the system does to perform
the behavior is not well defined enough to answer that question, there is likely more information
that needs to be uncovered. " (Rational Unified Process)

After use-case model is created on the base of use cases described, drafting a use-case hierarchy
is recommended. When drafting a hierarchy, bear in mind that each functionality is to be taken into
account only once when counting Function Points. Hence, both the use cases having
relationships stereotyped as uses (used use cases), include (included use cases), extend (inserted
use cases) and the use cases that are more general with regard to some other (more specific) use
cases are to be arranged under suitable base use cases to avoid repeated accounting of use
cases. The abstract use cases must be excluded from the FP-counting.
 "The ATM sends the customer's account number
and the PIN to the ATM Network to be validated.
The ATM Network returns success if the customer
number and the PIN match and the customer is
authorized to perform transactions, otherwise the
Making a deposit
ATM Network returns failure." = 1Primitive Input
(PI) + 1Primitive Output (PO)

<<uses>>

Currency transaction Validation of the bank customer's

Customer
card

<<include>>

Withdrawal of a sum from the Closing the account

account

For instance, the use case described in the example above can be used by some other use cases.
The possible use-case diagram is present below:
This use-case diagram is to be transformed into the hierarchy diagram that is present below:

This use case is abstract and

must be excluded from the
FP-counting.
Currency transaction

Closing the account Making a deposit Validation of the bank customer's

card

Withdrawal of a sum from the

account
In view of the above, the following rules on how to apply use-case modeling to estimating project
effort on the base of EFP method can be formulated:

1. The use cases of suitable level of detail containing the white-box description of system
behavior are to be extracted from the Statement of Work provided by Customer. If the sufficient
level of detail of use-case description cant be drawn from the Statement of Work the Customer
ought to be applied for additional information. The main criterion of sufficiency of information
obtained from Customer is provided by the question "what does it mean for the system to do
that thing?

2. On the base of white-box description the flow of events is to be drawn. The flow of events is
the base for identifying the Functionalities.

3. The use-case model is to be transformed into hierarchical model. Herein the use cases having
relationships stereotyped as uses (used use cases), include (included use cases), extend
(inserted use cases) and the use cases that are more general with regard to some other (more
specific) use cases are to be arranged under suitable base use cases.

4. The use cases of the hierarchical model ought to be bottom-up analyzed in order to avoid
repeated accounting of use cases. Each use case must be taken into account only once (!).

? Case study
Let's estimate effort for developing a client part of software system intended for providing
information interchange between ships and the land. The server part is situates on the land. The
client parts are to be situated on different ships (i.e. on multiple sites) and must implement the
following functions:

1. Automated generating of documents based on templates provided.

2. Storing documents in the local database that can be synchronized with the central
database.

3. Sending documents of the specified types to the land via e-mail.

About 70 types of document templates will be created. Each template will contain about 15 fields to
be filled.

The business process is described by the following use-case model:

 <<include>>

Authorization
Creating a document Storing the document in the local
<<include>> database

<<include>>

Selecting a document template

The captain
Editing the document

<<include>>
Sending a document to the land <<include>>

<<include>>
Selecting a document from the
local database

Printing the document

 1. Classifying Logical Data
Bear in mind that the physical implementation of the data does matter not so much as its logical
manifestation. In aspect of logical manifestation we can distinguish two information objects : Users
(including captain, navigator, and so on) and Documents. Hence, according to the Table 1 we
have to assign the Low Multiplicity value to the Logical Data complexity when estimating effort of
developing the database at summary level of detail . According to the Table 3 the following Function
Point values correspond to the Logical Data specified: Min. 14, Avg. 18, Max. - 22 .

Lets estimate the Logical Data at detailed level of detail. Remember that documents are generated
when filling templates with real values that can be stored separately from the templates. Hence,
there are two RETs in the Information Object called Documents: Template form storage and
Document data. Taking into account that each template will contain about 15 fields, it would be
natural to assume that amount of DETs would exceed 51 despite possible repeatability of some
fields. Hence, according to the Table 2 we have to assign the Complex value to the Information
Object Documents (at the moment, amount of DETs included in the Document Data RET cant
already influence estimation of Information Object complexity). According to the Table 3 the
following Function Point values correspond to the Information Object specified: Min .13, Avg.
14, Max. - 15 . It is obviously that complexity value of the second Information Object (Users) is
Simple because this Information Object consists of a single RET that would contain certainly less
than 51 DETs. Hence, according to the Table 3 the following Function Point values correspond to
the Information Object Users : Min . 5, Avg. 6, Max. - 7. In such a way, the Function Point
values corresponding to the Logical Data at detailed level of detail can be calculated as follows:
Min .{13 + 5} =18, Avg. {14 + 6} =20, Max. {15 + 7} =22 .

Note that the average value of detailed level is almost identical to the summary level's one,
but the deviation between average and minimum and maximum is clearly reduced .

Lets assume that developing of database will be implemented by using SQL.. To calculate SLOC
for the FP-ranges calculated, select from the Table 11 the suitable conversion ratio (Language -
Query-default; SLOC/FP - 13); then multiply values of FP-range by the conversion ratio selected.
The resulted SLOC(SQL) values are: Min .234, Avg. 260, Max. - 286 .
The following table contains the complete information on Logical Data parameters:

2. Classifying Functionalities

According to the above we can use use-case model for applying the EFP method to estimating
effort of the project. To avoid repeated counting of any functionality included in different use cases,
lets transform the use-case diagram into so-called hierarchy use-case diagram:
 This use case must be excluded
from FP-counting because there is
not any its peculiar functionality
that is not included in any other
use case of the model.

Authorization

Sending a document to the land Printing the document Editing the document Creating a document

Selecting a document from the Storing the document in the local Selecting a document template
local database database
The Editing the document use case must be excluded from FP-counting because there is not
any its peculiar functionality that is not included in any other use case of the model, in particular,
in the Creating a document use case and the Selecting a document from the local database use
case that is stereotyped as include regarding other two use cases.

Lets analyze bottom-up the hierarchy model.

The Selecting a document from the local database use case. Flow of events: 1. User calls
the list containing names of the documents that are present in the local database - 1 Primitive
Request. 2. User selects the needed document from the list and clicks OK 1 Primitive Input.

The Storing the documents in the local database use case. Flow of events: 1. A document is
open; User saves the document by clicking Save 1 Primitive Input..

The Selecting a document template use case. Flow of events: 1. User calls the list containing
names of the templates that are present in the local database - 1 Primitive Request. 2. User
selects the appropriate template from the list and clicks OK 1 Primitive Input.

The Sending a document to the land use case. Flow of events: 1. User invokes the Selecting
a document from the local database use case ; 2. User clicks Send - 1 Primitive Input.

The Printing the document use case. Flow of events: 1. User invokes the Selecting a
document from the local database use case ; 2. User clicks Print - 1 Primitive Inquiry.

The Creating a document use case. Flow of events: 1. User invokes the Selecting a
document template use case ; 2. User fills fields of the template and clicks OK - 1 Primitive
Input; 3. User invokes the Storing the document in the local database use case.

The Authorization use case. 1. User enters the login and password (fills the suitable fields) and
clicks OK 1 Primitive Input. 2. The system carries out authorization of the user and returns error
message if users login and/or password are not valid 1 Primitive Output.

Besides, the two , lets call them so, supplementary use cases - Sending Error message and
Deleting the current task - are to be identified. For example, error message is to be sent by the
system when some mandatory fields of a template are not filled when creating a new document . It
would be a message like Data entered are not sufficient. In some cases a current task is to be
interrupted and all the intermediate results are to be deleted.

The Sending Error message use case. According to the above, an error message is to be
classified as Primitive Output.

The Deleting the current task use case. Flow of events: User clicks the Delete current task
button when a task is being executed 1 Primitive Input.

The final FP-counting of Functionalities is present in the following table:

It is assumed that the user interface will be implemented by using Visual Basic 5.0. When
calculating SLOC the suitable conversion ratio (29) has been obtained from the Table 11.

3. Calculating Value Adjustment Factor (VAF) , Adjusted Function Point (ADF)

values and Adjusted SLOC values (ASLOCs) .