什么是软件质量？

如果你们中有人听到我在培训课程或会议上讲话，您会发现我引用Philip Crosby的话：“ 质量是免费的！ ”。 克罗斯比（Crosby）谈论导弹生产的背景，但这一消息被汽车业和硅芯片业所接受（1980年的“ 安德森炸弹壳 ”（ Anderson Bombshel​​l）解释了日本RAM制造商如何比美国人便宜和质量更高）。 我非常喜欢将该论点应用于软件。

我喜欢引用Capers Jones的话：“具有低缺陷可能性和高缺陷去除效率的项目也具有最短的进度，最低的成本和最佳的客户满意度。” （Capers Jones，《 应用软件评估》 ，2008年）

汤姆·吉尔布（​​Tom Gilb）说，他并不孤单：“减少缺陷……可以节省'返工'，否则这大约占软件项目所有工作的一半。” （Tom Gilb， 竞争工程 ，2005年）。

乔恩·贾格尔（Jon Jagger）让我开始对Xanpan中软件质量，缺陷和返工的草率讨论。 因此，我试图对软件质量的定义进行一个（简洁的）定义，事实证明，这比您想象的要困难得多。

令我失望的是，琼斯没有给出定义。

Gilb提供了“缺陷：未能遵守正式的书面要求的规则。 这不是个人意见或个人品味。 这是违反团体规范或要求的最佳实践的失败。”

听起来很不错，直到您将陈述分解成碎片：

• 如果规则是非正式的怎么办？ 我想我们可以允许非正式的，默认的规则，因为它们是“群体规范”。
• “书面”假设有书面内容，这不是我可以接受的假设。 琼斯指出，文档修复是仅次于缺陷的第二昂贵的活动，因此我不希望消除缺陷，但要以增加写作成本为代价。
• “个人意见或品味”似乎很公平，但是将其付诸实践可能会非常困难。 我知道很多时候我会将缺陷称为个人品味，但提出问题的人却不会
• 当您开发将改变团体规范的产品时，“团体规范”特别困难
• 还有“最佳实践”……。 谁说这是最佳做法？ 谁说不能再改善了？

我喜欢吉尔布的定义，但我认为这还不够。 至关重要的是，即使说“不是个人观点”，也无法避免“一个人的错误是另一个人的特征”问题。

关于软件质量和缺陷，我们能说些什么？

• 软件质量与系统缺陷的数量成反比：高质量意味着很少的缺陷，反之亦然
• 缺陷会产生不良后果
• 缺陷产生的成本很可能是财务成本，但还有其他成本，尤其是时间。 即使无法修复缺陷，也将产生成本，例如，金融系统的超额付款或拨打求助热线报告拼写错误的人
• 消除缺陷需要返工，并且返工会花费时间和金钱

这可能是更长列表的开始，我所描述的是我归因于“高质量软件”的属性或质量。

该清单也是自我实现的：到目前为止，我所说的一切都暗示着低质量，大量缺陷会增加成本，因此Crosby，Jones和Gilb的报价都变得自我实现。 也许这不是问题，也许我们希望从软件中获得的质量属性是降低成本。

但是，我想从阴险的高质量软件中获得另一种品质。 高质量的软件应该是可变的–实际上，所有软件都是可变的（软！），但是某些代码比其他代码更容易更改。

易于更改的高质量软件

让我们简单地定义一个简单的定义，我同意应该对它进行量化，但现在不行。

我说“改变”是什么意思？ 我认为这种精神被我一直很喜欢的老约翰·弗利斯赛德语录所俘获：

“良好的面向对象设计的一个标志-甚至不是标志-您可以通过添加代码而不是对其进行修改来修改和扩展系统……” 简而言之，变化是累加的，不是侵入性的。 与侵入性变更相比，附加变更可能更容易，更本地化，更不易出错，并且最终更易于维护。” John Vlissides，《 C ++报告》，1998年2月

我准备将其推广到所有软件，而不仅仅是OO软件。 我什至可能更着重于“而不是对其进行黑客攻击”-尽管然后需要定义“黑客攻击”。 好的软件需要允许更改，而不是强迫更改。

