COTS 与定制/构建与购买：决策树和最佳实践

Question

背景：

我在一家拥有大量 SAP 投资的公司工作，我们还有数十个大型 .NET 系统（主要用于内部工程系统）和 Java 平台（主要用于外部 Web 应用程序）。 因此，我们在 ABAP、C# 和 Java EE 上拥有大型开发中心。

问题：

简而言之，我们需要一种更好的方法来确定何时应使用商业现成 (COTS) 软件，以及何时应利用我们自己的开发人员。

标准：

我想构建基于最佳实践的决策树可以帮助解决这个问题。

在最高层，Jeff Atwood 的相关帖子总结得很好： 最好的代码就是没有代码更

深入一点，我希望看到这样的标准：

是否有可以满足大多数要求的 COTS 系统？ （如果是，COTS系统可能是一个不错的选择：（避免重新发明轮子））

• 如果是，是否有完全公开的API 可用的？ （这对于 集成/定制）
• 如果是这样，源代码是否可用？ （这对于深入 集成/定制）

系统的设计是为了满足核心业务功能/创造竞争优势吗？ （如果是这样，定制开发可能是一个不错的选择：参见 Joel Sposky 的：In Defense of Not-Invented -Here Syndrome）

• 如果是这样，定制开发是否允许 用于将来代码重用/其他 系统？ （有很多优点 重用现有代码）

定制应用程序与 COTS 产品的 TCO 是多少？

是否存在定制开发无法满足的时间限制？ （如果是，COTS 系统可能是一个不错的选择）

Answer 1

我不完全确定您的要求是什么，但我想我应该对多年来我在 COTS 与定制开发选择中看到的一些事情发表评论：

1. 这需要时间正确分析任何 COTS 系统的适用性。 无论是从需求角度还是技术角度。 有多少定制开发可以代替分析？

2. 当心 COTS 销售宣传中的“棒上月球”承诺。 有很多。 唯唯诺诺的人会做出华而不实的演讲，他们会提出满足任何要求以达成交易。 最危险的陷阱是承诺目前 COTS 中没有的功能，但他们会为您添加 - 通常情况下，销售人员已经对您说“是”，甚至没有弄清楚他们的产品是否可以做到这一点

3. 检查 COTS 中的单元测试以及它们使用的开发实践。 良好的质量指标。 牛仔开发实践中，缺乏测试和文档是未来可维护性的难题。

4. 如果 COTS 供应商没有提供太多有关其产品技术方面的信息，请务必小心。

如果您想要的系统相当简单，那么您的 COTS 选择也将相当简单。 但如果它是一个大型、复杂的系统，您可能会将其提供给 RFP（征求建议书），为此您必须拥有全面且正确的需求规范。 生成 RFP 需求所需的时间是否会比定制开发敏捷解决方案更重要？ 您必须非常严格地确定这些要求，以确保 COTS 系统能够交付，这将需要大量的时间和精力。

就我个人而言，我永远不会考虑 COTS，除非：

1. 源代码可用，并且我已经让程序员对其进行了评估
2. 我已经看过并尝试了一个工作演示，而不仅仅是炫目的销售宣传
3. 没有时间或人员在内部进行此操作。

最终，我同意乔尔的说法：如果它是核心业务功能——无论如何，都要自己做。