【正文】 。 3 術語和縮略語 3． 1 項目委托單位 project entrust anization 項目委托單位是指為產(chǎn)品開發(fā)提供資金并通常也是（但有時 也未必）確定產(chǎn)品需求的單位或個人。 ............................. 5 軟件質量保證員（ Software Quality Assurance， SQA） .................................. 6 開發(fā)人員（ Dev， Developer）。 ................................................................ 5 配置管理員（ CMO， Configuration Management Officer）。 2 適用范圍 對于不同類別的軟件項目，配置管理的流程不同，可在本流程的基礎上進行裁減。 3． 4 用戶 user 用戶是指實際 使用 軟件來完成某項計算、控制或數(shù)據(jù)處理等任務的單位或個人。 3． 7 軟件生存周期 software life cycle 軟件 （集成系統(tǒng)） 生存周期是指從軟件系統(tǒng) （集成系統(tǒng)） 設計對軟件系統(tǒng) （集成系統(tǒng)） 提出應用需求開始，經(jīng)過 設計 開發(fā)，產(chǎn)生出一個滿足需求的計算機軟件系統(tǒng) （集成系統(tǒng)） ，然后投入運行，直至該軟件系統(tǒng) （集成系統(tǒng)） 退役為止。 存放與該階段 有關 的信息的庫。 3． 12 功能基線 （ functional baseline） 功能基線是指在系統(tǒng)分析與軟件定義階段結束時，經(jīng)過正式評審和批準的系統(tǒng)設計規(guī)格說明書中對待開發(fā)系統(tǒng)的規(guī)格說明；或是指經(jīng)過項目委托單位和項目承辦單位雙方簽字同意的協(xié)議書或合同中所規(guī)定的對待開發(fā)軟件系統(tǒng)的規(guī)格說明；或是由下級申請經(jīng)上級同意或直接由上級下達的項目任務書中所規(guī)定的對待開發(fā)軟件系統(tǒng)的規(guī)格說明。 3． 14 產(chǎn)品基 線 (product baseline) 產(chǎn)品基線是指在軟件組裝與系統(tǒng)測試階段結束時，經(jīng)過正式評審的批準的有關所開發(fā)的軟件產(chǎn)品的全部配置項的規(guī)格說明。后面這個過程也中做交付 (delivery)。 配置 （ Configuration） 配置是在技術文檔中明確說明并最終組成軟件產(chǎn)品的功能或物理屬性。這些文檔雖然不是產(chǎn)品的組成部分，但是值得保存。 基線 （ Baseline） 在配置管理系統(tǒng)中，基線就是一個 CI 或一組 CIS 在其生命周期的不同時間點上通過正式評審而進入正式受控的一種狀態(tài)， 這 些配置項構成了一個相對穩(wěn)定的邏輯實體，而這個過程被稱為“基線化”。每個基線都將接受配置管理的嚴格控制，基線中的配置項被“凍結”了，不能再被任何人隨意修改，對其的修改將嚴格按照變更控制要求的過程進行，在一個軟件開發(fā)階段結束時，上一個基線加上增加和修改的基線內容形成下一個基線。當認為更新不穩(wěn)定或不可信時，基線為團隊提供一種取消變更的方法。作為一個單獨分支，新項目將與隨后對原始項目（在主要分支上）所進行的變更進行隔離。 根據(jù)配置管理計劃執(zhí)行各項管理任務，定期向 CCB 提交報告，并 參加 CCB 的例會， 6 其具體工作職責如下： 1. 軟件配置管理工具的日常 管理與維護； 2. 提交配置管理計劃； 3. 各配置項的管理與維護； 4. 執(zhí)行版本控制和變更控制方案； 5. 完成配置審計并提交報告； 6. 對開發(fā)人員進行相關的培訓； 7. 識別開發(fā)過程中存在的問題并制定解決方案。 3． 按照文檔、程序、系統(tǒng)、數(shù)據(jù)庫統(tǒng)一命名的規(guī)定命名； 4． 每次修改執(zhí)行“提交” “檢出”操作和填寫修改信息 。其具體工作職責如下 1. 批準配置項的標志，以及軟件基線的建立； 2. 制定訪問控制策略； 3. 建立、更改基線的設置，審核變更申請； 4. 根據(jù)配置管理員的報告決定相應的對策。 制定配置管理計劃 《配置管理計劃》的編制 通常情況下，由 CMO 在 項目 設計 合同簽訂 后，開始編制《配置管理計劃》；如有特殊需要，根據(jù)合同或項目要求，由 CMO 在項目的某一階段開始前制定《配置管理計劃》。 2) 在開發(fā)過程中項目組人員提交的配置項，由項目組人員按照本節(jié)相關部分標識規(guī)則進行標識。 名稱 、文件狀態(tài) ： 文件名稱的標識按文檔模板中統(tǒng)一名稱為準 ,一般為：項目編號 +項目拼音縮寫 +文檔 編號 +文檔 名稱 。 版本 號 版本號： V（ Version）：即版本，通常用數(shù)字表示版本號 ? 文檔版本號： V ? 程序、系統(tǒng)、子系統(tǒng)、模塊版本號 :V .[Z.[ 編譯版本號 ]] 主版本號 (19). 子版本號 (099) [修正版本號 (099)[.編譯版本號 ]] 示例 : . 公司軟件統(tǒng)一采用 Window 下的版本號管理策略 ? 當項目初版時 , 版本號為 ； ? 當項目在進行了局部修改或 bug 修正時，主版本號和子版本號都不變 , 修正版本號加 1, 版本號為 。 Alpha：內部 單元 測試版， 一般不向外部發(fā)布 ,會有很多 人員使用。 OEM：隨機版。 ? 三級庫：根據(jù) 開發(fā)階段，三 級庫 構成情況不同。一般地，項目成員擁有 Add、 Checkin/Checkout、 Download 等權限，但是不能擁有“刪除”權限。 配置庫的檢出 、檢入 當發(fā)生變更且變更評審通過后，或者發(fā)現(xiàn) Bug 且 Bug 評審通過后，由 配置管理員將 開發(fā)庫 中 CIs發(fā)布稿 檢出 ，編制版本號存入基線庫； 項目完成后配置管理員統(tǒng)一將程序、文檔的統(tǒng)一版本檢入 成品庫 。 項目啟動 配置項包括需求說明、訂單及其評審結果等；項目 立項后 應封鎖該子項目，建立立項 基線。如需升版則必須通過評審并得到客戶的確認。針對需求分析報告進行系統(tǒng)設 計，配置時應說明系統(tǒng)設計的版本與需求分析報告版本的對應關系。配置時應說明測試的版本與編碼版本的對應關系。 相關資料與培訓 相關資料與培訓也應作為配置項納入配置管理，此部分包括： 1) 相關法律、法規(guī)； 2) 必須遵照或項目組約定的技術規(guī)范； 3) 與客戶或項目組內部重要的交互信息記錄，如 Question Sheet、會議記錄、會談記錄、 和 MSN 記錄； 4) 必要的業(yè)務 或技術培訓等。 變更的流程 第一步：變更提出 由發(fā)起者（客戶、最終用戶或開發(fā)部門） 提出 變更， 填寫《變更請求 /評審單》，描述變更原因和變更內容，并提交給 CMO。 a) 變更控制的一個重要環(huán)節(jié)就是變更評估，變更評估要分析每個變更對系統(tǒng)功能、接口、成本、進度以及約定需求的影響，同時還要分析對軟件安全性、可靠性、可維護性、可移植性和性能的 影響。 CCB 也可能需更多的變更分析的信息。 b) 對于代碼變更，必須修改設計、代碼、測試以及變更正確性的驗證。 第五步 變更確認 a) 變更后的程序 Merge 后必需經(jīng)過測試組進行回歸測試，以確保變更沒有引入新的 Bug。 第六步 變更標識 a) 配置管理員 應重新標識所有被影響的配置項及版本 的版本號 。 配置狀態(tài)報告記錄的內容 1) 軟件和文檔的標識； 2) 目前狀態(tài)； 3) 基線演化狀態(tài)； 4) 變更狀態(tài)； 5) 版本交付信息等。 SQA 配置審核執(zhí)行的時機 通常選擇以下幾種情況由 SQA 負責實施配置審核： 1)軟件產(chǎn)品交付或是軟件產(chǎn)品正式發(fā)行前； 2)軟件開發(fā)的階段工作結束后； 3)在產(chǎn)品維護工作中，定期地進行。 交付管理 這里“交付”是指從配置庫中提取配置項，交付給客戶或項目外的人員 。如果該申請不合法（合理），則拒絕交付配置項。 主題詞：配置 管理 流程 主送：軟件部 技術開發(fā)部 審核人： 起草人： XXX