長庚大學資訊工程系 系主任兼所長 林仲志博士

Presentation on theme: "長庚大學資訊工程系 系主任兼所長 林仲志博士"— Presentation transcript:

1 長庚大學資訊工程系 系主任兼所長 林仲志博士 cclin@mail.cgu.edu.tw
醫療器材軟體確效法規實務介紹 長庚大學資訊工程系 系主任兼所長 林仲志博士

2 FDA對醫療器材的定義 所謂醫療器材是指符合以下條件的儀器、裝置、工具、機具、器具、插入管、體外試劑或其他相關物品，包括組件、零件或附件等
意圖使用於動物或人類疾病或其他身體狀況的診斷；或用於疾病之治癒、減緩、治療者 意圖影響動物或人類身體的功能或結構，但不經由動物或人類身體或身體上的化學反應來達成其首要目的，同時也不依賴新陳代謝來達成其主要目的

3 FDA對醫療器材分類 依照器材的用途，FDA把現有醫療器材產品總共被分成16類、約1700種：
862 Clinical chemistry and clinical toxicology devices 臨床化學及臨床毒理學 864 Hematology and pathology devices 血液學及病理學 866 Immunology and microbiology devices 免疫學及微生物學 868 Anesthesiology devices 麻醉學 870 Cardiovascular devices 心臟血管醫學 872 Dental devices 牙科學 874 Ear, nose, and throat devices 耳鼻喉科學 876 Gastroenterology-urology devices 胃腸病科學及泌尿科學

4 FDA對醫療器材分類 878 General and plastic surgery devices 一般及整形外科手術
880 General hospital and personal use devices 一般醫院及個人使用裝置 882 Neurological devices 神經科學 884 Obstetrical and gynecological devices 婦產科學 886 Ophthalmic devices 眼科學 888 Orthopedic devices 骨科學 890 Physical medicine devices 物理醫學科學 892 Radiology devices 放射學科學

5 FDA對醫療器材分級 FDA依醫療器材對人體之危害性程度，將所有醫療器材劃分為三級：
第一級（Class Ⅰ）器材 一般而言，此類器材均不用於維護病人生命，不致於危害病人的健康。這些器材只要經過一般管制就可以確保其功效與安全性，如拐杖、眼鏡片、膠布等，約佔全部醫療器材的27%。 第二級（Class Ⅱ）器材 此等級的醫療器材這些產品除了上述一般管制之外，尚須符合FDA所訂定的特別要求或其他工業界公認的標準，此類產品包含醫用手套、電動輪椅、助聽器、血壓計、診療導管等，約佔所有器材的60%。FDA的特別要求之中，對特定產品另有強制性的標準(mandatory performance standards)、病患登記及上市後監督等。 第三級（Class Ⅲ）器材 絕大部分是為維繫或繼續維繫病人的生命與健康者。 屬於第一或第二類之器材，申請資料較為簡化且需時也較短(即510(k))。而第三類器材，必需經過極嚴格之試驗及極長之審核程序(即PMA)，才能被批准上市。

6 何謂 FDA 510(k) FDA 510(k)即是指上市前通知（Premarket Notification，或簡稱510(k)) ，此途徑適用於仿造「市場上現存合格 Legally marketed」，或於一九七六年前即已上市之第一類及第二類產品之新器材。此類新器材包括相同用途之全新器材、或是同樣不同公司銷售之器材、以及經過改良之相似器材。 由於此新產品是仿照現有之合格產品，在510(k)之申請時，必須對其設計、材料、製造過程、功效性及用途等，與已上市之舊產品(也即所謂Predicate Device)做比較。 以裁定此新產品是否與舊產品具「實質相等性（Substantial Equivalence）」。

7 何謂 PMA PMA是上市前許可（Premarket Approval）的簡稱，亦即所有第三類之器材，或第一類或第二類之新器材產品，若被裁定與現在市場上同類器材不具「實質相等」性時，必須經過「上市許可」申請而被批准之後，才能上市。同樣地，也必須經過「上市許可」之申請、審核，批准之後才能上市。 PMA之申請不需與任何市場上產品做比較，其主要是用 於證明此新產品對人體無害，且能達到預期之效果。

8 範例:醫療器材參考指引(血糖機) IEC 60068-2-64 振動測試
EN Stability testing for IVD reagents

9 品質管理系統(ISO 13485)指引架構介紹

10 品質管理系統(ISO 13485)文件架構圖 根據第13張品質管理系統(ISO 13485)指引架構將文件分成四階

11 風險管理(ISO 14971)介紹 醫療器材的安全與品質直接攸關人身安全，因此全球各國不單只是對醫療器材產品進行全面的控管與審核，亦嚴格把關整個品質管理系統，並將「 風險管理 」 納入醫療器材核可上市的關鍵程序之一。 醫療器材業者除了需符合產品安全性的各項規定外，如何藉由事前的管理系統進行風險分析、評估、控制，將影響產品危害的風險降至最低，確保產品於其生命週期內之安全性，成了當前醫療器材產業面臨的重要課題之一。

12 風險管理(ISO 14971)介紹 目前台灣衛生署公佈製造業者應於設計過程中評估風險分析的必要性，並製作且保存風險分析之執行記錄。要求組織在產品實現的整個過程中，建立風險管理文件化的要求。 國際標準 ISO 融合了相關醫療器材標準，是目前全球唯一發展進行醫療器材風險管理評估的工具。 在歐洲，ISO 已被採納為歐洲醫療器材通用標準 美國食品和藥品管理局 (FDA) 亦認可此項規範 日本也採用為日本產業標準，可預期其他各國亦將陸續將此標準納入規範當中。

