医疗器械软件描述文档

《医疗器械软件描述文档》由会员分享，可在线阅读，更多相关《医疗器械软件描述文档（42页珍藏版）》请在装配图网上搜索。

1、医疗器械软件描述文档1. 基本信息1.1. 产品标识软件名称：软件型号：软件版本号：软件制造商：软件生产地址:1.2. 安全性级别软件的安全f级别为A/B/C级。理由如下：a）软件的预期用途为：b）软件的功能包括：c）如果软件失效，可能导致以下后果（按软件各功能失效逐条描述，如果软件失效的时候由硬件降低失效后果或危害发生概率，可以做说明，并由此降低安全性级别）：1）2）3）1.3. 结构功能1.3.1 .组成模块、各模块功能及模块相互关系依据软件设计规格给出体系结构图（如图1.3-1所示）。嵌入式软件（SDS）体系结构图一一示例1独立式软件（SDS）体系结构图一一示例2-可编辑修改-结构图（S

2、C）举例财务管理房理药管阵理药n诊理门管图1.3-1XXX体系结构图1.3.2 各模块功能说明系统主要由XXXXXX模块组成。各模块功能简介如下：产品名称版本号模块名称软件功能项目功能说明一级功能二级功能三级功能模块名称软件功能项目功能说明一级功能二级功能三级功能注：1、每个软件模块一份表单。2、软件功能项目列表需列出与测试相关的所有功能（包括各级子功能）3、功能说明栏目应填写：功能项目概述、边界值规定（数据有效性）、安全说明等信息。4、功能列表上所列出来的功能必须是可以实现或演示的。5、功能名称与软件、文档保持一致。6、软件功能项目列表根据需要列出（可增加或删减子功能列）。1.3.2.用户界

3、面设计采用广泛应用的图形用户界面（GUI），即诸如窗口、菜单、对话框、滚动条等。用户主界面见图1.3- 2。图1.3-2XXX用户主界面1.3.3. 外部接口XXX可使用VISUALC+提供的对SQLSERVER的接口，进行对数据库的所有访问。XXX可使用SQLSERVER的对数据库的备分命令，以做到对数据的保存。在网络软件接口方面，使用一种无差错的传输协议，采用滑动窗口方式对数据进行网络传输及接收。-可编辑修改-1.4. 硬件关系1.4.1. 物理拓扑图嵌入式软件物理拓扑关系表格形式一一示例1硬件软件分类零件种类功能显示部分血压显示7工具LED血压值显示取局血压？取低血压、月辰拍在表小时刻显

4、示7工具LED畴刻显示显示现在时刻压力单位显示LEDmmHg/kPa显示显示血压值以及压力值的单位开关部分开始/关闭开关开始/关闭开关读取控制开始测量血压测量时停止测量背面功能设定开关背面功能设定开关读取控制时刻的设定等、主机功能设定的更改打印部分打印切纸打印控制测量结果的打印、打印后切纸血压测量部分泵、电磁阀、压力传感器血压测定控制测量时加压、减压控制、脉搏彳乃处理以及测量值的确定安全监视用压力传感器压力安全检测控制压力监测、急排控制袖带驱动部分袖带驱动用马达袖带控制袖带的卷曲、固定、开放语音部分:扬语音控制测量通知外部进出力部串行通信串行进出力测量结果出力、指令输入记忆存储U盘设定值记，忆

5、存储控制功能设定内容的保持嵌入式软件物理拓扑关系表格形式一一示例2MedicalDevice/(System)UserSensorData entryKeyboard nUserInterfaceSoftwareApplicationSoftwareHardwareInterfaceSoftwareReadingMomrtor Informatiori -ZlDisplayHardwareControltPatient独立式软件物理拓扑关系表格形式一一示例图1.4-1物理拓扑图他射科强密器和存精设各IU/ use硬做毒放鼾的蹙与曲1.4.2. 连接关系描述与PC连接与医疗器械硬件连接1.5.

6、运行环境1.5.1. 硬件配置处理器：储存器外设器件输入/输出设备1.5.2. 软件环境系统软件:支持软件:必备软件:选配软件:杀毒软件:1.5.3. 网络条件网卡：网络类型：网络架构：1.6. 适用范围独立软件：软件的适用范围和适用人群。软件组件：同医疗器械产品的适用范围和适用人群。1.7. 禁忌症独立软件：软件的禁忌症和不适用人群。软件组件：同医疗器械产品的禁忌症和不适用人群。1.8. 上市历史（软件组件写医疗器械的上市历史）（表格形式）国产首次注册示例：该医疗器械，产品名称为XXXXX,据产品结构及预期用途，按医疗器械分类目录分为6870类软件，按照二/三类医疗器械进行首次注册。进口（首

