1、醫療器械軟件描述文檔1. 基本信息1.1. 產品標識軟件名稱：軟件型號：軟件版本號： 軟件制造商：軟件生產地址： 1.2. 安全性級別軟件的安全性級別為A/B/C軟件安全性級別（YY/T 0664-2008）基于醫療器械軟件損害嚴重度分為：A級：不可能對健康有傷害和損壞；B級：可能有不嚴重的傷害；C級：可能死亡或嚴重傷害。對于B級和C級的醫療器械軟件，軟件描述文檔的部分內容應提供原始文件。級。理由如下：a) 軟件的預期用途為：b) 軟件的功能包括：c) 如果軟件失效，可能導致以下后果（按軟件各功能失效逐條描述，如果軟件失效的時候由硬件降低失效后果或危害發生概率，可以做說明，并由此降低安全性級別

2、本段填寫內容，舉例：以一般超聲產品的安全判定為例。B級，超聲存在間接傷害的風險，若所提供圖象不準確，有誤診的風險）：1） 2） 3） 1.3. 結構功能1.3.1. 組成模塊、各模塊功能及模塊相互關系依據軟件設計規格給出體系結構圖圖示醫療器械軟件組成模塊之間、組成模塊與外部接口之間的關系（如圖1.3-1所示）。嵌入式軟件（SDS）體系結構圖示例1獨立式軟件（SDS）體系結構圖示例2圖1.3-1 XXX體系結構圖1.3.2 各模塊功能說明 系統主要由XXXXXX模塊組成。各模塊功能簡介如下：產品名稱版本號模塊名稱軟件功能項目功能說明一級功能二級功能三級功能模塊名稱軟件功能項目功能說明一級功能二級

3、功能三級功能注：1、每個軟件模塊一份表單。 2、軟件功能項目列表需列出與測試相關的所有功能（包括各級子功能）。 3、功能說明欄目應填寫：功能項目概述、邊界值規定（數據有效性）、安全說明等信息。 4、功能列表上所列出來的功能必須是可以實現或演示的。 5、功能名稱與軟件、文檔保持一致。 6、軟件功能項目列表根據需要列出（可增加或刪減子功能列）。1.3.2. 用戶界面設計 采用廣泛應用的圖形用戶界面（GUI），即諸如窗口、菜單、對話框、滾動條等。用戶主界面見圖1.3-2。圖1.3-2 XXX用戶主界面1.3.3. 外部接口 XXX可使用VISUAL C+ 提供的對 SQL SERVER 的接口，進行

4、對數據庫的所有訪問。 XXX可使用SQL SERVER 的對數據庫的備分命令，以做到對數據的保存。 在網絡軟件接口方面，使用一種無差錯的傳輸協議，采用滑動窗口方式對數據進行網絡傳輸及接收。1.4. 硬件關系依據軟件設計規格（SDS）給出物理拓撲圖，圖示醫療器械軟件、通用計算機、醫療器械硬件相互之間的物理連接關系。依據物理拓撲圖描述醫療器械軟件（或組成模塊）與通用計算機、醫療器械硬件的物理連接關系。1.4.1. 物理拓撲圖嵌入式軟件物理拓撲關系表格形式示例1硬件軟件分類零件種類功能顯示部分血壓顯示7工具LED血壓值顯示最高血壓最低血壓、脈拍表示時刻顯示7工具LED時刻顯示顯示現在時刻壓力單位顯示

5、LED mmHg / kPa 顯示顯示血壓值以及壓力值的單位開關部分開始/關閉開關開始/關閉開關讀取控制開始測量血壓測量時停止測量背面功能設定開關背面功能設定開關讀取控制時刻的設定等、主機功能設定的更改打印部分打印切紙打印控制測量結果的打印、打印后切紙血壓測量部分泵、電磁閥、壓力傳感器血壓測定控制測量時加壓、減壓控制、脈搏信號處理以及測量值的確定安全監視用壓力傳感器壓力安全檢測控制壓力監測、急排控制袖帶驅動部分袖帶驅動用馬達袖帶控制袖帶的卷曲、固定、開放語音部分揚聲器語音控制測量通知外部進出力部串行通信串行進出力測量結果出力、指令輸入記憶存儲U盤設定值記憶存儲控制功能設定內容的保持嵌入式軟件物

