项目风险管理案例分析2778.pdf

《项目风险管理案例分析2778.pdf》由会员分享，可在线阅读，更多相关《项目风险管理案例分析2778.pdf（6页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、项目风险管理案例分析 1 公司背景简介 河北 H-A 会计师事务所是河北省财政厅对国有大中型企业进行社会审计的试点所;承担省直大中型企业的审计工作.具有丰富工作经验;拥有一批具有丰富实践经验的注册会计师.河北省某研究所是省直科研单位;现有 50 多位员工.在基于 WINDOWS平台开发软件方面;具备较丰富的实战技能.河北 H-A 会计师事务所在审计工作中发现;很多企业都采用了会计电算化软件;对审计工作提出新的要求.社会审计工作的需要;对开发计算机辅助审计软件的愿望越来越强烈.所以就联合河北省某研究所进行联合开发 2 实际项目分析 2.1 项目介绍 该 系 统 基 于 windows 和 sql

2、 server 进 行 开 发;开 发 工 具 是powerbulider.项目 开发过程中;共生成程序源代码约数万行;项目开发的难度和源代码行数都比预 计的要多.计算机辅助审计软件具有工作底稿制作能力和查证功能；数据可传递;能自 动生成和人工输入相结合;产生合并抵销分录；能自动产生勾稽无误的审计报告 和会计报表附注；有灵活开放的系统;方便用户进行二次开发等特点.2.2 开发队伍的风险 开发团队维持在 10 人上下;事务所提供 3 人;开发单位 6-7 人;有一些人 员只能部分时间工作;开发人员能够自始至终地参加整个项目的工作.开发人 员的流动基本能保证工作的连续性.2.3 技术风险 数据结构

3、复杂;关联比较多.需要创建新的算法或输入;输出技术；软件需要与其他软件产品的数据库系统接口；客户能确定所要求的功能是可行的.同时;由于当时审计软件在国内的应用尚处于起步阶段;开发人员普遍对该系统比较陌 生;这也带来了相当的技术风险.2.4 客户相关风险 用户对自己真正的需求并不是十分明确;他们认为计算机是万能的;只要简 单的说说自己想干什么就是把需求说明白了;而对业务的规则、工作流程却不愿 多谈;也讲不清楚.有的用户日常工作繁忙;他们不愿意付出更多的时间和精力 向分析人员讲解业务;这样加大分析人员的工作难度和工作量;也可能导致因业 务需求不足而使系统风险加大.2.5 项目按时完成的风险 另外;

4、这个项目也像许多其它软件项目一样;面临着竣工日期带来的巨大压 力.3 实际的风险管理状况 凭借公司在以往的经验;在此软件项目的整个生命周期中;任何阶段都有可能有风险存在;WBS 是完整表示项目;且伴随整个项目生命周期的项目要素;所以以 WBS 为基础进行风险管理;既可以方便地识别;标识相应的风险来源;又方便和项日其他工作一起;统一管理.在软件项目中;各阶段主要工作简述如下：启动阶段：进行项目预研;以确定项目是否立项;并对项目的范围进行比较清晰的定义；计划编制阶段：进行初步的需求分析;详细定义项目的范围;并对项目涉及的所有相关活动;做尽可能细的详细计划；执行阶段：详细分析需求;保证软件开发生命周

5、期各阶段中不同需求的来源是可追溯;并按需求进行设计、编码、测试;以确定软件产品达到计划给定的范围和标准;并做相应的部署测试；控制阶段：该阶段贯穿计划和执行两个阶段;主要进行各种控制 T 作;如需求变更、进度、费用控制等；收尾阶段：项目的收尾工作;主要是安装和维护；在软件开发生命周期的四个主要阶段中;通过研究不同阶段侧重点不同的阶段目标以及衡量不同阶段目标的标准;在软件开发的各个阶段中;即需求分析阶段、软件设计阶段、编码阶段和测试阶段;我们可以发现存在于各阶段中的风险项.并由项目经理在启动、计划、执行、控制、结束五个阶段予以控制.3.1 需求分析阶段 3.1.1、风险识别 表 1 需求阶段识别的

6、主要风险 3.1.2、风险分析 表 2 需求阶段风险定性分析 3.1.3、风险解决 表 3 需求阶段风险解决方案 3.2 设计阶段 3.2.1、风险识别 表 4 设计阶段识别的主要风险 3.2.2、风险分析 表 5 设计阶段风险定性分析 3.2.3、风险解决 表 6 设计阶段风险解决方案 4 实施效果与总结分析 4.1 实施效果 此项目开发的目标是为了向审计公司提供辅助审计管理系统.开发流程也是比较遵从软件工程的规范的.但是最终的结果却不尽人意;投入了比预料多几倍的人力物力.根据当时参与项目的同事的分析;失败的原因主要是：4.1.1、需求不明确 由于出发点和利益不同;系统开发者与用户对于同一问

7、题常有不同看法;这样需求分析的风险就逐渐加大了.另外对需求变更的控制做得不好.需求的改变;就会产生连锁反应;有时候这种反应会导致程序的不稳定;严重的时候;一个错误的修改引起另一处程序的错误;而新的错误的修改会导致更新的错误;更严重的情况;不是所有的错误都能被修改.4.1.2、技术风险 此软件数据结构复杂;逻辑关联性比较强.软件需要与第三方财务软件产品的数据库系统接口.带来了相当的技术开发困难;阻碍了项目的进行.由于以上原因到了测试阶段;未确定的需求和不断发现的 bug 成了灾难.结果测试当天就因为一个 bug 导致数据被误删和数据混乱.于是暂停测试;改为封闭式开发;并且继续增加人员;第二次修改

8、时是才发现整个数据结构也要发生变动;这就意味着无异于从新开发一次;所以最后不得不投入大量的人员予以弥补.分析原因;为什么这个项目会失败看来好像是需求没有做好;其实是没有把风险放在整个项目这个大系统下来对待;没有建立一套完整的风险管理机制;这样一来风险因素就容易被忽略.然而;软件项目前一阶段的失误会对下一阶段产生严重的影响.一旦发生了变化;就不得不修改设计、重写代码、修改测试用例、调整项目计划等等;为项目的正常的进展带来不尽的麻烦.所以;没有切实可行的风险管理过程机制;就很难有效地保证风险管理活动的效率.建立切实可行的风险管理过程机制是软件风险管理理论研究成果最终在实践中得到应用的最根本保证 4

9、.2 软件项目风险管理改进 IT 项目管理从某种意义上讲;就是风险管理.从理论上讲;虽然 IT 项目风险管理开始于项目开发生命周期的可行性研究阶段;但实际上风险管理应该贯穿于项目的始终;并需要持续的关注和评估.因此实施项目风险管理就要建立风险管理机制;从制度上加以保障;只有这样才能够及时识别风险并且能采取降低风险的好措施;从而减小 1T 项目的不确定性和偏差;最终顺利地把项目引向成功.根据实际情况;也可通过外部环境的优化对风险管理起到的支持作用;比如组织架构、人力资源等方面;所有这些措施都是对全面风险管理体系的内在支持.借助保障制度的实施;使我们以风险管理方法、技术等为核心基础;创造出一个适宜风险管理的软环境.通过外部环境的优化;促进内部核心功能的发挥.