软件度量验证

验证软件度量

仅仅收集度量指标（metrics）是不够的；我们需要确信我们的度量是有意义的，并且基于这些度量的预测是准确的。验证（Validation）就是确保这种信心的过程。它通常涉及两个方面：

验证度量系统（measurement system，即度量指标本身）。
验证预测系统（prediction systems，即使用度量指标的模型）。

验证度量系统

这一步确保一个度量指标（metric）准确地代表它声称要度量的特定属性（attribute）。它关乎检查该度量指标的行为是否与我们对该属性的理解一致。

正式来说，这涉及证明该度量指标满足度量理论中的“表示条件（representation condition）”——这意味着它保留了在现实世界中观察到的定性关系。例如：

如果我们认为程序 A 比程序 B“更复杂”，一个有效的复杂性度量指标（complexity metric）m 应该得出 m(A) > m(B)。
如果我们组合两个独立的[代码模块] P1 和 P2，一个有效的长度度量指标（length metric）m 可能预期满足 m(P1 + P2) = m(P1) + m(P2)（可加性，additivity）。

验证技术包括：

理论验证（Theoretical Validation）： 证明度量指标符合该属性应有的数学特性（例如长度的可加性示例）。
经验验证（Empirical Validation，收敛验证，Convergent Validation）： 证明度量指标与衡量相同属性的其他公认的（且最好已验证过的）度量指标强烈相关。例如，将一个新的复杂性度量指标与[圈复杂度（Cyclomatic Complexity）]或开发者对复杂性的主观评分进行关联。
专家判断（Expert Judgment）： 评估度量结果是否与经验丰富的从业者的共识理解一致。

示例：验证“代码行数”（Lines of Code, [LOC]）作为“长度”（Length）的度量指标。我们可以从理论上论证它满足基本的顺序关系（程序越长，LOC 越高）。从经验上，我们可能会发现它与字符计数等其他长度度量指标有很好的相关性。然而，它作为衡量“工作量”（Effort）或“复杂性”（Complexity）的有效性要弱得多，需要单独进行更严格的验证，并且通常显示出较差的相关性。

验证预测系统

预测系统使用数学模型（通常包含已验证的度量指标）来估计未来的结果，例如项目工作量（effort）、成本、进度、缺陷数量或系统可靠性。

这里的验证意味着在特定上下文（context）中确定模型预测的准确性（accuracy）。这主要是一个经验性过程：

收集目标环境中过去项目的历史数据（例如，关于项目规模度量指标、实际工作量、实际缺陷的数据）。
将预测模型应用于这些过去项目的输入数据。
将模型的预测结果与已知的实际结果进行比较。
使用统计技术（statistical techniques）（例如，[相对误差的平均幅度（Mean Magnitude of Relative Error, MMRE）]、[预测水平（Prediction Level, PRED(l)）]）来量化预测准确性。

主要考虑因素：

上下文依赖性（Context Dependency）： 预测模型通常对环境（团队技能、流程成熟度、技术栈）高度敏感。在一个上下文中验证过的模型在另一个上下文中可能不准确。
数据质量（Data Quality）： 验证的准确性很大程度上取决于所用历史数据的质量和相关性。
随机性 vs 确定性（Stochastic vs. Deterministic）： 有些预测本质上是不确定的（随机的），例如缺陷到达率。验证评估的是预测结果是否落在可接受的概率范围内，而不是期望完全精确的匹配。
模型校准（Model Calibration）： 通常，验证会促使校准或调整预测模型的参数，以便更好地适应本地上下文。

示例：验证基于 [COCOMO] 的工作量估算模型。我们将收集过去项目的数据（按[千行代码（KLOC）]或[功能点（Function Points）]计算的规模、实际工作量）。我们将使用规模输入运行模型，并将其工作量预测与这些项目记录的实际工作量进行比较。如果平均误差在我们的目的下是可以接受的低，我们可能会认为该模型已通过验证，可在我们组织中用于类似的未来项目。

验证不是一次性活动。随着环境的变化，度量指标和预测模型应该定期重新验证，以确保其持续的相关性和准确性。