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

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

培養(yǎng)質(zhì)量文化

質(zhì)量文化將減少實現(xiàn)優(yōu)質(zhì)產(chǎn)品的開銷，并意味著在生產(chǎn)高質(zhì)量軟件時需要更少的有意識的思考和努力。

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

有效的質(zhì)量文化的基石是良好的溝通。技術(shù)包括從每日例會到報告錯誤時提高清晰度的所有內(nèi)容，以便在修復(fù)錯誤時不太可能犯錯誤?？缏毮軋F隊和團隊之間的密切溝通也有助于促進質(zhì)量文化，并確保所有利益相關(guān)者對質(zhì)量和安全目標有很好的理解。

優(yōu)化您的軟件開發(fā)方法

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

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

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

但是，仍然可以利用許多 DevOps 和敏捷原則來創(chuàng)建一種簡化的、更具迭代性的方法來開發(fā)安全關(guān)鍵型和業(yè)務(wù)關(guān)鍵型嵌入式項目。

Shift-left

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

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

寫出高質(zhì)量的需求

從硬件開始

讓領(lǐng)域?qū)＜覅⑴c需求定義

優(yōu)化項目范圍

簡單的設(shè)計

靜態(tài)分析

自動化測試生成

使用持續(xù)集成

保持硬件循環(huán)

簡化需求可追溯性

編寫易于維護的測試

審核編輯：郭婷