本文档旨在为ClearCase 和ClearQuest产品的操作、使用和扩展提供对当前功能和可能战略的洞察力，以按照21 CFR Part 11的规范解决电子签名和电子记录的兼容问题。

文档摘要

本文遵照美国食品及药物管理局（FDA）的21 CFR Part 11条款，描述了解决"良好电子记录管理"（GERM）的兼容问题。

在高度规范化的食品和药物行业内转换一个公司的软件开发实践是一项很有挑战性的事情。GERM的复杂性是显而易见的--从理解FDA需求到创建良好制造流程，从培训员工到实现加工。

成熟的软件开发流程和配置管理流程可简化软件开发团体中的GERM开发。来自IBM Rational的业内领先的产品ClearCase® 和 ClearQuest®为在自动化系统的生命周期中生成的工件的管理提供了健壮的配置管理和变更请求管理解决方案。尽管这些解决方案提供了即开即用的功能，满足了当前的GERM实践，但是软件开发团体应该采取措施，扩展这些功能，以便提供额外的记录保护。

本文档旨在为ClearCase 和ClearQuest产品的操作、使用和扩展提供对当前功能和可能战略的洞察力，以按照21 CFR Part 11的规范解决电子签名和电子记录的兼容问题。

假定

转换到GERM实践需要已建立的策略、步骤和流程，以及产品定制，以支持这些流程。Rational Unified Process（RUP） 提供了一个固定的流程框架，使客户可以为规章所需的策略和步骤的非自动实施草定策略、步骤和实践。

目标读者

下面的文档针对理解与他们行业的记录管理相关的规章或者行业做法的读者。

产品描述

Rational ClearCase--Rational ClearCase是一个配置管理（CM）和版本控制（VC）系统，重要用于电子工件的存储。ClearCase被作为一个文件系统实现，模仿和扩展了大部分本机文件系统的行为。在ClearCase中，不但可存储软件，还可以存储能在本机文件系统上存储的几乎所有文件类型。这些文件类型的例子包括文档、需求、模型、代码、目录等。

Rational ClearQuest--Rational ClearQuest是一个变更请求管理（CRM）系统，用于与自动化系统有关的更改请求或问题（软件bug）的跟踪。ClearQuest高度可配置，可适应几乎所有的自动化流程设计。ClearQuest支持用户定义、工作流支持（可定制的状态机）、字段、表单和电子邮件通知。

文档格式

讨论了21 CFR Part 11的每个主要章节，并提供了IBM Rational对该节的解释，因为它与Rational产品的配置管理和变更请求管理相关。

21 CFR Part 11简介

联邦规则法典（CFR）是联邦政府的执行部门或代理机构在联邦公报（Federal Register）上发布的通用和永久规则的法律化。CFR被分为50个代表联邦规则的各个广泛主题的条款（title）。每个条款又分割成通常以发布机构的名称命名的章。

第21条款由联邦食品和药物管理局拥有和控制。尽管这些条款的内容由相关机构制定和维护，但是对条款内容的交叉引用是很常见的事情。为了消除规章的重复和冲突，大部分机构交叉引用条款内容，以利用一致的消息集合规章。

比如，代理机构交叉引用条款、段、小段来构建一个规章以定义Title 21中的电子签名需求。

IBM Rational解释

IBM Rational开发该文档以描述如何通过使用Rational ClearCase 和 ClearQuest满足21 CFR Part 11。包含来自联邦规则法典的实际文本的段落在下面用斜体表示。规章描述中点缀的是解释性的陈述，解释了ClearCase 和/或 ClearQuest如何提供或者能够提供符合规章每个部分的功能。大概有三分之一的规章被用作定义自动解决方案的上下文。其余的三分之二适用于规则化的建立如何使用和管理技术。IBM Rational解释一节中没有遵循的部分规章是规章的用法和管理部分。

[注意：下面的斜体表明这些话是从联邦规则法典Title 21 Part 11中原文引用的]

联邦规则法典Title 21 Part 11；电子记录；电子签名

A小节--总则

Sec. 11.1 范围

（a）此部分的规则设立了标准，在该标准下代理机构将电子记录、电子签名和被转换成电子记录的手写签名看作是可信赖的、可靠的，并且等价于纸上签署的手写签名。

