软件度量

现代软件度量

现代软件度量框架侧重于交付价值和持续改进。它通常遵循以下原则：

识别软件开发生态系统中的关键实体。
定义与业务目标一致的清晰、可操作的度量目标。
理解组织的过程成熟度，并选择适当的度量指标（Metrics）。

识别用于度量的关键实体

在当代软件工程中，我们主要度量三类实体：

过程（Processes）：用于创建和维护软件的工作流和活动（例如，开发生命周期、CI/CD 流水线、测试过程）。
产品（Products）：软件本身及相关工件（例如，代码、文档、测试套件、已部署应用）。
资源（Resources）：过程所需的输入（例如，开发团队、工具、基础设施、预算）。

每个实体都具备内部属性和外部属性：

内部属性（Internal attributes）：实体本身固有的可度量特性。示例：代码复杂度、测试覆盖率百分比、过程周期时间（Cycle Time）。
外部属性（External attributes）：只能通过观察实体与其环境的交互来度量的特性。示例：负载下的应用响应时间、用户满意度得分（NPS）、用户报告的缺陷率。

过程（Processes）

过程是软件相关活动的序列，旨在实现特定结果。

当前常用的内部过程属性度量有：

周期时间（Cycle Time）：从开始处理某项工作（例如，特性、缺陷修复）到完成所需的时间。
交付周期（Lead Time）：从请求某项工作到交付所需的时间。
部署频率（Deployment Frequency）：新代码部署到生产环境的频率。
变更失败率（Change Fail Rate）：导致生产环境故障的部署百分比。

外部过程属性包括：成本（Cost）、可预测性（Predictability）、有效性（delivering value）、整体质量影响（overall quality impact）以及稳定性/韧性（stability/resilience）。

产品（Products）

产品涵盖交付的软件和生命周期中创建的任何工件（代码、设计文档、测试用例、用户手册）。

内部产品属性：大小（Size）（例如，代码行数 - LOC、Story Points）、代码复杂度（Code Complexity）（例如，圈复杂度 - Cyclomatic Complexity、认知复杂度 - Cognitive Complexity）、测试覆盖率（Test Coverage）、代码变更率（Code Churn）、安全漏洞（Security Vulnerabilities）（静态分析结果 - Static Analysis results）、可维护性指数（Maintainability Index）。

外部产品属性：可靠性（Reliability）（例如，平均故障间隔时间 - MTBF）、性能（Performance）（例如，响应时间 - response time、吞吐量 - throughput）、可用性（Usability）（例如，任务成功率 - task success rate、可用性启发法合规性 - usability heuristics compliance）、安全性（Security）（例如，渗透测试结果 - penetration test results）、效率（Efficiency）、可移植性（Portability）和互操作性（Interoperability）。

资源（Resources）

资源是被过程活动消耗或利用的实体。这包括人员（团队）、工具（IDE、CI/CD 服务器）、基础设施（云服务、硬件）和方法论（Methodologies）。

内部资源属性：团队规模（Team size）、工具许可成本（tool license cost）、服务器 CPU/内存容量（server CPU/memory capacity）、团队技能矩阵（team skill matrix）。

外部资源属性：团队速度（Team Velocity）（在敏捷环境中）、工具有效性（tool effectiveness）、基础设施可靠性（正常运行时间 - uptime）、开发者生产力/满意度（developer productivity/satisfaction）。

定义相关的度量目标

度量只有在提供了有助于理解和改进过程或产品的洞察力时才有价值。清晰定义的目标至关重要。像“提高质量”这样的模糊目标不如像“在下个季度将生产环境缺陷率降低 15%”这样具体的目标有效。

目标-问题-度量（GQM）方法

GQM 方法仍然是定义有意义的度量指标的一个高度相关的框架：

目标（Goal）：定义项目、过程或组织的主要目标（你想实现什么？）。
问题（Question）：从每个目标导出具体问题，其答案将表明实现该目标的进展（你需要知道什么来跟踪进展？）。
度量指标（Metric）：确定回答这些问题所需的数据和计算（哪些具体数据点将提供答案？）。

