软件度量复习指南：核心概念、公式与计算题实战

简介：这份关于中南大学软件学院软件度量课程的复习重点整理，主要面向软件工程专业学生及备考者，系统梳理测量的基本概念、软件测量三阶段（用头脑度量、用单词度量、用数字度量）、六种测量尺度（标定、类型、序列、间隔、比例、绝对）及其典型示例，并详解直接测量与间接测量、软件度量分类与有效度量步骤等核心考点，适合期末复习、考研备考及工程复盘使用。资料为单个docx文档，共1.66MB，内容按章节组织，包含各尺度的典型示例、样本过程/产品/资源度量表等，便于对照记忆。已有467人学习下载。文档还涵盖了Halstead软件规模度量等进阶内容，能帮助读者快速搭建软件度量知识框架，提升复习效率。 期末复习周走到软件度量这一科的时候，我猜不少人和我当年一样：公式抄了满满一页，看到题目还是不知道从哪下手。这门课的特点是概念密集、公式多、计算题占分不低，而且很多知识点之间是有底层逻辑的，不是孤立背诵就能搞定。我这次把中南大学软件学院软件度量课程的复习重点完整梳理了一遍，按“基本概念→规模度量→复杂度度量→质量度量与过程度量→考前复盘”的顺序来写，尽量把教材里容易漏掉的关联讲清楚。如果你正在备考这门课，这篇可以直接当最后一遍复习提纲用；如果刚学完想整体回顾，也能靠它快速搭起知识框架。

1. 先分清“测量-度量-指标”，否则概念题会很惨

1.1 三者定义和常考判断

软件度量课程的第一章通常都在讲基本术语，但恰恰是这些基础概念，最容易被考到。测量（Measurement）是采集数据的过程，比如记录某段程序的执行时间、统计代码行数、收集缺陷数量；度量（Measure）是通过测量得到的量化结果，比如平均响应时间是 2.5 秒；指标（Indicator）则是把测量或度量结果映射到管理者关心的决策问题上，比如“当前缺陷密度偏高，意味着发布前需要增加测试轮次”。

这三个词的关系可以这样记：测量是手段，度量是结果，指标是语义。考试里常见的判断题就是给你一句话，让你判断说的是 measurement、measure 还是 indicator。比如“用圈复杂度评估模块可测试性”，这里圈复杂度本身是度量结果，但“评估可测试性”这个动作让它的角色变成了指标。这种辨析题不难，但需要你在复习时主动多问自己一句：这句话描述的到底是采集、量化，还是解释？

1.2 直接度量、间接度量与三大对象

另一个高频考点是度量的分类。直接度量是可以直接从软件产品或过程中获取的属性，比如代码行数、缺陷数、投入工作量、进度天数；间接度量则需要通过其他属性推导出来，比如缺陷密度等于缺陷数除以规模，生产率等于产出除以工作量。

从度量对象角度，软件度量还能分成产品度量、过程度量和资源度量三类。产品度量关注代码和文档的质量，如规模、复杂度、缺陷数；过程度量关注开发和维护过程的效率，如进度偏差、返工量、缺陷关闭速度；资源度量关注人、工具、设备等投入，如项目团队规模、预算使用率。做选择题时很容易混，记法也很简单：能拿到手上看的代码和文档是产品，开发和维护的流程是过程，投入的人力物力和预算是资源。

1.3 GQM 模型为什么是软件度量的灵魂

GQM 是 Goal-Question-Metric 的缩写，这套方法在考试里出现的频率非常高，简答和综合题都可能涉及。GQM 的思路是：先定义目标（Goal），再围绕目标提出可测量的问题（Question），最后为每个问题确定具体度量项（Metric）。它把抽象目标逐步拆成可执行的数据采集方案，说白了就是“面向目标的度量设计”。

举个例子：目标是提升软件交付质量。第一个问题可以是“测试阶段缺陷发现是否充分”，对应的度量项是缺陷发现率，即测试阶段缺陷数占总缺陷数的比例；第二个问题可以是“线上缺陷密度是否在可接受范围”，对应度量项是每千行代码缺陷数。考试如果让你设计度量方案，一定要按 GQM 三层结构作答，把目标和度量用问题桥接起来，而不是直接写指标，否则容易丢分。

1.4 测量尺度：哪类数据能算平均数

测量尺度这个概念容易被忽视，但它经常以判断或选择题形式出现。标称尺度只能做相等性判断，比如开发语言类型；序数尺度能排序但不能加减，比如缺陷优先级高、中、低；间隔尺度差值有意义，但没有绝对零点，比如某些标准分数；比率尺度有绝对零点，加减乘除都有意义，比如代码行数、缺陷数、工作量。

