Лекция 6. 25.02.13.

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

В модели имеются 4 квадранта.

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

2. Оценка альтернатив, выделение рисков и способов разрешения рисков. Менеджмент рисков, в ходе которого принимается решение о продолжение работ над проектом.

3. Разработка и верификация очередной части продукта. Включает в себя работы собственно связанные с созданием проекта: разработка кода, тестирование, компоновка продукта, анализ.

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

В квадранте отсутствуют заданное кол-во итераций (циклов) их адаптируют под конкретный проект.

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

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

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

V-образная модель.

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

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

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

Применяются для небольших проектов где можно возможно определить требования и разработать архитектуру на ранних стадиях.

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

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