功能点分析 - 严重高估的技术？

Question

赏金澄清

我知道这是一个主观的问题。我正在寻找的理想答案是解释为什么这里引用的场景会如此令人惊讶。

如果您认为引用的情况就是事实 不是 令人惊讶的是，请预料到，请分解步骤，以证明这样的小应用程序如何花费一个月的时间和数千美元的开发。我走了很远的时间来进行计算（例如，查找最低工资），所以我希望理想的答案能做到类似。

如果您认为报价的场景确实被高估了，请准确指出您的原因。您可以发现他的计算中有什么错误导致这样的简单应用程序的巨大成本？您将如何做不同的事情？ （无需写整个过程，但是细节而不是广义的感觉会很好）

---

我知道有关FPA的问题以前曾多次问过，但是这次我对此进行了更分析的角度， 备份数据.

1.首先，一些数据

这个问题是基于 教程. 。他有一个“样本计数”部分，在其中逐步证明了这一点。你可以看到一些 他的样品申请的屏幕截图.

最后，他 计算了未经调整的FP 成为 99.

还有另一种 有关信息的文章 具有典型小时/fp的行业数据。它的范围从2小时/fp到27.4小时/fp。让我们尝试坚持 2 目前（因为这样的读者可能是更有效的人群：P）。

2.现实检查！

现在只需查看 屏幕截图 再次。

在这里做一点数学

99 * 2 = 198 hours
198 hours / 40 hours per week = 5 weeks

严重地？该样本应用程序将需要5周才能实施？只是我的觉得不需要任何体面的程序员一个星期以上（我“我甚至没有说周末）才能完成？

现在，让我们尝试估计项目的成本。目前我们将使用纽约的最低工资（维基百科），$ 7.25

198 * 7.25 = $1435.5

从我可以从屏幕截图中看到的内容，此应用程序是一个小型Excel-Improvement应用程序。我本可以以200美元的价格购买了MS Office Pro，这使我可以提供更大的互操作性（.xls文件）和灵活性（电子表格）。

（根据记录，同一网站还有另一篇文章讨论生产力。似乎他们通常使用4.2小时/fp，这给了我们更令人震惊的统计数据：

99 * 4.2 = 415 hours = 10 weeks = almost 3 whopping months!
415 hours * $7.25 = $3000 zomg

（这甚至假设我们所有可怜的编码人员都获得最低工资！）

3.我在这里错过了什么吗？

现在，我可以提出一些可能的解释：

1. FPA实际上仅适用于较大的项目（1000多个FPS），因此它在较小规模上变得极为不准确。
2. 小时/fp度量波动 突然 从团队到团队，项目到项目。对于这样的小型项目，我们可以使用0.5小时/fp之类的东西。 （现在，这种使整个估计的事情毫无意义，除非我的公司与同一团队进行了几年的相同类型的项目，但并不是很普遍。）

从我对几个软件指标的经验来看，功能点实际上不是轻量级指标。如果小时/fp的东西波动如此之多，那么这是什么重点，也许我可以使用用户故事点，而用户的故事点可以更快地获得，并且可以说几乎不确定。

FP专家对此的答案是什么？

Answer 1

大约十年前，我的一个饮酒伙伴给了我一个很棒的智慧。在任何项目咨询中，提出三个问题：1。我们要解决的问题是什么？ 2.什么是可交付成果？ 3.我们怎么知道何时完成？他补充说，在项目启动之前，绝不应该接受任何任何问题未回答的项目。

在手头的情况下，我们还有另一个软件估计方法恐怖故事，其中估计似乎很高。我会通过指出他没有回答第二和第三个问题的答案来回答他的恐怖故事，而他并没有真正回答第一个问题，除了说“我们想构建类似这样有效的东西”。

我将通过指出他明确地询问功能点估算值包括或排除在估计总数中的哪些任务来扩展这一点。例如，功能点估计器允许文档进行多少额外的努力？如果他的估计是用于应用程序的，没有任何文档，并且功能点估算器的估计是用于完整文档的应用程序，那么，我说对所需的总工作量（和时间）有一些分歧。

