第三章 软件项目管理 项目管理的概念 软件项目度量 软件项目计划与估算 风险分析和管理 项目进度安排 软件质量保证 软件配置管理

项目管理的谱系

人员管理 产品管理 项目管理过程管理

软件项目管理

项目参与者

项目负责人

软件项目组

协调通信问题

软件范围

问题分解

确定软件过程模型

过程分解

确定危险信息

确定解决方案

软件项目管理的目的、任务和内容目的 为了使软件项目能够在预定成本、进度、质

量的前提下顺利完成，必须对软件工程项目进行计划、组织、监控和管理

任务 制定软件项目的实施计划和方案； 对人员进行组织和分工； 按照计划进度，以及成本管理、风险管理、质

量管理的要求进行软件开发，完成软件项目的各项要求和任务。

3.1.1 软件度量

软件度量的概念软件度量的概念 软件规模度量软件规模度量 软件功能度量软件功能度量

3.1 软件项目度量

软件度量分类

3.1.1.1 度量、估算 度量 metrics

度量具有数字特征，软件工程范围的度量是软件开发过程、软件资源或软件产品简单属性的定量描述。

如，程序规模、操作符个数、程序中错误的个数等。

估算 estimation对软件产品、过程、资源进行预测估算可以采用经验公式、或参考历史资料估算用于事前签订合同、立项、制定工作计划等

软件的外部属性和内部属性 外部属性 软件产品、过程、资源与环境的关系如，成本、效益、劳动生产率、可靠性、可

维护性 内部属性 软件产品、过程、资源、环境自身的属性如，产品结构、模块化程度、复杂性、程序

长度等。

产品 - 过程 - 资源

产品的内部属性程序代码长度 程序功能 模块化 重用性控制流 数据流 模块耦合度与内聚度

产品的外部属性程序的可靠性 可用性 可维护性软件的可理解性 有效性 可移植性

过程的内部属性 工作量 计划和进度 一段时间内某类事件发生的次数

过程的外部属性 成本 可控制性 可观察性 稳定性

资源的内部属性 人 软硬件环境 方法 经验

资源的外部属性 成本 时间

3.1.1.2 面向规模的度量 代码行数 LOC或 KLOC 生产率 Pl=L/E 其中 L 软件项目代码行数 E 软件项目工作量（人月 PM） Pl 软件项目生产率（ LOC/PM） 代码出错率 EQRl=Ne/L 其中 Ne 软件项目的代码错误数 EQRl 每千行代码的错误数

每行代码平均成本 Cl=S/L

其中 S 软件项目总开销（元／美元） Cl 软件项目每行代码的平均成本

文档与代码比 Dl=Pd/L

其中 Pd 软件项目文档页数 Dl 每千行代码的平均文档数

例 软件项目记录

项目 工作量 PM

成本万美元

代码行kLOC

文档页数 Pd

错误数 Ne

人数 M

Aaa

-01 24 16.8 12.1 365 29 3

Ccc

-04 62 44.0 27.2 1224 86 5

Fff

-03 43 31.4 20.2 1050 64 6

生产率： Pl=L/E=12.1kLoc/24PM=504Loc/PM

出错率： EQRl=Ne/L=29 个 /12.1kLoc=2.4个 /kLoc

平均成本：Cl=S/L =168 000 美元 /12.1kLoc= 13.88 美

元 /Loc

每千行代码的平均文档页数：Dl=Pd/L=365Pd/ 12.1kLoc=30.16Pd/kLoc

规模度量的优缺点用软件代码行数估算软件规模简单易行。缺点 代码行数的估算依赖于程序设计语言的功能和表

达能力； 采用代码行估算方法会对设计精巧的软件项目产

生不利的影响； 在软件项目开发前或开发初期估算它的代码行数

十分困难； 代码行估算只适用于过程式程序设计语言，对非

过程式的程序设计语言不太适用等等。

根据事务信息处理程序的基本功能定义的，在系统设计初期可以估算出软件项目的规模

FP=CT*［ 0.65+0.01*∑Fi ］其中： CT 按表 3.1 计算 ()

Fi 是复杂性调节值 Fi 取值 0,1,...,5

当 Fi = 0 时，表示 Fi 不起作用 Fi = 5 时，表示 Fi 作用最大

3.1.1.3 面向功能的度量

表 3.1 功能点度量

测量参数 值 权值用户输入数 □ *4 ＝ □用户输出数 □ *5 ＝ □用户查询数 □ *4 ＝ □文件数 □ *7 ＝ □外部界面数 □ *7 ＝ □CT ＝ □

表 3.1 中的五个信息量按下列方式取值

用户输入数 用户为软件提供的输入参数个数用户输出数 软件系统为用户提供的输出参数个数用户查询数 一个联机输入确定一次查询，软件以 联机输出的形式 ,实时地产生一个响应文件数 统计逻辑的主文件个数外部界面数 统计所有机器可读的界面，利用这些 界面可以将信息从一个系统传送到另一

个系统

用功能点定义相应的概念 生产率： Pf=FP/E 其中 Pf 表示每人月完成的功能点数 平均成本：

Ci=S/FP 其中 Ci 表示每功能点的平均成本 文档与功能点比：

