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

Question

背景：

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

问题：

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

标准：

我想根据最佳实践构建一个决策树来帮助解决这个问题。

在最高级别，Jeff Atwood 的相关帖子总结得很好：The Best Code is No Code At All

再深入一点，我希望看到如下标准：

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

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

系统是否旨在满足核心业务功能/创造竞争优势？ （如果是这样，定制开发可能是一个不错的选择：See Joel Sposky's: 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. 没有时间或人员在内部进行。

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