How useful is it to measure function points?
We use function points at my new job. I've heard of function points but haven't had any training or experience... but I don't have much confidence in things that cannot be explained succinctly.
Personally, I have never found an explicit answer to the question "What is a Function Point?" Without such, I'm REALLY hesitant about any estimating methodology that claims to do anything with Function Points.
The single most important part of a serious software estimation methodology is "periodic recalibration to actuals", which means you make your estimate, you write it down, and then, when the project is over, you compare your actual results to your estimate, and, if necessary, revise your estimating process. INCLUDED IN THAT is comparing your the INPUTS to your estimating process with the ACTUAL INPUTS.
If, for example, you estimate Source Lines of Code (SLOC), and go from there, you have to compare your actual delivered SLOC with your estimated SLOC, and see whether, how far, and where and why you went astray. An estimator that predicts man-hours perfectly, given an accurate and precise SLOC estimate in, is not going to do you any good if your SLOC estimates are worthless. Garbage in, garbage out. (The same thing applies to Function Points.)
If your SLOC (or Function Point) actuals match your initial estimates, then you can look at your cost actuals against your estimated costs, and adjust your estimator parameters to improve your results. General Dynamics/Fort Worth Division did this exercise, in detail, in the early 1980s, for F-16C/D software development, and then for several years would routinely bet the company bottom line on those estimates. GD/FW was GD's cash cow for quite a while, keeping the rest of the firm afloat, so they must have been doing something right.
And note that requirements and feature creep is THE ENEMY of software estimation.
(This is a later edit.) Bernd's last point deserves an answer. He asks what should be done about projects that come in early, and don't expend all their allocated man-hours.
This is just as much an estimating error as the (far more common) schedule overruns. The fact of the matter is this: if all of your projects are overrunning their schedule, your estimating folks are not doing their job.
If your estimating folks are doing everything right, and your managers are doing everything right, then you are going to have some projects come in early, along with the ones that come in late. Estimates are probabilities. Shade your estimator to eliminate schedule underruns, and you BY DEFINITION increase the probability of schedule overruns. If your management demands schedules and estimates with zero possibility of underrun, then you are going to be delivering schedules that WILL be overrun, guaranteed, and then you will start seeing demands for Death Marches, and then you start seeing resignations, and your overruns get much, much worse, as you try to recruit replacements (and the word gets out that your company is a sweatshop).
When dealing with the scope of a project, generally it is better to use a measure of Function Points rather than Lines of Code. Because software projects can have upwards of millions of LOC (including LOC in libraries) the number becomes relatively meaningless.
How do you measure LOC if you're calling functionality from libraries? Do you include LOC from libraries? If you don't include LOC from libraries, does your boss not thing you're writing enough LOC?
Generally, it is better to say "I completed XXX functionality" rather than "I wrote XXX lines of code".
Also, this COCOMO II Manual gives a detailed description of Function Points and LOC around page 11. Hopefully that's enough for you to go on.
In my experience, the companies that I've seen use function points are only one step above pure madness.
I work in an organization where we introduced function points for calculating fixed price projects, i.e. customer and we count based on specs, agree the count and then multiply the #FP with a FP price in order to determine the project price. All this in an environment with two-digit Million Euro yearly project turnover. Intention is to remove ambiguity and negotiation from price determination which was a constant cause of friction.
We have done an initial calibration, evaluating about 2 years of project history worth two-digit Million Euro.
We clearly see that #FP and project costs correllate very indirectly. Deviations of +/- 50% are reasonably possible. However, we see (well we expect, or better: we hope) that in the long run function point counts and project costs converge.
We are now in the process of rolling this out into the organization and experience (from a suppier point of view):
They seem to be marginally useful at expressing the complexity of a given system/component, and can help managers/team leads apportion work, but they're not really any more useful than any other synthetic/arbitrary metrics (SLOC, Cyclomatic Complexity, etc.) That is, they may give an indication of the relative amount of effort required for specific parts of a system, but there's no way to map them to concrete estimates.