6、理拓撲關系表格形式示例2獨立式軟件物理拓撲關系表格形式示例3圖1.4-1物理拓撲圖1.4.2. 連接關系描述依據軟件設計規格圖示軟件、PC、醫療器械硬件之間的物理連接關系。并進行注釋。獨立軟件：應說明PC的類型和功能，如需與醫療器械硬件聯合使用（數據型）應說明 硬件的名稱、型號、規格和制造商。如：刺激器、打印機、腳踏開關等。軟件組件：說明醫療器械硬件的名稱、規格和型號，如需與PC聯合使用（控制型）應說PC的類型和功能。與PC連接與醫療器械硬件連接1.5. 運行環境1.5.1. 硬件配置處理器:儲存器外設器件輸入/輸出設備1.5.2. 軟件環境系統軟件：支持軟件：必備軟件：選配軟件：殺毒軟件：1

7、.5.3. 網絡條件 網卡：網絡類型:網絡架構：1.6. 適用范圍獨立軟件：軟件的適用范圍和適用人群。軟件組件：同醫療器械產品的適用范圍和適用人群。1.7. 禁忌癥獨立軟件：軟件的禁忌癥和不適用人群。軟件組件：同醫療器械產品的禁忌癥和不適用人群。 1.8. 上市歷史（軟件組件寫醫療器械的上市歷史）(表格形式)國產首次注冊示例：該醫療器械，產品名稱為XXXXX，據產品結構及預期用途，按醫療器械分類目錄分為6870類軟件，按照二/三類醫療器械進行首次注冊。進口（首次/重新）該醫療器械作為XXX的組件，在中國（首次/重新）申請上市。依據產品結構及預期用途，按醫療器械分類目錄分為68xx-xx類。上市

8、歷史詳情見下表：上市國家管理類別上市時間版本號現版本號原產國（中國）歐洲（如有）美國（如有）2. 實現過程2.2.1 開發綜述我司于XXXX年XX月開始XX軟件的開發工作。整個開發過程包括可行性研究和項目開發計劃、需求分析、概要設計、詳細設計、編碼、集成、測試等6個階段，并編制相應開發文檔。本軟件開發采用XXXX模型。在開發過程中，采用的語言、工具和方法分別為：a） 語言：本軟件開發采用XX語言；b） 工具： 軟件需求工具：XXXXX，版本：XXXXXX，來源（制造商）：XXXXXX； 設計工具： 構造工具： 測試工具： 維護工具： 配制管理工具： 缺陷管理工具： c） 開發方法：本軟件采用X

9、XXXX如：面向對象、面向數據結構、敏捷軟件開發方法等方法； 在開發過程中，開發人員為XXX人，開發時間為XX月，工作量為XXXX人月。代碼行共XXXX行，控制文檔XXXX個。 2.2 風險管理風險管理報告全文，見附件1。XXX風險管理報告（文件號：xxx 版本：xxx）2.3需求規格A級，提供軟件需求規格關于功能和性能的要求。B級和C級，提供全文，全文應包括：硬件、功能、性能、輸入輸出、接口界面、警示信息、保密安全、數據與數據庫、文檔和法規的要求。組成模塊如有現成軟件，B級和C級應描述要求。 (SRS)需求規格說明書（SRS）全文，見附件2。需求規格說明書（文件號：xxx 版本：xxx）2.

10、4生存周期A級，軟件開發生存周期計劃摘要：包含開發策劃、需求分析、設計（體系結構設計、詳細設計）、編碼和測試（單元、集成、系統、用戶）個階段的任務、內容和結果B級，在A級基礎上提供配置管理計劃和維護計劃摘要，描述相應過程工具、流程和要求C級，在B級基礎上列明各階段輸入輸出控制文檔。組成模塊如有現成軟件，B級和C級的軟件應在開發生存周期計劃、配置管理計劃和維護計劃中說明相應的要求。可提供IEC 62304或IEC 60601-1-4核查表作為參考FDA軟件通用指南中的開發環境軟件開發計劃（SDP）摘要見附件3。軟件配制管理計劃（SCMP）摘要見附件4。軟件維護計劃摘要見附件5。生存周期實施情況核

11、查表見附件6。2.5驗證與確認軟件驗證與確認計劃見附件7。在軟件開發過程中，進行了以下測試：序號測試測試文檔編號XXX單元測試XXX單元測試計劃XXX單元測試報告各測試文檔詳見附件82.6缺陷管理2.6.1缺陷管理的流程 缺陷管理流程為：步驟工作主要內容負責人1缺陷報告22.6.2缺陷總數和剩余數開發過程中發現缺陷xx個，上市后剩余缺陷數為xx個。剩余缺陷描述、嚴重度、整改計劃為：序號缺陷描述嚴重度整改計劃計劃完成時間2.7修訂歷史軟件版本的命名規則：軟件的版本號為 的形式，版本號中，第一位是xx，代表：XXXX，第二位是xx，代表。本軟件修訂歷史序號軟件版本修訂日期修訂類型變更內容描述123

