软件开发 与 测试 比例-脸的比例测试软件

医疗器械良好生产规范附录“单机软件”

第一部分范围和原则

1.1 本附录适用于单机软件，软件组件参照执行。

解释：

本文中的软件应指用于“医疗目的”的软件； 独立软件是指“运行在通用计算平台上”、“不依赖于医疗设备”，能够起到“医疗”作用的软件； 软件组件是指“驱动医疗设备硬件或在医疗计算平台上运行的控制或软件”。

当然，用于医疗器械企业“制造过程控制”和“工作流程管理”的软件不在本文讨论范围内，但所有“软件”的生命周期管理和开发过程的客观规律是同样，也值得我们生产企业和装备行业借鉴。

1.2 本附录遵循软件生命周期过程和网络安全的基本原则和通用要求，是对独立软件生产质量管理规范的特殊要求。

解释：

无论是“医疗用途”软件还是针对医疗器械产品的“制造过程控制软件”，所有软件的软件生命周期流程、数据可靠性、网络安全都是一样的，都遵循软件本身的客观规律。 应遵循软件的客观规律和生命周期管理。 这并不是真正的“特殊”要求。

第二部分特殊要求

2.1 人员

2.1.1 软件开发、测试、维护人员应具备与岗位职责相适应的专业知识、实践经验和工作能力。

解释：

对于软件开发/测试/维护……，相关参与者的“专业知识、实践经验、工作能力……”当然非常重要。

2.1.2 黑盒测试应保证同一软件项目的开发人员和测试人员不得同时工作。

解释：

那么，白盒测试呢？ 开发人员和测试人员可以为彼此工作吗？ 我真的不知道这个。 其实开发是为了满足客户需求，测试是为了保证软件质量； 对于一些小的软件公司，出于成本的考虑，开发人员和测试人员也可能兼职工作，即对自己开发的软件进行测试。 有检测的能力和素质，当然本身没有什么大问题，就像生产人员可以检测自己生产的产品质量一样；

但基于“责任”和“利益关系”，以及“专业分工差异”的考虑，不兼任也是非常合理的。

就像医疗器械企业的“制造总监”和“质量总监”是不允许兼职的，但对于一线开发人员和测试人员来说，其实是两个不同的职位。

2.1.3 用户测试人员应具有相应的软件产品使用经验，或经过培训，具备相应的软件产品使用技能。

解释：

用户测试人员是出于“医疗目的”使用软件的用户。 用户必须有使用软件的经验，主要关注软件的功能和使用技巧。

其实，对于医疗设备企业的设备操作人员来说，他们同时也是设备控制软件和过程管理软件的用户，应该主要关注软件的体验、功能、技能……而不是过分关注软件开发过程和测试过程。

2.2 设备

2.2.1 在软件生命周期内持续提供充足、合适、有效的软件开发和测试环境，包括软硬件设备、开发和测试工具、网络等资源，以及病毒防护、数据备份和恢复等。其他保障措施。

解释：

对于软件企业来说，软件开发环境和测试环境等同于“制造业”的生产环境（包括厂房设施、设备系统）和检测环境，就像厂房设施、洁净环境、生产设备、检测系统一样制药业，与公共工程相同；

本附录要求软件企业提供软件开发和测试所需的环境条件。 开发环境和测试环境需要特定的硬件设备、软件环境、特定的开发工具、测试工具、网络资源、安全条件（病毒防护、数据备份和数据恢复……）。

2.2.2 软件开发测试环境的维护应形成文件，确定软件开发测试环境定期验证、更新升级、病毒防护等活动的要求，并保存相关记录。

解释：

对于软件企业来说，软件开发环境和测试环境，当然需要“确认、验证、再验证”、更新、修改、升级、报废……安全保障、数据可靠性要求……

开发环境和测试环境的维护活动必须有相关文件和记录...

2.3 设计开发

2.3.1 软件生命周期过程控制程序应结合软件生命周期模型的特点，对软件开发策划、软件需求分析、软件设计、软件编码、验证与确认、软件更新、风险管理、缺陷管理、回顾分析、配置管理、文件和记录控制、现成软件使用、网络安全保障、软件发布、软件部署和软件中断等活动是必需的。

