课程名称：软件工程 第3讲

班 级：
日 期：
教 室：
教学题目：第2章 软件项目管理 2.1 软件度量
2.2软件项目的估算 2.2.1软件项目估算方法
教学目的：了解软件度量的基本概念，掌握面向规模和
面向功能点度量方法。了解项目估算方法。
教学重点：面向规模和面向功能点的度量方法。
教学难点：面向功能点的度量方法
教 具：多媒体教室、电子教案
作 业：
 第2章 软件项目管理
软件项目管理必须从项目的开头介入，并贯穿于整
个软件生存周期的全过程。
软件项目管理的范围主要集中于3个P上，即：
People（人员）、Problem（问题）和Process（过程）。
软件项目管理的主要任务是：
根据选定的软件开发过程框架（即软件开发模型）
和对其估算的结果制定软件项目实施计划；再根据
计划对人员进行组织、分工；按照计划的进度，以
及成本管理、风险管理、质量管理的要求，控制并
管理软件开发和维护的活动，最终以最小的代价完
成软件项目规定的全部任务。
 第2章 软件项目管理
软件项目的成本管理、软件质量管理和软件配置管理
有一定的特殊性和独立性，可单独立项。其任务分别
是：
成本管理——估算软件项目的成本，作为立项和签合
同的依据之一，并在软件开发过程中按计划管理经费
的使用；
质量管理——制定软件质量保证计划，按照质量评价
体系控制软件质量要素，对阶段性的软件产品进行评
审，对最终软件产品进行确认，确保软件质量；
配置管理——制定配置管理计划，对程序、数据、文
档的各种版本进行管理，确保软件的完整性和一致性。
 第2章 软件项目管理

在制定有效的项目实施计划的过程中，首先要
对项目的工作量、完成期限等等参考量进行估
算。估算的结果将成为项目计划其他活动的基
础，同时，为了对软件项目进行科学、有效的
管理，就必须对软件开发过程的有关特征进行
度量，度量的结果用于软件开发过程的管理与
监控。
本章主要介绍软件度量的概念，软件的规模度
量，软件项目的估算，软件的质量度量、复杂
性度量、可靠性度量、风险的分析与度量以及
软件项目管理过程与步骤等等。
第2章 软件项目管理
2.1 软件度量
2.2 软件项目估算
2.3 软件质量度量
2.4 软件复杂性度量
2.5 软件可靠性度量
2.6 软件开发过程的管理
习题思考题
 2.1 软件度量
对软件工程项目的规模、成本、产品质量等属性进
行定量的描述，可以帮助项目管理人员和开发者制
定有效的项目计划，监控项目的风险、进度和阶段
产品的质量，并为调整过程中活动和做出重要决策
提供可靠的依据。下面介绍软件度量的基本概念，
并介绍软件的规模度量和功能度量。
2.1.1 软件度量的基本概念
1．测量、度量、估算和指标
软件工程项目的定量描述涉及测量、度量、估算
和指标等一些基本概念。
1）测量（measure）：对产品或过程的某
个属性的范围、数量、维度、容量或大
小提供一个定量的指示。
2）度量（metric）：对系统、部件或过程
的某一特性所具有的程度进行的量化测
量。如软件质量度量等。
3）估算（estimation）：对软件产品、过
程、资源等使用历史资料或经验公式等
进行预测。如工作量、成本、完成期限
等。估算一般用于立项、签订合同、制
定工作计划等。
4）指标（guideline）
指标——是一个度量或度量的组合，它可对软件产
品、过程或资源提供更深入的理解。
如有4个小组共同完成一个软件项目，每一个小
组都必须采用自行选择的评审类型进行技术评审。
管理者检查“每小时每人所发现的错误数”这一度
量结果时发现：采用正式技术评审方法的两个小组
的该度量值要比另外两个小组高出40%。假设4个
小组的其他参数都相同，这就给管理者提供了一个
指标：正式技术评审方法比其他技术评审方法更有
效率。于是，管理者可决定建议所有小组都采用更
加正式的技术评审方法。
 2．软件项目管理的对象及其属性
软件项目管理的对象主要包括产品、过程和资源等。
产品（product）是指软件开发过程得到的文档和程序，
如：需求规格说明、设计规格说明、源代码、测试报
告等；
过程（process）是指与软件项目有关的活动，如软件
项目计划、开发活动、维护活动、管理活动等；
资源（resource）是指进行软件项目所需要的各种支
持，如人力、经费、方法、工具、软硬件环境等。
要对软件项目管理的对象进行有效的管理与控制，
就必须对这些对象的属性进行测量、度量与估算。一
般来说，产品、过程、资源等对象都具有内部属性和
外部属性。
 对象的属性

内部属性是指对象本身的属性，如软件
产品的代码长度、模块化的程度、复杂
性等。
对象的外部属性体现了对象与环境的关
系，如软件的可靠性、可维护性、可移
植性、成本、人员的生产率等。对象的
部分属性如表2-1所示。
 表2-1 软件工程的产品、过程、资源的属性
产 品 过 程 资 源
程序代码行长度；
内 程序功能； 人员；
部 模块化； 工作量； 方法；
属 控制流结构； 计划及进度； 工具；
性 重用性； 事件。 环境；
模块耦合度与内聚度。 经验。
软件的可靠性；
外 软件的可理解性；
成本；
部 软件的有效性； 成本；
可控制性；
属 软件的可用性； 生产率；
可观察性；
性 软件的可维护性； 时间。
稳定性。
软件的可移植性。
 对象的属性
 项目管理员和用户都十分关心产品、过程、
资源的外部属性，于是可将外部属性看成是
面向管理员和用户的属性。但在软件开发的
过程中，软件的外部属性一般是很难度量和
控制的。这些外部属性是由软件的内部属性
所决定的，因此，可以通过研究内部属性与
外部属性之间的关系来解决外部属性的度量
问题，进而逐步建立起了软件工程度量系统。
 3．软件度量的分类
可分为直接度量和间接度量两类：
1）直接度量。即对不依赖于其他属性的简
单属性的测量。如软件的模块数、程序的代码
行数、操作符的个数，工作量、成本等。
2）间接度量。即对涉及若干个其他属性的
软件要素、准则或属性的度量。因为它们必须
通过建立一定的度量方法或模型才能间接推断
而获得。如软件的功能性、复杂性、可靠性、
可维护性等等。
软件度量系统还可进一步划分为两个侧面。
它们之间的关系如图2-1-1所示。
 技术度量

质量度量

生产率度量

面向规模的度量

面向功能的度量

面向人的度量

图2-1-1 两侧面间关系
 2.1.2 面向规模的度量
面向规模的度量是以软件的代码行（LOC，
Line of Code）数为基础的直接度量。一般的
软件开发组织对开发过的每个软件项目都有如
代码行、工作量、成本、错误、人数、文档页
数等的统计记录。利用代码行数可以度量软件
规模、生产率、平均成本、出错率、文档率等
参考量。
设 ： L 表 示 软 件 的 代 码 行 数 ， 单 位 为 KLOC
（千行代码）或LOC；E表示开发软件所需工
作量，单位为人月（PM）或人年（PY）；S
表示软件成本，单位为美元或元；N表示错误
个数；Pd表示软件文档页数；M表示开发所用
的人数。则有：
1．软件开发的生产率P（即平均每人月开发的代码行数，
以LOC/PM为单位）为：
P=L/E （2-1）
2．开发每行代码的平均成本C（以美元/LOC或元
/LOC为单位）为：
C=S/L （2-2）
3．代码出错率EQR（即每千行代码的平均错误数，
以个/KLOC为单位）为：
EQR = N / L （2-3）
4．软件的文档率D（即平均每千行代码的文档页数，
以页/KLOC为单位）为：
D = Pd / L （2-4）
【例2.1】 已知有一个国外典型的软件项目的记录，开发
人 员 M=6 人 ， 其 代 码 行 数 =20.2KLOC ， 工 作 量
E=43PM，成本S=314000美元，错误数N=64，文档页
数Pd=1050页。试计算开发该软件项目的生产率P、平
均成本C、代码出错率EQR和文档率D。
解：根据给出的已知数据，可得：
P = L / E =20.2 KLOC /43 PM = 0.47 KLOC / PM
= 470 LOC / PM
C = S / L = 314000美元 / 20.2 KLOC
= 15.54 美元 / LOC
EQR = N / L = 64个 / 20.2KLOC = 3.17 个 / KLOC
D = Pd / L = 1050 页 / 20.2 KLOC = 51.98 页 / KLOC
基于代码行面向规模的度量方法的
优缺点、适用场合

优点：简单、直接。
缺点：如它依赖于程序设计语言的功能和表达
等特征、在开发初期很难准确估算出
代码行数、对设计水平高的软件项目
产生不利影响。
适用场合：适合于过程式程序设计语言和事后
度量。
 2.1.3 面向功能的度量

1．简单功能点度量
1979年，Albrecht首先提出了功能点度
量方法。这是一种面向功能的间接度量
方法，即从软件定义的基本功能出发，
来估算软件系统的规模。因此，该方法
可以在软件开发项目的初期，在软件定
义过程中即可预测待开发软件的规模。
 1．简单功能点度量
功能点FP的度量公式如下：
14
FP = CT×TCF = CT [0.65 + 0.01∑F i ] （2-5）
i=1
其中：
CT——基本功能点。
CT值按表2-2来计算，它的值为5个参数加
权值的总和。
 表2-2 简单功能点度量的基本功能点的计算

加权因子
测量参数 值 加权值
简单 一般 复杂
用户输入数 ×3 ×4 ×6 =
用户输出数 ×4 ×5 ×7 =
用户查询数 ×3 ×4 ×6 =
文件数 ×7 ×10 ×15 =
外部接口数 ×5 ×7 ×10 =
基本功能点CT
 表2-2中的5个参数的含义
1）用户输入数：用户为软件系统提供的输入参数的个
数（不包括查询）；
2）用户输出数：软件为用户提供的输出参数（报告、
屏幕帧、错误信息等）的个数；
3）用户查询数：一次联机输入导致软件以联机输出方
式实时产生一个响应的个数；
4）文件数： 逻辑主文件的个数；
5）外部接口数：机器可读的接口（如磁盘或磁带上的
数据文件等）的个数。
 1．简单功能点度量
在FP度量公式中：
TCF——技术复杂性调节因子。
0.65和0.01——经验数据。
Fi（i=1，2，…，14）——复杂性调节值。
Fi所代表的因素如表2-3所示，每个Fi可根据实
际情况取0、1、2、3、4、5中的一个值。
其中：0—没有影响、1—偶然的、2—适中、
3—普通、4—重要、5—极重要的影响。
TCF取值范围：0.65 ~ 1.35。
 表2-3 F i 取值表

i 因素 Fi i 因素 Fi
1 需要可靠的备份和恢复吗？ 8 需要联机更新主文件吗？
2 需要数据通信吗？ 9 输入、输出、文件、查询
3 有分布式处理的功能吗？ 复杂吗？
4 性能是关键吗？ 10 内部处理过程复杂吗？
5 在现存实用的操作环境下 11 要求代码设计可重用吗？
运行吗？ 12 设计中包含转换和安装吗？
6 需要联机数据入口吗？ 13 系统设计支持不同组织的
7 联机数据入口需要用输入 多次安装吗？
信息构造复杂的界面或操 系统设计有利于用户的修
作吗？ 14
改、使用吗？
 2．功能点度量
