32 过程与项目度量

说明

本文档由 AI 生成

这一章（Chapter 32: Process and Project Metrics）是上一章（Ch.30 产品度量）的自然延伸，但它将视角从“产品本身”拉回到了“过程和项目管理”。这一章的核心在于：好的管理者需要通过度量来评估项目状态、控制风险和提升过程效率。

这一章的逻辑非常清晰：首先阐述了为什么要进行度量（目的）；接着详细讲解了过程度量（Process Metrics）和项目度量（Project Metrics）的具体指标；然后对比了面向规模（Size-oriented）和面向功能（Function-oriented）的度量方法；最后，章节还特别探讨了WebApp、面向对象以及小型组织的特殊度量需求，并强调了建立度量计划的步骤。

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

---

📊 软件工程 Chapter 32: 过程与项目度量 (Process and Project Metrics)

1. 度量的目的 (Why Do We Measure?)

度量不仅仅是为了收集数据，更是为了管理：

• 评估项目状态 (Assess status)： 了解正在进行的项目的健康状况。
• 跟踪潜在风险 (Track risks)： 预测可能出现的问题。
• 发现隐患 (Uncover problems)： 在问题变得“严重 (Critical)”之前发现它们。
• 调整工作流 (Adjust workflow)： 根据数据调整任务分配。
• 评估团队能力 (Evaluate team ability)： 评估团队控制软件工作产品（Work products）质量的能力。

2. 过程度量 (Process Measurement)

• 间接性 (Indirect measurement)： 我们通常通过**结果 (Outcomes)** 来间接衡量软件过程的有效性。
• 结果指标 (Outcome measures) 包括：
  • 软件发布前发现的错误数 (Errors uncovered before release)。
  • 最终用户报告的缺陷数 (Defects delivered to/report by end-users)。
  • 交付的工作产品数量 (Work products delivered)。
  • 人力投入 (Human effort expended)。
  • 日历时间投入 (Calendar time expended)。
  • 进度符合度 (Schedule conformance)。
• 任务特征 (Task characteristics)： 也可以通过衡量特定软件工程任务的特征来推导过程度量。

3. 过程度量指南 (Process Metrics Guidelines)

