Инкрементная модель ЖЦ

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

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

Инкрементная модель ЖЦ - student2.ru

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

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

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

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

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

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

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

При применении данной модели необходимо учитывать следующие факторы риска:

– требования составлены непонятно для реализации;

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

– быстро меняются технологии и требования к системе;

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

Данную модель разработки целесообразно использовать, в случае когда:

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

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

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

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

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

. Инкрементная модель ЖЦ - student2.ru

Реализация

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

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

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

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

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

Наши рекомендации