考试时常见问法是：某个度量能不能计算平均数和方差？答案是，比率尺度和间隔尺度通常可以，序数尺度做了排序但无法保证距离相等，直接算平均数是错误的。比如模块优先级“高中低”不能像 3+2 那样平均；但 LOC 可以求平均，因为一定行数之差在任何区间意义一致。

2. 规模度量：LOC 简单但坑不少，功能点需要会数数

2.1 用 LOC 估规模：简单直观，但不同语言没法直接比

规模度量是整个课程度量体系的基础，很多后续指标都要除以规模。LOC（Lines of Code）是最直观的规模度量，以一行物理代码为计数单位，常用 KLOC（千行代码）表示。优点是好统计、历史数据多、直觉性极强；缺点也很明显，不同的编程语言同一功能代码行数差别很大，而且 LOC 容易被钻空子——代码写得冗长，行数上去了，规模看似大，实际工作量并不一定高。

计算题里 LOC 通常是作为中间参数出现，比如先算出功能点，再乘以“每个功能点对应的代码行数”得到 LOC，然后进入 COCOMO 的工作量估算。这里要注意单位换算，如果你算出的是行数，而公式要求 KLOC，千万别忘记除以 1000。

2.2 功能点五类部件：考试计数最容易漏的是 EIF

功能点分析（FPA）是规模度量里的重点，计算题特别喜欢考。它的核心思路是识别五类功能并计数，再乘权重得到功能点。五类功能分别是：

• 外部输入 EI：用户输入的、能够改变系统内部状态的数据，比如提交订单；
• 外部输出 EO：系统向用户输出的、包含加工计算或派生数据的成果，比如统计报表；
• 外部查询 EQ：查询类事务，输入是条件、输出是结果，不包含计算或更新数据；
• 内部逻辑文件 ILF：系统内部维护的数据文件或数据表；
• 外部接口文件 EIF：系统要引用的、由其他系统维护的外部数据。

考试里常见的丢分点是把 EIF 漏掉。很多同学数完 EI、EO、ILF 就觉得完事了，但题目中一旦出现“从第三方接口读取数据”或“与外部系统交换文件”这类描述，就对应着 EIF，必须单独计数。建议做题时在草稿纸上固定列一个五类清单，逐个核对，不要靠感觉。

2.3 功能点调整系数 VAF：0.65 和 0.01 这两个数要记牢

功能点计算不是五类加权求和就结束了，还要考虑 14 个通用系统特征（GSC），每个特征按影响程度评 0 到 5 分，把所有特征值求和得到总影响度 FI，然后计算调整系数 VAF = 0.65 + 0.01 × FI。最终调整后的功能点数 FP = 未调整功能点(UAFP) × VAF。

考试时即使题目给出了 GSC 评分，很多人也会忘记 VAF 下限是 0.65、每个特征评分区间是 0~5 这两个要求。为什么要这样设计？因为 0.65 保证了调整系数永远不会低于 0.65，哪怕所有特征都完全没有影响，也不算到零；上限则是 1.35。如果题目给了一堆冗余系统特征描述，先不慌，只要逐个打分并按公式算就行。

2.4 对象点和用例点：知道适用场景就够了

对象点（Object Point）常用于项目早期快速估算，以界面、报表和模块数量为基础，适合数据库和界面密集型系统。用例点（Use Case Point）则基于参与者权重和用例权重展开，常用于 UML 建模驱动的项目，估算时还要考虑技术复杂度因子和环境因子。这两类规模度量在考试中一般不会出太深的计算，通常以选择题或简答题出现，重点是把适用场景说清楚：传统事务处理用 FPA，界面密集系统用对象点，用例驱动开发用用例点。

3. Halstead 和 McCabe 两套公式，计算题基本从这出

3.1 Halstead 度量：操作符和操作数别数错

复杂度度量整章可以看成两大支柱，一个是 Halstead 度量，一个是 McCabe 圈复杂度。Halstead 从代码的词汇与长度出发，认为程序可以看成“操作符”和“操作数”的组合。操作符包括运算符、关键字、括号、分号等语法元素；操作数则包括变量名、常量等。

先记住四个基础计数：n1 表示不同操作符个数，n2 表示不同操作数个数，N1 表示操作符总出现次数，N2 表示操作数总出现次数。由这四个量可以派生出很多指标，最常考的是这几个：

• 程序长度 N = N1 + N2；
• 词汇量 n = n1 + n2；
• 程序量 V = N × log₂(n)；
• 程序难度 D = (n1 / 2) × (N2 / n2)；
• 工作量 E = D × V；
• 智能度 S = V / D。

