软件项目管理

■

弟二早软件项目管理

■项目管理的概念

■软件项目度量

■软件项目计划与估算

■风险分析和管理

■项目进度安排

■软件质量保证

■软件配置管理

■

项目管理的谱系

确

定

解

■—m删网rBiiiii

软件项目管理的目的、任务和内容

目的

为了使软件项目能够在预定成本、进度、质

量的前提下顺利完成，必须对软件工程项目进

行计划、组织、监控和管理

任务

■制定软件项目的实施计划和方案；

■对人员进行组织和分工；

■按照计划进度，以及成本管理、风险管理、质

量管理的要求进行软件开发，完成软件项目的

各项要求和任务。

□

3.1软件项目度量

3.1.1软件度量

■软件度量的概念

■软件规模度量

■软件功能度量

软件度量分类

3.1.1.1度量、估算

■度量metrics

度量具有数字特征，软件工程范围的度量是软

件开发过程、软件资源或软件产品简单属性的

定量描述。

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

等。

■估算estimation

对软件产品、过程、资源进行预测

估算可以采用经验公式、或参考历史资料

估算用于事前签订合同、立项、制定工作计划

等

软件的外部属性和内部属性

■外部属性

软件产品、过程、资源与环境的关系

如，成本、效益、劳动生产率、可靠性、可

维护性

■内部属性

软件产品、过程、资源、环境自身的属性

如，产品结构、模块化程度、复杂性、程序

长度等。

产品•过程•资源

■产品的内部属性

程序代码长度程序功能模块化重用性

控制流数据流模块耦合度与内聚度

■产品的外部属性

程序的可靠性可用性可维护性

软件的可理解性有效性可移植性

■过程的内部属性

工作量计划和进度一段时间内某类事件

发生的次数

■过程的外部属性

成本可控制性可观察性稳定性

■资源的内部属性

人软硬件环境方法经验

■资源的外部属性

成本时间

■

面向规模的度量

■代码行1数LOC或KLOC

■生产率

Pi=UE

其中L软件项目代码行数

E软件项目工作量（人月PM）

Pi软件项目生产率（LOC/PM）

■代码出错率

EQR|=Ne/L

其中Ne软件项目的代码错误数

EQ&每千行代码的错误数

■每行代码平均成本

CI=S/L

其中S软件项目总开销（元/美元）

CI软件项目每行代码的平均成本

■文档与代码比

DI=Pd/L

其中Pd软件项目文档页数

DI每千行代码的平均文档数

■

例软件项目记录

项目工作量成本代码行文档页数错误数人数

PM万美元kLOCPdNeM

Aaa

-012416.812.1365293

Ccc

-046244.027.21224865

Fff

-034331.420.21050646

生产率：p1=UE=12.1kLoc/24PM=504Loc/PM

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

/kLoc

平均成本：

CI=S/L=168000美元"2.1kLoc=13.88美元

/Loc

每千行代码的平均文档页数：

DI=Pd/L=365Pd/12.1kLoc=30.16Pd/kLoc

■

规模度量的优缺点

用软件代码行数估算软件规模简单易行。

缺点

■代码行数的估算依赖于程序设计语言的功能和表

达能九

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

生不利的影响；

■在软件项目开发前或开发初期估算它的代码行数

十分困难；

■代码行估算只适用于过程式程序设计语言，对非

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

■

3.1.1.3面向功能的度量

根据事务信息处理程序的基本功能定义的,

在系统设计初期可以估算出软件项目的规模

FP=CT*[0.65+0.01*ZFi]

其中：CT按表3.1计算0

Fi是复杂性调节值

Fi取值0,1,...,5

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

Fi=5时，表示Fi作用最大

表3」功能点度量

测量参数值权值

用户输入数口*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.L1.4代码行度量与功能点度量的比较

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

量不依赖于程序设计语言。

■Albrecht和Jones等人对若干软件采用事后处理

的方式分别统计出不同程序设计语言每个功能

点与代码行数的关系，用LOCVFP的平均值表示。

