【发布时间】：2009-04-10 15:04:20
【问题描述】：
当然软件不会磨损，但几十年前人们普遍认为，在应用程序的生命周期代码维护后期引入的错误比修复的要多。
但是浴盆曲线是否适用于使用现代软件工程方法开发的现代软件？
【问题讨论】：
标签： qa
【发布时间】：2009-04-10 15:04:20
【问题描述】：
简短的回答是“是”。长答案是浴缸分布不是一个很好的模型，因为故障的工作方式缺乏连续性。例如，输入值 42 会导致除零错误；那么这些故障的分布将恰好是输入中 42 个值的分布。它不像你所说的硬件：软件不会随着时间的推移而失败，它会在出错时失败。
现在，您可能误用了这里的词语：您的意思是 defect 而不是 failure。 failure 是一种不正确行为的发生； defect 是实现中的一个缺陷，一个“错误”。
软件中缺陷的外观往往呈浴缸式分布，但实际上并不像您想象的那样干净：错误往往会在早期被观察到并逐渐减少，然后在补丁和新版本中激增，总体上升趋势开始进入软件的生命周期。不过，即使这样也需要仔细定义，因为您实际上是在谈论每单位时间观察到的缺陷。
话虽如此，现代 SE 实践往往会改变实际发生率，但不会改变观察到的缺陷随时间的分布。这里的“现代”也值得一点定义：航天飞机 HAL 软件的缺陷率非常低，使用了 20 年前“现代”的 SE 技术：强大的规范、结构化编程、严格的审查以及 OCD 版本控制和测试。极限编程往往具有较低的“缺陷”率，但许多更传统的方法称为“缺陷”的事情 XP 将其称为“用户输入”——因为它应该做什么没有有限和严格的定义，“缺陷”只是另一个故事。
有一些不错的研究表明 XP/TDD 确实会导致低缺陷率，但如果缺陷/单位时间分布是不同的形状，我会感到非常惊讶。
【讨论】：
浴缸曲线实际上是硬件故障的描述（而且是一个很好的故障）而不是软件。
但是，软件也有类似的情况。一般来说，在大多数软件生产中，我们创造复杂性的能力继续略微超过我们处理复杂性的能力 --- i.o.w.有某种彼得校长在工作，软件系统（集体）变得复杂，直到它们变得无法管理，然后一直呆在那里。因此，虽然今天我们在处理 1990 年代的一些系统性问题方面比当时要好得多，但我们在处理 00 年代的系统性问题方面并没有好多少。这就是生活。
不过，我不认为这看起来很像浴缸。
【讨论】：
并非如此，大多数错误是在软件的初始部署期间发现的。在那之后，它通常是一组渐进的错误，主要是由修改代码或添加新功能引起的。与最初的代码发布完全不同。随着制作原始产品的开发人员死亡，升级停止，错误也停止了。
【讨论】：
我认为图表中有一些（小）事实。在第一个或两个版本之后，您将引入新功能和新错误以及对以前错误的错误修复，因此我认为您会不断收到新错误。但过了一段时间，代码库变得脆弱且难以维护，所以我相信新错误的流量会急剧上升。到那时（希望）最终你可以说服你的老板停止修补并开始重新设计。
【讨论】：
我认为这在很大程度上取决于它的维护情况。我有一个大型 GUI 应用程序，实际上我是唯一维护它的程序员，而且它的缺陷频率多年来一直在稳步下降，而且我预计它在未来的任何时候都不会上升。
但是，如果我让初级程序员维护它，我不会有同样的感觉，因为维护程序员很容易编写“足够好”的修复程序而不是“正确的”修复程序。我不能完全责怪他，他可能没有原始程序员所做的代码知识。
关于浴缸的右侧，如果您考虑外部因素，例如操作系统，则可能存在一些相关性，因为我有一些应用程序被较新版本的 Windows 破坏，通常不是应用程序的错误.但这是一个相对较小的数字。
【讨论】：