您打印的软件应该属于谁的代码？

工作画面与交付的产品不一样

想象一下，已经为您的公司开发了一个投标应用程序。员工登录、选择产品并收到 PDF。就日常使用而言，似乎工作已经完成。然而，当将更改价格表的开发人员离开时，尚不清楚另一个团队是否能够运行该应用程序。此时源代码问题就变得很重要。在项目开始时分别讨论使用屏幕、更改软件以及在不同位置运行它的可能性。不要将这些视为具有相同含义的提交；明确将为每个人提供哪个文件和哪个文档。

本文不决定合同的法律结果。权利范围根据协议、使用的组件和适用的法律进行评估。必要时请法律专家审查合同条款。技术上唯一可以做的就是将预期的交付成果转化为可理解的列表。哪一部分是专门为您开发的，哪一部分是作为现成的服务使用的，哪一部分是基于第三方库的？如果没有这种区别，假设所有代码都将以相同的条件交付可能会产生误导。

确定您需要的交付模式

在现成的订阅服务中，提供商可能不需要提供源代码。相反，会评估数据导出、服务结束时的访问以及集成的可能性。在您的特定应用中，可能会要求将焊接罐、安装说明和修改条件包含在供货范围内。两种型号都满足不同的要求。不要仅根据初始价格做出决定。如果应用程序正在运行公司的核心业务，那么能够继续与其他供应商合作的需求可能会更加明显。

要求的交付应与项目范围兼容。例如，当您获得为您编写的应用程序的屏幕时，您无法获得所使用的云服务的内部软件。但是，您可能希望它记录发送到该服务的数据以及如何建立连接。 不要假设未包含在要约中的交付稍后会自动发生，而是以书面形式澄清问题。

代码旁边应包含哪些信息？

将源文件放在文件夹中是一个好的开始；仅靠这一点还不足以实现可持续交付。代码的版本是什么，使用什么开发工具，依赖版本是如何修复的？应记录配置变量的名称、它们的实例值以及安全配置方法。实际密码或密钥不应放置在代码存储库中。新团队应该能够通过在单独的授权过程中获取机密来安装应用程序。在交付文件中明确写明生产环境的机密信息不利于交付；产生新的风险。

软件包中还应包含数据库结构、安装步骤、示例测试数据和备份恢复说明。保存计划任务、外部服务连接和文件存储位置。如果仅使用特定服务器上的字体生成报告，则必须了解此要求。还描述用户角色和管理员可以执行的操作。这些文件不必像一本长书一样描述申请的每一个细节；新团队必须提供有关如何安全操作系统的完整信息。

单独的依赖项和使用条款

应用程序可以使用提供商提供的开源库、付费组件或共享模块。他们的使用条款并不相同。维护组件名称、版本、许可证来源和续订要求的清单。如果开发者帐户中注册了付费组件，请提前询问如何在新团队中使用它。购买并不一定意味着在每个环境中无限制地转让或使用。从实际许可文件中查看相关情况；不要根据一般假设做出决定。

将代码存储库保存在企业帐户中可能会方便访问；仅拥有帐户并不能解释所有使用权利。开发者提供什么贡献以及存在什么限制应该在合同中看到。同样，数据所有权和迁移数据的能力应与代码分开处理。如果您在转移到新团队时无法导出客户记录，即使代码已交付，您也可能会遇到迁移问题。 系统间的数据传输 因此将其纳入交付计划中。

通过小型验收测试验证交付

在项目结束时，设置一个干净的测试环境，而不仅仅是计算文件数。使用交付文档运行应用程序，使用示例用户登录，并完成基本操作。然后恢复备份并导出示例数据。如果流程中需要的步骤未包含在文档中，请添加它。在不传播生产数据和修改实时系统的情况下执行测试。因此，正在交付的文件和可用的交付之间的差异是清晰可见的。

将存储库地址、交付版本、安装配方、依赖项清单、数据导出、维护者和分离步骤放在最终清单中。该列表将在发生更改时更新。目标不是在所有项目上使用相同的合同，而是定义将维持您的业务的交付。当一开始讨论的模型、报价和验收记录相互匹配时，供应商变更就成为一项更容易理解的技术任务。

常见问题

仅获取源代码就足够了吗？

不需要。还需要安装文档、依赖项、正确的使用条款以及在干净环境中运行的验证。

每个软件都需要代码交付吗？

现成的订阅服务和专门为您开发的软件的交付模式可能不同。在合同中明确定义模型和范围。

如何测试供应商切换？

纳入验收测试，让新的授权团队使用交付包设置测试环境并导出样本数据。