2 第二章 软件项目管理.

Presentation on theme: "2 第二章 软件项目管理."— Presentation transcript:

1 2 第二章 软件项目管理

2 2.1 软件项目管理概述 项目管理是广泛应用于各种工程、金融等技术管理过程，管理的好坏决定了工程的成败。
软件及IT 行业，尤其是软件产品的特殊性，软件项目管理对于保证软件产品的质量具有极为重要的作用，是决定一个产品或企业能否成功的最重要的指标。 不可见性 不确定性 人员流动性

3 2.1 软件项目管理概述 随着软件的规模和复杂度的不断增大，开发人员的增加以及开发时间的增长，这些都增加了软件项目管理的难度。 例如：Windows 2000的开发 是微软公司历史上最艰巨的任务，仅核心部门的的成员就有2500人，测试用的代码就有1000万行，测试中所用到的脚本程序就有6500种…。象规模如此之大的软件系统，如果没有科学的、规范的、有效的管理，是不可能成功的。因此软件项目管理成为软件工程的重要研究内容之一。

4 2.1.1 软件项目管理的任务 一、软件项目管理的“4P” 过程 (process) 技术集成 工具 (tools) 人员 （people）
(Project) 自动化 参与 结果 产品 (Product)

5 2.1.1 软件项目管理的任务 二、软件项目管理过程 软件项目管理，是对整个软件生存期的所有活动进行管理。主要过程包括： 1.项目启动
确定系统范围、组建项目团队、建立项目环境。 2.项目规划 确定项目活动、项目成本估算、制定进度计划 3.项目实施 监控项目执行、管理项目风险、控制项目变更 4.项目收尾 项目验收、软件安装培训、项目总结

6 2.1.1 软件项目管理的任务 三、软件项目管理与过程管理的关系
过程定义 过程改进 项目规划 项目监控 项目实施 软件项目管理 软件过程管理 软件项目管理用于保证项目目标的成功实现，过程管理用于辅助项目管理，将最佳的项目实践用于软件开发过程。

7 2.1.2 项目管理的主要活动 软件项目的规划 人员的组织管理 软件风险管理 软件配置管理 包括： 可行性分析 软件项目度量
 软件成本估算  软件计划 软件项目的规划 人员的组织管理 软件风险管理 软件配置管理

8 2.1.2 项目管理的主要活动 软件项目的规划 人员的组织管理 软件风险管理 软件配置管理 包括：  人员配备原则  人员配备模式
 软件团队建设  软件项目沟通活动

9 软件项目的规划 人员的组织管理 软件风险管理 软件配置管理 2.1.2 项目管理的主要活动 包括：  风险识别  风险分析  风险规划
 风险监控

10 2.1.2 项目管理的主要活动 软件项目的规划 人员的组织管理 软件风险管理 软件配置管理
是为了有效地控制和管理软件开发过程中的变化，进行标识、组织和控制修改的技术。 配置管理活动：  配置项的标识  版本管理  系统构建  变更控制 软件项目的规划 人员的组织管理 软件风险管理 软件配置管理

11 软件项目度量 软件度量 软件度量的概念 软件规模度量 软件功能度量 软件度量分类

12 度量、估算 度量 metrics 度量具有数字特征，软件工程范围的度量是软件开发过程、软件资源或软件产品简单属性的定量描述。
如，程序规模、操作符个数、程序中错误的个数等。 估算 estimation 对软件产品、过程、资源进行预测 估算可以采用经验公式、或参考历史资料 估算用于事前签订合同、立项、制定工作计划等

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

14 每行代码平均成本 Cl=S/L 其中 S 软件项目总开销（元／美元） Cl软件项目每行代码的平均成本 文档与代码比 Dl=Pd/L 其中 Pd 软件项目文档页数 Dl 每千行代码的平均文档数

15 例 软件项目记录 项目 工作量 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

