軟件項目開發(fā)流程RUP

軟件項目開發(fā)流程RUP軟件項目開發(fā)流程RUP軟件項目開發(fā)流程RUP資料僅供參考文件編號：2022年4月軟件項目開發(fā)流程RUP版本號：A修改號：1頁次：1.0審核：批準:發(fā)布日期：軟件項目開發(fā)流程RUPRUP（RationalUnifiedProcess，統(tǒng)一軟件開發(fā)過程，統(tǒng)一軟件過程)是一個面向對象且基于網絡的程序開發(fā)方法論。根據Rational(RationalRose和統(tǒng)一建模語言的開發(fā)者)的說法，好像一個在線的指導者，它可以為所有方面和層次的程序開發(fā)提供指導方針，模版以及事例支持。RUP和類似的產品--例如面向對象的軟件過程（OOSP），以及OPENProcess都是理解性的軟件工程工具--把開發(fā)中面向過程的方面（例如定義的階段，技術和實踐）和其他開發(fā)的組件（例如文檔，模型，手冊以及代碼等等）整合在一個統(tǒng)一的框架內。

一、六大經驗

迭代式開發(fā)。在軟件開發(fā)的早期階段就想完全、準確的捕獲用戶的需求幾乎是不可能的。實際上，我們經常遇到的問題是需求在整個軟件開發(fā)工程中經常會改變。迭代式開發(fā)允許在每次迭代過程中需求可能有變化，通過不斷細化來加深對問題的理解。迭代式開發(fā)不僅可以降低項目的風險，而且每個迭代過程以可以執(zhí)行版本結束，可以鼓舞開發(fā)人員。

管理需求。確定系統(tǒng)的需求是一個連續(xù)的過程，開發(fā)人員在開發(fā)系統(tǒng)之前不可能完全詳細的說明一個系統(tǒng)的真正需求。RUP描述了如何提取、組織系統(tǒng)的功能和約束條件并將其文檔化，用例和腳本的使用以被證明是捕獲功能性需求的有效方法。

基于組件的體系結構。組件使重用成為可能，系統(tǒng)可以由組件組成?；讵毩⒌摹⒖商鎿Q的、模塊化組件的體系結構有助于管理復雜性，提高重用率。RUP描述了如何設計一個有彈性的、能適應變化的、易于理解的、有助于重用的軟件體系結構。

可視化建模。RUP往往和UML聯系在一起，對軟件系統(tǒng)建立可視化模型幫助人們提供管理軟件復雜性的能力。RUP告訴我們如何可視化的對軟件系統(tǒng)建模，獲取有關體系結構于組件的結構和行為信息。

項目管理論壇

驗證軟件質量。在RUP中軟件質量評估不再是事后進行或單獨小組進行的分離活動，而是內建于過程中的所有活動，這樣可以及早發(fā)現軟件中的缺陷。

控制軟件變更。迭代式開發(fā)中如果沒有嚴格的控制和協調，整個軟件開發(fā)過程很快就陷入混亂之中，RUP描述了如何控制、跟蹤、監(jiān)控、修改以確保成功的迭代開發(fā)。RUP通過軟件開發(fā)過程中的制品，隔離來自其他工作空間的變更，以此為每個開發(fā)人員建立安全的工作空間。二、統(tǒng)一軟件開發(fā)過程RUP的二維開發(fā)模型

RUP軟件開發(fā)生命周期是一個二維的軟件開發(fā)模型。橫軸通過時間組織，是過程展開的生命周期特征，體現開發(fā)過程的動態(tài)結構，用來描述它的術語主要包括周期(Cycle)、階段(Phase)、迭代(Iteration)和里程碑(Milestone)；縱軸以內容來組織為自然的邏輯活動，體現開發(fā)過程的靜態(tài)結構，用來描述它的術語主要包括活動(Activity)、產物(Artifact)、工作者(Worker)和工作流(Workflow)。轉自項目管理者聯盟

三、統(tǒng)一軟件開發(fā)過程RUP核心概念

RUP中定義了一些核心概念，

角色：描述某個人或者一個小組的行為與職責。RUP預先定義了很多角色。

活動：是一個有明確目的的獨立工作單元。

工件：是活動生成、創(chuàng)建或修改的一段信息。

四、統(tǒng)一軟件開發(fā)過程RUP裁剪

RUP是一個通用的過程模板，包含了很多開發(fā)指南、制品、開發(fā)過程所涉及到的角色說明，由于它非常龐大所以對具體的開發(fā)機構和項目，用RUP時還要做裁剪，也就是要對RUP進行配置。RUP就像一個元過程，通過對RUP進行裁剪可以得到很多不同的開發(fā)過程，這些軟件開發(fā)過程可以看作RUP的具體實例。RUP裁剪可以分為以下幾步：

1)確定本項目需要哪些工作流。RUP的9個核心工作流并不總是需要的，可以取舍。2)確定每個工作流需要哪些制品。

3)確定4個階段之間如何演進。確定階段間演進要以風險控制為原則，決定每個階段要那些工作流，每個工作流執(zhí)行到什么程度，制品有那些，每個制品完成到什么程度。

4)確定每個階段內的迭代計劃。規(guī)劃RUP的4個階段中每次迭代開發(fā)的內容。5)規(guī)劃工作流內部結構。工作流涉及角色、活動及制品，他的復雜程度與項目規(guī)模即角色多少有關。最后規(guī)劃工作流的內部結構，通常用活動圖的形式給出。

五、開發(fā)過程中的各個階段和里程碑RUP中的軟件生命周期在時間上被分解為四個順序的階段，分別是：初始階段(Inception)、細化階段(Elaboration)、構造階段(Construction)和交付階段(Transition)。每個階段結束于一個主要的里程碑(MajorMilestones)；每個階段本質上是兩個里程碑之間的時間跨度。在每個階段的結尾執(zhí)行一次評估以確定這個階段的目標是否已經滿足。如果評估結果令人滿意的話，可以允許項目進入下一個階段。

1．初始階段

初始階段的目標是為系統(tǒng)建立商業(yè)案例并確定項目的邊界。為了達到該目的必須識別所有與系統(tǒng)交互的外部實體，在較高層次上定義交互的特性。本階段具有非常重要的意義，在這個階段中所關注的是整個項目進行中的業(yè)務和需求方面的主要風險。對于建立在原有系統(tǒng)基礎上的開發(fā)項目來講，初始階段可能很短。初始階段結束時是第一個重要的里程碑：生命周期目標(LifecycleObjective)里程碑。生命周期目標里程碑評價項目基本的生存能力。

項目經理博客

2．細化階段

細化階段的目標是分析問題領域，建立健全的體系結構基礎，編制項目計劃，淘汰項目中最高風險的元素。為了達到該目的，必須在理解整個系統(tǒng)的基礎上，對體系結構作出決策，包括其范圍、主要功能和諸如性能等非功能需求。同時為項目建立支持環(huán)境，包括創(chuàng)建開發(fā)案例，創(chuàng)建模板、準則并準備工具。細化階段結束時第二個重要的里程碑：生命周期結構(LifecycleArchitecture)里程碑。生命周期結構里程碑為系統(tǒng)的結構建立了管理基準并使項目小組能夠在構建階段中進行衡量。此刻，要檢驗詳細的系統(tǒng)目標和范圍、結構的選擇以及主要風險的解決方案。

3．構造階段項目管理者聯盟文章

在構建階段，所有剩余的構件和應用程序功能被開發(fā)并集成為產品，所有的功能被詳細測試。從某種意義上說，構建階段是一個制造過程，其重點放在管理資源及控制運作以優(yōu)化成本、進度和質量。構建階段結束時是第三個重要的里程碑：初始功能(InitialOperational)里程碑。初始功能里程碑決定了產品是否可以在測試環(huán)境中進行部署。此刻，要確定軟件、環(huán)境、用戶是否可以開始系統(tǒng)的運作。此時的產品版本也常被稱為“beta”版。

4．交付階段

交付階段的重點是確保軟件對最終用戶是可用的。交付階段可以跨越幾次迭代，包括為發(fā)布做準備的產品測試，基于用戶反饋的少量的調整。在生命周期的這一點上，用戶反饋應主要集中在產品調整，設置、安裝和可用性問題，所有主要的結構問題應該已經在項目生命周期的早期階段解決了。在交付階段的終點是第四個里程碑：產品發(fā)布(ProductRelease)里程碑。此時，要確定目標是否實現，是否應該開始另一個開發(fā)周期。在一些情況下這個里程碑可能與下一個周期的初始階段的結束重合。六、統(tǒng)一軟件開發(fā)過程RUP的核心工作流(CoreWorkflows)