简单功能点度量方法没有直接考虑软件本身的算法
的复杂性问题。所以它仅适用于度量算法简单的事
务处理等系统。
1986年Jones对简单功能点度量进行了推广，在计
算软件系统的基本功能点CT时，引入了算法复杂
性因素，即使用表2-4计算CT 。我们称这种推广的
度量方法为功能点度量。
这两种方法对一般的事务处理系统等算法简单的软
件系统计算出来的FP值基本相同，但对于较复杂
的软件系统，功能点度量方法比简单功能点度量方
法计算出来的FP值要高20%~35%。
表2-4 推广的功能点度量的基本功能点的计算

测量参数 值 权值 加权值
用户输入数 ×4 =
用户输出数 ×5 =
用户查询数 ×4 =
文件数 ×7 =
外部接口数 ×7 =
复杂算法数 ×3 =
基本功能点CT
 用功能点计算软件项目的有关参考量：

1）生产率P（平均每人月开发的功能点数，以功
能点 / PM为单位）：
P = FP / E （2-6）
2）平均成本C（以美元/功能点或元/功能点为单
位）：
C = S / FP （2-7）
 用功能点计算软件项目的有关参考量：

3）代码出错率EQR（即每功能点的平均错误
数，以个/功能点为单位）为：
EQR = N / FP （2-8）
4）软件的文档率D（即平均每功能点的文档
页数，以页/功能点为单位）为：
D = Pd / FP （2-9）
 3．功能点度量方法的优缺点
优点：
①可用于软件项目开发的初期阶段的项目估
算。因为在可行性研究和需求分析阶段已
能基本确定输入、输出等各个参考量；
②与程序设计语言无关。适合于过程或非过
程式语言。
缺点：
①某些参考量的收集有一定困难；
②度量值的主观因素较多，如Fi取值；
③功能点FP本身没有直观的物理意义。
 4．软件的代码行与功能点的关系

 软件的功能点数和选用的程序设计语言
无关，但对于同一个软件（功能点数已
定），如用不同的程序设计语言来实现，
所得到的软件的代码行数可能会有较大
差别。Albrecht等人通过多个软件统计
出了用不同程序设计语言实现每个功能
点所需代码行数，即计算出各语言的
LOC/FP的平均值，如表2-5所示。
表2-5 部分程序设计语言LOC/FP平均值的比较

程序设计语言 LOC/FP 程序设计语言 LOC/FP

汇编语言 320 Ada 70
C语言 128 面向对象语言 30
COBOL 105 第四代语言（4GL） 20
FORTRAN 105 代码生成器 15
Pascal 90 图形语言（图标） 4
 2.2 软件项目估算
2.2.1 软件项目的估算方法

常用的软件项目的估算方法主要有以下4种：
1．自顶向下的估算方法
基本思想：首先根据已完成项目的总成本或总
工作量来推算待开发软件的总成本或总工作量，
然后再按比例将其分配到各开发任务中去。即
从整体到局部。
优点：估算工作量小、速度快。
缺点：对项目中的特殊困难估计不足，有可能
产生遗漏，估算出的值盲目性较大。
 2．自底向上的估算方法
基本思想是：把待开发软件细分，直到每一个
子任务或阶段都已经明确所需要的开发工作量
或成本，然后再把它们累加起来，得到待开发
软件的总工作量或总成本。
需要指出，在对软件进行细分时，一种是按照
功能将大的软件项目划分为若干个子项目；另
一种是按照软件生命周期分解为各个阶段。当
然，也可以两者同时进行。
优点：计算各个部分的准确性较高。
缺点：缺少各个子任务之间相互联系的工作量
和系统工作量（如项目管理、配置管理、质量
管理），估算值往往偏低，必须用其他方法进
行校正。
 3．差别估算法

基本思想：把待开发的软件项目与过去完成的
软件项目进行比较，从各子任务中区分出类似
的和不同的部分。类似的部分按已知的实际量
计算，不同的部分则采用某种方法进行估算。
差别估算法综合了以上两种方法的优点。
优点：估算的准确程度高。
缺点：不容易划分相似的界限。
 4．根据经验估算公式

通过众多实际软件项目的经验，总结出一些有
价值的软件成本和工作量估算的经验模型。这
些模型对于软件项目管理具有一定的指导意义
和验证效果。

没有一种估算模型能够适合于所有类型的软件
项目。因此，对估算的结果应当慎重使用。

在实际估算时，几种估算方法可单独、同时或
组合使用，以便提高估算的准确程度。
 估算方法举例

【例2.2】Boehm给出了“软件库存情况更
新”项目采用自顶向下估算方法的一个
参考例子，由过去已完成的项目的工作
量，估算出该项目的总工作量为53。然
后将其按比例分配到各个阶段，如表2-6
所示。从中可以看出软件开发各阶段工
作量的分配情况。
 表2-6 软件项目的自顶向下估算
软件库存情况更新 开发者：W.Ward 日期：2/8/82
阶段 任务 工作量（1/53） 小计（1/53）
可行性研究与 软件需求定义 5
6
需求分析 开发计划 1
概要设计 6
概要设计 初步用户手册 3 10
测试计划 1
详细PDL描述 4
数据定义 4
详细设计 12
测试数据及过程设计 2
正式的用户手册 2
编码 6
编码 16
单元测试 10
编写文档 4
组装与联合测试 9
组装与联合测试 5
总计 53
课程名称：软件工程 第4讲
班 级：
日 期：
教 室：
教学题目：2.2.2 代码行和功能点的估算，2.2.3软件
项目的经验估算模型.
教学目的：熟悉软件项目估算模型。
教学重点：软件项目估算模型。
教学难点：详细CoCoMo模型
教 具：多媒体教室、电子教案
作 业：
 2.2.2 代码行和功能点的估算
采用2.2.1中介绍的估算方法可以估算出代码行
或功能点的乐观值a、一般值m和悲观值b，并
用如下的加权平均公式计算LOC或FP的期望
值（expectation）：
X =（ a +4 m +b）/ 6 （2-10）
软件的LOC或FP的期望值估算出来后，就
可以根据已有的标准生产率对成本和工作量等
进行估算了。
【例2.3】对CAD软件项目进行估算

解：这里采用自底向上的估算方法。即首先，将
CAD项目按功能分解为7个子项目，并估算出
每个子项目LOC的乐观值a、一般值m和悲观
值b，由此可估算出每个子项目的代码行的期
望值X。在根据已知的开发类似子项目的生产
率P和平均成本C即可估算出每一个子项目的
成本和工作量，最后将7个子项目的成本和工
作量分别累加，即可估算出软件项目的总成本
S和总工作量E。估算的各种值如表2-7所示。
表2-7 采用加权平均、自底向上方法估算代码行、成本和工作量

a m b X 每行成本C 生产率P 成本S 工作量

子项目
(LOC) (LOC) (LOC) (LOC) (美元/LOC) (LOC/PM) (美元) (PM)

用户接口控制 1800 2400 2700 2350 14 315 32900 7.5

二维几何造型 4100 5200 7500 5400 20 220 108000 24.5

三维几何造型 4800 6900 8700 6850 20 220 137000 31.1

数据库管理 2900 3500 3700 3350 18 240 60300 13.9

图形显示 4000 4900 6400 5000 22 200 110000 25.0

外设控制 2000 2100 2500 2150 28 140 60200 15.4

设计分析 6600 8500 9800 8400 18 300 151200 28.0

总计 33500 659600 145.4

 估算的组织实施
为了使估算更准确，可以组织几个专家采用无
记名的方式分别填写表2-7，然后组织者计算
出这几个表格的平均值；这一过程可反复几次，
直到获得一个得到多数专家共识的软件规模。
另外，还可以将每个子项目再按生存周期划分，
估算其各阶段的工作量，再累加求出每个子项
目的工作量和整个项目的工作量。可将用几种
方法估算的结果进行比较来验证估算的准确性。
 2.2.3 软件项目的经验估算模型

1．IBM模型——1977年，IBM公司对60个软件项目的
数据利用最小二乘法拟合，得到的经验估算公式：
E = 5.2 × L0.91 （2-11）
D=4.1×L0.36 = 2.136× E0. 3956 （2-12）
S = 0.54 × E0.6 （2-13）
DOC = 49 × L1.01 （2-14）
其中：E为工作量（PM）；L为源代码行数（ KLOC ）；
D为项目持续的时间，以月为单位；
S为人员需要量（人）；DOC为文档数量（页）。
 1．IBM模型

IBM模型是根据已估算出的源代码行数来估算
其他资源的需要量的，因此该模型是面向LOC
的静态单变量估算模型。

还有一些面向FP的静态单变量估算模型。由于
这些模型的准确度不高，在实际应用中必须对
公式中的参数进行调整，以适应目前情况。
 2．Putnam模型

1978年，Putnam提出了大型软件项目的动态
多变量估算模型。
该模型以工作量在30人年以上的大型软件项目
的实测数据为依据，推导出了工作量分布曲线，
如图2-2-1所示。
图中的工作量分布曲线的形状与著名的
Rayleigh-Norden曲线相似。
 工作量 （人年）
系统定义、需求分析 开 发 运行维护

总工作量
测试和确认

设计编码 维护
功能设计
系统定义 规格说明
管理

0 td
开发占总工作量的40% 维护占总工作量的60% 时间t（年）

图2-2-1 软件项目的工作量分布曲线
 2．Putnam模型
由上图可得出Putnam估算模型如下：
L = Ck E1/3 td 4/3 （2-15）
其中：L为源代码行数（以LOC计）；
E为开发与维护的工作量（以人年计）；
td为开发时间（以年计）；
C k为技术状态常数，与开发环境有关，如下：
2000 较差，没有方法学的支持，缺乏文档
和评审，采用批处理方式；
C k= 8000 一般，有方法学的支持，有适当的文档
和评审，采用交互处理方式；
11000 较好，有集成化的CASE工具和环境。
 2．Putnam模型

由式（2-15）可以得出估算工作量的式子：
E = L3 / (Ck3 td4) (2-16)
工作量估算出来之后，就可以估算软件项目的成本。
式中的td是对应于软件交付时的时间，它正好是工
作量曲线的峰值，说明此时的工作量最大、参加
项目的人最多。
图2-2-2给出了软件开发项目每年所需的人年数与
开发时间的关系。
 R-N分布

人 线性分布
年
数
\

td
0 1 2 3 4 t（年）

图2-2-2 概率密度
 2．Putnam模型

如图2-2-2所示，软件开发项目每年所需的人年
数与开发时间的关系满足Rayleigh-Norden分
布，即软件项目的工作量分布曲线不是线性的，
因此，参加软件项目的人员就不能一成不变。
如果按线性方案平均分配人员，则开发的初期
一部分人力是多余的，而到了峰值段人力明显
不足，到了开发的后期再临时增加人力已为时
过晚，即造成了浪费，又拖延了进度。
 2．Putnam模型
从公式（2-16）即 E = L3 / (Ck3 td4)还可以看出，
开发软件项目的工作量和交货时间td的4次方成
反比，如果条件允许，适当地推迟交货时间
（即使td增大），可大幅度降低开发工作量。
例如：如果以1.1td代替式（2-16）中的td，即
推迟10%的时间交货，可使开发工作量E减少
到原来的68%。反之，如果以0.9td代替td，即
提前10%的时间交货，会使E比原来增加52%。
因此，工作量与时间的折衷就显得十分重要。
图2-2-3给出了各类人员随开发工作的进展在软
件工程各阶段参与情况的典型曲线。
人数 初级技术人员

高级技术人员

