项目风险评估new

1、项目风险评估一、前言2二、风险概述以及相应措施21.组织管理风险22.人员风险23.开发环境风险24.产品风险35.设计和实现风险36.过程风险3三、风险辨识31.策略风险32.管理风险33.开发环境风险34.技术风险45.人员技术及经验带来的风险4四、风险分析4五、风险驾驭4一、前言本文档主要针对软件开发涉及到的风险，整个MSF开发阶段的风险。以及对风险能做出的应对措施。软件风险主要来自两方面，一是软件管理，二是软件体系结构。软件产品的开发时工程技术与个人创作的有机结合。软件管理是保证软件开发工程化的手段。软件体系结构的合理程度是取决于集体智慧发挥的程度和经验的运用二、风险概述以及相应措施1

2、.组织管理风险01)仅由管理层或市场人员进行技术决策,导致计划进度缓慢,计划时间延长;02)低效的项目组结构降低生产率;03)管理层审查 决策的周期比预期的时间长;04)管理层作出了打击项目组织积极性的决定05)缺乏必要的规范,导至工作失误与重复工作;06)非技术的第三方的工作(预算批准、设备采购批准、法律方面的审查、安全保证等)时间比预期的延长;2.人员风险01)作为先决条件的任务(如培训及其他项目)不能按时完成;02)开发人员和管理层之间关系不佳,导致决策缓慢,影响全局;03)缺乏激励措施,士气低下,降低了生产能力;04)某些人员需要更多的时间适应还不熟悉的软件工具和环境;05)项目后期加

3、入新的开发人员,需进行培训并逐渐与现有成员沟通,从而使现有成员的工作效率降低;06)由于项目组成员之间发生冲突,导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作;07)不适应工作的成员没有调离项目组,影响了项目组其他成员的积极性;08)没有找到项目急需的具有特定技能的人。3.开发环境风险01)设施未及时到位;02)设施拥挤、杂乱或者破损;03)开发工具未及时到位;04)开发工具不如期望的那样有效,开发人员需要时间创建工作环境或者切换新的工具;05)新的开发工具的学习期比预期的长,内容繁多;4.产品风险01)矫正质量低下的不可接受的产品,需要比预期更多的测试、设计和实现工作;02)开发额外的

4、不需要的功能(镀金),延长了计划进度;03)严格要求与现有系统兼容,需要进行比预期更多的测试、设计和实现工作;04)要求与其他系统或不受本项目组控制的系统相连,导致无法预料的设计、实现和测试工作;05)在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题;06)开发一种全新的模块将比预期花费更长的时间;07)依赖正在开发中的技术将延长计划进度;5.设计和实现风险1)设计质量低下,导致重复设计;2)一些必要的功能无法使用现有的代码和库实现,开发人员必须使用新的库或者自行开发新的功能;3)代码和库质量低下,导致需要进行额外的测试,修正错误,或重新制作;4)过高估计了增强型工具对计划进度的

5、节省量;5)分别开发的模块无法有效集成,需要重新设计或制作;6.过程风险1)大量的纸面工作导致进程比预期的慢;2)前期的质量保证行为不真实,导致后期的重复工作;3)太不正规(缺乏对软件开发策略和标准的遵循),导致沟通不足,质量欠佳,甚至需重新开发;4)过于正规(教条地坚持软件开发策略和标准),导致过多耗时于无用的工作;5)向管理层撰写进程报告占用开发人员的时间比预期的多;6)风险管理粗心,导致未能发现重大的项目风险;三、风险辨识1.策略风险:开发产品不符合小组的整体商业策略2.管理风险:由于重点的转移或者人员变动失去管理层的支持的风险3.开发环境风险:与开发工具的可用性和质量相关的风险4.技术

6、风险: 指在设计、实现、接口、验证、维护、规约的二义性、技术的不确定性、陈旧的技术等方面存在的风险。技术风险威胁到软件开发的质量及交付的时间，如果技术风险变成现实，则开发工作可能变得很困难或根本不可能5.人员技术及经验带来的风险: 与参与工作的软件工程师的总体技术水平及项目经验相关的风险: (1)性能风险：产品能够满足需求和符合使用目的的不确定程度。(2)成本风险：项目预算能够被维持的不确定的程度。(3)支持风险：软件易于纠错、适应及增强的不确定的程度。(4)进度风险：项目进度能够被维持且产品能按时交付的不确定的程度四、风险分析在进行了风险辨识后，我们就要进行风险估算，风险估算从以下几个方面评

7、估风险清单中的每一个风险：(1)建立一个尺度，以反映风险发生的可能性；(2)描述风险的后果；(3)估算风险对项目及产品的影响；(4)标注风险预测的整体精确度，以免产生误解。 风险类别概率影响交付日期的不确定进度风险5%导致项目无法再规定的时间内完成技术达不到预期效果技术风险5%致使产品与预期的设想偏离前期的质量保证不符实过程风险5%拖延交付日期风险管理粗心导致未能发现重大的项目风险过程风险15%致使后期开发，文档等工作修改甚至是影响整个项目的开发进度分别开发的块无法有效集成设计和实现风险10%拖延交付日期，严重的影响到各个块的开发，也许会导致重新设计开发一种全新的模块比预期花费的时间长产品风险

8、40%新模块需要与旧模块磨合，致使项目无法再规定的时间内完成开发工具不如期望的那么有效开发环境风险10%需要学习新技术添加额外的需求需求风险10%后期的开发等工作被拖延 五、风险驾驭风险驾驭包括对策指定、风险缓解、风险监控、风险跟踪等内容。 所有风险分析活动都只有一个目的辅助项目组建立处理风险的策略。如果软件项目组对于风险采取主动的方法，则避免永远是最好的策略。这可以通过建立一个风险缓解计划来达到即制定对策。 对不同的风险项要建立不同的风险驾驭和监控的策略比。如对于开发人员离职的风险项目开始时应作好人员流动的准备采取一些措施确保人员一旦离开时项目仍能继续；制定文档标准并建立一种机制保证文档及时

9、产生；对每个关键性技术岗位要培养后备人员。对于技术风险，可以采用的策略有，对采用的关键技术进行分析，避免软件在生命周期中很快落后；在项目开发过程中保持对风险因素相关信息的收集工作，减少对合作公司的依赖尤其是对延续性强的项目应该尽可能地吸收合作公司的技术并变为自己的技术，避免因为可能发生的与合作公司合作的终止带来的影响和风险降低投入成本。 一个有效的策略必须考虑风险避免、风险监控和风险管理及意外事件计划这样三个问题。风险的策略管理可以包含在软件项目计划中，或者风险管理步骤也可以组成一个独立的风险缓解、监控和管理计划（RMMM计划）。RMMM计划将所有风险分析工作文档化，并且由项目管理者作为整个项目计划的一部分来使用，RMMM计划的大纲主要包括：主要风险，风险管理者，项目风险清单，风险缓解的一般策略、特定步骤，监控的因素和方法，意外事件和特殊考虑的风险管理等。一旦建立了RMMM计划，我们就开始了风险缓解及监控，风险缓解是一种避免问题的活动，风险监控则是跟踪项目的活动。它有三个主要目的：评估一个被预测的风险是否真的发生了；保证为风险而定义的缓解步骤被正确地实施；收集能够用于未来的风险分析信息。 软件开发是高风险的活动。如果项目采取积极风险管理的方式，就可以避免或降低许多风险，而这些风险如果没有处理好，就可能使项目陷入瘫痪中。因此在软件项目管理中还要进行风险跟踪。