标题：完美软件：缺陷预防最佳实践
图书信息
出版社: 清华大学出版社; 第1版 (2010年6月1日)
外文书名: The Practical Guide to Defect Prevention
丛书名: 微软技术丛书
平装: 397页
正文语种: 简体中文
开本: 16
ISBN: 7302224226, 9787302224228
条形码: 9787302224228
尺寸: 25.8 x 18 x 2 cm
重量: 662 g
作者简介
作者：（美国）麦克唐纳（Marc McDonald） （美国）马森（Robert Musson） （美国）史密斯（Ross Smith） 译者：李滋堤
麦克唐纳（Marc McDonald），拥有30年的PC行业经验，他拥有6项软件专利。作为微软的第一位有薪员工，他设计了MS-DOS的FA丁文件系统。
Robert Musson拥有超过25年的软件工程师和软件经理工作经验。他是卡耐基-梅隆大学软件工程研究所“团队软件过程倡议”的成员。
马森（Ross Smith），从事软件开发与测试已有近20年的时间。他参与了自1995年以来Windows和Microsoft Office的所有版本的开发，拥有5项软件专利。
Ross Smith从事软件开发与测试已有近20年的时间。他参与了自1995年以来Windows和Microsoft Office的所有版本的开发，拥有5项软件专利。
Dan Bean、David Catlett、Lori Ada Kilty和Joshua Williams都是软件开发行业的专家，他们都拥有数十年的相关经验。
内容简介
《完美软件:缺陷预防最佳实践》是一本非常实用的缺陷预防技术实践指南，它提供的一整套技术可以用来帮助软件开发人员、项目管理人员和测试人员避免软件中的人为错误或缺陷。《完美软件:缺陷预防最佳实践》的主旨不是在发现问题之后如何修正问题，而是通过预防和即时检测来减少错误的引入。《完美软件:缺陷预防最佳实践》主要内容包括：缺陷预防入门、缺陷检测技术、缺陷分析技术、缺陷预防技术以及如何建立缺陷预防文化。
《完美软件:缺陷预防最佳实践》的目标读者是从事软件行业的开发人员、项目管理人员、测试人员和质量保证人员。
媒体评论
“非常棒的一本书!作者介绍了许多实用理念，用来帮助工程团队在其早期生产过程中实施缺陷预防，从而向客户提供高价值的产品。” 
——PaKlck Copeland，谷歌测试工程经理 
“全面、深入地探究了缺陷的实质。可以迅速、直接地应用于软件开发科技领域。” 
——理查得·纽曼，微软游戏工程室(日本)，团队高级经理
目录
第Ⅰ部分 缺陷预防简介 
第1章 缺陷预防 3 
1.1 什么是软件缺陷 5 
1.2 以高质量软件为目标 6 
1.3 理解软件缺陷的产生原因 7 
1.4 可以做些什么 9 
1.4.1 使用检测、分析与预防技术 9 
1.4.2 进行缺陷预防的组织有何不同 10 
1.5 使用缺陷预防技术 11 
1.5.1 缺陷检测技术 11 
1.5.2 缺陷分析技术 12 
1.5.3 缺陷预防技术 12 
1.6 选择质量提高技术 12 
1.6.1 考虑的因素 13 
1.6.2 选择一种策略 14 
1.7 组织考虑的因素 14 
1.8 在上游阶段提高质量 15 
1.9 从错误中学习 15 
1.10 为未来投入 15 
1.11 小结 16 
第2章 缺陷预防框架 17 
2.1 研究一种示例框架 19 
2.2 提出模型 20 
2.3 缺陷预防模型 20 
2.3.1 能力成熟度模型 21 
2.3.2 能力成熟度模型集成 26 
2.3.3 Malcolm Baldrige框架 26 
2.3.4 ISO模型 29 
2.3.5 其他模型 30 
2.3.6 对比这些模型 30 
2.4 选择和使用模型 30 
2.5 小结 32 
第3章 缺陷预防的经济学 34 
3.1 预防缺陷对企业有好处 35 
3.1.1 缺陷预防的经济理论与价值 36 
3.1.2 盈利能力 37 
3.2 对软件开发进行边际成本分析 38 
3.2.1 估计成本 39 
3.2.2 确定回报 45 
3.3 小结 47 
第Ⅱ部分 缺陷检测技术 
第4章 质量与开发过程 51 
4.1 什么是软件质量 52 
4.1.1 开发方法与质量 52 
4.1.2 完全可测试性的神话 53 
4.1.3 当前测试方法与质量 54 
4.1.4 不可能测试所有内容 56 
4.2 作为一种转换过程的产品开发 57 
4.2.1 向产品周期内添加验证步骤 58 
4.2.2 承认原始说明书中的缺陷 61 
4.2.3 将设计转换为代码 62 
4.3 小结 72 
第5章 利用生产效率游戏预防缺陷 73 
5.1 什么是游戏理论 75 
5.1.1 历史上的游戏 76 
5.1.2 游戏玩家时代 77 
5.1.3 游戏为什么改变行为 79 
5.2 游戏的类型 79 
5.2.1 机会游戏和技能游戏 80 
5.2.2 微型游戏 80 
5.2.3 预测市场 81 
5.2.4 交替现实游戏 82 
5.3 缺陷预防游戏的实践指导 82 
5.3.1 从排名榜开始 82 
5.3.2 保持简单 82 
5.3.3 仔细考虑记分方式 83 
5.3.4 奖励正确的行为 83 
5.3.5 利用记分方式鼓励参与 84 
5.3.6 使玩家时常查看自己的分数 84 
5.3.7 竞赛内容多样 84 
5.3.8 留出调整空间——设置一个时间段 85 
5.3.9 通过分级来保持兴趣 85 
5.3.10 保留玩家的历史 85 
5.3.11 以小型实验版本作为开始 85 
5.3.12 让人们按自己的步调进行 86 
5.3.13 使用现金和奖品来提高兴趣 86 
5.3.14 使用随机抽奖 86 
5.4 应用缺陷预防游戏的实例 86 
5.5 游戏设计的提示 87 
5.6 游戏设计的清单 88 
5.7 小结 88 
5.8 推荐阅读资料 89 
第6章 提高软件的可测试性 90 
6.1 认识可测试性的好处 91 
6.2 实施可测试性 92 
6.2.1 简单性：开发不复杂的软件 92 
6.2.2 可观察性：使软件可观察 95 
6.2.3 控制：加强对被测试软件的控制 97 
6.2.4 知识：明白期待什么样的结果 98 
6.3 避免实施可测试性的风险 100 
6.4 小结 100 
第Ⅲ部分 缺陷分析技术 
第7章 软件测量与量度 103 
7.1 理解构建一个成功记分卡的关键 104 
7.2 明确确定战略目标 106 
7.2.1 确定客户战略 106 
7.2.2 确定内部业务战略 107 
7.2.3 确定财务战略 108 
7.2.4 定义创新战略 108 
7.3 明确定义业务、过程和改进目标 109 
7.3.1 理解目标类型 109 
7.3.2 确定目标 110 
7.3.3 确定量度 110 
7.3.4 划定量度的优先级 111 
7.3.5 确定量度的权重 111 
7.3.6 避免量度操纵 113 
7.3.7 适当确定目标的范围 114 
7.3.8 划定目标的优先级 114 
7.3.9 创建SMART目标 114 
7.4 将所确定的目标通知各级管理人员 115 
7.4.1 收集并显示数据 115 
7.4.2 自动收集和报告数据 117 
7.4.3 回顾 118 
7.5 使人们广泛接受已确定的目标 118 
7.6 小结 120 
第8章 风险分析 121 
8.1 什么是风险 122 
8.2 什么是风险分析 122 
8.2.1 将风险分析应用于漂流 124 
8.2.2 确定风险分析阶段 125 
8.2.3 风险分析的好处 127 
8.2.4 理解风险 128 
8.2.5 实施风险分析 129 
8.3 创建风险预测模型 129 
8.3.1 特征：确定代码特征 129 
8.3.2 数量：跟踪改动 133 
8.3.3 影响：理解变更的结果 133 
8.3.4 理由：理解为什么进行变更 137 
8.3.5 所有权：知道一个改变归谁拥有 138 
8.4 应用风险预测模型 139 
8.5 小结 142 
第9章 利用仿真和建模进行组织改革 144 
9.1 理解随机建模 145 
9.2 使用建模过程 153 
9.2.1 定义目标 154 
9.2.2 确定起始过程 154 
9.2.3 确定过程的输入和输出 155 
9.2.4 构建所倡导的过程 156 
9.2.5 将过程结果与组织结果进行对比 157 
9.2.6 开发实际过程 157 
9.2.7 根据需要进行重复 157 
9.3 基线过程模型举例 158 
9.3.1 简单规划模型 158 
9.3.2 经过改进的计划模型 161 
9.3.3 详尽的质量模型 165 
9.3.4 过程改进模型 170 
9.3.5 开发生产能力模型 176 
9.4 与CMM框架的关系 180 
9.5 小结 181 
第10章 缺陷分类法 182 
10.1 从大型软件项目中的缺陷进行学习 183 
10.2 指定缺陷分类的目标 185 
10.3 理解缺陷分类的组织原则 185 
10.4 明确缺陷分类法中做出的假设 186 
10.4.1 假设：我们只能进行特定类型的更改 187 
10.4.2 假设：人们是会犯错误的 187 
10.4.3 假设：缺陷在产品周期的后期被发现 187 
10.4.4 假设：在产品周期中生成缺陷的阶段未能检查出这些缺陷 188 
10.4.5 假设：测试可能是不平衡的 188 
10.4.6 假设：您可能过度使用工具和过程 189 
10.4.7 假设：您可能是在进行后期设计纠正 189 
10.5 构建缺陷分类法实例 189 
10.5.1 发生阶段 192 
10.5.2 促成原因阶段 196 
10.5.3 改变阶段 200 
10.5.4 检测阶段 202 
10.5.5 缓解阶段 204 
10.6 经过分类的缺陷举例 205 
10.7 小结 208 
第11章 根本原因分析 209 
11.1 理解根本原因分析研究如何帮助预防缺陷 210 
11.2 何时进行RCA研究 211 
11.3 合理配置人员以成功完成研究 211 
11.4 RCA研究的阶段 212 
11.4.1 阶段一：事件确定 213 
11.4.2 阶段二：数据收集 216 
11.4.3 阶段三：数据分析与评估 218 
11.4.4 阶段四：纠正操作 222 
11.4.5 执行纵向分析 223 
11.4.6 阶段五：通知与应用 224 
11.4.7 阶段六：遵循、测量和建议 225 
11.5 根本原因分析的好处 227 
11.6 根本原因分析的风险 228 
11.7 小结 229 
第Ⅳ部分 缺陷预防技术 
第12章 采用过程 233 
12.1 理解传统的开发过程 235 
12.2 实施敏捷过程 236 
12.2.1 需求管理 237 
12.2.2 项目计划 237 
12.2.3 项目跟踪与监督 238 
12.2.4 软件质量保证 239 
12.2.5 软件配置管理 240 
12.3 Scrum 240 
12.4 个体软件过程 241 
12.5 团队软件过程 244 
12.6 鼓励采用创新性的实践方式 244 
12.7 部署一体化过程 245 
12.8 小结 246 
第13章 FMEA、FTA与故障建模 248 
13.1 故障模式和效果分析 249 
13.2 实施FMEA 250 
13.2.1 预备知识 250 
13.2.2 程序 251 
13.2.3 FMEA小结 262 
13.3 故障树分析 263 
13.4 实施FTA 264 
13.4.1 预备知识 265 
13.4.2 程序 265 
13.4.3 故障树开发过程 269 
13.4.4 故障树小结 275 
13.5 故障建模：结合FMEA和FTA 275 
13.5.1 故障建模 276 
13.5.2 对比威胁建模与故障建模 277 
13.6 小结 277 
第14章 预防标签 279 
14.1 预防标签如何工作 282 
14.2 在整个生产周期中使用预防标签 284 
14.2.1 编写高质量的预防标签 284 
14.2.2 谁可以推动预防技术 284 
14.2.3 寻找“缺陷引入”行为的样式 287 
14.3 实施预防标签计划 287 
14.3.1 确定目标 288 
14.3.2 确定进度跟踪和交流方法 288 
14.3.3 确定存储预防数据的位置 288 
14.3.4 为预防相关工作提供激励机制 288 
14.3.5 确保有足够的分析人员 289 
14.3.6 定期报告并进行更改测量 289 
14.4 对预防标签数据采取行动 289 
14.4.1 对预防技术进行分类 290 
14.4.2 深入分析 292 
14.5 使用预防标签的好处 292 
14.5.1 帮助个人转向全局考虑 293 
14.5.2 预防技术和知识易于共享 293 
14.5.3 预防数据与发现和修复数据存储在一起 293 
14.5.4 提供用于过程改进的反馈机制 293 
14.5.5 简化数据收集 293 
14.5.6 可用于所有阶段 294 
14.6 使用预防标签的风险 294 
14.6.1 变为一个指责平台 294 
14.6.2 面对有偏差的数据 294 
14.6.3 容易过分重视或反应过度 294 
14.6.4 需要编译与分析 295 
14.6.5 预防方法可能过于笼统或者过于具体 295 
14.7 小结 295 
第Ⅴ部分 预防文化 
第15章 方案投票 299 
15.1 应用大数定律 300 
15.2 利用方案投票来帮助预防缺陷 301 
15.3 理解方案投票流程 303 
15.3.1 创建功能说明文件 304 
15.3.2 编写高质量的方案 305 
15.3.3 对方案进行分类 305 
15.3.4 了解投票人员都是哪些人 306 
15.4 实施方案投票计划 307 
15.4.1 了解适当的项目阶段 307 
15.4.2 了解产品 308 
15.4.3 开发体验树 308 
15.4.4 为反馈设定明确目标 309 
15.4.5 为方案建立文档以及制订方案 309 
15.4.6 征集用户制订的方案 311 
15.4.7 理解用户群 312 
15.4.8 获取反馈 313 
15.4.9 启动引导项目 314 
15.4.10 部署投票项目 315 
15.4.11 保持项目的活力 316 
15.4.12 报告结果 316 
15.4.13 分析结果 317 
15.4.14 鼓励投票者持续参与 318 
15.4.15 将结果提交给支持团队 319 
15.4.16 采取行动 321 
15.5 方案投票的好处 323 
15.5.1 简化数据收集 323 
15.5.2 能够收集涉及大范围功能和用户的大量数据 323 
15.5.3 适用于项目周期的所有阶段 324 
15.6 方案投票的风险 325 
15.6.1 投票结果受投票人群构成的影响 325 
15.6.2 投票结果仅提供了用户意见的概要信息 325 
15.6.3 不完整的方案选择可能会使结果产生偏差 326 
15.6.4 设计不佳的方案可能会使结果产生偏差 326 
15.7 小结 327 
15.8 推荐阅读资料 327 
第16章 创建一种质量文化 328 
16.1 评价您的现有文化 329 
16.1.1 常见的文化缺陷 330 
16.1.2 用于检测设计不当的量度 332 
16.2 改进您的文化 333 
16.3 小结 338 
第17章 在上游阶段提高质量 339 
17.1 质量与客户导向是相互联系的 340 
17.2 将开发过程理解为一系列转换 341 
17.3 避免阻碍上游质量的提高 344 
17.3.1 测试不会提高质量 344 
17.3.2 质量是不可见的 344 
17.3.3 重功能，轻质量 345 
17.3.4 工程态度妨碍了注重质量的文化 346 
17.3.5 任务和团队的短视妨碍了全局观 346 
17.3.6 团队回避适当行为 347 
17.3.7 价值和奖励没有促进质量的提高 348 
17.4 缺陷具有不同风险 349 
17.5 查明下游质量不佳的原因 350 
17.6 未来产品开发的模型 351 
17.6.1 开发工作以客户为导向 352 
17.6.2 产品信息是可执行的 354 
17.6.3 客户方案被移向上游 355 
17.6.4 测试过程和测试生成被自动化 355 
17.6.5 静态测试普遍深入 356 
17.6.6 开发过程被修改 357 
17.6.7 在组织、角色和职业生涯中所导致的变化 358 
17.7 小结 359 
第18章 回报、动机和激励 360 
18.1 应用激励技巧 361 
18.1.1 消除“抑制激励”的因素 362 
18.1.2 为缺陷预防工作设立SMART目标 362 
18.1.3 衡量在缺陷预防工作上花费的时间和精力 363 
18.1.4 确保领导者行为体现了对缺陷预防工作的重视 363 
18.1.5 创造缺陷预防的文化 363 
18.1.6 使组织目标与缺陷预防工作保持一致 364 
18.1.7 在设计组织进程时，要考虑到缺陷预防 364 
18.1.8 建立奖励机制，鼓励员工发表不同观点 365 
18.2 激励——不只是金钱奖励 365 
18.2.1 庆祝成功 366 
18.2.2 使用游戏和竞赛 366 
18.3 理解个人的动机 366 
18.4 明白什么是成功 368 
18.5 衡量成功 368 
18.6 小结 369 
第19章 知识管理与交流 370 
19.1 交流不畅所产生的问题 371 
19.1.1 孤立知识 372 
19.1.2 知识传播不足 372 
19.1.3 不能找出最佳实践 373 
19.1.4 缺乏向上交流 373 
19.2 交流方法 373 
19.3 利用规模优势 374 
19.3.1 优秀交流模型的特性 374 
19.3.2 分类法 375 
19.3.3 有机的专家系统 375 
19.3.4 预防标签 377 
19.3.5 方案投票 378 
19.4 小结 378 
第20章 融为一体 379 
20.1 了解标准与约定 380 
20.1.1 火车、汽车和PF 381 
20.1.2 公共结果标准 382 
20.2 各司其职 383 
20.2.1 质量保证 383 
20.2.2 代码开发 388 
20.2.3 项目管理 394 
20.3 小结 397