Di=Pd/FP 其中 Di 表示每个功能点平均具有的文档页数

代码出错率：EORi=Ne/FP

其中 EORi 表示每个功能点的平均错误个数

面向功能的度量 软件规模的功能点度量没有直接涉及软件系统本身

的算法复杂性。 1986年 Jones把软件项目中的算法复杂性因素引入到功 能 点 计 算 中来， 为 了避免混淆，我们把Albrecht 定义的功能点称为简单功能点，用 FPs 表示，把 Jones推广的功能点称为功能点，用 FP 表示。

推广的功能点包括计算机程序中用于各类问题求解的算法因素，如求解线性代数方程组、遍历二叉树的各个结点、处理中断等等。

功能点计算仍用上面的公式 , 其中 CT 按表 3.2 计算。

表 3.2 推广的功能点度量 测量参数 值 权值用户输入数 □ *4 ＝ □用户输出数 □ *5 ＝ □用户查询数 □ *4 ＝ □文件数 □ *7 ＝ □外部界面数 □ *7 ＝ □算法 □ *3 ＝ □CT ＝ □ 对一般的工程计算或事务处理软件，用表 3.1 和表 3.2两种方法计算出来的 FP值应该基本上相同

对于比较复杂的软件系统 FP比 FPs 的值高 20%～ 35%

面向功能的度量的优缺点优点①与程序设计语言无关，它不仅适用于过程式

语言，也适用于非过程式的语言；②软件项目开发初期就能基本上确定系统的输入、输出等参数，功能点度量能用于软件项目的开发初期。

缺点①它涉及到的主观因素比较多，如各种权函数

的取值；②信息领域中的某些数据有时不容易采集；③FP 的值没有直观的物理意义。

3.1.1.4 代码行度量与功能点度量的比较

代码行度量依赖于程序设计语言，而功能点度量不依赖于程序设计语言。

Albrecht 和 Jones 等人对若干软件采用事后处理的方式分别统计出不同程序设计语言每个功能点与代码行数的关系，用 LOC/FP 的平均值表示。

表 3.3 表明，一行 Ada 语言代码的“功能”平均是一行 FORTRAN 语言代码“功能”的 1.4倍。一行四代语言代码的“功能”平均是一行传统程序设计语言代码“功能”的 3至 5倍。

表 3.3 各种语言的 LOC/FP( 平均值 )

程序设计语言 LOC/FP( 平均值 )汇编语言 300COBOL 100FORTRAN 100Pascal 90Ada 70面向对象的语言 30四代语言 (4GL) 20代码生成器 15 

3.1.2 软件复杂性度量1976年 T.J.McCabe McCabe 度量法又称环路复杂性度量 , 基于程序控

制结构的软件复杂性度量模型。程序控制结构图 程序结构对应于有一个入口结点和一个出口结点的有向图 图中每个结点对应一个语句或一个顺序流程的程序代码块 弧对应于程序中的转移 它基于一个程序模块的程序图中环路的个数基于一个程序模块的程序图中环路的个数，因此计算它先要画出程序图。

程序图是退化的程序流程图。流程图中每个处理都退化成一个结点，流线变成连接不同结点的有向弧。

McCabe 度量法

McCabe 用程序控制结构图的巡回秩数 V(G)作为程序结构复杂性的度量

V(G) = e-n+2

其中： e 为结构图的边数

n 为结构图的结点数 可以证明 V(G) 等于结构图中有界或无界的封闭区域个数

例 3.1 计算程序控制结构的 V(G)值

E = 1 E = 3

N = 2 N = 3

V = 1 V = 2

计算程序控制结构的 V(G)值

E = 4 E = 3N = 4 N = 3V = 2 V = 2

计算程序控制结构的 V(G)值

E = 6

N = 5

V = 3

例 3.1 计算如图所示程序控制结构图的 V(G)值。 (a) e=1,n=2,v=1;

(b) e=3,n=3,v=2;

(c) e=4,n=4,v=2 ； (d) e=3,n=3,v=2;

(e) e=6,n=5,v=3.

示例：

在前面的例示中 ,

n＝ 11，m＝ 13， V(G)＝m－ n＋ p＝ 13－ 11＋ 1＝

3.

p＝ 1

McCabe建议把 V(G) 作为模块规模的定量指标，一个模块 V(G) 的值不要大于 10

当 V(G)>10 时，模块内部结构就会变得复杂，给编码和测试带来困难。

这种度量的缺点是： 对于不同种类的控制流的复杂性不能区分 简单 IF 语句与循环语句的复杂性同等看待 嵌套 IF 语句与简单 CASE 语句的复杂性是

一样的 模块间接口当成一个简单分支一样处理 一个具有 1000 行的顺序程序与一行语句

的复杂性相同

3.2 软件项目计划与估算3.2.1 软件项目计划

• 软件项目管理人员在开发工作一开始需要进软件项目管理人员在开发工作一开始需要进行定量估算。行定量估算。• 软件项目计划的目标是提供一个能使项目管软件项目计划的目标是提供一个能使项目管理人员对资源、成本和进度做出合理估算的框理人员对资源、成本和进度做出合理估算的框架。架。• 这些估算应当在软件项目开始时的一个有限这些估算应当在软件项目开始时的一个有限的时间段内做出，并且随着项目的进展定期进的时间段内做出，并且随着项目的进展定期进行更新。行更新。

