Using function point to quote a software

Summary

Software Industry, an industry which sells logical things. The advantage of buying a software is automation, better
analyzing of business, thus making life easier. As we are into logical selling, it makes difficult to come with a costing to
an accurate level. Customer can see the benefits of buying only when he uses the software for quiet a period of time
and then says 'Aah its worth of it'. When customer sees accountants performing better, invoices been made with least
errors etc., customer gets convinced. So to convince the customer at the primary stage is really a big nut to crack. If
you give more quote you lose the project, if you give less quote you will end up doing social service to clients and
probably also loss. In this tutorial, we will discuss mainly "Function Point" from practical point of view.

Acronyms and Abbreviation

Through out the tutorial i have been using lot of acronyms. Knowing them before hand will make your comfortable
while reading.

1. FP : Function Point
2. ILF : Internal Logical File.
3. EIF : External Interface file
4. EI : External Inputs
5. EO : External Outputs
6. EQ : External Enquiries
7. RET : Record Element Type
8. DET : Data Element Type
9. FTR : File Type Reference
10. GSC : General System Characteristic
11. VAF : Value Added Factor
12. LOC : Line of code

Scope

This article will give a practical approach to using "Function point". Function point is a very vast topic and it will be
complete injustice to say that this tutorial will accommodate everything. So at the end i have put links to different
websites which you can review for details further. This article will deal with how function point calculation is done. So
just make your mathematician head out while reading this tutorial. The religious war of how to evaluate a software is
from years. So if i say function point is perfect way my email box will be full with contradiction. Software cost evaluation
techniques (LOC, Function point etc) have there own advantage and disadvantage. So this tutorial will deal with only
function point calculation and a small customer screen sample for getting a feel of function point. When you are going
through my article you will do see some math's equations coming across. You may also wonder there is no way
software can be evaluated using formula's.

Theory

If said to analyze cost of any physical product, example a simple pen, I can pin point to a good extent the cap's cost,
the ink cost etc., and come out with a rough estimation. Even the customer is equally convinced as he can see those
physical products. Software industry also has practices of evaluating cost, the following are 2 major ones:

1. Lines of code.
2. Function points (FP).

I personally do not believe in lines of code. In this software world of reusability, 1000 lines of code can become 200
lines, thus leading to complete misjudgment. Just wondering during design phase how can you know the total lines of
code. For some reason, I feel Lines of Code favor the software company more than its clients. Just imagine i want to
make simple window based customer GUI in C language and the same in Visual basic. The Lines of code will differ a
lot and hence the costing. In short lines of code are programming language dependent." Lines of code would have
been fair if there was one programming language in the world". Just my 2 cents Programmers output is not Quantity

1
(Lines of code) but the logic what he has written. If you want to evaluate a house cost do we ever measure the bricks
and nails. Well i stop here talking about LOC or else the whole tutorial will look like i am against LOC.

But with FP, I see the quote coming out fair for both customer as well as the software company and is language
independent to a very good extent Note not completely independent). I was very convinced with FP in one of my
clients' place where the client handed us a huge book of use case and said to come out with estimation. We where a
team of 4 people. We divided in team of 2 and said let's come out with some quote and then tally our results. After 2
days continuously counting every element, we saw both teams coming to the same value of "Function Points", that
means consistency even after different people sitting on it.

Definition of Function Point and History

They are units of software measurement, like for distance we have kilometer. There's a favorite saying - You can't
control what you can't measure. Breaking the system into smaller systems, and analyzing them and coming out with
cost for every unit. Finally, we total all the smaller units to come out with final total. Function points measure system
from functionality perspective and are independent of technology.
Does not it sound cool? Dear customer, we are issuing a invoice of 1000 function points for these functionality.

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 coming out.For best practicec and
live example

Sections of Function Point

There are basic 4 section. All the below four section of function point can either reside inside application or outside
application boundary.

Data section: Data section is further divided into:

