軟件配置管理是一套管理軟件開發和軟件維護的方法和規則，其最終體現的是維護軟件產品的一致性和完整性。下面是小編整理的關於配置管理和變更管理的文章，歡迎參考!
變更常有
所在銀行科技部已經建立了比較完善的項目管理體系和質量保障體系，但要應對分行或支行需求變更和相關軟件版本配置管理的問題，如果沒有一整套的解決措施和工具的支持，就會出現以下問題：
1)分行反映的缺陷更改不能快速響應，不能快速分配缺陷到指定的開發人員，只能依靠口頭或文檔的傳輸，缺乏一個整合開發商服務人員、產品經理(或項目經理)、開發團隊領導、開發人員、分行領導的信息傳遞和交流的平臺。
2)分行的需求變更不能快速響應。分行的需求變更和軟件版本配置只能依靠手工備份，因而，自身不能快速有效地管理各系統的版本，缺乏版本基線的管理策略。
針對以上問題，可以考慮採用軟件配置管理這一關鍵域的思路系統地解決以上問題。配置管理是整個集成軟件項目正常運作的一個管理支撐平臺，其目的就是將有關該項目的客戶、客戶服務人員、產品經理(或項目經理)、開發團隊領導、開發人員、高層領導等項目干係人的工作協同起來，實現高效的溝通，及時地共享工作成果。
配置管理的基本功能包括配置標識、變更控制、配置狀態發佈和配置審計。變更控制是配置管理的重要內容，其目的是爲了在動態中保證配置項的完整性、一致性和可回溯性，保證配置項的變更過程規範、受控、有完整記錄，受影響的各方均能及時瞭解情況，並協調一致。
控制不可少
變更控制是通過創建產品基線，在產品的整個生存週期中控制它的發佈和變更。配置控制指在配置項標識正式確定之後，對配置項特別是對已提交的代碼、相關文檔和數據等的變更進行系統地跟蹤和控制的過程，主要包括變更的提出、確定配置項的控制等級、變更的評價、變更的處置、實施經批准的變更、對變更進行驗證和結束變更。變更控制的目的是建立一套控制軟件修改的機制，保證生產符合質量標準的軟件和保證每個版本的軟件包含所有必需的元素及工作在同一版本中的各元素中可以正常工作，以確定在變更控制過程中控制什麼，如何控制，誰控制變更、何時接收變更、批准和檢驗。
配置項級別
1)已基線化的配置項是指已完成該配置項的審覈和批准，並且成爲創建或修改其他配置項的輸入。例如：一個設計文檔已審覈、通過、簽發，並且成爲編碼活動的基礎。
2)受管理和受控的配置項是指已提交審覈，但還沒有批准通過的配置項。例如：一個正在進行審覈的設計文檔。
3)受控的配置項指已置於版本控制，但項目組不能直接進行改動的配置項。例如：用戶提供的軟件、購買的工具、產品標準等等。
變更請求的狀態
軟件變更、軟件優化和軟件bug都是產生變更的原因。變更申請人(用戶或產品經理)提出變更時，首先要對受控的'配置項的修改提出一個變更請求，說明對軟件變更的需求。這是因爲變更控制過程是通過變更請求的流動來實現的，而且對軟件的任何請求都必須和相應的變更請求對應。
變更請求的狀態包括：
1)提交：變更請求提交給配置管理員;
2)拒絕：變更控制委員會拒絕變更請求;
3)接受：變更控制委員會接受變更請求;
4)掛起：變更請求被掛起，以後再作決定;
5)已驗證：更改已執行和驗證;
6)關閉：驗證並歸檔配置項，更新的配置項提交給用戶(例如：通過版本發佈)。
變更請求的類型
1)增強型：變更請求要求對已批准的項目功能進行增強。
2)改進型：變更請求不會造成功能更改，但使配置項的維護更加有效率。
3)糾錯型：變更請求對錯誤進行修正(諸如bug)。
變更請求的優先級
在評價變更請求的優先級時，要對請求變更的配置項進行系統的分析，確定變更影響範圍和修改的程度，確定變更的級別，爲確定是否有必要記錄變更提供參考依據。變更請求的優先級可分爲三類：
1)高：嚴重地影響一些用戶或許多用戶。
2)中：對用戶造成不方便，或是可以採取相應的變通方法處理的主要問題。
3)低：小問題。
修改完後簽入(Check in)
對變更的處理，要按照變更控制規程，將變更請求及其相關附件提交軟件配置控制委員會審批。配置管理組根據審批意見處理變更請求。
只有配置管理員具有Check in權限。在進行Check in之前，確認下面的事項：
1)所有對配置項所做的修改被批准;
2)所有的更改都經過審覈或驗證;
3)所對應的變更請求已經被保存起來;
4)所有相關的審覈記錄被保存;
5)Check in時須註明Check in因，如對應的變更請求。
從數據庫中籤出(Check out)
1)對於文檔，配置管理員在更改審批人同意後，從配置庫中Check out配置項，發給項目組成員修改。
2)Check out時須註明Check out原因，如將要修改的問題。
3) 配置管理員一定要在配置狀態發佈中跟蹤被Check out出來的配置項。