软件项目计划的目标软件项目计划的目标

软件的范围软件的范围

软件范围包括功能、性能、限制、接口和可靠性。软件范围包括功能、性能、限制、接口和可靠性。 估算开始时，应对软件的功能进行评价，对其进行适估算开始时，应对软件的功能进行评价，对其进行适当的细化以便提供更详细的细节。由于成本和进度的当的细化以便提供更详细的细节。由于成本和进度的估算都与功能有关，因此常常采用某种程度的功能分估算都与功能有关，因此常常采用某种程度的功能分解。解。

性能的考虑包括处理和响应时间的需求。性能的考虑包括处理和响应时间的需求。 约束条件则标识产品成本、外部硬件、可用存储或其约束条件则标识产品成本、外部硬件、可用存储或其

它现有系统对软件的限制。它现有系统对软件的限制。 软件与其它系统元素是相互作用的。要考虑每个接口软件与其它系统元素是相互作用的。要考虑每个接口

的性质和复杂性，以确定对开发资源、成本和进度的的性质和复杂性，以确定对开发资源、成本和进度的影响。影响。

软件开发中的资源软件开发中的资源

3.2.2 软件项目估算

常用的估算方法①参照已经完成的类似项目估算待开发项目的成本和工作

量。②将大的项目分解成若干子项目，在估算出每个子项目成

本和工作量之后，再估算整个项目。③将软件项目按软件生存周期分解，分别估算出软件项目

在软件开发各个阶段的工作量和成本，然后再把这些工作量和成本汇总估算整个项目。

④根据实验或历史数据给出软件项目工作量或成本的经验估算公式。

四种方法可以同时、单独或组合使用，以便取长补短，提高项目估算的精度和可靠性。

采用分解技术估算软件项目应考虑系统集成时需要的工作量。

为了实现软件项目估算，实践中开发了大量的软件项目自动估算工具，用以支持软件工作量或成本估算。

分解技术采用”分而治之”的策略进行软件项目估算 .将项目

分解为若干个主要的功能及相关的软件工程活动 ,通过逐步求精的方式进行成本及工作量估算。

经验估算模型可用于补充分解技术 自动估算工具实现一种或多种分解技术或经验模型，与人机交互

结合，自动估算将是很好的选择。

3.2.2.1 代码行、功能点和工作量估算 软件项目的规模是影响软件项目成本和工作量的重

要因素。 软件项目代码行和功能点估算是成本和工作量估算

的基础。 采用上面的估算方法可以估算出 LOC或 FP 的乐

观值 a ，悲观值b 和一般值m ，然后根据下列加权公式计算出期望值

e=(a＋ 4m＋ b)／ 6 希望 LOC或 FP 的值落在区间［ a,b］之外的概率极小

当 LOC或 FP 的期望值估算出来之后，根据以前软件项目开发的平均生产率 LOC/PM或 FP/PM就可以计算出工作量。

如，软件项目的规模估算为 310FP ，以前完成的软件项目的生产率为 5.5FP/PM ，于是工作量估算为 E=310/5.5=56PM。

例 3.2 估算计算机辅助设计软件项目将 CAD 项目按功能分解为七个子项目①用户界面和控制；②二维几何分析；③三维几何分析；④数据库管理；⑤计算机图形显示；⑥外设控制；⑦设计分析。表 3.4给出七个子项目代码行的乐观估计、悲观计和一般估计值，然后计算出加权平均值。

估算计算机辅助设计软件项目 分析七个子项目的规模复杂性和难度，参照以前

开发类似项目的经验给出开发每行代码的平均成本，每月开发的代码行数。

用这两组数据计算出七个子项目的开发成本和工作量。

最后汇总的 CAD 软件开发项目 规模为 33360 LOC 成本为 656680 $ 工作量为 144.5 PM。

再用这两种方法分别估算软件开发子项目在软件工程各个阶段的工作量，估算结果列入表 3.5 。

两种方 法 估 算 的 工 作 量 分别为 144.5PM 和152.5PM ，相差 5%左右。

估算的成本分别为 656680$ 和 708075$ ，相差 7%左右。

两种方法估算的工作量和成本基本一致。

表 3.4 代码行和成本、工作量估算

功能 乐观 一般 悲观 加权 $ LOC 成本 工作量 LOC LOC LOC 平均 /LOC /PM ＄ ( 人

月 )

用户界面控制 1790 2400 2650 2340 14 315 32760 7.4

二维几何分析 4080 5200 7400 5380 20 220 107600 24.4

三维几何分析 4600 6900 8600 6800 20 220 136000 30.9

数据库管理 2900 3400 3600 3350 18 240 60300 13.9

图形显示 3900 4900 6200 4950 22 200 108900 24.7

外设控制 1990 2100 2450 2140 28 140 59920 15.2

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

总计 33360 656680 144.5

表 3. 5 工作量估算

