第一篇：軟件項(xiàng)目流程規(guī)范

軟件項(xiàng)目開發(fā) 過程管理

姓名：李長(zhǎng)璽 學(xué)號(hào)：S314080098

（一）項(xiàng)目實(shí)施方案概述

軟件產(chǎn)品，特別是行業(yè)解決方案軟件產(chǎn)品不同于一般的商品，用戶購買軟件產(chǎn)品之后，不能立即進(jìn)行使用，需要軟件公司的技術(shù)人員在軟件技術(shù)、軟件功能、軟件操作等方面進(jìn)行系統(tǒng)調(diào)試、軟件功能實(shí)現(xiàn)、人員培訓(xùn)、軟件上線使用、后期維護(hù)等一系列的工作，我們將這一系列的工作稱為軟件項(xiàng)目實(shí)施。大量的軟件公司項(xiàng)目實(shí)施案例證明，軟件項(xiàng)目是否成功、用戶的軟件使用情況是否順利、是否提高了用戶的工作效率和管理水平，不僅取決于軟件產(chǎn)品本身的質(zhì)量，軟件項(xiàng)目實(shí)施的質(zhì)量效果也對(duì)后期用戶應(yīng)用的情況起到非常重要的影響。項(xiàng)目實(shí)施規(guī)范主要包括項(xiàng)目啟動(dòng)階段、需求調(diào)研確認(rèn)階段、軟件功能實(shí)現(xiàn)確認(rèn)階段、數(shù)據(jù)標(biāo)準(zhǔn)化初裝階段、系統(tǒng)培訓(xùn)階段、系統(tǒng)安裝測(cè)試及試運(yùn)行階段、總體驗(yàn)收階段、系統(tǒng)交接階段等八個(gè)階段工作內(nèi)容，每個(gè)階段下面有不同的工作事項(xiàng)，各個(gè)階段之間都是承上啟下關(guān)系，上一階段的順利完成是保證下一階段的工作開展的基礎(chǔ)。軟件開發(fā)計(jì)劃的目的是收集控制項(xiàng)目時(shí)所需的所有信息，項(xiàng)目經(jīng)理根據(jù)項(xiàng)目計(jì)劃來安排資源需求并根據(jù)時(shí)間表跟蹤項(xiàng)目進(jìn)度。項(xiàng)目團(tuán)隊(duì)成員根據(jù)項(xiàng)目計(jì)劃以了解他們的工作任務(wù)、工作時(shí)間以及他們所依賴的其他活動(dòng)。項(xiàng)目管理培訓(xùn)可將計(jì)劃分成總體計(jì)劃和詳細(xì)計(jì)劃，總體計(jì)劃中每個(gè)任務(wù)為一個(gè)里程碑，詳細(xì)計(jì)劃中必須將任務(wù)落實(shí)到個(gè)人。軟件開發(fā)計(jì)劃還應(yīng)包括產(chǎn)品的應(yīng)收標(biāo)準(zhǔn)及應(yīng)收任務(wù)（包括確定需要制訂的測(cè)試用例）。下面將按照每個(gè)項(xiàng)目實(shí)施階段分別介紹。

（二）項(xiàng)目實(shí)施方案介紹

1、項(xiàng)目啟動(dòng)階段

此階段處于整個(gè)項(xiàng)目實(shí)施工作的最前期，由成立項(xiàng)目組、前期調(diào)研、編制總體項(xiàng)目計(jì)劃、啟動(dòng)會(huì)四個(gè)階段組成。

公司：在合同簽定后，指定項(xiàng)目經(jīng)理，成立項(xiàng)目組，授權(quán)項(xiàng)目組織完成項(xiàng)目目標(biāo)。公司項(xiàng)目組：進(jìn)行前期項(xiàng)目調(diào)研，與用戶共同成立項(xiàng)目實(shí)施組織，編制《總體項(xiàng)目計(jì)劃》，召開項(xiàng)目啟動(dòng)會(huì)。商務(wù)經(jīng)理：配合公司項(xiàng)目組，將積累的項(xiàng)目和用戶信息轉(zhuǎn)交給項(xiàng)目組。將項(xiàng)目組正式介紹給用戶，配合項(xiàng)目組建立與用戶的聯(lián)系。用戶：成立項(xiàng)目實(shí)施組織，配合前期調(diào)研和召開啟動(dòng)會(huì)，簽署《總體項(xiàng)目計(jì)劃》和《項(xiàng)目實(shí)施協(xié)議》。

成立項(xiàng)目組：

部門經(jīng)理接到實(shí)施申請(qǐng)后，任命項(xiàng)目經(jīng)理，指定項(xiàng)目目標(biāo)，由部門經(jīng)理及項(xiàng)目經(jīng)理一起指定項(xiàng)目組成員及成員任務(wù)，并報(bào)總經(jīng)理簽署《項(xiàng)目任務(wù)書》，并制定初步方案。

前期調(diào)研：

項(xiàng)目經(jīng)理及項(xiàng)目組成員，在商務(wù)人員配合下，建立與用戶的聯(lián)系，對(duì)合同、用戶進(jìn)行調(diào)研。填寫《用戶及合同信息表》。在項(xiàng)目商務(wù)談判中，商務(wù)經(jīng)理積累了大量的信息，項(xiàng)目組首先應(yīng)收集商務(wù)和合同信息，并與商務(wù)經(jīng)理一起識(shí)別那些個(gè)體和組織是項(xiàng)目的干系人，確定他們的需求和期望，如何滿足和影響這些需求、期望以確保項(xiàng)目能夠成功。

編制《項(xiàng)目總體計(jì)劃》：

《項(xiàng)目總體計(jì)劃》是一個(gè)文件或文件的集合，隨著項(xiàng)目信息不斷豐富和變化，會(huì)被不斷變更，主要介紹項(xiàng)目目標(biāo)、主要項(xiàng)目階段、里程碑、可交付成果。通常包括以下幾方面內(nèi)容：項(xiàng)目描述，項(xiàng)目目標(biāo)、主要項(xiàng)目階段、里程碑、可交付成果。所計(jì)劃的職責(zé)分配（包括用戶的）；溝通管理計(jì)劃，確定項(xiàng)目干系人對(duì)信息和溝通的需要：即什么人何時(shí)需要什么信息以及通過什么方式將信息提供給他們。質(zhì)量管理計(jì)劃，確定適合于項(xiàng)目的質(zhì)量標(biāo)準(zhǔn)和如何滿足其要求。如果有必要，可以包括上述每一個(gè)計(jì)劃，詳細(xì)程度根據(jù)每個(gè)具體項(xiàng)目的要求而定。未解決事宜和未定的決策。

啟動(dòng)會(huì)：

項(xiàng)目組與用戶共同召開的宣布項(xiàng)目實(shí)施正式開始的會(huì)議。會(huì)程安排如下：共同組建項(xiàng)目實(shí)施組織，實(shí)施組織的權(quán)利和職責(zé)；雙方簽署《項(xiàng)目實(shí)施協(xié)議》。項(xiàng)目組介紹《項(xiàng)目總體計(jì)劃》和《項(xiàng)目實(shí)施協(xié)議》，包括以下內(nèi)容：項(xiàng)目目標(biāo)、主要項(xiàng)目階段、里程碑、可交付成果。所計(jì)劃的職責(zé)分配（包括用戶的）；項(xiàng)目實(shí)施中項(xiàng)目管理的必要性和如何進(jìn)行項(xiàng)目管理，項(xiàng)目的質(zhì)量如何控制；項(xiàng)目實(shí)施中用戶的參與和領(lǐng)導(dǎo)的支持的重要作用；階段驗(yàn)收、技術(shù)交接和項(xiàng)目結(jié)束后如何對(duì)用戶提供后續(xù)服務(wù)。

2、需求調(diào)研確認(rèn)階段

此階段的主要工作是軟件公司的項(xiàng)目實(shí)施人員向用戶調(diào)查用戶對(duì)系統(tǒng)的需求，包括管理流程調(diào)研、功能需求調(diào)研、報(bào)表要求調(diào)研、查詢需求調(diào)研等，實(shí)施人員調(diào)研完成后，會(huì)編寫《需求調(diào)研分析手冊(cè)》，并交付用戶進(jìn)行確認(rèn)，待用戶對(duì)《需求調(diào)研分析手冊(cè)》上所提到的需求確認(rèn)完畢后，項(xiàng)目實(shí)施人員將以此為依據(jù)進(jìn)行軟件功能的實(shí)現(xiàn)。如果用戶又提出新的需求，實(shí)施人員將分析需求的難度及對(duì)整個(gè)系統(tǒng)的影響程度來確定是否給予實(shí)現(xiàn)。需求調(diào)研階段具體包括如下內(nèi)容：

1、進(jìn)行需求調(diào)研準(zhǔn)備

2、編制《需求調(diào)研計(jì)劃》

3、內(nèi)部評(píng)審是否通過《需求調(diào)研計(jì)劃》，項(xiàng)目組、部門經(jīng)理、商務(wù)等人員根據(jù)合同要求和項(xiàng)目實(shí)際情況對(duì)《需求調(diào)研計(jì)劃》草稿進(jìn)行評(píng)審，如評(píng)審?fù)ㄟ^，則在稍后的時(shí)間內(nèi)簽署，如評(píng)審不通過則重新修改。

4、用戶是否簽署《需求調(diào)研計(jì)劃》，如用戶簽署《需求調(diào)研計(jì)劃》，則作為以后需求調(diào)研工作的指南。否則重新修改。

5、《需求調(diào)研計(jì)劃》是否有變更，如果計(jì)劃存在變更，則執(zhí)行變更控制流程，否則按計(jì)劃進(jìn)行后續(xù)工作。

