《软件工程（第4版?修订版）》—第1章1.3节什么是好的软件

本节书摘来自异步社区《软件工程（第4版?修订版）》一书中的第1章1.3节什么是好的软件，作者【美】Shari Lawrence Pfleeger , 【加】Joanne M.Atlee，更多章节内容可以访问云栖社区“异步社区”公众号查看。

1.3 什么是好的软件
软件工程（第4版•修订版）
正如制造商寻找各种方法以确保他们生产的产品的质量一样，软件工程师也必须寻找各种途径来确保他们的产品具有可接受的质量和功效。因此，好的软件工程必须总是使用开发高质量软件的策略。但是在我们设计一个策略之前，必须理解高质量软件的含义是什么。补充材料1-2说明了不同的视角是如何影响“质量”的含义的。在本节中，我们研究好的软件和差的软件之间的区别是什么。

补充材料1-2 关于质量的各种视角

Garvin描述了不同的人是如何认识质量的（Garvin 1984）。他从5种不同的视角对质量加以描述。

• 先验论的观点：质量是可认知但不可定义的。
• 用户的观点：质量是恰好达到目的。
• 制造业的观点：质量是与规格说明的一致。
• 产品的观点：质量是与产品的内在特征相联系的。
• 基于价值的观点：质量取决于客户愿意支付的金额。

先验论的观点很像柏拉图对理想的描述或亚里士多德关于形式的概念。换言之，就像每个真实的桌子都是接近理想的桌子一样，我们可以把软件质量认为是我们努力的理想。然而，我们可能永远也不能完全实现它。

先验论的观点是无形的。它与用户更为具体的观点形成对照。当我们测量产品特性（如缺陷密度或可靠性等）的时候，为了理解整个产品质量，我们采用用户的观点。

制造业的观点是在开发过程中以及交付后考虑产品质量。尤其是，它检查产品是否第一次就构建正确，以避免花费大量重复劳动去修复产品交付后的故障。因此，制造业的观点是过程的观点，它提倡遵守良好的过程。然而，几乎没有什么证据能够说明遵守过程就会真正生产出含有较少故障或失效的产品。过程可能确实会导致高质量的产品，但是也可能使生产低质量的产品成为制度化。我们将在第12章分析其中一些问题。

用户和制造业的观点从外部来考虑产品，而产品的观点是从产品内部考察产品并评估产品的内在特性。这通常是软件度量专家所提倡的观点之一，他们假设良好的内部质量指标将会导致良好的外部质量，例如可靠性和可维护性等。然而，仍需要做更多的研究工作来对这些假设加以验证，确定哪些方面的质量会影响产品的实际使用。我们可能必须要开发将产品观点和用户观点联系起来的模型。

客户或市场人员通常采取用户的观点来看待质量。研究人员有时采取产品的观点，而开发团队则会持有制造业的观点。如果未对这些观点之间的差异加以明确，则由此造成的混淆和误解可能会导致错误的决策和劣质的产品。基于价值的观点，可以将这些完全不同的质量描述联系起来。通过将质量与客户愿意支付的价钱等同起来，我们可以在产品价格和质量之间进行权衡，当冲突发生时能够加以控制。类似地，购买方将产品的价格与潜在的收益进行比较，他们按照金钱的价值来考虑质量。
Kitchenham和Pfleeger在一期IEEE Software质量专刊的导言中，研究了这个问题的答案（Kitchenham and Pfleeger 1996）。他们指出，背景有助于答案的确定。字处理软件的容错程度在安全攸关或关键任务的系统中，可能是无法接受的。因此，我们必须至少以3种方式考虑质量：产品的质量、生产该产品的过程的质量以及在将使用产品的商业环境背景下产品的质量。

1.3.1 产品的质量
我们可以要求人们命名影响整体质量的软件特性，但是，从每一个我们询问的人那里得到的答案很可能是不同的。之所以出现这种差异，是因为特性的重要性取决于分析这个软件的人。如果软件用易于学习和易于使用的方式做了用户想要它做的事情，用户就断定软件是高质量的。但是，有时质量和功能是相互关联的。如果一个软件难以学习或难以使用，但是它的功能值得这些付出，那么仍然可以认为它是具有高质量的软件。