功能 需求分析 设计 编码 测试 总计 用户界面控制 1.0 2.0 0.5 3.5 7二维几何分析 2.0 10.0 4.5 9.5 26三维几何分析 2.5 12.0 6.0 11.0 31.5数据库管理 2.0 6.0 3.0 4.0 15计算机图形显示 1.5 11.0 4.0 10.5 27外设控制 1.5 6.0 3.5 5.0 16设计分析 4.0 14.0 5.0 7.0 30总计 ( 人月 ) 14.5 61 26.5 50.5 152.5 每人月成本 5200 4800 4250 4500成本 (＄ ) 75400 292800 112625 227250 708075

3.2.2.2 经验估算模型之一 CoCoMo 模型

计算机软件的估算模型是根据以前完成项目的实际数据导出的，用于软件项目的计划阶段。

模型是根据“从前的”，“局部的”数据得出的，估算模型不可能完全适用于当前所有的软件项目和全部开发环境。这些模型的计算结果仅供参考。

两个常用的估算模型 CoCoMo 模型 Putnam 模型

CoCoMo 模型 1981 年 Boehm 提出“构造性成本模型” (Constructive

Cost Model) ，简称 CoCoMo 模型。它是在静态、单变量模型的基础上构造出来的。

CoCoMo 模型分为基本、中间、详细三个层次，分别用于软件开发的三个不同阶段。

基本 CoCoMo 模型 用于系统开发的初期，估算整个系统的工作量 (包括软件维护 ) 和软件开发所需要的时间。

中间 CoCoMo 模型 用于估算各个子系统的工作量和开发时间。

详细 CoCoMo 模型 用于估算独立的软部件，如子系统内部的各个模块。

1 基本 CoCoMo 模型

静态、单变量模型 E = aLb (3-1) D = cEd (3-2)其中： E 表示工作量，单位是人月 (PM)。 D 表示开发时间，单位是月 (M)。 L 是项目的代码行估计值，单位是千行代码 a,b,c,d 是常数，取值如表 3.6所示。 Boehm把软件划分为组织型、半独立型和嵌入型三类，允许

不同应用领域和复杂程度的软件按照三类软件的适用范围选取相应的参数 a,b,c,d。

给出了代码行数与工作量、工作量与开发时间之间的函数关系

表 3.6 简单 CoCoMo 模型参数

软件类型 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 实时处理、 控制程序、 操作系统

2 中间 CoCoMo 模型

中间 CoCoMo 模型 以基本 CoCoMo 模型为基础，在工作量估计公式

中乘以工作量调节因子 EAF

E = aLb *EAF (3-3)

其中： L 是软件产品的目标代码行数 a,b 是常数，取值如表 3.7所示。

中间 CoCoMo 模型

表 3.7 中间 CoCoMo 模型参数

软件类型 a b

组织型 3.2 1.05

半独立型 3.0 1.12

嵌入型 2.8 1.20

CoCoMo 模型 工作量调节因子 EAF 与软件产品属性、计算机属性、人

员属性、项目属性有关 软件产品属性 软件可靠性、软件复杂性、数据库的规模。 计算机属性 程序执行时间、程序占用内存的大小、软件开发环境的变

化、软件开发环境的响应速度。 人员属性 分析员的能力、程序员的能力、有关应用领域的经验、开

发环境的经验、程序设计语言的经验 项目属性 软件开发方法的能力，软件工具的质量和数量、软件开发

的进度要求。

CoCoMo 模型 四种属性共 15 个要素。 每个要素调节因子 Fi, i=1,2,...,15, 的值分为： 很低、低、正常、高、很高、极高，共六级。 正常情况下 Fi=1。 Boehm推荐的 Fi值范围 (0.70, 0.85, 1.00, 1.15, 1.30, 1.65) 当 15个 Fi 的值选定后， EAF 的计算如下 EAF＝ F1*F2*……*F15 

CoCoMo 模型

调节因子集的定义和调节因子定值是由统计结果和经验决定的。不同的软件开发组织，在不同的历史时期，随着环境的变化，这些数据可能改变。

使用中间 CoCoMo 模型可以估算开发软件产

品的工作量，比较各种开发方案的工作量。

例 3.3 用基本 CoCoMo 模型估算例 3.2

工作量、开发时间和项目开发人数在例 3.2 中，目标代码行数为 33.3 KLOC

CAD 软件开发属于中等规模、半独立型从表 3.7 中查到 a=3.0， b=1.12。代入公式 (3-1)

E = 3.0＊ L1.12

= 3.0＊ 33.31.12

= 152 PM

将 E 的估算值代入公式 (3-2) 取 C=2.5 d=0.35 D=2.5＊ E0.35

=2.5*1520.35

=14.5 M 建议参加项目开发的人数 N=E/D=152/14.5≈11 例中计算出来的 11人是粗略估计

在软件项目开发过程中， 11个人不可能都有相同的能力和个性，相同的经验和知识结构，并且在软件开发的各个阶段对人的要求也不同。

CoCoMo 模型 若干人共同开发一个软件项目还应该增加他们之间相互通信和交换意见的额外工作量。

设 N 个程序员组成小组，实现相同规模的程序，相互通信数为

=N(N-1)/2 每次通信和交换意见的平均工作量为 μ 则 增加的通信开销为 Ec＝ μN(N-1)/2 (3-4)

2NC

例 3.4 计算一个程序的通信开销

3 人和 5 人开发一个程序相互通信和交换意见的关系如图所示

