第3章 软件项目管理ppt课件

1、第三章 软件工程管理工程管理的概念软件工程度量软件工程方案与估算风险分析和管理工程进度安排软件质量保证软件配置管理工程管理的谱系人员管理产品管理工程管理过程管理软件工程管理项目参与者项目负责人软件项目组协调通信问题软件范围问题分解确定软件过程模型过程分解确定危险信息确定解决方案 软件工程管理的目的、义务和内容目的 为了使软件工程可以在预定本钱、进度、质量的前提下顺利完成，必需对软件工程工程进展方案、组织、监控和管理 义务制定软件工程的实施方案和方案；对人员进展组织和分工；按照方案进度，以及本钱管理、风险管理、质量管理的要求进展软件开发，完成软件工程的各项要求和义务。 3.1.1 软件度量软件度

2、量的概念软件规模度量软件功能度量3.1 软件工程度量软件度量分类3.1.1.1 度量、估算度量 metrics度量具有数字特征，软件工程范围的度量是软件开发过程、软件资源或软件产品简单属性的定量描画。如，程序规模、操作符个数、程序中错误的个数等。估算 estimation对软件产品、过程、资源进展预测估算可以采用阅历公式、或参考历史资料估算用于事前签署合同、立项、制定任务方案等 软件的外部属性和内部属性外部属性 软件产品、过程、资源与环境的关系如，本钱、效益、劳动消费率、可靠性、可维护性内部属性 软件产品、过程、资源、环境本身的属性如，产品构造、模块化程度、复杂性、程序长度等。产品-过程-资源

3、产品的内部属性程序代码长度 程序功能 模块化 重用性控制流 数据流 模块耦合度与内聚度 产品的外部属性程序的可靠性 可用性 可维护性软件的可了解性 有效性 可移植性 过程的内部属性 任务量 方案和进度 一段时间内某类事件发生的次数 过程的外部属性 本钱 可控制性 可察看性 稳定性资源的内部属性 人 软硬件环境 方法 阅历资源的外部属性 本钱 时间3.1.1.2 面向规模的度量代码行数 LOC或KLOC消费率 Pl=L/E 其中 L 软件工程代码行数 E 软件工程任务量人月 PM Pl 软件工程消费率LOC/PM代码出错率 EQRl=Ne/L 其中 Ne 软件工程的代码错误数 EQRl 每千行代

4、码的错误数每行代码平均本钱 Cl=S/L 其中 S 软件工程总开销元美圆 Cl软件工程每行代码的平均本钱文档与代码比 Dl=Pd/L 其中 Pd 软件工程文档页数 Dl 每千行代码的平均文档数例 软件工程记录项目工作量 PM成本万美元代码行kLOC文档页数 Pd错误数 Ne人数 MAaa-012416.812.1365293Ccc-046244.027.21224865Fff-034331.420.21050646消费率：Pl=L/E=12.1kLoc/24PM=504Loc/PM出错率：EQRl=Ne/L=29个/12.1kLoc=2.4个/kLoc平均本钱：Cl=S/L =168 000美

5、圆/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 是复杂性调

6、理值 Fi 取值 0,1,.,5 当 Fi = 0 时，表示 Fi 不起作用 Fi = 5 时，表示 Fi 作用最大3.1.1.3 面向功能的度量 表3.1 功能点度量丈量参数 值 权值用户输入数 *4 用户输出数 *5 用户查询数 *4 文件数 *7 外部界面数 *7 CT 表3.1中的五个信息量按以下方式取值用户输入数 用户为软件提供的输入参数个数用户输出数 软件系统为用户提供的输出参数个数用户查询数 一个联机输入确定一次查询，软件以 联机输出的方式,实时地产生一个呼应文件数 统计逻辑的主文件个数外部界面数 统计一切机器可读的界面，利用这些 界面可以将信息从一个系统传送到另一 个系统用功能

