1. 课程导论：缺陷预防的重要性、FMEA与设计审查的协同价值、课程目标与学习路径
1.1 为什么缺陷预防是软件质量的“第一性原理”？
在软件工程中，缺陷的发现时间与修复成本呈指数级增长。需求阶段的一个逻辑错误，如果在编码后才发现，修复成本可能是需求阶段的 10 倍；如果在生产环境暴露，成本可能高达 100 倍。因此，缺陷预防 的核心思想是：将质量活动左移，在缺陷注入的源头（需求分析阶段）就将其识别并消除，而不是依赖后期的测试和返工。
核心数据： 根据 IBM System Sciences Institute 的研究，需求阶段修复一个缺陷的成本为 1 个单位，设计阶段为 6 个单位，编码阶段为 15 个单位，测试阶段为 40 个单位，发布后则高达 100 个单位。
缺陷预防不是简单的“多检查几遍”，而是建立一套系统化的工程方法，从认知、流程和技术三个维度阻断缺陷的产生。本课程聚焦于需求阶段，因为这是缺陷注入的“重灾区”，也是预防投入产出比最高的环节。
1.2 FMEA 与设计审查：两种核心预防机制的协同价值
在需求阶段，FMEA（失效模式与影响分析） 和 设计审查 是两种互补性极强的预防工具。它们不是二选一的关系，而是需要深度结合，形成“分析-评审-闭环”的预防链条。
| 维度 | FMEA（失效模式与影响分析） | 设计审查（Design Review） |
|---|---|---|
| 核心目标 | 系统化识别“可能出错的方式”及其影响 | 通过同行评审验证需求的正确性、完整性和一致性 |
| 分析视角 | 自下而上：从功能/组件出发，推导失效链 | 自上而下：从用户/系统视角，检查逻辑合理性 |
| 输出产物 | FMEA 表格（失效模式、原因、影响、RPN 值） | 审查报告（问题列表、修改建议、结论） |
| 预防时机 | 需求分析中期，在需求文档定稿前 | 需求文档完成后，进入设计前 |
| 协同价值 | 为审查提供“风险清单”，让审查更有针对性 | 为 FMEA 提供“逻辑验证”，确保分析不脱离实际 |
两者的结合可以形成以下闭环：
- FMEA 先行： 对需求功能进行失效模式分析，识别高风险区域。
- 审查聚焦： 设计审查团队基于 FMEA 输出的风险清单，重点审查高风险项的逻辑和边界。
- 闭环反馈： 审查中发现的新问题或逻辑漏洞，反向补充到 FMEA 表格中，更新风险优先级。
实践建议： 不要将 FMEA 和设计审查视为两个独立的活动。建议在需求评审会议前，先完成一轮快速的 FMEA 分析，并将 RPN（风险优先级数）较高的项作为评审会议的“必查项”。
1.3 课程目标与学习路径
本课程旨在帮助软件质量工程师、需求分析师和开发人员掌握一套可落地的缺陷预防方法。通过 30 个章节的系统学习，你将能够：
- 掌握 FMEA 方法论： 独立完成需求阶段的 FMEA 分析，识别失效模式、原因和影响，并计算 RPN 值。
- 精通设计审查技巧： 掌握基于检查表、角色扮演和场景驱动的审查技术，提升审查效率。
- 实现协同落地： 将 FMEA 输出与设计审查流程无缝集成，建立预防型质量文化。
- 输出可交付物： 能够产出标准化的 FMEA 表格、审查报告和缺陷预防行动计划。
课程学习路径分为四个阶段，建议按顺序学习：
| 阶段 | 章节范围 | 核心内容 | 预期产出 |
|---|---|---|---|
| 第一阶段：基础认知 | 第 1-5 章 | 缺陷预防理论、FMEA 基础、设计审查基础 | 理解核心概念，能区分预防与检测 |
| 第二阶段：方法实操 | 第 6-15 章 | FMEA 七步法、审查检查表设计、场景分析 | 独立完成 FMEA 表格和审查清单 |
| 第三阶段：协同融合 | 第 16-25 章 | FMEA 与审查的集成流程、工具链、案例演练 | 完成一个完整的需求阶段预防案例 |
| 第四阶段：进阶与度量 | 第 26-30 章 | 缺陷度量、持续改进、组织级推广 | 制定团队缺陷预防改进计划 |
学习提醒： 本课程包含大量实操练习和案例。建议在学习第 6 章后，选择一个你正在参与的项目作为“实战项目”，边学边练，效果最佳。