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