解释：

对于独立的医疗软件或医疗器械控制软件，软件开发公司（医疗器械公司）应非常熟悉软件生命周期管控流程，并形成系统文件规范软件生命周期管控，这是必要的。

2.3.2 软件生命周期过程质量保证活动的要求应与软件安全等级相适应。 在采取风控措施前，应结合软件的预期用途、使用场景和核心功能等综合判断软件安全等级，只能通过外部风控措施降低等级。

解释：

软件生命周期中质量保证活动的要求是基于软件的安全等级，而软件的安全等级是基于软件本身对患者的风险等级。 采取必要的外部（软件本身之外）风险控制措施可以降低软件的风险。 本身的风险是可以接受的，从而降低了软件的风险等级。

对于非独立软件（软件组件），该软件的风险等级与该软件本身控制的医疗器械硬件功能对患者造成的风险一致。

2.3.3 软件风险管理活动应按照风险管理控制程序，结合产品识别、分析、评价、控制和监视软件功能、接口、用户界面、现成软件、网络安全和其他风险，贯穿于软件生命周期的全过程。

解释：

独立软件和带有软件的医疗器械直接用于医疗目的，对其进行风险评估和风险控制，类似于产品生产过程的风险管理，也是基于软件功能（类似于产品质量属性）。 ) 和软件开发、测试过程控制、风险管理活动。

2.3.4 软件配置管理应建立控制程序并形成文件，规范对软件版本、源代码、文件、工具、现成软件的控制要求，确定配置标识、变更控制、配置等活动要求状态记录。 使用配置管理工具来保证软件质量并贯穿于软件生命周期的全过程。

解释：

对于软件开发公司（独立软件开发公司或相关医疗器械制造商）来说，这些基本要求是必要的。

2.3.5 软件版本控制应根据合规性要求确定软件版本命名规则，涵盖所有软件更新类型、现成软件和网络安全。 每个字段的含义应该清楚，没有歧义和矛盾。 软件版本变更应符合软件版本命名规则的要求。

解释：

软件命名规则和软件版本控制要求系统的、科学的命名方法，包括所有软件（医疗用途软件、开发软件、测试软件、网络安全软件……遗留软件、成品软件、外购软件……）。

2.3.6 软件溯源分析应建立控制程序并形成文件，涵盖现成软件和网络安全的控制要求，形成软件溯源分析报告供审核。 使用溯源分析工具，确保软件开发和软件更新过程满足溯源要求，并贯穿于整个软件生命周期。

解释：

软件追溯，通过“软件需求、软件设计、源代码、软件测试、软件风险管理”之间的关系，分析和评价各个步骤之间的“正确性、一致性、完整性、准确性”，当然需要用到《溯源分析工具》，也可以在线下载《软件溯源分析报告》模板。

2.3.7 对现成软件的使用应形成文件，确定风险管理、验证确认、缺陷管理、溯源分析、软件更新、配置管理、文件记录控制、网络安全保障等方面的要求。 遗留软件还应确定评估活动的要求，例如现有文件、上市后使用、用户投诉、不良事件和召回。 使用开源软件应遵循相应的开源许可协议。

解释：

现成的软件是指没有按照本规范进行完整的生命周期控制的“以前自行开发的软件、外购成品软件、委托第三方开发的软件”。 当然，管理这些软件需要一套文档。 明确“风险管理、验证确认、缺陷管理、溯源分析、软件更新、配置管理、文件记录控制、网络安全保障”的工作流程。

用于“医疗目的”的“单机软件或医疗器械”需要跟踪“使用情况、不良事件、用户投诉、产品召回……”，并在产品上市后定期评估这些活动。

当然，这些工作是由“医疗目的”的独立软件提供商和医疗设备制造商完成的，当然不应该由独立软件或医疗设备的“用户”主导； 许多用户不是直接患者，因此此类用户也应该直接参与这些活动。