7、次/重新）该医疗器械作为XXX的组件，在中国（首次/重新）申请上市。依据产品结构及预期用途，按医疗器械分类目录分为68xx-xx类。上市历史详情见下表：上市国家管理类别上市时间版本号现版本号原产国（中国）欧洲（如有）美国（如有）-可编辑修改-2.实现过程2.1 开发综述我司于XXXX年XX月开始XX软件的开发工作。整个开发过程包括可行性研究和项目开发计划、需求分析、概要设计、详细设计、编码、集成、测试等6个阶段，并编制相应开发文档。本软件开发采用XXXX模型。在开发过程中，采用的语言、工具和方法分别为：a）语言：本软件开发米用XX语言；b）工具：一软件需求工具：XXXXX,版本：XXXXXX,

8、来源（制造商）：XXXXXX;一设计工具：一构造工具：一测试工具：一维护工具：一配制管理工具：一缺陷管理工具：c）开发方法：本软件采用XXXXX方法；在开发过程中，开发人员为XXX人，开发时间为XX月，工作量为XXXX人月。代码行共XXXX行，控制文档XXXX个。2.2风险管理风险管理报告全文,见附件 1。XXX风险管理报告（文件号： xxx版本：xxx）2.3需求规格（SRS）需求规格说明书（SRS全文，见附件2。需求规格说明书（文件号：xxx版本：xxx）2.4生存周期软件开发计划（SDP）摘要见附件3。软件配制管理计划（SCMP）摘要见附件4。软件维护计划摘要见附件5。生存周期实施情况核

9、查表见附件6。2.5 验证与确认软件验证与确认计划见附件7。在软件开发过程中，进行了以下测试：序号测试测试文档编PXXX单元测试XXX单元测试计划XXX单元测试报告各测试文档t见附件82.6 缺陷管理2.6.1 缺陷管理的流程缺陷管理流程为:步骤工作主要内容负责人1缺陷报告22.6.2缺陷总数和剩余数开发过程中发现缺陷xx个，上市后剩余缺陷数为xx个。剩余缺陷描述、严重度、整改计划为：序号缺陷描述严重度整改计划计划完成时间2.7 修订历史软件版本的命名规则：软件的版本号为XX.XX.XXXXX的形式，版本号中，第一位是xx,代表:XXXX,第二位是xx,代表本软件修订历史序号软件版本修订日期修

10、订类型变更内容描述1232.8 临床评价参考医疗器械软件描述文档附件9“临床评价报告（文件号：xxx版本号xxx）”。与注册资料7临床评价资料一致。3核心算法概述算法类型：公认成熟算法：公开文献专利标准、原理简单明确、上市超过四年且无不良事件。公认成熟算法列明名称、原理、用途，全新算法列明名称、原理、用途，并提供验证资料。全新算法：源自科学研究和临床数据内容：实质首次注册：所有核心算法实质重新注册：新增核心算法-可编辑修改-附件 2XXX风险管理报告-可编辑修改-XXX需求规格说明书(SRS)1. 引言1.1 编写目的为了明确“XXXXX”项目的需求，为用户和分析设计人员之间的交流提供方便，更

11、好地安排项目规划与进度，组织软件开发与测试，减少项目风险，撰写本需求规格规格说明书。本需求规格说明书的读者为项目经理、分析设计人员、程序员、质量保证人员、维护人员以及客户方的相关人员。1.2 项目背景1.3 定义GB/T11457所列术语和下列定义适用于本指南。合同：指XXXX共同签署的关于本项目的合同。客户：指XXXX公司。语言：是指具有语法和语义的通信工具，包括一组表达式、惯例和传递信息的有关规则。编程语言：是指用于编写源程序的高级语言和汇编语言。用户：XXXXXX1.4 参考资料a) GB/T11457软件工程术语b) GB8566计算机软件开发规范c) GB8567计算机软件产品开发文

12、件编制指南d) GB/T12504计算机软件质量保证计划规范e) GB/T12505计算机软件配置管理计划规范f) GB/T19001质量管理体系g) ISO9001质量管理体系h) ISO9000-3质量管理体系i) ISO/IEC12207软件生命周期过程标准j) ISO/IECTR15504软件过程评估标准k) IEEE1058.1软件项目管理计划标准l) CMM2.0能力成熟度模型m) PMBOK项目管理知识体系n) 项目计划任务书o) 项目开发计划p) 设备用户手册2. 总体描述2.1 目标2.1.1 开发意图、应用目标a） 开发意图：XXXX。b） 应用目标：XXXX2.1.2 产

13、品描述（描述产品的基本要求、主要部分、外部接口等可使用框图展示较大系统的主要部分、相互关系、外部接口等）2.1.2.1 软件系统总体结构图采用基于采用MVC模式架构的开发方式，实现的系统具有界面美观、操作简单、开发系统容易升级、系统开发周期短、成本低等优点。在项目的研发中，从体系结构上将本系统设计为4层结构：系统结构图（结构图说明）2.1.2.2 软件系统总体数据流图（图示及说明）2.1.2.3 系统功能的总体用况图（图示及说明）2.1.2.4 约束：a） 系统接口；（列出每个系统接口，识别完成系统需求的软件功能以及与系统匹配的接口描述。）b） 用户界面；（如要求的屏幕显示格式、页面、版式、报

