风险管理-软件项目管理的精髓

风险管理-软件项目管理的精髓

ID:44672157

大小:34.55 KB

页数:4页

时间:2019-10-24

风险管理-软件项目管理的精髓_第1页
风险管理-软件项目管理的精髓_第2页
风险管理-软件项目管理的精髓_第3页
风险管理-软件项目管理的精髓_第4页
资源描述:

《风险管理-软件项目管理的精髓》由会员上传分享,免费在线阅读,更多相关内容在工程资料-天天文库

1、风险管理:软件项目管理的精髓缺乏真正的风险管理与控制是导致软件项忖失败的最重要原因。实施有效的风险管理,做到真正风险驱动的迭代式开发,尽早排除架构(性能上)的风险也是最重要的。因此,风险管理是软件项目管理的第一管理要点。当笔者三年前读到《漫谈金业应用项目的软件开发过程:一个PRM系统实施的经验与教训》时,就发现它是一篇非常难得的好文章。国内类似这样的软件工程案例分析太少了,很多人没有时间写或舍不得与旁人分享具中的美妙,何况这篇文章还是专门针对XP、RUP并涉及到敏捷统一过程实践的。除了这篇PRM(伙伴关系管理)案例外,Johnson其实早在2002年7刀还发表过一篇《从一个项冃

2、谈XP在国内的应用》,该文在网络上流传甚广。这两篇文章好像是国内互联网上最早公开的XP(极限编程)实践案例,还是尝试XP、RUP整合的案例。姑且不论它们是否真正做到了敏捷,整合是否成功,但这対个应用案例的结果恰好一个成功,一个失败,其价值就在于真实性和典型性,具有很好的说服力和教育意义。匚不管结果如何,PRM原文的篇幅不长,却有很多值得我们借鉴和学习的地方。笔者认为这个项H无论从商务角度,还是从工程技术的角度来看,都是比较失败的。PRM系统虽然通过2个月紧张的敏捷、迭代开发并准时交付使用,但却后来出现性能问题,人半年之后仍然没有通过客户验收,不但有几十万尾款没有收到,而且还影响

3、了开发商其它项口的投标。为什么一个曾一度成功按时交付的系统,在新旧系统数据集成、上线运行的儿个月后会出现严重的性能问题,并暴露出系统架构设计上的缺陷,导致迟迟无法获得客户的信任,让项R各方都陷于被动和尴尬呢?是XP、RUP不行?还是敏捷过程、方法不行?有没有可能事先避免这种典型的风险呢?以上所有这些有趣的问题,都值得我们深入探究。敏捷开发的基础是首先做到迭代式(Iterative)开发。迭代不仅仅是把整个系统开发任务逐一分解、按阶段分步骤来实现的。如果迭代的含义仅仅停留在这个层面上,那么提出用迭代演进式过程取代瀑布型开发模型也就毫无意义,因为我们做任何T作本来就是耍一天一天、一

4、块一块地来完成,不管瀑布型还是演进式皆如此。迭代真正的目的是为了通过加速客户反馈,显着地消除开发风险,这就要求每次迭代结束必须有一个可运行、可演示的系统。这时的系统可能功能上还不完整,仅仅是一个骨架,但它总是系统开发中最难、最重要同时是风险最大的部分。RUP核心Z—:风险驱动的迭代风险驱动的迭代是RUP的核心特征Z-,XP对此强调的不够,在早期的XP项冃屮主耍是客户驱动的。所以,真正的迭代式开发在项冃早期就允许客户对可运行的系统进行验证,从而使项冃的风险减到最小。开发工作也应该根据风险的人小來安排,通过迭代及时调整优先级,风险越大的任务越应该及早设计、实现、测试和反馈。我们知道

5、,RUP从风险驱动出发把一个软件项日分为四个阶段:起始阶段、细化阶段、构造阶段和移交阶段,这四个阶段分别对应着项H的四个里程碑。起始阶段主要消除项冃的业务风险,细化阶段应该尽力消除项H的主要技术风险:架构风险(同时包括功能和非功能两方面)。很遗憾,PRM项目是在到了项目最后一个阶段:移交阶段。在系统运行了几个月、数据迁移完成之后才发现架构设计上存在着严重的性能缺陷需要修补。重要的是:在项目之初的合同上其实就己经对数据迁移、上线运行的要求作岀了规定。这导致了最大架构级风险:系统性能满足用户的真实需要吗?直到临近项目结束也未能被消除。实际上PRM项目的“细化阶段”并未真正完成,建立

6、稳定、可靠的系统架构的里程碑忖标也从未达到。在项H几近成功、圆满结束的时候,突然爆炸一颗硕大的“地雷”(严重的系统缺陷或问题),导致项H进度拖延甚至失控,人员失和,资金拖欠,这就是软件开发屮最糟糕的一种情况。不幸的是,这种在齐种经典教材中都能人量看到的案例,再一次地在已经(部分)采用了敏捷XP、RUP实践的PRM项日上重演了。那么,我们有没有可能事先防范PRM项目这颗延迟爆炸的“地雷”呢?当年PRM项目已经花了10个月的时间,却仍未能通过客户验收。前期用了2个月完成功能开发,2个月部署和试运行,从第5个月完成实际数据导入、开始正式运行起,就出现了严重的性能问题。随后的6个月基本

7、上都用在了系统的性能优化和改进上。总体上项冃开发给人一种手忙脚乱、进度失控的感觉。现在看来,PRM项Fl的进度至少延误了一倍时间。软件工程不相信眼泪如果PRM团队和客户从一开始就意识到系统潜在的性能问题,明确了对系统容量的要求;如杲PRM系统的架构师拥有足够的设计经验,系统表示层、控制层和数据资源层在上线之前就已经得到优化,捉供了足够的性能;如果架构设计评审产生了真正的效用;如果PRM团队做到了完备的系统测试;如果时间能够倒流……。所有这些“如杲”当屮,只要有一条灵验,那么那颗可恶的“地雷”

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。