軟體組態管理基本術語

軟體組態管理（Configuration
Management）是指用於控制系統一系列變化的學科，通
過一系列技術、方法和手段來維護產品的曆史、鑒別和定位產品專屬的版本，並在產品的開
發和發布階段控制變化，通過有序管理和減少重複性工作，保證生產的品質和效率。
不同於組態管理，軟體組態管理以電腦為載體（不論工具和產品），不光維護產品的
狀態，曆史紀錄，同樣還支援儲存、恢複和產品製造。軟體組態管理是軟體工程中涉及概念
較多的一項內容，為了便於說明，下面給出一些軟體組態管理相關術語（主要是軟體配置管
理計劃規範GB/T
12505-90）的定義和說明。
（1） 項目委託單位（Project Entrust
Organization）
項目委託單位指為產品開發提供資金，通常也是（但有時也未必確定產品需求的單位或
個人。
（2）
項目承辦單位（Project Undertaking
Organization）
項目承辦單位指為項目委託單位開發、購置或選用軟體產品的單位或個人。
（3） 軟體開發單位（Software
Development Organization）
軟體開發單位是指直接或間接受項目委託而直接負責開發軟體的單位或個人。
（4）
使用者（User）
使用者指實際使用軟體來完成某項計算、控制或資料處理等任務的單位或個人。
（5）
軟體（Software）
軟體指電腦程式及其有關的資料和文檔，也包括固化了的程式。
IEEE
給出的定義為：電腦程式、方法、規則、相關的文檔資料以及在電腦上運行
時所必須的資料。
由此可見，軟體已不再只是一個程式和一本使用手冊，而是包括大量的程式、文檔和
資料。
（6）
軟體對象（Software
Object）
軟體對象是在項目進展過程中產生的、可由軟體組態管理加以控制的任何實體。每個
軟體對象都具有一個唯一的標識符、一個包含實際資訊的對象實體、一組用於描述其自身特
性的屬性與關係，以及用於與其他對象進行關係操作與訊息傳遞的機制。
軟體對象按其產生方式可分為來源物件（Source
Object）與派生對象（Derived Object）,
按其內容結構形式可分為原子物件（Atomic Object）與綜合物件（Derived
Object）,按其內
部結構形式可分為原子物件（Atomic Object）與綜合物件（composite
Object）,按照軟體開
發的不同時刻（狀態）可分為可變對象（Mutable Object）與不可變對象（Immutable
Object）.
（7）
配置（Configuration）
配置指在組態管理中，軟體或硬體所具有的（即在技術文檔中所陳述的或產品所實現
的）那些功能特性和物理特性。
（8）
重要軟體（Critical Software）
重要軟體指其故障會影響到人身安全，會導致重大經濟損失或社會損失的軟體。
（9）
軟體生存周期（Software Life
Cycle）
軟體生存周期指從對軟體系統提出應用需求開始，經過開發，產生出一個滿足需求的計
算機軟體系統，多面手投入運行，直至該軟體系統“退役”為止。其間經曆系統分析與軟體
定義、軟體開發以及系統的運行與維護等3
個階段。其中軟體開發階段一般又分成需求分析、
概要設計、詳細設計、編碼與單元測試、組裝與整合測試、系統測試以及安裝與驗收等6
個階段。

