поколения, RAD-процесс работает с повторно используемыми программными компонентами или создает повторно используемые компоненты. Для обеспечения конструирования используются утилиты автоматизации;
-тестирование и объединение. Поскольку применяются повторно используемые компоненты, многие программные элементы уже протестированы. Это уменьшает время тестирования (хотя все новые элементы должны быть протестированы).
Применение RAD возможно в том случае, когда каждая главная функция может быть завершена за 3 месяца. Каждая главная функция адресуется отдельной группе разработчиков, а затем интегрируется в целую систему.
Применение RAD имеет и недостатки, и ограничения:
-для больших проектов в RAD требуются существенные людские ресурсы (необходимо создать достаточное количество групп);
-RAD применима только для таких приложений, которые могут декомпозироваться на отдельные модули и в которых производительность не является критической величиной;
-RAD не применима в условиях высоких технических рисков (т. е. при использовании новой технологии).
2.5Спиральная модель
Спиральная модель – классический пример применения эволюционной стратегии конструирования.
Спиральная модель (автор Барри Боэм, 1988) базируется на лучших свойствах классического жизненного цикла и макетирования, к которым добавляется новый элемент – анализ риска, отсутствующий в этих парадигмах.
31
Модель определяет четыре действия, представляемые четырьмя квадрантами спирали (рис. 5).
1.Планирование – определение целей, вариантов и ограничений.
2.Анализ риска – анализ вариантов и распознавание/выбор риска.
3.Конструирование – разработка продукта следующего уровня.
4.Оценивание – оценка заказчиком текущих результатов конструирования.
Интегрирующий аспект спиральной модели очевиден при учете
радиального измерения спирали. С каждой итерацией по спирали (продвижением от центра к периферии) строятся все более полные версии ПО.
В первом витке спирали определяются начальные цели, варианты и ограничения, распознается и анализируется риск. Если анализ риска показывает неопределенность требований, на помощь разработчику и заказчику приходит макетирование.
Планирование |
|
Анализ риска |
|
2 |
|
3 |
|
|
|
||
1 |
|
4 |
|
|
|
Линия принятия решения |
|
|
|
5 |
|
|
|
8 |
|
9 |
|
7 |
|
Оценивание |
6 |
Конструирование |
|
заказчиком |
|||
|
|
Рис. 5. Спиральная модель:
1 – начальный сбор требований и планирование проекта; 2 – та же работа, но на основе рекомендаций заказчика; 3 – анализ риска на основе начальных требований; 4 – анализ риска на основе реакции заказчика; 5 – переход
к комплексной системе; 6 – начальный макет системы; 7 – следующий уровень макета; 8 – сконструированная система; 9 – оценивание заказчиком
32
Для дальнейшего определения проблемных и уточненных требований может быть использовано моделирование. Заказчик оценивает инженерную (конструкторскую) работу и вносит предложения по модификации (квадрант оценки заказчиком). Следующая фаза планирования и анализа риска базируется на предложениях заказчика. В каждом цикле по спирали результаты анализа риска формируются в виде «продолжать, не продолжать». Если риск слишком велик, проект может быть остановлен.
В большинстве случаев движение по спирали продолжается, с каждым шагом продвигая разработчиков к более общей модели системы. В каждом цикле по спирали требуется конструирование (нижний правый квадрант), которое может быть реализовано классическим жизненным циклом или макетированием. Заметим, что количество действий по разработке (происходящих в правом нижнем квадранте) возрастает по мере продвижения от центра спирали.
Достоинства спиральной модели:
1)наиболее реально (в виде эволюции) отображает разработку программного обеспечения;
2)позволяет явно учитывать риск на каждом витке эволюции разработки;
3)включает шаг системного подхода в итерационную структуру разработки;
4)использует моделирование для уменьшения риска и совершенствования программного изделия.
Недостатки спиральной модели:
1)новизна (отсутствует достаточная статистика эффективности модели);
2)повышенные требования к заказчику;
3)трудности контроля и управления временем разработки.
33
2.6 Компонентно-ориентированная модель
Компонентно-ориентированная модель является развитием спиральной модели и тоже основывается на эволюционной стратегии конструирования.
В этой модели конкретизируется содержание квадранта конструирования – оно отражает тот факт, что в современных условиях новая разработка должна основываться на повторном использовании существующих программных компонентов.
Рис. 6. Компонентно-ориентированная модель
Программные компоненты, созданные в реализованных программных проектах, хранятся в библиотеке. В новом программном
34