項目管理規範-RUP管理實施

作者：李傑    本文選自：UMLCHINA  2002年03月28日 

第一部分：項目階段 

第二部分：核心工作流程 

第三部分：角色劃分 

第四部分：目前實施項目規範的考慮 

概述

軟體開發的産品品質水準，是一個由來已久的話題。而提高軟體企業的産品品質水準，必須改進軟體産品的開發過程。但是這裡沒有什麼百試百靈的靈丹妙藥，我們必須根據本企業的實際情況，參考國内外先進企業的經驗，總結出一種适合本企業的軟體開發模式。 

此規範是基于CMM模型規範，以RUP軟體工程過程為藍本，由我本人根據項目實際情況而選擇修改，進而使之适應目前應用級系統設計開發的需要。 

本文主要以RUP的軟體工程架構為主，省略複雜概念部分。着眼點放在控制軟體産品開發流程上，由于人員配置與軟體分工現行狀況的限制，對其中的部分細節進行了合并可省略，進而适應目前國内軟體開發所要求。 

Rational Unified Process（簡稱RUP）是一套軟體工程過程（在下面介紹）。 

在RUP過程中，我們可以看到它非常強調一點：循環。 

現在我們做的每一個項目都存在不斷變化的問題。使用者需求變化、系統設計變化（可能是需求變化也可能是存在了技術問題）、編碼變化（由測試與複審等環節引發的）等問題困擾着項目進行。解決這些問題的方法就是不斷的循環。 

這個規範是我根據自己的觀點整理編寫而成的，有不足之處請指教。 

RUP簡介 

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

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

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

如上圖所示，時間維從組織管理的角度描述整個軟體開發生命周期，是RUP的動态組成部分。它可進一步描述為周期（Cycle）、階段（phase）、疊代(Iteration)。 

核心工作流從技術角度描述RUP的靜态組成部分，它可進一步描述為行為（activities）、工作流（workflow）、産品（artifact）、勞工（worker）。 

圖中的陰影部分描述了不同的工作流，在不同的時間段内工作量的不同。值得注意的是，幾乎所有的工作流，在所有的時間段内均有工作量，隻是大小不同而已。這與Waterfall process 有明顯的不同。 

RUP采用Use Case的概念，把要開發的系統根據各功能使用的情況劃分多個Use Case，并采用疊代的思想把系統的風險分布在四個階段，風險越大的疊代越要放在靠前的階段做，使軟體産品的風險不斷降低；而不是像傳統軟體工程那樣越往開發的後期問題越多。是以RUP的思想一推出就受到軟體企業的歡迎。按照RUP的開發模式一般可以達到CMM2、3級的水準。當然，了解和掌握RUP需要一個相對較長的過程。 

1. 項目階段 

從管理的觀點來說，軟體生命周期随着時間分為四個依次進行的階段，每個階段的結束都有一個主要裡程碑；實質上，每個階段就是兩個主要裡程碑之間的時間跨度。在每個階段結束時進行評估，以确定是否實作了此階段的目标。良好的評估可使項目順利進入下一階段。 

1.1. 計劃階段 

在進度和工作量方面，所有階段都各不相同。盡管不同的項目有很大的不同，但一個中等規模項目的典型初始開發周期應該預先考慮到工作量和進度間的配置設定： 

先啟

精化

建構

産品化

工作量

~5 %

20 %

65 %

10%

進度

10 %

30%

50%

可表示為下圖 

對于演進周期，先啟和精化階段就小得多了。能夠自動完成某些建構工作的工具将會緩解此現象，并使得建構階段比先啟階段和精化階段的總和還要小很多。 

通過這四個階段就是一個開發周期；每次經過這四個階段就會産生一代軟體。除非項目“死亡”，否則通過重複同樣的先啟階段、精化階段、建構階段和産品化階段的順序，産品将演進為下一代産品，但每一次的側重點都将放在不同的階段上。這些随後的周期稱為演進周期。 随着産品經曆了幾個周期，新一代産品随之産生。 

1.2. 先啟階段 

1.2.1. 目标 

