軟體配置管理參考

軟體配置管理（Software Configuration Management，SCM）是一種標識、組織和控制修改的技術。軟體配置管理應用於整個軟體工程過程。我們知道，在軟體建立時變更是不可避免的，而變更加劇了專案中軟體開發者之間的混亂。SCM活動的目標就是為了標識變更、控制變更、確保變更正確實現並向其他有關人員報告變更。從某種角度講，SCM是一種標識、組織和控制修改的技術，目的是使錯誤降為最小並最有效地提高生產效率。

軟體配置管理（Software Configuration Management，SCM）作為CMM 2級的一個關鍵域（Key Practice Area，KPA），在整個軟體的開發活動中佔有很重要的位置。正如Pressman所說的：“軟體配置管理是貫穿於整個軟體過程中的保護性活動，它被設計來（1）標識變化，（2）控制變化，（3）保證變化被適當的發現，以及（4）向其他可能有興趣的人員報告變化。” 所以，我們必須為軟體配置管理活動設計一個能夠融合於現有的軟體開發流程的管理過程，甚至直接以這個軟體配置管理過程為框架，來再造組織的軟體開發流程。

一、迅速發展的軟體配置管理

配置管理的概念源於美國空軍，為了規範裝置的設計與製造，美國空軍1962年制定併發布了第一個配置管理的標準“AFSCM375-1，CM During the Development & Acquisition Phases”。

而軟體配置管理概念的提出則在20世紀60年代末70年代初。當時加利福利亞大學聖巴巴拉分校的Leon Presser教授在承擔美國海軍的航空發動機研製合同期間，撰寫了一篇名為“Change and Configuration Control”的論文，提出控制變更和配置的概念，這篇論文同時也是他在管理該專案（這個過程進行過近一千四百萬次修改）的一個經驗總結。

Leon Presser在1975年成立了一家名為SoftTool的公司，開發了配置管理工具：Change and Configuration Control（CCC），這是最早的配置管理工具之一。

隨著軟體工程的發展，軟體配置管理越來越成熟，從最初的僅僅實現版本控制，發展到現在的提供工作空間管理、並行開發支援、過程管理、許可權控制、變更管理等一系列全面的管理能力，已經形成了一個完整的理論體系。同時在軟體配置管理的工具方面，也出現了大批的產品，如：最著名的ClearCase；開源產品CVS；入門級工具Microsoft VSS；新秀Hansky Firefly。

在國外已經有30多年曆史的軟體配置管理，但在國內的發展卻是在21世紀這幾年的事。但是通過專家們的介紹，我們感受到，國內的軟體配置管理已經取得了迅速發展，並得到了軟體公司的普遍認可。

二、軟體配置管理的基本目標

軟體配置管理是在貫穿整個軟體生命週期中建立和維護專案產品的完整性。它的基本目標包括：

目標 1: 軟體配置管理的各項工作是有計劃進行的。

目標 2: 被選擇的專案產品得到識別，控制並且可以被相關人員獲取。

目標 3: 已識別出的專案產品的更改得到控制。

目標 4: 使相關組別和個人及時瞭解軟體基準的狀態和內容。

三、XSSC有關軟體配置管理的方針

為了達到上述目標， 如下的方針應該得到貫徹執行：

技術部門經理和具體專案主管應該使用和遵循XSSC的OSSP中所描述的軟體配置管理的工作過程。

施行軟體配置管理的職責應被明確分配。相關人員得到軟體配置管理方面的培訓。

技術部門經理和具體專案主管應該明確他們在相關專案中所擔負的軟體配置管理方面的責任。

軟體配置管理工作應該享有足夠的資金支援，這需要在客戶，技術部門經理和具體專案主管之間協商。

軟體配置管理應該實施於如下產品：對外交付的軟體產品，以及那些被選定的在專案中使用的支援類工具等。

軟體配置的整體性在整個專案生命週期中得到控制。

軟體質量保證人員應該定期稽核各類軟體基準以及軟體配置管理工作。

使軟體基準的狀態和內容能夠及時通知給相關組別和個人。

四、常用的軟體配置管理工具

現在常用的軟體配置管理工具主要分為三個級別：

• Rational ClearCase，CA CCC/Havest
• Merant PVCS
• Microsoft VSS，CVS

五．軟體配置管理角色職責