7、点定义相应的概念消费率： Pf=FP/E 其中 Pf表示每人月完成的功能点数平均本钱：Ci=S/FP 其中 Ci表示每功能点的平均本钱文档与功能点比：Di=Pd/FP 其中 Di表示每个功能点平均具有的文档页数代码出错率：EORi=Ne/FP 其中 EORi表示每个功能点的平均错误个数 面向功能的度量软件规模的功能点度量没有直接涉及软件系统本身的算法复杂性。1986年Jones把软件工程中的算法复杂性要素引入到功能点计算中来，为了防止混淆，我们把Albrecht定义的功能点称为简单功能点，用FPs表示，把Jones推行的功能点称为功能点，用FP表示。推行的功能点包括计算机程序中用于各类问题求解

8、的算法要素，如求解线性代数方程组、遍历二叉树的各个结点、处置中断等等。功能点计算仍用上面的公式,其中CT按表3.2计算。 表3.2 推行的功能点度量 丈量参数 值 权值用户输入数 *4 用户输出数 *5 用户查询数 *4 文件数 *7 外部界面数 *7 算法 *3 CT 对普通的工程计算或事务处置软件，用表3.1和表3.2两种方法计算出来的FP值应该根本上一样对于比较复杂的软件系统 FP比FPs的值高20%35% 面向功能的度量的优缺陷优点与程序设计言语无关，它不仅适用于过程式言语，也适用于非过程式的言语；软件工程开发初期就能根本上确定系统的输入、输出等参数，功能点度量能用于软件工程的开发初期

9、。缺陷它涉及到的客观要素比较多，如各种权函数的取值；信息领域中的某些数据有时不容易采集；FP的值没有直观的物理意义。3.1.1.4 代码行度量与功能点度量的比较代码行度量依赖于程序设计言语，而功能点度量不依赖于程序设计言语。Albrecht和Jones等人对假设干软件采用事后处置的方式分别统计出不同程序设计言语每个功能点与代码行数的关系，用LOC/FP的平均值表示。表3.3阐明，一行Ada言语代码的“功能平均是一行FORTRAN言语代码“功能的1.4倍。一行四代言语代码的“功能平均是一行传统程序设计言语代码“功能的3至5倍。 表3.3 各种言语的LOC/FP(平均值)程序设计言语 LOC/FP

10、(平均值)汇编言语 300COBOL 100FORTRAN 100Pascal 90Ada 70面向对象的言语 30四代言语(4GL) 20代码生成器 153.1.2软件复杂性度量1976年 T.J.McCabe McCabe度量法又称环路复杂性度量,基于程序控制构造的软件复杂性度量模型。程序控制构造图 程序构造对应于有一个入口结点和一个出口结点的有向图图中每个结点对应一个语句或一个顺序流程的程序代码块弧对应于程序中的转移它基于一个程序模块的程序图中环路的个数，因此计算它先要画出程序图。程序图是退化的程序流程图。流程图中每个处置都退化成一个结点，流线变成衔接不同结点的有向弧。McCabe度量法

11、 McCabe用程序控制构造图的巡回秩数V(G)作为程序构造复杂性的度量 V(G) = e-n+2 其中：e为构造图的边数 n为构造图的结点数 可以证明 V(G)等于构造图中有界或无界的封锁区域个数例3.1计算程序控制构造的V(G)值E = 1 E = 3N = 2 N = 3V = 1 V = 2计算程序控制构造的V(G)值E = 4 E = 3N = 4 N = 3V = 2 V = 2计算程序控制构造的V(G)值E = 6N = 5V = 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

12、； (d) e=3,n=3,v=2; (e) e=6,n=5,v=3.例如：在前面的例示中,n11，m13，V(G)mnp131113.p1McCabe建议把V(G)作为模块规模的定量目的，一个模块V(G)的值不要大于10 当V(G)10时，模块内部构培育会变得复杂，给编码和测试带来困难。这种度量的缺陷是： 对于不同种类的控制流的复杂性不能区分 简单IF语句与循环语句的复杂性同等对待 嵌套IF语句与简单CASE语句的复杂性是一样的 模块间接口当成一个简单分支一样处置 一个具有1000行的顺序程序与一行语句的复杂性一样3.2 软件工程方案与估算3.2.1 软件工程方案 软件工程管理人员在开发任务

