當軟體品質目標明確規定了分析指標、編程指南，以及執行階段錯誤的接受標準和閾值，車用軟體系統透過這些標準會自動進行評估，軟體變更時執行，就成為軟體開發流程中完整的一部分。如何降低程式碼品質評估的主觀性，並改善軟體開發周期的整體開發效率，就成為當中要點。

車用軟體系統在現今車輛的安全性、可靠性及效率扮演著愈來愈重要的角色。因此，工程團隊專注於提供先進駕駛輔助系統（advanced driver assistance systems；ADAS）、電池管理系統、穩定控制及其他類似的創新功能。通常，他們也需要透過證明符合ISO 26262/SAE 21434的規定，以確保滿足功能安全與網路安全的要求。

全球頂級車輛供應商Ficosa International正在開發使用在各式車輛應用的軟體。作為確保產品符合產業標準的其中一部份流程，我們的工程團隊在從實現到單元驗證、整合及鑑定測試的完整開發週期，均使用Polyspace靜態程式碼分析產品來衡量並改進程式碼品質。許多使用的流程都是基於一套明確定義的軟體品質目標，由諸如所開發的元件的關鍵性和專案的成熟度等要素組織而成。

軟體品質目標明確規定了Polyspace靜態分析指標、MISRA和CERT/CWE等編程指南，以及執行階段錯誤的接受標準和閾值。現在這些標準會自動地進行評估，並且在每一次軟體變更時執行，成為軟體開發流程中完整的一部分。因此，我們盡可能降低程式碼品質評估的主觀性，同時改善軟體開發周期的整體開發效率。

進行Polyspace使用評估

2010年，我們開始進行車輛通訊模組專案。這項專案的其中一部分要求，客戶指定使用靜態分析來檢查是否符合MISRA C。經過對市面上的靜態分析產品進行完整評估之後，我們根據產品的表現和成本，選擇了Polyspace。同時間，我們也致力於逐漸符合Automotive SPICE能力等級2（level 2），並且開始搭配使用Polyspace Bug Finder和Polyspace Code Prover靜態分析來支援軟體單元驗證活動。

很快地，我們的工程團隊開始進入ADAS的其他領域，而我們的客戶開始要求符合ASPICE level 3。與此同時，我們還開始幾項需要符合ISO 26262以被視為滿足功能安全要求的專案。不久之後，還有一些客戶開始要求符合CERT C和通用缺陷列表（Common Weakness Enumeration；CWE）的檢查，以確保滿足安全的程式碼編寫標準，在這個案例是需要尋求符合ISO 21434。

使用Polyspace軟體進行靜態分析幫助我們支援這其中每一項行動。然而，從企業組織的角度來看，缺少了開發及驗證活動的全面性計畫，計畫裡面應該要清楚定義會在何時，以及採用哪些技術、衡量方式及閾值來確保軟體品質。

正式架構尚未就位的其中一個缺點，是研發團隊會傾向等到專案更後面的階段才執行靜態分析，而不是從專案一開始就系統化地執行。可以料想，這些在開發後期進行靜態分析結果出現了許多違規行為，其中包含許多違反MISRA C的違規行為。由於這些問題是在專案後期才被發現，很難透過問題解決或論證來彌補。

為了處理這類挑戰，我們透徹分析Ficosa International該如何最佳化的符合軟體品質目標，以及我們的客戶跨越多種領域，在可靠性、功能安全和安全防護等方面的目標。這項分析的終端產品是一份軟體品質目標文件，這份文件現在被我們的團隊視為確保交付的軟體系統品質的基礎。

定義軟體品質目標

在Ficosa International的軟體品質目標文件中，我們定義了在驗證所開發的軟體時所有生效的指標和規則，包含以MISRA C、CERT C及CWE為基礎的指標和規則，還有諸如循環複雜度及註解密度等軟體指標。

下一步，我們依據待驗證的程式碼的源頭、開發中的元件類型以及其成熟度來定義指標和規則的採用標準。舉例來說，為第三方程式碼、既有程式碼（legacy code）、自動產生的程式碼，以及人工編寫的程式碼定義了不同的目標（圖1）。

圖1 : 依據軟體元件類型和專案成熟度而定義的Ficosa International軟體品質目標

對於第三方程式碼，僅執行強制性的MISRA C規則，並且假定這類程式碼附有其他相配的品質證明。對於既有程式碼、自動產生的程式碼和人工編寫的程式碼，我們採用愈來愈嚴格的規則。涉及功能安全或安全防護的元件還會進行額外的檢查，以符合ISO 26262的汽車安全完整性等級（Automotive Safety Integrity Level；ASIL）要求和ISO/SAE 21434的網路安全保證等級（cybersecurity assurance level；CAL）要求。

