醫(yī)療設(shè)備使用的軟件代碼比以往任何時候都多。然而，雖然軟件為醫(yī)療設(shè)備提供了更多的功能和靈活性，但它也帶來了額外的復(fù)雜性，從而增加了故障風(fēng)險。今天大約 20% 的醫(yī)療設(shè)備召回是由軟件缺陷引起的，而且這個數(shù)字還在上升。

聯(lián)邦藥物管理局 （FDA） 監(jiān)督在美國銷售的醫(yī)療器械的質(zhì)量，希望發(fā)布醫(yī)療器械的公司必須獲得 FDA 510（k） 許可。在調(diào)查上市后失敗的同時，F(xiàn)DA 更加注重預(yù)防，并建議將靜態(tài)代碼分析作為方法的一部分。

復(fù)雜缺陷檢測的價值

現(xiàn)代靜態(tài)代碼分析工具使用復(fù)雜的技術(shù)來分析源代碼以檢測潛在的軟件缺陷。工具嘗試分析代碼中的所有邏輯路徑，提供比傳統(tǒng)測試形式更多的路徑和代碼覆蓋率。靜態(tài)分析工具不需要任何測試用例，甚至可以對代碼片段進(jìn)行操作，發(fā)現(xiàn)潛在的程序崩潰、緩沖區(qū)溢出、內(nèi)存泄漏、數(shù)據(jù)損壞等。靜態(tài)分析通常運(yùn)行迅速，并且可以在相對較短的時間內(nèi)報告一系列潛在的錯誤（參見圖 1）。

圖 1：靜態(tài)分析可以在軟件開發(fā)生命周期的早期發(fā)現(xiàn)潛在問題。

由于各種原因，靜態(tài)分析工具確實會產(chǎn)生一些錯誤的結(jié)果，通常稱為誤報和誤報。當(dāng)靜態(tài)分析工具認(rèn)為有錯誤而沒有錯誤時，就會發(fā)生誤報。誤報是應(yīng)該報告錯誤但沒有報告。

大多數(shù)現(xiàn)代靜態(tài)分析工具必須在可接受的精度水平和可接受的運(yùn)行時間之間找到盡可能多的好結(jié)果之間進(jìn)行微妙的權(quán)衡。換句話說，在大量誤報中發(fā)現(xiàn)每個問題的嘈雜工具的價值可能有限，就像只發(fā)現(xiàn)一小部分問題的高度準(zhǔn)確的工具一樣（參見圖 2）。

