中小企業配置管理基本流程

賈莉英

【摘 要】在中小企業應用配置管理流程中，為了節約資源，提高企業工作效率，必須根據實際情況變通配置流程中的不切實際的環節，針對各子環節有相應的變通方法。

【關鍵詞】中小企業、配置管理流程

【中圖分類號】C29【文獻標識碼】A【文章編號】1672-5158（2013）07-0492-02

一、 引言

軟件配置管理的發展在國內雖然是21世紀的事，但是發展比較迅速，得到了軟件公司的普遍認可。但是對于中小公司，由于重視不夠或缺少相關知識，在實際使用中存在一些問題。中小公司照搬大公司流程存在也不切合實際。

二、 配置管理流程

2.1制定配置管理計劃

在《項目開發計劃》完成后，配置管理員（SCME）參考項目經理制定的《項目開發計劃》完成《配置管理計劃》，《配置管理計劃》中需要明確項目的基線配置項計劃，以及基線計劃等信息。

不同的項目，配置管理計劃的內容可以不同。主要受以下方面影響：

項目的大小和復雜性會影響到配置管理計劃。特別簡單的項目可能只需要一個配置管理工具，簡單管理一下源代碼；但是大項目、復雜的項目則需要詳細的配置計劃。

特殊的項目需要更詳細的計劃。舉例來說，如果企業中絕大多數產品都是完整獨立開發，而某產品使用了開源代碼。那么在該項目的配置計劃中，此點就要考慮。

2.2 項目配置庫的建立

項目立項后，項目經理通知配置管理員建立項目的配置庫，同時為項目組人員開放配置庫權限。

2.3 配置識別

配置識別的目的是識別配置項和基線。

配置項是指處于配置管理之下的軟件或/和硬件的集合體。這個集合體在配置管理過程中作為一個實體出現。

基線是已經通過正式復審和批準的某規約或產品，它因此可以作為進一步開發的基礎，并且只能通過正式的變更控制過程來改變。

配置識別活動包括以下幾個內容：

* 配置項識別

配置項可以分為基線配置項和非基線配置項。基線配置項包括所有的技術類文檔和源程序等；非基線配置項包括項目的各類計劃和報告等。

配置管理工作的關注重點是基線配置項。配置項識別由SCME參照項目開發計劃中的交付物，同項目經理共同識別基線配置項，以及配置項間的依賴關系。配置管理員需要完成《配置管理計劃》中的配置項計劃。

* 配置項標識

配置項的標識，版本等規則，參見企業標識規范。

* 基線建立

一般在項目的不同階段有對應的基線。

> 基線建立

當基線包含的配置項穩定后，由項目經理通知SCME建立基線。基線建立后一般不允許隨意更改。SCME需要對基線庫的權限進行設置。

> 基線變更

當基線建立后，如果基線配置項經過若干次變更，在配置項穩定后，項目經理認為有必要進行變更（再發布等），或者基線不穩定，需要回朔到上一基線，由項目經理通知SCME對基線進行變更。

2.4 版本控制

版本控制能夠簡單、明確地重現軟件系統的歷史版本。一般的配置工具都能自動保存配置項的版本歷史，但是大多時候，針對項目不同階段需要整體化的標識。以下是整體化版本控制的方法：

* 標簽

如果項目只有一個主干，只需要通過打標簽的方式，來辨明當前的整體版本。這樣將來搜索所有的以這個整體版本命名的標簽，就能找到這個整體版本對應的所有文件的正確版本，包括源代碼。

* 分支

不同的客戶，基本需求一定，但是有不同的差別，此時就需要用到分支。使用分支，能夠有效地實現隔離，也實現共享。但是分支是有管理成本的。如果標準版的發布比較頻繁，而客戶又要求變體的發布跟上標準版發布的話，那么需要頻繁創建分支。另一方面，如果變體所在的分支上，包含了一些應該共享的改動，那么應該合并到主干。這樣，相應管理成本也會提高。