很多同学会把 D 公式里的 N2 和 n2 位置记反。我的记忆技巧是：公式里只有 n1 和 N2，没有 N1；难度本质是“不同操作符种类越多越难，操作数重复使用次数越多越难”。N1 不参与 D 的计算。

3.2 一个伪代码例子带你完整统计

这里用伪代码演示统计过程，便于理解公式到底怎么套。假设统计对象是：

IF a > b THEN c = a + b ELSE c = a - b ENDIF

以常见的课堂约定为准，IF、THEN、ELSE、ENDIF、>、=、+、- 都算操作符，a、b、c 算操作数。那么 n1 = 8，n2 = 3；操作符出现次数里“=”出现 2 次，其余各出现 1 次，所以 N1 = 9；操作数 a、b、c 各出现 2 次，所以 N2 = 6。于是 N = 9 + 6 = 15，n = 8 + 3 = 11，V = 15 × log₂(11) ≈ 51.9，D = (8 / 2) × (6 / 3) = 8，E = D × V ≈ 415.4，S = V / D ≈ 6.5。

这里强调一点，不同类型的括号、关键字是否算作操作符，不同教材和老师可能有差异，考试时如果题目没有给约定，优先按课堂笔记的约定来，不要自己发挥。

3.3 McCabe 圈复杂度：同一个模块要写几个测试用例

McCabe 圈复杂度也叫环路复杂度，用来衡量程序控制流的复杂程度，计算法和路径测试直接挂钩。最基础的计算方法是根据程序图：V(G) = e - n + 2p，其中 e 是边数，n 是节点数，p 是连通分量数，一般无向连通图的 p = 1。

更实用的考试公式是：V(G) = 判定节点数 + 1。所谓判定节点就是产生分支的节点，如 if、while、case、三目运算符等。顺序结构的 V(G) = 1，一个 if-else 的 V(G) = 2，一个 while 循环的 V(G) = 2，两个 if 嵌套则 V(G) = 3。有些教材还强调 V(G) 等于程序图中区域的数目，三种算法选哪种快就用哪种。

圈复杂度的意义在于测试：基本路径测试要求覆盖的独立路径数量等于 V(G)，所以算出 V(G) = 3，写测试用例时就至少要准备 3 条独立路径。考试经常同时出现“求圈复杂度”和“至少设计几个测试用例”这两种问法，本质是一个答案。

3.4 两套复杂度怎么分辨

Halstead 和 McCabe 的计算思路完全不一样，考试却喜欢放在同一张卷子里。Halstead 看的是代码的词汇特征，比如操作符操作数的种类和次数，偏向文本统计；McCabe 看的是控制流结构，比如分支数量，偏向拓扑结构。一个模块可能 Halstead 的值不大，但 McCabe 很高，因为逻辑分支特别多；也有可能代码很长导致 Halstead 很高，但整体结构是顺序执行，McCabe 仍然等于 1。所以复习时要明确：两者是互补的，一个管“代码写得难不难”，一个管“控制流绕不绕”。

4. 质量度量和过程度量：缺陷密度、COCOMO 这些高频点

4.1 先分清错误、缺陷和失效

质量度量常考的三个词：错误（error）是人在开发过程中犯下的失误，缺陷（defect/fault）是由错误引入并残留在代码或文档中的问题，失效（failure）是缺陷在运行时被触发后表现出的异常行为。一句话总结：人犯了错误，代码留了缺陷，系统产生失效。简答题里这个辨析经常出现，千万不要把 fault 和 failure 混着用——一个是静态的、存在于产品中，一个是动态的、发生在运行时。

4.2 缺陷密度和可用性计算

缺陷密度是最基础的质量指标，公式是缺陷数除以规模，规模可以用 KLOC，也可以用功能点。比如一个 5 KLOC 模块发现 20 个缺陷，缺陷密度就是 4 个/千行。这个指标可以用来比较同类模块的质量，但要注意不同语言、不同业务复杂度下缺陷密度差异很大，横向比较要谨慎。

可靠性相关的公式也经常考。MTTF 是失效前平均时间，MTTR 是平均修复时间，MTBF 是平均失效间隔时间，且 MTBF = MTTF + MTTR。可用性 A = MTTF / (MTTF + MTTR)，也写作 MTTF / MTBF。这里容易犯的错误是把可用性写成 MTTF / MTTR，题目里常设置一个干扰项，看到分母千万别想当然。

4.3 内聚与耦合：质量设计的重要判断

