軟件變更控制規(guī)范

版本更改類型生效日期更改內(nèi)容XX有限公司版本文件編號生效日期A0XXXX目的：本文件描述軟件變更控制管理的規(guī)范，向參與變更控制管理活動的人員提供信息和指導(dǎo)，以確保變更經(jīng)過授權(quán)、保證變更后的軟件配置項的質(zhì)量和一致性與完整性、保證變更過程的可跟蹤性和可回溯性，防止配置項被隨意修改而導(dǎo)致混亂。范圍：本規(guī)范適用于公司所有研發(fā)類項目（定制開發(fā)類項目除外）的變更管理。定義：3.1變更請求：一個用于描述來自涉眾人員的對工件或過程進行變更的所有請求的通用術(shù)語。變更請求中所記錄的是關(guān)于起源的信息以及當(dāng)前問題的影響、建議的解決方案。變更請求的來源分為四大類：需求變更、設(shè)計變更、代碼變更、計劃變更。3.2需求變更：指系統(tǒng)出現(xiàn)新特征或系統(tǒng)原特征發(fā)生改變。設(shè)計變更：指對原設(shè)計標(biāo)準(zhǔn)狀態(tài)的改變和修改。設(shè)計變更僅包含由于設(shè)計工作本身的漏項、錯誤或其它原因而修改、補充原設(shè)計的技術(shù)資料。3.3代碼變更：代碼變更是由需求變更、設(shè)計變更或系統(tǒng)存在的缺陷被發(fā)現(xiàn)引起，如果由需求變更、設(shè)計變更引起，需要在《變更管理單》的任務(wù)分配欄填寫代碼變更任務(wù)；如果由缺陷引起，參見《TD管理辦法》。3.4計劃變更：指因項目資源發(fā)生改變而引起的計劃改變。3.5變更請求管理：一種用來對所請求的變更對現(xiàn)有產(chǎn)品在成本和調(diào)度上的影響進行評估時所需的組織基礎(chǔ)結(jié)構(gòu)進行描述的過程。變更請求管理闡述了變更審查組或變更控制委員會的工作方式。3.6變更嚴重級別：指對變更嚴重程度的度量。變更級別分為重大和一般，重大必須走常規(guī)變更流程，一般可視情況走裁剪流程，參見裁剪。重大：需求因素：因為需求的增加或刪除導(dǎo)致產(chǎn)品版本或補丁項目的需求點列表發(fā)生變動，屬于重大變更。設(shè)計因素：因為在開發(fā)中發(fā)現(xiàn)技術(shù)方面的問題，不得不修改前期的設(shè)計、接口等文檔，而且項目計劃也要做較大調(diào)整，屬于重大變更。管理因素：因為項目組資源情況導(dǎo)致項目計劃需要進行調(diào)整，如果對需求點列表發(fā)生變動，對本項目組對外交付的時間點發(fā)生變動，屬于重大變更。一般：規(guī)范因素：對需求、設(shè)計等文檔的排版格式、描述做輕微的修改，對配置項本身的定義不造成影響，屬于一般變更比如增加背景信息、修改語句錯別字。管理因素：因為項目組資源情況導(dǎo)致項目計劃需要進行調(diào)整，僅對本項目組內(nèi)部人員、任務(wù)安排，或僅對本項目組內(nèi)開發(fā)、測試時間點發(fā)生變動，屬于一般變更。其它因素：先走一般變更，在變更的判斷過程中決定是否上升到一級。3.7縮略語縮略語描述SCMSoftwareConfigurationManagement軟件配置管理CCBChangeControlBoard變更控制委員會PMProjectManager項目經(jīng)理PQAProductQualityAssurance產(chǎn)品級質(zhì)量保證人員SQAQualityAssurance項目級質(zhì)量保證人員CMConfigurationManagementEngineer配置管理人員TLTeamLeader小組組長控制機制本過程的改進由SEPG負責(zé)。SEPG負責(zé)匯集本過程的改進需求，并完成改進任務(wù)。質(zhì)量管理部門負責(zé)審核本過程的執(zhí)行情況。過程描述變更控制是當(dāng)需要更改已基線化的配置項時所進行的管理和控制活動，即對一個正式的變更請求進行評估、分析并通過嚴格的流程對變更活動進行控制和記錄的過程。對基線的變更活動必須從提交一個正式的變更請求開始，變更控制過程是通過對變更請求的處理與狀態(tài)控制來實現(xiàn)的。所有的變更請求都有一個從提交、分析、決策、實施、驗證直至關(guān)閉的過程，這一過程構(gòu)成了變更請求的生命周期。5.1角色與職責(zé)XX有限公司版本文件編號生效日期A0XXXX5.1.1請求提交角色提交角色是變更請求的發(fā)起人，項目或產(chǎn)品中的任何角色都可以通過提交一個變更請求而成為提交角色。填寫完整《變更管理單》中的請求部分并提交5.1.2CCB組長接收處理需求類變更和影響產(chǎn)品交付時間的計劃類變更（接收和處理產(chǎn)品級基線的變更）確認變更請求的有效性；指派變更請求的分析角色；接收完成分析后的〈變更管理單〉根據(jù)分析結(jié)果決策是否接受該變更，對接受變更的每項任務(wù)分配變更實施角色；組織與之相關(guān)的評審和驗證活動；對變更結(jié)果進行驗證，審批基線申請。5.1.3配置管理角色5.1.3.1測試部配置管理員測試部配置管理員承擔(dān)公司級配置管理職責(zé)；控制產(chǎn)品接口類基線及系統(tǒng)測試類基線；具體參見《版本/PATCH配置管理操作指導(dǎo)書》3.1.3.1角色與職責(zé)對與之相關(guān)的評審和驗證活動進行跟蹤并做報告；對通過變更驗證的源代碼更新基線，關(guān)閉該部分的變更。5.1.3.2產(chǎn)品配置管理員控制需求類基線；具體參見《版本/PATCH配置管理操作指導(dǎo)書》3.1.3.1角色與職責(zé)將變更任務(wù)通知變更實施角色；對與之相關(guān)的評審和驗證活動進行跟蹤并做報告；對通過變更驗證的需求和計劃重新基線，并發(fā)布報告；對總的變更管理單進行關(guān)閉操作。5.1.4分析角色對變更請求進行分析，分析的要素參見〈變更管理單〉模板；填寫變更請求中以下信息：變更影響，變更范圍，變更文檔，變更的工作量信息5.1.5變更實施角色負責(zé)更新待變更的配置項；根據(jù)CCB指派的變更任務(wù)，對配置項實施變更；將變更后的配置項提交驗證，并根據(jù)驗證返回結(jié)果重新修改配置項，直到驗證通過；將驗證通過后的配置項提交新的基線申請。5.1.6變更驗證角色對變更后的配置項進行驗證，保證驗證變更結(jié)果的正確性及變更結(jié)果與分析評估結(jié)果的一致性。5.1.7質(zhì)量保證角色PQA對變更過程進行引導(dǎo)；對產(chǎn)品級的變更結(jié)果進行審計。確保需求變更活動符合既定的規(guī)程。不同的配置項變更，審批、決策變更的CCB角色和處理基線的配置管理角色會有所不同，具體操作參見《版本/PATCH配置管理操作指導(dǎo)書》3.1.3.基線控制3.1.3.1角色與職責(zé)。5.2入口條件已經(jīng)基線的配置項出現(xiàn)變更需求5.3輸入《變更管理單》5.4活動XX有限公司版本文件編號生效日期A0XXXX變更控制管理過程請求提出角色變更分析角色CCB角色變更實施角色變更驗證角色配置管理角色輸入文檔輸出文檔創(chuàng)建變更請