2.5變更控制

在項目開發過程中，配置項發生變更幾乎是不可避免的。變更控制的目的就是為了防止配置項被隨意修改而導致混亂。

在瀑布模型的管理中：修改處于“草稿”狀態的配置項不算是“變更”。當配置項的狀態成為“正式發布”，或者被“凍結”后，此時任何人都不能隨意修改，必須依據變更的規則執行。

以下為變更規則：

1） 變更請求

2） 變更審核

3） 配置項出庫

4） 變更實施

5） 變更驗證

6） 配置項入庫

SCME負責實施配置項入庫，確保配置項處于“正式”狀態，并且版本正確。并通知項目經理，項目組人員，質量保證人員等變更已經完成。

但是還有兩種情況，可能不需要嚴格的變更流程：

1） 功能小變動：把程序已有的功能，稍微增強或改變一下。特點是：數量多容易丟，改動量不太大。對這類請求的管理，建議像對缺陷的管理，進行分別跟蹤、處理，直至解決。

2） 迭代模型中管理變更

迭代開發把一個大項目在時間軸上分解成很多小項目，每個小項目被稱作一個迭代。幾乎每次迭代，都會包含需求分析，系統設計、代碼實現，以及集成和測試。這樣就不必刻意走變更流程，只要通過基線或標簽的方式就可以對配置項進行識別。但是在每一個迭代中，出現的對正式發布的配置項進行修改，還需要走變更流程。

2.6配置審計

配置審計是對交付的軟件基線進行檢驗，以驗證其中包含了所有必需的內容，并且這些內容本身都是經過驗證而滿足了需求。配置審計分為功能審計和物理審計兩種：

1） 功能審計是一種驗證審核，它驗證配置項的開發是否完全滿足特定的性能和功能特性，并且所有的操作和支持文檔是齊備的。功能審計主要方法有評審、測試等。一般由研發人員和測試人員來做。

2） 物理審計的目的是為了驗證配置項是按照技術文檔中的規定構建的。

物理審計工作主要由配置管理人員定期（每月）執行。也可因事件驅動進行，比如配置項發布，新版本發布等。

主要進行以下內容：

> 審核配置項一致性，具體檢查點如下：

* 參照配置管理計劃檢查配置項是否按時提交；

配置項是否滿足配置管理相關規定，如配置項標識，版本，狀態，版式等；

配置項信息是否正確；

配置項評審記錄、變更記錄是否完備等。

審核配置項版本一致性：檢查配置管理工作表中配置項版本信息與配置庫中配置項版本信息是否一致，以免工作疏漏造成不一致情況。

審核基線一致性：檢查配置管理工作表中基線內容與配置庫中基線信息是否一致。

審核結構權限一致性：檢查配置庫結構權限是否合理，是否滿足安全適用需要。

2.7配置狀態報告

配置狀態報告工作主要由SCME定期執行。也可因事件驅動進行，比如階段總結，階段評審等。

常用的配置狀態報告分為：

> 周報告

周報告每周進行，主要內容為本周開展的關于SCM的活動總結，以及對SCM工作發現的問題的跟蹤。周報告的審閱人為項目經理、質量部經理。

> 總結報告

總結報告主要用于項目結束時，或者因事件驅動而對SCM工作的當前狀態進行概括總結。總結報告的審閱人為項目經理、質量部經理。

2.8 配置中止

當項目結束時，由項目經理確認此項目已不會再有配置管理方面的變更，由項目經理通知配置管理員項目關閉。

配置管理員關閉該項目的所有讀寫權限，并將項目基準庫內容移入產品庫中。該項目配置管理活動中止。

三、 結束語

本文對配置管理各環節都根據實際進行了簡化變通，或提供了方法，對中小企業的配置工作有一定的借鑒意義。

參考文獻

[1] 董越 理解軟件配置管理 電子工業出版社 2008

[2] [美] Dave Thomas Andy Hunt 版本控制之道——使用CVS 電子工業出版社 2006