质量的相对性
在上面的故事中，我之所以会陷入两难的境地，可以通过质量的相对性来加以解释。这个关于MiniCozy 公司的故事清楚地告诉我们：某个用户认为是质量完全过关的某个软件产品，另一位用户可能会认为质量不完全过关。
发现相对性
由于软件的质量，有过种种定义。只要考察一下这些定义，您就会发现上面提到的相对性。不过，只有仔细加以考察才能有所发现，因为这种相对性通常都被隐藏起来了；即使在最好的情况下，也是很不明显的。比如，让我们来看看Crosby 给出的定义：
所谓质量，就是"符合需求"。2
这反映了一些软件开发者的思想，他们认为用户的需求是无缘无故地从天上直接掉下来的，但是实际情况并非如此。因此，下面的定义会更为精确一些：
所谓质量，就是"符合某个用户的需求"。
正如可以从我外甥女的文字处理软件一事中看到的，对于不同的个人，同一个软件产品往往会体现出不同的"质量"。对于Terra 而言，她所关心的是其读者；但是对于MiniCozy 公司的那位项目主管来说，他关注的却是其用户中的主流。一旦认识到了这一点，我关于MiniCozy 的自我矛盾就迎刃而解了。
那个masked 的人是谁？
简而言之，我们不能脱离具体的人来抽象地谈论质量。
每一条关于质量的陈述，都是关于某个（某些）人的陈述。
这句话既明确又含糊。在大多数时候，"某个（某些）人"到底指谁并不明确，而且这类关于质量的定义，听起来就像摩西从西奈山上带下来的刻在石板上的东西{这里作者指的是十戒（Ten Commandments 或Decalogue ）。据《旧约全书》（the Old Testament）记载，在西奈山（Mount Sinai）上，神用指头在两块石板上写下十项戒律，赐颁给摩西。--译者注}一样。这也就是为什么虽然有那么多关于软件质量的清议空谈，但是最终却都徒劳无功--你崇拜的可能是金牛像{ Golden Calf，一种祭祀用的牛形金像，是以色列人崇拜的偶像。--译者注}，而我崇拜的却可能是石板。
如果能够考虑到质量的相对性，那么我们就可以利用这个工具来把这些讨论落实为实在的结果。每当有人提出一个关于软件质量的定义时，我们只需简单地问一句：
在这里所讨论的质量背后，到底是针对什么人而言的呢？
关于软件质量的组成要素，有很多提法已经为我们所熟知，但是它们常常又是互相矛盾的。现在，就让我们通过上述的启发式方法，重新审视一下这些提法。
高质量就是毫无纰漏
a. 对于某些用户而言的确如此--这些缺陷会把这些用户的工作搞砸
b. 对于某些主管而言的确如此--他们会因这些缺陷的存在而受到指责
高质量就是提供众多的功能
a. 对于某些用户而言的确如此--他们在工作中会因这些功能而受益（当然，如果他们
确实了解这些功能的话）
b. 对于市场营销人员而言的确如此--这些人坚信，功能越多就越有销路
高质量就是简洁而优雅编码
a. 对于开发人员而言的确如此--他们非常看重同行们的评价
b. 对于计算机科学领域的教授们而言的确如此--他们陶醉于简洁优雅
高质量就是高性能
a. 对于某些用户而言的确如此--他们的工作使他们的计算机不堪重负
b. 对于销售人员而言的确如此--他们销售的软件必须通过标准测试
高质量就是低开发成本
a. 对于某些用户而言的确如此--他们想要购买上千份该软件
b. 对于某些项目主管而言的确如此--他们在开发开发时囊中羞涩
高质量就是高开发速度
a. 对于某些用户而言的确如此--他们的工作正等着该软件下锅
b. 对于某些市场运营人员而言的确如此--他们企图在竞争对手来得及杀入之前，就独
霸市场
高质量就是高用户友好性
a. 对于某些用户而言的确如此--每天八个小时，他们都需要目不转睛地盯着屏幕使用
该软件
b. 对于另一些用户而言也是如此--每次使用该软件时，他们总是记不住上次使用时的
界面细节
行政上的两难
认识到质量的相对性，通常已经可以让我们摆脱语义上的两难困境。作为一本讨论质量的书，能够在一开始就解决这个问题，实在是难能可贵。但是，这还远不足以消除政治上的两难困境：
对某一个人而言更高的质量，也许对另一个人而言就意味着更低的质量。
比方说，如果我们的目标是提高"整体的质量"，那么我们就不得不对所有相关的用户作一权衡。这样，为了实现整体的高质量，我们就首先需要确定所有有关的用户，并对其各自的需求作充分全面的了解3。因此在每次设计中，对于任何的软件工程方法，我们将必须为对应于每个用户的质量进行衡量。然后再把这些测量的结果分别相加，才能比较采用不同方法所能获得的总体质量。
当然，在实际应用中任何软件开发项目都不会严格地进行这项繁杂的工作。取而代之的方法是，首先把大多数人排除在外，也就说首先确定清楚：
在进行决策的时候，应该考虑到谁的意见？
比如说，MiniCozy 公司的那位项目主管不仅对Terra 的意见毫不理会，而且认定在他进行软件工程上的决策时，Terra 的意见是微不足道的。从这件事上我们可以看出，软件工程并不是一个民主的过程。更为不幸的是，它也不是一个理性的过程，因为在确定究竟要考虑谁的意见时，往往是根据个人的主管情感做出判断的。
发表于 @ 2005年04月05日 17:18:00|评论(loading...)|编辑