12、2.8臨床評價參考醫療器械軟件描述文檔 附件9“臨床評價報告（文件號：xxx 版本號xxx）”。 與注冊資料7臨床評價資料一致。3核心算法概述算法類型：公認成熟算法：公開文獻專利標準、原理簡單明確、上市超過四年且無不良事件。公認成熟算法列明名稱、原理、用途，全新算法列明名稱、原理、用途，并提供驗證資料。全新算法：源自科學研究和臨床數據內容：實質首次注冊：所有核心算法實質重新注冊：新增核心算法附件1XXX風險管理報告附件2XXX需求規格說明書（SRS）1. 引言1.1 編寫目的為了明確“XXXXX”項目的需求，為用戶和分析設計人員之間的交流提供方便，更好地安排項目規劃與進度，組織軟件開發與測試，

13、減少項目風險，撰寫本需求規格規格說明書。本需求規格說明書的讀者為項目經理、分析設計人員、程序員、質量保證人員、維護人員以及客戶方的相關人員。1.2 項目背景1.3 定義GB/T 11457所列術語和下列定義適用于本指南。 合同：指XXXX共同簽署的關于本項目的合同。 客戶：指XXXX公司。 語言：是指具有語法和語義的通信工具，包括一組表達式、慣例和傳遞信息的有關規則。 編程語言：是指用于編寫源程序的高級語言和匯編語言。用戶：XXXXXX1.4 參考資料a） GB/T 11457 軟件工程術語 b） GB 8566 計算機軟件開發規范 c） GB 8567 計算機軟件產品開發文件編制指南 d）

14、GB/T 12504 計算機軟件質量保證計劃規范 e） GB/T 12505 計算機軟件配置管理計劃規范 f） GB/T 19001 質量管理體系g） ISO9001 質量管理體系h） ISO9000-3質量管理體系i） ISO/IEC 12207軟件生命周期過程標準j） ISO/IEC TR 15504軟件過程評估標準k） IEEE1058.1軟件項目管理計劃標準l） CMM 2.0 能力成熟度模型m） PMBOK項目管理知識體系n） 項目計劃任務書o） 項目開發計劃p） 設備用戶手冊2. 總體描述2.1 目標2.1.1 開發意圖、應用目標a） 開發意圖： XXXX。b） 應用目標：XXXX

15、2.1.2 產品描述 （描述產品的基本要求、主要部分、外部接口等可使用框圖展示較大系統的主要部分、相互關系、外部接口等）2.1.2.1 軟件系統總體結構圖 采用基于采用 MVC 模式架構的開發方式，實現的系統具有界面美觀、操作簡單、開發系統容易升級、系統開發周期短、成本低等優點。在項目的研發中，從體系結構上將本系統設計為4層結構：系統結構圖（結構圖說明）2.1.2.2 軟件系統總體數據流圖 （圖示及說明）2.1.2.3 系統功能的總體用況圖 （圖示及說明）2.1.2.4 約束：a) 系統接口；（列出每個系統接口，識別完成系統需求的軟件功能以及與系統匹配的接口描述。）b) 用戶界面；（如要求的屏

16、幕顯示格式、頁面、版式、報告內容、菜單內容等）c) 硬件接口；（如支持的設備，采用的協議等）d) 軟件接口；（與其他軟件的接口，軟件應提供名稱、助記符、規格說明編號、版本號、來源，接口軟件的目的等）e) 通信接口；（如局域網協議等）f) 內存約束；（對主存、輔存的任何使用特征和限制）g) 運行；（如用戶引發的操作、交互操作的周期、無人值守操作的周期、數據處理支持能力、備份和回復操作）h) 現場適應性需求（給定現場、任務和運行模式的需求）2.2 產品功能描述軟件的將執行主要功能的概要。（可用文本或圖示的方法，顯示不同功能及其之間的關系，顯示變量之間的邏輯關系）2.3 用戶的特點 a） 管理員：。

17、 b） 用戶1：c） 用戶2： 2.4 約束條件 經費限制： 時間限制： 硬件局限：方法、技術、環境：法規：標準：并行操作：審核功能：3. 具體需求 3.1 外部接口各接口描述包括以下內容：a) 項的名稱；b) 目的描述；c) 輸入源和輸出目的地；d) 有效范圍、準確度和容限；e) 測量單位；f) 定時；g) 與其他輸入/輸出的關系；h) 屏顯格式；i) 窗口格式；j) 數據格式；k) 命令格式；l) 結束消息。3.1.1.1 用戶接口 3.1.1.2 硬件接口 3.1.1.3 軟件接口 3.1.1.4 通信接口 3.2 功能需求3.2.1 用戶注冊功能系統應能完成用戶注冊功能 主參加者：用戶

