Процессы

Каскадно-вовратная модель

"Классическая" каскадная модель предполагает только движение вперед по схеме: все необходимое для проведения очередного этапа должно быть подготовлено в ходе предшествующих работ.

Поэтому при реальной работе в соответствии с моделью, допускающей движение только в одну сторону, обычно возникают проблемы при обнаружении недоработок и ошибок, сделанных на ранних этапах. Но еще более тяжело иметь дело с изменениями окружения, в котором разрабатывается ПО (это могут быть изменения требований, смена подрядчиков, изменения политик разрабатывающей или эксплуатирующей организации, изменения отраслевых стандартов, появление конкурирующих продуктов и пр.).

В процессе создания ПО постоянно возникает потребность в возврате к предыдущим этапам и уточнения или пересмотре ранее принятых решений.

В целом необходимость возвратов на предыдущие стадии обусловлена следующими причинами:

• неточные спецификации, уточнение которых в процессе разработки может привести к необходимости пересмотра уже принятых решений;

• изменение требований заказчика непосредственно в процессе разработки;

• быстрое моральное устаревание используемых технических и программных средств;

• отсутствие удовлетворительных средств описания разработки на стадиях постановки задачи, анализа и проектирования.

Отказ от уточнения (изменения) спецификаций приведет к тому, что законченный продукт не будет удовлетворять потребности пользователей. При отказе от учета смены оборудования и программной среды пользователь получит морально устаревший продукт. А отказ от пересмотра неудачных проектных решений приводит к ухудшению структуры программного продукта и, соответственно, усложнит, растянет по времени и удорожит процесс его создания. Реальный процесс разработки, таким образом, носит итерационный характер.

В результате реальный процесс создания ПО принимал вид каскадно-возвратного подхода:

Стадии

АнализПроектирование РеализацияТестирование Сопрововождение

и отладка эксплуатация

Здесь разрешены возвраты к предыдущим стадиям и пересмотр или уточнение ранее принятых решений.

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

Недостаток этого подхода:

- существенные задержки с готовностью ПО из-за корректировок при возвратах.

- требования к создаваемой системе "заморожены" в виде технического задания на все время ее создания.

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