16 生产率：Pl=L/E=12.1kLoc/24PM=504Loc/PM
出错率：EQRl=Ne/L=29个/12.1kLoc=2.4个/kLoc 平均成本： Cl=S/L = 美元/12.1kLoc= 13.88美元/Loc 每千行代码的平均文档页数： Dl=Pd/L=365Pd/ 12.1kLoc=30.16Pd/kLoc

17 规模度量的优缺点 用软件代码行数估算软件规模简单易行。 缺点 代码行数的估算依赖于程序设计语言的功能和表达能力；
采用代码行估算方法会对设计精巧的软件项目产生不利的影响； 在软件项目开发前或开发初期估算它的代码行数十分困难； 代码行估算只适用于过程式程序设计语言，对非过程式的程序设计语言不太适用等等。

18 面向功能的度量 根据事务信息处理程序的基本功能定义的，在系统设计初期可以估算出软件项目的规模 FP=CT*［0.65+0.01*∑Fi］
当 Fi = 0 时，表示 Fi 不起作用 Fi = 5 时，表示 Fi 作用最大

19 表 功能点度量 测量参数 值 权值 用户输入数 □ *4 ＝ □ 用户输出数 □ *5 ＝ □ 用户查询数 □ *4 ＝ □
表 功能点度量 测量参数 值 权值 用户输入数 □ *4 ＝ □ 用户输出数 □ *5 ＝ □ 用户查询数 □ * ＝ □ 文件数 □ * ＝ □ 外部界面数 □ * ＝ □ CT ＝ □

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

21 用功能点定义相应的概念 生产率： Pf=FP/E 其中 Pf表示每人月完成的功能点数 平均成本： Ci=S/FP
文档与功能点比： Di=Pd/FP 其中 Di表示每个功能点平均具有的文档页数 代码出错率： EORi=Ne/FP 其中 EORi表示每个功能点的平均错误个数

22 面向功能的度量 软件规模的功能点度量没有直接涉及软件系统本身的算法复杂性。
1986年Jones把软件项目中的算法复杂性因素引入到功能点计算中来，为了避免混淆，我们把Albrecht定义的功能点称为简单功能点，用FPs表示，把Jones推广的功能点称为功能点，用FP表示。 推广的功能点包括计算机程序中用于各类问题求解的算法因素，如求解线性代数方程组、遍历二叉树的各个结点、处理中断等等。 功能点计算仍用上面的公式,其中CT按表2.2计算。

23 表 推广的功能点度量 测量参数 值 权值 用户输入数 □ *4 ＝ □ 用户输出数 □ *5 ＝ □ 用户查询数 □ *4 ＝ □
表 推广的功能点度量 测量参数 值 权值 用户输入数 □ *4 ＝ □ 用户输出数 □ *5 ＝ □ 用户查询数 □ * ＝ □ 文件数 □ * ＝ □ 外部界面数 □ * ＝ □ 算法 □ * ＝ □ CT ＝ □ 对一般的工程计算或事务处理软件，用表2.1和表2.2两种方法计算出来的FP值应该基本上相同 对于比较复杂的软件系统 FP比FPs的值高20%～35%

24 面向功能的度量的优缺点 优点 ①与程序设计语言无关，它不仅适用于过程式语言，也适用于非过程式的语言；
②软件项目开发初期就能基本上确定系统的输入、输出等参数，功能点度量能用于软件项目的开发初期。 缺点 ①它涉及到的主观因素比较多，如各种权函数的取值； ②信息领域中的某些数据有时不容易采集； ③FP的值没有直观的物理意义。

25 代码行度量与功能点度量的比较 代码行度量依赖于程序设计语言，而功能点度量不依赖于程序设计语言。
Albrecht和Jones等人对若干软件采用事后处理的方式分别统计出不同程序设计语言每个功能点与代码行数的关系，用LOC/FP的平均值表示。 表2.3表明，一行Ada语言代码的“功能”平均是一行FORTRAN语言代码“功能”的1.4倍。一行四代语言代码的“功能”平均是一行传统程序设计语言代码“功能”的3至5倍。

