Стратегии конструирования ПО

Существуют 3 стратегии конструирования ПО.

• водопадная стратегия (однократный проход) — линейная последовательность этапов конструирования;
• инкрементная стратегия. В начале процесса определяются все пользовательс­кие и системные требования, оставшаяся часть конструирования выполняется в виде последовательности версий. Первая версия реализует часть запланиро­ванных возможностей, следующая версия реализует дополнительные возмож­ности и т. д., пока не будет получена полная система;
• эволюционная стратегия. Система также строится в виде последовательности версий, но в начале процесса определены не все требования. Требования уточ­няются в результате разработки версий.

Характеристики стратегий конструирования программного обеспечения в соответствии с требованиями стандарта IEEE/EIA 12207.2 приведены в табл. 1.

Таблица 1 - Характеристики стратегий конструирования

Модели конструирования

Инкрементная модель

Инкрементная модель является классическим примером инкрементной стратегии конструирования (рис.4). Она объединяет элементы последовательной водопад­ной модели с итерационной философией макетирования.

Поставка

1-й инкремент 1-го инкремента

Поставка

2-й инкремент 2-го инкремента

Поставка

3-й инкремент 3-го инкремента

Рис.4. Инкрементная модель

Каждая линейная последовательность здесь вырабатывает поставляемый инкре­мент ПО. Например, ПО для обработки слов в 1-м инкременте реализует функции базовой обработки файлов, функции редактирования и документирования; во 2-м ин­кременте — более сложные возможности редактирования и документирования; в 3-м инкременте — проверку орфографии и грамматики; в 4-м инкременте — воз­можности компоновки страницы. Первый инкремент приводит к получению базового продукта, реализующего ба­зовые требования (правда, многие вспомогательные требования остаются нереа­лизованными). План следующего инкремента предусматривает модификацию базового продукта, обеспечивающую дополнительные характеристики и функциональность

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

3.2 Модель RAD - Быстрая разработка приложений

Модель быстрой разработки приложении (Rapid Application Development) — вто­рой пример применения инкрементной стратегии конструирования (рис. 5).

2-я группа

1-я группа

60-90 дней

Рис.5. Модель быстрой разработки приложений

RAD-модель обеспечивает экстремально короткий цикл разработки. RAD — вы­сокоскоростная адаптация линейной последовательной модели, в которой быст­рая разработка достигается за счет использования компонентно-ориентированно­го конструирования. Если требования полностью определены, а проектная область ограничена, RAD-процесс позволяет группе создать полностью функциональную систему за очень короткое время (60-90 дней). RAD- подход ориентирован на разработку информационных систем и выделяет следующие этапы:

• бизнес-моделирование. Моделируется информационный поток между бизнес - функциями. Ищется ответ на следующие вопросы: Какая информация руководит бизнес процессом? Какая генерируется информация? Кто генерирует ее? Где информация применяется? Кто обрабатывает ее?
• моделирование данных. Информационный поток, определенный на этапе бизнес моделирования, отображается в набор объектов данных, которые требуются для поддержки бизнеса. Идентифицируются характеристики (свойства, атрибуты) каждого объекта, определяются отношения между объектами;
• моделирование обработки. Определяются преобразования объектов данных, обеспечивающие реализацию бизнес функций. Создаются описания обработки для добавления, модификации, удаления или нахождения (исправления) объектов данных;
• генерация приложения. Предполагается использование методов, ориентированных на языки программирования 4-го поколения. Вместо создания ПО с помощью языков программирования 3-го поколения, RAD-процесс работает с повторно используемыми программными компонентами или создает повторно-используемые компоненты. Для обеспечения конструирования используются утилиты автоматизации;
• тестирование и объединение. Поскольку применяются повторно используемые компоненты, многие программные элементы уже протестированы. Это уменьшает время тестирования (хотя все новые элементы должны быть протестированы).

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

1. Для больших проектов в RAD требуются существенные людские ресурсы (необходимо создать достаточное количество групп).

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

3. RAD не применима в условиях высоких технических рисков (то есть при использовании новой технологии).

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

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

Как показано на рис.6, модель определяет четыре действия, представляемые четырьмя квадрантами спирали.

1. Планирование – определение целей, вариантов и ограничений.
2. Анализ риска – анализ вариантов и распознавание/выбор риска.
3. Конструирование — разработка продукта следующего уровня.
4. Оценивание — оценка заказчиком текущих результатов конструирования.

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

Рис. 6. Спиральная модель:

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

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

Достоинства спиральной модели:

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

Недостатки спиральной модели: