1、软件项目管理,2,第二章,项目管理是广泛应用于各种工程、金融等技术管理过程，管理的好坏决定了工程的成败。软件及IT 行业，尤其是软件产品的特殊性，软件项目管理对于保证软件产品的质量具有极为重要的作用，是决定一个产品或企业能否成功的最重要的指标。,2.1 软件项目管理概述,不可见性 不确定性 人员流动性,2.1 软件项目管理概述,随着软件的规模和复杂度的不断增大，开发人员的增加以及开发时间的增长，这些都增加了软件项目管理的难度。例如：Windows 2000的开发 是微软公司历史上最艰巨的任务，仅核心部门的的成员就有2500人，测试用的代码就有1000万行，测试中所用到的脚本程序就有6500种。
2、象规模如此之大的软件系统，如果没有科学的、规范的、有效的管理，是不可能成功的。因此软件项目管理成为软件工程的重要研究内容之一。,2.1.1 软件项目管理的任务,过程 (process),人员 （people）,工具 (tools),项目 (Project),一、软件项目管理的“4P”,二、软件项目管理过程,软件项目管理，是对整个软件生存期的所有活动进行管理。主要过程包括： 1.项目启动确定系统范围、组建项目团队、建立项目环境。 2.项目规划确定项目活动、项目成本估算、制定进度计划 3.项目实施监控项目执行、管理项目风险、控制项目变更 4.项目收尾项目验收、软件安装培训、项目总结,2.1.1 软
3、件项目管理的任务,2.1.1 软件项目管理的任务,三、软件项目管理与过程管理的关系,软件项目管理用于保证项目目标的成功实现，过程管理用于辅助项目管理，将最佳的项目实践用于软件开发过程。,2.1.2 项目管理的主要活动,软件项目的规划 人员的组织管理 软件风险管理 软件配置管理,包括：可行性分析软件项目度量 软件成本估算 软件计划,2.1.2 项目管理的主要活动,包括： 人员配备原则 人员配备模式 软件团队建设 软件项目沟通活动,软件项目的规划 人员的组织管理 软件风险管理 软件配置管理,2.1.2 项目管理的主要活动,包括： 风险识别 风险分析 风险规划 风险监控,软件项目的规划 人员的组织管
4、理 软件风险管理 软件配置管理,2.1.2 项目管理的主要活动,是为了有效地控制和管理软件开发过程中的变化，进行标识、组织和控制修改的技术。配置管理活动： 配置项的标识 版本管理 系统构建 变更控制,软件项目的规划 人员的组织管理 软件风险管理 软件配置管理,软件度量,软件度量的概念 软件规模度量 软件功能度量,软件项目度量,软件度量分类,度量、估算,度量 metrics度量具有数字特征，软件工程范围的度量是软件开发过程、软件资源或软件产品简单属性的定量描述。 如，程序规模、操作符个数、程序中错误的个数等。 估算 estimation对软件产品、过程、资源进行预测估算可以采用经验公式、或参考历
5、史资料估算用于事前签订合同、立项、制定工作计划等,面向规模的度量,代码行数 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 每千行代码的平均文档数,例 软件项目记录,生产率：Pl=L/E=12.1kLoc/24PM=504Loc/PM 出错率：EQRl=Ne/L=29
6、个/12.1kLoc=2.4个/kLoc 平均成本： Cl=S/L =168 000美元/12.1kLoc= 13.88美元/Loc 每千行代码的平均文档页数： Dl=Pd/L=365Pd/ 12.1kLoc=30.16Pd/kLoc,规模度量的优缺点,用软件代码行数估算软件规模简单易行。 缺点 代码行数的估算依赖于程序设计语言的功能和表达能力； 采用代码行估算方法会对设计精巧的软件项目产生不利的影响； 在软件项目开发前或开发初期估算它的代码行数十分困难； 代码行估算只适用于过程式程序设计语言，对非过程式的程序设计语言不太适用等等。,根据事务信息处理程序的基本功能定义的，在系统设计初期可以估算
7、出软件项目的规模FP=CT*0.65+0.01*Fi 其中：CT按表2.1计算Fi 是复杂性调节值Fi 取值 0,1,.,5 当 Fi = 0 时，表示 Fi 不起作用Fi = 5 时，表示 Fi 作用最大,面向功能的度量,表 功能点度量,测量参数 值 权值 用户输入数 *4 用户输出数 *5 用户查询数 *4 文件数 *7 外部界面数 *7 CT ,表中的五个信息量按下列方式取值用户输入数 用户为软件提供的输入参数个数 用户输出数 软件系统为用户提供的输出参数个数 用户查询数 一个联机输入确定一次查询，软件以联机输出的形式,实时地产生一个响应 文件数 统计逻辑的主文件个数 外部界面数 统计所
8、有机器可读的界面，利用这些界面可以将信息从一个系统传送到另一 个系统,用功能点定义相应的概念 生产率：Pf=FP/E其中 Pf表示每人月完成的功能点数 平均成本：Ci=S/FP 其中 Ci表示每功能点的平均成本 文档与功能点比：Di=Pd/FP 其中 Di表示每个功能点平均具有的文档页数代码出错率：EORi=Ne/FP 其中 EORi表示每个功能点的平均错误个数,面向功能的度量,软件规模的功能点度量没有直接涉及软件系统本身的算法复杂性。 1986年Jones把软件项目中的算法复杂性因素引入到功能点计算中来，为了避免混淆，我们把Albrecht定义的功能点称为简单功能点，用FPs表示，把Jone
9、s推广的功能点称为功能点，用FP表示。 推广的功能点包括计算机程序中用于各类问题求解的算法因素，如求解线性代数方程组、遍历二叉树的各个结点、处理中断等等。 功能点计算仍用上面的公式,其中CT按表2.2计算。,表 推广的功能点度量,测量参数 值 权值 用户输入数 *4 用户输出数 *5 用户查询数 *4 文件数 *7 外部界面数 *7 算法 *3 CT 对一般的工程计算或事务处理软件，用表2.1和表2.2两种方法计算出来的FP值应该基本上相同 对于比较复杂的软件系统FP比FPs的值高20%35%,面向功能的度量的优缺点,优点 与程序设计语言无关，它不仅适用于过程式语言，也适用于非过程式的语言；
10、软件项目开发初期就能基本上确定系统的输入、输出等参数，功能点度量能用于软件项目的开发初期。 缺点 它涉及到的主观因素比较多，如各种权函数的取值； 信息领域中的某些数据有时不容易采集； FP的值没有直观的物理意义。,代码行度量与功能点度量的比较,代码行度量依赖于程序设计语言，而功能点度量不依赖于程序设计语言。 Albrecht和Jones等人对若干软件采用事后处理的方式分别统计出不同程序设计语言每个功能点与代码行数的关系，用LOC/FP的平均值表示。 表2.3表明，一行Ada语言代码的“功能”平均是一行FORTRAN语言代码“功能”的1.4倍。一行四代语言代码的“功能”平均是一行传统程序设计语言
11、代码“功能”的3至5倍。,表 各种语言的LOC/FP(平均值),程序设计语言 LOC/FP(平均值) 汇编语言 300 COBOL 100 FORTRAN 100 Pascal 90 Ada 70 面向对象的语言 30 四代语言(4GL) 20 代码生成器 15,软件复杂性度量,1976年 T.J.McCabe McCabe度量法又称环路复杂性度量,基于程序控制结构的软件复杂性度量模型。 程序控制结构图 程序结构对应于有一个入口结点和一个出口结点的有向图 图中每个结点对应一个语句或一个顺序流程的程序代码块 弧对应于程序中的转移 它基于一个程序模块的程序图中环路的个数，因此计算它先要画出程序图。
12、 程序图是退化的程序流程图。流程图中每个处理都退化成一个结点，流线变成连接不同结点的有向弧。,McCabe度量法,McCabe用程序控制结构图的巡回秩数V(G)作为程序结构复杂性的度量 V(G) = e-n+2其中：e为结构图的边数n为结构图的结点数可以证明 V(G)等于结构图中有界或无界的封闭区域个数,例 计算程序控制结构的V(G)值,E = 1 E = 3 N = 2 N = 3 V = 1 V = 2,计算程序控制结构的V(G)值,E = 4 E = 3 N = 4 N = 3 V = 2 V = 2,计算程序控制结构的V(G)值,E = 6 N = 5 V = 3,例2.1 计算如图所
13、示程序控制结构图的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.,这种度量的缺点是：对于不同种类的控制流的复杂性不能区分简单IF语句与循环语句的复杂性同等看待嵌套IF语句与简单CASE语句的复杂性是一样的模块间接口当成一个简单分支一样处理一个具有1000行的顺序程序与一行语句的复杂性相同,软件项目估算,常用的估算方法 参照已经完成的类似项目估算待开发项目的成本和工作量。 将大的项目分解成若干子项目，在估算出每个子项目成本和工作量之后，再估算整个项目。 将软件项目按软件生
14、存周期分解，分别估算出软件项目在软件开发各个阶段的工作量和成本，然后再把这些工作量和成本汇总估算整个项目。 根据实验或历史数据给出软件项目工作量或成本的经验估算公式。,四种方法可以同时、单独或组合使用，以便取长补短，提高项目估算的精度和可靠性。 采用分解技术估算软件项目应考虑系统集成时需要的工作量。 为了实现软件项目估算，实践中开发了大量的软件项目自动估算工具，用以支持软件工作量或成本估算。,分解技术 采用”分而治之”的策略进行软件项目估算.将项目分解为若干个主要的功能及相关的软件工程活动,通过逐步求精的方式进行成本及工作量估算。 经验估算模型 可用于补充分解技术 自动估算工具 实现一种或多种
15、分解技术或经验模型，与人机交互结合，自动估算将是很好的选择。,代码行、功能点和工作量估算,软件项目的规模是影响软件项目成本和工作量的重要因素。 软件项目代码行和功能点估算是成本和工作量估算的基础。 采用上面的估算方法可以估算出LOC或FP的乐观值a，悲观值b和一般值m，然后根据下列加权公式计算出期望值e=(a4mb)6 希望LOC或FP的值落在区间a,b之外的概率极小,当LOC或FP的期望值估算出来之后，根据以前软件项目开发的平均生产率LOC/PM或FP/PM就可以计算出工作量。 如，软件项目的规模估算为310FP，以前完成的软件项目的生产率为5.5FP/PM，于是工作量估算为E=310/5.
16、5=56PM。,2.2 成本估算技术,成本估算是可行性分析的重要依据，也是软件管理的重要内容，直接影响到软件开发的风险。软件开发成本主要是指软件开发过程中所花费的工作量及相应的代价，即主要是人的劳动的消耗。以软件计划、需求分析、设计、编码到测试的软件开发全过程所花费的代价为依据。一个大型、复杂项目，由于其项目的度，成本估算并不是一件简单的事，必须建立相应的估算模型，按照一定的方法、技术来进行估算。,一、影响成本估算的因素1. 软件人员的业务水平2. 软件产品的规模及复杂度规模：按YOURDON分类法分为 超小型,小型,中型,大型,超大型,极大型。复杂度：应用程序， 实用程序，系统程序低 高,3
17、.开发所需时间对确定规模、复杂度的软件存在一个”最佳开发时间”。 4.软件开发技术水平指开发方法、工具、语言等，技术水平高，效率高。 5.软件可靠性要求 可靠性要求愈高，成本愈高。,2.2 成本估算技术,2.2 成本估算技术,二.软件成本的估算量源代码行（LOC） 机器指令行/非机器语言的执行步开发工作量 人-月（PM） 人-年（PY） 人-日（PD） 软件生产率 LOG/PM ￥/LOC ￥/PM软件开发时间,其中:ai 估计的最小行数 bi 估计的最大行数 mi 最可能的行数,2.2.1 专家估算模型即源代码行估算模型（Deiphi技术）由Rand公司提出的Deiphi技术，是由n位专家进
18、行成本估算。每位专家根据系统规格说明书，反复讨论给出ai、 bi及 mi的值，并按照下式反复估算源代码的期望值Li ，期望中值L。,将估算的源代码行数，乘以根据经验推算的每行源代码所需成本，即为该软件的成本。,2.2.2 IBM 估算模型1977年由Waiston(威斯通) 和 Felix(费利克斯) 总结了IBM联合系统分部（FSD）负责的个项目的数据，利用最小二乘法拟合，得到如下估算公式：工 作 量： E=5.2*L （PM）项目持续时间： D=4.1*L （月）人员需要量： S=0.54*E （人）文 档 数： DOC=49*L （页）其中：L 源代码行，以千行计。,IBM估算模型是一种
19、静态单变量模型，它利用已估算的结果，如源代码行，来估算各种资源的需求量 但IBM 估算模型不是一种通用模型，因此应用中应根据具体实际情况调整模型中的参数,2.2.3 普特南(Putnam) 估算模型, Ck td,普特南Putnam 估算模型是一种动态多变量模型，是根据一些大型项目中工作量的分布情况推导出来的。,其中： L源代码行， K 所需人力（PY）td 开发时间, CK 技术水平常数其值与开发环境有关。（差：2500-2000，正常：10000-8000，好：12500-11000）, Ck K td,大型项目的工作量分布情况,2.2.3 Putnam 估算模型,COCOMO模型（Con
20、structive Cost Model）由TRW公司开发，是由Boehm提出的结构型成本估算模型，其特点是精确、易用。是一种层次模型，按照其祥细程度分为三级：即基本的COCOMO模型、中间的COCOMO模型和详细的COCOMO模型。,该模型主要对工作量（单位：PM）和进度TDEP（单位：月）进行估算。模型中考虑到估算量与开发环境有关，将开发项目分为三类：,9.5.5 COCOMO模型,2.2.4 COCOMO模型,2.2.4 COCOMO模型,组织型（Organic）规模5万，较简单,开发人员对产品目标理解充分，经验丰富，对软件开发环境熟悉。大多数应用软件及老的操作系统、编译系统属此类。,嵌
21、入型（Embadded)软件、硬件关系紧密,操作有限制条件,对接口、数据结构,算法要求较高。如大型复杂的事务处理系统，大型、超大型的操作系统,军事指挥系统,航天控制系统等,半独立型（Semidetached)对项目要求界于上述两者之间,规模复杂度中等。如新操作系统,大型数据库,生产控制等软件属此类。,9.5.5 COCOMO模型, 基本的COCOMO模型（静态单变量模型）,其中： MM 工作量（PM），KLOC 估计的源代码行 Cl 模型系数， 模型指数 . Cl、 取决于开发项目的模式为组织型、半独立型或嵌入型。,下表是根据63个项目的数据统计结果，按照基本的COCOMO模型估算的工作量和进
22、度。,其中： fi 成本因素包括： 生产因素（可靠性，数据库规模，软件复杂度） 计算机因素（时间约束，存储约束，环境变更率，计算机换向时间） 人员因素（系统分析员能力、经验，程序员能力，开发人员环境知识，程序时间语言知识） 项目工程因素（设计技术，软件工具，进度限制约束）, 详细的COCOMO模型按照开发阶段给出更加详细的成本因素fi。, 中间的COCOMO模型进一步考虑了15种影响软件工作量的因素，更加合理的估算软件工作量和进度。,2.2.5 成本估算方法,1、自顶向下的估算方法据以前完成的同类项目的总成本推算，再将其分配到各开发任务中。特点：简便、估算工作量小、误差大。 2、自底向上的估算
23、法估算每一子任务的开发工作量，将它们累加起来。特点：精确度高、但缺少子任务（模块）间的联系。 3、差别估计法与已完成的项目进行类比，对不同部分另行估算。特点：估算较精确、但区分类比较困难。,对于大型软件项目的估算处理，处理手段主要是分解和类比。一般有以下方式：,注意：通常使用综合方法对实际项目进行估算。,2.3 软件开发进度计划,软件开发进度计划安排是一件困难的任务，尽可能并行地安排任务，还要考虑各个子任务之间的相互联系，又要预见潜在的问题，提供意外事件的处理意见。,描述计划进度的主要工具：一般的表格工具、甘特图、PERT技术与CPM方法。,、一般的表格工具例如：进度表,进度表,2.甘特图（G
24、antt Chart）用水平线段表示任务的工作阶段；线段的起点和终点分别表示任务的开始和完成时间，线段的长度表示完成任务所需的时间。下图给出了具有五个任务的甘特图。,甘特图,周,优点：标明了各任务的计划进度和当前进度。能够动态反映软件开发的进展情况。 缺点：不能够反映多个任务之间的复杂逻辑关系。,3. PERT技术和CPM方法PERT（Program evaluation & review technique)计划评审技术或CPM（Critical path method）关键路径法，都是采用网络图来描述项目的进度安排。如图描述了开发模块A、B、C的任务网络图。各边上所标注的数字为该任务所持续
25、的时间，数字结点为任务的起点和终点。,假设红线为关键路径，即完成所有任务的主要路径。,2.4 人员配备与组织,三、评价人员的条件1、固掌握计算机软件的基本知识和技能；2、善于分析和综合问题，具有严密的逻辑思维能力；3、工作踏实、细致、不靠运气，遵循标准和规范，具有严格的科学作风；4、工作中耐心、有毅力、有责任心；5、善于听取意见，善于团结协作，有良好的人际关系；6、具有良好的书面和口头表达能力。,合理的配备人员是成功的完成软件项目的切实保证。一、项目各阶段所需人员按Putnam_Norden 曲线分配。,二、配备人员遵守的原则重质量;重培训;阶梯提升：,四、软件开发小组与软件生产率,随着软件项
26、目规模的增大，需要组成开发小组共同承担软件开发项目中的某一任务，于是人与人之间必须通过交流来解决各自承担任务之间的接口问题，即通信问题。通信需要的时间和代价，会降低软件的生产率。 开发小组的组织有以下原则：1.软件开发小组的规模不宜太大，人数不能太多，一般3-5人左右为宜。2.切忌在开发过程中增加人员，这将因增加人员之间的联系而降低效率。,四、软件开发小组与软件生产率,例：设一开发小组有4个软件工程师,开发效率为5000行/年，共有6条通信路径,每条路径降低生产率250行/年，则小组生产率为：50004250618500（行/年）,如为了加快进度，新增加2人（图8.10），每人效率为840行/
27、年，通信路径增加到15条，此时的小组生产率为： 2000084022501517930 （行/年）即新增加人，并未提高生产率。,软件组织结构,软件质量是一个软件企业成功的必要条件，其重要性无论怎样强调都不过分。由于软件质量是难于定量度量的软件属性，主要从管理的角度讨论影响软件质量的因素。我们把影响软件质量的因素分成三组：,2.5 软件质量保证, 可移植性 可重用性 互运行性（与另一个系统结合）, 正确性 完整性 健壮性 可用性 效 率 风险性, 可理解性 可修改性 灵活性 可测试性,2.5.1 软件质量因素的定义,项目经理在微软是负责并保证高质量的软件产品按时完成合发布的专职管理人员。其任务包
28、括：倾听用户需求；负责产品功能定义、规划和设计；作各种复杂的决策；保证开发团队顺利开展工作及跟踪程序错误等。,2.5.2 项目经理与软件质量保证,软件质量度量方法有以下三种：1.精确度量：使用质量度量评价准则进行详细度量，工作量大，但度量精确度也高；2.全面度量：可以与简易度量并用对各个质量设计评价准则进行度量，工作量可以控制在一定的范围内。3.简易度量,2.5.3 软件项目的跟踪与控制,在软件项目实施过程中进行跟踪与控制，是软件项目管理的重要内容，也是保证软件质量的重要措施。可用不同的方法进行追踪：,2.6.1风险分析,风险的概念 风险与将要发生的事情有关，研究风险就是研究明天将要发生的事情
29、 风险涉及思想、观念、行为、地点、时间等多种因素 风险随条件的变化而改变，人们通过改变、选择、控制与风险密切相关的条件减少、回避风险 改变、选择、控制条件的策略是不确定的,2.6风险分析和管理,软件风险,软件风险和其它风险一样存在不确定性,有些是很难预测的。 对风险的不确定性进行量化，估算某一风险可能带来的损失。 除关注软件项目的一般性风险外，还要关注软件项目的特殊风险，如项目的背景、特殊要求、关键内容、薄弱环节、技术难点、人员状况、工作环境等。,软件项目存在各种风险，人们关心的问题：什么风险会导致软件项目的彻底失败? 顾客需求、开发环境、目标机、时间、成本的改变对软件项目的风险会产生什么影响
30、? 人们必须抓住什么机会、采取什么措施才能有效地减少风险、顺利完成任务?,不同类型的风险,项目风险 预算、进度、人力、资源、客户及需求 项目的复杂度、规模、结构的不确定性等 技术风险 设计、实现、接口、验证和维护 规约的二义性、技术的不确定性、陈旧的技术、领先的技术 商业风险 无需求的产品、策路风险、管理风险、预算风险,软件风险分析包括的部分风险标识 风险估算 风险规划 风险监控,软件风险分析,1风险标识,对待风险不能采取回避态度项目开始时应对一般性风险和特定产品风险进行系统标识，並随着项目的展开不断更新。 一般可预测风险产品规模、商业影响、客户、过程、技术、环境、人员及经验等。 识别风险的有
31、效方法 风险检测表 为了帮助项目管理人员、项目规划人员,全面了解软件开发过程存在的风险， Boehm 建议设计并使用各类风险检测表，表中条目指明,常見並可预测的风险。有些风险可以预料，有些很难预料。,例2.6 人员配备风险检测表,(1) 开发人员的水平如何。 (2) 开发人员在技术上是否配套。 (3) 开发人员的数量如何。 (4) 开发人员是否能够自始至终地参加软件开发工作。 (5) 开发人员是否能够集中全部精力投入到软件开发工作。 (6) 开发人员对自己的工作是否有正确的期望。 (7) 开发人员是否接受过必要的培训。 (8) 开发人员的流动是否能够保证工作的连续性。 上述问题可以选用0,1,
32、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种风险的估算值可以定义为 mi WijXij(mN)j=1其中 Wij m， Wij 0 (310),风险估算,如果第i种风险对整个软件项目的风险估算加权系数是i, i=1
33、,2,l. 为风险要素的个数,i1，则软件项目风险估算定义为lRii (311) i=1 0R1当R接近于0时表示风险比较小，R接近于1时表示风险比较大。 当ii 比较大时，表示第i类风险出现并带来不良影响的可能性比较大，必须引起足够重视，设法改善条件，减小i的值。,3 风险评价和管理,风险评价是风险管理的重要步骤 任务 进一步审查风险预测的精度； 更新风险优先次序； 考虑控制和/或避免可能发生风险的办法。,风险评价,定义 用三元组ri， li， xi描述风险，i =1,2,3其中： ri 表示风险 li 表示风险发生的概率 xi 表示风险产生的影响对大多数软件项目，应该定义性能、成本及进度的
34、风险参考水平值，当某一风险或风险组合值超过水平值时项目被迫停止。,风险评估的步骤,1 定义项目的风险参考水平值； 2 建立三元组，给出相应的参考水平值； 3 预测一组临界点，定义项目终止区域； 4 预测什么样的风险组合会影响参考水平 值,风险表 （13）,风险 类别 概率 影响 RMMM 1 2 3 项目开始时应在第一列列出所有风险; 第二列给出风险类别； 第三列给出每种风险发生的概率； 第四列给出各种风险产生影响的评估值； 第五列给出风险缓解、监控和管理计划。,风险表（23）,评估值按风险因素：性能、成本、进度的影响类别求加权平均值 影响类别取值：灾难的1，严重的2，轻微的3，可忽略的4。
35、对风险表中的风险按照发生概率大小、影响大小，由大至小排序。,风险表（33）,项目管理者对风险表进行研究后应定义一条中止线，线上的风险较大者应给予特别的关注，线下的风险需要进一步的跟踪、评估、排序。对风险发生概率较大的事件应引起特别关注，要及早采取措施尽量避免它的发生。,风险评价和管理,三元组ri,li,xi是风险管理的基础设 高级职员流动给项目带来风险r1,根据历史的经验或直观感觉，高级职员离开课题组的概率 l1 = 70%, 这一风险导致事件 x1 发生项目开发时间延长 15%，成本增加 20%,项目负责人采取的风险管理措施,(1)项目开始前控制产生风险的原因。项目开工后应设法减轻风险的影响
36、。 (2)了解项目开发人员变动的原因，在项目开发期间应控制上述原因，尽量减少人员的流动。 (3)在工作方法和技术上采取适当措施，防止因人员流动给工作带来损失。 (4)项目在开发过程中应及时公布并交流项目开发的信息。 (5)建立组织机构，确定文档标准、并及时生成文档。 (6)对工作进行集体复审，使多数人都能了解工作的细节，跟上工作进度。 (7)为关键技术准备后备人员。,RMMM计划,风险缓解、监控和管理计划Risk Mitigation,Monitoring,and Management Plan将风险分析工作文挡化，成为项目的一部分。 执行RMMM计划需要成本当软件项目比较大时，可能标出30至
37、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
38、.3.1意外事件计划3.3.2特殊考虑 4.RMMM计划时间安排表 5.总结,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
39、Integration)，能力成熟度模型集成阶段。,2.7软件过程及软件成熟度模型CMM,2.7.1 CMM概述,CMM侧重于软件开发过程的管理及工程能力的提高与评估，是国际上流行的软件生产过程标准和软件企业成熟度等级认证标准，它更代表了一种管理哲学在软件企业中的应用。 CMM认证已经成为世界公认的软件产品进入国际市场的通行证。,CMM的主要用于： 1.软件过程评估SPA（Software Process Assessment） 2. 软件过程改进SPI（Software Process Improvement） 3. 软件能力评价SCE（Software Capability Evaluat
40、ion）,1. 什么是软件过程一个软件过程是指人们开发和维护软件及其相关产品所采取的一系列活动。,规程与方法,工具和设备,有技能经过培训的开发人员,2. 什么是软件能力成熟度？ 由于特定项目的属性和环境限制，项目的实际性能并不能充分反映组织的软件过程能力，但成熟的软件过程可弱化和预见不可控制的过程因素（如客户需求变化或技术变革等）。一个组织的软件过程能力为组织提供了预测软件项目开发的数据基础，提供了全面的软件质量保证。,软件过程成熟度是指一个软件过程被明确定义、管理、度量和控制的有效程度。成熟意味着软件过程能力持续改善的过程，成熟度代表软件过程能力改善的潜力。,软件过程的成熟度等级,CMM将软件过程的成熟度分为5个级别(Maturity Levels),如图所示，5个等级分别是：,1.初始级（Initial） 2.可重复级（Repeatable） 3.已定义级（Defined） 4.已管理级（Managed） 5.优化级（Optimizing）,成熟度等级,单击鼠标左键 查看相应内容,表描述了SW-CMM不同成熟度等级过程的可视性和过程能力。,可视性与过程能力的比较,进行软件过程改进的IDEAL方法,
