|
|
在《從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的兩個重要內容。
- 用例驅動開發：使用用例表達需求，對業務進行描述。用例作為整個開發流程的基礎。
- 架構為中心流程：架構使用多個、協調一致的視圖來表達系統，作為概念、構建、管理和演進系統的主要工件
其他
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)
書籍
The Rational Unified Process: An Introduction, Third Edition
UP和XP
- UP建議增量的編寫用例和非功能性需求文檔（XP不是）
- UP建議在迭代開始，主要編程之前繪制更多的可視化設計圖（例如耗時半天或一天），XP建議用一點點時間來做可視化設計（例如30分鐘）
it知識庫：從IT方法論來談RUP，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