18、 環境目標： 前置條件：數據庫有足夠的空間。 觸發器：用戶進入注冊界面。 場景： a） 用戶進入注冊界面。 b） 用戶輸入會員名。 c） 用戶輸入登錄密碼。 d） 用戶輸入確認密碼。 e） 用戶輸入其他個人基本信息。 f） 用戶輸入驗證碼。 g） 點擊確認按鈕，提交注冊信息。 異常： a） 用戶注冊的會員名已在系統中存在時，給出提示信息，讓其更改所輸入的會員名。 b） 用戶輸入的確認密碼與登錄密碼不一致時，給出提示信息，讓其重新輸入密碼。 c） 用戶輸入的驗證碼錯誤時，給出提示信息，隨機更換驗證碼的圖片后，讓其重新輸入驗證碼。 優先級：必須被實現。 何時可用：首次開發。 使用頻率：每天多次。

19、后置條件：用戶完成操作后顯示注冊成功信息。 活動圖 3.2.2 3.3 性能需求3.3.1 支持的終端數：3.3.2 支持同時運行的用戶數量；3.3.3 要處理的信息量和類型：3.3.4 精度3.3.5 速度：3.3.6 人身和環境安全性需求3.4 數據庫邏輯需求（規定將置于數據庫的任何信息的邏輯需求，可包括：）a) 不同功能使用的信息類型；b) 使用頻度；c) 訪問能力；d) 數據實體及其之間的關系；e) 完整性約束；f) 數據保存要求3.5 設計約束（描述由可能由其他標準、硬件局限等引發的設計約束）3.6 軟件系統屬性3.6.1 可靠性3.6.2 可用性3.6.3 保密性需求 a） 對注冊

20、過的用戶個人信息的嚴格保密，除用戶自己以及管理員之外，其他人不能查閱用戶信息。 b） 對數據傳輸過程需有嚴格的保密機制，防止用戶數據的泄露。 c） 對于管理員要分發給管理數據庫的權限。 3.6.4 可維護性3.6.5 可移植性附件3XXX軟件開發計劃（SDP）摘要1. 引言本條應簡述本文檔適用的系統和軟件的用途，它應描述系統和軟件的一般特性；概述系統開發、運行和維護的歷史；標識項目的投資方、需方、用戶、開發方和支持機構；標識當前和計劃的運行現場；列出其他有關的文檔。2. 實施整個軟件開發活動的計劃2.1 軟件開發過程本條應描述要采用的軟件開發過程。計劃應覆蓋論及它的所有合同條款，確定已計劃的開

21、發階段（適用的話）、目標和各階段要執行的軟件開發活動。2.2 軟件開發總體計劃2.2.1 軟件生存周期描述預期采用的生存周期模型，并進行說明2.2.2 軟件開發方法本條應描述或引用要使用的軟件開發方法，包括為支持這些方法所使用的手工、自動工具和過程的描述。該方法應覆蓋論及它的所有合同條款。2.2.3 可重用的軟件產品本條應描述標識、評估和吸納可重用軟件產品要遵循的方法，包括搜尋這些產品的范圍和進行評估的準則。描述應覆蓋合同中論及它的所有條款。在制定或更新計劃時對已選定的或候選的可重用的軟件產品應加以標識和說明，（若適用）同時應給出與使用有關的優點、缺陷和限制。2.2.4 處理關鍵性需求本條應分

22、以下若干條描述為處理指定關鍵性需求應遵循的方法。描述應覆蓋合同中論及它的所有條款。3. 進度表和活動網絡圖本章應給出：a 進度表，標識每個開發階段中的活動，給出每個活動的初始點、提交的草稿和最終結果的可用性、其他的里程碑及每個活動的完成點；b 活動網絡圖，描述項目活動之間的順序關系和依賴關系，標出完成項目中有最嚴格時間限制的活動。4. 項目組織和資源4.1 項目組織本條應描述本項目要采用的組織結構，包括涉及的組織機構、機構之間的關系、執行所需活動的每個機構的權限和職責。4.2 項目資源 本條應描述適用于本項目的資源。（若適用）應包括： a人力資源，包括： 1) 估計此項目應投入的人力（人員時間

23、數）； 2) 按職責（如：管理，軟件工程，軟件測試，軟件配置管理，軟件產品評估，軟件質量保證和軟件文檔編制等）分解所投入的入力； 3) 履行每個職責人員的技術級別、地理位置和涉密程度的劃分； b開發人員要使用的設施，包括執行工作的地理位置、要使用的設施、保密區域和運用合同項目的設施的其他特性； c為滿足合同需要，需方應提高的設備、軟件、服務、文檔、資料及設施，給出一張何時需要上述各項的進度表； d其他所需的資源，包括：獲得資源的計劃、需要的日期和每項資源的可用性。附件4XXX軟件配置管理計劃（SCMP）摘要1. 軟件配置管理活動本章描述配置標識、配置控制，配置狀態記錄與報告以及配置檢查與評審等