13、一开场需求进展定量估算。 软件工程方案的目的是提供一个能使工程管理人员对资源、本钱和进度做出合理估算的框架。 这些估算该当在软件工程开场时的一个有限的时间段内做出，并且随着工程的进展定期进展更新。 软件工程方案的目的 软件的范围软件范围包括功能、性能、限制、接口和可靠性。估算开场时，应对软件的功能进展评价，对其进展适当的细化以便提供更详细的细节。由于本钱和进度的估算都与功能有关，因此经常采用某种程度的功能分解。性能的思索包括处置和呼应时间的需求。约束条件那么标识产品本钱、外部硬件、可用存储或其它现有系统对软件的限制。软件与其它系统元素是相互作用的。要思索每个接口的性质和复杂性，以确定对开发资源

14、、本钱和进度的影响。软件开发中的资源3.2.2 软件工程估算常用的估算方法参照曾经完成的类似工程估算待开发工程的本钱和任务量。将大的工程分解成假设干子工程，在估算出每个子工程本钱和任务量之后，再估算整个工程。将软件工程按软件生存周期分解，分别估算出软件工程在软件开发各个阶段的任务量和本钱，然后再把这些任务量和本钱汇总估算整个工程。根据实验或历史数据给出软件工程任务量或本钱的阅历估算公式。四种方法可以同时、单独或组合运用，以便取长补短，提高工程估算的精度和可靠性。 采用分解技术估算软件工程应思索系统集成时需求的任务量。为了实现软件工程估算，实际中开发了大量的软件工程自动估算工具，用以支持软件任务

15、量或本钱估算。分解技术采用分而治之的战略进展软件工程估算.将工程分解为假设干个主要的功能及相关的软件工程活动,经过逐渐求精的方式进展本钱及任务量估算。阅历估算模型可用于补充分解技术自动估算工具实现一种或多种分解技术或阅历模型，与人机交互结合，自动估算将是很好的选择。3.2.2.1 代码行、功能点和任务量估算软件工程的规模是影响软件工程本钱和任务量的重要要素。软件工程代码行和功能点估算是本钱和任务量估算的根底。采用上面的估算方法可以估算出LOC或FP的乐观值a，悲观值b和普通值m，然后根据以下加权公式计算出期望值 e=(a4mb)6 希望LOC或FP的值落在区间a,b之外的概率极小 当LOC或F

16、P的期望值估算出来之后，根据以前软件工程开发的平均消费率LOC/PM或FP/PM就可以计算出任务量。如，软件工程的规模估算为310FP，以前完成的软件工程的消费率为5.5FP/PM，于是任务量估算为E=310/5.5=56PM。例 3.2 估算计算机辅助设计软件工程将CAD工程按功能分解为七个子工程用户界面和控制；二维几何分析；三维几何分析；数据库管理；计算机图形显示；外设控制；设计分析。表3.4给出七个子工程代码行的乐观估计、悲观计和普通估计值，然后计算出加权平均值。 估算计算机辅助设计软件工程 分析七个子工程的规模复杂性和难度，参照以前开发类似工程的阅历给出开发每行代码的平均本钱，每月开发

17、的代码行数。 用这两组数据计算出七个子工程的开发本钱和任务量。 最后汇总的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 (人月)用户界面控制17

18、90 2400 2650 2340 14 315 32760 7.4 二维几何分析4080 5200 7400 5380 20 220 107600 24.4三维几何分析4600 6900 8600 6800 20 220 000 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

19、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 11262

