項目管理規(guī)范-RUP管理實施doc28

項目管理規(guī)范-RUP管理實施第一部分：項目階段

第二部分：核心工作流程

第三部分：角色劃分

第四部分：目前實施項目規(guī)范的考慮概述

軟件開發(fā)的產(chǎn)品質(zhì)量水平，是一個由來已久的話題。而提高軟件企業(yè)的產(chǎn)品質(zhì)量水平，必須改進軟件產(chǎn)品的開發(fā)過程。但是這里沒有什么百試百靈的靈丹妙藥，我們必須根據(jù)本企業(yè)的實際情況，參考國內(nèi)外先進企業(yè)的經(jīng)驗，總結(jié)出一種適合本企業(yè)的軟件開發(fā)模式。

此規(guī)范是基于CMM模型規(guī)范，以RUP軟件工程過程為藍本，由我本人根據(jù)項目實際情況而選擇修改，從而使之適應(yīng)當前應(yīng)用級系統(tǒng)設(shè)計開發(fā)的需要。

本文主要以RUP的軟件工程框架為主，省略復(fù)雜概念部分。著眼點放在控制軟件產(chǎn)品開發(fā)流程上，由于人員配置與軟件分工現(xiàn)行狀況的限制，對其中的部分細節(jié)進行了合并可省略，從而適應(yīng)目前國內(nèi)軟件開發(fā)所要求。

RationalUnifiedProcess（簡稱RUP）是一套軟件工程過程（在下面介紹）。

在RUP過程中，我們可以看到它非常強調(diào)一點：循環(huán)。

現(xiàn)在我們做的每一個項目都存在不斷變化的問題。用戶需求變化、系統(tǒng)設(shè)計變化（可能是需求變化也可能是存在了技術(shù)問題）、編碼變化（由測試與復(fù)審等環(huán)節(jié)引發(fā)的）等問題困擾著項目進行。解決這些問題的方法就是不斷的循環(huán)。

這個規(guī)范是我根據(jù)自己的觀點整理編寫而成的，有不足之處請指教。RUP簡介介

RaatioonallUnnifiiedProocesss（簡簡稱RUUP）是是一套軟軟件工程程過程，主主要由IIvarrJaacobbsonn的TTheObjjecttoryyAppprooch和TTheRattionnalAppprocch發(fā)發(fā)展而來來。同時時，它又又是文檔檔化的軟軟件工程程產(chǎn)品，所所有RUUP的的實施細細節(jié)及方方法導(dǎo)引引均以WWeb文文檔的方方式集成成在一張張光盤上上，由RRatiionaal公司司開發(fā)、維維護并銷銷售，當當前版本本是RUUP20000。RRUP又又是一套套軟件工工程方法法的框架架，各個個組織可可根據(jù)自自身的實實際情況況，以及及項目規(guī)規(guī)模對RRUP進進行裁剪剪和修改改，以制制定出合合乎需要要的軟件件工程過過程。

RRUP吸收了了多種開開發(fā)模型型的優(yōu)點點，具有有很好的的可操作作性和實實用性、從從它一推推出市場場，憑借借Boooch、IIvarrJaacobbsonn、以及及Rummbauugh在業(yè)界界的領(lǐng)導(dǎo)導(dǎo)地位、以以及與統(tǒng)統(tǒng)一建模模語言（UUniffieddMoodellLaanguuagee,以下簡簡稱UMML）的的良好集集成、多多種CAASE工工具的支支持、不不斷的升升級與維維護，迅迅速得到到業(yè)界廣廣泛的認認同，越越來越多多的組織織以它作作為軟件件開發(fā)模模型框架架。

在RRUP中中，軟件件開發(fā)生生命周期期根據(jù)時時間和RRUP的的核心工工作流劃劃分為二二維空間間。如上圖所示示，時間間維從組組織管理理的角度度描述整整個軟件件開發(fā)生生命周期期，是RRUP的的動態(tài)組組成部分分。它可可進一步步描述為為周期（CCyclle）、階階段（pphasse）、迭迭代(IIterratiion))。

核心心工作流流從技術(shù)術(shù)角度描描述RUUP的靜靜態(tài)組成成部分，它它可進一一步描述述為行為為（acctivvitiies）、工工作流（wworkkfloow）、產(chǎn)產(chǎn)品（aartiifacct）、工工人（wworkker）。

圖中的陰影部分描述了不同的工作流，在不同的時間段內(nèi)工作量的不同。值得注意的是，幾乎所有的工作流，在所有的時間段內(nèi)均有工作量，只是大小不同而已。這與Waterfallprocess有明顯的不同。

RUP采用UseCase的概念，把要開發(fā)的系統(tǒng)根據(jù)各功能使用的情況劃分多個UseCase，并采用迭代的思想把系統(tǒng)的風險分布在四個階段，風險越大的迭代越要放在靠前的階段做，使軟件產(chǎn)品的風險不斷降低；而不是像傳統(tǒng)軟件工程那樣越往開發(fā)的后期問題越多。所以RUP的思想一推出就受到軟件企業(yè)的歡迎。按照RUP的開發(fā)模式一般可以達到CMM2、3級的水平。當然，理解和掌握RUP需要一個相對較長的過程。

1.項目階段

從管理的觀點來說，軟件生命周期隨著時間分為四個依次進行的階段，每個階段的結(jié)束都有一個主要里程碑；實質(zhì)上，每個階段就是兩個主要里程碑之間的時間跨度。在每個階段結(jié)束時進行評估，以確定是否實現(xiàn)了此階段的目標。良好的評估可使項目順利進入下一階段。

1.1.計劃階段

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

先啟精化構(gòu)建產(chǎn)品化

工作量~5%20%65%10%

進度10%30%50%10%

可表示為下圖

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