26 表 各种语言的LOC/FP(平均值) 程序设计语言 LOC/FP(平均值) 汇编语言 300 COBOL 100 FORTRAN 100
汇编语言 COBOL FORTRAN Pascal Ada 面向对象的语言 四代语言(4GL) 代码生成器  

27 软件复杂性度量 1976年 T.J.McCabe McCabe度量法又称环路复杂性度量,基于程序控制结构的软件复杂性度量模型。
程序控制结构图 程序结构对应于有一个入口结点和一个出口结点的有向图 图中每个结点对应一个语句或一个顺序流程的程序代码块 弧对应于程序中的转移 它基于一个程序模块的程序图中环路的个数，因此计算它先要画出程序图。 程序图是退化的程序流程图。流程图中每个处理都退化成一个结点，流线变成连接不同结点的有向弧。

28 McCabe度量法 McCabe用程序控制结构图的巡回秩数V(G)作为程序结构复杂性的度量 V(G) = e-n+2

29 例 计算程序控制结构的V(G)值 E = E = 3 N = N = 3 V = V = 2

30 计算程序控制结构的V(G)值 E = E = 3 N = N = 3 V = V = 2

31 计算程序控制结构的V(G)值 E = 6 N = 5 V = 3

32 例2.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.

33 这种度量的缺点是： 对于不同种类的控制流的复杂性不能区分 简单IF语句与循环语句的复杂性同等看待 嵌套IF语句与简单CASE语句的复杂性是一样的 模块间接口当成一个简单分支一样处理 一个具有1000行的顺序程序与一行语句的复杂性相同

34 软件项目估算 常用的估算方法 ①参照已经完成的类似项目估算待开发项目的成本和工作量。
②将大的项目分解成若干子项目，在估算出每个子项目成本和工作量之后，再估算整个项目。 ③将软件项目按软件生存周期分解，分别估算出软件项目在软件开发各个阶段的工作量和成本，然后再把这些工作量和成本汇总估算整个项目。 ④根据实验或历史数据给出软件项目工作量或成本的经验估算公式。

35 四种方法可以同时、单独或组合使用，以便取长补短，提高项目估算的精度和可靠性。
采用分解技术估算软件项目应考虑系统集成时需要的工作量。 为了实现软件项目估算，实践中开发了大量的软件项目自动估算工具，用以支持软件工作量或成本估算。

36 分解技术 采用”分而治之”的策略进行软件项目估算.将项目分解为若干个主要的功能及相关的软件工程活动,通过逐步求精的方式进行成本及工作量估算。
经验估算模型 可用于补充分解技术 自动估算工具 实现一种或多种分解技术或经验模型，与人机交互结合，自动估算将是很好的选择。

37 代码行、功能点和工作量估算 软件项目的规模是影响软件项目成本和工作量的重要因素。 软件项目代码行和功能点估算是成本和工作量估算的基础。
采用上面的估算方法可以估算出LOC或FP的乐观值a，悲观值b和一般值m，然后根据下列加权公式计算出期望值 e=(a＋4m＋b)／6 希望LOC或FP的值落在区间［a,b］之外的概率极小

38 当LOC或FP的期望值估算出来之后，根据以前软件项目开发的平均生产率LOC/PM或FP/PM就可以计算出工作量。
如，软件项目的规模估算为310FP，以前完成的软件项目的生产率为5.5FP/PM，于是工作量估算为E=310/5.5=56PM。

39 2.2 成本估算技术 成本估算是可行性分析的重要依据，也是软件管理的重要内容，直接影响到软件开发的风险。
软件开发成本主要是指软件开发过程中所花费的工作量及相应的代价，即主要是人的劳动的消耗。 以软件计划、需求分析、设计、编码到测试的软件开发全过程所花费的代价为依据。 一个大型、复杂项目，由于其项目的度，成本估算并不是一件简单的事，必须建立相应的估算模型，按照一定的方法、技术来进行估算。