13 風險管理(ISO 14971)流程

14 FMEA小組成員 職稱 參與人員資格限制 風險管理負責人 （報告稽核者）
由各部門主管、總經理或公司管理代表擔任，成員須有人熟悉最新版本風險管理標準之內容與規定 報告制定人員 （風險評估者） 由各部門資深工程人員擔任，須受過內部或外部最新版本之風險管理標準教育訓練 由公司委由專業顧問幫忙制定

15 故障機率 (Probability of Failures)
人為因素 高：平均每月發生10次以上，分數5 中：平均每月發生3 -10次，分數3 低：平均每月發生0 - 2次，分數1 產品品質因素 高：平均每一千台故障一台（故障率1000ppm），分數5 中：平均每一萬台故障一台（故障率100ppm），分數3 低：平均每十萬台故障一台（故障率10ppm），分數1

16 嚴重度 (Severity) 嚴重度係指某安全危害發生後，對客戶可能產生影響之嚴重程度，以1~5 計分： 重度：造成立即傷害，分數5
中度：長期下來會影響健康，分數3 低度：影響系統能否正常操作，分數1

17 風險優先數 ( RPN: Risk Priority Number )
發生頻率×影響度 ＞ 10 ：Non acceptable 5 ＜ 發生頻率×影響度 ＜ 10 ：as low as reasonably practicable (ALARP） 發生頻率×影響度 ＜ 5 ：Acceptable

18 Failure mode and effect analysis(失效模式效應分析 )
Risk Chart範例

19 Failure mode and effect analysis(失效模式效應分析 )
元件名 故障模式 影響 致命度評估 對策 子系統 系統 安全性 發生頻率 影響度 致命度 血糖監控模組 血糖值計算錯誤(偏高) Pump持續動作 Insulin傳送 過量 造成患者血糖過低而昏迷,嚴重者造成死亡 4 10 40 設定血糖監測器自我診斷功能，每小時至少執行一次 設定blood glucose sensor異常警報 傳送系統模組 Insulin累計值計算錯誤(偏低) Insulin過量 2 20 設定pump診斷功能，每小時至少執行四次檢查 設定pump異常狀況之警報 設定insulin最大劑量，及最大累積劑量

20 醫療電氣安規測試標準 醫療電氣設備測試標準 測試標準項目說明 醫電設備- EMC電磁相容性規定 醫電設備-一般安全規定
IEC Medical electrical equipment - Part 1-2 : General requirements for safety - Section 2: Collateral standard: Electromagnetic compatibility - Requirements and tests. 醫電設備- EMC電磁相容性規定 IEC 61326 Electrical Requirement for measurement , control and laboratory use-EMC requirements IEC Medical Electrical Equipment Part 1: General Requirements for Safety. 醫電設備-一般安全規定 IEC Safety requirements for electrical equipment for measurement, control and laboratory use Part 1: General Requirements. IEC Safety requirements for electrical equipment for measurement, control and laboratory use. Part2-101:Particular requirements for IVD Medical equipment.

21 EN 376(Information supplied by the manufacturer with in vitro diagnos reagents for self-testing ) 介紹
外部包裝 提醒使用者要詳細閱讀說明書以及包裝上的文字。 使用的語言必須是官方的、通用的語言。

22 EN 376(Information supplied by the manufacturer with in vitro diagnos reagents for self-testing ) 介紹
內部包裝 製造商、產品名稱、到期日期、內容物及數據、預期的效果、目的、可操作的範圍：溫度、電量、血液量、預防錯誤及危險的警告標示…等 以羅氏優勝血糖機為例

23 EN 592(Instructions for use for in vitro diagnostic instruments for self-testing )介紹
使用說明的內容 操作元件的概述 流程方塊圖 說明文字及內容的配置，排版 預期用途及事實都必須被清楚說明表示 圖形提示跟警示 範例(列出可能提供的教學相關訊息 )

24 EN 980 (Labeling of Medical Devices)介紹
批次編碼 勿重複使用 使用期限 製造商 序號

25 軟體開發生命週期 使用者需求 使用者：我需要什麼 確認 理解 需求規格書 產品 分析者：我提供什麼 設備/電腦：執行結果 設計規格書
設計者：我要讓軟體做什麼 原始程式 軟體工程師：我要寫什麼

26 軟體測試的迷思 由於大多數企業缺乏軟體測試與實踐之知識，所以對軟體測試工作容易有以下幾點誤解 軟體品質有問題，全部是軟體工程師的錯
文件化過程太浪費時間，口頭說說就好 軟體測試技術要求不高，隨便找一個人就能做 等到產品開發最後階段才進行測試

27 關於軟體測試 依據過去經驗每千行程式碼大約有60個缺陷，2/3缺陷在需求與設計階段，在這個階段發現問題的修正費用最少，如果到系統測試才發現，要花10倍以上經費，若到產品驗收時期，則需花費100倍以上 美國國防部要求每千行0.01以下的錯誤，電信/銀行之系統平均每千行0.05個錯誤，一般企業軟體為每千行0.5個錯誤 修正bug的代價 產品開發生命週期 需求 程式 設計 測試 單元 測試 系統 測試 整合 測試 驗收

28 軟體測試人員 Vs 軟體開發人員 測試需要花費龐大的人力、物力與時間 微軟為例
2000年全球52,000員工，10,000開發人員，15,000測試人員 測試費用佔60% Exchange研發：開發人員140人，測試人員350人 Windows 2000研發：開發人員1,700人，測試人員3,200人 IE4產品研發：開發時間6個月，測試時間8個月 測試需要花費龐大的人力、物力與時間

29 何謂軟體驗證 軟體驗證是透過產品發展生命週期活動來評估軟體產品品質的嚴謹方法
軟體驗證的工作將努力確保品質被導入軟體產品之中，並讓軟體滿足所需達到的功能與使用者之需求 軟體驗證的工作將包括產品與發展程序之分析、評估、審核、檢視、測試等 實務運作必須將軟體工程(Software Engineering )與品質管理系統相結合

30 Verification and Validation
保證軟體產品可以正確實現某一功能 軟體開發生命周期中每個階段的正確性與完備性 Are we building the product right? 我們是否正確地開發了產品 確認(Validation) 保證軟體符合功能需求 需求規格的確認，軟體邏輯性的確認 Are we building the right product 我們是否開發了正確的產品

31 Verification and Validation

32 目前業界現況探討 部份業者已經被美國FDA及國外客戶要求提供軟體確效報告，但對如何進行完全沒有概念。
管理階層並未體認到落實軟體確效之重要性，故絕大多數業者未建立系統化之管理方式。 大部分之業者均不清楚軟體開發時應管制哪些技術文件，僅知道最後功能測試O.K! 絕大多數之軟體僅進行正常功能之確認測試，甚少探討可預見之異常操作，且測試者通常即為軟體開發人員本身，無法抓出潛在之軟體異常問題(潛在的龐大成本支出)

33 美國FDA軟體驗證發展沿革 1989年FDA公佈電腦軟體之法規政策“FDA Policy For the Regulation of Computer Product” 1991年FDA公佈電腦控制之醫療器材510(K)申請審查指引“ Reviewer Guidance for Computer Controlled Medical Devices Undergoing 510(k) Review ” 1997年六月，美國醫療器材新版品質系統規範（QSR）正式生效，同時FDA要求醫療器材需經過軟體驗證

34 FDA軟體驗證發展沿革 1997年6月，FDA公佈軟體驗證之一般原則草案“ General Principles of Software Validation ”，並於2002年1月11日公佈正式版 軟體為醫療器材之一部分 軟體本身為醫療器材（例如：醫學圖像紀錄傳輸系統：PACS） 使用軟體來製造醫療器材（例如：製造設備之可程式邏輯控制器） 使用軟體來執行品質系統（例如：紀錄與維持器材歷史紀錄之軟體）

35 FDA軟體驗證發展沿革 FDA於1997年公佈醫療器材使用市售軟體指引“Guidance for Off-the-Shelf Software Use in Medical Devices”，並於1999年公佈正式版 FDA於1998年公告包含軟體之醫療器材上市前申請案指引“ Guidance for the Content of the Premarket Submissions for Software Contained in Medical Devices ”並於2005年改版 生命週期活動（Life Cycle Activities） 影響等級（Level of Concern） 風險管理（Risk Management） 軟體驗證、確認與測試（SVV＆T)

