SUP.9 Problem Resolution Management 問題解決管理

ASPICE 標準解讀: 支持流程

Published in

ASPICE標準解讀

4 min readMay 12, 2020

目錄: Automotive SPICE(ASPICE)標準解讀 / 支持流程SUP.1: 品質保證
SUP.2: 驗證
SUP.4: 聯合審查 
SUP.8: 建構管理 
SUP.9: 問題解決管理
SUP.10: 變更管理

流程目的(Process Purpose)

The purpose of the Problem Resolution Management Process is to ensure that problems are identified, analyzed, managed and controlled to resolution.

問題解決管理流程的目的是確保問題被識別、分析、管理和控制，直到問題被解決。

流程結果(Process Outcome)

成功實作問題解決管理流程，其相應的結果如下：
[Outcome 1]制定一份問題解決管理策略；
[Outcome 2]問題被記錄，並採用唯一標示和分類；
[Outcome 3]分析和評估問題以找到合適的解決方案；
[Outcome 4]啟動問題解決；
[Outcome 5]問題被追蹤至結案；
[Outcome 6]問題的狀態及趨勢是被知曉的

基礎實踐(Base Practices)

SUP.9.BP1: Develop a problem resolution management strategy.
SUP.9.BP1: 制定一個問題解決管理策略
[Outcome 1]

Develop a problem resolution management strategy, including problem resolution activities, a status model for the problems, alert notifications, responsibilities for performing these activities and an urgent resolution strategy. Interfaces to affected parties are defined and definitions are maintained.

制定一個問題解決管理策略，包含：問題解決活動、問題狀態模型、警報通知、執行相關活動的權責、緊急解決策略。與受影響單位的介面被定義且維持。

額外說明：BP1標準原文中，講述了許多內容，筆者以下一一的說明：1) 問題解決活動：
一般來說，問題解決分成識別、記錄、分析/評估、決定解決方案、執行解決方案等。這一套解決問題的活動可以依不同的問題類別細部定義。2) 問題狀態模型：
這邊提到的模型，基本的概念是問題在被解決過程中的狀態；這邊的狀態模型可以根據問題解決活動來依序定義。常見的狀態包含：開放(open)、處理中(in progress)、已解決(Resolved)、結案(Closed)、重新開放(Reopen)。3) 警報通知
當問題被發現時，或當問題因分析得到其嚴重程度等級後的通知。(請參見BP6)4) 執行相關活動的權責
針對問題解決活動的每個環節，定義需要負責的角色與相關權責。5) 緊急解決策略
定義什麼樣的問題算是緊急的問題，一般來說會從問題的嚴重性、優先性等做一個綜合判斷，來決定問題的緊急程度。
ex: 緊急的問題，不一定等於嚴重的問題；例如:寄給廠商的信件中，名字打錯。6) 受影響單位介面的定義與維持
當問題被識別和記錄後，這個問題的處理與異動都將要讓受影響的單位了解狀態，因此需要建立一份溝通的方法，讓受影響單位能夠追蹤問題的處理狀態。

NOTE 1: Problem resolution activities can be different during the product life cycle, e.g. during prototype construction and series development.
備註1: 在產品生命週期中，問題解決活動可能會有所不同。例如：雛型建造和系列開發。

—

SUP.9.BP2: Identify and record the problem.
SUP.9.BP2: 識別並記錄問題
[Outcome 2]

Each problem is uniquely identified, described and recorded. Supporting information should be provided to reproduce and diagnose the problem.

每個問題都是被單獨的識別、描述和記錄。協助資訊(所描述與記錄的相關資訊)可被用來重現和診斷問題。

NOTE 2: Supporting information typically includes the origin of the problem, how it can be reproduced, environmental information, by whom it has been detected, etc.
NOTE 3: Unique identification supports traceability to changes made.
備註2: 協助資訊(所描述與記錄的相關資訊)通常包含問題的起源、如何重現問題、環境資訊、被誰發現等。
備註3: 唯一識別支援追溯性與所做的變更