将 N=3 和 N=5 分别代入公式 (3-4)

Ec(3)＝ μ3(3-1)/2＝ 3μ Ec(5)＝ μ5(5-1)/2＝ 10μ

CoCoMo 模型 由 N 个程序员组成的小组共同开发一个程序总的工作量

ET满足 ET=E+Ec (3-5)程序员小组的生产率是 PG=LOC/(E+Ec) (3-6)程序员小组生产率和单个程序员生产率的比为 Rp=E/(E+Ec) (3-7) 随着程序员小组人数的增加 ,Ec≈μN2/2 ，程序员小组的

生产率将会下降。 模型表明 盲目增加程序员人数会推迟软件完成的日期

3.2.2.3 经验估算模型之二： Putnam 模型 1978年， Putnam 提出了大型软件项目工作量 ( 一般在 30 人年以上 ) 估算模型。

它是一个动态多变量模型，适用于软件开发的各个阶段，估算模型以大型软件项目的实测数据为基础，导出工作量分布曲线。

该曲线与著名的 Rayleigh-Norden (R-N) 曲线相似，它描述了开发工作量，开发时间和软件代码行数之间的关系。

Putnam 模型方程 L = CK E

1/3 td4/3 (3-8)其中： L 表示源程序代码行数 td 表示开发时间 Ck 表示技术状态常数 E 表示工作量 ( 以人年记，包括维护 )

Putnam 模型揭示了软件项目的工作量、软件开发时间和程序代码长度三者之间的关系

Putnam 模型 差的软件开发环境 软件开发没有方法学的支持，缺乏对文档的评审，采用批

处理方式。 一般的软件开发环境 应有软件开发方法学的支持，有适宜的文档和评审，采用交互处理方式。

好的软件开发环境 应采用 CASE 工具和集成化 CASE 环境。 CK= 2000 比较差的软件开发环境 8000 一般的软件开发环境 11000 比较好的软件开发环

Putnam 模型 由 (2-18) 3 3 4 E ＝ L / (CK*td ) (3-9) td 对应于 Rayleigh-Norden曲线的最大值，表示软件交付

时工作量最大，参与软件项目的人最多。 当工作量估算出来之后，利用每人年的开销 ($/PY) 可以

估算成本。 公式 (3-9) 表明，开发软件项目的工作量与交货时间的 4

次方成反比，将 0.9td 代替 (3-9) 式的 td 计算 E 发现，提前 10% 的时间要增加 52% 的工作量，降低了软件开发生产率。

软件开发过程中人员与时间的折衷是一个十分重要的问题。

Putnam 模型

3.3.1 风险分析风险的概念 风险与将要发生的事情有关，研究风险就是研究明天将要发生的事情

风险涉及思想、观念、行为、地点、时间等多种因素

风险随条件的变化而改变，人们通过改变、选择、控制与风险密切相关的条件减少、回避风险

改变、选择、控制条件的策略是不确定的

3.3 风险分析和管理

软件风险

软件风险和其它风险一样存在不确定性 , 有些是很难预测的。

对风险的不确定性进行量化，估算某一风险可能带来的损失。

除关注软件项目的一般性风险外，还要关注软件项目的特殊风险，如项目的背景、特殊要求、关键内容、薄弱环节、技术难点、人员状况、工作环境等。

软件项目存在各种风险，人们关心的问题：

什么风险会导致软件项目的彻底失败 ? 顾客需求、开发环境、目标机、时间、成本的改变

对软件项目的风险会产生什么影响 ? 人们必须抓住什么机会、采取什么措施才能有效地减少风险、顺利完成任务 ?

不同类型的风险 项目风险预算、进度、人力、资源、客户及需求项目的复杂度、规模、结构的不确定性等 技术风险设计、实现、接口、验证和维护规约的二义性、技术的不确定性、陈旧的技术、领先的技术

商业风险无需求的产品、策路风险、管理风险、预算风险

软件风险分析包括的部分

风险标识 风险估算 风险规划 风险监控

软件风险分析

风险标识

风险估算

风险规划

风险监控

潜在地风险列表 优先级高的

风险列表风险规划和应急计划 风险评估

1 风险标识 对待风险不能采取回避态度 项目开始时应对一般性风险和特定产品风险进行

系统标识，並随着项目的展开不断更新。 一般可预测风险 产品规模、商业影响、客户、过程、技术、环境、

人员及经验等。 识别风险的有效方法 风险检测表 为了帮助项目管理人员、项目规划人员 ,全面了

解软件开发过程存在的风险， Boehm 建议设计并使用各类风险检测表，表中条目指明 ,常見並可预测的风险。有些风险可以预料，有些很难预料。

例 3.6 人员配备风险检测表(1) 开发人员的水平如何。(2) 开发人员在技术上是否配套。(3) 开发人员的数量如何。(4) 开发人员是否能够自始至终地参加软件开发工作。(5) 开发人员是否能够集中全部精力投入到软件开发工作。(6) 开发人员对自己的工作是否有正确的期望。(7) 开发人员是否接受过必要的培训。(8) 开发人员的流动是否能够保证工作的连续性。上述问题可以选用 0,1,2,3,4,5来回答。完全肯定取值为 0 ，反之