管理人员
系 需 概 详 编 单 组 验
统 求 要 细 码 元 装 收
定 分 设 设 测 测 测
义 析 计 计 试 试 试

图2-2-3 人力资源的分配
 Putnam模型的优缺点

优点：揭示了软件项目的源程序代码长度、
软件开发时间和工作量三者之间的关
系，在理论上有重要意义。
缺点：准确程度不高。
没有反映软件产品、项目、参加人员、
软硬件资源等属性。
 3．CoCoMo模型

1981年，Boehm提出了CoCoMo模型
（Constructive Cost Model，即构造性成
本模型）。该模型是以静态单变量模型
为基础构造出来的。CoCoMo模型按其
详细程度分三个层次：
基本CoCoMo模型；
中间CoCoMo模型；
详细CoCoMo模型。
 1）基本CoCoMo模型
其工作量和开发时间的估算公式如下：
E = a Lb （2-17）
D = c Ed （2-18）
其中：
L —— 软件代码行的估算值（以KLOC计）；
E —— 工作量（以PM计）；
D——开发时间（以月计）；
a、b、c、d——经验常数。应根据待开发软件所属的
类型按照表2-8来选取。
 表2-8 a、b、c、d参数值的选取

软件类型 a b c d 适应领域

组织型 2.4 1.05 2.5 0.38 一般应用程序

实用程序、
半独立型 3.0 1.12 2.5 0.35
编译程序等
实时控制程序、
嵌入型 3.6 1.20 2.5 0.32
操作系统
基本CoComo模型主要用于系统开发的初期估算整
个系统开发和维护的工作量及软件开发所需时间。
【例2.4】用基本CoCoMo模型计算开发CAD软件所
需的工作量、开发时间以及需要参加项目的平均人数。
解：在【例2.3】中已估算出CAD软件的代码行数为
33.5KLOC，CAD软件为半独立型、中等规模的软件，
由表2-8可查出a = 3.0，b = 1.12，c = 2.5，d = 0.35。
CAD项目的开发工作量为：
E = a Lb = 3.0×33.51.12 = 153 PM
开发时间为： D = c Ed =2.5 × 1530.35 = 14.54（月）
CAD项目平均需要的人力为：
N = E / D = 153 / 14.54 ≈ 11人
 2）中间CoCoMo模型
中 间 CoCoMo 模 型 在 估 算 工 作 量 时 ， 在 基 本
CoCoMo模型的基础上再乘以由15个因素组成的工
作量调节因子EAF，于是有：
15
E = a Lb EAF = a Lb ∏ F i （2-19）
i=1
其中：
L —— 软件的代码行数（以KLOC计）；
E —— 工作量（以PM计）；
a、b —— 经验常数，其取值如表2-9所示；
 表2-9 a、b参数的取值

软件类型 a b
组织型 3.2 1.05
半独立型 3.0 1.12
嵌入型 2.8 1.20
 2）中间CoCoMo模型

工作量调节因子EAF与软件的产品的取值属
性、计算机属性、人员属性、项目属性等因
素有关。这15个因素Fi（i=1~15）的值可按
等级取值，即可分为很低、低、正常、高、
很高、极高，共6级。正常情况下Fi=1。
Boehm推荐的Fi值的范围是0.70~1.66，F i的
值可根据实际情况按表2-10来选取。
工作量E求出之后，就可以用公式（2-18）
即 D = c Ed计算出开发时间D。
 表2-10 工作量调节因子F i的取值
Fi 属性含义 很低 低 正常 高 很高 极高
F1 软件可靠性（RELY） 0.75 0.88 1.00 1.15 1.40
产品
F2 数据库规模（DATA） 0.94 1.00 1.08 1.16
属性
F3 软件复杂性（CPLX） 0.70 0.85 1.00 1.15 1.30 1.65
F4 执行时间约束（TIME） 1.00 1.11 1.30 1.66
计算 F5 内存约束（STOR） 1.00 1.06 1.21 1.56
机
F6 开发环境变更率（VIRT） 0.87 1.00 1.15 1.30
属性
F7 开发环境响应速度（TURN） 0.87 1.00 1.07 1.15
F8 分析员的能力（ACAP） 1.46 1.19 1.00 0.86 0.71
F9 程序员的能力（PCAP） 1.42 1.17 1.00 0.86 0.70
人员
F10 应用领域经验（AEXP） 1.29 1.13 1.00 0.91 0.82
属性
F11 开发环境使用经验（VEXP） 1.21 1.10 1.00 0.90
F12 程序设计语言经验（LEXP） 1.14 1.07 1.00 0.95
F13 开发方法的能力（MODP） 1.24 1.10 1.00 0.91 0.82
项目
F14 软件工具的使用（TOOL） 1.24 1.10 1.00 0.91 0.83
属性
F15 开发进度约束（SCED） 1.23 1.08 1.00 1.04 1.10
 3）详细CoCoMo模型简介
详细CoCoMo模型的基本工作量（指EAF=1
时的工作量）公式、开发时间公式与中间
CoCoMo模型相同。
所不同的是详细CoCoMo模型在计算EAF时
针对每个影响因素，分层次（系统层、子系
统层、模块层）并按软件生存周期分阶段给
出工作量因素的分级表。
详细CoCoMo模型可以更准确地估算软件项
目的工作量。
 表2-11 子系统层软件可靠性工作量因素分级表

阶段 需求分析和 详细 编码及 集成及

综合
概要设计 设计 单元测试 测试
可靠性级别
很低 0.80 0.80 0.80 0.60 0.75
低 0.90 0.90 0.90 0.80 0.88
正常 1.00 1.00 1.00 1.00 1.00
高 1.10 1.10 1.10 1.30 1.15
很高 1.30 1.30 1.30 1.70 1.40
 通信工作量
由N个程序员组成的程序员小组的通信数量：
C（N）=N（N-1）/2
设：每两个人之间通信的平均工作量为μ
则：N人的程序员小组增加的通信工作量为：
EC = μC（N）= μN（N-1）/ 2 （2-20）
则该小组的总工作量ET为：
ET = E + EC （2-21）
 通信工作量
如图，由3人组成的程序员小组的通信数量：

C（3）=3（3-1）/2=3

而由5人组成的程序员小组的通信数量：
C（5） = 5（5-1）/2 = 10。
当程序员小组的人数较多时，通信工作量EC ≈ μN2
/2与人数的平方成正比，从而使程序员小组的生产
率随着人数的增加而迅速下降。
由此可见，当在开发的后期发现不能按时交货时，
临时盲目增加程序员将会更加推迟交货的日期。
 通信数

图2-2-4 N=3 和N=5 时的通信数

课程名称：软件工程 第5讲
班 级：
日 期：
教 室：
教学题目：2.3 软件质量度量，2.4软件复杂性度量
教学目的：理解软件质量、复杂性度量方法。
教学重点：软件质量、复杂性度量方法。
教学难点：软件质量要素的度量
教 具：多媒体教室、电子教案
作 业：
 2.3 软件质量度量
软件质量是软件的生命。它作为软件工程的
一部分，贯穿于整个软件生存周期之中。
生产高质量的软件产品是软件工程的首要目
标。
由于软件是逻辑产品，软件质量很难直接度
量。因此，应当给出软件质量的科学的、实
用的定义，并通过一定的度量模型进行度量，
以便在整个软件生存周期中对其进行评价和
控制。
 2.3.1 软件质量的定义
1983年，ANSI/IEEE std729标准给出了软件
质量的定义如下：
软件质量是软件产品满足规定的和隐含的与
需求能力有关的全部特征和特性，包括：
1．软件产品满足用户要求的程度；
2．软件拥有所期望的各种属性的组合程度；
3．用户对软件产品的综合反映程度；
4．软件在使用过程中满足用户需求的程度。
 2.3.2 软件质量的度量模型
 软件质量与软件的内部特性及其组合有关。要度量
软件质量，就应根据这些内部特性（即软件属性）
建立起软件度量模型，进而构建软件质量度量体系。
1976年，Boehm提出了定量度量软件质量的概念，
他给出了软件质量的层次模型，并给出了60个软件
质量度量公式；
1978年，Walters和McCall提出了三层次软件质量
度量模型；
1985年，ISO提出了SQM（Software Quality
Metric，软件质量度量）工作报告等等。
 1．McCall等人的软件质量度量模型

 McCall等人提出了由软件质量要素、评价准
则、定量度量三个层次组成的三层次度量模
型。
 其中:
第一层是将对软件质量的度量归结为对直接
影响软件质量的若干个软件质量要素的度量；
第二层是用若干个可度量的评价准则来间接
度量软件质量要素；
第三层是对相应评价准则的直接度量。
 要素j

评价 评价 … 评价
准则1 准则2 准则L

度量1 度量2 … 度量L

图2-3-1 软件质量三层次度量模型
 2．软件质量要素
 软件质量要素（factor）是指直接影响软件质量的
软件质量特性。
 随着对软件质量的认识的逐步提高，软件质量要素
也可能有所变化。
 当时McCall等人认为，软件质量由11个软件质量要
素来衡量。这11个质量要素可划分为三类：
面向运行特征的软件质量要素有正确性、可靠性、
有效性、完整性和可用性；
面向软件承受修改的质量要素有可维护性、灵活性、
可测试性；
面向转移的软件质量要素有可移植性、可重用性、
可互操作性。这三类要素构成了软件质量的三个侧
面，如图2-3-2所示。
 可维护性 可移植性
灵活性 可重用性
可测试性 产品 产品 可互操作性
修正 转移

产品
运行

正确性 可靠性 有效性

完整性 可用性
图2-3-2 软件质量要素的构成
 质量要素新概念
1）正确性（correctness）：
指程序满足需求规格说明及用户目标的程度；
2）完整性（integrity）：
指对未授权人员访问程序或数据加以控制
的程度；
3）可用性（usability）：
指学习使用软件（即操作软件、准备输入
数据、解释输出结果等）的难易程度；
 质量要素新概念

4）灵活性（flexibility）：
指改变一个操作的顺序所需工作量的多少；
5）可测试性（testability）：
指测试软件以便使其具有预定功能所需工
作量的多少；
6）可互操作性（interoperability）：
指程序与其他系统相互交换并使用信息的能力。
 2．软件质量要素
软件质量要素不是独立的，一个要素可能与
其他几个要素有关系，如表2-12所示，其中:
正相关以“√”表示，
负相关以“×”表示。
对于具有负相关的质量要素，在开发时应根
据具体情况加以取舍或进行折衷。
例如，对于实时控制系统，必须确保系统的
可靠性和有效性，而软件的可重用性、可移
植性等质量要素就可以放宽要求。
 表2-12 质量要素间的关系
可
可 可 可 可
关系 要素 正 可 有 完 可 灵 互
维 测 移 重
确 靠 效 整 用 活 操
护 试 植 用
性 性 性 性 性 性 作
要素 性 性 性 性
性
正确性
可靠性 √
有效性
完整性 ×
可用性 √ √ × √
可维护性 √ √ × √
灵活性 √ √ × × √ √
可测试性 √ √ × √ √ √
可移植性 × √ √
可重用性 × × × √ √ √ √
可互操作性 × × √
 3．软件质量要素的评价准则

软件质量要素一般很难直接测量。为了
对11个要素进行度量，McCall等人通过
确定影响软件质量要素的属性，定义了
21个软件质量要素的评价准则。这些评
价准则既能够比较完整、准确地描述软
件质量要素，又比较容易测量。
通过这组评价准则就可以间接测量软件
质量要素，进而度量整个软件质量。
 评价准则新概念