6、編寫及發(fā)出《需求調(diào)研通知》，項(xiàng)目組編寫《需求調(diào)研通知》，確定進(jìn)行需求調(diào)研的相關(guān)事宜，發(fā)給用戶，為順利完成需求調(diào)研工作做準(zhǔn)備。

7、需求調(diào)研，項(xiàng)目組以《需求調(diào)研手冊(cè)》為依據(jù)，從業(yè)務(wù)流程、單據(jù)使用、打印格式、報(bào)表查詢幾個(gè)方面展開深入和全面的調(diào)研，并搜集用戶的個(gè)性化需求。

8、需求調(diào)研分析根據(jù)調(diào)研的結(jié)果，項(xiàng)目組和公司其他技術(shù)部門將進(jìn)一步進(jìn)行分析，確定合理、可行的需求，將分析結(jié)果形成《需求分析報(bào)告》草稿。

9、內(nèi)部評(píng)審是否通過《需求分析報(bào)告》。項(xiàng)目組、部門經(jīng)理、公司其他技術(shù)部門的人員對(duì)《需求分析報(bào)告》草稿進(jìn)行評(píng)審，如評(píng)審?fù)ㄟ^，則在稍后由用戶簽署，如評(píng)審不通過則重新修改，直至內(nèi)部評(píng)審?fù)ㄟ^。

10、編寫及發(fā)出《需求分析報(bào)告確認(rèn)通知》。項(xiàng)目組編寫《需求分析報(bào)告確認(rèn)通知》，發(fā)給用戶，確定進(jìn)行需求確認(rèn)的相關(guān)事宜，告之相關(guān)部門及人員安排好工作，準(zhǔn)時(shí)參與需求確認(rèn)工作，為順利完成需求確認(rèn)工作做準(zhǔn)備。

11、用戶是否確認(rèn)《需求分析報(bào)告》。如果用戶確認(rèn)，并簽署了《需求分析報(bào)告》，則需求調(diào)研階段工作結(jié)束，進(jìn)行后續(xù)的軟件功能實(shí)現(xiàn)的工作；如沒有確認(rèn)，則進(jìn)一步進(jìn)行調(diào)研、分析，直至用戶最終確認(rèn)并簽署《需求分析報(bào)告》。雙方簽署了《需求分析報(bào)告》，需求調(diào)研工作結(jié)束之后，如果用戶提出新的需求或是變更已有的需求，則執(zhí)行需求新增及變更流程。

3、軟件功能實(shí)現(xiàn)確認(rèn)階段

此階段的主要工作是項(xiàng)目實(shí)施人員根據(jù)需求調(diào)研階段確認(rèn)的《需求調(diào)研分析手冊(cè)》中的用戶需求內(nèi)容進(jìn)行具體軟件功能的實(shí)現(xiàn)工作。在軟件功能實(shí)現(xiàn)的過程中，項(xiàng)目實(shí)施人員將記錄軟件實(shí)現(xiàn)的詳細(xì)過程。便于公司售后服務(wù)之用。每一個(gè)實(shí)施技術(shù)人員必須嚴(yán)格按照要求記錄、存檔。按照調(diào)研要求的所有功能實(shí)現(xiàn)完畢后，項(xiàng)目實(shí)施人員將編制《軟件功能確認(rèn)表》，將定制好軟件功能待用戶確認(rèn)，用戶根據(jù)《軟件功能確認(rèn)表》上的功能逐一確定軟件功能是否達(dá)到要求，對(duì)不滿足要求的功能，項(xiàng)目實(shí)施人員將會(huì)記錄下來并進(jìn)行功能修改，直到滿足用于要求。

4、數(shù)據(jù)標(biāo)準(zhǔn)化初裝階段

此階段的主要工作是項(xiàng)目實(shí)施人員指導(dǎo)用戶進(jìn)行系統(tǒng)標(biāo)準(zhǔn)化資料的準(zhǔn)備工作，并對(duì)用戶進(jìn)行初裝資料的軟件操作培訓(xùn)，以便用戶能夠及時(shí)的將標(biāo)準(zhǔn)資料錄入系統(tǒng)，初裝完成后，項(xiàng)目實(shí)施人員會(huì)對(duì)資料初裝的情況進(jìn)行核查，為以后具體業(yè)務(wù)功能的開展做好基礎(chǔ)。

5、系統(tǒng)培訓(xùn)階段

系統(tǒng)培訓(xùn)階段工作是整個(gè)項(xiàng)目實(shí)施工作中比較重要的工作，用戶對(duì)軟件的操作功能是否熟練將直接影響到后面的軟件應(yīng)用效果，所以軟件公司和用戶雙方要對(duì)此階段的工作給予足夠的重視。要充分認(rèn)識(shí)培訓(xùn)的重要性和艱巨性。在項(xiàng)目實(shí)施之前對(duì)用戶的相關(guān)人員進(jìn)行系統(tǒng)和規(guī)范的產(chǎn)品培訓(xùn)是非常必要的，達(dá)到讓用戶了解軟件產(chǎn)品，最終自己能夠解決使用中的具體的問題。

此階段的培訓(xùn)工作中將用戶參加產(chǎn)品培訓(xùn)的人員劃分為三個(gè)層次：決策層、技術(shù)層、操作層，對(duì)不同層次的用戶參加產(chǎn)品培訓(xùn)人員的培訓(xùn)內(nèi)容分別是：決策層：領(lǐng)導(dǎo)在實(shí)施中的作用與重要性、決策查詢。維護(hù)層：系統(tǒng)維護(hù)知識(shí)、操作方法。操作層：操作方法。具體的培訓(xùn)工作流程為：

1、調(diào)研培訓(xùn)信息：在培訓(xùn)開始前3天由用戶實(shí)施負(fù)責(zé)人，將參加培訓(xùn)的部門和人員情況填入《受訓(xùn)部門匯總表》、《受訓(xùn)人員情況一覽表》。

2、編制培訓(xùn)計(jì)劃：結(jié)合調(diào)研結(jié)果，與用戶實(shí)施負(fù)責(zé)人商議具體培訓(xùn)內(nèi)容、時(shí)間，場(chǎng)地，人員等。項(xiàng)目組編制《培訓(xùn)計(jì)劃》。

3、簽署培訓(xùn)計(jì)劃：用戶簽署《培訓(xùn)計(jì)劃》，進(jìn)一步確認(rèn)培訓(xùn)安排。

4、發(fā)培訓(xùn)通知：培訓(xùn)開始前2天，按照簽署的《培訓(xùn)計(jì)劃》，將培訓(xùn)內(nèi)容、時(shí)間，場(chǎng)地，人員等信息通知用戶實(shí)施負(fù)責(zé)人。

5、搭建培訓(xùn)環(huán)境：公司項(xiàng)目組在培訓(xùn)開始前，將培訓(xùn)環(huán)境搭建及檢查妥當(dāng)，將培訓(xùn)提綱及培訓(xùn)手冊(cè)準(zhǔn)備好。

6、組織培訓(xùn)：公司項(xiàng)目組培訓(xùn)負(fù)責(zé)人與用戶實(shí)施負(fù)責(zé)人組織相關(guān)人員參加培訓(xùn)，按培訓(xùn)制度嚴(yán)格考核。由用戶將考勤情況填入《培訓(xùn)人員簽到表》。

7、培訓(xùn)考核：公司項(xiàng)目組培訓(xùn)負(fù)責(zé)人與用戶實(shí)施負(fù)責(zé)人組織受訓(xùn)人員參加上機(jī)及理論考試。

8、培訓(xùn)總結(jié)：公司項(xiàng)目組培訓(xùn)負(fù)責(zé)人與用戶實(shí)施負(fù)責(zé)人一起將出勤情況及考核情況做出總結(jié)，填入《培訓(xùn)及考核統(tǒng)計(jì)表》，及時(shí)向相關(guān)負(fù)責(zé)人匯報(bào)。

6、系統(tǒng)安裝測(cè)試及試運(yùn)行階段

此階段的主要工作是在用戶真實(shí)環(huán)境下，對(duì)用戶網(wǎng)絡(luò)及硬件設(shè)備進(jìn)行測(cè)試，對(duì)軟件系統(tǒng)進(jìn)行容量、性能壓力等測(cè)試測(cè)試及試運(yùn)行的目的在于確保系統(tǒng)各項(xiàng)功能均能正常使用，并且符合用戶簽署的《需求分析報(bào)告》中描述的需求，同時(shí)把盡可能多的潛在問題在正式運(yùn)行之前發(fā)現(xiàn)并改正；同時(shí)目的還在于在正式運(yùn)行前用戶的有關(guān)人員能進(jìn)一步提高操作水平，掌握操作規(guī)范。此階段的主要工作內(nèi)容為：

1、編制計(jì)劃：與用戶實(shí)施負(fù)責(zé)人商議具體測(cè)試及試運(yùn)行時(shí)間、地點(diǎn)、人員等安排，項(xiàng)目組編制《測(cè)試及試運(yùn)行計(jì)劃》。

2、簽署計(jì)劃：用戶簽署《測(cè)試及試運(yùn)行計(jì)劃》，進(jìn)一步確認(rèn)測(cè)試及試運(yùn)行安排。

3、發(fā)測(cè)試及試運(yùn)行通知：在測(cè)試及試運(yùn)行開始前2天，按照簽署的《測(cè)試及試運(yùn)行計(jì)劃》，將時(shí)間，地點(diǎn)，人員等信息通知用戶實(shí)施負(fù)責(zé)人。

4、搭建環(huán)境及數(shù)據(jù)準(zhǔn)備：在試運(yùn)行開始前搭建好軟件環(huán)境、硬件環(huán)境、網(wǎng)絡(luò)環(huán)境、調(diào)通線路；檢查軟件、硬件、網(wǎng)絡(luò)、線路等各個(gè)環(huán)節(jié)是否有問題；

