I was an IFPUG Certified Function Point Specialist from 2002-2005, and I still use them to estimate business applications (web-based and thick-client). My experience is mostly with smaller projects (1000 FP or less).
I settled on Function Points after using Use Case Points and Lines of Code. (I've been actively working with estimation techniques for 10+ years now).
Some questions about Function Points:
1) Is it a reasonably precise way to do estimates? (I'm not unreasonable here, but just want to know compared to other estimation methods)
Hard to answer quickly, as it depends on where you are in the lifecycle (from gleam-in-the-eye to done). You also have to realize that there's more to estimation than precision.
Their greatest strength is that, when coupled with historical data, they hold up well under pressure from decision-makers. By separating the scope of the project from productivity (h/FP), they result in far more constructive conversations. (I first got involved in metrics-based estimation when I, a web programmer, had to convince a personal friend of my company's founder and CEO to go back to his investors and tell them that the date he had been promising was unattainable. We all knew it was, but it was the project history and functional sizing (home-grown use case points at the time) that actually convinced him.
Their advantage is greatest early in the lifecycle, when you have to assess the feasibility of a project before a team has even been assembled.
Contrary to common belief, it doesn't take that long to come up with a useful count, if you know what you're doing. Just off of the basic information types (logical files) inferred in an initial client meeting, and average productivity of our team, I could come up with a rough count (but no rougher than all the other unknowns at that stage) and a useful estimate in an afternoon.
Combine Function Point Analysis with a Facilitated Requirements Workshop and you have a great project set-up approach.
Once things were getting serious and we had nominated a team, we would then use Planning Poker and some other estimation techniques to come up with an independent number, and compare the two.
2) And is the effort required worth the benefit you get out of it?
Absolutely. I've found preparing a count to be an excellent way to review user-goal-level requirements for consistency and completeness, in addition to all the other benefits. This was even in setting up Agile projects. I often found implied stories the customer had missed.
3) Which type of Function Points do you use?
IFPUG CPM (Counting Practices Manual) 4.2
4) Do you use any tools for doing this?
An Excel spreadsheet template I was given by the person who trained me. You put in the file or transaction attributes, and it does all of the table lookups for you.
As a concluding note, NO estimate is as precise (or more precisely, accurate) as the bean-counters would like, for reasons that have been well documented in many other places. So you have to run your projects in ways that can accommodate that (three cheers for Agile).
But estimates are still a vital part of decision support in a business environment, and I would never want to be without my function points. I suspect the people who characterize them as "fantasy" have never seen them properly used (and I have seen them overhyped and misused grotesquely, believe me).
Don't get me wrong, FP have an arbitrary feel to them at times. But, to paraphrase Churchill, Function Points are the worst possible early-lifecycle estimation technique known, except for all the others.
No because any particular requirement can have an arbitrary amount of effort based on how precise (or imprecise) the author of the requirement is, and the level of experience of the function point assessor.
No because administration of imprecise derivations of abstract functionality yield no reliable estimate.
None if I can help it.
Tools? For function points? How about Excel? Or Word? Or Notepad? Or Edlin?
Yes they are more precise than anything else I have encountered (in 20+ years).
Yes they are well worth the effort. You can estimate size, resources, quality and schedule from just the FP count - extremely useful. It takes an average of 1 minute to count an FP manually and an average of 8 hours to fully code an FP (approximately $800 worth). Consider the carpenter's saying of "measure twice cut once". And now a shameless plug: with https://www.ScopeMaster.com you can measure 1 FP per second, and you don't need to learn how!
I like Cosmic Function Points (because they are versatile) and IFPUG because there is a lot of published data (mostly from Capers Jones).
Having invested considerable time, effort and money in developing a tool that counts FPs automatically from requirements, I shall never have to do it manually again!
From what I have study about Function Point (one of my teacher was highly involved in the process of the theory of function point) and he wasn't able to answer all our answers.Function point fail in many way because it's not because you have something read or write that you can evaluate correctly. You might have a result of 450 functions points and some of these function point will take 1 hour ans some will take 1 weeks. It's a metric that I will never use again.
Joel on Software 有一个合理的替代方案，称为基于证据的调度，该方案位于至少听起来可能有效......
The great hacknot is offline now, but it is in book form. He has an essay on function points: http://www.scribd.com/doc/459372/hacknot-book-a4, concluding they are a fantasy (which I agree with).
Joel on Software has a reasonable sound alternative called Evidence based scheduling that at least sounds like it might work....
Mike Cohn in his Agile Estimating and Planning consider FPs to be great but difficult to get right. He (obviously) recommends to use story points-based estimation instead. I tend to agree with this as with each new project I see the benefits of Agile approach more and more.
1) Is it a reasonably precise way to do estimates? (I'm not unreasonable here, but just want to know compared to other estimation methods)
As far as estimation precision goes the functional points are very good. In my experience they are great but expensive in terms of effort involved if you want do it properly. Not that many projects could afford an elaboration phase to get the FP-based estimates right.
2) And is the effort required worth the benefit you get out of it?
FPs are great because they are officially recognised by ISO which gives your estimations a great deal of credibility. If you work on a big project for a big client it might be useful to invest in official-looking detailed estimations. But if the level of uncertainty is big to start with (like other vendors integration, legacy system, loose requirements etc.) you will not get anywhere near precision anyway so usually you have to just accept this and re-iterate the estimations later. If it is the case a cheaper way of doing the estimates (user stories and story points) are better.
3) Which type of Function Points do you use?
If I understand this part of your question correctly we used to do estimations based on the Feature Points but gradually moved away from these an almost all projects expect for the ones with heavy emphasis on the internal functionality.
4) Do you use any tools for doing this?
Excel is great with all the formulas you could use. Using Google Spreadsheets instead of Excel helps if you want to do that collaboratively.
There is also a great tool built-in to the Sparx Enterprise Architect which allows you to do the estimates based on the Use Cases which could be used for FP estimations as well.
发布评论
评论（6）
从 2002 年到 2005 年，我是一名 IFPUG 认证功能点专家，现在我仍然使用它们来评估业务应用程序（基于 Web 的和胖客户端）。 我的经验主要是较小的项目（1000 FP 或更少）。
在使用用例点和代码行之后，我决定使用功能点。 （我已经积极研究估计技术十多年了）。
很难快速回答，因为这取决于您在生命周期中的位置（从闪闪发光到完成）。 您还必须认识到，估算的意义不仅仅在于精确度。
它们最大的优势在于，结合历史数据，它们能够在决策者的压力下保持良好的状态。 通过将项目范围与生产力 (h/FP) 分开，它们会产生更具建设性的对话。 （我第一次涉足基于指标的估算是在我，一名网络程序员，不得不说服我公司创始人兼首席执行官的一位私人朋友回到他的投资者那里，告诉他们他所承诺的日期是无法实现的。我们都知道是这样，但真正说服他的是项目历史和功能规模（当时的本土用例点），
它们的优势在生命周期的早期是最大的，此时你必须在项目开始之前评估项目的可行性。 与普遍看法相反，如果您知道自己在做什么，
只需从初始推断的基本信息类型（逻辑文件）中得出有用的计数即可。 得出一个粗略的计数（但不会比该阶段的所有其他未知数更粗略）和一个有用的估计。
客户会议，以及我们团队的平均生产力，我可以在一个下午将功能点分析与简化的需求研讨会结合起来， 有一个很好的项目设置方法。
一旦事情变得严重并且我们提名了一个团队，我们就会使用规划扑克和其他一些估计技术来得出一个独立的数字，并对两者进行比较。
绝对地。 我发现除了所有其他好处之外，准备计数是检查用户目标级别要求的一致性和完整性的绝佳方法。 甚至在建立敏捷项目时也是如此。 我经常发现客户错过的隐含故事。
IFPUG CPM（计数实践手册）4.2
培训我的人给了我一个 Excel 电子表格模板。 您输入文件或事务属性，它会为您执行所有表查找。
作为结论，任何估计都不像精算师所希望的那样精确（或更准确地说，准确），原因在许多其他地方都有详细记录。 因此，您必须以能够适应这种情况的方式运行您的项目（为敏捷欢呼三声）。
但估计仍然是商业环境中决策支持的重要组成部分，我永远不想没有我的功能点。 我怀疑那些将它们描述为“幻想”的人从未见过它们被正确使用（相信我，我见过它们被过度炒作和怪诞地误用）。
不要误会我的意思，FP 有时对他们有一种武断的感觉。 但是，套用丘吉尔的话来说，除了所有其他技术之外，功能点是已知的最糟糕的早期生命周期估计技术。
I was an IFPUG Certified Function Point Specialist from 2002-2005, and I still use them to estimate business applications (web-based and thick-client). My experience is mostly with smaller projects (1000 FP or less).
I settled on Function Points after using Use Case Points and Lines of Code. (I've been actively working with estimation techniques for 10+ years now).
Hard to answer quickly, as it depends on where you are in the lifecycle (from gleam-in-the-eye to done). You also have to realize that there's more to estimation than precision.
Their greatest strength is that, when coupled with historical data, they hold up well under pressure from decision-makers. By separating the scope of the project from productivity (h/FP), they result in far more constructive conversations. (I first got involved in metrics-based estimation when I, a web programmer, had to convince a personal friend of my company's founder and CEO to go back to his investors and tell them that the date he had been promising was unattainable. We all knew it was, but it was the project history and functional sizing (home-grown use case points at the time) that actually convinced him.
Their advantage is greatest early in the lifecycle, when you have to assess the feasibility of a project before a team has even been assembled.
Contrary to common belief, it doesn't take that long to come up with a useful count, if you know what you're doing. Just off of the basic information types (logical files) inferred in an initial client meeting, and average productivity of our team, I could come up with a rough count (but no rougher than all the other unknowns at that stage) and a useful estimate in an afternoon.
Combine Function Point Analysis with a Facilitated Requirements Workshop and you have a great project set-up approach.
Once things were getting serious and we had nominated a team, we would then use Planning Poker and some other estimation techniques to come up with an independent number, and compare the two.
Absolutely. I've found preparing a count to be an excellent way to review user-goal-level requirements for consistency and completeness, in addition to all the other benefits. This was even in setting up Agile projects. I often found implied stories the customer had missed.
IFPUG CPM (Counting Practices Manual) 4.2
An Excel spreadsheet template I was given by the person who trained me. You put in the file or transaction attributes, and it does all of the table lookups for you.
As a concluding note, NO estimate is as precise (or more precisely, accurate) as the bean-counters would like, for reasons that have been well documented in many other places. So you have to run your projects in ways that can accommodate that (three cheers for Agile).
But estimates are still a vital part of decision support in a business environment, and I would never want to be without my function points. I suspect the people who characterize them as "fantasy" have never seen them properly used (and I have seen them overhyped and misused grotesquely, believe me).
Don't get me wrong, FP have an arbitrary feel to them at times. But, to paraphrase Churchill, Function Points are the worst possible early-lifecycle estimation technique known, except for all the others.
回答您的问题：
是的，它们比我（20 多年来）遇到的任何其他东西都更精确。
是的，他们非常值得付出努力。 您可以仅根据 FP 计数来估计规模、资源、质量和进度 - 非常有用。 手动计算 FP 平均需要 1 分钟，完整编码 FP 平均需要 8 小时（价值约 800 美元）。 考虑一下木匠的说法“测量两次，切割一次”。 现在是一个无耻的插件：使用 https://www.ScopeMaster.com 你可以每秒测量 1 FP，而且您无需学习如何操作！
我喜欢 Cosmic Function Points（因为它们用途广泛）和 IFPUG，因为有很多已发表的数据（主要来自 Capers Jones）。
我投入了大量的时间、精力和金钱来开发一个根据需求自动计算 FP 的工具，我再也不需要手动执行此操作了！
To answer your questions:
Yes they are more precise than anything else I have encountered (in 20+ years).
Yes they are well worth the effort. You can estimate size, resources, quality and schedule from just the FP count - extremely useful. It takes an average of 1 minute to count an FP manually and an average of 8 hours to fully code an FP (approximately $800 worth). Consider the carpenter's saying of "measure twice cut once". And now a shameless plug: with https://www.ScopeMaster.com you can measure 1 FP per second, and you don't need to learn how!
I like Cosmic Function Points (because they are versatile) and IFPUG because there is a lot of published data (mostly from Capers Jones).
Having invested considerable time, effort and money in developing a tool that counts FPs automatically from requirements, I shall never have to do it manually again!
根据我对功能点的研究（我的一位老师高度参与了功能点理论的过程），他无法回答我们所有的答案。功能点在很多方面都失败了，因为这不是因为你有您可以正确评估的读或写的东西。 您可能会得到 450 个功能点的结果，其中一些功能点需要 1 小时，有些需要 1 周。 这是一个我永远不会再使用的指标。
From what I have study about Function Point (one of my teacher was highly involved in the process of the theory of function point) and he wasn't able to answer all our answers.Function point fail in many way because it's not because you have something read or write that you can evaluate correctly. You might have a result of 450 functions points and some of these function point will take 1 hour ans some will take 1 weeks. It's a metric that I will never use again.
伟大的黑客现在离线了，但它是书的形式。 他有一篇关于功能点的文章： http://www.scribd.com/ doc/459372/hacknot-book-a4，结论是它们是一个幻想（我同意）。
Joel on Software 有一个合理的替代方案，称为基于证据的调度，该方案位于至少听起来可能有效......
The great hacknot is offline now, but it is in book form. He has an essay on function points: http://www.scribd.com/doc/459372/hacknot-book-a4, concluding they are a fantasy (which I agree with).
Joel on Software has a reasonable sound alternative called Evidence based scheduling that at least sounds like it might work....
Mike Cohn 在他的敏捷估算和规划中认为 FP 很棒，但很难获得正确的。 他（显然）建议改用基于故事点的估计。 我倾向于同意这一点，因为在每个新项目中，我越来越多地看到敏捷方法的好处。
1) 这是一种相当精确的估算方法吗？ （我在这里并不是无理取闹，只是想知道与其他估计方法相比）
就估计精度而言，功能点非常好。 根据我的经验，如果你想正确地做到这一点，它们很棒，但就所涉及的努力而言，它们是昂贵的。 并不是很多项目都能承担起细化阶段来获得正确的基于 FP 的估算。
2）所需的努力是否值得您从中获得的收益？
FP 很棒，因为它们得到了 ISO 的正式认可，这使您的估计具有很大的可信度。 如果您为大客户处理一个大项目，那么投资于官方的详细估算可能会很有用。 但是，如果一开始的不确定性很大（如其他供应商集成、遗留系统、宽松的要求等），那么您无论如何都无法获得接近精确的结果，因此通常您必须接受这一点，并在以后重新进行估计。 如果是这种情况，更便宜的估算方法（用户故事和故事点）会更好。
3）您使用哪种类型的功能点？
如果我正确理解了您问题的这一部分，我们过去常常根据功能点进行估计，但逐渐远离这些功能点，几乎所有项目都期望非常注重内部功能的。
4) 您是否使用任何工具来执行此操作？
Excel 非常适合您可以使用的所有公式。 如果您想协作完成此操作，使用 Google 电子表格而不是 Excel 会有所帮助。
Sparx Enterprise Architect 还内置了一个很棒的工具，它允许您根据也可用于 FP 估计的用例。
Mike Cohn in his Agile Estimating and Planning consider FPs to be great but difficult to get right. He (obviously) recommends to use story points-based estimation instead. I tend to agree with this as with each new project I see the benefits of Agile approach more and more.
1) Is it a reasonably precise way to do estimates? (I'm not unreasonable here, but just want to know compared to other estimation methods)
As far as estimation precision goes the functional points are very good. In my experience they are great but expensive in terms of effort involved if you want do it properly. Not that many projects could afford an elaboration phase to get the FP-based estimates right.
2) And is the effort required worth the benefit you get out of it?
FPs are great because they are officially recognised by ISO which gives your estimations a great deal of credibility. If you work on a big project for a big client it might be useful to invest in official-looking detailed estimations. But if the level of uncertainty is big to start with (like other vendors integration, legacy system, loose requirements etc.) you will not get anywhere near precision anyway so usually you have to just accept this and re-iterate the estimations later. If it is the case a cheaper way of doing the estimates (user stories and story points) are better.
3) Which type of Function Points do you use?
If I understand this part of your question correctly we used to do estimations based on the Feature Points but gradually moved away from these an almost all projects expect for the ones with heavy emphasis on the internal functionality.
4) Do you use any tools for doing this?
Excel is great with all the formulas you could use. Using Google Spreadsheets instead of Excel helps if you want to do that collaboratively.
There is also a great tool built-in to the Sparx Enterprise Architect which allows you to do the estimates based on the Use Cases which could be used for FP estimations as well.