第12章 控制.ppt

2. (1) (2) (3)
二、 通过识别已知的和可预测的风险，项目管理者就朝 着在可能时避免风险并且在必要时控制风险的目标
前面描述的每一类风险又可进一步分成两种类型： 一般性风险和特定产品的风险。一般性风险对每个 软件项目都是潜在的威胁。特定产品的风险只有那 些对当前项目的技术、人员、及环境非常了解的人 才能识别出来。为了识别出特定产品的风险，必须 检查项目计划和软件范围说明，并且回答下述问题： “本项目有什么特殊的性质可能会威胁我们的项目 计划”
一旦填好了风险表前4列的内容，就应该根据概率和 影响来排序。高概率、高影响的风险放在表的上方， 而低概率的风险放在表的下方，这样就完成了第一
项目管理者研究排好序的风险表，并确定一条中止 线。该中止线是经过表中某一点的水平直线，它的 含义是，只有位于线的上方的那些风险才会得到进 一步的关注。对于处于线下方的风险要再次评估，
灾难性的
严重的
因素
性能
支持
成本
进度
1
不能满足需求而导致项目失败
错误导致成本增加和进度延迟， 预计超支＄500k 以上
2
不能 满足 要 求 的技术性能
无响 应或 无 法 支持的软件
资金 严重 短 缺， 很可 能 超 出预算
不能 在预 定 的 交付 日期 内 完 成
1
不能满足需求，系统性能降低到 对项目能否成功有疑问的程度
或系统；
策略风险：开发的产品不符合公司的整体商业策略； 销售风险：开发了一个销售部门不知道如何去卖的
产品；
管理风险：由于重点的转移或人员的变动而失去了 高级管理层的支持的风险；
预算风险：没有得到预算或人力上的保证。
(3)客户特性风险：与客户的素质以及开发者和客户沟 通能力相关的风险。
(4)过程定义风险：与软件过程定义相关的风险。
(5)开发环境风险：与开发工具的可用性及质量相关的 风险。
(6)技术风险：技术风险是指在设计、实现、接口、验 证、维护、规约的二义性、技术的不确定性、陈旧 的技术等方面存在的风险。技术风险威胁到软件开 发的质量及交付的时间，如果技术风险变成现实， 则开发工作可能变得很困难或根本不可能。
(7)人员数目及经验带来的风险：与参与工作的软件工 程师的总体技术水平及项目经验相关的风险。
· 成本风险——
· 支持风险——软件易于改错、适应和增强的不确定
· 进度风险——能够实现项目进度计划且产品能按时
根据风险发生时对上述四个风险因素影响的严 重程度，可以把风险后果划分成四个等级：可忽略 的、轻微的、严重的和灾难性的。按照实际后果与 表中描述的特点的吻合程度，可以把风险后果划分
表 12.1 等级
· 不确定性：标志风险的事件可能发生也可能不发 · 损失：如果风险变成了现实，就会造成不好的后
1.按照风险的影响范围分类
(1)产品规模风险：与软件的总体规模相关的风险。 (2)商业影响风险：商业风险影响到软件开发的生存能
力。商业风险包含的五个主要的风险是： 市场风险：开发了一个没有人真正需要的优秀产品
错误导致运行延迟和成本增加， 预计超支＄100k 至＄500k
2
技术 性能 有 些 降低
软件 修改 工 作 有些延迟
资金 有些 短 缺， 可能 会 超 支
交付 日期 可 能 拖后
1 轻微的
2
1 可忽略的
2
不能满足需求而导致次要功能降 成本有 些增 加，进 度延 迟可 补
级
救，预计超支＄1k 至＄100k
· 所用技术——与待开发系统的复杂性及系统所包 含的技术的“新奇性”
· 人员数目与经验——与参加工作的软件工程师的
三、 风险预测(也称为风险估算)试图从两个方面来评估
每个风险：风险变成现实的可能性或概率，以及当
1. 美国空军建议从性能、支持、成本和进度等四个方
· 性能风险——产品能满足需求且符合其使用目的的
类别 PS PS PS BU BU CU CU TE DE ST ST
概率 60% 30% 70% 40% 50% 40% 80% 30% 80% 30% 60%
影响 2 3 2 3 2 1 2 1 3 2 2
表中第4列给出的是风险后果的整体等级值，其中， 1代表灾难性的，2代表严重的，3代表轻微的，4代
第12章 控制
一般说来，所谓控制就是掌握被控制的 对象，不让它任意活动或超出规定范围 活动，尽量使一切活动都按照预定的计
12.1 风险管理
软件开发几乎总会存在某些风险。对付风险应该采 取主动的策略，也就是说，早在技术工作开始之前 就应该启动风险管理活动：标识出潜在的风险，评 估它们出现的概率和影响，并且按重要性把风险排 序，然后，软件项目组制定一个计划来管理风险。 风险管理的主要目标是预防风险，但是，并非所有 风险都能预防，因此，项目组还必须制定一个处理 意外事件的计划，以便一旦风险变成现实时能够以 可控的和有效的方式作出反应。
采用建立风险条目检查表的方法，人们可以集中精 · 产品规模——与要开发或要修改的软件总体规模相 · 商业影响——与管理或市场所施加的约束相关的风 · 客户特性——与客户素质以及开发者和客户定期通
· 过程定义——与软件过程已被定义的程度以及软
· 开发环境——与用来开发产品的工具的可用性和
从管理的角度看，风险影响和风险概率的作用是不 同的。对一个具有高影响但发生概率很低的风险因 素，不应该花费太多管理时间。但是，高影响且发 生概率为中到高的风险，以及低影响且高概率的风
应该在软件项目进展的过程中，迭代使用上述的风 险预测与分析技术。项目组应该定期复查风险表， 再次评估每个风险，以确定新情况是否引起它的概 率和影响发生变化。作为这项活动的结果，可能在 表中添加了一些新风险，删除了某些与项目不再有
技术性能稍微 降低一点
较好的软件支 持
资金充足
现实的、可完 成的进度计划
不能满足需求而导致使用不方便 错误对成本和进度影响很小，预
或对非运行方面有影响
பைடு நூலகம்
计超支少于＄1k
技术性能没有 降低
易于支持的软 件
可能低于预算
交付日期提前
2. 建立风险表是一种简单的风险预测技术，表12.2
表 12.2 风险
规模估算可能很不准确 用户数目超出计划 重用程度低于计划 终端用户抵制该系统 交付日期将要求提前 资金将流失 客户将改变需求 技术达不到预期的水平 缺少关于工具的培训 人员缺乏经验