Software Project Estimation Part 6: Function Point Analysis

This post is part of my series on Software Project Estimation:

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.

More posts on Software Estimation are coming…

I am working on several more posts in my Software Estimation series.  Things have gotten very busy so I’m just running a couple of weeks behind schedule.  The next posts will focus on Function Point Analysis and Fuzzy Logic.

In the meantime, why don’t you check out this great series from my friend Caleb Jenkins: 10 practices that every developer needs to start right now.

foursquare vs. Gowalla vs. brightkite: The Location Based Social Networking War

Ok, so for the last couple weeks I have been using three location-based social networking tools, trying to determine which I like best.  The contendors are foursqure, Gowalla, and brightkite.

First, let’s talk about the concept.  Using these tools you “check in” at locations you visit.  Seems like a neat way to see what your friends are doing and find interesting places to go and things to see.  Each of these tools will post to Facebook and Twitter so all of your followers on those services will see updates.  And each of these tools have great iPhone apps.  The problem is that they each of great features, and several shortcomings.  So, I’m having trouble picking one.


Foursqure is the most popular of the three.  I love the concept of becoming a Mayor of a location and collecting Badges.  But, it doesn’t give you an easy way to see on a page what your friends are doing, or who is currently near you.  Both of these seem obvious features that I just cannot find on their website.  Actually, on the home screen of the iPhone app you see where your friends currently are, but I cannot find it anywhere on the website.  However, the majority of my friends using one of these tools is using foursqure, so that is a plus for it.


Gowalla is the next most popular.  Unlike foursqure, on the Gowalla home page you can easily see what your friends are doing.  It also has the concept of Creators and Founders, which seems very similar to the Mayors on foursquare.  I love the large locaiton icons it uses and the stamps you earn and items you can drop.  Gowalla was really looking like it would come out in first place for me, but it does something strange with the Twitter posts.  When it posts to twitter it seems to insert a random “@” username in for the location name.  I can’t find on the locations where these twitter usernames are set.  Seems like a pretty major bug to me, so I don’t think this is going to be the one I end up using.


Brightkite is the least popular of the three, but surprisingly the most feature rich.  You can easily see people near you at any radius you select.  You can also easily see what your friends are doing.  It also gives you the ability to upload a picture when you checkin.  You can set it up to automatically push that picture to Flick or your Facebook photo album.  It doesn’t seem to have any concept like a Mayor or Founder.  But that’s not a huge deal.  Really, the biggest downside for me on brightkite is the fact that I only have a few friends on it, and almost all of them have switched exclusively to foursqure or Gowalla.

So, in my personal opinion, brightkite should win the war of the location based social networking tools.  Do I think it will?  Probably not.  Foursqure and Gowalla are currently much more popular.  But brightkite is the most feature rich and seems the most stable.  So, everyone out there who is looking at these tools, let’s all switch to brightkite and call this war over!

If you are using any of these three, add me as a friend.  Here are the links to my profiles:

My thoughts on Lost Season 6 Episodes 1 & 2: LA X

Ok, so I’ve been thinking a lot over night about what’s going on in Lost, and here are my current thoughts.  Do not read if you haven’t seen last night’s episodes yet, there ars spoilers below.

What’s with the Alternate Timeline?

When Juliet set off the Nuke in 1977, the alternate timeline was created.  Why?  Because it had to be.  If you think about cause and effect, a paradox would have been created otherwise.  If the alternate timeline were not created, then setting off the nuke would have caused the plane never to crash in 2004.  If they plane never crashed in 2004, then Jack and team never went back in time to set off the nuke that caused the plane to not crash.  You have a paradox.

So, instead of creating a paradox, the alternate timeline was created.  The whole Infinite Universes theory.  The effect of them setting off the nuke in the main timeline was the nuke going off in the alternate timeline.  Though in the main timeline the nuke did not go off because it couldn’t.

So, in the main timeline, the group jumps back to where they are supposed to be in time: 2007.  This catches them back up to where the rest of their group was.  And now everyone is back together in the main timeline.

