在软件项目的开发过程中,会产生很多各种各样的风险。而这些风险的发生会对软件项目产生重大的影响,甚至直接影响到一个软件项目的成败。因此,加强对软件项目风险的管理在软件项目开发过程中显得尤其重要。
有效的软件项目风险,包含风险识别、风险分析与风险监控等多个方面。
1) 风险识别
风险的识别是风险管理中最基础的一项内容,只有有效的提前识别了各种可能发生的风险,才可以有效的对这些风险进行跟踪。
在软件项目中可能发生的风险,一般有:技术风险、人力资源风险、资源风险、市场与政策风险、需求风险等。这些都需要在项目开始的时候以及项目进行的过程中进行有效识别。在项目开始的时候识别这些潜在的风险是为了防范这些风险的发生,在项目进行的过程中识别这些风险,是为了有效的发现项目中存在的问题,并尽早解决。
如何识别风险一方面是参照之前的软件项目,看在项目进行的过程中发生过那些危机,这些曾经发生过的危机就很可能是当前这个软件项目可能会碰到的风险,另一方面也可以综合当前软件项目的客户情况、研发团队情况、采用的技术、涉及的专业知识等方面的情况来识别可能的风险。
2) 风险分析
项目可能会碰到的风险很多,但我们在进行风险管理的过程中,不可能每个项目都给以同样的经历来进行管理。通常的做法就是给这些可能的风险划分一个优先级。对于那些优先级高的风险我们给以更多的关注。
划分风险优先级的过程就是一个风险分析的过程。通常从风险判断标准、风险预防措施、风险消除措施、发生的时机、风险发生的可能性、风险发生的危险度等几个方面进行评估。
风险判断标准指出现什么样的情况我们就可以认为一个风险发生了。比如:项目团队人员异动给项目造成延期的风险我们可以认为当一个项目有2人以上的异动,且项目进度延迟5%的时候,我们就可以认为这个风险发生了。
风险预防措施是指针对识别的可能发生的风险,提出一些可以预防的措施。比如人员异动给项目造成延期的风险,我们可以提出诸如加强人员沟通,尽早了解人员动向;加强团队成员互动,让成员间能够了解工作状况等。
风险消除措施是指当一个风险发生时,我们将采取什么样的措施将风险消除。比如人员异动给项目造成延期的风险一旦发生,我们可以提出采取诸如适当调整工作分工和项目计划,在确保项目关键任务的前提下,调整其他任务的进度安排等。
风险发生的时机指这个风险最有可能在什么时候发生。一般为了好评估,可以采用评分的方式来进行估计。这里我们采用0.3,0.6,0.9分来计算。结合软件工程中软件阶段的划分,我们把在当前这个阶段可能发生的风险定为0.9分,在下一个阶段可能发生的风险定为0.6分,在下一个阶段之后才会发生的风险定为0.3分。
风险发生的可能性一般划分为极可能、可能、有点可能三个等级,分别计分为0.9,0.6,0.3分。比如服务器不能按时到位的风险,假设当前没有这种资源,而采购该服务器得到货周期一般在30天左右,而项目需要服务器在20天内到位,这个时候我们就可以把该风险确定为极可能发生,定为0.9分。
风险发生的危险度一般划分为致命、严重、一般三个等级,分别计分为0.9,0.6,0.3分。比如项目团队核心成员离开的风险一旦发生很可能会导致项目没有办法进行下去,此时该风险的危险度就是致命的,计为0.9分。
以上三个标准的分值相乘在乘100就可以得到一个数值。根据这个数值我们就可以给风险排定一个优先级。分数越高,优先级越高。通常一个缺陷的评估分值大于30分的时候就需要给以足够的重视了。
下表是一个例子:
编号 | 风险描述 | 判断标准 | 发生时机 | 危险度 | 可能性 | 预防措施 | 消除措施 | 识别日期 | 风险等级 | 已发生 |
1 | 评审不到位 | 每次评审发现的缺陷低于10个 | 0.9 | 0.6 | 0.9 | 评审时,根据评审内容分配到具体的每一个人,同时要求进行评审前准备 | 及时补充评审。 | 2005-11-30 | 48.60 | N |
2 | 需求变更频繁 | 需求分析结束后,需求变更数达到总需求数的5% | 0.6 | 0.6 | 0.6 | 进行需求管理,并且在需求发生变更时,严格地执行需求变更流程。并及时根据需求变更情况修改项目计划 | 与客户协调需求变更的问题。可以采取将变更需求纳入到下一个版本开发,或者延长约定的开发周期并增加费用。 | 2005-11-30 | 21.60 | N |
3 | 服务器不能按时到位 | 在获取日期前3天服务器还没有到位 | 0.3 | 0.6 | 0.3 | 根据计划,提前对服务器资源的落实进行跟催 | 寻找可替代资源,诸如配置相当的个人计算机临时使用 | 2005-11-30 | 5.40 | N |
从以上可以看出编号为1的风险优先级最高,在项目进行过程中需要给以足够的重视。
3) 风险监控
风险监控则指根据以上的风险分析结果,在项目执行的过程中采取相应的措施。一方面是根据风险预防措施,采取相应的行动,尽量避免风险的发生或者减弱风险发生造成的危害;另一方面是根据风险判断标准,随时了解一个风险是否已经发生。如果一个风险已经发生,则需要根据风险消除措施和项目当前的实际情况立即采取行动尽早消除该风险。
以上针对风险采取的预防和消除措施,都需要记录下来。这样一方面在项目总结的时候是有用的材料,同时也可以为其它的项目提供借鉴和参考。
下表是一个例子:
风险 时间 | 评审不到位 | 需求变更频繁 | …… | |||
预防措施 | 消除措施 | 预防措施 | 消除措施 | 预防措施 | 消除措施 | |
2005-12-1 | 给项目组成员培训评审流程 |
|
|
|
|
|
2005-12-5 |
|
| 需求有一个变动,进行了记录和跟踪,同时与客户针对改变动进行了沟通,确定是否有其他可能的变动。 |
|
|
|
…… |
|
|
|
|
|
|
同时,风险监控中还包含一个不断识别风险的过程。因为在项目进行的过程中,周边情况总是在不断的动态变化过程中,这时就需要我们及时检查原来已经识别的风险是否还可能会发生。同时也需要去识别是否有新的风险可能会发生等。并且把这些更新的情况在风险识别表中记录下来。原来已经识别的风险部可能发生时,该风险的评估分值修改为0。比如服务器不能按时到位的风险,当服务器到位后,这个风险就不存在了,此时就可以把这个风险的评估指修订为0。
下表是一个项目进行过程中的风险识别表格:
编号 | 风险描述 | 判断标准 | 发生时机 | 危险度 | 可能性 | 预防措施 | 消除措施 | 识别日期 | 风险等级 | 已发生 |
1 | 评审不到位 | 每次评审发现的缺陷低于10个 | 0.9 | 0.6 | 0.9 | 评审时,根据评审内容分配到具体的每一个人,同时要求进行评审前准备 | 及时补充评审。 | 2005-11-30 | 48.60 | N |
2 | 需求变更频繁 | 需求分析结束后,需求变更数达到总需求数的5% | 0.6 | 0.6 | 0.6 | 进行需求管理,并且在需求发生变更时,严格地执行需求变更流程。并及时根据需求变更情况修改项目计划 | 与客户协调需求变更的问题。可以采取将变更需求纳入到下一个版本开发,或者延长约定的开发周期并增加费用。 | 2005-11-30 | 21.60 | N |
3 | 服务器不能按时到位 | 在获取日期前3天服务器还没有到位 | 0 | 0 | 0 | 根据计划,提前对服务器资源的落实进行跟催 | 寻找可替代资源,诸如配置相当的个人计算机临时使用 | 2005-11-30 | 0 | N |
4 | 数据库设计不合理 | 数据库设计变更3次 | 0.6 | 0.6 | 0.9 | 检查数据库设计找出不合理的地方,统一变更。 | 对设计进行重新评审。 | 2005-12-10 | 32.40 | N |