30 产品度量¶

说明

本文档由 AI 生成

这一章（Chapter 30: Product Metrics）将我们的视角从具体的开发流程、测试和安全，转向了一个更宏观、更数据驱动的领域——软件产品度量 (Software Product Metrics)。这一章的核心思想是：为了改进软件过程和产品质量，我们必须建立一套科学的度量体系。

这一章的逻辑非常严密，遵循了从“道”到“术”的原则：首先阐述了度量的基本原则和流程；接着引入了目标导向的度量范式（Goal/Question/Metric）；然后详细列举了从需求分析、架构设计、面向对象设计、编码、测试到维护各个阶段的具体度量指标；特别值得一提的是，本章还专门探讨了Web和移动应用的特殊度量需求。

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

📊 软件工程 Chapter 30: 产品度量 (Product Metrics)¶

1. 度量的基本概念 (Measures, Metrics and Indicators)¶

测量 (Measure)： 对产品或过程的某个属性（如范围、数量、维度、容量或大小）提供定量指示。
度量 (Metric)： 根据 IEEE 词汇表，度量是“定量衡量系统、组件或过程具备某个属性的程度”。
指标 (Indicator)： 一个或一组度量的组合，用于提供对软件过程、项目或产品本身的洞察。

2. 度量原则 (Measurement Principles)¶

目标先行 (Objectives first)： 在开始收集数据之前，必须先确立度量目标。
明确性 (Unambiguous definition)： 每个技术度量都应被明确定义。
有效性 (Validity)： 度量应基于对该应用领域有效的理论（例如，设计度量应基于基本的设计概念和原则）。
可裁剪性 (Tailoring)： 度量应根据特定的产品和过程进行裁剪，以适应具体情况。

3. 度量流程 (Measurement Process)¶

公式化 (Formulation)： 推导出适合所考虑软件表示形式的软件度量。
收集 (Collection)： 累积计算度量所需数据的机制。
分析 (Analysis)： 计算度量值并应用数学工具。
解释 (Interpretation)： 评估度量结果，以获得对表示形式质量的洞察。
反馈 (Feedback)： 将基于度量结果解释得出的建议传达给软件团队。

4. 目标导向的软件度量 (Goal-Oriented Software Measurement)¶

目标/问题/度量范式 (Goal/Question/Metric Paradigm)：
1. 建立明确的度量**目标 (Goal)**。
2. 定义为实现该目标必须回答的一组**问题 (Questions)**。
3. 识别有助于回答这些问题的、格式良好的**度量 (Metrics)**。
目标定义模板 (Goal definition template)：
- 分析 {要度量的活动或属性名称}
- 目的 {分析的总体目标}
- 关于 {所考虑的活动或属性的方面}
- 从 {对度量感兴趣的人} 的观点出发
- 在 {度量发生的环境} 的上下文中。

5. 度量属性 (Metrics Attributes)¶

简单且可计算 (Simple and computable)： 易于学习和计算，不应耗费过多精力或时间。
有说服力 (Empirically and intuitively persuasive)： 应满足工程师对该产品属性的直觉概念。
一致且客观 (Consistent and objective)： 计算结果应始终明确无歧义。
单位一致 (Consistent in its use of units)： 数学计算不应导致奇怪的单位组合。
语言无关 (Programming language independent)： 度量应基于分析模型、设计模型或程序结构本身，而非特定编程语言。
有效的质量反馈机制 (Effective mechanism for quality feedback)： 应能提供帮助工程师提高最终产品质量的信息。

6. 收集与分析原则 (Collection and Analysis Principles)¶

自动化 (Automation)： 只要可能，数据收集和分析都应自动化。
统计技术 (Statistical techniques)： 应应用有效的统计技术来建立内部产品属性与外部质量特征之间的关系。
解释指南 (Interpretative guidelines)： 应为每个度量建立解释指南和建议。

7. 需求模型的度量 (Metrics for the Requirements Model)¶

基于功能的度量 (Function-based metrics)： 使用功能点 (Function point) 作为标准化因子或规格说明“大小”的度量。
规格说明度量 (Specification metrics)： 通过按类型统计需求数量来指示质量。

8. 功能点 (Function Points)¶

定义： 由 Albrecht 提出，用于有效衡量系统交付的功能性。
计算依据： 基于软件信息域的计数（直接度量）和软件复杂性的评估。
信息域值 (Information Domain Values)：
- 外部输入 (External Inputs, EIs)
- 外部输出 (External Outputs, EOs)
- 外部查询 (External Inquiries, EQs)
- 内部逻辑文件 (Internal Logical Files, ILFs)
- 外部接口文件 (External Interface Files, EIFs)
计算： 每个类别根据复杂性（简单、平均、复杂）加权求和。

9. 架构设计度量 (Architectural Design Metrics)¶

结构复杂度 (Structural complexity)： 与扇出 (Fan-out) 相关。
数据复杂度 (Data complexity)： 与输入/输出变量和扇出相关。
系统复杂度 (System complexity)： 结构复杂度和数据复杂度的函数。
HK 度量 (HK metric)： 基于扇入 (Fan-in) 和扇出 (Fan-out) 的架构复杂度函数。
形态度量 (Morphology metrics)： 模块数量和模块间接口数量的函数。

10. 面向对象设计度量 I (Metrics for OO Design-I)¶

Whitmire 提出的 9 个特征：
- 规模 (Size)： 人口、体积、长度、功能性的视图。
- 复杂度 (Complexity)： 类之间的相互关联方式。
- 耦合 (Coupling)： OO 设计元素之间的物理连接。
- 充分性 (Sufficiency)： 抽象具备所需特性的程度。
- 完整性 (Completeness)： 抽象或设计组件可重用的间接暗示。

