SUP.10 Change Request Management 變更請求管理
ASPICE 標準解讀: 支持流程
目錄: Automotive SPICE(ASPICE)標準解讀 / 支持流程SUP.1: 品質保證
SUP.2: 驗證
SUP.4: 聯合審查
SUP.8: 建構管理
SUP.9: 問題解決管理
SUP.10: 變更管理
流程目的(Process Purpose)
The purpose of the Change Request Management Process is to ensure that change requests are managed, tracked and implemented.
變更請求管理流程的目的是為確保變更請求被管理、追蹤和實作。
額外說明 -- 變更管理與建構管理CMMI標準中，變更與建構是放在一起討論的，因此如果讀者曾經接觸或導入過CMMI標準，應該會發現這兩者之間的關係。在ASPICE標準中，特別將變更獨立拉出成為一個流程，因此在建置符合ASPICE標準的變更流程時，也請讀者要一併考量到變更與建構之間的關係。舉例來說：當變更請求涉及到已經被基準的文件時，變更執行人應持變更請求的核准證明向建構管理員申請文件的簽出，並於驗證和變更完畢後，再行向建構管理員申請文件的簽入。再上述的案例中，讀者應可以察覺到變更請求與建構管理流程之間的互動關係。
流程結果(Process Outcome)
成功實作建構管理流程，其相應的結果如下：
[Outcome 1]制定一個變更請求管理策略；[Outcome 2]識別與紀錄變更請求；[Outcome 3]識別與其他變更請求的相依性與關係；[Outcome 4]定義確認變更請求實作的條件；[Outcome 5]分析變更請求，並預估其所需資源；[Outcome 6]根據分析結果與可用資源，核准並排序變更[Outcome 7]實作並追蹤被核准的變更直至其結案[Outcome 8]所有變更請求的狀態是已知的[Outcome 9]建立變更請求與被影響的工作產出間的雙向追溯
基礎實踐(Base Practices)
SUP.10.BP1: Develop a change request management strategy.
SUP.10.BP1: 制定一個變更請求管理策略[Outcome 1]
Develop a change request management strategy, including change request activities, a status model for the change requests, analysis criteria, and responsibilities for performing these activities. Interfaces to affected parties are defined and maintained.
制定一個變更請求管理策略，包含變更請求活動、變更請求狀態模型、分析準則(標準)、執行變更請求活動的人員與責任。定義和維護(變更)影響方的介面。
NOTE 1: A status model for change requests may contain: open, under investigation, approved for implementation, allocated, implemented, fixed, closed, etc.
NOTE 2: Typical analysis criteria are: resource requirements, scheduling issues, risks, benefits, etc.
NOTE 3: Change request activities ensure that change requests are systematically identified, described, recorded, analyzed, implemented, and managed.
NOTE 4: The change request management strategy may cover different proceedings across the product life cycle, e.g. during prototype construction and series development.備註1: 變更請求的狀態模型可包含：開放、調查中、已核准實作、已分派、已實作、已修正、已關閉、等。
備註2: 典型的分析準則(標準)有：資源需求、計劃問題、風險、收益等。
備註3: 變更請求活動是為了確保變更請求可以被系統地識別、描述、記錄、分析、實施和管理。
備註4: 變更請求管理策略可涵蓋整個產品生命週期中的不同程序，例如在原型製作和系列(產品)開發。
額外說明 -- 變更請求狀態模型(參考)下圖為變更請求的參考狀態模型，從這張圖的基本概念，共可以分成兩塊：
1. 指派與分析階段 -- 淺藍色背景
2. 規劃與實作階段 -- 淺橘色背景這張圖，的基本概念流程是：
1. 當變更請求發生時，登陸到變更請求管理系統中(狀態：OPEN)
2. 變更請求建立完畢，並指派給負責人(狀態:Assigned)
3. 負責人進行變更請求分析，分析完成(狀態:Analyzed)
4. CCB成員審查變更請求，當變更請求被接受(狀態:Accepted)
5. 負責人開始規劃變更實作計畫(狀態:Planning)
6. 變更計畫完成並被核准(狀態:Approved)
7. 相關成員開始實作變更(狀態:In progress)
8. 相關成員已完成變更實作(狀態:Implemented)
9. 負責人驗證變更實作成果，驗證完成(狀態:Verified)
10.CCB成員確認變更結果(包含驗證結果)(狀態:Close)從現有的變更狀態圖中，亦存在特殊狀況，請參考圖中的(A)(B)(C)(D)：
(A)當變更請求狀態被調整為「推遲(Deferred)」，這表示這個變更請求在此專案當前的V-model(也有可能是一段時間)中不被接受，因此當下一個V(或推遲時間到達時)，這一個變更請求將可以重新被啟動，此時變更請求將重新進入「Open」狀態，再次根據當前的專案狀態重新評估。(B)一般在變更請求分析完畢後，會送交CCB進行變更請求的決策；一般來說，決策分為三種常見的可能，分別是(1)接受變更(狀態:Accepted)、(2)當變更影響範圍超過專案可接受的範圍(情況包含：變更內容過多、造成專案時間嚴重延誤、沒有好處的變更、風險過大、等)，那麼變更請求就會被拒絕(狀態:Rejected)；(3)當變更請求經評估後，沒有立即變更的必要性，則此變更將被推遲到之後的時間點再行重新評估(狀態:Deferred)。(C)變更實作完成後，將會進入驗證，當驗證沒有通過，有可能會需要重新實作(狀態:In progress)，抑或是重新制定變更實作計畫(狀態:Planning)。(D)變更實作驗證通過後，最終將送交CCB做最後確認，如果經確認仍然不被接受，則可能會需要重新實作(狀態:In progress)，抑或是重新制定變更實作計畫(狀態:Planning)。
額外說明 -- 變更請求狀態模型的角色與責任根據上圖，不同的變更請求狀態，其相關的角色，大致分為：
1. 變更發起人
2. 變更分析人(負責分析變更請求)
3. 變更控制委員會(負責評估變更請求)
4. 變更負責人
5. 變更執行人(可能多人)
6. 變更驗證人不同的變更請求狀態，對應的角色也不同，請參考：
1.(狀態:Open)=>變更發起人: 負責登錄變更請求的相關資料
2.(狀態:Assigned)=>變更分析人: 負責分析變更請求
3.(狀態:Analyzed)=>變更控制委員會: 負責評估是否要接受變更請求
4.(狀態:Accepted)(狀態:Planning)=>變更負責人: 接手並開始著手規劃變更行動計畫
5.(狀態:Approved)=>變更負責人: 請求專案主管協助審查變更行動計畫
6.(狀態:In progress)=>變更執行人: 執行變更行動計畫
7.(狀態:Implemented)=>變更驗證人: 負責變更行動結果的驗證
8.(狀態:Verified)=>變更控制委員會: 負責確認變更行動與驗證的最終成果；變更負責人: 負責通知變更受影響的單位
—
SUP.10.BP2: Identify and record the change requests.
SUP.10.BP2: 識別與紀錄變更請求[Outcome 2,3]
Each change request is uniquely identified, described, and recorded according to the strategy, including the initiator and reason of the change request.
每一個變更請求均根據策略進行唯一識別、描述和紀錄。需被識別、描述和紀錄的資訊包含：變更發起者和變更請求的原因。
額外說明 -- 變更發起的來源常見的變更請求來源，可以能有以下幾種：
1) 從問題而來的變更
2) 專案團隊的共同決議(一般來說，會先記錄成問題，再進入變更)
3) 從客戶端來的變更
4) 從供應商來的變更實作變更請求管理時，應該要針對變更請求的來源進行識別，並且定義不同變更處理角色，包含：變更發起人、變更分析人、變更控制委員會成員等。
—
SUP.10.BP3: Record the status of change requests.
SUP.10.BP3: 紀錄變更請求的狀態[Outcome 8]
A status according to the status model is assigned to each change request to facilitate tracking.
根據所定義的狀態模型，針對每個變更請求的設定狀態，以方便於追蹤。
額外說明 -- 容易被忽略的變更請求狀態實際專案中，當變更開始被執行時，變更請求的狀態將顯示為「實作中(Implementing」；但是因為變更的實作可能耗費的時間較長，因此只透過狀態來追蹤變更請求的實際狀況往往是不夠的，在這樣的情況下，搭配「截止日期」或是專案時程來協助管理，都可以讓變更請求可以被更有效的管理。
—
SUP.10.BP4: Analyze and assess change requests.
SUP.10.BP4: 分析且評估變更請求[Outcome 3,4,5,9]
Change requests are analyzed according to the strategy including their dependencies to affected work products and other change requests. Assess the impact of the change requests and establish criteria for confirming implementation.
根據BP1所制定的策略分析變更請求，包含其對受影響的工作產出的關聯性，以及其他變更請求。評估變更請求的影響，並建立變更實作後的允收標準。
—
SUP.10.BP5: Approve change requests before implementation.
SUP.10.BP5: 在實作前核准變更請求[Outcome 6]
Change requests are prioritized based on analysis results and availability of resources before implementation and approved according to the strategy.
在實作變更前，應根據分析結果和資源可用性，排定變更請求的優先順序。
額外說明(1) -- 變更請求的優先順序變更的分析是為了決定變更的優先順序(或稱變更的程度)，根據不同的優先順序，亦可用來決定變更控制委員會的成員組成。一般來說，變更的優先順序可以分為以下兩種：1) 一級變更(重大)
常見的一級變更可能如下：
a) 影響到專案的目標、里程碑
b) 投入資源(人力、時程、工作量)超出可接受水平
c) 客戶來源的需求變更
d) 設計架構變更
e) 採用技術與方法變更
f) 供應商變更
g) 重大風險2) 二級變更(一般)
一般來說非一級變更，都可以是二級變更。常見的二級變更通常是單一份文件的變更(即使是基準文件)額外說明(2) -- 變更分析與變更程度的判定在標準中，特別提到變更分析的方向，具體為(1)受影響的工作產出、(2)其它變更；因此讀者也可以針對受影響的工作產出數量與其它變更的交互影響來判定變更的程度，這邊存在一些可以量化的可能性。舉例：
1) 受影響的工作產出 = 版本文件(3) + 基準文件(1) => 二級變更
2) 受影響的工作產出 = 版本文件(5) + 基準文件(3) => 一級變更額外說明(3) -- 透過安排變更執行計劃來協助變更請求的評估在筆者於企業端顧問輔導過程中，亦有企業透過制定變更執行計畫來評估是否要接受變更請求，只是這個做法相對來說會較耗費時間。如果讀者亦想要透過制定變更計畫來協助評估變更請求，筆者會建議綜合以下幾個量化數據來協助評估變更請求：
1) 受影響工作產出數量
2) 其它正在執行的變更請求數量
3) 其它專案或產品
4) 變更可能涉及的流程
5) 變更可能涉及的人力資源與工作量
6) 變更是否需要暫停現有流程，需要暫停多久
NOTE 5: A Change Control Board (CCB) is a common mechanism used to approve change requests.
NOTE 6: Prioritization of change requests may be done by allocation to releases.備註5: 變更控制委員會是核准變更請求的常見機制
備註6: 變更請求的優先順序可透過發配到不同的發布來完成
額外說明 -- 變更於下一輪V-model中實作有一些變更請求，經分析與評估後，判定非立即需要執行，因此這樣的變更請求的優先順序也可以透過指派到下一輪開發流程中再行實作。(備註: 讀者可參考"變更請求參考狀態模型"中的Deferred狀態)
—
SUP.10.BP6: Review the implementation of change requests.
SUP.10.BP6: 審查變更請求的實作成果[Outcome 7,8]
The implementation of change requests is reviewed before closure to ensure that their criteria for confirming implementation are satisfied, and that all relevant processes have been applied.
變更請求在實作結束前應進行審查，以確保(1)變更實作滿足BP4所制定的允收標準，(2)所有相關流程均已被採用。
額外說明 -- 變更執行的允收確認一般檢查變更實作是否確實，除了要檢查實作時的相關產出，亦要針對實作的過程進行確認；標準這邊所提到的流程，即是變更實作過程所採用的流程。
—
SUP.10.BP7: Track change requests to closure.
SUP.10.BP7: 追蹤變更請求直到其結案[Outcome 7,8]
Change requests are tracked until closure. Feedback to the initiator is provided.
追蹤變更請求直到其結案並提供反饋給變更發起者。
額外說明 -- 給變更發起者的反饋除了要回饋給變更發起者之外，亦可根據專案需求通知對變更請求有影響的相關方。
—
SUP.10.BP8: Establish bidirectional traceability.
SUP.10.BP8: 建立雙向追溯[Outcome 9]
Establish bidirectional traceability between change requests and work products affected by the change requests. In case that the change request is initiated by a problem, establish bidirectional traceability between change requests and the corresponding problem reports.
建立變更請求與被變更請求影響的工作產出之間的雙向追溯。如果變更請求是由問題所引發的，則建立變更請求與對應問題報告之間的雙向追溯。
額外說明 -- 變更請求與被影響工作產出的雙向追溯在標準條文中，所提到的追溯性是雙向性的。參考範例如下：變更管理透過文件來實作：
- 變更申請單 >> 工作產出
- 工作產出(制修訂履歷) >> 變更申請單變更管理透過工具來實作：
- 變更工具的單筆變更資料 >> 工作產出
- 工作產出(制修訂履歷) >> 變更工具的單筆變更資料額外說明 -- 由問題所引發的變更在這種狀況下，需要在問題管理過程中，標註該問題正處於變更中，並針對問題的截止時間進行追蹤與管理，以避免因無止盡的變更執行，導致問題無法被有效關閉。(備註:有一些流程的結束條件是所有跟該流程有關的問題均被解決，在這種情況下，則要特別注意問題與變更之間的關係)
NOTE 7: Bidirectional traceability supports consistency, completeness and impact analysis.
備註7: 雙向追溯性支援覆蓋性、一致性和影響分析。
工作產出(Output Work product)
08–28 變更管理計畫[Outcome 1]08-04 變更請求 [Outcome 2,3,4,5,6,7]08–14 審查紀錄 [Outcome 7]13–08 變更控制紀錄 [Outcome 8,9]
感謝閱讀本文章！
如果你對文章內容有任何問題，請隨時與我聯絡。
if you found any question in the article, please feel free to contact me.
email: linchewing@gmail.com
