配置管理規(guī)范V1.0

第2頁共22頁第1頁共22頁文檔編號XX_運(yùn)維_0041版本號V1.0密級內(nèi)部公開配置管理規(guī)范XXX信息技術(shù)有限公司

版本控制編號修訂人修訂時間版本號修訂內(nèi)容說明

目錄1 引言 41.1 編寫目的 41.2 范圍 41.3 定義 41.4 工作表格 42 配置管理基本規(guī)則 52.1 配置項(xiàng)命名規(guī)則 52.1.1文檔命名 52.1.2基線命名 62.1.3分支命名 62.1.4產(chǎn)品（代碼）命名 72.2 角色和職責(zé) 73 配置管理工作流程 83.1 制定配置管理計劃 93.2 識別配置項(xiàng) 93.3 配置庫管理 93.3.1建立項(xiàng)目配置庫 93.3.2配置庫結(jié)構(gòu) 103.3.3配置庫的維護(hù)和備份 103.4 基線管理 103.5 產(chǎn)品版本和發(fā)布 113.5.1文檔版本和發(fā)布 113.5.2代碼版本和發(fā)布 123.5.3產(chǎn)品發(fā)布注意事項(xiàng) 153.6 變更控制 173.7 配置狀態(tài)統(tǒng)計及配置審計 183.7.1配置狀態(tài)統(tǒng)計 183.7.2配置審計 19

