我們集中討論如何通過使用兩個流行的方法得到過程的恰當級別：Rational Unified Process 或簡稱 RUP 以及極限程式設計（XP）。我們展示如何在小型專案中使用 RUP 以及 RUP 如何處理 XP 沒有涉及到的領域。二者融合為專案團隊提供了所需的指南--減少風險同時完成交付軟體產品的目標。

RUP 是由 IBM Rational 開發的過程框架。它是一種迭代的開發方法，基於六個經過行業驗證的最佳實踐（參見 RUP 附錄）。隨著時間的推進，一個基於 RUP 的專案將經歷四個階段：起始階段（Inception）、細化階段（Elaboration）、構造階段（Construction）、交付階段 （Transition）。每個階段都包括一次或者多次的迭代。在每次迭代中，您根據不同的要求或工作流（如需求、分析和設計等）投入不同的工作量。 RUP 的關鍵驅動因素就是降低風險。RUP 通過數千個專案中數千名 IBM Rational 客戶和合作夥伴使用而得到精化。下圖展示了一個典型迭代過程的工作流：

典型迭代流

作為風險如何影響過程的一個例子，我們應該考慮是否需要為業務建模。如果由於對業務的理解中沒有考慮到一些重大風險，將導致我們所構建的系統是錯誤 的，那麼我們就應該執行一些業務建模工作。我們需要正式進行建模工作嗎？這取決於我們的涉眾--如果一個小團隊將非正式地使用結果，那麼我們也許只進行非 正式的記錄就可以。如果組織中的其他人也將使用結果或者檢視結果，那麼我們可能就要投入更大的努力，並且確保該結果的正確性和可理解性。

您可以定製 RUP 使其滿足幾乎任何專案的需要。如果沒有滿足您特定需要的即裝即用的過程或路線圖，您可以輕鬆地建立您自己的路線圖。路線圖描述了該專案如何計劃使用過程， 因此代表了該專案的特定過程例項。這就意味著，RUP 可以按需要變得簡單或複雜，我們將在本文中詳細解釋。

XP 是一個用於小型專案中的以程式碼為中心的輕量級過程（參見 XP 附錄）。它來自 Kent Beck 的創意，在大概 1997 年 Chrysler 公司的 C 3 工資單專案中得到軟體界的關注。如同 RUP 一樣，XP 也是基於迭代的，並且體現了諸如小規模釋出、簡單設計、測試以及持續迭代幾項實踐，。XP 為恰當的專案和環境引入了一些有效的技術；不過，其中也存在隱藏的假設、活動和角色。

RUP 和 XP 具有不同的基本原理。RUP 是過程元件、方法以及技術的框架，您可以將其應用於任何特定的軟體專案，我們希望使用者限定 RUP 的使用範圍。XP，從另一方面來說，是一個具有更多限制的過程，需要附加內容以使其適合完整的開發專案。這些不同點解釋了軟體開發界的一個觀點：開發大型 系統的人員使用 RUP 解決問題，而開發小型系統的人員使用 XP 作為解決方案。我們的經驗表明大部分的軟體專案都處於兩者之間--盡力找尋適用於各自情況的過程的恰當級別。單純地使用兩者之一是不充分的。

當您在 RUP 中融合了 XP 技術時，您會得到過程的正確量，既滿足了專案所有成員的需要，又解決了所有主要的專案風險問題。對於一個工作於高信任環境中的小型專案團隊，其中使用者是團 隊的一部分，那麼 XP 完全可以勝任。對於團隊越來越分散，程式碼量越來越大，或者構架沒有很好定義的情況，您需要做一些其他工作。在使用者互動具有"契約"風格的專案中，僅有 XP 是不夠的。RUP 是一個框架，您可以從 RUP 出發，在必要時以一組更健壯的技術來擴充套件 XP。

本文的以下部分描述了一個基於 RUP 四個階段的小型專案。在每個階段中，我們都確定了所產生的活動和工件 。雖然 RUP 和 XP 具有不同的角色和職責，但是我們在這裡不會處理這些差異。對於任何組織或專案，實際專案成員必須在過程中與正確的角色關聯起來。

專案啟動－起始階段
對於新的開發專案來說，起始階段是很重要的，在專案繼續進行前，您必須處理重要的業務與需求風險。對於那些增強現有系統的專案，起始階段是比較短暫的，但是其目的仍是確定該專案的實施價值及可行性。