RUP中有9個核心工作流，分為6個核心過程工作流(CoreProcessWorkflows)和3個核心支持工作流(CoreSupportingWorkflows)。盡管6個核心過程工作流可能使人想起傳統(tǒng)瀑布模型中的幾個階段，但應注意迭代過程中的階段是完全不同的，這些工作流在整個生命周期中一次又一次被訪問。9個核心工作流在項目中輪流被使用，在每一次迭代中以不同的重點和強度重復。項目管理培訓

1．商業(yè)建模(BusinessModeling)商業(yè)建模工作流描述了如何為新的目標組織開發(fā)一個構想，并基于這個構想在商業(yè)用例模型和商業(yè)對象模型中定義組織的過程，角色和責任。

項目管理者聯盟文章

2．需求(Requirements)項目經理博客

需求工作流的目標是描述系統(tǒng)應該做什么，并使開發(fā)人員和用戶就這一描述達成共識。為了達到該目標，要對需要的功能和約束進行提取、組織、文檔化；最重要的是理解系統(tǒng)所解決問題的定義和范圍。轉自項目管理者聯盟

3．分析和設計(Analysis&Design)

分析和設計工作流將需求轉化成未來系統(tǒng)的設計，為系統(tǒng)開發(fā)一個健壯的結構并調整設計使其與實現環(huán)境相匹配，優(yōu)化其性能。分析設計的結果是一個設計模型和一個可選的分析模型。設計模型是源代碼的抽象，由設計類和一些描述組成。設計類被組織成具有良好接口的設計包(Package)和設計子系統(tǒng)(Subsystem)，而描述則體現了類的對象如何協同工作實現用例的功能。設計活動以體系結構設計為中心，體系結構由若干結構視圖來表達，結構視圖是整個設計的抽象和簡化，該視圖中省略了一些細節(jié)，使重要的特點體現得更加清晰。體系結構不僅僅是良好設計模型的承載媒介，而且在系統(tǒng)的開發(fā)中能提高被創(chuàng)建模型的質量。

項目管理培訓

4．實現(Implementation)

實現工作流的目的包括以層次化的子系統(tǒng)形式定義代碼的組織結構；以組件的形式(源文件、二進制文件、可執(zhí)行文件)實現類和對象；將開發(fā)出的組件作為單元進行測試以及集成由單個開發(fā)者（或小組）所產生的結果，使其成為可執(zhí)行的系統(tǒng)。

5．測試(Test)

項目經理圈子

測試工作流要驗證對象間的交互作用，驗證軟件中所有組件的正確集成，檢驗所有的需求已被正確的實現,識別并確認缺陷在軟件部署之前被提出并處理。RUP提出了迭代的方法，意味著在整個項目中進行測試，從而盡可能早地發(fā)現缺陷，從根本上降低了修改缺陷的成本。測試類似于三維模型，分別從可靠性、功能性和系統(tǒng)性能來進行。6．部署(Deployment)

項目管理論壇

部署工作流的目的是成功的生成版本并將軟件分發(fā)給最終用戶。部署工作流描述了那些與確保軟件產品對最終用戶具有可用性相關的活動，包括：軟件打包、生成軟件本身以外的產品、安裝軟件、為用戶提供幫助。在有些情況下，還可能包括計劃和進行beta測試版、移植現有的軟件和數據以及正式驗收。

7．配置和變更管理(Configuration&ChangeManagement)

配置和變更管理工作流描繪了如何在多個成員組成的項目中控制大量的產物。配置和變更管理工作流提供了準則來管理演化系統(tǒng)中的多個變體，跟蹤軟件創(chuàng)建過程中的版本。工作流描述了如何管理并行開發(fā)、分布式開發(fā)、如何自動化創(chuàng)建工程。同時也闡述了對產品修改原因、時間、人員保持審計記錄。項目經理圈子

項目經理博客

8．項目管理(ProjectManagement)

軟件項目管理平衡各種可能產生沖突的目標，管理風險，克服各種約束并成功交付使用戶滿意的產品。其目標包括：為項目的管理提供框架，為計劃、人員配備、執(zhí)行和監(jiān)控項目提供實用的準則，為管理風險提供框架等。

9．環(huán)境(Environment)環(huán)境工作流的目的是向軟件開發(fā)組織提供軟件開發(fā)環(huán)境，包括過程和工具。環(huán)境工作流集中于配置項目過程中所需要的活動，同樣也支持開發(fā)項目規(guī)范的活動，提供了逐步的指導手冊并介紹了如何在組織中實現過程。

七、RUP的迭代開發(fā)模式

RUP中的每個階段可以進一步分解為迭代。一個迭代是一個完整的開發(fā)循環(huán)，產生一個可執(zhí)行的產品版本，是最終產品的一個子集，它增量式地發(fā)展，從一個迭代過程到另一個迭代過程到成為最終的系統(tǒng)。傳統(tǒng)上的項目組織是順序通過每個工作流，每個工作流只有一次，也就是我們熟悉的瀑布生命周期。這樣做的結果是到實現末期產品完成并開始測試，在分析、設計和實現階段所遺留的隱藏問題會大量出現，項目可能要停止并開始一個漫長的錯誤修正周期。項目管理者聯盟文章

一種更靈活，風險更小的方法是多次通過不同的開發(fā)工作流，這樣可以更好的理解需求，構造一個健壯的體系結構，并最終交付一系列逐步完成的版本。這叫做一個迭代生命周期。在工作流中的每一次順序的通過稱為一次迭代。軟件生命周期是迭代的連續(xù)，通過它，軟件是增量的開發(fā)。一次迭代包括了生成一個可執(zhí)行版本的開發(fā)活動，還有使用這個版本所必需的其他輔助成分，如版本描述、用戶文檔等。因此一個開發(fā)迭代在某種意義上是在所有工作流中的一次完整的經過，這些工作流至少包括：需求工作流、分析和設計工作流、實現工作流、測試工作流。其本身就像一個小型的瀑布項目。與傳統(tǒng)的瀑布模型相比較，迭代過程具有以下優(yōu)點：

降低了在一個增量上的開支風險。如果開發(fā)人員重復某個迭代，那么損失只是這一個開發(fā)有誤的迭代的花費。轉自項目管理者聯盟

轉自項目管理者聯盟

降低了產品無法按照既定進度進入市場的風險。通過在開發(fā)早期就確定風險，可以盡早來解決而不至于在開發(fā)后期匆匆忙忙。項目管理者聯盟

加快了整個開發(fā)工作的進度。因為開發(fā)人員清楚問題的焦點所在，他們的工作會更有效率。轉自項目管理者聯盟

由于用戶的需求并不能在一開始就作出完全的界定，它們通常是在后續(xù)階段中不斷細化的。因此，迭代過程這種模式使適應需求的變化會更容易些。

項目管理培訓

八、統(tǒng)一軟件開發(fā)過程RUP的十大要素

項目管理培訓

1.開發(fā)前景

2.達成計劃項目管理者聯盟

3.標識和減小風險

4.分配和跟蹤任務轉自項目管理者聯盟

5.檢查商業(yè)理由

6.設計組件構架

7.對產品進行增量式的構建和測試

8.驗證和評價結果

9.管理和控制變化

10.提供用戶支持轉自項目管理者聯盟

讓我們逐一的審視這些要素，看一看它們什么地方適合ＲＵＰ，找出它們能夠成為十大要素的理由。1.開發(fā)一個前景

有一個清晰的前景是開發(fā)一個滿足涉眾真正需求的產品的關鍵。前景抓住了ＲＵＰ需求流程的要點：分析問題，理解涉眾需求，定義系統(tǒng)，當需求變化時管理需求。前景給更詳細的技術需求提供了一個高層的、有時候是合同式的基礎。正像這個術語隱含的那樣，它是軟件項目的一個清晰的、通常是高層的視圖，能被過程中任何決策者或者實施者借用。它捕獲了非常高層的需求和設計約束，讓前景的讀者能理解將要開發(fā)的系統(tǒng)。它還提供了項目審批流程的輸入，因此就與商業(yè)理由密切相關。最后，由于前景構成了“項目是什么”和“為什么要進行這個項目”，所以可以把前景作為驗證將來決策的方式之一。對前景的陳述應該能回答以下問題，需要的話這些問題還可以分成更小、更詳細的問題：關鍵術語是什么（詞匯表）我們嘗試解決的問題是什么（問題陳述）涉眾是誰用戶是誰他們各自的需求是什么產品的特性是什么功能性需求是什么（ＵｓｅＣａｓｅｓ）非功能性需求是什么設計約束是什么2.達成計劃

“產品的質量只會和產品的計劃一樣好?！?2)在ＲＵＰ中，軟件開發(fā)計劃（ＳＤＰ）綜合了管理項目所需的各種信息，也許會包括一些在先啟階段開發(fā)的單獨的內容。SDP必須在整個項目中被維護和更新。ＳＤＰ定義了項目時間表（包括項目計劃和迭代計劃）和資源需求（資源和工具），可以根據項目進度表來跟蹤項目進展。同時也指導了其他過程內容（原文：processcomponents）的計劃：項目組織、需求管理計劃、配置管理計劃、問題解決計劃、QA計劃、測試計劃、評估計劃以及產品驗收計劃。