20、5 227250 708075 3.2.2.2 阅历估算模型之一 CoCoMo模型计算机软件的估算模型是根据以前完成工程的实践数据导出的，用于软件工程的方案阶段。 模型是根据“从前的，“部分的数据得出的，估算模型不能够完全适用于当前一切的软件工程和全部开发环境。这些模型的计算结果仅供参考。 两个常用的估算模型 CoCoMo模型 Putnam模型 CoCoMo模型1981年Boehm提出“构造性本钱模型(Constructive Cost Model)，简称CoCoMo模型。它是在静态、单变量模型的根底上构造出来的。 CoCoMo模型分为根本、中间、详细三个层次，分别用于软件开发的三个不同阶段。

21、根本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把软件划分为组织型、半独立型和嵌入型三类，允许不同运用领域和复杂程度的软件按照三类软件的适用范围

22、选取相应的参数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所示。中间 CoCo

23、Mo模型表3.7 中间CoCoMo模型参数 软件类型 a b 组织型 3.2 1.05 半独立型 3.0 1.12 嵌入型 2.8 1.20 CoCoMo模型 任务量调理因子EAF与软件产品属性、计算机属性、人员属性、工程属性有关软件产品属性 软件可靠性、软件复杂性、数据库的规模。计算机属性 程序执行时间、程序占用内存的大小、软件开发环境的变化、软件开发环境的呼应速度。人员属性 分析员的才干、程序员的才干、有关运用领域的阅历、开发环境的阅历、程序设计言语的阅历工程属性 软件开发方法的才干，软件工具的质量和数量、软件开发的进度要求。 CoCoMo 模型四种属性共15个要素。每个要素调理因子 Fi

24、, i=1,2,.,15,的值分为： 很低、低、正常、高、很高、极高，共六级。正常情况下 Fi=1。Boehm引荐的Fi值范围 (0.70, 0.85, 1.00, 1.15, 1.30, 1.65) 当15个Fi的值选定后，EAF的计算如下 EAFF1*F2*F15 CoCoMo 模型 调理因子集的定义和调理因子定值是由统计结果和阅历决议的。不同的软件开发组织，在不同的历史时期，随着环境的变化，这些数据能够改动。 运用中间CoCoMo模型可以估算开发软件产品的任务量，比较各种开发方案的任务量。 例3.3 用根本CoCoMo模型估算例3.2任务量、开发时间和工程开发人数在例3.2中，目的代码行

25、数为 33.3 KLOCCAD软件开发属于中等规模、半独立型从表3.7中查到a=3.0，b=1.12。代入公式(3-1) E = 3.0L1.12 = 3.033.31.12 = 152 PM 将E的估算值代入公式 (3-2) 取 C=2.5 d=0.35 D=2.5E0.35 =2.5*1520.35 =14.5 M 建议参与工程开发的人数 N=E/D=152/14.511例中计算出来的11人是粗略估计在软件工程开发过程中，11个人不能够都有一样的才干和个性，一样的阅历和知识构造，并且在软件开发的各个阶段对人的要求也不同。 CoCoMo模型 假设干人共同开发一个软件工程还应该添加他们之间相互

26、通讯和交换意见的额外任务量。 设 N个程序员组成小组，实现一样规模的程序，相互通讯数为 =N(N-1)/2 每次通讯和交换意见的平均任务量为 那么 添加的通讯开销为 EcN(N-1)/2 (3-4)例3.4 计算一个程序的通讯开销 3人和5人开发一个程序相互通讯和交换意见的关系如下图 将N=3和N=5分别代入公式(3-4) Ec(3)3(3-1)/23 Ec(5)5(5-1)/210 CoCoMo模型 由N个程序员组成的小组共同开发一个程序总的任务量ET满足 ET=E+Ec (3-5)程序员小组的消费率是 PG=LOC/(E+Ec) (3-6)程序员小组消费率和单个程序员消费率的比为 Rp=E

27、/(E+Ec) (3-7) 随着程序员小组人数的添加,EcN2/2，程序员小组的消费率将会下降。 模型阐明 盲目添加程序员人数会推迟软件完成的日期 3.2.2.3阅历估算模型之二：Putnam模型 1978年，Putnam提出了大型软件工程任务量(普通在30人年以上)估算模型。它是一个动态多变量模型，适用于软件开发的各个阶段，估算模型以大型软件工程的实测数据为根底，导出任务量分布曲线。该曲线与著名的Rayleigh-Norden (R-N)曲线类似，它描画了开发任务量，开发时间和软件代码行数之间的关系。 Putnam模型方程 L = CK E1/3 td4/3 (3-8)其中：L 表示源程序代