在起始階段中，為了構建軟體您可以建立業務案例。檢視是起始過程中的關鍵工件。它是系統的高階描述。它為每個人解釋該系統是什麼、可能使用系統的用 戶、使用系統的原因、必須具備的功能，以及存在的約束。檢視可能很短，也許只有一兩段。檢視往往包括軟體必須為客戶提供的關鍵功能。

下面的例子展示了一個專案的很短檢視，該專案對 Rational 的外部網站進行了改造。

為使 Rational 的地位達到電子開發（包括工具、服務和最佳實踐）的世界領先程度，可以通過動態的、個性化的網站加強客戶關係，為訪問者提供自助服務、支援和目標內容。新的過程和技術啟用可以使內容供應商通過一種簡化的、自動的解決方案加速釋出並提高內容的質量。

RUP 起始階段中 4 個重要活動為：

制定專案的範圍。如果我們打算構建一個系統，我們需要知道其內容以及它如何滿足涉眾的需要。在這個活動中，我們捕獲內容和最重要的需求的足夠詳細的資訊，從而得出產品可接受的標準。

計劃並準備業務案例。我們使用檢視作為指導，定義風險緩和策略，開發起始的專案計劃，並確定已知成本、日程計劃，以及盈利率平衡。

綜合得出備選構架。如果正在計劃中的系統沒什麼新穎性，而且使用的框架廣為人之，那麼您可以跳過這一步。我們一旦知道客戶的需求，就要開始分配時間 研究可行的備選構架。新技術能夠帶來解決軟體問題的新的並且經過改進的解決方案。在過程的早期花些時間評估購買還是建立系統，並選擇技術，也可以開發出一 個起始原型，這些都可以減少專案的一些主要風險。

準備專案環境。任何專案都需要專案環境。不論您使用 XP 技術（例如結對程式設計），還是較傳統的技術，您都需要確定團隊將要使用的物理資源、軟體工具以及步驟。

進行小型專案開發時，並不需要太多的"過程時間"來執行起始過程。您往往可以在幾天中或者更少的時間裡完成，下面的內容說明了本階段除了檢視之外的預期工件。

一個經批准的業務案例
涉眾有機會 從業務的角度認定專案是值得進行的。RUP 和 XP 都承認最好在早期就得出專案是否值得進行的結論，以免在一個註定將要失敗的專案中花費寶貴的資源。如同在"Planning Extreme Programming" 一書描述的那樣，XP 對於專案是如何形成的以及涉及哪些角色這兩個問題的回答是比較模糊的（似乎在現有專案或系統的環境中是最清晰的），但是在研究階段，XP 處理的工件與 RUP 起始過程中的是相同的。

不論您在 XP 中非正式地考慮業務問題，還是在 RUP 中將業務案例做成一流的專案工件，您都需要考慮這些問題。風險清單您應該在整個專案開發過程中都保持記錄 Risk List（風險清單）。使用有風險清單可以是一個具有經過計劃的風險緩和策略的簡單清單。為各個風險設定優先順序。任何與專案有關的人員都可以隨時看到風險 的內容以及如何處理風險，但是沒有提供解決風險的一般方式 。

初步專案計劃
本計劃包括資源估算、規模以及階段計劃。對於任何專案，這些估算都是不斷變化的，您必須監控它們。

專案驗收計劃
您的計劃正式與否依 賴於專案的型別。您必須判斷客戶會如何才能認為您的專案取得了成功。對於一個 XP 專案，客戶會採取驗收測試的形式。在更普遍的過程中，客戶可能不會真正地進行測試，但是接受的標準必須直接由客戶作出，或者由另一個角色作出，例如與客戶 直接接觸的系統分析員。也可能存在其他的驗收標準，例如建立終端使用者文件和幫助，但是XP並不涉及此內容。

起始細化迭代計劃
在基於 RUP 的專案中，在上次迭代的最後，您將詳細計劃下次迭代。在迭代的最後，您可以評估迭代開始時設立的標準。XP 提供了探監控與衡量迭代成功的一些優秀技巧。衡量標準是簡單的，您可以輕鬆地將它們合併到迭代計劃和評估標準中。

