Спиральная модель жизненного цикла программных средств

Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ, общая схема которой приведена на рисунке 4.5а). Разработка ПО осуществляется поэтапно (определение требований, анализ, проектирование, реализация и тестирование, интеграция) в виде итераций, делая упор на начальных этапах ЖЦ: анализ и проектирование. На этих этапах реализуемость технических решений проверяется путем создания прототипов. Каждый виток спирали соответствует созданию фрагмента или версии ПС, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом, углубляются и последовательно конкретизируются детали проекта, и в результате выбирается обоснованный вариант, который доводится до реализации.

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

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

а)

б)

Рисунок 4.5 – Cпиральная модель жизненного цикла а) общая схема спиральной модели жизненного цикла; б) модифицированная спиральная модель: 1 – начальный сбор требований и планирование проекта; 2 – та же работа, но на основе рекомендаций заказчика; 3 – анализ риска на основе начальных требований; 4 – анализ риска на основе реакции заказчика; 5 – переход к комплексной системе; 6 – начальный макет системы; 7 – следующий уровень макета; 8 – сконструированная система; 9 – оценивание заказчиком

На 4.5б) приведена модифицированная спиральная модель, предложенная Барри Боэм, базирующаяся на лучших свойствах классического жизненного цикла и макетирования, к которым добавляется новый элемент – анализ риска, отсутствующий в этих парадигмах. Как показано на 4.5б), модель определяет четыре действия, представляемые четырьмя квадрантами спирали: планирование – определение целей, вариантов и ограничений; анализ риска – анализ вариантов и распознавание/выбор риска; конструирование – разработка продукта следующего уровня; оценивание – оценка заказчиком текущих результатов конструирования.

Интегрирующий аспект спиральной модели (рис.4.5б)) очевиден при учете радиального измерения спирали. С каждой итерацией по спирали (продвижением от центра к периферии) строятся все более полные версии ПО. В первом витке спирали определяются начальные цели, варианты и ограничения, распознается и анализируется риск. Если анализ риска показывает неопределенность требований, на помощь разработчику и заказчику приходит макетирование (используемое в квадранте конструирования). Для дальнейшего определения проблемных и уточненных требований может быть использовано моделирование. Заказчик оценивает инженерную (конструкторскую) работу и вносит предложения по модификации (квадрант оценки заказчиком). Следующая фаза планирования и анализа риска базируется на предложениях заказчика. В каждом цикле по спирали результаты анализа риска формируются в виде «продолжать, не продолжать». Если риск велик, проект может быть остановлен.

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

Достоинства спиральной модели: наиболее реально (в виде эволюции) отображает разработку программного обеспечения; позволяет явно учитывать риск на каждом витке эволюции разработки; включает шаг системного подхода в итерационную структуру разработки; использует моделирование для уменьшения риска и совершенствования программного изделия.

Недостатки спиральной модели: новизна (отсутствует достаточная статистика эффективности модели); повышенные требования к заказчику; трудности контроля и управления временем разработки.

4.5 Компонентно–ориентированная модель

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

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

Достоинства компонентно–ориентированной модели: уменьшает на 30% время разработки программного продукта; уменьшает стоимость программной разработки до 70%; увеличивает в полтора раза производительность разработки.

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