40 2.2 成本估算技术 一、影响成本估算的因素 1. 软件人员的业务水平 2. 软件产品的规模及复杂度
规模：按YOURDON分类法分为 超小型,小型,中型,大型,超大型,极大型。 复杂度：应用程序， 实用程序，系统程序 低 高 3.开发所需时间 对确定规模、复杂度的软件存在一个”最佳开发时间”。 4.软件开发技术水平 指开发方法、工具、语言等，技术水平高，效率高。 5.软件可靠性要求 — 可靠性要求愈高，成本愈高。

41 2.2 成本估算技术 二.软件成本的估算量 源代码行（LOC） 机器指令行/非机器语言的执行步 开发工作量
人-月（PM） 人-年（PY） 人-日（PD） 软件生产率 LOG/PM ￥/LOC ￥/PM 软件开发时间

42 2.2.1 专家估算模型 即源代码行估算模型（Deiphi技术） 由Rand公司提出的Deiphi技术，是由n位专家进行成本估算。每位专家根据系统规格说明书，反复讨论给出ai、 bi及 mi的值，并按照下式反复估算源代码的期望值Li ，期望中值L。 ai+4mi+bi 6 1 n Li = L= 其中:ai — 估计的最小行数 bi — 估计的最大行数 mi — 最可能的行数 将估算的源代码行数，乘以根据经验推算的每行源代码所需成本，即为该软件的成本。

43 2.2.2 IBM 估算模型 工 作 量： E=5.2*L （PM） 项目持续时间： D=4.1*L （月）
1977年由Waiston(威斯通) 和 Felix(费利克斯) 总结了IBM联合系统分部（FSD）负责的６０个项目的数据，利用最小二乘法拟合，得到如下估算公式： 工 作 量： E=5.2*L （PM） 项目持续时间： D=4.1*L （月） 人员需要量： S=0.54*E （人） 文 档 数： DOC=49*L （页） 其中：L ＿　源代码行，以千行计。 IBM估算模型是一种静态单变量模型，它利用已估算的结果，如源代码行，来估算各种资源的需求量． 但IBM 估算模型不是一种通用模型，因此应用中应根据具体实际情况调整模型中的参数．

44 2.2.3 普特南(Putnam) 估算模型 普特南Putnam 估算模型是一种动态多变量模型，是根据一些大型项目中工作量的分布情况推导出来的。 L Ck td 3 4 Ｋ＝ Ｌ＝ CkＫ td 其中： L—源代码行， K — 所需人力（PY） td— 开发时间, CK —技术水平常数其值与开发环境有关。（差： ，正常： ，好： ）

45 2.2.3 Putnam 估算模型 L Ck td Ｋ＝ Ｌ＝ Ck K td 大型项目的工作量分布情况 3 4 运行与维护 系统开发
功能设计规格说明 系统定义 安装 测试与确认 设计与编码 功能设计 规格说明 时间 大型项目的工作量分布情况

46 9.5.5 COCOMO模型 2.2.4 COCOMO模型 COCOMO模型（Constructive Cost Model）由TRW公司开发，是由Boehm提出的结构型成本估算模型，其特点是精确、易用。 　 是一种层次模型，按照其祥细程度分为三级：即基本的COCOMO模型、中间的COCOMO模型和详细的COCOMO模型。 该模型主要对工作量ＭＭ（单位：PM）和进度TDEP（单位：月）进行估算。模型中考虑到估算量与开发环境有关，将开发项目分为三类：

47 2.2.4 COCOMO模型 组织型（Organic）
规模<5万，较简单,开发人员对产品目标理解充分，经验丰富，对软件开发环境熟悉。大多数应用软件及老的操作系统、编译系统属此类。 嵌入型（Embadded) 软件、硬件关系紧密,操作有限制条件,对接口、数据结构,算法要求较高。如大型复杂的事务处理系统，大型、超大型的操作系统,军事指挥系统,航天控制系统等 半独立型（Semidetached) 对项目要求界于上述两者之间,规模复杂度中等。如新操作系统,大型数据库,生产控制等软件属此类。