14、告内容、菜单内容等）c） 硬件接口；（如支持的设备，采用的协议等）d） 软件接口；（与其他软件的接口，软件应提供名称、助记符、规格说明编号、版本号、来源，接口软件的目的等）e） 通信接口；（如局域网协议等）f） 内存约束；（对主存、辅存的任何使用特征和限制）g） 运行；（如用户引发的操作、交互操作的周期、无人值守操作的周期、数据处理支持能力、备份和回复操作)h） 现场适应性需求(给定现场、任务和运行模式的需求)2.2 产品功能描述软件的将执行主要功能的概要。(可用文本或图示的方法，显示不同功能及其之间的关系，显示变量之间的逻辑关系)2.3 用户的特点a) 管理员：。b) 用户1：c) 用户2：

15、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 用户注册功能系统应能完成用户注册功能主参加者：用户环境目标：前置条件：数据库有足够的空间。触发器：用

16、户进入注册界面。场景：a) 用户进入注册界面。b) 用户输入会员名。c) 用户输入登录密码。d) 用户输入确认密码。e) 用户输入其他个人基本信息。f) 用户输入验证码。g) 点击确认按钮，提交注册信息。异常：h) 用户注册的会员名已在系统中存在时，给出提示信息，让其更改所输入的会员名。i) 用户输入的确认密码与登录密码不一致时，给出提示信息，让其重新输入密码。j) 用户输入的验证码错误时，给出提示信息，随机更换验证码的图片后，让其重新输入验证码。优先级：必须被实现。何时可用：首次开发。使用频率：每天多次。后置条件：用户完成操作后显示注册成功信息。活动图3.2.23.3 性能需求3.3.1 支

17、持的终端数：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) 对注册过的用户个人信息的严格保密，除用户自己以及管理员之外，其他人不能查阅用户信息。b) 对数据传输过

18、程需有严格的保密机制，防止用户数据的泄露。c) 对于管理员要分发给管理数据库的权限。3.6.4 可维护性3.6.5 可移植性-可编辑修改-附件 3XXX软件开发计划（SDP）摘要1. 引言本条应简述本文档适用的系统和软件的用途，它应描述系统和软件的一般特性；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；列出其他有关的文档。2. 实施整个软件开发活动的计划2.1 软件开发过程本条应描述要采用的软件开发过程。计划应覆盖论及它的所有合同条款，确定已计划的开发阶段（适用的话）、目标和各阶段要执行的软件开发活动。2.2 软件开发总体计划2.2.

19、1 软件生存周期描述预期采用的生存周期模型，并进行说明2.2.2 软件开发方法本条应描述或引用要使用的软件开发方法，包括为支持这些方法所使用的手工、自动工具和过程的描述。该方法应覆盖论及它的所有合同条款。2.2.3 可重用的软件产品本条应描述标识、评估和吸纳可重用软件产品要遵循的方法，包括搜寻这些产品的范围和进行评估的准则。描述应覆盖合同中论及它的所有条款。在制定或更新计划时对已选定的或候选的可重用的软件产品应加以标识和说明，（若适用）同时应给出与使用有关的优点、缺陷和限制。2.2.4 处理关键性需求本条应分以下若干条描述为处理指定关键性需求应遵循的方法。描述应覆盖合同中论及它的所有条款。3.

20、 进度表和活动网络图本章应给出：a进度表，标识每个开发阶段中的活动，给出每个活动的初始点、提交的草稿和最终结果的可用性、其他的里程碑及每个活动的完成点；b活动网络图，描述项目活动之间的顺序关系和依赖关系，标出完成项目中有最严格时间限制的活动。4. 项目组织和资源4.1 项目组织-可编辑修改-本条应描述本项目要采用的组织结构，包括涉及的组织机构、机构之间的关系、执行所需活动的每个机构的权限和职责。4.2 项目资源本条应描述适用于本项目的资源。（若适用）应包括：a.人力资源，包括：1） 估计此项目应投入的人力（人员时间数）；2） 按职责（如：管理，软件工程，软件测试，软件配置管理，软件产品评估，软

21、件质量保证和软件文档编制等）分解所投入的入力；3） 履行每个职责人员的技术级别、地理位置和涉密程度的划分；b.开发人员要使用的设施，包括执行工作的地理位置、要使用的设施、保密区域和运用合同项目的设施的其他特性；c.为满足合同需要，需方应提高的设备、软件、服务、文档、资料及设施，给出一张何时需要上述各项的进度表；d.其他所需的资源，包括：获得资源的计划、需要的日期和每项资源的可用性。-可编辑修改-附件 4XXX软件配置管理计划（SCMP）摘要1.1.1 软件配置管理活动本章描述配置标识、配置控制，配置状态记录与报告以及配置检查与评审等四方面的软件配置管理活动的需求。1.1 配置标识1.1.2 本