2.3.8 软件开发计划应确定软件需求分析、软件设计、软件编码、验证和确认、风险管理、缺陷管理、可追溯性分析、配置管理、文件和记录控制、现成软件的使用、网络安全保障、审查等活动计划，形成相关文件和记录，并适时更新。 软件开发策划应当保证软件开发和测试的人员和环境与软件开发要求相适应。

解释：

软件生命周期的管理应从软件需求分析、软件开发计划开始，相当于一个软件开发项目计划，涵盖整个软件开发和软件测试过程的各个方面，严格执行计划并形成文件和文件。记录。 （软件开发硕士课程）

2.3.9 软件需求分析应综合分析法规、标准、用户、产品、功能、性能、接口、用户接口、网络安全、告警等软件需求，确定风险管理、溯源分析、现成软件使用评估、软件确认测试计划创建、评审等活动的要求，形成和批准软件需求规约和评审记录，并适时更新和批准。 溯源分析此时应分析软件需求与风险管理、软件需求与产品需求之间的关系。

解释：

软件需求分析相当于对“软件用户需求”的分析和评价，基于“法规、标准、功能、性能、风险管理、使用评价、溯源性、确认测试、评审需求……”等方面，以及最终形成《软件需求说明书》并经审核通过。功能需求文档应明确列出系统的通用主次功能模块，以及相关接口和接口功能。（软件需求说明书）

2.3.10 软件设计应按照软件需求说明书进行软件架构、功能、性能、算法、接口、用户界面、单元、网络安全等设计，确定风险管理、溯源分析、关- 上架软件使用评估，以及软件验证测试。 计划创建、审查和其他活动需要软件设计规范和审查记录在适当的时候形成和批准、更新和批准。 溯源性分析此时应分析软件设计与软件需求之间的关系。

解释：

在软件设计阶段，根据《软件需求说明书》，对软件进行“体系结构和功能”设计（或系统设计）软件开发 与 测试 比例，形成《软件设计说明书》，并经审查批准。

系统设计（或概要设计）需要设计软件系统的基本处理流程、系统组织结构、模块划分、功能分配、界面设计、操作设计、数据结构设计、错误处理设计等，提供详细信息对于软件。 设计提供了基础。

软件系统的详细设计应描述实现具体模块的主要算法、数据结构、类层次结构和调用关系。 需要说明软件系统各个层次中每个程序（每个模块或子程序）的设计注意事项，以便进行编码和测试，确保软件需求说明书在整个软件设计中得到充分贯彻，并且详细设计报告是下一步“软件编码”的依据。

2.3.11软件编码应按照软件设计规范进行，确定源代码编译和注释、使用现成软件、溯源分析、各级测试用例创建、评审等活动的要求，形成审核记录，并适时更新。 源代码的编写和注释应符合软件编码规则文件的要求。 测试用例应确保软件验证和确认测试的充分性、适用性和有效性。 溯源分析此时要分析源代码与软件设计、源代码与测试用例的关系。

解释：

根据《软件系统详细设计报告》中数据结构、算法分析和模块实现的设计要求，开始具体的程序编写工作，实现各模块的功能，从而实现目标系统的功能、性能、接口，接口需求。在标准化的研发流程中，编码工作不会超过整个项目流程的1/2，通常是1/3的时间

2.3.12 软件验证应确定源代码审查、静态分析、动态分析、单元测试、集成测试、系统测试、审查等活动的要求，涵盖现成软件和网络安全的验证要求，并维护相关记录。 白盒测试应确定语句、判断、条件、路径等的测试覆盖率要求，并与软件安全级别相适应。

解释：

本附录针对医疗器械本身的操作软件或“医疗用”的独立软件。 软件的“验证”也是软件开发商或设备制造商所要求的。 因此，源代码审查、静态分析、动态分析、单元测试、集成测试、系统测试、系统审查……包括白盒测试的具体要求，都应严格执行IT行业全生命周期验证标准软件验证。