1. Internal logical file (ILF): This contains logically related data that resides inside application boundary. The
application has to maintain data . Example like customer table which will be maintained through a Customer
data entry screen. Note the inside application data is updated and not any external data. But if you are
updating external application table, those tables will not be categorized as ILF.

2. External Interface files (EIF): This contains components which will lie external of application boundary and
used for only for reference purpose. Note : Do not include functionality like updating the external application in
this section.
Transaction Section: Transaction section uses data section, that is, it maintains information of ILF and EIF. Excuse me
for the short acronyms I am using everywhere, like the ILF and EIF there's acronym list at top for everything. All the
down 3 components adds,modifies,deletes,retrieves or process information contained in ILF and EIF so are termed as
Transaction Section.

1. External Inputs (EI): EI is basically from which we can maintain the ILF. Accountants definitely should have
interface through which they can maintain (Add, Update, Delete) the customer ILF. The basic judgment factor
to come out with EI is from user screens. Like, a customer maintenance screen which gives us an idea that we
have 1 EI and 1 ILF of customer.
2. External Outputs (EO): Here data passes from inside application to outside. Example your application
generates XML or CSV ( Comma separated values) Files. These files are then used by some external
application to update the external application tables. So in this scenario the data is passed from your
application to a external application. So these types of function will fall in this category.
When you send data to external application if you are getting some output from external application. Later this
output is updated in the ILF of internal application is also scenarios which will come under EO.
So litmus test for identifying EO's are :-
a) When data crosses boundary and goes and updates external application tables(EIF).
b) In response of you data sent you get some derived data which is updated in the internal application(ILF).
2
 3. External Inquiries (EQ): These functions will be mainly reports. They have input criteria. Any type of reports
and search screens are right components for EQ.Note like EI and EQ they do not update any ILF or EIF.They
only fetch data for display. So the litmus test for identifying EQ is any reports or search screens which do not
update data in any tables(ILF or EIF).Example Balance sheet in accounting reports.
Sub sections: These are subsections which can either be a subset of either transaction section or data section.

1. Record Element Type (RET): A subgroup of data element inside a logical file. In our customer ILF, we can
have multiple addresses or multiple phone numbers. So for the customer, we can have 2 RETs, Addresses
and Phone numbers.
2. Data Element Type (DET): DET is a non-repetitive field in a ILF. Please note, I have said that field should not
repeat in counting again. Every customer ILF can have Customer Code. So the customer code becomes a
DET. Every invoice can have customer code saying whom this invoice belongs to. But once the customer
code has been counted, do not count customer code twice as two different DETs. But in practical scenarios,
when doing function point of huge projects, there is possibility that you can count DET twice, make a second
iteration just for removing the duplicate DETs.

3. File Type Reference (FTR): An FTR is a file referenced by transaction. An FTR must also be an internal
logical file or external interface file.
General System Characteristic Section (GSC):

This section is the most important section. All the above 3 sections are counting sections. They relate only to
application. But there are other things also to be considered while making a software, like are you going to make it an
N-Tier application, what's the performance level the user is expecting etc. These are external factors which affect the
software a lot and also the cost of it. When you submit a function point to a client, he normally will skip everything and
come to GSC first. GSC gives us something called as VAF (Value Added Factor). There are 14 points considered to
come out with VAF (Value Added factor).

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 ILFs 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?
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?

All the GSC have ratings from 0 to 5. So, the VAF formulae is something like this:

Collapse
VAF = 0.65 + ((sum of all GSC factor)/100).

Scope document

Function point evaluation depends on how much functionality your system provides.So you have to know the
functionality before you start using Function point. In this tutorial we will be evaluating the customer GUI. So i will just
scope what the customer GUI is all about.

3
Following is the scope of the customer screen :-

1. Customer screen will be as shown below.

2. After putting the customer code and Customer name. They will be verified credit card check.
3. Credit Card check is a external system.
4. Every Customer can have multiple addresses.
5. Customer will have add, update functionality

Let's Start Counting

As said, this is a practical guide to FP and to make Quick start. This section will discuss the practical way of counting
the FP and coming out with a Man/Days on a project.

