變更請求
出自 MBA智库百科(https://wiki.mbalib.com/)
變更請求(Request for Change,RFC)
目錄 |
什麼是變更請求[1]
變更請求是指一個用於描述來自涉眾的對工件或過程進行變更的所有請求的通用術語。變更請求中所記錄的是關於起源的信息，以及當前問題的影響、建議的解決方案及其費用。
變更請求是關於修改任何文件、可交付成果或基準的正式提議。如果在開展項目工作時發現問題，就可提出變更請求，對項目政策或程式、項目或產品範圍、項目成本或預算、項目進度計劃、項目或產品結果的質量進行修改。其他變更請求包括必要的預防措施或糾正措施，用來防止以後的不利後果。任何項目相關方都可以提出變更請求，應該通過實施整體變更控制過程對變更請求進行審查和處理。變更請求源自項目內部或外部，是可選或由法律 (合同)強制的。變更請求可能包括:[2]
- 糾正措施。為使項目工作績效重新與項目管理計劃一致，而進行的有目的的活動。
- 預防措施。為確保項目工作的未來績效符合項目管理計劃，而進行的有目的的活動。
- 缺陷補救。為了修正不一致產品或產品組件的有目的的活動。
- 更新。對正式受控的項目文件或計劃等進行的變更，以反映修改或增加的意見或內容。
變更請求的分類[1]
變更請求管理過程經常同公司的內部組織密切相關，在這一領域沒有標準術語。但是，變更請求經常被分為兩個大類：增強請求(Enhancements)和缺陷(Defects)。(用於管理變更的變更請求類型在公司和公司之間差異較大，甚至同一公司內的項目之間也會不一致。這裡描述的類型，即缺陷和增強請求僅是最基本類型的變更請求。)
增強請求是指系統的新增特征或對系統“預定設計”行為的變更。缺陷是指“存在於一個已交付產品中的異常現象或缺陷。這樣的例子包括在生命周期的早期階段發現的疏忽和有缺陷的地方，以及在一個足以成熟的用於測試或操作的軟體中包含的錯誤的癥狀。缺陷可以是任何您想跟蹤並解決的問題”。儘管用於維護增強請求和缺陷的許多數據都十分相似，但這兩類變更請求在變更請求管理過程上通常用截然不同的方式來處理。
變更請求的目的[3]
變更的必要性是演進中的軟體或現有軟體系統所固有的。變更控制經理負責確定變更請求管理的過程，維護變更請求（CR），並確保以可控制的方式變更系統，以便預測變更對系統的影響。變更請求可以用於記錄和追蹤所有類型的系統變更請求，包括擴展請求和缺陷。
系統分析員可以利用擴展請求確定將來要在產品中包含的特性。為了理解涉眾需要，在收集涉眾請求時，擴展請求將用作輸入。
缺陷就是已交付工作產品中的異常情況或瑕疵。缺陷包含諸如在生命周期早期階段發現的遺漏和缺點，和/或是用於測試或操作的成熟軟體中包含的故障癥狀（瑕疵）。缺陷還包括與預期目的的偏差或任何要加以跟蹤併進行解決的問題。
缺陷的目的在於反映問題的細節，以便可以採取糾正措施、解決方法，並跟蹤發生的情況。下列人員使用變更請求：
系統分析員，使用確定為擴展請求的變更請求，來確定產品的新特性，
項目經理，使用變更請求分配工作，
測試員，使用變更請求確定和說明在測試過程中發現的缺陷，
實施員，使用變更請求分析缺陷，查找變更請求的故障或起因，
測試設計員，使用變更請求計劃核實已解決的變更請求的測試，分析收集的缺陷來評測軟體和流程的質量。
變更請求的提要[3]
在進行與任何已提交的變更請求有關的決策時，以下屬性非常實用：
大小
必須要變更的現有工作量是多少？
需要添加的多少新工作量？
是否有備選方案？
複雜程度
提議的變更是否容易實現？
變更可能導致哪些連鎖反應？
嚴重性
不實施這個請求的會導致哪些影響？
是否涉及到工作或數據丟失？
是否為擴展請求？
是否為次要的錯誤？
進度
何時需要進行變更？
是否可行？
影響
進行變更的後果如何？
不進行變更的後果如何？
進行變更的成本或節約的資金是多少？
與其他變更的關係
其他變更是否可以取代此變更或使其無效嗎，或者此變更是否依賴於其他變更？
測試
是否存在任何特殊的測試需求？
示例變更請求表
1.標識信息
項目：
變更請求號：
變更請求類型：（問題或擴展）
標題：
提交日期：
始發人:
變更請求優先順序：
2.當前問題
當前問題的說明：
嚴重故障：
障礙：
擴展：
新請求：
觀察問題的環境：
當前環境：硬體
操作系統
當前問題的來源：
當前問題的成本影響：
3.提議的變更（始發人）
提議的變更的說明：
實施提議變更的預計成本：
4.提議的變更（變更覆審團隊）
操作：
批准：
不批准：
延期：
提議的變更的說明：
影響的配置項：
類別：
錯誤修複：
擴展：
新特性：
其他：
5.解決方案
實施提議變更的預計成本：
實施員：
實施變更的實際時間：
分析：
實施：
測試：
文檔：
影響的代碼行數：
6.評估
測試方法：
檢查
分析
演示
測試：
測試平臺：
測試實例：
7.變更覆審團隊的處理
批准的變更和接受的變更：
變更請求的時機[3]
通常在項目生命周期的初期使 CM 操作制度化或建立 CM 操作。因此，變更請求（CR）作為構成變更流程整體的一部分，可以隨時在項目過程中提出。
缺陷的主要來源是運行測試的結果（集成、系統和性能測試）。然而，缺陷可以隨時出現在軟體開發生命周期過程中，缺陷還可包括缺失的或不完整的用例、測試用例或文檔的確認。
變更請求的職責[3]
有關項目的任何人員都應該可以提出變更請求。 然而，變更請求要得到提出變更請求角色上司的覆審和批准才能成為合法請求。變更請求的最後仲裁由覆審團隊或變更控制委員會（CCB）執行。
變更控制經理負責缺陷的完整性，以確保：
缺陷是唯一的，或不是再次出現的已確定缺陷。
變更請求的定製[3]
準確確定、說明和追蹤缺陷需要的實際欄位/數據取決於實施的標準、指南和變更控制系統。
變更請求的管理[4]
變更請求管理是使軟體開發成本降低的最大因素之一，隨著對軟體開發的要求越來越高，變更量也越來越多，開發人員必須迅速解決變更問題。變更請求管理就需要建立合理的變更流程。實施變更請求管理流程的基本步驟如下：
(1)確定變更請求管理流程執行的範圍，然後制定響應的變更流程。
(2)制定變更管理流程的模型。
(3)決定團隊各個角色在流程實施中所起的作用。
(4)確定實施計劃及開始實施日程。
(5)部署變更請求管理系統。
(6)不斷強化變更管理流程。
為了保證整個項目開發的成功，變更請求管理應明確如下問題：
·哪些需求發生了變化?應可提供具有各種重要特征的變更請求信息，且對各種變更請求在處理完畢之前的內容能及時調整，並保證各種請求的信息絕對不能丟失。
·這些需求變化後，對測試工作會產生哪些影響?包括會不會影響測試用例?會不會影響到測試方案?會不會影響到測試計劃?應通過對缺陷及其他各種變更的登記、保管、跟蹤、解析，達到團隊之間的各種變化信息的共有、安全而可靠地高質量變更信息管理系統。
·需求變化後對工作進度產生多大的影響?有效地跟蹤各種變更，對管理人員提出各種變更狀況的查詢請求，做到快而準地提供信息。
·不同變更請求之間的連接關係。對項目整體發展狀況，提供巨集觀及定量的分析，從而能合理分配項目開發人員的工作、合理制訂項目的計劃、合理管理項目各種請求實施的優先順序。
·統計各種項目指標數據，項目管理人員就可以進行更加科學、量化的管理、規劃、調配、監控，保證項目如期的進行。