11. 面向对象设计度量 II (Metrics for OO Design-II)¶

内聚 (Cohesion)： 所有操作共同协作以实现单一、明确定义目的的程度。
原语性 (Primitiveness)： 操作或类的原子程度。
相似性 (Similarity)： 两个或多个类在结构、功能、行为或目的上的相似程度。
波动性 (Volatility)： 发生变更的可能性。

12. 区分特征 (Distinguishing Characteristics)¶

Berard 论点： 以下特征要求开发特殊的 OO 度量：
- 局部化 (Localization)
- 封装 (Encapsulation)
- 信息隐藏 (Information hiding)
- 继承 (Inheritance)
- 抽象 (Abstraction)

13. 面向类的度量 (Class-Oriented Metrics)¶

Chidamber 和 Kemerer 提出：
- 每个类的加权方法 (Weighted Methods per Class, WMC)
- 继承树深度 (Depth of the Inheritance Tree, DIT)
- 子类数量 (Number of Children, NOC)
- 类间耦合 (Coupling Between Object Classes, CBO)
- 类的响应 (Response for a Class, RFC)
- 方法的内聚缺失 (Lack of Cohesion in Methods, LCOM)
Lorenz 和 Kidd 提出：
- 类规模 (Class size)
- 子类重写的操作数 (Number of operations overridden)
- 子类添加的操作数 (Number of operations added)
- 专门化指数 (Specialization index)
MOOD 度量套件 (MOOD Metrics Suite)：
- 方法继承因子 (Method Inheritance Factor)
- 耦合因子 (Coupling factor)
- 多态因子 (Polymorphism factor)

14. 面向操作的度量 (Operation-Oriented Metrics)¶

Lorenz 和 Kidd 提出：
- 平均操作规模 (Average operation size)
- 操作复杂度 (Operation complexity)
- 每个操作的平均参数数 (Average number of parameters per operation)

15. 组件级设计度量 (Component-Level Design Metrics)¶

内聚度量 (Cohesion metrics)： 数据对象及其定义位置的函数。
耦合度量 (Coupling metrics)： 输入/输出参数、全局变量和被调用模块的函数。
复杂度度量 (Complexity metrics)： 提出了数百种（例如，圈复杂度 Cyclomatic complexity）。

16. 接口设计度量 (Interface Design Metrics)¶

布局适当性 (Layout appropriateness)： 布局实体、地理位置以及在实体间转换的“成本”函数。

17. Web 和移动应用的设计度量 (Design Metrics for Web and Mobile Apps)¶

可用性 (Usability)： 用户界面是否促进可用性？
美学 (Aesthetics)： 应用的美学是否适合应用领域并取悦用户？
内容设计 (Content design)： 是否以最少的努力传达最多的信息？
导航 (Navigation)： 导航是否高效直接？
架构 (Architecture)： 是否适应 App 用户的特殊目标、内容结构和导航流？
组件 (Components)： 是否减少过程复杂度并增强正确性、可靠性和性能？

18. 代码度量 (Code Metrics)¶

Halstead 的软件科学 (Halstead's Software Science)： 基于组件或程序中操作符 (Operators) 和操作数 (Operands) 的数量和出现次数的一整套度量。
- 注意： Halstead 的“定律”存在争议，许多学者认为其理论基础有缺陷，但在特定编程语言中已进行过实验验证。

19. 测试度量 (Metrics for Testing)¶

测试工作量估计 (Testing effort)： 可使用源自 Halstead 度量的指标进行估算。
可测试性设计度量 (Design metrics for testability)： Binder 建议了一系列直接影响 OO 系统“可测试性”的设计度量：
- 方法的内聚缺失 (Lack of cohesion in methods, LCOM)
- 公有和保护成员百分比 (Percent public and protected, PAP)
- 对数据成员的公有访问 (Public access to data members, PAD)
- 根类数量 (Number of root classes, NOR)
- 扇入 (Fan-in, FIN)
- 子类数量 (Number of children, NOC)
- 继承树深度 (Depth of the inheritance tree, DIT)

20. 维护度量 (Maintenance Metrics)¶

软件成熟度指数 (Software Maturity Index, SMI)： 根据每次发布发生的变化指示软件产品的稳定性。
计算公式：
- \(M_T\) = 当前版本的模块总数
- \(F_c\) = 当前版本中已更改的模块数
- \(F_a\) = 当前版本中已添加的模块数
- \(F_d\) = 从上一版本中删除的模块数
- \(SMI = [M_T - (F_a + F_c + F_d)] / M_T\)
解读： 随着 SMI 接近 1.0，产品开始趋于稳定。

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

基本概念辨析 (Measures vs Metrics vs Indicators)： 必须清晰区分这三个层次，从数据到指标的递进关系。
GQM 范式 (Goal/Question/Metric)： 这是一个非常经典的答题框架，记住“目标 -> 问题 -> 度量”的逻辑链条。
功能点分析 (Function Points)： 理解其计算逻辑（基于信息域和复杂度），知道它是衡量功能性而非代码行数的指标。
面向对象度量 (OO Metrics)： 这是重点也是难点。务必记住 CK 套件 (Chidamber and Kemerer) 的核心指标（WMC, DIT, NOC, CBO, RFC, LCOM），以及 MOOD 套件的几个因子。
Halstead 度量： 知道它基于操作符和操作数，虽然理论有争议但实践中仍有应用。
SMI (Software Maturity Index)： 记住其公式和含义，SMI 越接近 1，软件越稳定。

评论区

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