先啟階段的基本目标是實作項目的生命周期目标中所有相關因素（如客戶等）之間的并行。 先啟階段主要對新的開發工作具有重大意義，新工作中的重要業務風險和需求風險問題必須在項目繼續進行之前得到解決。對于重點是擴充現有系統的項目來說，先啟階段較短，但重點仍然是確定項目值得進行而且可以進行。 

先啟階段的主要目标包括： 

· 建立項目的軟體規模和邊界條件，包括運作前景、驗收标準以及希望軟體中包括和不包括的内容。 

· 識别系統的關鍵用例（也就是将造成重要設計折衷操作的主要部分）。 

· 評估整個項目的總體成本和進度（以及對即将進行的精化階段進行更詳細的評估） 

· 評估潛在風險（不可預測性的來源） 

· 準備項目的支援環境。 

1.2.2. 核心活動 

· 明确地說明項目規模。這涉及了解環境以及最重要的需求和限制，以便于可以得出最終産品的驗收标準。 

· 計劃和準備商業理由。評估風險管理、人員配備、項目計劃和成本/進度/收益率折衷的備選方案。 

· 綜合考慮備選構架，評估設計和自制/外購/複用方面的折衷，進而估算出成本、進度和資源。此處的目标在于通過對一些概念的證明來證明可行性。該證明可采用可模拟需求的模型形式或用于探索被認為高風險區域的初始原型。先啟階段的原型設計工作應該限制在确信解決方案可行就可以了。該解決方案在精化和建構階段實作。 

· 準備項目的環境，評估項目群組織，選擇工具，決定流程中要改進的部分。 

1.2.3. 裡程碑：生命周期目标 

生命周期目标裡程碑評估項目的基本可行性。 

先啟階段末是第一個重要的項目裡程碑，即生命周期目标裡程碑。此時，檢查項目的生命周期目标，并決定繼續進行項目還是取消項目。 

1.2.3.1 評估标準 

· 規模定義和成本／進度估算中，所有相關因素（如客戶等）可并行 

· 對是否已經獲得正确的需求集達成一緻意見，并且對這些需求的了解是共同的。 

· 對成本／進度估算、優先級、風險和開發流程是否合适達成一緻意見。 

· 已經确定所有風險并且有針對每個風險的減輕風險政策。 

如果項目無法達到該裡程碑，則它可能中途失敗或需要進行相當多的重新考慮。 

1.2.3.2 提供的文檔及模型 

核心文檔及模型（按照重要性排序）

裡程碑狀态

前景

已經對核心項目的需求、關鍵功能和主要限制進行了記錄。

商業理由

已經确定并得到了準許。

風險清單

已經确定了最初的項目風險。

軟體開發計劃

已經确定了最初階段及其持續時間和目标。軟體開發計劃中的資源估算（特别是時間、人員和開發環境成本）必須與商業理由一緻。資源估算可以涵蓋整個項目直到傳遞所需的資源，也可以隻包括進行精化階段所需的資源。此時，整個項目所需的資源估算應該看作是大緻的“粗略估計”。該估算在每個階段和每次疊代中都會更新，并且随着每次疊代變得更加準确。 根據項目的需要，可能在某種條件下完成了一個或多個附帶的“計劃”工件。此外，附帶的“指南”工件通常也至少完成了“草稿”。

疊代計劃

第一個精化疊代的疊代計劃已經完成并經過了複審。

軟體驗收計劃

完成複審并确定了基線；随着其他需求的發現，将對其在随後的疊代中進行改進。

項目專用模闆

已使用文檔模闆制作了文檔工件。

用例模組化指南

确定了基線。

工具

選擇了支援項目的所有工具。安裝了對先啟階段的工作必要的工具。

詞彙表

已經定義了重要的術語；完成了詞彙表的複審。

用例模型（主角，用例）

已經确定了重要的主角和用例，隻為最關鍵的用例簡要說明了事件流。

領域模型（也叫做業務對象模型）

已經對系統中使用的核心概念進行了記錄和複審。在核心概念之間存在特定關系的情況下，已用作對詞彙表的補充。

原型

概念原型的一個或多個證據，以支援前景和商業理由、解決非常具體的風險。

1.3. 精化階段 

1.3.1. 目标 

精化階段的目标是建立系統構架的基線，以便為建構階段的主要設計和實施工作提供一個穩定的基礎。構架是基于對大多數重要需求（對系統構架有很大影響的需求）的考慮和風險評估發展而來的。構架的穩定性是通過一個或多個構架原型進行評估的。 