在較簡單的項目中，對這些計劃的陳述可能只有一兩句話。比如，配置管理計劃可以簡單的這樣陳述：每天結束時，項目目錄的內容將會被壓縮成ZIP包，拷貝到一個ZIP磁盤中，加上日期和版本標簽，放到中央檔案柜中。軟件開發(fā)計劃的格式遠遠沒有計劃活動本身以及驅動這些活動的思想重要。正如Dwight所說：“plan什么也不是，planning才是一切?！薄斑_成計劃”—和列表中第3、4、5、8條一起—抓住了RUP中項目管理流程的要點。項目管理流程包括以下活動：構思項目、評估項目規(guī)模和風險、監(jiān)測與控制項目、計劃和評估每個迭代和階段。

3.標識和減小風險

RUP的要點之一是在項目早期就標識并處理最大的風險。項目組標識的每一個風險都應該有一個相應的緩解或解決計劃。風險列表應該既作為項目活動的計劃工具，又作為確定迭代的基礎。

4.分配和跟蹤任務轉自項目管理者聯盟

有一點在任何項目中都是重要的，即連續(xù)的分析來源于正在進行的活動和進化的產品的客觀數據。在RUP中，定期的項目狀態(tài)評估提供了講述、交流和解決管理問題、技術問題以及項目風險的機制。團隊一旦發(fā)現了這些障礙物（籬笆），他們就把所有這些問題都指定一個負責人，并指定解決日期。進度應該定期跟蹤，如有必要，更新應該被發(fā)布。（原文：updatesshouldbeissuedasnecessary。）這些項目“快照”突出了需要引起管理注意的問題。隨著時間的變化/雖然周期可能會變化（原文：Whiletheperiodmayvary。），定期的評估使經理能捕獲項目的歷史，并且消除任何限制進度的障礙或瓶頸。

5.檢查商業(yè)理由

商業(yè)理由從商業(yè)的角度提供了必要的信息，以決定一個項目是否值得投資。商業(yè)理由還可以幫助開發(fā)一個實現項目前景所需的經濟計劃。它提供了進行項目的理由，并建立經濟約束。當項目繼續(xù)時，分析人員用商業(yè)理由來正確的估算投資回報率(ROI，即returnoninvestment)。商業(yè)理由應該給項目創(chuàng)建一個簡短但是引人注目的理由，而不是深入研究問題的細節(jié)，以使所有項目成員容易理解和記住它。在關鍵里程碑處，經理應該回顧商業(yè)理由，計算實際的花費、預計的回報，決定項目是否繼續(xù)進行。6.設計組件構架項目經理圈子

在RUP中，件系統(tǒng)的構架是指一個系統(tǒng)關鍵部件的組織或結構，部件之間通過接口交互，而部件是由一些更小的部件和接口組成的。即主要的部分是什么他們又是怎樣結合在一起的RUP提供了一種設計、開發(fā)、驗證構架的很系統(tǒng)的方法。在分析和設計流程中包括以下步驟：定義候選構架、精化構架、分析行為（用例分析）、設計組件。要陳述和討論軟件構架，你必須先創(chuàng)建一個構架表示方式，以便描述構架的重要方面。在RUP中，構架表示由軟件構架文檔捕獲，它給構架提供了多個視圖。每個視圖都描述了某一組涉眾所關心的正在進行的系統(tǒng)的某個方面。涉眾有最終用戶、設計人員、經理、系統(tǒng)工程師、系統(tǒng)管理員，等等。這個文檔使系統(tǒng)構架師和其他項目組成員能就與構架相關的重大決策進行有效的交流。

7.對產品進行增量式的構建和測試

在RUP中實現和測試流程的要點是在整個項目生命周期中增量的編碼、構建、測試系統(tǒng)組件，在先啟之后每個迭代結束時生成可執(zhí)行版本。在精化階段后期，已經有了一個可用于評估的構架原型；如有必要，它可以包括一個用戶界面原型。然后，在構建階段的每次迭代中，組件不斷的被集成到可執(zhí)行、經過測試的版本中，不斷地向最終產品進化。動態(tài)及時的配置管理和復審活動也是這個基本過程元素（原文：essentialprocesselement）的關鍵。

8.驗證和評價結果

顧名思義，RUP的迭代評估捕獲了迭代的結果。評估決定了迭代滿足評價標準的程度，還包括學到的教訓和實施的過程改進。根據項目的規(guī)模和風險以及迭代的特點，評估可以是對演示及其結果的一條簡單的紀錄，也可能是一個完整的、正式的測試復審記錄。這兒的關鍵是既關注過程問題又關注產品問題。越早發(fā)現問題，就越沒有問題。（原文：Thesooneryoufallbehind,themoretimeyouwillhavetocatchup.）

9.管理和控制變化

RUP的配置和變更管理流程的要點是當變化發(fā)生時管理和控制項目的規(guī)模，并且貫穿整個生命周期。其目的是考慮所有的涉眾需求，盡可能的滿足，同時仍能及時的交付合格的產品。用戶拿到產品的第一個原型后（往往在這之前就會要求變更），他們會要求變更。重要的是，變更的提出和管理過程始終保持一致。在RUP中，變更請求通常用于記錄和跟蹤缺陷和增強功能的要求，或者對產品提出的任何其他類型的變更請求。變更請求提供了相應的手段來評估一個變更的潛在影響，同時記錄就這些變更所作出的決策。他們也幫助確保所有的項目組成員都能理解變更的潛在影響。10.提供用戶支持

在RUP中，部署流程的要點是包裝和交付產品，同時交付有助于最終用戶學習、使用和維護產品的任何必要的材料。項目組至少要給用戶提供一個用戶指南（也許是通過聯機幫助的方式提供），可能還有一個安裝指南和版本發(fā)布說明。根據產品的復雜度，用戶也許還需要相應的培訓材料。最后，通過一個材料清單（BOM表，即BillofMaterials）清楚地記錄應該和產品一起交付哪些材料。關于需求有人看了我的要素清單后，可能會非常不同意我的選擇。例如，他會問，需求在哪兒呢他們不重要嗎我會告訴他我為什么沒有把它們包括進來。有時，我會問一個項目組（特別是內部項目的項目組）：“你們的需求是什么”，而得到的回答卻是：“我們的確沒有什么需求?！眲傞_始我對此非常驚訝（我有軍方的宇航開發(fā)背景）。他們怎么會沒有需求呢當我進一步詢問時，我發(fā)現，對他們來說，需求意味著一套外部提出的強制性的陳述，要求他們必須怎么樣，否則項目驗收就不能通過。但是他們的確沒有得到這樣的陳述。尤其是當項目組陷入了邊研究邊開發(fā)的境地時，產品需求從頭到尾都在演化。因此，我接著問他們另外一個問題：“好的，那么你們的產品的前景是什么呢”。這時他們的眼睛亮了起來。然后，我們非常順利的就第一個要素（“開發(fā)一個前景”）中列出的問題進行了溝通，需求也自然而然的流動著（原文：andtherequirementsjustflownaturally.）。也許只有對于按照有明確需求的合同工作的項目組，在要素列表中加入“滿足需求”才是有用的。請記住，我的清單僅僅意味著進行進一步討論的一個起點。

項目經理博客

九、總結

RUP具有很多長處：提高了團隊生產力，在迭代的開發(fā)過程、需求管理、基于組件的體系結構、可視化軟件建模、驗證軟件質量及控制軟件變更等方面，針對所有關鍵的開發(fā)活動為每個開發(fā)成員提供了必要的準則、模板和工具指導，并確保全體成員共享相同的知識基礎。它建立了簡潔和清晰的過程結構，為開發(fā)過程提供較大的通用性。但同時它也存在一些不足：RUP只是一個開發(fā)過程，并沒有涵蓋軟件過程的全部內容，例如它缺少關于軟件運行和支持等方面的內容；此外，它沒有支持多項目的開發(fā)結構，這在一定程度上降低了在開發(fā)組織內大范圍實現重用的可能性?？梢哉fRUP是一個非常好的開端，但并不完美，在實際的應用中可以根據需要對其進行改進并可以用OPEN和OOSP等其他軟件過程的相關內容對RUP進行補充和完善。

RUP與XP的平衡之道Author：SpiderMan（ShenZhen）

From：

Email：

人有過什么經驗，遇到過什么恐懼的事，就會形成設法避免這種事情的方法學。研究重型方法學的人可能一直以來的經驗就是組織上千人的開發(fā)隊伍進行開發(fā)，比如說大型電信系統(tǒng)的開發(fā)、軍事航天系統(tǒng)的開發(fā)......這種項目嚴格強調過程執(zhí)行的規(guī)范，注重文檔規(guī)范、評審及過程度量。而發(fā)明XP的人可能一直是在小團隊里做項目，項目團隊只有3、5個人，項目總是會因為沒有滿足用戶價值而被Cancel，開發(fā)公司也蒙受損失，因此注重與用戶的交流、反饋，強調快速、靈活。