5、組織測(cè)試及試運(yùn)行：用戶相關(guān)各級(jí)領(lǐng)導(dǎo)給予全面配合，組織相關(guān)人員進(jìn)行測(cè)試及試運(yùn)行。公司項(xiàng)目組負(fù)責(zé)擔(dān)當(dāng)指揮，檢查用戶人員組織情況并給予指導(dǎo)，跟蹤檢查如下情況：跟蹤單據(jù)流轉(zhuǎn)狀況；跟蹤新資料登錄環(huán)節(jié)；觀察業(yè)務(wù)流程執(zhí)行狀況；觀察操作人員操作表現(xiàn)；觀察系統(tǒng)運(yùn)行速度及異常表現(xiàn)；觀察關(guān)鍵數(shù)據(jù)的正確性；及時(shí)糾正錯(cuò)誤操作、對(duì)于新發(fā)生的問題及時(shí)與相關(guān)人員溝通，確定解決辦法。

6、測(cè)試及試運(yùn)行總結(jié)：測(cè)試及試運(yùn)行完成，總結(jié)試運(yùn)行中設(shè)備、軟件的運(yùn)行情況，總結(jié)試運(yùn)行中業(yè)務(wù)流程和操作環(huán)節(jié)的情況，以書面總結(jié)形式將測(cè)試及試運(yùn)行結(jié)果通知相關(guān)負(fù)責(zé)人。

7、總體驗(yàn)收階段

此階段是對(duì)項(xiàng)目總體的完成情況進(jìn)行驗(yàn)收。驗(yàn)收分階段進(jìn)行，在每一項(xiàng)目階段結(jié)束時(shí)，用戶對(duì)這一階段的可交付成果進(jìn)行驗(yàn)收，在測(cè)試及試運(yùn)行結(jié)束后，對(duì)系統(tǒng)進(jìn)行總體驗(yàn)收。需要驗(yàn)收的可交付成果：主要項(xiàng)目階段組成，主要里程碑可交付成果。

8、系統(tǒng)交接階段 此階段是項(xiàng)目實(shí)施的最后一個(gè)階段，主要工作是軟件公司項(xiàng)目組向用戶移交軟件項(xiàng)目，包括軟件產(chǎn)品、項(xiàng)目實(shí)施過程中所生成的各種文檔，并簽署《售后服務(wù)協(xié)議》，項(xiàng)目將進(jìn)入售后服務(wù)階段。軟件公司項(xiàng)目組還需要讓用戶填寫《用戶滿意度調(diào)查表》，對(duì)軟件公司項(xiàng)目實(shí)施人員的整個(gè)項(xiàng)目實(shí)施情況進(jìn)行評(píng)價(jià)，軟件公司將聽取用戶的意見，再今后的項(xiàng)目實(shí)施管理中進(jìn)行加強(qiáng)和改進(jìn)。

下圖是整體開發(fā)過程：

第二篇：軟件項(xiàng)目開發(fā)管理流程

研發(fā)中心項(xiàng)目開發(fā)管理流程

1，新項(xiàng)目開發(fā)管理流程

按照項(xiàng)目管理規(guī)范，項(xiàng)目管理分為：項(xiàng)目啟動(dòng)—》項(xiàng)目計(jì)劃—》項(xiàng)目執(zhí)行—》項(xiàng)目控制—》項(xiàng)目結(jié)尾。5個(gè)階段。根據(jù)該管理流程和我公司實(shí)際情況，將新項(xiàng)目開發(fā)的管理流程制定如下圖：

1.1 項(xiàng)目立項(xiàng)

項(xiàng)目立項(xiàng)階段，首先由的項(xiàng)目經(jīng)理編寫《項(xiàng)目立項(xiàng)報(bào)告》。

研發(fā)項(xiàng)目立項(xiàng)報(bào)告模板.doc

1.2 立項(xiàng)評(píng)審

《項(xiàng)目立項(xiàng)報(bào)告》編寫完成后，交由項(xiàng)目管理委員會(huì)進(jìn)行立項(xiàng)評(píng)審，評(píng)審?fù)ㄟ^后由副總經(jīng)理簽字確認(rèn)立項(xiàng)。確定需求分析和項(xiàng)目設(shè)計(jì)階段的時(shí)間和人員安排。

1.3 需求分析

需求分析階段，需要與用戶交流，雙方對(duì)軟件需求取得共同理解基礎(chǔ)上達(dá)成的協(xié)議。編寫并完成軟件需求說明書：也稱軟件規(guī)格說明書。

軟件需求說明書模板.doc

1.4 系統(tǒng)設(shè)計(jì)階段

常規(guī)的系統(tǒng)設(shè)計(jì)需要依次完成《概要設(shè)計(jì)說明書》，《詳細(xì)設(shè)計(jì)說明書》。以下是文檔的簡(jiǎn)要說明：

概要設(shè)計(jì)說明書：該說 明書是概要設(shè)計(jì)階段的工作 成果，它應(yīng)說明功能分配、模 塊劃分、程序的總體結(jié)構(gòu)、輸 入輸出以及接口設(shè)計(jì)、運(yùn)行設(shè) 計(jì)、數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)和出錯(cuò)處理 設(shè)計(jì)等，為詳細(xì)設(shè)計(jì)奠定基礎(chǔ)。

概要設(shè)計(jì)說明書.doc

詳細(xì)設(shè)計(jì)說明書：著重 描述每一模塊是怎樣實(shí)現(xiàn)的，包括實(shí)現(xiàn)算法、邏輯流程等。詳細(xì)設(shè)計(jì)說明書.doc

詳細(xì)設(shè)計(jì)說明書編寫完成后，項(xiàng)目經(jīng)理應(yīng)該依次編寫安排項(xiàng)目開發(fā)工作計(jì)劃。工作計(jì)劃安排可以根據(jù)項(xiàng)目經(jīng)理的習(xí)慣進(jìn)行工作計(jì)劃編寫。建議采用project。附件為綜合考務(wù)平臺(tái)的工作計(jì)劃安排，可以供參考：

考試考務(wù)綜合管理平臺(tái)工作計(jì)劃.mpp。并且確定里程碑，以便在后期項(xiàng)目執(zhí)行過程中，對(duì)其進(jìn)行確認(rèn)。對(duì)于大項(xiàng)目，建議按照項(xiàng)目設(shè)計(jì)流程，先進(jìn)行概要設(shè)計(jì)，再到詳細(xì)設(shè)計(jì)。但是對(duì)于特殊項(xiàng)目（項(xiàng)目周期較短，小項(xiàng)目），可以講概要設(shè)計(jì)和詳細(xì)設(shè)計(jì)階段合二為一，編寫功能，接口方案。但是值得注意的是，該方案中，仍然需要涵蓋項(xiàng)目模塊功能，用戶權(quán)限和各模塊實(shí)現(xiàn)邏輯，接口等。

項(xiàng)目設(shè)計(jì)開發(fā)方案.docx。

1.5 項(xiàng)目設(shè)計(jì)評(píng)審

設(shè)計(jì)階段完成后，項(xiàng)目經(jīng)理填寫《項(xiàng)目設(shè)計(jì)評(píng)審表》，將相關(guān)文檔交由項(xiàng)目管理委員會(huì)進(jìn)行項(xiàng)目設(shè)計(jì)評(píng)審。通過評(píng)審后，方可進(jìn)行編碼工作。

項(xiàng)目設(shè)計(jì)評(píng)審表.docx

1.6 編碼和測(cè)試用例編寫階段

項(xiàng)目編碼階段，項(xiàng)目經(jīng)理需要對(duì)項(xiàng)目執(zhí)行情況進(jìn)行控制和監(jiān)督，其中包括（項(xiàng)目輸入，項(xiàng)目輸出，里程碑）。如果由于特殊情況，如：需求變化，人員臨時(shí)調(diào)配，或者其他原因?qū)е碌捻?xiàng)目范圍和時(shí)間，計(jì)劃等變更，項(xiàng)目經(jīng)理應(yīng)該及時(shí)填寫變更申請(qǐng)。并提交給項(xiàng)目管理委員會(huì)。作為之后項(xiàng)目輸出驗(yàn)證的重要依據(jù)項(xiàng)目變更申請(qǐng)書.doc。

在此階段，測(cè)試人員應(yīng)該根據(jù)《需求說明書》，《概要設(shè)計(jì)》和《詳細(xì)設(shè)計(jì)說明書》的內(nèi)容，編寫相應(yīng)的《測(cè)試用例》。1.7 測(cè)試階段

編碼完成后，應(yīng)該移交測(cè)試組進(jìn)行相關(guān)測(cè)試工作。按照測(cè)試流程，需要提交《測(cè)試申請(qǐng)表》。測(cè)試人員在接收到《測(cè)試申請(qǐng)》后，應(yīng)該與研發(fā)人員討論《測(cè)試用例》的相關(guān)內(nèi)容，確定測(cè)試時(shí)間，開始程序測(cè)試。并在測(cè)試工作完成后，編寫對(duì)應(yīng)的《測(cè)試報(bào)告》。

1.8 結(jié)項(xiàng)評(píng)審與驗(yàn)證

項(xiàng)目負(fù)責(zé)人和測(cè)試負(fù)責(zé)人分別填寫《項(xiàng)目結(jié)項(xiàng)評(píng)審表》，交由項(xiàng)目管理委員會(huì)進(jìn)行評(píng)審。評(píng)審?fù)ㄟ^后，由研發(fā)中心副總經(jīng)理進(jìn)行發(fā)布確認(rèn)。