起始用例模型
雖然這聽起來比較正 式而讓人望之卻步，但是它卻相當簡單。用例與客戶在XP中編寫的"故事"相對應。其間的差異就是一個用例就是一套完整的動作，由參與者或系統外部的人員或 事物發起，這正是用例的價值所在。用例可能包括若干個XP"故事"。RUP 為了定義專案的邊界，推薦在起始過程中確定使用者與角色。從使用者的觀點關注整套操作有助於將系統分為有價值的部分。這有助於判定恰當的實施特性，因此我們能 夠在每次迭代的最後向客戶交付一些成果（可能在起始迭代與細化迭代早期除外）。

RUP 與 XP 都可以幫助我們確保避免一種情況，即整個專案已完成 80％，但都不是可交付的形式。我們一直希望釋出的系統對使用者都是有價值的。

在這一點上，用例模型在識別用例和參與者方面幾乎沒有或只有很少提供支援的細節。它可以是手工或使用工具繪製的簡單的文字或者 UML（統一建模語言）圖。該模型幫助我們確保已經包含了涉眾所關心的正確的功能，並且沒用忘記任何功能，並允許我們輕鬆地檢視整個系統。用例根據若干因 素設定優先順序，這些因素包括風險、對客戶的重要程度以及技術難點。起始階段中不需要過於正式的或過大的工件。按照您的需求讓它們保持簡單或者正式就可以。 XP 包括對計劃與系統驗收的指南，但是 RUP 需要在專案的早期新增更多的一些內容。這些少量新增可能通過處理一套更完整的風險而為專案提供很大的價值。

細化階段
細化階段的目標是為系統構架設立基線，為在構建階段大量的設計與實施工作打下堅實的基礎。構架通過考慮最重要的需求（那些對系統構架影響最大的需求）與評估風險演進而來。構架的穩定性是通過一個或多個構架原型進行評估的。

在 RUP 中，設計活動主要關注系統構架的概念，對於軟體密集型的系統來說，就是軟體構架的概念。使用元件構架是在 RUP 中體現的軟體開發 6 項最佳實踐其中之一，該實踐推薦在開發與所作所為構架上要投入一些時間。在這項工作花費的時間可以減緩與脆弱的、僵化日系統有關的風險。

XP 使用"隱喻"替換了構架的概念。隱喻只捕獲構架的一部分，而其餘構架部分則隨著程式碼開發的自然結果而演進。XP假定構架的形成是從生成簡單的程式碼開始，然後進行持續的程式碼重構。

在 RUP 中，構架不只是"隱喻"。在細化階段中，您構建可執行的構架，從中可能降低與是否滿足非功能性需求相關的許多風險，例如效能、可靠性以及健壯性。通過閱讀 XP文獻，很可能推斷出一些 RUP 為細化階段所描述的內容，尤其是過於 XP 所稱的基礎設施的過分關注，都是徒勞無功的。XP 認為在沒有必要的情況下建立基礎設施所做的工作導致瞭解決方案過於複雜，並且所建立的結果對客戶沒有價值。在 RUP 中，構架與基礎設施不是等同的。

在 RUP 與 XP 中建立構架的方法是截然不同。RUP 建議您關注構架，避免隨時間變化而產生的範圍蔓延、增加專案規模以及採用新技術帶來的風險。XP 採用足夠簡單或是很好理解的現有構架，該構架能夠隨著程式碼而演進。XP 建議您不要為明天而設計，而要為今天而實施。XP 相信如果您儘可能地保持設計簡單，那麼將來管理起來也輕而易舉。RUP 希望您考慮該主張帶來的風險。如果系統或者部分系統在未來不得不重寫，那麼 XP 認為這種舉措比現在就計劃這種可能性更明智而且花費更少。對於一些系統，這是千真萬確的，而且使用 RUP 時，在您細化階段考慮風險也會得出同一結論。RUP 並不認為對於所有系統這都是正確的，而且經驗表明對於那些較大型、較複雜和沒有先例的系統來說，這可能是災難性的。

雖然為未來的可能性（可能永遠不會生生）花費太多的精力可能是一種浪費但是對未來進行足夠的關注不失為一件精明之舉。多少公司能花得起代價不斷重寫或者甚至是重構程式碼呢？

對於任何專案，在細化階段您應該至少完成這三項活動：