每種軟件方法產生的背景不同、特點不同、適用的領域亦不相同。那么對于軟件項目來說，是否可以使用同一種軟件開發(fā)方法來對不同類型、規(guī)模、復雜度的項目來進行開發(fā)呢，顯然是不合理的。

前不久，恰巧和國內一位資深的軟件工程咨詢顧問做過一些交流，他本人熱衷于RUP的過程改進，倡導針對不同類型項目進行適當的裁剪，實際上這也是一種靈活適應的方式、隨需而變的思想。我對此是理解并贊同的，但是我對RUP卻一直保持一種相對謹慎的態(tài)度。

對于RUP來說，首先，我認為它過于理想化和理論化，RUP是過程組件、方法以及技術的框架，你可以將其應用于任何特定的軟件項目，由用戶自己限定RUP的使用范圍。對于各種類型的軟件項目，RUP并未給出具體的自身裁減及實施策略，總有些無依據可循的感覺。你既可以說它能解決任何問題，也可以說它什么都不是；其次，RUP從本質來說還是一個強調設計和規(guī)范的軟件方法，從這個角度來講，與傳統(tǒng)的瀑布模型沒有太大差別，它的靈活性較之敏捷方法還是相對較弱的。在一些小型軟件項目、特別是不可預測的軟件項目開發(fā)中，面臨著各種緊急需求、面臨著時間壓力，沿用RUP是很難應付自如的。但是在另一方面，RUP強調對知識的收集、整理和加工定義，強調在軟件開發(fā)的時候要有好的體系結構。所以它還是很有利于知識的積累和共享的。

相比RUP

，敏捷方法如XP則更為靈活，倡導盡早的、持續(xù)的交付有價值的軟件滿足用戶需要。用交流溝通取代詳盡的文檔，強調團隊的主動、自律、自我組織和自發(fā)管理。而XP也是以代碼為核心的一種方法，這里有很多的東西是未知的，知識只存在于兩個地方：開發(fā)者的頭腦和最后的代碼。對于項目管理者來說，他們會認為敏捷開發(fā)方法弱化了知識管理的概念，而實際上敏捷開發(fā)注重的是最有價值的知識的積累和沉淀。

如何靈活應對各種項目風險、如何最大化優(yōu)先滿足用戶價值、又如何能夠有效的控制項目開發(fā)過程、如果做好項目過程中的知識管理，是每一個軟件項目管理者都需要深入思考的問題。RUP的倡導者一直強調RUP裁剪，實際上我認為RUP不僅僅是需要自身的裁剪，還需要學會融合。在RUP裁剪的同時，適宜的融合敏捷開發(fā)的各種實踐。不要認為RUP與XP是矛盾的，其實不然，它們具有不同的原理、具有不同的應用領域。在RUP中融合了XP技術時，才會得到過程的正確量，既滿足了項目所有成員的需要，又解決了所有主要的項目風險問題。對于一個工作于高信任環(huán)境中的小型項目團隊，其中用戶是團隊的一部分，那么XP完全可以勝任。對于團隊越來越分散，代碼量越來越大，或者構架沒有很好定義的情況，您需要做一些其他工作。在用戶交互具有"契約"風格的項目中，僅有XP是不夠的。RUP是一個框架，可以從RUP出發(fā)，在必要時以一組更健壯的技術來擴展XP。

RUP最佳實踐包括：1.迭代開發(fā)

2．管理需求

3．使用基于組件的構架

4．可視建模

5．持續(xù)的質量驗證

6．控制變更

12個XP實踐包括：有計劃的開發(fā)：通過結合使用優(yōu)先級"故事"和技術估算，確定下一版本的功能

小版本：以小的增量版本經常向客戶發(fā)布軟件

隱喻：隱喻是一個簡單、共享的"故事"或描述，說明系統(tǒng)如何工作

簡單設計：通過保持代碼簡單從而保證設計簡單。不斷的在代碼中尋找復雜點并且立刻進行移除

測試驅動開發(fā)：用戶編寫測試內容以對"故事"進行測試。程序員編寫測試內容來發(fā)現代碼中的任何問題。在編寫代碼前先編寫測試內容

重構：這是一項簡化技術，用來移除代碼中的重復內容和復雜之處

結對編程：團隊中的兩個成員使用同一臺計算機開發(fā)所有的代碼。一個人編寫代碼或者驅動，另一個人同時審查代碼的正確性和可理解性

集體代碼所有權：任何人都擁有所有的代碼。這就意味這每個人都可以在任何時候變更任何代碼

持續(xù)集成：每天多次創(chuàng)建和集成系統(tǒng)，只要任何實現任務完成就要進行

每周40個小時：程序員在疲勞時無法保證最高效率。連續(xù)兩周加班是絕對不允許的

現場客戶：一名真實的客戶全時工作于開發(fā)環(huán)境中，幫助定義系統(tǒng)、編寫測試內容并回答問題

編碼標準：程序員采用一致的編碼標準證RUP與XP的融合，是各自特點的相互補充，也是軟件開發(fā)方法的平衡之道。而對軟件技術平衡的思考也可以說是技術成熟的開始吧。最后，再闡明我對軟件項目開發(fā)的理解。在軟件項目開發(fā)過程中，應該能夠識別、分析不同軟件項目的特點，采用相對適合的開發(fā)實踐來適應軟件開發(fā)過程，保證對軟件開發(fā)的有效支持，以便能夠創(chuàng)造出“足夠好的”軟件。而這個足夠就是對進度、成本、質量之間的平衡，最大化滿足客戶需要的實現。

軟件開發(fā)過程學習總結目的：初步理解CMM、RUP、XP分別是怎樣的過程，弄懂其關鍵步驟，分析其優(yōu)劣及適應情況。最后綜各家之長，給出一個可能較實用可行的軟件開發(fā)過程體系XProcess，以用在項目(或產品)開發(fā)中。ByRobinZhang.一、

CMM1.綜述CMM2－CMM3，可以看作是一個嚴謹的，傳統(tǒng)瀑布式的開發(fā)體系。CMM并未提供具體的過程體系，它只是一個評價標準(“軟件能力成熟度”)。但它提供了一個目標：一個可重復賦值成功經驗的開發(fā)體系應該是怎樣的。知識點：1).通常應該從CMM2開始實現，一般做到CMM3的已經難得了。2).CMM2是一套已定義的項目管理過程，CMM3是總結不同項目的經驗，最終形成組織（公司）的一套過程標準。3).可以考慮交叉引用，即上CMM2及CMM3的培訓、同行評審。4).CMM與CMMI的區(qū)別：前者僅限于軟件工程,后者還包括其他學科的CMM，如系統(tǒng)工程等；前者一般意味著瀑布過程，后者支持迭代方法。參考：CMM2:“定義了項目管理過程，將項目劃分成幾個明確定義的階段，每個階段結束都是控制點，增加了軟件開發(fā)過程的透明度和可控性。項目執(zhí)行中好的經驗可以在別的項目中重復，軟件開發(fā)有了一定的保證。”CMM3:“是對CMM2項目管理的全面整合和提高，綜合公司所有類型項目的過程經驗，制定公司統(tǒng)一的最佳過程，增加了對項目每個階段的內部過程規(guī)定和檢查點，使得軟件開發(fā)工程更加透明和可控?！?.關鍵過程包括：CMM2：項目計劃、需求管理、配置管理、質量管理、項目過程控制。CMM3：同行評審(需求、設計、代碼評審)、培訓計劃、體系規(guī)范注：能做到上面8項就可以了。

CMM等級關鍵域KPA對應產出、流程操作相關產出、過程(參考)CMM2需求管理需求基線項目建議書,概要需求,需求評審,需求規(guī)格書軟件項目計劃建立一個合理有效的軟件項目計劃軟件項目立項書、風險分析控制報告等軟件項目跟蹤和監(jiān)督項目管理,過程管理任務分解、下達，每日耗費，每周例會，單元測試報告，里程碑等軟件配置管理標識軟件配置項，建立產品基線庫，對配置項的修改加以系統(tǒng)的控制配置管理計劃,VSS代碼庫,版本,代碼同步,演示帳套軟件質量管理單元測試、功能測試、繼承測試等質量保證計劃,測試計劃,測試用例,產品質量報告,單元測試、功能測試、繼承測試等子合同管理外包管理CMM3同行評審

需求評審,設計評審,代碼評審培訓計劃

知識共享,內部培訓,VSS共享,創(chuàng)新獎等組織級過程焦點，組織級過程定義，集成軟件管理，軟件產品工程，組間協調，1.各種規(guī)范：需求、分析設計、編碼、數據庫規(guī)范。2.體系規(guī)定文檔

