配置管理規(guī)范

文件編碼文件密級最新發(fā)布日期當(dāng)前版本XX軟件股份有限公司配置管理規(guī)范鄭重聲明：XX軟件股份有限公司版權(quán)所有。本文檔中任何部分未經(jīng)XX軟件股份有限公司書面授權(quán)，不得將材料泄露給第三方，不得以任何手段、任何形式進行復(fù)制與傳播。變更履歷版本日期變更位置變更理由/變更內(nèi)容變更人備注1.0新建，將原配置管理規(guī)范、OSSP中的配置管理規(guī)程進行整合，并結(jié)合目前公司要求。

目錄1 概述 22 術(shù)語定義 23 適用范圍 34 閱讀對象 35 配置管理計劃 35.1 配置管理計劃流程圖 45.2 配置管理計劃流程說明 46 配置管理軟硬件資源確定 56.1 配置管理服務(wù)器 56.2 配置管理工具 67 配置項/文檔管理 77.1 配置項識別 77.2 配置項編寫及命名 87.3 配置項入庫 88 配置庫目錄結(jié)構(gòu)規(guī)劃 89 權(quán)限管理 99.1 用戶角色定義 99.2 配置庫操作定義 109.3 配置庫授權(quán)控制參考 109.4 注意事項 1010 基線管理 1110.1 基線計劃制定 1110.2 基線建立時機 1110.3 基線建立流程 1210.4 基線命名規(guī)范 1311 分支合并管理 1311.1 分支建立 1411.1.1 分支建立時機 1411.1.2 分支建立模式 1411.2 分支合并 1411.2.1 分支合并類型 1411.2.2 版本庫發(fā)布模式 1512 代碼集成管理 1513 發(fā)布管理 1613.1 正式版本發(fā)布 1613.2 測試版本發(fā)布 1713.3 臨時版本發(fā)布 1714 變更管理 1814.1 變更控制 1814.2 變更流程 1914.3 變更結(jié)束準則 2015 備份/還原管理 2016 生效 2017 參考及附錄 20

