封面 书名页 “在我看过的所有有关软件质量经济学的文献中，本书的讲解是最好 本书是软件工程领域的泰斗Capers 作为一家重要的电信公司，我们的业务包括产品和服务的复杂组合 本书的目标读者是软件经理、执行主管，以及参与规划、估算、执行 定义软件质量和经济价值 质量总是很难定义，而定义软件质量更是异常困难 “质量”因为存在多种观点而是一个模糊的术语，“价值”也是 内部构建企业或政府的运营软件是计算机在商业环境中的首次应用 截至2010年年中，据美国劳工统计局的报道，美国的就业人数约 现在已经有成千上万的商业软件公司和商业软件应用程序，而有意思 截至2011年，约有14659956家美国公司使用计算机和软 2011年嵌入式软件已经存在于相当多的产品中 对使用由嵌入式软件控制的设备的用户来说，软件的经济价值是能够 在讨论软件价值和软件质量的价值背景下，可能会提到很多其他企业 很多大企业会同时扮演多种角色，例如，如AT&T那样的大公司就 50多年来，软件质量的主题一直很难定义 估算和度量软件质量 本书使用功能点度量方法来量化潜在的缺陷 软件bug或缺陷有很多来源和起因 50多年来，软件质量的一个传统定义是“与需求的一致性” 软件行业在创造收入和财富上一直非常成功 任何试过阅读大型应用程序的软件需求的人都知道，这类材料通常晦 信息系统软件需求很大却不完整，难于理解，忽略了质量等必要的主 不管是软件工程文献还是软件质量文献中都没有完整地讨论软件需求 截至2011年，至少存在2500种编程语言 软件缺陷预防会在第3章里详细讨论，本章只提供了一些大概的原则 在20世纪70年代IBM首先开始研究缺陷检测效率（DDE）和 和构建、改进和维护软件的过程质量不同，功能的、非功能的与结构 评估可靠性至少需要检查下列软件工程实践和技术属性。 评估性能效率至少需要检查下列软件工程实践和技术属性： 评估安全性至少需要检查下列软件工程实践和技术属性。 评估可维护性至少需要检查下列软件工程实践和技术属性。 应用程序源代码的规模会影响应用程序的质量，因为随着规模的增长 表2-16总结了评估应用程序各个特性所需要度量的应用程序要素 本节描述了几个应用程序质量问题的案例，来帮助澄清为什么它们不 多层应用程序中问题的一大来源是，一层中某个组件绕过要求的架构 应用程序在无法控制大量数据或其允许的处理量时，行为会失常 现代应用程序平台使用资源池（resource 大多数安全应用程序含有一个专门管理访问权限和相关安全事务的组 这里介绍的许多导致运行中破坏性后果的问题，都来源于对系统间交 在与其他系统、数据库、中间件和API间有着大量交互的环境下， 软件是制造出来的产品，因此软件项目应当使用制造经济学的基本方 作为一系列软件成本估算工具的开发人员，本书的一位作者经常被问 使用LOC度量方法的生产力研究中如果包含了多种编程语言，则其 软件质量经济学研究中最为古老的度量方法是单位缺陷成本 假定软件工程师花费15个小时编写测试用例，10个小时运行它们 在这个案例中，假定软件工程师花费15个小时编写测试用例，10 在这第3个案例中，假定测试者花费15个小时来编写测试用例，并 通过采集数百个功能点总数已知的应用程序的缺陷数据，给出一些预 50多年来，在软件的所有活动中成本最大的就是找到并修复bug 软件缺陷预防 20世纪70年代，IBM软件团队注意到软件应用程序正在变得越 表3-2展示了多种方法各自独立使用的结果 直到现在，关于潜在缺陷的讨论一直围绕着整个应用程序 非正式的软件重用自从软件行业起步以来就很常见 随着应用程序规模的增长，潜在缺陷也显著地增加了 软件行业每年都能发展出几个新的方法论，每个月新出现的编程语言 敏捷开发方法（有很多）试图通过将软件应用程序分成可以在较短的 自动化的软件质量预测是几个商业软件估算工具的标准特性，如Kn 任何引入过程改进尤其是质量改进的尝试，都很有可能被高级管理者 软件工程研究所（SEI）是1984年成立的。在Watts 软件工程不是美国商务部认可的职业（Profession） 前面提到过，单位缺陷成本对质量是不利的，因为对于bug最多的 COQ（质量成本）方法的历史比软件行业还要久 圈复杂度和基本复杂度都于1975年因数学家Tom 缺陷预防和缺陷清除的缺陷度量方案的有效性是相对较高的，然而令 正式审查（inspection）是IBM在20世纪70年代开 因为本书使用了功能点度量方法，所以包含以下的简短的讨论还是比 在本书写作时（2011年），存在很多（美国）国内和国际标准组 截止到2011年，质量功能展开（QFD）是开发出来的最有效的 软件开发是高风险的工作 六西格玛（Six 商业静态分析工具相对比较新，在新世纪到来之前在数目和特性上都 截至2011年，至少有65种对缺陷预防有利的（在某些案例中或 测试前缺陷清除 在本书中，“小型软件项目”被定义为规模小于1000个功能点或 当我们将关注点从小于等于1000个功能点的小型项目转移到大于 这一节将会从效率和执行所需的工作量方面来讨论之前提到的测试前 个人桌面检查是最古老的软件缺陷清除形式 由于我们难以在自己的文本和源代码中发现错误这一众所周知的问题 “自动化文本检查”这个词指的是使用计算机化的工具评估文本文档 这个使用数学证明来确认软件算法的想法很吸引人，尤其是在学术界 "scrum"这个词来自橄榄球运动（指并列争球） Yoke 日本是一个自然资源匮乏的岛国，非常不利于现代工业的发展，但却 结对编程的想法是两个软件工程师或程序员共用一个工作站 本书的一位作者经常作为专家证人出席各个软件项目诉讼案，这些软 独立验证和确认（IV&V）已经作为军用和政府应用程序的标准要 短语“软件质量保证”（SQA）在常见的用法中是模糊不清的 在20世纪60年代和70年代，当软件应用程序开始增大到超过1 正式审查是由IBM在20世纪70年代早期开发出来的，当时大家 文字编辑是第一道防线 自动静态分析已经成为从源代码中清除软件缺陷的领先方法之一 有关测试的软件质量文献数量至少是有关测试前缺陷清除的质量文献 软件测试 软件测试文献通常将测试分为黑盒测试和白盒测试（也称为玻璃盒测 另一种二分测试的方法是将其分为功能测试和非功能测试 在软件行业的早期，应用程序都很小，手动测试很常见 软件测试的通用形式几乎发生在任何种类的软件中：系统软件、商业 子例程测试是我们的客户中注意到的最低级别的测试形式 PSP/TSP单元测试是个人软件过程（PSP）和团队软件过程 XP（eXtreme 单元测试是测试文献中通常讨论的最低级别的测试形式 新功能测试经常与回归测试一起进行，两种测试形式在更新或修改现 回归测试与新功能测试相反 集成测试，顾名思义就是测试若干个模块或程序，这些模块或程序合 针对整个应用程序的系统测试是最后的内部测试，通常在客户介入现 专门的软件测试的发生频率要比普通的测试低，并且更常用于系统软 压力或容量测试是一种专门的测试，旨在判断当接近所使用信息容量 性能测试是一种专门的测试，旨在判断应用程序是否能达到为它所设 病毒防护测试，这种白盒测试正在迅速从专门测试向通用测试转变， 渗透测试是一种源于机密军用软件应用程序的专门测试 一般安全性测试在军用软件中最普遍、最复杂，其次是处理非常机密 平台测试是很多公司都在使用的一种专门测试，这些使用平台测试的 供应链测试是在我们的客户中最近兴起的一种专门测试 净室统计测试只有在使用净室开发方法的背景下才会出现 诉讼测试常常发生在指控被告一方软件质量差的诉讼案中 云测试是最新的测试形式之一，在写作本书时刚刚有超过5年的历史 SOA（面向服务的架构）测试是另一种新的测试，只有少数几年的 独立测试在军用软件中很普遍，因为美国国防部的标准需要独立测试 本土化测试发生在旨在使软件在许多国家运行并要以许多国家的语言 案例研究测试是一种专门的测试，通常用于新型软件，而这类软件正 对于很多软件项目，客户或用户在全程各个阶段上都是积极的参与者 敏捷测试是一种较新的测试 可用性测试是一种专门的测试，有时会在可用性实验室中执行 现场（Beta）测试是一种用于商业软件的普通测试技术 实验室测试主要是在混合产品上进行，这些混合产品由复杂的经软件 客户验收测试一般出现于由外包供应商开发的合同软件中 对于将由从开发人员分离出的专业测试人员来执行测试的应用程序而 对于所有规模超过50个功能点的软件应用程序而言，测试用例设计 IBM在针对其部分商业应用程序的测试库的一项研究中发现了两个 换一个观点来观察数据，如果将每一种特定的测试视为一个“测试阶 当然，按照已使用的典型测试模式来看，不同行业与各类软件的测试 另一种观察测试阶段分布的有趣方法是观察与软件应用程序的各种规 一项有趣的观察发现，对于那些因最终被认定质量不可接受或不合格 功能点和相关的特征点度量正开始提供一些初步但有趣的有关测试用 在测试上下文中最新但却最有趣的功能点度量的一个用途是，用功能 功能点度量在测试中的另一项使用是对测试工作量（和成本）的估算 一个有关软件测试的重要问题是：由谁来执行测试 测试是软件缺陷清除的最古老的形式之一，并拥有超过50年的信息 发布后缺陷清除 软件缺陷在危害方面的差异非常大 缺陷等级起到了软件质量度量方法的作用 软件可维护性的话题被广泛讨论，但人们仍然对其缺乏了解 当软件投入生产并且使用时间开始累积时，客户将会发现大部分的潜 无效缺陷报告是指那些被认为是真正的软件缺陷，但经过调查被证明 第6个主题也提出了一个针对维护和支持人员的困难挑战 第7个主题“重复缺陷报告”，是有很多用户的商业软件的一个主要 IBM保留应用程序的缺陷数据已经有25年了 用于度量缺陷检测效率（DDE）和缺陷清除效率（DRE）的一般 由客户报告的发布后的bug是令人吃惊地模棱两可，如果考虑到超 有关客户支持或计划的主题方面的软件文献在论述当软件应用程序被 就发布后缺陷修复而言，软件行业被分成了两大阵营 假设一个软件工程师负责开发一个Java语言的改进应用程序，该 在案例2中，原始的应用程序和改进项目具有相同的规模 这两个案例研究都作了很多简单的假设，但它们也都揭示了一个关键 很多质量差的内部项目被发布，但是这些项目并不出现在法庭上 发布后的缺陷修复是一个非常复杂的主题，因为有很多因素需要考虑 与发布后缺陷相关的主要职业团队包括但不限于以下人员。 对发布后缺陷修复有影响的重要自变量如下： 因为软件缺陷起源于需求、架构、设计和用户文档以及源代码，所以 在20世纪70年代软件应用程序和系统软件的规模激增之时，IB 许多网站和博客都有讨论著名和昂贵软件缺陷的列表和引用 表6-20仅仅给出了影响软件运行的缺陷，在软件中还有安全漏洞 在写作本章时，本书的一位作者碰巧不得不报告与Verizon网 案例1假设一个规模为1000个功能点的商业应用程序，该应用程 对于案例2，假设一个商业应用程序有10000个功能点，被10 有一些特殊的问题使得以缺陷修复和度量改进来度量软件维护比度量 在发布后找到并修复bug已经是一个普通的活动，自从软件行业开 软件质量的经济学分析 在讨论软件质量经济价值之前，考虑软件本身的经济价值是有帮助的 在花费任何一笔巨额资金来创建一项重要的新软件应用程序之前，利 在一个企业中实际上批准软件项目资金投入的水平，将因项目的规模 作为所有历史上最重大的技术进步，软件对商业、政府、军事行动、 软件收入的产生主要来自于12个渠道，下面将详细讨论。 在几个领域中软件的收入渠道明显不同于其他类型的产品和服务的收 一个有趣的历史事实是，在软件之前，研制机械式计算设备和早期的 正如在本章前面所讨论的，软件是现代社会最有价值的商品之一 低质量 低质量 低质量 低质量 技术债务被定义为修复应用程序中结构质量问题的成本，如果未解决 这里的框架是为了量化Bill 提高应用程序的质量有两个构成要素：外部的功能质量和内部的结构 许多结构性的主题存在着对软件质量的影响 表7-4显示一个可能会让读者感到吃惊的主题 表7-5探讨了有争议的话题：职业认证 表7-6也探讨了一个有些争议的模糊话题 表7-7探讨了一个区别高质量与低质量的更重要因素——项目管理 表7-8组合了所有的重要质量因素来区分高质量与平均质量、低质 最早、最惊人的有关质量的量化数据类型之一是，发现高质量应用程 同样令人惊讶的是，比起团队相同规模和类型的低质量应用程序，高 高质量等级缩短进度和减少工作人员的需求，因此显而易见的是，软 为表示生产率趋势，用功能点度量来规范数据是有用的 因为软件成本来自于进度、用工、工作量和生产率的结合，图7-7 对度量指标（如功能点）做标准化是有用的，它能在按规模和质量等 高质量软件项目和低质量软件项目之间的一个主要区别是它们的取消 即使非常高质量的软件项目也可能因为商业原因被取消 因为被取消的低质量软件项目一般都是延迟的和超出预算的，所以当 当被取消的项目数据被以平均项目的成本百分比来表示时，可以看到 一些关于在低质量和高质量项目背景下的测试的信息是违反直觉的 图7-14显示，不出所料，大型系统比起小程序需要更多的测试 当比较高质量和低质量软件时另一个意料之外的现象是：高质量软件 图7-16扩展了在图7-15中的数据，并说明了测试用例的典型 “测试覆盖”这个词语是非常模糊不清的 软件测试可以由软件开发者、培训过的软件测试人员或两者来执行 读者可以回顾前面的几章，其中术语“潜在缺陷”指的是在需求、设 图7-20扩展了图7-19中的数据，显示了缺陷的总量，那些数 图7-21涉及一个更重要的质量因素——缺陷检测效率 缺陷清除效率（DRE）可能是唯一最重要的质量度量 图7-23扩展了图7-22中的数据，显示了在软件交付给客户之 图7-24说明了软件质量的一个中心问题：当软件被交付给客户或 图7-25将图7-24的数据转换成标准形式，显示了每个功能点 由图7-26我们可以得出软件行业历史中最重要的质量因素之一： 当交付的高严重程度缺陷被规范化为“每功能点缺陷数”时，有必要 度量过软件可靠性的人都知道，这是一个复杂且模糊的话题 在本书中，术语“维护”、“支持”和“改进”是不同的 图7-30扩展了从图7-29中得来的工作量数值，通过使用一个 软件最初发布后，事情并没有完 因为本书从维护或缺陷修复中分离出了改进或新特性，因此解释一下 图7-33扩展了图7-32中的信息，使用一个每人月10000 在许多公司和政府组织中，维护（缺陷修复）和改进（新特性）由同 此时，图的结构发生了变化 图7-36（a～e）展示了原始开发加上5年的维护和改进的总拥 图7-37（a～j）从前面的图表中截取信息并尝试展示质量成本 图7-38（a～j）扩展了图7-37中图形的结果，表达了以每 图7-39试图展示软件行业的麻烦区域：一项软件应用程序在部署 图7-40研究了一个有许多变量的高度复杂的问题：当第一次考虑 图7-41比较了来自图7-40中的可能价值数据和图7-37中 图7-42显示了与被取消各种规模项目相关的可能财务损失 图7-43比较了低质量、平均质量和高质量项目的取消项目成本。 图7-44显示了大约13000个软件项目的近似分布，这些项目 由于考虑两个极端的有用性，研究可能的高质量软件应用程序和低质 使用本章图中的数据，加上一些有关使用模式的其他假设，高质量版 对用户、客户和成本的数量采用相同的假设，研究低质量软件的结果 第1章 239.软件质量经济学 240.软件质量经济学 241.软件质量经济学 242.软件质量经济学 243.软件质量经济学 244.软件质量经济学 245.软件质量经济学 ..更多