（10）
軟體開發庫（Software Development
Library）
軟體開發庫指在軟體生存周期的某一個階段期間，存放與該階段軟體開發工作有關的
電腦可讀資訊和人工可讀資訊的庫。
（11）
配置項（Configuration Item）
配置項指一個配置中的實體，它滿足一項最終使用功能，並能在給定的參考點上意象
標識。在GB/T
11457-1995《軟體工程術語》中給出配置項另外一個定義：為了組態管理目
的而作為一個單位來看待的硬體和/或軟體成分，滿足最終應用功能並被指明用於組態管理
的硬體/軟體，或它們的集合體。
軟體組態管理的對象是軟體配置項，它們是在軟體工程過程中產生的資訊項。按照
ISO9000-3
的規定，軟體配置可以是：
-與合約、過程、計劃和產品有關的文檔和資料；
-原始碼、目標代碼、和可執行代碼；
-相關產品，包括軟體工具、庫內的可利用軟體、外購軟體及使用者提供的軟體。
組成上述資訊的所有項目構成了一個軟體配置，而其中的每一項便於工作稱為一個軟
件配置項，這是組態管理的基本單位。在軟體開發過程中，最早的軟體配置項是系統軟體規
格說明書，隨著軟體開發過程的不斷深入，軟體配置項也迅速增加。
軟體配置項基本可劃分為兩種類別：
-軟體基準——經過正式評審和認可的一組軟體配置項（文檔和其他軟體產品），它們作
為下一步的軟體開發工作的基礎，並且只有通過正式的變更控制堆積才能被更改。例如：設
計報告是編碼工作的基礎，設計報告可作為軟體基準。
-非基準配置項——沒有正式評審認可的一組軟體配置項。
這可以從下面角度劃分軟體配置項。
一個軟體系統劃分為幾個配置項要由專案經理所確定的開發策略決定。讀者可以參考
NASA
給出的軟體配置項劃分原則( 《NASA Software Configuration
Management
Guidebooks》,1995)，每個軟體或某集合符合如下條件之一，可視為一個軟體配置項：
-該軟體集合是獨立設計、實現和測試的；
-該軟體集合對總體效能是關鍵的，或存在高風險的，或關係到系統安全性；
-該軟體集合極為複雜，涉及高新技術，或有嚴格的效能要求；
-該軟體集合與其他現有軟體項目或由其他機構提供的軟體之間有直接介面；
-預計該軟體集合在成為可運行軟體之後會有比常規更多的修改；
-該軟體集合包括了某個特定範圍的所有功能，如應用軟體、作業系統等；
-該軟體集合安裝在與系統其他部分不同的電腦平台上；
-該軟體集合被設計成可重複使用的。
下面介紹軟體配置項的命名/編號。
軟體的每個組件/組件的標識必須唯一，以便於用該標識符來跟蹤和報告軟體配置項的
狀態。通常，對每一個軟體配置項要賦予一個標識名稱或符號，軟體配置項的各部分又在該
標識符下附上描述符。NASA-CM-GDBK
給出的一個標識例子是：組成太空梭飛行軟體的
軟體配置項可標識為FS（Flight Software for a
Spacecraft）;而該飛行軟體的組成部分，例如
飛行執行程式可標識為FS_EX，表示它是FS
軟體配置項的第二層次組件；該執行程式的各
元件（子程式）可編號為FS_EX_001、FS_EX_002
等。
因此，可以根據“型號代號_分系統/裝置配置代號_所處研製階段代號_軟體產品分類編
號_配置項編號”原則來對各軟體配置項及其組件、子程式及相關描述文檔進行命名、編號。
在軟體的事個生存周期中，一般包括制定計劃，分析評估、設計，測試，運行/維護等
狀態。相應地可以把軟體組態管理分為設計態，測試態，受控態和運行態4
種狀態，其中受控態即指軟體組態管理項處於組態管理狀態。
（12） 軟體受控庫（Software controlled
Library）
軟體受控庫指在軟體生存周期的某一個階段結束時，存放作為階段產品而釋放的，與軟
件開發工作有關的電腦可讀資訊和人工可讀資訊的庫。軟體組態管理就是對軟體受控庫中
的各軟體項進行管理，因此軟體受控庫也叫做軟體組態管理庫。
（13）
軟體產品庫存（Software Product
Library）
軟體產品庫指在軟體生存周期的系統測試階段結束後，存放最終產品、交付給使用者運
行或在現場安裝的軟體的庫。軟體產品庫可在分系統、系統層上分別設立並維護。如果軟體
產品庫中的產品需要更改則應將些產品在產品庫中加鎖，撮軟體受控庫中相應的軟體配置
項，履行受控庫中的更改控制手續，直至更改完成並確認其能完成指定功能和效能後，方可
再次存入軟體產品庫。
（14）
組態管理（Configuration
Management）
組態管理是對以下各項在運用技術上和行政上的管理和監視的一門學科。對一個配置
項的功能特性和物理特性進行標識並寫成文檔；對這些特性的更改進行控制；對更改處理過
程和實施狀態進行記錄和報告；以及對是否符合規定需求進行驗證。
（15）
介面控制（Interface
Control）
介面控制指描述由一個或多個部門提供的，兩個或兩個以上的配置項介面的所有功能
特性和物理特性的過程。在這些功能特性和物理特性實現之前，要確保對它們所做的修改
已經評審和批准。
（16）
版本（Version）
版本是某一配置項的已標識了的執行個體（Instance）。也可以說，不可變的來源物件經品質
檢查合格後所形成的新的相對穩定的格局（配置）稱為軟體版本。
每個軟體對象可具有一人版本組，它們彼此間具有特定的關係，這種關係用以描述其演
變情況，通常軟體對象的版本組呈樹形結構。
（17）
版本控制（Version
Control）
版本控制就是管理在在軟體生存周期中建立起惡報某一配置項的不同版本。
在軟體工程過程中所涉及的軟體對象都要加以標識。在對象成為基準以前可能要做多
次變更，在成為基準之後也可能需要頻繁地變更。
（18）
釋放（Release）
釋放指在軟體軟體周期的各個階段結束時，由該階段向下階段提交該階段產品的過程。
它也指將系統測試階段結束時所花籃的最終產品向使用者提交的過程，這個過程也叫做交付
（Delivery）。
（19）
基準（Baseline）
基準指一個配置項在其生存周期的某一特定時間，被正式標明、固定並經正式獲批准的
版本。也可以說，基準是軟體生存周期中各開發階段末尾的特定點，又稱裡程碑。只有由正
式技術評審而得到的軟體配置項協議和軟體配置的正式的技術評審而得到的軟體配置協議
和軟體配置的正式文本才能成為基準。它的作用是使各階段工作的劃分更加明確化，使本來
連續的工作在這些點上斷開，以便於檢驗和肯定階段成果。
一個軟體配置項一旦成為基準，就把它存放到項目資料庫（也稱項目資訊庫或軟體倉
庫）中。當一位軟體組織成員想要對基準配置項進行修改時，就把它從項目資料庫中複製到
該工程師的專用工作空間（例如ClearCase
的視圖）中。這個活動記錄在一個記事檔案中。
總之，基準是軟體組態管理的一個很需要概念。從某種意義上講，它是在軟體開發過
程中為進行品質控制而引入的，它是開發進度表上的一個參考點與度量點，是後續開發的穩
定基礎。基準的形成實際上就是對某些配置進行凍結。