通過這四個階段就是一個開發(fā)周期；每次經(jīng)過這四個階段就會產(chǎn)生一代軟件。除非項目“死亡”，否則通過重復(fù)同樣的先啟階段、精化階段、構(gòu)建階段和產(chǎn)品化階段的順序，產(chǎn)品將演進為下一代產(chǎn)品，但每一次的側(cè)重點都將放在不同的階段上。這些隨后的周期稱為演進周期。隨著產(chǎn)品經(jīng)歷了幾個周期，新一代產(chǎn)品隨之產(chǎn)生。

1.2.先啟階段

1.2.1.目標

先啟階段的基本目標是實現(xiàn)項目的生命周期目標中所有相關(guān)因素（如客戶等）之間的并行。先啟階段主要對新的開發(fā)工作具有重大意義，新工作中的重要業(yè)務(wù)風險和需求風險問題必須在項目繼續(xù)進行之前得到解決。對于重點是擴展現(xiàn)有系統(tǒng)的項目來說，先啟階段較短，但重點仍然是確保項目值得進行而且可以進行。

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

?建立項目的軟件規(guī)模和邊界條件，包括運作前景、驗收標準以及希望軟件中包括和不包括的內(nèi)容。

?識別系統(tǒng)的關(guān)鍵用例（也就是將造成重要設(shè)計折衷操作的主要部分）。

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

?評估潛在風險（不可預(yù)測性的來源）

?準備項目的支持環(huán)境。

1.2.2.核心活動

?明確地說明項目規(guī)模。這涉及了解環(huán)境以及最重要的需求和約束，以便于可以得出最終產(chǎn)品的驗收標準。

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

?綜合考慮備選構(gòu)架，評估設(shè)計和自制/外購/復(fù)用方面的折衷，從而估算出成本、進度和資源。此處的目標在于通過對一些概念的證實來證明可行性。該證明可采用可模擬需求的模型形式或用于探索被認為高風險區(qū)域的初始原型。先啟階段的原型設(shè)計工作應(yīng)該限制在確信解決方案可行就可以了。該解決方案在精化和構(gòu)建階段實現(xiàn)。

?準備項目的環(huán)境，評估項目和組織，選擇工具，決定流程中要改進的部分。

1.2.3.里程碑：生命周期目標

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

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

1.2.3.1評估標準

?規(guī)模定義和成本／進度估算中，所有相關(guān)因素（如客戶等）可并行

?對是否已經(jīng)獲得正確的需求集達成一致意見，并且對這些需求的理解是共同的。

?對成本／進度估算、優(yōu)先級、風險和開發(fā)流程是否合適達成一致意見。

?已經(jīng)確定所有風險并且有針對每個風險的減輕風險策略。

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

1.2.3.2提供的文檔及模型

核心文檔及模型（按照重要性排序）里程碑狀態(tài)

前景已經(jīng)對核心項目的需求、關(guān)鍵功能和主要約束進行了記錄。

商業(yè)理由已經(jīng)確定并得到了批準。

風險列表已經(jīng)確定了最初的項目風險。

軟件開發(fā)計劃已經(jīng)確定了最初階段及其持續(xù)時間和目標。軟件開發(fā)計劃中的資源估算（特別是時間、人員和開發(fā)環(huán)境成本）必須與商業(yè)理由一致。

資源估算可以涵蓋整個項目直到交付所需的資源，也可以只包括進行精化階段所需的資源。此時，整個項目所需的資源估算應(yīng)該看作是大致的“粗略估計”。該估算在每個階段和每次迭代中都會更新，并且隨著每次迭代變得更加準確。根據(jù)項目的需要，可能在某種條件下完成了一個或多個附帶的“計劃”工件。此外，附帶的“指南”工件通常也至少完成了“草稿”。

迭代計劃第一個精化迭代的迭代計劃已經(jīng)完成并經(jīng)過了復(fù)審。

軟件驗收計劃完成復(fù)審并確定了基線；隨著其他需求的發(fā)現(xiàn)，將對其在隨后的迭代中進行改進。

項目專用模板已使用文檔模板制作了文檔工件。

用例建模指南確定了基線。

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

詞匯表已經(jīng)定義了重要的術(shù)語；完成了詞匯表的復(fù)審。

用例模型（主角，用例）已經(jīng)確定了重要的主角和用例，只為最關(guān)鍵的用例簡要說明了事件流。

領(lǐng)域模型（也叫做業(yè)務(wù)對象模型）已經(jīng)對系統(tǒng)中使用的核心概念進行了記錄和復(fù)審。在核心概念之間存在特定關(guān)系的情況下，已用作對詞匯表的補充。

原型概念原型的一個或多個證據(jù)，以支持前景和商業(yè)理由、解決非常具體的風險。

1.3.精化階段

1.3.1.目標

精化階段的目標是建立系統(tǒng)構(gòu)架的基線，以便為構(gòu)建階段的主要設(shè)計和實施工作提供一個穩(wěn)定的基礎(chǔ)。構(gòu)架是基于對大多數(shù)重要需求（對系統(tǒng)構(gòu)架有很大影響的需求）的考慮和風險評估發(fā)展而來的。構(gòu)架的穩(wěn)定性是通過一個或多個構(gòu)架原型進行評估的。精化階段的主要目標包括：

確保構(gòu)架、需求和計劃足夠穩(wěn)定，充分減少風險，從而能夠有預(yù)見性地確定完成開發(fā)所需的成本和進度。對大多數(shù)項目來說，通過此里程碑也就相當于從簡單快速的低風險運作轉(zhuǎn)移到高成本、高風險的運作，并且在組織結(jié)構(gòu)方面面臨許多不利因素。

處理在構(gòu)架方面具有重要意義的所有項目風險

建立一個已確定基線的構(gòu)架，它是通過處理構(gòu)架方面重要的場景得到的，這些場景通?？梢燥@示項目的最大技術(shù)風險。

