(更新2024/03/06) ASPICE v3.1版，共有32個關鍵流程；新增訂版的ASPICE for Cybersecurity 又額外增加了6個流程；ASPICE 4.0版，亦加入了新的關鍵流程。這麼多的流程，該如何選定導入與驗證範圍呢？本篇文章，筆者將簡介ASPICE v3.1版的導入範圍。
關於 ASPICE v4.0 的導入範圍 2023年12月，由VDA QMC正式推出的ASPICE v4.0版，針對ASPICE的流程有了非常大幅度的調整，其導入範圍，請參考：ASPICE v4.0 的導入範圍一文。
ASPICE v3.1現有流程
為了促使汽車電子和軟件供應商關注產品開發過程，提升過程品質。ASPICE v3.1版本共定義了32個關鍵流程，分為3大類、8個流程組。
從標準的流程圖中，3大類流程，分別是：
- (橘色) 主要生命週期(Primary Life Cycle Processes)
- (藍色) 組織生命週期(Organizational Life Cycle Processes)
- (綠色) 支援生命週期(Supporting Life Cycle Processes)
根據流程所側重的活動型別不同，每個分類又被細分成8個子分類，每個子分類再定義各自的流程：
- 採購(ACQ: Acquisition) 主要生命週期
- 供應(SPL: Supply) 主要生命週期
- 系統工程(SYS: System Engineering) 主要生命週期
- 軟體工程(SWE: Software Engineering) 主要生命週期
- 管理(MAN: Management) 組織生命週期
- 改進(PIM: Process Improvement) 組織生命週期
- 重用(REU: Reuse) 組織生命週期
- 支持(SUP: Supporting) 支持生命週期
ASPICE範圍誰來決定？
在標準文件中，ASPICE並沒有說明評估的範圍，總數32個流程如果全部要導入，將會非常的曠日廢時。誰來決定ASPICE的範圍？
答案是：與客戶共同商定的
在亞洲，常被要求的範圍大致上，可以分為三個，分別是：
- VDA Scope
- VDA Extended Scope
- VDA Extended Scope (plus additional processes)
額外說明: HIS Scope與VDA Scope 「HIS」是由Audi AG, BMW, DaimlerChrysler, Porsche, Volkswagen等車廠成立的組織，負責制定軟體開發的相關規則。 2016年，HIS組織解散了。接續，VDA QMC (Automotive SPICE PAM v2.5及後續標準版本的負責單位)在2017年Automotive SPICE PAM v3.0發佈時，將之前在業界廣為人知的HIS Scope，改名為VDA Scope。
VDA Scope
為最基本，也是最常見的範圍，為上圖中「紅色」框所圈選的範圍 — 共計16個。
- ACQ.4: 供應商監控 採購 主要生命週期
- SUP.1: 品質管理 支持 支持生命週期
- SUP.8: 建構管理(或稱 組態管理, 或稱 配置管理) 支持 支持生命週期
- SUP.9: 問題管理 支持 支持生命週期
- SUP.10: 變更管理 支持 支持生命週期
- MAN.3: 專案管理 管理 組織生命週期
- SYS.2: 系統需求分析 系統工程 主要生命週期
- SYS.3: 系統架構設計 系統工程 主要生命週期
- SYS.4: 系統整合及整合測試 系統工程 主要生命週期
- SYS.5: 系統合格測試 系統工程 主要生命週期
- SWE.1: 軟體需求分析 軟體工程 主要生命週期
- SWE.2: 軟體架構設計 軟體工程 主要生命週期
- SWE.3: 軟體細部設計及單元開發 軟體工程 主要生命週期
- SWE.4: 軟體單元驗證 軟體工程 主要生命週期
- SWE.5: 軟體整合及整合測試 軟體工程 主要生命週期
- SWE.6: 軟體合格測試 軟體工程 主要生命週期
VDA Extended Scope
是VDA Scope的延伸範圍，這個範圍通常是由16個VDA Scope提到的流程，外加4個或5個流程。(通常SUP.2和SUP.4可以被歸類為同一個)
- SYS.1: 需求獲取 系統工程 主要生命週期
- MAN.5: 風險管理 管理 組織生命週期
- SUP.2: 驗證 支持 支持生命週期
- SUP.4: 聯合審查 支持 支持生命週期
- SPL.2: 產品發佈 供應 主要生命週期
VDA Extended Scope (plus additional processes)
上述的VDA Scope(16個流程)，和VDA Extended Scope(21個流程)為汽車供應鏈中最常被要求的兩個範圍，除此之外，不同國家的車廠亦會額外要求一些流程，這些被額外追加的流程通常包含但不限於下列：
- REU.2: 重複使用 管理 組織生命週期
- SUP.7: 文件化 支持 支持生命週期
- PIM.3: 流程改善 改進 組織生命週期
額外說明: REU.2為何被要求？
通常在車用產業的組件(或部件)開發，並不是從無到有的。許多都是架構在之前的專案或產品之上，因此，「重複使用」先前專案的成果在現有的專案中，是很常見的。
為此，REU.2也是隱性被客戶要求的需求。如果現行交付的產品有很大一部分是建構在「重用」的基礎上，客戶也有很大的可能會要求提出「重用」的合理性判斷。
備註：通常過去的專案與產品，並非依照ASPICE標準開發的，因此，筆者建議如果遇到客戶針對重用的部分進行確認，可以盡可能提出越多的證據以證明之前專案的合規性。(e.g. 量產證明、測試案例與報告、客戶證明、等)
額外說明: SUP.7 可以怎麼被實現？ 一般組織如果有導入IATF 16949或ISO 9001，那麼在這些標準中，都有要求文件管制。這部分的管制辦法可以高度用於實現SUP.7。
額外說明: PIM.3何時會需要導入？ 如果公司的目標是追求ASPICE Level 3，那麼建議以PIM.3流程為基礎，建立一個企業流程改善程序，並組建一個流程改善小組(EPG小組)。 對於EPG小組而言，建立並維護一套企業的標準作業流程是其份內的工作，而這也是合乎ASPICE Level 3的流程屬性。
2023年後的範圍趨勢
VDA QMC在2023年12月，發布的ASPICE 4.0，該文件將ASPICE 3.1的許多流程刪除，亦增加了許多新的範圍，包含：
- 硬體工程流程 (Hardware Engineering)
- 機器學習工程流程 (Machine Learning Engineering)
- 確效流程 (Validation)
新版的ASPICE標準中，將會留有更多的活動與已經發布的ISO 26262:2018 及 ISO/SAE 21434進行整合，預計2023年後的專案流程範圍除了既有的ASPICE流程之外，亦會提出整合功能安全與網宇安全等標準。更多關於ASPICE v4.0的介紹，請參考ASPICE v4.0目錄
您好
很高興能讀到您的文章，敝人是IS26262&ASPICE安全經理，已經有3~4年。
希望能一直在車用領域發展。不過，近期有個問題困擾，就是顆粒度粗細的決定，問幾個相關領域的顧問，一樣是一知半解…
您好，
這邊的顆粒度指的什麼樣的顆粒度呢？
我初步解讀成2種不同顆粒度，看看是否能夠回答到您的問題。
1. 專案執行的細緻程度
ASPICE專案執行，其要求是非常細緻的，在評鑑過程也是如此。大部分企業被要求通過ASPICE標準評鑑，通常都是「客戶需求」，也就是說，客戶會把注意力關注在”客戶”自己的案子上，因此，ASPICE專案執行的細緻度幾乎等於於供應商評鑑，會看的相對仔細。
不同客戶及不同評鑑老師的關注點也會有所不同，這要根據被要求的ASPICE等級而定；如果被要求Level 1，通常會被放大檢視的流程，會落在工程流程及支持流程(客戶在意產品的開發過程及細節)，如果被要求Level 2，會被放大檢視的是流程之間的互動性(例如: 專案管理 對應 工程流程、支持流程對應工程流程、等)，如果被要求Level 3，則會放大檢視公司組織層級對於不同專案的管理對策。
—
2. 證據產出的顆粒度
在ASPICE Guideline中，有明確要求產出物的顆粒度，這裡的顆粒度被要求到”追溯”及”證據呈現”上，此外，產出物指的是：
1) 單一利益相關者需求
2) 單一系統需求
3) 單一系統架構元件
4) 單一軟體需求
5) 單一軟體架構元件
6) 單一軟體細部設計元件
7) 單一軟體單元
8) 單一驗證標準
9) 單一測試案例
10) 單一測試結果
11) 單一變更請求
12) 單一問題紀錄
例子1: 如果一條系統需求包含的內容太多(常見將所有訊號整理在一張表中)，那麼這條需求的顆粒度，就太粗了！
例子2: 一條系統需求可以寫出超過1條以上的驗證標準，而且一條驗證標準又能寫出超過1條以上的測試案例。
例子3: 一堆的系統需求直接被分配到一整個系統架構元件中，在這種情況下，系統架構元件的內容顆粒度就太粗了。
額外備註：
車廠&OEM提供的需求文件中，幾乎是針對每一段需求給一個編號，關於顆粒度的概念，可以參考相關文件喔！(例如: VW 的 kgas )
如果要更加了解產出物的顆粒度，建議您提供貴司的個案，進行專案實務討論。鑒於我過去幾年的ASPICE評鑑及顧問經驗，這一塊有許多彈性的作法，如果有疑問，我會試著寫成文章來解答。