圖 2：靜態(tài)分析工具不會發(fā)現(xiàn)所有錯誤（誤報），并且會報告一些并非真正的錯誤（誤報）。使遺漏的錯誤和錯誤報告最小化的是良好的分析算法和適當(dāng)?shù)姆治稣{(diào)整。

現(xiàn)代靜態(tài)分析工具已經(jīng)改進(jìn)了分析技術(shù)，可以以足夠的準(zhǔn)確度生成有用的結(jié)果。大多數(shù)組織認(rèn)識到靜態(tài)分析工具雖然不完善，但在大多數(shù)軟件開發(fā)過程中都提供了重要的價值。

充分利用靜態(tài)分析工具

現(xiàn)代靜態(tài)分析工具對大多數(shù)醫(yī)療設(shè)備制造商來說都是相對較新的。對于許多首次在其流程中實施靜態(tài)分析的組織而言，了解最佳實踐有助于在最短的時間內(nèi)以最少的返工量充分利用工具。

調(diào)音

靜態(tài)分析工具提供了適用于所有類型代碼庫的通用設(shè)置，雖然它們可以立即發(fā)現(xiàn)好的錯誤，但只需針對代碼調(diào)整工具就可以大大改善結(jié)果（參見圖 3）。這有助于找到更多相關(guān)的錯誤并減少通過誤報進(jìn)行的搜索，這會浪費時間并導(dǎo)致開發(fā)人員疲勞。

圖 3：幾乎每個靜態(tài)分析部署都應(yīng)該從一個可靠的調(diào)優(yōu)項目開始。調(diào)整會帶來更多更好的錯誤和更少的誤報。

許多靜態(tài)分析工具都有自己的源代碼解析器，它們可能無法理解或無法訪問所有代碼。將系統(tǒng)配置為分析所有代碼或調(diào)整系統(tǒng)以識別分析時無法訪問的接口——例如單獨驗證的第三方庫——確保結(jié)果是最佳和可重復(fù)的。實現(xiàn) 100% 的代碼覆蓋率對于堵住可能增加風(fēng)險的漏洞非常重要。

調(diào)優(yōu)有助于發(fā)現(xiàn)真正的問題。例如，告訴靜態(tài)分析工具內(nèi)存分配機(jī)制是如何工作的，或者程序何時退出，以便該工具不會繼續(xù)沿著特定路徑跟蹤問題，可以幫助發(fā)現(xiàn)新問題并刪除錯誤問題。這可能是一個繁瑣的過程，需要特定的專業(yè)知識，但從長遠(yuǎn)來看會有所回報。

調(diào)優(yōu)通常是一個持續(xù)的過程，應(yīng)定期審查，以確保一致地使用配置并跟上代碼和環(huán)境的變化。如果不進(jìn)行持續(xù)調(diào)整，開發(fā)人員可能會錯過一些重要的錯誤，并且團(tuán)隊將浪費時間檢查誤報。

配置檢查器

許多靜態(tài)分析工具附帶數(shù)百個檢查，涵蓋從并發(fā)性到安全性到 C 和 C++ 陷阱的一系列問題。許多人不一定適用于給定的應(yīng)用程序。例如，為什么在分析 C 代碼時打開 C++ 特定檢查？確定正確的檢查器集需要一些試驗和錯誤以及專業(yè)知識，以了解什么是最劃算的。需要考慮的一些領(lǐng)域是：哪些類型的檢查器會導(dǎo)致真正的問題，哪些檢查器容易產(chǎn)生噪音，哪些檢查器可以配置為有用。一旦一個好的集合最終確定，將其鎖定，以便記錄并始終如一地運(yùn)行。

在一個說明檢查器價值的真實示例中，客戶希望確保他們的靜態(tài)分析系統(tǒng)始終如一地運(yùn)行，并要求在系統(tǒng)出現(xiàn)差異時立即收到警報。開發(fā)人員創(chuàng)建了一個測試套件，其中包含每個檢查器的測試用例。每當(dāng)他們更改系統(tǒng)時，他們都會運(yùn)行測試套件以確保每個檢查器確實按預(yù)期運(yùn)行。如果結(jié)果失敗，他們知道他們有需要解決的配置問題。如果測試通過，開發(fā)人員會將結(jié)果放入他們的設(shè)計歷史文件中，以證明系統(tǒng)按照他們記錄的方式工作。該測試套件不僅為客戶提供了責(zé)任和保證，而且還降低了他們的維護(hù)和管理成本。

過程

一旦實現(xiàn)了全面覆蓋、調(diào)整了系統(tǒng)并定義了分析的廣度，開發(fā)人員就可以開始更有效地使用靜態(tài)分析。對于醫(yī)療設(shè)備，一個典型的目標(biāo)是檢查報告的每一個問題。每個問題都可以通過多種不同的方式進(jìn)行分類：

一個必須解決的問題。它將有一個適當(dāng)?shù)膬?yōu)先級來描述它的重要性以及在軟件開發(fā)過程中必須如何解決它。

正確標(biāo)記的問題，但不太可能表現(xiàn)為現(xiàn)實世界的錯誤，通常是因為該工具做出了不正確的環(huán)境假設(shè)。這些類型的分類標(biāo)志著潛在的調(diào)整機(jī)會。

被錯誤地標(biāo)記為錯誤的問題，無論是誤報還是分析工具中的徹底錯誤。這些問題也預(yù)示著調(diào)整機(jī)會。

這些案例中的每一個都必須仔細(xì)審查。尤其應(yīng)檢查誤報的正確性。每個問題都需要自由文檔，并且需要一個強(qiáng)大的數(shù)據(jù)保留政策來實現(xiàn)全面問責(zé)。如果在流程后期發(fā)現(xiàn)重大錯誤，這些分類缺陷報告可能會在審計過程中或在回顧中重新審查。組織通常會回到靜態(tài)分析缺陷以查看主要錯誤是如何通過該過程的。它可能標(biāo)志著一個中斷的過程或一個調(diào)整分析以找到更好的錯誤的機(jī)會。

使用模式

靜態(tài)分析通常在開發(fā)人員沙箱構(gòu)建中和/或通過中央構(gòu)建運(yùn)行（參見圖 4）。至少，在發(fā)布之前分析和評估結(jié)果是有意義的。但是，軟件開發(fā)組織不應(yīng)該等到最后一刻才解決可能存在的大量錯誤，特別是當(dāng)這些錯誤本可以作為規(guī)范流程的一部分更早地解決時。否則，團(tuán)隊可能會錯過最后期限并在最壞的時間更改代碼。