對於任何一個管理流程來說，保證該流程正常運轉的前提條件就是要有明確的角色、職責和許可權的定義。特別是在引入了軟體配置管理的工具之後，比較理想的狀態就是：組織內的所有人員按照不同的角色的要求、根據系統賦予的許可權來執行相應的動作。因此，在本文所介紹的這個軟體配置管理過程中主要涉及下列的角色和分工：

專案經理（Project Manager，PM）：

專案經理是整個軟體研發活動的負責人，他根據軟體配置控制委員會的建議批准配置管理的各項活動並控制它們的程式。其具體職責為以下幾項：

• 制定和修改專案的組織結構和配置管理策略；
• 批准、釋出配置管理計劃；
• 決定專案起始基線和開發里程碑；
• 接受並審閱配置控制委員會的報告。

配置控制委員會（Configuration Control Board，CCB）：

負責指導和控制配置管理的各項具體活動的進行，為專案經理的決策提供建議。其具體職責為以下幾項：

• 定製開發子系統；
• 定製訪問控制；
• 制定常用策略；
• 建立、更改基線的設定，稽核變更申請；
• 根據配置管理員的報告決定相應的對策。

配置管理員（Configuration Management Officer，CMO）：

根據配置管理計劃執行各項管理任務，定期向CCB提交報告，告，並列席CCB的例會。其具體職責為以下幾項：

• 軟體配置管理工具的日常管理與維護；
• 提交配置管理計劃；
• 各配置項的管理與維護；
• 執行版本控制和變更控制方案；
• 完成配置審計並提交報告；
• 對開發人員進行相關的培訓；
• 識別軟體開發過程中存在的問題並擬就解決方案。

系統整合員（System Integration Officer，SIO）：

系統整合員負責生成和管理專案的內部和外部發布版本，其具體職責為以下幾項：

• 整合修改；
• 構建系統；
• 完成對版本的日常維護；
• 建立外部發布版本。

開發人員（Developer，DEV）：

開發人員的職責就是根據組織內確定的軟體配置管理計劃和相關規定，按照軟體配置管理工具的使用模型來完成開發任務。

六．軟體配置管理過程描述

一個軟體研發專案一般可以劃分為三個階段：計劃階段、開發階段和維護階段。然而從軟體配置管理的角度來看，後兩個階段所涉及的活動是一致，所以就把它們合二為一，成為“專案開發和維護”階段。

專案計劃階段：

一個專案設立之初PM首先需要制定整個專案的計劃，它是專案研發工作的基礎。在有了總體研發計劃之後，軟體配置管理的活動就可以展開了，因為如果不在專案開始之初制定軟體配置管理計劃，那麼軟體配置管理的許多關鍵活動就無法及時有效的進行，而它的直接後果就是造成了專案開發狀況的混亂並註定軟體配置管理活動成為一種“救火”的行為。所以及時制定一份軟體配置管理計劃在一定程度上是專案成功的重要保證。

在軟體配置管理計劃的制定過程中，它的主要流程應該是這樣的：

• CCB根據專案的開發計劃確定各個里程碑和開發策略；
• CMO根據CCB的規劃，制定詳細的配置管理計劃，交CCB稽核；
• CCB通過配置管理計劃後交專案經理批准，釋出實施。

專案開發維護階段：

這一階段時專案研發的主要階段。在這一階段中，軟體配置管理活動主要分為三個層面：（1）主要由CMO完成的管理和維護工作；（2）由SIO和DEV具體執行軟體配置管理策略；（3）變更流程。這三個層面是彼此之間既獨立又互相聯絡的有機的整體。

在這個軟體配置管理過程中，它的核心流程應該是這樣的：（1）CCB設定研發活動的初始基線；（2）CMO根據軟體配置管理規劃設立配置庫和工作空間，為執行軟體配置管理就阿做好準備；（3）開發人員按照統一的軟體配置管理策略，根據獲得的授權的資源進行專案的研發工作；（4）SIO按照專案的進度整合組內開發人員的工作成果，並構建系統，推進版本的演進；（5）CCB根據專案的進展情況，稽核各種變更請求，並適時的劃定新的基線，保證開發和維護工作有序的進行。

這個流程就是如此迴圈往復，直到專案的結束。當然，在上述的核心過程之外，還涉及其他一些相關的活動和操作流程，下面按不同的角色分工予以列出：

各開發人員按照專案經理髮布的開發策略或模型進行工作；

SIO負責將各分專案的工作成果歸併至整合分支，供測試或釋出；

SIO可向CCB提出設立基線的要求，經批准後由CMO執行；

CMO定期向專案經理和CCB提交審計報告，並在CCB例會中報告專案在軟體過程中可能存在的問題和改進方案；

