如何開展配置管理

如何開展配置管理

在CMMI和IEEE關於配置管理的正式定義是：軟件配置管理是軟件工程中的一項規程，包括相關工具和應用技術（過程或方法），公司用它來管理軟件資產變更。

一般的來說，配置管理的主要目的是進行工作產品管理，其中包括各類文檔、代碼、版本、紀要、bug等等。但不要簡單理解爲，配置管理就是版本管理，配置管理是所有工作產品的管理。

如果一個組織缺乏配置管理，會有哪些問題？【以下8點描述，部分摘錄互聯網相關內容】

1. 組織的知識和過程財富流失

現代的社會競爭激烈，人員流動頻繁，如果由於沒有必要的配置管理流程和工具，大量的文檔和代碼等知識財富必然缺乏統一的管理，可能隨意地保存在項目經理和軟件工程師各自的機器裏，往往會因爲硬盤的故障或人員的離職而永遠的消失，軟件組織的數字財富就這樣因爲缺乏必要的配置管理而白白的流失。

2. 不能及時瞭解項目的進展狀況

現代軟件工程思想認爲越早發現缺陷和風險，採取相應措施的代價越小。CMM /CMMI的 一個重要作用就是要提高軟件開發過程中的可視性，使得問題能夠被及時的發現。然而由於缺乏配置管理的流程和工具的支持，部門主管無法確切得知項目的進展情 況，即便是項目經理也不知道各個開發人員的具體工作，項目進展隨意性很大。所有的問題往往都會集中到項目里程碑時一起出現，這必然會造成巨大的開銷，其結 果往往是容忍部分缺陷存在或者延誤開發週期。所有問題只能寄希望於最終實施時再解決，項目的實施工作因此變成了無法彙報、無法理清、無休止的維護。

3. 缺乏實現並行開發的手段

在日常的開發工作中，經常會出現並行開發的需求，比如：對於一個項目可能要在開發新版本的同時繼續對先前的版本進行必要的維護，或者針對某個特定的版本需要針對不同的客戶同時進行客戶化的修改等等。在並行模式下，不同開發人員可以同時編輯修改某一文件，並行開發有可能產生衝突，但是卻能夠提高開發效率。如果沒有配置管理工具的支持，進行並行開發將十分困難，單單通過人工操作，往往會造成修改過的bug 重複出現或者幾個人進行相同的工作，產生不必要的浪費。

4. 軟件複用率低下

軟件複用是現代軟件工程中的重要思想，是提高軟件產品生產效率和質量的重要手段。軟件產品是一個公司的寶貴財富，代碼的可重用性是相當高的，如何建好知識庫，用好知識庫將對公司優質高效開發產品產生重大的影響。但如果沒有良好的配置管理流程，軟件複用的效率將大打折扣，比如對於複用的代碼進行了必要的修改或改進，卻只能通過手工的方式將發生的變更傳遞給所有複用該軟件的項目，效率如何可想而知。另外由於缺乏進行溝通的必要手段，各個開發人員各自爲政，編寫的代碼不僅風格迥異，而且編碼和設計脫節，往往會導致開發大量重複的難以維護的代碼。

5. 無法開展規範化的測試工作

在傳統的開發方式中，由於缺乏必要的配置管理和變更控制，測試工作只是人們的一種主觀願望，根本無法提出具體的測試要求，加之開發人員的遮醜，測試工作往往是走走過場，測試結果既無法考覈又無法量化，當然就無法對以後的開發工作起指導作用。

6. 對軟件版本的發佈缺乏有效的管理

因爲缺乏有效的管理手段，往往會在產品發佈時卻無法確定該版本所有的組件，或者向用戶提供了錯誤的版本。對於特定客戶出現的問題，無法重現其使用的版本，只能到用戶的現場才能進行相應的調試工作。由於應用軟件的特點，各個不同的客戶會有不同的要求，開發人員要手工地保持多份不同的拷貝，即使是相同的問題，但由於在不同地方提出，由不同人解決，其做法也不盡相同，程序的可維護性越來越差。這些都會延長實施的週期，同時意味着人力物力的浪費。

可見，版本管理只在第六位。

7. 缺乏歷史數據的積累，沒有軟件開發的歷史數據

缺乏軟件開發的歷史數據是大多數軟件項目失敗的關鍵所在，這樣的結論也許使很多人感到吃驚，但事實就是如此。因爲軟件開發的歷史數據是反映軟件開發隊伍的能 力的標尺，沒有了這個標尺，就無法對軟件的開發過程有一個清醒的認識。而良好的配置管理正是收集軟件開發歷史數據的重要來源。