制作產(chǎn)品質(zhì)量構(gòu)件的演進式原型，也可能同時制作一個或多個可放棄的探索性原型，以減小特定風險，例如：

設(shè)計/需求折衷

構(gòu)件復(fù)用

產(chǎn)品可行性或向客戶和最終用戶進行演示。

證明已建立基線的構(gòu)架將在適當時間、以合理的成本支持系統(tǒng)需求。

建立支持環(huán)境。

為了實現(xiàn)這個主要目標，建立項目的支持環(huán)境也同等重要。這包括創(chuàng)建開發(fā)案例、創(chuàng)建模板和指南、安裝工具。

1.3.2.核心活動

?快速確定構(gòu)架、確認構(gòu)架并為構(gòu)架建立基線。

?根據(jù)此階段獲得的新信息改進前景，對推動構(gòu)架和計劃決策的最關(guān)鍵用例建立可靠的了解。

?為構(gòu)建階段創(chuàng)建詳細的迭代計劃并為其建立基線。

?改進開發(fā)案例，定位開發(fā)環(huán)境，包括流程和支持構(gòu)建團隊所需的工具和自動化支持。

?改進構(gòu)架并選擇構(gòu)件。評估潛在構(gòu)件，充分了解自制/外購/復(fù)用決策，以便有把握地確定構(gòu)建階段的成本和進度。集成了所選構(gòu)架構(gòu)件，并按主要場景進行了評估。通過這些活動得到的經(jīng)驗有可能導(dǎo)致重新設(shè)計構(gòu)架、考慮替代設(shè)計或重新考慮需求。

1.3.3.里程碑：生命周期構(gòu)架

生命周期構(gòu)架里程碑為系統(tǒng)構(gòu)架建立管理基線，并使項目團隊能夠在構(gòu)建階段調(diào)整規(guī)模。

精化階段末是第二個重要的項目里程碑，即生命周期構(gòu)架里程碑。此時，您檢查詳細的系統(tǒng)目標和規(guī)模、選擇的構(gòu)架以及主要風險的解決方案。

1.3.3.1評估標準

?產(chǎn)品前景和需求是穩(wěn)定的。

?構(gòu)架是穩(wěn)定的。

?可執(zhí)行原型表明已經(jīng)找到了主要的風險元素，并且得到妥善解決。

?構(gòu)建階段的迭代計劃足夠詳細和真實，可以保證工作繼續(xù)進行。

?構(gòu)建階段的迭代計劃由可靠的估算支持。

?所有客戶方人員一致認為，如果在當前構(gòu)架環(huán)境中執(zhí)行當前計劃來開發(fā)完整的系統(tǒng)，則當前的前景可以實現(xiàn)。

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

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

1.3.3.2提供的文檔及模型

核心文檔及模型（按照重要性排序）里程碑狀態(tài)

原型已經(jīng)創(chuàng)建了一個或多個可執(zhí)行構(gòu)架原型，以探索關(guān)鍵功能和構(gòu)架上的重要場景。

風險列表已經(jīng)進行了更新和復(fù)審。新的風險可能是構(gòu)架方面的，主要與處理非功能性需求有關(guān)。

項目專用模板已使用文檔模板制作了文檔工件。

工具已經(jīng)安裝了用于支持精化階段工作的工具。

軟件構(gòu)架文檔編寫完成并確定了基線，如果系統(tǒng)是分布式的或必須處理并行問題，則包括構(gòu)架上重要用例的詳細說明（用例視圖）、關(guān)鍵機制和設(shè)計元素的標識（邏輯視圖），以及（部署模型的）進程視圖和部署視圖的定義。

設(shè)計模型（和所有組成部分）制作完成并確定了基線。已經(jīng)定義了構(gòu)架方面重要場景的用例實現(xiàn)，并將所需行為分配給了適當?shù)脑O(shè)計元素。已經(jīng)確定了構(gòu)件并充分理解了自制/外購/復(fù)用決策，以便有把握地確定構(gòu)建階段的成本和進度。集成了所選構(gòu)架構(gòu)件，并按主要場景進行了評估。通過這些活動得到的經(jīng)驗有可能導(dǎo)致重新設(shè)計構(gòu)架、考慮替代設(shè)計或重新考慮需求。

數(shù)據(jù)模型制作完成并確定了基線。已經(jīng)確定并復(fù)審了主要的數(shù)據(jù)模型元素（例如重要實體、關(guān)系和表）。

實施模型（以及所有組成工件，包括構(gòu)件）已經(jīng)創(chuàng)建了最初結(jié)構(gòu)，確定了主要構(gòu)件并設(shè)計了原型。

前景已經(jīng)根據(jù)此階段獲得的新信息進行了改進，對推動構(gòu)架和計劃決策的最關(guān)鍵用例建立了可靠的了解。

軟件開發(fā)計劃已經(jīng)進行了更新和擴展，以便涵蓋構(gòu)建階段和產(chǎn)品化階段。

指南，如設(shè)計指南和編程指南。使用指南對工作進行了支持。

迭代計劃已經(jīng)完成并復(fù)審了構(gòu)建階段的迭代計劃。

用例模型用例模型（大約完成80%）-已經(jīng)在用例模型調(diào)查中確定了所有用例、確定了所有主角并編寫了大部分用例說明（需求分析）。

補充規(guī)約已經(jīng)對包括非功能性需求在內(nèi)的補充需求進行了記錄和復(fù)審。

可選里程碑狀態(tài)

商業(yè)理由如果構(gòu)架調(diào)查不涵蓋變更基本項目假設(shè)的問題，則已經(jīng)對商業(yè)理由進行了更新。

分析模型可能作為正式工件進行了開發(fā)；進行了經(jīng)常但不正式的維護，正演進為設(shè)計模型的早期版本。

培訓材料用戶手冊與其他培訓材料。根據(jù)用例進行了初步起草。如果系統(tǒng)具有復(fù)雜的用戶界面，可能需要培訓材料。

