书籍详情
完美软件：缺陷预防最佳实践
作者：（美）麦克唐纳，（美）马森，（美）史密斯 著，李滋堤 译
出版社：清华大学出版社
出版时间：2010-06-01
ISBN：9787302224228
定价：¥49.00
购买这本书可以去
内容简介
《完美软件：缺陷预防最佳实践》是一本非常实用的缺陷预防技术实践指南，它提供的一整套技术可以用来帮助软件开发人员、项目管理人员和测试人员避免软件中的人为错误或缺陷。《完美软件：缺陷预防最佳实践》的主旨不是在发现问题之后如何修正问题，而是通过预防和即时检测来减少错误的引入。《完美软件：缺陷预防最佳实践》主要内容包括：缺陷预防入门、缺陷检测技术、缺陷分析技术、缺陷预防技术以及如何建立缺陷预防文化。《完美软件：缺陷预防最佳实践》的目标读者是从事软件行业的开发人员、项目管理人员、测试人员和质量保证人员。
作者简介
麦克唐纳（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都是软件开发行业的专家，他们都拥有数十年的相关经验。
目录
第Ⅰ部分 缺陷预防简介
第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
第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
猜您喜欢
