- 相關(guān)推薦
項目管理師考點：配置管理變更的關(guān)鍵路徑
導(dǎo)語：CMMI全稱是CapabilityMaturityModelIntegration，即軟件能力成熟度模型集成(也有稱為：軟件能力成熟度集成模型)，是美國國防部的一個設(shè)想。
隨著CMMI熱潮興起，有些軟件企業(yè)誤認為，只要通過CMMI就萬事俱備，高枕無憂了。事實并非如此。與其說CMMI是一種標準，不如說是一種管理方法和管理思想。企業(yè)通過CMMI評估并不是企業(yè)持續(xù)改進的工作就此結(jié)束，這僅僅是企業(yè)發(fā)展道路上的一個里程碑。評估不是最終目的，它只是檢驗企業(yè)自身研發(fā)能力成熟度的一種手段。企業(yè)要生存、發(fā)展，就必須不斷地自我完善，自我超越，就必須在配置管理、項目計劃、質(zhì)量保證等方面持續(xù)努力。
配置管理來源于硬件系統(tǒng)。例如PC行業(yè)中，每一臺PC由主機和顯示器等構(gòu)成，而主機又由CPU、主板等構(gòu)成，對這些構(gòu)件配置情況進行管理，就是硬件的配置管理。在軟件行業(yè)，計算機軟件由編譯后的代碼和相關(guān)的一系列文檔組成。但構(gòu)成軟件的部件的變化是跟隨軟件產(chǎn)品的開發(fā)周期而不斷變化的。就頻率和程度來說，軟件的變化遠遠大于硬件。因此，軟件配置管理是一套管理軟件開發(fā)和軟件維護的方法和規(guī)則，其最終體現(xiàn)的是維護軟件產(chǎn)品的一致性和完整性。
變更常有
所在銀行科技部已經(jīng)建立了比較完善的項目管理體系和質(zhì)量保障體系，但要應(yīng)對分行或支行需求變更和相關(guān)軟件版本配置管理的問題，如果沒有一整套的解決措施和工具的支持，就會出現(xiàn)以下問題：
1)分行反映的缺陷更改不能快速響應(yīng)，不能快速分配缺陷到指定的開發(fā)人員，只能依靠口頭或文檔的傳輸，缺乏一個整合開發(fā)商服務(wù)人員、產(chǎn)品經(jīng)理(或項目經(jīng)理)、開發(fā)團隊領(lǐng)導(dǎo)、開發(fā)人員、分行領(lǐng)導(dǎo)的信息傳遞和交流的平臺。
2)分行的需求變更不能快速響應(yīng)。分行的需求變更和軟件版本配置只能依靠手工備份，因而，自身不能快速有效地管理各系統(tǒng)的版本，缺乏版本基線的管理策略。
針對以上問題，可以考慮采用軟件配置管理這一關(guān)鍵域的思路系統(tǒng)地解決以上問題。配置管理是整個集成軟件項目正常運作的一個管理支撐平臺，其目的就是將有關(guān)該項目的客戶、客戶服務(wù)人員、產(chǎn)品經(jīng)理(或項目經(jīng)理)、開發(fā)團隊領(lǐng)導(dǎo)、開發(fā)人員、高層領(lǐng)導(dǎo)等項目干系人的工作協(xié)同起來，實現(xiàn)高效的溝通，及時地共享工作成果。
配置管理的基本功能包括配置標識、變更控制、配置狀態(tài)發(fā)布和配置審計。變更控制是配置管理的重要內(nèi)容，其目的是為了在動態(tài)中保證配置項的完整性、一致性和可回溯性，保證配置項的變更過程規(guī)范、受控、有完整記錄，受影響的各方均能及時了解情況，并協(xié)調(diào)一致。
控制不可少
變更控制是通過創(chuàng)建產(chǎn)品基線，在產(chǎn)品的整個生存周期中控制它的發(fā)布和變更。配置控制指在配置項標識正式確定之后，對配置項特別是對已提交的代碼、相關(guān)文檔和數(shù)據(jù)等的變更進行系統(tǒng)地跟蹤和控制的過程，主要包括變更的提出、確定配置項的控制等級、變更的評價、變更的處置、實施經(jīng)批準的變更、對變更進行驗證和結(jié)束變更。變更控制的目的是建立一套控制軟件修改的機制，保證生產(chǎn)符合質(zhì)量標準的軟件和保證每個版本的軟件包含所有必需的元素及工作在同一版本中的各元素中可以正常工作，以確定在變更控制過程中控制什么，如何控制，誰控制變更、何時接收變更、批準和檢驗。
配置項級別
1)已基線化的配置項是指已完成該配置項的審核和批準，并且成為創(chuàng)建或修改其他配置項的輸入。例如：一個設(shè)計文檔已審核、通過、簽發(fā)，并且成為編碼活動的基礎(chǔ)。
2)受管理和受控的配置項是指已提交審核，但還沒有批準通過的配置項。例如：一個正在進行審核的設(shè)計文檔。
3)受控的配置項指已置于版本控制，但項目組不能直接進行改動的配置項。例如：用戶提供的軟件、購買的工具、產(chǎn)品標準等等。
變更請求的狀態(tài)
軟件變更、軟件優(yōu)化和軟件bug都是產(chǎn)生變更的原因。變更申請人(用戶或產(chǎn)品經(jīng)理)提出變更時，首先要對受控的配置項的修改提出一個變更請求，說明對軟件變更的需求。這是因為變更控制過程是通過變更請求的流動來實現(xiàn)的，而且對軟件的任何請求都必須和相應(yīng)的變更請求對應(yīng)。
變更請求的狀態(tài)包括：
1)提交：變更請求提交給配置管理員;
2)拒絕：變更控制委員會拒絕變更請求;
3)接受：變更控制委員會接受變更請求;
4)掛起：變更請求被掛起，以后再作決定;
5)已驗證：更改已執(zhí)行和驗證;
6)關(guān)閉：驗證并歸檔配置項，更新的配置項提交給用戶(例如：通過版本發(fā)布)。
變更請求的類型
1)增強型：變更請求要求對已批準的項目功能進行增強。
2)改進型：變更請求不會造成功能更改，但使配置項的維護更加有效率。
3)糾錯型：變更請求對錯誤進行修正(諸如bug)。
變更請求的優(yōu)先級
在評價變更請求的優(yōu)先級時，要對請求變更的配置項進行系統(tǒng)的分析，確定變更影響范圍和修改的程度，確定變更的級別，為確定是否有必要記錄變更提供參考依據(jù)。變更請求的優(yōu)先級可分為三類：
1)高：嚴重地影響一些用戶或許多用戶。
2)中：對用戶造成不方便，或是可以采取相應(yīng)的變通方法處理的主要問題。
3)低：小問題。
修改完后簽入(Check in)
對變更的處理，要按照變更控制規(guī)程，將變更請求及其相關(guān)附件提交軟件配置控制委員會審批。配置管理組根據(jù)審批意見處理變更請求。
只有配置管理員具有Check in權(quán)限。在進行Check in之前，確認下面的事項：
1)所有對配置項所做的修改被批準;
2)所有的更改都經(jīng)過審核或驗證;
3)所對應(yīng)的變更請求已經(jīng)被保存起來;
4)所有相關(guān)的審核記錄被保存;
5)Check in時須注明Check in因，如對應(yīng)的變更請求。
從數(shù)據(jù)庫中簽出(Check out)
1)對于文檔，配置管理員在更改審批人同意后，從配置庫中Check out配置項，發(fā)給項目組成員修改。
2)Check out時須注明Check out原因，如將要修改的問題。
3) 配置管理員一定要在配置狀態(tài)發(fā)布中跟蹤被Check out出來的配置項。
【項目管理師考點：配置管理變更的關(guān)鍵路徑】相關(guān)文章：
項目管理師知識考點項目采購管理07-14
投資項目管理師《投資項目決策》考點10-11
項目管理師考點：項目計劃書的作用07-07
2017助理項目管理師考點：項目溝通管理07-26
項目管理師考點：項目如何靠融資走出困境10-21
項目管理師考點：范圍管理成功11-08
項目管理師考試考點：項目計劃書的作用09-11