36 FDA要求應檢附之軟體技術文件 Level of Concern(醫療設備層級) ：說明醫療設備對於安全層級方面的定義與基本的判定方法
Software Description(軟體描述) ：醫療設備軟體的概要說明 Device Hazard Analysis(醫療設備危險分析) ：說明醫療裝置可能因故障而發生各種危險之分析 Software Requirements Specification(軟體需求規格) ：說明該軟體須實現及限制方面等需求 Architecture Design Chart(架構設計圖) ：以圖表等方式，說明醫療設備軟硬體架構、系統流程、功能與軟體模組等。 Software Design Specification(軟體設計規格)：實現軟體需求之設計

37 FDA要求應檢附之軟體技術文件 Traceability Analysis(可溯性分析)：將設計、測試、危險分析連結在一起，有助於內容的連貫性，提升檢視文件效率 Software Development Environment Description (軟體開發環境描述)：指軟體開發的專案策略與管理等之說明 Verification and Validation Documentation(確認與驗證文件)：說明在產品的開發過程中，需要確認與驗證的工作，以確保產品符合規格與客戶之需求 Revision Level History(校訂版本歷史紀錄)：記錄產品發展的過程中，軟體修正的歷史 Unresolved Anomalies(未解決異常記錄) 記錄軟體未解決的異常情況

38 Level of Concerns 評估一項裝置可能會直接或間接讓病人或操作者遭受傷害的嚴重性。分為Major, Moderate與Minor三種levels Major Level 一次的故障或潛在因素，直接造成病人或操作者的死亡或嚴重傷害 間接性造成病人或操作者的死亡或嚴重傷害亦同。如不正確/延遲的資訊、或者是經由照護者的行為造成 Moderate Level 一次的故障或潛在因素，直接造成病人或操作者的較小傷害 間接性造成病人或操作者的較小傷害亦同。如不正確/延遲的資訊、或者是經由照護者的行為造成 Minor Level 指故障或潛在因素，不會造成病人或操作者任何傷害