24、四方面的軟件配置管理活動的需求。1.1 配置標識1.1.1 本條必須詳細說明軟件項目的基線（即最初批準的配置標識） 在軟件生存周期中，主要有三種基線，它們是功能基線、分配基線和產品基線。對于每個基線，必須描述下列內容： a 每個基線的項（包括應交付的文檔和程序）； b 與每個基線有關的評審與批準事項以及驗收標準； c 在建立基線的過程中用戶和開發者參與情況。 例如，在產品基線中，要定義的元素可以包括： a 產品的名字和命名規則； b 產品標識編號； c 對每一個新交付的版本，要給出版本交付號、新修改的描述、修改交付的方法、對支持軟件的修改要求以及對有關文檔的修改要求； d 安裝說明； e 已知

25、的缺陷和故障；f 軟件媒體和媒體標識。1.1.2 本條必須描述本項目所有軟件代碼和文檔的標題、代號、編號以及分類規程例如，對代碼來說： a 編譯日期可以作為每個交付模塊標識的一部分；b 在構造模塊源代碼的順序行號時，應使它適合于模塊作進一步的修改。1.2 配置控制1.2.1 本條必須描述軟件生存周期中各個階段使用的修改批準權限的級別1.2.2 本條必須定義對已有配置的修改申請進行處理的方法 其中包括： a 詳細說明在本計劃第3.2條描述的軟件生存周期各個階段中提出修改申請的程序（可以用注上自然語言的流程圖來表達）； b 描述實現已批準的修改申請（包括源代碼、目標代碼和文檔的修改）的方法； c

26、描述軟件庫控制的規程，其中包括庫存軟件控制、對于適用基線的讀寫保護、成員保護、成員標識、檔案維護、修改歷史以及故障恢復等七項規程；d 如果有必要修補目標代碼，則要描述其標識和控制的方法。2. 工具、技術和方法 本章必須指明為支持特定項目的軟件配置管理所使用的軟件工具、技術和方法，指明它們的目的，并在開發者所有權的范圍內描述其用法。例如，可以包括用于下列任務的工具，技術和方法： a 軟件媒體和媒體文檔的標識。 b 把文檔和媒體置于軟件配置管理的控制之下，并把它正式地交付給用戶。例如，要給出對軟件庫內的源代碼和目標代碼進行控制的工具、技術和方法的描述；如果用到數據庫管理系統，則還要對該系統進行描述

27、。又如，要指明怎樣使用軟件庫工具、技術和方法來處理軟件產品的交付。 c 編制關于程序及其有關文檔的修改狀態的文檔。因此必須進一步定義用于準備多種級別（如項目負責人、配置控制小組、軟件配置管理人員和用戶）的管理報告的工具、技術方法。 附件5XXX軟件維護計劃摘要1. 維護范圍a) 改正性維護b) 適應性維護c) 完善性維護d) 預防性維護2. 維護工作流程附件6XXX軟件生存周期實施情況核查表（YY/T 0708）應維護應用本標準形成的文件并應使其成為質量記錄的一部分;見圖241。宜依照GB/T 19001-2000中4. 2的要求實施。這些文件（以下簡稱為風險管理文檔），應根據規定的配置管理機

28、制進行批準、發布和更改。宜依照GB/T19001-2000中的4.2.3的要求實施52.201.3在整個開發生存周期中，應形成風險管理概要，并將其作為風險管理文檔的一部分。其內容應包括：a)已識別的危害以及其起因b)風險估計c)用于消除或控制危害的風險所采取的安全性措施的證明d)風險控制e)驗證證明通過檢查風險管理文檔核查其符合性52.202.1制造商應制定風險管理計劃。52.202. 2計劃應包括以下內容:a)計劃的范圍，確定項目或產品以及該計劃適用的開發和生存周期的各階段；b)使用的開發生存周期（見52.203），包括驗證計劃的開發生存周期的各階段；c)依照GB/T 19001-2000中

29、5.1的管理職責；d)風險管理過程e)審核要求52. 202.3如果在開發過程中計劃改變，應保留更改的記錄通過檢查風險管文檔核查其符合性52. 203. 1應為可編程醫用電氣系統的設計和開發定義開發生存周期52. 203. 2開發生存周期應分解為各個階段和任務，對每一個階段和任務都應明確定義輸入和輸出以及活動。52. 203. 3開發生存周期應包括風險管理的整個個過程。52. 203. 4開發生存周期應包括對文檔的要求。52. 203. 5風險管理活動應合適地貫穿于開發生存周期中，見52. 204。注:在附錄DDD（資料性附錄)給出了一個開發生存周期的示例。通過檢查風險管理文檔核查其符合性。應