項(xiàng)目結(jié)項(xiàng)評(píng)審驗(yàn)證表.doc

1.9 新產(chǎn)品發(fā)布

編寫《用戶手冊(cè)》。方可進(jìn)行新產(chǎn)品發(fā)布。

2，舊項(xiàng)目升級(jí)開發(fā)管理流程

舊項(xiàng)目的升級(jí)，依照如下流程：

2.1項(xiàng)目升級(jí)需求分析

項(xiàng)目需求分析，需要收集用戶在產(chǎn)品使用過程中，已經(jīng)技術(shù)人員在調(diào)試過程中的反饋?zhàn)鳛樾枨蠓治龅妮斎?。并填寫?duì)應(yīng)的項(xiàng)目升級(jí)需求報(bào)告表。項(xiàng)目升級(jí)需求報(bào)告表.doc

2.2 升級(jí)評(píng)審

將《升級(jí)需求報(bào)告》交由項(xiàng)目管理委員會(huì)，評(píng)審?fù)ㄟ^后，進(jìn)行升級(jí)設(shè)計(jì)。2.2項(xiàng)目升級(jí)設(shè)計(jì)

項(xiàng)目負(fù)責(zé)人，根據(jù)需求報(bào)告和升級(jí)具體情況，編寫升級(jí)開發(fā)方案。項(xiàng)目升級(jí)開發(fā)方案.docx。并安排整改工作計(jì)劃。

2.3 項(xiàng)目升級(jí)設(shè)計(jì)評(píng)審

升級(jí)開發(fā)方案完成后，填寫《項(xiàng)目設(shè)計(jì)評(píng)審表》，交由項(xiàng)目管理委員會(huì)評(píng)審。

2.4 編碼

按照項(xiàng)目升級(jí)開發(fā)方案進(jìn)行編碼設(shè)計(jì)，如果編碼工作中，發(fā)生特殊情況需要變更計(jì)劃，或者項(xiàng)目范圍等，同樣需要提交《變更申請(qǐng)》，作為項(xiàng)目驗(yàn)證的基礎(chǔ)。同樣，此階段，測(cè)試人員應(yīng)該編寫或者修改相關(guān)測(cè)試用例。

2.5 測(cè)試

編碼完成后，應(yīng)該移交測(cè)試組進(jìn)行相關(guān)測(cè)試工作。按照測(cè)試流程，需要提交《測(cè)試申請(qǐng)表》。測(cè)試人員在接收到測(cè)試申請(qǐng)后，應(yīng)該與研發(fā)人員討論《測(cè)試用例》的相關(guān)內(nèi)容，確定測(cè)試時(shí)間，開始程序測(cè)試。并在測(cè)試工作完成后，編寫對(duì)應(yīng)的《測(cè)試報(bào)告》。

2.6 升級(jí)輸出評(píng)審

項(xiàng)目負(fù)責(zé)人和測(cè)試負(fù)責(zé)人分別填寫《項(xiàng)目結(jié)項(xiàng)評(píng)審表》，交由項(xiàng)目管理委員會(huì)進(jìn)行評(píng)審。評(píng)審?fù)ㄟ^后，由副總經(jīng)理進(jìn)行發(fā)布確認(rèn)后。

第三篇：軟件項(xiàng)目變更管理流程

變更管理流程 2 概述.......................................................................................錯(cuò)誤！未定義書簽。變更流程.................................................................................................................2

2.1 摘要.........................................................................................................................................2 2.2 提交變更申請(qǐng).........................................................................................................................3 2.3 審核變更申請(qǐng).........................................................................................................................4 2.4 識(shí)別變更可行性.....................................................................................................................4 2.5 批準(zhǔn)變更申請(qǐng).........................................................................................................................4 2.6 實(shí)施變更申請(qǐng).........................................................................................................................4 變更任務(wù).................................................................................................................5

3.1 變更申請(qǐng)人.............................................................................................................................5 3.2 變更經(jīng)理.................................................................................................................................5 3.3 變更可研小組.........................................................................................................................5 3.4 變更審批小組.........................................................................................................................5 3.5 變更實(shí)施小組.........................................................................................................................5 5 變更登記.................................................................................................................6 變更模板.................................................................................................................6

Confidential

Page 1 1 概述

描述變更管理的目的。就項(xiàng)目中變更管理的總體流程提供一份概述，如：

變更管理流程是成功交付項(xiàng)目的基礎(chǔ)。變更管理流程確保對(duì)在項(xiàng)目環(huán)境中的每個(gè)變更在實(shí)施以前都得以恰當(dāng)?shù)亩x、評(píng)估和審批。

對(duì)項(xiàng)目的變更管理是通過對(duì)以下五個(gè)關(guān)鍵步驟的實(shí)施引入的。，: ? 提交和接收變更申請(qǐng) ? 審核和記錄變更申請(qǐng) ? 確定變更申請(qǐng)的可行性 ? 批準(zhǔn)變更申請(qǐng)

? 實(shí)施和結(jié)束變更申請(qǐng)變更流程

對(duì)將要執(zhí)行的流程和程序做一個(gè)圖表概述，以啟動(dòng)、實(shí)施項(xiàng)目中的變更并審核其效果。例如：Provide a diagrammatic representation of the processes and procedures to be undertaken in order to initiate, implement and review the effects of changes within the project.An example follows:

2.1 概要

下圖對(duì)將要執(zhí)行的變更流程和程序做了一個(gè)概述，以有效地管理與項(xiàng)目相關(guān)的變更。同時(shí)也明確的變更管理中的職責(zé)分工。

Confidential

Page 2 ChangeManagementProcessChangeManagementRole1.1 Changerequirementidentified1.0 SubmitChange Request1.2 ChangeRequest FormsubmittedChangeRequestor2.1 ChangeRequest Formreviewed2.0 ReviewChange Request2.2 FeasibilityStudy required?ChangeManagerNoYes3.1 ChangeFeasibility Studyperformed3.0 IdentifyChange Feasibility3.2 ChangeFeasibility StudyapprovedChangeFeasibility Group3.3 Changedocumentationsubmitted4.1 Changedocumentationreviewed4.0 ApproveChange Request4.2 Changeapproved?ChangeApproval GroupNoYes5.1 Changeimplementationscheduled5.2 Changeimplementationtested5.0 ImplementChange Request5.3 ChangeimplementationperformedChangeImplementationGroup5.4 Changeimplementationreviewed5.5 Changeclosed2.2 提交變更申請(qǐng)

本步驟中項(xiàng)目團(tuán)隊(duì)中的任何成員都可以提交項(xiàng)目變更申請(qǐng)，需要完成以下工作：

? 變更申請(qǐng)人識(shí)別項(xiàng)目中任何方面的變更需求（如范圍、可交付成果、時(shí)限、組織）.? 變更申請(qǐng)人完成變更申請(qǐng)表（CRF），并將其呈交變更經(jīng)理。變更申請(qǐng)表對(duì)需要進(jìn)行的變更做一概述，包括：

? 變更描述

? 變更原因（包括商業(yè)驅(qū)動(dòng)）? 變更利益 ? 變更成本

? 變更帶來的影響 ? 支持性文件

2.3 審核變更申請(qǐng)

本步驟授權(quán)變更經(jīng)理對(duì)變更申請(qǐng)表進(jìn)行審核，以決定是否需要一份充分的可行性研究報(bào)告以供變更批準(zhǔn)小組評(píng)估變更可能帶來的全部影響。做出上述決定的基本依據(jù)是：

? 呈交的可選擇變更數(shù)目Number of change options presented ? 申請(qǐng)變更可選反性的復(fù)雜程度Complexity of the change options requested ? 提出的變更解決方案的衡量Scale of the change solutions proposed 變更經(jīng)理將不會(huì)在變更日志中打開一份變更申請(qǐng)并記錄是否需要一個(gè)變更可行性研究。The Change Manager will open a 慍hange Request’ in the Change Log and record whether or not a change feasibility study is required.2.4 識(shí)別變更可行性

本步驟涉及完成一份完整的變更可行性研究，以確保對(duì)所有的變更可選項(xiàng)進(jìn)行調(diào)查并上報(bào)，變更可行性研究包括對(duì)以下各項(xiàng)的定義：

? 變更需求

? 變更可選項(xiàng)Change options ? 變更成本及利益

? 變更風(fēng)險(xiǎn)及事項(xiàng)Change risks and issues ? 變更帶來的影響 ? 變更的建議和計(jì)劃

對(duì)對(duì)可行性研究進(jìn)行認(rèn)真審核以確保研究是切題的，同時(shí)確保（經(jīng)過變更后的）最終的可交付成果是可以通過的—那研究報(bào)告就可以上報(bào)變更審批小組了。變更經(jīng)理將整理所有變更文件并報(bào)變更審批小組做最終審核。這些文件包括：: ? 原始的變更申請(qǐng)表

? 已通過的變更可行性研究報(bào)告 ? 所有支持性文件

2.5 批準(zhǔn)變更申請(qǐng)

本步驟涉及變更審批小組對(duì)變更申請(qǐng)的正式審核。變更審批小組可能做出下列任何一種結(jié)論：

? 拒絕變更Reject the change ? 要求與變更相關(guān)的更多信息Request more information related to the change ? 批準(zhǔn)變更申請(qǐng)Approve the change as requested ? 在特定條件下批準(zhǔn)變更Approve the change subject to specified conditions

決定是否變更的標(biāo)準(zhǔn)大致為：

? 實(shí)施變更給項(xiàng)目帶來的風(fēng)險(xiǎn) ? 不實(shí)施變更給項(xiàng)目帶來的風(fēng)險(xiǎn)

? 實(shí)施變更對(duì)項(xiàng)目產(chǎn)生的影響（時(shí)間、資源、財(cái)務(wù)、質(zhì)量方面）?