28、码行数 td 表示开发时间 Ck 表示技术形状常数 E 表示任务量 (以人年记，包括维护)Putnam模型提示了软件工程的任务量、软件开发时间和程序代码长度三者之间的关系Putnam模型差的软件开发环境 软件开发没有方法学的支持，缺乏对文档的评审，采用批处置方式。普通的软件开发环境 应有软件开发方法学的支持，有适宜的文档和评审，采用交互处置方式。好的软件开发环境 应采用CASE工具和集成化CASE环境。 CK= 2000 比较差的软件开发环境 8000 普通的软件开发环境 11000 比较好的软件开发环 Putnam模型 由(2-18) 3 3 4 E L / (CK*td ) (3-9)td

29、对应于Rayleigh-Norden曲线的最大值，表示软件交付时任务量最大，参与软件工程的人最多。当任务量估算出来之后，利用每人年的开销($/PY)可以估算本钱。公式(3-9)阐明，开发软件工程的任务量与交货时间的4次方成反比，将0.9td替代(3-9)式的td计算E发现，提早10%的时间要添加52%的任务量，降低了软件开发消费率。软件开发过程中人员与时间的折衷是一个非常重要的问题。Putnam模型3.3.1风险分析风险的概念风险与将要发生的事情有关，研讨风险就是研讨明天将要发生的事情风险涉及思想、观念、行为、地点、时间等多种要素风险随条件的变化而改动，人们经过改动、选择、控制与风险亲密相关的

30、条件减少、逃避风险改动、选择、控制条件的战略是不确定的3.3风险分析和管理软件风险软件风险和其它风险一样存在不确定性,有些是很难预测的。对风险的不确定性进展量化，估算某一风险能够带来的损失。除关注软件工程的普通性风险外，还要关注软件工程的特殊风险，如工程的背景、特殊要求、关键内容、薄弱环节、技术难点、人员情况、任务环境等。 软件工程存在各种风险，人们关怀的问题：什么风险会导致软件工程的彻底失败?顾客需求、开发环境、目的机、时间、本钱的改动对软件工程的风险会产生什么影响?人们必需抓住什么时机、采取什么措施才干有效地减少风险、顺利完成义务? 不同类型的风险工程风险预算、进度、人力、资源、客户及需求

31、工程的复杂度、规模、构造的不确定性等技术风险设计、实现、接口、验证和维护规约的二义性、技术的不确定性、陈旧的技术、领先的技术商业风险无需求的产品、策路风险、管理风险、预算风险软件风险分析包括的部分 风险标识 风险估算 风险规划 风险监控软件风险分析1风险标识对待风险不能采取逃避态度 工程开场时应对普通性风险和特定产品风险进展系统标识，並随着工程的展开不断更新。普通可预测风险 产品规模、商业影响、客户、过程、技术、环境、人员及阅历等。识别风险的有效方法 风险检测表 为了协助工程管理人员、工程规划人员,全面了解软件开发过程存在的风险， Boehm 建议设计并运用各类风险检测表，表中条目指明,常見並

32、可预测的风险。有些风险可以预料，有些很难预料。例3.6 人员配备风险检测表(1) 开发人员的程度如何。(2) 开发人员在技术上能否配套。(3) 开发人员的数量如何。(4) 开发人员能否可以自始至终地参与软件开发任务。(5) 开发人员能否可以集中全部精神投入到软件开发任务。(6) 开发人员对本人的任务能否有正确的期望。(7) 开发人员能否接受过必要的培训。(8) 开发人员的流动能否可以保证任务的延续性。上述问题可以选用0,1,2,3,4,5来回答。完全一定取值为0，反之为5，中间情况分别取值1,2,3,4值越大表示风险越大。人员配备风险检测表反映了人的要素给软件工程带来的风险。2风险估算 假设某