（b）该部分适用于在代理规则中设置的任何记录需求下创建、更改、维护、归档、检索或传输的电子形式的记录。该部分还适用于在《联邦食品，药品和化妆品法案》和《公共卫生服务法案》的需求下提交给代理的电子记录，即使这样的记录并没有专门在代理规则中标识。但是，该部分不适用正在或者已经通过电子手段传输的纸质记录。

（c）在电子签名及其相关电子记录满足该部分需求的地方，代理将视电子签名等同于完全手写的签名、首字母缩写以及其他普通签字，除非1997年8月20日生效的规则中明确要求。

（d）满足该部分需求的电子记录可能用于替代纸质记录，以便与Sec. 11.2一致，除非明确需要纸质记录。

（e）在该部分下维护的计算机系统（包括软硬件）、控制器和附属文档应接受FDA的检查。

IBM Rational解释--该节描述了FDA（下文简称"管理局"）感兴趣的记录工件。这些工件在谓词规则中被法典化，并且被看作等同于纸质记录。

Sec. 11.2 实现

（a）对于需要维护但是不向管理局提交的记录，人们可全部或部分使用电子记录替代纸质记录，或者用电子签名替代传统签名，倘若满足该部分需求的话。

IBM Rational解释--如果客户选择在ClearCase 和 ClearQuest内存储规范化工件，那么本文档（21 CFR Part 11）是适用的 。

（b）对于提交给管理局的记录，人们可全部或部分使用电子记录替代纸质记录，或者用电子签名替代传统签名，倘若：
（1）该部分的需求被满足
（2）要提交的文档或文档的一部分已经作为管理局所接受的电子形式提交类型在公共摘要No. 92S-0251中被标识。该摘要将专门标识何种类型的文档或文档部分会被接受以电子形式提交而无需纸质记录和管理局接收单位（比如专门中心、办公室、部门和机构）。没有在该公共摘要中指定的发给管理局接收单位的文档如果以电子形式提交会被认为是非正式的；纸质形式的文档会被认为是正式的，但同时必须有电子形式的文档。
关于如何（比如，传输方法、媒介、文件格式和技术协议）以及是否需要进行电子提交的信息可咨询管理局的目标接收单位。

IBM Rational解释--大部分情况下，客户不可能使用IBM Rational工具进行电子提交的交付和传输。但是，客户可能正在寻求用于电子提交的装配和交付的软件产品。这种情况下，IBM Rational产品可能成为这些计算环境的构建和服务的基础，或者甚至成为提交工件本身的基础，并因此可能受到定期检查。这种情况下，保证这些步骤反映了使用ClearCase和ClearQuest过程中受控的任何工件的生命周期管理很重要。

Sec. 11.3 定义.

（a）该法案201节中包含的术语定义和解释适用于该部分中用到的术语。

（b）下面的术语定义同样适用于该部分：
（1）法案是指联邦食品、药物和化妆品法案（201-903节（21 U.S.C. 321-393））
（2）管理局意味着食品和药物管理局。
（3）生物特征识别（Biometrics）指的是通过衡量个人物理特征或者可重复动作验证个人身份，其中这些特性和/或动作对于该个人来说都是唯一和可测量的。
（4）封闭系统意味着系统访问受负责系统中电子记录内容的人控制的环境。
（5）数字签名意味着基于发起者认证的加密方法的，通过使用一组规则和一组参数计算出来（这样签名者的身份以及数据的完整性可以得到验证）的电子签名。
（6）电子记录意味着由计算机系统创建、修改、维护、归档、检索或分发的文本、图片、数据、音频、画报或其他数字形式的信息表示方式的组合。
（7）电子签名意味着法律上等同于手写签名的，由个人执行、采用或授权的任何符号或符号系列的计算机数据编码。
（8）手写签名意味着由个人手写或者被执行或采用以按照永久的形式验证手写的手写名称或法律符号。利用写字或标记工具（如钢笔或铁笔）签名的做法得到保留。手写名称或者法律标记虽然按照惯例适用于纸张，但是也可适用于捕获名称或标记的其他设备。
（9）开放系统意味着系统访问不受负责系统中电子记录内容的人控制的环境。

IBM Rational解释--管理局为澄清规则中所用的某些术语提供了这些定义。应该注意到，相对于术语"生物特征识别"和捕获手写签名图像的技术，ClearCase和ClearQuest API使得使用这些不仅仅是用户ID和密码组合的识别形式成为可能。如果API使得可以与捕获和验证生物特征识别数据的设备以及捕获手写签名的设备通信。