39 軟體影響等級判斷法則 用以控制維生系統？ 用以控制危險能源之傳遞？ 用以控制處方之傳遞？ 用以提供診斷資訊作為處置或治療之參考？
是 用以控制維生系統？ 否 是 用以控制危險能源之傳遞？ 否 是 用以控制處方之傳遞？ 否 是 用以提供診斷資訊作為處置或治療之參考？ 否 是 用以提供生理監視訊號？ 否 Minor 否 失效是否會造成死亡或嚴重傷害？ 否 失效是否會造成非嚴重傷害？ 是 Moderate 是 Major

40 軟體 審查文件 Minor Moderate Major 影響等級 軟體描述 風險分析 軟體需求規格 軟體設計架構 設計規格 可追溯性分析
都需要 軟體描述 風險分析 軟體需求規格 軟體功能之描述 所有軟體需求與詳細規格 軟體設計架構 描述軟體系統與次系 統之架構圖 描述軟體系統與次系統之架構圖 ，以及功能模組符合 軟體需求規格之說明 設計規格 不需要 軟體設計規格書 可追溯性分析 軟體需求 、風險之鑑別與驗證 、確認及測試之間的可 追溯性記錄 軟體開發 軟體生命週期的開發 計畫書 ，包括型態管 理和軟體維護活動的 概要 。 軟體生命週期的開發計畫書 ， 開發過程中產出的管制文件及 索引 ，包括型態管理和軟體維 護計畫書 確認 、驗證及測驗 軟體功能測試計畫 書 ，通過 / 失敗的判定 準則與測試結果 單元 、整合和系統 VV &T 活動的描述 。系 統測試計畫包括通過 失敗的判定準則和 測驗結 VV &T 活 動的描述 測試計畫包括通過 失敗的判 定準則 、測試報告概要和測驗 結果 修訂記錄 修訂之歷史記錄 軟體未解決的錯 誤 （ BUGS ） 器材未解決之軟體錯誤項目說明 ，並依據操作原理與 人因工程說明這些項目不對安全性與功效性造成影 響之依據 發行版本與序號 發 行版本 、序號 ，以及發行日期等記錄

41 Software Description(軟體描述)
設備內軟體控制要點 軟體在醫療器材中扮演的角色 軟體可以做或做不到的事 軟體如何與使用者溝通(介面) 軟體可被使用者控制或修改的功能 軟體主要特色說明，如功能、性能、方法、優點、新穎等方面的特色作要點概述 軟硬體平台概述，如開發語言、硬體平台與作業系統

42 Device Hazard Analysis (醫療設備危險分析)
進行危險分析時，須找出所有可預見的危險，包括有意圖或者不小心誤用設備的結果。 內容應該包含 Identification of the hazardous event (危險情況之鑑定) Severity of the hazard (危險的嚴重性) Causes of the hazard (危險造成的後果) Method of control (控制或解決方法) Corrective measures taken (改善措施)  包含對於device的設計/實作、排除/減少/警告危險情況方面的解說 Verification (確認)  確認method of control被正確無誤地實行

43 Failure mode and effect analysis(失效模式效應分析 )
元件名 故障模式 影響 致命度評估 對策 子系統 系統 安全性 發生頻率 影響度 致命度 血糖監控模組 血糖值計算錯誤(偏高) Pump持續動作 Insulin傳送 過量 造成患者血糖過低而昏迷,嚴重者造成死亡 4 10 40 設定血糖監測器自我診斷功能，每小時至少執行一次 設定blood glucose sensor異常警報 傳送系統模組 Insulin累計值計算錯誤(偏低) Insulin過量 2 20 設定pump診斷功能，每小時至少執行四次檢查 設定pump異常狀況之警報 設定insulin最大劑量，及最大累積劑量

44 Failure mode and effect analysis(失效模式效應分析 )
故障模式發生頻率評分表範例 影響度評分表範例 等級 發生頻率 10 發生機率極高 8 發生頻率高 6 偶而發生 4 發生機會不高 2 發生機率極低 1 幾乎不可能發生 等級 影響度 10 造成死亡 8 造成人體機能永久性傷害 6 造成人體機能嚴重傷害 4 造成人體輕度傷害 2 造成人體輕微反應 1 對人體無影響

45 Failure mode and effect analysis(失效模式效應分析 )
Risk Chart範例

46 Software Requirements Specification(軟體需求規格)
說明該軟體應該要滿足的需求，包含功能、效能、介面、設計、開發與其他方面的需求  描述該軟體設備應該要做些什麼 對於Minor Level的軟體設備，只要提供從SRS擷取功能需求的摘要即可，包括現成軟體的鑑定；對於Moderate與Major Level則必須要提供完整的SRS文件 Software Requirement Specification普遍要求內容包含(ISO12207) 標的軟體系統摘述 定義與縮寫符號 系統功能目的 系統用戶種類特性 功能需求 非功能需求：以條列方式說明軟體運作及發展過程有何限制條件，如溫度限制、供應電壓、反應時間、資料安全等。 界面需求

47 Architecture Design Chart (架構設計圖)
使用流程圖或者是簡單的描述在軟體設備中數個主要功能單元之間的關係，包含與硬體的關係以及data flows 不一定要將每個function call以及module都寫入文件當中，只需要足夠的資訊讓review時能將軟體的架構與功能、軟體設備用途之間的關係串接起來即可 對於Moderate與Major Level的軟體設備須細部地描述功能單元與軟體模組，包含state diagram與flow charts，可以清楚地描述軟體功能單元之間的關係 若當中有參考其他文件則需要註明參考文獻及出處

