RUP和IPD流程的优缺点

发布时间:2010-01-20 共2页

  RUP的过程改进,倡导针对不同类型项目进行适当的裁剪,实际上这也是一种灵活适应的方式、随需而变的思想。我对此是理解并赞同的,但是我对RUP却一直保持一种相对谨慎的态度。

  对于RUP来说,首先,我认为它过于理想化和理论化,RUP 是过程组件、方法以及技术的框架,你可以将其应用于任何特定的软件项目,由用户自己限定 RUP 的使用范围。对于各种类型的软件项目,RUP并未给出具体的自身裁减及实施策略,总有些无依据可循的感觉。你既可以说它能解决任何问题,也可以说它什么都不是;其次,RUP从本质来说还是一个强调设计和规范的软件方法,从这个角度来讲,与传统的瀑布模型没有太差别,它的灵活性较之敏捷方法还是相对较弱的。在一些小型软件项目、特别是不可预测的软件项目开发中,面临着各种紧急需求、面临着时间压力,沿用RUP是很难应付自如的。但是在另一方面,RUP强调对知识的收集、整理和加工定义,强调在软件开发的时候要有好的体系结构。所以它还是很有利于知识的积累和共享的。

  相比RUP ,敏捷方法如XP则更为灵活,倡导尽早的、持续的交付有价值的软件满足用户需要。用交流沟通取代详尽的文档,强调团队的主动、自律、自我组织和自发管理。而XP也是以代码为核心的一种方法,这里有很多的东西是未知的,知识只存在于两个地方:开发者的头脑和最后的代码。对于项目管理者来说,他们会认为敏捷开发方法弱化了知识管理的概念,而实际上敏捷开发注重的是最有价值的知识的积累和沉淀。

  如何灵活应对各种项目风险、如何最化优先满足用户价值、又如何能够有效的控制项目开发过程、如果做好项目过程中的知识管理,是每一个软件项目管理者都需要深入思考的问题。RUP的倡导者一直强调RUP裁剪,实际上我认为RUP不仅仅是需要自身的裁剪,还需要学会融合。在RUP裁剪的同时,适宜的融合敏捷开发的各种实践。不要认为RUP与XP是矛盾的,其实不然,它们具有不同的原理、具有不同的应用领域。在 RUP 中融合了 XP 技术时,才会得到过程的正确量,既满足了项目所有成员的需要,又解决了所有主要的项目风险问题。对于一个工作于高信任环境中的小型项目团队,其中用户是团队的一部分,那么 XP 完全可以胜任。对于团队越来越分散,代码量越来越,或者构架没有很好定义的情况,您需要做一些其他工作。在用户交互具有"契约"风格的项目中,仅有 XP 是不够的。RUP 是一个框架,可以从 RUP 出发,在必要时以一组更健壮的技术来扩展 XP。

   RUP最佳实践包括:
  1. 迭代开发: RUP的开发过程建立在一系列迭代之上,每次迭代都有一个固定的时间限制(例如四个星期),称为"时间盒",每次迭代结束的时候都发布一个稳定的小版本,该版本是最终系统的子集。"时间盒"是迭代开发中的关键概念:它意味着迭代周期的期限是固定的,如果目标没有完成,则放弃本次迭代的需求,而不是延长迭代的时间。
  2. 管理需求
  3. 使用基于组件的构架
  4. 可视建模
  5. 持续的质量验证
  6. 控制变更

百分百考试网 考试宝典

历年真题,视频课件,考试资料,助力考试顺利过关!

立即免费试用