Subpart B--电子记录

Sec. 11.10 封闭系统的控制

使用封闭系统创建、更改、维护或者传输电子记录的人应该使用可保证电子记录的真实性、完整性以及机密性，并保证签字人不能轻易抵赖的步骤和控制。

IBM Rational解释--ClearQuest和ClearCase都用作封闭系统。ClearQuest使用它自己的本机应用认证机制。ClearCase使用安装了ClearCase的客户端上的操作系统认证。不管是哪种情况，都应该草拟或更改适当的步骤控制，以保证两种情况下用户ID都受到正确对待。签署ClearQuest记录应该使用单独的用户ID和密码。很自然地，还应该为创建这些用户ID/密码建立步骤。

这样的步骤和控制应该包含：
（a）系统的验证，以保证精确性、可靠性、一致的性能，以及识别无效或已改动记录的能力。

IBM Rational解释--配置管理系统的验证应该像用于支持受管制活动的其他计算环境或计算工具那样与典型的良好系统实践合作。它的含义是客户应该准备包含系统生命周期（SLC）方法的计算机确认实践。在SCL活动涉及从市场购买技术的情况下，供应商的评估（供应商审计）很重要。用于审计活动的良好系统实践的一个例子如非经肠胃药品协会（PDA）的文档"Technical Report 32, Auditing of Suppliers Providing Computer Products and Services for Regulated Pharmaceutical Operations"中描述。

（b）以适合人阅读的形式和适合管理局检查、回顾和复制的电子形式生成精确和完整的记录副本的能力。如果管理局回顾和复制电子记录的能力有问题，应该联系管理局。

IBM Rational解释--ClearCase提供了重新创建任意版本的登入ClearCase系统的元素的能力，使得用户能够以可阅读的形式查看知识库的内容。如果使用专门工具创建ClearCase工件，那么可能必须使用同样的工具来提供有问题工件的可供人阅读的版本。比如，Microsoft Word以专有形式存储文档。如果Word文档存储在ClearCase知识库中，那么Word就需要在从ClearCase从检索时读取这些文档。正是因为如此，才建议不但应该对工件进行版本化，还应该对用于生产这些工件的工具进行版本化。

ClearQuest还可通过使用钩子和/或报告重新创建任意指定日期的记录。

（c）记录保护，以便实现记录保持阶段中的精确和迅速检索。

IBM Rational解释--ClearCase 和ClearQuest用于为它们支持的平台无限期地存储记录；这意味着数字信息的归档是可能的。然而，记录的长期保存作为记录生命周期的一部分是一个涉及记录格式、记录内容和记录上下文的复杂问题，更不用说在记录的有用期结束时有选择地丢弃（清洗）记录的需要。对丢弃记录的支持也是可用的。客户应该为ClearCase 和 ClearQuest建立记录保留策略，并且他们应该确定谁将丢弃记录。客户还被建议咨询他们的记录管理人员，以确定如何最佳利用ClearCase 和 ClearQuest工具实现归档目标。

（d）将系统访问限制在授权用户的范围。

IBM Rational解释--如前所述，对ClearQuest的访问受唯一的用户ID和密码组合的限制。ClearCase的访问被工作站认证所限。然而，还可以通过使用ClearCase触发器或ClearQuest钩子添加访问控制机制。你还可以为特定元素设置访问特权，以保证对不同元素具有不同的访问级别。

（e）对安全的、计算机生成的、时间戳审计痕迹的使用，以便独立记录创建、更改或删除电子记录的操作人员登记和动作的日期和时间。记录变更不应该是以前记录的信息。这样的审计痕迹文档应该被保留一段时间（至少保留主题电子记录所需的一段时间），并且应该对于管理局的检查和复制是可用的。

IBM Rational解释--ClearCase自动记录针对存储在它知识库中的所有对象的全部操作。ClearQuest需要创建一个钩子，以支持事务的字段级记录。然而，两种情况下，ClearCase和ClearQuest都存储了与格林威治标准时间（GMT）相关的日期-时间戳信息。对ClearCase元数据或ClearQuest历史和字段日志数据的检查可用于描绘那些已经发生的变更以及是何时发生的。

通过使用这种日志功能，放进知识库中之后被更改的记录可轻易地与未被修改的记录相区分。

（f）对可运行系统检查的使用，以便在适当的时候对步骤和事件进行排序。