精化階段的主要目标包括： 

確定構架、需求和計劃足夠穩定，充分減少風險，進而能夠有預見性地确定完成開發所需的成本和進度。對大多數項目來說，通過此裡程碑也就相當于從簡單快速的低風險運作轉移到高成本、高風險的運作，并且在組織結構方面面臨許多不利因素。

處理在構架方面具有重要意義的所有項目風險

建立一個已确定基線的構架，它是通過處理構架方面重要的場景得到的，這些場景通常可以顯示項目的最大技術風險。

制作産品品質構件的演進式原型，也可能同時制作一個或多個可放棄的探索性原型，以減小特定風險，例如：

設計/需求折衷

構件複用

産品可行性或向客戶和最終使用者進行示範。

證明已建立基線的構架将在适當時間、以合理的成本支援系統需求。

建立支援環境。

為了實作這個主要目标，建立項目的支援環境也同等重要。這包括建立開發案例、建立模闆和指南、安裝工具。 

1.3.2. 核心活動 

· 快速确定構架、确認構架并為構架建立基線。 

· 根據此階段獲得的新資訊改進前景，對推動構架和計劃決策的最關鍵用例建立可靠的了解。 

· 為建構階段建立詳細的疊代計劃并為其建立基線。 

· 改進開發案例，定位開發環境，包括流程和支援建構團隊所需的工具和自動化支援。 

· 改進構架并選擇構件。 評估潛在構件，充分了解自制/外購/複用決策，以便有把握地确定建構階段的成本和進度。內建了所選構架構件，并按主要場景進行了評估。通過這些活動得到的經驗有可能導緻重新設計構架、考慮替代設計或重新考慮需求。 

1.3.3. 裡程碑：生命周期構架 

生命周期構架裡程碑為系統構架建立管理基線，并使項目團隊能夠在建構階段調整規模。 

精化階段末是第二個重要的項目裡程碑，即生命周期構架裡程碑。此時，您檢查詳細的系統目标和規模、選擇的構架以及主要風險的解決方案。 

1.3.3.1 評估标準 

· 産品前景和需求是穩定的。 

· 構架是穩定的。 

· 可執行原型表明已經找到了主要的風險元素，并且得到妥善解決。 

· 建構階段的疊代計劃足夠詳細和真實，可以保證工作繼續進行。 

· 建構階段的疊代計劃由可靠的估算支援。 

· 所有客戶方人員一緻認為，如果在目前構架環境中執行目前計劃來開發完整的系統，則目前的前景可以實作。 

· 實際的資源耗費與計劃的耗費相比是可以接受的。 

1.3.3.2 提供的文檔及模型 

已經建立了一個或多個可執行構架原型，以探索關鍵功能和構架上的重要場景。

已經進行了更新和複審。 新的風險可能是構架方面的，主要與處理非功能性需求有關。

已經安裝了用于支援精化階段工作的工具。

軟體構架文檔

編寫完成并确定了基線，如果系統是分布式的或必須處理并行問題，則包括構架上重要用例的詳細說明（用例視圖）、關鍵機制和設計元素的辨別（邏輯視圖），以及（部署模型的）程序視圖和部署視圖的定義。

設計模型（和所有組成部分）

制作完成并确定了基線。已經定義了構架方面重要場景的用例實作，并将所需行為配置設定給了适當的設計元素。 已經确定了構件并充分了解了自制/外購/複用決策，以便有把握地确定建構階段的成本和進度。內建了所選構架構件，并按主要場景進行了評估。通過這些活動得到的經驗有可能導緻重新設計構架、考慮替代設計或重新考慮需求。

資料模型

制作完成并确定了基線。已經确定并複審了主要的資料模型元素（例如重要實體、關系和表）。

實施模型（以及所有組成工件，包括構件）

已經建立了最初結構，确定了主要構件并設計了原型。

已經根據此階段獲得的新資訊進行了改進，對推動構架和計劃決策的最關鍵用例建立了可靠的了解。

已經進行了更新和擴充，以便涵蓋建構階段和産品化階段。

指南，如設計指南和程式設計指南。

