Мифы и реалии компонентной автоматизации

Сегодня много говорится о перспективах компонентного подхода. Дескать, компании скоро навыпускают множество кубиков, и разработчикам останется только собирать из них готовые системы. Да и лоскутная автоматизация (сборка КИС из разных систем или их модулей) в России весьма популярна. В этой связи интересно мнение доктора Уильяма Трэкза, руководителя подразделения Lockheed Martin Federal Systems, входящего также в состав научной лаборатории ВВС США. Он считает, что в области компонентных технологий имеется немало мифов.

Миф 1. Важно, что компоненты дают вам.
Реалия. Важно, что компоненты могут вам сделать.
Когда число компонентов, приобретаемых у разных поставщиков, увеличивается, сложность взаимосвязей между ними стремительно растет, и возникает множество проблем с безопасностью, распределением нагрузки и обработкой ошибок.

Миф 2. Компонентные системы могут проектироваться сверху вниз.
Реалия. Компонентные системы строятся снизу вверх.
Современные методологии предусматривают обязательное определение требований к системе на самых ранних этапах проектирования, что требует итерационного подхода к разработке - быстрого создания прототипа и его совершенствования. Для этого приходится прибегать к анализу реальных возможностей и настройкам компонентов уже с самого начала проекта.

Миф 3. Открытая архитектура позволяет решить проблемы взаимодействия компонентов.
Реалия. Нет стандартного определения "открытой архитектуры" или "открытой системы", поэтому принцип "подключи и работай" выполняется далеко не всегда.
Хотя делаются попытки создать подобные стандарты, число подключаемых компонентов для них еще слишком мало.

Миф 4. Вам не надо тестировать покупаемые компоненты.
Реалия. Вам надо тестировать компоненты более жестко, чем собственное ПО, потому что вы не знаете, как эти компоненты создавались.
Компоненты нередко имеют ошибки как внутри кода, так и ошибки реализации внешних интерфейсов.

Миф 5. Компоненты можно отбирать после тщательного анализа.
Реалия. Компоненты выбираются на основе демо-роликов или рекламных статей.
Компонентный рынок слишком молод, и для него еще не выработаны эффективные способы оценки и отбора нужных продуктов.

Миф 6. Компоненты сопровождаются хорошей документацией.
Реалия. Многие возможности компонентов недокументированы.
Нередко неполная или ошибочная документация (что связано с молодостью рынка и стремлением поставщиков быстро выпустить новые продукты) может привести к серьезным сбоям в работе создаваемой системы.

Миф 7. Можно настраивать компонентные системы в соответствии с собственными нуждами.
Реалия. Требуется подстраивать процессы работы организации под возможности компонентов.
Правило 80/20 применимо к большинству компонентных систем - 20% возможностей компонента удовлетворяют 80% потребностей пользователя. Но при этом реализация оставшихся 20% стоит значительно дороже, чем при обычной разработке ПО, потому что влезть внутрь компонента и изменить его невозможно. Поэтому ведущие поставщики компонентов никогда не меняют их и выполняют в полном соответствии с требованиями. Соответственно, не выпускаются новые версии компонентов, а выпускаются новые наборы под другой торговой маркой, чтобы при попытке сделать обновления не возникали проблемы.

Миф 8. Использование компонентов - лучшая современная технология.
Реалия. Компонентная технология - во многом дань моде и результат побочной деятельности компании-разработчика.
Не бывает компонентов, в которых есть все, что вам надо. Обычно компоненты содержат множество настроек, менять которые придется самостоятельно.

Миф 9. Компонент покупается как обычный продукт.
Реалия. Покупается право на использование конкретной версии компонента. Частый выпуск новых версий компонентов приводит к сокращению срока их обслуживания и повышению расходов на обновление.

Миф 10. Компания-разработчик будет исправлять находимые в компонентах ошибки.
Реалия. Компания-разработчик исправит ошибки в следующей версии компонента. Это следствие из предыдущего пункта.

Миф 11. Крупный клиент может влиять на компанию-разработчика компонентов и даже обЪединиться с ней.
Реалия. На разработку компонентов влияет рынок.
Когда покупателей много, разработчик руководствуется собственными интересами получения прибыли.

Миф 12. Компонентный подход - это спасение.
Реалия. Компоненты негативно влияют на процесс создания ПО, ошибочно стимулируя высшее руководство сокращать запланированное время на разработку.

Миф 13. Компоненты после их покупки можно свободно использовать в разных проектах.
Реалия. Расходы на увеличение сложности проекта с активным использованием компонентов значительно превышают выгоду от покупки готовых компонентов.

Миф 14. Можно не покупать новые версии компонентов.
Реалия. В таком случае теряется сопровождение.

Миф 15. Можно заплатить разработчику, чтобы он модифицировал компоненты нужным образом.
Реалия. Придется заплатить третьей фирме, чтобы она модифицировала компоненты нужным образом.

И несколько правил по работе с компонентами.

Правило 1. Стоимость компонента - 1% от расходов на программирование аналогичных функций.

Правило 2. Максимальный рыночный срок жизни компонента - 2 года.

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

Правило 4. Оценивать компонент надо в реальном окружении, с учетом его реальных взаимосвязей с создаваемой системой.

Правило 5. Никогда не добиться 100%-ного компонентного решения из-за того, что внутренность компонентов закрыта от пользователя и не может им контролироваться.

Правило 6. Чем меньше число пользователей компонентов, тем выше его цена и лучше обслуживание.

Правило 7. Главный недостаток компонентного подхода - короткая жизнь компонентов.

Правило 8. Не используйте последние версии компонентов.

Правило 9. При использовании компонентов снижается время на разработку и увеличивается время на интеграцию модулей.

Правило 10. Процесс выбора компонента приводит либо к снижению, либо к увеличению риска неудачи проекта.

Правило 11. Компонентные системы никогда не удовлетворят нужды пользователей.

Пока компоненты подходят для использования в небольших проектах, при решении- хорошо известных популярных задач, когда можно применить небольшое число проверенных и неизменяемых компонентов и когда доказан механизм корректного взаимодействия компонентов.