48 ① 基本的COCOMO模型（静态单变量模型）
ＭＭ＝ 其中： MM — 工作量（PM），KLOC — 估计的源代码行 Cl —模型系数， —模型指数 . Cl、  取决于开发项目的模式为组织型、半独立型或嵌入型。 　　下表是根据63个项目的数据统计结果，按照基本的COCOMO模型估算的工作量和进度。 总体类型 工作量 进度 组织型 MM=10.4（KLOG）1.05 TDEV=10.5（MM）0.38 半独立型 MM=3.0（KLOG）1.12 TDEV=10.5（MM）0.35 嵌入型 MM=3.6（KLOG）1.20 TDEV=10.5（MM）0.32

49 进一步考虑了15种影响软件工作量的因素，更加合理的估算软件工作量和进度。
② 中间的COCOMO模型 　　进一步考虑了15种影响软件工作量的因素，更加合理的估算软件工作量和进度。 ＭＭ＝ 其中： fi — 成本因素包括： 生产因素（可靠性，数据库规模，软件复杂度） 计算机因素（时间约束，存储约束，环境变更率，计算机换向时间） 人员因素（系统分析员能力、经验，程序员能力，开发人员环境知识，程序时间语言知识） 项目工程因素（设计技术，软件工具，进度限制约束） ③ 详细的COCOMO模型 按照开发阶段给出更加详细的成本因素fi。

50 2.2.5 成本估算方法 对于大型软件项目的估算处理，处理手段主要是分解和类比。一般有以下方式： 1、自顶向下的估算方法
　 据以前完成的同类项目的总成本推算，再将其分配到各开发任务中。 　 特点：简便、估算工作量小、误差大。 2、自底向上的估算法 　 估算每一子任务的开发工作量，将它们累加起来。 　 特点：精确度高、但缺少子任务（模块）间的联系。 3、差别估计法 　 与已完成的项目进行类比，对不同部分另行估算。 　 特点：估算较精确、但区分类比较困难。 注意：通常使用综合方法对实际项目进行估算。

51 2.3 软件开发进度计划 描述计划进度的主要工具：一般的表格工具、甘特图、PERT技术与CPM方法。 １、一般的表格工具
　　软件开发进度计划安排是一件困难的任务，尽可能并行地安排任务，还要考虑各个子任务之间的相互联系，又要预见潜在的问题，提供意外事件的处理意见。 描述计划进度的主要工具：一般的表格工具、甘特图、PERT技术与CPM方法。 需求分析 总体设计 详细设计 编码、测试 １、一般的表格工具 例如：进度表 10 20 30 40 50 60 70 一月 二月 三月 四月 五月 六月 ▲ ▲ ▲ 软件测试 ▲ ▲ ▲ 编码 ▲ ▲ 详细设计 总体设计 ▲ ▲ ▲ 需求分析 １　 任务 月份 进度表

52 2.甘特图（Gantt Chart） 用水平线段表示任务的工作阶段；线段的起点和终点分别表示任务的开始和完成时间，线段的长度表示完成任务所需的时间。下图给出了具有五个任务的甘特图。 　 任务 A B C D E 当前进度 ○△ 完成 计划完成 ○ 文档编写 △ 评审 图 例 优点：标明了各任务的计划进度和当前进度。能够动态反映软件开发的进展情况。 缺点：不能够反映多个任务之间的复杂逻辑关系。 周 甘特图

53 假设红线为关键路径，即完成所有任务的主要路径。
3. PERT技术和CPM方法 　PERT（Program evaluation & review technique)计划评审技术或CPM（Critical path method）关键路径法，都是采用网络图来描述项目的进度安排。如图描述了开发模块A、B、C的任务网络图。各边上所标注的数字为该任务所持续的时间，数字结点为任务的起点和终点。 2 3 4 5 6 7 1 8 起点 A编码 A调试 B编码 A测试 C理解 Ｂ测试 C修改 C调试 C测试 9 BC组装 测试 Ｂ调试 任务网络图 假设红线为关键路径，即完成所有任务的主要路径。

