在之前的文章《配置管理漫漫談之配置管理主要活動及實現方法》中，介紹了配置管理活動及實現方法，但是有很多朋友對其中基準建立和變更的時機不清楚，我們今天來交流一下。
首先我們溫習一下「基準」的概念：經過正式評審和認可的一組配置項，它們作為進一步開發的基礎，並且只有經過正式的變更控制流程才能被更改。從這個概念中，我們知道基準是進一步開發的基礎，這就明確了我們進行基準建立的時機，即在下一步的開發開始之前建立上一階段工作產品的基準。示例如下：
我們從乙個例項來看一下基準建立的時機：
假設專案需求分析尚未完全完成，但已需要開始進行系統設計，則應先建立需求分析基準，然後開始進行系統設計，待需求分析完成或者需求分析基準變更時再對需求分析基線進行變更。
對於基準變更，我們一般認為不同型別配置項的變更時機如下：
為應對部分型別配置項(如需求分析)的頻繁變更，一般可根據實際情況規定如預計在一定時間(如5個工作日)內特定型別配置項的變更還會出現則可集中做一次變更，如周一接受可乙個需求變更，預計週三還會有需求變更，則可合併兩次需求變更做一次變更執行。但是這樣的情況不應該經常出現，原則上變更不合併執行。
一次配置變更可能包含乙個或者多個配置基準。
我們從乙個例項來看一下基準變更的時機：
假設某個專案已經進展到 系統測試 階段，已經建立的基準有專案計畫基準、需求分析基準、系統設計基準、概要設計基準、詳細設計基準、系統**基準、整合測試基準、系統測試基準，客戶方提出 刪除乙個需求，此變更請求請分析後確定工作量為4h，可通過加班完成，不影響里程碑完成，直接影響需求分析基準，間接影響詳細設計、系統**、系統測試基準，因此需要對需求分析、系統測試、詳細設計、系統**基準進行變更。
在實際實施過程中，很多人往往會疑惑於「影響」的概念，什麼樣才叫影響？如僅僅進行了很少文字上的修正，不影響其他的配置項，也需要進行基準變更嗎？我們建議所有對已經基準化的配置項的變更都走正式的變更流程，但是為了避免/減少沒有價值的變更，允許對不影響其他工作的配置項變更不做正式的基準變更，待有其它影響工作的變更時再一起進行正式的基準變更。
假設專案進行到了編碼階段，但是因為開發人員發現了詳細設計中不完善的地方，如概述文字描述錯誤，而對其進行修改，由於此修改不影響編碼工作，則可不進行正式的基準變更，如修改了函式引數等影響編碼工作的地方，則需進行正式的基準變更。
值得注意的是，如需求、設計的變更是否會影響其他工作的進行較容易判斷，但是對於專案進度計畫(當然，部分組織不把專案進度計畫作為專案計畫基線的一部分)，幾乎任何變更都會影響其它工作，是否每次變更都需要走正式的基準變更流程呢？對於很多專案來說，專案進度計畫變更頻繁，次次進行基準變更並不合適，因此一般約定對專案里程碑進行變更時才進行正式的基準變更。
基準建立和基準變更需要及時進行，否則如有交叉變更出現則很容易導致管理上的混亂。
配置管理漫漫談之典型配置庫結構
在筆者之前的文章 配置管理漫漫談之scm基本知識 中提到配置庫結構層次 配置庫一般由動態庫 開發庫 受控庫 靜態庫 產品庫 組成。開發庫 專案成員的工作環境，儲存正處於開發 變更的工作產品 文件 源 開發庫內的工作產品處於存檔控制 版本控制之下，其資訊可能進行頻繁的修改 受控庫 儲存開發過程中某個階...
質量管理漫漫談之目標問題度量方法
目標問題度量 goal question metric，gqm 方法是由maryland大學的victorbasili開發出來的，是一種嚴格的面向目標的度量方法，在這種方法中，目標 問題和度量被緊密的結合在一起。首先確定業務目標，然後確定與達到目標相關的問題，再針對每乙個問題，確定出乙個度量來給出這...
CMD批量建立目錄 配置管理
echo off rem 設定字符集為gbk chcp 936 rem cd 到指令碼所在目錄 set dir dp0 cd d dir rem 檔名陣列，必須以逗號 分隔。符號 為不換行符號。set foldernames 01 會議記錄 02 專案管理 01 輸入資料 02 專案管理 02 輸出...