Стратегии конструирования программных средств

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

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

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

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

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

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

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

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

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

Рисунок 4.3 – Инкрементная модель

Примером современной реализации инкрементного подхода является экстремальное программирование ХР. Оно ориентировано на очень малые приращения функциональности.

Модель быстрой разработки приложений (Rapid Application Development) – второй пример применения инкрементной стратегии конструирования (рис. 4.4). RAD–модель обеспечивает экстремально короткий цикл разработки. RAD – высокоскоростная адаптация линейной последовательной модели, в которой быстрая разработка достигается за счет использования компонентно–ориентированного конструирования. Если требования полностью определены, а проектная область ограничена, RAD–процесс позволяет группе создать полностью функциональную систему за очень короткое время (60–90 дней). RAD–подход ориентирован на разработку информационных систем и выделяет следующие этапы:

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

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

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

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

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

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

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

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

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

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

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