软件开发成本金字塔
有一天,一位朋友告诉我,在软件开发生命周期中修复问题的成本存在一个金字塔.我在哪里可以找到这个？
他指的是解决问题的成本.
例如,
在需求阶段解决问题成本1.
在开发阶段解决问题成本为10.
在测试阶段解决问题成本为100
在生产阶段解决问题成本为1000.
(这些数字只是例子)
如果有人参考,我会有兴趣看到更多相关信息.
Jör*_*tag 12
这是经验软件工程中众所周知的结果,在无数研究中反复复制和验证.不幸的是,这在软件工程中非常罕见:大多数软件工程"结果"基本上都是传闻,轶事,猜测,观点,一厢情愿或只是简单的谎言.事实上,大多数软件工程可能不值得"工程"品牌.
不幸的是,尽管它是最坚实,最科学和统计上最健全,最经过深度研究,最广泛验证,最常被复制的软件工程结果之一,但它也是错误的.
问题是所有这些研究都没有正确控制变量.如果要衡量一个变量的影响,你必须要非常小心,要改变只说一个变量,而另一个变量不发生改变,在所有.不是"改变一些变量",而不是"最小化对其他变量的改变"."只有一个"而其他人"完全没有".
或者,用Zed Shaw的精彩话语:如果你想测量狗屎,不要测量其他狗屎.
在这种特殊情况下,他们并没有只是衡量哪个阶段(需求,分析,建筑,设计,实施,测试,维护)的bug被发现,他们还测量了长时间它停留在系统中.事实证明,这个阶段几乎无关紧要,重要的是时间.重要的是要快速找到错误,而不是在哪个阶段.
这有一些有趣的后果:如果快速发现错误很重要,那么为什么要等到最有可能发现错误的阶段呢:测试？为什么不把在测试开始？
"传统"解释的问题在于它会导致效率低下的决策.因为您假设您需要在需求阶段找到所有错误,所以您不必要地长时间拖出需求阶段:您无法运行需求(或架构或设计),因此在您甚至无法执行的某些内容中查找错误会让人感到害怕辛苦了!基本上,虽然在需求阶段修复 bug很便宜,但找到它们很昂贵.
但是,如果你意识到这不是发现的错误在尽可能早的阶段,而是要找到的错误在最早的时间,那么你可以调整你的过程中,让您移动在其中期发现的bug是最便宜的(测试)到固定它们最便宜的时间点(最开始).
注意:我很清楚结束一个关于没有正确应用统计数据与完全未经证实的声明的咆哮的讽刺意味.不幸的是,我忘记了我读这篇文章的链接.Glenn Vanderburg在2010年Lone Star Ruby Conference的" 真实软件工程 "演讲中也提到了这一点,但AFAICR,他也没有引用任何消息来源.
如果有人知道任何消息来源,请让我知道或编辑我的答案,甚至只是偷我的答案.(如果你能找到一个来源,你应该得到所有的代表!)