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

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

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

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

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

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

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

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

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

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

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

Shift-left

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

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

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

從硬件開始

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

優(yōu)化項(xiàng)目范圍

簡(jiǎn)單的設(shè)計(jì)

靜態(tài)分析

自動(dòng)化測(cè)試生成

使用持續(xù)集成

保持硬件循環(huán)

簡(jiǎn)化需求可追溯性

編寫易于維護(hù)的測(cè)試

審核編輯：郭婷