跳转至

20 评审技术

说明

本文档由 AI 生成

这一章（Chapter 20: Review Techniques）非常关键，它详细讲解了**评审技术 (Review Techniques)**。在软件工程中，评审是发现缺陷、保证质量最经济有效的方式。

这一章的逻辑非常清晰：首先定义了什么是评审，然后通过**缺陷放大与去除模型 (Defect Amplification Model)** 论证了“为什么越早评审越省钱”，接着介绍了评审的度量指标 (Metrics) 和不同形式（从非正式评审到正式技术评审 FTR），最后还提到了一种基于抽样的评审策略 (SDR)。

以下是为你整理的详细笔记（Markdown格式），专有名词后均已附上英文对照，非常适合用来复习备考。

🧐 软件工程 Chapter 20: 评审技术 (Review Techniques)

1. 评审概述 (Overview)

  • 什么是评审 (What are Reviews)：
    • 由技术人员为技术人员召开的会议。
    • 对软件工程过程中产生的**工作产品 (Work product)** 进行技术评估。
    • 一种软件质量保证机制。
  • 错误 (Error) 与缺陷 (Defect) 的区别：
    • 错误 (Error)： 在软件发布给最终用户**之前**发现的质量问题。
    • 缺陷 (Defect)： 在软件发布给最终用户**之后**才发现的质量问题。
    • 注意：虽然书中做了这种时间上的区分，但这并不是业界主流的思维方式。

2. 缺陷放大与去除 (Defect Amplification and Removal)

  • 缺陷放大模型 (Defect Amplification Model)：
    • 描述了缺陷如何在开发步骤中被引入、传递和放大。
    • 核心数据 (Key Data)：
      • 设计阶段发现的错误修复成本设为 1.5 单位。
      • 测试前发现成本为 6.5 单位。
      • 测试期间发现成本为 15 单位。
      • 发布后发现成本为 67-100 单位。
    • 结论： 设计活动引入了约 50%-65% 的所有错误。在设计阶段使用正式评审技术，去除缺陷的有效性可达 75%。
  • 案例对比 (Example Comparison)：
    • 无评审 (No Reviews)： 总成本计算高达 2177。
    • 有评审 (With Reviews)： 总成本降至 771。
    • 启示： 早期的投资（评审）虽然增加了前期工作量，但大幅减少了后期的测试和修复成本。

3. 评审度量指标 (Review Metrics)

  • 关键公式与定义：
    • 总评审工作量 (Total review effort, \(E_{review}\))： \(E_p\) (准备) + \(E_a\) (评估) + \(E_r\) (返工)。
    • 总错误数 (Total errors, \(Err_{tot}\))： \(Err_{minor}\) (次要) + \(Err_{major}\) (主要)。
    • 缺陷密度 (Defect density)： \(Err_{tot}\) / WPS (工作产品规模，如页数或模型数)。
  • 成本效益分析 (Cost-Benefit Example)：
    • 需求错误在评审中修复平均需 6 人时。
    • 需求错误在测试中修复平均需 45 人时。
    • 节省： 每个错误节省 39 人时。若发现 22 个错误，则节省约 660 人时。
  • 表现预测 (Performance Prediction)：
    • 若历史平均缺陷密度为 0.6 错误/页，新文档为 32 页。
    • 预计应发现约 19-20 个错误。若只发现 6 个，说明要么文档质量极高，要么评审不够彻底。

4. 评审的形式化程度 (Reference Model)

评审的正式程度 (Formality) 随以下因素增加：

  • 评审员的角色 (Roles) 定义明确。
  • 有充分的计划和准备 (Planning & Preparation)。
  • 会议结构 (Meeting Structure) 清晰。
  • 有后续的纠正和验证 (Correction & Verification)。

5. 非正式评审 (Informal Reviews)

  • 形式：
    • 同事间的简单**案头检查 (Desk check)**。
    • 涉及多人的随意会议。
    • 结对编程 (Pair programming)：鼓励在创建工作产品（设计或代码）时进行持续评审。
  • 优点： 错误能被立即发现，工作产品质量更好。

6. 正式技术评审 (Formal Technical Reviews, FTR)

  • 目标 (Objectives)：
    • 发现功能、逻辑或实现上的错误。
    • 验证软件是否满足需求。
    • 确保软件符合预定义标准。
    • 使项目更易于管理。
  • 评审会议 (Review Meeting)：
    • 参与人数：3-5人。
    • 准备时间：每人不超过 2 小时。
    • 会议时长：小于 2 小时。
  • 角色 (The Players)：
    • 评审负责人 (Review leader)： 负责准备工作，分发材料。
    • 生产者 (Producer)： 开发该工作产品的人员。
    • 评审员 (Reviewer)： 负责审查产品，做笔记。
    • 记录员 (Recorder)： 记录会议中提出的所有重要问题。
    • 标准承载者 (Standards bearer/SQA)： 确保过程符合标准。
  • 流程 (Process)：
    1. 准备阶段 (Preparation)： 生产者 -> 负责人 -> 评审员（发现问题列表）。
    2. 执行阶段 (Perform)： 生产者介绍 -> 评审员提出问题 -> 记录员记录。
    3. 跟踪阶段 (Track)： 总结会议，生成 SQA 报告。
  • 指导原则 (Guidelines)：
    • 评审**产品 (Product)，而不是**生产者 (Producer)（不要人身攻击）。
    • 设定议程并遵守它。
    • 限制辩论（不要试图在会上解决所有问题）。
    • 限制参与者数量，坚持提前准备。
    • 为每个产品制定**检查表 (Checklist)**。

7. 样本驱动评审 (Sample-Driven Reviews, SDRs)

这是一种量化评审资源分配的策略：

  1. 检查每个工作产品 (\(i\)) 的一部分 (\(a_i\))。
  2. 记录发现的故障数 (\(f_i\))。
  3. 估算整个工作产品的故障数 = \(f_i \times (1/a_i)\)。
  4. 按估算的故障数降序排列工作产品。
  5. 将评审资源集中在故障数估算最高的产品上。

💡 复习重点总结 (Key Takeaways for Exam)

  1. 缺陷成本曲线 (Defect Cost Curve)： 必须记住 "越晚发现 Bug，修复成本越高" 的具体数量级（设计阶段 vs 发布后）。这是说服管理层进行评审的最强有力论据。
  2. 术语区分 (Terminology)： 注意书中对 Error (发布前发现) 和 Defect (发布后发现) 的特殊定义，虽然不主流，但考试可能会考。
  3. FTR (Formal Technical Review)： 这是核心考点。
    • 角色 (Roles)： Leader, Producer, Reviewer, Recorder, SQA。
    • 原则 (Principles)： 评审产品不评审人，限制辩论，有准备。
  4. 度量指标 (Metrics)： 理解 Defect density (缺陷密度) 和如何计算 Effort saving (节省的工作量)。
  5. SDR (Sample-Driven Reviews)： 了解这是一种基于统计抽样的评审优先级排序方法。

评论区

欢迎在评论区指出文档错误，为文档提供宝贵意见，或写下你的疑问