By Todd Merry
Arguably, the toughest part of any project is estimating its cost and/or schedule. My wife has always teased me about my ability to estimate when I will leave work and it being inversely proportional to the importance of me getting home at a specific time. Even the best laid plans get washed out the door by those last minute status reports, phone calls, Jira worklog entries and sometimes even beer o’clock. Maybe I just need a better estimating technique!
A method to the madness
Once you’ve recognized that you need to stop what you’re doing long enough to do an estimate, you now need to figure out what approach to estimating you should take. Entire volumes have been written on how to perform estimates. In my mind, there are 3 traditional types of estimating, which I will list here in their order of accuracy starting with the least accurate:
- Ballpark Estimate or Guesstimate,
- Top-down Estimate and,
- Bottom-up estimate
Each type of estimate serves a purpose depending on the stage of the project that you’re at. The ballpark estimate is the quickest to produce but the least accurate and is typically used early on in the project to simply get a sense for the size of a project. At the other end of the spectrum, the Bottoms-up estimate takes the most time to produce but can be quite accurate and is used at any time when a highly accurate estimate is needed. Bidding on a fixed-bid project comes to mind!
The Top-down or Analogous estimate, takes a moderate amount of effort to produce, yet is still fairly accurate. Conceptually, the approach simply compares a new project to one that has been done in the past, taking into consideration what is different about the new project and adjusting the estimate accordingly.
Some might ask, “What if I’ve never done a project like this before?” which is fairly common in the innovation driven software development world! In comes the Function Point Analysis (FPA) estimating process, providing a toolkit to consistently and easily produce an accurate estimate for just about any software development project, using historical project data that has been collected for almost 50 years.
Ugh you say! Anything with the word Analysis in its name must require a PHD to understand and use. Not so. Let me get you started with some key concepts that, once understood, should make using this toolkit as easy as counting sheep. Maybe not the best analogy to use here considering the exciting topic of estimating, but please bear with me!
Honoring the Socratic Paradox
“I know that I know nothing at all.” – Socrates
It is quite common for any developer to feel uncomfortable when requested to estimate a development project that they know absolutely nothing about. The trick is to break the project down into smaller chunks that are recognizable, and then estimate these chunks. Then you simply aggregate the estimates for all these chunks together to arrive at an estimate for the project as a whole. Sound simple? It is, using Function Points as a basis for identifying the chunks!
Function Points, at their simplest level of understanding, fall into 5 categories:
- Inputs,
- Outputs,
- Queries,
- Internal Files and,
- External Files
Well that seems simple enough, right? I strongly suggest following some guidelines to help you distinguish between these 5 types of Function Points, because, in the real world, there are always gray areas. It will make it easier for you to identify the function points and ultimately provide for a more accurate result when all is said and done.
Keep it Simple Stupid (K.I.S.S.)
The KISS principle should be applied here. I found, when I performed my first FPA or two, that I kept getting stuck with deciding whether a particular function point was an Input or an Output. My recommendation is to follow your instincts and allow these simple definitions to guide your identification and categorization of the function points. In the end, I found it beneficial to have at least identified the function point rather than to have missed it all together. So here goes:
Inputs – This is how an application gets information. The most obvious example is a data input field on a screen.
Outputs – Information that leaves the application, whether by report, file or screen. Information that leaves the application can be used by another application or by the user.
Queries – A process by which both inputs and outputs are utilized in data retrieval from one or more Internal or External Files. Ah, but we haven’t yet defined what internal and external files are!
Internal Files – a group of logically related data that is contained within the system that you are estimating AND is maintained by one or more Inputs to the system.
External Files – a group of logically related data that is not contained within the system you are estimating and/or is maintained by another applications inputs. External files are for reference purposes only within the bounds of the system you are estimating. An example would be an Address Book application that provides an extract of employee addresses (via an external file) to an HR application.
The complexities with identifying whether something is an external or internal file can be overwhelming at times. When you become confused with how to categorize something, it helps to step back and think of the business functions that you are planning to create with this new system. In the example above, the HR application that you are planning to create will not be responsible for creating an employee address file or function. The data exists outside of the boundary of the HR application, in an external file that is maintained by a separate and distinct application (the Address book application). This helps define scope for your project too!
I’ve given you an inch
Now that I’ve described to you the basics of what a Function Point is, now what do you do? Well, rather than write a lengthy book (this is just a blog!), I think I’ll simply point you to some great references where you can find examples of each of the 5 types of Function Points, as well as what is involved with what to do after you’ve categorized them.
In a future installment, I’ll likely attempt to take you, the reader, into a deeper dive that will explore some real world situations where performing an FPA was beneficial.
References
- International Function Point Users Group – www.ifpug.org
- Function Point Training Guide
- Function Point Quick Reference Card