IEC 62304在醫(yī)械軟件開發(fā)中的實施

需求跟蹤與SOUP

需求跟蹤矩陣是一種用于管理和跟蹤需求的習(xí)慣做法，在管理軟件需求和系統(tǒng)所用SOUP項目方面起著重要作用。RTM能夠通過醫(yī)療器械應(yīng)用的架構(gòu)設(shè)計在與SOUP有關(guān)的高級需求之間實現(xiàn)可追蹤性(圖2)。

圖2

圖2 需求跟蹤矩陣(RTM)在開發(fā)生命周期模型中起著重要作用，即使是在SOUP項目是系統(tǒng)的一部分的時候。各個階段的典型產(chǎn)物都直接與需求矩陣相連，各個階段的變更都會自動更新RTM。

為了確保SOUP能夠滿足IEC 62304規(guī)定的系統(tǒng)級要求，醫(yī)療器械制造商需要規(guī)定：

? 預(yù)期用途所需的SOUP項目的功能和性能要求

? 讓SOUP項目正常運(yùn)行所需的系統(tǒng)硬件和軟件的生產(chǎn)規(guī)范

? 證明醫(yī)療器械架構(gòu)能夠讓任意SOUP項目正常運(yùn)行所需的詳情

大多數(shù)情況下，SOUP項目是作為源代碼提供的，但是不帶設(shè)計文件，這樣就很難分析它們。使用現(xiàn)代測試工具有助于實現(xiàn)早期代碼設(shè)計可視化。

不論它是否應(yīng)用于語句模塊、進(jìn)程(或類)、應(yīng)用和/或系統(tǒng)，現(xiàn)代測試工具提供的系統(tǒng)可視化設(shè)施功能都非常強(qiáng)大。應(yīng)用和系統(tǒng)實體的分層示意圖如圖3a內(nèi)的靜態(tài)調(diào)用圖所示;圖3b內(nèi)的靜態(tài)流程圖展示了整個程序模塊的控制流程。利用彩色編碼圖對于了解SOUP極有好處。這類調(diào)用圖和流程圖只是綜合分析代碼內(nèi)使用的所有參數(shù)和數(shù)據(jù)對象的一部分優(yōu)勢。

圖3

圖3 靜態(tài)調(diào)用圖(a)和流程圖(b)以圖形的形式分別說明了代碼的結(jié)構(gòu)和邏輯。

需求管理和跟蹤已經(jīng)證明了它們在軟件開發(fā)生命周期內(nèi)的優(yōu)勢，能夠確保實現(xiàn)所有需求和所有開發(fā)成果都可以追溯到一個或多個需求。同樣的，需求管理與跟蹤可以保證根據(jù)系統(tǒng)要求添加和驗證SOUP項目。

RTM在架構(gòu)設(shè)計和SOUP項目之間實現(xiàn)了可追蹤性。由于這些項目都包含在源代碼內(nèi)并且現(xiàn)在需要按照IEC 62304的要求進(jìn)行系統(tǒng)級合規(guī)性測試，所以代碼驗證就成了制造商的責(zé)任。

大多數(shù)SOUP項目都不嚴(yán)謹(jǐn)，從而為系統(tǒng)集成商提高了嚴(yán)格驗證與風(fēng)險分析要求。由于SOUP驗證非常耗時，所以開發(fā)人員一開始通常需要滿足一系列編碼標(biāo)準(zhǔn)，再逐漸采用其他規(guī)則。雖然測試工具只辨別而不糾正代碼內(nèi)存在的違規(guī)之處和本征誤差，但是它們確實通過指出問題所在而加快了代碼糾正速度。

IEC 62304希望醫(yī)療器械制造商評估SOUP項目供應(yīng)商提供的軟件異常列表，以便確定已知異常是否會引發(fā)事件，進(jìn)而導(dǎo)致出現(xiàn)危險情形。

