ASPICE 標準解讀

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)。

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

額外討論 — 什麼時候需要定義內外部待發佈對象?

一般來說,如果專案的規模涉及多個部門(或多個子公司),那麼就建議將內部發佈納入考量;反之,在專案時程及資源限制下,筆者會建議可以不特別為內部發佈制定計畫,但是儘管如此,專案計畫中仍然會將內部發佈的重要時間加入監管,只是不用刻意完整的遵照SPL.2流程的定義。


流程結果(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標準與公司既有流程整成後的順暢性。
SPL.2 根據產品開發過程 可能會有多次的發佈時機
額外說明 -- 應用參數 (application parameters)

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

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

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

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


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

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

(額外參考:ISO 26262-6:2018 Annex C)
SPL.2 發佈過程的應用參數(著重在軟體編譯)

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.11.2.0-b.2:這是在進行單元測試後的版本發佈,單元測試期間可能遭遇一些錯誤並完成修正,因此出現了兩個迭代的版本。

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

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

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

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

如果客戶並沒有在過程中不斷索要(軟體),那麼當然可以透過版本控管(這將會在SUP.8 建構管理中說明),就可以完成開發過程中的程式碼管理了。
SPL.2: 發佈版本的概念 – 結合工程開發模型

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: 如何確保產品發佈的一致性

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]


筆者筆記

在這個章節,我將整理在評鑑與輔導過程中,最常被企業問到的問題。

問題1: 如果被要求VDA Scope (換句話說,沒有被要求SPL.2) 是否還是要注意產品發佈?
答:當然是需要注意!一般來說,如果沒有特別被要求SPL.2,那麼評鑑老師一般會期待在專案計畫書中找到產品發佈的相關資訊(當然並不需要像發佈計畫書講到的這麼細);其次,關於產品發佈流程中所提到的構建流程(Build Process),評鑑老師也會期待在建構管理計畫書(CM Plan)中找到相關的內容。

如同BP13的Note10所提,產品發佈流程大部分都是透過建構管理流程(SUP.8)來支持的。因此,如果產品發佈流程並沒有被圈列在評鑑範圍內,那麼評鑑老師將會期待在專案管理及建構管理兩大流程中看到公司如何有效的控管產品發佈。

問題2: 內部發佈一定要被管理嗎?
答:如同筆者在「流程目的」的額外討論所提到的,如果專案的規模不大,並沒有涉及多個跨部門的工作,那麼內部發佈是可以被忽略的。

一般來說,評鑑老師會比較重視的內部發佈通常也會鎖定在「硬體發佈」及「軟體發佈」這兩個重要時機點上。不過,就如同筆者所言,如果公司實作專案的團隊規模甚小,那麼內部發佈的工作通常會在專案時程上展現,並在系統整合及整合測試流程中被檢查其發佈的合規性。

問題3: 如果客戶在開發過程臨時要求發佈,該怎麼管理?
答:一般跟客戶合作專案密切時,客戶常有在專案開發過程中臨時要求產品發佈的情形。這種情形下的發佈,也沒有在開案被識別出來。

這種情況下,通常比較嚴謹的作法是,先透過變更請求管理(SUP.10)分析處理客戶的要求,並根據客戶要求識別發佈的功能涵蓋範圍,以此更新發佈計畫書;後續,再透過既定的產品發佈流程進行臨時產品發佈。

值得一提的是,筆者於BP3所提到的產品發佈編碼原則,可以有效管理交付給客戶的產品。建議讀者也可以自行建立一套編碼原則,針對常態型發佈及臨時性發佈有所區別,以利專案的產品發佈管理。


感謝閱讀本文章!

如果你對文章內容有任何問題,請隨時與我交流聯絡。

歡迎訂閱我的文章,當有最新文章發布時,我將第一時間通知您 :)


WRITTEN BY
David Lin

現任國際標準輔導顧問及評鑑師;
在這個網站,我將分享一些產業新知、趨勢以及標準的解讀與看法。

歡迎與我交流:
Email:
linchewing@gmail.com
LinkedIn:
https://www.linkedin.com/in/linchew/