内聚衡量模块内部元素结合的紧密程度，从低到高依次是偶然内聚、逻辑内聚、时间内聚、过程内聚、通信内聚、顺序内聚、功能内聚；耦合衡量模块之间相互依赖的程度，从低到高通常分为无耦合、数据耦合、标记耦合、控制耦合、外部耦合、公共耦合、内容耦合。课程的核心思想是“高内聚、低耦合”，这是软件设计质量的经典判断标准。

考试给出代码片段让你判断耦合类型的概率不小。记住最典型的分界：如果模块之间传递的是普通数据变量，是数据耦合；如果传递的是开关变量、控制标志，是控制耦合；如果共享全局数据区，是公共耦合；如果直接访问另一个模块内部数据，是内容耦合。看到“flag”“mode”“switch”这类参数时要警觉，多半往控制耦合方向判断。

4.4 面向对象度量：C&K 度量要认识

面向对象软件不能只用传统函数级复杂度评估，C&K 度量套件是经典方法。WMC 是类的加权方法数，类内方法复杂度总和越大，类的职责越重；DIT 是继承树深度，越深复用越多但理解成本上升；NOC 是子类个数，越大说明父类变更影响范围越广；CBO 是类之间耦合数，越大越难维护；RFC 是类响应集大小，越大测试越复杂。这五个指标基本是简答或者选择题，不要求大计算，重在理解每个值变大代表什么风险。

4.5 过程度量与 COCOMO 工作量估算

过程度量这块最核心的是成本估算模型。COCOMO 基本模型用公式 E = a × Sᵇ 估算工作量，其中 S 是规模，单位 KLOC，E 是工作量，单位人月。不同模式参数如下：

开发时间 TDEV = c × Eᵈ，组织型 c=2.5、d=0.38，半独立型 c=2.5、d=0.35，嵌入型 c=2.5、d=0.32。预算一个 50 KLOC 的嵌入式项目，E = 3.6 × 50^1.20 ≈ 393 人月，TDEV ≈ 2.5 × 393^0.32 ≈ 16.9 个月。算这类题时，如果题目提供了参数表就按表来，没有提供就用常见教材参数。

除了 COCOMO，挣值分析（EVM）也常考，核心是四个值：计划价值 PV、挣值 EV、实际成本 AC、成本偏差 CV = EV - AC、进度偏差 SV = EV - PV、成本绩效指数 CPI = EV / AC、进度绩效指数 SPI = EV / PV。记住一点：偏差和绩效指数为正或大于 1 才代表好状态，负数或小于 1 意味着超支或延期。

5. 备考复盘：我在软件度量上踩过的坑和最后建议

5.1 公式记忆坑：先把符号写到纸上

Halstead 这套公式，我当年复习时最大的问题是把 N 和 n 搞混。后来我把符号卡写在草稿纸最上面：小写 n 表示“不同”的个数，大写 N 表示“总共”出现的次数。只要这个区分刻进脑子里，V、D、E 基本不会错。McCabe 那边则要注意 e - n + 2p 中 p 通常为 1，如果你拿到的程序图画着多个连通分量，不要想当然把 p 写成 1。

5.2 功能点计数坑：五类清单固定怼在草稿纸上

我刚才提到的五类清单法，在考场上真的救命。拿到一个功能点大题，先别急着算权重，先把题目中可能对应 EI、EO、EQ、ILF、EIF 的句子全部标注出来，再逐个确认。特别是 EIF，很多同学栽在上面。如果你最后算出来的未调整功能点和同学差得很多，大概率是五类部件有漏数或多数。

5.3 概念辨析坑：错、缺、失效是三个词

简答题里把 error、fault、failure 混写的同学不少。我的经验是：可以用“原因→载体→表现”来记忆，error 是原因，fault 是载体，failure 是表现。答题时不要只写中文，最好把英文关键词也带上，因为阅卷老师可能会按要点给分。

5.4 我的复习节奏和时间分配

如果再让我重新备考一科，我会把整体时间分成三个部分：先用四分之一时间把基本概念和 GQM 看懂，特别适合做思维导图；再花二分之一时间集中刷计算题，重点就是功能点、Halstead、McCabe、COCOMO、EVM，每类至少做两三道完整题；最后留四分之一时间专门背概念辨析、内聚耦合层次和 C&K 度量的含义。计算题不要只看不练，真正落笔写过程才能发现哪里会卡住。

考前最后一天，我会自己默写一张表：左边写 Halstead 全部公式，中间写 COCOMO 三模式参数，右边写 EVM 的 CV、SV、CPI、SPI。能默写出来，第二天进考场心里基本就稳了。软件度量这门课确实不难，难的是把公式和定义串成体系。按照这套节奏复习下来，你会在考场上发现，大部分题其实都是平时见过的老面孔。

本文还有配套的精品资源，点击获取