8. 無法有效的管理和跟蹤變更

軟件的一個顯著特點就是易於改變，沒有配置管理將無法對軟件的變更進行有效的記錄、跟蹤和控制。

這八點做好了，就是一個合格的配置管理過程

• 組織的知識和過程財富流失
• 不能及時瞭解項目的進展狀況
• 缺乏實現並行開發的手段
• 軟件複用率低下
• 無法開展規範化的測試工作
• 對軟件版本的發佈缺乏有效的管理
• 缺乏歷史數據的積累，沒有軟件開發的歷史數據
• 無法有效的管理和跟蹤變更

這裏要強調的是，要制定好配置管理計劃纔能有效開展配置管理。也就是說，以上這8條是公司都非常關注的點，但每個項目的重點是不一樣的。文檔、代碼、記錄、版本控制以便於並行開發或回退、變更管理是重中之重。

配置管理的內容涉及的很多，最核心內容有三點。

• 1. 沒有文檔記錄、代碼記錄，我們無法衡量結果是否有效

舉個例子，評審通過的文檔要受控，即入庫。評審紀要不受控，如何知道評審時如何開展的，評審質量如何等等。
開發計劃要求9.10提交代碼，配置管理庫看到的是9.12入庫的，那麼我們怎麼知道是按時提交的代碼？

• 2. 版本控制以並行開發或回退

版本是很關鍵的。做產品不是一蹴而就，中間會出來大量的正式、非正式、補丁版本等等。那麼，在不同的版本上衍生的功能、bug修改如何管理，是否要管理都是配置管理非常看重的點。如果沒有配置計劃，合併基線版本、新增功能代碼增加、bug修改代碼更新等工作，可能會是一個可怕的災難工作。掛一漏萬太容易了。

• 3. 變更管理

這是配置管理的重點項。一個項目、產品開發過程變化是難免的，但要通過配置管理將變化前後的東西記錄下來。變更帶來的是範圍變化，範圍變化帶來的是工作量的變化，那麼進度計劃隨之而變。如果不控制、記錄變更，拿什麼保證最終交付給客戶的客戶要求的100%？

那麼如何制定配置計劃呢？

配置計劃，要根據公司具體情況，結合上面提到的內容制定。這個計劃要把配置庫如何建立、配置權限等等細節給與明確規定。下面給大家一個參考：

1. 引言
   1.1 目的
   1.2 術語定義
   1.3 參考資料

2. 軟件配置
   2.1 軟件配置環境
   2.2 軟件配置項
   2.3 配置管理員

3. 軟件配置管理計劃
   3.1 建立示例配置庫
   3.2 配置標識管理
   3.3 配置庫控制
   3.4 配置的檢查和評審
   3.5 配置庫的備份
   3.6 配置管理計劃的修訂
   3.7 配置管理計劃附屬文檔

4. 里程碑

附錄1 文檔命名規定
1、受控配置庫文件命名規則
2、非受控配置庫文件命名規則
3、提交文檔文件命名規則
附錄2 文檔編碼規範
附錄3 帳號及權限管理
附錄4 配置庫使用規定
文檔修改記錄

上面是配置計劃模板的目錄，從中可以指導配置計劃的開展。

配置管理計劃中，通常給出配置管理名詞定義，以便於項目成員對配置工作的理解。例如：

軟件配置管理：簡稱SCM（Software Configuration Management的縮寫），是在項目開發中，標識、控制和管理軟件變更的一種管理。配置管理的使用取決於項目規模和複雜性以及風險水平。軟件的規模越大，配置管理就顯得越重要。

基線：(BaseLine) 是項目儲存庫中每個工件版本在特定時期的一個“快照”。它提供一個正式標準，隨後的工作基於此標準，並且只有經過授權後才能變更這個標準。建立一個初始基線後，以後每次對其進行的變更都將記錄爲一個差值，直到建成下一個基線。

配置管理員：項目組中負責配置管理工作的角色，該角色可以兼職。在某一開發階段通過評審或某一質量檢查點通過審覈後，配置管理員負責統一添加或修改相關文檔的最新有效版本以及審批人簽字。

配置標識：（Configuration Identification）對軟件項目在開發過程中的資源進行標識，以便識別。

配置檢查：（Configuration Audit）對軟件配置管理過程中的行動進行檢查。

配置管理的核心是配置項的建立和相應權限設置，需要明確定義配置管理員、PM、產品經理等角色和職責。

通常，可以將配置庫分爲受控配置庫和非受控配置庫兩種。

1. 受控配置庫

