项目风险及规避.docVIP

广东海洋大学学生实验报告书（学生用表） 实验名称 项目规划 课程名称 软件工程 成绩 学院（系） 软件学院 专业 软件工程 班级 学生姓名 学号 实验地点 实验时间 2016-4-28 第3大节 9风险分析及规避措施 9.1产品风险管理计划 对于本项目的可能采取的风险管理方法主要有以下几种类别： 专家评判干法：经验估计法、Delphi法、清单法与当量分析 问卷法：调查与统计分析方法 简单风险结构描述与分析工具：决策树分析法、层次分析法、风险矩阵法 复杂风险结构描述与评估工具：影响图、Petri网、网络分析技术 可靠性分析法：故障模式及影响分析、概率风险评估 人工智能方法：贝叶斯网络、粗糙集理论、模糊集理论、人工神经网络、专家系统 成本评估模型与工具：构造型成本模型、蒙特卡洛模拟、成本效益分析 风险管理周期与频率： 风险管理预算： 预备风险资金15000元，用于削减项目成本、进度、范围、质量和资源等方面的风险。 9.2风险识别 通过讨论确定了七个主要的风险，下面是风险清单： 9.2.1组织风险 项目缺乏企业高层的支持和积极参与 项目进程过程中企业经历重组或管理层变动 项目所需的业务流程的变化与组织文化不相匹配 由于企业战略的变化，项目所需资源被转移 项目没有明确的商业价值，而是出于某些政治上的原因 项目计划没有征求所有相关方的同意 项目实施对组织结构具有较大影响 项目实施对业务流程具有较大影响 9.2.2需求风险 错误的系统需求 系统范围或需求频繁变动 不清晰或误解的需求 由于对该应用领域较陌生并且缺乏相关知识，用户和开发人员对系统需求不能很好定义 用户与开发人员一技术为中心，而忽视了商业需求 相关人员对系统需求定义存在冲突 用户对系统功能和需求缺乏了解 没有定义，项目的成功标准 难以界定系统的输入和输出 系统需求分析不充分，有遗漏 9.2.3用户风险 缺乏用户的合作和责任 用户提出不切实际的期望 用户过度依赖咨询顾问，忽略了自身的重要作用 用户抵触变化 用户对项目持否定态度 缺乏足够的用户参与 用户与开发人员之间存在分歧或冲突 用户部门之间存在冲突 用户没有按排足够用于系统维护阶段的预算 9.2.4技术风险 项目采用的是以前未曾实用过的新技术 缺乏有效的开发方法 项目需求与已有的其他系统进行较多的集成 技术相当复杂 使用不成熟的技术 9.2.5团队风险 项目开发团队成员缺乏责任感 项目团队成员在性格、态度、观念方面存在冲突 项目团队成员变动频繁和严重短缺 团队成员不熟悉自己的任务 开发人员缺乏项目所需的技能 开发人员没有经过充分培训 9.2.6计划和控制风险 没有清晰地设立项目里程碑 缺乏有效的项目管理方法 项目计划制订得很糟糕 项目所需资金和资源估计不足 项目干系人之间缺乏有效的沟通 项目所需时间和进度估计不足 对项目进展状况监控不够 没有实行有效的变化管理 对相关方（如开发商和顾问）的角色和责任没有进行明确和合理的规定 风险管理很糟糕 选择了错误的系统开发方法 对顾问、开发商及合同方缺乏控制 9.2.7市场和竞争风险 市场发生变化以至于项目不能获得预期的商业价值 竞争者着手开发类似系统或采取其他难以防范的行动 合作伙伴、客户、供应商和商业团体做出对项目产生影响的不利举动 市场上新的替代产品、服务或技术出现使系统变得过时 项目相关方没有提供很好的服务和帮助 项目依赖过多的供应商，缺乏供应商之间的合作，软件包不兼容很难进行集成 9.3风险定性分析（包括定性分析与定量分析） 类别 潜在风险事件 风险发生概率的定性等级 风险后果影响的定性等级 综合风险指数 组织风险 项目缺乏企业高层的支持和积极参与 高 灾难性的 1 项目进程过程中企业经历重组或管理层变动 中 轻度 7 项目所需的业务流程的变化与组织文化不相匹配 低 严重 7 由于企业战略的变化，项目所需资源被转移 低 严重 7 项目没有明确的商业价值，而是出于某些政治上的原因 低 轻度 10 项目计划没有征求所有相关方的同意 中 轻度 9 项目实施对组织结构具有较大影响 高 灾难性的 1 项目实施对业务流程具有较大影响 高 严重 2 需求风险 错误的系统需求 高 灾难性的 1 系统范围或需求频繁变动 极高 轻度 8 不清晰或误解的需求 中 轻度 8 由于对该应用领域较陌生并且缺乏相关知识，用户和开发人员对系统需求不能很好定义 低 严重 6 用户与开发人员一技术为中心，而忽视了商业需求 低 轻度 9 相关人员对系统需求定义存在冲突 高 轻度 8 用户对系统功能和需求缺乏了解 低 轻微 11 没有定义，项目的成功标准 低 轻微 11 难以界定系统的输入和输出 中 轻度 8 系统需求分析不充分，有遗漏 高 轻度 7 用户风险 缺乏用户的合作和责任 中 轻度 8 用户提出不切实际的期