- Part 1: Introduction
- Part 2: The Process of Software Development
- Part 3: The Cone of Uncertainty
- Part 4: Expert Judgement
- Part 5: Count
- Part 6: Function Point Analysis
Function Point Analysis is one of the estimation techniques I have been most excited about over the past few years. It’s actually a specific implementation of the “Count” methodology that I talked about prevoiusly. But, I figured it was important enough to give it it’s own post.
In Function Point Analysis you count the number of Function Points in a project. To get there, you first have draw a boundary representing the scope of your project. You then make an inventory of all of the interfaces (data in motion) and files (data at rest) associated with the project.
There are 2 different types of files that have to be identified:
- Internal Logical File (ILF): A file whose data is created and maintained by this application.
- External Interface File (EIF): A file whose data is referenced by this application, but not maintained by it.
For each one of the file types you have to count the number of record element types (tables) and data element types (columns within the tables). Based on these counts, each file is assigned a number of Function Points. The important thing with these files is to keep in mind that they might not actually be a database or a file. They could be something like another system that is interfaced with.
There are 3 different types of iterfaces that have to be identified:
- External Inputs (EI): Data coming into the system from outside the system. An example would be a user’s login form.
- External Outputs (EO): Data coming out of the system from inside the system. An example would be a report.
- External Inquiries (EQ): An interface where some data comes in which causing processing and then some data coming out. An example would be a search form.
For each of these interfaces, you have to identify the number of record file types that are interfaced with and data element types that are carried along the interface. Based on those counts, each interface is assigned a number of Function Points.
Once you have identified the interfaces and files and assigned a number of Function Points to each, you can add up those counts and come up with your Unadjusted Function Point count.
The Global System Characteristics can then be used to adjust this Function Point Count. The Global System Characteristics are attributes used to assess the complexity of an application. Once you assign a rating to each characteristic, you come up with an adjustment factor. It may be something like 1.1. You then muliply your Unadjusted Function Point Count by this adjustment factor to get your Adjusted Function Point Count.
At this point you just have a number which is pretty meaningless on its own. However, industry standards exist showing, on average, how long it takes application development teams to complete projects of different Function Point counts. In my experience doing .Net projects, I know that it takes about 15 hours per Function Point for coding and unit testing.
This will give you the hours for development. The percentages assigned to each phase of the project can then be used to determine how long the entire project will take.
It’s very easy to learn the basics of counting Function Points. Becoming an expert, however, takes lots of study and practice. If you give the same project requirements to two different expert counters, their counts will come out almost identical. This makes Function Point Analysis a very useful methodology for estimating the size of a project.