IBM Rational解释--ClearQuest操作基于用户可定制的状态机。换言之，ClearQuest支持用户定义工作流的自动化。通过在用户定义的流程中的各种状态间移动记录对其进行操纵。ClearQuest根据哪些条件或动作需要实现（所需的字段）来收集数据，以便从一个流程状态迁移到另一个流程状态，比如一个批准流程中的状态或步骤。ClearCase也可以进行扩展，以充分支持状态机功能。可借助使用ClearCase API和基于属性的触发器的外部应用实现对ClearCase状态机的支持。实现定制状态机的客户需要保证ClearQuest自动化工作流基于手动策略以及设计期间的步骤。 ClearCase也可以进行扩展，以支持它自己的或者共享用户管理功能。实现这种支持的一种战略是依靠ClearQuest种提供的认证基础架构。该战略出于签名的目的允许用户ID被合并到单个存储和管理点。

（g）对授权检查的使用，以保证只有授权用户才能使用系统，对记录进行电子签名，访问操作或计算机系统的输入输出设备，变更记录，或者进行手头的操作。

IBM Rational解释--如上11.10(f)中所述，可能需要ClearQuest数据。所需数据可能包括在允许将记录提升到任意后续状态之前的适当的数字或电子签名的需要。该功能也可以如建议的那样通过ClearCase/ClearQuest集成来支持。但是，强调联合使用适当的物理访问手段以及该文档中所描述的功能很重要。

（h）对设备检查的使用，以确定数据输入源或操作指示的有效性。

（i）确定开发、维护或使用电子记录/电子签名系统的人具有完成他们指定任务所需的教育、培训和经验。

IBM Rational解释--IBM Rational为客户提供了使用它的工具所需的各种技术培训。为适应21 CFR Part 11而对Rational工具进行的配置需要客户创建符合他们具体配置的操作步骤的培训。IBM Rational服务机构以及很多的IBM Rational伙伴可以可在需要时帮助定制和提供培训。

（j）书面策略的建立和坚持，以便让签名人负起责任，杜绝记录和签名的伪造。

（k）对系统文档的适当控制包括：
（1）对文档的分发、访问和使用的适当控制，以进行系统操作和维护。
（2）为维护审计痕迹（审计痕迹归档了系统文档的时间序列开发和更改）而进行的修订和变更控制步骤。

Sec. 11.30 开放系统的控制

使用开放系统创建、更改、维护或传输电子记录的人应该采取步骤并进行控制，以保证电子记录自创建到接收之间的真实性、完整性和机密性。这样的步骤和控制应该包括Sec. 11.10中所讲述的内容，以及像文档加密和使用适当的数字签名标准这样的额外步骤，以保证该环境下记录的真实性、完整性和机密性。

IBM Rational解释--所有的IBM Rational产品包括ClearCase和ClearQuest都支持开放开发，并支持环境；因而，这些产品可用于上述的开放系统上下文。ClearCase和ClearQuest提供了自动实现11.10节中所述功能的能力，从而推动了其他措施的采用。

Sec. 11.50 签名的表现

（a）签署过的电子记录应该包含与下列内容相关的信息：
（1）签名者的姓名；
（2）签名日期和时间。
（3）签名的相关含义（比如检查、批准、职责或者作者）

（b）本节a)(1)、 (a)(2)和(a)(3)中所列的项应该受到与电子记录同样的控制，并且应该作为可读形式的电子记录（比如电子显示或打印输出）的一部分被包括进去。

IBM Rational解释--11.50(a)到（b）中所需的全部数据可以存储在ClearQuest记录中，在安全的不可更改的环境中也可以作为ClearCase版本和元数据存储。

ClearCase对该数据的报告如附录A中所示。

Sec. 11.70 签名/记录链接

电子签名和手写签名应该与它们相应的电子记录链接，以保证签名不被分割、复制或传输，从而避免了通过普通手段伪造电子记录。

IBM Rational解释--ClearQuest签名可直接存储在每个已签署的记录上，从而建立了与正在签署数据的直接链接。ClearCase元素将适当的签名作为元数据存储在给定文档的实际版本上，从而将文档的具体实例与它的适当签名链接。通常建议将签名作为最终的信息实体插入源文档。该方法对于接收某些类型的最终批准的工件来说有意义，并且绝不再更改。ClearCase支持该功能。

