(v3.1)ASPICE標準: SPL.2 產品發佈(Product Release)

本流程為ASPICE標準中的供應流程 — SPL.2 Product Release 產品發佈，本流程被涵蓋在ASPICE VDA延伸範圍(VDA Extended Scope)中；本文章為「ASPICE v3.1標準解讀」系列文章，筆者將針對ASPICE標準條文提供解讀與說明，期許本篇文章能夠為讀者，解決標準導入時的疑惑。

---

流程目的(Process Purpose)

The purpose of the Product Release Process is to control the release of a product to the intended customer.

「產品發佈流程」的目的是控制產品向預定客戶的發佈。

額外說明 -- "Product" 待發佈的產品

本流程所提到的「產品」並不限於系統，也可以是純硬體、純機構或純軟體。

額外說明 -- 預定客戶

本標準提到的預定客戶，除了一般泛指"公司的客戶"外，亦可包括公司其他部門，或其他專案。因此，常見的發佈又可以被細分成：外部發佈(External Release)及內部發佈(Internal Release)。

如下圖所示，其中橘色菱形為常見的內部發佈(包含硬體發佈、軟體發佈、機構發佈等)，其發佈的預定對象是專案中的其他成員；黃色菱形則為常見的外部發佈，其發佈的預定對象是外部的客戶。

---

流程結果(Process Outcome)

成功實作「產品發佈」，其相應的結果如下：
[Outcome 1]確定產品發佈的內容；
[Outcome 2]以建構項目(或稱組態項目)組成發佈物；
[Outcome 3]定義並產出發佈文件;
[Outcome 4]確定發佈交付機制與媒介;
[Outcome 5]根據定義的標準執行發佈批准;
[Outcome 6]產品發佈提供給預定客戶；
[Outcome 7]取得發佈的確認。

---

基礎實踐(Base Practices)

SPL.2.BP1: Define the functional content of releases.
SPL.2.BP1: 定義發佈的功能性內容
[Outcome 1,3]

Establish a plan for releases that identifies the functionality to be included in each release.

制定一個發佈計畫，識別每次發佈所要包含的功能。

NOTE 1: The plan should point out which application parameters influencing the identified functionality are effective for which release.

備註1: 計畫應指出，影響已識別功能的應用參數，是對哪個發佈有效。

額外說明 -- 發佈時機

識別與定義發佈的功能性內容前，建議讀者先根據公司內部的開發及發佈流程，識別發佈時機。以汽車產業常見的開發流程(如：先前產品品質規劃 APQP)。

請參考下圖，常見的發佈時機可包含：

1. 概念驗證(POC)
2. 工程驗證(EVT)
3. 設計驗證(DVT)
4. 量產驗證(PVT)

先明確的定義出這些發佈時機，再識別這些發佈產品的相對應功能。

備註：如果公司有採用APQP的管制模型，在專案管理時也應該將ASPICE的開發流程與APQP流程做一定程度的整合，這將有助於ASPICE標準與公司既有流程整成後的順暢性。

額外說明 -- 應用參數 (application parameters)

產品在不同的發布時機，其功能將有所不同。為了因應不同發布的產品功能，一般來說將會透過調教(或稱設定)產品中的軟體，來達成目的。

軟體的調教，一般是透過「配置參數」和「校準參數」這2種參數來達成。在ASPICE標準中，所提到的應用參數，一般指的是「校準參數」。

請參考下圖，軟體(或稱可設定的軟體)搭配「配置參數」一起編譯，產出「完成設定的軟體」。「完成設定的軟體」，再搭配設定校準參數，最終產出「應用於特定車輛的軟體」。

在產品發佈流程，因應不同發佈的產品功能不同，因此，應用參數的定義應著重於「配置參數」，在發佈計畫書中，應該要說明每一次發佈的配置參數，以利於進行產品構建(Build)作業。

額外說明 -- 名詞解釋


配置參數 (Configuration DATA)：在軟體編譯時，被指派用於控制軟體編譯的資料。例如：前處理器指令、軟體編譯指令(例: XML設定檔) 

