软件项目风险管理概述

软件项目风险是指在软件开发过程中遇到的预算和进度等方面的问题以及这些问题对软件项目的影响。软件项目风险会影响项目计划的实现,如果项目风险变成现实,就有可能影响项目的进度,增加项目的成本,甚至使软件项目不能实现。因此软件项目风险管理是软件质量保障的一项重要内容。

  我们根据多年的风险评估经验,在本文中阐述下风险管理的概念以及分类。

  风险管理概念

   风险管理就是评估风险出现的概率及产生的影响,然后建立一个规划来管理风险。风险管理的主要目标是预防软件项目风险。 如果对项目进行风险管理,就可以最大限度的减少风险的发生。但是,目前国内的软件企业不太关心软件项目的风险管理,结果造成软件项目经常性的延期、超过预 算,甚至失败。成功的项目管理一般都对项目风险进行了良好的管理。因此任何一个系统开发项目都应将风险管理作为软件项目管理的重要内容。

  风险分类

  软件项目的风险体现在以下四个方面:需求、技术、成本和进度。IT项目开发中常见的风险有如下几类:

  1、需求风险

  需求已经成为项目基准,但需求还在继续变化;需求定义欠佳,而进一步的定义会扩展项目范畴;添加额外的需求;产品定义含混的部分比预期需要更多的时间;制定需求过程中客户参与不够;缺少有效的需求变化管理过程。

  2、计划编制风险

   计划、资源和产品定义全凭客户或上层领导口头指令,并且不完全一致;计划是优化的,是“最佳状态”,但计划不现实,只能算是“期望状态”;计划基于使用 特定的小组成员,而那个特定的小组成员其实指望不上;产品规模比估计的要大;完成目标日期提前,但没有相应地调整产品范围或可用资源;涉足不熟悉的产品领 域,花费在设计和实现上的时间比预期的要多。

  3、组织和管理风险

  仅由管理层或市场人员进行技术决策,导致计划进度缓慢,计划时间延长;低效的项目组结构降低生产率;管理层审查决策的周期比预期的时间长;预算削减,打乱项目计划;缺乏必要的规范,导致工作失误与重复工作;非技术的第三方的工作(预算批准、设备采购批准、法律方面的审查、安全保证等)时间比预期的延长。

  4、人员风险

   作为先决条件的任务(如培训及其他项目)不能按时完成;开发人员和管理层之间关系不佳,导致决策缓慢,影响全局;缺乏激励措施,士气低下,降低了生产能 力;某些人员需要更多的时间适应还不熟悉的软件工具和环境;项目后期加入新的开发人员,需进行培训并逐渐与现有成员沟通,从而使现有成员的工作效率降低; 由于项目组成员之间发生冲突,导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作;不适应工作的成员没有调离项目组,影响了项目组其他成员的积极性; 没有找到项目急需的具有特定技能的人。

  5、开发环境风险

  设施未及时到位;设施虽到位,但不配套,如没有电话、网线、办公用品等;设施拥挤、杂乱或者破损;开发工具未及时到位;开发工具不如期望的那样有效,开发人员需要时间创建工作环境或者切换新的工具;新的开发工具的学习期比预期的长,内容繁多。

  6、客户风险

   客户对于最后交付的产品不满意,要求重新设计和重做;客户的意见未被采纳,造成产品最终无法满足用户的审核;客户没有或不能参与规划、原型和规格阶段的 审核,导致需求不稳定和产品生产周期的变更;客户答复的时间(如回答或澄清与需求相关问题的时间)比预期长;客户提供的组件质量欠佳,导致额外的测试、设计和集成工作,以及额外的客户关系管理工作。

  7、产品风险

   矫正质量低下的不可接受的产品,需要比预期更多的测试、设计和实现工作;开发额外的不需要的功能,延长了计划进度;严格要求与现有系统兼容,需要进行比 预期更多的测试、设计和实现工作;要求与其他系统或不受本项目组控制的系统相连,导致无法预料的设计、实现和测试工作;在不熟悉或未经检验的软件和硬件环 境中运行所产生的未预料到的问题;开发一种全新的模块将比预期花费更长的时间;依赖正在开发中的技术将延长计划进度。

  8、设计和实现风险

   设计质量低下,导致重复设计;一些必要的功能无法使用现有的代码和库实现,开发人员必须使用新的库或自行开发新的功能;代码和库的质量低下,导致需要进 行额外的测试,修正错误,或重新制作;过高估计了增强型工具对计划进度的节省量;分别开发的模块无法有效集成,需要重新设计或制作。

  9、过程风险

   大量的纸面工作导致进程比预期的慢;前期的质量保证行为不真实,导致后期的重复工作;不正规,导致沟通不足,质量欠佳,甚至需重新开发;过于正规,导致 过多耗时于无用的工作;向管理层撰写进程报告占用开发人员的时间比预期的多;风险管理粗心,导致未能发现重大的项目风险。

  路漫漫其修远兮,我中心将与大家共同求索。

====================================分割线================================

最新内容请见作者的GitHub页:http://qaseven.github.io/

时间: 2024-09-18 14:58:11

软件项目风险管理概述的相关文章

《Python数据挖掘:概念、方法与实践》一2.3 项目—发现软件项目标签中的关联规则

2.3 项目-发现软件项目标签中的关联规则 1997年,Freshmeat网站创立,它是一个跟踪免费.自由和开放源码软件(FLOSS)项目的目录.2011年,该网站更名为Freecode.在出售.并购和多次网站重新设计之后,2014年,Freecode网站的所有更新都停止了.这个网站仍然在线,但是不再更新,目录中也不再加入任何新项目.现在,Freecode是20世纪90年代和21世纪初FLOSS项目相关信息的快照.每个软件项目的相关事实包括名称.描述.下载软件的URL.描述其特征的标签.代表其流

