Thursday, May 26, 2005

Software Estimation (Part 1) - What method to use

"If a woman can have a baby in nine months, why can't nine women have a baby in one month?"

I think that is from The Mythical Man-Month, but it's been so long since I read it, I'm not sure. The thought is still valid, though, especially when applied to software estimation. Almost always, the concept of adding developers to a project late in the game is raised by non-technical managers in charge of a project when they see the schedule slipping. Many times, the manager's expected timeframe for building the software has nothing to do with the actual project and is driven by external business forces. I've seen CEO's put an idea for a new system and a request for a confirmation of their time guestimate into a single sentence. "Hey, Mike, it should only take you about three months to build a new system that automates our inventory system, right?" It can be quite a shock getting a question like this.

There are really only two ways you can respond to a statement like this:
  1. Capitulate and agree just to get the ball rolling. This does a disservice to the executive who now thinks he/she knows how to estimate software. Plan on getting more requests like this. You'll look like a software guru for a short period of time until you have to have your first meeting where you have to tell everybody that it's probably going to take 9 months. That's when the executive says that he meant the "office supplies" inventory, not our product inventory. It seemed like you were spending a lot of time in the shop.
  2. Hedge. Let the executive know that you will need to do some work to get the details of the new system down on paper before you can commit to a schedule.
As an industry, I think we shoulder a lot of the blame for encouraging this type of thinking. I can't tell you how many times I've seen a developer group start writing test code as soon as they refill their coffee cup after their 2 minute discussion with the executive in the hallway on their way to the kitchen.

Our businesses need us to provide a regimented way of analyzing projects and producing consistent estimates of project size. There have been many attempts at doing this over the years. Systems like Cocomo, sloc and various statistical methods have been developed to try to solve this problem. Most have proven to be unreliable or difficult to implement. Some, like counting lines of code, have been proven to be flat out wrong.

Probably the best method for estimating software size and effort is Function Point Counting. Function Point Counting has many laudable features including:
  1. Standardization of approach - there is a set of comprehensive rules that can be followed to produce consistent estimates of project size.
  2. It's verifiable - you can have two analysts working under a common set of assumptions come up with the same estimate.
  3. It's objective - you can take your finger and point to a line and say "This part of the estimate is incorrect"
  4. It is aware of the differences between the initial estimate of a new piece of software and estimates for changes or modifications to an existing piece of software.
  5. It includes a post mortem estimate so you can track how you did.
  6. Precision - estimation errors are handled to some degree by abstracting actual feature counts to generalizations of complexity.
  7. The estimate is built from the users point of view.
  8. It's platform independent and tunable.
Sounds great, so why doesn't everybody use it? Well, there are a few problems.
  1. It's very time consuming - you can use a significant amount of your project budget just putting together your estimate.
  2. It has a pretty steep learning curve. Getting good at function point counting takes time, effort and review by others good at fp counting.
Here's the deal breaker: You can't do a decent fp count until you have a relatively complete software design. Most people won't have something like that until after the first two phases of their project (inception and elaboration). By the time you are able to pull an estimate together using function points, you may be as much as 1/3 of the way through your project. Not acceptable.

After looking at the function point method for a while, it becomes obvious that if you could increase some of the levels of abstraction that you might be able to base your estimate on use cases instead of attributes of the project. Gustav Karner proposed this concept as part of his university thesis, but I haven't been able to find his work online anywhere. A synopsis of his work can be found at http://www.bfpug.com.br/Artigos/UCP/Damodaran-Estimation_Using_Use_Case_Points.pdf.

There are some additional guidelines that we have to put into practice to consider using Use Case Point, but I'll get to that later.

I think this approach currently provides our best opportunity to produce workable estimates quickly and early in the project life-cycle.

Next: Nuts and Bolts.

Part 1: What Method to Use
Part 2: Nuts and Bolts
Part 3: Working with the Factors

1 comment:

  1. Estimation is easily one of the most hotly debated topics in the software development world (the word development used broadly). I have always wondered why the industry has not consolidated on set of components needed to create an estimate. I have always been happy with the construct of an estiamte being a function of size, complexity and project attributes that leverages a productivity curve.

    The current Software Process and Measurement Cast (www.spamcast.net) includes an interview on estimatin with Murali Chemuturi. The interview adds a different perspective.

    ReplyDelete