■表3.3表明，一行Ada语言代码的“功能”平均是

一行FORTRAN语言代码“功能”的1.4倍。一行

四代语言代码的“功能''平均是一行传统程序设

计语言代码“功能”的3至5倍。

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

程序设计语言LOC/FP（平均值）

汇编语言300

COBOL100

FORTRAN100

Pascal90

Ada70

面向对象的语言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)值

①顺序结构②While结构

(a)

E=1E=3

N=2N=3

V=1V=2

□

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

③选择结构

(c)(d)

E=4E=3

N=4N=3

V=2V=2

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

(e)

例3.1计算如图所示程序控制结构图的V(G)值。

(a)e=l,n=2,v=l;

(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.

示例：弓直）程序流程图程序图A

B

FJ

、H输-入-f

在前面的例示中，

〃=11,

勿=13,«G)=6一〃+〃=13—11+1=3.

P=1

■McCabe建议把V(G)作为模块规模的定量指标，

一个模块V(G)的值不要大于10

■当V(G)>10时，模块内部结构就会变得复杂，给

编码和测试带来困难。

■这种度量的缺点是：

□对于不同种类的控制流的复杂性不能区分

□简单IF语句与循环语句的复杂性同等看待

□嵌套IF语句与简单CASE语句的复杂性是

一样的

□模块间接口当成一个简单分支一样处理

□一个具有1000行的顺序程序与一行语句

的复杂性相同

■

3.2软件项目计划与估算

3.2.1软件项目计划

■软件项目计划的目标

•软件项目管理人员在开发工作一开始需要进

行定量估算。

•软件项目计划的目标是提供一个能使项目管

理人员对资源、成本和进度做出合理估算的框

架。

•M些估算应当在软件项目开始时的一个有限

的时间段内做出，并且随着项目的进展定期进

行更新。

■软件的范围

■软件范围包括功能、性能、限制、接口和可靠性。

■估算开始时，应对软件的功能进行评价，对其进行适

当的细化以便提供更详细的细节。由于成本和进度的

估算都与功能有关，因此常常采用某种程度的功能分

解。

■性能的考虑包括处理和响应时间的需求。

■约束条件则标识产品成本、外部硬件、可用存储或其

它现有系统对软件的限制。

■软件与其它系统元素是相互作用的。要考虑每个接口

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

影响。

软件开发中的资源

>A：需要的技勤刑附间，工作期的有效性

静»：开发系绛目楙喘新系藕它硬件部分

ftft：M娜软件

投入时邮特轴瓦Wtt

高

人高级技术人员

员

参

加

程

度初级技术人员

./管理人员

计

需

编

单

整

确

详

概

元

体

认

求

细

要

测

测

测

分

设

设

试

试

试

析

计

计

划

码

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软件开发项目

规模为33360L0C

成本为656680$

工作量为144.5PMo

■

■再用这两种方法分别估算软件开发子项目在软件

工程各个阶段的工作量，估算结果列入表3.5。

■两种方法估算的工作量分别为144.5PM和

152.5PM,相差5%左右。

■估算的成本分别为656680$和708075$,相差7%

左右。

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

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

功能乐观一般悲观加权$LOC成本工作量

LOCLOCLOC平均/LOC/PM$（人月）

用户界面控制179024002650234014315327607.4

二维几何分析40805200740053802022010760024.4

三维几何分析46006900860068002022013600030.9

数据库管理2900340036003350182406030013.9

图形显示39004900620049502220010890024.7

外设控制1990210024502140281405992015.2

设计分析66008500980084001830015120028.0

总计33360656680144.5

表3.5工作量估算

功能需求分析设计编码测试总计

用户界面控制1.02.00.53.57

二维几何分析2.010.04.59.526

三维几何分析2.512.06.011.031.5

数据库管理2.06.03.04.015

计算机图形显示1.511.04.010.527

外设控制1.56.03.55.016

设计分析4.014.05.07.030

总计(人月)14.56126.550.5152.5

每人月成未

5200480042504500

成本($)75400292800112625227250708075

■

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

