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 (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.Theres 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).
  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:

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.

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

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

There are 2 ILFs in the above screen:
  1. The customer ILF.
  2. The Customer Address ILF.

ILF Customer

Description Number of DET Number of RET
There are total 10 DETs, all add and 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).

 10 1
So according to the above ILF ranking table Total function 7

 

ILF Customer addresses

Description Number of DET Number of RET
There are total 3 DETs, all the column 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.		 3 0
  Total FP 7

 

EIF Credit card Information

Description Number of DET Number of RET
The credit card information referenced 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.

 1 0
  Total FP 5

 

EI Customer

Description Number of DET Number of FTR
There are total 10 DETs, all add and 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.

 10 2
Referring  ranking table above Total Function 4

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 Points 24

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:

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

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.

References

    Tutorial Links

  1. International Function point user group http://www.ifpug.org.
  2. http://www.qpmg.com/fp-intro.htm.
  3. A good PDF tutorial on this website http://www.ifpug.com/freemanual.htm

    Free Function point Software

  1. Try FPrecorder in google.

Last Words

"Do not quote too less that programmers work for over night, you lose the project or end doing social service, or loss. Do not quote too high that you lose the project. Be fair to yourself and your customer."

Shivprasad Koirala.