第15章 软件工程风险管理

《第15章 软件工程风险管理》由会员分享，可在线阅读，更多相关《第15章 软件工程风险管理（35页珍藏版）》请在金锄头文库上搜索。

1、第15章 软件工程风险管理 第15章 软件工程风险管理 15.1 软件风险15.2 风险识别15.3 风险预测 15.4 风险缓解、监控与管理15.5 RMMM计划 15.6 小结 第15章 软件工程风险管理 15.1 软 件 风 险对软件风险的严格定义还存在着很多争议，但对于在风险中包含了两个特性这一点上已经达成了共识。(1) 不确定性：风险可能发生也可能不发生，即不存在发生概率为100%的风险(100%会发生的风险实际上是加在项目上的约束)。(2) 危害性：一旦风险变成了现实，就会产生恶性后果或损失。 第15章 软件工程风险管理 进行风险分析时，重要的是量化不确定性的程度和与每个风险相关的

2、损失程度。为了达到此目的，必须考虑不同类型的风险。项目风险威胁到项目计划。也就是说，如果项目风险变成现实，可能会拖延项目进度且增加项目的成本。项目风险是指潜在的预算、进度、人力(工作人员及组织)、资源、客户及需求等方面的问题以及它们对软件项目的影响。项目的复杂性、规模及结构不确定性也被定义为项目(估算)风险因素。第15章 软件工程风险管理 技术风险威胁到要开发软件的质量和交付时间。如果技术风险变成现实，则开发工作可能变得很困难或者根本不可能。技术风险是指潜在的设计、实现、接口、验证和维护等方面的问题。此外，需求规约的二义性，技术的不确定性，陈旧的技术及“先进的”技术也是风险因素。技术风险的发生

3、是因为问题比我们所设想的更难以解决。第15章 软件工程风险管理 商业风险威胁到要开发的软件的生存能力。商业风险常常会危害项目或产品。五个主要的商业风险是：市场风险：开发了一个没有人真正需要的优秀产品或系统。策略风险：开发的产品不再符合公司的整体商业策略。营销风险：生产了一个销售部门不知道如何去卖的产品。管理风险：由于重点的转移或人员的变动，失去了高级管理层的支持。预算风险：没有得到预算或人力上的保证。 第15章 软件工程风险管理 另一种分类方式将风险分为三类：已知风险：通过仔细评估项目计划，开发项目的商业及技术环境以及其他可靠的消息来源(如不现实的交付时间，恶劣的开发环境，没有需求或者软件范围

4、文档)之后可以发现的那些风险。可预测风险：能够从过去项目的经验中推断出来(如人员调整、与客户无法沟通、开发人员精力分散)的风险。不可预测风险：可能或有时真会出现的风险，但事先很难识别出来。第15章 软件工程风险管理 15.2 风 险 识 别风险识别就是要识别属于前述类型中的某些特定的风险。方法是利用一组问卷来帮助项目计划人员了解在项目和技术方面有哪些风险。Boehm建议使用一个“风险项目检查表”列出所有可能的与每一个风险因素有关的提问。例如，管理人员或计划人员可以通过回答下列问题得到对有关人力风险的认识：可用人员是最优秀的吗？按照技能对人员进行了合理组合吗？人力足够吗？第15章 软件工程风险管

5、理 整个项目开发期间人员如何投入？有多少人不是全工时投入本项目的工作？人们对于手头上的工作是否有正确的目标？项目成员是否接受过必要的培训？项目的成员是否是稳定的和连续的？第15章 软件工程风险管理 对于这些提问，通过判定分析或假设分析，给出确定的回答，就可以帮助管理人员或计划人员估算风险的影响。当然，上面仅仅是针对人力资源风险有效的问题。同样地，我们也可以对其他类型的风险制定出必要的问题，利用和上述方法相同的手段，估算不同类别风险的影响。例如，针对技术风险的问题包括：该技术对你的组织来说是新的吗？客户的需求是否需要创建新的算法或I/O技术？软件是否需要使用新的或未经证实的硬件接口？第15章 软