使用指南對工作進行了支援。

已經完成并複審了建構階段的疊代計劃。

用例模型

用例模型（大約完成 80%）- 已經在用例模型調查中确定了所有用例、确定了所有主角并編寫了大部分用例說明（需求分析）。

補充規約

已經對包括非功能性需求在内的補充需求進行了記錄和複審。

可選

如果構架調查不涵蓋變更基本項目假設的問題，則已經對商業理由進行了更新。

分析模型

可能作為正式工件進行了開發；進行了經常但不正式的維護，正演進為設計模型的早期版本。

教育訓練材料

使用者手冊與其他教育訓練材料。根據用例進行了初步起草。 如果系統具有複雜的使用者界面，可能需要教育訓練材料。

1.4. 建構階段 

1.4.1. 目标 

建構階段的目标是闡明剩餘的需求，并基于已建立基線的構架完成系統開發。建構階段從某種意義上來說是一個制造過程，在此過程中，重點在于管理資源和控制操作，以便優化成本、進度和品質。從這種意義上說，從先啟和精化階段到建構和産品化階段，管理上的思維定勢經曆了從知識産權開發到可部署産品開發的轉變。 

建構階段的主要目标包括： 

· 通過優化資源和避免不必要的報廢和返工，使開發成本降到最低。 

· 快速達到足夠好的品質 

· 快速完成有用的版本（Alpha 版、Beta 版和其他測試釋出版） 

· 完成所有所需功能的分析、開發和測試。 

· 疊代式、遞增式地開發随時可以釋出到使用者群的完整産品。這意味着描述剩餘的用例和其他需求，充實設計，完成實施，并測試軟體。 

· 确定軟體、場地和使用者是否已經為部署應用程式作好準備。 

· 開發團隊的工作實作某種程度的并行。 即使是較小的項目，也通常包括可以互相獨立開發的構件，進而使各團隊之間實作自然的并行（資源允許）。這種并行性可較大幅度地加速開發活動；但同時也增加了資源管理和工作流程同步的複雜程度。如果要實作任何重要的并行，強壯的構架至關重要。 

1.4.2. 核心活動 

· 資源管理，控制和流程優化 

· 完成構件開發并根據已定義的評估标準進行測試 

· 根據前景的驗收标準對産品釋出版進行評估。 

1.4.3. 裡程碑：最初操作性能 

最初操作性能裡程碑确定産品是否已經可以部署到 Beta 測試環境。 

在最初操作性能裡程碑，産品随時可以移交給産品化團隊。此時，已開發了所有功能，并完成了所有 Alpha 測試（如果有測試）。除了軟體之外，使用者手冊也已經完成，而且有對目前釋出版的說明。 

1.4.3.1 評估标準 

建構階段的評估标準涉及到對以下問題的回答： 

· 該産品釋出版是否足夠穩定和成熟，可部署在使用者群中？ 

· 是否已準備好将産品釋出到使用者群？ 

· 實際的資源耗費與計劃的相比是否仍可以接受？ 

如果項目無法達到該裡程碑，産品化可能要推遲一個釋出版。 

1.4.3.2 提供的文檔及模型 

“系統”

可執行系統本身随時可以進行“Beta”測試。

部署計劃

已開發最初版本、進行了複審并建立了基線。

實施模型（以及所有組成部分，包括構件）

對在精化階段建立的模型進行了擴充；建構階段末期完成所有構件的建立。

測試模型（和所有組成部分）

為驗證建構階段所建立的可執行釋出版而設計并開發的測試。

已經完成并複審了産品化階段的疊代計劃。

已經用新設計元素進行了更新，這些設計元素是在完成所有需求期間确定的。

已使用文檔模闆制作了文檔模闆。

已經安裝了用于支援建構階段工作的工具。

已經用支援持續實施所需的所有元素（例如，表、索引、對象關系型映射等）進行了更新

已經用建構階段發現的新需求（如果有）進行了更新。

已經用建構階段發現的新用例（如果有）進行了更新。

1.5. 産品化階段 

1.5.1. 目标 

産品化階段的重點是確定最終使用者可以使用軟體。産品化階段可跨越幾個疊代，包括測試處于釋出準備中的産品和基于使用者回報進行較小的調整。在生命周期中的該點處，使用者回報應主要側重于調整産品、配置、安裝和可用性問題，所有較大的結構上的問題應該在項目生命周期的早期階段就已得到解決。 

