工程型軟體項目的組態管理執行個體 (三) ——組態管理規範

組態管理規範
  對於一個一般的項目來說，組態管理規範的內容至少需要包括以下的內容：
  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			其他
……	……	……	……	……

  從這裡的配置庫結構中可以看到，我們在最上層將配置項分為管理類和產品類：管理類中的專案管理部分基本是按照初始－計劃－執行－收尾四個階段來劃分。在項目產品類別中，我們按照需求－設計－實現－測試四個階段劃分目錄，在實現階段，為每個模組劃分了代碼、詳細設計、概要設計和單元測試四個目錄，需要說明的是，在第三層中有一個HLD的目錄，在模組下同樣有一個HLD的目錄，在我們的實際工作中，第三層的HLD目錄用來存放系統層級的概要設計文檔，而模組下的HLD目錄用來存放模組層級別的概要設計文檔。
當然，這裡的配置庫結構僅僅起到了示範作用，在實際使用中，可以根據自己的需要修改。例如，在Module的層級上可以增加一個SubSystem的層，便於在產品整合時更加方便。

  角色定義及許可權分配
  角色是組態管理流程的執行者和參與者，定義明確的角色有利於實現明確的授權和明晰的流程，雖然在實際中可能多個角色由一個人擔任，但還是應該保留角色的定義。
  下面是該項目中我們的角色定義：
  組態管理員
  整個組態管理庫由組態管理員管理。組態管理員負責分配和修改其他成員的許可權，要維護所有目錄和配置項。
  開發經理
  開發經理在本項目中負責主導完成需求分析和系統總體設計，對項目的總體進度負責。開發經理擁有對管理類文檔的讀取許可權，可以對項目類文檔進行讀寫操作；
  開發組長
  開發組長對本小組的工作負有組織和管理工作，同時開發組長也需要承擔一定的開發工作單位。開發組長對管理類文檔有讀取許可權，對本組負責的模組有讀取許可權，對自己負責的模組有讀寫的許可權；
  開發工程師
  開發工程師完成具體的開發工作單位，對自己負責的模組目錄有讀寫權限，對管理類文檔有讀取許可權；
  測試組長
  測試組長負責組織測試，給出測試計劃和測試方案，並核定測試報告。測試組長對所有目錄都有讀取許可權，對測試目錄有讀寫權限；
  測試工程師
測試工程師負責完成測試工作，包括測試案例開發與測試執行，測試報告編寫。測試工程師對自己負責的模組有讀取許可權，對測試案例目錄有讀寫權限。
  QA工程師
QA工程師擁有對所有目錄的讀取許可權，擁有對QA類文檔目錄的讀寫權限。
〔說明〕除組態管理員外，其他所有成員都沒有Destroy目錄和檔案的許可權，這是為了防止誤刪除操作帶來不可挽回的損失。如果需要對目錄進行Destroy操作，必須由組態管理員進行。
【小結】在本章中，我們介紹了組態管理規範的配置項及其命名、配置庫的目錄結構以及組態管理的角色許可權分配。在下一章中，我們將介紹完組態管理規範的其他內容並給出組態管理實施過程中的一些心得體會。