48 Software Design Specification(軟體設計規格)
SRS與SDS之間的關係：SRS  描述軟體設備將可以作些什麼；SDS  這些對於軟體設備的需求，要如何被實作出來 內容的呈現必須要充分，確保軟體工程師開發軟體設備時，可以清楚了解並使用最少的設計決策實作 設計方法與工具 組織架構 系統流程 軟體元件規格 界面設計規格 資料結構設計規格

49 Traceability Analysis(可溯性分析)
設計需求 對應之設計規格 對應之V&V測試 對應之危險防治 SAS004 SDS101 V&V200 FMEA002

50 Software Development Environment Description (軟體開發環境描述)
軟體發展：軟體發展生命週期計畫之摘要，軟體發展生命週期如Water fall模式、V型模式、螺旋模式等，訂定流程與時程計畫 軟體專案品質管理 專案管理計畫：說明對於整體專案的管理方式，如時程規劃(可使用甘特圖表示)、人力資源、管理流程/策略、check point(管制點)等 軟體測試計畫：說明軟體測試計畫，以確認其符合規格及客戶需求 建構與維護管理計畫 ：說明如何管理相關系統標準與文件，並記錄軟體系統發展之改變狀況、各元件間之相互關係，以及評估、追蹤、記錄軟體元件之改變，區分不同版本之演變。

51 Verification and Validation Documentation (確認與驗證文件)
使用列表的方式，摘要說明如何針對單元/整合/系統三種levels進行V&V之相關測試，該測試須與危險分析相互對照。 報告內容 測試項目編號 軟體版本 測試人員、檢視人員 測試項目名稱、測試目的、設備與使用工具 測試方法、輸入規格、輸出規格、環境需求 測試通過標準、測試步驟描述、測試結果

52 軟體測試層級 驗收測試 目的：是否滿足使用者需求 測試定義：判斷測試結果使否滿足客戶的需求 系統測試
目的：確認軟體為完整的實體，能夠與操作需求配合 測試定義：測試整個硬體與軟體的完整性 整合測試 測試目的：確定滿足設計的目標 (高層程式設計) 測試定義：硬體與軟體元件的整合測試 單元測試 目的：確認程式邏輯的完整性與正確性，確定元件的運作符合設計的要求 測式定義：檢查軟體元素的設計實作

53 測試流程 測試計劃 (test plans) 測試的範圍、方式、資源與排程 測試設計 (test design) 設想要測試的功能與方式
要能夠完成回歸測試(regression test) 測試案例 (test cases) 執行最精簡的測試案例 測試程序 (test procedure) 測試系統之執行步驟 測試執行 (test execution) 從元件測試開始，然後進入整合、系統與驗收測試 測試報告 (test report) 摘要所有測試結果

54 軟體測試的分類方法 黑箱測試：注重功能測試 白箱測試：著重結構測試 靜態：不用執行軟體 動態 決策表格架構測試 因果圖 靜態 規格證明
動態：使用測試資料進行測試 測試邊界 結構測試 (路徑涵蓋) 靜態：不用執行軟體 程式證明 異常分析

55 Revision Level History(校訂版本歷史紀錄)
內容須包含產品發展過程中，軟體修正的歷史 可利用條列式表格的方式呈現發展週期中軟體更改的主要內容，包含日期、版本編號，以及簡短描述此版本的更動與前一版本之間的關係 修訂編號 修改日期 軟體版本 主要更改內容 與前一版本之關係

56 Unresolved Anomalies(未解決異常記錄)
對於Moderate與Major Level的軟體設備，內容應包含全部未解決的軟體異常列表，對於每項異常需要說明以下幾點 Problem (問題所在) Impact on device performance (對於device效能的影響) Any plans or timeframes for collecting the problem (解決問題計畫或時程範圍)

57 FDA要求應檢附之軟體技術文件(範例說明)
Level of Concern(醫療設備層級) ：說明醫療設備對於安全層級方面的定義與基本的判定方法 Software Description(軟體描述) ：醫療設備軟體的概要說明 Device Hazard Analysis(醫療設備危險分析) ：說明醫療裝置可能因故障而發生各種危險之分析 Software Requirements Specification(軟體需求規格) ：說明該軟體須實現及限制方面等需求 Architecture Design Chart(架構設計圖) ：以圖表等方式，說明醫療設備軟硬體架構、系統流程、功能與軟體模組等。 Software Design Specification(軟體設計規格)：實現軟體需求之設計

58 FDA要求應檢附之軟體技術文件(範例說明)
Traceability Analysis(可溯性分析)：將設計、測試、危險分析連結在一起，有助於內容的連貫性，提升檢視文件效率 Software Development Environment Description (軟體開發環境描述)：指軟體開發的專案策略與管理等之說明 Verification and Validation Documentation(確認與驗證文件)：說明在產品的開發過程中，需要確認與驗證的工作，以確保產品符合規格與客戶之需求 Revision Level History(校訂版本歷史紀錄)：記錄產品發展的過程中，軟體修正的歷史 Unresolved Anomalies(未解決異常記錄) 記錄軟體未解決的異常情況

59 IEC 軟體發展過程與活動概要

60 IEC 軟體維護過程與活動概要

61 軟體測試與驗證項目