在産品化階段生命周期結束時，目标應該已經實作，項目應處于将結束的狀态。某些情況下，目前生命周期的結束可能是同一産品另一生命周期的開始，進而導緻産生産品的下一代或下一版本。對于其他項目，産品化階段結束時可能就将文檔與模型完全傳遞給第三方，第三方負責已傳遞系統的操作、維護和擴充。 

根據産品的種類，産品化階段可能非常簡單，也可能非常複雜。例如，釋出現有桌面産品的新釋出版可能十分簡單，而替換一個國家的航空交通管制系統可能就非常複雜。 

産品化階段的疊代期間所進行的活動取決于目标。例如，在進行調試時，實施和測試通常就足夠了。 但是，如果要添加新功能，疊代類似于建構階段中的疊代，需要進行分析設計。 

當基線已經足夠完善，可以部署到最終使用者領域中時，則進入産品化階段。通常，這要求系統的某個可用部分已經達到了可接受的品質級别并完成使用者文檔，進而向使用者的轉移可以為所有方面都帶來積極的結果。 

産品化階段的主要目标是： 

· 進行 Beta 測試，按使用者的期望确認新系統 

· Beta 測試和相對于正在替換的遺留系統的并行操作 

· 轉換操作資料庫 

· 教育訓練使用者和維護人員 

· 市場營銷、進行分發和向銷售人員進行新産品介紹 

· 與部署相關的工程，例如接入、商業包裝和生産、銷售介紹、現場人員教育訓練 

· 調整活動，如進行調試、性能或可用性的增強 

· 根據産品的完整前景和驗收标準，對部署基線進行的評估 

· 實作使用者的自我支援能力 

· 在使用者之間達成共識，即部署基線已完成 

· 在使用者之間達成共識，即部署基線與前景的評估标準一緻 

1.5.2. 核心活動 

· 執行部署計劃 

· 對最終使用者支援材料定稿 

· 在開發現場測試可傳遞産品 

· 制作産品釋出版 

· 獲得使用者回報 

· 基于回報調整産品 

· 使最終使用者可以使用産品 

1.5.3. 裡程碑：産品釋出 

産品化階段末是第四個重要的項目裡程碑，即産品釋出裡程碑。此時，您确定是否達到目标，以及是否應該開始另一個開發周期。有時候，該裡程碑可能與下一周期的先啟階段末重合。産品釋出裡程碑是項目驗收複審成功完成的結果。 

1.5.3.1 評估标準 

産品化階段的主要評估标準涉及到對以下問題的回答： 

· 使用者是否滿意？ 

· 實際的資源耗費與計劃的耗費相比是否可以接受？ 

在産品釋出裡程碑處，釋出後的維護周期同時開始。這涉及開始一個新的周期，或某個其他的維護釋出版。 

1.5.3.2 提供的文檔及模型 

産品工作版本

已按照産品需求完成。客戶應該可以使用最終産品。

釋出說明

完成。

安裝産品與模型

完成，以確定客戶自己可以使用和維護産品。

最終使用者支援材料

測試模型

在客戶想要進行現場測試的情況下，可以提供測試模型。

2. 核心工作流程 

軟體工程中的工作流程分為兩部分：核心工作流程與核心支援工作流程 

核心工作流程（在項目中的流程） 

業務需求模組化

分析設計

實施

測試

部署

核心支援工作流程（在組織中的流程） 

環境

項目管理

配置與變更管理

2.1. 業務需求模組化 

2.1.1. 目的 

業務模組化的目的在于： 

了解目标組織（将要在其中部署系統的組織）的結構及機制。

了解目标組織中目前存在的問題并确定改進的可能性。

確定客戶、最終使用者和開發人員就目标組織達成共識。

導出支援目标組織所需的系統需求。

為實作這些目标，業務模組化工作流程說明了如何拟定新目标組織的前景，并基于該前景來确定該組織在業務用例模型和業務對象模型中的流程、角色以及職責。 

作為對這些模型的補充，還編寫了以下文檔： 

補充業務規約

2.1.2. 業務模組化工作流程 

