qa - 浴缸曲线是否适用于现代软件？

Question

当然软件不会磨损，但几十年前人们普遍认为，在应用程序的生命周期代码维护后期引入的错误比修复的要多。

但是浴缸曲线是否适用于用现代软件工程方法 开发的现代软件呢？

Answer 1

简短的回答是“是”。长答案是浴缸分布不是一个很好的模型，因为故障的工作方式缺乏连续性。例如，输入值 42 会导致除零错误；那么这些故障的分布将恰好是输入中 42 个值的分布。正如您所说，它不像硬件：软件不会随着时间的推移而失败，它会在错误时失败。

现在，您可能在这里误用了这些词：您的意思是缺陷而不是失败。失败是一种不正确行为的发生；缺陷是实现中的缺陷，是“错误” 。

软件中缺陷的出现往往具有浴缸般的分布，但实际上并不像您的图片那样干净：错误往往会在早期被观察到并逐渐减少，然后在补丁和新版本中激增，一般上升趋势开始深入软件的生命周期。但是，即使这样也需要仔细定义，因为您实际上是在谈论每单位时间观察到的缺陷。

现在，话虽如此，现代 SE 实践倾向于改变实际比率，而不是随着时间的推移观察到的缺陷的分布。这里的“现代”也值得稍微定义一下：航天飞机 HAL 软件的缺陷率非常低，使用了 20 年前“现代”的 SE 技术：强大的规范、结构化编程、严格的审查以及 OCD 版本控制和测试。极限编程往往具有较低的“缺陷”率，但许多更传统的方法称之为“缺陷”的东西 XP 称之为“用户输入”——因为它应该做什么没有有限和严格的定义，“缺陷”只是另一个故事。

有一些不错的研究表明 XP/TDD 确实会导致低缺陷率，但如果缺陷/单位时间分布是不同的形状，我会感到非常惊讶。

Answer 2

浴缸曲线实际上是硬件故障的描述（而且是一个很好的故障）而不是软件。

但是，软件也有类似的情况。一般来说，在大多数软件生产中，我们创造复杂性的能力继续略微超过我们处理复杂性的能力 --- iow 有某种彼得原则在工作，软件系统（集体）变得复杂，直到它们变得无法管理，并且然后呆在那里。因此，虽然今天我们在处理 1990 年代的一些系统性问题方面比当时要好得多，但我们在处理 00 年代的系统性问题方面并没有好多少。这就是人生。

不过，我不认为这看起来很像浴缸。

Answer 3

并非如此，大多数错误是在软件的初始部署期间发现的。在那之后，它通常是一组渐进的错误，主要是由修改代码或添加新功能引起的。与最初的代码发布完全不同。随着制作原始产品的开发人员死亡，升级停止，错误也停止了。

Answer 4

我认为图表中有一些（小）真相。在第一个或两个版本之后，您将引入新功能和新错误以及对以前错误的错误修复，所以我认为您会不断收到新错误。但一段时间后，代码库变得脆弱且难以维护，因此我相信新错误的流量会急剧上升。那是最终（希望）你可以说服你的老板停止修补并开​​始重新设计的时候。

Answer 5

我认为这在很大程度上取决于它的维护情况。我有一个大型 GUI 应用程序，实际上我是唯一维护它的程序员，而且它的缺陷频率多年来一直在稳步下降，而且我预计它在未来的任何时候都不会上升。

但是，如果我让初级程序员维护它，我不会有同样的感觉，因为维护程序员很容易编写一个“足够好”的修复程序而不是“正确的”修复程序。我不能完全责怪他，他可能没有原始程序员所做的代码知识。

关于浴缸的右侧，如果您考虑外部因素，例如操作系统，那么可能存在一些相关性，因为我有一些应用程序被较新版本的 Windows 破坏，通常不是应用程序的故障。但这是一个相对较小的数字。