62 軟體缺陷分類屬性 缺陷嚴重度 (Severity) ：對軟體的嚴重程度 優先順序(Priority)：緊急修復順序
缺陷狀態(Status)：處裡狀況 缺陷起源(Origin) ：事件如何被發現 缺陷來源(Source) ：缺陷的起因 缺陷根源(Root Cause) ：根本因素

63 測試模型 – V Model 需求分析、軟體設計、程式開發等步驟隨時間依序進行，而測試的順序正好相反 使用者 驗收測試 需求分析 系統測試
使用者 驗收測試 需求分析 系統測試 軟體設計規格 整合測試 程式開發 單元測試

64 測試模型 – W Model 修正V model兩個缺點 測試是軟體開發後期的工作 要測試的對象只有軟體 伴隨開發週期同步進行測試 需求
需求測試 安裝 驗收測試 系統功能 功能 系統測試 功能測試 設計 設計測試 元件組合 整合測試 程式開發 單元測試

65 測試模型 – H Model W模式將測試視為一個獨立的活動問題，H模式則將測試視為一個系統流程 測試活動貫穿整個產品週期
測試活動可以依序先後執行，但也可能反覆的執行 測試點 測試執行 測試準備 其他活動 循序測試

66 軟體測試指引 判斷何時停止測試 清楚了解使用者需求、操作流程、系統設計與元件介面等規格 指定測試者測試的責任 描述每種測試情況的預期結果
避免無法重複產生,或是無規律的測試 寫出有效與無效輸入條件的測試案例(test case) 進行測試

67 軟體測試的分類方法 動態：使用測試資料進行測試 動態 靜態：不用執行軟體 靜態 白箱測試：著重結構測試 黑箱測試：注重功能測試 測試邊界
結構測試 (路徑涵蓋) 靜態：不用執行軟體 程式證明 異常分析 黑箱測試：注重功能測試 動態 決策表格架構測試 因果圖 靜態 規格證明

68 窮舉測試 窮舉測試定義：將所有可能的輸入資料全部拿來做測試，或是覆蓋所有程式可能執行的路徑 測試範例將是天文數字
說明：假設一個軟體有兩個輸入、一個輸出。如果兩個輸入為32位元的整數，利用窮舉法共有232 *232 = 264情況，如果測試一次需要1毫秒，共需5億年 輸入 1 待測軟體 輸出 輸入 2

69 靜態分析 靜態分析：不實際執行程式，而是透過檢查與閱讀等方式來發現錯誤的軟體測試技術，以及評估是否確實依照規劃執行邏輯順序 方式
Walk Through (快速閱讀)：經驗豐富的開發人員，經由開發者的解釋，檢視軟體的邏輯錯誤、程式碼規範，將人腦充當電腦 Inspection (檢閱)：以會議形式進行，明定會議目標、流程與規定、採用check list方式進行錯誤檢視 Review(複審)：比inspection更嚴謹，第一步提供相關文件，以及常見錯誤清單。第二步召開審查會議，開發者透過講解發現程式中的錯誤。

70 測試範例 測試範例定義：由一對滿足測試情境的輸入/輸出資料所組成，透過這個資料範例，可以執行某個層面的軟體測試 測試範例隨測試方法不同而不同
軟體中的錯誤很多，考量時間與經費不可能全部修正，所以應該對使用者容易發生的錯誤進行測試 測試範例是為了提高有效的測試比率 軟體總体錯誤 使用者易遇到錯誤 優先測試與排除

71 常用的黑箱測試方法 -決策表格 1 基本原理：這種測試特別適用於軟體需求是以”if – then”為敘述的系統架構 …
條件 基本原理：這種測試特別適用於軟體需求是以”if – then”為敘述的系統架構 例如： if cond(1) then action(A) else action(B) 決策表：包含了所有測試情況的欄位，上半部為必須滿足的條件，下半部為產生動作 缺點：分開考慮所有輸入內容，會出現一些沒有必要的組合 條件1 1 … 條件2 條件3 條件4 條件5 條件N 條件N+1 動作 動作1 動作2 動作3 動作4 動作5

72 常用的黑箱測試方法 –因果圖 指定輸入(因)與輸出(果)的組合，圖形包含了相互有關係的結點，用以表示邏輯關係
因果圖在刪除沒有關係的輸入點後，可以產生一個精簡的決策表 符號 利用”C”表示原因、以”E”表示結果 例如有四個原因C1、C2、C3、C4，但E1僅與C2、C3、C4有關，則可以畫出以下因果圖 C2 C3 And E1 C4

73 常用的白箱測試 – 路徑覆蓋 路徑覆蓋測試就是設計足夠的案例，覆蓋程式中所有可能的路徑，真實世界很難做到，必須將路徑數目壓到一定限度
路徑覆蓋的複雜度 N+1 < 路徑數目 < 2n

74

75 路徑覆蓋

76 常用的白箱測試 – 邊界值測試 從經驗得知，錯誤常發生在輸入或是輸出範圍的邊界上，因此利用邊界值的測試，可以找到更多的錯誤。
邊界值測試是白箱測試一個有效的方法 例如三角型三邊(A、B、C)，兩邊和大於第三邊，如果在邊界值出現” A+B=C “，就出現錯誤 方法： 確定邊界值 測試值的選取：等於、略小於、略大於邊界值 如果輸入條件規定了參數個數，則用最大參數個數、最小參數個數、最大參數個數加1、最小參數個數-1 如果測試資料為一集合，測試時選擇集合中第一個與最後一個作為測試範例