3.適用情況1).中大型軟件企業(yè)，同時進行多個項目、產品的研發(fā)（必須有一套體系以便管理、控制）。2).需求比較明確，并已經定義凍結的情況，如產品項目。3)適合用瀑布式過程開發(fā)的項目。4.優(yōu)劣優(yōu)點：體系嚴謹，提高了軟件開發(fā)過程的透明度和可控性，令項目成功經驗可以重復復制。缺點：因瀑布過程需要，要求需求凍結，導致需求過程要求非常高。而在項目中，需求變更是不可避免的。5.其他企業(yè)上到一定規(guī)模，偏重產品開發(fā)時，可以考慮上CMM。中小軟件企業(yè)可借鑒并精簡地實現它的關鍵過程，如項目計劃、需求管理、配置管理、質量管理、項目過程控制、同行評審、培訓計劃。

二、

RUP1．

綜述RUP是一個由用例驅動、以架構為中心的、迭代增量的開發(fā)過程框架。2．

關鍵過程

迭代開發(fā)過程及產出：見：《UML和設計模式》第一頁。流程工件初始精化構造交付項目管理軟件開發(fā)計劃等S:1)定義項目目的，范圍、約束。2)第一個迭代計劃1）

分析需求用例，確定迭代計劃(任務時間表)。2）

確定編碼等規(guī)范3）

需求基線1）按迭代計劃進行開發(fā)2）每個迭代都實現一個用例集，包含一個設計編碼測試過程。客戶測試評估上線運行

業(yè)務建模領域模型

S細化建模

需求用例模型、需求規(guī)格說明書、補充需求文檔S:1)確定Actor及其需要。2)確定最重要的用例

R1)編寫詳細用例需求規(guī)格書2)確定更多用戶需要、產品特性、用例集合并確定其優(yōu)先級重要性風險。需求初步基線。r迭代過程中允許需求變更，但必須受控，分析對目前需求的影響，再決定是否在下一個迭代基線進去。

設計設計模型、軟件架構文檔

R挑選部分重要用例，開始建設計模型R對迭代內的用例進行更詳細的設計

實現實現代碼

S1）實現部分重要且風險大的用例，以驗證并確定架構設計。R全力編碼，按時完成迭代內的用例實現。

測試測試用例

S根據用例編寫測試用例測試已實現迭代功能，編寫新迭代的測試用例

文檔等使用文檔等

s

產品文檔，用戶培訓產出

項目計劃書(前景文檔)、高層用例模型、最重要用例規(guī)格說明書、(概要設計說明書)、開發(fā)環(huán)境(總體軟件架構、開發(fā)規(guī)范)80%詳細需求規(guī)格書(用例集及補充說明書)、用例模型、領域模型及設計模型，部分詳細設計文檔，部分測試用例，產生一個可執(zhí)行的原型(實現部分重要用例)內部發(fā)版，可用于測試的完整產品。詳細設計說明書

產出2

項目計劃、概要需求列表、初步架構說明、重要用例需求規(guī)格書、編碼規(guī)范需求規(guī)格說明書(80%)，概要設計文檔()、項目迭代計劃、重要用例的設計及實現,設計模型，詳細設計說明書，代碼實現，測試用例（迭代）產品、說明文檔，用戶培訓s開始，r精化提煉

3．

適用情況4．

優(yōu)劣5．

其他參考：

三、

XPXp注重人的因數，提倡盡量敏捷輕量級的過程。重要過程：測試驅動、迭代開發(fā)、持續(xù)集成構建、客戶現場參與(確定迭代內的功能集，提供業(yè)務邏輯的確認，驗證程序等)、只在必要時做簡單設計

一)、Xp的缺點：1.

要求客戶現場參與。通常國內項目都是前期作需求確認，無法提供整個開發(fā)過程的需求確認支持。除非是分段來確認（如迭代結束時）。2.

測試驅動開發(fā)。目前還很難做到，因為編寫測試腳本需要花費不少精力，一般項目無法做到。由此也無法作重構，無法保證能有靈活的設計來支持因前期不明確的需求而導致的變更。3.

缺少文檔、設計支持。Xp只在必要時才寫文檔及設計，這樣可能導致xp新手缺乏良好的設計指引，項目開發(fā)過程透明度不夠，可能會失控。二）、xp可借鑒的地方1.

對整個開發(fā)過程：迭代開發(fā)、持續(xù)集成2.

對特定迭代：編碼規(guī)范、保持設計靈活(允許需求改動)3.

設計編碼過程：測試驅動、重構(用在編碼過程中，以客戶端來“測試驅動”業(yè)務邏輯層、以重構減少重復代碼)參考：四、實用過程XProcess：RUP+XP，并達到CMM2-3考慮目前國內項目現況：需求調研先行，但需求不明確導致需求變更。中小公司缺乏過程規(guī)范指導，基本在CMM1即混亂狀態(tài)。

XProcess＝CMM的體系+RUP的過程+XP的最佳實踐參考文檔：,,RUPand,dXProcess

1.

過程：取RUP的過程過程還是取項目啟動、細化、構建、交付四個過程。啟動階段：定義項目計劃、風險分析、項目前景、范圍、約束；確定Actor、涉眾及收益；確定概要需求；作一個原型，實現關鍵用例。細化階段：確定用戶需要、產品特性并確認優(yōu)先級、風險；確定80%需求，編寫需求規(guī)格書。制定迭代計劃，需求基線；完成重要用例的設計及實現，由此確定系統(tǒng)架構及第三方組件。已制定迭代計劃。同時編寫對應用例的測試用例。 構建階段：按計劃迭代開發(fā)。在每個迭代里采用小瀑布的方式，應用部分XP的最佳實踐(見下2)，每個迭代為一個里程碑，提交給客戶確認，由此得到需求變更，分析后調整迭代計劃。 交付階段：提交客戶測試，作小的修改。編寫產品說明，用戶培訓，上線運行。項目總結、關閉報告。2.

迭代內的步驟：取xp的最佳實踐合并細化的后期+構造期，為“設計編程期”，在這期間，啟用“保持設計靈活”、編碼規(guī)范、代碼審核(結隊編程)、持續(xù)集成、測試驅動、重構的最佳實踐。3.

使用CMM的關鍵域的規(guī)范流程，，以達到CMM2-3的效果在RUP的四個階段中，應用CMM的關鍵域，來保證各種產出的質量。如下：先啟階段：項目計劃、項目過程控制、配置管理、培訓計劃(設計、編碼規(guī)范)細化階段：體系規(guī)范、同行評審(需求、設計、代碼評審)、需求管理、質量管理構建階段：編碼規(guī)范、設計、代碼評審、需求變更管理交付階段：體系規(guī)范

三者的關系如下：1.

RUP：是由用例驅動、迭代增量開發(fā)的過程，主要定義了各個階段應該做什么，做到什么程度。2.

CMM：是一套評估標準，提供了一些關鍵實現域(需求管理等)，對每一個產出提出了質量要求。3.

XP：主要關注編碼階段的一些最佳實踐。是一個提倡敏捷的輕量級軟件開發(fā)方法。強調“交流；簡單；反饋；實事求是”。強調客戶參與，簡單設計(靈活設計)、允許需求變更等。4.

下面是按傳統(tǒng)瀑布式的過程，來考察三種過程方法在各個階段的活動及產出。

過程RUPCMMXP項目啟動先啟項目計劃、風險列表、過程控制、配置計劃、概要需求列表等客戶盡可能參與需求調研先啟、精化(用例模型)需求管理、需求評審、需求基線客戶盡可能參與分析設計精化、構建(領域模型、設計模型)設計評審、軟件配置、培訓計劃靈活設計、需求變更編碼實現構建、啟動、精華(代碼)代碼評審、需求變更控制測試驅動開發(fā)、重構、編碼規(guī)范、日構建、小版本發(fā)布、簡單實現測試構建、精化質量管理UnitTest文檔及實施等交付

RUP與Scrum的對話作者：IBM摘要現在使用RUP的軟件項目可以很容易地從Scrum原則中獲益，即使已經開始的項目也是如此。首先需要調研的是RUP過程模型，Scrum如何影響RUP最好的實踐活動，四個階段（初始，細化，構建和產品化），以及RUP的九個原則。

來自于RationalEdge：本文介紹了被稱為Scrum的靈活軟件開發(fā)過程。作者闡述了軟件開發(fā)團隊在已有RUP環(huán)境中加入Scrum理念的技術。

正如你所知道的，RUP（RationalUnifiedProcess，Rational統(tǒng)一過程），是一種被廣泛使用的軟件過程框架。它可以很好地迎合你的軟件開發(fā)過程的需要，還可以容納其他技術。Scrum是一系列有趣的，用來包裝靈活軟件項目的項目管理模式。本文介紹了Scrum的一些重要特性，并闡述了可以讓你在已有RUP環(huán)境中加入Scrum理念的技術。我在工具條內提供了關于Scrum和“靈活”的術語的詞匯表，并且在下文中這些術語首次出現的地方用星號作了標記。

