軟件開發過程中通常會產生各種產品，如代碼，文檔（需求文檔、設計文檔等）和交互文檔（記錄與客戶開會情況），而這些產品可能被多人，多次修改過，因此需要管理，如記錄誰在什么時候改過什么等，這就叫做配置管理。這些產品就叫做配置項。
一、概要
1.1 內容
規范配置管理活動，確保配置項正確地唯一標識并易于存取，保證基準配置項的更改受控，明確基線狀態，在貫穿整個軟件生命周期中建立和維護項目產品的完整性和可追溯性。
1.2 適用范圍
對于不同類別的軟件項目，配置管理的流程不同，可在本流程的基礎上進行裁減。
1.3 術語和縮略語
1.3.1 軟件配置管理（Software Configuration Management，SCM）
軟件配置管理是對軟件修改進行標識、組織和控制的技術，用來協調和控制整個過程。是通過技術或行政手段對軟件產品及其開發過程和生命周期進行控制、規范的一系列措施。配置管理的目標是記錄軟件產品的演化過程，確保軟件開發者在軟件生命周期中各個階段都能得到精確的不同版本的產品配置。
1.3.2 配置（Configuration）
配置是在技術文檔中明確說明并最終組成軟件產品的功能或物理屬性。因此配置包括了即將受控的所有產品特性，其內容及相關文檔、軟件版本、變更文檔、軟件運行的支持數據，以及其他一切保證軟件一致性的組成要素，相對與硬件類配置，軟件產品的配置包括更多的內容并具有易變性。
1.3.3 配置項（Configuration Item，CI）
凡是納入配置管理范疇的
工作成果統稱為配置項（Configuration Item, CI），配置項邏輯上組成軟件系統的各組成部分，一般是可以單獨進行設計、實施和測試的。一個純軟件的CIs通常也稱之為軟件配置項（Computer Software Configuration Items，CSCIs）。
配置項主要有兩大類：
1) 屬于產品組成部分的工作成果，例如需求文檔、設計文檔、源代碼、測試用例等；
2) 項目管理和機構支撐過程產生的文檔。這些文檔雖然不是產品的組成部分，但是值得保存。
每個配置項的主要屬性有：名稱、標識符、文件狀態、版本、作者、日期等。所有配置項都被保存在配置庫里，確保不會混淆、丟失。配置項及其歷史記錄反映了軟件的演化過程。
1.3.4 基線（Baseline）
在配置管理系統中，基線就是一個CI或一組CIs在其生命周期的不同時間點上通過正式評審而進入正式受控的一種狀態，些配置項構成了一個相對穩定的邏輯實體，而這個過程被稱為“基線化”。每一個基線都是其下一步開發的出發點和參考點。基線確定了元素（配置項）的一個版本，且只確定一個版本。一般情況下，基線一般在指定的里程碑（Milestone）處創建，并與項目中的里程碑保持同步。每個基線都將接受配置管理的嚴格控制，基線中的配置項被“凍結”了，不能再被任何人隨意修改，對其的修改將嚴格按照變更控制要求的過程進行，在一個軟件開發階段結束時，上一個基線加上增加和修改的基線內容形成下一個基線。
基線的主要屬性有：名稱、標識符、版本、日期等。通常將交付給客戶的基線稱為一個“Release”，為內部開發用的基線則稱為一個“Build”。
建立基線的好處：
1) 重現性：及時返回并重新生成軟件系統給定發布版的能力，或者是在項目中的早些時候重新生成開發環境的能力。當認為更新不穩定或不可信時，基線為團隊提供一種取消變更的方法。
2) 可追蹤性：建立項目工件之間的前后繼承關系。目的是確保設計滿足要求、代碼實施設計以及用正確代碼編譯可執行文件。
3) 版本隔離：基線為開發工件提供了一個定點和快照，新項目可以從基線提供的定點之中建立。作為一個單獨分支，新項目將與隨后對原始項目（在主要分支上）所進行的變更進行隔離。
二、相關人權責
2.1 項目經理（Project Manager，PM）
責任：
1) 與CCB協商確定項目起始基線和開發里程碑；
2) 接受配置管理計劃，并按相關規定貫徹執行；
3) 接受配置控制委員會的報告。
權利：
1) 提出配置管理計劃的修改要求；
2) 提出管理管理的建議和要求。
2.2 配置控制委員會（Configuration Control Board，CCB）
責任：
1) 制定和修改項目的配置管理策略；
權利：
1) 批準、發布配置管理計劃；
2) 建立、更改基線的設置，審核變更申請；
3) 根據配置管理員的報告決定相應的對策。
2.3 配置管理員（Configuration Management Officer，CMO）
責任：
1) 編制配置管理計劃；
2) 執行配置項管理方案；
3) 執行版本控制和變更控制方案；
4) 編制配置狀態報告；
權利：
向CCB匯報有關配置管理流程中的不符合情況。
2.4 程序庫管理員（Program Librarian，PL）
責任：
1) 配置庫的建立和權限分配；
2) 配置管理工具的日常管理與維護；
3) 配置庫的日常操作和維護；
權利：
1) 各配置項的管理與維護；
2) 對開發人員進行相關的培訓。
2.5 開發人員（Developer）
責任：
1） 根據確定的配置管理計劃和相關規定，提交配置項和基線；
2） 負責軟件集成和版本生成。
權利：
按照軟件配置管理工具的使用模型來完成開發任務。
2.6 測試人員（Tester）
責任：
根據配置管理計劃和相關規定，提交測試配置項和測試基線；
權利：
負責軟件變更的測試驗證。
2.7 軟件質量保證員（Software Quality Assurance，SQA）
責任：
負責配置審核并提交報告。
權利：
對配置審核中發現的不符合項，要求相關責任人進行糾正
三、實施細則
3.1 CCB的成立
3.1.1 項目在設計發注后，由項目經理負責組織成立CCB。
3.1.2 CCB成員組成
CCB成員人數一般為奇數，人數在3～7人范圍內。CCB成員一般包括：
1) 項目經理PM；
2) 配置管理員CMO；
3) SQA；
4) 測試人員Tester；
5) 顧客代表；
6) 主要開發人員等。
3.1.3 CCB的決策機制
尋求CCB成員的一致意見。若不能達成一致，可采取由顧客代表做出決策；或采取少數服從多數的原則，由CCB成員投票確定，投票超過半數即為通過。
3.2 確定配置策略
3.2.1 配置策略確定的時機
CCB成立后，由CCB組織會議根據項目的開發計劃確定各個里程碑和開發策略，CMO負責整理確定的項目基線和配置項列表，并在編制《配置管理計劃》時列明，按約定的時機收集配置項和建立初始基線。
3.2.2 配置項的范圍
1) 技術文檔（Documents）：項目開發計劃、需求分析報告、軟件設計書、質量保證計劃、概要設計書、詳細設計書、測試文檔、技術報告、用戶手冊、總結報告等；
2) 程序（Program）：階段產品、計算機程序、源程序、釋放產品等；
3) 工具（Tools）：自動設計工具、開發工具、測試工具、維護工具等；
4) 交互文檔（Communications）：與客戶或項目組內交互產生文檔，如會談記錄、E-mail、會議紀要、MSN記錄等。
3.3 制定配置管理計劃
3.3.1 《配置管理計劃》的編制
通常情況下，由CMO在設計發注后，開始編制《配置管理計劃》；如有特殊需要，根據合同或項目要求，由CMO在某一項目或項目的某一階段開始前制定《配置管理計劃》。
3.3.2 《配置管理計劃》的內容
《配置管理計劃》應包括以下方面的內容：
1) 該項目對配置管理的要求；
2) 實施配置管理的責任人、組織及其職責；
3) 需要開展的配置管理活動及其進度安排；
4) 采用的方法和工具等。
3.3.3 《配置管理計劃》的由CCB負責審批。
3.4 配置項標識規則
3.4.1 配置項標識要求
1) 合同有明確標識和追蹤要求時，由開發人員按合同要求進行標識，以保證滿足合同追蹤要求。
2) 在開發過程中項目組人員提交的配置項，由項目組人員按照本節相關部分標識規則進行標識。
3) 項目組人員將要標識或已標識的配置項提交給CMO納入配置庫統一管理，并填寫《配置狀態報告》。
3.4.2 配置項標識方式
3.4.2.1 標識項
配置項標識屬性包括：名稱、編號、文件狀態、版本、作者、日期等。本文標識規則對名稱、編號、文件狀態和版本進行了描述和規定。
3.4.2.2 名稱
文件名稱的標識按文檔模板中統一名稱為準。
a) 編號
文檔編號格式為CC_XXX_***_$$$_###，其中CC表示公司，XXX是項目的三位英文字母縮寫表示，***_$$$表示文檔類別，###表示文檔順序號。同時對應每個內容都有固定的一個索引文件CC_XXX_**_$$$_index，目的是為了為本類別下的文件建立一個概要說明列表，保證快速對文檔進行識別和檢索。
3.4.2.3 文件狀態
文件狀態分為“草稿”、“正式發布”和“修改中”三種。
修改處于“草稿”狀態的配置項不算是“變更”，無需CCB的批準，修改者按照版本控制規則執行即可。
當配置項的狀態成為“正式發布”，或者被“凍結”后，此時任何人都不能隨意修改，必須依據配置變更控制的規則執行。
3.4.2.4 文檔版本控制
對于計劃性文檔、技術文檔和用戶文檔，其版本按修改的先后順序確定。新生成的文檔第一次發行為第一版，修改后第二次發行為第二版，以此類推。
3.4.2.5 發行版本控制
最終完成的軟件版本用三位符號表示：“s.x.y”。各符號位的含義如下：
1) “y”為第二次版本號，表示糾正錯誤時的版本升級，用一位數字表示：“1~9”，對上一次產品或項目中的缺陷做修正，第二次版本號增加；
2) “x”為第一次版本號，表示增加功能時的版本升級，用一位數字表示：“0~9”。與上一產品或項目相比，功能進行了小量的增加或修正時，第一次版本號增加，第二次版本號為零，第二版本號為零時可以省略不寫；
3) “s”為主版本號。對產品作重大調整，或與已發行的上一產品相比，在功能與性能上有較大改善時主版本號增加；產品或項目概念全新，第一次完成，版本號為1.0。
3.4.2.6 基線版本標識
內部基線，如計劃基線、設計基線等，在版本號前加Build，如Build 1.0；
發行產品基線在版本號前加Release，如Release 2.0。