1 / 13
文档名称:

最新软件项目风险管理(同名21103).doc

格式:doc   大小:113KB   页数:13页
下载后只包含 1 个 DOC 格式的文档,没有任何的图纸或源代码,查看文件列表

如果您已付费下载过本站文档,您可以点这里二次下载

分享

预览

最新软件项目风险管理(同名21103).doc

上传人:lu2yuwb 2022/3/10 文件大小:113 KB

下载得到文件列表

最新软件项目风险管理(同名21103).doc

文档介绍

文档介绍:软件工程风险管理(同名21103)
软件工程风险管理
一、风险管理概述
软件风险是指软件开发过程中及软件产品本身可能造成的伤害或损失。风险关注未来的事情,这意味着,风险涉及选择及选择本身包含的不确定性,在软件开发过程及软件产品素质以及开发者和客户定期通信的能力相关的风险。
过程定义——与软件过程被定义的程度以及它们被开发组织所遵守的程度相关的风险。
开发环境——与用以建造产品的工具的可用性及质量相关的风险。
建造的技术——与待开发软件的复杂性以及系统所包含技术的“新奇性〞相关的风险。
人员数目及经验——与参与工作的软件工程师的总体技术水平及工程经验相关的风险。
风险条目检查表能够以不同的方式来组织。与上述话题相关的问题可以由每一个软件工程来答复。这些问题的答案使得方案者能够估算风险产生的影响。
1、产品规模风险
工程风险是直接与产品规模成正比的。下面的风险检查表中的条目标识了产品〔软件〕规模相关的常见风险:
是否以LOC或FP估算产品的规模;
对于估算出的产品规模的信任程度如何;
是否以程序、文件或事务处理的数目来估算产品规模;
产品规模与以前产品的规模的平均值的偏差百分比是多少;
产品创立或使用的数据库大小如何;
产品的用户数有多少;
产品的需求改变多少?交付之前有多少?交付之后有多少?
复用的软件有多少?
2、商业影响风险
销售部门是受商业驱动的,而商业考虑有时会直接与技术实现发生冲突。下面的风险检查表中的条目标识了与商业影响相关的常见风险:
本产品对公司的收入有何影响;
本公司是否得到公司高级管理层的重视;
交付期限的合理性如何;
将会使用本产品的用户数及本产品是否与用户的需要相符合;
本产品必须能与之互操作的其它产品/系统的数目;
最终用户的水平如何;
政府对本产品开发的约束;
延迟交付所造成的本钱消耗是多少;
产品缺陷所造成的本钱消耗是多少;
对于待开发产品的每一个答复都必须与过去的经验加以比较。如果出现了较大的百分比偏差或者如果数字接近过去很不令人满意的结果,那么风险较高。
3、客户相关风险
客户有不同的需要。一些人只知道他们需要什么;而另一些人知道他们不需要什么。一些客户希望进行详细的讨论,而另客户那么满足于模糊的承诺。
客户有不同的个性。一些人喜欢享受客户的身份,而另一些人那么根本不喜欢做为客户。一些人会快乐地接受几乎任何交付的产品,并能充分利用一个不好的产品;而另一些人那么会对质量差的产品猛烈抨击。一些人会对质量好的产品表示赞赏;而另一些人那么不管怎样都抱怨不休。
客户和供应商之间也有各种不同的通信方式。一些人非常熟悉产品及生产厂商;而另一些人那么可能素未谋面,仅仅通过信件来往和电话与生产厂商沟通。
一个“不好的〞客户可能会对一个软件工程组能否在预算内完成工程产生很大的影响。对于工程管理者而言,不好的客户是对工程方案的巨大威胁和实际的风险。下面的风险检查表中的条目标识了与客户特征相关的常见风险:
你以前是否曾与这个客户合作过;
该客户是否很清楚需要什么;他能否化时间把需求写出来;
该客户是否同意花时间召开正式的需求收集会议,以确定工程范围;
该客户是否愿意建立与开发者之间的快速通信渠道;
该客户是否愿意参加复审工作;
该客户是否具有改产品领域的技术素养;
该客户是否愿意你的人来做他们的工作;
该客户是否了解软件过程;
如果对于这些问题中的任何一个答案是否认的,那么需要进一步的调研,以评估潜在地风险。
4、过程风险
如果软件过程定义得不清楚;如果分析、设计、测试以无序的方式进行;如果质量是每个人都认为很重要的概念,但没有人切实采取行动来保证它,那么这个工程就处在风险之中。
过程问题:
高级管理层是否有一份已经写好的政策陈述,该陈述中强调了软件开发标准过程的重要性;
开发组织是否已经拟定了一份已经成文的、用于本工程开发的软件过程的说明;
开发人员是否同意按照文档所写的软件过程进行开发工作,并自愿使用它;
该软件过程是否可以用于其它工程;
管理者和开发人员是否接受过一系列的软件工程培训;
是否为每一个软件开发者和管理者提供了印好的软件工程标准;
是否为作为软件过程一局部而定义的所有交付物建立了文档概要及例如;
是否认期对需求规约、设计和编码进行正式的技术复审;
是否认期对测试过程和测试情况进行复审;
是否对每一次正式技术复审的结果建立了文档,其中包括发现的错误及使用的资源;
有什么机制来保证按照软件工程标准来指导工作;
是否使用配置管理来维护系统/软件需求、设计、编码、测试