54 2.4 人员配备与组织 合理的配备人员是成功的完成软件项目的切实保证。 一、项目各阶段所需人员 按Putnam_Norden 曲线分配。
高 低 计划 需求分析 初步设计 详细设计 编码 单元测试 整体测试 功能测试 管理人员 高级技术人员 初级技术人员  二、配备人员遵守的原则 重质量;重培训;阶梯提升： 三、评价人员的条件 1、固掌握计算机软件的基本知识和技能； 2、善于分析和综合问题，具有严密的逻辑思维能力； 3、工作踏实、细致、不靠运气，遵循标准和规范，具有严格的科学作风； 4、工作中耐心、有毅力、有责任心； 5、善于听取意见，善于团结协作，有良好的人际关系； 6、具有良好的书面和口头表达能力。

55 四、软件开发小组与软件生产率 随着软件项目规模的增大，需要组成开发小组共同承担软件开发项目中的某一任务，于是人与人之间必须通过交流来解决各自承担任务之间的接口问题，即通信问题。通信需要的时间和代价，会降低软件的生产率。 开发小组的组织有以下原则： 1.软件开发小组的规模不宜太大，人数不能太多，一般3-5人左右为宜。 2.切忌在开发过程中增加人员，这将因增加人员之间的联系而降低效率。

56 例：设一开发小组有4个软件工程师,开发效率为5000行/年，共有6条通信路径,每条路径降低生产率250行/年，则小组生产率为：
四、软件开发小组与软件生产率 例：设一开发小组有4个软件工程师,开发效率为5000行/年，共有6条通信路径,每条路径降低生产率250行/年，则小组生产率为： 5000×4－250×6＝18500（行/年） 如为了加快进度，新增加2人（图8.10），每人效率为840行/年，通信路径增加到15条，此时的小组生产率为： ＋840×2－250×15＝17930 （行/年） 即新增加人，并未提高生产率。

57 软件组织结构 主程序员 秘书 程序员 后备程序员 主程序员式组织结构 项目管理 组长 程序员 … 大型项目的技术管理式组织结构

58 2.5 软件质量保证 　　软件质量是一个软件企业成功的必要条件，其重要性无论怎样强调都不过分。由于软件质量是难于定量度量的软件属性，主要从管理的角度讨论影响软件质量的因素。我们把影响软件质量的因素分成三组： ● 可理解性 ● 可修改性 ● 灵活性 ● 可测试性 产品运行 产品修改 产品转移 ● 可移植性 ● 可重用性 ● 互运行性（与另一个系统结合） ● 正确性 ● 完整性 ● 健壮性 ● 可用性 ● 效 率 ● 风险性

59 2.5.1 软件质量因素的定义 质量因素 定 义 正确性 系统满足规格说明和优化目标的程度，即在预定环境下能正确地完成预期功能的程度。
定　　　义 正确性 系统满足规格说明和优化目标的程度，即在预定环境下能正确地完成预期功能的程度。 健壮性 在硬件故障、操作错误等意外情况下，系统能作出适当反应的程度。 效　率 为完成预定功能，系统需要的计算资源的多少。 完整性 即安全性，对非法使用软件或数据，系统能够控制（禁止）的程度。 可用性 对系统完成预定功能的满意程度。 风　险 能否按照预定成本和进度完成系统看法，并为用户满意的程度。 可理解性 理解和使用该系统的容易程度。 可维护性 诊断和改正运行时所发现错误所需工作量的大小。 灵活性 即适应性，修改或改进正在运行的系统所需工作量的大小。 可测试性 软件易测试的程度。 可移植性 改变系统的软、硬件环境及配置时，所需工作量的大小。 可再用性 软件在其它系统中可被再次使用的程度（或范围）。 互运行性 把该系统与另一个系统结合起来所需工作量。

60 2.5.2 项目经理与软件质量保证 　　项目经理在微软是负责并保证高质量的软件产品按时完成合发布的专职管理人员。 其任务包括： 倾听用户需求；负责产品功能定义、规划和设计；作各种复杂的决策；保证开发团队顺利开展工作及跟踪程序错误等。

