软件开发成本金字塔

Question

一位朋友前几天告诉我，在软件开发生命周期中解决问题的成本存在金字塔。我在哪里可以找到这个？

他指的是解决问题的成本。

例如，

  

在需求阶段成本1修复问题。

     

在开发阶段解决问题成本为10。

     

在测试阶段解决问题成本为100

     

在生产阶段解决问题成本为1000。

（这些数字只是示例）

如果有人参考，我会有兴趣了解更多相关信息。

Answer 1

The Incredible Rate of Diminishing Returns of Fixing Software Bugs

（Stefan Priebsh：OOP和设计模式：2009年9月的Codeworks DC）

Answer 2

这是众所周知的经验软件工程的结果，在无数的研究中反复复制和验证。不幸的是，这在软件工程中非常罕见：大多数软件工程“结果”基本上都是传闻，轶事，猜测，观点，一厢情愿或只是简单的谎言。事实上，大多数软件工程可能不值得“工程”品牌。

不幸的是，尽管它是最坚实，最科学和统计上最健全，最经过深度研究，最广泛验证，最常被复制的软件工程结果之一，但它也是错误的。

问题是所有这些研究都没有正确控制变量。如果要测量变量的影响，则必须非常小心地仅更改 一个变量以及其他变量根本不会改变 。不是“改变一些变量”，而不是“最小化对其他变量的改变”。 “只有一个”而其他人“完全没有”。

或者，用精彩的Zed Shaw的话说：如果你想测量狗屎，不要测量其他狗屎。

在这种特殊情况下，他们不只测量发现错误的阶段（需求，分析，架构，设计，实现，测试，维护），他们也测量了 long 在系统中的停留时间。事实证明，这个阶段几乎无关紧要，重要的是时间。重要的是找到错误快速，而不是在哪个阶段。

这有一些有趣的后果：如果找到 fast 错误很重要，那么为什么要等待最有可能发现错误的阶段呢：测试？为什么不将测试放在开头？

“传统”解释的问题在于它会导致效率低下的决策。因为您假设需要在需求阶段找到所有错误，所以您不必要地拖延需求阶段：您无法运行需求（或架构或设计），因此查找< / em>你甚至无法执行的东西中的一个错误是 hard ！基本上，虽然在需求阶段修复错误很便宜，但找到它们很昂贵。

但是，如果您意识到这不是在尽可能早的时间找到错误 ，而是在尽可能早的时间找到错误 ，那么你可以对您的流程进行调整，以便将查找错误最便宜（测试）的阶段移动到 fix 它们最便宜的时间点（最开始） ）。

---

注意：我很清楚结束一个关于没有正确应用统计数据与完全未经证实的声明的咆哮的讽刺意味。不幸的是，我忘记了我读这篇文章的链接。 Glenn Vanderburg在2010年Lone Star Ruby Conference的“Real Software Engineering”演讲中也提到了这一点，但AFAICR，他也没有引用任何消息来源。

如果有人知道任何消息来源，请让我知道或编辑我的答案，甚至只是窃取我的答案。 （如果你能找到一个来源，你应该得到所有的代表！）

Answer 3

见this presentation（pdf）第42和43页。

不幸的是，情况就像Jörg所描述的那样，实际上有点糟糕：本文中引用的大多数参考文献都将我视为虚假，因为引用的论文要么不是原创性研究，要么不包含支持声明的词语正在制作，或者 - 在1998 paper about Hughes（p54）的情况下 - 包含实际的测量结果与演示文稿的p42中的曲线所暗示的相反：曲线的不同形状，在需求阶段和功能测试阶段之间（以及实际上在系统测试和维护中减少）的成本固定的x5到x10因子是适度的。

Answer 4

之前从未听说它被称为金字塔，这对我来说似乎有些颠倒！尽管如此，人们普遍认为中心论点是正确的。关于它，在alpha阶段修复bug的成本通常是微不足道的。在测试阶段，可能需要更多的调试和用户报告。发货后可能非常昂贵。必须创建一个全新的版本，您必须担心破坏生产中的代码和数据，由于该错误，可能还会丢失销售额？

Answer 5

试试这个article。它使用“成本金字塔”参数（没有命名），等等。