我将以我发现的大部分内容都来自1970年代和1980年代初期为事实作为开头。在这段时间里，顺序过程模型比迭代和/或增量方法（螺旋模型或敏捷方法）普遍得多。这些工作大部分建立在这些顺序模型上。但是，我认为这不会破坏关系，但是迭代/增量方法的好处之一是在注入依赖项和每个阶段的复杂性之前，快速发布功能（应用程序的整个垂直片段）并纠正其中的问题。高。
我刚拿出软件工程经济学的副本，并在第4章中找到了该图表背后的数据。他引用了ME Fagan（IEEE，UMD的PDF），EB的“减少程序开发中的错误的设计和代码检查”。Daly的“软件工程管理”，WE Stephenson的“对保障系统软件开发中使用的资源的分析”（ACM）和“几个TRW项目”。
...根据进行校正或更改的阶段来校正软件错误（或进行其他软件更改）的相对成本。如果在计划和需求阶段检测到并纠正了软件需求错误，则其修正是更新需求规范的相对简单的事情。如果在维护阶段之前未纠正相同的错误，则纠正工作涉及大量的规格，代码，用户和维护手册以及培训材料。
此外，后期更正涉及更正式的变更批准和控制流程，以及更广泛的重新验证更正的活动。这些因素相结合，使得在大型项目的维护阶段纠正错误的成本通常比要求阶段高100倍。
Bohem还研究了两个较小的，非正式的项目，发现成本增加了，但远没有大型项目中确定的100倍重要。根据图表，在系统运行后，修复需求缺陷的差异似乎比需求阶段大4倍。他将其归因于组成该项目的项目的较小库存和减少的形式，从而导致能够更快地实施更简单的解决方案。
基于《软件工程经济学》中的Boehm，“代码完成”中的表相当肿（范围的下限通常太高）。在阶段内进行任何更改的成本确实为1。从软件工程经济学的图4-2推断，需求更改应为体系结构的1.5-2.5倍，编码2.5-10，测试4-20和4- 100维护中。金额取决于项目的规模和复杂程度以及所使用流程的形式。
在巴里·勃姆（Barry Boehm）和理查德·特纳（Richard Turner）的平衡敏捷与纪律的附录E中，有一小节是关于变更成本的经验发现。
开头几段引用了Kent Beck的《 Extreme Programming Explained》，引用了Beck。它说，如果变更的成本随着时间的推移缓慢上升，则决策将尽可能晚地做出，而仅执行需要的事情。这就是所谓的“平坦曲线”，它是极限编程的驱动力。但是，先前的文献发现是“陡曲线”，小型系统（<5 KSLOC）的变化为5：1，大型系统的变化为100：1。
本节引用了马里兰大学基于经验的软件工程中心（由美国国家科学基金会资助）。他们搜索了可用的文献，发现结果倾向于确定100：1的比例，其中一些结果表明范围为70：1至125：1。不幸的是，这些通常是“前期大型设计”项目，并且按顺序进行管理。
有一些使用Extreme Programming运行的“小型商业Java项目”的示例。对于每个故事，都跟踪了在错误修复，新设计和重构方面的工作量。数据表明，随着系统的开发（实施了更多的用户案例），平均工作量倾向于以不平凡的速度增加。重构的工作量增加了大约5％，固定工作的努力增加了大约4％。
我正在了解的是，系统复杂性在所需的工作量中起着很大的作用。通过在系统中构建垂直切片，可以通过逐渐增加复杂度而不是将其成堆增加速度来降低曲线的速率。与其处理大量的需求复杂性，然后处理极其复杂的体系结构，然后处理极其复杂的实现，等等，不如说是非常简单地开始并添加。
这对修复成本有什么影响？最后，也许不多。但是，它确实具有允许对复杂性进行更多控制（通过管理技术债务）的优势。此外，经常与敏捷相关联的频繁交付物意味着项目可能会更快结束-而不是交付“系统”，而是交付件直到业务需求得到满足或对新系统（以及新项目）进行了彻底改变为止是必需的。
Stephen Kan的“ 软件质量工程中的度量标准和模型”在第6章中有一节介绍了相位缺陷消除的成本效益。
他首先引用了Fagan 1976年的论文（在软件工程经济学中也曾引用），指出在高级设计（系统架构），低级设计（详细设计）中进行的返工和实现的成本可以降低10至100倍。比在组件和系统级测试期间完成的工作要多。
他还引用了Freedman和Weinberg分别于1982年和1984年发表的两篇有关大型系统的出版物。第一个是“演练，检查和技术审查手册”，第二个是“演练，检查和检查手册”。在开发周期的早期应用评审可以将到达测试阶段的错误数量减少10倍。缺陷数量的减少导致测试成本降低了50％至80％。我将不得不更详细地阅读研究报告，但似乎花费还包括发现并修复缺陷。
Remus于1983年所做的一项研究“检查/审查中的集成软件验证”，研究了使用IBM加利福尼亚州圣塔特雷莎实验室的数据来消除不同阶段的缺陷的成本，特别是设计/代码检查，测试和维护。引用的结果表明成本比为1:20:82。也就是说，在设计或代码检查中发现的缺陷的变更成本为1。如果相同的缺陷无法通过测试，则成本将增加20倍。如果它一路逃脱给用户，它将使纠正成本增加多达82倍。Kan使用IBM位于明尼苏达州Rochester的设施的样本数据，发现AS / 400项目的缺陷清除成本是相似的在1:13:92。但是，他指出，成本增加可能是由于发现缺陷的难度增加。
提到了Gilb在1993年（“软件检查”）和1999年（“优化软件工程规范和质量控制过程”）有关软件检查的出版物，以佐证其他研究。
其他信息可以在Construx的“ 缺陷成本增加”页面上找到，该页面提供了许多有关缺陷修复成本增加的参考。应当指出，Code Complete的作者Steve McConnell创建并为Construx工作。
我最近听了讲座，真正的软件工程，由下式给出格伦Vanderburg在2010年他给在同一谈话在龙星红宝石会议苏格兰红宝石会议和Erubycon在2011年的QCon旧金山在2012年，和O'Reilly的软件架构会议在2015年。我只听过Lone Star Ruby会议，但是随着他的思想的提炼，话题随着时间的推移而发展。
范德堡（Venderburg）建议，所有这些历史数据实际上都在显示随着时间的推移而修复缺陷的成本，而不一定是随着项目的逐步进行而修复的。前面提到的论文和书籍中检查的许多项目都是顺序的“瀑布”项目，其中阶段和时间一起移动。但是，在迭代项目和增量项目中也会出现类似的模式-如果在一次迭代中注入缺陷，则在该迭代中进行修复将相对便宜。但是，随着迭代的进行，发生了很多事情-软件变得更加复杂，人们忘记了有关在特定模块或代码部分中工作的一些次要细节，需求也随之变化。所有这些都会增加修复缺陷的成本。
我认为这可能更接近现实。在瀑布式项目中，由于上游问题需要校正的伪像数量，导致成本增加。在迭代和增量项目中，由于软件复杂性的增加，成本增加。