summary
rup的基本組成元素：
通過工作流的方式體現軟體工程過程，以各種指導原則方式組織，並明確各個角色及其職責、活動、工件等
整個軟體工程過程的步驟劃分如下：
關鍵特徵：迭代（iterative）、以架構為中心（architecture-centric）、用例驅動（use-case driven）
橫軸表示時間維度，縱軸表示rup中的9個工作流。工作流在縱軸上的高度，表示某時刻該工作流的工作量比重
phases
在時間維度上，rup將專案分成4個階段（phases）：初始階段inception、細化階段elaboration、構造階段construction、交付階段transition。階段只是一種較粗的劃分方式，強調該時間段內的工作重心、主要目標。比如說交付階段，並不僅僅是將專案交付給使用者使用，同時也包括了需求、設計、實現、測試等活動，只是說這個階段從專案整體來看，他的重點在於給客戶交付，比如參考下面的增量交付模式
每個階段包含乙個或者多個迭代過程，每個迭代都是乙個完整的開發流程，至少包括需求、分析設計、實現、測試這幾個活動，可以看作乙個小的瀑布模型過程，每個迭代的產出都是穩定的、可執行的產品（產品子集）
每個工作流都定義了相關的產出，在專案的四個階段中，各工作流產出的完成情況可以用下圖大致描述
專案完成時，所有產出都是完整的
每個階段結束都是乙個主要milestone，需要進行評估檢驗是否實現了該階段的目標
對比較典型的中型專案，各階段的進度、工作量分布大致如下
初始階段 inception
對新專案，初始階段主要與利益相關者就專案目標進行交流，確定業務和需求風險等，對已有系統改進公升級的專案，也需要確定專案值得做並且可以做
工作流：
主要目標：
1. 確定專案範圍、邊界條件，包括運作場景、驗收標準，以及哪些可能會做哪些可能不會做
2. 確定關鍵用例、主要業務場景，用於開展主設計工作
3. 針對主要業務場景，陳述或者是演示至少一種備選架構方案
4. 評估專案的總體成本和進度計畫
5. 評估潛在的風險
6. 專案環境準備
細化階段 elaboration
確定系統架構，為後續構造階段的設計和實現工作提供乙個穩定的基礎
工作流：
主要目標：
1. 確定架構的各種風險
2. 構建基準架構
3. 使用原型降低風險
4. 基於成本、時間等方面評估驗證架構的可行性，確保架構、需求和進度計畫足夠穩定，以及風險被很好的控制，不影響專案成本和進度
5. 下階段環境準備
構建階段 construction
明確專案需求，基於架構進行開發，重點是成本、進度、質量的控制
交付階段 transition
包括發布前的測試、根據使用者反饋進行調整。使用者反饋應該集中於產品的優化、配置、安裝、使用者使用性等問題
還有安裝準備工作、使用者培訓、上線執行、實現客戶自行維護、按照驗收標準進行評估、利益相關者確定交付完成等
iteration
每個迭代確定乙個主要的milestone，需要release出可執行的產品。迭代劃分的粒度不會太細，一般小專案中乙個迭代也在一周以上。因為迭代的主要目的是降低類似瀑布模型方式下的風險，避免在最後時刻所有風險才顯現出來，因此乙個迭代結束，需要有驗證評估等管理手段，迭代週期劃分的太細反而會失去這種管理方式的初衷。但迭代週期也不能劃分的太長，否則仍然會減弱對風險的控制能力
迭代模式：incremental lifecycle（增量模式）
確定使用者要求，定義系統需求，然後通過多個構建階段實現產品，第乙個階段實現一部分功能，以後每個階段新增一部分功能
典型過程：
1. 乙個較短的初始期迭代，建立專案範圍和目標，建立業務用例
2. 乙個細化期迭代，確定需求，建立架構
3. 多個構造期迭代，實現架構和用例
4. 多個交付期迭代，整合產品，交付給使用者
適用場景：a). 對問題域很熟悉；b). 較好的理解專案風險；c). 專案團隊經驗豐富
迭代模式：evolutionary lifecycle（演化模式）
不同於增量模式的地方是使用者的要求無法確定，沒法在最開始將使用者需求完全定義出來，而是通過乙個個迭代過程來明確、確定使用者需求，構建專案、產品
典型過程：
1. 乙個較短的初始期迭代，建立專案範圍和目標，建立業務用例
2. 多個細化期迭代，每個階段使用者需求進一步細化、明確
3. 乙個構造期迭代，實現架構和用例
4. 多個交付期迭代，整合產品，交付給使用者
適用場景：a). 針對新的或不熟悉的問題域；b). 團隊經驗不足
迭代模式：incremental delivery lifecycle（增量交付模式）
可以說是增量模式的一種，但其迭代的產出需要給客戶部署實施起來。一般場景是市場壓力比較大，盡早發布關鍵功能可以給客戶帶來巨大的商業效益。對客戶而言關鍵在於盡早發布，這種模式要求一開始能建立乙個穩定的架構
典型過程：
1. 乙個較短的初始期迭代，建立專案範圍和目標，建立業務用例
2. 乙個細化期迭代，需要基本確定乙個穩定的架構
3. 乙個構造期迭代，實現架構和用例
4. 多個交付期迭代，整合產品，交付給使用者
適用場景：a). 對問題域很熟悉，需求和架構能盡早在專案初期確定，針對專案團隊和客戶而言沒有太多新的需要嘗試的東西；b). 團隊經驗豐富；c). 增量的功能發布能給客戶帶來很高的價值
迭代模式：grand design lifecycle（總設計模式）
即瀑布模型，他可以看作迭代模式的退化方式，只包含乙個迭代週期。實際操作中可能會包含多個交付迭代週期。與增量互動模式等相比，他的構造期時間比較長，例如下圖所示，其構造期相比於正常的迭代過程，所佔比例比較大，並且是單一乙個構造期
迭代模式：hybrid strategies（混合模式）
沒有幾個專案採用單一迭代模式，都是各種形式的混合
RUP和IPD流程的優缺點
rup的過程改進，倡導針對不同型別專案進行適當的裁剪，實際上這也是一種靈活適應的方式 隨需而變的思想。我對此是理解並贊同的，但是我對rup卻一直保持一種相對謹慎的態度。對於rup來說，首先，我認為它過於理想化和理論化，rup 是過程元件 方法以及技術的框架，你可以將其應用於任何特定的軟體專案，由使用...
軟考個人補漏 開發方法 RUP
rup將專案管理 業務建模 分析與設計等統一起來，貫穿整個開發過程。rup中的軟體過程在時間上被分解為4個順序的階段，分別是初始階段 細化階段 構建階段和移交階段。基於rup的軟體過程是乙個迭代和增量的過程。除非產品退役，否則通過重複同樣的4個階段，產品將演化為下一代產品，但每一次的側重點都將放在不...
論RUP分析設計（RUP學習感悟）
rup rational unified process 統一軟體開發過程 統一軟體過程 是乙個 物件導向 且基於網路的 程式開發方 根據 rational rational rose 和統一建模語言 的開發者 rup和類 似的產品 例如物件導向的 軟體過程 oosp 以及 open process...