医疗器械软件研究模板Word格式文档下载.docx

医疗器械软件研究模板Word格式文档下载.docx

《医疗器械软件研究模板Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《医疗器械软件研究模板Word格式文档下载.docx（51页珍藏版）》请在冰豆网上搜索。

分类

零件

种类

功能

显示部分

血压显示7工具LED

血压值显示

最高血压・最低血压、脈拍を表示

时刻显示7工具LED

時刻显示

显示现在时刻

压力单位显示LED

mmHg/kPa显示

显示血压值以及压力值的单位

开关部分

开始/关闭

开关

开关读取控制

开始测量血压

测量时停止测量

背面功能设定开关

背面功能设定

时刻的设定等、主机功能设定的更改

打印部分

打印

切纸

打印控制

测量结果的打印、

打印后切纸

血压测量部分

泵、电磁阀、

压力传感器

血压测定控制

测量时加压、减压控制、脉搏信号处理以及测量值的确定

安全监视用

压力安全检测控制

压力监测、急排控制

袖带驱动部分

袖带驱动用马达

袖带控制

袖带的卷曲、固定、开放

语音部分

扬声器

语音控制

测量通知

外部进出力部

串行通信

串行进出力

测量结果出力、指令输入

记忆存储

U盘

设定值记忆存储控制

功能设定内容的保持

嵌入式软件物理拓扑关系表格形式——例如2

独立式软件物理拓扑关系表格形式——例如3

图1.4-1物理拓扑图

1.3.5.连接关系描述

与PC连接

与医疗器械硬件连接

1.4.运行环境

1.4.1.硬件配置

处置器:

贮存器

外设器件

输入/输出设备

……

1.4.2.软件环境

系统软件：

支持软件：

必备软件：

选配软件：

杀毒软件：

1.4.3.网络条件

网卡：

网络类型:

网络架构：

1.5.适用范围

独立软件：

软件的适用范围和适用人群。

软件组件：

同医疗器械产品的适用范围和适用人群。

1.6.禁忌症

软件的禁忌症和不适用人群。

同医疗器械产品的禁忌症和不适用人群。

1.7.上市历史（软件组件写医疗器械的上市历史）（表格形式）

国产第一次注册例如：

该医疗器械，产品名称为XXXXX，据产品结构及预期用途，按《医疗器械分类目录》分为6870类软件，依照二/三类医疗器械进行第一次注册。

入口（第一次/从头）

该医疗器械作为XXX的组件，在中国（第一次/从头）申请上市。

依据产品结构及预期用途，按《医疗器械分类目录》分为68xx-xx类。

上市历史详情见下表：

上市国家

管理类别

上市时间

现版本号

原产国

（中国）

欧洲（如有）

美国（如有）

…

2.实现进程

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版本：

xxx）

2.3需求规格（SRS）

《需求规格说明书》（SRS）全文，见附件2。

《需求规格说明书》（文件号：

2.4生存周期

《软件开发打算》（SDP）摘要见附件3。

《软件配制治理打算》（SCMP）摘要见附件4。

《软件保护打算》摘要见附件5。

《生存周期实施情形核查表》见附件6。

2.5验证与确认

《软件验证与确认打算》见附件7。

在软件开发进程中，进行了以下测试：

序号

测试

测试文档

编号

XXX单元测试

XXX单元测试计划

XXX单元测试报告

各测试文档详见附件8

2.6缺点治理

2.6.1缺点治理的流程

缺点治理流程为：

步骤

工作

主要内容

负责人

1

缺陷报告

2

2.6.2缺点总数和剩余数

开发进程中发觉缺点xx个，上市后剩余缺点数为xx个。

剩余缺点描述、严峻度、整改打算为：

缺陷描述

严重度

整改计划

计划完成时间

2.7修订历史

软件版本的命名规那么：

软件的版本号为XX.XX.XXXXX的形式，版本号中，第一名是xx，代表：

XXXX，第二位是xx，代表……。

本软件修订历史

软件版本

修订日期

修订类型

变更内容描述

3

2.8临床评判

参考医疗器械软件描述文档附件9

“《临床评判报告》（文件号：

xxx版本号xxx）”。

——与注册资料7临床评判资料一致。

3核心算法概述

算法类型：

公认成熟算法：

公布文献专利标准、原理简单明确、上市超过四年且无不良事件。

公认成熟算法列明名称、原理、用途，全新算法列明名称、原理、用途，并提供验证资料。

全新算法：

源自科学研究和临床数据

内容：

实质第一次注册：

所有核心算法

实质从头注册：

新增核心算法

附件1

XXX风险治理报告

附件2

XXX需求规格说明书（SRS）

1.引言

1.1编写目的

为了明确“XXXXX”项目的需求，为用户和分析设计人员之间的交流提供方便，更好地安排项目计划与进度，组织软件开发与测试，减少项目风险，撰写本需求规格规格说明书。

本需求规格说明书的读者为项目领导、分析设计人员、程序员、质量保证人员、保护人员和客户方的相关人员。

1.2项目背景

1.3概念

GB/T11457所列术语和以下概念适用于本指南。

合同：

指XXXX一起签署的关于本项目的合同。

客户：

指XXXX公司。

语言：

是指具有语法和语义的通信工具，包括一组表达式、老例和传递信息的有关规那么。

编程语言：

是指用于编写源程序的高级语言和汇编语言。

用户：

XXXXXX

1.4参考资料

a）GB/T11457软件工程术语

b）GB8566运算机软件开发标准

c）GB8567运算机软件产品开发文件编制指南

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）应用目标：

XXXX

2.1.2产品描述

（描述产品的大体要求、要紧部份、外部接口等可利用框图展现较大系统的要紧部份、彼此关系、外部接口等））

2.1.2.1软件系统整体结构图

采纳基于采纳MVC模式架构的开发方式，实现的系统具有界面美观、操作简单、开发系统容易升级、系统开发周期短、本钱低等优势。

在项目的研发中，从体系结构上将本系统设计为4层结构：

系统结构图

（结构图说明）

2.1.2.2软件系统整体数据流图（图示及说明）

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.1用户接口

3.1.1.2硬件接口

3.1.1.3软件接口

3.1.1.4通信接口

3.2功能需求

3.2.1用户注册功能

系统应能完成用户注册功能

Ø

主参加者：

用户

环境目标：

前置条件：

数据库有足够的空间。

触发器：

用户进入注册界面。

场景：

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可保护性

3.6.5可移植性

附件3

XXX软件开发打算（SDP）摘要

本条应简述本文档适用的系统和软件的用途，它应描述系统和软件的一样特性；

概述系统开发、运行和保护的历史；

标识项目的投资方、需方、用户、开发方和支持机构；

标识当前和打算的运行现场；

列出其他有关的文档。

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．其他所需的资源，包括：

取得资源的打算、需要的日期和每项资源的可用性。

附件4

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．编制关于程序及其有关文档的修改状态的文档。

因此必需进一步概念用于预备多种级别（如项目负责人、配置操纵小组、软件配置治理人员和用户）的治理报告的工具、技术方式。

附件5

XXX软件保护打算摘要

1.保护范围

a）更正性保护

b）适应性保护

c）完善性保护

d）预防性保护

2.保护工作流程

附件6

XXX软件生存周期实施情形核查表（YY/T0708）

52.201.1

应维护应用本标准形成的文件并应使其成为质量记录的一部分;

见图241。

宜依照

GB/T19001-2000中4.2的要求实施。

52.201.2

这些文件（以下简称为风险管理文档），应根据规定的配置管理机制进行批准、发布和更改。

宜依照GB/T19001-2000中的4.2.3的要求实施

52.201.3

在整个开发生存周期中，应形成风险管理概要，并将其作为风险管理文档的一部分。

其内容应包括：

a）

已识别的危害以及其起因

b）

风险估计

c）

用于消除或控制危害的风险所采取的安全性措施的证明

d）

风险控制

e）

验证证明

通过检查风险管理文档核查其符合性

52.202.1

制造商应制定风险管理计划。

52.202.2

计划应包括以下内容:

计划的范围，确定项目或产品以及该计划适用的开发和生存周期的各阶段；

使用的开发生存周期（见52.203），包括验证计划的开发生存周期的各阶段；

依照GB/T19001-2000中5.1的管理职责；

风险管理过程

审核要求

52.202.3

如果在开发过程中计划改变，应保留更改的记录

通过检查风险管文档核查其符合性

52.203.1

应为可编程医用电气系统的设计和开发定义开发生存周期

52.203.2

开发生存周期应分解为各个阶段和任务，对每一个阶段和任务都应明确定义输入和输出以及活动。

52.203.3

开发生存周期应包括风险管理的整个个过程。

52.203.4

开发生存周期应包括对文档的要求。

52.203.5

风险管理活动应合适地贯穿于开发生存周期中，见52.204。

注:

在附录DDD（资料性附录）给出了一个开发生存周期的示例。

通过检查风险管理文档核查其符合性。

52.203.6

应在开发生存周期的所有阶段和任务之内或之间的适用处，建立和维护一套明确的问题解决体系，并作为风险管理文档的一部分.根据间题，该体系可具有如下特征:

—定义作为开发生存周期的一部分;

—允许报告潜在的或现存安全性和（或）性能方面的问题，

—包括对每个问题的相关风险的评估;

—确定问题分析结束的准则〔安全性和（或）性能方面〕;

—确定解决各种问题所采取的措施;

—确定每一种措施的确认方法;

一确定验证持续符合性的步骤。

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

应对所有合理可预见的情况进行危害识别，包括:

—正常使用情况下;

—不正确使用情况下。

52.204.3.1.3

应考虑合适的危害状