22、条必须详细说明软件项目的基线（即最初批准的配置标识）在软件生存周期中，主要有三种基线，它们是功能基线、分配基线和产品基线。对于每个基线，必须描述下列内容：a每个基线的项（包括应交付的文档和程序）；b与每个基线有关的评审与批准事项以及验收标准；c在建立基线的过程中用户和开发者参与情况。例如，在产品基线中，要定义的元素可以包括：a产品的名字和命名规则；b产品标识编号；c对每一个新交付的版本，要给出版本交付号、新修改的描述、修改交付的方法、对支持软件的修改要求以及对有关文档的修改要求；d安装说明；e已知的缺陷和故障；f软件媒体和媒体标识。1.1.3 本条必须描述本项目所有软件代码和文档的标题、代号、

23、编号以及分类规程例如，对代码来说：a编译日期可以作为每个交付模块标识的一部分；b在构造模块源代码的顺序行号时，应使它适合于模块作进一步的修改。1.2配置控制1.2.1 本条必须描述软件生存周期中各个阶段使用的修改批准权限的级别1.2.2 本条必须定义对已有配置的修改申请进行处理的方法其中包括：a详细说明在本计划第3.2条描述的软件生存周期各个阶段中提出修改申请的程序（可以用注上自然语言的流程图来表达）；b描述实现已批准的修改申请（包括源代码、目标代码和文档的修改）的方法；c描述软件库控制的规程，其中包括库存软件控制、对于适用基线的读写保护、成员保护、成员标识、档案维护、修改历史以及故障恢复等七

24、项规程；-可编辑修改-d如果有必要修补目标代码，则要描述其标识和控制的方法。2.工具、技术和方法本章必须指明为支持特定项目的软件配置管理所使用的软件工具、技术和方法，指明它们的目的，并在开发者所有权的范围内描述其用法。例如，可以包括用于下列任务的工具，技术和方法：a软件媒体和媒体文档的标识。b把文档和媒体置于软件配置管理的控制之下，并把它正式地交付给用户。例如，要给出对软件库内的源代码和目标代码进行控制的工具、技术和方法的描述；如果用到数据库管理系统，则还要对该系统进行描述。又如，要指明怎样使用软件库工具、技术和方法来处理软件产品的交付。c编制关于程序及其有关文档的修改状态的文档。因此必须进一

25、步定义用于准备多种级别（如项目负责人、配置控制小组、软件配置管理人员和用户）的管理报告的工具、技术方法。-可编辑修改-附件 5-可编辑修改-XXX软件维护计划摘要1. 维护范围a)改正性维护b)适应性维护c)完善性维护d)预防性维护2. 维护工作流程附件6XXX软件生存周期实施情况核查表（YY/T0708）52.201.1应维护应用本标准形成的文件并应使其成为质量记录的一部分见图241。宜依照GB/T19001-2000中4.2的要求实施。52.201.2这些文件（以下简称为风险管理文档），应根据规定的配置管理机制进行批准、发布和更改。宜依照GB/T19001-2000中的4.2.3的要求实施

26、52.201.3在整个开发生存周期中，应形成风险管理概要，并将其作为风险管理文档的一部分。其内容应包括：a)已识别的危害以及其起因b)风险情计c)用于消除或控制危害的风险所米取的安全性措施的证明d)风险控制e)验证证明通过检查风险管理文档核查其符合性52.202.1制造商应制定风险管理计划。52.202.2计划应包括以下内容：a)计划的范围，确定项目或产品以及该计划适用的开发和生存周期的各阶段；b)使用的开发生存周期（见52.203）,包括验证计划的开发生存周期的各阶段；c)依口GGB/T19001-2000中5.1的管理职责；d)风险管理过程e)审核要求52.202.3如果在开发过程中计划改

27、变，应保留更改的记录通过检查风险管文档核查其符合性52.203.1应为可编程医用电气系统的设计和开发定义开发生存周期52.203.2开发生存周期应分解为各个阶段和任务，对每一个阶段和任务都应明确定义输入和输出以及活动。52.203.3开发生存周期应包括风险管理的整个个过程。52.203.4开发生存周期应包括对文档的要求。52.203.5风险管理活动应合适地贯穿于开发生存周期中，见52.204注:在附录DDD（资料性附录）给出了一个开发生存周期的示例。通过检查风险管理文档核查其符合性。52.203.6应在开发生存周期的所有阶段和任务之内或N间的适用处，建立和维护一套明确的问题解决体系，并作为风险

28、管理文档的一部分.根据间题，该体系可具有如下特征：一定义作为开发生存周期的一部分；一允许报告潜在的或现存安全性和（或）性能方面的问题，一包括对每个问题的相关风险的评估；一确定问题分析结束的准则安全性和（或）性能方卸；一确定解决各种问题所采取的措施；一确定每一种措施的确认方法；一确定验证持续符合性的步骤。52.204.1要素应米用包括如卜要素的风险管理过程：一风险分析；一风险控制。52.204.2要求风险管理过程应贯穿于整个开发生存周期。52.204.3风险分析52.204.3.1危害分析52.204.3.1.1应按风险管理计划进行危害的识别，见52.202。52.204.3.1.2应对所有合理

