配置管理過程

2021-06-17 16:22:50 字數 3541 閱讀 2493

該過程用於規範專案配置管理工作,保證專案生成的工作產品在整個生命週期中的完整、一致性。

本過程適用於專案級和公司級的配置管理工作。 無

角色

職責

cm工程師

l         編制專案的《配置管理計畫》

l         定期備份配置庫

l         基線建立

l         配置項變更控制

專案經理

l         協助cm工程師確定配置項、基線建立時間以及ccb成員

l         審批《配置管理計畫》

l         執行配置審計及審計發現問題跟蹤

變更發起人

l         填寫變更申請

ccb(change control board, 變更控制委員會)

l         評估需求變更影響及配置項變更範圍

變更實施人

l         實施配置項變更

l         專案啟動

l         專案總體計畫

專案立項後,cm工程師根據《專案配置管理目錄》中的庫結構在配置庫中為專案組分配區域,建立配置管理目錄。

《專案總體計畫》及《專案進度安排》初稿完成後,cm工程師根據《pdp》及專案特徵等資訊制定《配置管理計畫》,與專案經理溝通確定配置項、基線以及ccb成員。

在專案開發過程中,專案組成員根據規定使用配置庫,並及時提交工作產品。cm工程師根據計畫建立基線,並由專案經理審計確認。

cm工程師負責管理變更流程,確保配置項的變更受控。

cm工程師根據規定或計畫定期對配置庫進行備份,並妥善保管備份檔案。

專案結項時,cm工程師根據《專案結項報告》,將確定需要提交組織財富庫的文件放入正確位置。

1

2

3

4

專案立項後,cm工程師根據《專案配置管理目錄》中的庫結構在配置庫中為專案組分配區域,建立配置管理目錄。

配置庫總體劃分為開發庫及受控庫:

受控庫:用於存放各基線包含的配置項文件。

配置庫建立後,cm工程師初步為開發團隊分配許可權,並將配置庫資訊告知專案組。

cm工程師負責編寫《配置管理計畫》,計畫內容包括以下資訊:

ccb成員cm工程師與專案經理溝通確定ccb成員,一般包括:專案經理、cm工程師、專案關鍵技術人員以及產品負責人(如果有)

配置項及非配置項(資料項)cm工程師與專案經理溝通確定需要納入基線的配置項

訪問許可權配置庫各目錄的訪問許可權

基線及建立時間cm工程師與專案經理溝通確定需要建立的基線、包含內容以及建立觸發時間

備份方法可以根據組織習慣或專案特殊情況確定備份方法

紙質文件管理方法確定紙質文件在開發過程以及結項之後的儲存方法

計畫編寫完成後,cm工程師提交專案經理審核,並通過計畫評審(見《專案管理過程》)。計畫評審後,cm工程師根據計畫對配置庫設定進行調整。

專案組成員建立文件記錄時,根據以下方式對文件進行命名:

專案名_文件名稱

專案名:專案立項時的專案名稱或專案編號

文件名稱:文件原始模板名稱

例如al83專案的總體計畫檔名為「al83_專案總體計畫」。

對於可能修改多次的技術文件(如需求規格說明書、概要設計等)及管理文件(專案計畫),需要在文件中使用修訂履歷對其版本變更情況進行記錄。

其版本的編號規則如下:

v0.1              建立

v0.x              評審前的修改

v1.0              通過評審

v1.x              評審後的修改

v2.0              文件內容變更較大,需要再次正式評審

對於源**及設計開發文件,要求編寫負責人每天在下班前check in 配置庫。

基線是專案儲存庫中配置項在特定時期的乙個「快照」,它由一組確定的配置項組成。基線中的文件應該是已經通過驗證(測試或評審)的,或者下階段工作需要以其為基礎的工作產品。

cm工程師根據《配置管理計畫》中確定的基線建立觸發時間建立基線。

基線建立步驟如下:

cm工程師填寫《基線記錄表》

cm工程師將該基線包含的配置項從開發庫提取到受控庫的相應位置

專案經理及cm工程師對已建立基線進行配置審計,檢查配置項的正確性。(詳見4.6配置審計)

該小節僅描述配置管理變更控制程式。

配置管理變更控制是指對納入基線的配置項變更進行評估、跟蹤及控制的一系列活動,可能由需求變更、設計變更或計畫變更引起。關於需求變更流程,請參見《需求開發及管理流程》。

配置管理變更遵循以下流程:

變更申請

變更評估

評估內容可從涉及變更的配置項、變更工作量、成本、可能的風險以及影響範圍等方面考慮,在評估基礎上進行變更審批後,評估、審批結果填入《變更記錄表》。

變更跟蹤

變更實施結果需經cm工程師驗證,若驗證不通過則由cm工程師通知變更實施人及相關人員,並跟蹤直至驗證通過,驗證結果由配置管理填入《變更記錄表》。

如變更後需建立基線,參見4.4建立基線。

配置審計包括配置庫審計及基線審計,審計依據《配置管理計畫》中的配置審計時間安排及《配置審計表》進行。

配置審計型別包括以下三類:

配置管理審計

該審計驗證配置管理記錄以及配置項完整性、一致性及正確性。

物理審計

該審計驗證配置項與構建產品與技術文件的一致性。

功能審計

該審計驗證配置項與待測試產品的功能特徵與需求的一致性,以及操作及支援文件的完整性和正確性。

配置審計執行要求如下:

配置庫審計

cm工程師負責根據《配置管理計畫》中確定的審計週期對開發庫及受控庫進行審計,建議採用的審計方法為:配置管理審計及物理審計。審計結果填入《配置審計表》中,對發現的問題應及時處理關閉。

基線審計

專案經理及cm工程師負責在每次基線建立後(里程碑評審前)依據《配置審計表》進行配置審計,審計結果填入《基線記錄表》中,對發現的問題應及時處理關閉。

基線審計建議採用的方法為:物理審計及功能審計。

配置庫必須週期性備份到專案備份庫中,具體備份時間在專案《配置管理計畫》中確定,每次備份更新備份記錄表,cm工程師定期對備份檔案進行恢復測試。

專案結項時,專案經理挑選可供組織未來參考的文件,並記錄於《專案結項總結》中。cm工程師根據批准的檔案提交清單將相應的文件提交到組織財富庫的相應目錄,並通知epg。

《配置管理計畫》

《變更記錄表》

《基線記錄表》

《配置審計報表》

專案結項

專案文件提交組織級配置庫 無

《配置管理計畫》

《變更記錄表》

《基線記錄表》

《配置審計報表》

專案管理過程

過程是一組為了完成一系列預先指定的產品 服務 勞動成果而執行的相互關聯的行動或活動。專案管理過程由專案團隊實施,一般屬於兩大類 a 大多數情況下,專案都有共同的專案管理過程,它們通過啟動 規劃 執行 監控和結束專案的實施而相互聯絡。b 由面向產品的過程或製作專案的產品規定。面向產品的過程一般都由專案...

版本管理過程

controller層 upload responsebody public string upload model model,requestparam file multipartfile file trycatch exception e 班級學習資訊統計 selectcoursebysidc...

資料 配置管理

目前國內外常見的10種配置管理工具一覽 配置管理不是單純的指軟體的 版本管理,上面的資料介紹的主要是 級管理.配置管理的目的是為了準確交付,減少事故.當專案本身是由多個語言,多個部門來開發,採用了較多開源和第三方的軟體例項時,需要好的配置管理.配置管理之路 scmroad 軟體測試網 軟體測試管理 ...