为 5 ，中间情况分别取值 1,2,3,4值越大表示风险越大。人员配备风险检测表反映了人的因素给软件项目带来的风险。

2风险估算

如果某一风险检测表由m 项组成，每项选取一个整数值 0,1,…， N ，在最理想的情况取值为 0，反之取值为 N ，对于中间状态依次取值1,2,…,N-1

当 N=1 时取值 0,1，对应布尔量真 /假 (T/F) 设第 i种风险检测表第 j项取值 Xij ，对应的加权系

数是 Wij ，于是第 i种风险的估算值可以定义为 m σi ∑＝ WijXij／ (mN) j=1 其中 ∑Wij ＝ m ， Wij ≥ 0 (3—10)

风险估算 如果第 i种风险对整个软件项目的风险估算加权

系数是 ρi, i=1,2,…,l. 为风险要素的个数 ,∑ρi＝1 ，则软件项目风险估算定义为

lR ∑＝ ρiσi (3—11)  i=1

0≤R≤1当 R接近于 0 时表示风险比较小， R接近于 1 时表示风险比较大。

当 ρiσi 比较大时，表示第 i 类风险出现并带来不良影响的可能性比较大，必须引起足够重视，设法改善条件，减小 σi 的值。

3 风险评价和管理

风险评价是风险管理的重要步骤任务 进一步审查风险预测的精度； 更新风险优先次序； 考虑控制和 / 或避免可能发生风险的办法。

风险评价

定义 用三元组 [ri ， li ， xi] 描述风险， i =1,2,3…

其中： ri 表示风险 li 表示风险发生的概率 xi 表示风险产生的影响 对大多数软件项目，应该定义性能、成本及进

度的风险参考水平值，当某一风险或风险组合值超过水平值时项目被迫停止。

风险评估的步骤

1 定义项目的风险参考水平值；2 建立三元组，给出相应的参考水平值；3 预测一组临界点，定义项目终止区域；4 预测什么样的风险组合会影响参考水平 值

风险表 （ 1 ／ 3 ） 风险 类别 概率 影响 RMMM123 项目开始时应在第一列列出所有风险 ; 第二列给出风险类别； 第三列给出每种风险发生的概率； 第四列给出各种风险产生影响的评估值； 第五列给出风险缓解、监控和管理计划。

风险表（ 2 ／ 3 ）

评估值按风险因素： 性能、成本、进度的影响类别求加权平均值 影响类别取值：灾难的 1 ，严重的 2 ，轻微的 3 ，

可忽略的 4 。 对风险表中的风险按照发生概率大小、影响大小，由大至小排序。

风险表（ 3 ／ 3 ）

项目管理者对风险表进行研究后应定义一条中止线，线上的风险较大者应给予特别的关注，线下的风险需要进一步的跟踪、评估、排序。

对风险发生概率较大的事件应引起特别关注，要及早采取措施尽量避免它的发生。

风险评价和管理

三元组［ ri,li,xi］是风险管理的基础

设 高级职员流动给项目带来风险 r1,

根据历史的经验或直观感觉，高级职员离开课题组的概率 l1 = 70%,

这一风险导致事件 x1 发生 项目开发时间延长 15% ，成本增加 20%．

项目负责人采取的风险管理措施(1) 项目开始前控制产生风险的原因。项目开工后应设法减轻风险的影响。

(2) 了解项目开发人员变动的原因，在项目开发期间应控制上述原因，尽量减少人员的流动。

(3) 在工作方法和技术上采取适当措施，防止因人员流动给工作带来损失。

(4) 项目在开发过程中应及时公布并交流项目开发的信息。(5)建立组织机构，确定文档标准、并及时生成文档。(6) 对工作进行集体复审，使多数人都能了解工作的细节，跟上工作进度。

(7) 为关键技术准备后备人员。

RMMM 计划 风险缓解、监控和管理计划 Risk Mitigation,Monitoring,and Management Plan 将风险分析工作文挡化，成为项目的一部分。 执行 RMMM 计划需要成本 当软件项目比较大时，可能标出 30至 40种风

险，如果为每种风险定义 3至 7种风险管理步骤，则风险管理本身就是一个项目。

将 Pareto 的 20-80 规则用于软件项目的风险标识，即 20% 的风险具有 0.80 的权，而其余的 80% 风险只有 0.20 的权。要善于标识属于 20% 的主要风险，降低 RMMM 计划的规模和复杂性。

RMMM 计划大纲 计划大纲1.引言 1.1 文挡的范回和目的 1.2主要风险综述 1.3 责任 1.3.1 管理者 1.3.2技术人员2. 项目风险表 2.1 中止线以上的风险描述 2.2 影响概率及影响因素

3. 风险缓解、监控和管理 3.1缓解 3.1.1 一般策略 3.1.2缓解风险的特定步骤 3.2 监控 3.2.1被监控的因素 3.2.2 监控方法 3.3 管理 3.3.1意外事件计划 3.3.2 特殊考虑4.RMMM 计划时间安排表5. 总结

3.4 项目进度安排 制定软件项目进度表有两种途径。 (1)软件开发小组根据提供软件产品的最后期限从后往前安排时间。

(2)软件项目开发组织根据项目和资源情况制定软件项目开发的初步计划和交付软件产品的日期。

