任何優化軟件開發過程的嘗試都將不可避免地遇到質量、資源和時間之間的古老權衡。這個三重約束對于項目經理來說是眾所周知的，格言是只有三分之二才有可能成功。

當然，沒有公司真的想在質量上妥協，但對于安全關鍵型或業務關鍵型軟件而言，風險更高，因為在質量上妥協可能會導致嚴重的財務或危及生命的后果，因此主要關注點必須放在質量上對于此類項目。那么，當項目的性質要求軟件質量必須是最重要的時候，您如何優化嵌入式軟件開發呢？

培養質量文化

質量文化將減少實現優質產品的開銷，并意味著在生產高質量軟件時需要更少的有意識的思考和努力。

幸運的是，通過遵循一些簡單的原則，發展質量文化相對容易。質量文化傾向于促進透明度和所有權。他們還將測試和質量控制視為開發過程的重要組成部分，而不是最后的開發步驟。

有效的質量文化的基石是良好的溝通。技術包括從每日例會到報告錯誤時提高清晰度的所有內容，以便在修復錯誤時不太可能犯錯誤。跨職能團隊和團隊之間的密切溝通也有助于促進質量文化，并確保所有利益相關者對質量和安全目標有很好的理解。

優化您的軟件開發方法

現代軟件開發方法，如敏捷和 DevOps，被廣泛認為比傳統的瀑布方法產生更快的結果。所有主要的軟件安全標準（例如，IEC 61508、ISO 26262 和 DO-178C）都將軟件開發定義為線性過程，v 模型在左側顯示需求定義，在右側顯示測試，如下圖所示：

圖 2：ISO 26262 道路車輛定義的 V 型 - 功能安全

這使得在開發安全關鍵軟件時很難擺脫線性瀑布方法。現代敏捷開發實踐側重于頻繁發布，這可能會給安全關鍵型軟件的開發帶來問題，因為每個發布都需要經過正式的驗證和/或認證流程。同樣，DevOps 原則（例如持續部署）在涉及硬件時會變得更加復雜。

但是，仍然可以利用許多 DevOps 和敏捷原則來創建一種簡化的、更具迭代性的方法來開發安全關鍵型和業務關鍵型嵌入式項目。

Shift-left

在項目開發生命周期中較早（左）移動工作量通常會導致整體工作量減少。花更多時間確保軟件需求和設計正確可減少生產問題并避免將時間花在浪費性的開發活動上。左移的測試方法的原理是，更早地發現錯誤意味著可以更快、更容易、更便宜地修復它們。這主要是因為，如果測試被延遲，依賴項變得難以解除。

Shift-left 可以增量地應用于大型和復雜的系統。敏捷通過在敏捷方法中為每個沖刺或迭代使用迷你 v 模型來進一步實現這一點。

寫出高質量的需求

從硬件開始

讓領域專家參與需求定義

優化項目范圍

簡單的設計

靜態分析

自動化測試生成

使用持續集成

保持硬件循環

簡化需求可追溯性

編寫易于維護的測試

審核編輯：郭婷