求提交請求.信息不指定分析人指定變更分

析角色初始變更單變更分析提交決策結(jié)束分析后變更段階策+拒絕—變更決策變更任務(wù)通知變更單歸檔分析后變更決策后變更CheckOut配置項—*實施變更提交驗證待更新的配置項、變更后的配

創(chuàng)建變更請

求提交請求.信息不指定分析人指定變更分

析角色初始變更單變更分析提交決策結(jié)束分析后變更段階策+拒絕—變更決策變更任務(wù)通知變更單歸檔分析后變更決策后變更CheckOut配置項—*實施變更提交驗證待更新的配置項、變更后的配

置項臉證不通過驗證活動項提交請求?審批基線n驗證通創(chuàng)建基線申請—審批通過Check】n配置”基線變更文檔結(jié)束階評審單/缺陷.記錄單一、、根據(jù)驗證結(jié)

果更新的配

置項基線申請表一___^/~-配置狀態(tài)發(fā)

布表（流程圖）5.4.1提交階段提交階段是變更請求的發(fā)起人發(fā)現(xiàn)問題并在變更控制系統(tǒng)中提交變更請求的階段。變更請求的記錄一旦被提交，即將進入分析階段。提交階段記錄的信息包括變更請求的標(biāo)題、提交人、提交時間、問題的詳細描述以及問題的嚴重性。5.4.1.1提交請求需要對曾經(jīng)進行過基線的配置項進行變更時，由請求提交角色填寫《變更管理單》中的請求部分，描述清楚變更類型、嚴重級及優(yōu)先級等基本信息，然后提交給CCB組長。CCB組長根據(jù)變更嚴重級別（參見2.1定義））進行判斷采用常規(guī)流程還是裁減后的流程（參見6裁減）。5.4.1.2指派分析CCB組長根據(jù)《變更管理單》中的申請指派分析角色。5.4.2分析階段5.4.2.1分析請求分析角色對變更請求進行分析，填寫《變更管理單》中的分析部分。5.4.2.2提交決策完成請求分析后，由分析角色將《變更管理單》提交給CCB組長。5.4.3決策階段決策階段將根據(jù)分析結(jié)果衡量變更將造成的影響，然后確定將對變更請求采取的處理方法。CCB對變更請求有兩種處理方法：XX有限公司版本文件編號生效日期A0XXXX同意：同意對當(dāng)前基線中的配置項進行變更，允許進入變更實施階段拒絕：不實施變更，關(guān)閉該變更請求5.4.3.1CCB決策根據(jù)變更的嚴重級別，由CCB組長選擇決策方式：會議方式：對于嚴重級別為重大的變更，由CCB組長組織召開CCB會議，討論決策。直接裁決：對于嚴重級別為一般的變更，可以由CCB組長直接裁決。決策后填寫《變更管理單》中的決策部分，由配置管理員將信息知會到相關(guān)人員。5.4.3.2指派實施如果CCB決策同意該變更請求，CCB需要對同意變更的配置項指派變更實施角色，填寫《變更管理單》任務(wù)分配表部分，將該《變更管理單》發(fā)送給配置管理角色歸檔，由配置管理員將任務(wù)通知到變更實施角色。5.4.4實施階段實施階段將由變更實施角色實施所有的變更活動。5.4.4.1實施變更變更實施角色收到變更任務(wù)通知后，Checkout已經(jīng)基線的配置項，對配置項實施變更操作。5.4.4.2提交驗證如果變更的配置項是文檔，變更實施角色完成變更操作后，將變更后的配置項提交給CCB組長組織評審。如果變更的配置項是源代碼，變更實施角色完成變更操作后，直接將變更后的配置項提交給變更驗證角色。5.4.5驗證階段5.4.5.1進行驗證如果變更的配置項是文檔，采用評審作為驗證手段；由CCB組長組織評審活動。評審遵循《評審規(guī)范》。當(dāng)最終評審結(jié)果為通過，即可提交基線申請進入關(guān)閉階段；當(dāng)最終評審結(jié)果為不通過，變更實施角色需要重新對配置項實施變更操作，重新提交評審，直至驗證結(jié)果為通過。備注：當(dāng)變更的嚴重級別為一般，變更的內(nèi)容較少、影響較小時，可以通過CCB組長或相關(guān)責(zé)任人郵件確認替代評審。評審需知會配置管理員角色，以便對變更的進度進行報告。如果變更的配置項是源代碼，采用測試作為驗證手段；由測試人員擔(dān)當(dāng)變更驗證角色，進行測試活動。測試遵循《測試過程》。當(dāng)最終測試結(jié)果為通過，即可提交基線申請進入關(guān)閉階段；當(dāng)最終測試結(jié)果為不通過，變更實施角色需要重新對配置項實施變更操作，重新提交測試，直至測試結(jié)果為通過。5.4.6關(guān)閉階段5.4.6.1申請基線驗證結(jié)束并通過后，變更實施者checkin通過驗證的配置項，填寫《基線申請/發(fā)布電子流》中的基線申請內(nèi)容，提交給CCB。5.4.6.2審批基線CCB根據(jù)驗證結(jié)果審批是否同意該基線申請。由CCB組長在《基線申請/發(fā)布電子流》中填寫審批意見后將《基線申請/發(fā)布電子流》交給配置管理角色。如果審批意見為通過，配置管理角色就可以對變更后的配置項進行基線操作；如果審批意見為不通過，該配置項重新提交驗證。5.4.6.3基線操作配置管理角色對申請基線操作的配置項進行基線操作，填寫《基線申請/發(fā)布電子流》中的發(fā)布信息內(nèi)容，并郵件知會所有相關(guān)人員。5.5輸出《變更管理單》《基線申請/發(fā)布電子流》重新基線的配置項5.6出口條件《變更管理單》內(nèi)所有的變更任務(wù)已經(jīng)完成，重新基線并發(fā)布。度量度量項名稱|分析階段處理時長|決策階段處理時長|驗證階段處理時長

XX有限公司版本文件編號生效日期A0XXXX公式（分析階段實際結(jié)束時間-提交階段實際結(jié)束時間）（決策階段實際結(jié)束時間-分析階段實際結(jié)束時間）（驗證階段實際結(jié)束時間-決策階段實際結(jié)束時間）目的收集平均處理時長作為參考標(biāo)準(zhǔn)收集平均處理時長作為參考標(biāo)準(zhǔn)收集平均處理時長作為參考標(biāo)準(zhǔn)收集頻率每月每月每月何時收集月底月底月底&相關(guān)工具/表格/記錄《變更管理單》《基線申請/發(fā)布電子流》9.附錄：引用《TD管理辦法》《版本/PATCH配置管理操作指導(dǎo)書》《評審規(guī)范》7.裁剪上述常規(guī)流程中