一、軟件配置管理的基本概念
1. 軟件配置和配置管理
計算機配置是說明計算機組成的一種專門術語。這種“組成”由用戶的需求決定。通常，計算機系統由CPU、存儲器、輸入/輸出設備、傳輸設備等組成；其中就存儲器而言，除內存外，外存又分軟盤、硬盤、光盤等，它們又有容量和速度之別�，F在，可以將計算機配置定義為是用戶根據不同用途，選擇不同功能-性能的設備和部件組成的最優計算機系統的一種構建方案。推廣到系統，則系統配置就是根據用戶需求優選各種設備，組成最佳系統的一種建構方案（或者是按最佳性能價格比，組成系統的各種設備的一種優化組合）。
同樣，軟件配置也是說明軟件組成的一種術語。與計算機配置中選擇的部件都是現成的產品不同的是組成軟件的部件通常都是要開發的。軟件配置（ software configuration）是指開發過程中，構成軟件產品的各種 文檔、程序及其數據的優化組合。該組合中的每一個元素稱為配置中的一 個配置項(configuration item)。也可以把軟件配置項定義是軟件中可以獨立進行開發的一個實體，該實體包括程序、數據及其相應的文檔和說明。
配置管理要對軟件生存期內各階段的文檔、實體和最終產品的演化和變更進行管理；同時要解決變更的標識、控制和發布等問題。目的是使對設計變更的管理制度化，從而提高開發效率、減少錯誤，保證產品的質量。
軟件配置管理主要任務有以下幾方面的內容
確定軟件配置項；
定義配置項和版本的標識規則；
制定控制變更的權限和實施步驟；
記錄、追蹤配置項的變更狀態；
驗證配置項的正確和完整性；
進行版本管理和發行管理。
2. 配置管理源頭設計變更
軟件設計不可能一步到位，變更是不可避免的；特別是用戶需求多變 （如組織體制、業務流程的變化）必然會引起設計的變更。如何記錄這些變更，需要做二件事。一是要標識這些設計文件（即根據文件名，確定一個唯一的標識符）；二是要動態地記錄這些變更文件（即用版本的方法記錄這些變更）．
3. 軟件配置標識規則
軟件配置標識就是對每個軟件配置項的標識。對一個軟件項目而言，它的配置項有以下內容需求分析文檔、概要設計文檔、詳細設計文檔、軟件實體、測試文檔、客戶文檔等。當然，這些軟件實體及其相應的文檔都可以按其功能進行逐級細化，被分解為分系統、子系統和功能模塊。功能分解后能單獨實現的這些軟件和文檔都是軟件配置項，都應該加以標識。與系統的逐級細化相似，軟件配置項的標識也可以按層次進行，現以3層為例，敘述如下〈第一層標識〉〈第二層標識〉〈第三層標識〉；如果第二層標識是本配置項標識的話，那么第一層標識就稱為前綴（即前一層的標識），第三層標識稱為后綴（即后一層的標識）依次類推。這樣標識規則的好處是可以看出配置項的前后關系，比較直觀又便于理解。有關配置項標識的實例后面還會給出。 [Page]
4 版本管理
標識一個配置項變更（如設計修改）的最好方法就是版本。版本不僅記錄了配置項的當前狀態，為后續開發提供依據；而且還可以根據版本追溯以前的狀態。
版本標識規則
＜配置標識＞V＜主版本號＞·＜版本號＞·＜次版本號＞
主版本號、版本號和次版本號都可以由 1至2位的整數組成。通常，＜次版本號＞可省，因為二個層次的版本號就足以表示一個配置項的變化了；對于大型軟件項目，其版本標識可以擴大到三層或更多的層次。
當配置項出現大的變化時（如因需求變化，導致《功能規格書》需要增加新功能時）主版本號升級（如從 1.**升級為2.**）；當配置項出現小的變化（如局部的完善和修改等，一般在階段結束時，經過評審確認后）主版本號不動，次版本號升級 （如從**.0升級為**.1）。
版本管理是指對軟件生存期內各種軟件實體、文檔等的修改和變化的管理。它的主要的功能就是記錄和追蹤文件的變更，如記錄文件更改的內容、時間和更改 -審批人員等。此外，版本管理的另一個功能是并行開發，它能有效地解決版本的同步以及不同開發者之間的溝通問題，從而減少錯誤、保證質量、提高了效率。
根據經驗，在軟件開發過程中，經常需要保存多個版本。因為有時可能會發生這樣的情況，即在修改一個軟件后，卻發現是改錯了，需要恢復到修改前的一個老版本。如果不保留多個版本，沒有版本管理，會給工作帶來很大的麻煩，也會浪費很多時間。
對于大型軟件公司，為順利解決用戶在使用某個版本時發現的問題，須要借助版本管理工具的支持，否則要解決這類問題是很國難的。因為不是舊版軟件找不到，就是原開發人員已離開了公司。但是，如果按版本管理要求，將文件的不同版本形成一條鏈，并將它們存儲起來。那么就能解決前面提到的找不到舊版軟件的問提。
5. 基本概念
在配置管理中有幾個常用的基本概念是需要弄清楚它們之間的聯系和區別的。這些概念是配置項、里程碑、基線、受控庫、基線庫、產品庫等。
軟件配置項是軟件生存期內，能相對獨立開發的一個程序實體或文檔。
里程碑即通常所說的軟件開發過程中的“階段”，如果說它們之間有 區別的話，那么“階段”強調的是過程，而“里程碑”則強調過程的終點和終點的標識。這些階段可以是需求分析階段、概要設計階段、詳細設計階段等等。
基線 是軟件開發過程中最重要的里程碑，不過基線更強調的是一個開發階段到達里程碑時的結果及其內容，如功能基線是 經過評審和批準的需求規格說明書；產品基線是經集成和確認測試后，經正式審批可交付客戶的軟件產品的全部配置項（包括軟件實體和所有的文檔）。 [Page]
正如清華大學鄭仁杰教授所說 在一個開發階段結束后，要對相應的配 置項進行基線化并形成各類基線�；�就是一個配置項（或一組配置項）在其生命期的不同階段完成時，通過評審而進入受控狀態的一組文檔和程序實體，這個過程被稱為 “基線化”。每個基線都是其下一步開發的基點和參考 點；它們都將接受配置管理的嚴格控制。因此，基線必須通過評審過程建立；基線存在于基線庫中，接受更高權限的控制；基線是進一步開發和修改的基準和出發點。
受控庫 是軟件開發過程中，其修改權限受到控制的文檔庫和程序庫，其中基線庫和產品庫，特別是產品庫的修改權限將受到嚴格的控制，即使是授權修改的人，在修改前還必須得到批準。
基線庫 是受控庫中一些特別重要的庫，如需求（基線）庫和產品（基線）庫。
產品庫 是存放軟件最終產品（即產品基線）的庫，基于它的重要性，對它的修改將受到特別的控制。 產品基線是最初批準的產品配置標識。
6. 配置標識 方法與實例
6.1文檔標識
通常，可把一個軟件項目的文檔分成 3類，即項目的管理文檔、設計文檔和客戶文檔。管理文檔是項目管理過程中形成的文檔，如項目的立項書、開發計劃、質量計劃、成本計劃、配置管理計劃、測試計劃、設計評審報告、測試驗證報告、驗收確認報告、項目總結報告和維護服務報告等。設計文檔是設計過程中產生的文檔，如需求規格說明書、概要設計說明書、詳細設計說明書、源程序、可執行程序等�？蛻粑臋n是供客戶使用的文檔，如用戶操作手冊、系統安裝手冊、系統維護手冊等。
二、軟件配置管理過程及其關鍵活動
一個軟件研發項目一般可以劃分為三個階段：計劃階段、開發階段和維護階段。然而從軟件配置管理的角度來看，后兩個階段所涉及的活動是一致，所以就把它們合二為一，成為“項目開發和維護”階段。
項目計劃階段：
一個項目設立之初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．配置項（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）向相關人員報告配置的狀態。
在此，我想特別指出的是：由于軟件配置管理覆蓋了整個軟件的開發過程，因此它是改進我們的軟件過程、提高過程能力成熟度的理想的切入點。希望本文所描述的這個軟件配置管理的角色分配和工作流程能在實踐中不斷地得到完善，從而使我們的軟件開發活動能夠更加有序、高效的進行！
三、軟件配置管理的意義
提到軟件配置治理，作為從事軟件的人來講，相必都不生疏。要想真正做到實施好配置治理，對于軟件配置治理的意義及其重要性我想應該有必要的熟悉和理解。
軟件配置治理，software configuration management，其簡稱SCM；在軟件配置治理中，有一個要害的一環就是變更治理，而變更治理的基礎是配置項的確定與版本治理。要正確理解這些問題，我們不能僅僅將SCM作為一個治理工具或者在項目洽談與執行中一種合行規定的義務來履行。假如這樣，在開展工作的過程中很輕易使這種工作變成一種官僚式的絆腳石。往往在我們開展項目時，很多合同對配置治理提出了明確的要求，需要熟悉的是，我們所需要進行配置治理的目的是為軟件開發過程中的不同的角色控制和跟蹤治理自已的工作提供支持與幫助。
很多軟件開發過程中碰到的問題都是因配置治理不善而造成的。而發生這些問題需要時間去確定，而且有可能很多可能是重復的問題。有的是不必要的麻煩。比如說一個已花費較大精力和成本解決的高難度的軟件錯誤忽然再次出現，已經開發或完成測試的一個特性神密的消失，一個已經通過完全測試的軟件系統忽然間無法運行。配置治理通過對同一項目中不同人員的所產生的工作產品來幫助我們減少和消除這些問題。問題主要體現在： —— 現在項目的開發大部分都是以疊迭式，漸進式的模型進行開發。在一個版本交付的同時，另一個版本可能還是進行測試，而進行同步開發的后續版本可能還在進行設計與開發階段。在這個循環的過程中，假如客戶發現錯誤，那么不單只是針對客戶的錯誤在現有的版本上進行修改完成就可以，同時要在后續的版本中體現。另外，假如在測試或開發的過程中發現了新的問題，那么對于以前正在使用的版本也需要考慮進行修改。在大系統開發的過程中，問題與修改問題的人，版本都會比較多，很輕易出現混亂的情況。 ——核心代碼，或者公用構件和代碼。在系統的開發過程中，當涉及到公用構件或代碼的修改時，需要使與此相關的人都需要知道。假如沒有有效的代碼治理與報告與協調機制，對于修改的代碼如何使相關人員都提到通知就存在一個問題了。 ——現在的軟件項目，大多都是由一個團體協作完成的，那么，涉及到，對于最后某人對其所作的工作或輸出很輕易損害到其它相關人員的工作。如在一個應該系統的開發過程中，數據流程比較密集，假如其接口的變化，可能會引起很多相關地方的變化。
這些問題是由什么而引的呢，不言而明，在軟件開發過程中的缺少規范的治理而導致出這些問題。需要我們花費很大的精力與時間來處理。那么怎么來對這些問題來形成一個有效的解決方案呢，需要我們對以下的問題進行明確： ——在公司，目前的配置治理是什么，做了些什么？
——目前公司配置治理的狀態是何狀態？
——如何去控制配置的變更項？
——對于配置變更，怎么樣通知相關的個人和組？
——公司的軟件項目都有哪些類型的變更？
——假如在公司或同一項目組，其它人所做的變更會不會影響你所寫的軟件部分？
-
文章來源于領測軟件測試網 http://www.kjueaiud.com/
