在《從IT方法論來談Scrum》中我談到了6Ways方法框架，本篇仍用6Ways方法框架來概括的談談RUP方法。

　　軟件開發過程描述了軟件構造、部署和維護的一種方法。統一過程（Unified Process）是一種流行的構造面向對象系統的軟件開發過程。RUP（Rational Unified Process）是對UP的詳細精化，并且已經被廣泛采納。有些人可能一看到RUP提供這么多流程和工件，覺得不夠敏捷，我認為RUP本身其實是一個方法框架，本身也可以采納一些現在敏捷實踐。采用什么方法重要，但采用方法后的執行更重要，對RUP來說，如果我們做得好就是敏捷，做不好就可能瀑布了。

The way of thinking

　　軟件開發中成功的項目比例很少，原因很多，如：沒有正確的理解用戶需求、沒有能力處理需求的改變、模塊不能集成、軟件很難維護和擴展、很晚才發現重要的項目缺陷、不好的軟件質量、不能接收的軟件性能等。基于導致項目失敗的這些原因，RUP認為下面這些最佳實踐可以改善軟件的開發狀況：

在早期迭代中解決高風險和高價值的問題 不斷的讓用戶參與評估、反饋和需求 在早期迭代中建立內聚的核心架構 不斷地驗證質量：提早、經常和實際的測試 可視化軟件建模（使用UML） 仔細的管理需求 實行變更請求和配置管理

The way of working

　　迭代是UP最重要的思想。RUP重要的概念之一：周期（cycles），如下圖由多個周期構成一個軟件開發生命周期。

　　對于每個周期，下圖展現了更為詳細的不同階段（Phase）和流程：

四個階段

初始階段（Inception)：預見項目的范圍、構想和業務案例 （Lifecycle Objective）初始階段不是一個需求階段，而是類似與可行性階段，項目相關人員是否就項目的構想達成基本的一致，項目是否值得繼續進行認真的研究 時間不應超過一周，只需要確定這個項目是否值得認真研究，而不是真正去深入研究項目（這個工作留待細化階段進行）如果預選就決定項目必須進行，而且項目明顯是可行的，那么初始階段會很短，可能只包含一次需求研討會，并為第一次迭代執行計劃，然后就快速的進入細化階段 主要實踐活動－用例建模 對于迭代開發的一個關鍵理解在于：過程中的工件在初始階段只是部分完成，在之后的迭代中在逐步精化提煉。例如，用例模型可以列舉大多數所需的用例和參與者，但其中可能只有10％的用例會被詳細描述，這樣就足以建立起有關系統的范圍、目標和風險的高層的大致構想。 主要工件：是否意味著大量的文檔？工件是可選的，只需要從下面選擇對項目確實有價值的工件，放棄哪些不必要的工件，工件的關鍵不是文檔或圖表本身，而是其中蘊含的思想、分析和前期準備。構想和業務案例：描述高層的目標和約束、業務案例，并提供一個執行摘要 用例模型：描述功能需求和相關的非功能需求 補充規范：描述其他需求 術語表：關鍵的領域術語 風險列表和風險管理計劃：描述業務、技術、資源和進度的風險，以及如何減輕這些風險或該如何應對 原型和概念驗證：闡明構想，驗證技術問題。 迭代計劃：描述在第一次細化迭代中該作什么 階段計劃和

軟件開發

計劃：對細化階段的持續時間和工作量進行低精度的猜測。開發涉及的工具、人員、培訓和其他資源 開發案例：描述為本項目定制的統一過程的步驟和工件。在統一過程中，總需要為項目定制一些步驟或工件細化階段（Elaboration）：已精化的構想，核心架構的迭代實現，高風險的解決，大多數需求和范圍的識別，更為現實的評估。 （Lifecycle Architecture）

細化階段不是一個需求或設計階段，而是一個迭代實現核心架構并降低高風險的階段構造階段（Construction）：迭代實現遺留下來的風險較低和比較容易的元素，準備部署 （Initial Operational Capability） 移交階段（Transition）：beta測試，部署 （Product Release）

多個流程

業務建模：在開發單獨的應用時，業務建模包括領域對象建模。在從事大規模業務分析或業務過程再工程時，業務建模包括跨越整個企業的業務過程的動態建模。 需求：對應用的需求分析，如寫出用例和識別非功能性需求 分析和設計：設計的所有方面，包括總體架構、對象、數據庫、網絡連接等。分析強調的是對問題和需求的調查研究，而不是解決方案。設計強調的是滿足需求的概念上的解決方案，而不是其實現。分析和設計可以被概括為：作正確的事（分析）和正確的做事（設計）。 實現：編程和構建系統，而不是部署系統 測試 配置和變更管理 項目管理 環境：指建立工具并為項目定制過程，也就是說，設置工具和過程環境。

　　1－5為核心工作流程，6－8為支持工作流程

The way of controlling

如何計劃和管理迭代：需要多少迭代？每次迭代多長時間？每次迭代的目的是什么？如何跟蹤每次迭代情況？

The Phase Plan (Project Plan)：一個粗略的計劃，每個開發項目只有一份項目計劃。包括了一個周期（cycle）內所有的環節（有時也可以包含多個周期）。計劃包含主要里程碑的時間，要求的資源。如果能夠明確分幾個iteratio，則需要標識時每個小里程碑的時間和目的。

The Iteration Plan：迭代計劃，包含當前迭代的詳細計劃，包括時間、任務和資源分配，在當前迭代后半期還需要包含下一個迭代的計劃

風險管理 度量

The way of modeling

RUP在不同流程中會由不同模型支持，下圖為模型和流程對應圖：

對于每個模型，RUP描述who在when時how做what。RUP使用五個主要元素來表達：

角色: the who

活動: the how

工件：the what

工作流: the when

規程（Disciplines）: 組合前面四種元素

下圖為其中一個示例：

The way of supporting

Rational （現IBM）提供了對RUP的工具支持。

The way of communicating

　　RUP定義了一系列流程和工件，這些工作作為各角色間溝通的主要內容，用例和架構是RUP的兩個重要內容。

用例驅動開發：使用用例表達需求，對業務進行描述。用例作為整個開發流程的基礎。 架構為中心流程：架構使用多個、協調一致的視圖來表達系統，作為概念、構建、管理和演進系統的主要工件

其他

IBM Rational Unified Process

developerWorks 中國 RUP資源 RUP搜索

如何做一個成功的架構師——玩轉RUP

Enterprise Unified Process(EUP) 一個RUP的擴展

Agile Modeling and the Rational Unified Process (RUP) EUP 引入了許多企業級別的規程，包括操作和支持以及七個企業規程：企業業務建模、組合管理、企業架構、戰略重用、人員管理、企業管理、軟件流程改進。RUP 與 EUP 之間的一個基本區別在于后者處理完整的 IT 生命周期。RUP 僅處理該生命周期的軟件開發部分。

Making the Unified Process Work in Practice

The Agile Unified Process (AUP)

統一過程 UP/AUP/RUP 資源

RUP presentation

書籍

The Rational Unified Process: An Introduction, Third Edition

Applying UML and Patterns：An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition)

編寫有效用例

UP和XP

UP建議增量的編寫用例和非功能性需求文檔（XP不是） UP建議在迭代開始，主要編程之前繪制更多的可視化設計圖（例如耗時半天或一天），XP建議用一點點時間來做可視化設計（例如30分鐘）

總結

以上是生活随笔為你收集整理的从IT方法论来谈RUP的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。