61 2.5.3 软件项目的跟踪与控制 在软件项目实施过程中进行跟踪与控制，是软件项目管理的重要内容，也是保证软件质量的重要措施。可用不同的方法进行追踪：  软件质量度量方法有以下三种： 1.精确度量：使用质量度量评价准则进行详细度量，工作量大，但度量精确度也高； 2.全面度量：可以与简易度量并用对各个质量设计评价准则进行度量，工作量可以控制在一定的范围内。 3.简易度量

62 2.6风险分析和管理 2.6.1风险分析 风险的概念 风险与将要发生的事情有关，研究风险就是研究明天将要发生的事情
风险涉及思想、观念、行为、地点、时间等多种因素 风险随条件的变化而改变，人们通过改变、选择、控制与风险密切相关的条件减少、回避风险 改变、选择、控制条件的策略是不确定的

63 软件风险 软件风险和其它风险一样存在不确定性,有些是很难预测的。 对风险的不确定性进行量化，估算某一风险可能带来的损失。
除关注软件项目的一般性风险外，还要关注软件项目的特殊风险，如项目的背景、特殊要求、关键内容、薄弱环节、技术难点、人员状况、工作环境等。

64 软件项目存在各种风险，人们关心的问题： 什么风险会导致软件项目的彻底失败?
顾客需求、开发环境、目标机、时间、成本的改变对软件项目的风险会产生什么影响? 人们必须抓住什么机会、采取什么措施才能有效地减少风险、顺利完成任务?

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

66 软件风险分析包括的部分 风险标识 风险估算 风险规划 风险监控

67 软件风险分析

68 1风险标识 对待风险不能采取回避态度 项目开始时应对一般性风险和特定产品风险进行系统标识，並随着项目的展开不断更新。 一般可预测风险
产品规模、商业影响、客户、过程、技术、环境、人员及经验等。 识别风险的有效方法 风险检测表 为了帮助项目管理人员、项目规划人员,全面了解软件开发过程存在的风险， Boehm 建议设计并使用各类风险检测表，表中条目指明,常見並可预测的风险。有些风险可以预料，有些很难预料。

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

70 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 ≥ (3—10)

71 风险估算 如果第i种风险对整个软件项目的风险估算加权系数是ρi, i=1,2,…,l. 为风险要素的个数,∑ρi＝1，则软件项目风险估算定义为 l R＝∑ρiσi (3—11)  i=1 0≤R≤1当R接近于0时表示风险比较小，R接近于1时表示风险比较大。 当ρiσi 比较大时，表示第i类风险出现并带来不良影响的可能性比较大，必须引起足够重视，设法改善条件，减小σi的值。

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

73 风险评价 定义 用三元组[ri， li， xi]描述风险，i =1,2,3… 其中： ri 表示风险 li 表示风险发生的概率
对大多数软件项目，应该定义性能、成本及进度的风险参考水平值，当某一风险或风险组合值超过水平值时项目被迫停止。

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

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

76 风险表（2／3） 评估值按风险因素： 性能、成本、进度的影响类别求加权平均值 影响类别取值：灾难的1，严重的2，轻微的3，可忽略的4。
对风险表中的风险按照发生概率大小、影响大小，由大至小排序。

77 风险表（3／3） 项目管理者对风险表进行研究后应定义一条中止线，线上的风险较大者应给予特别的关注，线下的风险需要进一步的跟踪、评估、排序。
对风险发生概率较大的事件应引起特别关注，要及早采取措施尽量避免它的发生。

78

79 风险评价和管理 三元组［ri,li,xi］是风险管理的基础 设 高级职员流动给项目带来风险r1,
项目开发时间延长 15%，成本增加 20%．

