Спиральная модель ЖЦ ПО
Спиральная модель – классический пример применения эволюционной стратегии конструирования. Модель (автор Б. Боэм, 1988) базируется на лучших свойствах классического жизненного цикла и макетирования, к которым добавляется новый элемент – анализ риска, отсутствующий в этих парадигмах. Модель определяет четыре действия, представляемые четырьмя квадрантами спирали (рис.5.10).
Рис. 5.10. Спиральная модель жизненного цикла программного обеспечения
1. Планирование – определение целей, вариантов и ограничений.
2. Анализ риска – анализ вариантов и распознавание/выбор риска.
3. Конструирование – разработка продукта следующего уровня.
4. Оценивание – оценка заказчиком текущих результатов конструирования.
Интегрирующий аспект спиральной модели очевиден при учете радиального измерения спирали. С каждой итерацией по спирали строятся все более полные версии ПС. В первом витке спирали определяются начальные цели, варианты и ограничения, распознается и анализируется риск. Если анализ риска показывает неопределенность требований, на помощь разработчику и заказчику приходит макетирование, используемое в квадранте конструирования.
Для дальнейшего определения проблемных и уточненных требований может быть использовано моделирование. Заказчик оценивает инженерную (конструкторскую) работу и вносит предложения по модификации (квадрант оценки заказчиком). Следующая фаза планирования и анализа риска базируется на предложениях заказчика. В каждом цикле по спирали результаты анализа риска формируются в виде "продолжать, не продолжать". Если риск слишком велик, проект может быть остановлен.
В большинстве случаев движение по спирали продолжается, с каждым шагом продвигая разработчиков к более общей модели системы. В каждом цикле по спирали требуется конструирование (нижний правый квадрант), которое может быть реализовано классическим жизненным циклом или макетированием. Заметим, что количество действий по разработке (происходящих в правом нижнем квадранте) возрастает по мере продвижения от центра спирали.
Основные виды деятельности при разработке ПО
Эти действия пронумерованы на рис.5.10 и имеют следующее содержание:
1. – начальный сбор требований и планирование проекта;
2. – та же работа, но на основе рекомендаций заказчика;
3. – анализ риска на основе начальных требований;
4. – анализ риска на основе реакции заказчика;
5. – переход к комплексной системе;
6. – начальный макет системы;
7. – следующий уровень макета;
8. – сконструированная система;
9. – оценивание заказчиком.
Достоинства спиральной модели:
1. наиболее реально (в виде эволюции) отображает разработку программного обеспечения;
2. позволяет явно учитывать риск на каждом витке эволюции разработки;
3. включает шаг системного подхода в итерационную структуру разработки;
4. использует моделирование для уменьшения риска и совершенствования программного изделия.
Недостатки спиральной модели:
· сравнительная новизна (отсутствует достаточная статистика эффективности модели);
· повышенные требования к заказчику;
· трудности контроля и управления временем разработки.
Модель спирального процесса разработки является наиболее распространенной в настоящее время. Самыми известными ее вариантами являются RUP (RationalUnifiedProcess) от фирмы Rational и MSF (MicrosoftSolutionFramework). В качестве языка моделирования используется язык UML (UnifiedModelingLanguage). Создание системы предполагается проводить итерационно, двигаясь по спирали и, проходя через одни и те же стадии, на каждом витке уточнять характеристики будущего продукта. Казалось бы, теперь все хорошо: и планируется только то, что можно предвидеть, разрабатывается то, что запланировано, и пользователи начинают знакомиться с продуктом заранее, имея возможность внести необходимые коррективы.
Однако для этого нужны очень большие средства. Действительно, если раньше можно было создавать и распускать группы специалистов по мере необходимости, то теперь все они должны постоянно участвовать в проекте: архитекторы, программисты, тестировщики, инструкторы и т. д. Более того, усилия различных групп должны быть синхронизированы, чтобы своевременно отражать проектные решения и вносить необходимые изменения.
Каскадная и итерационная модели жизненного цикла.