当外包时，什么样的软件交付指南是合适的？

Question

我开始在一家非常小的公司工作，该公司经常(不经常)不得不外包一些软件开发。外部供货商比必须交付的东西。正如我现在所看到的，供应商交付的交付品的质量非常不同--有时只包括二进制可执行文件(没有源)、缺少的文档、没有接口描述、.

由于我现在不是软件专家，我仍然想对此进行基线，我正在寻找一些标准/通用的最佳实践，可以用于合同等，其中包含交付应该包含的内容：

• 可执行文件
• 源代码
• 工具链描述(如何构建代码的参考)
• 文档
• 接口描述
• 通用编码标准(可能不像MISAR XY那样具体)

。。对于这一点(在提到的几点上)，什么是最起码的--以及遗漏了什么。对于这种软件交付指南，有IEEE/RFC/ITF标准吗？

在我的上一家公司里，有一些专家致力于这一主题，他们一直在为每个合同/供应商创建这类文档(所需文档/交付品列表)。

Answer 1

我不知道有这样的标准。

最终，分包商应该交付他们合同交付的任何东西。如果你想要文件，它应该在合同中这样说。这同样适用于源代码、设计或其他任何东西。

因此，如果您对交付的内容不满意，请仔细查看您与他们签订的交付合同，并(作为一家公司)问自己，您的分包过程是否足够健壮。

除了一个二进制文件和一些发布说明之外，提供任何东西都不符合分包商的利益。如果他们给了你一切，那么你可以自己更新，而不是付钱给他们改进。

Answer 2

据我所知，目前还没有这方面的标准，尽管您肯定应该支持软件基线，以满足您公司的需求。

一个好主意是建立一个基本的项目结构，更好地组织项目以及如何使用它，比如：

project root 
  \_ source
       \_ build.sh / build.bat
  \_ bin
      \_ project executable
      \_ resources
  \_ doc

启动build.sh或build.bat时，应该在bin文件夹中生成project.exe，并相应地命名可执行文件。其他可执行文件也可以出现在需要的情况下。源文件夹可以以最方便的方式对开发团队进行组织。同样，bin文件夹可以以最方便的方式组织，以便于开发团队执行。

“资源”文件夹用于提供可执行文件工作所需的任何其他库或参考文件。

doc文件夹将用于提供基本用法和如何调用。附加的技术文档也可以添加，但是基本的调用使用必须存在(并且它必须反映当前版本的构建)。如果有一个接口要实现，那么应该有完整的文档，该接口和它将如何使用。为每个api接口提供一个这样的文档(以便于访问)。

您可以自由地对此进行一些更改，但是类似这样的内容将是一个很好的基础，对于开发人员来说也是灵活的。

对于您来说，我需要一些提示，我需要每次都提供源代码。如果您的公司正在为软件的制作付费，软件代码将允许您完全从头开始重新创建它，这是您要求它的权利。

另外，如果您不信任这个第三方，您还应该坚持最初不存在可执行文件，并且每次都构建可执行文件。这需要更长的时间，而且他们可能会认为这对您来说不太方便，但这是程序与正在构建的源代码相对应的保证。