2. Разработка логической модели программного продукта

Как уже отмечалось, разработчик должен сконструировать логическую модель проектируемого программного продукта, независимую от последующей физической реализации, которая должна отражать требования пользователя. Эта модель используется для выработки совокупности требований к программному обеспечению. Существующие структурные методологии используют для построения модели принцип нисходящей декомпозиции основной функции программного изделия в иерархию функций с последовательной детализацией функции на следующих уровнях иерархии. Средством логического моделирования является структурный системный анализ, позволяющий подробно описывать схемы потоков данных, которые будут существовать при функционировании автоматизированной системы (программного продукта). Для описания схем потоков данных используются компоненты: источник/приемник данных, линия потока данных, хранилище данных, блок обработки данных.

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

Логическая модель должна удовлетворять следующим правилам:

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

2. Функции должны соответствовать уровню иерархии, на котором они представлены в модели.

3. Связи между функциями (функциональными блоками модели) должны быть минимизированы.

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

5. В модели не должна присутствовать информация, связанная с последующей реализацией изделия, например, такие понятия, как модуль, файл, запись и т. п.

6. Для каждой функции должны быть указаны входные данные.

7. Каждой функции должен соответствовать список выходных данных (выходных отчетов).

4. Классификация требований к программному продукту

Требования к программному продукту должны быть систематизированы в соответствии со следующими категориями:

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

2. Эксплуатационные требования определяют значения измеряемых переменных, характеризующих работу программного продукта. Они могут быть представлены либо в виде отдельных требований, либо в виде количественных атрибутов функциональных требований. Количественные требования не должны фиксироваться в виде качественных характеристик типа «быстрый ответ», а должны быть записаны, например, в виде «время ответа должно быть не более X сек», или вместо «в большинстве случаев» должно быть указано «для У% случаев среднее время ответа должно быть менее 2 сек» и т. п. Атрибуты эксплуатационных характеристик могут быть также представлены в виде диапазона значений.

3. Требования к интерфейсам описывают элементы технических средств, программного обеспечения, баз данных, с которыми должен взаимодействовать программный продукт. Требования к интерфейсам с техническими средствами могут определять необходимую их конфигурацию. Требования к программному обеспечению могут включать требования к типу и версии операционной системы, прикладным пакетам, типу СУБД. Требования к внешним интерфейсам могут потребовать, например, использования конкретного сетевого протокола передачи информации, определенного языка описания документов и т. п. Требования к интерфейсам могут быть проиллюстрированы с помощью специальных структурных схем, описывающих взаимодействие программного изделия с окружающей обстановкой.

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

5. Требования к ресурсам обычно устанавливают верхние пределы для характеристики технических средств, таких как скорость процессора, емкость внешней и оперативной памяти и т. д.

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

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

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

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

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