在基線生效後，一切對基線和基線之前的開發成果的變更必須經CCB的批准；

CCB定期舉行例會，根據成員所掌握的情況、CMO的報告和開發人員的請求，對配置管理計劃作出修改，並向專案經理負責。

綜上所述，配置管理的工作流程如圖1所示：

七. 軟體配置管理的關鍵活動

1．配置項（Software Configuration Item，SCI）識別

Pressman對於SCI給出了一個比較簡單的定義：“軟體過程的輸出資訊可以分為三個主要類別：（1）計算機程式（原始碼和可執行程式），（2）描述計算機程式的文件（針對技術開發者和使用者），以及（3）資料（包含在程式內部或外部）。這些項包含了所有在軟體過程中產生的資訊，總稱為軟體配置項。”

由此可見，配置項的識別是配置管理活動的基礎，也是制定配置管理計劃的重要內容。

軟體配置項分類軟體的開發過程是一個不斷變化著的過程，為了在不嚴重阻礙合理變化的情況下來控制變化，軟體配置管理引入了“基線（Base Line）”這一概念。IEEE對基線的定義是這樣的：“已經正式通過複稽核批準的某規約或產品，它因此可作為進一步開發的基礎，並且只能通過正式的變化控制過程改變。”

所以，根據這個定義，我們在軟體的開發流程中把所有需加以控制的配置項分為基線配置項和非基線配置項兩類，例如：基線配置項可能包括所有的設計文件和源程式等；非基線配置項可能包括專案的各類計劃和報告等。

配置項的標識和控制

所有配置項都都應按照相關規定統一編號，按照相應的模板生成，並在文件中的規定章節（部分）記錄物件的標識資訊。在引入軟體配置管理工具進行管理後，這些配置項都應以一定的目錄結構儲存在配置庫中。

所有配置項的操作許可權應由CMO嚴格管理，基本原則是：基線配置項向軟體開發人員開放讀取得許可權；非基線配置項向PM、CCB及相關人員開放。

2．工作空間管理

在引入了軟體配置管理工具之後，所有開發人員都會被要求把工作成果存放到由軟體配置管理工具所管理的配置庫中去，或是直接工作在軟體配置管理工具提供的環境之下。所以為了讓每個開發人員和各個開發團隊能更好的分工合作，同時又互不干擾，對工作空間的管理和維護也成為了軟體配置管理的一個重要的活動。

一般來說，比較理想的情況是把整個配置庫視為一個統一的工作空間，然後再根據需要把它劃分為個人（私有）、團隊（整合）和全組（公共）這三類工作空間（分支），從而更好的支援將來可能出現的並行開發的需求。

每個開發人員按照任務的要求，在不同的開發階段，工作在不同的工作空間上，例如：對於私有開發空間而言，開發人員根據任務分工獲得對相應配置項的操作許可之後，他即在自己的私有開發分支上工作，他的所有工作成果體現為在該配置項的私有分支上的版本的推進，除該開發人員外，其他人員均無權操作該私有空間中的元素；而整合分支對應的是開發團隊的公共空間，該開發團隊擁有對該整合分支的讀寫許可權，而其他成員只有只讀許可權，它的管理工作由SIO負責；至於公共工作空間，則是用於統一存放各個開發團隊的階段性工作成果，它提供全組統一的標準版本，並作為整個組織的Knowledge Base。

當然，由於選用的軟體配置管理工具的不同，在對於工作空間的配置和維護的實現上有比較大的差異，但對於CMO來說，這些工作是他的重要職責，他必須根據各開發階段的實際情況來配置工作空間並定製相應的版本選取規則，來保證開發活動的正常運作。在變更發生時，應及時做好基線的推進。

3．版本控制

版本控制是軟體配置管理的核心功能。所有置於配置庫中的元素都應自動予以版本的標識，並保證版本命名的唯一性。版本在生成過程中，自動依照設定的使用模型自動分支、演進。除了系統自動記錄的版本資訊以外，為了配合軟體開發流程的各個階段，我們還需要定義、收集一些後設資料（Metadata）來記錄版本的輔助資訊和規範開發流程，併為今後對軟體過程的度量做好準備。當然如果選用的工具支援的話，這些輔助資料將能直接統計出過程資料，從而方便我們軟體過程改進（Software Process Improvement，SPI）活動的進行。