額外說明：常見的問題識別方法，會從問題的種類、問題發現的單位/流程來定義。1) 問題的種類
在產品開發過程中，常見的問題種類包含：
- 議題(Issue)
- 缺陷(Defect)
- 缺失(NC)
- 漏洞(Bug)
- 失效(Failure)
- 抱怨(Complain)2) 問題發現的單位/流程
- 客戶聯絡窗口
- 會議
- 測試流程(SWE4, SWE5, SWE6, SYS4, SYS5, SPL2)
- 品保流程(SUP1)
- 建構管理流程(SUP8)
- 審查流程(SUP2, SUP4)不同的問題種類，搭配不同的發現單位，通常需要不同的問題處理人員與審查人員，常見的問題處理人員定義如下：1) 問題發現人
發現或檢測到問題的人，通常也是將問題登錄到問題管理系統的人。2) 問題協調人
問題被登錄之初，一般還不清楚主要負責人，因此會有一個問題協調者的角色，負責幫忙分派問題給主要負責人。3) 問題負責人
通常是主要分析、評估及解決問題的人。4) 問題當責人
通常是問題負責人的當責對象，負責最後確認問題是否被解決，並且將問題結案。5) 問題觀察人
所有被此問題影響的所有相關單位。常見在問題管理系統中，會有一個觀察者(Watcher)的欄位，該欄位可以加入所有需要追蹤此問題的專案成員或管理層人員。

—

SUP.9.BP3: Record the status of problems.
SUP.9.BP3: 記錄問題的狀態
[Outcome 6]

A status according to the status model is assigned to each problem to facilitate tracking.

根據問題狀態模型，針對每個不同的問題指派一個狀態，以便於追蹤問題。

—

SUP.9.BP4: Diagnose the cause and determine the impact of the problem.
SUP.9.BP4: 診斷原因並確立問題的影響
[Outcome 2,3]

Investigate the problem and determine its cause and impact in order to categorize the problem and to determine appropriate actions.

調查問題並確定其根因和影響，以便於對問題進行分類並決定適當的措施。

NOTE 4: Problem categorization (e.g. A, B, C, light, medium, severe) may be based on severity, impact, criticality, urgency, relevance for the change process, etc.

備註4: 問題分類(例如: A, B, C, 輕微, 中等, 嚴重) 可以基於嚴重性(Severity)、影響(Impact)、迫切性(Criticality)、緊急程度(Urgency)、與變更流程的相關性。

—

SUP.9.BP5: Authorize urgent resolution action.
SUP.9.BP5: 授權緊急解決措施
[Outcome 4]

If according to the strategy a problem requires an urgent resolution, authorization shall be obtained for immediate action also according to the strategy.

根據策略，如果一個問題需要被緊急解決時，也應根據策略獲得立即採取行動的授權。

—

SUP.9.BP6: Raise alert notifications.
SUP.9.BP6: 發起警報通知.
[Outcome 4]

If according to the strategy the problem has a high impact on other systems or other affected parties, an alert notification needs to be raised also according to the strategy.

根據策略，如果一個問題對其他系統或其他受影響單位有高度的影響時，也需要根據該策略發出警報通知。

額外說明 - 通知的層級ex: 一般測試所發現的問題，可以由測試單位通知設計研發單位。(採用一般通知)
ex: 如果所發現的問題嚴重程度很高，則可以往上通知到專案經理。(採用警報通知)
ex: 如果發現緊急問題，且必須要進行緊急處理，除了可通知專案經理外，亦可再往公司管理層級通報。(採用嚴重警報通知)

—

SUP.9.BP7: Initiate problem resolution.
SUP.9.BP7: 啟動問題解決.
[Outcome 4]

Initiate appropriate actions according to the strategy to resolve the problem including review of those actions, or initiate a change request.

根據策略採取適當的行動來解決問題，包含對這些行動進行審查、或發起變更請求。

額外說明 - 發起變更請求的時機問題處理與變更處理，通常是兩個不同級別的概念。當一個問題必須透過變更才能來處理時，通常表示該問題影響的範圍相當的廣。舉個例子來說：
SWE4在進行單元測試時，測試人員發現一個程式單元的錯誤，該錯誤被登錄在問題管理系統中，後續由研發單位的工程師分析、評估問題，發現這是程式碼中的一部分內容撰寫錯誤，因此工程師後續制定解決問題的行動方案，並根據行動方案解決了問題；當問題被解決後，通知SWE4單元測試人員透過回歸測試策略實施重測。在上述的例子，單純的透過「解決問題」就可以達成問題解決的目的，雖然在過程中，程式碼被修改，但仍在問題解決管理的範疇內。另外一個例子：
SWE4在進行單元測試時，測試人員發現一個程式單元的錯誤，該錯誤被登錄在問題管理系統中，後續由研發單位的工程師分析、評估問題，發現這個問題源自於軟體細部設計(SWE.3 DD)的瑕疵，因此工程師制定的問題解決方案是透過發起變更請求(SUP.10)來解決問題，透過變更請求實現以下步驟：
1) 變更軟體細部設計
2) 重新實施單元建構
3) 重新實施單元驗證(透過回歸測試策略)
4) 變更結案
待變更結束，即表示該問題結束。

