我們在討論軟件工程化的時候經常會說起配置項這個名詞，討論軟件測試時也經常說配置項測試，那到底什么叫配置項？配置項（CI）和軟件配置項（CSCI）到底有什么關系？配置項到底應該怎么劃分才是合理的？

我們搞技術的，說話要有依據，讓我們從國標的定義說起。

首先搞清楚什么是配置項：

在國標《GB/T 11457-2006 信息技術與軟件工程術語》里，對這幾個概念都有明確的定義：

配置項（configuration item，縮寫為CI），是為配置管理設計的硬件、軟件或兩者的集合。它在配置管理中作為單個實體來對待。

計算機軟件配置項（computer software configuration item，縮寫為CSCI），是為配置管理設計的軟件的集合，在配置管理的過程中，作為單個實體對待。

在《GJB/Z 141-2004軍用軟件測試指南》中，對軟件配置項也有描述：

軟件配置項是為獨立的配置管理而設計的并且能滿足最終用戶功能的一組軟件。

從配置項的定義可以得出，配置項（CI）和軟件配置項（CSCI）是包含與被包含的關系，配置項包括硬件配置項和軟件配置項兩部分。我們平常在CMMI，GJB5000A和軟件測試中通常指的配置項是軟件配置項（CSCI）。

從定義可以看出，軟件配置項這個概念的引入目的是為了更好的做配置管理，那么什么是軟件配置管理？我們再從概念入手，說一說軟件（software）、軟件配置（software configuration,簡稱SC）和配置管理（configuration management，簡稱CM）。

軟件：與計算機系統的操作有關的計算機程序、規(guī)程和可能相關的文檔。

軟件配置：軟件產品在不同時期的組合，該組合隨開發(fā)工作的進展而不斷的變化。

配置管理：應用技術的和管理的指導和監(jiān)控的方法以標識和說明配置項的功能和物理特性，控制這些特征的變更，記錄和報告變更處理和實現狀態(tài)，并驗證與規(guī)定的需求的遵循性。

從軟件的定義可以開出，軟件并不是說我們通常意義上理解的簡單的一個程序，而是包括規(guī)約和相關文檔。我們常常說的軟件測試，不僅指的是被測的程序，還包括涉及的軟件需求，設計等文檔（被測對象可能還要包括相關的數據，特別是現在的人工智能軟件，這一點標準里沒有提到），他們共同組成了一個軟件實體。為了控制該實體的功能和物理特性與設計期望相一致，我們需要在配置管理中對其特性進行標識、記錄與驗證。

在配置管理過程中，配置項是作為單個實體來對待的。為了便于理解配置項的定義，就需要搞清楚什么叫做“單個實體”。
任何一篇非獨立的文檔、數據、規(guī)程或者程序，是不是可以作為單個實體？答案是否定的，因為它們只是產品的一部分，單獨存在是沒有意義的。如果在配置管理中將每一個元素都作為配置項，就會產生配置管理過于繁瑣的后果。

這又引出了另外一個問題：如果將一個系統的所有軟件都劃成一個配置項，或者少劃幾個配置項，這樣管理活動就會少很多，豈不是皆大歡喜？

這樣會造成新的問題。配置管理過程的各種審核和管理都是基于配置項的。在配置管理過程中，會采用“鎖定”的方法來保證開發(fā)過程的統一（這里暫時不考慮分支合并）。當開發(fā)人員甲申請對某個配置項進行修改，系統將配管系統中的配置項下發(fā)給甲之后，系統應將該配置項進行鎖定，避免其他人員在甲更改該配置項的過程中對同一配置項進行更改，該鎖定過程會持續(xù)到甲完成更改，將內容提交系統后結束。在此期間內，其余人是不能對同一配置項提出更改要求的，否則就會導致版本的混亂。配置管理系統的“取回——鎖定——更改——提交并解除鎖定”過程，在互聯網的很多開源項目中（如Git中的很多項目），是由公共配置管理系統自動控制的，而在很多科研單位，是由配置管理員人工控制的。不論哪種控制方式，配置管理的核心內容就是配置控制，而實現配置控制，合適的控制粒度都是合理控制和高效率開發(fā)的基礎。所以，將很多軟件劃到一個配置項是不合適的。

有人可能會說：“我們的配置項都是總體單位定的，總體單位劃配置項時，將我們單位分系統中所有軟件，大概七八個都劃成一個配置項，這是總體定的，所以我們單位的配置管理也只劃分了一個配置項。”這種說法是否合理？

從項目的總體方來說，這樣的安排沒有問題。總體方完全可以在配置管理中將一個分包方的所有軟件產品作為一個配置項進行管理。但作為產品的分包承制方，在拿到總體的要求后，應做自己的配置項劃分。換句話說，一個項目的配置項劃分應該分成不同的層級，越往下配置項劃分越細。《GJB 5000A-2008 軍用軟件研制能力成熟度模型》中也有描述：“工作產品的配置管理可以按照多個粒度級進行實施。”對于總體方，可按照將工程中涉及的軟件產品按照適合自己管理的方式劃分出若干配置項，而配置項分配到了各級承研單位，應將自己承研的部分再次細化成更小的配置項。承研單位的某一個配置項可以作為該工程承研上級單位的配置部件或配置單元。這就體現了配置管理的多粒度級的特性。

那么如何劃分配置項？我們以例子進行說明。

某單位被分配一個分系統研制任務，其軟件在總體單位按照一個配置項管理。在此單位組織人員對分系統進行需求分析與設計后，將系統功能設計成A，B兩個軟件實現。其中A軟件由甲工程師負責完成，B軟件因為規(guī)模較大，由乙和丙兩位工程師共同完成。這種情況下，怎么劃分配置項才合理？

比較合理的方式是在該單位的組織層面，劃分成A軟件與B軟件兩個軟件配置項，在課題組內部的配置管理中，將B軟件按照乙和丙的分工，劃分成兩個配置項（或者配置部件）進行多級管理。如果結合傳統“三庫”管理制度，可以在組織級的受控庫和產品庫中將A與B劃分成兩個配置項進行管理，在開發(fā)組內部的開發(fā)庫中將A劃分成一個配置項，將B軟件劃分成兩個配置項（配置部件）進行管理。

需要說明的是，GJB5000A里邊并又沒有軟件配置項如何劃分作出具體的說明。因此，本文的觀點只是在作者從自己的工程經驗角度所論述的最佳的定義方法，并不代表GJB5000Ａ的官方解讀。

總結

以上是生活随笔為你收集整理的聊一聊软件配置项的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。