前几天一位朋友告诉我，在软件开发生命周期中解决问题的成本是一个金字塔。我在哪里可以找到这个？
他指的是解决问题的成本。
例如，
在需求阶段解决问题的成本 1.
在开发阶段解决问题需要花费 10。
在测试阶段解决问题需要花费 100
在生产阶段解决问题需要花费 1000 美元。
（这些数字只是示例）
如果有人有参考资料，我将有兴趣了解更多相关信息。
问问题
10282 次
5 回答
19
于 2010-11-09T02:54:21.697 回答
13
这是经验软件工程中的一个众所周知的结果，在无数研究中被一次又一次地复制和验证。不幸的是，这在软件工程中非常罕见：大多数软件工程“结果”基本上都是道听途说、轶事、猜测、意见、一厢情愿或只是简单的谎言。事实上，大多数软件工程可能不配得上“工程”的标签。
不幸的是，尽管它是软件工程中最可靠、最科学和最合理、研究最多、验证最广泛、最常复制的结果之一，但它也是错误的。
问题是所有这些研究都没有正确控制它们的变量。如果你想衡量一个变量的影响，你必须非常小心地只改变那个变量，而其他变量根本不改变。不是“改变一些变量”，也不是“尽量减少对其他变量的改变”。“只有一个”，其他的“根本没有”。
或者，用出色的 Zed Shaw 的话来说：“如果你想衡量某样东西，就不要衡量其他狗屎”。
在这种特殊情况下，他们不仅测量在哪个阶段（需求、分析、架构、设计、实施、测试、维护）发现了错误，他们还测量了它在系统中停留的时间。事实证明，阶段几乎无关紧要，重要的是时间。重要的是要快速找到错误，而不是在哪个阶段。
这有一些有趣的后果：如果快速找到错误很重要，那么为什么要在最有可能找到错误的阶段等待这么长时间：测试？为什么不把测试放在开头呢？
“传统”解释的问题在于它会导致低效的决策。因为您假设您需要在需求阶段找到所有错误，所以您将需求阶段拖得不必要的长：您无法运行需求（或架构或设计），因此在您甚至无法执行的事情中找到错误是可怕的硬！基本上，虽然在需求阶段修复错误很便宜，但找到它们却很昂贵。
但是，如果您意识到这不是在尽可能早的阶段找到错误，而是在尽可能早的时间找到错误，那么您可以对您的流程进行调整，以便您移动发现错误的阶段最便宜（测试）到修复它们最便宜的时间点（最开始）。
注意：我很清楚以完全未经证实的说法结束关于未正确应用统计数据的咆哮具有讽刺意味。不幸的是，我失去了阅读本文的链接。Glenn Vanderburg 在 2010 年 Lone Star Ruby 会议上的“真正的软件工程”演讲中也提到了这一点，但 AFAICR，他也没有引用任何来源。
如果有人知道任何来源，请让我知道或编辑我的答案，甚至只是窃取我的答案。（如果你能找到来源，你应该得到所有的代表！）
于 2010-11-09T04:37:53.707 回答
2
请参阅本演示文稿的第 42 和 43 页(pdf)。
不幸的是，情况正如 Jörg 所描述的那样，实际上更糟：本文件中引用的大多数参考文献让我觉得是虚假的，因为所引用的论文要么不是原创研究，要么不包含支持所提出主张的文字，或者 - 在1998 年关于 Hughes 的论文(p54) 的情况下 - 包含实际上与演示文稿 p42 中的曲线所暗示的内容相矛盾的测量结果：曲线的不同形状，以及适度的 x5 到 x10 成本因子因子-修复需求阶段和功能测试阶段（实际上在系统测试和维护中减少）。
于 2012-01-03T07:37:25.210 回答
0
以前从未听说过它被称为金字塔，这对我来说似乎有点颠倒！尽管如此，中心论点被广泛认为是正确的。仅此而已，在 alpha 阶段修复错误的成本通常是微不足道的。在 beta 阶段，它可能需要更多的调试和用户报告。发货后可能会很贵。必须创建一个全新的版本，您必须担心破坏生产中的代码和数据，还可能因错误而失去销售？
于 2010-11-09T02:53:07.433 回答
-1
试试这篇文章。它使用“成本金字塔”参数（没有命名）等等。
于 2013-04-18T15:03:41.273 回答