1）可审查性（audit-ability）：
检查软件需求、文档、过程、标准等是否一致
的难易程度；
2）准确性（accuracy）：计算和控制的精确程度；
3）简明性（conciseness）：程序源代码的紧凑程度；
4）通信通用性（communication commonality）：
使用标准接口、协议和带宽的程度；
5）数据通用性（data commonality）：
在程序中使用标准数据结构和类型的程度；
6）容错性（error-tolerance）：
在各种异常情况下软件能继续提供操作的能力；
 评价准则新概念
7）执行效率（execution efficiency）：软件运行效率；
8）可扩充性（expandability）：
结构、数据、过程等设计可以扩充的程度；
9）通用性（generality）：程序潜在应用领域的多少；
10）硬件独立性（hardware independence）：
软件与其运行的硬件环境无关的程度；
11）检测性（instrumentation）：
程序监视自身运行并标识错误的程度；
12）可操作性（operability）：
操作该软件的难易程度；
 评价准则新概念
13）安全性（security）：控制或保护程序和数
据不被破坏、非法访问等机制的能力；
14）自文档化（self-documentation）：
源代码提供自身说明文档的程度；
15）简单性（simplicity）：程序易于理解的程度；
16）软件独立性（software independence）：
软件与非标准编程语言特征、操作系统特征
等软件环境约束无关的程度；
17）易培训性（training）：
软件对使用它的新用户的支持程度。
 表2-13 质量要素与评价准则的关系

评价准则 可 完 数 硬 通 软
可执可 可 自 易
一容准简 检安据 通 件简信 件 模
关系 追全 操行审 扩 文 培
致错确单 测全通 用 独明通 独 块
踪性 作效查 充 档 训
性性性性 性性用 性 立性用 立 化
质量要素 性 性率性 性 化 性
性 性 性 性
正确性 √ √ √
可靠性 √ √ √ √
有效性 √ √ √
完整性 √ √ √
可用性 √ √
可维护性 √ √ √ √ √ √
灵活性 √ √ √ √ √ √ √
可测试性 √ √ √ √ √
可移植性 √ √ √ √ √
可重用性 √ √ √ √ √
可互操作性 √ √ √ √
 4．软件质量要素的度量
第j种软件质量要素Fj（j=1,2,…,11）的计算公式为：

Fj = ∑Cj k M k （2-21）

其中：M k 是第j 种软件质量要素F j 对第k种评价准则

的测量值。评价准则多数只能按主观想法定值。
McCall将每个评价准则都划分为0 ~ 10级，并且M
k 的值可以在0，0.1，0.2，…，1.0中取一个。
加权系数Cjk满足∑Cjk = 1，Cjk ≥ 0。
Cjk = 0表示质量要素与第k种评价准则无关。
 4．软件质量要素的度量
例如，要度量某软件的F2（可靠性）
假设C23=0.1，C24=0.3，C25=0.4，C26=0.2，
其余的C2k = 0，
而M3=0.7、M4=0.6、M5=0.5，M6=0.8，
则可靠性的度量值为：
F2 = C23M3+C24M4+C25M5+C26M6
=0.1×0.7+0.3×0.6+0.4×0.5+0.2×0.8
=0.61
 ISO三层次软件质量度量模型。
 1985年，国际标准化组织也提出了三层次软件质量
度量模型。其中：
高层称为软件质量需求评价准则（SQRC），并由
正确性、可容性、有效性、安全性、可用性、可维
护性、灵活性、可互操作性等8个要素组成；
中层称为软件质量设计评价准则（SQDC），并由
可追踪性、完全性…、等共23个评价准则组成；
低层称作软件质量度量评价准则（SQMC）。
 ISO认为，应对高层和中层建立国际标准，而低层
可由各使用单位自行制定。
 2.4 软件复杂性度量
通过软件的复杂性度量值可以估算出软
件中故障的数量；
也能估算出软件开发所需的工作量；
定量度量的结果还可以用于比较不同设
计方案的优劣。
同时，软件的复杂性也能从某些方面影
响软件的可维护性、可靠性等软件质量
要素。
因此，软件复杂性度量是软件度量的一
个重要组成部分。
2.4.1 软件复杂性的概念及度量原则
1．软件复杂性的概念
K . Magel 从6个方面来描述软件复杂性：
1）理解程序的难度；
2）维护程序的难度；
3）向其他人解释程序的难度；
4）按指定方法修改程序的难度；
5）根据设计文件编写程序的工作量；
6）执行程序时需要资源的多少。
软件复杂性反映了软件的可理解性、模块化、
简单性等属性。
 2．软件复杂性度量的原则
软件复杂性的度量，的一些基本原则：
1）软件的复杂性与其规模的关系不是线性的；
2）数据结构复杂的程序较复杂；
3）控制结构复杂的程序较复杂；
4）转向语句使用不当的程序较复杂；
5）循环结构比选择结构复杂、选择结构比顺
序结构复杂；
6）语句、数据、子程序模块等出现的顺序对
复杂性有影响；
 2．软件复杂性度量的原则
7）非局部变量较多的程序较复杂；
8）参数按地址调用（Call by reference）比按值
调用（Call by value）复杂；
9）函数副作用比显式参数传递难理解；
10）作用不同的变量同名时较难理解；
11）模块、过程间联系密切的程序较复杂；
12）程序嵌套层数越多越复杂。
以上这些基本原则是指导我们进一步研究定量度
量软件复杂性的基础。
 2.4.2 McCabe度量模型
 1976年，McCabe提出了基于程序拓扑结构
的软件复杂性度量模型。该方法是把程序流
程图转化为程序图：即把程序看成是有一个
入口结点和一个出口结点的有向图，图中每
个结点对应一个语句、一个简单判断或一个
顺序流程的代码块，原来程序流程图中的箭
头变成连接各结点的有向弧（或称为边）。
一般地，可以假设从程序图中的开始结点可
以到达图中的任一结点，而从图中的任一结
点都可以到达出口结点。程序图又称为程序
控制结构图或程序流图。
 2.4.2 McCabe度量模型
McCabe给出了程序控制结构图G的巡回秩数V（G）
作为程序控制结构复杂性的度量，其度量模型为：
V（G）= E – N + 2 （2-22）
其中：E —— 程序图G中边的总数；
N —— 程序图中结点的总数。
V（G）又称为图G的环形复杂度。
可以证明，V（G）的值等于结构图中有界和无界
的封闭区域的个数。
（a）顺序结构
R1 V（G）= E – N + 2 = 1 – 2 + 2 = 1

（b）选择结构
R2
R1 V（G）= E – N + 2 = 4 – 4 + 2 = 2

（c）while结构
R1 R2
V（G）= E – N + 2 = 3 – 3 + 2 = 2

（d）until 结构
R1 R2
V（G）= E – N + 2 = 3 – 3 + 2 = 2

图2-4-1 三种基本结构的程序图
 2.4.2 McCabe度量模型
程序结构的复杂性度量值V（G）取决于程
序控制流的复杂程度。当程序内的分支数和
循环数增加时，V（G）值将随之增加，即
程序的复杂性增大。
McCabe研究大量程序后指出，V（G）可作
为程序规模的定量指标，V（G）值越高的
程序往往是越复杂、越容易出问题的程序。
McCabe建议模块规模应满足：V（G）≤10
 【例2.5】程序流程图如图2-4-2所示，
试求出其巡回秩数V（G）
解：（1）画出程序流程图对应的程序图。
开始
图2-4-2 程序流程图 图2-4-3 程序图 a
a 1
b b
2 7
c f R4
c R2 f
d e g 3 4 8
d R1 e g
h
10
6 9 R3
5
i
11 h
结束 i
 【例2.5】程序流程图如图2-4-2所示，
试求出其巡回秩数V（G）

（2）由程序图（或流图）可得： a
V（G）= E – N + 2 = 11 – 9 +2 = 4 1
b
（3）由程序图可以看出，其有界 2 7
R4
区域有R1、R2、R3共3个， c R2 f
3 4 8
还有1个无界区域R4，共4个 g
d R1 e
封闭区域，所以： 10
6 9 R3
V（G）= 4 5
11 h
i
 2.4.3 Halstead度量模型
20世纪70年代初，Halstead给出了称为文本复杂性
度量的模型。它是根据统计程序中的操作符和操作
数的个数来度量程序的复杂程度。程序可以看成是
由操作符和操作数组成的符号序列。操作符是指程
序中出现的语法符号，如+、–、if-then-else、while
等。操作数是操作对象，如程序中定义或使用的变
量、常量、数组、指针等。
令：N1为程序中操作符出现的总个数，
N2为程序中操作数出现的总个数。
则程序的语言符号长度N定义为：N = N1 + N2。
 2.4.3 Halstead度量模型
如果已经测得程序中不同操作符的个数n1和不同操
作数的个数n2，则程序的长度N可用下式来估算：
N ≈ n1 log2 n1+n2 log2 n2 （2-23）
Halstead用下式来定义程序量（即程序在词汇上的
复杂性）：

V = N log 2（ n1 + n2 ） （2-24）
Halstead还给出了预测错误数的公式如下：
E = N log 2（ n1 +n2 ）/ 3000 （2-25）
 2.4.3 Halstead度量模型

可以对多个某种程序设计语言的程序进
行统计分析，从而得出每千代码行
（KLOC）或每个功能点（FP）所包含
的操作符和操作数个数CL或CF，于是，
可以将程序语言符号长度N折合成相应的
代码行数或功能点数。
课程名称：软件工程 第6讲
班 级：
日 期：
教 室：
教学题目：2.5 软件可靠性度量
教学目的：了解可靠性的概念、理解可靠性估算
方法。
教学重点：可靠性的概念、估算方法。
教学难点：可靠性的概念、估算方法。
教 具：多媒体教室、电子教案
作 业：
 2.5 软件可靠性度量
2.5.1 软件可靠性的有关概念

1．软件可靠性
由于大型软件投入使用后还是要残留一
定数量的错误。于是，当某些操作或输
入数据导致遇到这些错误时，就会使程
序失效，从而出现软件故障。
软件可靠性定义为在某个给定时间间隔
内，程序按照规格说明成功运行的概率。
 1．软件可靠性
令：随机变量 t 表示发生故障的时刻，t∈[0，∞]；
函数f（t）为随机变量t 的概率密度函数，
F（t）表示分布函数；
P（0 ≤ t ≤ t1）表示从初始时刻到t1时刻程序
发生故障的概率。
设：初始时刻程序运行正常，即F（0）= 0。于是有：
t
F（t）= ∫ f（x）dx
0 （2-26）
d F（t）
f（t） = （2-27）
dt
令：Pf（t1）表示从0到t1时刻程序发生故障的概率，有：
Pf（t1）= P（0 ≤ t ≤ t1）= F（t1）– F（0）= F（t1）
如果在[0，t]区间程序成功运行的概率为Ps（t）、发
生故障的概率为Pf（t），则有：
Ps（t）+ Pf（t）= 1
Ps （t）就是可靠性，一般标记为R（t）。由以上几个
式子可导出：
t
R（t）= 1–Pf（t）=1– F（t）= 1 –∫f（x）dx
0
（2-28）
上式说明，当软件残留的错误数一定时，程序运行
的时间越长，发生故障的次数越多，软件的可靠性越
小。
 下面引入故障率函数Z（t），以比较一个程序在不同
