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

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

姓名：李長璽 學號：S314080098

（一）項目實施方案概述

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

（二）項目實施方案介紹

1、項目啟動階段

此階段處于整個項目實施工作的最前期，由成立項目組、前期調(diào)研、編制總體項目計劃、啟動會四個階段組成。

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

成立項目組：

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

前期調(diào)研：

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

編制《項目總體計劃》：

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

啟動會：

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

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

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

1、進行需求調(diào)研準備

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

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

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

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

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

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

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

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

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

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

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

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

4、數(shù)據(jù)標準化初裝階段

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

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

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

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

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

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

3、簽署培訓計劃：用戶簽署《培訓計劃》，進一步確認培訓安排。

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

5、搭建培訓環(huán)境：公司項目組在培訓開始前，將培訓環(huán)境搭建及檢查妥當，將培訓提綱及培訓手冊準備好。

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

7、培訓考核：公司項目組培訓負責人與用戶實施負責人組織受訓人員參加上機及理論考試。

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

6、系統(tǒng)安裝測試及試運行階段

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

1、編制計劃：與用戶實施負責人商議具體測試及試運行時間、地點、人員等安排，項目組編制《測試及試運行計劃》。

2、簽署計劃：用戶簽署《測試及試運行計劃》，進一步確認測試及試運行安排。

3、發(fā)測試及試運行通知：在測試及試運行開始前2天，按照簽署的《測試及試運行計劃》，將時間，地點，人員等信息通知用戶實施負責人。

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

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

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

7、總體驗收階段

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

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

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

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

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

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

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

1.1 項目立項

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

研發(fā)項目立項報告模板.doc

1.2 立項評審

《項目立項報告》編寫完成后，交由項目管理委員會進行立項評審，評審通過后由副總經(jīng)理簽字確認立項。確定需求分析和項目設(shè)計階段的時間和人員安排。

1.3 需求分析

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

軟件需求說明書模板.doc

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

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

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

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

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

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

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

項目設(shè)計開發(fā)方案.docx。

1.5 項目設(shè)計評審

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

項目設(shè)計評審表.docx

1.6 編碼和測試用例編寫階段

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

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

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

1.8 結(jié)項評審與驗證

項目負責人和測試負責人分別填寫《項目結(jié)項評審表》，交由項目管理委員會進行評審。評審通過后，由研發(fā)中心副總經(jīng)理進行發(fā)布確認。

項目結(jié)項評審驗證表.doc

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

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

2，舊項目升級開發(fā)管理流程

舊項目的升級，依照如下流程：

2.1項目升級需求分析

項目需求分析，需要收集用戶在產(chǎn)品使用過程中，已經(jīng)技術(shù)人員在調(diào)試過程中的反饋作為需求分析的輸入。并填寫對應(yīng)的項目升級需求報告表。項目升級需求報告表.doc

2.2 升級評審

將《升級需求報告》交由項目管理委員會，評審通過后，進行升級設(shè)計。2.2項目升級設(shè)計

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

2.3 項目升級設(shè)計評審

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

2.4 編碼

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

2.5 測試

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

2.6 升級輸出評審

項目負責人和測試負責人分別填寫《項目結(jié)項評審表》，交由項目管理委員會進行評審。評審通過后，由副總經(jīng)理進行發(fā)布確認后。

第三篇：軟件項目變更管理流程

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

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

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

Confidential

Page 1 1 概述

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

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

對項目的變更管理是通過對以下五個關(guān)鍵步驟的實施引入的。，: ? 提交和接收變更申請 ? 審核和記錄變更申請 ? 確定變更申請的可行性 ? 批準變更申請

? 實施和結(jié)束變更申請變更流程

對將要執(zhí)行的流程和程序做一個圖表概述，以啟動、實施項目中的變更并審核其效果。例如：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 概要

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

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 提交變更申請

本步驟中項目團隊中的任何成員都可以提交項目變更申請，需要完成以下工作：

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

? 變更描述

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

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

2.3 審核變更申請

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

? 呈交的可選擇變更數(shù)目Number of change options presented ? 申請變更可選反性的復雜程度Complexity of the change options requested ? 提出的變更解決方案的衡量Scale of the change solutions proposed 變更經(jīng)理將不會在變更日志中打開一份變更申請并記錄是否需要一個變更可行性研究。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 識別變更可行性

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

? 變更需求

? 變更可選項Change options ? 變更成本及利益

? 變更風險及事項Change risks and issues ? 變更帶來的影響 ? 變更的建議和計劃

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

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

2.5 批準變更申請

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

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

決定是否變更的標準大致為：

? 實施變更給項目帶來的風險 ? 不實施變更給項目帶來的風險

? 實施變更對項目產(chǎn)生的影響（時間、資源、財務(wù)、質(zhì)量方面）?