對於配置庫中的各個基線控制項，應該根據其基線的位置和狀態來設定相應的訪問許可權。一般來說，對於基線版本之前的各個版本都應處於被鎖定的狀態，如需要對它們進行變更，則應按照變更控制的流程來進行操作。

4．變更控制

在對SCI的描述中，我們引入了基線的概念。從IEEE對於基線的定義中我們可以發現，基線是和變更控制緊密相連的。也就是說在對各個SCI做出了識別，並且利用工具對它們進行了版本管理之後，如何保證它們在複雜多變得開發過程中真正的處於受控的狀態，並在任何情況下都能迅速的恢復到任一歷史狀態就成為了軟體配置管理的另一重要任務。因此，變更控制就是通過結合人的規程和自動化工具，以提供一個變化控制的機制。

在本文的前面的部分中，已經把SCI分為基線配置項和非基線配置項兩大類，所以這裡所涉及的變更控制的物件主要指配置庫中的各基線配置項。

變更管理的一般流程是：

A) （獲得）提出變更請求；

B) 由CCB稽核並決定是否批准；

C) （被接受）修改請求分配人員為，提取SCI，進行修改；

D) 複審變化；

E) 提交修改後的SCI；

F) 建立測試基線並測試；

G) 重建軟體的適當版本；

H) 複審（審計）所有SCI的變化；

I) 釋出新版本。

在這樣的流程中，CMO通過軟體配置管理工具來進行訪問控制和同步控制，而這兩種控制則是建立在前文所描述的版本控制和分支策略的基礎上的。

5．狀態報告

配置狀態報告就是根據配置項運算元據庫中的記錄來向管理者報告軟體開發活動的進展情況。這樣的報告應該是定期進行，並儘量通過CASE工具自動生成，用資料庫中的客觀資料來真實的反映各配置項的情況。

配置狀態報告應根據報告應著重反映當前基線配置項的狀態，以作為對開發進度報告的參照。同時也能從中根據開發人員對配置項的操作記錄來對開發團隊的工作關係作一定的分析。

配置狀態報告應該包括下列主要內容：

A) 配置庫結構和相關說明；

B) 開發起始基線的構成；

C) 當前基線位置及狀態；

D) 各基線配置項整合分支的情況；

E) 各私有開發分支型別的分佈情況；

F) 關鍵元素的版本演進記錄；

G) 其它應予報告的事項。

6．配置審計

配置審計的主要作用是作為變更控制的補充手段，來確保某一變更需求已被切實實現。在某些情況下，它被作為正式的技術複審的一部分，但當軟體配置管理是一個正式的活動時，該活動由SQA人員單獨執行。

總之，軟體配置管理的物件是軟體研發活動中的全部開發資產。所有這一切都應作為配置項納入管理計劃統一進行管理，從而能夠保證及時的對所有軟體開發資源進行維護和整合。因此，軟體配置管理的主要任務也就歸結為以下幾條：（1）制定專案的配置計劃；（2）對配置項進行標識；（3）對配置項進行版本控制；（4）對配置項進行變更控制；（5）定期進行配置審計；（6）向相關人員報告配置的狀態。

在此，我想特別指出的是：由於軟體配置管理覆蓋了整個軟體的開發過程，因此它是改進我們的軟體過程、提高過程能力成熟度的理想的切入點。希望本文所描述的這個軟體配置管理的角色分配和工作流程能在實踐中不斷地得到完善，從而使我們的軟體開發活動能夠更加有序、高效的進行！

八、實施配置管理的收益

國內很多軟體企業已經逐漸認識到配置管理的重要性，都希望通過實施配置管理來提高軟體開發管理的水平，增強企業自身的競爭力，應對市場的壓力。

針對市場的這些需求，Hansky公司在中國市場推出了業界技術領先的軟體配置管理解決方案，產品包括配置管理工具Firefly和變更管理工具Butterfly。Firefly是Hansky公司推出的軟體配置管理系統，它可以輕鬆管理、維護整個企業的軟體、程式碼和文件。Firefly是一個高效能、執行速度極快的軟體配置管理系統，支援不同的開發、執行平臺，因此它能在整個企業中的不同團隊、不同專案中都得以廣泛的應用。Firefly能夠對團隊開發提供有力的支援，開發團隊一旦擁有了Firefly，就可以非常準確的定義：

軟體將在什麼時間釋出；

當前釋出版本中有哪些功能，由哪些元件構成；

當前版本中加入了針對哪些Bug的修改；

軟體的某個修改是誰認可的；

如何建立新的釋出版本；

等等…

