需求跟蹤與SOUP

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

圖2

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

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

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

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

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

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

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

圖3

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

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

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

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

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

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

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

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

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

SOUP項(xiàng)目維護(hù)

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

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

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

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

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

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