时期、或不同程序在同一时期的可靠性。设系统一直
成功运行至时刻t，t∈[t1，t1+△t]，P（t1≤t≤t1+△t，t
＞t1 ）是系统在[t1 ，t1+△t]时间间隔且t＞t1 时发生故
障的概率。故障率函数Z（t1）的值定义为：

Z（t1）= lim P（t1≤t≤t1+△t，t＞t1）/ △t （2-29）

可以证明：
1 d F（t）
Z（t）= · （2-30）
R（t） d（t）
对式（2-28）的两端对时间t求导得：
dF（t）/dt = – dR（t）/d t，代入上式，得：
d R（t）= – Z（t）d t （2-31）
R（t）
对上式两端积分，利用初始条件R（0）= 1，可得：
t
R（t）=exp [ –∫Z（x）dx]
0 （2-32）
上式即为可靠性和故障率的基本方程式。据此可以
导出几个 常用的故障模型：
1）Z（t）= λ，其中λ是常数。将λ代入式（2-32），可
得：
R（t）= e –λt （2-33）
上式称为故障率为常数的可靠性模型。由于故障率
是常数，可靠性将随着时间t的增加呈指数衰减。
2）Z（t）= kt，这里k为常数，t ≥ 0。将kt代入式（2-
32），可得：
R（t）= e – k t 2/2 （2-34）
上式称为故障率是时间的线性函数时的可靠性模
型。即当存在损耗和退化时，故障率将随着时间的
增加而线性增加。该模型一般不适合于软件产品。
需要指出，软件中的错误一般都是人为的设计错
误，其中多数是逻辑错误。随着对软件的测试及修
复，软件系统中的错误会越来越少。因此，实际软
件系统的故障率函数曲线应如图2-5-1所示，即软件
故障率不是常数、也不是线性函数，而是按指数规
律下降。实际的统计结果也说明了这一点。
 Z（t）

O t

图2-5-1 软件系统故障率
 2．软件的有效性及其度量
软件的有效性函数A（t）定义为软件系统在时刻t
按照规格说明成功运行的概率。
可靠性与有效性之间的差别是，可靠性强调软件系
统在0～t这段时间间隔内都有效，而有效性强调软
件系统在时刻t这一时间点有效。
A（200）= 0.93表示假设有100个相同的系统同时
启动运行，运行到200小时这一时刻，其中有93个
处于正常运行状态，7个出现故障，等待修复。
R（200）= 0.93表示假设有100个相同的系统有93
个无故障运行了200小时，有7个在此期间发生故障。
 2．软件的有效性及其度量

一般来说，对R（200）= 0.93的要求比对A
（200）= 0.93的要求要严格得多。
对于不可修复系统（即不允许程序停止运行的
系统）或没有修复能力的情况：
A（t）= R（t）
对于可修复系统并能及时修复的情况：
A（t）≥R（t）。
 软件稳态有效性的两种度量方法

1）软件系统投入运行后，在一段时间内，可
统计软件系统的故障停机时间tdi和正常运
行时间tuj，则软件系统的稳态有效性为：
A（t）= Tu /（ Tu + Td ） （2-35）
其中：t = Tu + Td，Td = ∑ tdi，Tu = ∑ tuj
 软件稳态有效性的两种度量方法
2）软件系统在稳态运行时，可统计其平均故障间隔时
间MTBF（mean time between failurs，即程序正常
运行时间的平均值）和平均修复时间MTTR（mean
time to repair，即平均停机时间），则软件系统的稳
态有效性为：
A = MTBF/（MTBF + MTTR） （2-36）
采用上述方法，在开发阶段和投入运行后都可以定量
地度量软件系统的有效性和可靠性。
软件系统投入运行的一段时间内，可以用各种输入和
操作来引发程序中残留的错误，经过多次修复后错误
将逐渐减少，有效性和可靠性将不断提高。
 2.5.2 软件可靠性的估算
软件可靠性估算模型大致分为宏观和微观模型两类。
宏观模型是从程序中残留错误数的角度建立模型，
并用统计方法确定模型参数。
而微观模型则以程序的控制结构和语句分析为基础。
下面仅介绍几个典型的宏观模型。
1．残留错误总数的估算模型
对残留错误总数的估算是可靠性估算的基础。
典型的估算模型： 错误植入模型；

分别测试模型。
 1）错误植入模型
Mills首先提出了估算程序中残留错误总数的错误植
入模型。即在进行测试之前，由专人（比如统计人员）
在程序中随机地植入一些错误（称为带有标记的错
误），测试人员测试之后，通过统计测试人员发现的
原有错误和植入错误的比例来估算程序中原有错误总
数。
设：N t — 植入的错误数， n — 测试发现原有的错误数，
n t—发现植入的错误数， ET— 原有的错误总数。
则有： ET/ N t≈ n / n t
于是ET的估算模型为：
ET = N t·n / n t （2-37）
 2）分别测试模型
1973年，Hyman对错误植入模型做了改进，即用甲、
乙两个程序测试员同时对一个程序的两个副本进行
独立测试。
设：ET ——程序中原有的残留错误总数，
E1 ——甲在[0，τ]时间内发现的错误数，
E2 ——乙在[0，τ]时间内发现的错误数，
E0 ——两人在[0，τ]时间内发现的相同的错误
的个数，
则有： ET = E1·E2 / E0 （2-38）

Hyman提出的分别测试模型无论在技术上还是在
经济上都比错误植入模型优越。
 2．软件平均故障间隔时间的估算
软件的平均故障间隔时间MTBF是可靠性度量的一
个重要参数，往往作为一个重要的质量指标由用户
提出来。下面介绍MTBF的估算方法。
1）软件故障率为常数
当软件故障率λ为常数时，假设程序运行H小时，
共发生r次故障，则λ的估算值为：
λ≈r/H
于是有：
MTBF = 1 /λ = H / r （2-39）
 2）软件故障率与程序残留错误数成正比
设：IT — 程序代码长度；
ET — 测试之前程序中残留错误总数；
E c（τ）— [0，τ]区间内改正的错误数；
E r（τ）— 在τ时刻程序中剩余的错误数；

其中τ为调试和排错时间。

于是，剩余的错误数为：

E r（τ）= ET – E c（τ） （2-40）

 2）软件故障率与程序残留错误数成正比

E r（τ）= ET – E c（τ） （2-40）

用IT去除上式的两边，有：
E r（τ）/ IT = ET / IT – E c（τ）/ IT
令：εr（τ）= E r（τ）/ IT ，εT = ET /IT ，
εc（τ）= E c（τ）/ IT ，于是有：
εr（τ）=εT –εc（τ） （2-41）
2）软件故障率与程序残留错误数成正比
由于软件故障率λ=λ（τ）与程序残留错误数成正比，
所以有：
λ= kεr（τ）= k（εT –εc（τ）） （2-42）
其中的比例因子k可通过实验测试和统计的方法
来估算。设进行n次软件排错实验，时间区间为[0，
τj ]，到τj 时刻为止，共排除了E c（τj）个错误，而
在时间区间[0，τj ]内，程序运行了H j小时，出现
了rj个错误，j = 1，2，…，n 。此时k的估计值为：

k =∑
n r j /∑H
n j [εT –εc（τj）] （2-43）

j=1 j=1
 2）软件故障率与程序残留错误数成正比

k = ∑ r j /∑H j [εT –εc（τj）] （2-43）

当n = 1时，
k = r / H[εT –εc（τ）] （2-44 ）
当n = 2时，k =（r1 + r2）/ { H1[εT –εc（τ1）] +
+ H2[εT –εc（τ2）] } （2-45）
k 的 值 估 算 出 来 之 后 ， 即 可 利 用 式 （ 2-42 ） 估 算
MTBF，它是τ的函数。
2）软件故障率与程序残留错误数成正比

对于确定的τ值，λ = kεr（τ）为常数，于是，经
过[0，τ]区间的排错后，软件可靠性估算为：
R（t）= exp [ – kεr（τ）t ]
= exp（ – t /MTBF ） （2-46）
上式中时间参数τ以月计，表示对程序调试和
维护的时间，t ∈ [0，τ]，以小时计，表示程序
运行的时间。式2-46可理解为经过τ个月的调试
后所达到的软件可靠性。
【例2-5】对一个包含10000LOC的程序进行一个月的测
试后，总共改正了15个错误，此时MTBF=10h，又经
过一个月测试后，改正了10个错误，此时MTBF=15h。
试求出：1）测试前程序中的错误总数；2）为做到
MTBF=100h，应进行多长时间的测试？此时程序中
还残留多少个错误？3）分析测试各阶段的可靠性。
解：
1） ∵ λ = kεr（τ），MTBF=1/ λ
E r（τ）= IT εr（τ）= IT/(k · MTBF)
∴ EC（τ）= ET – IT/（k · MTBF）
即： 15 = ET – 10000 / （k · 10）
15 + 10 =ET – 10000 / （k · 15）
解上述方程组，得： ET = 45, k = 100 / 3
2）假设：单位时间内改正错误后剩余的错误数
与改正前错误总数成正比，于是有：
Er（ 1）= k1ET （1）
Er（ 2）= k1 Er（ 1）=k12 ET （2）
∴ Er（ τ）= k1 τ ET （3）
由（1）式，45 –15 = k1×45，得k1=2/3 ，
∴MTBF（ τ）=IT / （k Er（ τ） ）
τ
=IT / （k k1 ET ）
=10000 / [（100 / 3）×（2 / 3） τ ×45）]
= 6.666667 ×（3 / 2） τ （4）
MTBF（ τ）= 6.666667 ×（3 / 2） τ （4）
将已知MTBF(τ) = 100，代入（4）式：
τ
MTBF（ τ）= （20 / 3） ×（3 / 2）
100= （20 / 3） × （3 / 2） τ
（1.5）τ = 15
τ = ln15 / ln1.5
= 6.68（月）
由上面的（3）式，
Er（ τ）= k1 τ ET =(2/3)τ ×45，
将τ=6.68（月）代入，得：
Er（ 6.68）= 45 ×(2/3)6.68 =2.99863≈3（个）
3）分析测试各阶段的可靠性：
MTBF（ τ）（小时）

120 113.9
110 100
100
90 75.9
80 50.6
70
60 37.75
50 22.25
40
30 15
10
20
10

1 2 3 4 5 6 7 8 τ(月)
MTBF与τ的关系曲线
可靠性的公式如下：
R（t）= exp [ – kεr（τ）t ] = exp（ – t /MTBF（ τ ） ）
当 τ= 1（月）时， MTBF（1）=10h，此时的可靠性
公式为： R（t）= exp（ – t /MTBF（1 ） ）
= exp（ – t /10 ）
= e – 0. 1t
当 τ= 6.68（月）时， MTBF（6.68）=100h，则：
R（t）= exp（ – t /MTBF（6.68 ） ）
= exp（ – t /10 0）
= e – 0. 01t
 R（ t）

1
0.9 τ =6.68月，R（t）= e – 0. 01t
0.8
0.7
0.6
0.5
0.4 τ =1月，R（t）= e – 0. 1t
0.3
0.2
0.1

10 20 30 40 50 60 70 80 t （小时）
测试τ月后的可靠性R（t）曲线
课程名称：软件工程 第7讲
班 级：
日 期：
教 室：
教学题目：2.6 软件开发过程管理
教学目的：了解软件项目管理过程、风险分析、进度安
排、人员的组织与分工等。
教学重点：风险分析、进度安排、人员的组织与分工。
教学难点：风险分析。
教 具：多媒体教室、电子教案
作 业：习题4、5、7、8、9、10
 2.6 软件开发过程的管理
