A software estimation technique.  Its proponents reckon it is accurate to about 10%. There was a quick rundown at http://www-isds.jpl.nasa.gov/cwo/cwo_23/handbook/funptana.htm, but that Contract Work order is now closed and the associated pages are no longer available through that link. TomDeMarco would have us all go to school to learn this. He may be right - it's less than the lifetime's experience (and then some) required to master IdealProgrammingTime.

-- MattRickard

I did learn this at school, both my software engineering post-grad courses covered it in some depth. There is a definite whiff of black magic to it. I suspect that people who do well with FPA are good estimators anyway, there's plenty of leeway in the algorithm. And it has the same fundamental problem as CoCoMo, it estimates the size of the ''solution'' not the size of the ''problem''

''Is there any way of getting around that?  The standard candles of problems "Easier Said Than Done" are such things as FermatsLastTheorem, the Mandelbrot set and cryptanalysis.  -- MattRickard''

Pass. Ask a estimation guru. This is ''the'' problem, although I'm not sure your EStD examples are all that relevant to software requirements/estimating.

The Object Factory (http://www.theobjectfactory.com/) claim to have a tool that addresses this (using some top-secret proprietary maths), that bolts onto various CASE tools. It seems to work on, err, "Use-case points", or something similar.

I applied FPA to one of the programming assignments on one of the PG courses. The results were an order of magnitude out.

-- KeithBraithwaite
----
See IdealProgrammingTimeHomeworkAssignment.
----
A bit outdated perhaps. Also, it seems to be ''closed'', not extensible. More like a 4GL than an OOPL.

Nonetheless, FunctionPointAnalysis is soon to have an ISO standard - see http://www.isbsg.org/isbsg.nsf/weben/ISO%20Std%20for%20Functional%20Size%20Measurement .  This should ensure that it goes the way of flowcharts, COBOL and C++.

-- MattRickard

''You mean: extensively used today in the real world of commercial software development? OK, if you say so.''

----
From what I have read of it FunctionPointAnalysis seems to be derived from a very limited view of software, i.e. that it is all about database transactions, perhaps through a set of dialog boxes.  As far as I can tell, the FunctionPoint count for something like Quake will be close to zero, so it should be trivial to implement.

-- DaveKirby

See, however, UseCasesAndFunctionPoints

----
In a software development management course I took at Carnegie Mellon, we used FP to estimate the size of a robotics control program. I believe the exercise was intentionally designed to take FP beyond what it was designed to do, to show that it can be adapted. As I recall, everyone's first attempt at FP was at least an order of magnitude off on the high side. It takes practice to get out of the habit of double counting. My first (and only) attempt at FP in the business world hit the nail right on the head. I emailed the professor and asked him what was up. He said it was probably just luck, but "it sure builds confidence". The thing I like best about FP is that it gets you to ask some ''very interesting'' questions about the software to be built. You get to know a system quite well by doing this, even if your estimates are way off. And a "way off" estimate with a repeatable basis is better than no estimate at all, assuming someone wants a prediction of the effort. -- WaldenMathews