1.4.構(gòu)建階段

1.4.1.目標

構(gòu)建階段的目標是闡明剩余的需求，并基于已建立基線的構(gòu)架完成系統(tǒng)開發(fā)。構(gòu)建階段從某種意義上來說是一個制造過程，在此過程中，重點在于管理資源和控制操作，以便優(yōu)化成本、進度和質(zhì)量。從這種意義上說，從先啟和精化階段到構(gòu)建和產(chǎn)品化階段，管理上的思維定勢經(jīng)歷了從知識產(chǎn)權(quán)開發(fā)到可部署產(chǎn)品開發(fā)的轉(zhuǎn)變。構(gòu)建階段的主要目標包括：

?通過優(yōu)化資源和避免不必要的報廢和返工，使開發(fā)成本降到最低。

?快速達到足夠好的質(zhì)量

?快速完成有用的版本（Alpha版、Beta版和其他測試發(fā)布版）

?完成所有所需功能的分析、開發(fā)和測試。

?迭代式、遞增式地開發(fā)隨時可以發(fā)布到用戶群的完整產(chǎn)品。這意味著描述剩余的用例和其他需求，充實設(shè)計，完成實施，并測試軟件。

?確定軟件、場地和用戶是否已經(jīng)為部署應(yīng)用程序作好準備。

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

1.4.2.核心活動

?資源管理，控制和流程優(yōu)化

?完成構(gò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評估標準

構(gòu)建階段的評估標準涉及到對以下問題的回答：

?該產(chǎn)品發(fā)布版是否足夠穩(wěn)定和成熟，可部署在用戶群中？

?是否已準備好將產(chǎn)品發(fā)布到用戶群？

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

如果項目無法達到該里程碑，產(chǎn)品化可能要推遲一個發(fā)布版。

1.4.3.2提供的文檔及模型

核心文檔及模型（按照重要性排序）里程碑狀態(tài)

“系統(tǒng)”可執(zhí)行系統(tǒng)本身隨時可以進行“Beta”測試。

部署計劃已開發(fā)最初版本、進行了復(fù)審并建立了基線。

實施模型（以及所有組成部分，包括構(gòu)件）對在精化階段創(chuàng)建的模型進行了擴展；構(gòu)建階段末期完成所有構(gòu)件的創(chuàng)建。

測試模型（和所有組成部分）為驗證構(gòu)建階段所創(chuàng)建的可執(zhí)行發(fā)布版而設(shè)計并開發(fā)的測試。

培訓材料用戶手冊與其他培訓材料。根據(jù)用例進行了初步起草。如果系統(tǒng)具有復(fù)雜的用戶界面，可能需要培訓材料。

迭代計劃已經(jīng)完成并復(fù)審了產(chǎn)品化階段的迭代計劃。

設(shè)計模型（和所有組成部分）已經(jīng)用新設(shè)計元素進行了更新，這些設(shè)計元素是在完成所有需求期間確定的。

項目專用模板已使用文檔模板制作了文檔模板。

工具已經(jīng)安裝了用于支持構(gòu)建階段工作的工具。

數(shù)據(jù)模型已經(jīng)用支持持續(xù)實施所需的所有元素（例如，表、索引、對象關(guān)系型映射等）進行了更新

可選里程碑狀態(tài)

補充規(guī)約已經(jīng)用構(gòu)建階段發(fā)現(xiàn)的新需求（如果有）進行了更新。

用例模型（主角，用例）已經(jīng)用構(gòu)建階段發(fā)現(xiàn)的新用例（如果有）進行了更新。

1.5.產(chǎn)品化階段

1.5.1.目標

產(chǎn)品化階段的重點是確保最終用戶可以使用軟件。產(chǎn)品化階段可跨越幾個迭代，包括測試處于發(fā)布準備中的產(chǎn)品和基于用戶反饋進行較小的調(diào)整。在生命周期中的該點處，用戶反饋應(yīng)主要側(cè)重于調(diào)整產(chǎn)品、配置、安裝和可用性問題，所有較大的結(jié)構(gòu)上的問題應(yīng)該在項目生命周期的早期階段就已得到解決。在產(chǎn)品化階段生命周期結(jié)束時，目標應(yīng)該已經(jīng)實現(xiàn)，項目應(yīng)處于將結(jié)束的狀態(tài)。某些情況下，當前生命周期的結(jié)束可能是同一產(chǎn)品另一生命周期的開始，從而導(dǎo)致產(chǎn)生產(chǎn)品的下一代或下一版本。對于其他項目，產(chǎn)品化階段結(jié)束時可能就將文檔與模型完全交付給第三方，第三方負責已交付系統(tǒng)的操作、維護和擴展。

根據(jù)產(chǎn)品的種類，產(chǎn)品化階段可能非常簡單，也可能非常復(fù)雜。例如，發(fā)布現(xiàn)有桌面產(chǎn)品的新發(fā)布版可能十分簡單，而替換一個國家的航空交通管制系統(tǒng)可能就非常復(fù)雜。

產(chǎn)品化階段的迭代期間所進行的活動取決于目標。例如，在進行調(diào)試時，實施和測試通常就足夠了。但是，如果要添加新功能，迭代類似于構(gòu)建階段中的迭代，需要進行分析設(shè)計。

當基線已經(jīng)足夠完善，可以部署到最終用戶領(lǐng)域中時，則進入產(chǎn)品化階段。通常，這要求系統(tǒng)的某個可用部分已經(jīng)達到了可接受的質(zhì)量級別并完成用戶文檔，從而向用戶的轉(zhuǎn)移可以為所有方面都帶來積極的結(jié)果。

產(chǎn)品化階段的主要目標是：

?進行Beta測試，按用戶的期望確認新系統(tǒng)

?Beta測試和相對于正在替換的遺留系統(tǒng)的并行操作

?轉(zhuǎn)換操作數(shù)據(jù)庫

?培訓用戶和維護人員

?市場營銷、進行分發(fā)和向銷售人員進行新產(chǎn)品介紹

?與部署相關(guān)的工程，例如接入、商業(yè)包裝和生產(chǎn)、銷售介紹、現(xiàn)場人員培訓

?調(diào)整活動，如進行調(diào)試、性能或可用性的增強

?根據(jù)產(chǎn)品的完整前景和驗收標準，對部署基線進行的評估

?實現(xiàn)用戶的自我支持能力

?在用戶之間達成共識，即部署基線已完成

?在用戶之間達成共識，即部署基線與前景的評估標準一致

1.5.2.核心活動

?執(zhí)行部署計劃

?對最終用戶支持材料定稿

?在開發(fā)現(xiàn)場測試可交付產(chǎn)品

?制作產(chǎn)品發(fā)布版

?獲得用戶反饋

?基于反饋調(diào)整產(chǎn)品

?使最終用戶可以使用產(chǎn)品

1.5.3.里程碑：產(chǎn)品發(fā)布

產(chǎn)品化階段末是第四個重要的項目里程碑，即產(chǎn)品發(fā)布里程碑。此時，您確定是否達到目標，以及是否應(yīng)該開始另一個開發(fā)周期。有時候，該里程碑可能與下一周期的先啟階段末重合。產(chǎn)品發(fā)布里程碑是項目驗收復(fù)審成功完成的結(jié)果。

1.5.3.1評估標準

產(chǎn)品化階段的主要評估標準涉及到對以下問題的回答：

?用戶是否滿意？

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

在產(chǎn)品發(fā)布里程碑處，發(fā)布后的維護周期同時開始。這涉及開始一個新的周期，或某個其他的維護發(fā)布版。

1.5.3.2提供的文檔及模型

核心文檔及模型（按照重要性排序）里程碑狀態(tài)

產(chǎn)品工作版本已按照產(chǎn)品需求完成?？蛻魬?yīng)該可以使用最終產(chǎn)品。