定義、驗證並且設定構架的基線。 使 用風險清單從起始階段開發備選構架。我們關注是否能夠保證構想中的軟體具有可行性。如果選定技術對於系統沒什麼新穎性或者複雜性，這項任務不會花費太長時 間。如果您正在向現有系統中新增內容，那麼如果現有構架不需要進行變更，這項任務就不是必要的。但是當真正出現構架風險時，您並不想讓您的架構來"碰運 氣"。

作為這項活動的一部分，您可能執行一些元件選擇，並且做出決定進行購買/建立/重用元件。如果這需要大量工作，您可以將其分為單獨的活動。

精化檢視。 在起始 階段，您開發了一個檢視。因為你要確定專案的可行性，並且涉眾有時間檢查和評價系統，因此可能要對檢視文件及需求作出一些變更。對檢視與需求的修改一般在 細化階段進行。在細化階段的最後，您已經深刻理解了用來構建和計劃的最關鍵的用例。涉眾需要得到認可，在當前構架的環境中，只要按照當前的計劃開發整個系 統，就能實現當前的設想。在隨後的迭代過程中，變更的數量應該有所減少，但是您可能會在每次迭代中花一些時間進行需求管理。

為構建階段建立迭代計劃並且設定基線 。 現在，可以為您的計劃填充細節了。在每次構建迭代的最後，您可以按需要重新考慮計劃並且進行調整。調整過程經常是必需的，因為需要進行的工作往往被錯誤地 估算，業務環境也會常常變化，有時需求也會發生變更。為用例、場景以及技術工作設定優先順序，然後將它們分配到迭代過程中。在每次迭代過程的最後，您計劃產 生一個能夠為涉眾提供價值的工作產品。

您可以在細化階段執行其他活動。我們推薦您建立測試環境並且開始開發測試。雖然詳細的程式碼還沒有完成，但是您仍然可以設計測試，也許可以實施整合測 試。程式設計師應該隨時準備進行單元測試，並且瞭解如何使用專案選定的測試工具。XP 推薦您在編寫程式碼前先設計測試內容。這是個獨到的見解，尤其是當您向現有程式碼主體中新增內容時。不過，無論您選擇如何進行測試，都應該在細化階段建立常規 測試體制。

RUP 描述的細化階段包括 XP 中的研究階段和投入階段。XP 處理技術風險（例如新穎性和複雜性）的方式為使用"spike"解決方案，例如花費一些時間進行試驗以對工作量進行估算。這種技術在許多案例中都是有效 的，當較大風險沒有體現在單個用例或"故事"中時，您就需要花些工夫確保系統的成功而且對工作量進行精確的估算。

在細化階段，您會經常更新工件，例如起始階段的需求與風險清單。在細化階段可能出現的工件包括：

軟體構架文件（SAD）。 SAD 是一個複合型的工件，它提供了整個專案的技術資訊的單一來源。在細化階段的最後，該文件可能會包含詳細的介紹，描述在結構上很重要的用例，並且確定關鍵的 機制和設計元素。對於增強現有系統的專案，您可以使用以前的 SAD，或者如果你覺得不會帶來什麼風險，那麼就決定不使用該文件。在所有的情況下，您都應該深思熟慮並且記錄於文件中。

構建過程的迭代計劃。 您 可以在細化階段計劃構建迭代的次數。每次迭代都有特定的用例、場景以及其他分配的工作專案。這些資訊都在迭代計劃中有所體現並且設定基線。評審與核准計劃 可以作為細化階段的出口標準的一部分。對於非常小的短期專案來說，您可以將細化階段的迭代與起始過程和構建過程合併。關鍵性的活動仍然可以進行，但是迭代 計劃和評審所需的資源都會有所減少。

構建階段
構建的目標是完成系統開發。構建階段從某種意義上來看是一個製造過程，其中重點工作就是管理資源、控制操作以優化成本、日程和質量。從這個意義上來講，管理理念應該進行一個轉換，從起始階段和細化階段的智慧財產權開發轉換到構建和交付階段的部署產品的開發。

XP 側重構建階段。構建階段是編寫產品程式碼的階段。XP所有階段的目的都是為了進行計劃，但是 XP 的關注焦點是構建程式碼。

構建階段的每次迭代都具有三個關鍵活動：

管理資源與控制過程。 每個人都需要了解自己的工作內容和時間。您必須保證工作負荷不會超過您的能力，而且工作可以按計劃進行。