2.6 實(shí)施變更申請(qǐng)

本步驟涉及對(duì)變更的全面實(shí)施，包括: ? ? ? ? ? ? 確定變更進(jìn)度（如：實(shí)施變更的日期）

實(shí)施前對(duì)變更進(jìn)行測(cè)試Testing the change prior to implementation 實(shí)施變更

對(duì)實(shí)施變更的成功度進(jìn)行審核 就實(shí)施變更的成功度進(jìn)行溝通 在變更日志中結(jié)束變更 變更職責(zé)

對(duì)項(xiàng)目中啟動(dòng)、審核和實(shí)施變更所涉及的所有資源（包括項(xiàng)目中或項(xiàng)目之外的資源）的職責(zé)和責(zé)任進(jìn)行定義，如：

3.1 變更申請(qǐng)人

變更申請(qǐng)人最初意識(shí)到對(duì)項(xiàng)目進(jìn)行變更的必要性并就此需求與變更經(jīng)理進(jìn)行正式溝通。其主要職責(zé)為: ? 及早識(shí)別對(duì)項(xiàng)目進(jìn)行變更的需求

? 通過完成變更需求表來完成對(duì)更申請(qǐng)的正式文件 ? 將變更申請(qǐng)表提交變更經(jīng)理以供審

3.2 變更經(jīng)理

變更經(jīng)理對(duì)一個(gè)項(xiàng)目中所有的變更進(jìn)行接收、記錄、監(jiān)測(cè)和控制。其主要職責(zé)為：

? 接收所有的變更申請(qǐng)并將其記錄于變更登記簿中 ? 將所有的變更申請(qǐng)進(jìn)行分類、優(yōu)選

? 審核所有變更申請(qǐng)以確定在提交變更審核小組前是否還需增加有關(guān)信息 ? 確定是否需要進(jìn)行一個(gè)正式的可行性研究并提交變更審核小組 ? 通過委派變更可行性研究小組來啟動(dòng)變更可行生研

? 對(duì)所有的變更申請(qǐng)進(jìn)展情況進(jìn)行監(jiān)測(cè)以確保項(xiàng)目按時(shí)完成 ? 將所有的變更申請(qǐng)問題和風(fēng)險(xiǎn)上報(bào)變更審批小組 ? 就變更審批小組做出的所有決定進(jìn)行下達(dá)和溝通

3.3 變更可行性研究（可研）小組

變更可行性小組負(fù)責(zé)完成由變更經(jīng)理簽發(fā)的對(duì)于某變更申請(qǐng)的正式的可行性研究，主要職責(zé)為：

? 通過進(jìn)行摸擬研究來確定變更可能的要素：成本、利益和變更帶來的影響。? 將變更可行性研究報(bào)告中的所有發(fā)現(xiàn)形成文字 ? 對(duì)報(bào)告進(jìn)行認(rèn)真審核并批準(zhǔn)交其上報(bào)。? 將報(bào)告轉(zhuǎn)變更經(jīng)理以提交變更審批小組 ?

3.4 變更審批小組

變更審批小組決定是否批準(zhǔn)變更經(jīng)理轉(zhuǎn)來的所有變更申請(qǐng)。其主要職責(zé)為：

? 審核變更經(jīng)理轉(zhuǎn)來的所有變更申請(qǐng) ? 考慮所有變更支持性文件

? 根據(jù)每個(gè)變更申請(qǐng)的相關(guān)價(jià)值決定批準(zhǔn)還是拒絕 ? 解決變更爭(zhēng)議（當(dāng)兩個(gè)或兩以上變更撞車時(shí)）? 解決變更問題Resolving change issues ? 決定實(shí)施變更時(shí)間表

3.5 變更實(shí)施小組

變更實(shí)施小組對(duì)項(xiàng)目中所有變更的實(shí)施進(jìn)行計(jì)劃、落實(shí)和審核。變更實(shí)施小組主要負(fù)責(zé)： ? ? ? ? ? 計(jì)劃所有變更的進(jìn)度（在變更審批小組提供的總體時(shí)間框架范圍內(nèi)）)在實(shí)施前對(duì)所有變更進(jìn)行測(cè)試 實(shí)施項(xiàng)目中的所有變更 實(shí)施后審核變更的成功度 在變更日志中請(qǐng)求結(jié)束變更 變更登記簿

變更登記簿是用于登記、跟蹤變更申請(qǐng)進(jìn)展情況的日志/數(shù)據(jù)庫。描述項(xiàng)目變更登記簿的目的和用途，在下面插入一個(gè)真實(shí)的變更登記文本 變更模版

插入所需的每個(gè)模版（如變更申請(qǐng)表）以對(duì)項(xiàng)目中變更的效果加以啟動(dòng)、執(zhí)行、實(shí)施和考量。

第四篇：軟件項(xiàng)目上線發(fā)布流程

布比項(xiàng)目上線部署發(fā)布流程

V1.0 2017/9/14

1、目的

規(guī)范公司項(xiàng)目和產(chǎn)品的上線流程，建立和完善產(chǎn)品的版本控制，保證軟件產(chǎn)品質(zhì)量。

2、范圍

適用于公司所有項(xiàng)目和產(chǎn)品

3、發(fā)布人員

開發(fā)環(huán)境由開發(fā)人員內(nèi)部負(fù)責(zé)（包括維護(hù)和管理開發(fā)分支和git代碼庫）測(cè)試環(huán)境由測(cè)試人員負(fù)責(zé) 預(yù)熱環(huán)境由運(yùn)維人員負(fù)責(zé) 正式環(huán)境由運(yùn)維人員負(fù)責(zé)

*數(shù)據(jù)庫操作均由DBA統(tǒng)一負(fù)責(zé)(或運(yùn)維人員)

4、發(fā)布流程

在已開發(fā)完畢的各系統(tǒng)正式部署生產(chǎn)環(huán)境前要嚴(yán)格按照以下流程進(jìn)行上線前檢查。

一、提交測(cè)試

a)開發(fā)人員在功能開發(fā)完畢后首先配置開發(fā)環(huán)境，并將系統(tǒng)部署至開發(fā)環(huán)境。在開發(fā)環(huán)境經(jīng)過自測(cè)通過后提交測(cè)試代碼，并開始撰寫上線方案。(上線方案須包括新增的外部應(yīng)用程序安裝，應(yīng)用程序部署順序及應(yīng)用關(guān)聯(lián)性、是否關(guān)閉其他應(yīng)用服務(wù)，數(shù)據(jù)庫腳本，制定合理的上線時(shí)間，涉及的服務(wù)影響范圍以及上線失敗的回滾步驟。)并提交相關(guān)技術(shù)負(fù)責(zé)人審核，在審核過后郵件給相關(guān)測(cè)試人員。

b)測(cè)試人員根據(jù)模塊功能文檔并制定測(cè)試方案，測(cè)試用例，特別注意臨界點(diǎn)測(cè)試方案。

c)測(cè)試人員通過自動(dòng)化部署平臺(tái)根據(jù)提供的分支號(hào)依照上線方案進(jìn)行自動(dòng)化部署，涉及數(shù)據(jù)庫操作可提請(qǐng)DBA操作。

d)記錄各種數(shù)據(jù)測(cè)試結(jié)果及測(cè)試問題，并交由相關(guān)開發(fā)人員進(jìn)行二次迭代處理，該點(diǎn)須交付測(cè)試結(jié)果報(bào)告。

e)內(nèi)測(cè)完畢后交由相關(guān)業(yè)務(wù)及需求人員進(jìn)行集成測(cè)試，并請(qǐng)測(cè)試人員記錄測(cè)試結(jié)果及問題，交由相關(guān)開發(fā)人員進(jìn)行再次迭代。該點(diǎn)須交付測(cè)試方案測(cè)試結(jié)果報(bào)告。

二、預(yù)熱發(fā)布

a)測(cè)試人員在測(cè)試環(huán)境測(cè)試并跟蹤修改bug達(dá)到上線標(biāo)準(zhǔn)（沒有A、B級(jí)bug，C 級(jí)bug達(dá)到要求）時(shí)。開始部署預(yù)熱環(huán)境，測(cè)試人員對(duì)現(xiàn)有功能在預(yù)熱環(huán)境上進(jìn)行驗(yàn)收測(cè)試（重新執(zhí)行case）。緊急Bug修改走補(bǔ)丁/hotfix流程。不影響功能的bug留到下次版本解決，確認(rèn)達(dá)到上線標(biāo)準(zhǔn)。

b)如達(dá)到上線標(biāo)準(zhǔn)，測(cè)試人員發(fā)起郵件通知相關(guān)開發(fā)人員、產(chǎn)品人員，準(zhǔn)備正式上線發(fā)布流程。

三、正式上線

a)在測(cè)試人員確認(rèn)項(xiàng)目具備上線條件下，正式上線前，開發(fā)負(fù)責(zé)人須發(fā)起部署大會(huì)，召集相關(guān)開發(fā)人員、測(cè)試人員、產(chǎn)品人員、運(yùn)維人員討論此次部署事項(xiàng)(介紹項(xiàng)目的相應(yīng)負(fù)責(zé)人員，數(shù)據(jù)庫腳本執(zhí)行，部署順序，應(yīng)用程序關(guān)聯(lián)，部署時(shí)間點(diǎn)，部署回滾方案，包括數(shù)據(jù)庫回滾和應(yīng)用程序回滾)，最后生成會(huì)議紀(jì)要并發(fā)送郵件。b)確認(rèn)上線之后，測(cè)試人員郵件上線方案，數(shù)據(jù)庫腳本，應(yīng)用分支號(hào)給運(yùn)維人員及DBA，DBA應(yīng)提前執(zhí)行數(shù)據(jù)庫腳本，應(yīng)用部署須通過自動(dòng)化部署平臺(tái)進(jìn)行部署，部署系統(tǒng)應(yīng)在應(yīng)用系統(tǒng)中記錄當(dāng)前分支號(hào)，以便后續(xù)應(yīng)用回滾使用。在部署中出現(xiàn)錯(cuò)誤，及時(shí)通知相關(guān)開發(fā)人員。如若問題不能在計(jì)劃內(nèi)時(shí)間解決，執(zhí)行回滾方案。

