指南:风险列表
本指南描述如何确定和管理软件项目风险。
关系
相关元素
主要描述

简介

“有备无患。”- Hamlet V:ii:215

项目就像生活一样,是不确定的。我们不是为了识别风险而识别风险,而是尽可能要预见和降低风险,或在我们的降低策略不足时响应风险。

风险推动了迭代计划;迭代是围绕着处理特定风险而计划的,尝试限制风险或减少风险。定期复审风险列表可评估风险降低策略的效用,这反过来又推动了项目计划的修订及随后迭代计划的修订。

管理风险的关键并不是等到风险实际发生(并成为问题或故障)后才决定如何处理。就像在洲际飞行中失之毫厘则谬以千里一样,较早地管理风险几乎总是比事后清理代价更低,麻烦更小。

风险管理策略

有三种主要策略 [BOE91]:

  • 避开风险。重新组织项目,使其不会受该风险的影响。
  • 转移风险。重新组织项目,使其他人或事承担该风险(客户、供应商、银行、另一元素等)。一种特定的避开风险策略。
  • 接受风险。决定忍受风险,作为一种偶然情况。监视风险症状并确定一个出现风险时的应急计划。

如果决定接受该风险,您仍可能希望降低该风险,即采取某种直接措施来减少其影响。

风险类型

区分直接风险和间接风险是很重要的。简而言之,直接风险是我们能在某种程度上控制的风险;间接风险是我们无法控制的风险。

尽管不应该对间接风险一无所知,但它们在实践意义上是无关紧要的:既然无法更改它们,对它们有所顾虑也无济于事。也许明天是世界末日,也许不是,如果不是,我们最好还是继续进行我们手头的工作!

有时,间接风险可能实际上是伪装起来的直接风险。例如,我们可能依靠某个外部供应商提供一个组件或一组组件。这似乎是间接风险,但通过针对这些组件的应急计划,我们可以控制该风险:我们可以选择替代供应商,或我们可以选择自行开发功能。在许多情况下,我们比想像中的更有控制权!

对于间接风险,您要么必须找出如何对这些风险获得某种程度的控制的办法,要么只是记下它们并继续。对您无法改变的东西牵肠挂肚是没什么意义的。

资源风险

组织
  • 对此项目是否有足够的投入(包括管理层、测试人员、QA 和其他的外部相关各方)?
  • 这是否是该组织曾尝试过的最大项目?
  • 是否有明确定义的软件工程流程?是否有明确定义的需求捕获和管理?
拨款
  • 拨款是否到位、可以完成项目?
  • 是否分配了用于培训和指导的拨款?
  • 是否有预算限制,这样系统就必须按固定的成本交付、否则取消?
  • 成本估计是否精确?
人员
  • 是否有足够的人员?
  • 他们是否有适当的技能和经验?
  • 他们以前是否合作过?
  • 他们是否相信该项目可以取得成功?
  • 是否有用户代表进行复审?
  • 是否有领域专家?
时间
  • 时间表是否现实?
  • 是否可按时间表管理功能的范围?
  • 交付日期的紧急程度如何?
  • 是否有时间“把工作做好”?

业务风险

  • 如果竞争对手先进入市场,怎么办?
  • 如果项目拨款处于危险境地怎么办(换句话说,“如何确保有足够的资金”)?
  • 系统的计划价值是否大于计划成本?(务必考虑到金钱的现值和投资的成本)。
  • 如果无法与主要供应商签订合同,怎么办?

技术风险 回到页首

规模风险
  • 是否可以度量成功?
  • 是否有关于如何度量成功的一致意见?
  • 需求是否相当稳定并得到清楚的理解?
  • 项目范围是固定的还是一直在扩展?
  • 项目开发时间范围是否短暂而不灵活?
技术风险
  • 该技术是否已得到证明?
  • 重用目标是否合理?
    • 工作产品必须要使用一次后才能被重复使用。
    • 一个组件能需要发行好几个发行版,然后其稳定性才足以重用而不需要重大更改。
  • 需求中的事务量是否合理?
  • 事务率估计值是否可信?是否过于乐观?
  • 数据量是否合理?它们是否可存储在当前可用的大型机中,或者,如果需求让您相信工作站或部门系统将是设计的一部分,数据是否可在那里合理存储?
  • 是否有不常见的或挑战性的技术需求,要求项目团队处理他们不熟悉的问题?
  • 成功取决于新的或未经尝试的产品、服务或技术、新的或未经证明的硬件、软件还是工艺?
  • 是否有对其他系统(包括企业外的系统)接口的外部依赖性?必需的接口是否存在还是必须创建它们?
  • 是否存在极不灵活的可用性和安全性需求(例如“系统必须永远不出现故障”)?
  • 系统的用户是否对正在开发的系统的类型没有经验?
  • 是否由于应用程序的规模或复杂性或者技术的新颖性而增加了风险?
  • 是否要求本地语言支持?
  • 是否可能设计、实施和运行此系统? 有些系统只是由于过于庞大或复杂而无法正常工作。
外部依赖性风险
  • 项目是否依赖于其他(并行的)开发项目?
  • 成功是否依赖于成品产品或外部开发的组件?
  • 成功是否依赖于开发工具(设计工具、编译器等)、实施技术(操作系统、数据库、流程间沟通机制等)的成功集成。您是否有在没有这些技术的情况下交付项目的备份计划?

时间表风险

经验表明,85% 的风险对时间表有着直接或间接影响,因此肯定对成本有影响。可能其中的 5% 仅有成本影响。其余部分对成本或时间表没有任何直接影响,但对质量(举例)有直接影响。

如果截止期限是大敌,则在平稳接近该期限的过程中进行递增的交付。 避免为了努力符合时间表而进行一次性大量交付。

某些项目具有“时间极其受限的”最终期限。例如,在选举之夜用来实况分析选举结果的软件,它在选举结束一周后就几乎毫无价值了。或者您的软件可能会被竞争对手超越:当您还在构造中期时,他们已推出了比您更好的产品。突然之间,您出局了 - 并且您对这种情况无能为力。但总的来说,很少有项目具有这样紧迫的截止期限。延迟通常影响到成本。

总的来说,您承诺的时间表应等于您的最佳估计情况加上一些合理的偶然情况。

承诺 = 估计 + 偶然

有人建议,时间表预期值应等于您的应急策略时间,也就是说,根据您的应急计划来设置预期值,但这种建议过于悲观,因为并非所有风险都将实际发生。

时间表风险集中在一些估计和成本计算工具中。例如,在 COCOMO 模型中,有许多成本驱动因素,例如:

  • 复杂性(cplx)
  • 实时约束(time)
  • 存储约束(stor)
  • 经验(Vexp)
  • 好工具的可用性(tool)
  • 时间表压力(sced)

是实际的风险因素。

更高级的风险管理技术采用了 Monte Carlo 仿真,它使用仿真工具来运行大量“场景”,从而计算出总的风险和意外事件 [KAR96]。