• 人性化解读 (Common sense)： 解读数据时要使用常识和组织敏感性。
• 反馈机制 (Feedback)： 定期向收集数据的个人和团队提供反馈。
• 非考核用途 (Not for appraisal)： **不要**使用度量来评估个人绩效，这会引发抵触情绪。
• 合作设定目标 (Set goals together)： 与从业者合作设定清晰的目标和度量指标。
• 非威胁手段 (Not a threat)： 永远不要用度量来威胁团队。
• 正视问题 (Problem indicator)： 指示问题区域的数据不应被视为“负面”，它们仅仅是过程改进的指示器。
• 避免单一指标 (Don't obsess)： 不要沉迷于单一指标而忽略其他重要指标。

4. 软件过程改进 (Software Process Improvement, SPI)

• 闭环反馈 (Feedback loop)： 度量数据驱动 SPI。
• 流程： 过程模型 (Process model) -> 改进目标 (Improvement goals) -> 过程度量 (Process metrics) -> 过程改进建议 (Improvement recommendations)。

5. 过程度量的具体分类

• 质量相关 (Quality-related)： 关注工作产品和交付成果的质量。
• 生产力相关 (Productivity-related)： 关注产出的工作产品与投入的努力之间的关系。
• 统计SQA数据 (Statistical SQA data)： 错误分类与分析。
• 缺陷排除效率 (Defect Removal Efficiency, DRE)： 衡量错误从一个活动传播到另一个活动的情况。
• 复用数据 (Reuse data)： 组件数量及其可复用程度。

6. 项目度量 (Project Metrics)

• 调度优化 (Minimize schedule)： 通过调整避免延误。
• 质量评估 (Assess quality)： 在进行中评估产品质量，并修改技术方法以提高质量。
• 核心三要素 (Every project should measure)：
  • 输入 (Inputs)： 资源（人员、工具）。
  • 输出 (Outputs)： 交付的成果。
  • 结果 (Results)： 交付成果的有效性。

7. 典型的项目度量指标 (Typical Project Metrics)

• 每个软件工程任务的**投入/时间 (Effort/time)**。
• 每小时评审发现的**错误数 (Errors uncovered)**。
• 计划 vs 实际 (Scheduled vs. actual) 里程碑日期。
• 变更 (Changes) 的数量及其特征。
• 在软件工程任务上的**投入分布 (Distribution of effort)**。

8. 面向规模的度量 (Size-Oriented Metrics)

基于代码行数 (LOC) 的度量，是最常见的度量方式。 * 每千行代码 (KLOC) 的错误数/缺陷数。 * 每行代码的成本 ($ per LOC)。 * 每千行代码的文档页数。 * 每人月 (person-month) 的错误数/LOC数。

9. 面向功能的度量 (Function-Oriented Metrics)

基于功能点 (Function Points, FP) 的度量。 * 每功能点的错误数/缺陷数/成本。 * 每功能点的文档页数。 * 每人月的功能点数。

10. LOC vs FP 对比 (Comparing LOC and FP)

• FP 的优势 (Why opt for FP?)：
  • 语言无关 (Programming language independent)。
  • 早期可测 (Countable early)：在软件过程早期即可确定。
  • 鼓励创新 (No penalty for innovation)：不会因为发明了更短小精悍的代码（比笨拙的代码行数少）而受到“惩罚”。
  • 易于衡量复用 (Easier to measure reuse)：使衡量可复用组件的影响变得更容易。

11. 面向对象的度量 (Object-Oriention Metrics)

• 场景脚本数 (Number of scenario scripts)：即用例 (Use-cases)。
• 支持类数 (Number of support classes)：实现系统所需但与问题域无直接关系的类。
• 每关键类的支持类平均数。
• 子系统数 (Number of subsystems)：聚合类以支持最终用户可见的功能。

12. WebApp 项目度量 (WebApp Project Metrics)

• 静态网页数 (Static Web pages)：内容由开发人员固定。
• 动态网页数 (Dynamic Web pages)：内容由用户操作定制。
• 内部页面链接数 (Internal page links)。
• 持久数据对象数 (Persistent data objects)。
• 外部系统接口数 (External systems interfaced)。
• 静态/动态内容对象数。
• 可执行函数数 (Executable functions)。

13. 质量度量 (Measuring Quality)

• 正确性 (Correctness)：程序按照规范运行的程度。
• 可维护性 (Maintainability)：程序易于修改的程度。
• 完整性 (Integrity)：程序抵御外部攻击的能力。
• 可用性 (Usability)：程序易于使用的程度。

14. 缺陷排除效率 (Defect Removal Efficiency, DRE)

• 公式 (Formula)：\(DRE = E / (E + D)\)
  • \(E\)：交付前发现的错误数 (Errors found before delivery)。
  • \(D\)：交付后发现的缺陷数 (Defects found after delivery)。
• 意义 (Significance)：DRE 越接近 1.0，说明过程质量越高，交付给客户的产品越稳定。

15. 小型组织的度量 (Metrics for Small Organizations)

针对变更请求 (Change request) 的流程度量：

• 等待时间 (\(t_{queue}\))：从请求到评估完成的时间。
• 评估工作量 (\(W_{eval}\))：进行评估所需的人力。
• 分配时间 (\(t_{eval}\))：从评估完成到分配变更单的时间。
• 变更工作量/时间 (\(W_{change}, t_{change}\))：实施变更所需的工作量和时间。
• 变更错误/缺陷 (\(E_{change}, D_{change}\))：变更过程中及变更后发现的错误和缺陷。

16. 建立度量计划 (Establishing a Metrics Program)

• 步骤 (Steps)：
  1. 确立业务目标 (Identify business goals)。
  2. 确立想知道的内容 (Identify what you want to know)。
  3. 确立子目标 (Identify subgoals)。
  4. 确立相关实体和属性 (Identify entities & attributes)。
  5. 确立度量目标 (Formalize measurement goals)。
  6. 确立可量化的问题和指标 (Identify quantifiable questions & indicators)。
  7. 确立数据元素 (Identify data elements)。
  8. 定义度量方法 (Define measures)。
  9. 确立实施行动 (Identify actions)。
  10. 制定实施计划 (Prepare a plan)。

---

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

1. 核心目的 (Purpose)：记住度量是为了**改进 (Improvement)** 而不是为了**惩罚 (Punishment)**。考试中可能会出现关于“如何正确使用度量”的情景题。
2. DRE (Defect Removal Efficiency)：这是一个非常重要的公式，务必记住 \(DRE = E/(E+D)\) 以及 E 和 D 的定义。
3. LOC vs FP：必须掌握两者的区别，特别是 FP 的优势（语言无关、鼓励简洁代码）。
4. 过程度量 vs 项目度量：
   • 过程 (Process)：关注长期的、组织级别的流程改进 (SPI)。
   • 项目 (Project)：关注当前项目的调度、风险和质量控制。
5. WebApp 度量：注意区分**静态 (Static)** 和**动态 (Dynamic)** 页面/内容的度量，这是 Web 开发特有的考点。
6. 实施步骤 (Establishing a Program)：虽然细节较多，但记住这是一个从“目标”到“数据元素”的自顶向下分解过程。

评论区

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