摘要

上一篇文章我們簡單介紹了醫(yī)療設(shè)備軟件關(guān)于風(fēng)險方面的相關(guān)背景和兩個技巧。這篇文我們將繼續(xù)介紹剩下的三個技巧，以及如何管理風(fēng)險。

4. 動態(tài)分析

靜態(tài)分析將源代碼解析為文本，并在不執(zhí)行單個指令的情況下根據(jù)解析器輸出得出所有結(jié)果，而動態(tài)應(yīng)用程序安全測試（DAST）則為代碼提供了不同的視角。它檢查運行中的代碼，顯示代碼覆蓋率、充分性和單元測試的質(zhì)量、內(nèi)存泄漏和其他潛在的弱點問題。

技巧3：靈活使用運行時環(huán)境

“嵌入式”一詞涵蓋了許多設(shè)備，從具有數(shù)千字節(jié) RAM 和閃存的 8 位 MCU 到具有千兆字節(jié) RAM 和高速 SSD 的 64 位多核 CPU。如果設(shè)備的日常操作需要最少的內(nèi)存和處理能力，制造商可能會選擇僅滿足其需求的硬件，也可能因為尺寸、重量或成本限制。

雖然它們通常會留出一些用于軟件更新和維護的可用硬件資源，但當(dāng)涉及到對軟件進行動態(tài)分析工具檢測時，這可能仍然不夠，因為與正常操作模式相比，該過程將需要大量的 RAM 和存儲空間來收集測試和代碼覆蓋率結(jié)果。

因此，當(dāng)設(shè)備上的內(nèi)存量太低而無法運行測試和收集代碼覆蓋率時，目標平臺可能不適合收集單元和集成測試的代碼覆蓋率。

如果您的主要目標平臺不支持做動態(tài)分析，請搜索有效的替代平臺。可能有一個同類型的平臺，具有更多接口和內(nèi)存，并且被動態(tài)分析工具支持，因此客戶可以很輕松地在這個平臺上進行單元測試和一些集成測試。另一種選擇是硬件模擬器，也就是我們常說地simulator，比如QEMU 的硬件模擬器，它可以支持運行ARM可執(zhí)行程序。

雖然在目標平臺上運行測試是最理想的，但很多時候團隊選擇在開發(fā)人員工作站（例如 Linux、Mac、Windows）上執(zhí)行單元測試和一些應(yīng)用程序集成測試，這樣可以節(jié)省更多的時間，加快了開發(fā)周期。在這種情況下，用戶需要移植嵌入式代碼，讓這些代碼可以使用主機編譯器進行編譯，但這個過程會有一些挑戰(zhàn)。

有很多編譯器、構(gòu)建工具、框架和運行它們的方法。動態(tài)分析工具支持一些常見的構(gòu)建技術(shù)，并且有對應(yīng)的材料，讓開發(fā)人員快速上手。但是即使代碼是可移植的，項目團隊很可能需要額外的時間來根據(jù)項目構(gòu)建系統(tǒng)的工作方式來調(diào)整動態(tài)分析工具的設(shè)置。

強烈建議在進行這類工作前，進行工作時間和成本評估，以便從長遠角度為未來的發(fā)展找到最佳方法。

技巧4：不要過度依賴自動生成的測試用例

現(xiàn)代動態(tài)分析工具會自動生成單元測試用例以增加代碼覆蓋率。但工具只是工具。它們不知道如何使用業(yè)務(wù)代碼的各種場景，特別是當(dāng)用戶嘗試增加代碼覆蓋率并跨越純單元測試和集成測試之間的界限時。用戶仍然需要手動更新生成的單元測試，甚至編寫新的單元測試用例，因為只有用戶知道代碼在涉及正面和負面測試結(jié)果時的用途。

關(guān)鍵區(qū)域中的一組選定文件可以自動生成每個文件覆蓋范圍從 40% 到 100% 的單元測試。但平均而言，對于整個項目，數(shù)值可能在 25% 到 60% 之間變化。

此外，僅使用源代碼作為輸入的自動生成的單元測試通?？梢栽谟绣e誤的代碼上完美運行。自動生成測試用例應(yīng)該作為開始單元測試過程的良好開端，手動創(chuàng)建測試用例的過程可以提高代碼的質(zhì)量，因為它強制進行額外的代碼審查并為代碼結(jié)構(gòu)設(shè)計提供了不同的考慮方向。