開發與測試元件。 您構建元件以滿足迭代中用例、場景以及其他功能的需要。您對其進行單元測試和整合測試。

對迭代進行評估。 在迭代完成時，您需要判斷是否已經達到了迭代的目標。如果沒有，您必須重新劃分優先順序並管理範圍以確保能夠按時交付系統。

不同型別的系統需要使用不同的技術。RUP 為軟體工程師提供了不同的指導，以幫助他們建立恰當的元件。以用例和補充（非功能）需求的形式提出的需求是足夠詳細的，可以使工程師開展工作。RUP 中的若干活動為設計、實施和測試不同種類的元件提供了指南。一名有經驗的軟體工程師不需要詳細檢視這些活動。經驗稍欠缺一些的工程師可以通過最佳實踐獲得 很大的幫助。每個團隊成員都可以按需要深入研究過程或者只是稍微瞭解一下。不過，他們都參照一個單獨的過程知識基礎。

在 XP 中，"故事"驅動實施過程。在 Extreme Programming Installed 一書中，Jeffries等人認為"故事"是程式設計師的"會話承諾"（promises for conversation）。 持續有效的交流大有裨益。雖然總是需要澄清一些細節，如果"故事"不夠詳細，而使程式設計師不能完成他們大部分工作，那麼可以說"故事"還沒有就緒。用例必須 足夠詳細以方便程式設計師實施。在許多情況下，程式設計師會幫助編寫用例的技術細節。Jeffries 等人認為，會話應該記錄在文件中並且附加到"故事"中。RUP 也同意這個觀點，除了以用例規格說明的形式，可以按需要使用非正式的形式。捕獲並管理會話的結果是您必須管理的任務。

XP 的長處在於構建階段。對於大多數團隊來說，都存在適用於他們的"智慧與指南的結晶"。XP 中最顯著的實踐包括：

測試--程式設計師不斷地隨著程式碼的開發編寫測試。測試反映了"故事"。XP提倡您首先編寫測試，這是一項優秀的實踐，因為它可以迫使您深刻地理解"故 事"，並且在必要的地方提出更多的問題。不論在編寫程式碼之前還是之後，一定要編寫測試。將它們加入到您的測試包中，並且保證每次程式碼變更時都執行測試。

重構--不斷重構系統的結構而不改變其行為，可以使其更加簡單或靈活。您需要判斷對您的團隊來說是否存在一個較好的實踐。簡單與複雜的判別否因人而 異。有這樣一個例子，一個專案中的兩個很聰明的工程師每晚都要重寫對方的程式碼，因為他們認為對方的程式碼過於複雜。這產生了一個副作用，也就是他們總是干擾 第二天其他成員的工作。測試是有幫助的，但是如果他們之間不陷入程式碼之爭的話，那麼團隊的處境就會更好一些。

結對程式設計--XP 認為結對程式設計可以在更短的時間內創建出更好的程式碼。有證據表明這是正確的 。如果您遵照這項實踐，就需要考慮許多人文與環境的因素。程式設計師願意對此進行嘗試嗎？您的物理環境可以滿足這種情況嗎，即有足夠的空間使兩個程式設計師在一個 單獨工作站中有效地工作？您如何對待遠端工作或者在其他地點工作的程式設計師？

持續整合--整合與構建工作需要持續進行，可能每天不止一次。這是一種確保程式碼結構完整的很好的方式，它還允許在整合測試過程中進行持續的質量監控。

集體程式碼所有權--任何人都可以隨時修改任何程式碼。XP 依賴這樣一個事實，即一組好的單元測試將會減少這項實踐的風險。讓大家將每一件事都搞清楚的好處不能侷限在一定的尺度上--是 1 萬行程式碼、2 萬行程式碼還是一定要少於 5 萬行？

簡單設計--隨著重構過程的進行，需要不斷地修改系統設計使其變更簡單。再一次重申，您需要判斷這項工作進行到何種程度才恰好合適。如果您在細化階段中花費了必要霎時間來設計構架，我們相信簡單的設計將會很快完成並且很快變得穩定。

程式碼標準--這一直都是一項良好實踐。標準是什麼都沒關係，只要您使用它們而且每個人都認可就可以。

