重用舊代碼是現實，但是在安全關鍵型軟件項目中重用舊代碼并實現MISRA C 2012的完全合規性是艱巨的任務。

最初的MISRA原則是為了在開發代碼時應用而創建的，即使文檔本身也有警告：

“……在項目周期的后期檢查MISRA C符合性的項目可能會花費大量時間進行重新編碼、重新審查和重新測試。因此，預計軟件開發過程將需要盡早應用MISRA C原則。”

由于出于業務原因，許多組織確實需要重用其舊版代碼庫，因此針對這些挑戰創建了MISRA 2016合規指南文件。其中，在當前項目范圍內開發的新的本機代碼與在項目范圍之外開發的“已采用”代碼之間有明顯的區別。在這篇文章中，我解釋了一種處理遺留代碼和MISRA C合規性的實用方法。

遵循MISRA準則的灰色陰影

盡管似乎很容易理解要處理的代碼類型，但在很多情況下情況并非如此。例如，將不遵循MISRA準則開發的初始原型產品化，然后管理層意識到合規性是預期市場的要求。通常，遺留代碼庫的開發從來沒有考慮任何編碼準則。因此，如果在新項目的上下文中需要更新，則無法將代碼庫自動分類為“采用的代碼”。這會變得很復雜。

通常，通過啟用了所有MISRA C 2012規則（包括修訂1）的靜態分析工具對大型代碼庫進行的初始掃描會產生數以萬計的違規行為。在最初的震驚之后，團隊開始尋找解決沖突的“創造性”方法。重要的是，不要阻止開發團隊——隧道盡頭有陽光。

隨著時間的流逝，我已經收集并確定了開發團隊用來使代碼合規而又不影響正在進行的開發速度的最佳實踐和方法。在本文中，我將分享一些實用且平衡的方法，以使現有代碼庫符合MISRA。

使用MISRA Compliance: 2016框架

MISRA C 2012是用于C編程語言的一組編碼準則。該標準的重點是通過避免C語言中的已知問題構造，通過防止編程人員犯錯誤而導致運行時失敗（以及可能的安全問題），從而提高軟件的安全性。多年來，許多嵌入式系統開發人員一直（并且仍然）抱怨MISRA C對標準過于嚴格，并且編寫完全兼容的代碼的成本難以證明。實際上，鑒于MISRA C已應用在安全關鍵軟件中，因此將該標準應用于項目的價值取決于以下因素：

• 由于軟件故障而導致系統故障的風險

• 系統故障給企業造成的損失

• 開發工具和目標平臺

• 開發人員的專業知識水平

因此，程序員必須找到一種符合標準精神的實用中間立場，并且仍要聲稱自己符合MISRA，而不會浪費精力在非增值活動上。

在MISRA Compliance: 2016文件中，MISRA聯盟提供了社區所需的響應，并提供了一個合理定義良好的框架，說明“符合MISRA”一詞的真正含義。該文檔通過定義以下工件來幫助組織使用表達合規性要求的通用語言：

• 準則執行計劃——演示如何驗證每個MISRA準則。

• 準則重新分類計劃——在準則中傳達商定的各個規則的嚴重性，作為供應商/客戶關系的一部分。

• 偏差報告——以合理的理由記錄違反準則的情況。

• 準則合規摘要——是總體項目合規性的主要記錄。

為了專注于處理遺留代碼庫，關鍵文檔是指南重新分類計劃。本文檔包含所有指令和規則，并確定已重新分類了哪些類別。例如，下圖顯示了重新分類計劃的一部分：

首先，對于“采用的”舊代碼，《MISRA 2016: Compliance》文檔建議不要從不太嚴格的分類到更嚴格的分類進行重新分類。此外，在與小組一起審查違規類型之后，也可以一起取消應用咨詢規則。

僅對于所有必需規則才需要記錄偏差。應該對所采用的規范中的任何違規行為進行審查，并且偏差必須清楚地表明違規行為不會損害安全性。不管重新分類如何，如果發現有損害系統安全性的問題，則必須解決此問題。同樣，對遺留代碼的修改可能會引入其他問題，這些問題是開發人員無法清楚看到的。

開始就要考慮如何結束

安全關鍵軟件開發人員遇到的關鍵問題是如何在項目結束時演示和證明合規性。如果評估標準基于各個利益相關者的主觀意見，那么這可能是一個有爭議的問題，導致浪費時間和精力。在這種情況下，MISRA Compliance: 2016文檔得以解決。

建議的改進對合規性準備情況評估的方法是將現有模板用于最終合規性和工具合格性報告。還有一種趨勢是向報告中添加比所需更多的信息。如果標準不要求提供該信息，請避免點綴。添加額外的信息不僅浪費時間，而且存在延遲審核過程的風險。

MISRA Compliance 2016提供了包含在最終報告中的必需信息：

• 準則執行計劃

• 準則合規性摘要

• 所有批準的偏差許可證的詳細信息

• 偏差記錄涵蓋了所有違反準則的情況，已按要求重新分類。

以下來自Parasoft工具的示例顯示了HTML格式，并帶有指向相應部分的鏈接：

盡早建立最終目標

除上述建議外，還需要考慮其他一些重要點：