软件开发组织希望按照第二种方式安排工作进度。多数场合遇到的都是比较被动的第一种方式。

对软件项目的进度安排比对软件成本的估算要求更高。成本的增加可以通过提高产品定价或通过大批量销售得到补偿，而项目进度安排不当会引起顾客不满，影响市场销售。

PERT技术和 CPM 方法PERT技术叫做计划评审技术（程序评估与审查技术）

CPM 方法叫做关键路径法它们都是安排开发进度，制定软件开发计划最常用的

方法。它们都采用网络图来描述一个项目的任务网络，也就是从一个项目的开始到结束，把应当完成的任务用图的形式表达出来。通常用两张图来表示。一张图给出项目的所有任务，另一张图给出应按照什麽次序完成这些任务，给出各任务的衔接。

PERT和 CPM 方法提供了定量描述工具，包括①关键路径。完成关键路径上所有任务时间的总和，就是项目开发所需要的最短时间。②用统计模型估算开发每个子任务需要的工作量和时

间。③计算各子任务的最早启动时间和最迟启动时间。

例：某一项目进入编码阶段考虑如何安排三个模块 A,B,C的开发工作，其中 A是公用模块， B 和 C的测试有赖于 A的调试 C为现成已有的模块，但对它要做理解之后做部分修改。直到 A,B,C做组装测试为止。

图中各边表示要完成的任务，数字表示完成该任务的持续时间0为起点， 8为终点。

8

5

0

4

1 2

3

6

7起点

A编码

B编码

A 测试

C修改

C 理解A

调试

BC 组装测试

C 测试

B测试

B 调试

C调试

6 86

8

7

88

6

79 5

终点

开发模块任务网络图

B

AQ

P

P Q

No.0

N0.1 N0.2

在组织较为复杂的项目时或需要对特定的任务进一步做更为详细的计划时 ,可以使用分层的任务网络图。

分层任务网络图

一个概念开发的任务网络

I.1Conceptscoping

I.3aTech. Risk

Assessment

I.3bTech. Risk

Assessment

I.3cTech. Risk

Assessment

Three I.3 tasks areapplied in parallel to3 different conceptfunctions

Three I.3 tasks areapplied in parallel to3 different conceptfunctions

I.4Proof ofConcept

I.5aConcept

Implement.

I.5bConcept

Implement.

I.5cConcept

Implement.

I.2Conceptplanning

I.6CustomerReaction

Integratea, b, c

软件项目的进度安排 1. 任务分配、人力资源

分配、时间分配要与工程进度相协调。

2. 任务分解与并行化 3. 工作量分布 4-2-4 分布原则

4. 工程进度安排 使用程序评估 与审查技术(PERT) 或 关键路径方法 (CPM) 生成任务网络图。

软件项目的进度安排

进度安排的图形方法 甘特图

计划完成

文档编写A

B

C

D

E

1 2 3 4 5 6 7 8 9 10 11 12 13 14

任务

周

当前进度

完成

评审

时间表的例子I.1.1 Identify need and benefits Meet with customers Identify needs and project constraints Establish product statement Milestone: product statement definedI.1.2 Define desired output/control/input (OCI) Scope keyboard functions Scope voice input functions Scope modes of interaction Scope document diagnostics Scope other WP functions Document OCI FTR: Review OCI with customer Revise OCI as required; Milestone; OCI definedI.1.3 Define the functionality/behavior Define keyboard functions Define voice input functions Decribe modes of interaction Decribe spell/grammar check Decribe other WP functions FTR: Review OCI definition with customer Revise as required Milestone: OCI defintition completeI.1.4 Isolate software elements Milestone: Software elements definedI.1.5 Research availability of existing software Reseach text editiong components Research voice input components Research file management components Research Spell/Grammar check components Milestone: Reusable components identifiedI.1.6 Define technical feasibility Evaluate voice input Evaluate grammar checking Milestone: Technical feasibility assessedI.1.7 Make quick estimate of sizeI.1.8 Create a Scope Definition Review scope document with customer Revise document as required Milestone: Scope document complete

week 1 week 2 week 3 week 4Work tasks week 5

3.5 软件质量度量

1）软件质量度量及三层次度量模型

2）软件质量要素

3）软件质量要素评价准则

软件质量度量及三层次度量模型

软件质量是软件的生命，它直接影响软件的使用与维护。

质量低下的软件不但影响基于计算机系统的工作效率，而且还可能给用户带来灾难性的后果。

提高软件产品质量是软件工程的首要任务。 软件开发人员、管理人员、维护人员和用户在软件开

发、维护、使用过程中所处地位不同，对软件质量的理解和要求也不同。

软件质量度量 1976年 Boehm 提出了定量评价软件质量的概念，给

出了 60 个软件质量度量公式和软件质量度量的层次模型

1978 年 Walters 和 McCall 提 出 了包括质 量 要素(factor) 、准则 (criteria) 和度量 (metric) 的三层次软件质量度量模型

G.Murine又提出了软件质量度量技术 SQM 用于定量地评价软件质量

1985年国际标准化组织 (ISO) 提出了软件质量度量(SQM) 工作报告

三层次软件质量度量模型

质量要素 (factor)

评价准则 (criteria)

度 量 (metric)

要素