■计算机软件的估算模型是根据以前完成项目的实

际数据导出的，用于软件项目的计划阶段。

■模型是根据“从前的”，"局部的''数据得出的，估

算模型不可能完全适用于当前所有的软件项目和

全部开发环境。这些模型的计算结果仅供参考。

■两个常用的估算模型

CoCoMo模型Putnam模型

CoCoMo模型

■1981年Boehm提出“构造性成本模型”(ConstructiveCost

Model),简称CoCoMo模型。它是在静态、单变量模型的

基础上构造出来的。

■CoCoMo模型分为基本、中间、详细三个层次，分别用于

软件开发的三个不同阶段。

■基本CoCoMo模型用于系统开发的初期，估算整个系统的

工作量(包括软件维护)和软件开发所需要的时间。

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

时间。

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

部的各个模块。

1基本CoCoMo模型

静态、单变量模型

E=al?(3-1)

D=cEd(3-2)

其中：E表示工作量，单位是人月(PM)。

D表示开发时间，单位是月(M)。

L是项目的代码行估计值，单位是千行代码

是常数，取值如表3.6所示。

Boehm把软件划分为组织型、半独立型和嵌入型三类，允许

不同应用领域和复杂程度的软件按照三类软件的适用范围选

取相应的参数a9b4do

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

表3.6简单CoCoMo模型参数

软件类型abcd适用范围

组织型2.41.052.50.38各类应用程序

半独立型3.01.122.50.35各类实用程序

编译程序等

嵌入型3.61.202.50.32实时处理、

控制程序、

操作系统

■

2中间CoCoMo模型

■中间CoCoMo模型

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

中乘以工作量调节因子EAF

E=aLb*EAF(3-3)

其中：L是软件产品的目标代码行数

a,b是常数，取值如表3.7所示。

中间CoCoMo模型

表3.7中间CoCoMo模型参数

软件类型ab

组织型3.21.05

半独立型3.01.12

嵌入型2.81.20

CoCoMo模型

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

属性、项目属性有关

■软件产品属性

软件可靠性、软件复杂性、数据库的规模。

■计算机属性

程序执行时间、程序占用内存的大小、软件开发环境的

变化、软件开发环境的响应速度。

■人员属性

分析员的能力、程序员的能力、有关应用领域的经验、

开发环境的经验、程序设计语言的经验

■项目属性

软件开发方法的能力，软件工具的质量和数量、软件开

发的进度要求。

CoCoMo模型

■四种属性共15个要素。

■每个要素调节因子Fi,i=l,2,…,15,的值分为：

很低、低、正常、高、很高、极高，共六级。

■正常情况下Fi=lo

■Boehm推荐的Fi值范围

(0.70,0.85,1.0091.15,1.30,1.65)

■当15个Fi的值选定后，EAF的计算如下

EAF=F1*F2*...*F15

■

CoCoMo模型

调节因子集的定义和调节因子定值是由统

计结果和经验决定的。不同的软件开发组织，

在不同的历史时期，随着环境的变化，这些数

据可能改变。

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

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

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

工作量、开发时间和项目开发人数

在例3.2中，目标代码行数为33.3KLOC

CAD软件开发属于中等规模、半独立型

从表3.7中查到a=3.0,b=1.12o

代入公式(3・1)

E=3.0火山2

=3.0*33.3112

=152PM

将E的估算值代入公式（3-2）

取C=2.5d=0.35

D=2.5*E°・35

=2.5*152635

=14.5M

建议参加项目开发的人数

N=E/D=152/14.5^11

■例中计算出来的11人是粗略估计

■在软件项目开发过程中，11个人不可能都有相同

的能力和个性，相同的经验和知识结构，并且在

软件开发的各个阶段对人的要求也不同。

CoCoMo模型

若干人共同开发一个软件项目还应该增加他们之

间相互通信和交换意见的额外工作量。

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

通信数巧

盘=N(N-l)/2

每次通信和交换意见的平均工作量为口

则增加的通信开销为

Ec=uN(N-l)/2(3-4)

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

