關鍵活動
1．配置項（Software Configuration Item，SCI）識別
Pressman對於SCI給出了一個比較簡單的定義：“軟體過程的輸出信息可以分為三個主要類別：（1）電腦程式（原始碼和可執行程式），（2）描述電腦程式的文檔（針對技術開發者和用戶），以及（3）數據（包含在程式內部或外部）。這些項包含了所有在軟體過程中產生的信息，總稱為軟體配置項。”
由此可見，配置項的識別是配置管理活動的基礎，也是制定配置管理計畫的重要內容。
軟體配置項分類軟體的開發過程是一個不斷變化著的過程，為了在不嚴重阻礙合理變化的情況下來控制變化，軟體配置管理引入了“基線（Base Line）”這一概念。IEEE對基線的定義是這樣的：“已經正式通過複審核批准的某規約或產品，它因此可作為進一步開發的基礎，並且只能通過正式的變化控制過程改變。”
所以，根據這個定義，我們在軟體的開發流程中把所有需加以控制的配置項分為基線配置項和非基線配置項兩類，例如：基線配置項可能包括所有的需求文檔、設計文檔、源程式和正式項目整體計畫等；非基線配置項可能包括項目的各類細節計畫和報告等。
標識和控制
所有配置項都都應按照相關規定統一命名，並在文檔中的規定章節（部分）記錄對象的標識信息。在引入軟體配置管理工具進行管理後，這些配置項都應以一定的目錄結構保存在配置庫中。
所有配置項的操作許可權應由SCM嚴格管理，推薦原則是：基線配置項向軟體開發人員開放讀取得許可權；非基線配置項向PM、CCB及相關人員開放。
1．工作空間管理
在引入了軟體配置管理工具之後，所有開發人員都會被要求把工作成果存放到由軟體配置管理工具所管理的配置庫中去，或是直接工作在軟體配置管理工具提供的環境之下。所以為了讓每個開發人員和各個開發團隊能更好的分工合作，同時又互不干擾，對工作空間的管理和維護也成為了軟體配置管理的一個重要的活動。
一般來說，比較理想的情況是把整個配置庫視為一個統一的工作空間，然後再根據需要把它劃分為個人（私有）、團隊（集成）和全組（公共）這三類工作空間（分支），從而更好的支持將來可能出現的並行開發的需求。
每個開發人員按照任務的要求，在不同的開發階段，工作在不同的工作空間上，例如：對於私有開發空間而言，開發人員根據任務分工獲得對相應配置項的操作許可之後，他即在自己的私有開發分支上工作，他的所有工作成果體現為在該配置項的私有分支上的版本的推進，除該開發人員外，其他人員均無權操作該私有空間中的元素；而集成分支對應的是開發團隊的公共空間，該開發團隊擁有對該集成分支的讀寫許可權，而其他成員只有隻讀許可權，它的管理工作由SIO負責；至於公共工作空間，則是用於統一存放各個開發團隊的階段性工作成果，它提供全組統一的標準版本，並作為整個組織的Knowledge Base。
當然，由於選用的軟體配置管理工具的不同，在對於工作空間的配置和維護的實現上有比較大的差異，但對於CMO來說，這些工作是他的重要職責，他必須根據各開發階段的實際情況來配置工作空間並定製相應的版本選取規則，來保證開發活動的正常運作。在變更發生時，應及時做好基線的推進。
2．版本控制
版本控制是軟體配置管理的核心功能。所有置於配置庫中的元素都應自動予以版本的標識，並保證版本命名的唯一性。版本在生成過程中，自動依照設定的使用模型自動分支、演進。除了系統自動記錄的版本信息以外，為了配合軟體開發流程的各個階段，我們還需要定義、收集一些元數據（Metadata）來記錄版本的輔助信息和規範開發流程，並為今後對軟體過程的度量做好準備。當然如果選用的工具支持的話，這些輔助數據將能直接統計出過程數據，從而方便我們軟體過程改進（Software Process Improvement，SPI）活動的進行。
對於配置庫中的各個基線控制項，應該根據其基線的位置和狀態來設定相應的訪問許可權。一般來說，對於基線版本之前的各個版本都應處於被鎖定的狀態，如需要對它們進行變更，則應按照變更控制的流程來進行操作。
3．變更控制
在對SCI的描述中，我們引入了基線的概念。從IEEE對於基線的定義中我們可以發現，基線是和變更控制緊密相連的。也就是說在對各個SCI做出了識別，並且利用工具對它們進行了版本管理之後，如何保證它們在複雜多變得開發過程中真正的處於受控的狀態，並在任何情況下都能迅速的恢復到任一歷史狀態就成為了軟體配置管理的另一重要任務。因此，變更控制就是通過結合人的規程和自動化工具，以提供一個變化控制的機制。
在本文的前面的部分中，已經把SCI分為基線配置項和非基線配置項兩大類，所以這裡所涉及的變更控制的對象主要指配置庫中的各基線配置項。
變更管理的一般流程是：
A) （獲得）提出變更請求；
B) 由CCB審核並決定是否批准；
C) （被接受）修改請求分配人員為，提取SCI，進行修改；
D) 複審變化；
E) 提交修改後的SCI；
F) 建立測試基線並測試；
G) 重建軟體的適當版本；
H) 複審（審計）所有SCI的變化；
I) 發布新版本。
在這樣的流程中，SCM通過軟體配置管理工具來進行訪問控制和同步控制，而這兩種控制則是建立在前文所描述的版本控制和分支策略的基礎上的。
4．狀態報告
配置狀態報告就是根據配置項運算元據庫中的記錄來向管理者報告軟體開發活動的進展情況。這樣的報告應該是定期進行，並儘量通過CASE工具自動生成，用資料庫中的客觀數據來真實的反映各配置項的情況。
配置狀態報告應根據報告應著重反映當前基線配置項的狀態，以作為對開發進度報告的參照。同時也能從中根據開發人員對配置項的操作記錄來對開發團隊的工作關係作一定的分析。
配置狀態報告應該包括下列主要內容：
A) 配置庫結構和相關說明；
B) 開發起始基線的構成；
C) 當前基線位置及狀態；
D) 各基線配置項集成分支的情況；
E) 各私有開發分支類型的分布情況；
F) 關鍵元素的版本演進記錄；
G) 其它應予報告的事項。
5．配置審計
配置審計是指在配置標識、配置控制、配置狀態記錄的基礎上對所有配置項的功能及內容進行審查，以保證軟體配置項的可跟蹤性。一般的，獨立的SCM可以擔當配置審計。
總之，軟體配置管理的對象是軟體研發活動中的全部開發資產。所有這一切都應作為配置項納入管理計畫統一進行管理，從而能夠保證及時的對所有軟體開發資源進行維護和集成。因此，軟體配置管理的主要任務也就歸結為以下幾條：（1）制定項目的配置計畫；（2）對配置項進行標識；（3）對配置項進行版本控制；（4）對配置項進行變更控制；（5）定期進行配置審計；（6）向相關人員報告配置的狀態。
由於軟體配置管理覆蓋了整個軟體的開發過程，因此它是改進我們的軟體過程、提高過程能力成熟度的理想的切入點。