發(fā)布說明完成。

安裝產(chǎn)品與模型完成。

培訓材料完成，以確?？蛻糇约嚎梢允褂煤途S護產(chǎn)品。

最終用戶支持材料完成，以確保客戶自己可以使用和維護產(chǎn)品。

可選里程碑狀態(tài)

測試模型在客戶想要進行現(xiàn)場測試的情況下，可以提供測試模型。2.核心心工作流流程

軟軟件工程程中的工工作流程程分為兩兩部分：：核心工工作流程程與核心心支持工工作流程程核心心工作流流程（在在項目中中的流程程）

??業(yè)務(wù)務(wù)需求建建模

??分析析設(shè)計

?實實施

??測試試

?部署

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

??環(huán)境境

?項目管管理

??配置置與變更更管理

22.1..業(yè)務(wù)務(wù)需求建建模

2..1.11.目目的

業(yè)務(wù)務(wù)建模的的目的在在于：

??了解解目標組組織（將將要在其其中部署署系統(tǒng)的的組織）的的結(jié)構(gòu)及及機制。

?了解目標組織中當前存在的問題并確定改進的可能性。

?確?？蛻?、最終用戶和開發(fā)人員就目標組織達成共識。

?導(dǎo)出支持目標組織所需的系統(tǒng)需求。

為實現(xiàn)這些目標，業(yè)務(wù)建模工作流程說明了如何擬定新目標組織的前景，并基于該前景來確定該組織在業(yè)務(wù)用例模型和業(yè)務(wù)對象模型中的流程、角色以及職責。

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

?補充業(yè)務(wù)規(guī)約

?詞匯表

2.1.2.業(yè)務(wù)建模工作流程

2.1.3.提供的文檔與模型

?商業(yè)邏輯建模（USECASE）（ROSE）

?業(yè)務(wù)需求說明書（MSWORD）

?專業(yè)詞匯表（英漢對照）（MSWORD）

?風險說明（MSWORD）

?復(fù)審說明書

2.1.4.文檔模板

參見項目管理規(guī)范目錄下業(yè)務(wù)需求文檔模板子目錄

2.2.分析設(shè)計

2.2.1.目的

分析設(shè)計的目的在于：

?將業(yè)務(wù)需求轉(zhuǎn)換為未來系統(tǒng)的設(shè)計。

?逐步開發(fā)強壯的系統(tǒng)構(gòu)架。

?使設(shè)計適合于實施環(huán)境，為提高性能而進行設(shè)計。

2.2.2.分析設(shè)計工作流程

2.2.3.提供的文檔與模型

?系統(tǒng)總體設(shè)計報告（MSWORD）

?系統(tǒng)設(shè)計模型DOMAINMODEL（ROSE）

?系統(tǒng)設(shè)計模型DESIGNMODEL（ROSE）

?數(shù)據(jù)庫設(shè)計模型（POWERDESIGNER）

?數(shù)據(jù)字典（MSWORD）

?系統(tǒng)詳細設(shè)計報告（MSWORD）

?工作量化書（MSWORD）

2.2.4.文檔模板

參見項目管理規(guī)范目錄下分析設(shè)計文檔模板子目錄

2.3.實施

2.3.1.目的

實施的目的包括：

?對照實施子系統(tǒng)的分層結(jié)構(gòu)定義代碼結(jié)構(gòu)、

?以構(gòu)件（源文件、二進制文件、可執(zhí)行文件以及其他文件等）的方式實施類和對象、

?對已開發(fā)的構(gòu)件按單元來測試，并且

?將各實施員（或團隊）完成的結(jié)果集成到可執(zhí)行系統(tǒng)中。

實施工作流程的范圍僅限于如何對各個類進行單元測試。系統(tǒng)測試和集成測試將在測試工作流程中進行說明。

測試的目的在于：