30、在開發生存周期的所有階段和任務之內或之間的適用處，建立和維護一套明確的問題解決體系，并作為風險管理文檔的一部分.根據間題，該體系可具有如下特征:定義作為開發生存周期的一部分;允許報告潛在的或現存安全性和(或)性能方面的問題，包括對每個問題的相關風險的評估;確定問題分析結束的準則安全性和(或)性能方面;確定解決各種問題所采取的措施;確定每一種措施的確認方法;一確定驗證持續符合性的步驟。52 .204.1要素應采用包括如下要素的風險管理過程:風險分析;風險控制。要求風險管理過程應貫穿于整個開發生存周期。風險分析危害分析應按風險管理計劃進行危害的識別，見52.202。應對所有合理可預見的情況進行危害

31、識別，包括:正常使用情況下;不正確使用情況下。52.204.3 .1.3應考慮合適的危害狀況，包括:對患者的危害;對操作者的危害;一對維護人員的危害;對附近人員的危害;對環境的危害。應考慮可能導致危害的合理可預見的事件序列。應考慮導致危害的合適的原因，包括:人的因素，包括入體工程學方面的限制;硬件故障;軟件故障;集成錯誤;環境條件。應考慮合適的事項，包括:系統組件的兼容性，包括硬件和軟件;用戶界面，包括命令語言、警告以及出錯信息;用戶界面和使用說明書中使用的文本的翻譯準確性;針對有意或無意的人為因素影響的數據保護;風險(受益)準則;第三方軟件。應采用與開發生存周期階段相適應的危害識別方法。所采

32、用的方法(例:故障樹分析法，失效模式和效應分析)應歸檔到風險管理文檔中。方法應用的結果應歸檔到風險管理文檔中。每個被識別的危害和引發的原因應記錄在風險管理概要中。通過檢查風險管理文檔核查符合性風險估計對每一個被識別的危害，應估計其風險。風險估計應基于對每個危害發生的可能性和(或)每個危害發生后果的嚴重度進行估計。嚴重度級別分類方法應記錄在風險管理文檔中。危害發生的可能性的估計方法既可以是定量的也可以是定性的，并應記錄在風險管理文檔中。對每個危害，其估計的風險應記錄在風險管理概要中。 通過檢查風險管理文檔核查符合性。風險控制應控制風險以使每個已識別的危害的經估計的風險降至可接受的程度。如果風險低

33、于或等于最大可容許風險，并且該風險已經盡可能合理可行地降低了，那么認為是可接受的。風險控制方法應降低危害發生的可能性或危害的嚴重度，或兩者均降低。正確實施降低風險手段的可能性，應以定性或定量的方式說明;見附錄CCC(資料性附錄)。風險控制的方法應面向危害起因(例如，通過降低其可能性)或在危害的起因出現時采取保護措施，或者兩者均采用，優先級如下:固有安全設計;保護措施包括警報;關于剩余風險的充分的用戶信息。控制風險的各種要求應直接在風險管理概要中文件化或引用。風險控制有效性的評價應記錄在風險管理概要中。通過檢查風險管理文檔核查其符合性。52.205人員資格根據GB/T 19001-2000中6.

34、2.2的要求，可編程醫用電氣系統的設計和修改應視為一個指定的任務。通過檢查相關文件核查其符合性。52.206需求規格說明對可編程醫用電氣系統和其對應的子系統(如可編程電子子系統)都應有需求規格說明。 注:附錄EEE（資料性附錄）中給出了可編程醫用電氣系統體系結構的例子。52.206. 2需求規格說明應詳述與風險有關的功能。包括控制由下列原因產生的風險的功能:a)環境條件引起的原因;b)可編程醫用電氣系統其他方面引起的原因;c)可能的故障。需求規格說明中應包括確保風險控制措施圓滿地降低了已識別風險的必要信息。52.207體系結構體系結構應滿足需求規格說明。應規定可編程醫用電氣系統以及其子系統的體

35、系結構。有關編程醫用電氣系統及其子系統體系結構規格說明應在合適處通過降低相應的危害的可能性或危害發生的嚴重度，或二者均降低來實現風險控制要求。為了降低危害發生的可能性，應在體系結構規格說明的合適處利用:a)高可靠性組件;b)失效防護功能;c)冗余;d)多樣性;e)防護設計;f)潛在危害影響的限制，例如限制可獲得輸出能量和（或）通過采用限制執行機構行程的方法。體系結構規格說明應考慮如下因素:a)風險控制措施在可編程醫用電氣系統組件和子系統上的配置;注:子系統和部件包括:傳感器、執行機構、可編程電子子系統和接口。b)組件的失效模式及效應;c)一般原因的失效;d)系統性失效;e)測試時間間隔、濺試持