概述配置管理（CM）的目的是協(xié)調(diào)軟件開發(fā)過程、對項目生命周期過程中各種階段產(chǎn)品的演化和變更進行管理、使混亂（一旦發(fā)生，其代價通常都很大）減至最小，從而保證軟件工作產(chǎn)品的一致性和完整性。從變更的意義講，配置管理要解決變更標識、變更控制以及變更發(fā)布的問題。配置管理是項目質(zhì)量管理的重要組成部分，在控制由多人參與項目所生成的大量工作產(chǎn)品時，配置管理過程規(guī)范化至關(guān)重要。本文檔的編寫目的是統(tǒng)一軟件配置管理規(guī)范，為配置管理活動提供指導(dǎo)。配置管理活動主要遵循以下原則：受控：公司所有產(chǎn)品/項目產(chǎn)生的所有工作成果（即信息資產(chǎn)，也體現(xiàn)為配置項）都必須納入公司統(tǒng)一管理之下，并接受公司級配置管理的監(jiān)控。安全：所有工作成果都必須存放在配置庫，配置庫需配備相應(yīng)的安全管理措施，包括訪問控制、備份/還原等。一致：所有工作成果各階段版本都應(yīng)該提交到配置庫中，而且其內(nèi)容是一致的，比如工作成果中參考或引用的其他工作成果的正確版本是否存在配置庫中或者是否提供了訪問鏈接。完整：配置庫中存放的工作成果應(yīng)該包含產(chǎn)品/項目組全體成員為此項目完成的全部工作成果；要求能夠基于配置庫的最新內(nèi)容隨時構(gòu)建無損發(fā)布包（包括程序代碼、可執(zhí)行程序和相關(guān)文檔資料）。及時：立項產(chǎn)品/項目各項工作成果的新建或修訂均應(yīng)該及時納入配置庫。未立項產(chǎn)品/項目的文檔應(yīng)及時納入公司專門的服務(wù)器中。術(shù)語定義No.術(shù)語定義1配置管理（CM）配置管理是對項目生命周期過程中各階段產(chǎn)品和最終產(chǎn)品演化和變更的管理，是質(zhì)量管理的重要組成部分。配置管理通過一系列技術(shù)、方法和手段實現(xiàn)：指導(dǎo)和監(jiān)督對配置項的物理與功能特性的標識和歸檔工作。控制上述特性的變更，記錄并報告變更的處理和實現(xiàn)狀態(tài)，并驗證與需求的一致性。2變更控制委員會（CCB）CCB是一個虛擬小組，由項目監(jiān)理小組、項目經(jīng)理、資深項目成員、配置管理員、品質(zhì)保證工程師等組成，項目經(jīng)理為CCB召集人；CCB對配置管理各項活動擁有決策權(quán)（例如評審計劃、評審變更請求等），負責(zé)評估和審批配置項的變更、確保所有的變更都是經(jīng)過審核的。3配置項（ConfigurationItem,CI）配置項是指納入配置管理范疇的工作成果的最小集合。例如一個文檔（如需求文檔、設(shè)計文檔、測試用例、用戶文檔等屬于產(chǎn)品組成部分的工作成果以及項目管理、組織支撐過程域產(chǎn)生的文檔）或一組構(gòu)成獨立功能單元的源代碼文件都可以定義為一個配置項。4基線（Baseline）基線由一組穩(wěn)定的特定版本的配置項組成，是進一步開發(fā)的基礎(chǔ)?；€中的配置項是被“凍結(jié)”的，不能被隨意修改。基線通常在開發(fā)過程中的里程碑（Milestone）處建立，一般包括需求基線、設(shè)計基線、開發(fā)基線、發(fā)版基線、結(jié)項基線等。5配置管理員（CMO）每個項目應(yīng)配備一個配置管理員（可專職或由項目組某個成員兼職），為該項目制定配置管理計劃、創(chuàng)建和維護配置庫、適時出具配置管理各種報告如基線建立控制報告、配置項變更控制報告、版本發(fā)布通知等。適用范圍本配置管理規(guī)范適用于公司產(chǎn)品/項目從可研論證、立項、需求分析、設(shè)計編碼、測試驗證、版本發(fā)布、運行維護直至結(jié)束的全生命周期過程中文檔、代碼、構(gòu)建、發(fā)布等的管理，暫不適用于其他資產(chǎn)如測試數(shù)據(jù)、美工工作產(chǎn)品、售前資料、非產(chǎn)品/項目培訓(xùn)資料、多媒體資料、部門管理文檔、公司信息化數(shù)據(jù)等的管理。閱讀對象配置管理員、產(chǎn)品/項目經(jīng)理、開發(fā)人員、測試人員、維護人員、系統(tǒng)架構(gòu)師配置管理計劃配置管理的計劃過程主要由明確配置管理軟硬件資源、識別配置項、規(guī)劃配置庫目錄結(jié)構(gòu)、確定權(quán)限配置、制定基線計劃、確定項目分支合并策略、確定代碼集成策略、項目構(gòu)建策略、版本發(fā)布策略以及制定《配置管理計劃》等一系列活動組成，每個活動計劃的最終成果體現(xiàn)在《配置管理計劃》中。通過配置管理計劃，將項目開發(fā)、測試、實施、發(fā)版各階段涉及的配置管理工作明確下來，保證項目生命周期過程中產(chǎn)生的配置項被識別、記錄、跟蹤、管理。配置管理計劃流程圖圖1配置管理計劃流程圖配置管理計劃流程說明由項目經(jīng)理和配置管理員共同確定本項目配置管理的軟硬件資源，如下：確定CCB成員名單，根據(jù)項目不同規(guī)模和重要程度，CCB成員建議可以包括分管副總、研發(fā)項目總監(jiān)、部門經(jīng)理、項目經(jīng)理以及其他受變更影響的人員代表（必要時可包括測試人員等）。確定本項目配置管理的軟件工具和硬件設(shè)備，包括配置管理服務(wù)器、構(gòu)建服務(wù)器、軟件開發(fā)工具、配置管理工具、構(gòu)建工具等的具體名稱和版本以及需遵循的開發(fā)、編碼規(guī)范（確定配置管理的軟硬件資源可參考本規(guī)范以及《配置管理工作指南》相關(guān)章節(jié)內(nèi)容）。依據(jù)《項目管理計劃》，由配置管理員與項目經(jīng)理共同識別主要配置項、配置庫目錄及權(quán)限分配、基線計劃、分支合并策略等（具體內(nèi)容可參考本規(guī)范相關(guān)章節(jié)內(nèi)容），并體現(xiàn)在《配置管理計劃》中。配置管理員與項目經(jīng)理共同確定項目的變更策略、代碼集成策略、項目構(gòu)建策略以及版本發(fā)布策略（具體內(nèi)容可參考本規(guī)范相關(guān)章節(jié)內(nèi)容），并體現(xiàn)在《配置管理計劃》中。配置管理員完成《配置管理計劃》，以便于項目有計劃的開展配置管理工作（配置管理計劃相關(guān)模板詳見公司主頁規(guī)章制度下公布的最新模板）?！杜渲霉芾碛媱潯吩u審活動由配置管理員發(fā)起，評審組由CCB成員組成（可同時發(fā)送項目組人員）。CCB對已制定的《配置管理計劃》進行評審，以保證《配置管理計劃》的完整、正確、可行；如審批未通過，配置管理員需按照評審意見重新修訂《配置管理計劃》，直至CCB評審?fù)ㄟ^。配置管理員將審批通過的《配置管理計劃》納入配置庫進行管理，并發(fā)布給項目組相關(guān)人員。配置管理軟硬件資源確定配置管理服務(wù)器公司所有項目的配置庫必須在公司指定的配置管理服務(wù)器上，包括研發(fā)項目和實施項目。公司所有項目使用配置管理服務(wù)器必須與運營監(jiān)管中心溝通確認。公司級配置管理計劃模板中應(yīng)明確列示配置管理服務(wù)器的基本信息，如配置管理服務(wù)器名稱、操作系統(tǒng)、IP地址、內(nèi)存容量、硬盤容量、管理員等。