?核實對象之間的交互。

?核實軟件的所有構(gòu)件是否正確集成。

?核實所有需求是否已經(jīng)正確實施。

?確定缺陷并確保在部署軟件之前將缺陷解決。

2.3.2.實施工作流程

2.3.3.提供的文檔與模型

?實施總結(jié)書（MSWORD）

?實施模型（ROSE）

?系統(tǒng)集成書（MSWORD）

?代碼審核意見書（MSWORD）

?源代碼（MSWORD）

?用戶使用手冊（MSWORD）

?錯誤解決記錄手冊（MSWORD）

?構(gòu)件及其說明

2.3.4.文檔模板

參見項目管理規(guī)范目錄下實施文檔模板子目錄

2.4.項目管理

2.4.1.目的

本部分的目標是，通過提供一些項目管理的環(huán)境，使這個任務(wù)更加容易完成。它雖然不是成功的秘訣，但它介紹了可以顯著提高成功交付軟件可能性的項目管理方法。

項目管理的目的是：

?為對軟件密集型項目進行管理提供框架。

?為項目的計劃、人員配備、執(zhí)行和監(jiān)測提供實用的準則。

?為管理風險提供框架。

該工作流程主要側(cè)重于迭代式開發(fā)流程的以下重要方面：

?風險管理

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

?監(jiān)測迭代式項目的進度、指標

2.4.2.項目管理工作流程

2.4.3.提供的文檔和模板

?風險管理計劃（MSEXCEL）

?工作計劃書（MSEXCEL）

?風險列表（MSEXCEL）

?迭代計劃（MSEXCEL）

?問題解決計劃（MSEXCEL）

?測試計劃書（MSEXCEL）

?系統(tǒng)集成計劃書（MSEXCEL）

?子系統(tǒng)集成計劃書（MSEXCEL）

?工作單（MSEXCEL）

?產(chǎn)品驗收計劃（MSEXCEL）

?評測計劃（MSEXCEL）

?項目計劃復(fù)審意見書（MSWORD）

?開發(fā)總結(jié)（MSWORD）

2.4.4.文檔模板

參見項目管理規(guī)范目錄下項目管理文檔模板子目錄

2.5.部署

2.5.1.目的

部署工作流程用來描述那些為確保最終用戶可以正常使用軟件產(chǎn)品而進行的活動。

部署工作流程描述了兩種產(chǎn)品部署的模式：

?自定義安裝

?通過Internet使用軟件

在每個實例中，都強調(diào)要在開發(fā)場所對產(chǎn)品進行測試，并在產(chǎn)品最終發(fā)布之前進行Beta測試。

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

2.5.2.提供的文檔和模板

?部署計劃

?安裝文檔

?發(fā)布說明3.角色色劃分

角角色是抽抽象的職職責定義義，它定定義的是是所執(zhí)行行的一組組活動和和所擁有有的一組組文檔與與模型。

角色通常由一個人或作為團隊相互協(xié)作的多個人來實現(xiàn)。

項目團隊成員通常要履行許多不同的角色職能；就象一個人可以擔任許多職務(wù)，一個人也可以擔任許多不同的角色。

角色并不代表個人，而是說明個人在業(yè)務(wù)中應(yīng)該如何表現(xiàn)以及他們應(yīng)該承擔的責任。

分析員角色集

分析員角色集用于組織主要從事需求獲取和研究的各種角色。

角色

?業(yè)務(wù)流程分析員

?業(yè)務(wù)設(shè)計員

?業(yè)務(wù)模型復(fù)審員

?需求復(fù)審員

?系統(tǒng)分析員

?用戶界面設(shè)計員

3.1.1.業(yè)務(wù)流程分析員

業(yè)務(wù)流程分析員通過概括和界定作為建模對象的組織來領(lǐng)導(dǎo)和協(xié)調(diào)業(yè)務(wù)用例建模。例如，確定存在哪些業(yè)務(wù)主角和業(yè)務(wù)用例，他們之間如何進行交互。

人員配備

擔任業(yè)務(wù)流程分析員的人員應(yīng)該善于簡化工作，并且具有良好的溝通技巧。擔任此角色的人員中必須要有具備業(yè)務(wù)領(lǐng)域知識的人才，但這種知識并不是所有人都必備的。

業(yè)務(wù)流程分析員應(yīng)該準備好開展以下工作：

?評估將在其中部署項目最終產(chǎn)品的目標組織的情況。

?了解客戶與用戶的需求、策略和目標。

?協(xié)調(diào)目標組織的建模工作。

?在必要時對業(yè)務(wù)工程工作進行討論和協(xié)調(diào)。

?對目標組織中所建議的任何變更進行成本效益分析。

3.1.2.業(yè)務(wù)設(shè)計員

業(yè)務(wù)設(shè)計員通過描述一個或幾個業(yè)務(wù)用例的工作流程來詳細說明組織中某一部分的規(guī)約。他指定實現(xiàn)業(yè)務(wù)用例所需的業(yè)務(wù)角色及業(yè)務(wù)實體，并且將業(yè)務(wù)用例的行為分配給這些業(yè)務(wù)角色及業(yè)務(wù)實體。業(yè)務(wù)設(shè)計員定義一個或幾個業(yè)務(wù)角色和業(yè)務(wù)實體的責任、操作、屬性和關(guān)系。

人員配備

擔任業(yè)務(wù)設(shè)計員的人員應(yīng)該善于協(xié)調(diào)，并且具有良好的溝通技巧。他最好具有業(yè)務(wù)領(lǐng)域的知識，但這并不是擔任此角色的所有人都必需的。業(yè)務(wù)設(shè)計員需要熟悉用于獲取業(yè)務(wù)模型的工具。

3.1.3.業(yè)務(wù)模型復(fù)審員

業(yè)務(wù)模型復(fù)審員參與對業(yè)務(wù)用例模型和業(yè)務(wù)對象模型的正式復(fù)審。