Steps for coming out with a FP

• Counting the ILF, EIF, EI, EQ, RET, DET, FTR (this is basically all sections discussed above): This whole FP
count will be called as "unadjusted function point".
• Then put rating values 0 to 5 to all 14 GSC. Adding total of all 14 GSC to come out with total VAF. Formula for
VAF = 0.65 + (sum of all GSC factor/100).
• Finally, make the calculation of Adjusted function point. Formula: Total function point = VAF * Unadjusted
function point.
• Make an estimation how many function points you will do per day. This is also called as "Performance factor".

• On basis of performance factor, you can calculate Man/Days.

Now we know our steps, we can start counting. But hang in, here're all our charts which we will refer during counting.
These chart are ranking charts and decide the complexity of the section.

EI Rating Table
Data Elements
FTR 1 to 4 5-15 >15
Less than 2 3 3 4
2 3 4 6
>2 4 6 6

This table says that in any EI (External Input), if your DET count (Data Element) and FTR (File Type Reference)
exceed these limits, then this should be the FP (Function Point). Example, if your DET (data element) exceeds >15
and FTR (File Type Reference) is greater than 2, then the Function Point count is 6. The rest down tables also show
the same things. These tables will be there before us when we are doing function point count. The best is put these
values in Excel with formulae so that you have to only put quantity in the appropriate section and you get the final
value.

EO Rating Table
Data Elements
FTR 1 to 5 6-19 >19
<2 4 4 5
2 or 3 4 5 7
>3 5 7 7
EQ Rating Table
Data Elements
FTR 1 to 5 6-19 >19
<2 3 3 4
2 or 3 3 4 6

4
>3 4 6 6
ILF Rating Table
Data Elements
RET 1 to 19 20-50 51 or more
1 RET 7 7 10
2 to 5 7 10 15
>6 10 15 15
EIF Rating Table
Data Elements
RET 1 to 19 20-50 51 or more
1 RET 5 5 7
2 to 5 5 7 10
>6 7 10 10

The following table says what we have to see: for every transaction which subsection is eligible.If you see the table
below EI will have FTR and DETs,So while counting we will have to count in that way.

Section RETs FTRs DETs

EI 1 1
EO 1 1
EQ 1 1
EIF 1 1
ILF 1 1

Simple Customer Project

This is a simple project requirement where we are supposed only to do the customer form and with address details of
it. Following is the screen.

5
There are 2 ILFs in the above screen:

1. The customer ILF.

2. The Customer Address ILF.

• There are no EIFs in the above form.

ILF Customer
Description Number of DET Number of RET
There are total 10 DETs, all add and 10 1
update buttons, even the credit check
button, the address list box, check box
active, all text boxes.

There is only one RET, the customer

addresses. Note i have not included the
credit check as RET as they are not
Sub-elements(Child elements of
Customer ILF).
So according to the above ILF ranking Total function 7
table
ILF Customer addresses
Description Number of DET Number of RET
There are total 3 DETs, all the column 3 0
names in the list box, city name, street
name and pin code.

For the customer address ILF there are

no RET.Please note if this customer
address screen is any where else and
they have RET then make changes
accordingly.
Total FP 7
EIF Credit card Information
Description Number of DET Number of RET
The credit card information referenced 1 0
is EIF.Note this file is only referenced
for credit card check.

There's only one textbox credit card

number and hence one DET is put in
the side column. and RET 0.Looking at
the above rating table the total FP is 5.
Total FP 5
EI Customer
Description Number of DET Number of FTR
There are total 10 DETs, all add and 10 2
update buttons, even the credit check
button, the address list box, check box
active, all text boxes.

There are 2 FTRs, one is the address