29、可预见的情况进行危害识别，包括：一正常使用情况下；-可编辑修改-不止确使用情况下。j52.204.3.1.3应考虑合适的危害状况，包括：一对患者的危害；一对操作者的危害；一对维护人员的危害；一对附近人员的危害；一对环境的危害。52.204.3.1.4应考虑可能导致危害的合理可预见的事件序列。52.204.3.1.5应考虑导致危害的合适的原因，包括：一人的因素，包括入体工程学方面的限制；一硬件故障；一软件故障；一集成错误；一环境条件。52.204.3.1.6应考虑合适的事项，包括：一系统组件的兼容性，包括硬件和软件；一用户界面，包括命令语言、警告以及出错信息；用户界面和使用说明书中使用的文本的翻

30、译准确性；_针对有意或无意的人为因素影响的数据彳护；一风险（受益）准则;一第二方软件。52.204.3.1.7应米用与开发生存周期阶段相适应的危害识别方法。52.204.3.1.8所采用的方法（例:故障树分析法，失效模式和效应分析）应归档到风险管理文档中。52.204.3.1.9方法应用的结果应归档到风险管理文档中。52.204.3.1.10每个被识别的危害和引发的原因应记录在风险管理概要中。通过检查风险管理文档核查符合性52.204.3.2风险上52.204.3.2.1对每一个被识别的危害，应倩计其风1险。52.204.3.2.2风险情计应基于对每个危害发生的可能性和（或）每个危害发生后果的

31、严重度进行估计。52.204.3.2.3严重度级别分类方法应记录在风险管理文档中。52.204.3.2.4危害发生的可能性的估计方法既可以是定量的也可以是定性的，并应记录在风险管理文档中。52.204.3.2.5对每个危害，其估计的风险应记录在风险管理概要中。通过检查风险管理文档核查符合性。52.204.4风险控制52.204.4.1应控制风险以使每个已识别的危害的经估计的风险降至可接受的程度。52.204.4.2如果风险彳氐于或等于最大可容许风险，并且该风险已经尽可能合理可行地降低了，那么认为是可接受的。52.204.4.3风险控制方法应降低危害发生的可能，性或危害的严重度，或两者均降低。正

32、确实施降低风险手段的可能性，应以定，住或定量的方式说明见附录CCC（资料性附录）。52.204.4.4风险控制的方法应面向危害起因（例如，通过降低其可能性）或在危害的起因出现时采取保护措施，或者两者均采用，优先级如下：固有安全设计；一保护措施包括警报；关于剩余风险的充分的用户信息。52.204.4.5控制风险的各种要求应直接在风险管理概要中文件化或引用。52.204.4.6风险控制有效性的评价应记录在风险管理概要中。通过检查风险管理文档核查其符合性。52.205人员资格根据GB/T19001-2000中6.2.2的要求,可编程医用电气系统的设计和修改应视升-个指定的任务。通过检查相关文件核查其

33、符合性。52.206需求规格说明52.206.1对可编程医用电气系统和其对应的子系统（如可编程电子子系统）都应有需求规格说明。注:附录EEE（资料性附录）中给出了可编程医用电气系统体系结构的例子。52.206.2需求规格说明应详述与风险有美的功能。包括控制由卜列原因产生的风险的功能：a)环境条件引起的原因；b)可编程医用电气系统其他方面引起的原因；c)可能的故障。52.206.3需求规格说明中应包括确保风险控制措施圆满地降低了已识别风险的必要信息。52.207体系结构52.207.1体系结构应满足需求规格说明。52.207.2应规定可编程医用电气系统以及其子系统的体系结构。52.207.3有关

34、编程医用电气系统及其子系统体系结构规格说明应在合适处通过降低相应的危害的可能性或危害发生的严重度，或二者均降低来实现风险控制要求。52.207.4为了降低危害发生的可能性，应在体系结构规格说明的合适处利用：a)局可靠性组件；b)失效防护功能；c)冗余；d)多样性；e)防护设计；f)潜在危害影响的限制，例如限制可获得输出能量和（或）通过采用限制执行机构行程的方法。52.207.5体系结构规格说明J位考虑如卜因素：a)风险控制措施在可编程医用电气系统组件和子系统上的配置；注:子系统和部件包括：传感器、执行机构、可编程电子子系统和接口。b)组件的失效模式及效应；c)一般原因的失效；d)系统性失效；e