人員配備

在大多數(shù)情況下，擔任業(yè)務(wù)模型復(fù)審員的人員都需要具備業(yè)務(wù)領(lǐng)域的基本知識，或者對將用來實現(xiàn)業(yè)務(wù)自動化的技術(shù)具備基本的知識。業(yè)務(wù)模型復(fù)審員應(yīng)該具備的另一種技能是詳細了解所應(yīng)用的業(yè)務(wù)工程技術(shù)。

3.1.4.系統(tǒng)分析員

系統(tǒng)分析員通過概括系統(tǒng)的功能和界定系統(tǒng)來領(lǐng)導(dǎo)和協(xié)調(diào)需求獲取及用例建模。例如，確定存在哪些主角和用例，以及他們之間如何交互。

人員配備

擔任系統(tǒng)分析員的人員應(yīng)該善于協(xié)調(diào)，并且具有良好的溝通技巧。擔任此角色的人員中必須要有具備業(yè)務(wù)和技術(shù)領(lǐng)域知識的人才，但這些知識并不是所有人都必須具備的。

3.1.5.用戶界面設(shè)計員

用戶界面設(shè)計員通過以下方法領(lǐng)導(dǎo)和協(xié)調(diào)用戶界面的原型設(shè)計和正式設(shè)計：

?分析對用戶界面的需求，包括可用性需求；

?構(gòu)建用戶界面原型；

?邀請用戶界面的最終用戶參與可用性復(fù)審和使用測試會議；

?對用戶界面的最終實施方案（由設(shè)計員和實施員等其他開發(fā)人員創(chuàng)建）進行復(fù)審并提供相應(yīng)的反饋。

人員配備

用戶界面設(shè)計員不應(yīng)實施用戶界面。用戶界面設(shè)計員的工作重點和時間都應(yīng)集中在用戶界面的設(shè)計和“可視化成形”，原因如下：

?用戶界面設(shè)計員所需的技能通常需要為當前的項目和應(yīng)用程序類型（可能具有獨特的可用性需求）而加以改進和優(yōu)化，這需要投入時間并集中工作重點。

?應(yīng)該限制因“一心二用”而帶來的風險，即用戶界面設(shè)計員不應(yīng)該因為實施方面的考慮（相對于可用性方面的考慮而言）而受到過多的影響。

3.2.開發(fā)角色集

開發(fā)人員角色集用于組織主要從事軟件設(shè)計與開發(fā)的各種角色。

角色

?構(gòu)架設(shè)計師

?構(gòu)架復(fù)審員

?代碼復(fù)審員

?數(shù)據(jù)庫設(shè)計員

?系統(tǒng)設(shè)計員

?設(shè)計復(fù)審員

?實施員

?集成員

3.2.1.構(gòu)架設(shè)計師

構(gòu)架設(shè)計師負責在整個項目中對技術(shù)活動和工件進行領(lǐng)導(dǎo)和協(xié)調(diào)。構(gòu)架設(shè)計師要確立每個構(gòu)架視圖的整體結(jié)構(gòu)：視圖的詳細組織結(jié)構(gòu)、元素的分組以及這些主要分組之間的接口。因此，與其他角色相比，構(gòu)架設(shè)計師的見解重在廣度，而不是深度。

人員配備

構(gòu)架設(shè)計師必須多才多藝、成熟練達、洞察力強、經(jīng)驗豐富。這樣，他才能在無法獲得完整信息的情況下迅速領(lǐng)會問題并根據(jù)經(jīng)驗作出審慎的判斷。更準確地說，構(gòu)架設(shè)計師（或者構(gòu)架團隊的成員）必須兼具以下技能：

?經(jīng)驗：既包括在問題領(lǐng)域的經(jīng)驗（通過徹底了解需求），也包括在軟件工程領(lǐng)域的經(jīng)驗。對于一個構(gòu)架團隊，這些素質(zhì)要求可由各團隊成員來分別承擔，但其中至少要有一名構(gòu)架設(shè)計師能夠把握項目的全局。

?領(lǐng)導(dǎo)才能：能夠推動各個團隊的技術(shù)進展，并能在壓力下作出關(guān)鍵性的決策然后將其貫徹到底。要提高效率，構(gòu)架設(shè)計師和項目經(jīng)理必須緊密協(xié)作。構(gòu)架設(shè)計師主要負責解決技術(shù)問題，項目經(jīng)理主要負責解決行政管理問題。構(gòu)架設(shè)計師必須有權(quán)在技術(shù)問題上作出決定。

?溝通：能夠贏得他人的信任，以對其進行說服、激勵和指導(dǎo)。構(gòu)架設(shè)計師不能靠命令進行領(lǐng)導(dǎo)，而必須要贏得項目中其他人員的贊同。為了提高效率，構(gòu)架設(shè)計師必須贏得項目團隊、項目經(jīng)理、客戶、用戶群體以及管理團隊的尊敬。

?以目標為中心、積極主動，不懈地追求成效。構(gòu)架設(shè)計師是推動項目發(fā)展的技術(shù)動力，而不是空想家。在其職業(yè)生涯中，成功的構(gòu)架設(shè)計師一直都要在捉摸不定和承受壓力的情況下作出折衷決定。構(gòu)架設(shè)計師只有將注意力集中在該做的事情上，才能在項目中取得成功。

從專業(yè)角度看，構(gòu)架設(shè)計師必須具備系統(tǒng)設(shè)計員的所有能力。

團隊。如果項目較大，需要組建一個構(gòu)架團隊，則應(yīng)盡量廣聚賢才，使該團隊既擁有廣泛的經(jīng)驗，又對軟件工程流程具有一致的認識。構(gòu)架團隊不應(yīng)該是由各團隊、領(lǐng)域或承包商的代表組成的委員會。軟件構(gòu)架設(shè)計是一項長期的工作，始終都需要配備專職人員。

