【正文】 項目 安排 Schedule；這類變更必須由 CCB 批準(zhǔn)和認(rèn)可。 c) CMO 收到評估后的《變更請求 /評審單》后，更新變更記錄，并安排CCB 會議日程。當(dāng)變更以及測試完成后，進(jìn)行 合并（ Merge） 。 c) 生成 新版本后， CMO 負(fù)責(zé)收集所有變更信息歸檔，修改變更 的 CIs 狀態(tài) 的“ 版本號 ”，關(guān)閉變更，并將變更報告發(fā)送給發(fā)起者。所有的不符合項報告均關(guān)閉后，才能發(fā)布新版本。 3) 配置管理員 依據(jù) CCB 的批示，從配置庫中提取配置項交付給“索取人”。流程如下： 1)“索取人”向 CCB 提出交付申請。 配置審核 配置審核的類別 配置 審核分為： 1)功能配置審核（ Functional Configuration Audit， FCA）：審核軟件功能是否與需求一致，并符合基線文檔要求；通常要審查測試方法、流程、報告和設(shè)計文檔等。 b) 通過 Merge 后測試后， SQA 需對變更進(jìn)行審核，審核的范圍一般涉及以下方面： 1)測試記錄； 2)變更請求； 3)配置項的檢入及檢出； 5) 文件的命名； 6) 版本的編號。 c) CMO 負(fù)責(zé)整理 CCB 會議記錄，填寫《變更請求 /評審單》中相應(yīng)審核項；更新變更記錄，如果是接受變更，還需將要變更的 CIs 狀態(tài)改為“修改中”；將變更文檔分發(fā)給相關(guān)人員。CMO 對通過審查的變更申請分配變更 ID，以便跟蹤和記錄變更信息。 交付與驗收 在交付前配置審核完成后建立產(chǎn)品基線，產(chǎn)品基線包含程序以及有關(guān)文檔配置項，包括交付施工文檔、工具等。項目開發(fā)計劃評審?fù)ㄟ^后，封鎖該子項目，建立項目計劃基線。 配置管理員 定期備份配置庫。 程序 個人開發(fā)庫 當(dāng)事人讀寫其余項目組人員只讀 基線庫 文檔 評審?fù)甑牟牧? 管理員及指定人員負(fù)責(zé)讀寫，其余項目組人員只讀 程序 測試、評審?fù)甑哪K、系統(tǒng)、子系統(tǒng)、系統(tǒng)集成材料 管理員及指定人員讀寫，其余項目組人員只讀 產(chǎn)品庫 文檔 構(gòu)成版本的材料 管理員讀寫 程序 構(gòu)成版本的程序、數(shù)據(jù)庫、源碼 管理員讀寫 狀態(tài)標(biāo)識 、 版本號控制與配置庫管理 如文檔 13SZLX 系統(tǒng)需求規(guī)格說明 草稿（保存在開發(fā)庫 )； 13SZLX 系統(tǒng)需求規(guī)格說明 發(fā)布 （保存在開發(fā)庫） 13SZLX 系統(tǒng)需求規(guī)格說明 (從開發(fā)庫建立分支切換保存在基線庫） 13SZLX 系統(tǒng)需求規(guī)格說明 修改 （ 在 開發(fā)庫修改 發(fā)布稿，增加版本號 ，非關(guān)鍵項修改，修改成功 y 增加 1；關(guān)鍵項修改，修改成功 X 增加 1）； 13SZLX 系統(tǒng)需求規(guī)格說明 發(fā)布 （評審、測試通過后修改狀態(tài)為發(fā)布）； 10 13SZLX 系統(tǒng)需求規(guī)格說明 （從開發(fā)庫建立分支切換保存在基線庫） 所有文檔評審?fù)ㄟ^，在基線庫里集成，保存到 產(chǎn)品 庫中 如程序 13SZLX 電源控制系統(tǒng) 供電控制模塊 草稿（保存在開發(fā)庫 )； 13SZLX 電源控制 系統(tǒng) 供電控制模塊 發(fā)布（評審?fù)ㄟ^保存在開發(fā)庫 ) 13SZLX 電源控制系統(tǒng) 供電控制模塊 （從開發(fā)庫建立分支切換保存在基線庫 ) 13SZLX 電源控制系統(tǒng) 供電控制模塊 修改 . 8（在開發(fā)庫 修改發(fā)布稿 ，根據(jù)修改的程度 胚子組 確定 值， Z 值開發(fā)人員每修改測試一次增加 1) 13SZLX 電源控制系統(tǒng) 供電控制模塊 發(fā)布 . 9（評審?fù)ㄟ^保存在開發(fā)庫 ) 13SZLX 電源控制系統(tǒng) 供電控制模塊 . 9（（從開發(fā)庫建立分支切換保存在基線庫） 所有測試通過的模塊、子系統(tǒng)、系統(tǒng) 在基線庫里集成，并測試成功，保存到產(chǎn)品庫。 Final：正式版，修正了 Alpha 版和 Beta 版的 Bug。 ： 文件狀態(tài)分為“草稿”、“發(fā)布”和“修改”三種。 《配置管理計劃》由 CCB 負(fù)責(zé)審批。 一般由下列人員組成 ： 項目經(jīng)理 PM； 配置管理員 CMO； SQA； 系統(tǒng)負(fù)責(zé)人 ；用戶代表。 項目經(jīng)理是整個信息系統(tǒng)開發(fā)和維護(hù)活動的負(fù)責(zé)人，他批準(zhǔn)配置管理的各項活動并控制它們的進(jìn)程。通常將交付給客戶的基線稱為一個“ Release”，為內(nèi)部開發(fā)用的基線則稱 為一個“ Build”。所有配置項都被保存在配置庫里，確保不會混淆、丟失。是通過技術(shù)或行政手段對軟件產(chǎn)品及其開發(fā)過程和生命周期進(jìn)行控制、規(guī)范的一系列措施。 3． 13 指派基線 ( allocated baseline) 指派基線是指在軟件需求分析階段結(jié)束時，經(jīng)過正式評審和批準(zhǔn)的軟件需求的規(guī)格說明。其中軟件 集成系統(tǒng) 開 發(fā)階段一般又分成 軟硬件 需求分析、概要設(shè)計、詳細(xì)設(shè)計、編碼與 單元測試 、組裝與 系統(tǒng)測試 以及安裝與驗收等六個階段。 3． 2 項目承辦單位 project undertaking anization 項目承辦單位是指為項目委托單位開發(fā)、購置或選用軟件產(chǎn)品的單位或個人。 1 山大三元計算機(jī)工程有限公司 軟件系統(tǒng)集成 配置管理流程 目錄 1 目的 ........................................................................................................................... 3 2 適用范圍 .................................................................................................................... 3 3 術(shù)語和縮略語 ............................................................................................................. 3 4. 相關(guān)責(zé)任人 ............................................................................................................... 5 項目經(jīng)理（ PM， Project Manager）。 3． 3 軟件開發(fā)單位 software development anization 軟件開發(fā)單位是指直接或間接受項目委托單位委托而直接負(fù)責(zé)開發(fā)軟件的單位或個人。 3． 8 開發(fā)庫 （ development library） 開發(fā)庫是指在軟件 （ 集成 系統(tǒng)） 生存周期的 每一 個階段期間， 存放開發(fā)過程中需要保留的各種信息。指派基線是最初批準(zhǔn)的指派配置標(biāo)識。配置管理的目標(biāo)是記錄軟件產(chǎn)品的演化過程，確保軟件開發(fā)者在軟件生命周期中各個階段都能得到精確的不同版本的產(chǎn)品配置。配置項及其歷史記錄反映了軟件的演化過程。 建立基線的好處： 1)重現(xiàn)性：及時返回并重新生成軟件系統(tǒng)給定發(fā)布版的能力，或者是在項目中的早些時候重新生成開發(fā)環(huán)境的能力。其具體工作職責(zé)如下： 1． 制定項目的組織結(jié)構(gòu)和配置管理策略； 2． 批準(zhǔn)、發(fā)布配置管理計劃； 3． 決定項目起始基線和軟件開發(fā)工作里程碑； 配置管理員（ CMO， Configuration Management Officer）。 配置控制 小組（ CCB， Configuration Control Board） 職責(zé)： 負(fù)責(zé)指導(dǎo)和控制配置管理的各項具體活動的進(jìn)行，為項目經(jīng)理的決策提供建議。 配置項標(biāo)識規(guī)則 配置項標(biāo)識要求 1) 合同有明確標(biāo)識和追蹤要求時，由開發(fā)人員按合同要求進(jìn)行標(biāo)識，以保證滿足合同追蹤要求。 ? 評審前 提交 的 工作成果為 “草稿” 狀態(tài) ； 8 ? 測試、評審 后提交的工作成果為“ 發(fā)布 ” 狀態(tài) ； ? 發(fā)布后要變更修改，通過變更控制程序進(jìn)行修改時為“修改”狀