There are several remarks to be made about Gustavs method for estimating applications development costs.
First is that, contrary to what has been suggested, the method gives a number of UCP as the size of an application. Some authors on the web incorrectly conclude that Gustav measured hours, not size. But Gustav seems well aware of the distinction when he writes "It starts with measuring the functionality of the system based on the use case model in a count called Unadjusted Use Case Point (UUCP)".
Second, in the reference at the bottom of his post Gustav bases his constants on just 3 projects. That number is of course way to low to base formulas on.
Luckily Bente Anda of the university of Oslo has taken up this issue and evaluated the formulas for 37 projects. The result was that the use case points method gave an estimate that was closer to the actual effort spent on implementing the system than most estimates made by 37 experienced professional software developers divided into 11 groups. It also pointed out that a combination of UCP and experrtt estimates is the best way to go.
Edward R. Carroll claims: After applying the process across hundreds of sizable (60 manmonths average) software projects, we have demonstrated metrics that prove an estimating accuracy of less than 9 percent deviation from actual to estimated cost on 95 percent of our projects. Our process and this success factor are documented
over a period of five years, and across more than 200 projects.
This research at least gives some solid base under the method.
One assumption that nearly all authors make is that it is an absolute must that use cases are on the same detail level. And of course the more detailed Use Cases are, the more accurate the estimates will be. cap gemini even goes so far as to advise to go to "fish level", that is, to distinguish the importnt sugfunctions. They count these subfunctions, and even have a library of type-examples to support these counts.
A valid question is wether it makes sense to count function points based on use cases. The nesma, the dutch function point organization, thinks it does. In an article they detail how the sepcifications for a function point count can be retrieved from use Cases. Of course these are not Use Case Points, they require you are a certified or very experienced FP-expert. And even then it remains some work to distill the FP-details from the Use Cases. Judging from what they write, it is not a quick method.
At a course last week on rup iterative development i was surpised to see that IBM now includes the Gustav use case points in RUP> Imho this greatly improves the chances of this branch winning out, though i foresee much stricter guidelines in the future about the levels of detail in Use Cases than we have now, just to ensure that estimates will
"Sander, could you estimate the hours for this project?"
"Boss, sure, how much time do I have?"
"Sander, I guess I should have asked this earlier, but I must have the estimate in 1 hour if we want to have this order."
50 minutes later:
"Boss, In 1 hour of course I can not give a thorough estimate. But if you want to have a completely arbitrary number: we have 10 classes, and 180 pages in the RFP document, so I estimate the effort at 10*180=1800 hours."
1 week later:
"Sander, good news: our offer has been approved based on your estimate and you are in the team!"
Several months later:
"Boss, we finished the project is slightly under 1800 hours."
* http://royclemmons.com/articles/docs/0602Clemmons.pdf Article by Roy Clemmens
* Carroll, Edward R. “Estimating Software Based on Use Case Points.” 2005 Object-Oriented, Programming, Systems, Languages, and Applications (OOPSLA) Conference, San Diego, CA, 2005.