3人和5人开发一个程序

相互通信和交换意见的关

系如图所示

将N=3和N=5分别代入公

式(3・4)

N=3和N=5时的相互

Ec(3)=u3(3-l)/2=3n

通信关系

Ec(5)=n5(5-1)/2=10LI

CoCoMo模型

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

ET满足

ET=E+Ec(3-5)

程序员小组的生产率是

PG=LOC/(E+Ec)(3-6)

程序员小组生产率和单个程序员生产率的比为

Rp=E/(E+Ec)(3-7)

随着程序员小组人数的增加Ec心uN2/2,程序员小组的生

产率将会下降。

模型表明

盲目增加程序员人数会推迟软件完成的日期

3223经验估算模型之二：Putnam模型

■1978年，Putnam提出了大型软件项目工作量(一般

在30人年以上)估算模型。

■它是一个动态多变量模型，适用于软件开发的各个

阶段，估算模型以大型软件项目的实测数据为基

础，导出工作量分布曲线。

■该曲线与著名的Rayleigh-Norden(R-N)曲线相似，

它描述了开发工作量，开发时间和软件代码行数之

间的关系。

Putnam模型

方程

4/3

L=CKEi/3td(3-8)

其中：L表示源程序代码行数

td表示开发时间

Ck表示技术状态常数

E表示工作量(以人年记，包括维护)

Putnam模型揭示了软件项目的工作量、软件开发时

间和程序代码长度三者之间的关系

■

Putnam模型

■差的软件开发环境

软件开发没有方法学的支持，缺乏对文档的评审，采用

批处理方式。

■一般的软件开发环境

应有软件开发方法学的支持，有适宜的文档和评审，采

用交互处理方式。

■好的软件开发环境

应采用CASE工具和集成化CASE环境。

CK=f2000比较差的软件开发环境

<8000一般的软件开发环境

、11000比较好的软件开发环

■

Putnam模型

由(2・18)

E=LhcK^td4)(3-9)

■td对应于Rayleigh-Nordeii曲线的最大值，表示软件交付

时工作量最大，参与软件项目的人最多。

■当工作量估算出来之后，利用每人年的开销($/PY)可以估

算成本。

■公式(3-9)表明，开发软件项目的工作量与交货时间的4次

方成反比，将09td代替(3・9)式的td计算E发现，提前10%

的时间要增加52%的工作量，降低了软件开发生产率。

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

Putnam模型

大型软件项目的工作量分布

■

3.3风险分析和管理

331风险分析

风险的概念

■风险与将要发生的事情有关，研究风险就是研究

明天将要发生的事情

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

因素

■风险随条件的变化而改变，人们通过改变、选择、

控制与风险密切相关的条件减少、回避风险

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

软件风险

■软件风险和其它风险一样存在不确定性，有些是很

难预测的。

■对风险的不确定性进行量化，估算某一风险可能

带来的损失。

■除关注软件项目的一般性风险外，还要关注软件

项目的特殊风险，如项目的背景、特殊要求、关

键内容、薄弱环节、技术难点、人员状况、工作

环境等。

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

■什么风险会导致软件项目的彻底失败？

■顾客需求、开发环境、目标机、时间、成本的改变

对软件项目的风险会产生什么影响？

■人们必须抓住什么机会、采取什么措施才能有效地

减少风险、顺利完成任务？

不同类型的风险

■项目风险

预算、进度、人力、资源、客户及需求

项目的复杂度、规模、结构的不确定性等

■技术风险

设计、实现、接口、验证和维护

规约的二义性、技术的不确定性、陈旧的技术、领

先的技术

■商业风险

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

■

软件风险分析包括的部分

■风险标识

■风险估算

■风险规划

■风险监控

软件风险分析

险

险

凡

圳

整

」

ft算皿

J

潜在地风优先级高的风险规划和

风险评估

险列表风险列表应急并4

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风险估算

如果某一风险检测表由Hl项组成，每项选取一

个整数值0,1，…，N,在最理想的情况取值为0,反

之取值为N,对于中间状态依次取值1,2,…,NT

