在GAMP监管行业中应用开放源代码软件（OSS）的指导（二）

ISPE

客户-供应商关系
对比商业软件已知良好的客户-供应商关系，OSS提供了几种供应商交互的方法，典型的方法如下：


图1-典型的客户-供应商情形

情形a：客户下载、安装和使用OSS应用，应用并没有被用户或IT部门改变。在这种情形中，客户不是团队中的一部分。
情形b：应用由系统集成商或其他供应商支持和维护（也可能是定制化）。根据许可模型，集成商或供应商可能是团队中的一部分并编写代码。
情形c：像情形b一样，但是客户的IT部门作为集成方支持和维护应用，客户或客户的IT也可以修改代码。在这里，根据许可模型，客户甚至可以成为团队中的一部分。

这是三种典型的情形，在现实中 ，也可能存在不同的变化和组合。

从上述情形中的选择一种并制度化是非常重要的，由于他们牵扯到OSS客户的角色。例如，如果OSS软件减少缺陷和增加功能是非常重要的，可以建议针对该项目聘用外部的供应商（情形b）或安排内部的开发者（情形c）以保证问题的快速解决。进一步讲，如果OSS产品的修改给到第三方（例如，作为嵌合系统的一部分），根据OSS许可情况，甚至也可能需要调整团队。尽管第一眼看过去，投资潜在有益于其它公司的事情有些奇怪，但是接受来自于OSS团队的支持和产品改进还是值得这种付出的。
发布渠道

对于发布来说，OSS的开发者的以下几种渠道都是可以的。

最通常的情况包括：
直接网络下载。在某些情况中，OSS项目提供和管理他们自己的网络服务器（通常有来自公司赞助商的财务支持）。尽管许多项目依赖于网站提供通用的OSS项目服务，例如SourceForget或者Launchpad，但通过这种普通渠道发布的软件，通常也仅仅在源代码的论坛上可以获取。
操作系统发布。对操作系统的内核（例如Linux或BSD）和软件的公用及应用部分进行联合发布，可以提供一个可使用的、集成的系统。由于发布的开发者（OSS项目就是他们自己发布操作系统）通常使不同的部件在一起工作，发布者通常最熟悉安装开放代码的产品。并且，在大多数的情况中，发布者为通用的硬件结构提供预编译的、可运行的代码。例如Linux系统的发布者是Fedora、 SUSE企业和Ubuntu。
网站软件下载。专业提供软件（例如Tucows）下载的网站（通常是商业的），可以提供OSS产品不断增长的选择。
软件收集。软件收集，例如由计算机相关杂志发布的东西，通常也包含OSS。

这些发布渠道相关的主要风险是无意下载到可能被第三方恶意修改的OSS产品。可以通过使用“官方”的服务器或平台下载，使这些风险最小化，因为许多情况下这些下载由校验或数字签名来确认其真实性。

基于GAMP的OSS系统生命周期
不管是商业软件还是OSS，在GxP环境中都会运用同样的监管规则。
达到或维持GxP法规系统的合规性包含了OSS的部件与商业软件一样，能普遍地按照GAMP指南来完成 。对于OSS生命周期方法的不同和改进之处将在本章说明。在GAMP5中描述的总项目生命周期可以作为一个通用的框架。

表A-生命周期方法

表A列出了GAMP5的分类和OSS应用示例。在最右面的一列，给出了不同生命周期活动的一些建议。

概念阶段
概念阶段的目的是准备项目使之具备合适的资源。

项目/验证计划
项目计划定义了待开发的工作产品；生命周期使用的模型和方法；和项目管理相关的客户需求；需完成的任务；任务的所有权；项目资源；计划、里程碑和目标日期；预估值和质量标准。此外，计划识别的关键附属物；需求的工作产品；项目风险和风险转移计划；未完成任务的应急行动。

对于任何的验证项目，验证计划至少应该包括重要的背景信息、项目目标、责任人、需遵循的SOP描述、相关过程的标准和原则；以及用于结论的预先定义的接受准则。

需求/说明书
根据软件开发使用的生命周期，说明书可以用不同的方法实施。充分定义的需求说明书应该
是有效的。说明书应该用输入和结果描述由软件支持的过程。当然，详细的程度也取决于GAMP类别及涉及的风险、复杂性和新颖性。技术说明书，像功能说明书或设计说明书一样，应该和选择的生命周期模型一致。

项目阶段
承包商/供应商评估
由于OSS的特殊性和不同的客户-供应商关系，承包商和供应商评估可能是非常有挑战性 的任务，相比于商业软件有很大的不同。
对于低风险的应用，供应商的评估是不需要的。对于中等风险或高风险的应用，推荐采用情形b和情形c，因为一个服务组织-无论是内部或外部的-将减少不确定性以及团队的支持和维护风险。
对于情形b，供应商评估和商业软件是一样的。对于情形c，使用内部质量标准并且内部供应商需要按照情形a评估团队。评估的严格程度应与风险优先级一致。
如果一个团队被选择作为直接的资源（情形a），合适的质量标准用来衡量团队必须具有的稳定性和质量。GAMP5中提供了通用的OSS评估检查清单，并附上了材料（检查清单和问卷示例）。
OSS团队的持续性能够使用下列的通用标准评估，当进行供应商评估时应考虑选择4。标准的选择是取决于具体情况并应记录下来。

团队的活动
下载的数量
开发者的数量
发布的数量
邮件列表的活动和论坛
个人的档案资料
关键开发者/维护者的经验（对于OSS开发者的一个重要动因是获得团队的认可）
沟通
邮件列表
新团队
团队内的组织结构1，例如：
项目管理
核心团队定义
子项目的维护
组态管理
适用审核的过程定义和进入主分支的集成
明确从稳定放行产品中分类的流程
版本控制
系统和放行文档

额外的标准可以找到，例如FlossQuality14。

开发标准
开发标准对于OSS软件是主要的挑战，但是实际上许多团队有现成的标准。根据许可模型，下列标准对于重新使用代码和修改代码是必需的，这应该是供应商评估的准则。

可追溯性
在URS、功能说明、开发说明和测试之间的关系应该是可追溯的。例如如果你雇用团队的一部分来扩展或建立一个应用，你或团队被聘用的合同者必须提供按照GAMP5描述的方式提供追溯性。（未完待续）

文章来自 ISPE《制药工程》

小李飞刀

学习一下。

lyzqshsci

顶一下                     

PGY2016

感谢分享，谢谢！