модель не очень хороша для заказчиков или проектов, которые развиваются революционно.
С другой стороны, если продукт развивается эволюционно, модель во многом облегчает взаимодействие с заказчиком и отношения с ним, потому что основные модули, которые реализуют бизнес-логику приложения, будут меняться незначительно. К ним будет лишь добавляться некоторая функциональность (некоторые методы, если мы говорим на языке ООП). И в этой связи сопровождение продукта будет достаточно плавным, с небольшими затратами. В этом смысле рассматриваемый подход к разработке корпоративных информационных систем является достаточно хорошим для создания эволюционных продуктов. Естественно, обратная сторона медали – архитектурные решения. К сожалению, существуют программные архитектуры, которые не поддерживают такого рода масштабирование. Например, компонентная архитектура Microsoft с веб-сервисами достаточно хорошо поддерживает масштабирование, подключение новых элементов или расширение существующих. Существуют архитектуры, например файл-серверная, с масштабированием которых все гораздо сложнее. Поэтому уже на этапе выбора архитектуры, при первичном архитектурном проектировании, и отчасти при построении технических ограничений в проекте необходимо учитывать особенности той или иной модели. Вообще говоря, нужно выбрать модель жизненного цикла ПО и следовать этому выбору.
Еще нужно отметить как недостаток то обстоятельство, что ряд продуктов требует, к сожалению, сразу полнофункционального решения, причем это может быть связано во многом и с пожеланиями заказчика. Ряду заказчиков нужен сразу полнофункциональный интернет-магазин, который включает в себя и 3D-витрину, и возможность оплаты кредитной картой, и различные системы электронной оплаты. В некоторых случаях было бы полезно отслеживание доставки (оно реализовано, например, в таких службах, как DHL, это удобно и полезно). Но здесь все зависит от ТЗ и требований к продукту. Если продукт сразу требует полной функциональности, наверное, подойдет какая-то другая модель (может быть, каскадная), которая позволяет реализовать все за один проход. Конечно, и риски в этом случае будут выше, но о них речь пойдет далее, в связи со спиральной моделью, которая специфически их учитывает и призвана с ними бороться. Если же говорить об инкрементальной модели, то нужно отметить, что не для каждого продукта и корпоративной системы она годится.
Еще один недостаток: ПО должно предусматривать стабильный путь апгрейда (развития). То есть изменения, которые вносятся в каждый программный модуль при выпуске каждого релиза, не должны превышать паразитные, служебные изменения, которые очень сказываются на конфигурации. Они не должны существенным образом сказываться на производительности при создании очередного релиза программного продукта. Естественно, если путь развития ПО нестабильный, резкий, взрывной, эта модель опять-таки не подойдет: она не имеет
