何為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）——他的新想法。也許未來的體系工程師要失業，也許未來的體系工作真的就像玩紙牌一樣省去文檔的煩惱。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