在項目開發實施的整個過程中，可以根據不同階段的配置管理劃分爲11個受控配置目錄，只有配置管理員擁有增加和修改的權限，其它用戶只有只讀的權限。受控配置庫的目錄爲：

00 初始配置
01 啓動
02 需求分析
03 設計
04 編碼
05 測試
06 安裝
07 總結
08 變更
09 項目管理
10 環境配置

初始配置庫的根目錄中包含XXXX項目的配置文件清單，該文檔包括本項目開發過程中應該提交的文檔的清單，在實際開發過程中，根據實際情況，可以在清單中酌情修改、增加和刪除需要提交的文檔。

2. 非受控配置目錄

設立非受控配置目錄的目的是爲了統一管理和存放開發過程中產生的臨時文檔和過程性文檔，沒有格式及命名上的嚴格要求，使項目組成員在思考、設計時不受太多的限制和約束，能夠更有效地發揮個人能力，符合以人爲本的原則。

在項目初期，可以設立以下三個目錄：

目錄名稱	用途及說明
個人工作區	用於保存項目成員自己編寫的文檔，每個項目成員都有自己獨立的工作目錄
小組工作區	用於保存小組成員寫作編寫的文檔，每個小組都有自己獨立的工作目錄
文檔提交區	作爲非受控配置庫和受控配置庫之間的緩衝，用於提交已經定稿的文檔和代碼，在評審通過後，再由配置管理員取出並提交到受控配置庫中

配置管理要做得好是件不容易的事情，通常還需要一些配置管理工具來操作。業內通常用的配置管理工具很多，有國產的和外國的。各不相同，功能強大程度也不一樣，要根據自身需要篩選。支持常見的平臺有：

• SVN

  目前比較流行的開源配置管理工具，支持幾乎所有的操作系統，適用於中小規模的開發團隊。

• CVS

  支持幾乎所有的操作系統。較高的運行性能，適用於各種級別的開發團隊。

• PVCS

  軟件本身基於Java開發，能夠支持常見的平臺。服務器採用文件系統共享方式，對CPU、內存及網絡要求較高，性能一般，僅適用於中小型項目團隊，不適合於企業級應用。

• VSS –微軟的工具

  僅支持Windows操作系統。相對功能單一、簡陋，適用於幾個人的小型團隊，在數據量不大的情況下，性能可以接受。

• Telelogic CM Synergy

  Telelogic DOORS、Telelogic CM Synergy 和Telelogic Tau 覆蓋了複雜軟件開發的所有關鍵部分：需求管理、變更管理及可視化軟件工程。比較貴。

• ClearCase

  IBM的，非常細緻龐大的工具。服務器採用多進程機制，使用自帶多版本文件系統MVFS，對性能有較大負面影響。做爲一款企業級、全面的開發配置管理工具，適用於大型開發團隊。比較貴。

• Firefly --是國內的一家公司

  軟件本身基於Java開發，可在Windows、Linux、Solaris、HP-UX、AIX等常見平臺上使用，平臺之間的移植也非常方便。服務器採用了多線程的應用服務器，性能表現優秀，做爲一款企業級、全面的開發配置管理，能適用於中小團隊。

• 其他。

FAQ交流討論

• 1. 將代碼放到ＶＳＳ上怎麼組織呢？因爲我們有框架，框架中有項目。是放在一起呢？還是分開放？

這個是基線和分支的管理模式細節，各走各的版本，在不同的點分支、融合。這個是需要公司系統架構師來協助定計劃的。就是說，國外的配置管理工程師是系統級的，是公司產品、項目開發的大牛。可以提出自己在產品基線的規劃。

一般的項目不需要分支，只做簡單的管理即可，即文檔、代碼、版本受控。但項目多了，產品多了，平臺是節省費用和降低管理的好方法。

2. 項目經理需不需要懂配置管理？

項目經理要懂得配置管理方能較好的管理項目。只要是正規公司必須要配置管理，否則，你今天能找到08.9月的版本，代碼麼？其實，配置管理工具對於項目成員使用來說很簡單，大家把文檔、代碼傳上去記得checkout,checkin就行了。

項目經理只要有意識check in文檔、代碼、版本是基本的要求，即沒人力天天做，那麼在項目的階段點集中做下。否則出問題哭都來不及。還會有配置庫異地備份的問題等等。

3. 配置管理人員

在很多中小項目組，配置管理員是兼職的，甚至可以開發、測試分開管理，然後需要QA人員來檢查他們的工作。

大公司配置管理和質量管理，都應有專人任職。版本是一方面，基線是一方面。

4. 甲方如何參與到乙方的配置管理中呢

甲方對配置管理估計不需要太多控制，階段點監察他們的庫足夠了，否則太累。