測試工具的靜態(tài)分析能力能夠確定異常及其對軟件系統(tǒng)的影響。如果確定了SOUP供應(yīng)商提供的列表以外的任何其他異常，則應(yīng)告知相應(yīng)供應(yīng)商以解決問題。

靜態(tài)分析和異常糾正完成后，進(jìn)行動態(tài)分析(包括系統(tǒng)、集成度和單元測試)以便驗證SOUP項目的功能和結(jié)構(gòu)覆蓋率。雖然全系統(tǒng)功能測試提供了SOUP項目的功能簡介，但是它不測試所有代碼路徑。測試工具確定使用過的軟件部分，并且重點突出需要注意的區(qū)域，要對這些區(qū)域進(jìn)行單元測試以便保證各個單元都能夠獨立運(yùn)行。

進(jìn)行功能測試與結(jié)構(gòu)覆蓋率分析能夠確保使用了所有代碼路徑和驗證了多個單元之間的接口。它還有助于確保系統(tǒng)能夠按照設(shè)計要求運(yùn)行，即使集成了SOUP項目。值得注意的是，IEC 62304要求SOUP項目驗證遵循軟件規(guī)劃期間制定的集成計劃，再一次表明IEC 62304強(qiáng)調(diào)的重點在于確保醫(yī)療軟件升級不會引入誤碼。

根據(jù)先前制定的測試計劃，RTM在對SOUP項目進(jìn)行的各種分析之間實現(xiàn)了可追蹤性。該測試計劃包括有待執(zhí)行的測試用例以及基于系統(tǒng)要求的預(yù)期結(jié)果。利用RTM，項目經(jīng)理可以評估整合的SOUP項目的影響以及它們?nèi)绾斡绊懴到y(tǒng)安全。

SOUP項目維護(hù)

醫(yī)療器械行業(yè)的很多意外都與醫(yī)療器械系統(tǒng)的服務(wù)或維護(hù)有關(guān)，包括軟件更新和升級不當(dāng)。在這里，SOUP項目還起著重要作用，因為這些項目由不同的供應(yīng)商提供并且需要驗證。

在IEC 62304中，軟件維護(hù)過程和軟件開發(fā)過程一樣重要。強(qiáng)調(diào)維護(hù)旨在抑制產(chǎn)品發(fā)布以后(如軟件維護(hù)期間)引入的高醫(yī)療器械軟件缺陷率。

維護(hù)過程要求，制造商監(jiān)控組織內(nèi)部和用戶提供的已發(fā)布產(chǎn)品相關(guān)的反饋信息。必須記錄和分析該反饋信息，以便確定是否存在問題。發(fā)現(xiàn)問題時，應(yīng)編寫和分析問題報告，以便確定SOUP項目是否增加了問題的嚴(yán)重性。如果SOUP就是問題所在，則必須將該問題傳達(dá)給相應(yīng)的供應(yīng)商，以便通過升級或補(bǔ)丁來解決問題。

IEC 62304要求制造商制定規(guī)程，以便評估和實現(xiàn)SOUP項目升級、漏洞修復(fù)、補(bǔ)丁和報廢。必須分析和驗證每個升級、漏洞修復(fù)和補(bǔ)丁，以便確定這些升級是否引入了其它潛在的、可能導(dǎo)致出現(xiàn)危險情形的因素。一如往常，必須確定是否需要采取其它軟件風(fēng)險控制措施。

維護(hù)期間，要求制造商分析SOUP項目變更，以便確定軟件修訂是否會干擾現(xiàn)有的風(fēng)險控制措施。制造商必須制定獨特的配置項目和版本識別機(jī)制。對于使用的各種SOUP配置項目，制造商需要記錄標(biāo)題、SOUP制造商名稱和獨特的SOUP標(biāo)志符。該標(biāo)識符可以確定醫(yī)療器械軟件內(nèi)包含的軟件配置項目及其版本。

通過采用IEC 62304的高級軟件過程，公司能夠更好地開發(fā)安全的產(chǎn)品，避免代價高昂的召回，確保相同的開發(fā)過程能夠鞏固維護(hù)和升級過程。