1.2.3. Эволюционная стратегия конструирования
К этой стратегии относится спиральная модель, предложенная Барри Боэмом (Barry Boehm) в 1988 году, она стала существенным прорывом в понимании природы разработки ПО. Она представляет собой процесс разработки программного обеспечения, сочетающий в себе как проектирование, так и постадийное прототипирование с целью сочетания преимуществ восходящей и нисходящей концепции, делающая упор на начальные этапы жизненного цикла: анализ и проектирование.
Система также строится в виде последовательности версий, но в начале процесса определены не все требования. Требования уточняются в результате разработки версий.
Отличительной особенностью этой модели является специальное внимание рискам, влияющим на организацию жизненного цикла. Боэм формулирует десять наиболее распространённых (по приоритетам) рисков:
-
дефицит специалистов;
-
нереалистичные сроки и бюджет;
-
реализация несоответствующей функциональности;
-
разработка неправильного пользовательского интерфейса;
-
«Золотая сервировка», перфекционизм, ненужная оптимизация и оттачивание деталей;
-
непрекращающийся поток изменений;
-
нехватка информации о внешних компонентах, определяющих окружение системы или вовлечённых в интеграцию;
-
недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами;
-
недостаточная производительность получаемой системы;
-
«разрыв» в квалификации специалистов разных областей знаний.
Большая часть этих рисков связана с организационными и процессными аспектами взаимодействия специалистов в проектной команде.
Линия принятия решения (продолжать или нет)
Рис. 1.5. Спиральная модель: 1 – начальный сбор требований и планирование проекта; 2 – та же работа, но на основе рекомендаций заказчика; 3 – анализ риска на основе начальных требований; 4 – анализ риска на основе реакции заказчика; 5 – переход к комплексной системе; 6 – начальный макет системы; 7 – следующий уровень макета; 8 – сконструированная система; 9 – оценивание заказчиком
Каждый виток спирали соответствует созданию фрагмента или версии программного обеспечения, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который доводится до реализации. Каждый виток разбит на 4 сектора:
-
оценка и разрешение рисков,
-
определение целей,
-
разработка и тестирование,
-
планирование.
На каждом витке спирали могут применяться разные модели процесса разработки ПО. В конечном итоге на выходе получается готовый продукт. Модель сочетает в себе возможности модели прототипирования и водопадной модели. Разработка итерациями отражает объективно существующий спиральный цикл создания системы. Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем.
На рис.1.6 представлена усовершенствованная стратегия спиральной модели разработки программного обеспечения
Рис. 1.6. Спиральная модель разработки программного обеспечения
При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная задача — как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Основная проблема спирального цикла — определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная задача — как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований. Основная проблема спирального цикла — определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов жизненного цикла. Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.
Достоинства спиральной модели:
1. Наиболее реально (в виде эволюции) отображает разработку программного обеспечения;
2. Позволяет явно учитывать риск на каждом витке эволюции разработки;
3. Включает шаг системного подхода в итерационную структуру разработки;
4. Использует моделирование для уменьшения риска и совершенствования программного изделия.
Недостатки спиральной модели:
1. Повышенные требования к заказчику;
2. Трудности контроля и управления временем разработки.
Спиральная стратегия разработки программного обеспечения близка к инкрементной стратегии, однако имеются и различия.
Модель быстрой разработки приложений (RAD модель). Одним из возможных подходов к разработке программного обеспечения в рамках спиральной модели жизненного цикла является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки программного обеспечения, содержащий 3 элемента:
-
небольшую команду программистов (от 2 до 10 человек);
-
короткий, но тщательно проработанный производственный график (от 2 до 6 месяцев);
-
повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком.
Жизненный цикл программного обеспечения по методологии RAD состоит из четырёх фаз:
-
фаза определения требований и анализа;
-
фаза проектирования;
-
фаза реализации;
-
фаза внедрения
Применение RAD имеет и свои недостатки, и ограничения: для больших проектов в RAD требуются существенные людские ресурсы (необходимо создать достаточное количество групп);
RAD применима только для таких приложений, которые могут декомпозироваться на отдельные модули и в которых производительность не является критической величиной;
RAD неприменима в условиях высоких технических рисков (т.е. при использовании новой технологии)
- Университет им. М.Акмуллы
- Учебное пособие
- Введение
- Глава 1. Элементы программной инженерии
- 1.1. Стандарты, стадии и этапы разработок
- 1. Предпроектная стадия - так называемая стадия формирования требований к автоматизированной системе.
- 2. Стадия проектирования
- 3. Стадия внедрения.
- 4. Период сопровождения или пользовательский период.
- 1.2. Стратегии разработки программного продукта
- 1.2.1. Водопадная или каскадная стратегия конструирования
- 1.2.2. Инкрементная стратегия конструирования
- 1.2.3. Эволюционная стратегия конструирования
- 1.3. Примеры оформления технических заданий
- 1.3.1. Техническое задание на создание асутп
- 1.3.2. Техническое задание на разработку компьютерной модели
- 1.4. Инструментальные средства проектирования
- Глава 2. Основные подходы к разработке программ для компьютерного моделирования
- 2.1. Принципы разработки программного продукта
- 2.2. Направления и походы к разработке компьютерных
- 2.2.1. Разработка интерактивных компьютерных моделей для
- 2.2.2. Подходы и инструментарии разработки
- 2.2.3. Разработка сетевых компьютерных систем и
- 2.2.4. Разработка компьютерных вычислительных
- 1. Назначение еспд
- 2. Область распространения и состав еспд
- 3. Классификация и обозначение стандартов еспд
- Информационная технология
- Гост 34.602-89
- Государственный стандарт союза сср
- 1. Общие положения
- 2. Состав и содержание
- 3. Правила оформления
- Порядок разработки, согласования и утверждения тз на ас
- Форма титульного листа тз на ас
- Техническое задание
- Форма последнего листа тз на ас
- Информационные данные
- 2. Утвержден и введен в действие Постановлением Государственного комитета ссср по стандартам от 24.03.89 № 661
- 3. Взамен гост 24.201-85
- 4. Ссылочные нормативно-технические документы