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

　　軟件開發(fā)過程描述了軟件構(gòu)造、部署和維護(hù)的一種方法。統(tǒng)一過程（Unified Process）是一種流行的構(gòu)造面向?qū)ο笙到y(tǒng)的軟件開發(fā)過程。RUP（Rational Unified Process）是對UP的詳細(xì)精化，并且已經(jīng)被廣泛采納。有些人可能一看到RUP提供這么多流程和工件，覺得不夠敏捷，我認(rèn)為RUP本身其實(shí)是一個(gè)方法框架，本身也可以采納一些現(xiàn)在敏捷實(shí)踐。采用什么方法重要，但采用方法后的執(zhí)行更重要，對RUP來說，如果我們做得好就是敏捷，做不好就可能瀑布了。

The way of thinking

　　軟件開發(fā)中成功的項(xiàng)目比例很少，原因很多，如：沒有正確的理解用戶需求、沒有能力處理需求的改變、模塊不能集成、軟件很難維護(hù)和擴(kuò)展、很晚才發(fā)現(xiàn)重要的項(xiàng)目缺陷、不好的軟件質(zhì)量、不能接收的軟件性能等。基于導(dǎo)致項(xiàng)目失敗的這些原因，RUP認(rèn)為下面這些最佳實(shí)踐可以改善軟件的開發(fā)狀況：

1. 在早期迭代中解決高風(fēng)險(xiǎn)和高價(jià)值的問題
2. 不斷的讓用戶參與評估、反饋和需求
3. 在早期迭代中建立內(nèi)聚的核心架構(gòu)
4. 不斷地驗(yàn)證質(zhì)量：提早、經(jīng)常和實(shí)際的測試
5. 可視化軟件建模（使用UML）
6. 仔細(xì)的管理需求
7. 實(shí)行變更請求和配置管理

The way of working

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

　　對于每個(gè)周期，下圖展現(xiàn)了更為詳細(xì)的不同階段（Phase）和流程：

四個(gè)階段

1. 初始階段（Inception)：預(yù)見項(xiàng)目的范圍、構(gòu)想和業(yè)務(wù)案例 （Lifecycle Objective）
   1. 初始階段不是一個(gè)需求階段，而是類似與可行性階段，項(xiàng)目相關(guān)人員是否就項(xiàng)目的構(gòu)想達(dá)成基本的一致，項(xiàng)目是否值得繼續(xù)進(jìn)行認(rèn)真的研究
   2. 時(shí)間不應(yīng)超過一周，只需要確定這個(gè)項(xiàng)目是否值得認(rèn)真研究，而不是真正去深入研究項(xiàng)目（這個(gè)工作留待細(xì)化階段進(jìn)行）如果預(yù)選就決定項(xiàng)目必須進(jìn)行，而且項(xiàng)目明顯是可行的，那么初始階段會(huì)很短，可能只包含一次需求研討會(huì)，并為第一次迭代執(zhí)行計(jì)劃，然后就快速的進(jìn)入細(xì)化階段
   3. 主要實(shí)踐活動(dòng)－用例建模
   4. 對于迭代開發(fā)的一個(gè)關(guān)鍵理解在于：過程中的工件在初始階段只是部分完成，在之后的迭代中在逐步精化提煉。例如，用例模型可以列舉大多數(shù)所需的用例和參與者，但其中可能只有10％的用例會(huì)被詳細(xì)描述，這樣就足以建立起有關(guān)系統(tǒng)的范圍、目標(biāo)和風(fēng)險(xiǎn)的高層的大致構(gòu)想。
   5. 主要工件：是否意味著大量的文檔？工件是可選的，只需要從下面選擇對項(xiàng)目確實(shí)有價(jià)值的工件，放棄哪些不必要的工件，工件的關(guān)鍵不是文檔或圖表本身，而是其中蘊(yùn)含的思想、分析和前期準(zhǔn)備。
      1. 構(gòu)想和業(yè)務(wù)案例：描述高層的目標(biāo)和約束、業(yè)務(wù)案例，并提供一個(gè)執(zhí)行摘要
      2. 用例模型：描述功能需求和相關(guān)的非功能需求
      3. 補(bǔ)充規(guī)范：描述其他需求
      4. 術(shù)語表：關(guān)鍵的領(lǐng)域術(shù)語
      5. 風(fēng)險(xiǎn)列表和風(fēng)險(xiǎn)管理計(jì)劃：描述業(yè)務(wù)、技術(shù)、資源和進(jìn)度的風(fēng)險(xiǎn)，以及如何減輕這些風(fēng)險(xiǎn)或該如何應(yīng)對
      6. 原型和概念驗(yàn)證：闡明構(gòu)想，驗(yàn)證技術(shù)問題。
      7. 迭代計(jì)劃：描述在第一次細(xì)化迭代中該作什么
      8. 階段計(jì)劃和軟件開發(fā)計(jì)劃：對細(xì)化階段的持續(xù)時(shí)間和工作量進(jìn)行低精度的猜測。開發(fā)涉及的工具、人員、培訓(xùn)和其他資源
      9. 開發(fā)案例：描述為本項(xiàng)目定制的統(tǒng)一過程的步驟和工件。在統(tǒng)一過程中，總需要為項(xiàng)目定制一些步驟或工件
