項目管理師考點：配置管理變更的關(guān)鍵路徑

1、項目管理師考點：配置管理變更的關(guān)鍵路徑導(dǎo)語：CMMI全稱是 CapabilityMaturityModelIntegration，即軟件能力成熟度模型集成 ( 也有稱為：軟件能力成熟度集成模型 ) ，是美國國防部的一個設(shè)想。隨著 CMMI熱潮興起，有些軟件企業(yè)誤認(rèn)為，只要通過 CMMI就萬事俱備，高枕無憂了。事實并非如此。與其說 CMMI是一種標(biāo)準(zhǔn)，不如說是一種管理方法和管理思想。企業(yè)通過 CMMI評估并不是企業(yè)持續(xù)改進的工作就此結(jié)束，這僅僅是企業(yè)發(fā)展道路上的一個里程碑。評估不是最終目的， 它只是檢驗企業(yè)自身研發(fā)能力成熟度的一種手段。企業(yè)要生存、發(fā)展，就必須不斷地自我完善，自我超越，就必須在配

2、置管理、項目計劃、質(zhì)量保證等方面持續(xù)努力。配置管理硬件系統(tǒng)。例如 PC行業(yè)中，每一臺 PC由主機和顯示器等構(gòu)成，而主機又由 CPU、主板等構(gòu)成，對這些構(gòu)件配置情況進行管理，就是硬件的配置管理。在軟件行業(yè)，計算機軟件由編譯后的代碼和相關(guān)的一系列文檔組成。 但構(gòu)成軟件的部件的變化是跟隨軟件產(chǎn)品的開發(fā)周期而不斷變化的。 就頻率和程度來說， 軟件的變化遠(yuǎn)遠(yuǎn)大于硬件。因此，軟件配置管理是一套管理軟件開發(fā)和軟件維護的方法和規(guī)則，其最終體現(xiàn)的是維護軟件產(chǎn)品的一致性和完整性。變更常有所在銀行科技部已經(jīng)建立了比較完善的項目管理體系和質(zhì)量保障體系，但要應(yīng)對分行或支行需求變更和相關(guān)軟件版本配置管理的問題，如果沒有一

3、整套的解決措施和工具的支持，就會出現(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)理 (

4、或項目經(jīng)理 ) 、開發(fā)團隊領(lǐng)導(dǎo)、開發(fā)人員、高層領(lǐng)導(dǎo)等項目干系人的工作協(xié)同起來，實現(xiàn)高效的溝通，及時地共享工作成果。配置管理的基本功能包括配置標(biāo)識、變更控制、配置狀態(tài)發(fā)布和配置審計。變更控制是配置管理的重要內(nèi)容， 其目的是為了在動態(tài)中保證配置項的完整性、 一致性和可回溯性， 保證配置項的變更過程規(guī)范、受控、有完整記錄，受影響的各方均能及時了解情況，并協(xié)調(diào)一致?？刂撇豢缮僮兏刂剖峭ㄟ^創(chuàng)建產(chǎn)品基線，在產(chǎn)品的整個生存周期中控制它的發(fā)布和變更。 配置控制指在配置項標(biāo)識正式確定之后， 對配置項特別是對已提交的代碼、 相關(guān)文檔和數(shù)據(jù)等的變更進行系統(tǒng)地跟蹤和控制的過程，主要包括變更的提出、確定配置項的控制等

5、級、變更的評價、變更的處置、實施經(jīng)批準(zhǔn)的變更、對變更進行驗證和結(jié)束變更。變更控制的目的是建立一套控制軟件修改的機制，保證生產(chǎn)符合質(zhì)量標(biāo)準(zhǔn)的軟件和保證每個版本的軟件包含所有必需的元素及工作在同一版本中的各元素中可以正常工作，以確定在變更控制過程中控制什么，如何控制，誰控制變更、何時接收變更、批準(zhǔn)和檢驗。配置項級別1) 已基線化的配置項是指已完成該配置項的審核和批準(zhǔn)，并且成為創(chuàng)建或修改其他配置項的輸入。例如：一個設(shè)計文檔已審核、通過、簽發(fā)，并且成為編碼活動的基礎(chǔ)。2) 受管理和受控的配置項是指已提交審核，但還沒有批準(zhǔn)通過的配置項。例如：一個正在進行審核的設(shè)計文檔。3) 受控的配置項指已置于版本控制

6、，但項目組不能直接進行改動的配置項。例如：用戶提供的軟件、購買的工具、產(chǎn)品標(biāo)準(zhǔ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)

7、閉：驗證并歸檔配置項，更新的配置項提交給用戶 ( 例如：通過版本發(fā)布 ) 。變更請求的類型1) 增強型：變更請求要求對已批準(zhǔn)的項目功能進行增強。2) 改進型：變更請求不會造成功能更改，但使配置項的維護更加有效率。3) 糾錯型：變更請求對錯誤進行修正 ( 諸如 bug) 。變更請求的優(yōu)先級在評價變更請求的優(yōu)先級時，要對請求變更的配置項進行系統(tǒng)的分析，確定變更影響范圍和修改的程度，確定變更的級別，為確定是否有必要記錄變更提供參考依據(jù)。變更請求的優(yōu)先級可分為三類：1) 高：嚴(yán)重地影響一些用戶或許多用戶。2) 中：對用戶造成不方便，或是可以采取相應(yīng)的變通方法處理的主要問題。3) 低：小問題。修改完后簽入 (Checkin)對變更的處理，要按照變更控制規(guī)程，將變更請求及其相關(guān)附件提交軟件配置控制委員會審批。 配置管理組根據(jù)審批意見處理變更請求。只有配置管理員具有Checkin 權(quán)限。在進行 Checkin 之前，確認(rèn)下面的事項：1) 所有對配置項所做的修改被批準(zhǔn) ;2) 所有的更改都經(jīng)過審核或驗證 ;3) 所對應(yīng)的變更請求已經(jīng)被保存起來 ;4) 所有相關(guān)的審核記錄被保存 ;5)Checkin時須注明 Checkin 因，如對應(yīng)的變更請求。從數(shù)據(jù)庫中簽出 (Checkout)1) 對于文檔，