RUP 方法简介
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)绾瓮瓿伞H欢?#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很好地描述了這個方法:
轉(zhuǎn)載請注明原文地址:http://www.cnblogs.com/chenliangcl/p/7363139.html?
轉(zhuǎn)載于:https://www.cnblogs.com/chenliangcl/p/7384944.html
總結(jié)
- 上一篇: Centos7下使用yum安装lnmp
- 下一篇: linux下安装 配置 redis数据库