2.3.13 单元测试、集成测试、系统测试按照相应的测试计划进行，涵盖现成软件和网络安全的测试要求，确定缺陷管理、风险管理、溯源分析等要求，评审等活动，并形成相应的软件测试记录、测试报告和评审记录，并适时更新。 溯源性分析应分析各级测试用例与软件设计、系统测试与软件需求、系统测试与风险管理的关系。

解释：

软件测试的对象包括软件需求、总体设计（类似于概念设计）、详细设计、软件运行环境、可执行程序和软件源代码等。

软件测试一般分为四个阶段：单元测试、集成测试、系统测试和验收测试。

软件测试必须有相应的测试计划、测试记录、测试报告和评审记录。

测试过程应关注缺陷管理、风险管理、溯源性分析、评审等活动要求。

单元测试：

单元测试是对软件中最小的可验证单元的检查和验证。

集成测试：

集成测试是在单元测试的基础上，根据软件概要设计规范的规范要求，将软件单元组装成模块、子系统或系统，各部分工作是否满足或实现相应的技术指标和要求。

系统测试：

通过集成测试的软件作为计算机系统的一部分，与系统的其他部分相结合，在实际运行环境中进行一系列严格有效的测试，以发现软件中存在的潜在问题，确保系统的正常运行。

验收测试：

也称为交付测试，是对用户需求和业务流程进行的正式测试，以确定系统是否满足验收标准，由用户、客户或其他授权组织决定是否接受该系统。

验收测试包括 alpha 测试和 beta 测试。 Alpha 测试是由开发人员进行的软件测试，Beta 测试是由开发环境之外的用户进行的软件测试。

2.3.14 软件验证应确定用户测试、临床评价、审查等活动的要求，涵盖对现成软件和网络安全的验证要求，并保存相关记录。 确保软件满足用户的需求和预期目的，并且软件中已知剩余缺陷的风险是可以接受的。

解释：

软件测试结束后，就是软件确认。

其实和设备安装调试后的确认和验证是一样的。

软件验证，更侧重于用户测试、临床评价、审查等活动。

什么是用户测试？ 是软件的操作和使用，以及性能功能测试（见下一项）。

医疗软件更注重临床疗效，制药设备软件更注重使用功能。

如何评估已知软件缺陷的风险是否可以接受，当然关系到患者的安全和疗效。

2.3.15 用户测试应根据用户测试计划在真实使用环境或模拟使用环境中进行，涵盖现成软件和网络安全的测试要求，确定缺陷管理、风险管理、溯源分析、评审等活动，形成用户测试计划。 试验记录、试验报告和评审记录应及时批准、更新和批准。 溯源分析此时应分析用户测试与用户需求、用户测试与风险管理之间的关系。

解释：

这篇文章和2.3.13的要求是一样的，只不过这篇文章是针对用户的“用户测试”，而2.3.13是针对软件开发者的“单元测试、集成测试和系统测试”。 还需要注意用户测试的测试计划、测试记录、测试报告和审核记录。 用户测试过程应关注缺陷管理、风险管理、溯源分析、评审等活动需求。

2.3.16 软件更新应形成文档，涵盖现成软件和网络安全的变更控制要求、确定软件更新请求评估、软件更新计划、软件更新实施、风险管理、验证和确认、缺陷管理、可追溯性分析、配置相关文件和记录应形成和批准，用于管理、文件和记录控制、审查、用户通知等活动，并应适时更新和批准。 软件版本更改应与软件更新相匹配。 验证确认应根据软件更新的类型、内容和程度，实施适当的回归测试、用户测试等活动。

解释：

软件更新当然需要变更控制。 软件本身每一部分的变更都需要启动变更控制，按照既定流程进行评估和计划，考虑风险控制、确认和验证，考虑存在缺陷的处理软件开发 与 测试 比例，文档记录的管理。 当然，最重要的是告诉用户。

软件版本的变化更为重要。

验证和确认活动的范围和程度需要根据变更的类型、内容和程度进行评价，并采用与变更的类型和风险相适应的测试和评价方法。