3.2.2.構(gòu)架復(fù)審員

一般而言，構(gòu)架復(fù)審員負責計劃并執(zhí)行對軟件構(gòu)架的正式復(fù)審。

人員配備

構(gòu)架復(fù)審員角色的人員配備要求與構(gòu)架設(shè)計師的人員配備要求相同，但前者更加注重于技術(shù)問題。雖然對領(lǐng)導(dǎo)才能、成熟程度、實用主義及注重結(jié)果這些方面的重視程度稍低，但這些方面仍然重要：復(fù)審員可能會發(fā)現(xiàn)構(gòu)架方面的缺陷，并且有可能會因為影響項目的進度而不受歡迎。盡管如此，最好還是在問題可以解決的時候及早提出關(guān)鍵性的問題，而不是盲目地追隨進度，致使項目團隊步入歧途。構(gòu)架復(fù)審員需要根據(jù)成本對風險加以權(quán)衡，并對影響項目成功的概括性問題保持一定的敏感性。構(gòu)架復(fù)審員還需是善于說服的溝通者，他應(yīng)該能夠提出并討論對他人來說比較敏感的問題。

3.2.3.代碼復(fù)審員

代碼復(fù)審員負責確保源代碼的質(zhì)量，并且計劃和執(zhí)行源代碼復(fù)審。在復(fù)審活動中，代碼復(fù)審員還負責有關(guān)返工的任何反饋意見。

3.2.4.數(shù)據(jù)庫設(shè)計人員

數(shù)據(jù)庫設(shè)計員定義表、索引、視圖、約束條件、觸發(fā)器、存儲過程、表空間或存儲參數(shù)，以及其他在存儲、檢索和刪除永久性對象時所需的數(shù)據(jù)庫專用結(jié)構(gòu)。相關(guān)信息記錄在數(shù)據(jù)模型中。

人員配備

數(shù)據(jù)庫設(shè)計員必須在以下方面具有扎實的應(yīng)用知識：

?數(shù)據(jù)庫和面向?qū)ο蟮姆治鲈O(shè)計技術(shù)

?系統(tǒng)構(gòu)架，包括數(shù)據(jù)庫和系統(tǒng)性能調(diào)整，以及硬件和網(wǎng)絡(luò)負載平衡

?數(shù)據(jù)庫管理

?了解實施語言和環(huán)境

3.2.5.系統(tǒng)設(shè)計員

設(shè)計員定義一個或幾個類的職責、操作、屬性及關(guān)系，并確定應(yīng)如何根據(jù)實施環(huán)境對它們加以調(diào)整。此外，設(shè)計員可能要負責一個或多個設(shè)計包或設(shè)計子系統(tǒng)，其中包括設(shè)計包或子系統(tǒng)所擁有的所有類。

人員配備

設(shè)計員必須在以下方面具有扎實的應(yīng)用知識：

?用例建模技術(shù)。

?系統(tǒng)需求。

?軟件設(shè)計技術(shù)，包括：

o面向?qū)ο蟮姆治鲈O(shè)計技術(shù)。

o統(tǒng)一建模語言。

?實施系統(tǒng)時將利用的技術(shù)。

3.2.6.設(shè)計復(fù)審員

設(shè)計復(fù)審員計劃并進行設(shè)計模型的正式復(fù)審。

人員配備

設(shè)計復(fù)審員的人員配備要求與構(gòu)架設(shè)計師的人員配備要求相同，但前者更加側(cè)重于技術(shù)問題。雖然對領(lǐng)導(dǎo)才能、成熟程度、實用主義及注重結(jié)果這些方面的重視程度稍低，但這些方面仍然重要：復(fù)審員可能會發(fā)現(xiàn)設(shè)計方面的缺陷，并且有可能會因為影響項目的進度而不受歡迎。盡管如此，最好還是在問題可以解決的時候及早提出關(guān)鍵性的問題，而不是盲目地追隨進度，致使項目團隊步入歧途。設(shè)計復(fù)審員需要根據(jù)風險對成本加以權(quán)衡，并對影響項目成功的概括性問題保持一定的敏感性。設(shè)計復(fù)審員還需是一個善說服的溝通者，他應(yīng)該能夠提出并討論對他人來說比較敏感的問題。

從技術(shù)知識的觀點來看，設(shè)計復(fù)審員應(yīng)該具有與設(shè)計員相同經(jīng)驗。

3.2.7.實施員（程序員）

實施員負責按照項目所采用的標準來進行構(gòu)件開發(fā)與測試，以便將構(gòu)件集成到更大的子系統(tǒng)中。如果必須創(chuàng)建驅(qū)動程序或樁模塊等測試構(gòu)件來支持測試，那么實施員還要負責開發(fā)和測試這些測試構(gòu)件及相應(yīng)的子系統(tǒng)。

人員配備

實施員應(yīng)具備的相應(yīng)技能和知識包括：

?了解系統(tǒng)或所測試的應(yīng)用程序

?熟悉測試及測試自動化工具

?編程技能

建議負責實施子系統(tǒng)的實施員同時應(yīng)負責該子系統(tǒng)所包含的構(gòu)件。

3.2.8.集成員

實施員將經(jīng)測試的構(gòu)件交付到集成工作區(qū)，由集成員在集成工作區(qū)將構(gòu)件組合起來，生成一個工作版本。集成員還負責制定集成計劃。集成在子系統(tǒng)和系統(tǒng)級別進行，每次集成均有獨立的集成工作區(qū)。正如經(jīng)測試的構(gòu)件從實施員的專用開發(fā)工作區(qū)交付到子系統(tǒng)集成工作區(qū)一樣，已集成的實施子系統(tǒng)也從子系統(tǒng)集成工作區(qū)交付到系統(tǒng)集成工作區(qū)。

人員配備

有時，