示例：目标 - 提高我们的缺陷修复过程效率。问题 - 修复一个关键缺陷通常需要多久？度量指标 - 度量关键缺陷的“周期时间”（Cycle Time）（从“进行中”到“已解决”状态）。

使用 GQM 可以确保度量有明确目的，并直接与期望结果相关联。在制定目标和问题时，请考虑受众（开发者、经理、客户）。

Basili & Rombach 构建 GQM 定义的模板至今仍有帮助：

目的（Purpose）：分析（过程/产品）以（刻画/评估/改进）之，为了（理解/管理/等）的目的。示例：分析代码评审过程，评估其有效性，以提高代码质量。
视角（Perspective）：从（成本/缺陷/效率）角度考察，从（开发者/经理/客户）的视角。示例：从 DevOps 团队的视角考察部署频率。
环境（Environment）：描述背景（过程因素、团队经验、工具、约束）。示例：开发团队使用 Agile Scrum 进行为期两周的 Sprint，并严重依赖自动化测试。

度量与过程改进

度量对于以下方面至关重要：

理解当前绩效（过程和产品）。
建立比较基线。
跟踪目标进展并预测未来结果。
识别需要改进的领域。

度量的精细程度通常与过程成熟度相关。原始的 SEI 能力成熟度模型（CMM）描述了不同的级别，其后续模型 CMMI（能力成熟度模型集成）以及其他模型（如 Agile 或 DevOps 成熟度模型）都提供了框架。核心原则保持不变：随着过程变得更明确和受控，度量变得更精细和有影响力。

级别 1 (初始/随意 Initial/Ad hoc)：过程是混乱的。基本度量（例如，发现的缺陷总数）可能可行，但缺乏背景。重点在于建立基本的项目跟踪。

级别 2 (已管理/可重复 Managed/Repeatable)：基本项目管理实践已经就位。输入（需求规模）、资源（工作量）、约束（进度、成本）和输出（系统规模）可以识别和跟踪。过程是可重复的，但可能未在组织范围内标准化。文本描述（替代图片）：一个简单的流程图显示，输入（Inputs）进入一个“可重复过程”（Repeatable Process）框，受到资源（Resources）的约束，并产生输出（Outputs）。

级别 3 (已定义 Defined)：过程在组织范围内标准化并形成文档。中间活动及其输入/输出得到理解。度量可以跟踪过程遵循情况以及特定活动的有效性（例如，代码评审中发现的缺陷密度与测试中发现的缺陷密度）。文本描述（替代图片）：一个过程被分解为顺序的子活动（例如，活动 A -> 活动 B -> 活动 C），每个活动都有明确的输入和输出。

级别 4 (定量管理 Quantitatively Managed)：组织使用统计和定量方法来管理过程和质量。度量指标用于控制过程绩效并预测结果。反馈回路指导调整。文本描述（替代图片）：类似于级别 3，但包含从后续活动（例如，活动 C）返回到前期活动（例如，活动 A 或 B）的反馈回路，表明度量驱动的调整。

级别 5 (优化 Optimizing)：重点在于基于定量反馈和试点创新想法进行持续过程改进。过程本身被主动调整和优化。度量驱动根本性的过程变革。

在任何给定的成熟度级别，组织通常都可以收集适用于该级别及所有先前级别的有意义的度量指标。

将度量与成熟度匹配

过程成熟度决定了什么可以有意义地度量。将 GQM 与对成熟度的理解相结合，有助于选择最有用的度量指标。

在较低成熟度级别，需求可能不稳定，使得基于需求的度量变得困难。重点可能放在基本的项目跟踪（工作量、进度）。
随着成熟度提高（例如，级别 2/3），需求变得更稳定，允许跟踪变更、类型和复杂度。可以度量过程遵循情况。
在较高级别（例如，级别 4/5），跟踪过程绩效变化、缺陷预测和优化有效性的复杂度量变得可行。

GQM 定义了 为什么（即目标），而过程成熟度告知了 是什么 和如何（什么可以可靠地度量以及如何度量）。它们共同为建立有效的软件度量计划提供了实用的背景。