我们设法测量软件质量，以便能够将一个产品与其他产品进行比较。要做到这一点，就要找出影响系统整体质量的那些方面。因此，在测量软件质量的时候，用户从故障数目和故障类型等外部特性进行评价。例如，他们可能将失效分为次要的、主要的以及灾难性的，并且希望所发生的任何故障都是次要的。

软件还必须由那些设计和编写代码的人员以及维护该程序的人员来评价。这些实践人员倾向于考虑产品的内部特性，有时甚至会在产品交付给用户之前就考虑这些内部特性。尤其是，实践人员通常会把故障的数目和类型看作为产品质量（或缺乏质量）的证据。例如，开发人员跟踪在需求、设计和代码审查中发现的故障数目，并把它们作为最终产品可能的质量指示器。

由于这样的原因，我们通常要建立模型，把用户的外部视图和软件开发人员的内部视图联系起来。图1-5所示是一个早期质量模型的例子，由McCall和他的同事构建，说明外部的质量因素（在图的左边）与产品质量标准（在图的右边）是如何联系在一起的。McCall为右边的每一个标准都关联一种测度，以说明一个质量要素受关注的程度（McCall, Richards and Walters 1977）。我们将在第12章研究若干产品质量模型。

1.3.2 过程的质量
有很多活动会影响到最终的产品质量。只要有活动出了差错，产品的质量就会受到影响。因此，许多软件工程师认为开发和维护过程的质量与产品的质量是同等重要的。对过程进行建模的一个优点是，我们能够研究它，并寻找方法对它加以改进。例如，我们可以提出下面的问题。

在什么时间、什么地点，我们可能发现某种特定类型的故障？
如何能够在开发过程的更早期阶段发现故障？
如何构建容错机制以便把故障演变为失效的可能性降到最低？
是否有一些其他的做法能够在确保质量的前提下使我们的过程更加高效或有效？
这些问题可以应用于整个开发过程或其中一个子过程（如配置管理、复用或测试等）；我们将在后面的章节中研究这些过程。

20世纪90年代，软件工程重点宣扬的是过程建模和过程改进。受到Deming和Juran工作的启发并由IBM等公司实现的能力成熟度模型（CMM）、ISO 9000、软件过程改进及能力确定（SPICE）等过程指导原则提出：通过改进软件开发过程，可以提高最终产品的质量。在第2章中，我们将看到如何识别相关的过程活动，并用模型表示它们对中间产品和最终产品的影响。第12章和第13章将深入分析过程模型并改进框架。

1.3.3 商业环境背景下的质量
当质量评价集中于产品和过程的时候，我们通常使用包含故障、失效和计时的数学表达式来测量质量。人们很少会拓展到商业的视角。在商业环境中，质量是根据软件所处的商业环境提供的产品和服务来看待的。也就是说，我们考虑的是产品的技术价值，而不是更广泛的商业价值，而且我们只根据最终产品的技术质量来做出决策。换句话说，我们假定改进的技术质量会自动转化为商业价值。

一些研究人员仔细研究了商业价值和技术价值之间的关系。例如，Simmons访问了很多澳大利亚企业，以确定他们是如何做出与信息技术相关的商业决策的。她提出了一种理解公司的“商业价值”含义的框架（Simmons 1996）。在Favaro和Pfleeger的报告（Favaro and Pfleeger 1997）中，一家大型美国保险公司Cigna的信息主管Steve Andriole描述了他的公司是如何区分商业价值与技术价值的：

