关于RUP实用性的讨论

发现有网友提出关于rup实用性的疑问，觉得是个抛砖引玉的话题，欢迎大家参与讨论

 

何为RUP：

Rational Unified Process（简称RUP）是一套软件工程过程，主要由Ivar Jacobson的 The Objectory Approch 和 The Rational Approch 发展而来。同时，它又是文档化的软件工程产品，所有RUP 的实施细节及方法导引均以Web文档的方式集成在一张光盘上，由Rational公司开发、维护并销售。RUP又是一套软件工程方法的框架，各个组织可根据自身的实际情况，以及项目规模对RUP进行裁剪和修改，以制定出合乎需要的软件工程过程。

RUP 吸收了多种开发模型的优点，具有很好的可操作性和实用性、从它一推出市场，凭借Booch、Ivar Jacobson、以及Rumbaugh 在业界的领导地位、以及与统一建模语言（Unified Model Language , 以下简称UML）的良好集成、多种CASE工具的支持、不断的升级与维护，迅速得到业界广泛的认同，越来越多的组织以它作为软件开发模型框架。

伟杰观点：

对于实用性的问题我还是比较中立的，我不打算为RUP摇旗呐喊，也不打算痛陈RUP的不足，只是希望能够戴上不同颜色的思考帽，在各个不同角度审视我们的开发过程，审视我们的方法和体系，与所有读者交换看法，找出最适合的软件方法，最终能跟大家一起为中华软件之崛起贡献自己的一份力量。

其实是否实用关键看从什么角度出发去评价，自身组织的实际情况怎样，以及怎样使用这些方法。

        从对整个组织各个过程的覆盖看CMM、CMMI覆盖的要更全面一些，RUP重点聚焦在开发过程上。从对开发过程的指导上，RUP具有更好的操作性和实用性。
        首先，RUP是天生有工具平台支持的方法论，因为它是Rational的产品，Rational SDP天生对它有着良好的支持，有着很好的耦合，看看朋友豆豆他爹孙向辉的blog，《近距离接触RUP plug-in》http://blog.csdn.net/xiaosun/archive/2006/06/08/780737.aspx 至少在工具平台上RUP是更为实用的。
        再者，从侧重点来看RUP更是实际问题的总结和针对性的方法论框架，而CMM、CMMI则更为刻板，文档驱动和教条的味道更浓一些。

比如说：Trace Symptoms to Root Causes部分，见如下列表，表象、根本原因、最佳实践，都是我们经常碰到的问题，而最佳实践部分则更是业界多年的共识，从这点管中窥豹就可以感受到RUP从实践出发的努力。

 

Symptoms	Root Causes	Best Practices
Needs not met	Insufficient requirements	Develop Iteratively
Requirements chum	Ambiguous communications	Manage Requirement
Modules don't fit	Brittle architectures	Use Component Architectures
Hard to maintain	Overwheling complexity	Model Visually(UML)
Late discovery	Undetected inconsistencies	Continuously Verify Quality
Poor quality	Poor testing	Manage Change
Poor performance	Subjective assessment
colliding developers	Waterfall development
Build-and-release	uncontrolled change
	Insufficient automation

当然，跟其他的体系和方法论一样，RUP也摆脱不了文档化的东西，也需要体系工程师的投入，尤其对于开发人员来说还是较少有人愿意静下心读文档读体系的。而对于一些小型组织，敏捷开发在某些情况下则显现出自身的优势。

从开发过程来看RUP相对还是比较实用的，我这里仅仅从冰山一角开了个头，故事会继续，也欢迎大家畅所欲言。

另注：五月底，当Ivar Jacobson博士准备去参加在Orlando的软件大会前，有幸见到了他，并听他介绍了EUP（Essenital UP）——他的新想法。也许未来的体系工程师要失业，也许未来的体系工作真的就像玩纸牌一样省去文档的烦恼。

（原文，源自：乔丹 (个人网站) 标签：项目管理）