IEC 62304在医械软件开发中的实施

作者：时间：2011-12-08 来源：网络收藏

欧洲软件和系统提案之“利用经验驱动测试(PET)检验误码性能计划调查了这种现象，并且同意采用的代码通常带有很多误码的观点。PET旨在将发布后报告的漏洞数量减少50%和将每找出一个漏洞所耗费的测试工作时间缩短40%。有意思的是，PET超过了该标准，将报告的漏洞数减少了75%，将测试效率提高了46%。PET的发现表明可以利用较新的测试方法(如静态和动态分析)找出大量漏洞，即使代码已经通过了功能系统测试并于随后发布。

那么，可以采用先前通过功能测试的SOUP做进一步测试。即使它运行良好，代码的某些部分也可能未曾使用过，即使是产品正在现场使用的时候。如果 SOUP代码需要作进一步开发以便于后来的修订或新应用，那么先前从未碰到的数据组合也可能会使用先前未使用的代码路径，从而产生意料之外的结果。图1中的绿点曲线表示对SOUP代码进行增强时使用的代码。

为了克服这种潜在弱点，需要进行详细的结构覆盖率分析，以确保早期软件内不存在未使用的代码。IEC62304要求测试早期软件的功能覆盖率和结构覆盖率，还要详细分析增加这类软件可能引入的风险。功能覆盖率确保软件能够按照系统设计要求运行，而结构覆盖率则确保使用了所有代码并且能够正常运行。

IEC62304要求整合到医疗器械设计中的所有SOUP项目均符合功能和性能要求规范。医疗器械制造商需要确保任意SOUP项目的正常运行，还要保证它们符合功能和性能要求。

IEC62304软件开发过程始于软件开发规划，包括所用SOUP项目的详细计划。这些细节介绍了如何将SOUP项目整合到现有系统中、如何管理SOUP相关风险和软件配置、以及变更管理如何影响系统。

紧接着是软件需求管理、架构设计、集成测试、系统测试、风险管理、维护和变更管理阶段。在软件开发生命周期的各个阶段，都需要保持所有阶段之间的可追踪性。

传统的软件开发观点表明了各个阶段如何进入下一个阶段，可能还带有前几个阶段的反馈信息，以及配置管理与过程的周边架构。可追踪性被视为各个阶段间关系的一部分。然而，很少规定记录跟踪链路的机制。

实际上，虽然由于先进工具技术投资，各个阶段都能够有效实施，但是这些工具很少能够自动提高阶段间可追踪性。因此，在整个项目进行的过程中，其间链路的维护就变得越来越差。最终的结果就是需求与设计之间的交叉检验缺失或者流于表面，以及最终系统的机能不全。为了获得真正的自动可追踪性，则需要需求跟踪矩阵(RTM)。RTM是各个项目的核心，是很多开发标准(包括IEC62304)的关键所在。

需求跟踪与SOUP

需求跟踪矩阵是一种用于管理和跟踪需求的习惯做法，在管理软件需求和系统所用SOUP项目方面起着重要作用。RTM能够通过医疗器械应用的架构设计在与SOUP有关的高级需求之间实现可追踪性(图2)。