Answer 2

只是我的觉得不需要任何体面的程序员一个星期以上（我“我甚至没有说周末）才能完成？

开发人员总是倾向于低估实际完成某件事所需的时间。他们认为不会有错误，需求的变化，也没有以前从未做过的东西，不得不花几天的时间来弄清楚。

从我可以从屏幕截图中看到的内容，此应用程序是一个小型Excel-Improvement应用程序。我本可以以200美元的价格购买了MS Office Pro，这使我可以提供更大的互操作性（.xls文件）和灵活性（电子表格）。

您正在将完全定制的软件的价格与销售数百万份的软件进行比较？严重地？

Answer 3

现实是，大多数软件估计方法实际上都低估了，即使乍一看，它似乎是违反直觉的。我曾经在一家公司工作，每月300行被认为是一个高估计，大多数几个月我们都以200-250的速度进入。但是，让我们去做200。这是每个工作日的10行代码。谁不能在工作日写10行代码？来吧！我可以在美好的一天写50至100行代码！然而，使用此类数字的公司反复完成了计划和预算超额预算的项目。这是为什么？好吧，正如迈克尔·鲍格沃特（Michael Borgwardt）所建议的那样，范围蠕变是一个很大的。但是，让我们将图片删除一分钟，并假设客户和客户第一次将其正确。公司为什么每天只能估算10行代码？

• 要求分析
• 基于要求的软件设计
• 会议与队友协调界面和建筑。
• 间接费用（与管理层，病假，假期的状态会议，...）
• 编写单元测试
• 为整个申请编写测试计划
• 应用程序级测试

这是我可以在3分钟内脱颖而出的所有日常软件工程，我敢肯定我错过了更多，但是这是否有助于更完整地了解这些估计的来源？

Answer 4

不是FP专家。但是，我们目前正在研究FP。特别是，我们正在针对旧项目进行FP分析，这些项目具有努力 /成本等指标。那么我们可以评估其对我们在估计 /大小项目中的有用性。

在这一点上，我的看法是，它将是一个有用的自上而下的“数量级”估计值来补充自下而上的估计。如果可以应用多个估计技术来帮助验证到达“坚持”的数字，那总是很好。

进一步的想法 - 每个功能点的成本 /努力（即功能要求）将取决于系统所需的非功能要求。一旦您开始考虑安全性，可访问性，绩效，记录（和警报），可维护性，可移植性，法规合规性等，则每次FP的成本/努力大大增加。现在，对于引用的单用户示例应用程序，这些可能不是考虑因素。但是，如果此申请对公司或可能的客户或广泛的公众很重要，那么考虑到这些非功能要求的需求肯定会增加。

Answer 5

就我个人而言，我发现FPA的误导性...最初。

除非您拥有以前项目的历史FPA数据，否则FPA肯定会使用行业标准最终超出整个过程。

我了解到VAF是与FPA打交道时使用的好指针。尽管它为您的FP计数提供了35％的变化范围，但他们正在阻止分析师/项目经理将其转变为50％的变化。

优秀的团队负责人总是在估算之前评估他的团队能力。 FPA也是如此，根据历史数据达到了行业标准数字，该数据因公司而异，团队，团队以及开发人员以及开发人员。

因此，我要说的是，如果您在未经调整的计数上使用最佳情况为-35％，则可以达到调整后的FP计数〜64。给您大约3个半星期的估计。从经验中，我会说，这种应用可以比这更快地进行，但是任何彻底的测试，调试，文档和其他纸质工作都会进一步扩展并考虑到这一点。您的团队很有可能进行1 fp/hr。按照正常标准，编码和测试占FP计数的25％，因此，在这种情况下，即使以99 fps为单位，编码和测试零件也将降至25 fps，考虑到这种情况，这是可以理解的。

我在实践中也看到的是，有些公司已经设计了自己的复杂性表，因此，如果3 ret和10个DET表示一家公司的平均复杂性，另一个公司将其评级为低复杂性。这将在很大程度上影响最终的FP计数。