• 在項目開始時是否制定了GRP（指南重新分類計劃）？根據MISRA標準，可以與收購方進行協商，也可以為所采用的代碼創建多個GRP，這些代碼無需進行任何修改就可以使用，而本機代碼則是項目期間主動修改的。

• 對于每個增量更改，是否都存在要完全遵守法規的剩余工作量？這有助于相應地計劃工作并與管理層建立正確的期望。

• 在項目開始時，是否已與采購方一起審查了GPS（指南符合性摘要）報告模板，這些模板是否被接受并完整？

商業靜態分析工具供應商（包括Parasoft）提供了這些文檔的模板，以幫助組織滿足MISRA 2016合規性框架。

分階段實施：分而治之

盡管通過靜態分析工具對現有代碼進行的初始掃描往往會產生數千個違規行為（尤其是在使用默認規則集時），但停止新的開發工作來集中精力解決所有這些違規行為是不切實際的。實際上，我已經看到在對代碼庫進行重大更改以修復靜態分析違規時引入了回歸的情況。因此，重要的是建立一個工作流來解決隨時間推移的違規問題，而又不影響開發流程和軟件質量。

下面列出了在項目中首次使用靜態分析工具時的一些關鍵建議：

• 基線。在對代碼進行初始掃描之后，將所有初始違規標記為“稍后處理”，并設置為基準。從那時起，在更新現有代碼和/或開發新代碼時，應保持“不允許出現新的違規”政策。可以通過代碼檢查過程或Jenkins或Bamboo等持續集成（CI）工具來實施此策略。當開發人員有幾個小時或幾天的空閑時間時，他們可以解決從基線標記的其余違規情況。組織可以根據當前正在開發的代碼，代碼審查結果或依靠度量標準（例如復雜性）來建議下一個要解決的違規問題，從而優先考慮此方法。

• 線在沙子里。開發確定了一個日期，即“界線”。在此日期之后，修改的每個翻譯單元（單個源文件）都必須解決所有違規問題。所有未修改的翻譯單元都會自動歸入MISRA合規性文檔中真實的“采用”代碼定義之內。

• 基于嚴重性的優先級。開發人員會修復分配給他們的模塊的所有強制性發現。隨著時間的推移，他們會根據團隊負責人選擇的優先級，在時間允許的情況下解決所有要求的違規行為。

對于上述任何一種方法，對于技術負責人和管理人員而言，通過集中式儀表板不斷監視進度和項目合規性狀態至關重要。例如，Parasoft的報告中心提供了以下預配置的合規性狀態儀表板：

工具資格

MISRA合規性的一個不太明顯的組成部分（通常留到項目結束時）是認識到產品中使用的開發工具需要針對預期用途進行資格驗證（已證明適合目的）。如果工具需要鑒定，則需要執行什么級別的鑒定？

盡管在許多情況下需要工具鑒定，但用于進行工具鑒定的方法因與工具故障和軟件關鍵性等級相關的風險而異。Parasoft提供了針對特定安全標準及其要求的認證套件和認證。在缺少此高效工具包的情況下，軟件團隊在評估商業，免費和開源工具時必須考慮工具認證成本。

一些標準（例如ISO 26262和DO-178B/C）提供了有關工具鑒定要求的合理指導。無論采用哪種方法，工具鑒定過程的目標都是聲明“工具對預期用途有效”，并提供團隊如何得出此結論的證據和理由。

以下是一些建議的步驟，用于工具鑒定過程：

• 指定預期用途的工具要求

• 標識產品中使用的功能的子集。將認證過程簡化為僅使用的功能

• 概述資格計劃

• 概述驗證工具是否符合要求的一組資格驗證步驟（可能包括團隊執行的測試）

• 自動執行可以自動化的測試用例

• 提供一個框架來輸入手動測試步驟的結果

• 報告模板以減少開發人員需要輸入的文本量。

• 與利益相關者一起審查報告并簽字。

從一開始就忽視工具資格可能會導致項目周期延遲。

員工能力和培訓

開發人員的專業知識和培訓是軟件組織忽視的另一個關鍵因素，在評估產品的就緒狀態時，審計人員經常將其視為首要問題。

根據《MISRA指南》，員工能力是MISRA合規性的重要組成部分。最好在項目開始時進行培訓，并記錄培訓日期，所有開發人員都應簽字同意接受培訓。在項目結束時，開發團隊應該能夠證明：

• 批準偏差的工作人員了解并接受過培訓，可以認識到與違規有關的風險

• 人員經過培訓，可以在使用前正確配置和使用靜態分析和開發工具。

實際上，對經驗豐富的團隊的培訓相對較短，但是在錯過項目截止日期之后，在項目開始時投入幾天的時間就可以節省數周的返工。

總結

沒有任何靈丹妙藥可以使對安全至關重要的項目輕松實現對遺留代碼的MISRA合規性。但是，正如本文所概述的那樣，隨著引入MISRA Compliance 2016框架，使用實用的分階段方法以及明確定義的終點（如本文所述），軟件開發團隊可以在不嚴重破壞其開發流程的情況下實現合規性。最重要的是，要實現合規性還需要進行大量工作，但是通過智能計劃和正確的方法，可以建立起最小和平衡的任務集，以確保舊代碼和新開發代碼的安全。