2.6 實施變更申請

本步驟涉及對變更的全面實施，包括: ? ? ? ? ? ? 確定變更進度（如：實施變更的日期）

實施前對變更進行測試Testing the change prior to implementation 實施變更

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

對項目中啟動、審核和實施變更所涉及的所有資源（包括項目中或項目之外的資源）的職責和責任進行定義，如：

3.1 變更申請人

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

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

3.2 變更經(jīng)理

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

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

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

? 對所有的變更申請進展情況進行監(jiān)測以確保項目按時完成 ? 將所有的變更申請問題和風險上報變更審批小組 ? 就變更審批小組做出的所有決定進行下達和溝通

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

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

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

3.4 變更審批小組

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

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

? 根據(jù)每個變更申請的相關(guān)價值決定批準還是拒絕 ? 解決變更爭議（當兩個或兩以上變更撞車時）? 解決變更問題Resolving change issues ? 決定實施變更時間表

3.5 變更實施小組

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

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

插入所需的每個模版（如變更申請表）以對項目中變更的效果加以啟動、執(zhí)行、實施和考量。

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

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

V1.0 2017/9/14

1、目的

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

2、范圍

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

3、發(fā)布人員

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

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

4、發(fā)布流程

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

一、提交測試

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

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

c)測試人員通過自動化部署平臺根據(jù)提供的分支號依照上線方案進行自動化部署，涉及數(shù)據(jù)庫操作可提請DBA操作。

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

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

二、預熱發(fā)布

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

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

三、正式上線

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

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

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

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

五、總結(jié)報告

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

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

1、BUG修復開發(fā)自測提交測試申請

1、上線方案

2、其他上線文檔確認測試版本

1、內(nèi)容無誤

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

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

概述 1.1 目的

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

1.2 適用范圍

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

1.3 術(shù)語和縮略語

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

1.3.2 配置項（Configuration Item，CI）

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

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

1.3.3 基線（Baseline）

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

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

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

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

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

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

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

5)配置管理工具的日常管理與維護； 6)配置庫的日常操作和維護； 7)負責配置審核并提交報告；

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

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

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

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

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

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

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

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

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

結(jié)合SPP和ISO9000的相關(guān)規(guī)定，配置管理員根據(jù)配置管理規(guī)范及配置管理計劃，對配置項進行分階段管理，每一階段正式評審通過后納入受控庫，作為該項目的一個基線。

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

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

l 項目計劃：需求分析完成后即可制定項目的開發(fā)計劃，包括項目計劃和主要下屬計劃。包括項目進度計劃、配置管理計劃、質(zhì)量保證計劃、測試計劃、項目階段性計劃。項目開發(fā)計劃評審通過后，建立項目計劃基線。

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

l 測試：單元測試和系統(tǒng)測試。單元測試通過提交《單元測試報告》，項目啟動后應(yīng)提交《系統(tǒng)測試計劃》，系統(tǒng)測試完成后應(yīng)提交《系統(tǒng)測試報告》。配置時應(yīng)說明測試的版本與編碼版本的對應(yīng)關(guān)系。系統(tǒng)測試完成后建立測試基線。

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

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

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

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

2)與客戶或項目組內(nèi)部重要的交互信息記錄，如會議記錄、會談記錄、e-mail和MSN記錄等；

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

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

2.2.1.1 版本變化型文檔

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

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

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

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

l [版本號]：采用[Vs_x_y]的形式。

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

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

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

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

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

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

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

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

示 例：周例會會議紀要20030901.doc 2.2.1.3 時間序號型文檔

命名方式：[文檔名稱+人員姓名（拼音）+撰寫時間+序列號] 適用文檔：測試報告

示例：單元測試報告_lixiaohong_20071112_01.dco 2.2.1.4 其他文檔：

對于不能按照前四種類型進行命名的文檔 會議紀要：會議紀要YYYYMMDD()示 例：9月9日召開的項目啟動會 命名為：會議紀要20030909(項目啟動).doc 評審報告：評審報告YYYYMMDD()同”會議紀要”要求一致。

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

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

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

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

版本類型：分為3種

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

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

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

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

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

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

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

? 文檔評審通過后，文檔嚴格受控。由配置管理員將通過評審后的文檔移植到基線庫里同時將該配置項從開發(fā)庫移除。

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

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

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

2.3.3 分配權(quán)限

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

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

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

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

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

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

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

圖2 變更控制流程 2.4.2 變更請求的提出

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

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

2.4.3 評估變更

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

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

2.4.4 變更實施和確認

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

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

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

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

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

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

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

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

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

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

2.6.2 執(zhí)行時機

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

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

2.7 發(fā)行管理

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

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

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

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

3)交付人驗收后簽字。