IEC 62304在醫械軟件開發中的實施

歐洲軟件和系統提案之“利用經驗驅動測試(PET)檢驗誤碼性能計劃調查了這種現象，并且同意采用的代碼通常帶有很多誤碼的觀點。PET旨在將發布后報告的漏洞數量減少50%和將每找出一個漏洞所耗費的測試工作時間縮短40%。有意思的是，PET超過了該標準，將報告的漏洞數減少了75%，將測試效率提高了46%。PET的發現表明可以利用較新的測試方法(如靜態和動態分析)找出大量漏洞，即使代碼已經通過了功能系統測試并于隨后發布。

那么，可以采用先前通過功能測試的SOUP做進一步測試。即使它運行良好，代碼的某些部分也可能未曾使用過，即使是產品正在現場使用的時候。如果 SOUP代碼需要作進一步開發以便于后來的修訂或新應用，那么先前從未碰到的數據組合也可能會使用先前未使用的代碼路徑，從而產生意料之外的結果。圖1中的綠點曲線表示對SOUP代碼進行增強時使用的代碼。

為了克服這種潛在弱點，需要進行詳細的結構覆蓋率分析，以確保早期軟件內不存在未使用的代碼。IEC62304要求測試早期軟件的功能覆蓋率和結構覆蓋率，還要詳細分析增加這類軟件可能引入的風險。功能覆蓋率確保軟件能夠按照系統設計要求運行，而結構覆蓋率則確保使用了所有代碼并且能夠正常運行。

IEC62304要求整合到醫療器械設計中的所有SOUP項目均符合功能和性能要求規范。醫療器械制造商需要確保任意SOUP項目的正常運行，還要保證它們符合功能和性能要求。

IEC62304軟件開發過程始于軟件開發規劃，包括所用SOUP項目的詳細計劃。這些細節介紹了如何將SOUP項目整合到現有系統中、如何管理SOUP相關風險和軟件配置、以及變更管理如何影響系統。

緊接著是軟件需求管理、架構設計、集成測試、系統測試、風險管理、維護和變更管理階段。在軟件開發生命周期的各個階段，都需要保持所有階段之間的可追蹤性。

傳統的軟件開發觀點表明了各個階段如何進入下一個階段，可能還帶有前幾個階段的反饋信息，以及配置管理與過程的周邊架構。可追蹤性被視為各個階段間關系的一部分。然而，很少規定記錄跟蹤鏈路的機制。

實際上，雖然由于先進工具技術投資，各個階段都能夠有效實施，但是這些工具很少能夠自動提高階段間可追蹤性。因此，在整個項目進行的過程中，其間鏈路的維護就變得越來越差。最終的結果就是需求與設計之間的交叉檢驗缺失或者流于表面，以及最終系統的機能不全。為了獲得真正的自動可追蹤性，則需要需求跟蹤矩陣(RTM)。RTM是各個項目的核心，是很多開發標準(包括IEC62304)的關鍵所在。

需求跟蹤與SOUP

需求跟蹤矩陣是一種用于管理和跟蹤需求的習慣做法，在管理軟件需求和系統所用SOUP項目方面起著重要作用。RTM能夠通過醫療器械應用的架構設計在與SOUP有關的高級需求之間實現可追蹤性(圖2)。

圖2

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

為了確保SOUP能夠滿足IEC 62304規定的系統級要求，醫療器械制造商需要規定：