在前几节中介绍了软件度量和估算，这些即是评价软
件的重要依据，也是软件开发过程管理的组成部分和
基础。在本节中将介绍软件项目管理的过程、风险分
析，软件开发计划的进度安排，软件开发人员的组织
与分工等等。

2.6.1 软件开发项目管理过程
为达到软件工程的目标，必须对软件开发项目的工作
范围、所需的工作量和成本、必需的人力和软硬件资
源、可能遇到风险、进度的安排、待实现的任务、经
历的里程碑等进行管理。软件开发过程的管理应在所
有技术工作开始之前启动，直至软件工程过程的结束。
软件开发项目管理过程主要包括以下几个方面：

1．启动一个软件项目
一般情况，软件人员与客户是在可行性研究
阶段确定软件工程项目的范围和目标的。其中，
目标指明了软件开发项目的目的，范围标明了
软件要实现的基本功能，并寻求解决方案。
2．成本估算
在软件项目管理过程中的一个关键活动是制
定项目计划。在制定计划时，必须对项目的规
模、所需的人力等资源、项目的持续时间、工
作量和成本进行估算。
 软件开发项目管理过程主要包括以下几个方面

3．风险分析
开发一个软件项目总存在某些不确定性，即存在
风险。有些风险如果控制得不好，可能导致灾难性
的后果。风险分析实际上就是贯穿于软件工程过程
中的一系列风险管理步骤，包括风险标识、风险估
算、风险评价、风险驾驭和监控。
4．进度安排
首先识别一组项目任务，再确定各任务之间的相互
关联，然后估算各个任务的工作量，制定进度时序，
建立分隔任务的里程碑，确定关键路径，分配人力
和其他资源。
软件开发项目管理过程主要包括以下几个方面
5．追踪和控制
项目管理人员负责追踪和控制在进度安排中
标识的每一个任务。如果任务实际完成日期
滞后于进度安排，则管理员可以使用一种自
动的项目进度安排工具来确定在项目的中间
里程碑上进度误期所带来的影响，并及时采
取措施加以解决。如重新分配资源、对任务
重新安排等等。作为最坏的情况，只好推迟
软件产品的交付日期。
 2.6.2 风险分析
风险的特点：
①具有不确定性，某项风险可能发生也可能不发生；
②一旦某项风险变成了现实，就必然会给项目带来
不良的影响和损失，甚至灾难性后果。
风险分析的四个主要活动：
风险标识；
风险估算；
风险评价；
风险驾驭和监控。
 1．风险标识
风险按影响的范围，可分为三类：
①项目风险是指项目在预算、进度、人力等资源、
客户和需求等方面可能存在的问题。这些问题一旦
发生将对软件开发项目产生不利影响。
②技术风险是指在需求、设计、实现、接口、验证
和维护等方面的潜在问题。如果技术风险发生了，
将直接威胁软件产品的质量和交付日期。
③商业风险是指开发一个没人需要的优质软件产品、
开发一个销售部门不知道如何销售的软件产品、或
开发一个不再符合整体商业策略的产品等等。
 1．风险标识
Boehm建议使用各类风险检测表来标识风险。
在风险检测表中列出所有可能的与每一个风险
因素有关的问题。
包括产品规模风险检测表、商业风险检测表、
客户风险检测表、过程风险检测表、开发环境
风险检测表、技术风险检测表、人员风险检测
表等等。
例如，“人员风险检测表”可如表2-14所示。
在表2-14中，可以根据实际情况选用0、1、
2、3、4、5来回答每一个问题，某个问题取值
越大表示该项风险也越大。人员风险检测表反
映了人的因素可能对软件项目的影响。
 表2-14 人员风险检测表
序 回 答
问 题
号 （0、1、2、3、4、5}
1 开发人员的水平如何？ 2

2 开发人员在技术上是否配套？ 1

3 是否有足够的人员可用？ 0

4 开发人员是否能自始至终参加软件项目的工作？ 2

5 开发人员是否能把全部精力投入到软件开发工作中？ 2

6 开发人员对自己的工作是否有正确的期望？ 1

7 开发人员是否已接受了必要的培训？ 0

8 开发人员的流动是否还能保证工作的连续性？ 3
 2．风险估算——风险预测。
软件项目管理人员主要从影响风险的因素和风险发生
后带来的损失来度量风险。
要对风险进行估算，首先应建立风险度量指标体系、
指明风险带来的影响和损失，确定影响风险的因素，
估计风险出现的可能性或概率，即进行定量的估算。
估算方法如下：
设 ： 某 一 风 险 检 测 表 由 m项 组 成 ， 每 项 可 在 0， 1 ，
2，…，N中根据实际情况选取一个整数值。其中0表
示最好情况，N表示最差情况。
又设：第i 种风险检测表的第j项取值为Xi j，对应的加
权系数为Wi j，则第i种风险的估算值可以定义为：
m
σi = ∑ Wi jXi j /（mN） （2-47）
j=1
 2．风险估算
m
其中：∑ Wi j = m，Wi j ≥ 0
j=1
设：第i种风险对整个项目的风险估算的加权系数
为ρi，i = 1，2，…，l，其中l为风险的种类数，且满
足ρ1 +ρ2 +…+ρl = 1，则整个软件项目的风险估算值R
定义为：
l l m
R = ∑ρiσi = ∑ ρi [∑ Wi jXi j /（mN）] （2-48）
i=1 i=1 j=1
容易验证，0 ≤ R ≤ 1。估算的结果，如果R接近于0，
说明项目风险比较小，如果R接近于1，说明项目风
险比较大。如果ρiσi的值比较大，说明第i类风险出现
的可能性比较大。
 3．风险评价
常采用三元组[ r i，p i，x i ]来描述风险。其中r i代
表第i 种风险，p i表示第i 种风险发生的概率，x i代
表该风险带来的影响，i=1，2，…，l ，表示软件
开发项目共有l 种风险，i 为风险序号。
一个风险评价技术就是定义风险参照水准。对于大
多数软件项目来说，成本、进度、性能就是典型的
风险参照水准。在软件开发过程中由于成本超支、
进度拖延、软件性能下降、支持困难，或它们的某
种组合，都有一个水准。当软件项目的风险的某种
组合达到或超过了一个或多个参照水准时，项目就
应终止。
 3．风险评价

比如，在软件开发的过程中，项目的进度应与
投入的成本相一致，如果投入的成本与进度的
拖延之间超过某一个参照水准时，项目就应该
终止。
图2-6-1给出了这样的参照曲线，当风险的一个
组合所引起的成本超支和进度拖延超过参照水
准而进入图中的封闭区域时，项目将被迫终止。
 3．风险评价

估
参照点（成本，时间）
计
将造成项目终止。
进
度
超
出

估算成本超出

2-6-1 风险参照水准
 3．风险评价
一般来说，参照点不是一条平滑的曲线，而是一个
易变动的区域，在这个区域要做出基于参照值组合
的管理判断往往是不准确的。因此，风险评价过程
可分四步进行：
1）定义项目的风险参照水准；
2）定义每种风险的三元组[ r i，p i，x i ]，并找出
和每个参照水准之间的关系；
3）预测一组参照点以定义一个项目终止区域，
用一条曲线或一些易变动区域来定界；
4）预测各种风险组合的影响是否超出参照水准。
 4．风险驾驭和监控
风险分析的目的是建立处理风险的策略，监控、
驾驭风险。
驾驭风险是利用原型化、软件自动化、可靠性
工程学等技术和软件项目管理方法设法避开或
转移风险。
描述风险的三元组[ r i，p i，x i ]是驾驭风险的
基础。
风险驾驭与监控活动如图2-6-2所示。
 4．风险驾驭和监控

风险1分析数据
风险1 [ r 1，p 1，x 1 ]
风险1驾驭步骤
风险2分析数据
风险驾驭 风险2 [ r 2，p 2，x 2 ]
风险2驾驭步骤
…

风险n分析数据
风险n [ r n，p n，x n ] 风险驾驭和监控计划
风险n驾驭步骤

图2-6-2 风险驾驭和监控
【例2.6】对开发人员的频繁流动这一风险的驾
驭与监控。
设:人员的流动给项目带来的风险为r 1，该风险发生
的概率的估算值p1为70%，而该风险的出现给项目
带来的影响的估算值x1是项目开发时间延长15%，
总成本增加20%。软件项目管理人员可以采取以下
的风险驾驭步骤：
1）项目开始前要控制人员流动的原因，项目开始后
要设法减轻风险的影响；
2）了解开发人员变动的原因，在开发期间对这些原
因加以控制，降低风险发生的概率；
3）采用适当的方法和技术以防止人员流动给项目带
来损失；
4）建立项目组，在开发的过程中应及时公布、交流
项目开发信息；
5）制定文档标准，建立及时生成文档的机制；
6）对工作组织集体评审，使多数人都能了解工作的
细节和按计划进度完成自己的工作；
7）为关键技术培养后备人员。
一个大型软件项目的开发可能存在30～40种风险。
如果每一种风险都有3～7个风险驾驭步骤，则风险
驾驭和监控本身也可能构成一个子项目，所以它也
需要人力、时间和经费。
 4．风险驾驭和监控
为了更好地对风险进行驾驭和监控，应制定详细的
风险驾驭与监控计划（RMMP，Risk Management
and Monitoring Plan），RMMP中给出了风险分析
的全部工作。
风险驾驭与监控计划随着软件项目的开始而开始。
风险驾驭与监控的主要目标有三个：
1）判断一个预测的风险是否已经发生；
2）确保针对每一个风险而制定的风险驾驭步骤正在
合理地实施；
3）收集有关风险分析的所有信息，以备将来使用。
 表2-15 风险驾驭与监控计划目录
1．引言
1.1 本文档的范围和目的
1.2 概述 a.目标 b. 风险转化的优先级
1.3 组织 a. 管理 b. 职责 c. 工作流程
1.4 软件演进过程 a. 进度安排 b. 里程碑和评审 c. 预算
2．风险分析
2.1 风险标识 a. 风险概述及风险源 b. 风险分类
2.2 风险估算 a. 估计风险概率 b. 风险估计的重要性
c. 估计准则 d. 估计误差的来源
2.3 风险评价 a.评价方法 b.评价假设和局限性 c.评价风险参照 d.评价结果
3．风险驾驭与监控
3.1 .建议
3.2 风险转化方案
3.3 控制风险转化的方案
3.4 风险监控过程
4．附录
4.1 软件开发形势的风险估算
4.2 风险减轻或排除计划
 2.6.3 进度安排
进度安排可能是如下两种方式之一：
1）软件产品最终交付日期已经确定，开发方只能根
据最终交付日期安排进度；
2）最后交付日期主要由软件开发方来确定。
软件项目的进度安排的准确程度可能比成本估算的
准确程度更重要，如果进度安排不当会导致客户不
满、丧失市场机会和成本的增加。因此，进度安排
必须解决好以下几个问题。
1．任务、人力、时间等资源的分配应与工程进
度相一致

由于大型软件项目的开发必然是项目管理人员、分
析人员、设计人员等的集体劳动，又是一项复杂的
智力劳动，因此，必须制定合理的进度计划，并根
据计划合理地分配任务、人力、时间等资源。
比如，人力的分配要符合大型软件项目的Rayleigh-
Norden曲线。如果人力分配不合理，比如在设计
高峰投入的程序员不足，拖延了进度，这时临时加
入新的程序员不但不能加快进度，反而会使进度变
得更慢。项目管理人员应努力寻求任务、人力、时
间的最佳组合，以便在满足进度要求的前提下获得
最大的效益。在可能的情况下，适当减少开发人员、
相对延长一些开发时间，也可以取得较大的经济效
益。
 2．任务的分解与并行开发