RUP 與 XP 都認為您必須管理（和控制）迭代過程。衡量標準可以提供較好的計劃資訊，因為它們可以幫助您選擇對於您的團隊來說什麼是最適合的。需要衡量三件事：時間、 規模和缺陷。這樣您就可以獲得所有型別您所感興趣的統計數字。XP 為您提供簡單的衡量標準來判斷進展並且預測成果。這些衡量標準圍繞著完成的"故事"數量、通過測試的數量以及統計中的趨勢這些問題。XP 為使用最少量的衡量標準做出了一個優秀的表率，因為檢視太多並不一定會增加專案成功的機會。RUP 為您提供了對於您可以衡量的內容以及如何衡量的指導，並且舉了有關衡量標準的例子。在所有的情況中，衡量標準必須簡單、客觀、易於蒐集、易於表達，並且不 易產生誤解。

在構建階段的迭代過程中將會產生哪些工件呢？這取決於迭代是處於構建階段的早期還是後期，您可以建立以下工件：

元件--元件代表了軟體程式碼中的一部分（原始碼、二進位制程式碼或者可執行程式），或者包含資訊的檔案，例如，一個啟動檔案或者一個 ReadMe 檔案。元件還可以是其他元件的聚合，例如由幾個可執行程式組成的應用程式。

培訓資料--如果系統的使用者介面比較複雜，那麼請在用例的基礎上儘早編寫使用者手冊和其他培訓資料的初稿。

部署計劃--客戶需要一個系統。部署計劃描述了一組安裝、測試並且有效地向用戶交付產品所需的任務。對於 以Web 為中心的系統來說，我們已經發現，部署計劃的重要性又提高了。

交付階段迭代計劃--臨近交付時，您需要完成並且評審交付階段迭代計劃。

程式碼完整嗎？
認為程式碼就是設計並且設計也就是程式碼。程式碼與自身總是一致的，這一點是千真萬確的。我們認為花費精力進行設計並且溝通設計是很值得的，而不僅僅是建立程式碼。下面的小故事會說明這一點。

一名工程師曾有兩次這樣的軟體專案經歷，設計體現在程式碼中，並且只能在程式碼中找到設計資訊。這兩個專案都是關於編譯器的：一個是改進與維護用於 Ada 編譯器的優化程式，另一個專案是將一個編譯器的前端移植到一個新的平臺上，並且連線一個第三方的程式碼生成器。

編譯器技術是比較複雜的，但也是廣為人知的。在這兩個專案中，該工程師想要概覽編譯器（或者優化程式）的設計和實施。在每個案例中，他都接到一堆源 程式碼清單，大概有幾英尺厚，而且被告知"檢視這些資訊"。他本應被提供一些帶有支援性文字的構建很好的圖。優化程式的專案沒有完成。但是編譯器專案確實取 得了成功，由於在程式碼開發過程中進行了廣泛的測試，所以程式碼質量很高。這位工程師花費了數天時間研究偵錯程式中的程式碼以弄明白其作用。個人的損失尚在其次， 團隊的損失代價就更不值得。我們並沒有按 XP 所示的那樣在 40 小時後完成開發，我們反而花費了大量個人努力來完成工作。

只開發程式碼帶來的主要問題就是無論程式碼文件編寫得多麼好，它都沒有告訴您它本身要解決的問題，它只提供了問題的解決方案。一些需求文件在最初使用者和 開發人員繼續工作很長時間以後，仍然可以很好地解釋專案的原始目標。為了維護系統，您往往需要了解最初專案團隊的設計目標。一些高階設計文件都是相似的 --程式碼經常沒有經過高度的抽象，所以無法提供任何資訊以表明整體的系統能夠實現什麼功能。在面向物件的系統中，這一點尤其是正確的，因為僅僅檢視裡面的 類檔案是很難甚至無法得出執行執行緒。設計文件指導您在後期出現問題時該檢視的內容--在後期經常會出現問題。

這個故事說明花費時間建立與維護設計文件確實會有所幫助。這可以降低誤解的風險，並且加速開發過程。XP 的方式就是花費幾分鐘勾畫出設計的大概內容或者使用 CRC 卡片。 但是團隊不主張這樣，而只是進行程式碼開發。他們有一個隱含的假設，那就是任務很簡單，我們已經知道該如何進行了。即使我們成功地完成了任務，那麼下一個新 來的人可能就不會如此幸運。RUP建議您多花費一些時間建立並維護這些設計工件。

