Capers Jones Namcook Analytics公司副总裁兼CTO、美国软件生产力研究所（SPR）的创办人及首席科学家，曾是Capers Jones & Associates公司的总裁兼CEO。他是IEEE会员和IFPUG（国际功能点用户组）会员，专注于软件质量评估、软件质量度量、软件成本和进度评估以及风险分析等，是软件工程领域最有影响力的思想领袖之一，著有《软件工程最佳实践》、《软件评估、基准测试与最佳实践》和《Applied Software Measurement, Third Edition》等书。
Olivier Bonsignour CAST软件公司产品开发副总裁，负责研发与产品管理。在加入CAST之前，Bonsignour是法国国防部武器装备总署（DGA）CIO。他是分布式系统开发和面向对象开发领域的先驱，1996年成为最早采用CAST技术的人之一，并且随后加入了CAST。他拥有法国国立应用科学学院工程与计算机科学硕士学位。在工作之余，他喜欢游泳、骑自行车、滑雪，以及沿法国海岸航行。
首部系统研究软件质量经济学的权威著作，软件工程领域最重要的图书之一，由软件工程领域的泰斗撰写
全面给出了度量软件质量的各种指标，并基于大量行业数据和真实案例，从经济学角度讲解了有效管理软 件质量和项目进度的方法，以及软件质量的经济学影响和商业价值
“不论是在做咨询、做项目还是教学，只要我需要可靠的、详细的、相关的度量方法以及对软件工程职业当前的能力和表现的洞察力时，我都会首先去读Capers Jones的著作。在这本重要的新书中，他和Olivier Bonsignour将基于实际经验的经济学案例与事实、数据结合起来，说明了为何软件质量如此重要。我知道我将会一次又一次地向本书寻求帮助。”
——Rex Black，RBCS（www.rbcs-us.com）总裁
一直以来，大型的开发项目都受到较差软件质量的困扰，但是很少有软件主管和参与者知道如何度量质量、选择质量最佳实践或通过成本来证明这些实践的价值。在本书中，世界顶级软件质量专家Capers Jones和Olivier Bonsignour展示了如何系统地度量质量的经济学影响，以及如何利用这些信息来实现更大的商业价值。
利用来自上百个软件组织的经验数据，Jones和Bonsignour展示了综合审查、结构化的质量度量、静态分析和测试如何使清除率超过95%。他们在以下方面提供了创新性的指导：预测缺陷和质量；选择缺陷预防、测试前缺陷清除和测试的方法；优化发布后的缺陷报告和修复。
学完本书，你将能够：
超越功能性的质量，量化非功能性的质量和结构化的质量
证明改进的软件质量可以极大提高ROI并大幅降低TCO
在质量保证和测试中获取当前投资的更好结果
使用质量改进技术来保证进度和维持预算
避免导致不良决策的“有害”度量指标
廖彬山 先后就读于南京大学数学系和北京航空航天大学计算机科学与技术系。现为美国CMMI主任评估师（SCAMPI Lead Appraiser）、北京国信普道科技有限公司首席咨询师、北京航空航天大学软件学院客座教授。主要从事CMMI的培训、咨询和评估及软件工程理论与方法的研究工作，擅长的方向有软件项目管理、软件估算、功能点分析方法、软件度量、软件测试、同行评审、风险管理、PSP和TSP等。
张永明 毕业于北京航空航天大学计算机科学与技术系，多年在国内外大型IT企业从事软件开发、项目管理、质量保证以及运维管理等工作。目前主要从事CMMI和GJB5000A方面的培训、咨询及相关理论与方法的研究工作，结合丰富的咨询实践经验，已经为几十家不同领域、不同规模企业的实际研发和项目管理提供了高效、有价值的改进。
崔曼 毕业于吉林大学软件学院，曾从事过软件开发、软件测试、质量保证及CMMI咨询等工作。担任CMMI咨询师期间，为多家不同类型、不同规模、不同应用领域的企事业单位提供了基于CMMI的咨询和评估服务，有效解决了企业实际存在的问题，积累了丰富的实践经验。
本书的目标读者是软件经理、执行主管，以及参与规划、估算、执行和维护软件的质量保证人员。当规划和开发新的应用程序以及改进或维护现存的应用程序时，经理和利益相关者需要理解软件质量经济学。
本书的目标是量化那些影响软件质量的因素，并给读者提供足够的信息，以便他们预测和度量他们的项目及应用程序的质量水平。
为了服务这个目标，我们加强扩展软件质量数据——这些数据是关于软件结构质量、软件保证过程和技术，以及提高软件质量的边际成本和收益的相关数据。本书提供了有关高质量和低质量如何影响软件项目进度、人员配备、开发成本和维护成本的定量数据。这种信息使软件经理能够对质量目标设定和跟踪过程，并在产品上市速度与商业风险之间做出正确的取舍。
我们使用来自私人和公共部门的大型组织的软件质量数据，来量化软件质量的正面经济价值，同时也量化差的软件质量的高成本。这不是一本关于“如何做”的书，有很多关于如何做的好书，它们描述了关于测试、审查、静态分析以及其他质量主题的过程和技术。我们希望增加大量来自现实世界的应用程序的质量数据，来作为那些介绍如何做的书的补充，从而使IT经理们能够量化这些技术的相对功效和经济价值。
在小型项目中，个人技能和经验在成功的结果中扮演着重要的角色。质量是重要的，但是个人技能往往是高质量的绝对驱动因素。
但是，当项目逐渐变大，开发团队从20人增加到超过1000人的时候，个人技能往往就回归到平均水平了。质量变得越来越重要，因为从历史上看，对于大型软件应用程序，发现和修复bug的成本已经是已知的最大费用。这一点不单对新开发，对改进及维护都是如此。
大部分有关软件质量的讨论几乎无一例外地都聚焦在功能质量上。在本书中，我们超越功能质量来扩展我们的处理范围，以覆盖非功能和结构质量。度量结构质量需要超越单个组件的质量，而将应用程序的质量作为一个整体来看待。我们将展示如何清晰地定义和可重复地度量非功能与结构质量。
全部三种质量——结构质量、非功能质量和功能质量——的可靠度量对于软件质量经济学的一个完整处理而言都是必不可少的。我们使用这些质量度量指标，来比较软件开发生命周期每个阶段中大量的质量改进技术，同时使用来自现实世界应用程序中的数据来量化它们的功效。
大型系统为了达到高质量水平，一个协同的方法集是必要的。这些方法集包括缺陷预防方法，可以降低缺陷等级；审查和静态分析等测试前缺陷清除方法；以及40多种测试方法。
相比传统的“瀑布”开发而言，不少较新种类的开发方法对软件质量也有有益的影响。其中包括敏捷开发、水晶开发、极限编程（XP）、个人软件过程（PSP）、Rational统一过程（RUP）、团队软件过程（TSP）以及其他一些方法。
软件行业普遍较差的度量实践，使得人们模糊了对软件质量经济学的理解。许多高管甚至有些质量人员，往往将软件质量视为一项花费。他们也往往把质量看作这样的一个主题，即认为质量延缓了进度并增加了开发成本。
然而，通过对1973年至今的大约13 000个软件项目的分析，我们很高兴地看到，高质量水平总是与快于平均的开发进度和低于平均的开发成本相联系的。
之所以如此的原因是，大部分上线延迟并超出预算的项目在测试开始之前都没有显示出明显的问题征兆。当测试开始时，高严重程度缺陷的泛滥往往会延长测试时间，并且引发大规模加班。一般而言，低质量大型项目的测试时长是高质量项目的两到三倍，而测试成本要比高质量项目高出一倍多。如果缺陷直到测试开始都还没有被发现和清除，那么就太迟了而不能使软件项目再次可控。如果在测试之前就预防缺陷或者清除缺陷，这样做的成本效益会更好。
另一个隐藏了软件质量经济价值的糟糕度量实践是使用每个缺陷的成本这一度量指标。“在产品交付之后修复一个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
“在我看过的所有有关软件质量经济学的文献中，本书的讲解是最好的。本书中加入了有价值的行业数据、深入的分析、改善质量的经验方法以及质量的经济学分析，对于那些对该主题感兴趣的读者来说，本书是必读之物。本书包含了大量最新的真实案例和故事，这些案例和故事将软件质量和日常生活联系起来，读者定会有一段愉快的阅读旅程。”
——Stephen H. Kan，IBM公司系统与技术组高级技术人员、项目经理、软件质量工程师，Metrics and Models in Software Quality Engineering一书的作者
“终于，一本阐述软件质量成本和软件质量经济学以及它们与商业价值的关系的书出炉了。单独的测试无法产生高质量软件、工程化的质量的价值、正的ROI（投资回报率）等事实都在本书中进行了引人入胜的说明。另外，本书也是理解、管理、清除软件系统中‘技术债务’的必读之物。”
——Dan Galorath，Galorath公司CEO、SEER by Galorath的创始人
“祝贺Capers和Olivier，祝贺他们发表了关于当今软件行业中的缺陷成本的确切、广泛、及时的研究。两位作者没有止步于给出缺陷的起因，而是继续研究了缺陷的引入点、清除和预防方法，这些都可以避免与有缺陷的软件产品相关的‘技术抵押’。在当今‘快速投放市场’的世界中，本书对加强软件工程中的‘工程’的强调令人为之一振。如果你是一名软件开发者、管理者、学生或者用户，这本书将会挑战你对软件质量的看法。非常感谢他们！”
——Joe Schofield，美国桑迪亚国家实验室，IFPUG副总裁，
CQA、CFPS、CSMS、LSS BB及SEI认证讲师
“不论是在做咨询、做项目还是教学，只要我需要可靠的、详细的、确切的度量方法和对软件工程职业当前的能力和表现的洞察力时，我都会首先去读Capers Jones的著作。在这本重要的新书中，他和Olivier Bonsignour将基于实际经验的经济学案例与事实、数据结合起来，说明了为何软件质量如此重要。我知道我将会一次又一次地向本书寻求帮助。”
——Rex Black，Rex Black咨询服务公司（www.rbcs-us.com）总裁，Managing the Testing Process, Third Edition等7本关于软件质量和测试的书的作者
“这部巨著可以让那些投资软件或依赖软件业务和产品的人们进行明智的投资。严格地将金融、经济学、管理、质量和生产力的原理应用到对大量投资于软件的价值命题和神话的全面彻底的检查上，这是一项开创性的工作。如果你要使你的钱在软件投资中物有所值，那么本书不可不读。”
——Leon A. Kappelman，北得克萨斯州大学商学院信息系统学教授
“Capers Jones是当今软件行业中软件度量方面最重要的先驱。本书是一项对跨应用程序领域高质量软件挑战的广泛、具有丰富数据的研究。对于那些希望能更好地了解他们所面对的挑战以及潜在解决方案的成本和有效性的软件质量专业人员来说，这是一本必要的读物。作者在书中倾注了很多的研究与思考。”
——Maysa-Maria Peterson Lach，雷神导弹系统公司资深高级软件工程师
“没有哪个行业像软件行业一样抵制精确严密的度量，软件从业者已经如此强烈地抵制了50多年。Capers Jones在30多年前就接受了将清醒的头脑与可预见性引入软件生产中来的挑战，现在，他与Olivier Bonsignour一起发表了将标准工程和经济学原理应用到软件开发中的‘荒凉西部’的重要观点。”
——Douglas Brindley，软件生产力研究所总裁兼CEO
计算机\软件工程
“不论是在做咨询、做项目还是教学，只要我需要可靠的、详细的、相关的度量方法以及对软件工程职业当前的能力和表现的洞察力时，我都会首先去读Capers Jones的著作。在这本重要的新书中，他和Olivier Bonsignour将基于实际经验的经济学案例与事实、数据结合起来，说明了为何软件质量如此重要。我知道我将会一次又一次地向本书寻求帮助。”
——Rex Black，RBCS（www.rbcs-us.com）总裁
较差的质量持续困扰着大范围的开发项目，但是很少有软件主管和参与者知道如何度量质量、选择质量最佳实践或通过成本来证明这些实践的价值。世界顶级软件质量专家Capers Jones和Olivier Bonsignour在本书中展示了如何系统地度量质量的经济学影响，以及如何利用这些信息来产生更大的商业价值。
通过使用来自上百个软件组织的经验数据，Jones和Bonsignour展示了综合审查、结构化的质量度量、静态分析和测试如何使清除率超过95%。他们在以下方面提供了创新性的指导：预测缺陷和质量；选择缺陷预防、测试前缺陷清除和测试的方法；优化发布后的缺陷报告和修复。
学完本书，你将能够：
•超越功能性的质量，量化非功能性和结构化的质量
•证明软件质量的改善可以极大地提高ROI，并大幅降低TCO
•在质量保证和测试中获取当前投资的更好结果
•使用质量改善技术来维持进度和预算
•避免导致不良决策的“有害”度量指标
廖彬山 先后就读于南京大学数学系和北京航空航天大学计算机科学与技术系。现为美国CMMI主任评估师（SCAMPI Lead Appraiser）、北京国信普道科技有限公司首席咨询师、北京航空航天大学软件学院客座教授。主要从事CMMI的培训、咨询和评估及软件工程理论与方法的研究工作，擅长的方向有软件项目管理、软件估算、功能点分析方法、软件度量、软件测试、同行评审、风险管理、PSP和TSP等。
张永明 毕业于北京航空航天大学计算机科学与技术系，多年在国内外大型IT企业从事软件开发、项目管理、质量保证以及运维管理等工作。目前主要从事CMMI和GJB5000A方面的培训、咨询及相关理论与方法的研究工作，结合丰富的咨询实践经验，已经为几十家不同领域、不同规模企业的实际研发和项目管理提供了高效、有价值的改进。
崔曼 毕业于吉林大学软件学院，曾从事过软件开发、软件测试、质量保证及CMMI咨询等工作。担任CMMI咨询师期间，为多家不同类型、不同规模、不同应用领域的企事业单位提供了基于CMMI的咨询和评估服务，有效解决了企业实际存在的问题，积累了丰富的实践经验。
（美）Capers Jones（法）Olivier Bonsignour 著：Capers Jones Namcook Analytics公司副总裁兼CTO、美国软件生产力研究所（SPR）的创办人及首席科学家，曾是Capers Jones & Associates公司的总裁兼CEO。他是IEEE会员和IFPUG（国际功能点用户组）会员，专注于软件评估、软件测量、软件质量和软件项目管理，是软件工程领域最有影响的思想领袖之一，著有《软件评估、基准测试与最佳实践》、《Software Systems Failure and Success》和《Applied Software Measurement, Third Edition》等书。 Olivier Bonsignour CAST软件公司产品开发副总裁，负责研发与产品管理。在加入CAST之前，Bonsignour是法国国防部武器装备总署（DGA）CIO。他是分布式系统开发和面向对象开发领域的先驱，1996年成为最早采用CAST技术的人之一，并且随后加入了CAST。他也是分布式系统和面向对象开发的早期的开拓者，拥有法国国立应用科学学院工程与计算机科学硕士学位。在工作之余，他喜欢游泳、骑自行车、滑雪，以及沿法国海岸航行。
廖彬山 张永明 崔曼 译：暂无简介
本书是软件工程领域的泰斗Capers Jones多年心血的结晶。书中详细论述了软件质量和改进软件质量的各种经验方法，提供了有价值的行业数据，并进行了软件质量的经济学分析。
书中提供了有关高质量和低质量如何影响软件项目进度、人员配备、开发成本和维护成本的定量数据，有助于项目设定质量目标并进行跟踪，有助于项目在尽快交付与商业风险之间做出权衡。
本书编排循序渐进，内容包括定义软件质量和经济价值、估算和度量软件质量、软件缺陷预防、测试前缺陷清除、软件测试、发布后缺陷清除、软件质量的经济学分析。
本书所涉及的内容，对于工作于软件质量管理以及软件项目管理领域的人员而言都会有很大的帮助，是软件工程和软件过程改进人员不可多得的参考书，同时也可作为软件工程相关专业的教材。
本书的翻译工作主要由张永明、崔曼负责完成，廖彬山做了部分翻译并对全书做了审校。由于译者水平有限，书中错漏在所难免，恳请广大读者指正。希望各位读者朋友能够通过阅读本书给自己的工作带来帮助，并不吝提出建议，这也是我们最大的愿望！
最后预祝大家在阅读本书之时，有一个愉快的经历！
北京国信普道科技有限公司?廖彬山??
联系邮箱：bsliao@gxpudao.com
对本书的赞誉
译者序
序
前言
第1章 定义软件质量和经济价值 1
1.1 引言 1
1.2 定义软件质量 6
1.3 定义经济价值和定义软件质量的价值 13
1.3.1 软件和质量对构建自用内部软件的企业的经济价值 14
1.3.2 软件和质量对内部软件用户的经济价值 16
1.3.3 软件和质量对商业软件厂商的经济价值 17
1.3.4 软件和质量对COTS用户和客户的经济价值 18
1.3.5 软件和质量对嵌入式软件公司的经济价值 20
1.3.6 软件和质量对嵌入式软件设备用户的经济价值 21
1.3.7 软件和软件质量对其他企业部门的经济价值 23
1.3.8 同时担当多种角色 23
1.4 总结和结论 23
第2章 估算和度量软件质量 25
2.1 引言 25
2.2 使用功能点度量方法来量化潜在缺陷 27
2.3 软件潜在缺陷 28
2.3.1 软件需求的专门案例 32
2.3.2 软件需求的起源 35
2.3.3 软件需求的规模、结构和完整性 37
2.3.4 最小化软件需求缺陷 39
2.3.5 软件需求缺陷结论 45
2.3.6 编码缺陷的专门案例 46
2.2 估计软件缺陷预防 51
2.3 估计软件缺陷检测和缺陷清除 53
2.4 度量应用程序结构质量 55
2.4.1 度量可靠性 56
2.4.2 度量性能效率 57
2.4.3 度量安全性 57
2.4.4 度量可维护性 58
2.4.5 度量规模 59
2.4.6 应用程序结构质量度量属性总结 59
2.5 结构质量评估案例 62
2.5.1 绕过架构 63
2.5.2 无法控制处理的数据量 64
2.5.3 应用程序资源失衡 65
2.5.4 安全弱点 66
2.5.5 缺乏防御机制 67
2.5.6 对评估结构质量的系统的要求 67
2.6 歪曲软件经济学分析的三大问题 68
2.6.1 软件历史数据的泄漏 69
2.6.2 LOC度量方法的经济学问题 74
2.6.3 单位缺陷成本度量方法的经济学问题 78
2.6.4 案例A：质量低劣 79
2.6.5 案例B：质量良好 79
2.6.6 案例C：零缺陷 80
2.6.7 预测软件潜在缺陷的有用经验法则 81
2.7 总结和结论 82
第3章 软件缺陷预防 84
3.1 引言 84
3.1.1 20世纪70年代IBM进行缺陷预防研究的早期历史 84
3.1.2 缺陷预防方法的协同组合 89
3.1.3 潜在缺陷和缺陷起源 90
3.1.4 缺陷预防、模式、认证的可重用材料 94
3.1.5 软件缺陷预防和应用程序规模 95
3.2 缺陷预防结果的分析 96
3.2.1 敏捷嵌入式用户 97
3.2.2 自动化的质量预测 97
3.2.3 软件质量数据的基准 98
3.2.4 能力成熟度模型集成（CMMI） 99
3.2.5 认证方案 100
3.2.6 单位缺陷成本度量 101
3.2.7 质量成本 104
3.2.8 圈复杂度度量（及相关的复杂度度量） 106
3.2.9 缺陷度量和缺陷跟踪 111
3.2.10 正式审查 113
3.2.11 功能点质量度量 116
3.2.12 ISO 质量标准、IEEE质量标准及其他行业标准 121
3.2.13 质量功能展开（QFD） 124
3.2.14 风险分析 126
3.2.15 六西格玛 132
3.2.16 静态分析 133
3.3 总结和结论 135
第4章 测试前缺陷清除 136
4.1 引言 136
4.2 小型项目的测试前缺陷清除 139
4.3 大型系统的测试前缺陷清除 143
4.4 测试前缺陷清除活动的分析 148
4.4.1 个人桌面检查 148
4.4.2 非正式的同行评审 149
4.4.3 文档的自动化文本检查 150
4.4.4 正确性证明 156
4.4.5 Scrum 会议 158
4.4.6 Poka Yoke 159
4.4.7 Kaizen 161
4.4.8 结对编程 164
4.4.9 规格说明书的客户评审 166
4.4.10 独立验证和确认 168
4.4.11 SQA评审 169
4.4.12 阶段评审 174
4.4.13 审查（需求、架构、设计、代码及其他可交付成果） 176
4.4.14 用户文档的编辑和校对 187
4.4.15 源代码的自动静态分析 189
4.5 总结和结论 195
第5章 软件测试 196
5.1 引言 196
5.1.1 黑盒与白盒测试 205
5.1.2 功能和非功能测试 206
5.1.3 自动化和手动测试 206
5.1.4 软件测试通用形式的讨论 207
5.1.5 子例程测试 207
5.1.6 PSP/TSP 单元测试 208
5.1.7 XP单元测试 208
5.1.8 单元测试 209
5.1.9 新功能测试 210
5.1.10 回归测试 210
5.1.11 集成测试 211
5.1.12 系统测试 212
5.1.13 专门的软件测试 213
5.1.14 压力或容量测试 214
5.1.15 性能测试 214
5.1.16 病毒防护测试 215
5.1.17 渗透测试 217
5.1.18 安全性测试 218
5.1.19 平台测试 219
5.1.20 供应链测试 219
5.1.21 净室测试 220
5.1.22 诉讼测试 220
5.1.23 云测试 221
5.1.24 SOA测试 221
5.1.25 独立测试 222
5.1.26 本土化测试 222
5.1.27 案例研究测试 223
5.1.28 涉及用户或客户的测试形式 224
5.1.29 敏捷测试 224
5.1.30 可用性测试 224
5.1.31 现场Beta测试 225
5.1.32 实验室测试 226
5.1.33 客户验收测试 226
5.1.34 测试计划编制 227
5.1.35 测试用例设计方法 227
5.1.36 测试用例中的错误和bug 229
5.1.37 软件项目的测试阶段数 229
5.1.38 按行业和软件类型分类的不同测试模式 230
5.1.39 按应用程序规模分类的不同测试模式 233
5.1.40 在指控质量低劣的诉讼案中记录的测试阶段 234
5.1.41 使用功能点估算测试用例数 235
5.1.42 使用功能点估算测试人员的数量 238
5.1.43 使用功能点估算测试工作量和成本 240
5.1.44 由开发人员或由专业测试人员执行的测试 244
5.2 总结和结论 245
第6章 发布后缺陷清除 247
6.1 引言 247
6.1.1 发布后缺陷严重程度等级 248
6.1.2 从结构质量的观点看严重程度等级 250
6.1.3 软件的可维护性 255
6.1.4 按软件应用程序用户分类的缺陷发现率 257
6.1.5 无效缺陷报告 258
6.1.6 发生在独特情况下的暂时搁置的缺陷 260
6.1.7 很多客户报告的重复缺陷 260
6.1.8 第一年缺陷发现率 261
6.1.9 度量DDE和DRE 262
6.1.10 发布后缺陷报告的变化 263
6.1.11 报告软件缺陷的方法的变化 266
6.1.12 缺陷在报告后由谁修复 269
6.1.13 案例1：开发人员负责缺陷修复 269
6.1.14 案例2：维护专家负责缺陷修复 270
6.1.15 案例研究对比 270
6.1.16 由低劣质量引起的诉讼 271
6.1.17 发布后的缺陷修复成本模式 272
6.1.18 参与缺陷修复的软件职业团队 273
6.1.19 检查发布后缺陷修复的自变量 277
6.1.20 按功能点计算的应用程序规模 278
6.1.21 软件应用程序中容易出错模块 284
6.2 来自发布后缺陷的用户和行业的成本 286
6.2.1 安全漏洞对企业和政府机构的影响 289
6.2.2 用于缺陷报告和修复安装的客户后勤 290
6.2.3 案例1：一个小公司的小型应用程序 292
6.2.4 案例2：大公司的大型应用程序 293
6.2.5 在维护和发布后缺陷修复中的度量问题 296
6.3 总结和结论 300
第7章 软件质量的经济学分析 301
7.1 引言 301
7.2 软件的经济价值 302
7.2.1 度量价值的方法 302
7.2.2 资金投入批准和应用程序规模 308
7.2.3 软件构建难度对软件质量的影响 309
7.2.4 来自于软件的收入产生 313
7.2.5 软件行业和其他行业之间的差异 315
7.2.6 软件带来的成本降低 316
7.3 低质量和高质量软件的经济影响 320
7.3.1 软件开发和维护 321
7.3.2 软件作为市场上销售的商品 321
7.3.3 软件作为减少人力的一种方法 322
7.3.4 软件和创新性的新型产品 322
7.3.5 技术债务：度量软件质量对软件成本影响的方法 324
7.3.6 量化商业价值的框架 327
7.3.7 超越功能质量 330
7.3.8 软件结构对质量的影响 330
7.3.9 员工培训对质量的影响 331
7.3.10 职业资格认证对质量的影响 332
7.3.11 技术投资对质量的影响 332
7.3.12 项目管理对质量的影响 333
7.3.13 质量控制方法论和工具对质量的影响 334
7.3.14 高质量和低质量对软件进度的影响 336
7.3.15 高质量和低质量对软件人员配置的影响 337
7.3.16 高质量和低质量对软件开发工作量的影响 338
7.3.17 高质量和低质量对开发生产率的影响 339
7.3.18 高质量和低质量对软件开发成本的影响 339
7.3.19 高质量和低质量对每个功能点的开发成本的影响 340
7.3.20 高质量和低质量对项目取消率的影响 341
7.3.21 高质量和低质量对取消项目的时间安排的影响 341
7.3.22 高质量和低质量对取消的项目工作量的影响 343
7.3.23 高质量和低质量对相对平均项目的工作量的影响 343
7.3.24 高质量和低质量对软件测试阶段的影响 344
7.3.25 高质量和低质量对测试占开发百分比的影响 346
7.3.26 高质量和低质量对每个功能点的测试用例的影响 347
7.3.27 高质量和低质量对创建的测试用例数的影响 347
7.3.28 高质量和低质量对测试覆盖的影响 348
7.3.29 专业测试人员对高质量和低质量的影响 349
7.3.30 高质量和低质量对软件潜在缺陷的影响 350
7.3.31 高质量和低质量对总体软件缺陷的影响 352
7.3.32 高质量和低质量对DDE的影响 352
7.3.33 高质量和低质量对DRE的影响 353
7.3.34 高质量和低质量对总缺陷清除的影响 354
7.3.35 高质量和低质量对已交付给客户的缺陷的影响 355
7.3.36 高质量和低质量对每功能点交付的缺陷的影响 355
7.3.37 高质量和低质量对交付的缺陷严重程度等级的影响 355
7.3.38 高质量和低质量对每功能点严重缺陷数的影响 357
7.3.39 高质量和低质量对软件可靠性的影响 357
7.3.40 高质量和低质量对维护和支持的影响 358
7.3.41 高质量和低质量对维护和支持成本的影响 359
7.3.42 高质量和低质量对维护缺陷容量的影响 360
7.3.43 高质量和低质量对软件改进的影响 361
7.3.44 高质量和低质量对改进成本的影响 362
7.3.45 高质量和低质量对维护和改进人员配置的影响 363
7.3.46 高质量和低质量对5年的总工作量的影响 363
7.3.47 高质量和低质量对TCO的影响 366
7.3.48 高质量和低质量对COQ的影响 369
7.3.49 高质量和低质量对每个功能点的TCO和COQ的影响 372
7.3.50 高质量和低质量对应用程序使用寿命的影响 376
7.3.51 高质量和低质量对软件应用程序有形资产价值的影响 377
7.3.52 高质量和低质量对ROI的影响 378
7.3.53 高质量和低质量对于被取消项目的影响 378
7.3.54 高质量和低质量对取消成本差异的影响 379
7.3.55 高质量、平均质量和低质量的软件项目的分布 380
7.4 总结和结论 381
7.4.1 对于10 000 个功能点的高质量结果 381
7.4.2 10 000个功能点的低质量软件结果 382
参考文献和延伸阅读 384