软件项目质量管理与度量

软件项目/产品的质量问题一直困扰软件企业.监理方和甲方,如何预防.发现.治理软件项目/产品质量问题,是目前我国it发展面临巨大的挑战,这也是it发展过程中关注的主要问题.软件企业.甲方和监理方在研发过程中常常要面临很多难题: 1.软件质量管理基础 (1)质量的概念与定义:(2)软件的质量要素:(3)软件质量评价的准则:(4)iso 9000软件质量体系结构:(5)软件质量保证过程:(6)质量管理大师简介:(7)质量管理的发展历程: 2.软件质量与质量管理 (1)软件质量面临的挑战及模糊认识:(2

《Python数据挖掘:概念、方法与实践》——2.3节项目—发现软件项目标签中的关联规则

2.3 项目-发现软件项目标签中的关联规则1997年,Freshmeat网站创立,它是一个跟踪免费.自由和开放源码软件(FLOSS)项目的目录.2011年,该网站更名为Freecode.在出售.并购和多次网站重新设计之后,2014年,Freecode网站的所有更新都停止了.这个网站仍然在线,但是不再更新,目录中也不再加入任何新项目.现在,Freecode是20世纪90年代和21世纪初FLOSS项目相关信息的快照.每个软件项目的相关事实包括名称.描述.下载软件的URL.描述其特征的标签.代表其流行

当程序员变成软件项目经理

当你预期的那一天,也许是害怕的那一天,终于来到了:从工程师的队伍里你被提拔到了软件项目领导或者团队领导的位置.这也许就是你选择的职业道路,或许你不太情愿,将就尝试一下.无论在哪种情况下,你都可能缺少工程学科.人员管理以及领导能力的相关教育 这需要更多的领导能力和管理(它们不是一回事),而不能象Dilbert(译注:著名IT漫画主角)那样简单地和老板对抗了.当你考虑新的目标时,请考虑下面的活动计划列表.一次就抓住了每个亮点,这是不可能的.但是这份建议说明可以帮助你将注意力放在可以提高你和你的团队绩

小型软件项目开发流程探讨

一.导言 国内很多项目都是小型项目,参与人员少(两到五个人),要快速交付(一两个月) . 要成功完成这种项目,除了使用成熟且被团队成员熟练使用的技术之外,有一个良好的开发流程,也是很必要的. 二.小型软件项目开发流程 下图是我对小型软件项目开发流程的一个设想: 需求分析的重要性想必大家都应该清楚,对于项目来说,满足用户的需求是第一位的. 因为时间紧,系统设计经常被忽略. 这会留下很大的隐患,国内很多项目的需求通常是很简略的,还需要在系统设计阶段把一些需求进一步的明确. 不然会出现因为前期一些需求

CMM可重复级在特殊软件项目中的应用

引言 由 SEI 在 1991 年 8 月发布的软件能力成熟度模型( SW-CMM ),用来评估软件企业的 成熟度级别,使软件企业了解自己的优势和不足之处,从而持续地改进企业的软件开发过程,提高管理水 平,降低管理成本,保证软件开发效率和软件质量. 然而, CMM 是针对大型项目和企业制定的. 小项目和中小企业由于受到相应条件的限制,如组织结构.角色和关系.过程模式定义等,生搬硬套 CMM 框架只能给自己带来沉重的负担.可取的做法是把 CMM 作为一个参考,从 CMM 评估体系中汲取适合于自 身

使用IBM RTC管理软件项目工程中的日常开发任务

IBM Rational Team Concert(RTC)作为软件协同开发工具,被逐渐应用在大型项目的生产过程中,维系着规模庞大的项目组织团队,有条不紊地管理每一项开发任务,从而为创造高质量的软件产品打下坚实基础. RTC 提供了贯穿整个http://www.aliyun.com/zixun/aggregation/17799.html">开发过程的集成环境,包括:需求定义.迭代计划.源码控制.自动构建.缺陷跟踪.变更管理以及统计报表等功能.本文将通过三个层次,自下而上地详细阐述如何使用

2012年最可怕的软件项目事故汇总

数十亿美元就这样打了水漂--今年多个软件项目遭遇失利,此类事故已经引起管理者的高度重视. 诚然,很多企业在软件项目的推进过程中获得了成功,也将供应商所承诺的新特性与新功能顺利传递给终端用户:更低的运营成本.更简洁的管理流程以及各类足以取悦消费者的要素. 但遗憾的是,仍然有一些项目以失败告终:投入巨资的客户只能面对"断瓦残垣"而欲哭无泪,并被卷入危害事业进展.有损合作关系的漫长诉讼当中. 而从积极的角度来看,我们能够将这些过往的事故当作前车之鉴,无论是供应商还是项目客户都能够从中吸取经验

关于软件项目后期Fix bug的意义之我见

众所周知:基本上所有的软件项目到后期必不可少的是fix bug,一个软件在交付客户后或交给测试人员测试时都存在一些程序员意想不到的问题.现在有一些成熟的bug跟踪系统,譬如:bugzero,bugzilla, redmine等等. 解bug是很头痛的问题,一般是以下原因引起的: (1)设计上的缺陷: (2)写代码时考虑不周全: (3)测试人员无中生有: (4)所依赖的插件,框架本身的缺陷. 第一种情况:最棘手,需要修改程序架构,费时又费力,但是不改又不行总不能要客户该需求,按照你的程序来吧.没办