c)運(yùn)維，DBA在操作完成時(shí)均需要回復(fù)郵件，并說明操作步驟結(jié)果。d)發(fā)布完成后運(yùn)維人員回復(fù)郵件通知測(cè)試人員、業(yè)務(wù)及需求人員進(jìn)行線上測(cè)試。測(cè)試結(jié)果及問題, 提交至開發(fā)人員。如若出現(xiàn)問題不能在計(jì)劃內(nèi)時(shí)間解決，執(zhí)行回滾方案，并進(jìn)行迭代改進(jìn)。e)（緊急Bug修改走補(bǔ)丁/hotfix流程。不影響功能的bug留到下次版本解決。）。測(cè)試通過后測(cè)試人員回復(fù)郵件，發(fā)布結(jié)束。

四、應(yīng)用服務(wù)監(jiān)控

a)運(yùn)維人員添加新增外部應(yīng)用服務(wù)監(jiān)控和新增云主機(jī)的系統(tǒng)監(jiān)控 b)運(yùn)維人員對(duì)相關(guān)業(yè)務(wù)保持上線后正式生產(chǎn)系統(tǒng)進(jìn)行有計(jì)劃地監(jiān)控其服務(wù)的性能和可用性，及時(shí)發(fā)現(xiàn)問題處理及反饋問題。

五、總結(jié)報(bào)告

a)上線成功后，撰寫或總結(jié)系統(tǒng)需求、架構(gòu)以及開發(fā)文檔進(jìn)行備案。

附：上線流程圖 系統(tǒng)上線部署發(fā)布流程開發(fā)人員測(cè)試人員運(yùn)維人員開發(fā)環(huán)境調(diào)試

1、BUG修復(fù)開發(fā)自測(cè)提交測(cè)試申請(qǐng)

1、上線方案

2、其他上線文檔確認(rèn)測(cè)試版本

1、內(nèi)容無誤

2、無明顯BUG開發(fā)負(fù)責(zé)人發(fā)起部署大會(huì)1.數(shù)據(jù)庫腳本2.部署順序3.部署時(shí)間4.回滾方案5.項(xiàng)目相關(guān)負(fù)責(zé)人同意上線發(fā)布上線公告郵件通知運(yùn)維1.上線方案2.數(shù)據(jù)庫腳本部署上線線上測(cè)試有無系統(tǒng)BUGY上線完成、持續(xù)監(jiān)控Y執(zhí)行一般修復(fù)流程（線上修復(fù)或迭代改進(jìn)）是否修復(fù)NN是否為嚴(yán)重bugY確認(rèn)回退Y執(zhí)行回滾

第五篇：軟件配置管理規(guī)范流程

概述 1.1 目的

本文檔主要目的在于規(guī)范項(xiàng)目配置管理活動(dòng)，確保配置項(xiàng)正確地唯一標(biāo)識(shí)并且易于存取，保證基線配置項(xiàng)的更改受控，明確基線狀態(tài)，在整個(gè)軟件生命周期中建立和維護(hù)項(xiàng)目產(chǎn)品的完整性和可追溯性。

1.2 適用范圍

本文檔適用于不同類別的軟件產(chǎn)品和軟件項(xiàng)目開發(fā)工程的配置管理活動(dòng)，針對(duì)項(xiàng)目不同在流程上作適當(dāng)?shù)膭h減。配置管理可采用各種工具及手工辦法，本文件以CVS（并行版本系統(tǒng)）配置管理工具為例，規(guī)定公司的配置管理辦法，使用其他工具時(shí)也可對(duì)應(yīng)本文件的要求參照?qǐng)?zhí)行。

1.3 術(shù)語和縮略語

1.3.1 軟件配置管理（Software Configuration Management，SCM）軟件配置管理是對(duì)軟件修改進(jìn)行標(biāo)識(shí)、組織和控制的技術(shù)，用來協(xié)調(diào)和控制整個(gè)過程。是通過技術(shù)或行政手段對(duì)軟件產(chǎn)品及其開發(fā)過程和生命周期進(jìn)行控制、規(guī)范的一系列措施。配置管理的目標(biāo)是記錄軟件產(chǎn)品的演化過程，確保軟件開發(fā)者在軟件生命周期中各個(gè)階段都能得到精確的不同版本的產(chǎn)品配置。

1.3.2 配置項(xiàng)（Configuration Item，CI）

凡是納入配置管理范疇的工作成果統(tǒng)稱為配置項(xiàng)，配置項(xiàng)邏輯上組成軟件系統(tǒng)的各組成部分，一般是可以單獨(dú)進(jìn)行設(shè)計(jì)、實(shí)施和測(cè)試的。

每個(gè)配置項(xiàng)的主要屬性有：名稱、標(biāo)簽、文件狀態(tài)、版本、作者、日期等。所有配置項(xiàng)都被保存在配置庫里，確保不會(huì)混淆、丟失。配置項(xiàng)及其歷史記錄反映了軟件的演化過程。

1.3.3 基線（Baseline）

在配置管理系統(tǒng)中，基線就是一個(gè)配置項(xiàng)或一組配置項(xiàng)在其生命周期的不同時(shí)間點(diǎn)上通過正式評(píng)審而進(jìn)入正式受控的一種狀態(tài)，這些配置項(xiàng)構(gòu)成了一個(gè)相對(duì)穩(wěn)定的邏輯實(shí)體，而這個(gè)過程被稱為“基線化”。每一個(gè)基線都是其下一步開發(fā)的出發(fā)點(diǎn)和參考點(diǎn)?；€確定了元素（配置項(xiàng)）的一個(gè)版本，且只確定一個(gè)版本。一般情況下，基線一般在指定的里程碑處創(chuàng)建，并與項(xiàng)目中的里程碑保持同步。每個(gè)基線都將接受配置管理的嚴(yán)格控制，基線中的配置項(xiàng)被“凍結(jié)”了，不能再被任何人隨意修改，對(duì)其修改要嚴(yán)格地按照變更控制的過程進(jìn)行。在一個(gè)軟件開發(fā)階段結(jié)束時(shí)，上一個(gè)基線加上增加和修改的基線內(nèi)容形成下一個(gè)基線。

基線的主要屬性有：名稱、標(biāo)簽、版本、日期等。1.4 權(quán)限與職責(zé) 1.4.1 研發(fā)總經(jīng)理助理 1）審核變更請(qǐng)求。

1.4.2 項(xiàng)目經(jīng)理（Project Manager，PM）1)審核批準(zhǔn)配置管理計(jì)劃； 2)接收或拒絕小范圍的變更申請(qǐng)； 3)召集評(píng)估變更；

4)提出配置管理的建議和要求； 5)配合配置管理員的工作。

1.4.3 配置管理員（Configuration Management Officer，CMO）1)編寫配置管理計(jì)劃；

2)執(zhí)行版本控制和變更控制方案； 3)制定訪問控制策略；

4)負(fù)責(zé)項(xiàng)目的配置管理工作，包括搭建環(huán)境、權(quán)限分配、配置庫的建立、配置項(xiàng)的控制等；

5)配置管理工具的日常管理與維護(hù)； 6)配置庫的日常操作和維護(hù)； 7)負(fù)責(zé)配置審核并提交報(bào)告；

8)根據(jù)配置部署表單編譯發(fā)布版本，并維護(hù)版本； 9)對(duì)開發(fā)人員進(jìn)行相關(guān)的培訓(xùn)；

10)對(duì)配置審核中發(fā)現(xiàn)的不符合項(xiàng)，擬訂糾正措施，要求相關(guān)責(zé)任人進(jìn)行糾正。

11)監(jiān)督項(xiàng)目組成員規(guī)范的執(zhí)行情況。1.4.4 開發(fā)人員（Developer）

1)根據(jù)確定的配置管理計(jì)劃和相關(guān)規(guī)定，提交配置項(xiàng)和基線； 2)負(fù)責(zé)項(xiàng)目組內(nèi)部測(cè)試； 3)負(fù)責(zé)軟件集成和版本生成；

4)按照軟件配置管理工具的使用模型來完成開發(fā)任務(wù)。2 實(shí)施細(xì)則 2.1 配置項(xiàng)管理 2.1.1 配置項(xiàng)的范圍

軟件配置可包括以下幾方面：開發(fā)文檔，代碼，第三方控件、插件，參考資料，測(cè)試文檔，用戶文檔，項(xiàng)目管理文檔，驗(yàn)收文檔等。

l 項(xiàng)目文檔主要指：立項(xiàng)建議書、可行性分析報(bào)告、技術(shù)建議書、用戶需求說明書、項(xiàng)目計(jì)劃、項(xiàng)目進(jìn)度計(jì)劃、項(xiàng)目階段性計(jì)劃、產(chǎn)品需求規(guī)格說明書、概要設(shè)計(jì)報(bào)告、詳細(xì)設(shè)計(jì)、數(shù)據(jù)庫設(shè)計(jì)、界面設(shè)計(jì)、用戶操作手冊(cè)、用戶安裝手冊(cè)、培訓(xùn)文檔、驗(yàn)收?qǐng)?bào)告以及上述文檔的評(píng)審記錄。

l 代碼主要指：源代碼等。