77 單元測試 單元測試是對軟體基本組成單元進行測試，可以是一個函式、功能等具有基本屬性之”單元”
重點在於發現程式實作的邏輯錯誤，也就是要發現程式模組內部的各種錯誤 單元測試不僅要白箱測試，同時也要有黑箱測試 單元測試必須是可重複的，因為程式碼修改、升級與維護都需要反覆執行 單元測試與撰寫程式所花的時間與精力大致相同。雖然會花費不少時間與成本，但卻對整個產品的測試有重大意義，因為bug越晚發現，所有修正的成本越高

78 單元測試的內容 測試者要依據詳細的設計規格書，了解模組的IO條件和邏輯架構，主要採用白箱測試，黑箱測試之案例為輔，使之對於合理與不合理之輸入都能鑑別與回應 測試內容 模組介面：檢查進出模組的資料是否正確 區域資料結構測試：檢查資料結構是否保持完整性 執行路徑測試：檢查計算錯誤、判斷錯誤、流程控制錯誤產生的程式錯誤 錯誤處理測試：內部錯誤處理是否有效 邊界測試：檢查臨界資料是否正確

79 單元測試內容 - 模組介面 參數的數入個數、型態、順序 所測的模組，如果有呼叫到其他子模組，需測試這些參數是否匹配
是否修改到僅作為輸入用的參數 輸出的參數個數、型態、順序是否正確 全域變數的定義在各模組間是否一致

80 單元測試內容 -區域資料結構測試 檢查不一致或不正確的資料類型 使用尚未初始化的變數 錯誤的初始值或是預設值 變數名稱拼寫錯誤
檢查不一致的說明資料

81 單元測試內容 -執行路徑測試 運算的優先順序不正確 物件的資料型態彼此不相容 演算法錯誤 運算精度不夠 運算符號表示錯誤，邏輯符號表示不正確
“差1的錯誤”，迴圈數少一次，或是多一次 錯誤或不可能的終止迴圈 不小心修改迴圈的變數

82 單元測試內容 -錯誤處理測試 出錯的描述不足以對錯誤定位和確定錯誤的原因 顯示的錯誤與實際的錯誤不符 對錯誤的處理不當
在錯誤處理之前，錯誤已經引起其他系統單元的錯誤

83 單元測試內容 –邊界測試 在n次迴圈中測試第0次,第1次,第n-1次,第n次,第n+1次 邏輯判斷中取條件的最大或是最小值是否有錯誤
資料流程中在等於、小於、大於這些比較值條件下執行是否正確

84 單元測試的環境 在單元測試時，如果該測試模組不是獨立完整的程式，需要兩個輔助的模組
驅動模組(Driver)：接收資料後轉傳給測試單元，再接收輸出結果 樁模組(stub)：代替測試單元所呼叫的子模組 測試案例 Driver 測試結果 被測試單元 Stub Stub Stub

85 單元測試實施步驟與文件 測試計劃：針對測試目標，規定測試範圍、環境、人員分工與時間表
測試設計：根據測試計劃，設計測試範例包括測試步驟、測試場景、測試程式與資料、預期結果 測試執行：執行測試設計 測試記錄：記錄執行過程與結果 缺陷追蹤：記錄、評估與分發缺陷報告 測試結果：評估最後的測試品質與效果 測試計劃 (測試計畫文件) 測試設計 (測試範例文件) 測試執行 測試記錄 (測試記錄文件) 缺陷追蹤 (缺陷追蹤報告) 分析 測試結果 (測試總結報告)

86 單元測試文件範例 測試單元名稱 完成測試日期 測試摘要 測試目的 測試範圍 測試類型 測試環境 被測元件原始程式碼位置 範例編號
測試計劃基本資料 測試單元名稱 完成測試日期 測試摘要 測試目的 測試範圍 測試類型 測試環境 被測元件原始程式碼位置 測試範例 範例編號 範例情境描述 測試步驟 測試資料說明 期望輸出結果 測試記錄 測試人員 測試時間 測試內容：如路徑測試、介面測試、宣告測試..等 使用測試範例編號 輸出結果 測試觀察符不符合期望結果 缺陷追蹤報告 嚴重程度 錯誤詳細描述與重現方式 建議修改方式 修改人員與修正時間 執行狀況：提交、複審、修改中、修正完畢 測試總結 缺陷統計 是否通過單元測試

87 整合測試 整合測試：依照設計規格，對所有需要組裝的單元模組進行整合測試，又稱為組裝測試或是聯合測試 測試考量
模組組裝時，穿越模組介面的資料是否正確 每個功能組裝起來後，會不會造成另一個模組不良的結果 各個子模組整合起來，是否達成總體功能要求 全域變數是否有問題 單個模組的錯誤是否有累積的效應

88 整合測試與單元測試關聯與區別 整合測試對象是模組間的整合關係，找出與軟體設計相關的程式結構、模組呼叫關係、模組介面方面的問題
單元測試主要是模組內部的白箱測試 整合測試以程式結構測試為主，發現軟體與系統定義不符合或是與之矛盾的地方，測試方式結合黑箱與白箱測試，但以黑箱測試為主