什么是Scrum

Scrum是一種靈活的軟件管理過程，它可以幫助你駕馭迭代，遞增的軟件開發(fā)過程。Scrum于1995年由AdvancedDevelopmentMethodologies,Inc提出，并在2001年“敏捷聯盟（AgileAlliance）”形成后受到了更多歡迎。這個輕量的過程可以作為包裝器，也就是說你可以把Scrum與其它靈活的過程框架組合起來，比如說RUP。

Scrum提供了一種經驗方法，它使得團隊成員能夠獨立地，集中地在創(chuàng)造性的環(huán)境下工作。它發(fā)現了軟件工程的社會意義。Scrum一詞來源于橄欖球運動，暗指這種情況：“在橄欖球比賽中，雙方前鋒站在一起緊密相連，當球在他們之間投擲時他們奮力爭球。2”

這一過程是迅速，有適應性，自組織的，它代表了從順序開發(fā)過程以來的重大變化。Scrum認為軟件的開發(fā)不應使用和一般制造業(yè)相同的方法，也就是不應采用一種反復的模式。這種重復使得輸入和輸出參數更加容易預測和描述，但這并不是當今軟件工程的有益目標。現代軟件工程的主要挑戰(zhàn)包括上市時間，投資回報，以及影響顧客的需要等。RUP和其他敏捷軟件工程過程能夠很好地迎接這些挑戰(zhàn)。

Scrum如何工作

Scrum區(qū)別于其他開發(fā)過程之處是什么假設你是一個Scrum項目的初次觀察者，那么最顯而易見的不同將是每天的短會，通常在每天的同一時間在同一個房間內舉行。這個會議也叫Scrum，在會議中每個團隊成員僅就以下三點發(fā)言：

*自上次Scrum會議后你做了什么

*從現在到下次Scrum會議的時間里你準備做什么

*你在工作中遇到了哪些困難

Scrum團隊的組成

由于一個Scrum團隊最多由7人組成，會議應當不超過15分鐘。Scrum管理者*主持會議，并且對整個項目的成敗負責。他傾聽每個成員的發(fā)言并設法解決會議中提到的各種障礙。Scrum管理者在會上對障礙提出即時的解決方案或指導，使團隊不斷向著目標前進。Scrum會議不同于項目會議，對團隊來說，它起到了快速簡報的作用。如果問題得不到解決，團隊成員應向Scrum管理者或大項目成員提出質疑。

只有團隊成員可以在Scrum會議上發(fā)言，但是允許有旁聽者。對于人數多于7人的項目團隊，Scrum建議與其擴大團隊規(guī)模不如將團隊分組。分組可依據功能，結構主體，或者應用，包括子應用等進行。分組后各個子團隊就可以并行工作了，而且Scrum管理者可以通過Scrum會議對各個子團隊的工作進行同步。Scrum甚至可以兼顧在其他地方工作的團隊成員。

Scrum團隊不止是一個程序員隊伍，它由各種背景下的不同角色組合而成，包括商業(yè)分析者，設計師，程序員和測試者等等。更多時候，成員可以身兼多職；正確的組合決定了團隊的能力和效率。

項目規(guī)劃

Scrum的迭代過程被稱為“疾跑”，時間為30天。在RUP中，迭代過程通常在2至6周之間，每次“疾跑”都以獲得可執(zhí)行可測試的代碼為結束。

產品擁有者持有產品訂單，他控制并區(qū)分功能的開發(fā)次序，但是工作量的評估是由Scrum團隊來完成的。產品風險的所有承擔者，包括Scrum團隊和產品所有者，共同檢視訂單，然后根據優(yōu)先級次序決定先開發(fā)哪一功能。除去優(yōu)先級，RUP的迭代規(guī)劃過程也是基于風險的。

現在團隊定義的“疾跑”目標已經成為了進展控制的指導?！凹才堋边^程一旦開始，團隊全部與外界的交流都必須經由Scrum管理者進行。Scrum管理者務必保證團隊能夠專心于既定目標而不受外界干擾。

Scrum團隊持有自己的“疾跑”訂單，上面記錄了更多關于待實現目標的具體任務的細節(jié)。在團隊對“疾跑”的作用有更多了解以后，團隊成員就可以調整原始的產品評估，并將“疾跑”過程中獲得的信息加入到產品訂單中。這些做法對Scrum進度回溯都是有益的。

Scrum團隊由每天的Scrum會議，每月的“疾跑”計劃和“疾跑”審查會議緊密相連，鑒于此，整個組織必然存在一種縱向的透明度。這就使得組織上的問題和挑戰(zhàn)清晰明顯。由于團隊成員都親自觀察整個項目，交流也就變得簡短，迅速和有效。團隊是自組織的，著眼于“疾跑”的目標，這樣就最大限度發(fā)揮了每一個團隊成員的作用。Scrum管理者充當一個問題和交流的“票據交換所”，而不是一個控制整個團隊的老板。

“疾跑”審查會議持續(xù)半天。在會上，團隊向項目的風險承擔者展示完成的功能模塊。團隊按照既定的“疾跑”目標來演示完成的內容。

訂單，“疾跑”計劃和回顧，管理承諾，每日Scrum會議，進度回溯，以及其他Scrum技術都是基于主要用于軟件項目管理的進程模式的。這些模式在過去的大小項目和不同商業(yè)領域中都獲得了成功。如果你打算采用Scrum進程模式并與RUP結合起來，下面一部分將向你解釋更多要點。

Scrum與RUP的結合

現在使用RUP的軟件項目可以很容易地從Scrum原則中獲益，即使已經開始的項目也是如此。首先需要調研的是RUP過程模型，Scrum如何影響RUP最好的實踐活動，四個階段（初始，細化，構建和產品化），以及RUP的九個原則。RUP各階段和原則之間的關系如圖一所示。

圖一：左邊列出的是RUP的各個原則，與項目的四個階段相關聯。

盡管大多數原則與各個階段都相關，上圖表示出了在各個階段中原則的不同的相關度。

RUP：軟件開發(fā)的最佳實踐

讓我們從RUP過程框架的六個最佳實踐開始吧。

迭代開發(fā)

Scrum項目強制執(zhí)行迭代的開發(fā)過程，以30天為一個合適的開發(fā)時長。盡管在對“迭代”的定義上RUP更為靈活，30天的限定仍然經常被RUP使用，并且已被認為是一個有效的長度。工作總是按照30天的“疾跑”排列下來的，而不是定義一個RUP項目的一次迭代的長度。

管理需求

整個團隊都可以管理需求，但是需求的控制權是由產品所有者掌握的。在RUP中，需求工程師對需求負責，但在Scrum中，這一責任屬于產品所有者，通常表現為商業(yè)風險承擔者。在RUP中，需求管理需要通過協作完成。

使用模塊構建

體系架構是由公司的開發(fā)策略和指導決定的，或者由團隊自身提出。RUP倡導的以體系架構為核心的方法導致了對各種應用結構的仔細考慮和選擇。在Scrum中，這一定義較松，并決定于發(fā)布給團隊的指導和標準。很多靈活的軟件項目使用現代軟件工具和編程語言，比如，模塊構建占主導的技術。

可視化模型

RUP提倡可視化模型。甚至RUP框架本身就是可視的，有很多UML的外殼。和RUP一樣，Scrum雖然不要求開發(fā)團隊建構某一特定的可視化組件，但是委派Scrum團隊完成這項工作。關于使用哪種組件，使用到何種程度和質量，取決于既定的“疾跑”目標。由于UML在工業(yè)界的廣泛認可，很多工業(yè)專家都使用可視化技術，并且在RUP和Scrum中，可視化模型的使用都是很普遍的。

持續(xù)的保證質量

迭代，遞增的開發(fā)已經為每個軟件項目的質量和進展提供了很好的度量手段。Scrum團隊完全集中于他們的“疾跑”目標，在30天的周期內必須展示工作成果。在這種方式下，功能是用一種重復的方式測試，度量和展示的。但是在大型組織中，質量控制是從各種角度觀察的，而且需要更高質量管理的程序。Scrum可以從RUP的質量保證計劃中獲益，該計劃由項目管理者控制，是成功的迭代開發(fā)的重要組成部分。

管理變更

在任何現代軟件開發(fā)項目中都會出現變更（變化應該是受到歡迎的?。?，但是Scrum管理者不會為了引入發(fā)生在達成共識的目標上的變更而打斷一個“疾跑”周期。他們抓住需要的變化，在本次“疾跑”結束時提出它們作為下一系列目標的一部分。這對Scrum的“疾跑”來說是最關鍵的。團隊與外界隔離開工作，不予許變化影響當前的“疾跑”。否則，迭代開發(fā)的領域（“疾跑”的目標）的不斷調整將會導致團隊失去中心，不能很好完成疾跑伊始確定的功能目標。