然而，软件组件（或者更准确地说软件代码）在插入外部数据流的过程中可能并且将会被破坏。此外，源代码不断进化（不断更改）的特性使得在源对象的生命期内插入大量的签名数据流不太实际。为此，ClearCase使用了元数据结构，允许数据流直接添加在源文档外面（详情请见附录A）。

Subpart C--电子签名

Sec. 11.100 一般需求

（a）每个电子签名都是唯一的，不能重新使用也不能再分配给他人。

IBM Rational解释--尽管这一部分实际上是针对程序上的控制，但是通常被误以为自动需求。Rational ClearCase 和 ClearQuest支持唯一的用户ID/密码组合。然而，使用该功能需要通知管理局何时在签署电子记录中使用电子签名方法。

（b）在一个机构建立、指定、担保或者批准个人的电子签名或者此类电子签名的任何元素之前，该机构应该检验个人的身份。

（c）使用电子签名的人在使用之前应该向管理局保证他们系统中的1997年8月20日之后用到的电子签名在法律上应等效于传统的手写签名。

（1）该认证应该以书面形式提交给Office of Regional Operations (HFC-100), 5600 Fishers Lane, Rockville, MD 20857.，并且必须附有手写签名。

（2）使用电子签名的人应该根据管理局的要求提供额外的证据，证明特定的电子签名法律上等效于签署者的手写签名。

Sec. 11.200 电子签名的组件和控制

（a）非基于生物特征识别的电子签名应该：
（1）至少使用两种截然不同的标识组件，比如标识码和密码。

IBM Rational解释--用户ID和口令的支持是通过在ClearQuest中使用钩子或在ClearCase中使用触发器来实现的。两种情况下都可以采用适当的加密方法。如前所述，需要采取适当的步骤，以保证已有的签名密码是由正确的人创建的。如果配置了对捕获手写签名的支持，那么可利用ClearQuest报告向签名权威提供统一的签名报告。

（i）当个人在一个连续的受控系统访问期间执行一系列签名时，第一次签名应该利用所有的电子签名组件进行；后面的签名应该至少使用一个电子签名组件，其中该组件只被该个人执行，并且本来就是仅供该个人执行的。

（ii）当个人执行一个或多个不是在一个连续的受控系统访问期间完成的签名时，各个签名应该使用所有的电子签名组件执行。

IBM Rational解释--如果不对Rational产品进行修改，不能期望支持"一系列签名"。预期ClearCase 或 ClearQuest中的每种状态变化需要单独的签名，从而同时需要用户ID和密码组件。

（2）只被它们的真正拥有者使用；并且

（3）被管理和执行，以保证除真正拥有者之外的任何人要想使用电子签名必须两个或更多人的合作。

IBM Rational解释--ClearCase 和 ClearQuest用于保证它们在操作上是安全的。跳过这些安全机制需要两个或两个以上人员的合作。

本部分规章通常被误认为是实现主要和备用签名支持的需求。

Sec. 11.300 标识码/密码的控制

根据标识码和密码的组合使用电子签名的人应该进行某种控制，以保证它们的安全性和完整性。这样的控制包括：

（a）维持各个标识码和密码组合的唯一性，以保证任意两个人不会具有同样的标识码和密码组合。 IBM Rational解释--ClearCase 和 ClearQuest提供了唯一的用户ID/密码组合。

（b）保证标识码和密码被定期检查、召回或修订（比如，以覆盖像密码过期这样的事件）。

IBM Rational解释--ClearCase 和 ClearQuest经过配置，可根据需要定期评估、召回密码和/或使其过期。ClearCase密码的过期是通过Windows 或Unix中的本机操作功能实现的。而ClearQuest密码的过期可通过构建一个基于应用的ClearQuest API来实现。该应用应该做为服务来运行，并且周期性地终止用户密码以及签名材料。

（c）采取遗失管理步骤，以便对那些携带和生成标识码或密码信息的丢失、失窃或潜在危险的令牌、卡和设备进行电子化地取消授权，并利用适当的严格控制进行暂时或永久替代。

IBM Rational解释--ClearCase 和 ClearQuest经过配置可电子化地取消ClearCase 或ClearQuest应用用户ID/密码组合或者签名用户ID/密码组合。关于推荐方法的完整描述请参见上面的11.300(b)。

（d）使用事务保护防止对密码和/或标识码的非授权使用，并在对系统的安全单元和机构管理进行非授权使用时进行及时的检测和报告。