为了充分发挥开发人员的潜力、缩短工期，软件工
程项目的任务分解与安排应尽力挖掘可并行开发的
部分。
图2-6-3是一个典型项目任务网络图。其中“▲”表
示软件工程过程的里程碑，当软件开发活动到达某
个里程碑时，应当交付包括文档在内的阶段性产品
并要通过评审。软件开发项目的里程碑为管理人员
提供了项目进度的可靠依据。图中给出了各个子任
务间的相互依赖关系。
由图可见，概要设计与软件测试计划工作可以并行
进行，对于各个模块的详细设计、编码、单元测试
等工作和测试过程的设计工作可以并行。
 需求复审 过程设计 编码 单元测试
概要设计复审 设计走查 代码走查
需求分析
验收测试
规格说明 概要设计 集成测试

…
▲ ▲ ▲ ▲
▲ ▲
▲
测试计划 测试过程 测试复审

图2-6-3 软件项目任务分解网络图
 3．工作量的分配

图2-6-4给出了在整个软件项目定义与开发各阶
段一种典型的工作量分布原则，称为40-20-40
分布原则。即：
编码前的工作量约占40%左右；
编码的工作量仅占20%左右；
编码后的工作量约占40%左右。
该原则只能从宏观上作为一个指南，实际工作
量分配的比例必须根据具体项目的类型和特点
来确定。比如，和人命相关的软件项目在测试
阶段的工作量可能达到其余各个阶段的3 ～ 5
倍。
 分析和设计 测试和调试
40%～50% 40%～50%

编码
15%～20%

图2-6-4 软件开发工作量的分布
 3．工作量的分配
在制定进度计划时，可以利用估算模型对工作量做
出估计。如果利用基本CoCoMo模型或其他公式，
可参照表2-16给出的进度分配百分比来安排进度。
可按照表2-16给出的比例进一步确定每一阶段所需
的开发时间。然后，在每一阶段，进行任务分解，
对各个任务再进行工作量和进度的分配。
表2-16 进度分配百分比
需求 编码与
阶段 设计 组装与测试
分析 单元测试
占开发时
10～30 17～27 25～60 16～28
间百分比
 3．工作量的分配
由于待开发软件的类型不同，规模不同，
所需的开发工作量和进度也不同。利用
基本CoCoMo模型，可以给出较为准确
的进度安排，如表2-17所示。
如果要进一步缩短开发时间、保证开发
进度，就必须考虑影响工作量的各个因
素，按照可减小工作量的因素取值，并
利用中间或详细CoCoMo模型给出比较
精确的工作量的分配和进度安排。
 表2-17 较精确的进度分配表
规模（KLOC）
项目 微型 小型 中型 大型 特大型
进度分配
类型 <2 8 32 128 512
阶段
计划与需求 10 11 12 17
组
设计 19 19 19 19
织 63 59 55 51
编码与单元测试
型 18 22 26 30
组装与测试
半 计划与需求 16 18 20 22 24
独 设计 24 25 26 27 28
立 编码与单元测试 56 52 48 44 40
型 组装与测试 20 23 26 29 32
计划与需求 24 28 32 36 40
嵌
设计 30 32 34 36 38
入 48 44 40 36 32
编码与单元测试
型 22 24 26 28 30
组装与测试
 4．具体进度安排
目前，软件项目的进度安排的两种比较常用的
方法是程序评估与审查技术（PERT）和关键
路径法（CPM），这两种方法都生成描述项目
进展状态的任务网络图。
图2-6-5给出了用MacProjectⅡ软件工具生成的
项目进度安排图的一部分。图中：
方框——子任务；
带圆角的方框——里程碑；
框左上方的日期——子任务的开始时间；
框左下角的数字——完成本子任务所需的天数
 4．具体进度安排
5 / 18 / 96 5 / 24 / 96 5 / 28 / 96 5 / 28 / 96 5 / 29 / 96
控制模块 控制模块 控制模块 控制模块
走查与迭代
过程设计 编码 代码走查 单元测试
4 2 1 0 1
5 / 18 / 96 5 / 22 / 96 5 / 27 / 96 5 / 28 / 96 5 / 28 / 96 5 / 29 / 96 5 / 31 / 96
计算模块 过程设计 计算模块 计算模块 计算模块 开始
走查与迭代
过程设计 完成 编码 代码走查 单元测试 集成测试
2 1 0 1 0 1 0
5 / 18 / 96 5 / 25 / 96 5 / 28 / 96 5 / 29 / 96 5 / 29 / 96
界面模块 界面模块 界面模块 界面模块
走查与迭代
过程设计 编码 代码走查 单元测试

…
…

…
…

5 1 2 0 2
5 / 15 / 96 5 / 29 / 96
基于设计启 单元测试
动测试过程 结果复审
6 2

图2-6-5 软件项目进度安排网络图（部分）
 4．具体进度安排

PERT和CPM方法为软件项目规划人员提供了
定量描述工具，具体有：
1）用经验模型估算完成每个子任务所需的工作
量和时间；
2）确定关键路径。完成关键路径上的所有任务
所需时间为项目开发所需的最短时间；
3）确定各子任务的时间窗口，即确定各子任务
的最早启动时间和最迟启动时间。
 4．具体进度安排
某子任务的最早启动时间是指该子任务的所有
各前导子任务完成的最早时间；
该子任务的最早启动时间与完成该子任务所需
时间之和就是该子任务的最早结束时间。
而某个子任务的最迟启动时间是指在保证项目
按时完成的前提下最晚启动该子任务的时间；
最迟启动时间与完成该子任务所需时间之和就
是该子任务的最迟结束时间。
在制定进度计划时，应首先找到影响进度的关
键路径，并在关键路径上安排一定的节假日和
机动时间，以便应付可能出现的问题和难点。
 2.6.4 软件质量保证
1．软件质量保证活动的内容
为了开发出高质量的软件，达到软件工程的
目标，必须有计划地、系统地进行软件质量保
证（SQA，Software Quality Assurance）活动。
SQA活动主要包括以下内容：
1）在需求分析阶段提出对软件质量的需求，并
将其自顶向下逐步分解为可以度量和控制的质
量要素，为软件开发、维护各阶段软件质量的
定性分析和定量度量打下基础；
2）研究并选用软件开发方法和工具；
 1．软件质量保证活动的内容
3）对软件生存周期各阶段进行正式的技术评审
（FTR）；
4）制定并实施软件测试策略和测试计划；
5）及时生成软件文档并进行其版本控制；
6）保证软件开发过程与选用的软件开发标准相一致；
7）建立软件质量要素的度量机制；
8）记录SQA的各项活动，并生成各种SQA报告。
这里仅介绍软件工程的正式技术评审，其他内容
在本书的其他章节中介绍。
 2．软件工程的正式技术评审
1）FTR的作用
①FTR是保证软件质量的重要措施。
由于开发者在软件生存周期各个阶段的工作都可
能产生错误。错误将随着工作的进展而具有一种积
累和放大效应，如图2-6-6所示。所以，在每一个阶
段结束时，都要进行正式的技术评审，以便及时发
现并消除阶段性产品中的错误或缺陷，从而可以保
证软件质量。
②正式的技术评审是降低软件成本的重要措施。
软件开发实践表明，后期改正一个错误要比早期
改正同一个错误需要付出的成本和代价高出二到三
个数量级，错误发现得越早，越易改正，损失越少。
 原始需求

需求分析 正确的规格说明 错误的规格说明

设 计 正确的设计 错误的设计 对错误说明的设计

编 码 正确编码 错误编码 对错误设计的编码 对错误说明的编码

测 试 正确功能 可改正的错误 不可改正的错误 潜伏的错误

不完善的软件产品

图2-6-6 软件错误的积累和放大效应
 2．软件工程的正式技术评审

2）正式的技术评审的组织和过程
FTR采用正式会议的方式。通常的做法是成
立一个由3~5人组成的技术评审小组，他们是
熟悉软件项目且水平较高的技术人员、管理人
员。其中由组长1人、设计者1人、评审员1~3
人组成，1人兼做记录员。组长的任务是组织
和领导评审过程的工作。设计者的任务是负责
回答技术上的问题，评审员的任务是合理、公
证地评论工程中的技术问题。
 2．软件工程的正式技术评审

2）正式的技术评审的组织和过程
FTR的过程一般由6个步骤组成：
①制定评审计划，即安排好评审会议日程。
②介绍工程情况。
设计者应向评审小组提供有关阶段产品的各种
文档，其中包括软件质量要素的度量数据及软
件质量的阶段性追踪报告；并应从技术角度简
要地介绍软件阶段性产品和文档资料的概况，
且仅介绍基本事实，讲清做了什么，如何做的，
不要介绍做法的理由，避免产生误导。
 2）正式的技术评审的组织和过程
③准备工作。评审小组成员自己审阅文档资料，并把
发现的问题和错误记录下来，以备在评审会议上讨
论。
④正式召开评审会议。评审会议由组长主持，评审小
组人员参加，记录员记录。评审人员根据事先准备
的有关设计指标完成情况、工程达到的技术水平等
问题和发现的错误提问，设计者回答。评审只针对
产品而不针对具体人员、只指出问题而不讨论如何
解决问题，并要避免无休止的争论。评审会议一般
不超过2小时。会议结束时，必须对参评产品是否
通过评审明确表态，并通过评审报告。报告内容有：
会议的主持人和参加人、评审的产品及内容、发现
的问题及评审结论等。
 2）正式的技术评审的组织和过程

⑤工程返工。由评审组长召开由设计者集体参加的讨
论会，讨论FTR会议的评审结论，分析产生问题和
错误的原因，限期解决或改正。
⑥工程复审。当工程中的问题和错误由设计者解决或
改正后，由评审组长再次召开评审会议，对返工的
结果进行复审，如此反复、直至通过复审为止。
需要指出，对于大型、复杂、重要的软件工程项
目，在正式的技术评审之后，还要进行管理复审。
管理复审是对软件工程进行管理和控制的重要手段，
它可以及时发现工程中的问题，采取措施加以解决。
如果发现工程项目不划算继续开发时，应决策停止
开发，以避免造成更大的损失。
2.6.5 软件项目组织的建立与人员分工
1．组织原则
建立一个好的软件项目组织是保证软件开发
能够顺利进行的必要条件之一。在建立软件
开发组织的时候要注意的原则是：
①尽早落实责任。特别是项目负责人的责任；
②减少接口。组织应该有良好的组织结构、合
理的人员分工，以减少不必要的通信；
③责权均衡。指软件经理的责任不应比赋予他
的权力还大。
 2．组织结构的模式— 常采用的3种
1）按课题划分的模式（Project Format）
将软件人员按照项目（课题）组成小组，小组成员
始终参加所承担课题的各项任务，即参加软件产品
的定义、设计、编码、测试、评审、文档编制、直
到维护的全过程。
2）按职能划分的模式（Functional Format）
将人员按照软件生存周期各个阶段划分成若干个
专业小组。比如分别建立计划组、需求分析组、设
计组、实现组、测试组、维护组、质量保证组等等。
优点：便于熟悉本组的工作。
缺点：各个小组之间通信频繁。
 2．组织结构的模式— 常采用的3种
