前几天一位朋友告诉我，在软件开发生命周期中解决问题的成本是一个金字塔。我在哪里可以找到这个？
他指的是解决问题的成本。
例如，
在需求阶段解决问题需要花费 1.
在开发阶段解决问题需要 10 美元。
在测试阶段解决问题需要花费 100
在生产阶段解决问题需要花费 1000。
（这些数字只是示例）
如果有人有参考资料，我很想了解更多相关信息。
【问题讨论】：
标签： software-quality
The Incredible Rate of Diminishing Returns of Fixing Software Bugs
（Stefan Priebsh：OOP 和设计模式：Codeworks DC，2009 年 9 月）
【讨论】：
这是经验性软件工程中众所周知的结果，已在无数研究中一次又一次地复制和验证。不幸的是，这在软件工程中非常罕见：大多数软件工程“结果”基本上都是道听途说、轶事、猜测、意见、一厢情愿或只是简单的谎言。事实上，大多数软件工程可能并不配得上“工程”这个品牌。
不幸的是，尽管它是软件工程中最可靠、最科学和最可靠、研究最深入、验证最广泛、最常被复制的结果之一，但它也是错误的。
问题在于所有这些研究都没有正确控制其变量。如果您想衡量一个变量的效果，您必须非常小心地更改仅该一个变量而其他变量不改变根本不改变。不是“改变一些变量”，也不是“尽量减少对其他变量的改变”。 “只有一个”，其他的“根本没有”。
或者，用出色的 Zed Shaw 的话来说："If you want to measure something, then don't measure other shit"。
在这种特殊情况下，他们不只是衡量在哪个阶段（需求、分析、架构、设计、实施、测试、维护）发现了错误，他们还 em> 测量它在系统中停留的时间多长时间。事实证明，阶段几乎无关紧要，重要的是时间。 快速发现错误很重要，而不是在哪个阶段。
这有一些有趣的后果：如果发现错误快速很重要，那么为什么要在最有可能发现错误的阶段等待这么长时间：测试？为什么不把测试放在开始？
“传统”解释的问题在于它会导致低效的决策。因为您假设您需要在需求阶段找到所有错误，所以您将需求阶段拖得不必要的长：您无法运行需求（或架构或设计），所以查找 一个你甚至无法执行的东西中的一个错误真是太可怕了hard！基本上，虽然在需求阶段修复错误很便宜，但找到它们却很昂贵。
但是，如果您意识到这不是尽早发现错误，而是尽早发现错误，那么您可以对您的流程进行调整，以便您将发现错误最便宜（测试）的阶段移动到修复最便宜的时间点（最开始)。
注意：我很清楚以完全未经证实的说法结束关于未正确应用统计数据的咆哮具有讽刺意味。不幸的是，我失去了阅读本文的链接。 Glenn Vanderburg 在 2010 年 Lone Star Ruby 会议上的“Real Software Engineering”演讲中也提到了这一点，但 AFAICR，他也没有引用任何来源。
如果有人知道任何来源，请让我知道或编辑我的答案，甚至只是窃取我的答案。 （如果你能找到来源，你应该得到所有的代表！）
【讨论】：
参见this presentation (pdf) 的第 42 和 43 页。
不幸的是，情况正如 Jörg 所描述的那样，实际上更糟：本文档中引用的大多数参考文献让我觉得是虚假的，因为所引用的论文要么不是原创研究，要么不包含支持该主张的文字正在制作，或者 - 在1998 paper about Hughes (p54) 的情况下 - 包含 事实上 与演示文稿的 p42 中曲线所暗示的内容相矛盾的测量值：曲线的不同形状，以及在需求阶段和功能测试阶段（实际上在系统测试和维护中降低）之间的修复成本系数是适度的 x5 到 x10。
【讨论】：
以前从未听说过它被称为金字塔，这对我来说似乎有点颠倒了！尽管如此，中心论点被广泛认为是正确的。仅此而已，在 alpha 阶段修复错误的成本通常是微不足道的。在 beta 阶段，它可能需要更多的调试和用户报告。发货后可能会很贵。必须创建一个全新的版本，您必须担心破坏生产中的代码和数据，还可能因错误而失去销售？
【讨论】：
试试这个article。它使用“成本金字塔”参数（未命名）等。
【讨论】：