Butterfly是Hansky公司提供的新一代的軟體變更請求管理軟體。它以軟體產品為中心，有效的協調軟體專案中各職位人員的工作，能夠使軟體專案在較短時間內高質量完成。

Butterfly的主要功能如下：

提供對開發過程中的缺陷、建議和任務的追蹤管理；

規劃開發過程，完善原始碼編寫，提高軟體重用率，最大限度保護企業知識財富；

提供豐富的報表功能，以直觀圖形統計開發人員的工作進度和編碼質量，客觀評價員工表現；

優化業務流程，科學的工作流系統使使用者工作起來有條不紊，大大提高工作效率，同時使用者可以根據實際情況簡單、快捷地定製自己的業務流程；

掌握工作進度，在軟體開發的各個階段進行都可以進行強大的過程控制；

開發人員可以明確地瞭解他被分配的開發任務，並根據優先順序依次完成；

提供友好的人機介面，支援工作分配的電子郵件自動通知，方便各種型別的工作人員使用，增加溝通和交流；

對軟體的錯誤進行系統管理，從根本上提高軟體產品競爭力，提高產品質量；

加速開發程式，規範軟體產品開發的各個階段，避免浪費不必要的時間。

Hansky公司的配置管理解決方案給公司帶來的益處將是顯而易見的：管理者能夠輕鬆控制產品的進度、質量；開發人員將有更多的時間進行創造性的工作；測試人員將依照一個標準的流程高效完成日常工作；產品釋出人員能夠確保交到使用者手中的產品的質量。

具體而言，使用者可以在資金、管理水平和保護知識財富等方面得到切實收益。

節約使用者資金

(1) Hansky配置管理系統的總體實施成本低

對硬體系統效能的要求低，可以跨平臺使用，節約了使用者的投資；

安裝簡單，易於維護，無需專職的系統管理員；

功能簡潔、實用，易於學習和掌握，可以有效縮短配置管理系統投入實際使用的週期；

良好的擴充套件性和靈活的License管理方式，以及元件式的解決方案，使得我們的配置管理系統既支援小組模式的使用者，也能夠支援大規模團隊的協同開發工作，並且能夠方便地進行擴充套件，使用者可以根據實際需要，靈活的配置，大大降低了降低初期投入的資金；

具有前瞻性，保護使用者的投資。Hansky公司的軟體配置管理產品採用最新的技術（如純TCP/IP技術、J2EE技術、MS .NET的開發環境等）和全新的應用模式（如三層結構、B/S應用結構等），確保系統在較長的時間內不會落後於同類產品或不需要技術上的更新；

自帶儲存庫增量備份/恢復功能，節約使用者在備份方面的支出。

(2) 縮短使用者的產品開發週期

利用Hansky的Firefly系統對開發資源進行版本管理和跟蹤，可以建立公司級的程式碼知識庫，儲存開發過程中的所有歷史版本，這樣大大提高了程式碼的複用率，還便於同時維護多個版本和進行新版本的開發，最大限度地共享程式碼。利用Butterfly組建開發團體之間的問題跟蹤及訊息通訊機制，通過與電子郵件系統的結合大大增強了開發團體之間的溝通能力，通過豐富的報表功能可對發現的問題進行整理、以報表方式分類報出，作為開發的指導。通過使用Hansky的配置管理套件可以提高開發效率和產品質量，避免了程式碼覆蓋、溝通不夠、開發無序的混亂局面，大大縮短了產品的開發週期。

(3) 降低產品的部署費用

使用Hansky的軟體配置管理解決方案後，使用者可以在Hansky技術專家的幫助下建立規範的配置管理流程，所有的軟體產品將得到統一有效的管理。藉助Firefly和Butterfly，工程人員可以通過訪問伺服器直接獲取所需的最新版本，查詢公司的知識庫，提交變更請求，收集使用者的反饋意見。開發人員無需到現場即可再現使用者環境，集中解決問題，釋出補丁。這樣可以同時響應多個地點的專案，防止開發人員分配到各個專案點、力量分散、人員不夠的弊端，同時節約大量的旅差費用。

提高軟體開發管理的水平

(1) 改進使用者的開發工作模式

使用Hansky的配置管理解決方案，可以有效地改進使用者的軟體開發模式和過程，提高企業軟體能力成熟度的級別。

藉助Firefly和Butterfly，使用者可以：

有效的管理工作空間，各個成員的具有獨立的工作空間，並能記錄其變更集和整個生命週期中的完整變更歷史；

簡便建立分支，支援分支之間的比較與合併，歸併，管理基線；

