前言

本书的目标读者是软件经理、执行主管，以及参与规划、估算、执行和维护软件的质量保证人员。当规划和开发新的应用程序以及改进或维护现存的应用程序时，经理和利益相关者需要理解软件质量经济学。

本书的目标是量化那些影响软件质量的因素，并给读者提供足够的信息，以便他们预测和度量他们的项目及应用程序的质量水平。

为了服务这个目标，我们加强扩展软件质量数据——这些数据是关于软件结构质量、软件保证过程和技术，以及提高软件质量的边际成本和收益的相关数据。本书提供了有关高质量和低质量如何影响软件项目进度、人员配备、开发成本和维护成本的定量数据。这种信息使软件经理能够对质量目标设定和跟踪过程，并在产品上市速度与商业风险之间做出正确的取舍。

我们使用来自私人和公共部门的大型组织的软件质量数据，来量化软件质量的正面经济价值，同时也量化差的软件质量的高成本。这不是一本关于“如何做”的书，有很多关于如何做的好书，它们描述了关于测试、审查、静态分析以及其他质量主题的过程和技术。我们希望增加大量来自现实世界的应用程序的质量数据，来作为那些介绍如何做的书的补充，从而使IT经理们能够量化这些技术的相对功效和经济价值。

在小型项目中，个人技能和经验在成功的结果中扮演着重要的角色。质量是重要的，但是个人技能往往是高质量的绝对驱动因素。

但是，当项目逐渐变大，开发团队从20人增加到超过1000人的时候，个人技能往往就回归到平均水平了。质量变得越来越重要，因为从历史上看，对于大型软件应用程序，发现和修复bug的成本已经是已知的最大费用。这一点不单对新开发，对改进及维护都是如此。

大部分有关软件质量的讨论几乎无一例外地都聚焦在功能质量上。在本书中，我们超越功能质量来扩展我们的处理范围，以覆盖非功能和结构质量。度量结构质量需要超越单个组件的质量，而将应用程序的质量作为一个整体来看待。我们将展示如何清晰地定义和可重复地度量非功能与结构质量。

全部三种质量——结构质量、非功能质量和功能质量——的可靠度量对于软件质量经济学的一个完整处理而言都是必不可少的。我们使用这些质量度量指标，来比较软件开发生命周期每个阶段中大量的质量改进技术，同时使用来自现实世界应用程序中的数据来量化它们的功效。

大型系统为了达到高质量水平，一个协同的方法集是必要的。这些方法集包括缺陷预防方法，可以降低缺陷等级；审查和静态分析等测试前缺陷清除方法；以及40多种测试方法。

相比传统的“瀑布”开发而言，不少较新种类的开发方法对软件质量也有有益的影响。其中包括敏捷开发、水晶开发、极限编程（XP）、个人软件过程（PSP）、Rational统一过程（RUP）、团队软件过程（TSP）以及其他一些方法。

软件行业普遍较差的度量实践，使得人们模糊了对软件质量经济学的理解。许多高管甚至有些质量人员，往往将软件质量视为一项花费。他们也往往把质量看作这样的一个主题，即认为质量延缓了进度并增加了开发成本。

然而，通过对1973年至今的大约13000个软件项目的分析，我们很高兴地看到，高质量水平总是与快于平均的开发进度和低于平均的开发成本相联系的。

之所以如此的原因是，大部分上线延迟并超出预算的项目在测试开始之前都没有显示出明显的问题征兆。当测试开始时，高严重程度缺陷的泛滥往往会延长测试时间，并且引发大规模加班。一般而言，低质量大型项目的测试时长是高质量项目的两到三倍，而测试成本要比高质量项目高出一倍多。如果缺陷直到测试开始都还没有被发现和清除，那么就太迟了而不能使软件项目再次可控。如果在测试之前就预防缺陷或者清除缺陷，这样做的成本效益会更好。

另一个隐藏了软件质量经济价值的糟糕度量实践是使用每个缺陷的成本这一度量指标。“在产品交付之后修复一个bug的成本是在开发期间修复它的100倍”，这已经成为一个现代传奇。遗憾的是，每个缺陷的成本这个度量指标实际上对质量是不利的，bug最多的软件反而获得了最低的度量值。随着质量的提高，每个缺陷的成本会上升，直到达到零缺陷的水平，这时，这个度量指标就不能再使用了。

高质量真正的经济价值只是部分地与缺陷修复成本相关。诚然，高质量只带来较少的缺陷并因而降低了缺陷修复成本。但是，其主要的经济效益是由于这样的事实，即高质量能够：

●减少大型系统取消的可能性；

●减少对于外包项目诉讼的可能性；

