何为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是更为实用的。
再者，从侧重点来看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）——他的新想法。也许未来的体系工程师要失业，也许未来的体系工作真的就像玩纸牌一样省去文档的烦恼。
文章来源于领测软件测试网 https://www.ltesting.net/
