項目管理規(guī)范-RUP管理實施（第一部分）
|
|
|
|
項目管理規(guī)范-RUP管理實施（第一部分）
|
|
來自：sawin.com.cn 作者：李杰 [2003/05/12]
|
第一部分：項目階段
第二部分：核心工作流程
第三部分：角色劃分
第四部分：目前實施項目規(guī)范的考慮
概述
軟件開發(fā)的產(chǎn)品質量水平，是一個由來已久的話題。而提高軟件企業(yè)的產(chǎn)品質量水平，必須改進軟件產(chǎn)品的開發(fā)過程。但是這里沒有什么百試百靈的靈丹妙藥，我們必須根據(jù)本企業(yè)的實際情況，參考國內(nèi)外先進企業(yè)的經(jīng)驗，總結出一種適合本企業(yè)的軟件開發(fā)模式。
此規(guī)范是基于CMM模型規(guī)范，以RUP軟件工程過程為藍本，由我本人根據(jù)項目實際情況而選擇修改，從而使之適應當前應用級系統(tǒng)設計開發(fā)的需要。
本文主要以RUP的軟件工程框架為主，省略復雜概念部分。著眼點放在控制軟件產(chǎn)品開發(fā)流程上，由于人員配置與軟件分工現(xiàn)行狀況的限制，對其中的部分細節(jié)進行了合并可省略，從而適應目前國內(nèi)軟件開發(fā)所要求。
Rational Unified Process（簡稱RUP）是一套軟件工程過程（在下面介紹）。
在RUP過程中，我們可以看到它非常強調一點：循環(huán)。
現(xiàn)在我們做的每一個項目都存在不斷變化的問題。用戶需求變化、系統(tǒng)設計變化（可能是需求變化也可能是存在了技術問題）、編碼變化（由測試與復審等環(huán)節(jié)引發(fā)的）等問題困擾著項目進行。解決這些問題的方法就是不斷的循環(huán)。
這個規(guī)范是我根據(jù)自己的觀點整理編寫而成的，有不足之處請指教。
RUP簡介
Rational Unified Process（簡稱RUP）是一套軟件工程過程，主要由Ivar Jacobson的 The Objectory Approch 和 The Rational Approch 發(fā)展而來。同時，它又是文檔化的軟件工程產(chǎn)品，所有RUP 的實施細節(jié)及方法導引均以Web文檔的方式集成在一張光盤上，由Rational公司開發(fā)、維護并銷售，當前版本是RUP2000。RUP又是一套軟件工程方法的框架，各個組織可根據(jù)自身的實際情況，以及項目規(guī)模對RUP進行裁剪和修改，以制定出合乎需要的軟件工程過程。
RUP 吸收了多種開發(fā)模型的優(yōu)點，具有很好的可操作性和實用性、從它一推出市場，憑借Booch、Ivar Jacobson、以及Rumbaugh 在業(yè)界的領導地位、以及與統(tǒng)一建模語言（Unified Model Language , 以下簡稱UML）的良好集成、多種CASE工具的支持、不斷的升級與維護，迅速得到業(yè)界廣泛的認同，越來越多的組織以它作為軟件開發(fā)模型框架。
在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 有明顯的不同。
RUP采用Use Case的概念，把要開發(fā)的系統(tǒng)根據(jù)各功能使用的情況劃分多個Use Case，并采用迭代的思想把系統(tǒng)的風險分布在四個階段，風險越大的迭代越要放在靠前的階段做，使軟件產(chǎn)品的風險不斷降低；而不是像傳統(tǒng)軟件工程那樣越往開發(fā)的后期問題越多。所以RUP的思想一推出就受到軟件企業(yè)的歡迎。按照RUP的開發(fā)模式一般可以達到CMM2、3級的水平。當然，理解和掌握RUP需要一個相對較長的過程。
1. 項目階段
從管理的觀點來說，軟件生命周期隨著時間分為四個依次進行的階段，每個階段的結束都有一個主要里程碑；實質上，每個階段就是兩個主要里程碑之間的時間跨度。在每個階段結束時進行評估，以確定是否實現(xiàn)了此階段的目標。良好的評估可使項目順利進入下一階段。
1.1. 計劃階段
在進度和工作量方面，所有階段都各不相同。盡管不同的項目有很大的不同，但一個中等規(guī)模項目的典型初始開發(fā)周期應該預先考慮到工作量和進度間的分配：
|
|
先啟 |
精化 |
構建 |
產(chǎn)品化 |
|
工作量 |
~5% |
20% |
65% |
10% |
|
進度 |
10% |
30% |
50% |
10% |
可表示為下圖
對于演進周期，先啟和精化階段就小得多了。能夠自動完成某些構建工作的工具將會緩解此現(xiàn)象，并使得構建階段比先啟階段和精化階段的總和還要小很多。
通過這四個階段就是一個開發(fā)周期；每次經(jīng)過這四個階段就會產(chǎn)生一代軟件。除非項目“死亡”，否則通過重復同樣的先啟階段、精化階段、構建階段和產(chǎn)品化階段的順序，產(chǎn)品將演進為下一代產(chǎn)品，但每一次的側重點都將放在不同的階段上。這些隨后的周期稱為演進周期。 隨著產(chǎn)品經(jīng)歷了幾個周期，新一代產(chǎn)品隨之產(chǎn)生。
1.2. 先啟階段
1.2.1. 目標
先啟階段的基本目標是實現(xiàn)項目的生命周期目標中所有相關因素（如客戶等）之間的并行。 先啟階段主要對新的開發(fā)工作具有重大意義，新工作中的重要業(yè)務風險和需求風險問題必須在項目繼續(xù)進行之前得到解決。對于重點是擴展現(xiàn)有系統(tǒng)的項目來說，先啟階段較短，但重點仍然是確保項目值得進行而且可以進行。
先啟階段的主要目標包括：
· 建立項目的軟件規(guī)模和邊界條件，包括運作前景、驗收標準以及希望軟件中包括和不包括的內(nèi)容。
· 識別系統(tǒng)的關鍵用例（也就是將造成重要設計折衷操作的主要部分）。
· 評估整個項目的總體成本和進度（以及對即將進行的精化階段進行更詳細的評估）
· 評估潛在風險（不可預測性的來源）
· 準備項目的支持環(huán)境。
1.2.2. 核心活動
· 明確地說明項目規(guī)模。這涉及了解環(huán)境以及最重要的需求和約束，以便于可以得出最終產(chǎn)品的驗收標準。
· 計劃和準備商業(yè)理由。評估風險管理、人員配備、項目計劃和成本/進度/收益率折衷的備選方案。
· 綜合考慮備選構架，評估設計和自制/外購/復用方面的折衷，從而估算出成本、進度和資源。此處的目標在于通過對一些概念的證實來證明可行性。該證明可采用可模擬需求的模型形式或用于探索被認為高風險區(qū)域的初始原型。先啟階段的原型設計工作應該限制在確信解決方案可行就可以了。該解決方案在精化和構建階段實現(xiàn)。
· 準備項目的環(huán)境，評估項目和組織，選擇工具，決定流程中要改進的部分。
1.2.3. 里程碑：生命周期目標
生命周期目標里程碑評估項目的基本可行性。
先啟階段末是第一個重要的項目里程碑，即生命周期目標里程碑。此時，檢查項目的生命周期目標，并決定繼續(xù)進行項目還是取消項目。
1.2.3.1 評估標準
· 規(guī)模定義和成本／進度估算中，所有相關因素（如客戶等）可并行
· 對是否已經(jīng)獲得正確的需求集達成一致意見，并且對這些需求的理解是共同的。
· 對成本／進度估算、優(yōu)先級、風險和開發(fā)流程是否合適達成一致意見。
· 已經(jīng)確定所有風險并且有針對每個風險的減輕風險策略。
如果項目無法達到該里程碑，則它可能中途失敗或需要進行相當多的重新考慮。
1.2.3.2 提供的文檔及模型
|
核心文檔及模型（按照重要性排序） |
里程碑狀態(tài) |
|
前景 |
已經(jīng)對核心項目的需求、關鍵功能和主要約束進行了記錄。 |
|
商業(yè)理由 |
已經(jīng)確定并得到了批準。 |
|
風險列表 |
已經(jīng)確定了最初的項目風險。 |
|
軟件開發(fā)計劃 |
已經(jīng)確定了最初階段及其持續(xù)時間和目標。軟件開發(fā)計劃中的資源估算（特別是時間、人員和開發(fā)環(huán)境成本）必須與商業(yè)理由一致。
資源估算可以涵蓋整個項目直到交付所需的資源，也可以只包括進行精化階段所需的資源。此時，整個項目所需的資源估算應該看作是大致的“粗略估計”。該估算在每個階段和每次迭代中都會更新，并且隨著每次迭代變得更加準確。 根據(jù)項目的需要，可能在某種條件下完成了一個或多個附帶的“計劃”工件。此外，附帶的“指南”工件通常也至少完成了“草稿”。 |
|
迭代計劃 |
第一個精化迭代的迭代計劃已經(jīng)完成并經(jīng)過了復審。 |
|
軟件驗收計劃 |
完成復審并確定了基線；隨著其他需求的發(fā)現(xiàn)，將對其在隨后的迭代中進行改進。 |
|
項目專用模板 |
已使用文檔模板制作了文檔工件。 |
|
用例建模指南 |
確定了基線。 |
|
工具 |
選擇了支持項目的所有工具。安裝了對先啟階段的工作必要的工具。 |
|
詞匯表 |
已經(jīng)定義了重要的術語；完成了詞匯表的復審。 |
|
用例模型（主角，用例） |
已經(jīng)確定了重要的主角和用例，只為最關鍵的用例簡要說明了事件流。 |
|
領域模型（也叫做業(yè)務對象模型） |
已經(jīng)對系統(tǒng)中使用的核心概念進行了記錄和復審。在核心概念之間存在特定關系的情況下，已用作對詞匯表的補充。 |
|
原型 |
概念原型的一個或多個證據(jù)，以支持前景和商業(yè)理由、解決非常具體的風險。 |
1.3. 精化階段
1.3.1. 目標
精化階段的目標是建立系統(tǒng)構架的基線，以便為構建階段的主要設計和實施工作提供一個穩(wěn)定的基礎。構架是基于對大多數(shù)重要需求（對系統(tǒng)構架有很大影響的需求）的考慮和風險評估發(fā)展而來的。構架的穩(wěn)定性是通過一個或多個構架原型進行評估的。 精化階段的主要目標包括：
確保構架、需求和計劃足夠穩(wěn)定，充分減少風險，從而能夠有預見性地確定完成開發(fā)所需的成本和進度。對大多數(shù)項目來說，通過此里程碑也就相當于從簡單快速的低風險運作轉移到高成本、高風險的運作，并且在組織結構方面面臨許多不利因素。
處理在構架方面具有重要意義的所有項目風險
建立一個已確定基線的構架，它是通過處理構架方面重要的場景得到的，這些場景通?？梢燥@示項目的最大技術風險。
制作產(chǎn)品質量構件的演進式原型，也可能同時制作一個或多個可放棄的探索性原型，以減小特定風險，例如：
設計/需求折衷
構件復用
產(chǎn)品可行性或向客戶和最終用戶進行演示。
證明已建立基線的構架將在適當時間、以合理的成本支持系統(tǒng)需求。
建立支持環(huán)境。
為了實現(xiàn)這個主要目標，建立項目的支持環(huán)境也同等重要。這包括創(chuàng)建開發(fā)案例、創(chuàng)建模板和指南、安裝工具。
1.3.2. 核心活動
· 快速確定構架、確認構架并為構架建立基線。
· 根據(jù)此階段獲得的新信息改進前景，對推動構架和計劃決策的最關鍵用例建立可靠的了解。
· 為構建階段創(chuàng)建詳細的迭代計劃并為其建立基線。
· 改進開發(fā)案例，定位開發(fā)環(huán)境，包括流程和支持構建團隊所需的工具和自動化支持。
· 改進構架并選擇構件。 評估潛在構件，充分了解自制/外購/復用決策，以便有把握地確定構建階段的成本和進度。集成了所選構架構件，并按主要場景進行了評估。通過這些活動得到的經(jīng)驗有可能導致重新設計構架、考慮替代設計或重新考慮需求。
1.3.3. 里程碑：生命周期構架
生命周期構架里程碑為系統(tǒng)構架建立管理基線，并使項目團隊能夠在構建階段調整規(guī)模。
精化階段末是第二個重要的項目里程碑，即生命周期構架里程碑。此時，您檢查詳細的系統(tǒng)目標和規(guī)模、選擇的構架以及主要風險的解決方案。
1.3.3.1 評估標準
· 產(chǎn)品前景和需求是穩(wěn)定的。
· 構架是穩(wěn)定的。
· 可執(zhí)行原型表明已經(jīng)找到了主要的風險元素，并且得到妥善解決。
· 構建階段的迭代計劃足夠詳細和真實，可以保證工作繼續(xù)進行。
· 構建階段的迭代計劃由可靠的估算支持。
· 所有客戶方人員一致認為，如果在當前構架環(huán)境中執(zhí)行當前計劃來開發(fā)完整的系統(tǒng)，則當前的前景可以實現(xiàn)。
· 實際的資源耗費與計劃的耗費相比是可以接受的。
如果項目無法達到該里程碑，則它可能中途失敗或需要進行相當多的重新考慮。
1.3.3.2 提供的文檔及模型
|
核心文檔及模型（按照重要性排序） |
里程碑狀態(tài) |
|
原型 |
已經(jīng)創(chuàng)建了一個或多個可執(zhí)行構架原型，以探索關鍵功能和構架上的重要場景。 |
|
風險列表 |
已經(jīng)進行了更新和復審。 新的風險可能是構架方面的，主要與處理非功能性需求有關。 |
|
項目專用模板 |
已使用文檔模板制作了文檔工件。 |
|
工具 |
已經(jīng)安裝了用于支持精化階段工作的工具。 |
|
軟件構架文檔 |
編寫完成并確定了基線，如果系統(tǒng)是分布式的或必須處理并行問題，則包括構架上重要用例的詳細說明（用例視圖）、關鍵機制和設計元素的標識（邏輯視圖），以及（部署模型的）進程視圖和部署視圖的定義。 |
|
設計模型（和所有組成部分） |
制作完成并確定了基線。已經(jīng)定義了構架方面重要場景的用例實現(xiàn)，并將所需行為分配給了適當?shù)脑O計元素。 已經(jīng)確定了構件并充分理解了自制/外購/復用決策，以便有把握地確定構建階段的成本和進度。集成了所選構架構件，并按主要場景進行了評估。通過這些活動得到的經(jīng)驗有可能導致重新設計構架、考慮替代設計或重新考慮需求。 |
|
數(shù)據(jù)模型 |
制作完成并確定了基線。已經(jīng)確定并復審了主要的數(shù)據(jù)模型元素（例如重要實體、關系和表）。 |
|
實施模型（以及所有組成工件，包括構件） |
已經(jīng)創(chuàng)建了最初結構，確定了主要構件并設計了原型。 |
|
前景 |
已經(jīng)根據(jù)此階段獲得的新信息進行了改進，對推動構架和計劃決策的最關鍵用例建立了可靠的了解。 |
|
軟件開發(fā)計劃 |
已經(jīng)進行了更新和擴展，以便涵蓋構建階段和產(chǎn)品化階段。 |
|
指南，如設計指南和編程指南。 |
使用指南對工作進行了支持。 |
|
迭代計劃 |
已經(jīng)完成并復審了構建階段的迭代計劃。 |
|
用例模型 |
用例模型（大約完成 80%）- 已經(jīng)在用例模型調查中確定了所有用例、確定了所有主角并編寫了大部分用例說明（需求分析）。 |
|
補充規(guī)約 |
已經(jīng)對包括非功能性需求在內(nèi)的補充需求進行了記錄和復審。 |
|
可選 |
里程碑狀態(tài) |
|
商業(yè)理由 |
如果構架調查不涵蓋變更基本項目假設的問題，則已經(jīng)對商業(yè)理由進行了更新。 |
|
分析模型 |
可能作為正式工件進行了開發(fā)；進行了經(jīng)常但不正式的維護，正演進為設計模型的早期版本。 |
|
培訓材料 |
用戶手冊與其他培訓材料。根據(jù)用例進行了初步起草。 如果系統(tǒng)具有復雜的用戶界面，可能需要培訓材料。 |
1.4. 構建階段
1.4.1. 目標
構建階段的目標是闡明剩余的需求，并基于已建立基線的構架完成系統(tǒng)開發(fā)。構建階段從某種意義上來說是一個制造過程，在此過程中，重點在于管理資源和控制操作，以便優(yōu)化成本、進度和質量。從這種意義上說，從先啟和精化階段到構建和產(chǎn)品化階段，管理上的思維定勢經(jīng)歷了從知識產(chǎn)權開發(fā)到可部署產(chǎn)品開發(fā)的轉變。 構建階段的主要目標包括：
· 通過優(yōu)化資源和避免不必要的報廢和返工，使開發(fā)成本降到最低。
· 快速達到足夠好的質量
· 快速完成有用的版本（Alpha 版、Beta 版和其他測試發(fā)布版）
· 完成所有所需功能的分析、開發(fā)和測試。
· 迭代式、遞增式地開發(fā)隨時可以發(fā)布到用戶群的完整產(chǎn)品。這意味著描述剩余的用例和其他需求，充實設計，完成實施，并測試軟件。
· 確定軟件、場地和用戶是否已經(jīng)為部署應用程序作好準備。
· 開發(fā)團隊的工作實現(xiàn)某種程度的并行。 即使是較小的項目，也通常包括可以相互獨立開發(fā)的構件，從而使各團隊之間實現(xiàn)自然的并行（資源允許）。這種并行性可較大幅度地加速開發(fā)活動；但同時也增加了資源管理和工作流程同步的復雜程度。如果要實現(xiàn)任何重要的并行，強壯的構架至關重要。
1.4.2. 核心活動
· 資源管理，控制和流程優(yōu)化
· 完成構件開發(fā)并根據(jù)已定義的評估標準進行測試
· 根據(jù)前景的驗收標準對產(chǎn)品發(fā)布版進行評估。
1.4.3. 里程碑：最初操作性能
最初操作性能里程碑確定產(chǎn)品是否已經(jīng)可以部署到 Beta 測試環(huán)境。
在最初操作性能里程碑，產(chǎn)品隨時可以移交給產(chǎn)品化團隊。此時，已開發(fā)了所有功能，并完成了所有 Alpha 測試（如果有測試）。除了軟件之外，用戶手冊也已經(jīng)完成，而且有對當前發(fā)布版的說明。
1.4.3.1 評估標準
構建階段的評估標準涉及到對以下問題的回答：
· 該產(chǎn)品發(fā)布版是否足夠穩(wěn)定和成熟，可部署在用戶群中？
· 是否已準備好將產(chǎn)品發(fā)布到用戶群？
· 實際的資源耗費與計劃的相比是否仍可以接受？
如果項目無法達到該里程碑，產(chǎn)品化可能要推遲一個發(fā)布版。
1.4.3.2 提供的文檔及模型
|
核心文檔及模型（按照重要性排序） |
里程碑狀態(tài) |
|
“系統(tǒng)” |
可執(zhí)行系統(tǒng)本身隨時可以進行“Beta”測試。 |
|
部署計劃 |
已開發(fā)最初版本、進行了復審并建立了基線。 |
|
實施模型（以及所有組成部分，包括構件） |
對在精化階段創(chuàng)建的模型進行了擴展；構建階段末期完成所有構件的創(chuàng)建。 |
|
測試模型（和所有組成部分） |
為驗證構建階段所創(chuàng)建的可執(zhí)行發(fā)布版而設計并開發(fā)的測試。 |
|
培訓材料 |
用戶手冊與其他培訓材料。根據(jù)用例進行了初步起草。 如果系統(tǒng)具有復雜的用戶界面，可能需要培訓材料。 |
|
迭代計劃 |
已經(jīng)完成并復審了產(chǎn)品化階段的迭代計劃。 |
|
設計模型（和所有組成部分） |
已經(jīng)用新設計元素進行了更新，這些設計元素是在完成所有需求期間確定的。 |
|
項目專用模板 |
已使用文檔模板制作了文檔模板。 |
|
工具 |
已經(jīng)安裝了用于支持構建階段工作的工具。 |
|
數(shù)據(jù)模型 |
已經(jīng)用支持持續(xù)實施所需的所有元素（例如，表、索引、對象關系型映射等）進行了更新 |
|
可選 |
里程碑狀態(tài) |
|
補充規(guī)約 |
已經(jīng)用構建階段發(fā)現(xiàn)的新需求（如果有）進行了更新。 |
|
用例模型（主角，用例） |
已經(jīng)用構建階段發(fā)現(xiàn)的新用例（如果有）進行了更新。 |
1.5. 產(chǎn)品化階段
1.5.1. 目標
產(chǎn)品化階段的重點是確保最終用戶可以使用軟件。產(chǎn)品化階段可跨越幾個迭代，包括測試處于發(fā)布準備中的產(chǎn)品和基于用戶反饋進行較小的調整。在生命周期中的該點處，用戶反饋應主要側重于調整產(chǎn)品、配置、安裝和可用性問題，所有較大的結構上的問題應該在項目生命周期的早期階段就已得到解決。 在產(chǎn)品化階段生命周期結束時，目標應該已經(jīng)實現(xiàn)，項目應處于將結束的狀態(tài)。某些情況下，當前生命周期的結束可能是同一產(chǎn)品另一生命周期的開始，從而導致產(chǎn)生產(chǎn)品的下一代或下一版本。對于其他項目，產(chǎn)品化階段結束時可能就將文檔與模型完全交付給第三方，第三方負責已交付系統(tǒng)的操作、維護和擴展。
根據(jù)產(chǎn)品的種類，產(chǎn)品化階段可能非常簡單，也可能非常復雜。例如，發(fā)布現(xiàn)有桌面產(chǎn)品的新發(fā)布版可能十分簡單，而替換一個國家的航空交通管制系統(tǒng)可能就非常復雜。
產(chǎn)品化階段的迭代期間所進行的活動取決于目標。例如，在進行調試時，實施和測試通常就足夠了。 但是，如果要添加新功能，迭代類似于構建階段中的迭代，需要進行分析設計。
當基線已經(jīng)足夠完善，可以部署到最終用戶領域中時，則進入產(chǎn)品化階段。通常，這要求系統(tǒng)的某個可用部分已經(jīng)達到了可接受的質量級別并完成用戶文檔，從而向用戶的轉移可以為所有方面都帶來積極的結果。
產(chǎn)品化階段的主要目標是：
· 進行 Beta 測試，按用戶的期望確認新系統(tǒng)
· Beta 測試和相對于正在替換的遺留系統(tǒng)的并行操作
· 轉換操作數(shù)據(jù)庫
· 培訓用戶和維護人員
· 市場營銷、進行分發(fā)和向銷售人員進行新產(chǎn)品介紹
· 與部署相關的工程，例如接入、商業(yè)包裝和生產(chǎn)、銷售介紹、現(xiàn)場人員培訓
· 調整活動，如進行調試、性能或可用性的增強
· 根據(jù)產(chǎn)品的完整前景和驗收標準，對部署基線進行的評估
· 實現(xiàn)用戶的自我支持能力
· 在用戶之間達成共識，即部署基線已完成
· 在用戶之間達成共識，即部署基線與前景的評估標準一致
1.5.2. 核心活動
· 執(zhí)行部署計劃
· 對最終用戶支持材料定稿
· 在開發(fā)現(xiàn)場測試可交付產(chǎn)品
· 制作產(chǎn)品發(fā)布版
· 獲得用戶反饋
· 基于反饋調整產(chǎn)品
· 使最終用戶可以使用產(chǎn)品
1.5.3. 里程碑：產(chǎn)品發(fā)布
產(chǎn)品化階段末是第四個重要的項目里程碑，即產(chǎn)品發(fā)布里程碑。此時，您確定是否達到目標，以及是否應該開始另一個開發(fā)周期。有時候，該里程碑可能與下一周期的先啟階段末重合。產(chǎn)品發(fā)布里程碑是項目驗收復審成功完成的結果。
1.5.3.1 評估標準
產(chǎn)品化階段的主要評估標準涉及到對以下問題的回答：
· 用戶是否滿意？
· 實際的資源耗費與計劃的耗費相比是否可以接受？
在產(chǎn)品發(fā)布里程碑處，發(fā)布后的維護周期同時開始。這涉及開始一個新的周期，或某個其他的維護發(fā)布版。
1.5.3.2 提供的文檔及模型
|
核心文檔及模型（按照重要性排序） |
里程碑狀態(tài) |
|
產(chǎn)品工作版本 |
已按照產(chǎn)品需求完成?？蛻魬摽梢允褂米罱K產(chǎn)品。 |
|
發(fā)布說明 |
完成。 |
|
安裝產(chǎn)品與模型 |
完成。 |
|
培訓材料 |
完成，以確?？蛻糇约嚎梢允褂煤途S護產(chǎn)品。 |
|
最終用戶支持材料 |
完成，以確保客戶自己可以使用和維護產(chǎn)品。 |
|
可選 |
里程碑狀態(tài) |
|
測試模型 |
在客戶想要進行現(xiàn)場測試的情況下，可以提供測試模型。 |
|
|
掃碼關注公眾號
溫馨提示：因考試政策、內(nèi)容不斷變化與調整，信管網(wǎng)網(wǎng)站提供的以上信息僅供參考，如有異議，請以權威部門公布的內(nèi)容為準！
信管網(wǎng)致力于為廣大信管從業(yè)人員、愛好者、大學生提供專業(yè)、高質量的課程和服務，解決其考試證書、技能提升和就業(yè)的需求。
信管網(wǎng)軟考課程由信管網(wǎng)依托10年專業(yè)軟考教研傾力打造，官方教材參編作者和資深講師坐鎮(zhèn)，通過深研歷年考試出題規(guī)律與考試大綱，深挖核心知識與高頻考點，為學員考試保駕護航。面授、直播＆錄播，多種班型靈活學習，滿足不同學員考證需求，降低課程學習難度，使學習效果事半功倍。
相關內(nèi)容
分享到微信
考試新手指南
學習計劃攻略
精華備考資料
案例論文干貨
章節(jié)模擬試題
免費試聽課程
考試信息推送