6

背景：

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

问题：

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

标准：

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

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

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

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

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

该系统是否旨在满足核心业务功能/创造竞争优势？（如果是这样，定制开发可能是一个不错的选择：请参阅 Joel Sposky 的：为非此处发明综合症辩护）

  • 如果是这样，定制开发是否允许在未来/其他系统中重用代码？（重用现有代码有很多好处）

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

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

4

1 回答 1

2

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

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

  2. 当心 COTS 销售宣传的承诺月亮在棍子上。他们有很多。来自应援者的华而不实的演讲，他们将提供满足任何要求以达成交易。最危险的陷阱是被承诺的功能目前不在 COTS 中，但它们会为您添加 - 通常情况下，推销员对您说“是”，甚至没有发现他们的产品是否可以这样做它。

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

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

If your desired system is fairly simple then your COTS choice will also be fairly simple. But if it's a large, complex system you would presumably offer it out for RFP (request for proposal) and to do that you are going to have to have a thorough and correct requirements specification. Will the time taken to produce requirements for the RFP out weigh a custom dev agile solution? You are going to have to nail those requirements down super tight to make sure the COTS system delivers and that will take a lot of time and effort.

Personally, I would never consider COTS unless:

  1. The source code is available and I have had programmers assess it
  2. I've seen and tried a working demo and not just glitzy sales pitches
  3. There isn't time or personnel to do it in-house.

Ultimately, I agree with Joel's statement: If it's a core business function -- do it yourself, no matter what.

于 2009-03-18T20:42:31.497 回答