Быстрая разработка приложений

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

 

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

· однократный проход (водопадная стратегия) — линейная последовательность этапов конструирования;

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

· эволюционная стратегия. Система также строится в виде последовательности версий, но в начале процесса определены не все требования. Требования уточ­няются в результате разработки версий.

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

 

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

 

Стратегия	В начале процесса определены все требования?	Множество циклов конструирования?	Промежуточное ПO распространяется
Однократный проход	Да	Нет	Нет
Инкрементная (запланированное улучшение продукта)	Да	Да	Может быть
Эволюционная	Нет	Да	Да

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

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

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

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

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

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

 

Забегая вперед, отметим, что современная реализация инкрементного подхода — экстремальное программирование ХР (Кент Бек, 1999) [10]. Оно ориентировано на очень малые приращения функциональности.

Быстрая разработка приложений

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

 

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

· бизнес-моделирование. Моделируется информационный поток между бизнес-функциями. Ищется ответ на следующие вопросы: Какая информация руководит бизнес-процессом? Какая генерируется информация? Кто генерирует ее? Где информация применяется? Кто обрабатывает ее?

· моделирование данных. Информационный поток, определенный на этапе биз­нес-моделирования, отображается в набор объектов данных, которые требуют­ся для поддержки бизнеса. Идентифицируются характеристики (свойства, ат­рибуты) каждого объекта, определяются отношения между объектами;

· моделирование обработки. Определяются преобразования объектов данных, обеспечивающие реализацию бизнес-функций. Создаются описания обработ­ки для добавления, модификации, удаления или нахождения (исправления) объектов данных;

· генерация приложения. Предполагается использование методов, ориентиро­ванных на языки программирования 4-го поколения. Вместо создания ПО с помощью языков программирования 3-го поколения, RAD-процесс работает с повторно используемыми программными компонентами или создает повторно используемые компоненты. Для обеспечения конструирования используются утилиты автоматизации;

· тестирование и объединение. Поскольку применяются повторно используемые компоненты, многие программные элементы уже протестированы. Это уменьшает время тестирования (хотя все новые элементы должны быть протестированы).

 

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

Применение RAD имеет и свои недостатки, и ограничения.

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

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

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

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

 

Спиральная модель —- классический пример применения эволюционной страте­гии конструирования.

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

В спиральной модели ЖЦ (рис. 4.3), делается упор на начальные этапы ЖЦ: анализ и проектирование. Реализуемость технических решений проверяется путем создания прототипов.

Рис.4.3. Спиральная модель ЖЦ

 

Каждый виток спирали соответствует созданию нового фрагмента или версии ИС, на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Один виток спирали при этом представляет собой законченный проектный цикл по типу каскадной схемы. Такой подход назывался также «Продолжающимся проектированием». Позднее в проектный цикл дополнительно стали включать стадии разработки и опробования прототипа системы. Это назвали: "быстрое прототипирование", rapid prototyping approach или "fast-track".

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

 

 

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

 

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

1. Планирование — определение целей, вариантов и ограничений.

2. Анализ риска — анализ вариантов ираспознавание/выбор риска.

3. Конструирование — разработка продукта следующего уровня.

4. Оценивание — оценка заказчиком текущих результатов конструирования. Интегрирующий аспект спиральной модели очевиден при учете радиального из­мерения спирали. С каждой итерацией по спирали (продвижением от центра к периферии) строятся все более полные версии ПО.

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

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

1) наиболее реально (в виде эволюции) отображает разработку программного обес­печения;

2) позволяет явно учитывать риск на каждом витке эволюции разработки;

3) включает шаг системного подхода в итерационную структуру разработки;

4) использует моделирование для уменьшения риска и совершенствования про­граммного изделия.

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

1) новизна (отсутствует достаточная статистика эффективности модели);

2) повышенные требования к заказчику;

3) трудности контроля и управления временем разработки.