2.3.17 软件缺陷管理应形成文件，确定软件缺陷评估、软件缺陷修复、回归测试、风险管理、配置管理、评审等活动的要求，并形成软件缺陷分析报告供评审。 使用缺陷管理工具确保软件质量并贯穿于软件生命周期的全过程。

解释：

软件有bug是正常的。 已经上市N年的成熟商业软件还是会存在缺陷和漏洞。 因此，供应商将继续提供补丁，用户将继续报告缺陷。 对于独立的医疗用软件，基于对患者的风险，用户（医疗机构）和软件开发商均应建立缺陷管理制度和程序，对报告、评估、修复、测试、软件变更、配置和审查等缺陷进行管理。 软件开发过程的“缺陷管理工具”是一个专业的工具。

2.4 采购

2.4.1现成软件的采购应形成文件，根据现成软件的类型、使用方式确定分类管理、质量控制、供应商审核等活动的要求，以及对产品质量的影响程度。

解释：

本文中的软件应指用于“医疗目的”的软件； 独立软件是指“运行在通用计算平台上”、“不依赖于医疗设备”，能够起到“医疗”作用的软件； 软件组件是指“驱动医疗设备硬件或在医疗计算平台上运行的控制或软件”。

现成的软件是指“不是自己开发的，从市场上购买的，或者第三方开发的”的软件。 可能是软件外包，比如波音公司外包给印度公司的737MAX软件，现在还停飞。 另一个例子是，一家医疗设备公司购买并在其生产的医疗设备上安装“控制或驱动医疗设备硬件或在医疗计算平台上运行”的软件。 又如医院购买的“自主软件”。 又如企业购买的设备上的自动化控制软件。

这些软件都是“采购”的，当然要有文件（是URS/合同/图纸/数据/FAT/SAT/DQ/IQ/OQ/PQ...？），影响评估，关键分类，质量管控、供应商审核……当然是必须的，具体要求与风险程度相符。

2.4.2 应与供方签订外包软件质量协议，明确外包软件需求分析要求、交付形式、验收方式和准则、设计开发文件交付、知识产权归属、维护、质量责任等。双方。

解释：

医疗器械企业与原材料供应商签订质量协议，是指医疗机构采购独立的医疗用软件，医疗器械生产企业采购医疗器械控制程序软件，都需要与软件开发商或软件厂商签订质量协议。 有担当，责任重大； 如果你不负责任，你就是一张纸。 除了信任，还需要有一定的契约精神。

2.4.3 云计算服务协议应明确网络安全保障、患者数据和隐私保护的责任要求。

解释：

当今社会，大数据、云服务……如火如荼，网络安全、隐私保护……火上浇油（无语表情）……安全保障需要技术、责任、后果，否则是空话。

2.5 生产管理

2.5.1 软件发布应文件化，确定软件产品文件创建、软件产品及文件归档与备份、软件版本标识与标记、交付形式评估与验证、病毒防护等要求，确保软件的可重复性发布。

解释：

生产管理，软件生产，当然就是软件的“开发和测试”，开发和测试，前面说了，这一段是关于软件的“发布”，或者说软件的销售，和软件采购相关 Echoing, just purchase一份可能就够了。 销售或发布也可以称为软件的物理复制（生产），即N份。 当然，各种活动都要保证软件发布的可重复性，否则卖出来的软件就不一样了，就惨了。

2.5.2 物理交付方式应确定软件产品复制、许可、存储介质包装、标识和保护的要求，网络交付方式应确定软件产品标识、许可和网络安全保障的要求。

解释：

软件发布后，你不花钱，当然用不了。 当然，也可以使用盗版，但那是违法的。 因此，实物交付（CD、U盘、移动硬盘……）必须明确是否可以复制、可以复制多少份、是否需要许可证、实物标识要求、实物保护要求等。 当然，你也可以在线下载。 付款后会给你下载地址和下载权限，也可以免费下载，但不花钱就不能用。 还是试用版？ 如果审理出了问题，谁来负责？ 授权和网络安全很重要，不然带病毒就麻烦了。

2.6 质量控制

2.6.1 软件产品的发布应形成文件，确定软件版本识别、安装和卸载测试、产品完整性检查、发布批准等活动要求，并保存相关记录。

