Posted on 2011-01-18 13:16
幻海藍夢 閱讀(1250)
評論(0) 編輯 收藏 所屬分類:
版本管理 、
配置管理
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）向相關人員報告配置的狀態。
在此，我想特別指出的是：由于軟件配置管理覆蓋了整個軟件的開發過程，因此它是改進我們的軟件過程、提高過程能力成熟度的理想的切入點。希望本文所描述的這個軟件配置管理的角色分配和工作流程能在實踐中不斷地得到完善，從而使我們的軟件開發活動能夠更加有序、高效的進行！
原文：http://blog.donews.com/MatthewGrant/archive/2010/02/22/1581584.aspx