2.1.3. 提供的文檔與模型 

商業邏輯模組化（USE CASE）（ROSE）

業務需求說明書（MS WORD）

專業詞彙表（英漢對照）（MS WORD）

風險說明（MS WORD）

複審說明書

2.1.4. 文檔模闆 

參見項目管理規範目錄下業務需求文檔模闆子目錄 

2.2. 分析設計 

2.2.1. 目的 

分析設計的目的在于： 

将業務需求轉換為未來系統的設計。

逐漸開發強壯的系統構架。

使設計适合于實施環境，為提高性能而進行設計。

2.2.2. 分析設計工作流程 

2.2.3. 提供的文檔與模型 

系統總體設計報告（MS WORD）

系統設計模型DOMAIN MODEL（ROSE）

系統設計模型DESIGN MODEL （ROSE）

資料庫設計模型 （POWER DESIGNER）

資料字典（MS WORD）

系統詳細設計報告（MS WORD）

工作量化書（MS WORD）

2.2.4. 文檔模闆 

參見項目管理規範目錄下分析設計文檔模闆子目錄 

2.3. 實施 

2.3.1. 目的 

實施的目的包括： 

對照實施子系統的分層結構定義代碼結構、

以構件（源檔案、二進制檔案、可執行檔案以及其他檔案等）的方式實施類和對象、

對已開發的構件按單元來測試，并且

将各實施員（或團隊）完成的結果內建到可執行系統中。

實施工作流程的範圍僅限于如何對各個類進行單元測試。系統測試和內建測試将在測試工作流程中進行說明。 

測試的目的在于： 

核實對象之間的互動。

核實軟體的所有構件是否正确內建。

核實所有需求是否已經正确實施。

确定缺陷并確定在部署軟體之前将缺陷解決。

2.3.2. 實施工作流程 

2.3.3. 提供的文檔與模型 

實施總結書（MS WORD）

實施模型（ROSE）

系統內建書（MS WORD）

代碼稽核意見書（MS WORD）

源代碼（MS WORD）

使用者使用手冊（MS WORD）

錯誤解決記錄手冊（MS WORD）

構件及其說明

2.3.4. 文檔模闆 

參見項目管理規範目錄下實施文檔模闆子目錄 

2.4. 項目管理 

2.4.1. 目的 

本部分的目标是，通過提供一些項目管理的環境，使這個任務更加容易完成。它雖然不是成功的秘訣，但它介紹了可以顯著提高成功傳遞軟體可能性的項目管理方法。 

項目管理的目的是： 

為對軟體密集型項目進行管理提供架構。

為項目的計劃、人員配備、執行和監測提供實用的準則。

為管理風險提供架構。

該工作流程主要側重于疊代式開發流程的以下重要方面： 

風險管理

計劃疊代式項目，貫穿生命周期并針對特定的疊代

監測疊代式項目的進度、名額

2.4.2. 項目管理工作流程 

2.4.3. 提供的文檔和模闆 

風險管理計劃（MS EXCEL）

工作計劃書（MS EXCEL）

風險清單（MS EXCEL）

疊代計劃（MS EXCEL）

問題解決計劃（MS EXCEL）

測試計劃書（MS EXCEL）

系統內建計劃書（MS EXCEL）

子系統內建計劃書（MS EXCEL）

工作單（MS EXCEL）

産品驗收計劃（MS EXCEL）

評測計劃（MS EXCEL）

項目計劃複審意見書（MS WORD）

開發總結（MS WORD）

2.4.4. 文檔模闆 

參見項目管理規範目錄下項目管理文檔模闆子目錄 

2.5. 部署 

2.5.1. 目的 

部署工作流程用來描述那些為確定最終使用者可以正常使用軟體産品而進行的活動。 

部署工作流程描述了兩種産品部署的模式： 

自定義安裝

通過 Internet 使用軟體

在每個執行個體中，都強調要在開發場所對産品進行測試，并在産品最終釋出之前進行 Beta 測試。 

盡管部署活動主要集中于産品化階段，但在較早的一些階段中也會有一些為部署進行計劃和準備的活動。 

2.5.2. 提供的文檔和模闆 

安裝文檔

<a href="http://www.umlchina.com/" target="_blank"></a>