●缩短开发周期；

●降低开发成本；

●降低维护成本；

●减少保证成本；

●提高客户满意度。

本书共包含7章。第1章中的引言讨论了软件已经成为人类历史上应用最为广泛的产品这样一个事实。正如本书所写到的，大多数商业活动都是由软件驱动的。大部分的政府运作是由软件控制的，比如民用税收、军事和防御系统，包括州和地方政府组织。软件是如此普遍，以至于质量水平的高低深刻影响着每一位公民。

第1章定义了软件质量，考虑了质量对于软件本身和对于其他工业产品都是模棱两可的这一主题。对于“质量”实际上意味着什么有很多不同的看法。第1章介绍了所有常见的观点，并认为对质量的有效定义需要在事情发生前是可预测的，并且在事情发生时是可度量的。因为本书会论及量化和经济主题，所以就有对质量因素的强调，这些质量因素可以精确度量，如缺陷和缺陷清除效率。除了这些明确定义的度量指标，我们还展示了如何精确地度量软件结构质量。质量的其他定义，例如健康、使用或审美因素，虽然也很重要，但并不总是与经济分析相关。

第2章讲述软件质量的估算和度量。理解在项目开始之前如何预测软件的质量，以及如何在开发过程中以及在产品发布后度量软件的质量，这点对于高管、客户、利益相关者、风险投资家以及在软件中有经济利益关系的其他人而言，都是重要的。因为软件质量涉及需求、架构、设计和许多其他的非代码制品，所以传统的代码行度量指标是不合适的。本书使用功能点度量指标和结构质量度量指标来量化质量。功能点度量指标独立于代码，因此可以处理非编码的缺陷（如“不良需求”）。结构质量度量指标是获得应用程序质量的根源，并充当软件成本和商业风险的基本度量指标。

第3章讨论缺陷预防这一重要主题。能够减少潜在缺陷并最大限度地减少错误的方法是很难研究的，因为无法孤立地研究它们。要想研究这些方法，需要有使用一种特定方法的大量案例，以及不使用该方法的类似案例。已经被证明在预防缺陷方面的成功方法有六西格玛、质量功能展开（QFD）、测试驱动开发（TDD）以及正式审查。来自日本的Kaizen和Poka yoke审查也是缺陷预防方法。其中有些方法（如审查）作为缺陷预防和缺陷清除方法都是有效的。

第4章论及当今使用的测试前缺陷清除方法。术语“测试前”（pretest）是指在测试开始之前产生的质量和使用的缺陷清除方法。这些方法有同行评审、正式审查以及静态分析。尽管有关测试前缺陷清除的文献相对测试相关的文献而言很稀少，但是这些方法是重要的而且有很高的价值。有效的测试前方法例如审查和静态分析缩短了测试时间，同时提高了测试效率。这一章讨论了25种不同的测试前缺陷清除方法。

第5章介绍测试，这是软件项目的传统质量控制技术。尽管存在大量测试相关的文献，但是在缺陷检测效率（DDE）和缺陷清除效率（DRE）等方面的量化数据仍然少得惊人。如果测试在没有有效的缺陷预防方法也没有测试前缺陷清除的条件下执行的话，那么大部分形式的测试通常在发现bug方面的效率都要低于35%，同时测试成本也会很高。缺陷预防、测试前清除和正式且计划良好的测试，这些方法的协同组合可以大幅度地提高测试清除效率。有效的质量控制的目标是，累积缺陷清除效率接近99%。第5章讨论了40种测试阶段。

第6章论及了发布后缺陷清除，对软件应用程序而言这是一个令人遗憾的现实。在美国，累积缺陷清除效率只有大约85%，所以所有的软件应用程序在交付时都带有潜在缺陷。因此，客户总是会发现bug，并且软件组织总会需要有可用的客户支持和维护人员来修复bug。然而，将缺陷预防、测试前清除和测试组合在一起的工艺，其缺陷清除效率平均最高可以达到96%，有些甚至能达到99%。

第7章整合了作者所有的数据，并给出了低质量、平均质量和高质量软件项目的结果。这一章还讨论了用于取得高质量的两种方法，以及获得高质量的量化结果。

使用来自全世界75个组织的295个应用程序的结构质量数据，我们定义并量化了技术债务的概念。技术债务是指修复工作中的软件问题的成本，如果不修复这些问题，将会造成严重的业务中断。我们将技术债务与框架并列用于量化由低劣质量引起的商业价值损失。这项商业价值框架与技术债务一道，为未来的软件经济学研究提供了一个平台。

致谢

这本书有两位作者，我们两个人都要感谢那些帮助本书创作的人。