公司目前允許使用的配置管理服務(wù)器如下表所示：服務(wù)器名訪問地址主要用途配置庫規(guī)劃備注jqcmr32289版全稱Subversion，研發(fā)項目，文檔和代碼vss\\ad01\開發(fā)輔助\VSS版本管理6.0C/無全稱VisualSourceSafe，研發(fā)項目，文檔和代碼starteam\\ad01\開發(fā)輔助\StarTeamEnterprise2008配置管理、需求管理、任務(wù)管理等2008/2006研發(fā)項目，文檔和代碼項目管理平臺Web訪問基線建立流程圖基線計劃時間點到達或需要建立基線時，由項目經(jīng)理提出基線建立申請。CCB對基線建立申請進行評審和批準，保證組成基線的配置項是完整的、正確的、一致的。配置管理員與項目經(jīng)理溝通，參照《基線建立前檢查Checklist》以及基線計劃對提交的配置項審查其完整性、正確性、一致性，并完成《基線建立前檢查Checklist》、《基線建立控制報告》，填寫基線名稱、版本、標識以及當(dāng)前基線包含的所有主要配置項等信息（如果前期已建立基線，當(dāng)前基線的配置項需要包含上一次基線的配置項）。配置管理員審查配置項時需注意檢查主要配置項的評審記錄、評審結(jié)論、變更影響等。比如需求規(guī)格說明書評審記錄、功能評審記錄、變更所影響的配置項是否正確變更并入庫等等，如若評審結(jié)論不通過或影響的配置項沒有變更或入庫，則該基線不能建立并必須與項目經(jīng)理溝通。CCB評審并批準基線建立申請后，由配置管理員執(zhí)行建立基線的操作，基線命名要按照《配置管理計劃》中規(guī)定的命名。配置管理員將《基線建立控制報告》發(fā)布給CCB、項目組成員并納入配置庫。基線命名規(guī)范計劃性基線：“項目編號-階段標識-YYYYMMDD”；事件性基線：“項目編號-階段標識-事件英文縮寫-YYYYMMDD”?；€名稱標識符基線所包含的主要配置項建立時間產(chǎn)品定義基線項目編號-REQBaseline-YYYYMMDD需求說明書需求規(guī)格說明書項目管理計劃品質(zhì)保證計劃配置管理計劃測試計劃風(fēng)險/重大問題跟蹤表各種報告和跟蹤表產(chǎn)品設(shè)計與開發(fā)基線項目編號-DES+CODEBaseline-YYYYMMDD概要技術(shù)方案說明書總體設(shè)計說明書模塊設(shè)計說明書數(shù)據(jù)庫設(shè)計說明書測試用例源代碼產(chǎn)品穩(wěn)定基線項目編號-RELEBaseline-YYYYMMDD測試報告用戶手冊培訓(xùn)資料技術(shù)白皮書發(fā)布版本產(chǎn)品結(jié)項基線項目編號-ENDBaseline-YYYYMMDD項目總結(jié)報告提交工作產(chǎn)品清單分支合并管理版本控制系統(tǒng)的一個特性是能夠把各種修改分離出來放在一個單獨的開發(fā)線上，這條線被稱為分支。分支經(jīng)常被用來試驗新的特性，而不會干擾主開發(fā)線，當(dāng)新的特性足夠穩(wěn)定之后，開發(fā)分支就可合并到主干里。分支管理是軟件版本控制的重要組成部分，運用分支使得并行開發(fā)的系統(tǒng)、同步更改多個并行版本的錯誤等成為可能。分支可用來維護獨立的開發(fā)支線（通常只對代碼做分支），使用分支進行項目組的開發(fā)可以提高項目組的開發(fā)速度，并減少對主干文件的誤修改操作，否則主干版本可能會變得十分混亂，維護難度大大加大。盡管SVN沒有做強制要求，但SVN版本目錄建議創(chuàng)建Trunk、Branches、Tags三個目錄。其中Branches是分支目錄，存放并行開發(fā)的項目文檔和代碼；Tags是標簽?zāi)夸?，存放所定義基線的項目文檔和代碼。分支建立分支建立時機建立分支是為了支持特定需求、完成新功能開發(fā)或解決某些重大bug，在項目立項、新增功能需求、解決某些重大bug等情況下允許建立分支。由配置管理員協(xié)助開發(fā)人員在配置庫相應(yīng)目錄下建立分支。應(yīng)當(dāng)盡量避免建立多個層次的分支，即基于分支再創(chuàng)建分支。分支建立模式一般情況下，圍繞代碼進行分支管理的模式主要有兩種：主干作為新功能開發(fā)，分支用作穩(wěn)定版的發(fā)布；分支用作新功能開發(fā)，主干作為穩(wěn)定版的發(fā)布。建立分支時，配置管理員需明確以下幾點：分支目錄結(jié)構(gòu)；人員訪問權(quán)限；此分支是否需提交相關(guān)項目文檔。分支合并分支合并類型分支合并是將某個分支中修改的代碼合并到另一個分支中。常見的分支合并有以下幾種：分支合并到分支；分支合并到主干；主干合并到分支。分支合并前應(yīng)臨時去除相關(guān)分支所有人員的寫權(quán)限，只保留被合并分支上合并人員的寫權(quán)限。應(yīng)當(dāng)盡量避免一個分支合并多次。當(dāng)一個分支完成特定任務(wù)后，應(yīng)及時合并。合并完成后分支應(yīng)設(shè)置為只讀，不再允許對該分支進行修改。版本庫發(fā)布模式新功能開發(fā)在主干上進行當(dāng)新功能開發(fā)在主干上進行、臨近發(fā)布階段時，從主干建立分支，在分支上修訂集成測試、系統(tǒng)測試所發(fā)現(xiàn)的BUG，在分支上進行發(fā)版；主干繼續(xù)進行新功能開發(fā)。版本發(fā)布完成后，將分支合并到主干，分支設(shè)置為只讀。新功能開發(fā)在分支上進行當(dāng)新功能開發(fā)在分支上進行、開發(fā)結(jié)束、功能測試通過時，將分支合并到主干修訂集成測試、系統(tǒng)測試所發(fā)現(xiàn)的BUG，在主干上進行發(fā)版；同時將分支設(shè)置為只讀。此模式下的開發(fā)周期較靈活，各功能模塊自主定義開發(fā)周期，分支上的開發(fā)臨近末期則將分支合并至主干，越先合并的分支，在合并過程中解決的沖突越小。代碼集成管理代碼集成目標是使集成和集成測試過程處于受控狀態(tài)。頻繁的集成能夠幫助項目在早期發(fā)現(xiàn)項目風(fēng)險和質(zhì)量問題，如果到后期才發(fā)現(xiàn)這些問題，解決問題的代價將會很大、并且很有可能導(dǎo)致項目延期或者失敗。當(dāng)產(chǎn)品/項目進入編碼階段后，不同開發(fā)人員在各自的個人工作空間下開始編碼。為保證代碼集成目標的實現(xiàn)、避免不同開發(fā)人員提交到代碼庫的代碼產(chǎn)生沖突，必須明確約定從個人工作空間到代碼庫的代碼集成策略：禁止使用有商業(yè)版權(quán)、未經(jīng)授權(quán)的工具、軟件或插件。同一個產(chǎn)品或項目的開發(fā)應(yīng)統(tǒng)一個人工作空間，一般包括以下內(nèi)容：操作系統(tǒng)、配置管理工具客戶端或插件版本、開發(fā)工具及版本、數(shù)據(jù)庫及版本、中間件及版本以及其他環(huán)境要求等。個人工作空間要求應(yīng)由項目經(jīng)理與配置管理員共同確定并體現(xiàn)在項目管理計劃和配置管理計劃中。個人工作空間目錄應(yīng)該盡可能的與服務(wù)器目錄結(jié)構(gòu)保持一致，禁止自行將多個文檔目錄或工程代碼合并到一個目錄或工程之中進行工作。工作時如需鎖定或Checkout文件，在修改完成后應(yīng)該馬上解鎖文件，禁止長期鎖定或當(dāng)產(chǎn)品/項目處于前期開發(fā)階段時，開發(fā)人員根據(jù)項目組要求應(yīng)該每天至少向配置庫中提交一次代碼、每天至少從配置庫更新一次相關(guān)的代碼到個人工作空間。開發(fā)人員向配置庫提交代碼前必須先在個人工作空間完成編譯、構(gòu)建、自測，保證代碼可編譯通過、沒有錯誤，從而確保配置庫的變更不會導(dǎo)致代碼集成失敗。當(dāng)產(chǎn)品/項目處于后期版本穩(wěn)定階段時，對于產(chǎn)品版本穩(wěn)定性要求較大的開發(fā)團隊，為避免由于代碼集成過程缺乏控制導(dǎo)致的代碼混亂問題，必須制定嚴密的代碼集成策略。跟產(chǎn)品/項目無關(guān)的文件一律不允許檢入配置庫，如編譯產(chǎn)生的文件、緩存縮略圖的文件Thumbs.db、從VSS中檢出的配置文件vssver.scc等。源代碼必須及時提交到配置庫，不允許長時間lock或checkout代碼而不執(zhí)行unlock或checkin。lock或checkout到unlock或checkin的時間間隔不得超過2個星期。對于開發(fā)人員，修復(fù)失敗的構(gòu)建是優(yōu)先級最高的事情。代碼修改過程中，為防止代碼被別人修改而引發(fā)沖突，可以考慮鎖定機制。正式版本發(fā)布、升級或發(fā)布臨時版本時，必須對源代碼打基線。配置管理員與項目經(jīng)理溝通確定代碼集成策略后，將具體的流程在《配置管理計劃》中做出約定，主要內(nèi)容如下：代碼集成策略內(nèi)容包括：代碼模塊集成順序、誰負責(zé)代碼集成過程、代碼集成前的一致性檢查、代碼提交要求等，參見《配置管理工作指南》代碼集成部分的內(nèi)容代碼集成策略影響整個系統(tǒng)各個代碼模塊的編譯順序和目標代碼的連接（受一些構(gòu)建參數(shù)的影響），項目經(jīng)理要根據(jù)代碼集成策略確定構(gòu)建腳本和相關(guān)構(gòu)建參數(shù)，確保構(gòu)建腳本及其配置參數(shù)符合代碼集成策略要求，配置管理員要注意督促。源代碼基線建立或第一次版本發(fā)布后，所有源代碼的修改、提交必須填寫修改注釋（COMMENTS）或更新說明。產(chǎn)品/項目穩(wěn)定后期，可設(shè)立專門的代碼集成人員，開發(fā)人員將修改文件及更新說明（明確注明修改文件、修改原因等信息）發(fā)送給代碼集成人員，由代碼集成人員向代碼庫提交代碼，并維護代碼庫更新說明列表。發(fā)布管理正式版本發(fā)布正式版本是指經(jīng)測試后、可發(fā)布給客戶正式使用的版本，包括程序包、更新腳本、用戶文檔等。對外發(fā)布的正式版本包中不得包含任何未經(jīng)授權(quán)的產(chǎn)品或半產(chǎn)品，比如不得使用未經(jīng)授權(quán)的商業(yè)軟件工具構(gòu)建程序包、創(chuàng)建文檔、制作圖片等，不得使用第三方獲取的未經(jīng)授權(quán)的圖片等。各產(chǎn)品/項目正式發(fā)布的版本包必須存放在久其產(chǎn)品庫中。久其產(chǎn)品庫按照產(chǎn)品線/項目進行目錄規(guī)劃。久其產(chǎn)品庫由組織級配置管理員在對應(yīng)的目錄上針對產(chǎn)品線或項目配置管理員開放讀寫權(quán)限，針對測試、實施、服務(wù)相關(guān)部門經(jīng)理/負責(zé)人、助理開放讀權(quán)限。如需訪問久其產(chǎn)品庫某產(chǎn)品，需經(jīng)主管領(lǐng)導(dǎo)、分管副總審批后由組織級配置管理員設(shè)定；沒有經(jīng)過申請、審批的人員不設(shè)置任何權(quán)限。正式產(chǎn)品的發(fā)布必須提交發(fā)版說明或者更新說明。正式版本的命名一般遵循“產(chǎn)品/項目編號+正式版本號+內(nèi)部版本號+八位數(shù)日期+隨機號”。正式版本的發(fā)布由配置管理員采用電子郵件方式統(tǒng)一執(zhí)行，發(fā)送范圍視版本內(nèi)容可以是全公司或部分人員。久其產(chǎn)品庫要做到每年做一次完全備份，并且刻盤、永久歸檔。測試版本發(fā)布測試版本是指構(gòu)建完成后僅用于內(nèi)部測試驗證、臨時滿足用戶演示或售前交流等需要臨時發(fā)布的版本，是非正式的產(chǎn)品版本，使用對象包括內(nèi)部測試人員或外部客戶（協(xié)助測試）。測試版本不能保證產(chǎn)品整體功能的正確性，是未經(jīng)過功能測試、集成測試或性能測試的版本，不得用于正式生產(chǎn)環(huán)境。各產(chǎn)品/項目構(gòu)建工作建議在久其統(tǒng)一的構(gòu)建服務(wù)器、通用構(gòu)建管理平臺上執(zhí)行。各產(chǎn)品/項目必須有一個唯一的標識，用于區(qū)分不同產(chǎn)品/項目的構(gòu)建。測試版本的構(gòu)建必須由配置管理員或指定的構(gòu)建人員執(zhí)行。構(gòu)建產(chǎn)生的測試版本存放在構(gòu)建服務(wù)器上，有相應(yīng)授權(quán)的人員可以登錄構(gòu)建平臺下載。測試版本的命名一般遵循“yyyy-mm-dd（hh-mm-ss）”的規(guī)則。一般情況下，測試版本保存半年之后可以刪除、無須永久備份。臨時版本發(fā)布臨時版本是指為了滿足用戶少量個性化需求或修復(fù)部分小缺陷而發(fā)布的版本，這種版本一般可以不經(jīng)過集成測試，但應(yīng)經(jīng)功能測試方可發(fā)布。為了做好版本管理、一般情況下應(yīng)盡可能減少臨時版本的發(fā)布。臨時發(fā)布的版本包中同樣不得包含任何未經(jīng)授權(quán)的產(chǎn)品或半產(chǎn)品。因臨時版本需要用于正式生產(chǎn)環(huán)境，所以臨時版本同樣必須存放在久其產(chǎn)品庫中。臨時版本存儲的目錄結(jié)構(gòu)劃分、權(quán)限設(shè)置等與產(chǎn)品/項目的正式版本一致。臨時版本的命名一般遵循“產(chǎn)品/項目編號+正式版本號+內(nèi)部版本號+八位數(shù)日期+隨機號+用戶方或者申請者姓名”。臨時版本可視情況考慮永久歸檔或者在保存一年之后刪除。變更管理變更控制為了確保重大變更經(jīng)過評審、確認，保證變更所引起的其他配置項能夠得到及時、一致的更新并及時入庫，保證所有事件性變更有記錄，我們需要加強變更控制。對于嚴重影響項目進度和成本的需求、設(shè)計、人員、計劃等的變更必須經(jīng)過申請、評審、審批方可執(zhí)行，不允許擅自修改。修改處于“草稿”狀態(tài)的配置項不算是“變更”，當(dāng)配置項的狀態(tài)成為“正式發(fā)布”，或者被“凍結(jié)”后，此時任何人都不能隨意修改，必須依據(jù)申請執(zhí)行變更的規(guī)則執(zhí)行。發(fā)生變更時，項目經(jīng)理必須及時通知配置管理員，延緩時間不能超過3天。配置管理員要跟蹤變更執(zhí)行進度，及時接收、入庫變更產(chǎn)生或修改的配置項。對配置項的變更操作應(yīng)以評審定稿為準、不僅僅以基線為準。即：配置項評審定稿入庫后、未建立基線前如對該配置項進行修改，需按照變更流程執(zhí)行。配置管理通過建立一個有序的變更控制過程要確保以下幾點：變更影響分析：對每個配置項的變更所造成的影響（如：技術(shù)影響、成本影響、進度影響等）需進行分析。變更審批：對任何基線化的配置項的更改必須經(jīng)過審批、并保留審批記錄。變更執(zhí)行與入庫：得到審批的變更及其影響必須得以實施并得到進一步審批方可入庫。變更流程圖1變更控制流程圖申請變更變更申請人向CCB提交變更申請（填寫《配置項變更控制報告》的相關(guān)內(nèi)容），需要重點說明“變更內(nèi)容”和“變更原因”及其“該配置項變更對項目造成的影響”。典型的變更請求有：項目目標發(fā)生改變、增加或減少重大功能需求、技術(shù)攻關(guān)出現(xiàn)難題、資源調(diào)整等。評審變更申請CCB評審該申請，重點分析此變更對項目造成的影響。安排變更