About ten years ago, a drinking buddy of mine gave me a really great piece of wisdom. On any project consultation, ask three questions: 1. What is the problem we are trying to solve? 2. What are the deliverables? 3. How will we know when we are done? He added that one should never take on any project for which any of the questions was not answered before the project starts.
In the case at hand, we have yet another Software Estimating Method horror story, in which the estimate seems ridiculously high. I would answer his horror story by pointing out that he has not given answers to the second and third questions, and he hasn't really answered the first, except to say "We want to build something that works something like this."
I would expand on that by pointing out that he explicitly has not even asked what tasks the Function Points estimate is including or excluding from the estimated total. How much extra effort is the function point estimator allowing for documentation, for example? If his estimate is for the application, without any documentation, and the function point estimator's estimate was for the application with full documentation, well, I'd say there's some room for disagreement on the total amount of work (and time) required.
从我所看到的 屏幕截图，这个应用程序是 小型 Excel 改进应用程序。我可以 花 200 美元购买了 MS Office Pro 美元给了我更大的 互操作性（.xls 文件）和 灵活性（电子表格）。
您正在将一款完全定制的软件的价格与销售数百万份的软件进行比较吗？严重地？
Is it just my feeling that it wouldn't take any decent programmer longer than one week (I"m not even saying weekend) to have it completed?
Developers always tend to underestimate how long it takes to actually finish something. They think there will be no bugs, no changes in requirements, and nothing they've never done before and have to spend days on figuring out.
From what I could see from the screenshots, this application is a small excel-improvement app. I could have bought MS Office Pro for 200 bucks which gives me greater interoperability (.xls files) and flexibility (spreadsheets).
You're comparing the price for a completely custom piece of software to one that's selling millions of copies? Seriously?
The reality is, most methods of software estimation actually underestimate, even though at first blush, it seems counter-intuitive. I once worked at a company where 300 lines of code per man-month was considered a HIGH estimate, and most months we came in at more like 200-250. But let's go with the 200. That's 10 lines of code per work day. Who can't write 10 lines of code in a work day? Come on! I could write 50 to 100 or more lines of code on a good day! And yet companies that use numbers like these repeatedly complete their projects behind schedule and over budget. Why is that? Well, scope creep, as Michael Borgwardt suggests, is a big one. But let's pull that out the picture for a minute, and assume the customer and client got it right the first time. Why would a company estimate only 10 lines of code per day?
Analysis of requirements
Software design based on requirements
Meetings to coordinate interfaces and architecture with team-mates.
Overhead costs(status meetings with management, sick-time, vacations, ...)
Writing unit tests
Writing a test plan for the whole applicaiton
Application-level testing
That's all the day-to-day software engineering I can pull off the top of my head in 3 minutes, I'm sure I missed some more, but does that help get a more complete picture of where those estimates are coming from?
Not an FP expert. However we're looking at FP at the moment. In particular we're performing FP analysis against old projects that we have the metrics for effort / cost etc. Then we can assess its usefulness to us in estimation / sizing projects.
My view at this point is that it will be a useful top down 'order of magnitude' estimate to supplement bottom up estimating. It's always good if more than one estimation technique can be applied to help validate that the numbers that are being arrived at 'hold up'.
A further thought - the cost / effort per function point (i.e. functional requirement) would depend on the non-functional requirements that are required for the system. Once you start taking account of security, accessibility, performance, logging (and alerting), maintainability, portability, regulatory compliance and so on, the cost/effort per FP increases significantly. Now these may not be a consideration for the single user sample app quoted. But if this application is important to a company or potentially their customers or a wide proportion of the general public, the need to take into account those non-functional requirements will certainly increase.
Unless you have historical FPA data of previous projects, FPA can definitely end up over-estimating the whole thing, using industry standards.
I learned that VAF is a good pointer to use when dealing with FPA. Although it gives you a 35% variation range on your FP count, who is stopping the analyst/project manager from turning this into a 50% variation.
A good team leader always assesses his teams ability before making estimations. Same goes for FPA, industry standard figures were reached based on historical data, and this data varies from company to company, team to team and developer to developer.
So I would say if you use the best case scenario of -35% on the unadjusted count, you reach an adjusted FP count of ~64. Gives you roughly 3 and half weeks of estimate. From experience i would say an application of this sort CAN be done alot sooner than that, but any thorough testing, debugging, documentation and other paper work would stretch it further and FP takes that into account. It is very much possible that your team is doing 1 FP/hr. By normal standards, coding and testing accounts for 25% of the FP count, so in this case even taking your figure of 99 FPs, the coding and testing part would come down to 25 FPs, which is more understandable given the situation.
What i have also seen in practice is that some companies have devised their own complexity tables, so if 3 RETs and 10 DETs mean average complexity for one company, another would rate it as low complexity. This would largely effect the final FP count.
So use the FP tool as guide and collect as much data for previous projects as you can before you actually start relying on FPA to set out cost and time estimates.
As a side note, i think the costing estimates on a simple software like that would seem ridiculous today, where outsourcing and freelancing is the way to go. Large companies who have been in this business still charge ridiculously high for software development. For instance if you want a level 3 support engineer to help you with your servers in a good hosting company, they would charge $250 per hour, however you can get the same advice from someone based elsewhere in the world at $25 or even $2.5.
I have practised FP in a few projects and found that it provides a fairly accurate estimate. Sometimes it may overestimate and sometimes underestimate depending on type of application. Typically for scientific applications, FP could be underestimated. FP provides for entire project development time, not just the time for writing code. Of course there are no development activities, like setup of test environment, etc and these should be estimated separately. I am not a big proponent of FP, but appreciate its usage. If not accurate estimation, if practised properly (identifying Files and Record Elements), it atleast validates completeness of your requirements.
In a way, we should say that FP is good for medium to large projects, scaling over 350-400 FPs.
Time-based payments lead to lower performance indirectly. I remember projects with time-based payment that I did a lot of research for each aspect of project while if it had a project-based payment method maybe I didn't do so. It's the unconscious mind not ethics. Best practice is to referring "Project" definition (within a limited time and budget) and make decision based on limitations. It's not about the work itself, i.e. you pay for an umbrella in a rainy day much more than when you buy normally. Don't bother yourself about what has done and how much it worth. Focus on the value of the work to the customer and his choices.
Plugging the values from the example you cited into this handy online function point calculator (http://developergeeks.com/functionpoint.aspx), which calculates the adjusted FPs and takes into account various other weighting factors, I get the following results, assuming a productivity rate of 2 FPs per hour since the system in the example is so simple:
Adjusted FPs: 42.9
Estimated Person Months: 0.54
Assuming 160 hours in a working month, that works out to about 86.4 hours, or roughly two work weeks for one developer. Not five weeks as you concluded in step 2. Given that developing systems for paying customers requires taking just a little more care and effort than just banging out some code late at night for your own amusement, I don't think that's an unreasonable estimate at all.
I mean, don't get me wrong, FP analysis in the wrong hands is probably a terrible idea. But if you've got a developer's background you can apply to counting FPs and gut checking the various weighting factors, it's not a bad way to get a reasonable estimate that isn't based on pure fantasy when you don't have detailed design specs, fully documented requirements or a detailed task-level project plan to work from. But you've got to use some common sense to make it work for you.
From my experience with several software metrics, Function Point is really not a lightweight metric. If the hour/FP thing fluctuates so much, then what's the point, maybe I could have gone with User Story Points which is a lot faster to get and arguably almost as uncertain.
The point in having Function Point Analysis is having some kind of rules/guidelines which are objective and standard so that it should (within a certain margin) end up giving you the same amount of function points on an application and/or project, regardless of which expert counted it, if the rules are applied consistently and correct. The productivity per function point, as you discovered, is highly dependable on many factors like team experience, tooling, programming language, platform, etc. etc. Therefore industry standards are nice to know, but in most cases completely useless (in my humble opinion). The main value in repetative counting is building up your own 'benchnmark' based on your own team productivity history. This in turn will help you see trends and also help plan and predict hours needed for future changes. If you're looking for speed, simply apply global counts instead of detailed counts. When doing a few example counts (like when preparing for exams) you will notice the difference between a detailed count and a global count aren't big enough to loose sleep over (by %).
This discussion is absolutely misleading, as the question already supposes FPA is an effort estimation technique. It is not.
Functional size (expressed in functions points) can be one of many input factors for an estimation model (such as COCOMO). Not more - but also not less if we agree that the 'amount' of functional requirements is an effort driver for software projects.
发布评论
评论（11）
大约十年前，我的一个酒友给了我一个非常伟大的智慧。在任何项目咨询中，请提出三个问题： 1. 我们要解决的问题是什么？ 2. 可交付成果是什么？ 3. 我们如何知道何时完成？他补充说，在项目开始之前，任何人都不应该承担任何问题没有得到解答的项目。
在本例中，我们还有另一个软件估算方法的恐怖故事，其中估算值似乎高得离谱。我会通过指出他没有给出第二个问题和第三个问题的答案来回答他的恐怖故事，并且他也没有真正回答第一个问题，只是说“我们想要构建一些可以像这样工作的东西”。
我想对此进行扩展，指出他甚至没有明确询问功能点估计包括或排除在估计总数中的任务。例如，功能点估算器需要为文档做多少额外的工作？如果他的估计是针对没有任何文档的应用程序，而功能点估计器的估计是针对具有完整文档的应用程序，那么我想说，对于所需的工作总量（和时间）存在一些分歧。
About ten years ago, a drinking buddy of mine gave me a really great piece of wisdom. On any project consultation, ask three questions: 1. What is the problem we are trying to solve? 2. What are the deliverables? 3. How will we know when we are done? He added that one should never take on any project for which any of the questions was not answered before the project starts.
In the case at hand, we have yet another Software Estimating Method horror story, in which the estimate seems ridiculously high. I would answer his horror story by pointing out that he has not given answers to the second and third questions, and he hasn't really answered the first, except to say "We want to build something that works something like this."
I would expand on that by pointing out that he explicitly has not even asked what tasks the Function Points estimate is including or excluding from the estimated total. How much extra effort is the function point estimator allowing for documentation, for example? If his estimate is for the application, without any documentation, and the function point estimator's estimate was for the application with full documentation, well, I'd say there's some room for disagreement on the total amount of work (and time) required.
开发人员总是倾向于低估实际完成某件事所需的时间。他们认为不会出现错误，需求不会发生变化，也不会出现他们以前从未做过的事情，并且必须花几天时间来弄清楚。
您正在将一款完全定制的软件的价格与销售数百万份的软件进行比较吗？严重地？
Developers always tend to underestimate how long it takes to actually finish something. They think there will be no bugs, no changes in requirements, and nothing they've never done before and have to spend days on figuring out.
You're comparing the price for a completely custom piece of software to one that's selling millions of copies? Seriously?
现实情况是，大多数软件估计方法实际上都会低估，尽管乍一看似乎违反直觉。我曾经在一家公司工作，每个人月 300 行代码被认为是一个很高的估计，而大多数月份我们的代码大约是 200-250 行。但我们还是选择 200 行吧。即每个工作日 10 行代码。谁不能在一个工作日写 10 行代码？快点！天气好的时候我可以写 50 到 100 行甚至更多行代码！然而，使用此类数字的公司却一再延迟完成项目并超出预算。这是为什么？好吧，正如迈克尔·博格沃特（Michael Borgwardt）所说，范围蔓延是一个很大的问题。但是，让我们稍微了解一下这个情况，并假设客户和客户第一次就做对了。为什么一家公司估计每天只需要 10 行代码？
这就是我可以完成的所有日常软件工程3 分钟内我的头脑，我确信我错过了更多，但这是否有助于更全面地了解这些估计值的来源？
The reality is, most methods of software estimation actually underestimate, even though at first blush, it seems counter-intuitive. I once worked at a company where 300 lines of code per man-month was considered a HIGH estimate, and most months we came in at more like 200-250. But let's go with the 200. That's 10 lines of code per work day. Who can't write 10 lines of code in a work day? Come on! I could write 50 to 100 or more lines of code on a good day! And yet companies that use numbers like these repeatedly complete their projects behind schedule and over budget. Why is that? Well, scope creep, as Michael Borgwardt suggests, is a big one. But let's pull that out the picture for a minute, and assume the customer and client got it right the first time. Why would a company estimate only 10 lines of code per day?
That's all the day-to-day software engineering I can pull off the top of my head in 3 minutes, I'm sure I missed some more, but does that help get a more complete picture of where those estimates are coming from?
不是 FP 专家。然而我们现在正在关注 FP。特别是，我们正在对旧项目进行 FP 分析，我们有工作量/成本等指标。然后我们可以评估它在估计/调整项目规模方面的有用性。
我目前的观点是，这将是一个有用的自上而下的“数量级”估计，以补充自下而上的估计。如果可以应用多种估计技术来帮助验证所得出的数字是否“可靠”，那总是好的。
进一步的思考 - 每个功能点（即功能需求）的成本/工作量将取决于系统所需的非功能需求。一旦开始考虑安全性、可访问性、性能、日志记录（和警报）、可维护性、可移植性、法规遵从性等，每个 FP 的成本/工作量就会显着增加。现在，这些可能不是引用的单用户示例应用程序的考虑因素。但是，如果此应用程序对公司或其潜在客户或广大公众很重要，那么考虑这些非功能性需求的需求肯定会增加。
Not an FP expert. However we're looking at FP at the moment. In particular we're performing FP analysis against old projects that we have the metrics for effort / cost etc. Then we can assess its usefulness to us in estimation / sizing projects.
My view at this point is that it will be a useful top down 'order of magnitude' estimate to supplement bottom up estimating. It's always good if more than one estimation technique can be applied to help validate that the numbers that are being arrived at 'hold up'.
A further thought - the cost / effort per function point (i.e. functional requirement) would depend on the non-functional requirements that are required for the system. Once you start taking account of security, accessibility, performance, logging (and alerting), maintainability, portability, regulatory compliance and so on, the cost/effort per FP increases significantly. Now these may not be a consideration for the single user sample app quoted. But if this application is important to a company or potentially their customers or a wide proportion of the general public, the need to take into account those non-functional requirements will certainly increase.
就我个人而言，我最初发现 FPA 具有误导性。
除非您有以前项目的历史 FPA 数据，否则 FPA 使用行业标准肯定会高估整个事情。
我了解到，在处理 FPA 时，VAF 是一个很好的指针。尽管它为您的 FP 计数提供了 35% 的变化范围，但谁阻止分析师/项目经理将其转变为 50% 的变化。
一个好的团队领导者在做出估计之前总是评估他的团队的能力。 FPA 也是如此，行业标准数据是根据历史数据得出的，并且该数据因公司、团队和开发人员而异。
所以我想说，如果您在未调整的计数上使用 -35% 的最佳情况，则调整后的 FP 计数约为 64。为您提供大约 3 周半的预估时间。根据经验，我想说这种应用程序可以比这更快地完成，但任何彻底的测试、调试、文档和其他文书工作都会进一步扩展它，FP 考虑到了这一点。您的团队很有可能每小时执行 1 FP。按照正常标准，编码和测试占 FP 数量的 25%，因此在这种情况下，即使采用 99 个 FP，编码和测试部分也会减少到 25 个 FP，考虑到这种情况，这更容易理解。
我在实践中还看到，一些公司设计了自己的复杂度表，因此，如果 3 个 RET 和 10 个 DET 意味着一家公司的平均复杂度，那么另一家公司会将其评为低复杂度。这将在很大程度上影响最终的 FP 计数。
因此，在真正开始依靠 FPA 来制定成本和时间估算之前，请使用 FP 工具作为指导，并尽可能多地收集以前项目的数据。
作为旁注，我认为对这样一个简单软件的成本估算在今天看来是荒谬的，因为外包和自由职业才是正确的选择。从事这一行业的大公司对软件开发的收费仍然高得离谱。例如，如果您希望 3 级支持工程师在一家优秀的托管公司中帮助您管理服务器，他们会收取每小时 250 美元的费用，但是您可以从世界其他地方的人员那里以 25 美元甚至 2.5 美元的价格获得相同的建议。
希望我的2分钱对你有用。
Personally i found FPA misleading ... initially.
Unless you have historical FPA data of previous projects, FPA can definitely end up over-estimating the whole thing, using industry standards.
I learned that VAF is a good pointer to use when dealing with FPA. Although it gives you a 35% variation range on your FP count, who is stopping the analyst/project manager from turning this into a 50% variation.
A good team leader always assesses his teams ability before making estimations. Same goes for FPA, industry standard figures were reached based on historical data, and this data varies from company to company, team to team and developer to developer.
So I would say if you use the best case scenario of -35% on the unadjusted count, you reach an adjusted FP count of ~64. Gives you roughly 3 and half weeks of estimate. From experience i would say an application of this sort CAN be done alot sooner than that, but any thorough testing, debugging, documentation and other paper work would stretch it further and FP takes that into account. It is very much possible that your team is doing 1 FP/hr. By normal standards, coding and testing accounts for 25% of the FP count, so in this case even taking your figure of 99 FPs, the coding and testing part would come down to 25 FPs, which is more understandable given the situation.
What i have also seen in practice is that some companies have devised their own complexity tables, so if 3 RETs and 10 DETs mean average complexity for one company, another would rate it as low complexity. This would largely effect the final FP count.
So use the FP tool as guide and collect as much data for previous projects as you can before you actually start relying on FPA to set out cost and time estimates.
As a side note, i think the costing estimates on a simple software like that would seem ridiculous today, where outsourcing and freelancing is the way to go. Large companies who have been in this business still charge ridiculously high for software development. For instance if you want a level 3 support engineer to help you with your servers in a good hosting company, they would charge $250 per hour, however you can get the same advice from someone based elsewhere in the world at $25 or even $2.5.
Hope my 2 cents are of some use to you.
在我以前的公司，我们会这样计算 - 特别是如果有人想要为此付费；）
At my previous company we would have calculated like that - especially if someone wants to pay for it ;)
我在几个项目中实践过 FP，发现它提供了相当准确的估计。有时它可能会高估，有时会低估，具体取决于应用程序的类型。通常对于科学应用，FP 可能会被低估。 FP 提供了整个项目开发时间，而不仅仅是编写代码的时间。当然，没有开发活动，例如测试环境的设置等，这些应该单独估计。我不是 FP 的大力支持者，但很欣赏它的使用。即使估计不准确，如果实践得当（识别文件和记录元素），它至少可以验证您的要求的完整性。
在某种程度上，我们应该说 FP 适用于中型到大型项目，可扩展超过 350-400 个 FP。
I have practised FP in a few projects and found that it provides a fairly accurate estimate. Sometimes it may overestimate and sometimes underestimate depending on type of application. Typically for scientific applications, FP could be underestimated. FP provides for entire project development time, not just the time for writing code. Of course there are no development activities, like setup of test environment, etc and these should be estimated separately. I am not a big proponent of FP, but appreciate its usage. If not accurate estimation, if practised properly (identifying Files and Record Elements), it atleast validates completeness of your requirements.
In a way, we should say that FP is good for medium to large projects, scaling over 350-400 FPs.
基于时间的付款会间接导致绩效下降。我记得有基于时间付款的项目，我对项目的各个方面都做了很多研究，但如果它有基于项目的付款方式，我可能就不会这样做。这是无意识的思想，而不是道德。
最佳实践是参考“项目”定义（在有限的时间和预算内）并根据限制做出决策。这与工作本身无关，也就是说，你在雨天买雨伞的费用比平时买的要多得多。不要为自己做了什么以及它值多少钱而烦恼。关注工作对客户及其选择的价值。
Time-based payments lead to lower performance indirectly. I remember projects with time-based payment that I did a lot of research for each aspect of project while if it had a project-based payment method maybe I didn't do so. It's the unconscious mind not ethics.
Best practice is to referring "Project" definition (within a limited time and budget) and make decision based on limitations. It's not about the work itself, i.e. you pay for an umbrella in a rainy day much more than when you buy normally. Don't bother yourself about what has done and how much it worth. Focus on the value of the work to the customer and his choices.
将您引用的示例中的值插入这个方便的在线功能点计算器（http://developergeeks.com/functionpoint.aspx ），它计算调整后的 FP 并考虑各种其他权重因子，假设生产率为每小时 2 FP，因为示例中的系统非常简单，我得到以下结果：
假设每个月工作 160 小时，则一名开发人员的工作时间约为 86.4 小时，即大约两周工作时间。正如您在步骤 2 中得出的结论，不到五周。考虑到为付费客户开发系统需要付出更多的关心和努力，而不仅仅是为了自己的娱乐而在深夜敲出一些代码，我认为这并不是一个不合理的估计全部。
我的意思是，不要误会我的意思，FP 分析如果落入错误的人手中可能是一个糟糕的主意。但是，如果您有开发人员的背景，您可以应用来计算 FP 并深入检查各种权重因子，当您没有详细的设计规范时，获得不基于纯粹幻想的合理估计并不是一个坏方法。 、完整记录的需求或详细的任务级项目计划。但你必须运用一些常识才能让它为你所用。
Plugging the values from the example you cited into this handy online function point calculator (http://developergeeks.com/functionpoint.aspx), which calculates the adjusted FPs and takes into account various other weighting factors, I get the following results, assuming a productivity rate of 2 FPs per hour since the system in the example is so simple:
Assuming 160 hours in a working month, that works out to about 86.4 hours, or roughly two work weeks for one developer. Not five weeks as you concluded in step 2. Given that developing systems for paying customers requires taking just a little more care and effort than just banging out some code late at night for your own amusement, I don't think that's an unreasonable estimate at all.
I mean, don't get me wrong, FP analysis in the wrong hands is probably a terrible idea. But if you've got a developer's background you can apply to counting FPs and gut checking the various weighting factors, it's not a bad way to get a reasonable estimate that isn't based on pure fantasy when you don't have detailed design specs, fully documented requirements or a detailed task-level project plan to work from. But you've got to use some common sense to make it work for you.
进行功能点分析的要点是制定某种客观和标准的规则/指南，以便它最终应该（在一定范围内）为您提供应用程序和/或项目上相同数量的功能点，无论如果规则一致且正确地应用，哪个专家会计算它。
正如您所发现的，每个功能点的生产力高度依赖于许多因素，例如团队经验、工具、编程语言、平台等。因此，很高兴了解行业标准，但在大多数情况下完全没有用（以我的愚见）。重复计数的主要价值是根据您自己的团队生产力历史建立您自己的“基准”。这反过来将帮助您了解趋势，并帮助计划和预测未来变化所需的时间。
如果您追求速度，只需应用全局计数而不是详细计数。当进行一些示例计数时（例如准备考试时），您会注意到详细计数和全局计数之间的差异并没有大到足以让您失眠（百分比）。
The point in having Function Point Analysis is having some kind of rules/guidelines which are objective and standard so that it should (within a certain margin) end up giving you the same amount of function points on an application and/or project, regardless of which expert counted it, if the rules are applied consistently and correct.
The productivity per function point, as you discovered, is highly dependable on many factors like team experience, tooling, programming language, platform, etc. etc. Therefore industry standards are nice to know, but in most cases completely useless (in my humble opinion). The main value in repetative counting is building up your own 'benchnmark' based on your own team productivity history. This in turn will help you see trends and also help plan and predict hours needed for future changes.
If you're looking for speed, simply apply global counts instead of detailed counts. When doing a few example counts (like when preparing for exams) you will notice the difference between a detailed count and a global count aren't big enough to loose sleep over (by %).
这个讨论绝对是误导性的，因为这个问题已经假设 FPA 是一种努力估计技术。 事实并非如此。
功能大小（以功能点表示）可以是估计模型（例如 COCOMO）的众多输入因素之一。如果我们同意功能需求的“数量”是软件项目的工作驱动力，那么就不会多，但也不会少。
This discussion is absolutely misleading, as the question already supposes FPA is an effort estimation technique. It is not.
Functional size (expressed in functions points) can be one of many input factors for an estimation model (such as COCOMO). Not more - but also not less if we agree that the 'amount' of functional requirements is an effort driver for software projects.