软件工程风险管理

第15章 软件工程风险管理 15.3.1 建立风险表 表15.1 风险预测表样本
风险描述 规模估算可能非常低 用户数量大大超过计划 复用程度低于计划 最终用户抵制该系统 风险类别 产品规模 产品规模 产品规模 商业风险 发生概率 60% 30% 70% 40% 可能的影响 2 3 2 3 RMMM
第15章 软件工程风险管理
第15章 软件工程风险管理
15.1 软件风险 15.2 风险识别 15.3 风险预测 15.4 风险缓解、监控与管理
15.5 RMMM计划
15.6 小结
第15章 软件工程风险管理
15.1 软 件 风 险
对软件风险的严格定义还存在着很多争议，但对于在风险 中包含了两个特性这一点上已经达成了共识。 (1) 不确定性：风险可能发生也可能不发生，即不存在发生 概率为100%的风险(100%会发生的风险实际上是加在项目上的 约束)。
第15章 软件工程风险管理 技术风险威胁到要开发软件的质量和交付时间。如果技术 风险变成现实，则开发工作可能变得很困难或者根本不可能。 技术风险是指潜在的设计、实现、接口、验证和维护等方面的 问题。此外，需求规约的二义性，技术的不确定性，陈旧的技
Leabharlann Baidu
术及“先进的”技术也是风险因素。技术风险的发生是因为问
第15章 软件工程风险管理 整个项目开发期间人员如何投入？ 有多少人不是全工时投入本项目的工作？
人们对于手头上的工作是否有正确的目标？
项目成员是否接受过必要的培训？
项目的成员是否是稳定的和连续的？
第15章 软件工程风险管理 对于这些提问，通过判定分析或假设分析，给出确定的回答， 就可以帮助管理人员或计划人员估算风险的影响。当然，上面仅
交付期限紧缩
商业风险
50%
2
第15章 软件工程风险管理 表15.1 风险预测表样本
资金流失 需求改变 技术达不到预期效果

预算风险
40%
1
产品规模
技术风险 人力风险 人力风险 人力风险
80%
30% 80% 30% 60%
2
1 3 2 2
缺少对于工具的培训 人员缺乏经验 人员流动频繁

第15章 软件工程风险管理 在表15.1中，影响类别取值为1：灾难的；2：严重的；3： 轻微的；4：可以忽略的。项目组将所有可能的风险都在第一列 中列出，在第二列上加以分类。发生概率经评估后取评估均值， 将估计的影响程度填入第四列，然后按照发生概率和影响程度
第15章 软件工程风险管理 需求中是否要求使用非传统的软件开发方法，如形式化方 法，人工神经网络方法？ 需求中对产品性能的约束是否过分严格？ 客户能确定所要求的功能是“可行的”吗？ 如果对于上列问题中任何一个问题的回答是肯定的，则需
要进行进一步的调研来评估潜在的风险。
第15章 软件工程风险管理
15.3 风 险 预 测
自高到低地对风险表进行第一次风险排序。
管理者研究已经排序的风险表，定义一条中止线，一般来
说，管理者对于中止线以上的风险会进行进一步的关注。其他
题比我们所设想的更难以解决。
第15章 软件工程风险管理 商业风险威胁到要开发的软件的生存能力。商业风险常常 会危害项目或产品。五个主要的商业风险是：
市场风险：开发了一个没有人真正需要的优秀产品或系统。
策略风险：开发的产品不再符合公司的整体商业策略。
营销风险：生产了一个销售部门不知道如何去卖的产品。
仅是针对人力资源风险有效的问题。同样地，我们也可以对其他
类型的风险制定出必要的问题，利用和上述方法相同的手段，估
算不同类别风险的影响。例如，针对技术风险的问题包括：
该技术对你的组织来说是新的吗？ 客户的需求是否需要创建新的算法或I/O技术？ 软件是否需要使用新的或未经证实的硬件接口？
第15章 软件工程风险管理 待开发软件是否要和开发商提供的未经证实的软件接口？ 待开发软件是否要和其功能和性能均未在本领域中得到证实 的数据库系统接口？ 产品的需求中是否包括要求采用特定的用户界面？ 产品的需求中是否要求开发某些程序构件，这些构件和你 的组织从前开发过的构件完全不同？ 需求中是否要求使用新的分析、设计或测试方法？
管理风险：由于重点的转移或人员的变动，失去了高级管 理层的支持。 预算风险：没有得到预算或人力上的保证。
第15章 软件工程风险管理 另一种分类方式将风险分为三类： 已知风险：通过仔细评估项目计划，开发项目的商业及技
术环境以及其他可靠的消息来源(如不现实的交付时间，恶劣的
开发环境，没有需求或者软件范围文档)之后可以发现的那些风 险。 可预测风险：能够从过去项目的经验中推断出来(如人员调 整、与客户无法沟通、开发人员精力分散)的风险。 不可预测风险：可能或有时真会出现的风险，但事先很难 识别出来。
风险预测又称为风险估算。它试图从两个方面去评价每一个
风险：其一是风险发生的可能性或概率；其二是如果风险发生
了会造成的后果。风险预测活动要进行四项工作： (1) 建立一个尺度，以反映风险发生的可能性(尺度可以是布 尔值、定性的或定量的)。 (2) 描述风险的后果。 (3) 估算风险对项目和产品的影响。 (4) 标注风险整体预测的精确度以免产生误解。
第15章 软件工程风险管理
15.2 风 险 识 别
风险识别就是要识别属于前述类型中的某些特定的风险。
方法是利用一组问卷来帮助项目计划人员了解在项目和技术方
面有哪些风险。Boehm建议使用一个“风险项目检查表”列出所 有可能的与每一个风险因素有关的提问。例如，管理人员或计 划人员可以通过回答下列问题得到对有关人力风险的认识： 可用人员是最优秀的吗？ 按照技能对人员进行了合理组合吗？ 人力足够吗？
(2) 危害性：一旦风险变成了现实，就会产生恶性后果或损
失。
第15章 软件工程风险管理 进行风险分析时，重要的是量化不确定性的程度和与每个风 险相关的损失程度。为了达到此目的，必须考虑不同类型的风 险。 项目风险威胁到项目计划。也就是说，如果项目风险变成现 实，可能会拖延项目进度且增加项目的成本。项目风险是指潜 在的预算、进度、人力(工作人员及组织)、资源、客户及需求等 方面的问题以及它们对软件项目的影响。项目的复杂性、规模 及结构不确定性也被定义为项目(估算)风险因素。