圖 4：靜態(tài)分析可以根據(jù)業(yè)務(wù)需求、環(huán)境和使用的工具以多種不同方式部署。

組織通常將靜態(tài)分析自動化作為夜間構(gòu)建或持續(xù)集成構(gòu)建的一部分。通過這種方式，可以經(jīng)常審查結(jié)果并在結(jié)果出現(xiàn)時加以處理。其他人則通過使開發(fā)人員能夠在沙盒環(huán)境中分析他們正在處理的代碼來更早地執(zhí)行錯誤發(fā)現(xiàn)過程。開發(fā)人員可以立即獲得有關(guān)其代碼更改質(zhì)量的反饋，然后在簽入前修復(fù)和驗證缺陷。循環(huán)時間越快，代碼庫中的代碼就越干凈。

無論在哪里運(yùn)行，技術(shù)環(huán)境都需要保持一致，以確保結(jié)果相同。中央和開發(fā)人員構(gòu)建需要保持一致。對分析設(shè)置的輕微更改可能會導(dǎo)致報告更多結(jié)果，并且組織不需要審查更多可能主要是誤報的問題的額外負(fù)擔(dān)。為開發(fā)人員創(chuàng)建一個高度自動化的系統(tǒng)將有助于確保一致性。

許多醫(yī)療設(shè)備公司不僅將源代碼檢查到其存儲庫中，還檢查其實際環(huán)境。這樣，可追溯性是可用的。靜態(tài)分析可執(zhí)行文件和所有相關(guān)配置、狀態(tài)和其他相關(guān)項目也應(yīng)定期檢查，以確保一致性和問責(zé)制。

處理積壓

大多數(shù)組織在開發(fā)大量代碼后開始使用靜態(tài)分析。通常，代碼越多，報告的錯誤就越多。因此，在推出靜態(tài)分析時，管理層必須預(yù)先分配時間來處理最初積壓的錯誤。

最好在開發(fā)周期中盡早進(jìn)行靜態(tài)分析，以盡量減少積壓，然后創(chuàng)建一個流程來處理積壓，與由于日常代碼更改導(dǎo)致的日常流入錯誤流分開處理。審查缺陷需要時間，應(yīng)該在開發(fā)人員之間適當(dāng)分配，或者外包給一個單獨的團(tuán)隊來挑選需要工作的缺陷。

文化

所有開發(fā)團(tuán)隊在技術(shù)技能水平以及團(tuán)隊中每個人如何定義質(zhì)量方面都存在差異。在培訓(xùn)和指導(dǎo)課程中，最常見的論點是：

“是的，這絕對是一個錯誤，但代碼一直在工作，所以我們不想更改它?！?/p>

“我們不應(yīng)該讓這樣的代碼出現(xiàn)在我們的產(chǎn)品中。”

“這種情況在現(xiàn)實生活中永遠(yuǎn)不會發(fā)生。”

“如果我們將來將產(chǎn)品移植到另一個平臺，這將成為一個錯誤?！?/p>

“如果你在這上面多花幾分鐘，你就會發(fā)現(xiàn)這顯然是一個錯誤?！?/p>

靜態(tài)分析將提供各種類型的錯誤，從必須解決的關(guān)鍵問題到警告。一些組織希望投機(jī)取巧，只為可證明的錯誤更改代碼。其他人則主動清理代碼并提高質(zhì)量，甚至“修復(fù)”警告。團(tuán)隊?wèi)?yīng)該在處理靜態(tài)分析結(jié)果的方式上保持一致。審查結(jié)果、培訓(xùn)/指導(dǎo)和頻繁的溝通是成功的關(guān)鍵。

如果使用得當(dāng)，靜態(tài)分析已被證明在提高安全關(guān)鍵代碼的軟件質(zhì)量方面非常有效。盡管不嚴(yán)格要求批準(zhǔn)，但 FDA 承認(rèn)其有效性。通過適當(dāng)?shù)囊?guī)劃、專業(yè)知識和現(xiàn)實的投資，靜態(tài)分析應(yīng)該會產(chǎn)生可觀的投資回報，并有助于向市場提供安全的代碼。

審核編輯：郭婷