Summary: I use Function Point Analysis (FPA) and Yesterday’s Weather to make “back of the envelope” software cost estimates when discussing potential new software projects with decision makers.
The problem
Many times when a software project is in its earlier stages (the conceptualization phase), the people that control the money at an organization (the CEO, CFO, CIO, etc.) want the best estimate they can get regarding the time and cost of a software development project. This is often very early in the project lifecycle, typically shortly after someone said, “Hmm, that sounds like a very interesting idea” and well before the first check is cut. In short, they want the best back of the envelope, ballpark cost estimate you can give them.
The solution
I used to dread these discussions, because I hated estimating the time and cost of software projects. I wasn’t any good at it, and the developers I worked with weren’t any good at it either. But once I learned two things:
- Function Point Analysis (FPA), and
- How fast we historically developed software applications
I became much more willing to enter these discussions. In fact, I encouraged them. I figured that in the end these discussions would save a lot of my customer’s time and my own time.
I learned that if I could drill a C*O (and their assistants) with a barrage of questions about the application, and if they could answer them to my satisfaction, I’d say, “Given (a) what you’ve told me and (b) our historical development rate, it looks like this will cost about $200,000 and take about four months. We might be a little higher or lower, a little faster or slower, but based on what you told me, we’re in that ballpark. Are you still interested?”
As a small business owner, I think that the CEO/CIO/CFO needs the best information they can get at this time. After all, you can’t determine the potential return on investment (ROI) without good information, right? Beyond that, if you can tell a C*O with some accuracy how much an application is going to cost, you’re a valuable person to have around.
Application size can be estimated by ILFs alone
Once I learned FPA — and then learned some of the secret techniques of FPA — I knew that there was a way to provide good cost estimates early in the software project lifecycle.
The first time the light bulb went on for me was when I was looking at all the data the FPA people have collected over the last 25 years and found this important piece of information:
On a typical software development project, there are approximately 35 function points for each ILF in the project.
For example, if you look only at the number of ILFs on a project, and determine there are 20 ILFs in the project, the odds are very good that the overall number of function points on the project will be right around 700 (35 FPs/ILF * 20 ILFs). I'm not saying that they'll be exactly 700, but on a typical project, they should be right around 700. (There are reasons this number works out the way it does, but those reasons are beyond the scope of this article.)
(“ILF” stands for Internal Logical File, a concept that’s a little like a database table or OOP “object” ... but not quite the same.)
Estimating the total number of hours
A lot of people might look at that piece of information and not know what to do with it, but there’s a simple formula that works with this piece of information to give you a cost estimate:
(NumberOfILFs) * (35 FP/ILF) * (NumberOfHoursPerFP) = Total Number of Hours
As you can see from that equation, there are only two pieces of information needed to get to “Total Number of Hours”. First, you need to know NumberOfILFs (the Number of ILFs) in the project. As mentioned, if you know what you’re doing, you can get close to knowing that number, especially if you’re talking to the right people.
The second variable you need to know is NumberOfHoursPerFP, i.e., the number of hours per function point that your team delivers. This variable is known by various names, including productivity rate. In a mature software development organization, and under the right conditions, this can also be fairly easy. For an average business application, the main piece of information you need is the historical productivity rate of the developers that will work on this project. Other factors can be the type of project, and number of users, but for an average business application, those are not major concerns.
When I started with FPA, my company had no idea what our productivity rate was, but because we were a consulting firm and billed our customers for our time, we did have good historical records, both for the software we created, and how much labor time it took to create them.
books by alvin
 |
 |
 |
 |