l 工具主要指：腳本文件、插件、第三方控件等。2.1.2 配置項(xiàng)基線管理

結(jié)合SPP和ISO9000的相關(guān)規(guī)定，配置管理員根據(jù)配置管理規(guī)范及配置管理計(jì)劃，對(duì)配置項(xiàng)進(jìn)行分階段管理，每一階段正式評(píng)審?fù)ㄟ^后納入受控庫，作為該項(xiàng)目的一個(gè)基線。

l 項(xiàng)目啟動(dòng)：配置項(xiàng)包括技術(shù)建議書、可行性分析報(bào)告、用戶需求說明書等立項(xiàng)階段產(chǎn)生的文檔，評(píng)審或?qū)徟ㄟ^后建立發(fā)布基線。

l 需求階段：系統(tǒng)調(diào)研后開發(fā)人員進(jìn)行需求分析，并整理產(chǎn)品需求規(guī)格說明書。產(chǎn)品需求規(guī)格說明書經(jīng)過客戶的確認(rèn)后，建立需求基線。如需升級(jí)版本則必須通過評(píng)審或?qū)徟⒌玫娇蛻舻拇_認(rèn)。

l 項(xiàng)目計(jì)劃：需求分析完成后即可制定項(xiàng)目的開發(fā)計(jì)劃，包括項(xiàng)目計(jì)劃和主要下屬計(jì)劃。包括項(xiàng)目進(jìn)度計(jì)劃、配置管理計(jì)劃、質(zhì)量保證計(jì)劃、測(cè)試計(jì)劃、項(xiàng)目階段性計(jì)劃。項(xiàng)目開發(fā)計(jì)劃評(píng)審?fù)ㄟ^后，建立項(xiàng)目計(jì)劃基線。

l 設(shè)計(jì)：系統(tǒng)設(shè)計(jì)可分為概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)、數(shù)據(jù)庫設(shè)計(jì)、數(shù)據(jù)庫字典、界面設(shè)計(jì)。針對(duì)用戶需求規(guī)格說明書進(jìn)行系統(tǒng)設(shè)計(jì)，配置時(shí)應(yīng)說明系統(tǒng)設(shè)計(jì)的版本與需求分析報(bào)告版本的對(duì)應(yīng)關(guān)系。設(shè)計(jì)說明書評(píng)審或?qū)徟ㄟ^后，建立設(shè)計(jì)基線。l 編碼（設(shè)計(jì)實(shí)現(xiàn)）：編碼按功能模塊分子項(xiàng)目，即每個(gè)模塊記作一個(gè)配置項(xiàng)。代碼在提交項(xiàng)目組系統(tǒng)測(cè)試時(shí)建立Beta版本，系統(tǒng)測(cè)試產(chǎn)品正式發(fā)布后建立Version版本。

l 測(cè)試：?jiǎn)卧獪y(cè)試和系統(tǒng)測(cè)試。單元測(cè)試通過提交《單元測(cè)試報(bào)告》，項(xiàng)目啟動(dòng)后應(yīng)提交《系統(tǒng)測(cè)試計(jì)劃》，系統(tǒng)測(cè)試完成后應(yīng)提交《系統(tǒng)測(cè)試報(bào)告》。配置時(shí)應(yīng)說明測(cè)試的版本與編碼版本的對(duì)應(yīng)關(guān)系。系統(tǒng)測(cè)試完成后建立測(cè)試基線。

l 版本發(fā)布：項(xiàng)目組提交《部署表單》，CMO根據(jù)部署表單進(jìn)行編譯，發(fā)布測(cè)試服務(wù)器上，并對(duì)版本進(jìn)行維護(hù)。同時(shí)將發(fā)布的版本上傳到文檔服務(wù)器上備份。

l 交付與驗(yàn)收：在交付前配置審核完成后建立產(chǎn)品基線，產(chǎn)品基線包含程序以及有關(guān)文檔配置項(xiàng)，包括交付文檔、代碼、工具等。

l 產(chǎn)品部署：部署時(shí)應(yīng)包括操作手冊(cè)、安裝維護(hù)手冊(cè)、維護(hù)文檔以及必要的業(yè)務(wù)和技術(shù)培訓(xùn)文檔。

l 相關(guān)資料：相關(guān)資料也應(yīng)作為配置項(xiàng)納入配置管理，此部分包括： 1)相關(guān)法律、法規(guī)；必須遵照或項(xiàng)目組約定的技術(shù)規(guī)范；

2)與客戶或項(xiàng)目組內(nèi)部重要的交互信息記錄，如會(huì)議記錄、會(huì)談?dòng)涗洝-mail和MSN記錄等；

2.2 版本控制 2.2.1 文檔的版本控制

所有文檔的管理納入配置管理庫，用版本控制工具進(jìn)行統(tǒng)一管理。文檔的版本控制主要通過文檔的名稱、文檔控制頁及版本控制工具的標(biāo)簽來實(shí)現(xiàn)，主要分為以下幾類：

2.2.1.1 版本變化型文檔

命名方式：[文檔名稱]+[子系統(tǒng)名稱]（可選）

適用文檔：項(xiàng)目計(jì)劃、配置管理計(jì)劃、質(zhì)量保證計(jì)劃、項(xiàng)目進(jìn)度計(jì)劃、用戶需求規(guī)格說明書、產(chǎn)品需求規(guī)格說明書、體系結(jié)構(gòu)設(shè)計(jì)報(bào)告、數(shù)據(jù)庫設(shè)計(jì)報(bào)告、詳細(xì)設(shè)計(jì)報(bào)告、用戶操作維護(hù)手冊(cè)、測(cè)試用例等。

示例：項(xiàng)目計(jì)劃.doc 詳細(xì)設(shè)計(jì)_SP門戶.doc 標(biāo)簽結(jié)構(gòu)：[大版本] + [子系統(tǒng)簡(jiǎn)稱] + [版本號(hào)] + 日期（標(biāo)簽控制說明版本信息）

l [大版本]： 可選，表示同一項(xiàng)目為不同用戶定制的版本。l [子系統(tǒng)簡(jiǎn)稱]： 可選，當(dāng)一個(gè)項(xiàng)目有多個(gè)子系統(tǒng)時(shí)，為區(qū)分不同子系統(tǒng)而設(shè)置。

l [版本號(hào)]：采用[Vs_x_y]的形式。

l 日期：納入基線管理的日期，用8位表示，如20071031 說明：

a.文檔發(fā)布名稱采用[文檔名+ Vs_x_y]的形式，文檔的版本號(hào)應(yīng)該和版本控制工具中相應(yīng)標(biāo)簽上的版本號(hào)一致。

b.對(duì)文檔的修改需要從配置管理庫中取到本地進(jìn)行。

c.對(duì)于文檔小的修改，如文字錯(cuò)誤，格式調(diào)整，變更Vs_x_y中的y來區(qū)別（如：V1_0_1）。

d.文檔內(nèi)容沒有大的增加和刪節(jié)，意思表述沒有發(fā)生重大的變化，版本標(biāo)識(shí)通過版本工具中加上x標(biāo)簽來表示（如：V1_1_0），以及在文檔內(nèi)部控制頁標(biāo)注變化來表示。

e.文檔有重大增加和刪節(jié)，意思表述有重大變化的，版本標(biāo)識(shí)通過在相應(yīng)文檔加上s標(biāo)簽來表示（如：V2_0_0）。

f.對(duì)于納入基線庫的文檔的修改需要提交變更申請(qǐng)，經(jīng)批準(zhǔn)才能進(jìn)行修改，并且修改的內(nèi)容要經(jīng)再次評(píng)審才能重新納入基線庫，作為后續(xù)階段的參考文檔。

2.2.1.2 時(shí)間區(qū)別型文檔 命名方式：[文檔名稱＋撰寫時(shí)間] 適用文檔：文檔名稱有明確的含義，需要用時(shí)間標(biāo)識(shí)的日常性文檔。如周例會(huì)會(huì)議紀(jì)要，項(xiàng)目月計(jì)劃，項(xiàng)目月總結(jié),階段性計(jì)劃等等。

示 例：周例會(huì)會(huì)議紀(jì)要20030901.doc 2.2.1.3 時(shí)間序號(hào)型文檔

命名方式：[文檔名稱+人員姓名（拼音）+撰寫時(shí)間+序列號(hào)] 適用文檔：測(cè)試報(bào)告

示例：?jiǎn)卧獪y(cè)試報(bào)告_lixiaohong_20071112_01.dco 2.2.1.4 其他文檔：

對(duì)于不能按照前四種類型進(jìn)行命名的文檔 會(huì)議紀(jì)要：會(huì)議紀(jì)要YYYYMMDD()示 例：9月9日召開的項(xiàng)目啟動(dòng)會(huì) 命名為：會(huì)議紀(jì)要20030909(項(xiàng)目啟動(dòng)).doc 評(píng)審報(bào)告：評(píng)審報(bào)告YYYYMMDD()同”會(huì)議紀(jì)要”要求一致。

示 例：10月9日召開的項(xiàng)目總體方案評(píng)審 命名為：評(píng)審報(bào)告20030910(總體方案).doc 2.2.2 發(fā)行版本表示

發(fā)行版本采用標(biāo)簽說明，結(jié)構(gòu)如下：

[大版本] + [版本類型] + [版本號(hào)] + [子系統(tǒng)簡(jiǎn)稱(拼音)]+日期 +序號(hào) [大版本]： 可選，表示同一項(xiàng)目為不同用戶定制的版本。

[子系統(tǒng)簡(jiǎn)稱]： 可選，當(dāng)一個(gè)項(xiàng)目有多個(gè)子系統(tǒng)時(shí)，為區(qū)分不同子系統(tǒng)而設(shè)置。

