1.什么是RUP：

Rational Unified Process（以下簡稱RUP）?是一套軟件工程方法，主要由?Ivar Jacobson的?The Objectory Approch?和?The Rational Approch發展而來。同時，它又是文檔化的軟件工程產品，所有RUP的實施細節及方法導引均以Web文檔的方式集成在一張光盤上，由Rational公司開發、維護并銷售，當前版本是5.0。RUP又是一套軟件工程方法的框架，各個組織可根據自身的實際情況，以及項目規模對RUP進行裁剪和修改，以制定出合乎需要的軟件工程過程。

RUP?吸收了多種開發模型的優點，具有很好的可操作性和實用性。從它一推出市場，憑借Booch、Ivar Jacobson、以及Rumbagh?在業界的領導地位以及與統一建模語言（Unified Model Language ,?以下簡稱UML）的良好集成、多種CASE工具的支持、不斷的升級與維護，迅速得到業界廣泛的認同，越來越多的組織以它作為軟件開發模型框架。

RUP是一種迭代的、以架構為中心 的、用例驅動的軟件開發方法；RUP是一種具有明確定義和結構的軟件工程過程，它明確規定了人員的職責、如何完成各項工作以及何時完成各項工作，以及軟件 開發生命周期的結構，定義了主要里程碑和決策的關系；RUP也是一個過程產品，提供了可定制的軟件工程的過程框架，支持過程定制、過程創作和多種類型的開 發過程，可通過裝配過程產品得到過程配置。RUP配置可以用于不同規模的開發團隊和規范程度不同的開發方法，RUP產品包含過程配置和過程視圖，以指導項 目經理、開發人員、測試人員等角色協作開發軟件

2.?二維的軟件開發模型

?傳統的軟件開發模型瀑布式開發模型是一個單維的模型，開發工作劃分為多個連續的階段。在一個時間段內，只能作某一個階段的工作比如，分析、設計或者實現。

在RUP中，軟件開發生生命周期根據時間和RUP的核心工作流劃分為二維空間。

時間維從組織管理的角度描述整個軟件開發生命周期，是RUP的動態組成部分。它可進一步描述為周期（Cycle）、階段（phase）、Iteration(迭代)。核心工作流從技術角度描述RUP的靜態組成部分，它可進一步描述為行為（activities）、工作流（workflow）、產品（artifact）、角色（worker）。

不同的工作流在不同的時間段內工作量的不同。值得注意的是，幾乎所有的工作流，在所有的時間段內均有工作量，只是工作程度不同而已。這與Waterfall process(瀑布式開發模型)有明顯的不同。

3.靜態結構：方法描述

?軟件開發過程描述了什么時候，什么人，做什么事，以及怎樣實現某一特定的目標。RUP采用以下四個基本模型元素組織和構造系統開發過程。

角色?: the who

行為?: the how

產品?: the what

工作流?: the when

角色描述某個人或一個小組的行為與職責。一個開發人員可以同時是幾個角色，一個角色也可以由多個開發人員共同承擔。RUP預先定義了很多角色，例如：Architect、Use-Case Designer、Course Developer、Implementer?…，并對每一個角色的工作和職責都作了詳盡的說明。

行為是一個有明確目的的獨立工作單元。產品是行為生成、創建或修改的一段信息。它是行為的輸入同時又是它的輸出結果。產品以多種形式存在，例如：模型（Model）、源代碼、可執行文件、文檔等。

模型是從某一個角度對系統的完全描述。RUP的很大一部分工作就是設計和維護一系列的模型，這其中有Use Case Model、Business Model、Analysis Model、Design Model等。所有的這些模型都以UML描述，因此它們是標準的并為多種CASE工具支持。RUP并不鼓勵寫在字面上的文擋，產品應盡可能地在CASE工具中創建和修改并為版本管理工具跟蹤和維護，它們在整個軟件開發周期中動態地增加和修改。當然也可以根據需要為模型生成報告（Reports），但它們是靜態的，是某一時刻模型的快照不需要維護和修改。

工作流描述了一個有意義的連續的行為序列，每個工作流產生一些有價值的產品，并顯示了角色之間的關系。RUP主要提供兩種組織工作流的方式：核心工作流（Core Workflow）和迭代工作流（Iteration Workflow）。

核心工作流從邏輯上把相關角色和行為劃分為組，以描述RUP的邏輯組成部件。它們相當于模板一樣，并不在開發過程中真正的執行。迭代工作流是RUP的一個具體的實現過程，它們對核心工作流進行裁剪，是核心工作流的具體實現。每類工作流都會同一個或多個模型打交道。

4、RUP的核心包含幾個基本原理，它們支持應用迭代方法進行軟件開發：
盡早并且不斷的化解重大風險?
確保滿足客戶的需求?
把注意力集中放到可執行的軟件上?
盡早在項目中適應變化?
在早期確定一個可執行架構?
使用構件構造軟件系統?
建立高效團結的開發團隊?
始終重視質量?
5、從管理角度觀察RUP，即業務和經濟方面，對應項目的進展，軟件生命周期包括四個階段：
起始階段－構建最終產品的設想和業務案例，確定項目范圍?
細化階段－計劃必要的活動和資源，詳細確定功能并設計架構?
構建階段－構建產品，直到一個可交付用戶的產品完成?
移交階段－產品交付用戶，包括制造、交付、培訓、支持、維護等

6、UP有九個核心的工作流

以下簡單描述這些工作流的目的：

商業建模（Business Modeling）：理解待開發系統的組織結構及其商業運作，確保所有參與人員對待開發系統有共同的認識。