35、)测试时间间隔、溅试持续时间和测试诊断范围；f)可维护性；g)有意或无意的人为因素的防护。52.208设计和实现52.208.1设计应在合适处适当分解成子系统，每个子系统都应有设计和测试规格说明。52.208.2有关设计环境的描述性数据应包括在风险管理文档中。注:有关设计环境要素的本例见附录DDD（资料性附录）。52.209验证52.209.1安全要求的实现应进行验证。52.209.2应制订验证计划，说明在开发生存周期的每个阶段的安全性要求如何验证。该计划应包括：a)验证的策略、活动和技术的选择和归档；b)验证工具的选择和运用；c)验证的覆盖准则。注:关于方法和技术的实例是：一走查和检查；静态

36、（动态）分析；一白盒（黑盒）侧试。52.209.3应根据验证计划进行验证。验证活动的结果应归档、分析和评定。52.209.4风险管理概要中应包含验证的方法、技术和结果的证明。52.210确认52.210.1应进行可编程医用电气系统在预期使用条件下安全性的确认。52.210.2应制订确认计划，以表明实现了正确的安全性要求。52.210.3应根据确认计划实施确认。确认活动的结果应归档、分析和评定。52.210.4实施确认的小组负责人应独立于开发小组。52.210.5确认小组成员和设计小组成员的专业关联性应记录在风险管理文档中。52.210.6设计小组成员不能承担其设计的确认职责。52.210.7风

37、险管理文档中应包括确认的方法和结果的证明。通过检查风险管理文档核查其符合性。52.211修改52.211.1如果任何部分或全部设计是由对先前设计的修改产生，则该设计要么视为一个全新设计，则本标准的所有条款适用；要么任何先前设计文档的持续有效性应按照修改/更改程序进行评价。5.2.11.2在开发生存周期中所有的相关文件，应依照GB/T190012000中4.2.3规定或等同规定的文件控制计划，进行校订、修正、复核和批准。通过检查风险管理文档核对其符合性。52.21评定为确保可编程医用电气系统按照本标准的要求开发完成并记录在风险管理文档中，应进行评定它可由内部审核方式进行。通过检查风险管理文档核查

38、符合性。附件 8XXX软件验证与确认计划（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的任务，描述每个V&V任务要求的输入、输出、进度、进度、资源等）5.2 活动：需求V&V5.3 活动：设计V&V5.4 活动：实现V&V5.5 活动：测试V&V5.6 活动：安装和检验V&V5.7 活动：运行V&V6. V&V报告XXX软件测试文档XXXX测试计划1 测试计划标识符AP05-01032 引言2.1 目标公司XX系统的系统测试计划应该支持

39、以下目标：(1) 细化准备和进行系统测试所需要的活动。(2) 与所有负责方沟通有关他们要执行的任务以及执行任务时所安排的进度。(3) 确定用来准备计划的信息源。(4) 确定进行系统测试所需要的测试工具和环境。2.2 背景去年，XYZ公司系统和程序开发部门应公司会计部门的要求开发了一个新的通用总帐系统。与此同时，还提出要求要开发一个与该通用总帐系统接口的新的公司工资系统。管理层系统评估委员会在19*年9月批准了开发工资系统的请求，并且指定一个工资系统顾问组来确定系统需求。顾问组于19*年12月完成了一份需求陈述(AP01-01)和一份初步开发计划。2.3 范围该测试计划覆盖了公司工资系统的全部系

40、统测试，包括操作者和用户规程、以及程序和作业控制。除了综合性多程序功能性测试外，还应评估外部接口、安全、恢复和性能。2.4 引用文件下列文档用作该测试计划的信息源：公司工资系统初步开发计划(AP01-02)公司工资系统授权(AP01-03)公司工资系统最终开发计划(AP01-06)公司工资系统质量倮证计划(AP01-08)公司工资系统配置管理计划(AP01-09)XYZ公司系统开发标准及规程(XYZ01-0100)公司通用总帐系统设计描述(AG01-04)公司通用总帐系统测试计划(AG05-01)3 测试项组成公司工资系统的所有项在系统测试期间应予测试。待测试的版本应由配置管理员放在合适的库中

41、。-可编辑修改-管理员还应控制对受试版本的更改，并且将可提供新版本的时间通知测试组。以下文档为规定正确的操作建立基础：公司工资系统需求规格说明(AP01-01)公司工资系统设计描述(AP01-04)公司工资系统参考手册(AP02-01)公司工资系统模块参考手册(AP02-03)GB/T 9386-2008要测试的各项列出如下：3.1 程序模块要测试的程序模块按以下规则来标识：类型库成员名称源代码SOURLIB1AP0302AP0305可执行代码MACLIBIAP0301AP0302AP03053.2 作业控制规程类型库成员名称应用程序PROCLIBlAP0401分类PROCLIB1AP0402