80 项目负责人采取的风险管理措施 (1)项目开始前控制产生风险的原因。项目开工后应设法减轻风险的影响。
(2)了解项目开发人员变动的原因，在项目开发期间应控制上述原因，尽量减少人员的流动。 (3)在工作方法和技术上采取适当措施，防止因人员流动给工作带来损失。 (4)项目在开发过程中应及时公布并交流项目开发的信息。 (5)建立组织机构，确定文档标准、并及时生成文档。 (6)对工作进行集体复审，使多数人都能了解工作的细节，跟上工作进度。 (7)为关键技术准备后备人员。

81 RMMM计划 风险缓解、监控和管理计划 Risk Mitigation,Monitoring,and Management Plan
将风险分析工作文挡化，成为项目的一部分。 执行RMMM计划需要成本 当软件项目比较大时，可能标出30至40种风险，如果为每种风险定义3至7种风险管理步骤，则风险管理本身就是一个项目。 将Pareto的20-80规则用于软件项目的风险标识，即20%的风险具有0.80的权，而其余的80%风险只有0.20的权。要善于标识属于20%的主要风险，降低RMMM计划的规模和复杂性。

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

83 2.7软件过程及软件成熟度模型CMM 2.7.1 CMM概述
　 软件能力成熟度模型CMM(Capability Maturity Model）是由美国卡内基-梅隆大学软件工程研究所(CMU/SEI)推出的评估软件能力与成熟度的一套标准，该标准基于众多软件专家的实践经验。 从86年开始，开发软件过程成熟度框架。 91年8月SEI将软件过程成熟度框架进化为软件能力成熟度模型（Capability Maturity Model For Software，简称SW-CMM1.0版）。 目前,CMM已经发展到CMMI（Capability Maturity Model Integration)，能力成熟度模型集成阶段。

84 2.7.1 CMM概述 CMM认证已经成为世界公认的软件产品进入国际市场的通行证。 CMM的主要用于：
1.软件过程评估SPA（Software Process Assessment） 2. 软件过程改进SPI（Software Process Improvement） 3. 软件能力评价SCE（Software Capability Evaluation）

85 过程 一个软件过程是指人们开发和维护软件及其相关产品所采取的一系列活动。 规程与方法 有技能经过培训的开发人员 工具和设备
　1. 什么是软件过程 　　一个软件过程是指人们开发和维护软件及其相关产品所采取的一系列活动。 规程与方法 过程 有技能经过培训的开发人员 工具和设备

86 一个组织的软件过程能力为组织提供了预测软件项目开发的数据基础，提供了全面的软件质量保证。
　2. 什么是软件能力成熟度？ 　　由于特定项目的属性和环境限制，项目的实际性能并不能充分反映组织的软件过程能力，但成熟的软件过程可弱化和预见不可控制的过程因素（如客户需求变化或技术变革等）。 一个组织的软件过程能力为组织提供了预测软件项目开发的数据基础，提供了全面的软件质量保证。 软件过程成熟度是指一个软件过程被明确定义、管理、度量和控制的有效程度。成熟意味着软件过程能力持续改善的过程，成熟度代表软件过程能力改善的潜力。

87 软件过程的成熟度等级 CMM将软件过程的成熟度分为5个级别(Maturity Levels),如图所示，5个等级分别是：
1.初始级（Initial） 2.可重复级（Repeatable） 3.已定义级（Defined） 4.已管理级（Managed） 5.优化级（Optimizing） 初始级 可重复级 已定义级 已管理级 优化级 单击鼠标左键 查看相应内容 成熟度等级

88 表描述了SW-CMM不同成熟度等级过程的可视性和过程能力。
1 初始级 有限的可视性 一般达不到进度和成本的目标 2 可重复级 里程碑上具有管理可视性 由于基于过去的性能，项目开发计划比较现实可行 3 已定义级 项目定义软件过程的活动具有可视性 基于已定义的软件过程，组织持续地改善过程能力 4 已管理级 定量地控制软件过程 基于对过程和产品的度量，组织持续地改善过程能力 5 优化级 不断地改善软件过程 组织持续地改善过程能力 可视性与过程能力的比较

89 进行软件过程改进的IDEAL方法