1.什么是RUP：

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

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

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

2.?二維的軟件開發(fā)模型

?傳統(tǒng)的軟件開發(fā)模型瀑布式開發(fā)模型是一個單維的模型，開發(fā)工作劃分為多個連續(xù)的階段。在一個時間段內(nèi)，只能作某一個階段的工作比如，分析、設計或者實現(xiàn)。

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

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

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

3.靜態(tài)結(jié)構(gòu)：方法描述

?軟件開發(fā)過程描述了什么時候，什么人，做什么事，以及怎樣實現(xiàn)某一特定的目標。RUP采用以下四個基本模型元素組織和構(gòu)造系統(tǒng)開發(fā)過程。

角色?: the who

行為?: the how

產(chǎn)品?: the what

工作流?: the when

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

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

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

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

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

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

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

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

商業(yè)建模（Business Modeling）：理解待開發(fā)系統(tǒng)的組織結(jié)構(gòu)及其商業(yè)運作，確保所有參與人員對待開發(fā)系統(tǒng)有共同的認識。

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

分析與設計（Analysis and Design）：把需求分析的結(jié)果轉(zhuǎn)化為實現(xiàn)規(guī)格。

實現(xiàn)（Implementation）：定義代碼的組織結(jié)構(gòu)、實現(xiàn)代碼、單元測試、系統(tǒng)集成。

測試（Test）：校驗各自子系統(tǒng)的交互與集成。確保所有的需求被正確實現(xiàn)并在系統(tǒng)發(fā)布前發(fā)現(xiàn)錯誤。

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

配置管理（Configuration and Change Management）：跟蹤并維護系統(tǒng)所有產(chǎn)品s的完整性和一致性。

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

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

?

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

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

7、動態(tài)結(jié)構(gòu)：迭代式開發(fā)

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

起始階段（Inception）：定義最終產(chǎn)品視圖、商業(yè)模型并確定系統(tǒng)范圍。

演化階段（evaluation）：設計及確定系統(tǒng)的體系結(jié)構(gòu)，制定工作計劃及資源要求。

構(gòu)造階段（construction）：構(gòu)造產(chǎn)品并繼續(xù)演進需求、體系結(jié)構(gòu)、計劃直至產(chǎn)品提交。

8、RUP小型項目

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

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

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

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

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

SEI的能力成熟度模型（CMM）和CMMI從五個級別來評估并驗證某組織的成熟度。按照SEI的規(guī)定，很清楚地評估和驗證一個組織做什么，以及在某種程度上，他們?nèi)绾瓮瓿伞Ｈ欢?#xff0c;這并不是規(guī)定一個“可重復過程”（二級）必須利用過程、工具和組織角色來完成。

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

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

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

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

轉(zhuǎn)載于:https://www.cnblogs.com/chenliangcl/p/7384944.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。