第15章 软件工程风险管理 普通高等院校计算机类专业系列教材 软件工程教学课件.ppt

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