33、一风险检测表由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 (310)风险估算 假设第i种风险对整个软件工程的风险估算加权系数是i, i=1,2,l. 为风险要素的个数,i1，那么软件工程风险估算定义为 lRii (311) i=10R1当R接近于0时表示风险比较小，R接近于1时表示风险比较大。当ii 比较大

34、时，表示第i类风险出现并带来不良影响的能够性比较大，必需引起足够注重，设法改善条件，减小i的值。3 风险评价和管理 风险评价是风险管理的重要步骤义务 进一步审查风险预测的精度；更新风险优先次序；思索控制和/或防止能够发生风险的方法。风险评价定义 用三元组ri， li， xi描画风险，i =1,2,3 其中： ri 表示风险 li 表示风险发生的概率 xi 表示风险产生的影响 对大多数软件工程，应该定义性能、本钱及进度的风险参考程度值，当某一风险或风险组合值超越程度值时工程被迫停顿。风险评价的步骤1 定义工程的风险参考程度值；2 建立三元组，给出相应的参考程度值；3 预测一组临界点，定义工程终止

35、区域；4 预测什么样的风险组合会影响参考程度 值风险表 13 风险 类别 概率 影响 RMMM123工程开场时应在第一列列出一切风险;第二列给出风险类别；第三列给出每种风险发生的概率；第四列给出各种风险产生影响的评价值；第五列给出风险缓解、监控和管理方案。风险表23评价值按风险要素： 性能、本钱、进度的影响类别求加权平均值影响类别取值：灾难的1，严重的2，细微的3，可忽略的4。对风险表中的风险按照发生概率大小、影响大小，由大至小排序。风险表33工程管理者对风险表进展研讨后应定义一条中止线，线上的风险较大者应给予特别的关注，线下的风险需求进一步的跟踪、评价、排序。对风险发生概率较大的事件应引起特

36、别关注，要及早采取措施尽量防止它的发生。风险评价和管理三元组ri,li,xi是风险管理的根底设 高级职员流动给工程带来风险r1, 根据历史的阅历或直观觉得，高级职员分开课题组的概率 l1 = 70%, 这一风险导致事件 x1 发生 工程开发时间延伸 15%，本钱添加 20%工程担任人采取的风险管理措施(1)工程开场前控制产生风险的缘由。工程开工后应设法减轻风险的影响。(2)了解工程开发人员变动的缘由，在工程开发期间应控制上述缘由，尽量减少人员的流动。(3)在任务方法和技术上采取适当措施，防止因人员流动给任务带来损失。(4)工程在开发过程中应及时公布并交流工程开发的信息。(5)建立组织机构，确定

37、文档规范、并及时生成文档。(6)对任务进展集体复审，使多数人都能了解任务的细节，跟上任务进度。(7)为关键技术预备后备人员。 RMMM方案风险缓解、监控和管理方案 Risk Mitigation,Monitoring,and Management Plan 将风险分析任务文挡化，成为工程的一部分。执行RMMM方案需求本钱 当软件工程比较大时，能够标出30至40种风险，假设为每种风险定义3至7种风险管理步骤，那么风险管理本身就是一个工程。将Pareto的20-80规那么用于软件工程的风险标识，即20%的风险具有0.80的权，而其他的80%风险只需0.20的权。要擅长标识属于20%的主要风险，降低

38、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)软件工程开发组织根据

39、工程和资源情况制定软件工程开发的初步方案和交付软件产品的日期。 软件开发组织希望按照第二种方式安排任务进度。多数场所遇到的都是比较被动的第一种方式。 对软件工程的进度安排比对软件本钱的估算要求更高。本钱的添加可以经过提高产品定价或经过大批量销售得到补偿，而工程进度安排不当会引起顾客不满，影响市场销售。PERT技术和CPM方法PERT技术叫做方案评审技术程序评价与审查技术CPM方法叫做关键途径法它们都是安排开发进度，制定软件开发方案最常用的方法。它们都采用网络图来描画一个工程的义务网络，也就是从一个工程的开场到终了，把该当完成的义务用图的方式表达出来。通常用两张图来表示。一张图给出工程的一切义务