Scrum和RUP原則

為了在Scrum的上下文環(huán)境中討論RUP的九個原則，我把它們分成了兩類。第一類是關于“雨傘活動”的，它們間接的對系統(tǒng)開發(fā)或組織有益，比如“環(huán)境”，“項目管理”，和“配置和變更管理”。第二類是材料活動，包括“商業(yè)模型”，“需求”，“分析和設計”，“實現”，“測試”，和“部署”。

雨傘活動

雨傘活動是指Scrum團隊上層的管理機制，應由外部的風險承擔者處理，比如，項目管理。除了扮演項目經理角色的Scrum管理者，團隊成員應該專注于對實現Scrum目標必要的活動，而不應陷于管理工作之中。

RUP的“項目管理”原則，特別是項目規(guī)劃，為軟件開發(fā)團隊提供了體驗Scrum精髓的絕好機會。從Scrum管理者開始項目起，對團隊來說RUP項目就如同一個Scrum項目。內部的組織上，管理上，語言的，非語言的交流都應被Scrum團隊消除，而應該交給Scrum管理者（在RUP中稱為項目經理）處理。一個RUP項目規(guī)劃對如下工作來說是最理想的：

*概括項目中應用的Scrum規(guī)則；

*確定項目階段標志；

*描述正在進行中的“疾跑”目標；

*呈現風險；

*描述評估和評估使用的技術。

在Scrum中，Scrum管理者充當了管理和Scrum團隊之間的協調人。管理者管理項目的使用域和功能，同內部和外部進行交流，但是并不參與更具體活動級別的管理。這些職責和義務的不同需要在項目規(guī)劃中定義。另外，Scrum團隊成員的角色通常是設計師。

在一個Scrum管理的項目中，RUP環(huán)境原則下的開發(fā)工程是不斷進行調整和修改的。開發(fā)工程把強制性的和可選擇性的組件羅列出來作為成功的指路標。但是由于Scrum團隊是作為一個獨立單位工作的，團隊開發(fā)的組件應該都被稱為“可選擇性的”以反映團隊在Scrum環(huán)境中的控制作用。另一方面，你也可以從開發(fā)工程去掉所有和Scrum團隊相關的組件。RUP中的一般開發(fā)工程模板都可以完成這種需要。經過一段時間，隨著Scrum團隊在“疾跑”過程中規(guī)律性地獲得有用的文檔，真實的開發(fā)工程也就成形了。

收集素材

余下的六個RUP原則對軟件工程有更直接的影響，它們?yōu)镾crum團隊提供了一系列可選擇的組件和活動。RUP過程框架可以作為指導，提供可供考慮的有用步驟和組件。在特殊情況下，團隊可以對每一條原則做出變更和修改，只要這種變更和修改有助于實現“疾跑”的目標。新手和經驗不豐富的軟件工程師可以把RUP作為交流的指導和一個結構化的環(huán)境。

RUP項目的四個階段體現了軟件工程過程中的不同項目樣式。盡管Scrum原則適用于項目的整個生存周期，消耗大部分項目資源的細化和構建階段最宜使用Scrum方法。與初始階段相比，在細化和構建階段團隊的工作更加獨立和指向切實目標。Scrum的“疾跑”規(guī)劃，審查，和每日會議在這兩個階段是非有用的手段。

如果在初始階段，甚至在項目開始之前，項目團隊中有各種商業(yè)分析人員，那么在初始階段Scrum也是很有益的。為了更好地保證項目的成功部署，產品化階段可以單獨作為一個項目擁有Scrum部署團隊人員。對整個RUP項目來說，Scrum項目管理技術可能不是最理想的，但是它們可以在項目的不同階段以不同形式被采用。項目規(guī)劃反映了這些決定，而且闡述了在某些階段不使用Scrum技術的原因。

使RUP適用于Scrum的工具

與IBM的RationalProcessWorkbench共用時，RUP作為進程框架體現了強大優(yōu)勢，而且是完全用戶化的。RationalProcessWorkbench產品包含了RUP模型設計，RUP組織和RUP構建。

RUP模型設計是修改和管理核心模型的可視化工具。過程工程師可以對現有RUP框架進行修改以引入Scrum概念。使用RUP模型設計工具可以很容易的管理Scrum的角色和組件之間的依賴性。過程工程師可以使用RUP組織工具描述修改后的Scrum工作流。這樣做有助于項目團隊成員更好的理解Scrum過程。為了共享組織內的過程變化，過程工程師通過RUP構建工具發(fā)布進程。該工具將過程，組件和描述文檔集成起來，并創(chuàng)建一個網絡導航。

結束語

Scrum和RUP可以通過很多方式相互加強。RUP過程框架可以迎合你的項目需要；RUP開發(fā)工程和軟件開發(fā)規(guī)劃反映了你對使用Scrum技術的決定。根據我的經驗，Scrum團隊會非常規(guī)律地進行開發(fā)活動，并完成最有效的開發(fā)工程。輸出的組件可以作為組織內其它項目的輸入文檔。

概括來說，RUP通過引入結構化并已經證實的進程框架滿足了組織上的需求，而且Scrum模式可以為項目加入更多動態(tài)特性。比如說，可以很容易地向你當前的或未來的RUP項目中加入Scrum管理模式。至于軟件工程的社會效應方面，Scrum已被證實的過程模式可以即時地方便需求管理，變化控制以及項目管理提供。在RUP組件對開發(fā)過程和項目文檔的指導下，Scrum團隊成員，特別是新手或是經驗不足者，可以避免陷入軟件開發(fā)的陷阱。

參考

您可以參閱本文在developerWorks全球站點上的英文原文。

AgileAlliance(2004)

KenSchwaber和MikeBeedle,AgileSoftwareDevelopmentwithSCRUMPrenticeHall,2002.

Scrum(2004).SeeThediagramat的圖表可以幫助你更直觀的理解Scrum的項目迭代過程。

