【導(dǎo)讀】《配置管理計劃》由CCB負(fù)責(zé)審批。

　　

【正文】 項(xiàng)目，建立項(xiàng)目計劃基線。 系統(tǒng)設(shè)計 系統(tǒng)設(shè)計可分為概要設(shè)計、詳細(xì)設(shè)計和數(shù)據(jù)庫設(shè)計等部分。針對需求分析報告進(jìn)行系統(tǒng)設(shè) 計，配置時應(yīng)說明系統(tǒng)設(shè)計的版本與需求分析報告版本的對應(yīng)關(guān)系。設(shè)計書評審?fù)ㄟ^后，建立設(shè)計基線。 編碼 編碼按功能模塊分子項(xiàng)目，即每個模塊計作一個配置項(xiàng)。代碼基線分別在單元測試結(jié)束后建立 Alpha 版， Alpha 集成 測試后建立 Beta 版，在 正式發(fā)布 時建立Final：正式版 測試 各測試階段應(yīng)提供測試計劃、測試用例、測試結(jié)果和測試分析報告，項(xiàng)目啟動后應(yīng)提供項(xiàng)目測試計劃書，項(xiàng)目驗(yàn)收結(jié)束后應(yīng)提交項(xiàng)目測試總結(jié)報告等。配置時應(yīng)說明測試的版本與編碼版本的對應(yīng)關(guān)系。各階段測試（如單元測試、集成測試）完成 后建立測試基線。 交付與驗(yàn)收 在交付前配置審核完成后建立產(chǎn)品基線，產(chǎn)品基線包含程序以及有關(guān)文檔配置項(xiàng)，包括交付施工文檔、工具等。 項(xiàng)目總結(jié) 項(xiàng)目總結(jié)應(yīng)經(jīng)過部門內(nèi)部評審，包括項(xiàng)目質(zhì)量報告、測試報告等。 相關(guān)資料與培訓(xùn) 相關(guān)資料與培訓(xùn)也應(yīng)作為配置項(xiàng)納入配置管理，此部分包括： 1) 相關(guān)法律、法規(guī)； 2) 必須遵照或項(xiàng)目組約定的技術(shù)規(guī)范； 3) 與客戶或項(xiàng)目組內(nèi)部重要的交互信息記錄，如 Question Sheet、會議記錄、會談記錄、 和 MSN 記錄； 4) 必要的業(yè)務(wù) 或技術(shù)培訓(xùn)等。 配置變更控制 變更的分類 軟件及其相關(guān)文檔的變更按照變更的影響范圍進(jìn)行分類： 1) A 級：變更會影響系統(tǒng)級需求、外部接口、產(chǎn)品價格或者交付期；這類變更必須經(jīng)過 CCB 審核并有客戶批準(zhǔn)和確認(rèn)。 2) B 級：變更會影響配置項(xiàng)間的功能接口、組件級成本或者項(xiàng)目 安排 Schedule；這類變更必須由 CCB 批準(zhǔn)和認(rèn)可。 3) C 級：變更會影響配置項(xiàng)內(nèi)部功能的設(shè)計和分配；這類變更可以 子系統(tǒng)負(fù)責(zé) 12 人 批準(zhǔn)。 變更的流程 第一步：變更提出 由發(fā)起者（客戶、最終用戶或開發(fā)部門） 提出 變更， 填寫《變更請求 /評審單》，描述變更原因和變更內(nèi)容，并提交給 CMO。 CMO 對填寫的申請表是否清晰、明確和完整性進(jìn)行審查，若 CMO 發(fā)現(xiàn)變更不明確或不完整，應(yīng)返回申請表給發(fā)起者。CMO 對通過審查的變更申請分配變更 ID，以便跟蹤和記錄變更信息。 第二步 變更評估 CMO 將《變更請求 /評審單》發(fā)送給項(xiàng)目經(jīng)理（或者其他授權(quán)人員），由 其 對變更進(jìn)行評估。 a) 變更控制的一個重要環(huán)節(jié)就是變更評估，變更評估要分析每個變更對系統(tǒng)功能、接口、成本、進(jìn)度以及約定需求的影響，同時還要分析對軟件安全性、可靠性、可維護(hù)性、可移植性和性能的 影響。 b) 變更評估產(chǎn)生的文檔應(yīng)描述若實(shí)施變更必須變更的配置項(xiàng)、文檔和資源；變更評估文檔在完成變更評估后發(fā)送給 CMO。 c) CMO 收到評估后的《變更請求 /評審單》后，更新變更記錄，并安排CCB 會議日程。 第三步 變更審核 a) CCB 對提交的變更申請進(jìn)行審核，并根據(jù)變更評估確定變更的影響級別 （ A 級、 B 級、 C 級） ； CCB 審核可能的結(jié)果有三種：接受變更；拒絕變更；延期變更。 CCB 也可能需更多的變更分析的信息。 b) CCB 批準(zhǔn)的變更，由 CMO 將變更項(xiàng)目發(fā)送到指定的開發(fā)人員（ Assigner）進(jìn)行下一步的實(shí)施變更工 作；對于拒絕的變更，由 CMO 將 CCB 拒絕變更的原因發(fā)送給發(fā)起者，并保存《變更請求 /評審單》，更新變更記錄，關(guān)閉變更活動；需要進(jìn)一步分析的，由 CMO 將變更項(xiàng)目隨同 CCB 的 Question Sheet 發(fā)送給評估分析人員；對于延期的變更，由 CMO 對變更的相關(guān)文檔進(jìn)行歸檔，以便在適當(dāng)時機(jī)提交 CCB 審核。 c) CMO 負(fù)責(zé)整理 CCB 會議記錄，填寫《變更請求 /評審單》中相應(yīng)審核項(xiàng)；更新變更記錄，如果是接受變更，還需將要變更的 CIs 狀態(tài)改為“修改中”；將變更文檔分發(fā)給相關(guān)人員。 第 四 步 變更實(shí)施 a) 變更被批準(zhǔn)后， CMO 配 置管理員 負(fù)責(zé)將要變更的 CIs 以及相關(guān)文檔遷移至變更負(fù)責(zé)人的 分支上 ，由變更負(fù)責(zé)人開始實(shí)施變更，并詳細(xì)記錄變更的內(nèi)容；項(xiàng)目管理部門要對變更的實(shí)施進(jìn)行跟蹤。 b) 對于代碼變更，必須修改設(shè)計、代碼、測試以及變更正確性的驗(yàn)證。而且與變更相關(guān)的文檔必須修訂，以反映變更。當(dāng)變更以及測試完成后，進(jìn)行 合并（ Merge） 。 c) 對于開發(fā)計劃、配置管理計劃發(fā)生變更的，項(xiàng)目組人員要按照變 13 更過的開發(fā)計劃、配置管理計劃提交配置項(xiàng)。 第五步 變更確認(rèn) a) 變更后的程序 Merge 后必需經(jīng)過測試組進(jìn)行回歸測試，以確保變更沒有引入新的 Bug。 不會引起程序變更的文檔（如計劃文檔）的變更不需經(jīng)過測試。 b) 通過 Merge 后測試后， SQA 需對變更進(jìn)行審核，審核的范圍一般涉及以下方面： 1)測試記錄； 2)變更請求； 3)配置項(xiàng)的檢入及檢出； 5) 文件的命名； 6) 版本的編號。 c) SQA 審核后，開發(fā)人員才能 將 配置項(xiàng)的狀態(tài)從 “ 修改 ” 變遷為 “ 發(fā)布 ” 生成 發(fā)布 版本，由 配置管理員 更新到基線庫中。 第六步 變更標(biāo)識 a) 配置管理員 應(yīng)重新標(biāo)識所有被影響的配置項(xiàng)及版本 的版本號 。 b) A 級和 B 級的變更項(xiàng)也可能直到下次系統(tǒng)發(fā)行版本時才生成。 c) 生成 新版本后， CMO 負(fù)責(zé)收集所有變更信息歸檔，修改變更 的 CIs 狀態(tài) 的“ 版本號 ”，關(guān)閉變更，并將變更報告發(fā)送給發(fā)起者。 配置狀態(tài)報告 配置狀態(tài)報告的目的 記錄和報告整個軟件生命周期演化狀態(tài)。 配置狀態(tài)報告記錄的內(nèi)容 1) 軟件和文檔的標(biāo)識； 2) 目前狀態(tài)； 3) 基線演化狀態(tài)； 4) 變更狀態(tài)； 5) 版本交付信息等。 配置狀態(tài)報告的生成 配置管理報告自第一個基線創(chuàng)建時建立，由配置管理系統(tǒng)生成，及時反映當(dāng)前配置狀態(tài)。 配置審核 配置審核的類別 配置 審核分為： 1)功能配置審核（ Functional Configuration Audit， FCA）：審核軟件功能是否與需求一致，并符合基線文檔要求；通常要審查測試方法、流程、報告和設(shè)計文檔等。 2) 物理配置審核（ Physical Configuration Audit， PCA）：審核要交付的組成項(xiàng)是否存在，是否包含所有必需的項(xiàng)目，如正確版本的源代碼、資源、文檔、安 14 裝說明等等。 SQA 配置審核執(zhí)行的時機(jī) 通常選擇以下幾種情況由 SQA 負(fù)責(zé)實(shí)施配置審核： 1)軟件產(chǎn)品交付或是軟件產(chǎn)品正式發(fā)行前； 2)軟件開發(fā)的階段工作結(jié)束后； 3)在產(chǎn)品維護(hù)工作中，定期地進(jìn)行。 不符合項(xiàng)的處理 對配置審核中發(fā)現(xiàn)的不符合現(xiàn)象， SQA 進(jìn)行記錄，并填寫《不符合項(xiàng)報告》，交由責(zé)任部門限期進(jìn)行糾正， SQA 負(fù)責(zé)糾正措施的驗(yàn)證。所有的不符合項(xiàng)報告均關(guān)閉后，才能發(fā)布新版本。 發(fā)行管理 版本標(biāo)識 通過配置審核后，由項(xiàng)目經(jīng)理負(fù)責(zé) 審核 生 成 新版本，并由 配置管理員 檢入產(chǎn)品庫中，并按照 節(jié)配置 項(xiàng) 標(biāo)識規(guī)則進(jìn)行版本標(biāo)識。 交付管理 這里“交付”是指從配置庫中提取配置項(xiàng)，交付給客戶或項(xiàng)目外的人員 。交付出去的配置項(xiàng)必須有據(jù)可查，避免發(fā)生混亂。流程如下： 1)“索取人”向 CCB 提出交付申請。 2) CCB 審批該申請。如果該申請不合法（合理），則拒絕交付配置項(xiàng)。如果同意交付， CCB 應(yīng)給出詳細(xì)的交付清單。 3) 配置管理員 依據(jù) CCB 的批示，從配置庫中提取配置項(xiàng)交付給“索取人”。 4)“索取人”驗(yàn)收后簽字。 主題詞：配置 管理 流程 主送：軟件部 技術(shù)開發(fā)部 審核人： 起草人： XXX