交付階段
交付階段的焦點就是確保軟體對於終端使用者是可用的。交付階段包括為釋出進行產品的測試，在使用者反饋的基礎上做微小的調整等幾方面內容。在生命週期的這個時刻，使用者反饋主要集中在精確調整產品、配置、安裝，以及可用性等問題上。

較早釋出、經常性發布都是很好的辦法。但是，我們通過釋出要達到的目的是什麼呢？XP 沒有清楚地解釋這個問題，也沒有處理髮布商業軟體所必須製造問題。在內部專案中，您可以為解決這些問題找到捷徑，但是即使這樣，您仍然需要編輯文件、員工 培訓等工作。那麼技術支援與變更管理又如何呢？希望現場客戶控制這些內容，這是可行的嗎？Bruce Conrad 在他的 XP 的 InfoWorld 評論 中指出使用者並不希望得到的軟體總是在持續變更。您必須對快速變更軟體的利益和變更的劣勢及可能帶來的不穩定性進行權衡。

當您決定釋出的時候，您必須為終端使用者提供比程式碼多得多的東西。交付階段的活動和工件會指導您完成本部分軟體開發過程。這些活動主要是為了向您的客戶提供可用的產品。交付階段的關鍵活動如下：

確定終端使用者支援資料。該活動比較簡單，您只需提供一個清單即可。但是務必要確保您的組織已準備好對客戶進行技術支援。

在使用者的環境中測試可交付的產品。如果您能夠在公司內部模擬使用者環境，那是最好不過的。否則，就到客戶的公司去，安裝軟體並且保證其可以執行。您一定不想尷尬地回答客戶："但是在我們的系統上工作很正常。"

基於使用者反饋精確調整產品。如果可能的話，在您向有限數量客戶交付軟體時計劃一次或者多次 Beta 測試周期。如果進行該測試，那麼就需要對 Beta 測試周期進行管理，並且考慮您"收尾工作"中的客戶反饋。

向終端使用者交付最終產品。對於不同型別的軟體產品和釋出版本，需要處理許多有關打包、製造和其他產品問題。您肯定不會僅僅將軟體複製到一個資料夾中，然後向客戶發一封郵件告訴他們軟體已經到位了。

與其他階段一樣，過程的格式與複雜度都有所不同。不過，如果您沒有注意部署細節，那麼可能導致數週或數月的良好開發工作前功盡棄，從而在進入目標市場時以失敗告終。

在交付階段中您可以生成若干工件。如果您的專案涉及到將來的釋出（有多少專案沒有涉及到呢？），那麼您就應該開始為下次釋出確定功能和缺陷。對於任何專案，下列工件都至關重要：

部署計劃--完成您始於構建階段的部署計劃並且將其作為交付的路線圖。

版本註釋--它是一個比較少見的軟體產品，不包含對終端使用者至關重要的指令。可以對其做出計劃，對於註釋要有一個可用的、一致的格式。

交付階段資料與文件--這類資料可以採取很多形式。您可以線上提供所有內容嗎？您會進行指導嗎？您的產品幫助完整並且可用嗎？不要認為您所瞭解的，客戶也同樣瞭解。您的成功就在於幫助您的客戶取得成功。

結束語
構建軟體的工作遠遠多於編 寫程式碼所工作。一個軟體開發過程必須集中處理向用戶釋出高質量軟體的所有必需活動。一個完整的過程不必是龐大的。我們通過集中論述專案中的主要活動和工 件，已經向您展示瞭如何進行一個小型但是完整的過程。如果執行某項活動或者建立某個工件對於緩解專案中的風險是有幫助的，那麼就請進行。您可以按需要為您 的專案團隊和組織使用或多或少的過程和格式。

RUP 和 XP 並不必是互相排斥的。通過結合使用這兩種方法，您完全可以得到一個過程，幫助您比現在更快地交付更高質量的軟體。Robert Martin 描述了一個叫做 dX 的過程，他將其作為 RUP 的附屬品 。它就是一個從 RUP 框架中構建的過程的例項。

一個優秀的軟體過程可以使用經業界驗證的最佳實踐。最佳實踐已經在真實的軟體開發組織中使用，並且經歷了時間的考驗。XP 是目前廣為關注的方法。它以程式碼為中心，並提供了一項承諾：花費最少的過程開銷得到最大的生產力。XP 中的許多技術值得在恰當的情況中考慮和採用。