校準參數 (Calibration DATA)：在軟體開發過程中，在軟體編譯後將應用的資料。例如：參數(parameters)(例:低怠速值、引擎特性圖)、車輛特定參數(vehicle specific parameters)(例: 節流閥限制器)、變型設碼(variant coding)(例: 國家/地區碼、左駕/右駕)

(額外參考：ISO 26262-6:2018 Annex C)

—

SPL.2.BP2: Define release products.
SPL.2.BP2: 定義發佈產品
[Outcome 1]

The products associated with the release are defined.

定義與發佈(時機)相關聯的產品

NOTE 2: The release products may include programming tools where these are stated. In automotive terms a release may be associated with a sample e.g. A, B, C.

備註2: 發佈產品可包括：程式碼撰寫工具(如有聲明)。在汽車產業術語中，發佈可與「樣品」相關聯(例如: 樣品A、樣品B、樣品C)

—

SPL.2.BP3: Establish a product release classification and numbering scheme.
SPL.2.BP3: 建利產品發佈分類和編號模型
[Outcome 2]

A product release classification and numbering scheme are established based upon the intended purpose and expectations of the release(s).

根據發佈的預期目的和期望，建立產品發布的分類與編號模型。

NOTE 3: A release numbering implementation may include:
the major release number
the feature release number
the defect repair number
the alpha or beta release
the iteration within the alpha or beta release.

備註3: 實作發佈編號模型，可包含：
主要發佈編號
功能發佈編號
缺陷修復編號
alpha或beta發佈
alpha或beta的迭代發佈

額外說明 -- 發佈版本