36、續時間和測試診斷范圍;f)可維護性;g)有意或無意的人為因素的防護。52.208設計和實現設計應在合適處適當分解成子系統，每個子系統都應有設計和測試規格說明。有關設計環境的描述性數據應包括在風險管理文檔中。注:有關設計環境要素的示例見附錄DDD(資料性附錄)。52.209驗證安全要求的實現應進行驗證。應制訂驗證計劃，說明在開發生存周期的每個階段的安全性要求如何驗證。該計劃應包括:a)驗證的策略、活動和技術的選擇和歸檔;b)驗證工具的選擇和運用;c)驗證的覆蓋準則。注:關于方法和技術的實例是:走查和檢查;靜態(動態)分析;白盒(黑盒)側試。應根據驗證計劃進行驗證。驗證活動的結果應歸檔、分析和評定

37、。風險管理概要中應包含驗證的方法、技術和結果的證明。52.210確認應進行可編程醫用電氣系統在預期使用條件下安全性的確認。應制訂確認計劃，以表明實現了正確的安全性要求。應根據確認計劃實施確認。確認活動的結果應歸檔、分析和評定。實施確認的小組負責人應獨立于開發小組。確認小組成員和設計小組成員的專業關聯性應記錄在風險管理文檔中。設計小組成員不能承擔其設計的確認職責。風險管理文檔中應包括確認的方法和結果的證明。通過檢查風險管理文檔核查其符合性。52.211修改如果任何部分或全部設計是由對先前設計的修改產生，則該設計要么視為一個全新設計，則本標準的所有條款適用;要么任何先前設計文檔的持續有效性應按照修

38、改/更改程序進行評價。在開發生存周期中所有的相關文件，應依照GB/T 19001一2000中4.2.3規定或等同規定的文件控制計劃，進行校訂、修正、復核和批準。通過檢查風險管理文檔核對其符合性。52.2 1評定為確保可編程醫用電氣系統按照本標準的要求開發完成并記錄在風險管理文檔中，應進行評定它可由內部審核方式進行。 通過檢查風險管理文檔核查符合性。附件7XXX軟件驗證與確認計劃（SVVP）1. 目的2. 引用文件3. 術語和定義4. V&V綜述4.1 組織4.2 主進度4.3 資源摘要4.4 職責4.5 工具、技術和方法5. V&V過程5.1 活動：概念V&V（標識要執行的V&V的任務，描述每

39、個V&V任務要求的輸入、輸出、進度、進度、資源等）5.2 活動：需求V&V5.3 活動：設計V&V5.4 活動：實現V&V5.5 活動：測試V&V5.6 活動：安裝和檢驗V&V5.7 活動：運行V&V6. V&V報告附件8XXX軟件測試文檔XXXX測試計劃1 測試計劃標識符AP05-01032 引言2.1 目標 公司XX系統的系統測試計劃應該支持以下目標： (1) 細化準備和進行系統測試所需要的活動。 (2) 與所有負責方溝通有關他們要執行的任務以及執行任務時所安排的進度。 (3) 確定用來準備計劃的信息源。(4) 確定進行系統測試所需要的測試工具和環境。2.2背景 去年，XYZ公司系統和程序

40、開發部門應公司會計部門的要求開發了一個新的通用總帳系統。與此同時，還提出要求要開發一個與該通用總帳系統接口的新的公司工資系統。管理層系統評估委員會在19*年9月批準了開發工資系統的請求，并且指定一個工資系統顧問組來確定系統需求。顧問組于19*年12月完成了一份需求陳述(AP01-01)和一份初步開發計劃。2.3范圍該測試計劃覆蓋了公司工資系統的全部系統測試，包括操作者和用戶規程、以及程序和作業控制。除了綜合性多程序功能性測試外，還應評估外部接口、安全、恢復和性能。2.4 引用文件 下列文檔用作該測試計劃的信息源： 公司工資系統初步開發計劃(AP01-02) 公司工資系統授權(AP01-03)

41、公司工資系統最終開發計劃(AP01-06) 公司工資系統質量倮證計劃(AP01-08) 公司工資系統配置管理計劃(AP01-09) XYZ公司系統開發標準及規程(XYZ01-0100) 公司通用總帳系統設計描述(AG01-04)公司通用總帳系統測試計劃(AG05-01)3測試項 組成公司工資系統的所有項在系統測試期間應予測試。待測試的版本應由配置管理員放在合適的庫中。管理員還應控制對受試版本的更改，并且將可提供新版本的時間通知測試組。 以下文檔為規定正確的操作建立基礎： 公司工資系統需求規格說明(AP01-01) 公司工資系統設計描述(AP01-04) 公司工資系統參考手冊(AP02-01)公