评价准则

度量 度量 度量

软件质量要素

软件质量要素直接影响软件开发过程各个阶段的产品质量

由于对软件质量理解的不断深化，软件质量要素不是一成不变的

McCall 等人给出的软件质量要素共 11 个，分为三类。

McCall 的软件质量要素软件的运行特征 正确性 可靠性 有效性

完整性 可用性软件承受修改的能力 可维护性 灵活性 可测试性软件对新环境的适应程度 可移植性 可重用性 可互操性

软件的属性 正确性 (Correctness)

程序满足规格说明及完成用户目标的程度。 完整性 (Integrity)

控制未被授权人员访问程序和数据的程度。 可用性 (Usability)

学习使用软件的难易程度。包括：操作软件、为软件准备输入数据，解释软件输出结果。

灵活性 (Flexibility) 改变一个操作程序所需的工作量。

可测试性 (Testability) 测试程序使之具有预定功能所需的工作量。

可互操性 (Interoperability) 两个或多个系统交换信息并相互使用已交换信息的能力。

软件质量要素之间的关系 软件质量要素之间有正相关，也有负相关。系统

设计过程中应根据具体情况对各种要素的要求进行折衷，以便得到在总体上用户和系统开发人员都满意的质量标准。

而有效性不是影响系统成败的关键要素。 实时控制系统的可靠性、有效性是决定系统成败的关键要素，必须全力保证，而软件的可移植性、可重用性就不是主要的了。

通用软件工具对可维护性、可移植性、可重用性应该给予更多的注意

表 3.8 质量要素之间的关系 要 正 可 有 完 可 可 可 灵 可 可 互 素 确 靠 效 整 用 维 测 活 移 重 操 性 性 性 性 性 护 试 性 植 用 作正确性可靠性 △有效性 完整性 -可用性 △ △ - △可维护性 △ △ - △可测试性 △ △ - △ △灵活性 △ △ - - △ △ △可移植性 - △ △可重用性 - - - △ △ △ △互操作性 - - △

3.5.1 软件质量要素评价准则

直接测量软件质量要素十分困难，甚至是不可能的， McCall 等人定义了一组比较容易度量的软件质量要素评价准则，通过评价准则间接测量软件质量要素。

定义评价准则的关键是确定影响软件质量要素的属性。这些属性必须满足

①比较完整、准确的描述软件质量要素； ②比较容易量化和测量，能够反映软件质量的优劣。

McCall 软件质量要素评价准则

可审查性 准确性 通信通用性 完全性简明性 一致性数据通用性 容错性执行效率 可扩充性通用性 硬件独立性检测性 模块化可操作性 安全性自文档化 简单性软件系统独立性 可追踪性易培训性

计算软件质量要素软件质量要素 Fj 的值可用下式计算 L Fj ∑＝ CjkMk j=1,2,……,11.  k=1其中 : Mk 是软件质量要素 Fj 对第 k种评价准则的测量值 Cjk 是相应的加权系数

L ∑Cjk=1 其中 , Cjk >=0  k=1当质量要素 Fj 与 k 项评价准则无关时 , Cjk=0;McCall 定义的评价准则多数都没有客观的测量方法，只能凭主观印象为评价准则定值。 L 表示评价准则的项数。对于McCall 的评价准则， L=21 。

McCall将评价准则分为 0--10级。 0级最低 ,10级最高。 Mk 的取值是 0 ,0.1 ,0.2 ,…, 1.0

表 3.9 质量要素与评价准则 (1/2) 要素 关系 准则

正确性

可靠性

有效性

完整性

可维护

可测试

可移植

可重用

互操作

可用性

灵活性

可审查性 V V

准确性 V

通信通用性 V

完全性 V

简明性 V V V

一致性 V V V V

数据通用性 V

容错性 V

执行效率 V

可扩充性 V

通用性 V V V V

表 3.10 质量要素与评价准则 (2/2)

要 素 关 系 准 则

正确性

可靠性

有效性

完整性

可维护

可测试

可移植

可重用

互操作

可用性

灵活性

硬件独立性 V V V V

检测性 V V V

模块化 V V V V V V V

可操作性 V V

安全性 V

自文挡化 V V V V V

简单性 V V V V

软件独立性 V V

可追踪性 V

易培训性 V

软件质量的 FURPS 度量

国内外许多软件工程组织和专家在软件质量要素和评价准则的选取度量方面做了大量的工作，用于软件开发过程的质量控制和软件产品的质量度量。

1987 年 Hewlett-Packard 提 出 一 组被称之为FURPS 的软件质量要素。

软件质量的 FURPS 度量

这组 要素由功 能 性 (Functionality) 、 可 用 性(Usability) 、 可 靠 性 (Reliability) 、 性 能(Performance) 和可支撑性 (Supportability) 组成。

Grad和 Caswell给出了以调查报告 / 规格说明、设计、实现、测试、支撑为行，以上述要素为列的 5 行 5列矩阵，通过对矩阵元素的度量导出软件开发过程和软件产品质量要素的 FURPS 度量。

FURPS 软件貭量要素

要素 关系 准则

功能性

可用性

可靠性

性能

可支撑性

论证报告 /

規格说明 设计 实现 测试 支撑环境

谢谢谢谢