| UML软件工程组织 | |||
| |
|||
|
|||
在医疗设备软件中应用需求管理
2008-03-12 作者:Dean A. Leffingwell,
Don R. Widrig and Wayne T. Morrissey 来源：IBM
在过去10 年中，医疗设备软件开发的技术发展水平经历了巨大的变化。从过去 10-15 年间的医疗软件规格说明书中，FDA 已经意识到，规格说明书还有待于大幅度地改进。实际上，FDA 发现，这期间大约 44% 导致厂家自愿召回产品的质量问题，归因于特殊医疗设备的设计错误或设计不足，而不是因为制造阶段的错误。而且，似乎可以通过充分的设计控制来避免这些错误。 医疗设备软件的规格说明书在过去10 年中，医疗设备软件开发的技术发展水平经历了巨大的变化。从过去 10-15 年间的医疗软件规格说明书中，FDA 已经意识到，规格说明书还有待于大幅度地改进。实际上，FDA 发现，这期间大约 44% 导致厂家自愿召回产品的质量问题，归因于特殊医疗设备的设计错误或设计不足，而不是因为制造阶段的错误。而且，似乎可以通过充分的设计控制来避免这些错误。 为了能够随着全球市场的不断演进来规范化美国的标准，并且为了改进医疗设备开发的规格说明书，1990 年美国通过了启用立法，来赋予 FDA 必要的职权范围以管理医疗设备软件的开发。启用立法包含在 1990 年安全医疗设备法（SMDA）中，是 FDA 大幅度修订其对医疗设备涉用软件开发设计监督不足的动力。 安全医疗设备法的通过，对以前的 GMP 规范起到了大幅度的修订作用。新的 GMP 规范刚刚通过批准，并且对医疗设备软件产生巨大影响。简而言之，新的 GMP 规范（现在也称作 Quality System Regulation（QSM））在 1997 年 6 月到 1998 年 6 月期间的过渡时期生效。在过渡期结束前，所有的第二类（Class II）和第三类（Class III）医疗设备及其软件开发，必须与 QSM 中规定的开发过程标准保持一致。 QSM 对建立现代软件开发实践起到了优秀的指导作用，这是个好消息。实际上，这些规定的实践是通过 QSM 中的规章，经过细致工作而作出的，以便与您所熟悉的标准相一致。QSM 是为了遵从 IEEE 软件工程标准或 ISO 9001、IEC 601 或 EN 46001中的全球化标准而特别编制的。还有一个更好消息，QSM 中没有绝对要求的标准。因此，您可以根据现有的标准来塑造自己的开发过程，并且能够调整过程模型使其满足您特有的开发需要。 自从 1984 年以来，FDA 为建立设计控制（包括安全和效率），并将其作为整体质量过程的一部分，做出了艰苦的努力。现在，随着 QSM 的实施，医疗设备软件开发的质量保证工作向前迈进了一大步。在本文的下一部分中，我们将探讨一下需求管理工具（如RequisiteProTM）如何帮助您高效地自动完成 QSM 规定的许多任务，这些任务是世界级医疗设备和产品开发过程的一部分。 下面第 1 部分概述了医疗设备软件开发过程要求的结构和文档编制。在第 2 部分中，我们将探讨一个医疗设备开发计划实例，并且考查一下 RequisitePro 工具所提供的功能，以及该工具所提供的对设备需求自动化和管理的支持。 第1部分 制定可以接受的开发计划从1997年中开始，Quality System Regulation（QSR）规定，应该建立可广泛使用的、良构型计划，用于依赖于软件而工作的医疗设备软件开发。尽管 QSR 规定了要建立计划，但并未规定这样的计划或过程（通过该过程开发软件）的内容。为了能得到这方面的深入见解，有必要熟悉另一个 Office for Device Evaluation （ODE）组织公布的新的 FDA 指导文档："用于医疗设备涉用软件上市前提交内容的 ODE 指导方针"（草案）。该文档是一个指导性文档，不具备规章效力。但是，该文档包含大量关于如何制定计划的实用建议，我们将这个文档称作"ODE Guidance"文档（OG）。 OG 的附录 A 定义了许多软件开发生命周期中截然不同的阶段。附录 A 定义了以下主要的生命周期域：
在本白皮书中，将讨论每个域的要点，从而建立过程和每个阶段所需文档的概要。在本白皮书第 2 部分中，将使用 RequisitePro 工具箱来自动处理用于支持这些阶段的需求管理活动，并为这些需求管理活动提供支持。 OG 的 A. 2 部分指出了确定和分析终端用户的产品功能性需求和性能需求的重要性。Rational软件的需求管理团队是这方面的业内领袖，并且他们已经公布了一些文章和教程，为收集和分析需求信息的至关重要性提供支持4。为了组织和管理这项工作，许多医疗设备项目，都通过定义和使用这三种不同类型的文档，获取良好的服务，来收集和管理需求：产品需求文档（PRD）、软件需求规格说明书（SRS），以及危害分析（HA）。这些文档形成了实现文件结构的顶层，其最初出现的形式如图 1 所示。 
产品需求文档 (PRD) 通过 PRD 收集、分析和定义用于设备的产品功能和用户需要。尽管没有可用于该文档的普遍采用的标准，但 RequisitePro 为产品需求文档提供了一个模板，可作为管理项目需求的起点。 PRD 的编辑工作可以从企业市场开发工作和临床专家的协同工作开始。它为市场部门提供了一个模板，用来记录高级用户需要，并且建立设备的临床要求。 它还应该作为组织要素，重点用于安全特性、与标准保持一致性、临床要求，甚至用于后续的市场抵压品。 软件需求规格说明书 (SRS) 通常，需求的收集工作开始时是非常抽象的，结束时能够获得一整套高级产品特性。这些特性记录在上面讨论过的 PRD 中，并通过 PRD 进行管理。SRS 是针对 PRD 中指定的依靠软件实现的行为而编写的。在现代医疗设备中，软件可以出现在用来使设备运转的嵌入式微控制器中，也可以作为某设备与其他设备接口中的一部分，或者设备可以包含外部的、独立的软件，用于数据后处理。无论软件有何种功能，所有的软件需求都应该记录在一个或多个 SRS 中。 软件需求提供了一个关于软件必须做什么工作的详细规格说明书，而不是用来说明如何设计或实现软件。编辑软件需求文档时，可以遵照 201 Principles of Software Development （201 项软件开发原则）第 3 章列出的原则清单。 编写 SRS 时需要考虑的要点包括：
IEEE 为正确编写 SRS 提供了一个优秀的讨论集和模板集。参见 IEEE 830-1993，Recommended Practice for Software Requirement Specifications（软件需求规格说明书的推荐实践）获取更多信息。RequisitePro 将 IEEE 的推荐纳入到其文档格式的基本模板中，从而允许快速完成该文档，并进入编辑需求文档的工作。 危害分析 (HA) 危害分析（HA）是设计过程中一个重要的早期文档。FDA 强调 HA 是改进医疗设备质量的关键要素。实际上，OG 的整个 2.8 节都在讨论关于风险管理和危害分析的问题。危害分析是： "以用户和病人的视角，对设备进行的详细检查。危害分析的目的在于，发现潜在缺陷，即引起危害的错误可能性，从而使制造商能够在设备投入使用之前改正这些错误。" 正如上面所提到的，HA 要求设计人员考虑产品中可能出现的，也是正要构建产品的各类和各种错误。随着对每项危害进行检查，并将其记录到 HA 文档中，设计人员能够记录潜在危害，然后提出能够减轻危害的设计策略和功能需求。 随着 OA 草案和 CGMP 的诞生，为传统的危害分析方法中增加了新的、更完善的风险分析方法。 OG 的附录 B 部分建议了 20 项事项，要求处理 HA 问题时进行详细阅读。FDA 发现，医疗设备产品开发涉及这些事项时，会引发特定的风险，我们建议把这些事项纳入到 HA 中。 在产品开发生命周期的后期阶段中，HA 将作为实际的文档，来记录潜在危害和用于防止危害发生的风险缓解策略。在后面的系统验证阶段，将对该文档进行访问，从而确认所有预期危害都已经被考虑到，并得到解决。 OG 的附录 A.3 是实现过程的开始。在此阶段中，功能性需求和安全需求被分配到产品的硬件和软件方面。通过对比研究，有可能确定最有效的实现方法。 产品开发生命周期这个阶段产生的关键文档是配置管理计划（CMP）。可以在现行标准 IEEE 828-1990，Standard for Software Configuration Management Plans 和 IEEE 1042-1987，Guide to Software Configuration Management 中，找到关于 CMP 的概念、设计和使用方面的精彩论述。 因为 CMP 是一个项目级指导文档，因此它独立于实现文档树。最初项目级文档树如图 2 所示： 
OG 附录 A.4 讨论了软件需求由 SRS 转化成源码的过程。为了标准化这个实现过程，OG 推荐采用格式指南、编码标准等。在该活动中，还推荐了走查测试和基准测试。通常，围绕某类实现单元来组织软件，例如代码模块、子例程、对象类等。因此，明确地，或隐含地建立了另一个文档集，即实现单元集。 随着实现文档的逐渐可用，应该将其加到图 3 所示的实现文档编制的结构中、 OG 推荐，在实现单元和规格说明与该实现过程的 HA 之间，开发人员应严格坚持审计跟踪。在第 2 部分讨论可跟踪性时，我们将讨论如何完成这项工作 
OG 附录 A.5 包含验证活动。IEEE 这样定义"验证"： "它是用来评价某一系统或某一组件的过程，来判断给定阶段的产品是否满足该阶段开始时施加的条件。" 换句话说，验证活动在很大程度上是一种普通的测试活动，要求您验证每个开发阶段（例如软件某项需求或多项需求的实现）是否符合先前阶段定义的需求。为了寻找一种验证方法，您需要一个计划。 经过合理组织的项目应该包含 Verification and Validation Plan（VVP）。通常，在 IEEE 1012-1987，IEEE Standard for Software Verification and Validation 和 IEEE 1059-1993，IEEE Software Guide for Verification and Validation Plans 中，IEEE 提供了优秀的指导，用于建立一个 VVP。注意 VVP 是用来建立验证测试和确认测试规则的项目级文档。因此，该文档可以作为一个项目级文档而"占据一方"，在这点上，它与前面曾提到的 ConfigurationManagement Plan (CMP) 相似。项目文档编制树如图 4 所示。 
OG 推荐，在验证活动和产品规格说明书与该实现过程的 HA 之间，开发人员应严格坚持审计跟踪。在第 2 部分讨论可跟踪性时，我们会探讨这个问题。 同样，OG 附录 A.6 推荐了多种确认活动。IEEE 这样定义"确认"： "它是开发过程中间或结束时对某一系统或某一组件进行评价的过程，以确定它是否满足规定的需求" 换句话说，您需要确认已经实现的组件实际上按照规格说明书进行工作。通常，用测试来完成这项任务。再一次强调，确认计划是必需的。按照惯例，确认计划是前面讨论过的 V 和 V 计划（VVP）的一部分， 确认活动与测试同步进行。但是，好的测试计划是什么样的呢？幸运的是，IEEE 回答了这个问题。IEEE 829-1983, IEEE Standard for Software Test Documentation 提供了广泛的内容，包括如何建立测试方法、进行测试、报告测试结果，以及如何解决异常问题。 注意进行软件测试时，应从两个角度确定被测部件的正确性：1）被测部件是否满足实现单元规格说明书，并且 2）被测部件是否满足其控制需求。也就是说，不仅要通过测试来确认部件能够正确运行，而且要确认被测部件满足原始规格说明书。测试文档是实现文档中的一部分。考虑到测试文档，实现文档树应如图 5 所示。 
OG 推荐，在确认/测试活动和产品规格说明书与该实现过程的 HA 之间，开发人员应严格坚持进行审计跟踪。通过需求可跟踪性的机制来提供这项审计跟踪。 OG 附录 A.7 规定了关于变更管理的一些事项。注意在前面的步骤中，您已经对 Configuration Management Plan (CMP) 有了一定了解，现在，您要确信 CMP 是变更管理领域中一个全面的管理计划。 变更是现代软件开发项目的一项规范，为高效管理变更，您必须：
非常幸运，前面部分论述的 CMP 中，已对这些问题进行了详细阐述。在本文第 2 部分中，我们将阐述用于分析和管理变更带来的影响的技术和机制。 OG 附录 A.8 推荐，验证和确认（V&V）活动应由局外方进行。通常，从事日常开发工作的人员容易形成"盲点"，可能会忽略某个医疗设备设计和开发中的潜在问题。因此，FDA 推荐由技术上合格人员进行项目独立评审，原则上，这些评审与您自己进行的 V&V 活动没有差异。事实上，使外部评审员熟悉现有 VVP，将会提高评审效率，但您可能更加期望在开发新领域时，这些评审员能够加入 VVP 中，并对其进行修订。 与前面的 V&V 活动案例一样，您应该就如何坚持在 V&V 活动（和相关文档）到高级规范和 HA 之间进行跟踪作出计划，在第二部分中讨论可跟踪性时，将对这个问题进行讨论。 关注级别与上述生命周期部分无关。关注级别（LOC）是 OG 的一项特殊关注事项。简单的说，LOC 参与识别设备错误的重要性和这些错误与病人安全之间的关系。也就是说，如果设备产生了错误，该错误会对病人造成严重伤害吗？会对病人造成较小伤害吗？或目前将对病人造成最小伤害吗？LOC 是一项复杂问题，OG 草案尚未完全决定是否采用它，事实上，LOC 引发了一系列建议的草拟方法，FDA 也许会在最终发布 OG 时采用这些方法。 传统的 LOC 方法倾向于将所有关于设备方面的内容集合到一个单个的 LOC 评估文档中。在传统方法中，设备最为安全攸关的功能，受到关注并用于建立一个 LOC 评估文档。采用收集方法的劣势在于，设备中一个单一的高安全级别方面促使生成一个高级别 LOC，进而，促使整个设备和所有组件，都作为高级别 LOC 来对待。事实上，这样的设备通常有许多不是高级别 LOC 的功能，这些功能可以在更加宽松的 LOC 基础上进行开发。 为避免产品低级别 LOC 部分开发中的资源浪费，在处理具有不同级别 LOC 的需求问题时，我们将更强调选择性。以这种方式，可以按照与不同部分 LOC 一致的方式，区别地管理项目的不同部分。 为了有效地划分项目，在 PRD 级采用逐项功能分析法，在 SRS 级（和HRS级）采用逐项需求分析法，来评估和分配 LOC。在第 2 部分中您会发现，RequisitePro 提供了功能和需求属性，用来处理和管理项目的不同 LOC。 第 2 部分 作为开发计划的一部分，实现软件需求管理为证明 RequisitePro 需求管理工具能够提供管理功能，我们将考查一个简略的医疗产品开发项目中的软件开发过程。本例中设备是一个假想设备，称为 Reverse Angioplasty Pump(RAP)。 创建一个产品需求文档 (PRD) 为正确定义产品临床功能和市场功能，用 RequisitePro 工具来创建一个产品需求文档（PRD）。RequisitePro 为该文档提供了一个模板，可以修改该模板以满足特定的设备需要。RequisitePro 与 Word 无缝结合，使您可以创建最初的 PRD。另外，该工具允许文档编辑人员在该文档内部标识特定产品需求（PR）。图 6 显示了从 PRD 中节选的一小部分。 
注意 RequisitePro 工具允许通过双下划线或以用户定义的样式，来自动强调某些需求。强调方式是我们推荐的一种有力的可视辅助形式，用来帮助阅读者快速定位特定行为问题、性能问题和安全问题等。 图 6 既标识了硬件功能也标识了软件功能，但为了简化本文，我们将所有的功能都当作产生软件需求的因素。这种做法不会忽略普遍性，但在实际的项目中，可以对硬件功能和软件功能（在文档中记录这些功能）加以区分，从而创建更精确的需求文档。 在标识产品需求时，RequisitePro 为每项产品需求分配唯一标识符（PR4, PR5等）；从而遵照第 1 部分中提到的 FDA 指南。 RequisitePro 还应该用来分配和维护属性集和 PRD 中每项 PR 值。 现在，我们将使用 Attribute 功能，在逐项功能分析法基础上，对关注级别（LOC）进行归类。随着每项功能被定义，可以插入属性值，即我们为 PR 定义的 Concern 属性。可以用 RequisitePro 定义属性并定义可选值清单。然后，随着功能被定义，您可以评估 LOC，并用 Concern 属性来记录评估结果。RequisitePro 提供了易于使用的选择和排序功能，使您过后可以只选择具有精选的 LOC 的那些功能，或选择团队感兴趣的其他属性和属性值组合。 在项目的任意位置，都可以用 RequisitePro 来打印文档，或显示数据视图，从而提供所有定义的 PR 的当前清单。可以根据不同属性，以特有角度，对该视图进行过滤或排序。表 1 显示了一个这类视图的一个样例。 
创建软件需求规格说明书 (SRS) 同样，可以依据模板，用 RequisitePro 为产品创建、编辑、和维护软件需求规格说明书（SRS）。图 7 显示了该文档的一小段摘录。 
在 PRD 例中，我们已经强调过软件需求（SR）。如前，标识软件需求时，RequisitePro 为每项需求分配唯一标识符（SR1、 SR2等），从而遵照第 1 部分中提到的 FDA 指南。 RequisitePro 还应用于分配和维护属性集和 SRS 中每项需求属性值。注意可以为每类需求独立地分配属性和属性值。注意我们已经通过与 PRD 中所用的相同属性概念实现了关注级别问题，但我们还定义了与 PRD 不同的属性。表 2 显示了一个 SR 视图样例和它们的一些属性。 
与 PRD 例一样，可以用 RequisitePro 的查询引擎，对具有指定的属性值集合的 SR 进行排序、摘录和管理。 创建危害分析 同样，可以用 RequisitePro 来为产品创建、编辑和维护危害分析（HA）。使用 RequisitePro 时，应创建一个 Word 文档，来详细记录软件（也可能是硬件）安全需求。 PRD、HA 和 SRS 一般完成后（不必等到批准"最终"版本），应开始建立这些文档之间的关系。目的是了解某一文档中的元素与另一文档中的元素是何种关系，如图 8 所示。 
每个文档中的单个元素，应与另一文档中的适当元素链接。也就是说，SRS 中每个 SR 项要与 PRD 中控制它的 PR 项关联起来。反之，将每个 PR 项和它控制的 SR 项进行匹配。注意这项匹配可以是一对多，多对一，或多对多。 同样，HA 项也要进行对应的关系链接。RequisitePro 未要求严格的关系分级结构。因此，允许所有的垂直关系（如 PR-to-SR）和所有的平行关系（如 HA -to-SR）。非分级结构关系是大多数开发项目的常见部分，并且不暗含特殊特征。 无论是何种关系，将相关项链接起来都非常重要。该链接过程称作可跟踪性。 优质软件实现过程中一个重要因素是，跟踪能力要贯穿整个实现过程，包括规格说明阶段、构架阶段、设计阶段、实现阶段，以及 V&V 阶段。实际上，跟踪关系的能力，并将这些关系与变更管理问题关联起来，成为贯穿新的 OG 的关键线程。另外，CGMP 的 Design Controls 部分，即 CGMP 的 Subpart C 再次重申在产品开发生命周期范围内，在不同工作产品之间建立关系跟踪能力的重要性。IEEE 提供了两种可跟踪性的工作定义： 1）"在两种或多种开发过程的产品之间建立关系的程度，特别是相互之间具有前后关系或主从关系的产品；例如，给定软件组件的需求与设计之间的匹配程度"。 2）"某一软件开发产品的元素存在原因的程度；例如，一个泡式图的元素为需求提供参考的程度"。 可跟踪性的一个要素是，对某一"可跟踪性关系"意味着什么作出的定义。使用 RequisitePro 工具，可以按照简单的"traced-to"和"traced-from"模型，方便地定义某种关系。例如，我们很容易设想，在系统中建立一个或多个软件需求（SR），来支持产品需求（PR）中指定的某一给定功能。从而可以说，从一个或多个 PR，对 SR 进行跟踪。在已建立的需求类型的环境中，可以赋予关系另外的意义。例如，如果从一个 SR 跟踪到测试用例需求型，可以推出该软件需求是"通过测试用例进行测试"，也就是"traced-to"型。从一个 SR 需求来跟踪类描述，意味着需求是通过该类来实现的。使用 RequisitePro 工具，对可定义的需求类型没有数量限制和类型限制。另外，给定类型的需求可以在任意文档范围内出现。例如，不必只有 SR 类型需求才能驻留在用于描述软件需求的文档中。 RequisitePro 提供了一个简单的 user-guided 过程，通过可能存在于生命周期中两个元素之间的关系，来"指向并点击"（point and click）。在定义了 PR 和 SR 之间的关系后，RequisitePro 可以显示 PR 和 SR 之间关系的矩阵图，如图 9 所示。 图 9 中可跟踪性矩阵是直接实现的。例如，可以考虑 PR8（远程数据通信）和 SR1（调制解调器端口）的相交部分。在相交部分的网格中，" "箭头表明，从 PR8 跟踪到 SR1，可以得到某种关系。也就是说，SR1 来自 PR8 定义的某种功能，或者 SR1 以某种方式满足 PR8 定义的功能。 
用 RequisitePro 建立了所有已知的关系后，在 FDA 指南的有力支持一下，检查可跟踪性矩阵的以下两个潜在错误是一项有益的需求管理活动： 1. 如果在某行中未能检查到任何可跟踪性关系（未检查到"箭头"），说明可能尚未为 PRD 要求的某项功能定义软件需求。该功能如果通过软件之外其他方式实现（例如，外壳由不易破碎的塑料制成），这种情况除外。尽管如此，空行意味着可能存在潜在错误，应该对其进行仔细检查。RequisitePro 可以自动完成这类检查。 2. 如果在某列中未能检查到任何可跟踪性关系，说明可能没有已知的产品功能需要这项软件需求。这表明对 SR 的任务可能存在误解，或者表明原始 PRD 中存在弱点，或者表明 PRD 中存在死码或不支持系统需求的代码。不管是哪种情况，都要进行仔细检查。 除提供了一套工具集来查询已建立的关系之外，RequisitePro 还提供了一种简单的方法来存储查询结果并且可以过后再调用它们。该项功能允许您过后再重新访问建立的关系，也许在变更发生之后快速重新查询关系，从而发现潜在的问题点。 简单明确地应用上述技术，使您能够把项目中许多元素关联起来。您应该仔细考虑以下的链接和关联
如上建议，把不同文档中的不同元素链接起来之后，可以建立如图 10 的关系。 
RequisitePro 还提供了显示项目中全部可跟踪性关系集的功能。图 11 显示了这样一个"树"视图。注意树视图（或部分树视图）允许同时查看项目所有关系。您应该利用树视图来帮助充分理解项目的总体关系。 例如，图 11 的树视图表明，PR3（一个产品需求或功能）链接到 SR1（一个软件需求），SR1 又链接到 TST4（一个测试规格说明）。 元素之间建立了链接之后，RequisitePro 将用于保持这些链接。利用 RequisitePro 的强大功能，可以任您所需地来检查项目元素之间的关系。一项关键的需求管理活动为您提供了一种常规的检查功能，那就是利用可跟踪性关系来检查项目中建议的变更、和已经实现的变更带来的影响，该类活动在 OG 和 QSR 中称为变更管理。 
变更管理实践帮助您理解和管理以下项目开发的三个重要方面： 1. 如果某一元素建议进行变更（例如，一个单一的产品需求），那么按何种顺序进行变更工作呢？换句话说，变更管理帮助您回答了当某一元素要发生变更时，如何确定重新工作所需的工作量。完成一项变更的工作量可能会对项目资源规划和工作负载规划造成显著影响。 2. 如果某一元素建议进行变更，那么该项变更会对系统其他元素造成什么影响？这个论题无论对您的项目规划还是对 FDA，都是备受关注的问题。经验表明，软件某项变更不可避免地将会对其他部分造成负面影响。这项问题对于设计和实现可靠的医疗产品尤为重要，FDA 特别要求将有组织的变更管理程序作为设计过程的一部分。 3. 进行中的项目不可避免地会发生顺序错误。项目中将会有某一时刻，您想要"退回去"，检查某项需求和某项需求在前面所作的修改。另外，记住为什么要进行修改和怎样修改，对您很有帮助。换句话说，为每项需求建立审计跟踪特别具有价值。这不仅有助于您的项目，而且 FDA 也要求把可审计性作为一部分纳入设计过程中。 受变更影响的元素 建立了项目中可跟踪性关系后，可跟踪性链接可以用作一个变更管理工具。让我们通过前面图 9 显示的可跟踪性矩阵来检验一下这项功能。假设PR8（远程数据通信）需要进行改动来反映修订后的产品功能。使用 Word/RequisitePro 对 PRD中PR8 进行编辑后，我们发现前面图 9 显示的可跟踪性矩阵通过 RequisitePro 自动发生改变，改变后如图 12 所示。 在图 12 中，注意网格中的对角线，这些对角线勾划了 PR8 对应行中的可跟踪性箭头。这些对角线称作"可疑链接"，是 RequisitePro 自动插入的，用于提醒您 PR8 的变更可能对 SR1、SR2、SR4、SR5 和 SR6 产生影响。 
随着项目的进展，您会发现，项目的很多方面都有变更提议。这些变更可能发生在项目的任何地方，从高级 PRD 一直到规格说明、实现过程和测试。无论变更何时发生，RequisitePro 都将自动插入可疑链接标记来提醒您可能受到变更影响的关系。当检查交互作用时，您可能发现受到影响的元素可能发生变更，也可能不发生变更。变更管理活动通常包含以下两个步骤之一： 1、如果受到影响的链接不会发生改变（例如，PR8 的变更不会影响到 SR1），那么只需用 RequisitePro 来清除可疑链接即可。请注意，过后的 PR8 变更可能在某一时刻再次将其标为可疑链接。 2、如果受到影响的链接发生了改变，可能需要为这些元素重新设置链接。例如，PR8 建议的变更可能要求对 SR2 进行重新说明。编辑完 SR2 后，将发现 RequisitePro 又自动插入了另外的可疑链接来提醒您可能受到 SR2 变更影响的元素（PR4，General ECG）。然后，需要检查那些变更带来的交互影响，等等。 RequisitePro 实际上提供了所有级别可跟踪性关系的变更管理功能。也就是说，改变 PRD 中 PR 项可能对 SRS 中若干项 SR 产生影响，这些影响随后又会对某些实现单元产生影响，而实现单元受到的影响随后又会对一个或多个测试计划产生影响。RequisitePro 还对可跟踪性链接进行双向跟踪。例如，测试计划规格说明书的变更可能需要回头来检查实现单元（IU）以确定是否对其产生影响。随后，改变 IU 可能要求您复查受到影响的 SR，甚至要求复查高级 PR，这些 PR 都是通过已建立的可跟踪性关系而最终进行链接的。 在所有情况下，RequisitePro 的跟踪活动贯穿了可跟踪性链接，并且在适当的地方插入可疑链接标记。这项强大功能为您提供了一个简单的方法，来跟踪项目中变更带来的影响。 变更历史记录的审计跟踪 RequisitePro 提供了一项强大功能，用来保持变更的审计跟踪。这项功能的最大用途在于，对单个需求发生的变更自动进行跟踪。RequisitePro 独立管理每项需求，尽管需求包含在文档中。这样，RequisitePro 能够自动捕获每项需求发生的变更，并且您可以过后检查和评审这些变更。 通过变更的历史记录来捕获当前的需求说明，包括当前的所有需求属性值。通过捕获所有当前的需求参数，可以将历史记录用作查看所有需求参数的简洁方法。这项功能类似于 RequisitePro 其他功能所提供的常用属性查看方法。 变更的历史记录还使您能够查看较早的需求变更的历史记录（这些记录是按时间顺序排列的），包括他们的属性。RequisitePro 能够自动捕获某项需求所有的文本变更和需求属性值的变更。 无论 RequisitePro 何时检测到一项变更，它可以自动捕获该项变更的背景情况。另外，RequisitePro 还可以自动捕获某项变更的创建者（例如，用 RequisitePro 进行变更的人）和该项变更的日期和时间。然后，在过后的任何时间，按时间顺序排列的变更和变更创建者可以作为历史记录的一部分来查看。 另外，RequisitePro 允许输入一项变更描述来记录该项变更。通常，用一两句话来解释为什么要进行变更，建立关于变更的项目备忘录参考资料，等等。将变更记录下来，可以得到令人满意的基本的变更理由和相互参照，从而在后面做历史记录检查时，可以充分地回想起某项变更的动机。在 FDA 评审那些影响到设备的临床要求、效率和安全性的变更时，这是一项关键要素。 图 13 显示了部分 SRS 需求历史记录（SR7）样例。注意变更的历史记录是按反向时间顺序排列的，并且记录了文本变更（#1.0006对 #1.0005）和所选属性值（#1.0005）的变更。变更可能是非常细小的，例如 1.0005 和 1.0006 的文本变更，仅仅是改变了"cpu"的字母大小写。即使如此，极小的变更也要作为一项变更，通过 RequisitePro 正确地记录下来。 
(rest of history truncated for this example) 配置管理与变更管理 在使用 RequisitePro 工具进行管理的项目中，强大的变更历史记录功能有三个级别： 1. 在最好的细节级别上，变更历史记录对项目中每项单个的需求的所有变更进行记录。图 13 显示了该细节级别。 2. 在中等细节级别上，RequisitePro 用于与常见的行业配置管理工具（包括 PVCS 和 Visual Source Safe）集成，从而自动保持每个已知项目文档的类似的变更历史记录。 3. 在最普通的细节级别上，RequisitePro 用于与配置管理工具进行链接，从而自动保持整个项目的勒死的变更历史记录。在这种模式中，RequisitePro 还提供了安全访问，来防止关键项目文档的非授权变更。RequisitePro 还用于保持项目级的内置的项目存档功能，从而允许您为处于特定开发形态中的项目进行"快照"。 借助于这些功能，RequisitePro 实现了与公共应用程序的自动且无缝集成，在配置管理任务中起到辅助作用，这些配置管理任务对于管理高可信度软件项目至关重要。 结束语随着最新的 FDA 规范的出台，医疗设备制造商正在面临着更加严格的医疗设备开发过程和医疗设备软件开发过程的管理方针。预计这种趋势将不断加深。不良的设计控制不仅意味着产品不能通过 FDA 评审，而且也无法满足客户的期望，还可能导致项目超过日程计划一半，以及相关的成本超支，而且最严重的后果将导致项目终止。 同时，我们正在开发复杂性不断增加的系统，要求对项目组成组件有更好的了解。不断出现的用户要求，促使形成了一个系统的设计控制的方法，该方法是完全有必要的。了解需求管理过程，并且将其用于开发医疗设备，是实现成功的项目设计、测试和管理的根本所在。 通过以原有形式输入需求文档和对其进行评审这两个功能的结合，并且链接到中心库（库内容包括需求、规格说明、属性和它们之间的可跟踪性链接），可以建立一个可以控制的机制，用以确保一致性和设计质量。通过使用 RequisitePro，使项目团队能够管理设备的设计过程，改进团队之间的交流，更清楚地定义项目基线，以及更高效地管理资源。另外，RequisitePro 提供了需求可跟踪性和变更管理的自动支持功能，从而降低了开发成本，并且通过消除许多人工活动易范的错误，而提高了产品质量。 将 RequisitePro 整合到医疗设备团队的设计控制过程中，可以提供一个更加自动化的方法，来开发能够按期交付的、预算内的产品，从而满足客户的真正需要，并且确保病人的安全。 建议阅读Software Requirements - Objects, Functions, & States, Davis, Alan M., Englewood Cliffs, NJ: Prentice Hall, 1993. Exploring Requirements - Quality Before Design, Gause, Donald C., and G. Weinberg, New York, NY Dorset House Publishing, 1989 如需订购这些书目，或加入网上论坛来讨论需求管理问题，请与 Rational 软件集团公司联系，4900 Pearl East Circle, Suite 106, Boulder, CO 80301，电话：(303)-444-3464，传真：(303)-444-3413，电子邮件：information@rational.com 缩写词汇表510(k) 关于上市的医疗设备（与市面上已有的医疗设备相似）方面控制立法的组织的简写。用法类似于用来指联邦管理下的公司储蓄计划时的"401(k)"。 CDRH Center for Devices and Radiological Health 参考资料
|
| |||
组织简介 | 联系我们 | Copyright 2002 ® UML软件工程组织 京ICP备10020922号 京公海网安备110108001071号 |