实际上，此引用还提供了我们需要定义“易于更改”的属性

• 变更已本地化
• 变更不太容易出错-也许更好地表述为“变更不会注入缺陷”（在Jones的某个地方，他建议7％的缺陷修复程序注入新缺陷，因此高质量的软件的错误修复程序注入率将低于7％）
• 更改更易于维护，即更改软件不会降低软件的可更改性

如果具有这些属性（如果需要，则具有质量），则软件质量较高，因此更改成本较低。 质量和成本之间的关系再次出现。

但是，我描述质量－成本链接的方式与许多人的看法相反：陈规定型的项目经理将质量视为可以降低的属性，以加快开发和降低成本。 我不得不说我很难真正理解这种观点，但这可能是因为我定义质量的方式。

除此之外，还有另一个接近的危险：过度设计。

到目前为止，我们已经说了这么多，您可以争论一下，花很多时间来设计软件以显示所有这些属性。 您可以寻求构建，设计不需要重新设计本身的软件。 毕竟是返工吗？

现在，我一直相信有返工，也有返工：

• 返工以修复错误，缺陷，是很糟糕且浪费的，因为您不应该首先将错误放在其中。
• 进行返工以更改软件以适应新的需求，即使这意味着重新设计（重构）设计是好的，或者至少可以接受，因为您可能事先不知道这一点，因此为满足此需求而进行的任何努力都可能放错了地方，并且实际上可能最终使设计复杂化。 换句话说，这是自我击败。

在我看来，这里存在一个知识问题：您需要在知识范围内进行工程设计（如果您知道或可以容易地找到一些信息），这些信息会使您的工作方式与您应做的不同。 但是，如果有您不知道的信息，并且要花时间/花费很多，甚至无法找到，那么推迟知道并接受返工将是可以接受的。

因此问题开始成为知识获取之一。 获取更多知识的一种方法是通过反馈，当快速，及时且廉价地获得反馈时，我们可以快速扩展我们正在使用的知识。

鉴于当前所需的知识，高质量的软件应尽可能避免出现缺陷，但是当有新知识需要进行更改时，可以自由更改。

将其写为：

质量（T）=可变性（T）/已知缺陷（T）

其中T代表某个时间点，随着时间的推移，可更改性可能会大大降低，哪些已知缺陷可能会上升或下降。

请注意，我已经说过：“已知缺陷”而不是“已知变更”。 对于一件成功的，成功的软件，将列出人们希望对该软件进行的更改。 该列表的存在实际上表明了高质量软件的另一个属性：人们使用它并改变价值。 （另一方面，低质量的软件可能有很多错误，以至于人们避免使用它，因此不要求更改。）

排除像这样的非缺陷更改确实会带来一个问题，即缺陷报告（错误）实际上是缺陷报告还是变更请求。 在某些组织中，此类辩论很激烈，但通常毫无意义。 有时他们确实是Cap Ex诉Op Ex的讨论，有时他们是“谁会这样做？” 或“何时完成？” 讨论中，有时他们是“谁来付钱？” 讨论。 所有这些以及更多的问题困扰着这种测量。

尽管我想敞开大门说：“所有工作都要做，但一个积压工作”就是将方程式和论点从水里捞出来，因为正如我刚才所说，高质量的软件可能会与低质量的软件相比，更改请求的列表更长。

因此，现在我们必须考虑有关内部质量与外部质量的争论。 但是此博客条目准备太久了。

这有道理吗？

这有帮助吗？

我是否更接近定义软件质量？

也许吧，但我认为我还没有回答我自己的问题！

写这篇文章对我有帮助。 我认为我已经找到了可能的质量定义，尽管我仍然需要定义缺陷。 我认为我们需要考虑质量和缺陷的属性。 我认为这里存在一个与知识有关的暂时性问题（但我不知道该如何建模或定义它。）我对成本和质量之间的关系比以往更加困惑，因为它看上去是循环的。

有人有更好的主意吗？ –还是只是评论？

参考： 什么是软件质量？ 来自我们的JCG合作伙伴 Allan Kelly，来自敏捷，精益，模式博客。

翻译自: https://www.javacodegeeks.com/2013/09/what-is-a-software-quality.html