17

赏金澄清

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

如果您认为所引用的场景并不令人惊讶并且可以预期，请分解步骤以证明这样一个小应用程序如何花费一个多月和数千美元的开发。我做了相当多的计算（例如，查找最低工资），所以我希望理想的答案能做类似的事情。

如果您认为引用的场景确实被高估了，请准确指出您的原因。你能在他的计算中发现哪些错误导致了这样一个简单的应用程序的巨大成本？你会怎么做？（不需要写全过程，但细节而不是概括的感觉会很好）

我知道关于 FPA 的问题已经被问过很多次了，但是这一次我会从一个更加分析的角度来分析它，并以数据为后盾。

1.首先，一些数据

这个问题是基于一个教程。他有一个“样本计数”部分，他一步一步地演示了它。您可以在此处查看他的示例应用程序的一些屏幕截图。

最后，他计算出未经调整的 FP为99。

InformIT 上还有另一篇文章，其中包含有关典型小时数/FP 的行业数据。它的范围从 2 小时/FP 到 27.4 小时/FP。让我们暂时坚持下去2（因为 SO 读者可能是更有效率的人群：p）。

2.现实检查！？

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

在这里做一个小数学

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

严重地？该示例应用程序将需要 5 周的时间来实施？仅仅是我的感觉，任何体面的程序员都不会花费超过一周的时间（我什至没有说周末）来完成它？

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

198 * 7.25 = $1435.5

从截图中我可以看出，这个应用程序是一个小型的 excel 改进应用程序。我本可以花 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+ FP），因此它在较小的规模上变得极其不准确。
  2. 小时/FP 指标在团队之间、项目之间突然波动。对于像这样的小项目，我们可以使用 0.5 小时/FP 之类的东西。（现在这种情况让整个估算变得毫无意义，除非我的公司用同一个团队做了几年相同类型的项目，这并不常见。）

根据我对几个软件指标的经验，功能点确实不是一个轻量级指标。如果小时/FP 的波动如此之大，那有什么意义呢，也许我可以选择用户故事点，它可以更快地获得，并且可以说几乎同样不确定。

FP 专家对此有何回答？

4

11 回答 11

12

大约十年前，我的一个酒友给了我一个非常棒的智慧。在任何项目咨询中，要问三个问题： 1. 我们要解决的问题是什么？2. 可交付成果是什么？3. 我们如何知道何时完成？他补充说，任何人都不应该承担在项目开始之前没有回答任何问题的任何项目。

在手头的案例中，我们还有另一个软件估算方法的恐怖故事，其中估算值似乎高得离谱。我会通过指出他没有回答第二个和第三个问题来回答他的恐怖故事，他也没有真正回答第一个问题，只是说“我们想要建造一些像这样工作的东西”。

我将对此进行扩展，指出他甚至没有明确询问功能点估计包括或排除在估计总数中的任务。例如，功能点估计器允许记录多少额外的工作？如果他的估计是针对没有任何文档的应用程序，而功能点估计器的估计是针对具有完整文档的应用程序，那么我想说在所需的工作总量（和时间）上存在一些分歧的空间。

于 2010-06-09T21:05:28.427 回答
9

仅仅是我的感觉，任何体面的程序员都不会花费超过一周的时间（我什至没有说周末）来完成它？

开发人员总是倾向于低估实际完成某件事所需的时间。他们认为不会有错误，不会改变需求，也不会出现他们以前从未做过的事情，因此必须花费数天时间来弄清楚。

从截图中我可以看出，这个应用程序是一个小型的 excel 改进应用程序。我本可以花 200 美元购买 MS Office Pro，这给了我更大的互操作性（.xls 文件）和灵活性（电子表格）。

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

于 2010-04-23T06:17:55.267 回答
4

现实情况是，大多数软件估计方法实际上都低估了，尽管乍一看，这似乎违反直觉。我曾经在一家公司工作，每个人月 300 行代码被认为是很高的估计值，而大多数月我们的代码大约是 200-250 行。但是让我们使用 200 行代码。这是每个工作日 10 行代码。谁不能在一个工作日内写出 10 行代码？来吧！在美好的一天，我可以写 50 到 100 行或更多行代码！然而，使用此类数字的公司却一再落后于进度并超出预算完成项目。这是为什么？好吧，正如迈克尔·博格沃特所说，范围蔓延是一个很大的问题。但是让我们先把它拉出来，假设客户和客户第一次就做对了。为什么一家公司估计每天只写 10 行代码？

  • 需求分析
  • 基于需求的软件设计
  • 与队友协调接口和架构的会议。
  • 间接费用（与管理层的状态会议、病假、假期……）
  • 编写单元测试
  • 为整个应用程序编写测试计划
  • 应用级测试

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

于 2010-06-08T13:09:46.943 回答
2

不是FP专家。然而，我们目前正在关注 FP。特别是，我们正在对具有工作量/成本等指标的旧项目进行 FP 分析。然后我们可以评估它在估算/调整项目时对我们的有用性。

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

进一步的想法 - 每个功能点的成本/工作量（即功能要求）将取决于系统所需的非功能要求。一旦您开始考虑安全性、可访问性、性能、日志记录（和警报）、可维护性、可移植性、法规遵从性等，每个 FP 的成本/工作量就会显着增加。现在，这些可能不是引用的单用户示例应用程序的考虑因素。但是，如果此应用程序对公司或其潜在客户或广大公众很重要，那么考虑这些非功能性需求的需求肯定会增加。

于 2010-06-09T20:54:51.663 回答
2

就我个人而言，我发现 FPA 具有误导性……最初。