IBM Rational解释--ClearCase 和 ClearQuest经过配置，可在签名过程中通知签名或登录管理员的误用/滥用。不管解决方案如何，期望的战略是采取措施防止误用用户ID和密码组合。该监控功能的扩展可实现为ClearQuest钩子和/或ClearCase触发器。

（e）对携带或生成标识码或密码信息的设备（比如令牌或卡）进行初始和周期性测试，以保证它们正确发挥作用，并且未经授权不会被更改。

IBM Rational解释--ClearCase和/或ClearQuest经过配置可使用内部安全令牌、传送卡以及其他外部设备。

一致性保护：

按照这里的建议进行实施的客户和IBM Rational专家必须警惕程序文档和运行日志的构建。这些文档应该与当前的良好做法以及行业规则一致。

解决方案实现：实际指南

概述

本文档后面的部分描述了解决规范市场需要的一致性解决方案的实现。该部分特别专注于解决受电子签名和电子记录影响的那些客户的需要。尽管本文档针对的是仅涉及ClearCase和ClearQuest的解决方案的开发，但是这里提到的功能还能解决很多需求、应用模型、设计和代码存储的很多问题。

这里提供的解决方案解决了用于规范系统的创建、更改和存储的软件应用的配置管理的一致性问题。这种类型的应用包括医疗设备软件、药物临床试验软件、交易厅系统软件以及在秘密/绝密环境中开发的联邦系统软件系统。

解决方案的定位

实现的总体解决方案类似于经典的ClearCase/ClearQuest集成模型。

为了与标准开发实践一致，还考虑了下面的理念，即各个产品（ClearCase和ClearQuest）应该独立运行。然而，在规范环境中运营的公司需要实施当前的良好做法，以便实现健壮的配置管理系统。当前的这些良好做法假定使用了变更请求管理、版本控制、自动工作区管理和构建管理。为了实现这些需求，该解决方案需要同时使用ClearCase和ClearQuest。因此，本解决方案的重点在于强调集成的设计上。

最终解决方案将允许用户通过一个用户定义状态模型提升ClearCase元素版本和ClearQuest缺陷。

安装、运行和过程质量测试

在任何规范的环境中，都会出现IQ、OQ和PQ测试问题。尽管这些术语对于不知道的人来说有些奇怪，但是它们只不过是用于证实产品被正确安装、正确运行并且符合预定设计的资格测试而已。

其中最容易创建的测试是安装质量资格（IQ）测试，因为它一开始就是ClearCase和ClearQuest产品的一部分。ClearCase 和ClearQuest的IQ测试驻留在它们相应的安装日志中。在各个安装阶段，按照设计Rational脚本检查各个组件是否正确安装，并记录结果。

运行质量资格（OQ）测试也可轻易创建，但是需要更多的工作。运行质量OQ测试验证产品是否如生产商设计的那样运行。

在这个具体的例子中，测试应该在实现ClearTeam Secure解决方案之后进行。为了创建OQ测试，需要编写一个执行下列ClearCase操作的脚本。

1、创建一个元素
2、main上的登出
3、main上的登入
4、允许你的配置通过认证将用户ID作为元数据捕获
5、为main上的元素标注
6、登出/登入，重新通过认证跟踪用户ID
7、来自已标记版本的登出和自动分支
8、登入，重新认证用户
9、登出/main/LATEST
10、从你的分支版本合并到/main/LATEST
11、登入，进行最后一次认证

现在你已经体验了ClearCase的所有基本功能，以及它与ClearQuest在用户认证方面的集成。该活动体现了正确的ClearQuest操作，并说明了供应商（IBM Rational）在测试该产品方面做了哪些工作。

PQ ora Performance Quality Qualification（PQ）测试的创建稍微有些困难。外行对PQ测试的定义是应用的测试，因为它用于长时间的使用。PQ测试是演示可靠性或吞吐量的应用功能的评估。

客户期望随着产品的总体性能而变化。IBM Rational建议客户使用适当的工具进行性能评估。IBM Rational在Test Studio Suite中提供了这样的一个工具，允许客户进行性能、功能和回归测试。

IBM Rational定期帮助客户使用这些工具创建这样的测试。

附录A

将ClearTeam Secure集成到数据采集设备：

为了将外部设备与ClearCase和/或ClearQuest正确集成以便进行生物特征识别捕获，应该用数据采集设备替换本文前面描述过的MD5加密解决方案。

此外，还需要修改外部认证工具，询问项目记录类型，以便为正在登出的项目标识使用中的生物特征识别机制。