XP 關注"故事"、測試和程式碼--它以一定的深度討論了計劃，但沒有詳細闡述如何獲取計劃。XP 意味著您可以完成其他一些工作，例如"使用一些卡片進行 CRC 設計或者草擬某種 UML……"或者"請不要生成並不使用的文件或者其他工件"，但只是一帶而過。RUP 希望您在定製和更新開發計劃時，僅僅考慮建立有用和必須的東西，並且指出了這些東西該是什麼。

RUP 是一個可以處理整個軟體開發週期的過程。它關注最佳實踐，並且經過了數千個專案的洗禮。我們鼓勵研究和發明新的技術以產生最佳實踐。隨著新的最佳實踐嶄露頭腳，我們希望將它們納入 RUP 中。

附錄：Rational Unified Process
Rational Unified Process，或者簡稱 RUP，提供了軟體開發的規律性方法。它是由IBM Rational開發並維護的過程產品。它為來同類型的專案提供了幾種即裝即用的路線圖。RUP 還提供了一些資訊，幫助您在軟體開發過程中使用其他 Rational 工具，但是它不要求將 Rational 工具有效地應用於整個組織，您也可以將 Rational 工具與其他供應商的產品進行整合。

RUP 為軟體專案所有方面提供了指導。並不需要您執行任何特定的活動或者建立任何特定的工件。它只為您提供資訊和指南，您可以決定將哪些應用於您的組織。如果沒有特定的路線圖適合您的專案或者組織，RUP 還提供了一些指南來幫助您量身定做你的過程。

RUP 強調採用現代軟體開發的一些最佳實踐，作為一種降低開發新軟體所帶來的內在風險的方式。這些最佳實踐包括：

1． 迭代開發
2． 管理需求
3． 使用基於元件的構架
4． 可視建模
5． 持續的質量驗證
6． 控制變更

這些最佳經驗融合到 Rational Unified Process 的以下定義中：

角色--執行的系列活動和擁有的工件。
學科--軟體工程中的關鍵領域，例如需求、分析與設計、實施與測試。
活動--工件生成與評估方式的定義。
工件--在執行活動中所使用的、生成的或修改的工作產品。

RUP 是一個迭代過程，確定了任何軟體開發專案的四個階段。隨著時間的推進，每個專案都要經歷起始階段、細化階段、構建階段和交付階段。每個階段包括一次或多次 迭代，其中您可以生成可執行檔案，但是系統可能不完整（可能起始階段除外）。在每次迭代過程中，您以不同的細節級別執行幾個學科中的活動。下文是 RUP 的概述圖。

The Rational Unified Process, An Introduction, Second Edition 一書是 RUP 的好的概述。您可以在 Rational 的 Web 站點 www.rational.com 上找到更進一步的資訊和對於 RUP 的評價。

附錄：極限程式設計
極限程式設計（XP） 是由 Kent Beck 在 1996 年開發的一種軟體開發學科。它基於四個價值：溝通、簡單、反饋和勇氣。它強調客戶與開發團隊成員的持續溝通，在開發程序中設立一名現場客戶。該現場客戶決 定建立的內容和順序。通過持續重構程式碼並建立最小的非程式碼工件集合而體現簡單。許多短期釋出和持續單元測試建立了反饋機制。勇氣意味著完成正確的事情，即 使並不是最流行的事情。它還意味著誠實面對您能做的和不能做的事情。

12 個 XP 實踐為這四個價值提供支援。它們是：

有計劃的開發：通過結合使用優先順序"故事"和技術估算，確定下一版本的功能。

小版本：以小的增量版本經常向客戶釋出軟體。

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

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

測試：使用者編寫測試內容以對"故事"進行測試。程式設計師編寫測試內容來發現程式碼中的任何問題。在編寫程式碼前先編寫測試內容。

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

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

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

持續整合：每天多次建立和整合系統，只要任何實現任務完成就要進行。

每週 40 個小時：程式設計師在疲勞時無法保證最高效率。連續兩週加班是絕對不允許的。

現場客戶：一名真實的客戶全時工作於開發環境中，幫助定義系統、編寫測試內容並回答問題。

編碼標準：程式設計師採用一致的編碼標準。