6、件工程风险管理 待开发软件是否要和开发商提供的未经证实的软件接口？待开发软件是否要和其功能和性能均未在本领域中得到证实的数据库系统接口？产品的需求中是否包括要求采用特定的用户界面？产品的需求中是否要求开发某些程序构件，这些构件和你的组织从前开发过的构件完全不同？需求中是否要求使用新的分析、设计或测试方法？第15章 软件工程风险管理 需求中是否要求使用非传统的软件开发方法，如形式化方法，人工神经网络方法？需求中对产品性能的约束是否过分严格？客户能确定所要求的功能是“可行的”吗？如果对于上列问题中任何一个问题的回答是肯定的，则需要进行进一步的调研来评估潜在的风险。第15章 软件工程风险管理 15.

7、3 风 险 预 测风险预测又称为风险估算。它试图从两个方面去评价每一个风险：其一是风险发生的可能性或概率；其二是如果风险发生了会造成的后果。风险预测活动要进行四项工作：(1) 建立一个尺度，以反映风险发生的可能性(尺度可以是布尔值、定性的或定量的)。(2) 描述风险的后果。(3) 估算风险对项目和产品的影响。(4) 标注风险整体预测的精确度以免产生误解。第15章 软件工程风险管理 15.3.1 建立风险表表15.1 风险预测表样本风险描述风险类别发生概率可能的影响RMMM规模估算可能非常低产品规模60%2 用户数量大大超过计划产品规模30%3 复用程度低于计划产品规模70%2 最终用户抵制该系

8、统商业风险40%3 交付期限紧缩商业风险50%2 资金流失预算风险40%1 需求改变产品规模80%2 技术达不到预期效果技术风险30%1 缺少对于工具的培训人力风险80%3 人员缺乏经验人力风险30%2 人员流动频繁人力风险60%2 风险描述风险类别发生概率可能的影响RMMM规模估算可能非常低产品规模60%2 用户数量大大超过计划产品规模30%3 复用程度低于计划产品规模70%2 最终用户抵制该系统商业风险40%3 交付期限紧缩商业风险50%2 资金流失预算风险40%1 需求改变产品规模80%2 技术达不到预期效果技术风险30%1 缺少对于工具的培训人力风险80%3 人员缺乏经验人力风险30%

9、2 人员流动频繁人力风险60%2 风险描述风险类别发生概率可能的影响RMMM规模估算可能非常低产品规模60%2 用户数量大大超过计划产品规模30%3 复用程度低于计划产品规模70%2 最终用户抵制该系统商业风险40%3 交付期限紧缩商业风险50%2 资金流失预算风险40%1 需求改变产品规模80%2 技术达不到预期效果技术风险30%1 缺少对于工具的培训人力风险80%3 人员缺乏经验人力风险30%2 人员流动频繁人力风险60%2 风险描述风险类别发生概率可能的影响RMMM规模估算可能非常低产品规模60%2 用户数量大大超过计划产品规模30%3 复用程度低于计划产品规模70%2 最终用户抵制该系

10、统商业风险40%3 交付期限紧缩商业风险50%2 资金流失预算风险40%1 需求改变产品规模80%2 技术达不到预期效果技术风险30%1 缺少对于工具的培训人力风险80%3 人员缺乏经验人力风险30%2 人员流动频繁人力风险60%2 风险描述风险类别发生概率可能的影响RMMM规模估算可能非常低产品规模60%2 用户数量大大超过计划产品规模30%3 复用程度低于计划产品规模70%2最终用户抵制该系统商业风险40%3 交付期限紧缩商业风险50%2 第15章 软件工程风险管理 资金流失预算风险40%1 需求改变产品规模80%2 技术达不到预期效果技术风险30%1 缺少对于工具的培训人力风险80%3

11、人员缺乏经验人力风险30%2 人员流动频繁人力风险60%2 资金流失预算风险40%1需求改变产品规模80%2技术达不到预期效果技术风险30%1缺少对于工具的培训人力风险80%3人员缺乏经验人力风险30%2人员流动频繁人力风险60%2表15.1 风险预测表样本第15章 软件工程风险管理 在表15.1中，影响类别取值为1：灾难的；2：严重的；3：轻微的；4：可以忽略的。项目组将所有可能的风险都在第一列中列出，在第二列上加以分类。发生概率经评估后取评估均值，将估计的影响程度填入第四列，然后按照发生概率和影响程度自高到低地对风险表进行第一次风险排序。管理者研究已经排序的风险表，定义一条中止线，一般来说