2. 細(xì)化階段（Elaboration）：已精化的構(gòu)想，核心架構(gòu)的迭代實(shí)現(xiàn)，高風(fēng)險(xiǎn)的解決，大多數(shù)需求和范圍的識(shí)別，更為現(xiàn)實(shí)的評估。 （Lifecycle Architecture）
   
   1. 細(xì)化階段不是一個(gè)需求或設(shè)計(jì)階段，而是一個(gè)迭代實(shí)現(xiàn)核心架構(gòu)并降低高風(fēng)險(xiǎn)的階段
3. 構(gòu)造階段（Construction）：迭代實(shí)現(xiàn)遺留下來的風(fēng)險(xiǎn)較低和比較容易的元素，準(zhǔn)備部署 （Initial Operational Capability）
4. 移交階段（Transition）：beta測試，部署 （Product Release）

多個(gè)流程

1. 業(yè)務(wù)建模：在開發(fā)單獨(dú)的應(yīng)用時(shí)，業(yè)務(wù)建模包括領(lǐng)域?qū)ο蠼！Ｔ趶氖麓笠?guī)模業(yè)務(wù)分析或業(yè)務(wù)過程再工程時(shí)，業(yè)務(wù)建模包括跨越整個(gè)企業(yè)的業(yè)務(wù)過程的動(dòng)態(tài)建模。
2. 需求：對應(yīng)用的需求分析，如寫出用例和識(shí)別非功能性需求
3. 分析和設(shè)計(jì)：設(shè)計(jì)的所有方面，包括總體架構(gòu)、對象、數(shù)據(jù)庫、網(wǎng)絡(luò)連接等。分析強(qiáng)調(diào)的是對問題和需求的調(diào)查研究，而不是解決方案。設(shè)計(jì)強(qiáng)調(diào)的是滿足需求的概念上的解決方案，而不是其實(shí)現(xiàn)。分析和設(shè)計(jì)可以被概括為：作正確的事（分析）和正確的做事（設(shè)計(jì)）。
4. 實(shí)現(xiàn)：編程和構(gòu)建系統(tǒng)，而不是部署系統(tǒng)
5. 測試
6. 配置和變更管理
7. 項(xiàng)目管理
8. 環(huán)境：指建立工具并為項(xiàng)目定制過程，也就是說，設(shè)置工具和過程環(huán)境。

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

The way of controlling

1. 如何計(jì)劃和管理迭代：需要多少迭代？每次迭代多長時(shí)間？每次迭代的目的是什么？如何跟蹤每次迭代情況？

   1. The Phase Plan (Project Plan)：一個(gè)粗略的計(jì)劃，每個(gè)開發(fā)項(xiàng)目只有一份項(xiàng)目計(jì)劃。包括了一個(gè)周期（cycle）內(nèi)所有的環(huán)節(jié)（有時(shí)也可以包含多個(gè)周期）。計(jì)劃包含主要里程碑的時(shí)間，要求的資源。如果能夠明確分幾個(gè)iteratio，則需要標(biāo)識(shí)時(shí)每個(gè)小里程碑的時(shí)間和目的。

   2. The Iteration Plan：迭代計(jì)劃，包含當(dāng)前迭代的詳細(xì)計(jì)劃，包括時(shí)間、任務(wù)和資源分配，在當(dāng)前迭代后半期還需要包含下一個(gè)迭代的計(jì)劃
2. 風(fēng)險(xiǎn)管理
3. 度量

The way of modeling

RUP在不同流程中會(huì)由不同模型支持，下圖為模型和流程對應(yīng)圖：

對于每個(gè)模型，RUP描述who在when時(shí)how做what。RUP使用五個(gè)主要元素來表達(dá)：

• 角色: the who

• 活動(dòng): the how

• 工件：the what

• 工作流: the when

• 規(guī)程（Disciplines）: 組合前面四種元素

下圖為其中一個(gè)示例：

The way of supporting

Rational （現(xiàn)IBM）提供了對RUP的工具支持。

The way of communicating

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

1. 用例驅(qū)動(dòng)開發(fā)：使用用例表達(dá)需求，對業(yè)務(wù)進(jìn)行描述。用例作為整個(gè)開發(fā)流程的基礎(chǔ)。
2. 架構(gòu)為中心流程：架構(gòu)使用多個(gè)、協(xié)調(diào)一致的視圖來表達(dá)系統(tǒng)，作為概念、構(gòu)建、管理和演進(jìn)系統(tǒng)的主要工件

其他

IBM Rational Unified Process

developerWorks 中國 RUP資源  RUP搜索

如何做一個(gè)成功的架構(gòu)師——玩轉(zhuǎn)RUP

Enterprise Unified Process(EUP)  一個(gè)RUP的擴(kuò)展

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

Making the Unified Process Work in Practice

The Agile Unified Process (AUP)

統(tǒng)一過程 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

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

it知識(shí)庫：從IT方法論來談RUP，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時(shí)間聯(lián)系我們修改或刪除，多謝。