Bonus: How to estimate extremely early in the lifecycle

If you're experienced with FPA and you really know what an Internal Logical File (ILF) is, you can use IFPUG data very early in the software development lifecycle (i.e., in RUP's "inception" phase) to make "back of the envelope" calculations to perform estimates.

The way this works is pretty simple. If you can accurately determine the ILFs in your "planned" application, IFPUG historical data shows that the average number of function points per ILF is about 35 (35 FPs/ILF). Add to this your knowledge that your development team productivity rate is about 4.0 hours/FP, and you can approximate the number of hours using the ILFs alone.

As an example, suppose that you're thinking about developing a simple personal-productivity web application, and during your initial brainstorming you've learned that your application needs to maintain the following objects:

1. Users
2. Memos
3. Tasks
4. Contacts
5. Appointments

(I'll stop here to keep this simple.)

Knowing that the application has five ILFs, and typical applications have about 35 FPs/ILF, it looks like this application is going to have 175 FPs.

Now, because I further know that applications at our organization historically grow by 25% from inception through elaboration, I'll increase this number to 219 FPs.

Next, because we also have a historical database of application development for our company, I can look up our productivity rate for applications of this size and type. At this size we have averaged 2.0 hours/FP, so my initial estimate is 438 hours.

To reiterate, this is very early in the process - we're just brainstorming. But if we know the ILFs in the planned application, and we have historical information about our development team's productivity, and we also know other characteristics about the planned application, it's perfectly viable to make these assumptions and use these numbers.

Of course you can also do the normal WBS work, and then use the correct multiplier, but I believe this approach is both easier and more accurate (especially for larger projects).

The Cone of Uncertainty

It's always right about this time that I tell people about Steve McConnell's Cone of Uncertainty. The Cone of Uncertainty says that the farther you are from the project finish line, the less certain you can be about your estimate. In fact, the only time you can truly know the cost of a project is when you're done. And right now, when we're just talking about an application, so we're about as far away from the finish line as you can imagine.

That being said, I've used this approach quite a few times with good success, but it all comes back to having historical performance information for your team.

Up: Cost-Estimating Previous: References   Contents