此外，隨著元件從早期開發（A sample）進展到中期、倒數第二個階段、最終交付（B、C、D samples），我們還會為專案定義更為嚴格的目標。最終，會有一個整合程式碼的獨立、經過縮減的規則與指標子集—亦即一組元件之中的每一個元件均通過各自的軟體品質目標評估，而且現在被整合在一起，成為更大系統的一部分。這對於簡化複雜軟體的靜態分析非常有用。

將靜態分析整合至開發工作流程

當有了明確定義軟體品質目標的文件，我們便開始使用Polysapce靜態分析產品，將這些文件整合至開發及測試流程（圖2）。

圖2 : 對於程式碼實現和驗證的流程，可看見靜態分析和後續修正的整合。

這套流程其中的一項關鍵步驟，在於納入針對開發人員向我們的版本控制系統Git發送收取要求時的規定。對於需要核准的收取要求，它除了要有單元測試結果之外，還必須成功通過Polyspace Bug Finder和Polyspace Code Prover的特定靜態分析檢查。單是這項改變就為我們整體工作流程帶來重大改善，因為它建立了一個閘門機制，確保開發人員只有在他們的程式碼完整通過合適的軟體品質目標，並且解決或證明在靜態分析找到的任何問題時，才能夠成功完成收取要求。

在軟體整合及測試期間，Polyspace產品被使用來執行以整合程式碼的軟體品質目標為基礎的靜態分析。在此階段， MISRA C的相符及程式碼指標的檢查僅限於系統層級規則和整合軟體指標。有個重點是整合層級的問題，像是共用記憶體的協作存取、無作用程式碼、重大執行階段錯誤等。

隨著採用Jenkins進行持續整合持續部署（continuous integration and continuous delivery，CI/CD）的情況愈來愈多，Polyspace產品支援頻繁的靜態分析及持續的反饋，確保開發人員及整合人員能夠維持原始程式碼與設定的品質目標的一致性。除此之外，透過Polyspace Access網路介面，我們所有的團隊都可以存取一個中央資料庫，查看靜態程式碼分析結果並且監控交付品質目標等級的進展。

在開發功能安全產品的時候，有另一個重要的考量點是要確保軟體工具不會造成、或者沒有發現在軟體量產階段的錯誤。ISO 26262明確要求軟體工具的認可流程，依據軟體的關鍵性進行分類，並且執行必要的活動來審核。針對Polyspace產品，MathWorks提供支援Bug Finder和Code Prover在專案範疇的認證套件。

關鍵優勢

透過Polyspace產品來運用良好定義的軟體品質目標，為Ficosa International須遵循ISO 26262與ISO/SAE 21434標準的車用軟體開發和交付，帶來幾項重要的優勢。

優勢之一是穩定地提升開發人員之間的開發技能。進一步來說，他們從Polyspace產品接收到的快速回應，幫助他們了解其程式碼品質哪裡需要修改及如何修改，而且因此可以幫助他們成為技術更佳、更有生產力的開發人員。事實上，透過我們建置的流程，他們必須要了解並解決通過靜態分析偵測到的問題—沒有其他的選項。

我們還發現另一個重要的好處是得以簡化ASPICE和ISO 26262外部品質評估，或者其他客戶要求須要遵循的目標。今天，我們做的每一件事都更易於論證，因為我們有清楚的軟體品質目標，並且附有報告呈現，舉例來說，MISRA與CERT變異數量遠比以往更少，還有證據顯示我們的程式碼通過了目標品質標準。

也許更為重要的是，Polyspace產品幫助我們達成品質目標，同時間增加效率，或者至少維持了同樣的效率。通常，在管理團隊或類似的團體調整組織的開發工作流程來制定執行的早期驗證步驟型態時，開發人員會將所需要完成的額外步驟視為另外的工作。有了Polyspace產品，我們便能夠向團隊證明，這些為了每一次的收取要求而執行的靜態分析所產生的額外步驟，實際上讓效率提升了。他們可以更有效率、更具信心地交付高品質的程式碼，因為所有透過靜態分析找到的錯誤都在較早的階段就已經被消滅，而不會留存到最終階段。

（本文由鈦思科技提供；作者David Tuset、Roger Marsal、Yolanda Guasch任職於Ficosa International公司）