（20）
軟體配置（Software
Configuration）
軟體配置指一個軟體產品在軟體生存周期各個階段所產生的各種形式（機器可讀或人工
可讀）和各種版本的文檔、程式及其資料的集合。該集合中的每一個元素稱為該軟體產品軟
件配置中的一個配置項。
軟體工程過程的輸出資訊有
3
種：電腦程式，描述電腦程式的文檔（包括技術文
檔和使用者文檔），資料結構。在軟體工程過程中產生的所有的資訊項（文檔、報告、程式、
表格、資料）就構成了軟體配置。軟體配置是軟體開發進展到某一時刻時產生的全部資訊所
形成的一種格局，它反映並描述了軟體開發階段的狀況。
軟體配置的具體形態可分為以下兩種。
-不可直接執行的材料。例如書寫的文檔、程式清單、測試資料、測試結果等。
-可直接執行的材料。例如目標代碼、資料庫資訊等。它們可由電腦處理，儲存於某
種儲存介質上。
（21）功能基準（Functional
Baseline）
功能基準指在系統分析與軟體定義程式階段結束時，在經過正式評審和獲批准的系統設計規格
說明書中對開發系統的規格說明；或是指在經過項目委託單位和項目承辦單位雙方簽字同意
的協議書或合約中，所規定的對開發軟體系統的規格說明；或是由下級申請並經上級同意或
直接由上級下達的專案工作書中所規定的對開發軟體系統的規格說明。功能基準是最初批准
的功能組態識別。
（22）分配基準（Allocated
Baseline）
分配基準指在軟體需求分析階段結束時，經過正式評審和獲批准的軟體需求規格說明。分
配基準是最初獲批准的分配組態識別。
（23）產品基準（Product
Baseline）
產品基準指在軟體組裝與系統測試階段結束時，經過正式評審和獲批准的有關軟體產品的
全部配置項的規格說明。產品基準是最初獲批准的產品組態識別。
（24）基準組態管理（Baseline
Configuration
Management）
基準組態管理指建立經正式評審和認可，並作為進一步開發工作的基礎的基準的過程。
某些（如軟體設計和代碼）軟體工作產品應該有在預先確定點上建立的基準，並且應該對這
些項施加嚴格的更改控制過程。當與顧客打交道時，這些基準提供控制和穩定性。
（25）基準管理（Baseline
Management）
基準管理是指在組態管理中，運用技術上和行政上的管理來指定一些文檔和更改這些文
檔，這些文檔在某些特定時刻正式標識和建立起基準。
（26）軟體基準審計（Software
Baseline
Audit）
軟體基準審計是指對於軟體基準庫的結構、內容和設施的考查，以便查證基準是否符合
描述基準的文檔。
（27）軟體基準庫（Software
Baseline Library）
軟體基準庫是指儲存配置項及相連記錄的倉庫。
（28）組態管理庫系統（Configuration
Management Library System）
組態管理庫系統是存取軟體基準庫內容的工具和規程。
（29）登錄區（Configuration
Unit）
登錄區是可放入組態管理庫系統的、可從庫中檢索的一個配置項。
（30）流程能力基準（Process Capability
Baseline）
流程能力基準是指用文檔記載的，對在典型環境下由於遵循某特定過程通常所能實現預
期結果的範圍的特性描述。
（31）配置控制組/委員會（Configuration
Control
Board）
配置控制組/委員會是指一組負責評估和審批配置項的變更人員，以確保所有的變更都
是經過審核的。
（32）組態識別（Configuration
Identification）
組態識別是軟體組態管理的一個要素，由為系統所選的配置項及記錄它們功能的物理特
性的技術文檔組成；經核準的配置項的技術文檔是由說明書、圖、表等組成的。為了方便對
軟體配置項進行控制和管理，不致造成混亂，要給它們命名，這就是組態識別的任務。
組態識別主要目的是對變更配置項的軟體行為及變更結果提供一個可跟蹤的手段，避免
軟體開發行為在不受控，混亂的情況下進行，也有利於軟體開發工作以基準漸進的方式完成。
（33）變更管理（Change
Management）
變更管理是軟體組態管理的一個要素，由評估、協調、批准或不批准以及對正式構造配
置標識的配置項實施變更等活動組成。
變更管理主要目的是控制和協調不同責任的軟體開發人員進行有效交流，使軟體開發
人員不會在無序的環境下各自為戰，導致團隊開發的效率出現不可逾越的瓶頸。軟體生存期
內全部的軟體配置是軟體產品的真正代表，必須使其保持精確。軟體工程過程中某一階段的
變更，均要引起軟體配置的變更，對這種變更必須嚴格加以控制和管理，保持修改資訊，並
把精確、清晰的資訊傳遞到軟體工程過程下一步驟。
（34）配置狀態統計（Configuration
Status
Accounting）
配置狀態統計是軟體組態管理的一個要素，由有效管理所需的記錄和報告資訊組成。這
些資訊包括經核準的組態識別表、需要變更的配置狀態和實施經審核的變更狀態。
狀態統計主要目的是在版本控制與過程管理的基礎上，通過量化的資料和報表展現軟體
開發進度的狀態。
（35）組態稽核（Configuration
Auditing）
組態稽核是軟體組態管理的一個要素，它根據需求、標準或合約協議檢驗軟體產品。
組態稽核主要目的是以使用者和Team Dev均認可的衡量尺度（例如與使用者簽定的軟體合
同），通過功能審核及物理審核兩種方式，對軟體實施過程和軟體功能的完整性、正確性進
行檢驗審核。組態稽核確保軟體組態管理系統作用正確，保證測試過後的配置項功能滿足需
求。
組態稽核分為非正式審核和正式審核。
在軟體生存周期的關鍵階段採取非正式審核。例如，在開始系統設計前，一般要進行配
置審核，檢驗需求規格配置的完整性和正確性。在軟體音樂會客戶前採取正式審核。
正式審核包括功能型和物理型兩種類型。功能組態稽核（FCA）是通過對測試方法、測
試流程及測試報告的評價，評鑑軟體配置項的實際效能是否符合設計文檔所確定的要求。物
理組態稽核（PCA）是對配置項的音樂會版本的正式檢測，評鑑該版本是否與所確定的技術
和文檔相一致，並保證軟體音樂會版本中已完成了所有已獲批准的更改，包括了所有要求的軟
件項目、資料、工作規程和文檔。
軟體組態管理的
4 個關鍵要素為組態識別、變更管理、組態稽核、配置狀態統計。
（36）開發組態管理（Developmental Configuration
Management）
開發組態管理是指運用技術上和行政上的管理來指定和控制軟體和其相關的技術文檔，
它們定義一個軟體工作產品在開發期間不斷進化的配置。開發組態管理自在開發人員的直接控
制之下。置於開發組態管理下的配置項不是基準，雖然在開發的某些點上，它們可能被基準
化共置於基準組態管理之下。
（37）關鍵過程域（Key
Process
Area）
一組相關的活動，當這些活動共同完成時，能實現對建立流程能力至關重要的一組目標。
每個關鍵過程域已經定義在單個成熟度等級上。CMU—SEI
確定它們是一些主要構成單元，
用於協助確定一個組織的軟體流程能力和瞭解為更高成熟度等級前進所做的改進。軟體配置
管理是CMM（軟體能力成熟度等級模型）中等級2
的關鍵過程域。
常用的軟體組態管理英文縮寫：
CI Configuration Item 配置項
SCM Software
Configuration Management 軟體組態管理
SCMP Software Configuration Management Plan
軟體組態管理計劃
CR Change Request 變更請求
SCN Specification Change Notice
說明變更注意
FCA Functional Configuration Audit 功能組態稽核
GUI Graphical User
Interface 圖形化使用者介面
PCA Physical Configuration Audit 物理組態稽核
VDD Version
Description Document 版本說明文檔
ECP Engineering Change Proposal 工程變更建議書
CPCI
Computer Program Configuration Item 電腦程式配置項
CSCI Computer Software
Configuration Item 電腦軟體配置項
SCCB Software Configuration Control Board
軟體配置控制組/委員會