引言編寫目的指導(dǎo)配置管理工作，確保軟件產(chǎn)品研發(fā)過程中的所有成果在其生命周期中的完整性、一致性和可追溯性。范圍適用于公司所有項(xiàng)目的配置管理工作。定義基線：軟件開發(fā)過程中的里程碑，它以一或多個軟件配置項(xiàng)的交付為標(biāo)志。基線由已經(jīng)通過正式評審和批準(zhǔn)的某規(guī)約或產(chǎn)品組成，它可以作為進(jìn)一步開發(fā)的基礎(chǔ)，并且只能通過正式的變更控制過程才能夠改變。工作表格《XXX_配置管理計劃》《XXX_配置庫結(jié)構(gòu)》《XXX_基線發(fā)布說明》《XXX_版本發(fā)布記錄》《XXX_變更申請表》配置管理基本規(guī)則配置項(xiàng)命名規(guī)則通用的配置項(xiàng)命名規(guī)則如下：所屬平臺_子系統(tǒng)名（產(chǎn)品名）_配置類別+版本號_附屬信息說明：所屬平臺，如YP2G，YP3G，YPOPEN。在工作中為避免繁瑣，可在工程中省略所屬平臺。子系統(tǒng)名按照項(xiàng)目對其的定義。產(chǎn)品名遵循現(xiàn)行公司對產(chǎn)品名稱的定義。配置類別用于文檔和基線的命名，詳見2.1.1和2.1.2。版本號為VX.Y.Z或VX.Y。命名產(chǎn)品時，使用VX.Y.Z，其中X是大版本號，Y是次版本號，Z是小版本號。大版本號對應(yīng)50%以上或整體性的變動，次版本號對應(yīng)50%以下小功能的調(diào)整，小版本號對應(yīng)缺陷修復(fù)、優(yōu)化。命名文檔和基線時，使用VX.Y，其中X是大版本號，Y是小版本號。大版本號對應(yīng)50%以上或整體大變動，小版本號對應(yīng)50%以下的內(nèi)容調(diào)整。當(dāng)高位變化時，低位清零。產(chǎn)品第一次發(fā)布版本號為V1.0.0，在發(fā)布之前初始版本號為V0.0.1。文檔和基線在通過第一次評審后版本號為V1.0。附屬信息，如測試分支test_日期。文檔命名技術(shù)或管理文檔所屬平臺_子系統(tǒng)名（產(chǎn)品名）_配置類別VX.Y所屬平臺：二代平臺YP2G、三代平臺YP3G、開放平臺YPOPEN子系統(tǒng)名（產(chǎn)品名）可用中文名字漢語拼音首字母，如ZDZH是賬單整合產(chǎn)品名的縮寫。配置類別配置類別命名配置類別命名用戶手冊UMF項(xiàng)目任務(wù)書PT操作手冊O(shè)PM項(xiàng)目計劃PP業(yè)務(wù)需求CRM配置管理計劃CMP軟件需求規(guī)格SRS質(zhì)量保證計劃QAP總體設(shè)計方案ODPQA不符合報告QAR數(shù)據(jù)庫設(shè)計DBD數(shù)據(jù)DA概要設(shè)計HLD源碼無詳細(xì)設(shè)計DDS開發(fā)環(huán)境DE工程實(shí)施方案PIP發(fā)布計劃RP測試報告STR發(fā)布說明RM系統(tǒng)運(yùn)維手冊SOM第三方代碼THC系統(tǒng)應(yīng)急手冊SEM測試代碼TC運(yùn)維管理制度OMS安全管理制度SMS安全審計報告SAR記錄（不屬于配置項(xiàng)范疇）所屬平臺_子系統(tǒng)名（產(chǎn)品名）_文件名稱_創(chuàng)建日期基線命名所屬平臺_產(chǎn)品名（子系統(tǒng)名）_配置類別VX.Y，可視情況剪裁。配置類別命名配置類別命名需求基線Require設(shè)計基線Design發(fā)布基線Release分支命名開發(fā)分支：dev_日期_內(nèi)容測試分支：test_日期發(fā)布分支：release_日期產(chǎn)品（代碼）命名二代平臺產(chǎn)品：（在三代未上線前，可省略YP2G）1、行業(yè)應(yīng)用產(chǎn)品所屬平臺_產(chǎn)品名VX.Y.Z，如YP2G_eposV1.0.02、平臺產(chǎn)品平臺名VX.Y.Z，如YE2PV1.0.0其他平臺產(chǎn)品：所屬平臺_子系統(tǒng)名VX.Y.Z，如YP3G_accountV1.0.0在描述子系統(tǒng)一級下的配置項(xiàng)時，可省略所屬平臺，直接以子系統(tǒng)名VX.Y.Z為標(biāo)識即可。角色和職責(zé)角色職責(zé)系統(tǒng)負(fù)責(zé)人制定項(xiàng)目計劃、版本計劃、基線計劃；識別配置項(xiàng)，提供配置庫結(jié)構(gòu)、項(xiàng)目組人員權(quán)限；版本和變更控制；確認(rèn)基線中配置項(xiàng)；確認(rèn)變更；進(jìn)行配置審計。產(chǎn)品人員提交需求、設(shè)計相關(guān)配置項(xiàng)；確認(rèn)變更。開發(fā)人員提交代碼及相關(guān)配置項(xiàng)；確認(rèn)變更。配置管理員建立、維護(hù)、備份配置庫；協(xié)助版本和變更控制；發(fā)布基線操作；進(jìn)行配置項(xiàng)狀態(tài)統(tǒng)計和配置審計。質(zhì)量保證人員監(jiān)控配置管理活動過程的遵循情況。配置管理工作流程制定配置管理計劃配置管理員根據(jù)項(xiàng)目計劃，按照配置管理計劃模板撰寫配置管理計劃，對人員及職責(zé)、配置管理軟硬件資源、配置項(xiàng)計劃、基線計劃、配置庫備份計劃等內(nèi)容進(jìn)行明確。配置管理計劃需經(jīng)過項(xiàng)目組一致確認(rèn)，達(dá)成工作共識。識別配置項(xiàng)配置項(xiàng)的特點(diǎn)：交付或非交付的產(chǎn)品、工作產(chǎn)品或工具；可能被兩個或更多小組/人共享的工作產(chǎn)品；隨時間改變的工作產(chǎn)品；具有相互依賴性的工作產(chǎn)品，其中一個改變時將會影響其他工作產(chǎn)品；重要性高的工作產(chǎn)品。因此，軟件研發(fā)過程中所產(chǎn)生的工作產(chǎn)品可以分為配置項(xiàng)和支持性記錄兩大類。支持性記錄是在軟件項(xiàng)目中不重要的，而且一旦生成就不會再修改的，例如：會議紀(jì)要、周報等。項(xiàng)目中常見的配置項(xiàng)有：業(yè)務(wù)需求說明、軟件需求說明、架構(gòu)設(shè)計說明、概要設(shè)計說明、詳細(xì)設(shè)計說明、項(xiàng)目計劃、測試計劃、測試用例、測試腳本、源代碼、數(shù)據(jù)、開發(fā)環(huán)境、測試環(huán)境……在進(jìn)行項(xiàng)目計劃的工作時，要對項(xiàng)目的配置項(xiàng)進(jìn)行識別，并通過配置管理計劃描述對配置項(xiàng)的具體管理工作。配置庫管理建立項(xiàng)目配置庫每個項(xiàng)目開始前期，由配置管理員為項(xiàng)目建立項(xiàng)目專用配置庫，包括開發(fā)庫、受控庫和產(chǎn)品庫。項(xiàng)目負(fù)責(zé)人負(fù)責(zé)規(guī)劃配置庫結(jié)構(gòu)和定義人員權(quán)限，由配置管理員實(shí)施。對于文檔來說，開發(fā)庫存儲文檔草稿，受控庫存儲評審?fù)ㄟ^的文檔，發(fā)布庫存儲隨基線發(fā)布的文檔。對于代碼來說，分為以下兩種方式：二代平臺，開發(fā)庫中內(nèi)容為開發(fā)分支代碼，受控庫中內(nèi)容為測試分支代碼，發(fā)布庫中內(nèi)容為主干即平臺代碼。其中，三庫中代碼為標(biāo)簽方式邏輯存儲。三代平臺，開發(fā)庫中內(nèi)容為子系統(tǒng)主干代碼，受控庫中內(nèi)容為測試分支代碼，發(fā)布庫中內(nèi)容為發(fā)布的基線和產(chǎn)品代碼。配置庫結(jié)構(gòu)詳見《XXX_配置庫結(jié)構(gòu)V1.0》。配置庫的維護(hù)和備份系統(tǒng)負(fù)責(zé)人定期清理開發(fā)庫的垃圾文件。配置管理員負(fù)責(zé)維護(hù)配置庫中各區(qū)域的訪問權(quán)限，確保只有被授權(quán)的人員才有權(quán)訪問相應(yīng)的項(xiàng)目庫。配置管理員每周進(jìn)行配置庫的備份，此備份文件至少保持三周以上。要保證當(dāng)系統(tǒng)出現(xiàn)災(zāi)難時，系統(tǒng)可以恢復(fù)到災(zāi)難以前的狀態(tài)?；€管理基線是已經(jīng)正式通過復(fù)審和批準(zhǔn)的某規(guī)約或產(chǎn)品，它因此可作為進(jìn)一步開發(fā)的基礎(chǔ)，并且只能通過正式的變化控制過程改變?；€的初始創(chuàng)建和發(fā)布通常在項(xiàng)目生命周期某個階段的結(jié)束時，主要對需求基線、設(shè)計基線和發(fā)布基線進(jìn)行管理?；€的建立與發(fā)布過程如下：開發(fā)人員按配置項(xiàng)命名規(guī)則，對配置項(xiàng)進(jìn)行標(biāo)識。根據(jù)配置管理計劃，在項(xiàng)目生命周期某個階段的結(jié)束時，基線按規(guī)定的批準(zhǔn)權(quán)限被批準(zhǔn)建立。當(dāng)配置項(xiàng)進(jìn)入配置控制（打標(biāo)簽或庫間轉(zhuǎn)移），開發(fā)或變更此配置項(xiàng)的人員必須確保相應(yīng)的質(zhì)量檢查活動（如：同行評審、測試等）已經(jīng)執(zhí)行。并向配置管理員提供批準(zhǔn)的《變更申請表》。配置管理員應(yīng)在接受配置項(xiàng)之前，對其應(yīng)做的質(zhì)量檢查是否完成進(jìn)行驗(yàn)證，并確保配置項(xiàng)均已正確標(biāo)識。配置管理員對基線所包含的配置項(xiàng)進(jìn)行檢查，主要檢查配置項(xiàng)的版本是否與變更后的基線下版本一致。配置管理員將該基線的所有配置項(xiàng)打標(biāo)簽入發(fā)布庫。配置管理員應(yīng)在《基線發(fā)布說明》中記錄相關(guān)信息，包括基線的配置項(xiàng)標(biāo)識、名稱、內(nèi)容、版本等。配置管理員應(yīng)將《基線發(fā)布說明》通報所有相關(guān)人員，并使有權(quán)使用的人員可以獲得當(dāng)前發(fā)布基線的配置項(xiàng)。在基線建立時，配置管理員應(yīng)進(jìn)行配置狀態(tài)統(tǒng)計，具體內(nèi)容參見配置狀態(tài)統(tǒng)計。產(chǎn)品版本和發(fā)布文檔版本和發(fā)布文檔版本變更，必須在文檔中的“文檔修訂記錄”中填寫詳細(xì)信息。包括日期、版本、內(nèi)容和作者。其中版本按照配置項(xiàng)命名規(guī)則中文檔版本號規(guī)定填寫，內(nèi)容為“創(chuàng)建”或本次變更的具體內(nèi)容（具體章節(jié)和內(nèi)容的變化）。文檔版本號X變更必須經(jīng)過評審。代碼版本和發(fā)布二代平臺二代平臺主要圍繞上線流程進(jìn)行的行業(yè)應(yīng)用產(chǎn)品及平臺代碼的維護(hù)工作，因此用流程圖的形式說明具體的版本管理操作內(nèi)容。三代平臺三代平臺開發(fā)過程采取分類說明的方式，定義分支和內(nèi)控版本及發(fā)布的操作。其他在三代平臺上線之前，對二代平臺的任何維護(hù)工作，在命名時（分支、標(biāo)簽、產(chǎn)品）可不用YP2G_作為前綴。在二代平臺切換到三代平臺期間，兩系統(tǒng)并行時，需要將二代平臺相關(guān)命名（分支、標(biāo)簽、產(chǎn)品），用前綴標(biāo)識，加以區(qū)分所屬平臺。二代平臺采取穩(wěn)定主干策略的維護(hù)工作，流程如下圖：操作說明：上線單為版本變更的依據(jù)。上線單的內(nèi)容可能是新功能，也可能是缺陷修改。如果是新功能，則須同時提交需求文檔。如果是缺陷修改，須提供缺陷號。上線單由項(xiàng)目負(fù)責(zé)人提交，遵循產(chǎn)品版本和平臺代碼版本的變更規(guī)則，命名規(guī)則：產(chǎn)品名VX.Y.Z+1或YP2GVX.Y.Z+1產(chǎn)品版本變更規(guī)則對照表：上線內(nèi)容變更規(guī)則（在上線單中描述）只是對缺陷的修改：產(chǎn)品名VX.Y.Z+1上線內(nèi)容新加了功能：產(chǎn)品名VX.Y+1.Z既有新功能又有缺陷修改：產(chǎn)品名VX.Y+1.Z對產(chǎn)品的改版：產(chǎn)品名VX+1.Y.Z平臺代碼變更規(guī)則對照表：對外發(fā)布變更規(guī)則發(fā)布的n張上線單內(nèi)容皆為缺陷修改：YP2GVX.Y.Z+1發(fā)布的n張上線單內(nèi)容新加了功能：YP2GVX.Y+1.Z發(fā)布的n張上線單內(nèi)容既有新功能又有缺陷修改：YP2GVX.Y+1.Z整體調(diào)優(yōu)：YP2GVX+1.Y.Z配置管理員選取當(dāng)前較為穩(wěn)定的主干代碼定義為YP2GV1.0.0。行業(yè)應(yīng)用產(chǎn)品版本的演變導(dǎo)致平臺代碼版本的演變。對行業(yè)應(yīng)用產(chǎn)品版本和平臺代碼版本建立關(guān)聯(lián)，即在行業(yè)應(yīng)用產(chǎn)品發(fā)布時，由配置管理員填寫產(chǎn)品的《版本發(fā)布記錄》。在每日進(jìn)行對外發(fā)布時，配置管理員還要完成平臺代碼的版本發(fā)布，包括平臺代碼版本和目前的《上線公告》。配置管理員在主干創(chuàng)建測試分支，命名為：test_日期，如test_20101021。開發(fā)人員按照產(chǎn)品本次開發(fā)的內(nèi)容，從主干提取代碼創(chuàng)建開發(fā)分支并進(jìn)行自測。開發(fā)分支命名為：dev_日期_內(nèi)容（功能或bug號）。之后把完成這次任務(wù)的所有代碼或配置全部提交到測試分支。提交時填寫注釋信息，并附代碼清單。代碼清單舉例：代碼清單命名：提交人_日期_內(nèi)容（功能或bug號）代碼清單內(nèi)容：wanghaiyang_20101011_paizhaoSetment/YP2G_boss_oltp/webapps/boss_oltp.war/jsp/customer/SatSumByYeGuan.jsp配置人員按照增量的形式在測試分支上按照技術(shù)提交的代碼清單提取文件，并編譯打包部署到測試服務(wù)器。測試人員及時更新本地測試代碼進(jìn)行測試，提交bug。開發(fā)人員收到bug通知，在開發(fā)分支進(jìn)行修改，再次提交測試分支。測試通過后，由配置管理員從主干上創(chuàng)建發(fā)布分支。發(fā)布分支命名為：release_日期。配置管理員按照測試結(jié)果，提取開發(fā)分支代碼合并到發(fā)布分支。發(fā)布分支運(yùn)行穩(wěn)定沒有問題，由配置管理員合并到主干，平臺代碼版本變更，如：YP2GV1.0.1。公司目前二代產(chǎn)品主干尚不穩(wěn)定，但已作為穩(wěn)定主干進(jìn)行日常維護(hù)，因此，應(yīng)定義主干版本。隨著配置組協(xié)調(diào)開發(fā)人員不斷對主干進(jìn)行修正，二代主干運(yùn)行版本會不斷變化，配置管理員記錄行業(yè)應(yīng)用產(chǎn)品與主干版本之間的關(guān)聯(lián)，即YP2GVX.Y.Z與產(chǎn)品名VX.Y.Z的關(guān)聯(lián)（見《版本發(fā)布記錄》）。三代平臺開發(fā)過程采取不穩(wěn)定主干策略。操作說明：子系統(tǒng)從開始創(chuàng)建到之后的升級都在trunk下開發(fā)，trunk為開發(fā)庫。每天進(jìn)行每日構(gòu)建工作。構(gòu)建是自動將源代碼的目錄，子目錄，文件的位置以代碼樹的形式固定下來。一般是每日自動構(gòu)建代碼樹。如果單元測試和自動化測試運(yùn)行通過后，會對主干上的代碼打個tag，命名方式為：子系統(tǒng)名VX.Y.Z_build_日期，如accountV1.0.0_build_20101028，以打標(biāo)簽的形式標(biāo)記。有時候進(jìn)行構(gòu)建的也可以是分支，構(gòu)建即對分支打tag。當(dāng)子系統(tǒng)要發(fā)布一個版本，但又不想停止開發(fā)進(jìn)程，這時候需要創(chuàng)建一個分支到branches目錄下，命名為子系統(tǒng)名_test_日期，對該分支進(jìn)行驗(yàn)收測試，開發(fā)人員在這個分支上修改代碼，保證代碼滿足發(fā)布要求。確定可以發(fā)布后，創(chuàng)建標(biāo)簽，命名為：子系統(tǒng)名VX.Y.Z，同時把該分支上的代碼合并回主干。有某個版本上線，需要針對上線的程序進(jìn)行維護(hù)。這種情況下需要從發(fā)布版的標(biāo)簽創(chuàng)建一個分支到branches目錄下，分支命名為：dev_日期_內(nèi)容，維護(hù)工作在分支上進(jìn)行。定期把該分支上的內(nèi)容合并回主干。針對一個新的應(yīng)用或行業(yè)（比如稱作應(yīng)用A），該子系統(tǒng)功能需要一些調(diào)整（但調(diào)整還不足以需要另外開發(fā)），同時該子系統(tǒng)原有的功能還在被使用。這種情況下需要從某個特定的發(fā)布版本創(chuàng)建出分支到branches目錄下，把那個分支當(dāng)作針對應(yīng)用A開發(fā)的主干。發(fā)布子系統(tǒng)時，將版本命名為：子系統(tǒng)名VX.Y.Z，如accountV1.0.0。子系統(tǒng)發(fā)布后將代碼存入發(fā)布庫，填寫《版本發(fā)布記錄》。產(chǎn)品發(fā)布注意事項(xiàng)軟件產(chǎn)品的每個版本都是一組配置項(xiàng)（源代碼、文檔、數(shù)據(jù)）的集合。要發(fā)布軟件的某個版本，就要把源代碼、文檔、數(shù)據(jù)中所有應(yīng)該包含到這個版本中的正確配置項(xiàng)檢出。發(fā)布原則：當(dāng)產(chǎn)品的可靠性介于最優(yōu)與客戶可接受兩者之間，發(fā)布。發(fā)布時，項(xiàng)目負(fù)責(zé)人、產(chǎn)品人員、開發(fā)負(fù)責(zé)人和測試負(fù)責(zé)人一致確認(rèn)，該產(chǎn)品才能發(fā)布。發(fā)布時配置管理人員完成產(chǎn)品發(fā)布說明。軟件產(chǎn)品發(fā)布的流程如下：1、發(fā)布準(zhǔn)備開發(fā)人員先要確定發(fā)布的準(zhǔn)備工作和發(fā)布的日期，開始OA上線單流程操作。準(zhǔn)備工作應(yīng)包含以下內(nèi)容：原有BUG是否徹底解決；新增模塊在功能上是否達(dá)到設(shè)計要求；修改了什么，增加了什么；所做的改變帶來的影響。2、撰寫文檔開發(fā)人員確定所發(fā)布內(nèi)容中是否有新增功能。若有，則需撰寫一份需求文檔，交給測試人員，否則修改bug狀態(tài)，告知測試人員。需求文檔的內(nèi)容如下：所做的改動有哪些；修改原有BUG或新增模塊的設(shè)計目標(biāo)。3、全面測試測試人員在收到測試單或需求文檔后，應(yīng)進(jìn)行全面、完善的測試。如果通過測試，繼續(xù)OA流程（流程見公司上線單流程），并修改BUG狀態(tài)。4、發(fā)布確認(rèn)所有程序由測試人員進(jìn)行確認(rèn)測試后,若發(fā)現(xiàn)JIRA中所有bug都已經(jīng)被修正，或者遺留的bug不影響系統(tǒng)的使用，則由項(xiàng)目負(fù)責(zé)人審核BUG解決情況或新增模塊使用情況，如果符合要求，則準(zhǔn)許發(fā)布,如果有嚴(yán)重bug未解決（級別為必須修正）則不能發(fā)布；5、質(zhì)量認(rèn)定測試人員編寫發(fā)布版本測試報告進(jìn)行分析和總結(jié)。6、源碼、文檔入發(fā)布庫配置管理員進(jìn)行程序打包；標(biāo)記源碼、文檔版本tag。源碼包括數(shù)據(jù)庫創(chuàng)建腳本（含靜態(tài)數(shù)據(jù)）、編譯構(gòu)建腳本和所有源代碼；文檔包括需求、設(shè)計、測試文檔，安裝手冊、使用手冊、產(chǎn)品介紹（ppt）等。7、發(fā)布產(chǎn)品新建產(chǎn)品發(fā)布計劃，填寫配置項(xiàng)，執(zhí)行發(fā)布計劃（發(fā)布產(chǎn)品）。8、編寫發(fā)布說明編寫發(fā)布說明，包括產(chǎn)品版本說明；產(chǎn)品概要介紹；本次發(fā)布包含的文件包、文檔說明；本次發(fā)布包含或者新增的功能特性說明；遺留問題及影響說明；版權(quán)聲明以及其他需要說明的事項(xiàng)。9、正式發(fā)布通知通知開發(fā)、測試、市場、銷售各相關(guān)部門并附上產(chǎn)品發(fā)布說明和產(chǎn)品介紹。10、后續(xù)工作產(chǎn)品發(fā)布后，在使用過程中可能還會發(fā)現(xiàn)一些bug。在不影響正常使用的情況下，這些bug將在下一版本發(fā)布時解決；如果bug嚴(yán)重影響使用，必須打patch或者按照流程重新發(fā)布。11、臨時發(fā)布軟件產(chǎn)品未正式發(fā)布前，可能需要一個臨時版本供開發(fā)人員或者用戶應(yīng)急使用，這時候需要臨時發(fā)布一個版本。這個版本只包括基本的程序包和必要的使用說明。臨時發(fā)布需要通知相關(guān)開發(fā)、測試人員；配置管理員需要為源碼、文檔打tag標(biāo)記。變更控制當(dāng)發(fā)生變更時，項(xiàng)目組任何一個環(huán)節(jié)的工作人員要修改工作產(chǎn)品時，都要依據(jù)審批通過的變更申請執(zhí)行相應(yīng)操作。變更必須履行申請、影響分析、審批和結(jié)果驗(yàn)證的過程。原則上，誰要求修改誰提變更申請，描述修改的內(nèi)容、引起的影響。當(dāng)修改涉及其他部門工作，應(yīng)交由相關(guān)人員會簽。變更申請由項(xiàng)目負(fù)責(zé)人或變更控制委員會批準(zhǔn)才可實(shí)施。實(shí)施修改前，應(yīng)作出全面的修改設(shè)計分析，明確修改需求、目的和要求。根據(jù)成本效益和涉及的技術(shù)、條件等因素判斷變更實(shí)施的必要性。變更實(shí)施時，不僅要對要修改的內(nèi)容進(jìn)行修改，還要注意文檔的修訂。變更實(shí)施后，在變更申請中填寫變更內(nèi)容、更改部位和更改結(jié)果。由項(xiàng)目負(fù)責(zé)人或產(chǎn)品人員或技術(shù)負(fù)責(zé)人驗(yàn)證變更結(jié)果，在變更申請中填寫確認(rèn)意見。配置管理員審計變更過程及對變更結(jié)果進(jìn)行配置管理。配置狀態(tài)統(tǒng)計及配置審計配置狀態(tài)統(tǒng)計在配置項(xiàng)被創(chuàng)建后，配置管理人員就要將配置項(xiàng)的信息記錄在配置狀態(tài)報告中，主要記錄發(fā)生了什么事、誰做的此事、此事是什么時候發(fā)生的、為什么做此事。當(dāng)配置項(xiàng)發(fā)生變更后要及時更新配置狀態(tài)報告中相關(guān)信息。按照項(xiàng)目需要，配置管理員生成《配置狀態(tài)統(tǒng)計報告》，報告所有配置項(xiàng)以及變更請求的狀態(tài)，通過量化的數(shù)據(jù)和報表反映項(xiàng)目開發(fā)進(jìn)度的狀態(tài)。配置審計軟件配置項(xiàng)在每次主要的發(fā)布之前，需要經(jīng)過審計以保證其完整性與正確性；軟件配置審計后，被審計通過納入基線的配置項(xiàng)需按照發(fā)布流程通知相關(guān)人員，以保證發(fā)布的內(nèi)容的正確性及相關(guān)人員能得到正確的軟件配置項(xiàng)。在軟件配置管理過程中需要完成兩類審計活動：技術(shù)評審與配置審計。本文只對配置審計進(jìn)行描述，有關(guān)技術(shù)評審工作指導(dǎo)，參見軟件開發(fā)過程質(zhì)量文件。軟件配置審計主要針對軟件基線的完整性進(jìn)行審計。對不同的基線，審計內(nèi)容不同。以下分別說明：需求基線審計需求基線的審計是在需求基線通過批準(zhǔn)建立后，由配置管理員在受控庫中對需求基線下的配置項(xiàng)進(jìn)行完整性和一致性的審計。如審計不合格，將返給產(chǎn)品經(jīng)理進(jìn)行修正。如審計通過，由配置管理員在受控庫中將需求基線下配置項(xiàng)入發(fā)布庫。開始時間：需求基線建立。責(zé)任人：配置管理員輸入內(nèi)容：業(yè)務(wù)需求說明、軟件產(chǎn)品需求規(guī)格說明及相關(guān)成果輸出內(nèi)容：配置審計報告操作步驟：在需求經(jīng)過正式評審后通過批準(zhǔn)建立需求基線，由配置管理員對需求基線進(jìn)行審計。配置管理員從受控庫中檢出最新版本的需求基線下的配置項(xiàng)，檢查需求文檔的更新日志是否正確記錄了每次的修改信息