NOTE 5: Appropriate actions may include the initiating of a change request. See SUP.10 for managing of change requests.
NOTE 6: The implementation of process improvements (to prevent problems) is done in the process improvement process (PIM.3).The implementation of generic project management improvements (e.g. lessons learned) are part of the project management process (MAN.3). The implementation of generic work product related improvements are part of the quality assurance process(SUP.1).
備註5: 適當的行動可包含初始化變更請求。關於變更請求的管理，請參照SUP.10。
備註6: 在流程改善流程(PIM.3)中，完成流程改善(避免問題)的實施；一般實現專案管理改善(例如:經驗教訓)是專案管理流程(MAN.3)的一部分；一般實現工作產出相關的改善是品質保證流程(SUP.1)的一部分。

額外說明 - 針對「備註6」問題被發現後，一般來說會有幾種可能性。1) 跟專案有關的問題(即專案管理改善)
常見的問題包含時程延宕，這個時候會透過專案管理流程(MAN.3)，由PM來進行問題處理。2) 跟工作產出有關(即備註6中所描述的工作產出相關的改善)
通常工作產出的問題，都是在審查或稽核的時候被發現的，品質保證流程的其中一項目的是確保工作產出的品質，因此透過品質保證流程(SUP.1)，由QA工程師發起NC給專案團隊，並督促專案團隊解決問題。3) 跟流程有關 (即流程改善)
專案進行中，有時候會發現問題來自於所訂定的流程有誤，常見的問題包含方法有誤、方法太難、方法不適用於此專案等；這類型的問題，將透過流程改善流程(PIM.3)來做後續標準流程的改善。

—

SUP.9.BP8: Track problems to closure.
SUP.9.BP8: 追蹤問題至結案.
[Outcome 5,6]

Track the status of problems to closure including all related change requests. A formal acceptance has to be authorized before closing the problem.

追蹤問題狀態直至結案，包含所有相關的變更請求。在問題結案前，必須要有一個正式結案確認授權。

額外說明:簡單來說，問題結案前，必須要有問題當責人確認問題處理的所有環節，確認沒有任何問題且問題已經被解決後，方能正式結案。

—

SUP.9.BP9: Analyze problem trends.
SUP.9.BP9: 分析問題趨勢.
[Outcome 6]

Collect and analyze problem resolution management data, identify trends, and initiate project related actions, according to the strategy.

根據策略，收集及分析問題解決管理的相關資料，識別趨勢，並啟動專案相關的行動。

NOTE 7: Collected data typically contains information about where the problems occurred, how and when they were found, what were their impacts, etc.

備註7: 需要收集的資料通常包含：問題發生的位置(流程或部門)、問題發生的原因、問題的影響，等。

額外說明:問題趨勢的分析，一般進行的頻率大約是一個月一次，常見的報告是將本月所發生的各種問題做統計與彙整。大致上彙整的資料包含：
1) 各種問題種類 vs 各月份累積總數
2) 單一問題種類 vs 各月份 新增/修正個數
3) 各種問題種類 vs 各月份各流程總數
4) 單一種問題嚴重程度 vs 各月份 新增/修正個數如下左圖所示，圖為各種問題 vs 各月份累積總數，圖中可以看見
1) 稽核缺失(橘色)與審查缺陷(綠色)是逐月下降的，其中已稽核缺失下降的最為明顯。
2) 專案議題(藍色)與測試漏洞(灰色)是逐月上升的，兩者的成長趨勢都非常的明顯。在進一步查看專案議題(如下右圖)，該圖為單一問題(專案議題) vs 各月份新增/修正個數的統計表，從圖中可以發現：
1) 新出現的議題雖然每個月仍然持續發生，但是有逐步趨緩的狀況。
2) 議題解決的能力，每個月持穩，但是這仍然無法應付過多的專案議題。總結與進一步行動：
1) 專案議題的解決能力 遠小於 專案議題的新增個數，因此建議增派資源。
2) 針對專案議題，仍需要再進一步查看目前新增的專案議題是屬於哪一種嚴重程度，以利判斷是否該加派資源。(需要上述第四種表格，再進一步查看)
※特殊備註※
問題趨勢分析，通常需要結論與進一步的行動；因此問題趨勢分析，可能再進一步產出新的專案問題。