医疗器械软件描述文档

医疗器械软件描述文档1. 基本信息1.1. 产品标识软件名称：软件型号：软件版本号：软件制造商：软件生产地址：1.2. 安全性级别软件的安全性级别为A/B/C级。理由如下：a）软件的预期用途为：b）软件的功能包括：c）如果软件失效，可能导致以下后果（按软件各功能失效逐条描述，如果软件失效的时候由硬件降 低失效后果或危害发生概率，可以做说明，并由此降低安全性级别：1）2）3）1.3. 结构功能1.3.1. 组成模块、各模块功能及模块相互关系依据软件设计规格给出体系结构图（如图1.3-1 所示）。嵌入式软件（SDS）体系结构图一一示例1独立式软件（SDS）体系结构图示例2图 1.3-1 XXX 体系结构图1.3.2 各模块功能说明系统主要由 XXXXXX 模块组成。各模块功能简介如下：产品名称版本号模块名称软件功能项目功能说明一级功能二级功能三级功能模块名称软件功能项目功能说明一级功能二级功能三级功能注：1、每个软件模块一份表单。2 、软件功能项目列表需列出与测试相关的所有功能（包括各级子功能）。3、功能说明栏目应填写：功能项目概述、边界值规定（数据有效性）、安全说明等信息4 、功能列表上所列出来的功能必须是可以实现或演示的。5 、功能名称与软件、文档保持一致。6、软件功能项目列表根据需要列出（可增加或删减子功能列）。1.3.2. 用户界面设计采用广泛应用的图形用户界面（GUI）,即诸如窗口、菜单、对话框、滚动条等。用户主界面见图1.3-2。图 1.3-2 XXX 用户主界面1.3.3. 外部接口XXX 可使用 VISUALC+ 提供的对 SQLSERVER 的接口，进行对数据库的所有访问。XXX 可使用 SQL SERVER 的对数据库的备分命令，以做到对数据的保存。在网络软件接口方面，使用一种无差错的传输协议，采用滑动窗口方式对数据进行网络传输及接收1.4. 硬件关系1.4.1. 物理拓扑图嵌入式软件物理拓扑关系表格形式示例1硬件软件分类零件种类功能显示部分血压显示7工具LED血压值显示最高血压?最低血压、脉拍艺表示时刻显示7工具LED时刻显示显示现在时刻压力单位显示LEDmmHg / kPa 显示显示血压值以及压力值的单位开关部分开始/关闭开关开始/关闭开关读取控制开始测量血压测量时停止测量背面功能设定开关背面功能设定开关读取控制时刻的设定等、主机功能设定的更 改打印部分打印切纸打印控制测量结果的打印、打印后切纸血压测量部分泵、电磁阀、压力传感器血压测定控制测量时加压、减压控制、脉搏信号 处理以及测量值的确定安全监视用压力传感器压力安全检测控制压力监测、急排控制袖带驱动部分袖带驱动用马达袖带控制袖带的卷曲、固定、开放语音部分扬声器语音控制测量通知外部进出力部串行通信串行进出力测量结果出力、指令输入记忆存储U盘设定值记忆存储控制功能设定内容的保持嵌入式软件物理拓扑关系表格形式示例2独立式软件物理拓扑关系表格形式示例3图 1.4-1 物理拓扑图1.4.2. 连接关系描述与 PC 连接 与医疗器械硬件连接1.5. 运行环境1.5.1. 硬件配置 处理器: 储存器 外设器件 输入/输出设备1.5.2. 软件环境系统软件支持软件必备软件选配软件杀毒软件1.5.3. 网络条件网卡：网络类型:网络架构：1.6. 适用范围 独立软件：软件的适用范围和适用人群。软件组件：同医疗器械产品的适用范围和适用人群1.7. 禁忌症 独立软件：软件的禁忌症和不适用人群。软件组件：同医疗器械产品的禁忌症和不适用人群。1.8. 上市历史（软件组件写医疗器械的上市历史）（表格形式）国产首次注册示例：该医疗器械，产品名称为XXXXX,据产品结构及预期用途，按医疗器械分类目录分为6870类软件， 按照二/三类医疗器械进行首次注册。进口（首次/重新）该医疗器械作为 XXX 的组件，在中国（首次/重新）申请上市。依据产品结构及预期用途，按医疗 器械分类目录分为 68xx-xx 类。上市历史详情见下表：上市国家管理类别上市时间版本号现版本号原产国（中国）欧洲（如有）美国（如有） 2. 实现过程2.1 开发综述我司于 XXXX 年 XX 月开始 XX 软件的开发工作。整个开发过程包括可行性研究和项目开发计划、需求 分析、概要设计、详细设计、编码、集成、测试等6 个阶段，并编制相应开发文档。本软件开发采用 XXXX 模型。在开发过程中，采用的语言、工具和方法分别为：a）语言：本软件开发采用 XX 语言；b）工具： 软件需求工具：XXXXX，版本：XXXXXX，来源（制造商）：XXXXXX； 设计工具： 构造工具： 测试工具： 维护工具： 配制管理工具：缺陷管理工具：c）开发方法：本软件采用XXXXX方法；在开发过程中，开发人员为XXX人，开发时间为XX月，工作量为XXXX人月。代码行共XXXX行，控制文档XXXX个。2.2 风险管理风险管理报告全文，见附件1。XXX风险管理报告（文件号：XXX版本：XXX2.3 需求规格 （SRS）需求规格说明书（SRS）全文，见附件2。需求规格说明书（文件号：XXX版本：XXX2.4 生存周期软件开发计划（SDP）摘要见附件3。软件配制管理计划（SCMP）摘要见附件4。软件维护计划摘要见附件5。生存周期实施情况核查表见附件6。2.5 验证与确认软件验证与确认计划见附件7。在软件开发过程中，进行了以下测试：测试测试文档XXX单元测试XXX单元测试计划XXX单元测试报告各测试文档详见附件82.6 缺陷管理缺陷管理流程为：剩余缺陷描述、严重度、整改计划为：软件版本的命名规则：软件的版本号为的形式，版本号中，第一位是XX,代表：XXXX,第二位 是XX，代表本软件修订历史序号软件版本修订日期修订类型变更内容描述1232.8 临床评价参考医疗器械软件描述文档 附件 9 “临床评价报告（文件号： XXX 版本号 XXX）”。与注册资料 7 临床评价资料一致。3 核心算法概述算法类型：公认成熟算法：公开文献专利标准、原理简单明确、上市超过四年且无不良事件。公认成熟算法列明 名称、原理、用途，全新算法列明名称、原理、用途，并提供验证资料。全新算法：源自科学研究和临床数据内容：实质首次注册：所有核心算法实质重新注册：新增核心算法附件1XXX 风险管理报告附件2XXX需求规格说明书(SRS)1. 引言1.1 编写目的为了明确“XXXXX”项目的需求，为用户和分析设计人员之间的交流提供方便，更好地安排项目规划与 进度，组织软件开发与测试，减少项目风险，撰写本需求规格规格说明书。本需求规格说明书的读者为项目经理、分析设计人员、程序员、质量保证人员、维护人员以及客户方的相关人员。1.2 项目背景1.3 定义GB/T 11457 所列术语和下列定义适用于本指南。合同：指 XXXX 共同签署的关于本项目的合同。客户：指 XXXX 公司。 语言：是指具有语法和语义的通信工具，包括一组表达式、惯例和传递信息的有关规则。 编程语言：是指用于编写源程序的高级语言和汇编语言。用户：XXXXXX1.4 参考资料a) GB/T 11457 软件工程术语b) GB 8566 计算机软件开发规范c) GB 8567 计算机软件产品开发文件编制指南d) 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) 应用目标：XXXX2.1.2 产品描述(描述产品的基本要求、主要部分、外部接口等可使用框图展示较大系统的主要部分、相互关系外部接口等)2.1.2.1 软件系统总体结构图采用基于采用 MVC 模式架构的开发方式，实现的系统具有界面美观、操作简单、开发系统容易升级系统开发周期短、成本低等优点。在项目的研发中，从体系结构上将本系统设计为4层结构：系统结构图(结构图说明)2.1.2.3 系统功能的总体用况图 (图示及说明)2.1.2.4 约束：a）系统接口； （列出每个系统接口，识别完成系统需求的软件功能以及与系统匹配的接口描述。）b）用户界面；（如要求的屏幕显示格式、页面、版式、报告内容、菜单内容等）c）硬件接口；（如支持的设备，采用的协议等）d）软件接口；（与其他软件的接口，软件应提供名称、助记符、规格说明编号、版本号、来源，接口软件的目的 等）e）通信接口；（如局域网协议等）f）内存约束；（对主存、辅存的任何使用特征和限制）g）运行；（如用户引发的操作、交互操作的周期、无人值守操作的周期、数据处理支持能力、备份和回复操作）h）现场适应性需求（给定现场、任务和运行模式的需求）2.2 产品功能描述软件的将执行主要功能的概要。（可用文本或图示的方法，显示不同功能及其之间的关系，显示 变量之间的逻辑关系）2.3 用户的特点a）管理员：。b）用户1：c）用户2：2.4 约束条件经费限制：时间限制：硬件局限： 方法、技术、环境 法规： 标准：并行操作：审核功能：3. 具体需求3.1 外部接口各接口描述包括以下内容：a) 项的名称；b) 目的描述；c) 输入源和输出目的地；d) 有效范围、准确度和容限e) 测量单位；f) 定时；g) 与其他输入/输出的关系；h) 屏显格式；i) 窗口格式；j) 数据格式；k) 命令格式；l) 结束消息。3.1.1.2 硬件接口3.1.1.3 软件接口3.1.1.4 通信接口3.2 功能需求3.2.1 用户注册功能系统应能完成用户注册功能 主参加者：用户 环境目标： 前置条件：数据库有足够的空间。 触发器：用户进入注册界面。A 场景：a)用户进入注册界面。b)用户输入会员名。c)用户输入登录密码。d)用户输入确认密码。e)用户输入其他个人基本信息。f)用户输入验证码。g)点击确认按钮，提交注册信息 异常：a) 用户注册的会员名已在系统中存在时，给出提示信息，让其更改所输入的会员名。b) 用户输入的确认密码与登录密码不一致时，给出提示信息，让其重新输入密码。c) 用户输入的验证码错误时，给出提示信息，随机更换验证码的图片后，让其重新输入验证码 优先级：必须被实现。 何时可用：首次开发。使用频率：每天多次。 后置条件：用户完成操作后显示注册成功信息。 活动图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) 对注册过的用户个人信息的严格保密，除用户自己以及管理员之外，其他人不能查阅用户信息b) 对数据传输过程需有严格的保密机制，防止用户数据的泄露。c) 对于管理员要分发给管理数据库的权限。3.6.4 可维护性XXX软件开发计划（SDP）摘要1. 引言本条应简述本文档适用的系统和软件的用途，它应描述系统和软件的一般特性；概述系统开发、运行 和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；列出 其他有关的文档。2. 实施整个软件开发活动的计划2.1软件开发过程本条应描述要采用的软件开发过程。计划应覆盖论及它的所有合同条款，确定已计划的开发阶段（适 用的话）、目标和各阶段要执行的软件开发活动。2.2软件开发总体计划2.2.1 软件生存周期描述预期采用的生存周期模型，并进行说明2.2.2 软件开发方法本条应描述或引用要使用的软件开发方法，包括为支持这些方法所使用的手工、自动工具和过程的描 述。该方法应覆盖论及它的所有合同条款。2.2.3 可重用的软件产品本条应描述标识、评估和吸纳可重用软件产品要遵循的方法，包括搜寻这些产品的范围和进行评估的 准则。描述应覆盖合同中论及它的所有条款。在制定或更新计划时对已选定的或候选的可重用的软件产品 应加以标识和说明，（若适用）同时应给出与使用有关的优点、缺陷和限制。2.2.4 处理关键性需求本条应分以下若干条描述为处理指定关键性需求应遵循的方法。描述应覆盖合同中论及它的所有条款3. 进度表和活动网络图本章应给出：a 进度表，标识每个开发阶段中的活动，给出每个活动的初始点、提交的草稿和最终结果的可用性、 其他的里程碑及每个活动的完成点；b 活动网络图，描述项目活动之间的顺序关系和依赖关系，标出完成项目中有最严格时间限制的活动。4. 项目组织和资源4.1 项目组织本条应描述本项目要采用的组织结构，包括涉及的组织机构、机构之间的关系、执行所需活动的每个 机构的权限和职责。4.2项目资源本条应描述适用于本项目的资源。（若适用）应包括：a. 人力资源，包括：1）估计此项目应投入的人力（人员时间数）；2）按职责（如：管理，软件工程，软件测试，软件配置管理，软件产品评估，软件质量保证和软 件文档编制等）分解所投入的入力；3）履行每个职责人员的技术级别、地理位置和涉密程度的划分；b. 开发人员要使用的设施，包括执行工作的地理位置、要使用的设施、保密区域和运用合同项目的 设施的其他特性；c. 为满足合同需要，需方应提高的设备、软件、服务、文档、资料及设施，给出一张何时需要上述 各项的进度表；d. 其他所需的资源，包括：获得资源的计划、需要的日期和每项资源的可用性。XXX软件配置管理计划（SCMP ）摘要1. 软件配置管理活动 本章描述配置标识、配置控制，配置状态记录与报告以及配置检查与评审等四方面的软件配置管理活动的需求。1.1 配置标识1.1.1 本条必须详细说明软件项目的基线（即最初批准的配置标识） 在软件生存周期中，主要有三种基线，它们是功能基线、分配基线和产品基线。对于每个基线，必须描述下列内容：a 每个基线的项（包括应交付的文档和程序）；b 与每个基线有关的评审与批准事项以及验收标准；c 在建立基线的过程中用户和开发者参与情况。 例如，在产品基线中，要定义的元素可以包括：a 产品的名字和命名规则；b 产品标识编号；c 对每一个新交付的版本，要给出版本交付号、新修改的描述、修改交付的方法、对支持软件的 修改要求以及对有关文档的修改要求；d 安装说明；e 已知的缺陷和故障；f 软件媒体和媒体标识。1.1.2 本条必须描述本项目所有软件代码和文档的标题、代号、编号以及分类规程 例如，对代码来说：a 编译日期可以作为每个交付模块标识的一部分；b 在构造模块源代码的顺序行号时，应使它适合于模块作进一步的修改。1.2 配置控制1.2.1 本条必须描述软件生存周期中各个阶段使用的修改批准权限的级别1.2.2 本条必须定义对已有配置的修改申请进行处理的方法其中包括：a 详细说明在本计划第3.2 条描述的软件生存周期各个阶段中提出修改申请的程序（可以用注上自 然语言的流程图来表达）；b 描述实现已批准的修改申请（包括源代码、目标代码和文档的修改）的方法；c 描述软件库控制的规程，其中包括库存软件控制、对于适用基线的读写保护、成员保护、成员 标识、档案维护、修改历史以及故障恢复等七项规程；d 如果有必要修补目标代码，则要描述其标识和控制的方法。2. 工具、技术和方法本章必须指明为支持特定项目的软件配置管理所使用的软件工具、技术和方法，指明它们的目的，并 在开发者所有权的范围内描述其用法。例如，可以包括用于下列任务的工具，技术和方法：a 软件媒体和媒体文档的标识。b 把文档和媒体置于软件配置管理的控制之下，并把它正式地交付给用户。例如，要给出对软件 库内的源代码和目标代码进行控制的工具、技术和方法的描述；如果用到数据库管理系统，则还要对该系 统进行描述。又如，要指明怎样使用软件库工具、技术和方法来处理软件产品的交付。c 编制关于程序及其有关文档的修改状态的文档。因此必须进一步定义用于准备多种级别（如项 目负责人、配置控制小组、软件配置管理人员和用户）的管理报告的工具、技术方法。XXX 软件维护计划摘要1. 维护范围a) 改正性维护b) 适应性维护c) 完善性维护d) 预防性维护2. 维护工作流程XXX软件生存周期实施情况核査表(YY/T 0708)应维护应用本标准形成的文件并应使 其成为质量记录的一部分;见图241。 宜依照GB/T 19001-2000中4. 2的要求实施。在整个开发生存周期中，应形成风险 管理概要，并将其作为风险管理文档 的一部分。其内容应包括：a)已识别的危害以及其起因b)风险估计c)用于消除或控制危害的风险所采取的 安全性措施的证明d)风险控制e)验证证明通过检查风险管理文档核查其符合性制造商应制定风险管理计划。52.202. 2计划应包括以下内容：a)计划的范围，确定项目或产品以及该 计划适用的开发和生存周期的各阶 段；b)使用的开发生存周期(见52.203)，包括验证计划的开发生存周期的各阶段；c)依照GB/T 19001-2000中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 （资料性附录）给出了一 个开发生存周期的示例。通过检查风险管理文档核查其符合 性。应在开发生存周期的所有阶段和任务 之内或之间的适用处，建立和维护一 套明确的问题解决体系，并作为风险 管理文档的一部分.根据间题，该体系 可具有如下特征：定义作为开发生存周期的一部分；允许报告潜在的或现存安全性和 （或）性能方面的问题，包括对每个问题的相关风险的评估；确定问题分析结束的准则安全性 和（或）性能方面；确定解决各种问题所米取的措施；确定母种扌曰施的确认方法；一确定验证持续符合性的步骤。52 .204.1要素应米用包括如下要素的风险管理过程：风险分析；风险控制。要求风险管理过程应贯穿于整个开发生存 周期。风险分析危害分析应按风险管理计划进行危害的识别， 见 52.202。应对所有合理可预见的情况进行危害 识别，包括：正常使用情况下；不正确使用情况下。52.204.3 .1.3应考虑合适的危害状况，包括：对患者的危害；对操作者的危害；一对维护人员的危害；对附近人员的危害；对环境的危害。应考虑可能导致危害的合理可预见的 事件序列。应考虑导致危害的合适的原因，包括：人的因素，包括入体工程学方面的 限制；硬件故障；软件故障；集成错误；环境条件。应考虑合适的事项，包括：系统组件的兼容性，包括硬件和软件；用户界面，包括命令语言、警告以 及出错信息；用户界面和使用说明书中使用的文 本的翻译准确性；针对有意或无意的人为因素影响的 数据保护；风险（受益）准则；第二方软件。应采用与开发生存周期阶段相适应的 危害识别方法。所采用的方法（例:故障树分析法，失效 模式和效应分析）应归档到风险管理文 档中。方法应用的结果应归档到风险管理文 档中。每个被识别的危害和引发的原因应记 录在风险管理概要中。通过检查风险管理文档核查符合 性风险估计对每一个被识别的危害，应估计其风 险。风险估计应基于对每个危害发生的可 能性和（或）每个危害发生后果的严重 度进行估计。严重度级别分类方法应记录在风险管 理文档中。危害发生的可能性的估计方法既可以 是定量的也可以是定性的，并应记录 在风险管理文档中。对每个危害，其估计的风险应记录在 风险管理概要中。通过检查风险管理文档核查符合 性。风险控制应控制风险以使每个已识别的危害的 经估计的风险降至可接受的程度。如果风险低于或等于最大可容许风 险，并且该风险已经尽可能合理可行 地降低了，那么认为是可接受的。风险控制方法应降低危害发生的可能 性或危害的严重度，或两者均降低。正确实施降低风险手段的可能 性，应以定性或定量的方式说明;见附 录CCC（资料性附录）。风险控制的方法应面向危害起因（例 如,通过降低其可能性）或在危害的起 因出现时采取保护措施，或者两者均 米用，优先级如下：固有安全设计；保护措施包括警报；关于剩余风险的充分的用户信息。控制风险的各种要求应直接在风险管 理概要中文件化或引用。风险控制有效性的评价应记录在风险 管理概要中。通过检查风险管理文档核查其符合 性。52.205人员资格通过检查相关文件核查其符合性。52.206需求规格说明对可编程医用电气系统和其对应的子 系统（如可编程电子子系统）都应有需 求规格说明。注:附录EEE （资料性附录）中给出 了可编程医用电气系统体系结构的例 子。52.206. 2需求规格说明应详述与风险有关的功 能。包括控制由下列原因产生的风险 的功能：a)环境条件引起的原因；b)可编程医用电气系统其他方面引起的 原因；c)可能的故障。需求规格说明中应包括确保风险控制 措施圆满地降低了已识别风险的必要 信息。52.207体系结构体系结构应满足需求规格说明。应规定可编程医用电气系统以及其子 系统的体系结构。有关编程医用电气系统及其子系统体 系结构规格说明应在合适处通过降低 相应的危害的可能性或危害发生的严 重度，或二者均降低来实现风险控制 要求。为了降低危害发生的可能性，应在体 系结构规格说明的合适处利用：a)咼可靠性组件；b)失效防护功能；c)冗余；d)多样性；e)防护设计；f)潜在危害影响的限制，例如限制可获 得输出能量和（或）通过采用限制执 行机构行程的方法。体系结构规格说明应考虑如下因素：a)风险控制措施在可编程医用电气系统 组件和子系统上的配置；注:子系统和部件包括:传感器、执行机 构、可编程电子子系统和接口。b)组件的失效模式及效应；c)一般原因的失效；d)系统性失效；e)测试时间间隔、溅试持续时间和测试 诊断范围；f)可维护性；g)有意或无意的人为因素的防护。52.208设计和实现设计应在合适处适当分解成子系统， 每个子系统都应有设计和测试规格说 明。有关设计环境的描述性数据应包括在 风险管理文档中。注:有关设计环境要素的示例见附录 DDD（资料性附录）。52.209验证安全要求的实现应进行验证。应制订验证计划，说明在开发生存周 期的每个阶段的安全性要求如何验 证。该计划应包括：a)验证的策略、活动和技术的选择和归档；b)验证工具的选择和运用；c)验证的覆盖准则。注:关于方法和技术的实例是：走杳和检杳：静态（动态）分析；白盒（黑盒）侧试。应根据验证计划进行验证。验证活动 的结果应归档、分析和评定。风险管理概要中应包含验证的方法、 技术和结果的证明。52.210确认应进行可编程医用电气系统在预期使 用条件下安全性的确认。应制订确认计划，以表明实现了正确 的安全性要求。应根据确认计划实施确认。确认活动 的结果应归档、分析和评定。实施确认的小组负责人应独立于开发 小组。确认小组成员和设计小组成员的专业 关联性应记录在风险管理文档中。设计小组成员不能承担其设计的确认 职责。风险管理文档中应包括确认的方法和 结果的证明。通过检查风险管理文档核查其符合 性。52.211修改如果任何部分或全部设计是由对先前 设计的修改产生，则该设计要么视为 一个全新设计，则本标准的所有条款 适用;要么任何先前设计文档的持续有 效性应按照修改/更改程序进行评价。通过检查风险管理文档核对其符 合性。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的任务，描述每个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公司系统和程序开发部门应公司会计部门的要求开发了一个新的通用总帐系统。与此同时， 还提出要求要开发一个与该通用总帐系统接口的新的公司工资系统。管理层系统评估委员会在19*年9月批准了开发工资系统的请求，并且指定一个工资系统顾问组来确 定系统需求。顾问组于19*年12月完成了一份需求陈述(AP01-01)和一份初步开发计划。2.3 范围该测试计划覆盖了公司工资系统的全部系统测试，包括操作者和用户规程、以及程序和作业控制。除 了综合性多程序功能性测试外，还应评估外部接口、安全、恢复和性能。2.4 引用文件下列文档用作该测试计划的信息源：公司工资系统初步开发计划(AP01-02)公司工资系统授权(AP01-03)公司工资系统最终开发计划(AP01-06)公司工资系统质量倮证计划(AP01-08)公司工资系统配置管理计划(AP01-09)XYZ公司系统开发标准及规程(XYZ01-0100)公司通用总帐系统设计描述(AG01-04)公司通用总帐系统测试计划(AG05-01)3测试项组成公司工资系统的所有项在系统测试期间应予测试。待测试的版本应由配置管理员放在合适的库中 管理员还应控制对受试版本的更改，并且将可提供新版本的时间通知测试组。以下文档为规定正确的操作建立基础：公司工资系统需求规格说明(AP01-01)公司工资系统设计描述(AP01-04)公司工资系统参考手册(AP02-01)公司工资系统模块参考手册(AP02-03)GB/T 9386-2008要测试的各项列出如下：3.1 程序模块要测试的程序模块按以下规则来标识：类型 库 成员名称源代码SOURLIB1 AP0302AP0305可执行代码MACLIBIAP0301AP0302AP03053.2 作业控制规程应用程序、分类和实用程序的控制规程标识如下：类型应用程序PROCLIBlAP0401分类PROCLIB1AP0402成员名称实用程序PROCLIBIAP04033.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 不要测试的特征 下列特征不应包括在系统测试中，因为它们在系统初始安装时不会使用 平等就业机会委员会符合性报告内部培训进度报告 工资业绩审查报告 二期开发阶段文档集应包含关于这些特征的一个测试计划。测试用例将不会覆盖正在受试的事务或者报告中所有可能的选项组合。只有目前XYZ公司工资处理明确 需求的组合应予测试。6 方法测试人员应根据系统文档集准备所有的测试设计、用例以及规程说明。这种方法应验证测试所覆盖那些 领域的文档集信息的准确性和综合性。公司工资和会计部门的人员应协助开发测试设计和测试用例，这样做有助于确保测试能体现系统的实际 使用。为了确保保密性，从会计文件中选取的所有测试数据应含有已更改的保密敏感字段。6.1 转换测试除了计算输入和输出的记录外，转换数据库的有效性应以两种方式进行验证。第一种验证方法涉及到 使用必须由开发组建立的“数据库审核员”功能。当针对被转换数据库运行时，数据库审核员应核对一条 记录内的数值范围，以及要求的各条记录之间的关系。第二种验证方法涉及到随机选取旧记录的一个小的子集，然后直接与新记录的相对应子集进行比较。 直接比较的数目“c”和旧记录的数目“r”必须加以规定。从1到r的范围内产生由随机数字组成的c集 合。在转换过程中，该集合应予以分类和应用，以驱动对宣接比较记录的选择。注：同样的两种验证方法在实际的转换期间应予采用。6.2 作业流测试月薪雇员和计时雇员的记录综合集以及这两种记录的合并集应用于测试工资处理。标准的作业流测试 方法应予采用。每种定期报告作业流至少运行一次。6.3 接口测试为了测试工资系统与通用总帐系统之间的接口，工资系统应建立一个通用总帐事务综合集。这些事务 应输入到通用总帐测试系统。生成的通用总帐条目必须加以选取、打印并与由工资系统准备的通用总帐事 务的打印输出相比较。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 号。必须符合这个日期，因为新的 ABC 部门将于 9 月 1 日开始全面运行，必须拥有这个系统方能向其雇员发放工资。7 测试项通过准则该系统必须符合XYZ公司系统开发标准和规程(XYZ01-0100)中陈述的系统通过/失败的标准需求。该系统还 必须满足下列需求：内存需求一定不要大于真实存储量64k。用户规程与其他会计系统的一致性必须使工资主管满意。8 暂停准则和恢复要求8.1 暂停准则不能转换雇员信息数据库会导致所有测试活动的暂停。8.2 恢复要求出现测试暂停后，当系统的新版本向测试组传递时， 6.7 条中描述的回归测试应予执行。9 测试交付项(1) 系统测试组应形成下列文档，这些文档在测试结束后交付给配置管理组。测试文档系统测试计划；系统测试设计说明；系统测试用例说明；系统测试规程说明；系统测试日志； 系统测试事件报告日志； 系统测试事件报告； 系统测试总结报告。测试数据：所有数据录入、查询屏幕和回答屏幕的拷贝都应附在相关的测试用例文档中。(2) 输入和输出测试文件的拷贝应交付给配置管理组。(3) 最终执行每个测试规程的打印输出的缩微胶片拷贝，应与测试文档集一起交付给配置管理组。1 0 测试任务见附件 A 的任务列表。1 1 环境要求11.1 硬件测试应在 XYZ 公司的硬件配置下进行。 鉴于大多数测试必须在主要的操作时间内开展，在此期间内应向测试组提供3 个在线终端。11.2 软件11.2.1 操作系统 该业务操作系统应用于执行这些测试。 所有在线程序应在测试通信软件的控制下加以测试。11.3 安全性安全性应限于现有的各种控制器。11.4 工具 开发和评估系统测试需要下列测试工具：(1) 测试数据生成器(UT09-0200)。该程序用于生成绝大多数的测试数据。它位于标准系统库SYSLIBA。(2) 比较器程序(UT08-0100)。该程序用于在回归测试期间比较系统结果。它位于标准系统库SYSLIBA 中。(3)数据库审核器。该程序用于审核数据库中的数值范围及记录之间的相互关系。它须由开发组提供。11.5 出版物需要下列文档支持系统测试：公司工资系统需求陈述(AP01-01)公司工资系统设计描述(AP01-04)一公司工资系统参考手册(AP02-01)公司工资系统操作手册(AP02-02)公司工资系统模块参考手册(AP02-03)公司工资系统用户事务参考手册(AP02-04)12 职责下列各组对测试各部分负有责任。12.1 系统测试组该组对测试及技术测试业务进行全面管理。12.2 公司工资部门该组是公司工资系统的终端用户，在下列各项活动中应协助系统测试组工作。 审查测试设计说明；执行在线测试；校验输出屏幕和报告。12.3 项目开发组该组传递要测试的系统，并响应系统测试事件报告。该组对需要排错的任何程序进行调试，并提供数 据库审核器。13 人员和培训要求13.1 人员配备需要下列人员开展该测试项目：13.1.1 测试组测试经理高级测试分析员测试分析员2测试技术员113.1.2 工资部门工资监管人员 113.2 培训公司工资部门的人员必须经过培训，以便对数据录入事务进行处理。用户事务参考手册（AP02-04）应作为该培训的基础。14 进度见附录 A 的任务列表。硬件，软件和测试工具应用于从19*年 6 月 1 日到 19*年 8 月 1 日期间的测试。15 风险和应急如果系统故障严重地影响测试进度，开发经理已同意分派一名全职人员到测试组做调试工作。如果一位工资监管人员对于测试工作不够用，工资经理已同意确定第二位监管人员。如果硬件出现的问题影响系统在白天的应用，则测试组应安排其夜晚的活动。公司工资系统的第一次运行使用，在分发工资支票前必须详细地加以核查，并对住何出错的支票须用手工进行修正。16 批准测试经理：日期开发项目经理：日期质量保证经理：日期附加 A 任务列表任务前期任务特殊技能责任投入完成日期（1）准备测试计划结束工资系统设计描述（AP01-04）和初步的开发计划（AP01-02）测试经理；高级测试 分析员4（人 日）XX-01-21(2)准备测试设计说明任务1通晓公司 的工资规程高级测试分析员9XX-04-01(3)准备测试用例 说明结束相应的测试设计(任务2)测试分析 员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任务8测试分析员1XX-06-22(10)执行批测试规程任务5任务8测试分析员3XX-06-30(11)检查批测试规程任务10通晓工资 报告需求测试分析员1XX-07-02(12)解决测试事 件报告任务9任务11开发组经 理;系统测 试组经理； 公司的工 资部门经 理2XX-07-16(13)重复任务(6) (12)直到所有测 试规程成功运行任务122XX-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. 测试记录6.1 能力6.2 缺陷和限制6.3 建议6.4 结论7. 测试活动总结附件9XXX 软件临床评价