版本類型：分為3種

Beta表示項(xiàng)目組內(nèi)部測(cè)試，標(biāo)簽：B1_0_0-20071015-01 Release系統(tǒng)測(cè)試，標(biāo)簽：Release1_0_0-SPmenhu-20071112-01 Version正式發(fā)行版，標(biāo)簽：Version1_0_0-SPmenhu-20071112-01 [版本號(hào)] 對(duì)于Version正式發(fā)行版 是必須要注明的，而其它可選。發(fā)行產(chǎn)品基線在版本號(hào)前加Version，如

Version_1, Version_2, Version_3….表示分支；

Version_1_0, Version_1_1, Version_1_2… 表示在分支Version_1上的標(biāo)簽； Version_0_0, Version_0_1, Version_0_2… 表示在主線上的標(biāo)簽。2.3 配置庫管理 2.3.1 配置庫的分類

配置庫統(tǒng)一由配置管理員負(fù)責(zé)管理，服務(wù)器端使用cvsnt2.0.4，客戶端主要使用烏龜CVS。配置庫目錄結(jié)構(gòu)如下：

2.3.2 配置庫的建立 所有項(xiàng)目應(yīng)建立配置庫，以便管理各配置項(xiàng)，配置管理員組織建立配置庫。程序庫主要通過設(shè)置版本的分支來實(shí)現(xiàn)對(duì)配置項(xiàng)權(quán)限管理：

1)開發(fā)庫：開發(fā)人員相對(duì)比較自由的存儲(chǔ)空間，開發(fā)人員可以在自己的權(quán)限范圍內(nèi)任意取出提交。

2)基線庫：配置管理員有最高權(quán)限，其余相關(guān)人員均為讀的權(quán)限，發(fā)生變更時(shí)變更人員須提交變更申請(qǐng)后方可修改基線庫內(nèi)的配置項(xiàng)。

? 文檔評(píng)審?fù)ㄟ^后，文檔嚴(yán)格受控。由配置管理員將通過評(píng)審后的文檔移植到基線庫里同時(shí)將該配置項(xiàng)從開發(fā)庫移除。

? 代碼一般在移交系統(tǒng)測(cè)試時(shí)納入基線庫受控，可根據(jù)項(xiàng)目的具體情況設(shè)置基線。

3)產(chǎn)品庫：產(chǎn)品庫的產(chǎn)品均出自于基線庫，產(chǎn)品庫存儲(chǔ)的產(chǎn)品用于交付和存檔。

配置三庫統(tǒng)一由配置管理員管理，根據(jù)各開發(fā)階段的實(shí)際情況定制相應(yīng)的版本選取規(guī)則，來保證開發(fā)活動(dòng)的正常運(yùn)作。在變更發(fā)生時(shí)，應(yīng)及時(shí)做好基線的推進(jìn)。

2.3.3 分配權(quán)限

項(xiàng)目開始后配置管理員編寫《配置庫目錄結(jié)構(gòu)表》明確項(xiàng)目組成員以及相關(guān)人員的權(quán)限。在wincvs里有三種權(quán)限，讀（r）、寫（w）、添加刪除（c）權(quán)限。在開發(fā)庫內(nèi)，文檔部分項(xiàng)目組成員有rcw權(quán)限，其他相關(guān)人員只r權(quán)限；代碼部分項(xiàng)目組成員有rcw權(quán)限，其他相關(guān)人員沒有任何權(quán)限。在基線庫內(nèi)，項(xiàng)目組成員僅有r權(quán)限，其他相關(guān)人的權(quán)限視情況而定。在產(chǎn)品庫內(nèi)，所有人沒有任何權(quán)限。配置管理員在三庫內(nèi)均擁有最高權(quán)限。

2.4 配置變更控制 2.4.1 變更的分類

軟件及其相關(guān)文檔的變更按照變更的影響范圍進(jìn)行分類：

1)A級(jí)：變更會(huì)影響系統(tǒng)級(jí)的需求、外部接口、產(chǎn)品價(jià)格或者交付期；這類變更必須經(jīng)過配置管理委員會(huì)審核并有客戶批準(zhǔn)和確認(rèn)。

2)B級(jí)：變更會(huì)影響配置項(xiàng)間的功能接口、內(nèi)部功能的設(shè)計(jì)、組件；這類變更必須由項(xiàng)目經(jīng)理或配置管理委員會(huì)的批準(zhǔn)和認(rèn)可。3)C級(jí)：變更只會(huì)影響配置項(xiàng)內(nèi)部或?qū)UG問題的處理；這類變更可以由配置項(xiàng)的管理人員負(fù)責(zé)批準(zhǔn)。

? 系統(tǒng)測(cè)試前變更控制流程：

? 系統(tǒng)測(cè)試完畢發(fā)布release版本后變更控制流程

圖2 變更控制流程 2.4.2 變更請(qǐng)求的提出

a． 由技術(shù)支撐中心匯集顧客意見，影響到需求變更則填寫《配置項(xiàng)變更控制報(bào)告》，并提交給配置管理員。

b． 配置管理員對(duì)申請(qǐng)表是否清晰、明確和完整性進(jìn)行審查，若發(fā)現(xiàn)變更不明確或不完整，應(yīng)返回申請(qǐng)者。對(duì)通過審查的變更申請(qǐng)分配變更ID，以便跟蹤和記錄變更信息。

2.4.3 評(píng)估變更

a． 配置管理員將《配置項(xiàng)變更控制報(bào)告》發(fā)送給項(xiàng)目經(jīng)理（或者其他授權(quán)人員），由項(xiàng)目經(jīng)理負(fù)責(zé)對(duì)變更進(jìn)行評(píng)估。

b． 項(xiàng)目經(jīng)理對(duì)變更進(jìn)行分解，一般的BUG修正不需要審批直接由項(xiàng)目經(jīng)理決定是否需要變更。新增功能或?qū)φ麄€(gè)項(xiàng)目影響重大的變更必須由研發(fā)總助審批通過后方可變更。變更評(píng)估文檔在完成變更評(píng)估后發(fā)送給配置管理員。

2.4.4 變更實(shí)施和確認(rèn)

a． 變更被批準(zhǔn)后，項(xiàng)目經(jīng)理提交變更實(shí)施進(jìn)度計(jì)劃，開發(fā)人員開始實(shí)施變更，并詳細(xì)記錄變更的內(nèi)容；質(zhì)量部對(duì)變更的實(shí)施進(jìn)行跟蹤。

b． 對(duì)于代碼變更，必須進(jìn)行回歸測(cè)試，以確保變更沒有引入新的Bug。另外與變更相關(guān)的文檔必須修訂，以反映變更。當(dāng)變更以及測(cè)試完成后，進(jìn)行提交。

c． 通過測(cè)試后，質(zhì)保人員需對(duì)變更進(jìn)行審核，審核的范圍一般涉及以下方面：測(cè)試記錄；變更請(qǐng)求；配置項(xiàng)的檢入及檢出；文件的命名；版本的編號(hào)。

a． 審核后，由配置管理員更新到基線庫中。2.5 配置狀態(tài)報(bào)告 2.5.1 目的

記錄和報(bào)告整個(gè)軟件生命周期演化狀態(tài)。2.5.2 記錄內(nèi)容

配置狀態(tài)報(bào)告記錄的內(nèi)容包括： 1)軟件和文檔的標(biāo)識(shí)； 2)目前狀態(tài)； 3)基線演化狀態(tài)； 4)變更狀態(tài)； 5)版本交付信息等。2.5.3 生成報(bào)告

配置管理報(bào)告自第一個(gè)基線創(chuàng)建時(shí)建立，由配置管理系統(tǒng)生成，及時(shí)反映當(dāng)前配置狀態(tài)。

2.6 配置審核 2.6.1 類別 配置審核分為：

1)功能配置審核（Functional Configuration Audit，F(xiàn)CA）：審核軟件功能是否與需求一致，并符合基線文檔要求，通常要審查測(cè)試文檔等。

2)物理配置審核（Physical Configuration Audit，PCA）：審核要交付的組成項(xiàng)是否存在，是否包含所有必需的項(xiàng)目，如正確版本的源代碼、資源、文檔、安裝說明等等。

2.6.2 執(zhí)行時(shí)機(jī)

通常選擇以下幾種情況由質(zhì)量保證人員負(fù)責(zé)實(shí)施配置審核： 1)軟件產(chǎn)品交付或是軟件產(chǎn)品正式發(fā)行前； 2)軟件開發(fā)的階段工作結(jié)束后； 3)在產(chǎn)品維護(hù)工作中，定期地進(jìn)行。2.6.3 不符合項(xiàng)處理

對(duì)配置審核中發(fā)現(xiàn)的不符合現(xiàn)象，配置管理員進(jìn)行記錄，并交由責(zé)任部門限期進(jìn)行糾正，配置管理員負(fù)責(zé)糾正措施的驗(yàn)證。所有的不符合項(xiàng)報(bào)告均關(guān)閉后，才能發(fā)布新版本。

2.7 發(fā)行管理

通過配置審核后，經(jīng)項(xiàng)目經(jīng)理批準(zhǔn)，由配置管理員負(fù)責(zé)生產(chǎn)新版本。2.7.1.1 交付管理

這里“交付”是指從配置庫中提取配置項(xiàng)，交付給客戶或項(xiàng)目外的人員。交付出去的配置項(xiàng)必須有據(jù)可查，避免發(fā)生混亂。流程如下：

1)交付人向質(zhì)量部申請(qǐng)；

2)質(zhì)量部如果不同意交付，則拒絕交付配置項(xiàng)。如果同意交付，配置管理員應(yīng)給出詳細(xì)的交付清單；

3)交付人驗(yàn)收后簽字。