最后，必须对ClearQuest签名类型做出适当的调整，以保证通过外部设备采集到的数据能正确存储。如果你打算使用外部采集到的数据进行认证，而不仅仅是授权正在进行的活动，那么就有其他的考虑。比如，如果你的设备使用专有方法验证个人签名（即手写压力的变化，以及钢笔笔画的维度和线性），那么你需要仔细计划你的实现。

为了确定这一切，你必须首先决定哪些供应商会提供生物特征识别数据采集工具。目前市场上存在几种类型方便数据采集的产品。按指纹、视网膜扫描、手写签名捕获以及捕获手掌大小是其中的一些例子。

确定你可以将鉴别人员所需的所有数据存储在ClearQuest签名记录类型中，或者可从所有ClearCase客户端访问认证数据和外部认证源。尽管这不是绝对需求，但却使利用ClearQuest钩子或ClearCase触发器自动完成并有计划控制工具行为的任务更加容易实现。

大部分生物特征识别解决方案供应商提供了基于API解决方案的ActiveX 和 COM，将它们的产品与现有应用集成。

统一的元素版本数据和元数据报告：

在试图保证ClearCase元数据与其相应的元素版本数据具有一致的报告的过程中，可能需要创建一个脚本。该脚本必须转储给定元素版本的内容，以及被请求版本的相关元数据。这在Windows平台或Unix上很容易作为两行脚本实现。

Windows上这样脚本的例子如下：

type %1 > dummy.txt
cleartool describe -l %1 >> dummy.txt

其中%1是一个脚本参数，包含要报告的纯文本文件的名称。

该脚本可直接从命令行执行。更优雅的实现是利用ClearCase Context Menu Editor向Windows Explorer或ClearCase Explorer中添加对该脚本的调用。该脚本然后通过对上下文菜单事件的右击被调用。

输出是选中元素版本的梭鱼文本，包括附在选中元素版本后面的所有元数据。

该脚本Unix版的例子如下所示：

Cat $1 > dummy.txt
Cleartool describe -l $1 >>dummy.txt

自然地，参数变量会根据实现的shell的不同而异。Unix环境中更有效的解决方案是创建一个可执行文件，该文件将元素的版本扩展名作为参数。

需要注意的很重要一点是，以专有格式存储的工件可能需要更多的脚本来适应向它们添加ClearCase元数据。这是因为当在给定元素的尾部添加或插入原始文本数据时，使用专有存储的工件可能不能正常工作。

然而，你很容易想到创建一个使用ClearCase类型管理器功能的脚本，这可能使得Word文档被打开并在后面附加上ClearCase元数据。

支持这样报告的功能将建立在具体情况具体分析的基础上。

参考文献

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。

1. Food and Drug Administration, Department of Health and Human Services (US) [FDA]. Code of Federal Regulations Title 21 - Part 11 Electronic Records; Electronic Signatures. Available From: United States Government Printing Office [GPO]. Complete set in Paper S/N: 869-044-00000-8. Complete set in Microfiche S/N: 869-043-00000-1

2. Food and Drug Administration, Department of Health and Human Services (US) [FDA]. Guidance for Industry 21 CFR Part 11; Electronic Signatures; Electronic Records. Draft Guidance August 2001 Available through: http://www.fda.gov/cber/gdlns/esigvalid.htm

3. FDA Compliance Policy Guide: 160.850 Enforcement Policy: 21 CFR 11; Electronic Records, Electronic Signatures (CGP 7153.17)

4. Good Practice and Compliance for Electronic Records and Signatures, Part 1 - Good Electronic Records Management (GERM) Version1. (ISPE/PDA, 2002)

5. Good Practice and Compliance for Electronic Records and Signatures, Part 2 - Complying with 21 CFR Part 11, Electronic Records and Electronic Signatures Version1. (ISPE/PDA, 2001)

6. General Principles of Software Validation; Final Guidance for Industry and FDA Staff (US Food and Drug Administration - Center for Devices and Radiological Health, January 2002)

7. Validation Key Practices for Computer Systems Used in Regulated Operations (Pharmaceutical Technology, June 1997 Vol.21 Number 6, Grigonis, Subak, Wyrick)

8. Technical Report No. 32 "Auditing of Suppliers Providing Computer Products and Services to Regulated Pharmaceutical Operations", PDA, October 1999, Release 1.0