当N=1时取值0,1,对应布尔量真/假(T/F)

设第i种风险检测表第j项取值Xij,对应的加权系

数是Wij,于是第i种风险的估算值可以定义为

m

。i=EWijXij/(mN)

j=l

其中EWij=m,Wij三0(3-10)

■

风险估算

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

系数是…J.为风险要素的个数，EPi=

L则软件项目风险估算定义为

1

R=EPioi(3—11)

i=l

■0WRW1当R接近于0时表示风险比较小，R接

近于1时表示风险比较大。

■当Pioi比较大时，表示第i类风险出现并带来不

良影响的可能性比较大，必须引起足够重视，设

法改善条件，减小。i的值。

3风险评价和管理

风险评价是风险管理的重要步骤

任务

■进一步审查风险预测的精度；

■更新风险优先次序；

■考虑控制和/或避免可能发生风险的办法。

风险评价

定义

用三元组［ri,li,xi］描述风险，i=1,23・・

其中：ri表示风险

li表示风险发生的概率

xi表示风险产生的影响

对大多数软件项目，应该定义性能、成本及进

度的风险参考水平值，当某一风险或风险组合值

超过水平值时项目被迫停止。

风险评估的步骤

1定义项目的风险参考水平值；

2建立三元组，给出相应的参考水平值；

3预测一组临界点，定义项目终止区域；

4预测什么样的风险组合会影响参考水平值

风险表(1/3)

风险类别概率影响RMMM

1

2

3

■项目开始时应在第一列列出所有风险；

■第二列给出风险类别；

■第三列给出每种风险发生的概率；

■第四列给出各种风险产生影响的评估值;

■第五列给出风险缓解、监控和管理计划。

风险表（2/3）

■评估值按风险因素：

性能、成本、进度的影响类别求加权平均值

■影响类别取值：灾难的1,严重的2,轻微的3,

可忽略的4。

■对风险表中的风险按照发生概率大小、影响大

小，由大至小排序。

风险表(3/3)

■项目管理者对风险表进行研究后应定义一条中止

线，线上的风险较大者应给予特别的关注，线下

的风险需要进一步的跟踪、评估、排序。

■对风险发生概率较大的事件应引起特别关注，要

及早采取措施尽量避免它的发生。

■

,风险分析数据

风险1((4人川)

、风险管理步骤1

,风险分析数据

风险管理

风险24(n,/2,xi)

、风险管理步骤2

「认＞风险分析数据

风险5.In,Jn)风险管理和监控计划

、风险管理步骤〃

风险管理和监控

风险评价和管理

三元组是风险管理的基础

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

根据历史的经验或直观感觉，高级职员离开课

题组的概率11=70%,

这一风险导致事件xl发生

项目开发时间延长15%,成本增加20%.

项目负责人采取的风险管理措施

(1)项目开始前控制产生风险的原因。项目开工后应设法

减轻风险的影响。

(2)了解项目开发人员变动的原因，在项目开发期间应控

制上述原因，尽量减少人员的流动。

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

给工作带来损失。

(4)项目在开发应程中应及时公布并交流项目开发的信息。

(5)建立组织机构，确定文档标准、并及时生成文档。

(6)对工作进行集体复审，使多数人都能了解工作的细

节，跟上工作进度。

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

RMMM计划

■风险缓解、监控和管理计划

RiskMitigation.Monitoring^ndManagementPlan

将风险分析工作文挡化，成为项目的一部分。

■执行RMMM计划需要成本

当软件项目比较大时，可能标出30至40种风

险，如果为每种风险定义3至7种风险管理步骤，

则风险管理本身就是一个项目。

■将Pareto的2040规则用于软件项目的风险标

识，即20%的风险具有0.80的权，而其余的80%

风险只有0.20的权。要善于标识属于20%的主要

风险，降低RMMM计划的规模和复杂性。

■

RMMM计划大纲

3•风险缓解、监控和管理

计划大纲3.1缓解

1.引言3/L1一般策略

1」文挡的范回和目的