and the second is the credit card
information.
Referring ranking table above Total Function 4
6
While counting EI i have seen many people multiplying it by 3.That means we are going to do all CRUD
functionality(ADD,UPDATE,DELETE).This is not fair as it just shows laziness of the Cost estimation team. Here the
customer screen has add and update. I can say the 2 * 4 that's = 8 FP for this EI customer. But i adjust this factor in
my buffer. If you start multiplying for every master screen like this it will be not fair for the customer. So make a
genuine count at the first half and later in buffer add the extra FPs.So over here i count this as 1 EI and not multiply by
any factor.

EO Customer
No EO for this screen. As Customer system is not sending any information to external system which will add or update
the external system.
EQ Customer
No EQ for this screen.At this moment there is no reports section here.Please note the display of cutomer addresses is
not counted as EQ.

So now, let's add the total function point got from above tables :

Section Name Function Point Counted

ILF Customer 7
ILF Customer Address 7
EIF credit card information 5
EI Customer 5
Total Unadjusted Function
24
Points

So all function point comes to 24.Please note i have said this as Unadjusted function as we have not accounted other
variance factor of project (Programmers leaving job, Language we will use, What architecture etc etc).

In order to make it adjusted function point, we have to calculate and tabulate the GSC and come out with the VAF.

GSC Value(0-5)
Data communications 1
Distributed data processing 1
Performance 4
Heavily used configuration 0
Transaction rate 1
On-Line data entry 0
End-user efficiency 4
On-Line update 0
Complex processing 0
Reusability 3
Installation ease 4
Operational ease 4
Multiple sites 0
Facilitate change 0
Total 22

So using formulae:

Collapse
VAF = 0.65 + ((sum of all GSC factor)/100). = 0.65 + (22/100) = 0.87.

7
This factor affects the whole FP like anything, be very particular with this factor. So now, calculating the
adjusted FP = VAF * Total unadjusted
FP = 0.87 * 24 = 20.88 = rounded to 21 FP.
Now we know that the complete FP for the customer GUI is 21 FP. Now calculating the efficiency factor, we say that
we will complete 3 FP per day, that is 7 working days. So, the whole customer GUI is of 7 working days (Note do not
consider Saturday and Sundays in this). I know upper manager people will say make it 7 FP per day and over load the
programmer. Thats why programmer works at night.

Other Practical Factors

I hope the above example has made clear how to use function point. But if the software industry was straightforward,
FP would be enough. How much ever i say software costing is still a very grey area. Function point can just help you in
getting things organized and bring it to almost close figure. Many things while implementing and counting function point
will be common sense (which is not so common) . Experience is the only thing that comes to rescue in software
costing and evaluation.

But also have these practical things in mind:

1. To the total FP, add a buffer FP in case the customer will say any changes or extra features. As, during the
negotiation period, definitely the customer will either bring down the cost so that you are at safe side while
negotiating.
2. Well this worked for me lot. Look at the customer how much can he spend which will make things clear. And
then just judge yourself, will this cost fit in or will it go for rejection.
3. Second, how critical is the software for him, if the criticality is high and he cannot stay with out it, make the
quote according to that. This is one of my friends' experience, he was a freelancer. He was once called to
make a small cash maintenance program. It was one form and one report saying how much amount got today,
and maintenance form. Well, one form, one report, he quoted it quiet less. He completed the project in one day
and got the money on a week's time. But then, client called him after 2 days and told him: "Your this small
program has saved my hell money and time. The amount what you quoted is nothing, I was ready to pay
above it. He said never quote on the quantity basis or size, but how frequently we will use the software". I have
seen billion dollar projects not used and small projects made by one person running the whole company
automation.
4. Is the client looking for maintenance point of view, which means the client can be permanent source of income,
then quote in such a way that you get your share during maintenance. FP does not take into account
maintenance. The best way to come out with maintenance cost is how much programmers you will require on
the site after the product is launched plus your profit share.
5. After evaluating his business sign a scope document with him saying that this is what we will do. Anything
more than this will be charged. So customer is pretty aware of what's going on.
6. Issue invoices regularly for changes and modifications. So that customer understands that there's cost factor
associated to whatever changes he says.

The above points are useful to make plus or minus on the calculated FP.