技巧5：不要低估工具驗證和確認的工作量

FDA 要求正式開發(fā)過程中使用的任何工具都必須針對預(yù)期用途進行驗證，以確保其執(zhí)行預(yù)期的操作并產(chǎn)生正確的結(jié)果。通常，這是一種稱為 IUV（預(yù)期用途驗證）的特殊測試協(xié)議。

業(yè)界領(lǐng)先的靜態(tài)和動態(tài)分析工具供應(yīng)商可幫助生成必要的程序和文檔，這對于最大限度地減少用戶的工作量非常有幫助。Parasoft 的解決方案特別有價值，因為它實現(xiàn)了大部分流程的自動化。與任何其他通用包一樣，用戶可能需要花費一些時間來審查和調(diào)整文檔，以便將它們與用戶自己的 QMS 程序同步。例如，Parasoft 的工具資格套件提供了一組要在用戶的環(huán)境中執(zhí)行的測試用例，以驗證靜態(tài)和動態(tài)分析功能。

5.5個技巧回顧

將編譯器警告視為錯誤。對于同一編譯器的較新版本，警告可能會變成錯誤。警告通常意味著編譯器隱式執(zhí)行某些操作：

在項目早期運行靜態(tài)分析工具并修復(fù)出現(xiàn)的問題

保持代碼可移植。即使您不打算將產(chǎn)品移植到另一個平臺，這也可能是未來的一個選擇。另一方面，這也將有助于保持代碼干凈、可維護和可讀，這總是有利于審查和進一步支持

不要過度依賴自動生成的測試用例來提高代碼質(zhì)量

不要低估驗證工具是否達到預(yù)期用途的需求和工作量

6. 醫(yī)療器械軟件開發(fā)中的風(fēng)險管理

在開發(fā)醫(yī)療設(shè)備軟件時，管理風(fēng)險是該過程的關(guān)鍵組成部分。醫(yī)療設(shè)備軟件通常很復(fù)雜，必須在嚴格的基準范圍內(nèi)運行，以確保醫(yī)療設(shè)備的安全性和效率。因此，識別、分析和減輕開發(fā)過程中可能出現(xiàn)的潛在風(fēng)險至關(guān)重要。

醫(yī)療設(shè)備軟件開發(fā)中的有效風(fēng)險管理涉及許多不同的活動， 這些可能包括：

識別與設(shè)備及其軟件相關(guān)的潛在危險和風(fēng)險

評估風(fēng)險的可能性和嚴重性

實施風(fēng)險控制以減輕或消除風(fēng)險

隨著時間的推移監(jiān)控這些控制措施的有效性

此外，醫(yī)療設(shè)備軟件開發(fā)中的風(fēng)險管理還需要深入了解醫(yī)療軟件缺陷可能造成的危害程度。這可以通過風(fēng)險索引來完成，風(fēng)險索引根據(jù)風(fēng)險的嚴重程度對風(fēng)險進行分類。

在醫(yī)療設(shè)備軟件方面，建立風(fēng)險指數(shù)有助于確定風(fēng)險管理指標，例如在軟件發(fā)布使用之前應(yīng)進行的所需測試、驗證和確認級別。它還可以幫助為確保軟件持續(xù)安全性和有效性所需的持續(xù)測試、監(jiān)控和維護定下基調(diào)。

安全完整性等級 (SIL) 示例表

6.1 風(fēng)險管理在醫(yī)療器械軟件開發(fā)中的重要性

有效的風(fēng)險管理對于醫(yī)療設(shè)備軟件的開發(fā)至關(guān)重要。即使是很小的錯誤或疏忽也可能給醫(yī)療保健部門的患者帶來嚴重后果。因此，在開發(fā)過程中盡早識別和減輕潛在風(fēng)險至關(guān)重要。以下是風(fēng)險管理在醫(yī)療設(shè)備軟件開發(fā)中很重要的一些原因：

1．確?；颊甙踩?/strong> 醫(yī)療設(shè)備軟件故障可能會導(dǎo)致生命安全。有效的風(fēng)險管理有助于識別潛在風(fēng)險并在對患者造成傷害之前減輕風(fēng)險。