42、司工資系統模塊參考手冊(AP02-03)GB/T 9386-2008要測試的各項列出如下：3.1 程序模塊要測試的程序模塊按以下規則來標識：類型 庫 成員名稱源代碼 SOURLIB1 AP0302AP0305可執行代碼 MACLIBI AP0301AP0302AP0305 3.2 作業控制規程 應用程序、分類和實用程序的控制規程標識如下： 類型 庫 成員名稱 應用程序 PROCLIBl AP0401分類 PROCLIB1 AP0402實用程序 PROCLIBI AP04033.3用戶規程公司工資系統用戶事務參考手冊(AP02-04)中規定的在線規程應予測試。3.4操作者規程系統測試包括公司工資

43、系統操作參考手冊(AP02-02)中規定的規程。4要測試的特征 以下清單列出待測試的特征：測試設計說明編號 描述AP06-01 數據庫轉換AP06-02 月薪雇員全面的工資處理AP06-03 計時雇員全面的工資處理AP06-04 所有雇員全面的工資處理AP06-05 定期報告AP06-06 通用總帳事務的建立AP06-07 安全AP06-08 恢復AP06-09 性能5不要測試的特征 下列特征不應包括在系統測試中，因為它們在系統初始安裝時不會使用。 平等就業機會委員會符合性報告內部培訓進度報告工資業績審查報告 二期開發階段文檔集應包含關于這些特征的一個測試計劃。 測試用例將不會覆蓋正在受試的事

44、務或者報告中所有可能的選項組合。只有目前XYZ公司工資處理明確需求的組合應予測試。6 方法 測試人員應根據系統文檔集準備所有的測試設計、用例以及規程說明。這種方法應驗證測試所覆蓋那些領域的文檔集信息的準確性和綜合性。 公司工資和會計部門的人員應協助開發測試設計和測試用例，這樣做有助于確保測試能體現系統的實際使用。 為了確保保密性，從會計文件中選取的所有測試數據應含有已更改的保密敏感字段。6.1 轉換測試 除了計算輸入和輸出的記錄外，轉換數據庫的有效性應以兩種方式進行驗證。第一種驗證方法涉及到使用必須由開發組建立的“數據庫審核員”功能。當針對被轉換數據庫運行時，數據庫審核員應核對一條記錄內的數值

45、范圍，以及要求的各條記錄之間的關系。 第二種驗證方法涉及到隨機選取舊記錄的一個小的子集，然后直接與新記錄的相對應子集進行比較。直接比較的數目“c”和舊記錄的數目“r”必須加以規定。從1到r的范圍內產生由隨機數字組成的c集合。在轉換過程中，該集合應予以分類和應用，以驅動對宣接比較記錄的選擇。 注：同樣的兩種驗證方法在實際的轉換期間應予采用。6.2作業流測試 月薪雇員和計時雇員的記錄綜合集以及這兩種記錄的合并集應用于測試工資處理。標準的作業流測試方法應予采用。 每種定期報告作業流至少運行一次。6.3接口測試 為了測試工資系統與通用總帳系統之間的接口，工資系統應建立一個通用總帳事務綜合集。這些事務應

46、輸入到通用總帳測試系統。生成的通用總帳條目必須加以選取、打印并與由工資系統準備的通用總帳事務的打印輸出相比較。6.4安全測試 無妥當口令但又試圖訪問在線數據條目并顯示事務的情況應予測試。6.5恢復測試 在可單獨運行的時間內，通過停機且隨后依照恢復規程進行恢復測試。6.6性能測試 依據性能要求(AP01-01)，通過利用產生的數據量測量若干作業的運行時間，以此來評估性能。6.7 回歸測試 假設為了測試在系統測試期間做過的程序修改，則應對系統進行若干次重復測試。對系統的每一新版本應做一次回歸測試，從而檢測由于程序修改所導致的意想不到的影響。 應通過對新版本執行前一版本曾執行的那些所有測試來完成回歸測試，然后對由此得到的結果文件進行比較。標準的比較器程序(UT08-0100)應予采用，以便比較所有的系統輸出。6.8綜合性 公司工資系統參考手冊( AP02-01)中描述的每個系統特征至少應有一份相關聯的測試設計說明。公司工資系統用戶事務參考手冊(AP02-04)中所規定的每個用戶規程至少應予測試一次。公司工資系統操作手冊(AP02-02)中規定的每個操作規程至少也應予測試一次。另外，每個作業控制規程至少應予執行一次。 對于關聯到上述每個領域的測試設計說明，應采用覆蓋矩陣予以核查。6.9約束 公司工資系統的最終執行日期定于19*年8月31號。必須符合這個日期