1.2. Функциональные требования

Автоматизированная система «Решатель математических формул» должна обеспечивать выполнение функций:

• Решение логарифмов

• Требования к надежности:

• Безотказная работа

• Проверка вводимых данных

Требования к составу и параметрам технических средств должны быть следующими: x86 или 64x совместимый процессор с тактовой частотой ~600MHz, объем оперативной памяти 64мб, объем свободного дискового пространства 3мб.

Требования к информационной и программной совместимости

Программа должна работать в операционной системе WindowsXP или более новой редакции.

1.3. Выбор модели жизненного цикла

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

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

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

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

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

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

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

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

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

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

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

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

Схема 1. Инкрементная модель

Преимущества Инкрементной модели:

• Не требуется заранее тратить средства, необходимые для разработки всего проекта

• При выполнении каждого инкремента получается функциональный продукт

• Заказчик может высказаться по поводу каждой разработанной версии системы

• Существует возможность поддерживать постоянный прогресс в ходе выполнения проекта

• Снижаются затраты на первоначальную поставку программного продукта

• Снижается риск неудачи и изменения требований

• Риск распределяется на несколько меньших по размеру инкрементов