RUP迭代開發(fā)計劃的兩種方法2009年5月14日隨著軟件技術的發(fā)展、客戶需求的變化越來越快、對應用軟件項目的交付的要求也越來越要跟上市場的變化，RUP非常適合這樣的開發(fā)場景，在應用軟件開發(fā)中已經成為最常用的開發(fā)模式。從項目管理的角度來看，RUP的開發(fā)中對于迭代計劃的開發(fā)和管理是保證成功交付項目的關鍵。好的迭代開發(fā)計劃可以有效降低項目的風險，提高團隊的協作，提高項目開發(fā)效率。筆者結合在以往項目中應用RUP迭代開發(fā)的實踐，總結了兩種開發(fā)迭代計劃的方法，并對比兩者的適用情況，以期對應用RUP的項目管理人員提供借鑒。前言隨著技術的快速發(fā)展和市場的快速變化，應用軟件項目的交付越來越面臨著需求不明確、交付進度緊、項目風險大、項目規(guī)模變大、項目團隊協作困難、客戶參與度高等問題。在這種情況下，RUP的迭代開發(fā)的方法已經成為應用軟件開發(fā)項目的主流的開發(fā)模式，并能夠有效解決這些問題。但是本文不會完整討論整個軟件開發(fā)過程中RUP的貢獻和如何應用RUP。只是從項目管理和項目計劃的角度探討如何應用RUP的迭代方法開發(fā)項目計劃。筆者在多個項目中應用RUP進行軟件項目的開發(fā)和管理，在本文中將結合實踐闡述RUP迭代計劃的兩種開發(fā)方法，對于指導項目經理裁剪和應用RUP有實際的參考意義。本文還將與讀者分享在實際項目中應用RUP如何開發(fā)迭代目標、如何開發(fā)迭代計劃以及介紹了兩種不同的迭代計劃的模板參考示例。迭代計劃的特點迭代開發(fā)是RUP的核心思想，但是大家在剛開始使用RUP時你會發(fā)現這么多的并行工作流對項目管理同時也帶來很大挑戰(zhàn)和難度。因此使用RUP來完成項目，開發(fā)迭代計劃是實施的主要難點之一。迭代計劃的特點：一個迭代是總體項目計劃的一個階段需要明確的交付目標（或可以運行的系統(tǒng)）多個比較明確的角色的參與可以串行也可以并行體現了RUP架構驅動、關注風險的特點實現快速交付，縮短大項目的交付周期提高客戶參與度和項目的可視化迭代計劃的開發(fā)考慮的因素：總體項目計劃項目規(guī)模大小、周期需求明確程度和技術風險團隊成熟度和規(guī)模項目所處的階段，在同一個項目的不同的階段可以采用不同的迭代計劃方法迭代目標的設置上面提到迭代計劃是實施RUP的難點之一，那么設置迭代目標就是解決這個難點的重點。應用RUP開發(fā)項目的迭代目標主要是以項目開發(fā)周期中該迭代結束后所發(fā)布的交付物為主。RUP的迭代交付物通常以可以運行的系統(tǒng)，包括需求驗證原型，架構驗證原型，功能驗證原型，測試系統(tǒng)，最終上線產品等。通常在項目前期的迭代中以發(fā)布原型系統(tǒng)和原型架構為主，在項目的中期以發(fā)布的增量的功能Feature、業(yè)務模塊為主，而在項目的后期以增量業(yè)務功能、測試系統(tǒng)、非功能需求、缺陷修改為主。當然，對于不同的項目類型，迭代的目標的設置也不同，比如系統(tǒng)軟件產品的開發(fā)項目與應用軟件開發(fā)項目，新軟件產品開發(fā)與軟件系統(tǒng)升級項目的差別就非常大。另外影響迭代目標的另外一個重要因素是項目的需求和架構的成熟程度，需求的明確程度，個性化需求和共性需求的比例，是影響項目風險和迭代開發(fā)目標的重要因素。還有就是采用的架構和技術，也是影響的重要因素之一，因此迭代目標的設置需要結合和考慮項目的總體目標和采用的不同的架構方法論，比如IBMSOA項目的SOMA（Service-OrientedModelingandArchitecture）面向服務的建模和架構。概括來說，項目范圍或需求、架構及決策、項目總體目標是設置迭代目標的重要的輸入。比如原型迭代開發(fā)的迭代目標可以這樣定義：開發(fā)架構驗證框架完成2個關鍵業(yè)務用例的實現完成對架構決策中3個關鍵技術的驗證實現迭代計劃的開發(fā)方法RUP的開發(fā)過程模型對項目管理和項目計劃提出了更高的要求，迭代計劃的好壞直接影響到項目目標的實現，項目風險和生產效率。如何更好地平衡和組織項目中眾多的并行活動和分配不同的項目專業(yè)角色，對項目管理提出了很大的挑戰(zhàn)。根據筆者在眾多的項目中應用和實踐RUP中，總結出了兩種迭代計劃的開發(fā)方法。當然這兩種方法并不是相互獨立和分開使用的。在不同的項目或者同一個項目的不同的階段，會交替使用甚至組合使用。下面就分別介紹這兩種方法的內容、區(qū)別和適用情況。以時間為軸線的迭代計劃以時間為軸線的迭代計劃也是使用RUP開發(fā)整體項目計劃的主要的方法。根據項目的周期分為軟件開發(fā)的初始階段（InceptionPhase）、精化階段（ElaborationPhase）、構建階段（ConstructionPhase）和產品化階段（TransitionPhase）。一般來說，這四個階段作為項目開發(fā)生命周期的主要里程碑，而細化后的迭代階段作為項目的二級里程碑。迭代計劃就是在每個里程碑下以時間順序設置不同的開發(fā)迭代以滿足里程碑的要求，達到里程碑的目標。比如在初始階段一般有1-2個迭代周期，精化階段一般會有2-4個迭代周期。當然迭代周期的個數要根據項目的類型、項目的規(guī)模和項目的特點不同來選擇。一般對于需求不明確的應用軟件的開發(fā)項目，往往精化階段會有更多個迭代，而在產品移交階段的迭代會比較少。而對于軟件系統(tǒng)升級項目，往往在構建階段的迭代會比較多。迭代周期（Duration）也是制定迭代目標要考慮的因素，迭代周期也是根據項目整體的周期長短來確定合理的周期。一般來說2個周到2個月是比較合理的選擇。迭代周期的長短在同一個項目中是可以不同的，但是一般經驗來看，相對固定的設置從項目管理和項目團隊的工作來看更適合，可以保持比較好的項目的工作節(jié)奏。確定迭代個數和迭代周期，往往與設置迭代目標是相輔相成的。綜合考慮，在完成了迭代目標、周期后，項目管理人員就可以開發(fā)項目的迭代計劃了。在以時間為軸線的迭代計劃一般會將多個工作流（WorkFlows）集成在一個計劃中，項目團隊內部有分工，但是不強調過于明顯的分工。這種方法一般適合項目早期、人員較少的情況下。在項目的中后期，往往會結合以軟件工程流程和角色為軸線的計劃方法。在這種方法下，對于一個迭代開發(fā)周期中，更像一個小的瀑布模型。各個迭代之間沒有重合（Overlap），是串行執(zhí)行的。具體例子參照如下：

圖1.以時間為軸線的迭代計劃

圖2.以時間為軸線的迭代計劃示例

以軟件工程流程或者角色為軸線的迭代計劃當項目規(guī)模比較大，團隊內部角色分工比較明確的情況下，迭代開發(fā)的活動組織在一個計劃中往往難以管理和監(jiān)控。這個時候項目一般會采取以軟件工程流程或者開發(fā)角色為軸線來組織迭代開發(fā)計劃。根據RUP的工程流程，項目中會有如下活動類型：業(yè)務建模，需求分析，分析設計，實施開發(fā)，測試，部署，配置和變更管理，項目管理，環(huán)境。理論上每種軟件工程流程都會對應一個單獨的計劃，而且每個軟件工程流程會定義自己的迭代周期和迭代次數。當然這個單獨的計劃只是相對獨立的，一方面要與總體的項目集成計劃保持一致，另一方面還要考慮與其他軟件工程流程的計劃的依賴關系。項目經理的非常重要的職責之一就是識別和管理這些依賴關系，使之保證項目開發(fā)的順利進行。對于如上九種軟件工程流程，并不是一定要對應九個單獨的子計劃，在一般的應用軟件的開發(fā)項目中，一般根據角色的團隊的情況分為如下幾個單獨的計劃：業(yè)務需求開發(fā)計劃軟件設計計劃軟件開發(fā)計劃測試計劃管理和集成計劃軟件開發(fā)計劃可能還會存在多個，比如一個項目有多個子系統(tǒng)的開發(fā)，開發(fā)團隊比較大，一般又會分為子系統(tǒng)1開發(fā)計劃、子系統(tǒng)2開發(fā)計劃，分別組織實施。在這種情況下各個迭代計劃之間是有重合（Overlap）的，項目計劃活動的執(zhí)行是并行進行的。具體的例子如下所示：

圖3.以軟件工程流程為軸線的迭代計劃

圖4.以軟件工程流程為軸線的迭代計劃示例

回頁首兩種計劃方法的總結下表對比兩種方法，總結不同的方法在不同的適用場景下的適用情況，作為項目管理人員選擇和采用的依據：

表1.兩種方法的對照總結適合情景時間為軸線的迭代計劃工作流程和角色為軸線的迭代計劃適合的項目規(guī)模都可以全部或大型項目適合項目團隊的大小小團隊大團隊適合的項目階段全部或者項目早期項目的中期依賴內部依賴，串行執(zhí)行造成團隊之間或者計劃之間的依賴，并行執(zhí)行管理難度中低高綜上所述，在一個項目中，項目經理和項目管理人員往往根據項目的具體情況和項目所在階段來采用不同的迭代計劃的開發(fā)方法。甚至將兩者結合，制定適合項目的迭代計劃，從而降低項目風險、提供項目團隊的協作能力，提高生產效率，實現快速交付的目標。

敏捷RUP：來自實戰(zhàn)中的經驗由ScottW.Ambler所做的介紹這篇文章實際上是由三篇文章組合而成的。它們?yōu)樵贗BM?Rational?UnifiedProcess?或者簡稱為RUP?團隊上面應用敏捷策略提供了被證明為行之有效的建議。本文是由MarkLines、JoshuaBarnes、以及JulianHolmes分別撰寫的，它們都是UnifiedProcessMentors（）的共同創(chuàng)辦人。這三位已經通過書籍指導了全世界成千上萬名軟件開發(fā)方面的從業(yè)者，舉辦了幾十場研討會，撰寫了多部著作，作為咨詢顧問和用戶組的主席人等。他們工作于遍及世界各地的機構中，將他們的處理過程理論付諸實踐，通過實例引導并且通過結構的改變驅動成功。我的經驗是，好的RUP就是敏捷的1并且包含了許多成功地測量敏捷技術所需要的建議。第一篇文章“將規(guī)則引入到敏捷的生命周期之中”是由MarkLines撰寫的，它展示了RUP需求管理技術和風險驅動開發(fā)周期是如何將所需要的規(guī)則性水平引入到許多機構中的，并且還不失敏捷方法的特點之一：靈活性。作者認為您并不希望需求在開發(fā)周期的后期發(fā)生根本上的變更，而前期的一小部分投資能夠從根本上減少您的開銷、進度、以及整個項目所面臨的風險。第二篇文章“在大型機構中將敏捷性引入RUP的策略”是由JoshuaBarnes撰寫的，它從一個相反的方向對待