42、实用程序PROCLIBIAP0403应用程序、分类和实用程序的控制规程标识如下：3.3用户规程公司工资系统用户事务参考手册(AP02-04)中规定的在线规程应予测试。3.4操作者规程系统测试包括公司工资系统操作参考手册(AP02-02)中规定的规程。4 要测试的特征以下清单列出待测试的特征：测试设计说明编号描述AP06-01数据库转换AP06-02月薪雇员全面的工资处理AP06-03计时雇员全面的工资处理AP06-04所有雇员全面的工资处理AP06-05定期报告AP06-06通用总帐事务的建立-可编辑修改-AP06-07安全AP06-08恢复AP06-09性能5 不要测试的特征下列特征不应包括

43、在系统测试中，因为它们在系统初始安装时不会使用。平等就业机会委员会符合性报告内部培训进度报告工资业绩审查报告二期开发阶段文档集应包含关于这些特征的一个测试计划。测试用例将不会覆盖正在受试的事务或者报告中所有可能的选项组合。只有目前XYZ公司工资处理明确需求的组合应予测试。6 方法测试人员应根据系统文档集准备所有的测试设计、用例以及规程说明。这种方法应验证测试所覆盖那些领域的文档集信息的准确性和综合性。公司工资和会计部门的人员应协助开发测试设计和测试用例，这样做有助于确保测试能体现系统的实际使用。为了确保保密性，从会计文件中选取的所有测试数据应含有已更改的保密敏感字段。6.1 转换测试除了计算输

44、入和输出的记录外，转换数据库的有效性应以两种方式进行验证。第一种验证方法涉及到使用必须由开发组建立的“数据库审核员”功能。当针对被转换数据库运行时，数据库审核员应核对一条记录内的数值范围，以及要求的各条记录之间的关系。第二种验证方法涉及到随机选取旧记录的一个小的子集，然后直接与新记录的相对应子集进行比较。直接比较的数目“c”和旧记录的数目“r”必须加以规定。从1至1Jr的范围内产生由随机数字组成的c集合。在转换过程中，该集合应予以分类和应用，以驱动对宣接比较记录的选择。注：同样的两种验证方法在实际的转换期间应予采用。6.2 作业流测试月薪雇员和计时雇员的记录综合集以及这两种记录的合并集应用于测

45、试工资处理。标准的作业流测试方法应予采用。每种定期报告作业流至少运行一次。6.3 接口测试为了测试工资系统与通用总帐系统之间的接口，工资系统应建立一个通用总帐事务综合集。这些事务应输入到通用总帐测试系统。生成的通用总帐条目必须加以选取、打印并与由工资系统准备的通用总帐事务的打印输出相比较。6.4 安全测试无妥当口令但又试图访问在线数据条目并显示事务的情况应予测试。6.5 恢复测试在可单独运行的时间内，通过停机且随后依照恢复规程进行恢复测试。6.6 性能测试依据性能要求(AP01-01),通过利用产生的数据量测量若干作业的运行时间，以此来评估性能。6.7 回归测试假设为了测试在系统测试期间做过的

46、程序修改，则应对系统进行若干次重复测试。对系统的每一新版本应做一次回归测试，从而检测由于程序修改所导致的意想不到的影响。应通过对新版本执行前一版本曾执行的那些所有测试来完成回归测试，然后对由此得到的结果文件进行比较。标准的比较器程序(UT08-0100)应予采用，以便比较所有的系统输出。6.8 综合性公司工资系统参考手册(AP02-01)中描述的每个系统特征至少应有一份相关联的测试设计说明。公司工资系统用户事务参考手册(AP02-04)中所规定的每个用户规程至少应予测试一次。公司工资系统操作手册(AP02-02)中规定的每个操作规程至少也应予测试一次。另外，每个作业控制规程至少应予执行一次。对

47、于关联到上述每个领域的测试设计说明，应采用覆盖矩阵予以核查。6.9 约束公司工资系统的最终执行日期定于19*年8月31号。必须符合这个日期，因为新的ABC部门将于9月1日开始全面运行，必须拥有这个系统方能向其雇员发放工资。7 测试项通过准则该系统必须符合XYZ公司系统开发标准和规程(XYZ01-0100)中陈述的系统通过失败的标准需求。该系统还必须满足下列需求：内存需求一定不要大于真实存储量64k。用户规程与其他会计系统的一致性必须使工资主管满意。8 暂停准则和恢复要求8.1 暂停准则不能转换雇员信息数据库会导致所有测试活动的暂停。8.2 恢复要求出现测试暂停后，当系统的新版本向测试组传递时，

48、6.7条中描述的回归测试应予执行。9 测试交付项(1) 系统测试组应形成下列文档，这些文档在测试结束后交付给配置管理组。测试文档系统测试计划；系统测试设计说明；系统测试用例说明；系统测试规程说明；系统测试日志；系统测试事件报告日志；系统测试事件报告；系统测试总结报告。测试数据：所有数据录入、查询屏幕和回答屏幕的拷贝都应附在相关的测试用例文档中。(2) 输入和输出测试文件的拷贝应交付给配置管理组。(3) 最终执行每个测试规程的打印输出的缩微胶片拷贝，应与测试文档集一起交付给配置管理组。1.1 0测试任务见附件A的任务列表。1.2 1环境要求1.3 1硬件测试应在XYZ公司的硬件配置下进行。鉴于大

