對于一個一般的項目來說，配置管理規范的內容至少需要包括以下的內容：
1、配置項及其命名規則；
2、配置庫文件目錄結構；
3、角色和權限定義；
4、配置項變更流程；
5、配置項發布；
6、基線定義和基線變更。
配置項及其命名規則
對我們的項目來說，配置項需要包括以下的內容：
1、項目管理過程文檔；
a) 項目任務書；
b) 項目計劃；
c) 項目周報；
d) 個人日報和周報；
e) 項目會議紀要；
f) 培訓記錄和培訓文檔；
2、QA過程文檔；
a) QA不符合報告；
b) QA周報；
c) 評審記錄；
3、工作產品
a) 需求文檔；
b) 設計文檔；
c) 代碼；
d) 測試文檔；
e) 軟件說明書和手冊；
4、項目中使用的第三方產品
上文中用紅色部分標識的是容易遺漏的配置項，尤其是第4個（項目中使用的第三方產品），實際上，一個工程型的項目會大量使用第三方的軟件（例如，我們的產品中就使用了IBM的MQSeries、Oracle、一些第三方的開發控件），對這些產品的管理至少可以解決三個方面的問題：
1、版本配合的問題：大部分的第三方軟件在升級之后，并不能實現二進制層面上的兼容，需要對原有的代碼重新編譯；甚至有的第三方軟件在升級之后，API層面上的兼容性都做不到；因此，在工程實施的過程中，版本的配合問題是一個需要關注的問題；
2、發布的完整性問題：一般來說，比較大型的第三方軟件在發布過程中都不會有遺漏，但對一些小的第三方軟件來說，比如我們使用的許多perl的CPan模塊，如果在開發過程中沒有有意識的進行管理的話，很容易就會發生遺漏；
3、在某些特殊條件下由于第三方軟件的變化引起的基線變更：這種情況極少會發生，但在我們以前的項目中，確實還遇見過。一般是因為原來選型時使用的第三方軟件不能滿足要求，只能通過更換新的第三方軟件，這就補課避免地需要變更基線（例如需求文檔、設計文檔等）；將第三方軟件納入配置管理的范疇可以更方便地管理基線的變更。
關于第三方軟件產品配置項的管理還有一點需要說明：由于第三方軟件有可能會比較大，而且相對我們的項目來說，是很少會發生變更的（一般在一個項目過程中，不會采用不同的配置項的命名可以便于查找相關配置項。配置項的命名包括兩個方面的內容：
1、配置項標識：在我們的項目中，一般使用“項目名_配置類別_配置項特殊標識”來命名。下表列出了我們在項目中使用的配置類別命名：
| 配置類別 | 命名 | 配置類別 | 命名 |
| 項目任務書 | PT | 項目計劃 | PP |
| 項目周報 | PR | 個人日報和周報 | PER |
| 項目會議紀要 | PM | 培訓記錄和培訓文檔 | TR |
| QA不符合報告 | QAP | QA周報 | QAR |
| 評審記錄 | RR | 需求文檔 | REQ |
| 設計文檔 | DD | 代碼 | CODE |
| 測試文檔 | TD | 軟件說明書和手冊 | MAN |
| 項目中使用的第三方產品 | PART3 |
配置項命名中的“配置項特殊標識”根據配置類別的不同而不同。比如，對“設計文檔”，如果細分的話，可以分為“概要設計”和“詳細設計”；對“代碼”，可以按照模塊來命名配置項。
2、配置項版本命名：配置項版本命名是針對配置項的版本進行命名，在我們的項目中，配置項版本通過對Project的Label操作來實現，配置項版本的命名需要能清楚標識配置項的狀態。一般說來，配置庫至少包括個人工作區、受控庫、發布區三個部分，在我們的項目中，所有的配置項都保存在一個VSS庫中，對這三個部分的劃分是通過邏輯劃分方式進行的，具體來說，就是通過配置項版本命名來劃分的。因此，我們配置項的版本命名規定如下：
a) 基線版本：按照基線的狀態，我們這個項目中的基線有兩個方面：一是作為里程碑的基線；另一個是模塊的階段性成果基線（對工作產品而言），由模塊的負責人確定。
里程碑基線――對我們的項目來說，采用的是迭代的開發過程，以一個迭代過程為例，分為需求、概要設計、詳細設計、代碼實現、單元測試、集成測試、系統測試七個階段，每個階段都需要產生里程碑。對每個里程碑都有明確的標識標明當前狀態。
階段性成果基線――階段性成果主要體現在代碼過程中，比如代碼進行到一個階段，開發組長認為代碼的這個狀態可以保留，就可以確定為一個代碼基線。這種基線一般不需要通過評審等正式手段來確定，但也必須有相應的驗證手段；比如在我們的項目中，在代碼階段，確定代碼基線的責任人是開發組長，但開發組長必須保證代碼基線符合一定的條件。
b) 其他版本：除基線版本外，有時候還需要在開發和維護過程中確定其他版本。例如，產品在測試過程中不斷的問題修復過程中，可能會有多種反復，此時需要將每次修改的內容作為一個版本。
關于版本，還有另一個需要注意的問題。一般來說，按照模塊來劃分，每個模塊有自己的版本演進比較合理。首先，一個模塊一般是由一個或兩個開發人員完成的；其次，一個模塊的功能會比較單一且獨立，在版本的演化過程中便于控制，也不會和其他模塊產生過于復雜的關系。而產品的版本則需要由各個模塊的不同版本組成，這個縱橫的關系需要很好地管理，我們的做法是在VSS庫上用Label來標識，同時維護一張描述產品版本和模塊版本關系的矩陣圖便于追蹤。
配置庫目錄結構
在確定了配置項之后，就可以確定配置庫的目錄結構了。配置庫的目錄結構直接關系到配置管理的工作量和使用的方便性，所以需要根據自己的需要確定一個合理的結構。
在確定配置管理庫目錄結構的時候，我們曾經考慮過兩種產品目錄結構的方式：一種是按照模塊劃分，在模塊下再劃分諸如設計文檔、代碼等目錄；另一種方式是按照產品類型劃分，例如首先是文檔、代碼，然后在其下按照模塊劃分。這兩種方式都有自己的優點，最終我們還是選擇了前一種劃分方式，一方面是考慮便于進行權限的分配，另一方面是考慮到便于將同一模塊的所有內容組織起來進行版本的管理。
下表是我們在實際中采用的配置庫結構（部分）：
| 第一級 | 第二級 | 第三級 | 第四級 | 說明 |
| M | 管理類文檔 | |||
| PM | 項目管理 | |||
| 0－Init | 初始階段 | |||
| PC | ||||
| PTR | ||||
| PN | ||||
| 1－Plan | 計劃階段 | |||
| …… | …… | …… | …… | …… |
| QA | ||||
| 0－PPQAP | 質量保證計劃 | |||
| …… | …… | …… | …… | …… |
| P | 項目產品 | |||
| 0－Req | 需求階段 | |||
| 0－CRS | 客戶需求 | |||
| 1－SRS | 需求分析文檔 | |||
| 2－RTM | 需求跟蹤矩陣 | |||
| 1－Des | 設計階段 | |||
| 0－HLD | 概要設計 | |||
| 1－DBD | 數據庫設計 | |||
| 2－Imp | 實現/編碼階段 | |||
| 0－Module1 | 模塊1 | |||
| 0－COD | 代碼 | |||
| 1－DDS | 詳細設計 | |||
| 2－HLD | 概要設計 | |||
| 3－UNT | 單元測試 | |||
| …… | …… | …… | …… | …… |
| 3－Test | ||||
| 0－Int | 集成測試 | |||
| 1－Syt | 系統測試 | |||
| …… | …… | …… | …… | …… |
| 4－Man | 手冊 | |||
| …… | …… | …… | …… | …… |
| 5－Others | 其他 | |||
| …… | …… | …… | …… | …… |
當然，這里的配置庫結構僅僅起到了示范作用，在實際使用中，可以根據自己的需要修改。例如，在Module的級別上可以增加一個SubSystem的層，便于在產品集成時更加方便。
角色定義及權限分配
角色是配置管理流程的執行者和參與者，定義明確的角色有利于實現明確的授權和明晰的流程，雖然在實際中可能多個角色由一個人擔任，但還是應該保留角色的定義。
下面是該項目中我們的角色定義：
配置管理員
整個配置管理庫由配置管理員管理。配置管理員負責分配和修改其他成員的權限，要維護所有目錄和配置項。
開發經理
開發經理在本項目中負責主導完成需求分析和系統總體設計，對項目的總體進度負責。開發經理擁有對管理類文檔的讀取權限，可以對項目類文檔進行讀寫操作；
開發組長
開發組長對本小組的工作負有組織和管理任務，同時開發組長也需要承擔一定的開發任務。開發組長對管理類文檔有讀取權限，對本組負責的模塊有讀取權限，對自己負責的模塊有讀寫的權限；
開發工程師
開發工程師完成具體的開發任務，對自己負責的模塊目錄有讀寫權限，對管理類文檔有讀取權限；
測試組長
測試組長負責組織測試，給出測試計劃和測試方案，并核定測試報告。測試組長對所有目錄都有讀取權限，對測試目錄有讀寫權限；
測試工程師
測試工程師負責完成測試工作，包括測試用例開發和測試執行，測試報告編寫。測試工程師對自己負責的模塊有讀取權限，對測試用例目錄有讀寫權限。
QA工程師
QA工程師擁有對所有目錄的讀取權限，擁有對QA類文檔目錄的讀寫權限。
〔說明〕除配置管理員外，其他所有成員都沒有Destroy目錄和文件的權限，這是為了防止誤刪除操作帶來不可挽回的損失。如果需要對目錄進行Destroy操作，必須由配置管理員進行。
【小結】在本章中，我們介紹了配置管理規范的配置項及其命名、配置庫的目錄結構以及配置管理的角色權限分配。在下一章中，我們將介紹完配置管理規范的其他內容并給出配置管理實施過程中的一些心得體會。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