In the alternate timeline, the island has now sunk in 1977 because of the nuke.  This causes the plane never to crash in 2004.  But, it also causes a series of effects beginning in 1977 which ultimately cause the little differences we see on the plane in 2004.  Differences such as Shannon not getting on the plane with Boone to go home, Hurley having good luck instead of bad, Michael and Walt not being on the plane, etc.  However, everyone on the plane is going to have a strange sense of deja-vu because of what has happened in the main timeline.  Jack experienced this when he saw Desmond.

What’s up with Jacob, his Nemesis, and the Other Others?

First of all, the Other Others.  These are simply part of the Others who live at the Temple.  We’ve seen Cindy, Zach, and Emma (who were from the tail section) before with the Others. They are preparing for an attack by Jacob’s Nemesis, as the Smoke Monster, now that they have heard Jacob (thier spiritual leader) is dead.

Jacob and his Nemesis represent the battle between good and evil.  Jacob has his Nemesis somehow trapped at the island so he cannot leave.  The Nemesis wants desperately to leave and the only way he can is by killing Jacob.  So, he arranges the series of events we saw last season with Jacob ultimately being killed by Ben.

Jacob and his Nemesis are disputing over the ultimate good or evil in man.  Jacob keeps bringing people to the island trying to show that a good, peaceful civilization can live there.  This results in the Others.  The Nemesis keeps corrupting groups of people causing the endless fighting that is occurring there over the years.

So, in both timelines, Jacob is dead.  Evil has won.  What we’re going to see this season is Jacob, speaking through Hurley, arranging events to send Jack and team back in time to stop Ben from killing Jacob.  I think Sayid will ultimately be the one to stop Ben.  When this happens, it will create another alternate timeline where the balance between good and evil, Jacob and his Nemesis, is restored.

So, that’s my current thoughts on what’s going on.  I’ve excited to see what happens over the rest of the season.

Software Project Estimation Part 5: Count

This post is part of my series on Software Project Estimation: 

Today’s I’d like to dive into another software estimation methodology.  I’ll refer to this only simply as Counting.  Using this technique you find something to count and base your estimation upon that count.

So, the first step is to find something to count.  What should this be?  Here are some examples of things you could count:

  1. Requirements
  2. User Screens or Web Pages
  3. Function Points
  4. Use Cases or User Stories
  5. Database Tables

Whatever you decide to count needs to satisfy a couple requirements:

  1. It must be available early on in the project (preferably at the Requirements stage, not the Technical Design one).
  2. It should be highly correlated to the actual effort invovled to execute the project.
  3. You should have historical data available telling you how long it will take for you to construct it.

Let’s say, for instance, you are creating a web site and you decide that you are going to count the web pages to try to get an estimate for the project.  Looking at your historical data, you determine that the web pages you have created have fallen into three categories: 1. Simple (static text), 2. Avarage (simple data input / retrieve), and 3. Complex (more difficult data input or retrieve).  Your historical data reveals the following average construction times for these web pages:

  1. Simple: 4 hours
  2. Average: 16 hours
  3. Complex: 40 hours

To come up with your estimat, you simply have to inventory the web pages you are going to create as part of this project, and assign them to those categories.  Using these counts, you can come up with the total amount of time for coding and unit testing.  Based on your project breakdown percentages you can then derive the time for the other phases and get your complete estimate for the project.

This technique can be further refined by breaking your components into those that are being Created or just Modified and getting afterage times for Simple, Average, and Complex components in those two categories.

An additional factor can be added to this estimate to take into account the skill level of the developer doing the construction.  Say, for instance, you estimate what it would take for an Average developer to do the coding.  From your historical data it my be clear that it takes a Novice 50% longer to do the construction and an Expert only 3/4 the time.  So, you could break your components down by the skill level of the person doing the development, muliply the Novice ones by 1.5 and the Expert by 0.75.

So far I have been describing this estimation technique in a way that relies heavily on having your own historical data available.  But, what if you do not have this information?  In that case I would recommend using an industry standard metric to count that has associated industry historical data avaiable.  Function Point Analysis is a perfect example of a very refined Counting technique.  I will explore this in detail in a later post.