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的錯誤解釋的基礎上的。
寫了這么多，我最希望大家注意的是——現在有許多對于UP不正確的說法在流傳。最主要的就是使用一些瀑布的思想去解釋UP。并且我們必須認識是使用UML不等于你就是在使用up。如果你不能把你的方法更加簡單，你也就做不到更加控制，也就是做不到UP的最初動機。在你實施UP的時候，必須從所謂的傳統軟件工程的種種思維方式中解放出來。
UP其實是一種內核很小的方法論，實際上最簡單的方式下你只需要選擇兩種工件就可以實施up，比如你選擇遠景視圖和風險列表。
UP的價值觀同敏捷的價值觀是不同的，強調的是以項目為導向，而不是以人為導向，同時也同以過程為導向的CMM體系有所不同。其核心價值觀在于：
1、使用UP指南和最佳實踐是非常重要的，其他一些手段是可以從它們中推導出來的、
2、強調風險和價值的驅動。
3、為項目定義一個清晰的遠景是非常重要的，這個遠景總結了項目相關人員的需求。
4、以最佳實踐為核心進行裁減UP，以此得到一個最小的方法過程集。
5、一個經過良好定義的過程是有用的。這個過程為項目中的人們的活動提供了指南性的幫助。
實際上歷來就存在兩種不同的UP——笨拙的和敏捷的。其分歧往往就是UP價值觀最后的一條。
UP的建造者是一群有經驗的工程人員，他們本身并不想建立一種笨拙的方法，他們更加贊同敏捷的UP。
作為那些新手，當然遵守UP的詳細軌道是有益的。這會加強他們對于開發過程的學習了理解，并且有利于建立一個檢查列表。高一級的人員則應該更加考慮如果建立有質量的工件，而不是優先考慮如何按照規定去工作。更高級的人員考慮問題應該從復用的角度去考慮問題，也就是優先的考慮建造可復用的工件。
而復用和可預見往往被一些人認為是必然聯系在一起的，這一點同敏捷的適應性而非預見性又矛盾。實際上復用由兩種方式，一種是提純(也就是發現設計模式那樣的工作)，一種是提前設計(也就是使用設計模式那樣的工作)。這兩種態度我想應該以提純為主，設計為輔。
UP強調建立一個通用的詞匯表，這會有利于項目和組織間的交流。當然這一點是被有些人所反對的，因為他們希望項目能綁定在某些特殊的組織中。
實際上過程究竟是一個定義的規定性過程，還是一個經驗性的過程，是一個不同協調的和平衡的問題。它會由使用者的能力的增加愈來愈偏向經驗性。但是你并不能就因此認為一群沒有經驗的開發者就必須遵守一個嚴格的規定性過程，實際上最初的過程一樣需要他們按照經驗去裁減以適合他們的能力。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