我们通过显而易见的度量来测量（软件的）质量：运行时间与停机时间、维护成本、与修改相关的成本，等等。换句话说，我们在成本参数范围内根据操作性能来管理开发。比起厂商提供的成本-效益性能，我们更关心工作量的结果……商业价值与技术价值相比，前者与我们更贴近……也是我们重点关心的问题。如果我知道公司为追求技术价值将以牺牲商业价值为代价签订合同，我会非常吃惊。如果两者有所不同，我宁可选择后者。如果没有（所期望的）明确的商业价值（可量化地描述：可处理的要求数量等），那么我们不会启动一个系统项目。在“有目的性的”项目需求阶段，我们非常认真，我们会问“我们为什么需要这个系统？”以及“我们为什么关心它？”

人们一直尝试着以量化的、有意义的方式将技术价值和商业价值联系起来。例如，Humphrey、Snyder和Willis指出，根据CMM“成熟”度等级改进其开发过程（将要在第12章中讨论），Hughes飞机制造公司的生产率提高了4倍，并且节省了数百万美元（Humphrey, Snyder and Willis 1991）。类似地，Dion报道，雷神公司的生产率增加了2倍，并且过程改进中每1美元的投资都有7.7美元的回报（Dion 1993）。在俄克拉何马州的Tinker空军基地，工作人员注意到其生产率提高了6.35倍（Lipke and Butler 1992）。

但是，Brodman和Johnson更仔细地研究了过程改进的商业价值（Brodman and Johnson 1995）。他们调查了33家执行了一定过程改进活动的公司，并且研究了几个关键事项，除此以外，Brodman和Johnson还询问了这些公司是如何定义投资回报（Return on Investment, ROI）的——这是一个在商业界明确定义的概念。他们注意到教科书中的投资回报的定义来自金融界，把投资解释为为了其他目标而做的付出。也就是说，“投资不仅仅是收回原始资本，而且收回必须足够多，至少等于这些资金在其他地方所能赚来的利润，再加上风险金”（Putnam and Myers 1992）。通常，商业界使用下面3种模型中的一种来评价ROI：回收模型、会计收益率模型和折现值现金流模型。

但是，Brodman和Johnson发现，美国政府和美国工业界以不同的方式来解释ROI，并且这两种方式与商学院的标准方法也不同（Brodman and Johnson 1995）。政府根据美元来看待ROI，同时考虑减少运作成本、预测节省的美元以及计算采用新技术的成本。政府投资也是用美元来表示，如引入新技术的成本或启动过程改进的成本等。

另一方面，工业界根据项目工作量而不是成本或美元来看待投资。也就是说，公司感兴趣的是节省时间和使用更少的人，而他们对投资回报的定义也体现出他们将重点放在减少工作量上。在对这些公司的调查中，投资回报包含下列各项：

培训；
进度；
风险；
质量；
生产率；
过程；
客户；
成本；
业务。
定义中的成本包含达到预计成本、提高成本效率，以及维持在预算范围之内，而不是减少运转成本或使项目或组织机构简单化。图1-6总结了许多组织使用ROI定义的投资项目的频率。例如，那些被访问的企业中，大约有5%将质量小组的工作量包含在ROI的工作量计算中，大约有35%的企业在考虑投资规模时包含了软件成本。

观点之间的差异带来了很大麻烦，因为它意味着组织之间ROI的计算是不可比较的。但是，也有其合理之处。因为缩短的进度、更高的质量、提高的生产率等因素节省的美元都返回给了政府而不是承包商。另一方面，承包商常常追求竞争优势、提高的劳动能力以及更大的利润，因此，承包商的ROI更多地是基于工作量而不是基于成本的。尤其是，更精确的成本和进度估算意味着客户的满意度和多次的商业机会，并且缩短投入市场的时间以及提高的产品质量也被认为是提供了商业价值。

尽管每个组织都可以对不同ROI计算方法进行调整，但令人担心的是，软件技术的ROI与金融的ROI是不同的。有些时候，程序的成功必须报告给高层管理机构，其中很多与软件无关而与公司的主要业务（如通信或银行业等）相关。用相同的术语表示截然不同的事物，会造成混淆。因此，成功的标准不仅要对软件项目和过程有意义，而且要对支持更一般的业务实践也有意义。第12章将讨论使用几种公共的商业价值测量来选择技术。

本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。