一如既往，感谢我的妻子Eileen，感谢她在这25年中在我写作16本书时给予我的支持。

在本书写作过程中，两位朋友与同事去世了。特别的感谢应该送给Al Albrecht和Watts Humphrey。

Allan J.Albrecht是功能点度量创始人之一，没有功能点度量就不可能有这本书。我和Al的第一次见面是在1978年，当时他在加利福尼亚州蒙特利市举办的联合“IBM/分享/指导”会议上作了一段关于功能点的演讲。虽然我们两个都曾就职于IBM，但Al在纽约州白原市，而我则在加州圣何塞市，所以我们直到此次会议之前都没有见过面。

Al的演讲和功能点度量创造了软件可行性的经济分析，并且提供了深刻的见解，即不能复制“代码行”和“单位缺陷成本”等老的度量指标。

Al Albrecht、IBM和会议管理部门友善地准许了我在第二本书Programming Productivity:Issues for the Eighties（IEEE出版社，1979）中发布Al的论文。从此以后，我所有的技术书籍都将功能点用作有关软件质量、生产率和经济主题的量化信息。

在Al从IBM退休后，我们两个一起在推广功能点度量的应用方面工作了大约5年。Al创建了第一个功能点认证考试，并且教过我的很多同事功能点度量。

Al是一名受过训练的电气工程师，预想功能点度量能为各种软件应用程序的质量和生产率研究提供坚实的基础。在今天，功能点是应用最广泛的软件度量指标，同时几乎也是唯一一种具有大量基准信息的度量指标。

大约在Al Albrecht去世两周前，软件行业失去了Watts Humphrey。Watts也是我在IBM的一位同事。Watts是一个发明家、多产优秀著作的作家，也是一位优秀的公众演讲家，经常在软件学术会议上发表主题演讲。

从IBM退休之后，Watts开始了在软件工程研究所（SEI）的第二次职业生涯，在SEI他倡导开发了原始版本的能力成熟度模型（CMM）。

Watts是最早认识到质量是有效软件开发方法驱动力的软件研究者之一。除非把质量提高得更快更深远，否则提高生产率将是毫无意义的，因为如若不然，更高的生产率只会制造更多的缺陷。在IBM和SEI，Watts都支持很多质量活动，例如从软件项目开始直到贯穿其整个生命周期的正式审查、正式测试以及完整的缺陷度量。

Watts还发明了个人软件过程（PSP）和团队软件过程（TSP），这两种过程都位于将高质量与高绩效结合起来的最有效方法之列。

Watts在软件过程改进方面的工作得到普遍的认可，并于2005年获得了来自乔治·布什总统颁发的国家技术勋章。

近年来，Watts参加了一系列的讲座和研讨会，于是我们能够在一年内见面好多次，通常都是在举办软件会议的城市。

在本书中，质量的重要性是通往软件开发成功的关键路径这一观点是Watts长期倡导的理念。而且，如果没有Al Albrecht开发的功能点度量，那么度量质量、生产率和其他经济因素的能力也是不可能存在的。

很多其他人员也对本书有所贡献，但是Al和Watts的创始工作是本书能够创作成功的关键因素。

——Capers Jones

首先，我想感谢Capers Jones，与他一起写作本书是一种乐趣。

我要感谢我在CAST的两位同事Lev Lesokhin和Bill Curtis。Lev和Bill是最早建议写作这本书的人，并且自始至终都是杰出的倡导者。在本书理念、组织和内容方面到处充满着他们的烙印，他们应该视为是本书的合著者。

我还借鉴了我在CAST的其他同事的工作成果。首先，Jitendra Subramanyam做了大量的工作，帮助我详细推敲这本书的内容。另外，第2章中区别应用程序级和组件级的软件结构质量的工作是我与Bill Curtis和Vincent Delaroche共同完成的。软件质量的这一属性（即整体大于部分之和）对于软件质量的分析和度量是至关重要的。在这一章中软件结构质量度量标准的定义基于我与Bill和Vincent的工作。在第7章中用于计算由于差的结构质量造成的商业损失的框架也是基于Bill的工作。Jay Sappidi做了开创性的工作，收集并分析了我们的第一批结构质量数据，以及给技术债务下了定义。在第6章和第7章中的大量结构质量分析都基于Jay的工作。

在CAST的产品工程团队（Razak Ellafi、Philippe-Emmanuel Douziech，以及他们的工程师同事）继续创造出一个出色的产品，该产品极好地满足了世界各地数以百计组织的需求。CAST应用程序智能平台不仅是一项精品工程，也是本书中所有结构质量数据的发生器。

——Olivier Bonsignour