49、多数测试必须在主要的操作时间内开展，在此期间内应向测试组提供3个在线终端。1.4 2软件1.4.1 1操作系统该业务操作系统应用于执行这些测试。1.4.2 2通信软件所有在线程序应在测试通信软件的控制下加以测试。1.5 3安全性安全性应限于现有的各种控制器。1.6 4工具开发和评估系统测试需要下列测试工具：(1) 测试数据生成器(UT09-0200)。该程序用于生成绝大多数的测试数据。它位于标准系统库SYSLIBA。(2) 比较器程序(UT08-0100)。该程序用于在回归测试期间比较系统结果。它位于标准系统库SYSLIBA中。(3)数据库审核器。该程序用于审核数据库中的数值范围及记录之间的相

50、互关系。它须由开发组提供。1.7 5出版物需要下列文档支持系统测试：公司工资系统需求陈述（AP01-01）公司工资系统设计描述（AP01-04）一公司工资系统参考手册（AP02-01）公司工资系统操作手册（AP02-02）公司工资系统模块参考手册（AP02-03）公司工资系统用户事务参考手册（AP02-04）12 职责下列各组对测试各部分负有责任。12.1 系统测试组该组对测试及技术测试业务进行全面管理。12.2 公司工资部门该组是公司工资系统的终端用户，在下列各项活动中应协助系统测试组工作。审查测试设计说明；执行在线测试；校验输出屏幕和报告。12.3 项目开发组该组传递要测试的系统，并响应系

51、统测试事件报告。该组对需要排错的任何程序进行调试，并提供数据库审核器。13 人员和培训要求13.1 人员配备需要下列人员开展该测试项目：13.1.1 测试组测试经理1高级测试分析员1测试分析员2测试技术员113.1.2 工资部门工资监管人员113.2 培训公司工资部门的人员必须经过培训，以便对数据录入事务进行处理。用户事务参考手册（AP02-04）应作为该培训的基础。14进度见附录A的任务列表。硬件，软件和测试工具应用于从19*年6月1日到19*年8月1日期间的测试。15风险和应急如果系统故障严重地影响测试进度，开发经理已同意分派一名全职人员到测试组做调试工作。如果一位工资监管人员对于测试工作

52、不够用，工资经理已同意确定第二位监管人员。如果硬件出现的问题影响系统在白天的应用，则测试组应安排其夜晚的活动。公司工资系统的第一次运行使用，在分发工资支票前必须详细地加以核查，并对住何出错的支票须用手工进行修正。16批准测试经理：日期:开发项目经理：日期:质量保证经理：日期:附加A任务列表任务前期任务特殊技能责任投入完成日期(1)准备测试计划结束工资系统设计描述(AP01-04)和初步的开发计戈ij(AP01-02)一测试经理；高级测试分析员4(人日)XX-01-21(2)准备测试设计说明任务1通晓公司的工资规程高级测试分析员9XX-04-01(3)准备测试用例说明结束相应的测试设计(任务2)

53、一测试分析员4XX-04-15(4)准备测试规程说明结束相应的测试用例(任务3)一测试分析员6XX-05-15(5)建立最初的雇员信息数据库任务4一测试分析员6xx-06-01(6)结束测试项传递并向测试组传递该公司的工资系统结束集成测试一开发项目经理一xx-06-01(7)检查执行该系统需要的所用工作控制规程任务6工作控制经验测试分析员1xx-06-08(8)组装并链接该公司工资系统任务6一测试分析员1xx-06-08(9)执行数据录入任务5一测试分析1xx-06-22测试规程任务8员(10)执行批测试规程任务5任务8一测试分析员3xx-06-30(11)检查批测试规程任务10通晓工资报告需

54、求测试分析员1XX-07-02(12)解决测试事件报告任务9任务11一开发组经理；系统测试组经理；公司的工资部门经理2XX-07-16(13)重复任务(6)(12)直到所有测试规程成功运行任务12一一2XX-07-30(14)撰写系统测试总结报告任务13一系统测试组经理；公司工资部门经理1xx-08-06(15)将所有测试文档集和测试数据传输给配置管理组任务14一系统测试组1xx-08-06XXX测试报告1 .引言1.1 标识1.2 系统概述1.3 文档概述2 .引用文件3 .测试结果概述3.1 对被测试软件的总体评估3.2 测试环境的影响3.3 改进建议4 .详细的测试结果4.1 XXX项目4.1.1 测试结果小结4.1.2 遇到的问题4.1.2.1 测试用例的项目唯一性标识符4.1.2.2 （逐个标识）4.1.3 与测试用例/测试过程的偏差4.1.3.1 测试用例的项目唯一性标识符4.1.3.2 （逐个标识）5.测试记录日期时间地点硬件配置软件配置测试活动测试结果测试人