问为什么SW质量被说成是上下文的.难道不是任何东西的质量都是这样吗？

EN

作者似乎试图传达的是，软件产品的“质量”通常更多地是关于最终用户(S)的感知和期望，而不是您可以应用到它的某种可量化的属性(例如编码标准、设计标准、安全标准等)，或者它的创建者的看法。

例如，一位称职的开发人员会指出一个古老的代码库，它已经变成了一个用过时的语言写成的“大泥球”，违反了所有现代设计原则，充斥着安全缺陷和后门(双关不是故意的)，对于维护工程师来说是脆弱的，并且有一个极其不友好、过于复杂的用户界面，并且说“这个软件糟透了！”

然而，在终端用户眼中，同样的软件可能会做那些用户需要或期望它做的所有事情。这些用户不会“看到”下面可怕的代码库，任何确实出现的缺陷通常都能以某种方式修补。

在这类软件的经验丰富的用户(尤其是拥有使用该软件的权利的人，并可能在几十年内为其开发/维护支付了数百万美元)看来，如果它被认为“足够好”、“足够稳定”和“它应该做的工作”，那么它通常会在质量箱中赢得一个巨大的橡皮图章。

这种观点并不是软件独有的，尽管它在软件中最常见，因为世界上仍有数以百万计的企业仍然依赖几十年前建造的软件；他们对“质量”的判断往往是--“它让我们赚到的钱比我们付出的多吗？(而且/或会让我们花费更多的钱)”和“它是否能保持我们的良好声誉？”

你能把这个应用到其他领域吗？也许吧，但对于“有形的东西”来说，它就不那么常见了，这些东西可以被拿起来，握在你的手里，“存在于现实世界”--尤其是那些物理/机械的东西会随着时间的推移而腐烂和褪色的时候(例如汽车有里程，机械的东西会磨损，东西会被过度狂热的用户破坏等等)--软件不会因此而受影响！

因此，除了代码没有“腐烂”(除非是软件工程师的不当行为)之外，软件的内部运作是如此的不透明，而且用户离它们很远，因此代码的“质量”以及安全缺陷、可用性问题和模糊的bug/缺陷对普通用户来说几乎是看不见的。

在引用的部分中没有任何地方表明只有软件质量取决于上下文。因为这本书是关于软件质量的，它有意义的是，它采取软件组件而不是硬件组件和软件质量而不是硬件质量。

有两个方面要看。

首先，考虑一下你如何衡量质量。

对于物理项目，你可以应用化学和物理的规则。您可以制作非常详细的模型，并运行基于计算机的物理设计模拟。然后，在制造之后，您可以取样并执行测试(包括符合或超过所需特性的破坏性测试)。

使用软件，您可以编写测试代码和手动测试过程来执行软件的各个部分，但是测试结果只能与测试用例一样好。过程和产品质量都有不同的度量和度量，但没有一个是精确的。

接下来，考虑一下你对质量的衡量可以做些什么。

使用物理项目，您可以描述产品的限制。您知道，您的小部件可以加速如此之快，或在某一角度保持如此大的重量，或在失去功能之前达到一定的温度。您不仅可以描述组件测试的环境(S)，还可以描述您确信小部件能够完成其工作的环境。

使用软件，环境中有许多变量。你不能总是控制操作系统，第三方库和软件包版本，处理器速度，内存，显卡，磁盘空间和速度，网络延迟，用户负载等等。您可以指定任何需求或依赖项，但用户可能以意想不到的方式使用您的软件，或者环境可能退化或配置不当。在您测试的环境之外使用它可能会导致发现软件的问题。您的软件可能在过程中具有很高的质量，但是在不同的环境中部署它会导致感知质量的差异。

我不认为这是专门针对软件的。我在车库里有一把斧头，它的质量很大程度上取决于我是用它劈开木柴(好的质量)，作为一种镇静剂(很好的质量)，还是从我的车的挡风玻璃上移除雪和冰(质量很低，玻璃和冰一样多)。