支援並行開發模式，提高開發效率；

支援異地開發，Firefly通過自動或手動同步不同開發地點的的儲存庫，為地理分佈的開發團隊提供很好的支援；

整合變更請求管理與專案生存週期中的變更記錄與追蹤，優化測試流程；

完善的釋出管理，可以方便的回溯任意版本，為不同的使用者定製應用程式的版本，促進系統的快速部署，提供釋出版本內容的審計能力；

支援變更集和原子事務，確保變更的一致性；

支援離線的版本管理，幫助使用者記錄專案證明週期內的完整歷史；

內建Defect、RFE、Task（問題、建議、任務）工作流，符合正規軟體公司的軟體開發流程。科學的工作流系統可以使公司人員工作起來得心應手，有條不紊，從而大大提高工作效率。

(2) 加強專案管理能力

通過瀏覽器，專案負責人可以方便地檢視專案進展情況以及員工工作情況；

利用Web介面即可實現程式碼複查和專案狀態複查；

豐富的圖表、報告功能，可以自動生成變更統計報告、配置審計報告，支援過程管理與進度分析，能夠幫助管理者進行決策。

(3) 量化工作量考核

傳統的開發管理中，工作量一直是難以估量的指標。靠開發人員自己把握，隨意性過大；靠管理人員把握，主觀性又太強。採用Firefly和Butterfly管理後，系統能夠客觀的記錄員工的工作內容和質量，可以作為工作量的衡量指標。

(4) 規範測試流程

Butterfly和Firefly整合後，可以有效地跟蹤和處理軟體的變更，完整地記錄測試人員的工作內容，測試有了實實在在的工作，測試人員根據修改描述細節對每一天的工作做具體的測試。對測試人員也具有相應的可考核性，這樣環環相扣，有效地增強了對測試的管理。

(5) 加強協調與溝通，增加團隊競爭力

使用Firefly儲存公司的所有知識財富、利用Butterfly的FAQ、檢索以及Email自動通知功能，有效地加強了專案成員之間的溝通，做到有問題及時發現、及時修改、及時通知，卻又不會額外增加很多的工作量，大大提高了開發團隊的協同工作效率。

保護企業的知識財富

從整個企業的發展戰略來說，如何在技術日新月異、人員流動頻繁的情況下，本公司的知識庫及經驗庫，把個人的知識及經驗轉變為公司的知識和經驗，這對於提高工作效率、縮短產品週期以及提高公司的競爭力都具有至關重要的作用。採用科學的配置管理思想，輔之以先進的配置管理工具，可以幫助使用者在內部建立完善的知識管理體系。

(1) 程式碼物件庫

軟體程式碼是軟體開發人員腦力勞動的結晶，也是軟體公司的寶貴財富，長期開發過程中形成的各種程式碼物件就像一個個零件一樣，是快速生成系統的組成部分。然而長期以來的一個事實是：一旦某個開發人員離開工作崗位，其原來所編寫的程式碼便基本成為垃圾，無人過問；或者由於文件不全，無從考究。究其原因，就是沒有專門對每個開發人員的程式碼、元件和文件進行科學的管理，將其應用範圍擴大到公司一級，進行規範化，加以說明和普及。Firefly為程式碼管理提供了一個平臺和倉庫，有利於建立公司級的程式碼物件庫，增進程式碼複用，提高開發重用率和軟體質量。

(2) 業務及經驗庫

通過Firefly和Butterfly，可自動生成完整的開發日誌及問題集合，用文字記錄開發的整個過程，不會因某人的流動而消失，有利於公司積累業務經驗，無論對軟體維護或版本升級，都具有重要的指導作用。此外，利用Butterfly內建的FAQ模組，可以建立檢索方便的經驗庫，傳播和共享集體的智慧。

(3) 安全性和可靠性

由於配置管理系統集中儲存了企業的重要知識財富，因此對其安全性和可靠性有極高的要求。Firefly可以對所有儲存的檔案進行冗餘校驗，使用MD5作為檔案的校驗和，並提供備份和恢復工具，確保了資料的可靠性。同時Firefly支援使用者身份驗證和訪問控制，支援使用者組，便於許可權設定。訪問控制可以針對分支、目錄，甚至單個檔案設定，採用類似Windows NTFS的許可權管理方式，既靈活又安全。這些措施使得企業的知識財富得到了安全可靠的儲存和保護。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14780914/viewspace-374778/，如需轉載，請註明出處，否則將追究法律責任。