常見的發佈版本，可以將「主要(Major)」、「次要(Minor」(或稱「功能發佈」)、「修補(Patch)」(或稱「缺陷修復」)、等概念組合成為主要的發佈編號。Alpha、Beta及其相對應迭代版本也可納入考量。

當然，這樣的版本發佈模型也可以與工程開發的V-model整合一起考量。請參考下圖。
(備註：本文所提出的架構僅為一個參考架構，筆者可以搭配既有的建構管理所制定的分支與合併原則，進行發佈的版本定義)

---
假設在本次發佈之前，已經存在一版正式發佈：1.1.0。這一次版本發佈，將加入一個次要功能。

第一次版本發佈：「Alpha版：1.2.0-a.1」：這個版本僅完成程式開發，並未進行單元測試。值得注意的是，這一個版本的「minor」編號，從1→2，並加上了「a.1」表示為Alpha版。

第二次版本發佈(共2次)：「Beta版：1.2.0-b.1、1.2.0-b.2」：這是在進行單元測試後的版本發佈，單元測試期間可能遭遇一些錯誤並完成修正，因此出現了兩個迭代的版本。

第三次版本發佈(共2次)：「RC版：1.2.0-rc.1、1.2.0-rc.2」：這是在進行整合測試後的版本發佈，整合測試期間可能遭遇一些錯誤並完成修正，因此出現了兩個迭代的版本。

第四次版本發佈：「1.2.0」：這個版本已經完成了最後的合格測試，為軟體的最終發佈版。

---
值得一提的是，為何需要這麼多次的發佈版本？如果沒有發佈，是不是簡單透過版本控管即可？

在我所顧問輔導的公司，多數都在開發過程中被客戶提前索要尚未完成的版本，因此，同上述例子，如果在工程流程的開發過程中，可以透過這樣的發佈編號，來管理提供給客戶的不同版本。

如果客戶並沒有在過程中不斷索要(軟體)，那麼當然可以透過版本控管(這將會在SUP.8 建構管理中說明)，就可以完成開發過程中的程式碼管理了。

—

SPL.2.BP4: Define the build activities and build environment.
SPL.2.BP4: 定義構建活動及構建環境
[Outcome 2]

A consistent build process is established and maintained.

建立並維護一致的建構流程。

NOTE 4: A specified and consistent build environment should be used by all parties.

備註4: 所有人(專案內及專案外)都應使用一致的構建環境

額外說明 -- 軟體的構建環境、與軟硬體的構建環境

考量到一般工程開發流程中，存在「軟體發佈」及「系統發佈」。這兩者的構建環境的定義，也會有所不同。

軟體構建環境
軟體的構建環境，一般會考慮到配置參數(例: makefile)、構建流程、構建工具等。

系統(軟硬體)構建環境
系統的構建環境則相對單純，一般需要考慮燒錄工具(將軟體燒入硬體中)、或其他系統元件結合所需要的工具(例: 焊接工具、接線工具、等)

—

SPL.2.BP5: Build the release from configured items.
SPL.2.BP5: 從建構項目(或稱組態項目)構建發佈
[Outcome 2]

The release is built from configured items to ensure integrity.

從建構項目(或稱組態項目)構建發佈，以確保其完整性。

NOTE 5: Where relevant the software release should be programmed onto the correct hardware revision before release.

備註5: (如果相關) 在發佈前， 軟體發佈應燒錄進正確的硬體版本。

額外說明 -- 建構管理與產品發佈

專案開發過程中，所有的產出物都應在建構管理流程(SUP.8)中被管理，這包括軟體及硬體。在產品發布之前，產品必然是從建構項目構建而成。

—

SPL.2.BP6: Communicate the type, service level and duration of support for a release.
SPL.2.BP6: 溝通發佈的類型、服務等級和提供支援的期間
[Outcome 3]

The type, service level and duration of support for a release are identified and communicated.

識別與溝通發佈的類型、服務等級和提供支援的期間

—

SPL.2.BP7: Determine the delivery media type for the release.
SPL.2.BP7: 確定發佈的交付媒介類型
[Outcome 4]

The media type for product delivery is determined in accordance with the needs of the customer.

根據客戶需求，確定產品交付的媒介類型。

NOTE 6: The media type for delivery may be intermediate (placed on an adequate media and delivered to customer), or direct (such as delivered in firmware as part of the package) or a mix of both. The release may be delivered electronically by placement on a server. The release may also need to be duplicated before delivery.

備註6: 交付的媒介類型可以是：間接的(放在適當的媒介並交付給客戶，例如: 貨運)、直接的(例如用交付包的韌體進行交付)、或兩者混合。發佈可上傳至伺服器並透過電子形式的方式進行交付。發佈也需要在交付前進行備份。

—

SPL.2.BP8: Identify the packaging for the release media.
SPL.2.BP8: 識別發佈媒介的包裝
[Outcome 4]

The packaging for different types of media is identified.

識別不同類型媒介的包裝

NOTE 7: The packaging for certain types of media may need physical or electronic protection for instance specific encryption techniques.

備註7: 某些類型媒介的包裝可能需要物理或電子保護，例如特定的加密技術

額外說明 -- 媒介的包裝

針對實體的媒介，一般將採用實體的保護機制(例如: 泡棉、保麗龍、等)。針對非實體的媒介(例如: FTP)，一般會針對待傳輸的檔案進行壓縮，並加密保護，為了避免客戶所收到的檔案與原提供的檔案不同，一般也會進行數位簽章。

關於非實體媒介的保護，在網絡安全日益重視的趨勢下，讀者也要將這一塊納入公司層級的網絡安全管理系統(CSMS)進行管制。

—

SPL.2.BP9: Define and produce the product release documentation / release notes.
SPL.2.BP9: 定義並產出產品發佈文件/發佈通知
[Outcome 3]

Ensure that all documentation to support the release is produced, reviewed, approved and available.

確保支持該發佈的所有文件被產出、審查、批准及提供

額外說明 -- 產品發佈資訊

根據ASPICE v3.1標準的建議，產品發佈的資訊包含：

- 所涵蓋的主要元件
- 簡介新增或修改的功能(包含移除)
- 系統資訊及需求
- 轉換程式和指南
- 發佈編號 (請參考BP3的說明)
- 組件清單(包含其版本): 硬體, 軟體, 產品元件, 函式庫, 等
- 相關文件清單
- 新的/修改的參數資訊(例如:應用參數或全域變數)
- 備份及復原資訊
- 已知問題、故障、警告等資訊清單
- 驗證及診斷程序
- 技術支援資訊
- 版權及所有權資訊
- 產品發佈通知 (請參見BP12的備註)

—

SPL.2.BP10: Ensure product release approval before delivery.
SPL.2.BP10: 確保交付前對產品發佈批准
[Outcome 5]

Criteria for the product release are satisfied before release takes place.

在發佈產品前，已滿足產品發佈的標準

—

SPL.2.BP11: Ensure consistency.
SPL.2.BP11: 確保一致性
[Outcome 5]

Ensure consistency between software release number, paper label and EPROM-Label (if relevant).

確保軟體發佈號碼、紙質標籤和EEPROM標籤(如果相關)之間的一致性。

額外說明 -- 如何確保一制性？

請參考下圖，該圖為產品發佈的整個流程。

第一步驟：制定發佈計畫
專案計畫是產品發佈流程的輸入文件，發佈計畫根據專案的生命週期及客戶期待，識別產品發佈時機及相對應的產品發布需求(包含其涵蓋功能、構建參數、構建環境及其他發佈項目)。發佈計畫也制定產品發佈的編號原則。

第二步驟：構建產品(黃色底色)
當發佈時機成熟時，構建工程師透過向建構管理員申請「已基準的建構項目」，搭配發佈計畫所制定的應用參數，透過構建流程(Build Process)，產出待發佈產品，並撰寫該發佈產品的發佈資訊文件(含發佈通知(Release Note))

第三步驟：確保一致性(並整理成發佈包) (Review -1)
發佈工程師透過測試、目視檢查、等方法確保待發佈產品的一致性，經確認沒有問題後，發佈工程師將待發佈產品(經構建程序產出)、其他預定發佈產品(定義在發佈計畫中)及發佈通知裝箱整理成發佈包(Release Package)，並通知品保工程師執行交付前的稽核。

第四步驟：交付前確保 (Review-2)
收到發佈工程師的通知後，品保工程師將針對發佈包進行「實體建構稽核(PCA)」及「功能建構稽核(FCA)」，以確保發佈產品的一致性。經確認沒問題後，於交付給客人前，將透過主管核准後，始可將產品透過發佈計畫所制定的交付媒介，交付給預定客戶。

---
透過第三及第四步驟，發佈產品得以確保其一致性。

—

SPL.2.BP12: Provide a release note.
SPL.2.BP12: 提供發佈通知
[Outcome 6]

A release is supported by information detailing key characteristics of the release.

通過詳細描述該發佈的關鍵特性資訊來支持該發佈

NOTE 8: The release note may include an introduction, the environmental requirements, installation procedures, product invocation, new feature identification and a list of defect resolutions, known defects and workarounds.

備註8: 發佈通知可包含：簡介、環境需求、安裝程序、產品使用說明、新功能識別、已修正缺陷(列表)、已知缺陷和排除方法(列表)

—

SPL.2.BP13: Deliver the release to the intended customer. 
SPL.2.BP13: 交付發佈給預定客戶
[Outcome 6,7]

The product is delivered to the intended customer with positive confirmation of receipt.

交付產品給預定客戶，並取得正向的收穫確認

NOTE 9: Confirmation of receipt may be achieved by hand, electronically, by post, by telephone or through a distribution service provider.

NOTE 10: These practices are typically supported by the SUP.8 Configuration Management Process.

備註9: 收穫確認可通過手寫、電子、貼文(郵件)、電話或透過運送(配送)服務提供商

備註10: 以上實踐通常可透過SUP.8建構管理流程來支持

---

工作產出(Output Work product)

08–16 發佈計劃 [Outcome 1,3]
11-03 產品發佈資訊 [Outcome 1,3,4,6]
11–04 產品發佈包(Package) [Outcome 2,3,6]
11–07 臨時解決方案 [Outcome 6]
13–06 交付紀錄 [Outcome 6,7]
13–13 產品發佈核准紀錄 [Outcome 5]
15–03 建構(組態)狀態報告 [Outcome 2]
18–06 產品發佈標準 [Outcome 5,7]

---