3）矩阵模式（Matrix Format）
这种模式是以上2种模式的组合。一方面，按
工作性质成立一些专门组，如开发组、业务组、
测试组、维护组等；另一方面，每个项目都指
派一个项目经理负责管理。于是，每个软件人
员即属于某一个专门组，又参加某一个项目的
工作。因此，他要接受专门组和项目经理的双
重领导。
优点：专门组内的成员可互相交流在各自参加
的项目中取得的经验教训，从而有利于发挥专
业人员的作用；而每个项目又有专人负责管理，
有利于项目完成。
 3．程序设计小组的组织形式
程序设计小组的组织和小组内部人员的组织形式对生
产率都会产生影响。常采用的组织形式有主程序员制
小组、民主制小组、层次式小组3种。
1）主程序员制小组（Chief Programmer Team）
小组由1位主程序员（高级工程师）、2 ~ 5位程序员
（技术员）、1位后援工程师组成，还可以配备辅助
人员（如资料员）。主程序员是小组的领导和核心，
他负责小组全部技术活动的计划、协调与管理、关键
技术、评审等工作。程序员负责项目的开发、文档资
料的编写等具体工作。后援工程师协助和支持主程序
员的工作，也做部分具体工作，必要时代替主程序员
的工作。
 主程序员

后援 程序员 资料员
工程师

（a）主程序员制小组
这种组织形式强调主程序员与其他程序员的直接联
系，从而简化了程序员之间的通信。而工作效果的
好坏主要取决于主程序员的技术水平和管理才能。
 2）民主制小组（Democratic Team）
虽然也设置一位组长，但是每当遇到问题时，组内的成
员可以进行民主协商，以平等的地位交换意见。工作目
标的制定、做出决定都有全体组员参加，即强调发挥小
组每一个成员的积极、主动性和协作精神。
优点：集思广益、取长补短，适于时间长难度大的项目；
缺点：削弱了个人的责任心、并使开发效率有所降低。

（b）民主制小组
 3）层次式小组（Hierarchical Team）

如图（c）所示，即将组内人员分为3级：
组长1人：他作为项目负责人负责全组工作；他直
接领导2 ~ 7名高级程序员；
高级程序员：通过基层小组管理若干名程序员。
层次式小组比较适合于这种本身就是层次结构状的
课题或大型软件项目。此时可以按照组织形式划分
课题，然后把子项目分配给各个基层小组去完成。
 3）层次式小组

项目负责人
高级程序员

若干程序员 若干程序员
（c）层次式小组
软件开发小组的组织形式应根据实际问题的特点进
行调整，软件开发小组内部和小组之间应经常交流
情况和信息，以减少误解，消除软件中的个人特征，
从而有利于软件质量的提高。
 4．人员配备
 实践表明，软件开发各个阶段所需要的技术人员的
类型、层次和数量是不同的。
在软件项目的计划和分析阶段，只需要少数人，主
要是系统分析员、从事软件系统论证和概要设计的
软件高级工程师和项目高级管理人员，人数虽不多，
但都是高层次人员。
概要设计阶段要增加几个高级程序员。
详细设计阶段要增加软件工程师和程序员。
在编码和测试阶段还要增加初级程序员和软件测试
员。在这一过程中，各类专门人员和管理人员也在
逐渐增加。
到验收测试时，维护人员也加入其中，使各类人员
的数量达到了最高峰。
 4．人员配备
在软件产品交付使用的初期，参加软件维护的人员较
多，此时为防止给维护活动带来困难，不应过早地解
散软件开发人员。软件经过一段时间的纠错性维护后，
出错率会明显减少，这时可以逐步撤出软件开发人员，
之后，软件维护人员也逐步撤离。
 按照上述方法安排人力资源符合Rayleigh-Norden曲
线，即符合软件工程项目工作量的分布，是比较合理
的。
 根据Putnam给出的开发工作量与开发时间的4次方成
反比的规律，可以得出软件开发人员与开发时间的折
衷定律：在时间允许的条件下，通过适当减少开发人
员就会提高工作效率，大大降低成本。
 实践表明，向一个已经延期的软件项目追加新的开发
人员，可能使项目完成得更晚。
 1）配备人员的3个主要原则
①重质量：软件项目开发是一种高智力、高技术型的
工作，使用少量有实践经验、素质高、有
能力的人员去完成关键性任务，常常比使
用较多的经验不足的人员更有效。
②重培训：花力气培养所需的技术和管理人员
是解决人员问题的有效方法。
③双阶梯提升：人员要么按照技术职务提升，要么按
照管理职务提升，两者不应兼得。
 2）对项目经理人员的要求

对项目经理除了管理能力外，还要求应具有的能力：
①把用户提出的非技术性要求加以整理提炼，
以技术说明书形式转告给分析员和测试员。
②能说服用户放弃那些不切实际的要求，以保
证合理的要求得以满足。
③具有综合问题的能力。
④具有很强的沟通能力。
 3）评价人员的标准
需要确定正确的人员评价标准并采用较好的方法了解
和评价开发人员的素质、管理能力和技术水平。
一个好的开发人员应具备的素质和能力有：
①善于与周围人员团结协作，建立良好的人际
关系，善于听取别人的意见。
②牢固掌握计算机软件的基本知识和技能。
③善于分析和综合问题，具有严密的逻辑思维能力。
④工作踏实、细致，遵循标准和规范，不靠碰
运气，具有严格的科学作风。
⑤工作中表现有责任心、有毅力、有耐心。
⑥具有良好的书面和口头表达能力。
2.6.6 软件项目的跟踪与控制
软件项目管理的重要任务是对正在开发的软件
项目进行跟踪和控制，以便及时发现和处理问
题，使开发人员能够按计划和要求有条不紊地
工作。
项目管理人员经常采用的跟踪方式主要有：
①定期召开项目工作会议，让每个项目成员汇
报任务进展情况和存在的问题。
②在软件开发过程中，请专家和用户按照里程
碑对阶段性成果进行管理复审，判定实际开发
进度是否与计划中定义的里程碑保持一致。
 2.6.6 软件项目的跟踪与控制
③对照进度计划检查各子任务的实际开始时间是
否与计划的开始时间一致。

④及时了解项目开发人员的进展情况及存在的主
要问题。

如果在跟踪的过程中发现了问题，比如，关
键路径上的某个子任务拖后了，管理人员应迅
速查明原因，及时采取措施尽早解决。比如，
利用机动时间或节假日加班等方法赶上进度。
 2.6.7 软件开发标准
软件开发的标准化有利于提高软件的一致性、完整
性、可理解性，有助于提高软件的质量。
目前我国颁布的部分软件开发标准有：
1.《计算机软件开发规范 GB 8566-88》；
2.《计算机软件产品开发文件编制指南 GB 8567-88》；
3.《计算机软件需求说明编制指南 GB 9385-88》；
4.《计算机软件测试文件编制规范 GB 9386-88》；
5.《计算机软件质量保证计划规范 GB/T 12504-90》；
6.《计算机软件配置管理计划规范 GB/T 12505-90》。
 2.6.7 软件开发标准
国外的部分软件工程标准有：
1．《软件工程术语标准词汇 IEEE Std 729-1983》；
2．《软件质量保证计划标准 IEEE Std 730-1984》；
3．《软件配置管理计划标准 IEEE Std 828-1983》；
4．《软件测试文档标准 IEEE Std 829-1983》；
5．《软件需求规格说明指南 IEEE Std 830-1983》；
6．《军用软件开发标准 DOD Std 1679A（Navy）》。
7．《质量管理体系标准 ISO9000系列标准》
 2.6.7 软件开发标准
其中：
IEEE—Institute of Electrical and Electronics Engineers，
指（美国）电气和电子工程师协会；
DOD—Department of Defense，
指（美国）国防部。
Navy—海军部；
ISO—International Standards Organization，
指国际标准化组织。
 软件项目管理的CASE工具
 软件项目管理的CASE工具十分丰富，主要有：
正文/表格/图形编辑工具；
工作量和成本估算工具；
制定工程计划工具、制定项目进度工具、软件质量、
复杂性、可靠性度量工具；
配置管理工具；
报告生成工具等等。
 这些工具应该有统一的界面，并应按照一定规则访问
软件工程信息库中的软件项目信息（包括：项目合同、
工程计划、工程进度表、人员组织与分工、开发各阶
段的产品及评审文件、相关的软件文档标准等等）。
 习题思考题

2.4 、2.5、 2.7、 2.8、 2.9、 2.10

2.4 已知有一个国外典型的软件项目的记录，开发人员
M=3人，其代码行数=12.1KLOC，工作量E=24PM，
成本S=168000美元，错误数N=29，文档页数Pd=365
页。试计算开发该软件项目的生产率P、平均成本C、
代码出错率EQR和文档率D。
解： 1．软件开发的生产率P为：
P = L / E = 12.1×103LOC / 24PM = 504 LOC/PM
2．开发每行代码的平均成本C为：
C = S / L = 168000美元 / 12100LOC=13.9美元/LOC
3．代码出错率EQR为：
EQR = N / L = 29个/12.1KLOC=2.4个/KLOC
4．软件的文档率D为：
D = Pd / L = 365页 / 12.1KLOC = 30页/ KLOC
2.5 已知某软件项目的特征为：用户输入数为30，用户
输出数为60，用户查询数为24，共有8个文件，有2个
外部界面。如果每个信息量的加权因子都取“一般”
值，所有的技术复杂性调节因子都取“普通”值，用
Albrecht方法计算该软件项目的功能点。
解：基本功能点CT为：
CT =用户输入数× 4+用户输出数×5+
+用户查询数×4+文件数×10+外部接口数×7
=30×4+60×5+24×4+8×10+2×7
=610 14
FP = CT×TCF = CT [0.65 + 0.01∑F i ]
i=1
= 610 × [0.65 + 0.01 ×3 ×14]
= 652.7功能点
答：该软件项目共有652.7功能点。
2.7 根据Putnam模型，Et d4 = 常数，其中E为工
作量（人年），t d为开发时间（年）。如果将
开发时间减少到原计划的50%，其工作量将增
加多少倍？
解：根据Putnam估算模型L = Ck E1/3 td 4/3 可
得：
E = L3 / (Ck3 td4)
于是工作量增加的倍数K为：
L3/ [ Ck3(0.5t d ) 4 ]
K= = 1 / 0.5 4 = 16
L3 / [ Ck3 ( t d ) 4 ]
答：工作量将增加16倍。
2.8 如图1所示的程序流程图，试计算其巡回秩数V(G)。
解：由程序流程图画流图如下： 开始
a a
1 R5
2 b b
3 R4 c f
c R1 8 f d e g h
4 5 9
R2 R3
d e g h
10 i
6 7 11 12
i j
13 结束
j
图1 程序流程图
（1）V（G）=E –N +2=13 –10 +2=5
（2）V（G）=封闭区域个数=5
（3）V（G）=谓词结点个数+1=4+1=5
2.9 甲乙两名程序测试员同时对一个程序进行独立测试
一个月，甲发现并改正了24个错误；乙发现并改正了
20个错误，其中有10个错误甲也发现了。试估算该程
序经过甲乙两人这一个月测试后，还残留多少个错误？
解：由题意知，E 1 = 24， E 2 = 20，E 0 = 10，该程序所
含错误总数可估算如下：
ET=E1×E 2 / E 0 = 24 ×20 / 10 = 48（个）
经过一个月的测试，该程序还残留的错误数为：
E r（τ）= ET – EC（ τ）
= ET –（E 1+E 2 –E 0）
=48 –（24+20-10）
=14
答：还残留14个错误