89 整合測試步驟 首先確定子系統有哪些模組，保證這些模組都通過單元測試 主要依據”軟體設計說明書”
由開發人員組裝這些模組，生成一個子系統，並保證各模組都能正常發揮功能 設計測試範例，以一個關鍵模組為核心展開測試。測試重點以功能與性能為主軸 擬定測試計劃：進度安排、測試範例、人員分配 搭建必要的測試環境，按照所寫的測試範例，進行測試 記錄測試結果 問題記錄、問題解決追蹤報告、測試總結

90 整合測試系統建置方式 一次性整合方式：又稱整體組裝，首先將每個模組分別進行模組測試，然後再把所有模組裝在一起，達成所要的測試。
缺點：實務上一次整合成功的機會不大，即便發現錯誤，有時很難判定出問題的模組為何 由上而下的增殖方式：將模組沿控制層次由上而下進行整合 優點：較早驗證了主要控制流程與邏輯判斷點 缺點：需要模擬一些Stub，這點在實務上很困難 由下而上的增殖方式：從程式最底層模組開始組裝，意即先完成子模組，好處是不需要開發模擬的stub 優點：一些複雜的IO以及演算法都是底層模組，可以優先找出這部份的問題 缺點：程式一直沒有實際的主體，直到最後一個模組加上去才形成實體。對主要的控制流程最後才接觸到

91 由上而下的增值方式示意圖 A A A Stub C Stub C B C Stub B B 步驟一：加入A 步驟二：加入B D Stub D
期望測試 A A Stub C B B C D D 步驟三：加入D 步驟四：加入C

92 混合增殖式測試 目的：整合”由上而下增殖方式”與”由下而上的增殖方式”兩方法的優點 常見的方式
衍變的由上而下的增殖方式：加強對IO模組以及重要演算法模組之測試，並由下而上整合功能完整且獨立的子系統，然後由主模組開始由上而下進行增殖測試 由上而下 & 由下而上增殖測試：首先對資料”讀取”這部份子系統由下而上進行模組整合測試，然後再對資料”寫入”的子系統做由上而下的整合測試

93 整合測試之關鍵模組 測試者需確定關鍵性模組，對這些模組及早進行測試 關鍵性模組的特徵 明確定義為軟體功能需求
在程式結構中屬於類似控制模組這種較高層次的模組 較複雜易發生錯誤的模組

94 系統測試 主要目的驗證整體系統是否滿足當初所擬之系統需求規格之定義 整個測試的範圍除了軟體外，還包括硬體、資料、操作人員和其他支援軟體
以黑箱測試為主 規格測試、輸入/輸出測試、功能測試

95 系統測試與單元、整合測試區別 測試方法：系統測試完全以黑箱測試為主
測試範圍：單元測試主要測試模組內的介面、資料結構與邏輯等。整合測試主要測試模組之間的介面與異常。系統測試主要測試系統是否滿足使用者的需求 評估基準不同：系統測試主要評估基準是測試範例對需求規格的覆蓋率，單元與整合測試主要的評估是程式碼的覆蓋率

96 系統測試的內容 (I) 功能測試： 對於產品功能進行測試，驗證符合需求規格書 效能測試 驗收系統的整體效能是否達成目標，一般與負載測試結合
在大量資料、大量存取情況下，評量系統的效能與功能穩定度 壓力測試 在人為資源緊缺的環境下(如CPU佔用、記憶體減少、網路頻寬限制)，檢查系統是否會發生問題 疲勞測試 連續保持長時間的測試，檢查系統是否會出現問題 易用性測試 操作介面是否簡易、操作流程是否一致性 安裝測試 檢查安裝時是否正確安裝所有檔案，是否會破壞其他檔案 配置測試 在不同環境下(如作業系統、軟體環境)，驗證系統的功能 文件測試 文件是否齊全，內容格式是否一致

97 系統測試的內容 (II) 安全測試 檢查系統是否有病毒，系統資料是否正確加密，並具有權限管理機制 恢復測試
系統發生災難時，檢查系統是否能夠回復破壞的資料與環境 回歸測試 當系統更新部份程式碼時，是否會引入新的錯誤或者舊的錯誤重新出現 演練測試 交付使用者之前，利用相似的環境進行測試 Back-to-back測試 設置一組測試，在不告知任何事情的狀況下，獨立進行測試，用來評估測試團隊的效果 度量測試 人為放入錯誤，並根據被發現的比例來確定遺留的錯誤數量 比較測試 與競爭產品或是舊版產品做比較，來確定系統的優勢與劣勢

98 系統測試活動過程 活動名稱 輸入 輸出 制定系統測試計劃 軟體需求文件 軟體專案計畫 系統測試計畫 設計系統測試 軟體需求 系統測試範例
系統測試過程 實施系統測試 系統測試腳本 執行系統測試 測試結果 評估系統測試 分析報告 修改變更請求

99 軟體測試是一個藝術與工程的結合 20世紀60年代開始有測試任務，80年代開始有測試職業，90年代開始有測試科學，21世紀開始有測試專業
測試的目標是發現問題 測試在理論與方法都不是很成熟，效果取決於測試資源、團隊能力，所以說軟體測試是一場戰爭

100 軟體測試的改進方法 外聘更多的測試人員 將原有開發人員轉任為專責的測試人員 加強所有人對於軟體測試的專業知識 購買或自行開發軟體測試工具
將測試工作外包

101 Thanks For Your Attention
長庚大學資訊工程系 林仲志 (03)