5. Внешнее описание программного средства и процесс его разработки…

Назначение внешнего описания программного средства

Раз-ка любого ПС нач-ся с процесса формулир-я требований к нему. При эт, исходя из довольно смутных пожеланий заказчика, д/б получен док-т, достаточно точно определяющий задачи разр-ков этого ПС: внешнее описание ПС или (ТЗ) на его разработку.

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

ВО ПС играет роль точной постановки з-чи, решение кот д обеспечить разрабатываемое ПС. Оно д содержать всю инф-ю, кот необх знать польз-лю для применения ПС. Оно явл исходным док-том для трех парал-но протекающих пр-сов: 1. разр-ки текстов (конструир-нию и кодир-ю) прог, входящих в ПС, 2. разр-ки докум-ции по применению ПС, 3. разр-ки существенной части комплекта тестов для тестир-я ПС. Ош-ки и неточности во ВО, трансфор-ся в ош-ки самого ПС.

ВО определяет, что должно делать ПС и какими внешними св-ми оно д обладать. Оно не отвечает на вопросы, как должно быть устроено это ПС. Оно обязано полно и точно определить задачи, кот-е д решить разр-ки требуемого ПС. В то же время оно д/быть понято представителем пользователя  на его основании заказчиком дост-но часто принимается окончательное решение на заключение договора на разработку ПС.

Существующие ст-ты на разработку технического задания. В настоящий момент при разработке ТЗ на требуемое ПС обычно используют два стандарта:

ГОСТ 19.201-78 ЕСПД. Техническое задание. Требования к содержанию и оформлению;

ГОСТ 34.602-89. Информационная технология. Техническое задание на создание автоматизированной системы.

Согласно первому из этих стандартов техническое задание должно содержать следующие разделы: наименование и область применения; основание для разработки; назначение разработки; технические требования к программе или программному изделию; технико-экономические показатели; стадии и этапы разработки; порядок контроля и приёмки; приложения. Содержание отдельных разделов ТЗ в ГОСТ 19.201-78 ЕСПД раскрыто очень лаконично, что оставляет много простора для ненужного «творчества» при составлении ТЗ, которое по этим причинам часто оказывается неполным.

Более предпочтительным в этом отношении представляется стандарт ГОСТ 34.602-89, в котором ПС рассматривается как важнейшая часть информационной системы. Согласно этому стандарту ТЗ на автоматизированную систему должно содержать следующие основные разделы, которые могут быть разделены на подразделы: 1) общие сведения; 2) назначение и цели создания (развития) системы; 3) характеристика объектов автоматизации; 4) требования к системе; 5) состав и содержание работ по созданию системы; 6) порядок контроля и приемки системы; 7) требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие; 8) требования к документированию; 9) источники разработки. 10) приложения. Данный стандарт значительно подробнее первого и включает в себя разветвленную иерархическую структуру из пунктов и подпунктов, которая способствует разработке более полных, непротиворечивых, удобно отслеживаемых и проверяемых ТЗ.

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

ГОСТ 28195-89 дает более подробную 4уровневую иерарх-ю стр-ру показателей кач-ва ПС: факторы кач-ва (6 штук), кр-рии кач-ва (19), метрики (несколько десятков), оценочные эл-ты (240).

1 уровень опр-ет группы показателей кач-ва ПС, хар-щие потребительски-ориентированные св-ва, кот соответствуют потребностям польз-лей. 2 уровень определён комплексными показателями кач-ва ПС, хар-щими программно-ориентированные св-ва, кот обеспечивают достижение требуемых потребительски-ориентированных св-в. Эти 2 верхн ур-ня модели кач-ва и пред-ют наиб интерес на этапе составления ВО. Два нижних ур-ня в основном представляют интерес для разр-ка, показывая ему механизмы дальнейшего объективного оценивания показателей кач-ва верхн ур-ней.

Общ стр-ра показ-лей кач-ва двух уровней:

1 Показ-ли надежности (Н): Устойчивость функционир-ния;Работоспособность .

2 Пок-ли сопр-ния (С): Стр-сть; Простота констр-ции; Наглядн-ть; Повтор-сть.

3 Показатели удобства применения (У): Легкость освоения;Доступность эксплуатационных программных документов;Удобство эксплуатации и обслуживания.

4 Пок-ли эфф-сти (Э): Ур-нь автоматизации; Временная эфф-сть; Ресурсоемкость.

5 Показатели универсальности: Гибкость; Мобильность; Модифицируемость.

6 Пок корр-сти: Полнота реализации; Соглас-сть; Логич корр-ть; Проверенность.

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

Функциональная спецификация программного средства. С учетом назначения функц-ной спец-ции ПС и тяжелых последствий неточностей и ошибок в этом док-те, она д/б математически точной. Это не означает, что она д/б формализована настолько, что по ней м б бы автоматически генерировать проги. А означает, что она д базир-ся на понятиях, постр-ых как мат-е объекты, и утверждениях, однозначно понимаемых заказчиками и разработчиками ПС.

Функциональная спецификация состоит из трех основных частей:

• описания внешней инф среды, к кот д применяться программы разраб-ого ПС;

• определение функций ПС, заданных на мн-ве состояний этой инф-ой среды;

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

В 1 части д/б опр-ны на концептуальном уровне все исп-ые каналы ввода и вывода и все инф-ые объекты, к кот б прим-ся разрабатыв-е ПС, а также существенные связи м/ду этими инф-ми объектами. (концептуальная схема базы данных)

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

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