12、，管理者对于中止线以上的风险会进行进一步的关注。其他的风险需要再次评估以完成第二次排序。第15章 软件工程风险管理 图15.1 风险和管理的考虑第15章 软件工程风险管理 风险表中所有在终止线以上的风险都应当进行管理。在表的最后一列包含有一个指针，指向为所有终止线以上的风险制定的风险缓解、监控和管理计划(RMMM计划，Risk Mitigation，Monitoring and Management Plan)。 第15章 软件工程风险管理 15.3.2 风险评估建立一个三元组集合来进行风险评估：Ri，Li，Xi。其中，Ri是风险，Li是风险出现的可能性，Xi是风险出现会造成的影响。在进行风险

13、评估时，应当进一步检验在风险预测时得到的估计的准确性(影响及概率)，试图为已被发现的风险排出优先顺序，并开始考虑如何控制或避免可能发生的风险。第15章 软件工程风险管理 要使评估发生作用，必须定义一个风险参考水平值。对于大多数软件项目而言，前面所讨论的风险因素性能、成本、支持及进度也代表了风险参考水平值，即对于性能下降、成本超支 、支持困难、进度延迟(或者它们的组合)都有一个水平值的要求。超出水平值就会导致项目被迫终止。如果风险的组合所产生的问题引起一个或多个参考水平值被超过，则工作将会停止。在软件风险分析中，风险参考水平值存在一个点，称为参考点或临界 点。在这个点上，决定继续进行某项目或者是

14、终止它(问题太大了)都是可以接受的。图15.2中就表示了这种情况。如果风险组合产生的问题导致成本超支及进度延迟，则会有一个水平值，(即图中的曲线)，当超过它时会引起项目终止。第15章 软件工程风险管理 图15.2 风险参考水平曲线第15章 软件工程风险管理 实际上参考水平值很少能够表示成如图15.2所示的光滑曲线。在大多数情况下，它是一个区域，其中存在很多不确定性，这个区域可能是一个易变区域。在这些区域中想要做出基于参考值组合的管理判断往往是非常困难的。因此，在作风险评估时，可以采用下面的步骤执行：(1) 为项目定义风险参照水准。(2) 尝试找出在每一个Ri，Li，Xi 和每一个参照水准之间

15、的关系。(3) 预测参照点组以定义一个终止区域，用一条曲线或一些 易变动区域来界定。(4) 努力预测复合的风险组合将如何形成一个参照水准。 第15章 软件工程风险管理 15.4 风险缓解、监控与管理在这一步的工作中，所有的风险分析活动都只有一个目的，那就是辅助项目建立处理风险的策略。任何一种有效的策略都必须考虑三个问题：风险避免、风险监控、风险管理及意外事件计划。如果项目组对于风险采取主动策略，则最好的方法是通过制定一个风险缓解计划并付诸实施，设法避免风险。图15.3所示为风险缓解与监控。第15章 软件工程风险管理 图15.3 风险缓解与监控第15章 软件工程风险管理 例如人员频繁流动是软件开

16、发组织中的一个普遍存在的风险。将其标注为R0，基于以往的历史数据和管理经验，发生概率L0被估算为0.7，影响X0被预测为对于项目的成本和进度有极严重的影响。为了缓解这一风险，项目管理者可以采取如下的策略来降低人员流动：(1) 预先与现有人员一同探讨一下人员流动的原因(如工作条件恶劣、低报酬、激烈的人才竞争)。(2) 在项目开始之前，采取行动来缓解那些被识别出的、且在管理控制之下的原因。第15章 软件工程风险管理 (3) 一旦项目启动，假设人员会发生流动，并采取一些措施以保证当人员离开时工作的连续性。(4) 对项目组进行良好的组织，使得每一个开发活动的信息能够被广泛地传播和交流。(5) 定义文档的标准，并建立保证文档能够被及时、正确建立的机制。(6) 对所有的工作进行详细的复审，保证不止一个人熟悉该项工作。(7) 对每一个关键的技术人员都指定一个后备人员。第15章 软件工程风险管理 随着项目的进展，开始进行风险监控活动。项目管理者监控某些因素，这些因素可以提供风险是否正在变高或变低的