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

Основной недостаток всех предыдущих подходов – отсутствие достаточной гибкости.

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

Процессы

Стадии

Анализ Проектирование Программирование Тестирование Эксплуатация

и отладка и сопровождение

Рис. 1. Спиральная модель жизненного цикла ПО

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

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

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

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

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

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

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

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

Кубическая модель ЖЦ позволяет рассматривать разработку программы в 3 измерениях: этапы разработки, компоненты программной системы и содержание работ по разработке данного компонента на данном этапе. Модель предполагает, что каждый из компонентов программной системы разрабатывается по своему технологическому циклу. Разрешается выполнять любой из этапов разработки любого компонента, если для этого достаточно проектной информации и ресурсов. Проект системы формируется путем постепенного заполнения свободных мест («кубиков») кубической модели в порядке, определяемом проектировщиками по обстоятельствам. Управление разработкой по кубической модели сводится к планированию срока завершения всего проекта, определению структуры проекта по этапам и компонентам, расчету трудозатрат проекта по этапам каждого компонента, а также к контролю заполнения проекта решениями. Кубическая модель разработки предназначена, прежде всего, для использования в CASE – системах автоматизации разработки программных средств, являясь основой для построения базы данных проекта и контроля полноты проекта.