Эволюционная модель ЖЦ

Спиральная модель

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

Рис.3. Спиральная модель ЖЦ разработки программных систем

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

Данная модель ЖЦ допускает анализ продута на витке разработки, его проверку, оценку его правильности и принятия решения двигаться на следующий виток или опуститься на нижний для доработки.

Отличие этой модели от каскадной модели состоит в возможности спиральной модели обеспечивать многоразовое возвращение к процессу формулирования требований и к повторной разработке с любого процесса выполнения работ.

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

В случае эволюционной модели система разрабатывается в виде последовательности блоков структур (конструкций). В отличие от инкрементной модели ЖЦ, подразумевается, что требования устанавливаются частично и уточняются в каждом последующем промежуточном блоке структуры системы (рис.2.4.).

Блок 1

R1 D C/T I/AS

Блок 2

R2 D C/T I/AS

Блок N

R3 D C/T

I/AS

Рис.4. Пример эволюционной модели

На данном рисунке модели используются следующие обозначения

– R (Requirements) требования,

– C/T (Coding/Testing) кодирование, тестирование,

– D (Design) проектирование,

– I/AS (Installation/acceptance) инсталляция, сопровождение.

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

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

При этом подходе учитываются такие факторы риска:

– реализация всех возможностей системы сразу;

– ограниченные ресурсы (людские, финансовые) заняты разработкой в течение длительного времени.

Преимущества применения данной модели ЖЦ состоит в следующем:

– проведение быстрой реализация некоторых возможностей системы;

– промежуточный продукт может использоваться на следующем процессе;

– в системе выделяются отдельные части для реализации их в отдельности;

– возможность увеличения финансирования системы;

– обратная связь устанавливается с заказчиком для уточнения требований;

– упрощение внесения изменений.

Модель развивается в направлении привлечения к разработке новых разработчиков и механизмов прототипирования для моделирования функциональности, нефункциональных требований (несанкционированного доступа, аутентификации и др.).