胖子說UP（轉自Javaeye）

要說RUP，就要先說UP。
UP可以用下面的話來概括——用例驅動、以構架爲中心、迭代和增量的開發過程。
acobson在《Object-Oriented Software Engineering : A Use Case Drivern Approach》中給的定義是這樣的：當希望改變系統的行爲時，重建相對應的參與者和用例模型。整個系統的基礎構架將有用戶所希望使用系統行爲進行的操作來控制。由於控制了所有模型，因此可以根據新需求修改系統。我們向用戶詢問他們希望改動的地方，也就是用例，並直接找出這些改變在其他模型的什麼部分實現。
用例被用來驅動你開發過程中的各種實踐，你的需求、設計、測試、部署都是需要在用例中去尋找理由的。
以構架爲中心，就是要你使用構架的方法，採取組件化的方式進行建造你的系統。
在RUP中的構架，是一種設計的基線。建造這樣的基線採取的策略是，從用例出發，尋找那些穩定的，業務意義重大的，技術風險可以在早期解決的部分，構建一個可以運行的程序。以後的開發，儘量使用以存在的組件。這一點同敏捷的做法是不相同的，其優勢和弱勢都存在。
而增量和迭代，就是要求在構建構架的基礎上，添加新的部分，按照週期性提交最終結果的方式進行開發。UP的建議迭代週期是2周到6周，同時各個階段的週期可以不同。
在UP中過程被劃分爲4個階段，起始階段、細化階段、構造階段、移交階段。
起始階段在理想的狀況下是短暫的，可能只需要幾天，以至於都不存在迭代。這個階段的工作主要是需求工程的短小片斷，去選擇10％的需求（最要業務價值和技術價值，風險最高最應該早期解決）的TOP10高級需求list，項目的最初視圖，商業用例的草圖。
如果這個時期過長，那麼往往是需求規格說明和計劃過度的表現。
細化階段，在我看來可能是UP中最關鍵的。核心的、具有構架意義的元素，將在一系列短小的timebox下的迭代內被編程和測試。並且這個階段最後，可能會完成一個部分可靠的計劃和評估。這個階段的工作包括了需求和設計建模，同時也有編程和測試。在這個階段需求通過迭代被不斷的精華，並且最終達到大部分的穩定。同時開發一個系統的核心——構架，並使之達到穩定，也是這個階段的目標。這個階段是創造和發現的階段，理想狀況下需要的是一個小型的、精誠合作的高素質團隊進行。由於這個階段不可知因素和新的需求將被不斷提出，迭代的週期往往比較長（例如3周）。同時這個階段在整個開發過程中往往是和構造階段的比例是3：10。
構造階段是構建系統的主要階段。這時需要在細化階段已經建立起來的牢固基礎上，去建造其他未完成部分。在這個階段需求還可以變化，但是大的風險和意外應該已經在細化階段被發現了。這個階段的主要工作是編程，還包括測試（α），文檔的建立（比如用戶使用文檔）、性能優化。當然還會存在一些少量的需求和設計工作。這個階段一般是由更多，更大的組進行並行的開發。這個階段的迭代週期由於已經定義了大部分的風險和意外，迭代週期往往會比較短（一般在1－2周）。
移交階段是系統的最終部署階段。首先你需要發佈一些release版本進行審覈和反饋。往往在這個階段的前期往往就已經凍結了代碼，而只進行除錯。可能還需要幾個迭代週期，最後就是部署上線的工作。這個階段往往還包括渠道的發行，培訓，新舊系統的並行運轉，數據的轉換。往往會由專門的團隊負責這個階段的主要工作。
這四個階段之間有里程碑需要被標示出來。起始階段的里程碑是定義好軟件的框架目標，也就是系統的視圖和商業用例，最重要的是定義好高級需求列表。一般這個週期的里程碑被稱爲LCO（life cycle objectives）。細化階段的完成以構建出一個構架爲里程碑，一般稱爲LCA（life cycle architecture）。構建階段的歷程碑就是完成這個系統的全部。移交階段就是完成這個系統的部署以完成合同。
UP定義了一組大概50個的工件集。這些工件都是按照其特有的工作流，在特有的角色的操作下建立的。這些工件是按照項目的具體要求進行專門的選擇的，這也就是裁減。裁減的原則是less is better，這樣纔可以做到資源更加集中，成本更加集中和低廉。
對於UP的實施建議是（《the RUP made easy》）：
1、儘早而持續的排除風險，否則將給你帶來麻煩。
2、交付給你客戶有價值的東西——儘早並且經常性的交付。
3、在早期的迭代中重點在開發可執行的軟件，而不是規格說明或者其他文檔。
4、儘早適應項目變化。通過早期開發，多種需求工序，變更管理工具等等手段，激發變化和管理變化。
5、儘早建立可執行的構架基線。
6、最好使用面向組件開發，儘量重用現有組件。
7、以團隊協作方式進行工作。例如使用交叉功能的團隊。
8、質量在某種意義上是生命，不應該在出現質量問題時再追悔莫及。
UP有六個最佳實踐：
1、timebox的迭代。
2、早期建立高風險、高價值的內聚構架。儘量使用現有組件。
3、持續性的驗證質量。
4、可視化建模。
5、管理需求。
6、管理變化。
最多的錯誤理解：
1、沒有使用迭代開發。
2、將起始階段理解爲需求階段，也就是建立需求分析和詳細說明。
將細化階段理解爲設計階段，建立更詳細的需求分析，建模和設計。
將構造階段理解爲編碼。
將移交階段理解爲測試。
也就是拿UP的四個階段類比爲瀑布的四個階段。
典型的做法是，在編碼之前試圖做絕大部分需求分析和設計，將項目的主要測試和評估放到項目的最後。
其他的錯誤方式還有：
迭代週期過長；迭代週期不在timebox內；迭代沒有以被集成和被測試的基線結束；每次迭代都以產品發佈作爲結束（提交而非發佈）；細化階段的目標是提交一個用之即拋棄的原型爲目標（應該是起始階段使用原型）；開發案例太複雜，使用太多的工件；使用預見性的計劃；開發小組製作許多模型和UML圖，並且必須使用一個CASE工具；需要大量工具；在細化階段完成之前舊完成構架文檔；不使用官方的工件名稱和階段名稱（up的目標在於建立一個跨項目的通用體系）。
RUP是UP的一個精華的商業過程，原則上在你沒有授權的情況下不能叫做RUP，一般情況下你還需要使用Rational的產品支持你的過程（當然這是可選的）。UP是一個通用性的方法框架，實際上它和許多其他方法可以結合使用。當然極端狀態下你也可以看到和瀑布方法結合使用，雖然這樣做是違背up的基本理念的。同時up的過程需要按照不同的項目進行鍼對性的裁減，而由於up自身的工件和工作流的衆多，裁減並不是一件容易的事情，特別是在不遵守less is better的原則的時候。up構架的定義同軟件工程上的定義是有區別的。UP的思想更加類似敏捷而不是CMM。同時我們必須知道UP的顧問不等於迭代開發的顧問，或者說UP的實施者可能不是在實施迭代增量開發，這是目前UP實施失敗的最多原因。同時我們必須看到很多關於UP和RUP的介紹文章和書籍是建立在對於UP的錯誤解釋的基礎上的。