解释：

软件发布指的是软件开发者的发布，或者软件厂商（物理复制者或者销售者）的发布，我觉得应该是销售者（或者批量生产者），就像药品成品的发布一样， software development Manufacturers are research and development units, software manufacturers, and in a sense, manufacturers of software media. Of course, there are software data on the media. Such products (software) need to pass QA review and be released by quality authorized persons! Batches of physical delivery are okay, but if it is online delivery? How to let it go? That is, it is released to a specific download address on the Internet, and it is OK.

2.7 Sales and after-sales service

2.7.1 Software deployment shall be documented to determine the requirements for delivery, installation, setup, configuration, user training and other activities, and relevant records shall be kept.

解释：

What is software deployment? Isn't it just that the software is installed at the user's place... First, it is delivered to the user, then installation, parameter setting, workflow configuration according to SOP, and then training to teach the user operation, maintenance, emergency treatment (software backup, software recovery... ...), software upgrades, software update versions... Do what you write, write what you do, records must be kept.

2.7.2 The outage of the software should be documented to determine the outage follow-up user services, data migration, patient data and privacy protection, user notification and other activity requirements, and keep relevant records.

解释：

Of course, the life cycle activities of the software must be recorded. When the software is out of service, of course, all the data cannot be lost. First, the software developer or seller must notify the user of the outage of the software; Data transfer storage, data security... the top priority. There are also a lot of software that you only pay for the right to use for a certain period of time. After that time, you can't use it and you need to renew it. Everyone understands this.

2.8 Adverse event monitoring, analysis and improvement

2.8.1 Data analysis control procedures should cover software defects and network security incident requirements.

解释：

Enterprises (software developers, software physical manufacturers, medical institutions...) should establish data analysis control procedures. It is necessary to conduct regular review, analysis and monitoring of software use, register software defects, and network security incidents. Regular software repairs and improvements...

2.8.2 The emergency response to network security incidents shall be documented to determine the requirements for network security incident risk management, emergency response measure verification, user notification, recall, and other activities, and maintain relevant records.

解释：

Network security is of great importance, and emergency plans are of course very important. Based on risks, emergency response measures should be verified. To put it bluntly, it is to conduct emergency plan drills. Should such drills be done regularly like fire drills? Based on risk.

Part III Terminology

3.1 The following terms have the meanings:

Independent software: software that has one or more medical purposes, can complete its intended purpose without medical device hardware, and runs on a general-purpose computing platform.

Software component: software that has one or more medical purposes, controls, drives medical device hardware, or runs on a medical computing platform.

Software security level: based on the degree of software risk, it is divided into mild, medium and serious. Minor means that the software is unlikely to cause harm, medium means that the software may directly or indirectly cause slight harm, and serious means that the software may directly or indirectly cause serious harm or cause death .

Software verification: by providing objective evidence to confirm that the output of a certain stage of software development and software update meets the input requirements.

Software Validation: Confirmation that software meets user needs and intended purposes by providing objective evidence.

Software traceability analysis: track the relationship between software requirements, software design, source code, software testing, and software risk management, and analyze the correctness, consistency, completeness, and accuracy of the identified relationships.

Software update: Any modification made by the manufacturer to the software during the whole software life cycle, also known as software change or software maintenance.

Software outage: The production enterprise terminates the after-sales service and sales of software at the end of the software life cycle process, also known as software delisting.

Off-the-shelf software: software that has not been controlled by the manufacturer for a complete life cycle, including legacy software, finished product software, and outsourced software.

Legacy software: Software that was previously developed by the manufacturer but cannot now be adequately documented.

Finished software: software that has been developed and is generally available, but the production company has not conducted a complete life cycle control.

Outsourced software: software developed by a third party entrusted by the manufacturer.

Cyber ​​Security: Maintain the confidentiality, integrity and availability of data related to medical devices.

Part IV Supplementary Provisions

4.1 The State Drug Administration is responsible for interpretation of this appendix.

4.2 This appendix will come into effect on July 1, 2020.