Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ОПИ Лекция 2.docx
Скачиваний:
2
Добавлен:
21.11.2019
Размер:
212.52 Кб
Скачать

Преимущества реализации системы с помощью каскадной модели следующие:

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

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

Инкрементный модель жц

Эту модель (incremental) еще называют моделью с наращиванием или с приростом. Ее суть заключается в разработке продукта итерациями, и каждая итерация заканчивается выпуском трудоспособного версии. В каждой новой версии добавляются некоторые функциональные возможности. Разработка системы начинается с определения набора всех требований к ПС и деления процесса разработки на итерации. Каждая итерация реализуется последовательно с использованием процессов ЖЦ и фиксации рабочей версии системы, системы, которая постепенно приближается к окончательной версии

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

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

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

- Требования составлены с учетом возможности их изменения при реализации продукта;

- Все возможности системы требуется реализовать сразу;

- Быстрое изменение технологии и требований к системе может привести к нарушению полученной структуры системы;

- Ограничения в ресурсном обеспечении (исполнители, финансы) могут привести к несвоевременному вводу системы в эксплуатацию.

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

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

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

- Возможное увеличение финансирования на разработку

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

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

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

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

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

Для программного продукта такая модель не очень подходит по нескольким причинам. Во-первых, высказывания требований заказчиком носит субъективный характер, требования могут многократно уточняться в течение разработки ПС и даже после завершения и испытания, и иногда может выясниться, что заказчик «хотел совсем другое». Во-вторых, меняются обстоятельства и условия использования системы, поэтому общепризнанным законом программной инженерии является закон эволюции, который сформулируем так: каждое действующее ПС со временем требует внесения изменений или выводится из эксплуатации.

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