需求分析（Requirements）：定義系統功能及用戶界面，使客戶知道系統的功能，開發人員知道系統的需求，為項目預算及計劃提供基礎。

分析與設計（Analysis and Design）：把需求分析的結果轉化為實現規格。

實現（Implementation）：定義代碼的組織結構、實現代碼、單元測試、系統集成。

測試（Test）：校驗各自子系統的交互與集成。確保所有的需求被正確實現并在系統發布前發現錯誤。

發布（Deployment）：打包、分發、安裝軟件，升級舊系統；培訓用戶及銷售人員，并提供技術支持。制定并實施beta測試。

配置管理（Configuration and Change Management）：跟蹤并維護系統所有產品s的完整性和一致性。

項目管理（Project Management）：為計劃、執行和監控軟件開發項目提供可行性的指導；為風險管理提供框架。

環境（Environment）：為組織提供過程管理和工具的支持。

?

由于版面所限，無法詳細解釋每一個工作流。前六個核心工作流的名字，很可能使人們同Waterfall Process的順序工作階段相混淆。但我們知道核心工作流并不是具體的實現，而核心工作流中的某些行為有可能在軟件開發周期中，一遍又一遍地在迭代工作流中得以細化。

從技術角度看，軟件開發可視為一連串的迭代過程，通過迭代開發軟件得以增量演進，每個迭代都以一個可執行的產品發布而結束，每次發布都伴隨支持性工件：版 本描述、用戶文檔等。一次迭代可包括以下活動：計劃、分析、設計、實現、測試，據其在開發周期的位置不同，所占比重也不同。

7、動態結構：迭代式開發

?在時間維上，為了能夠方便地管理軟件開發過程，監控軟件開發狀態，RUP把軟件開發周期劃分為Cycles,每個Cycle生成一個產品的新的版本。每個Cycle都依次由四個連續的階段(pahse)組成，每個階段都應完成確定的任務。

起始階段（Inception）：定義最終產品視圖、商業模型并確定系統范圍。

演化階段（evaluation）：設計及確定系統的體系結構，制定工作計劃及資源要求。

構造階段（construction）：構造產品并繼續演進需求、體系結構、計劃直至產品提交。

8、RUP小型項目

敏捷方法考慮到迅速和緊密的增加或者階段；減少開銷；并且確保開發人員與客戶之間的緊密聯系。

? ? ? 敏捷方法以及類似的方法（SCRUM，Paired Programming）在軟件構建中是革新的、有用的。然而，在RUP中也可以使用敏捷方法。那些輕量級的方法可以很好地在新系統的構建階段、解決方案，或者程序中得到運用；但是仍然需要管理其它三個階段的上游和下游活動，比如決定需要做什么（需求）以及操作環境將受到什么影響（發布管理）。RUP并不關注先啟階段、細化階段、構建階段和產品化階段所有業務原則的使用，事實上，它是為這些活動提供了一個最佳框架。

RUP以及類似的指導，比如PMBOK, 軟件工程協會(SEI)的集成的能力成熟度模型 (CMMI)，或 UK 的 IT Infrastructure Library (ITIL)標準給小型項目強加了一些不必要的過程。他們其實僅適用于一千萬以上的大型項目。

方法、知識體系，或者成熟模型不會強加過程。他們只為估算需要做什么，以及如何做得更好而提供一定的基礎。“如何做”這部分是由實施組織來決定的。

PMBOK并沒有規定2000版本中的39個過程或者2004版本中的44個過程在項目中都必須得到使用。它是一個知識體系，為項目管理者可能遇到的各種情況提供了一個起點。例如，它有助于定義組織的變更控制過程應該包括哪些內容。現在，項目管理專業人員（PMP?）在項目管理協會（PMI）監督之下，當然必須遵循PMBOK。PMI提供PMP資格認證，這樣，聘用專業人員的組織機構就能夠放心該專業人員懂得PMBOK。但是這并不意味著專業人員必須在每個項目中都使用到PMBOK的每一項知識。

SEI的能力成熟度模型（CMM）和CMMI從五個級別來評估并驗證某組織的成熟度。按照SEI的規定，很清楚地評估和驗證一個組織做什么，以及在某種程度上，他們如何完成。然而，這并不是規定一個“可重復過程”（二級）必須利用過程、工具和組織角色來完成。

相似地，“RUP的精髓”-- 以及已開發的許多實施RUP的工具 -- 培養逐漸細化的理念，即增量開發的本質。RUP的觀點是組織應當設計并構建部分而不是全部解決方案，需求是已知的。現實中，驗證某特色或者系統是“受人歡迎的應用程序”（比如，想法），還是“失敗”（比如，Coca-Cola's New Coke，自1984）的一個最有效辦法就是將產品交付給用戶。

應用RUP，探尋SEI CMM/CMMI評估，或者使用PMI PMBOK時，最佳實踐是成體系地使用這些向導。例如，你應該首先懂得業務需要（a.k.a 需求），從本質的用例開始，基于那些用例和UML的強大功能進行建模。在2004年《The Rational Unified Process Made Easy》一書中，Per Kroll和Philippe Krutchen很好地描述了這個方法：

．．．人們采用RUP時最常出現的錯誤是使用太多工件或者做太多活動。過量使用RUP將會降低你的開發效率；RUP過程框架類似于自助餐，如果你還想保持健康和快樂，那么就不能吃光所有的飯菜。

轉載請注明原文地址：http://www.cnblogs.com/chenliangcl/p/7363139.html?

轉載于:https://www.cnblogs.com/chenliangcl/p/7384944.html

總結

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

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