因此，在您实际开始依靠FPA来列出成本和时间估计之前，请使用FP工具作为指南并为先前项目收集尽可能多的数据。

附带说明，我认为今天这样的简单软件的成本量估计看起来很荒谬，在这里外包和自由职业是必经之路。从事这项业务的大型公司仍将软件开发的高度荒谬。例如，如果您希望3级支持工程师在一家好的托管公司中帮助您使用服务器，他们将收取每小时250美元的费用，但是您可以从世界其他地方的某人获得相同的建议，价格为25美元甚至2.5美元。

希望我的2美分对您有用。

Answer 6

在我以前的公司，我们会这样计算 - 特别是如果某人 想要 为此付费;）

Answer 7

我已经在一些项目中练习FP，发现它提供了相当准确的估计。有时，它可能会高估，有时会根据应用类型而低估。通常，对于科学应用，可能会低估FP。 FP提供了整个项目开发时间，而不仅仅是编写代码的时间。当然，没有开发活动，例如测试环境的设置等，应分别估算这些活动。我不是FP的支持者，但感谢它的用法。如果不准确的估计，如果正确练习（识别文件和记录元素），它至少会验证您的需求的完整性。

从某种意义上说，我们应该说FP适合中型到大型项目，扩展超过350-400 fps。

Answer 8

基于时间的付款可间接降低绩效。我记得基于时间付款的项目，我对项目的每个方面进行了大量研究，而如果它具有基于项目的付款方式，也许我没有这样做。这是无意识的思想而不是道德。最佳实践是转到“项目”定义（在有限的时间和预算之内），并根据限制做出决定。这与工作本身无关，即您在下雨天要支付的雨伞比正常购买时要多得多。不要为自己的所作所为和价值打扰自己。专注于对客户及其选择的工作价值。

Answer 9

将您引用的示例中的值插入此方便的在线功能点计算器（http://developergeeks.com/functionpoint.aspx），它计算了调整后的FPS并考虑了其他各种加权因素，我会得到以下结果，假设每小时生产率为2 fps，因为该示例中的系统非常简单：

1. 调整后FPS：42.9
2. 估计人员月份：0.54

假设在一个工作月份有160小时，大约为86.4小时，或者为一个开发人员大约需要两个工作周。您在步骤2中得出的结论不是五个星期的时间2。鉴于开发用于付款客户的系统需要花费更多的照顾和精力，而不是在深夜敲一些代码以进行自己的娱乐，我认为这不是一个不合理的估计。全部。

我的意思是，不要误会我的意思，FP分析在错误的手中可能是一个可怕的主意。但是，如果您有开发人员的背景，您可以应用计算FPS和IT检查各种权重因素，这不是一个不错的方法，即获得合理的估算值，而当您没有详细的设计规格时，它不基于纯粹的幻想，已充分记录的要求或详细的任务级项目计划。但是，您必须利用一些常识使其适合您。

Answer 10

从我对几个软件指标的经验来看，功能点实际上不是轻量级指标。如果小时/fp的东西波动如此之多，那么这是什么重点，也许我可以使用用户故事点，而用户的故事点可以更快地获得，并且可以说几乎不确定。

具有功能点分析的点是具有客观和标准的某种规则/准则，以便它（在一定余量之内）最终为您在应用程序和/或项目上提供相同数量的功能点如果规则始终如一，正确正确，那么哪个专家将其计算在内。正如您发现的那样）。重复计数的主要价值是根据自己的团队生产力历史建立自己的“基础标记”。反过来，这将帮助您了解趋势，还可以帮助计划和预测未来变化所需的时间。如果您正在寻找速度，只需应用全球计数而不是详细计数即可。进行一些示例计数（例如准备考试时）时，您会注意到详细计数和全球计数之间的区别不足以使睡眠不足（按％）。

Answer 11

该讨论绝对具有误导性，因为问题已经假设FPA是一种努力估计技术。 它不是.

功能大小（以功能点表示）可能是估计模型（例如Cocomo）的许多输入因素之一。不多 - 但是，如果我们同意功能要求的“数量”是软件项目的努力驱动力。