• 软件测试技术
  • 软件测试博客
  • 软件测试视频
  • 开源软件测试技术
  • 软件测试论坛
  • 软件测试沙龙
  • 软件测试资料下载
  • 软件测试杂志
  • 软件测试人才招聘
    暂时没有公告

字号: | 推荐给好友 上一篇 | 下一篇

Microsoft 解决方案框架:风险管理原则 v.1.1

发布: 2008-5-10 17:50 | 作者: 网络转载 | 来源: 网络转载 | 查看: 412次 | 进入软件测试论坛讨论

领测软件测试网

风险计划和调度

介绍

风险计划和调度是风险管理过程中的第三个阶段。由项目团队执行的计划工作将分类风险清单转化为行动计划。计划包含为最大风险展开的详细策略和行动、风险行为分级以及综合风险管理计划的创建。调度包括在风险行为计划中必需实现的任务与项目进度表的集成,这是通过将它们分配给个体,并积极地跟踪它们的状态来实现的。图5对这一阶段进行了描述。

Figure 5: Risk Planning and Scheduling

图 5:风险计划和调度
查看完整的图像。

在风险分析过程中确定的最大风险补充了主导风险清单。有时,在计划过程中,让被分配风险行为项目的团队成员将主导风险清单中的这些部分引入单独的风险行为表格,是相当方便的。

目标

风险计划和调度阶段的主要目标是开发详细的计划,用于控制在风险分析阶段确定的最大风险,并将它们和标准项目管理过程集成,从而确保它们的完整性。

输入

MSF 风险管理原则提倡:风险计划应该与标准项目计划过程和基础设施紧密集成。风险计划的输入不仅仅包含主导风险清单、最大风险清单、风险管理知识库中的信息,还包含风险计划和进度表。

计划工作

在为减少风险暴光量而开发计划的过程中,应该做到以下几点:

关注高暴光量风险。

准确定位条件以降低概率。.

寻找根本原因,而不是故障现象。

准确定位结果以最小化影响

确定根本原因,接着寻找其他领域里可能来自于同一原因的类似情况。

意识到风险间的依存关系和交互作用。

降低风险有以下几种方法:

对于项目团队可以控制的风险,应用所需资源来降低风险。

对于项目团队无法控制的风险,寻找变通的方法或将风险转交给权威人士来处理。

在风险行为计划的过程中,项目团队应该在明确叙述风险行为计划时考虑以下六种备选方案。

调查。我们对风险的了解深入吗?我们需要更进一步地学习风险以获得更多信息,从而在决定采取哪种措施前更好地确定风险特性吗?

接受。 如果风险真的转化为故障,我们可以接受结果吗?我们可以接受风险而不采取行动吗?

避免。 我们可以通过改变范围来避免风险吗?

迁移。 我们可以通过将风险转移给其他项目、团队、组织或个人,从而避免风险吗?

缓解。 项目团队可以采取行动来降低风险的概率或影响吗?

意外事故。 在计划的反作用中,影响会减少吗?

调查

很多项目风险与不完全信息周围的不确定性有关。知识缺乏引发的风险一般可以通过在行动前对更多的领域知识学习来高效地解决。例如,项目团队可以选择进行市场调查或用户群行为分析来了解更多关于用户基线技能以及完成项目计划前使用特定技术的想法。如果团队决定进行调查,那么风险计划应该包含适当的调查建议,包括有待证实的假定、有待回答的问题、职工安置以及任何所需的试验设备。

接受

一些风险是这样的,它不能简单地通过有效的预防性或调整措施来解决,但是项目团队可以选择简单地接受风险,从而认识机会。接受和“什么都不做”策略是不一样的,计划中应该包含归档的基本原理,说明团队为什么选择接受风险而不是开发缓解或意外事故计划。在项目生命周期中持续监控这样的风险应当非常谨慎,注意变化发生的可能性、影响或是执行风险相关的预防或意外事件方法。这些正在进行的监控或监视行动应该包含适当的资源和整体项目管理过程的跟踪度量值。

避免

有时风险可能非常容易通过改变项目范围来控制,来一并消除风险。风险计划应该包含变化基本原理的归档,项目计划则应该更新,并开始所有必需的计划更改或是范围变化过程。

迁移。

有时可以将风险迁移,这样它便能被另一个项目外部的实体所管理。可以迁移风险的情况如下所示:

保险

利用更具专家经验的外部顾问

购买组件,而不是自建

外购服务