除非你有以前项目的历史 FPA 数据，否则 FPA 肯定会使用行业标准高估整个事情。

我了解到在处理 FPA 时 VAF 是一个很好的指针。尽管它为您的 FP 计数提供了 35% 的变化范围，但谁阻止了分析师/项目经理将其转变为 50% 的变化。

一个好的团队领导总是在做出估计之前评估他的团队能力。FPA 也是如此，根据历史数据达到行业标准数据，并且这些数据因公司、团队和开发人员而异。

所以我想说，如果你在未调整的计数上使用 -35% 的最佳情况，你会达到 ~64 的调整后的 FP 计数。给你大约 3 周半的估计。根据经验，我会说这种应用程序可以比这更早完成，但是任何彻底的测试、调试、文档和其他书面工作都会进一步扩展它，FP 会考虑到这一点。您的团队很有可能正在做 1 FP/hr。按照正常标准，编码和测试占 FP 数的 25%，所以在这种情况下，即使以 99 FP 为数字，编码和测试部分也会降到 25 FP，考虑到这种情况，这更容易理解。

我在实践中还看到一些公司设计了自己的复杂度表，因此如果 3 RET 和 10 DET 意味着一家公司的平均复杂度，另一家公司会将其评为低复杂度。这将在很大程度上影响最终的 FP 计数。

因此，在您真正开始依赖 FPA 来制定成本和时间估算之前，请使用 FP 工具作为指导，并尽可能多地为以前的项目收集数据。

作为旁注，我认为对像这样的简单软件的成本估算在今天似乎很荒谬，外包和自由职业是要走的路。从事这项业务的大公司仍然对软件开发收取高得离谱的费用。例如，如果您希望 3 级支持工程师在一家优秀的托管公司帮助您使用服务器，他们将收取每小时 250 美元的费用，但是您可以以 25 美元甚至 2.5 美元的价格从世界其他地方的人那里获得相同的建议。

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

于 2010-06-12T12:58:53.423 回答
1

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

于 2010-04-22T21:00:24.707 回答
1

我在几个项目中练习过 FP，发现它提供了相当准确的估计。有时它可能高估有时低估，具体取决于应用程序的类型。通常对于科学应用，FP 可能被低估。FP 提供整个项目开发时间，而不仅仅是编写代码的时间。当然没有开发活动，例如测试环境的设置等，这些应该单独估计。我不是 FP 的大支持者，但很欣赏它的用法。如果估计不准确，如果实践得当（识别文件和记录元素），它至少可以验证您的要求的完整性。

在某种程度上，我们应该说 FP 适用于大中型项目，可扩展超过 350-400 FP。

于 2010-06-10T12:40:51.310 回答
1

基于时间的支付会间接导致绩效下降。我记得基于时间支付的项目，我对项目的各个方面进行了大量研究，而如果它有基于项目的支付方式，我可能没有这样做。这是潜意识而不是道德。最佳实践是参考“项目”定义（在有限的时间和预算内）并根据限制做出决策。这与工作本身无关，即您在下雨天为雨伞支付的费用比平时购买时要多得多。不要为已经做了什么以及它的价值而烦恼。关注工作对客户及其选择的价值。

于 2010-06-12T09:20:22.870 回答
0

将您引用的示例中的值插入这个方便的在线函数点计算器 ( http://developergeeks.com/functionpoint.aspx )，它计算调整后的 FP 并考虑到各种其他加权因子，我得到以下结果，假设由于示例中的系统非常简单，因此生产率为每小时 2 FP：

  1. 调整后的 FP：42.9
  2. 预计人月数：0.54

假设一个工作月有 160 小时，那么一个开发人员大约需要 86.4 小时，或大约两个工作周。不像您在第 2 步中得出的结论那样五周。鉴于为付费客户开发系统需要花费更多的精力和精力，而不仅仅是为了自己的乐趣而在深夜敲出一些代码，我不认为这是一个不合理的估计全部。

我的意思是，不要误会我的意思，FP 分析在坏人手中可能是一个糟糕的主意。但是，如果您有开发人员的背景，您可以申请计算 FP 并检查各种加权因子，当您没有详细的设计规范时，获得一个不基于纯粹幻想的合理估计并不是一个坏方法、完整记录的需求或详细的任务级项目计划。但是你必须使用一些常识来让它为你工作。

于 2013-01-31T20:43:48.270 回答
0

根据我对几个软件指标的经验，功能点确实不是一个轻量级指标。如果小时/FP 的波动如此之大，那有什么意义呢，也许我可以选择用户故事点，它可以更快地获得，并且可以说几乎同样不确定。

进行功能点分析的要点是具有某种客观和标准的规则/指南，因此它应该（在一定范围内）最终为您在应用程序和/或项目上提供相同数量的功能点，无论如果规则应用一致且正确，则由哪位专家计算。正如您所发现的，每个功能点的生产力高度依赖于许多因素，如团队经验、工具、编程语言、平台等。因此很高兴知道行业标准，但在大多数情况下完全没用（以我的拙见）。重复计数的主要价值是根据您自己的团队生产力历史建立自己的“基准”。这反过来将帮助您了解趋势，还有助于计划和预测未来变化所需的时间。如果你' 重新寻找速度，只需应用全局计数而不是详细计数。在进行一些示例计数时（例如在准备考试时），您会注意到详细计数和全局计数之间的差异不足以让您睡不着觉（按百分比）。

于 2014-04-29T09:12:38.427 回答
0

这种讨论绝对具有误导性，因为问题已经假设 FPA 是一种工作量估算技术。它不是。

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

于 2017-01-13T14:53:27.573 回答