COTS vs. Custom / Build vs. Buy: дерево решений и лучшие практики

Question

Справочная информация:

Я работаю в компании с большими инвестициями в SAP, и у нас также есть десятки крупных систем .NET (в основном для инженерных систем) и платформы Java (в основном для внешних веб-приложений). Таким образом, у нас есть большие магазины разработки на ABAP, C # и Java EE.

Вопрос:

Короче говоря, Нам нужен лучший способ определить, когда следует использовать программное обеспечение Commercial, Off The Shelf (COTS) и когда нам следует привлекать собственных разработчиков.

Критерий:

Я бы хотел построить дерево решений, основанное на лучших практиках, чтобы помочь с этим вопросом.

На высшем уровне соответствующий пост Джеффа Этвуда хорошо подводит итог: Лучший код - это вообще не код

Чуть глубже, я хотел бы видеть критерии вроде:

Доступна ли система COTS, отвечающая большинству требований? (Если да, система COTS может быть хорошим вариантом: (Избегайте повторного изобретения колеса))

• Если так, есть ли полностью открытый API имеется в наличии? (Это важно для интеграция / настройка)
• Если да, доступен ли исходный код? (Это важно для глубокого интеграция / настройка)

Разработана ли система для выполнения основной бизнес-функции / создания конкурентного преимущества? (Если это так, то разработка на заказ может быть хорошим вариантом: См. Статью Джоэла Споски: в защиту синдрома не изобретенного здесь )

• Если это так, позволит ли пользовательская разработка для повторного использования кода в будущем / другом системы? (Есть много преимуществ для повторного использования существующего кода)

Что такое совокупная стоимость владения для пользовательского приложения по сравнению с продуктом COTS?

Существуют ли временные ограничения, которые не могут быть выполнены при разработке на заказ? (Если да, система COTS может быть хорошим вариантом)

Answer 1

Я не совсем уверен, о чем вы просите, но я подумал, что прокомментирую несколько вещей, которые я видел, возникающих в COTS, по сравнению с выборочными вариантами разработки на протяжении многих лет:

1. Для надлежащего анализа любых систем COTS потребуется время. И с точки зрения требований, и с технической. Сколько нестандартного dev можно было сделать вместо анализа?

2. Остерегайтесь продаж COTS, обещайте луну на палочке. Их много. Яркие презентации от мужчин-да, которые предложат выполнить любое требование, чтобы получить сделку. Самая опасная ловушка, в которую можно попасть, - это обещанная функциональность, которой нет в COTS в настоящее время, но она добавит вам - чаще всего продавец говорит «да» вам, даже не выясняя, возможно ли для их продукта сделать это.

3. Проверьте для модульных тестов в COTS, а также какие методы разработки они используют. Хорошие показатели качества. Практика развития ковбоя, отсутствие тестов и документации - это проблемы с ремонтопригодностью в будущем.

4. Будьте осторожны, если поставщик COTS не дает много информации о технических аспектах своего продукта.

Если ваша желаемая система довольно проста, то ваш выбор COTS также будет довольно простым. Но если это большая и сложная система, вы, вероятно, предложите ее для запроса предложений (запроса предложений), и для этого вам понадобится тщательная и правильная спецификация требований. Будет ли время, затрачиваемое на разработку требований к RFP, влиять на нестандартное гибкое решение? Вам нужно будет очень жестко придерживаться этих требований, чтобы система COTS работала, а это потребует много времени и усилий.

Лично я никогда не рассмотрел бы COTS, если:

1. Исходный код доступен, и у меня есть программисты, оценивающие его
2. Я видел и попробовал рабочую демонстрацию, а не только блестящие рекламные материалы
3. Нет времени или персонала, чтобы сделать это на месте.

В конечном итоге, я согласен с утверждением Джоэла: если это основная бизнес-функция - делай это сам, несмотря ни на что.