风险迁移不意味着风险消除。一般而言,风险迁移会产生一些仍然需要前摄管理的风险,不过可以将风险降低到一个可以接受的等级。例如,利用外部顾问可以将技术风险转移到团队外部,但可能将一些风险引入项目管理和预算领域。

缓解

风险缓解计划包含了提前预防风险以及将影响或结果降低到可接受等级的行动或工作。风险缓解与风险避免不同,因为缓解关注预防和风险最小化,而风险避免则改变风险范围,从而移除可能带来无法接受风险的活动。

风险缓解的主要目标是减少风险发生的概率。例如使用冗余网络连接到 Internet,通过排除单点失效,可以减少访问失败的概率。

不是所有的项目风险都具有合理并划算的缓解策略。在缓解策略不可用的情况下,考虑一种高效应急计划作为替代,是非常基本的工作。

意外事故

风险应急计划创建一个或更多让步计划,从而避免不利的事件出现。意外事故计划对于所有风险都是必需的,包括已经拥有缓解计划的风险。它们定位了在风险发生时应该采取的措施,并关注结果和如何将影响最小化。为了更加高效,项目团队应该预先做出意外事故计划。项目团队常常可以基于可能遇到的影响/风险类型,为意外事故计划建立触发值。

有两种意外事故触发器:

时间点触发器基于日期构建,一般是某时发生的最近日期。

阀值触发器依赖可以被测量或计算的事物。

对于项目团队来说,尽早与适当的管理人员在意外事故触发器和它们的值上达成一致非常重要,这样在执行紧急事件计划时就不会有预算或资源延迟。

调度工作

对于通常的项目调度工作,风险管理调度和控制工作和 MSF 推荐的标准方法没有什么区别。30 项目团队应该理解:风险控制工作是项目的一部分,而不是建立在主动基础上的附加工作,这是相当重要的。所有的风险工作都应该在项目调度和状态报告过程中计算。

输出

风险行动计划的输出应该包含特定的风险行动计划,实现前面讨论过的六种方法的其中一种。实现这些计划的任务应该与标准项目计划和进度表集成。它包含了资源调整、进度表和特性设置,让一套风险行动项目指定将由团队成员完成的个体任务。主导风险清单应该更新,以反映包含于缓解和意外事件计划中包含的额外信息。将风险管理计划总结为单独的文档是非常重要的 。

风险行动项目

风险行动项目记录在项目团队的标准项目行为跟踪系统里,因此应该将它们与其他任何行动等同看待。

和所有适当的归档行动一样,它们也应该与完成时限及人员分配相关联,因此不应该混淆谁该对其完成负责。

风险行动表格

项目团队应该为最大风险清单中的每个风险发展附加计划信息,从而记录缓解和意外事故计划、触发器和详细行动。在开发风险行动表格或文档时,团队应该考虑的信息如下:

风险标识符。团队出于报告和跟踪目的,单独识别风险时使用的名称。

风险声明。一种自然语言声明,描述可能导致损失或是风险转化为故障后会发生的损失的条件。

风险缓解策略。一个或两个文本段落,描述项目团队缓解特定风险的策略,包含所有已经得出的推断。

风险缓解策略度量值。一个度量值,项目团队将用它来确定哪个计划中的风险缓解行动在向期望中的结果发展。

风险行动项目。一个行动清单,项目团队用它来为特定风险实现策略,包含完成时限以及个人任务。

风险意外事故策略。一个或两个文本段落,描述项目团队在意外事件中采取的策略。如果触发器启动,项目团队将会开始执行风险意外事故策略。

意外事故触发值。意外事故触发器是项目团队用来确定何时执行意外事故计划的标准。

风险意外事故策略度量值。这个度量值被项目团队用来确定意外事故策略是否工作。

风险计划职责。实现风险行动计划时付有责任的团队角色或个体。

更新的项目进度表和项目计划

风险相关的计划文档应该与整体项目计划文档以及被计划产生的新任务更新的主导项目进度表集成。

msf/msrmd11.mspx#top">

文章来源于领测软件测试网 https://www.ltesting.net/


关于领测软件测试网 | 领测软件测试网合作伙伴 | 广告服务 | 投稿指南 | 联系我们 | 网站地图 | 友情链接
版权所有(C) 2003-2010 TestAge(领测软件测试网)|领测国际科技(北京)有限公司|软件测试工程师培训网 All Rights Reserved
北京市海淀区中关村南大街9号北京理工科技大厦1402室 京ICP备2023014753号-2
技术支持和业务联系:info@testage.com.cn 电话:010-51297073

软件测试 | 领测国际ISTQBISTQB官网TMMiTMMi认证国际软件测试工程师认证领测软件测试网