40、，另一张图给出应按照什麽次序完成这些义务，给出各义务的衔接。PERT和CPM方法提供了定量描画工具，包括关键途径。完成关键途径上一切义务时间的总和，就是工程开发所需求的最短时间。用统计模型估算开发每个子义务需求的任务量和时间。计算各子义务的最早启动时间和最迟启动时间。 例：某一工程进入编码阶段思索如何安排三个模块A,B,C的开发任务，其中A是公用模块，B和C的测试有赖于A的调试C为现成已有的模块，但对它要做了解之后做部分修正。直到A,B,C做组装测试为止。图中各边表示要完成的义务，数字表示完成该义务的继续时间0为起点，8为终点。850412367起点A编码B编码A测试C修正C了解A调试BC组装

41、测试C测试B测试B调试C调试68687886795终点开发模块义务网络图BAQPPQNo.0N0.1N0.2在组织较为复杂的工程时或需求对特定的义务进一步做更为详细的方案时,可以运用分层的义务网络图。分层义务网络图一个概念开发的义务网络软件工程的进度安排 1.义务分配、人力资源分配、时间分配要与工程进度相协调。 2.义务分解与并行化 3.任务量分布 4-2-4分布原那么 4.工程进度安排 运用程序评价与审查技术(PERT)或关键途径方法(CPM) 生成义务网络图。软件工程的进度安排进度安排的图形方法甘特图方案完成文档编写ABCDE1 2 3 4 5 6 7 8 9 10 11 12 13 14

42、 义务周当前进度完成评审时间表的例子 3.5 软件质量度量1软件质量度量及三层次度量模型2软件质量要素3软件质量要素评价准那么软件质量度量及三层次度量模型软件质量是软件的生命，它直接影响软件的运用与维护。质量低下的软件不但影响基于计算机系统的任务效率，而且还能够给用户带来灾难性的后果。提高软件产质量量是软件工程的首要义务。软件开发人员、管理人员、维护人员和用户在软件开发、维护、运用过程中所处位置不同，对软件质量的了解和要求也不同。软件质量度量1976年Boehm提出了定量评价软件质量的概念，给出了60个软件质量度量公式和软件质量度量的层次模型1978年Walters和McCall提出了包括质量

43、要素(factor)、准那么(criteria)和度量(metric)的三层次软件质量度量模型G.Murine又提出了软件质量度量技术SQM用于定量地评价软件质量1985年国际规范化组织(ISO)提出了软件质量度量(SQM)任务报告 三层次软件质量度量模型 质量要素 (factor)评价准那么 (criteria)度 量 (metric) 软件质量要素软件质量要素直接影响软件开发过程各个阶段的产质量量由于对软件质量了解的不断深化，软件质量要素不是一成不变的McCall等人给出的软件质量要素共11个，分为三类。 McCall的软件质量要素软件的运转特征 正确性 可靠性 有效性 完好性 可用性软件

44、接受修正的才干 可维护性 灵敏性 可测试性软件对新环境的顺应程度 可移植性 可重用性 可互操性 软件的属性正确性(Correctness)程序满足规格阐明及完成用户目的的程度。完好性(Integrity)控制未被授权人员访问程序和数据的程度。可用性(Usability)学习运用软件的难易程度。包括：操作软件、为软件预备输入数据，解释软件输出结果。灵敏性(Flexibility) 改动一个操作程序所需的任务量。可测试性(Testability) 测试程序使之具有预定功能所需的任务量。可互操性(Interoperability) 两个或多个系统交换信息并相互运用已交换信息的才干。 软件质量要素之间的关系软件质量要素之间有正相关，也有负相关。系统设计过程中应根据详细情况对各种