ВУЗ: Томский государственный университет систем управления и радиоэлектроники
Категория: Методичка
Дисциплина: Проектирование информационных систем
Добавлен: 21.10.2018
Просмотров: 5795
Скачиваний: 6
11
1.5.5 Требования к информационной и программной
совместимости
В подразделе «Требования к информационной и программ-
ной совместимости» должны быть указаны требования к ин-
формационным структурам на входе и выходе и методам реше-
ния, исходным кодам, языкам программирования и программ-
ным средствам, используемым программой. При необходимости
должна обеспечиваться защита информации и программ.
Пример. ЭВМ должна работать под управлением операци-
онной системы не ниже, чем Windows 98/NT 4.0. Требование
информационной совместимости должно быть обеспечено рабо-
той с файлами геометрической информации определенной
структуры в качестве входной и выходной информации.
1.6
Требования
к
программной
документации
В разделе «Требования к программной документации» дол-
жен быть указан предварительный состав программной докумен-
тации и, при необходимости, специальные требования к ней.
1.7
Технико
-
экономические
показатели
В разделе «Технико-экономические показатели» должны
быть указаны: ориентировочная экономическая эффективность,
предполагаемая годовая потребность, экономические преиму-
щества разработки по сравнению с лучшими отечественными и
зарубежными образцами или аналогами.
1.8
Стадии
и
этапы
разработки
В разделе «Стадии и этапы разработки» устанавливают не-
обходимые стадии разработки, этапы и содержание работ (пере-
чень программных документов, которые должны быть разрабо-
таны, согласованы и утверждены), а также, как правило, уста-
навливают сроки разработки и определяют исполнителей.
12
2
СОГЛАШЕНИЕ
О
ТРЕБОВАНИЯХ
Составление соглашения о требованиях — цель второй час-
ти первой лабораторной работы. Также соглашение о требова-
ниях является вторым разделом курсовой работы.
Ниже дается описание разделов, которые должны присутст-
вовать в любом соглашении о требованиях (СТ) согласно ГОСТу.
Все последующие упоминания о соглашении о требованиях
имеют в виду соглашение о требованиях, разработанное в соот-
ветствии с данным разделом. Описываемый подход предполага-
ет также декомпозицию проекта и дальнейшую детализацию,
отражаемую во внешней спецификации изделия.
Предполагается, что все утверждения, включенные в со-
глашение о требованиях, являются требованиями, если они не
определены как цели. Различие состоит в том, что требование
должно быть обязательно выполнено, а цель допускает ее дос-
тижение с некоторым приближением.
Описание информации, содержащейся в СТ, дается ниже
очень подробно, и, возможно, после чтения первых абзацев поя-
вится желание ограничиться беглым просмотром. Однако если
вам когда-нибудь придется разрабатывать свой собственный
стандарт СТ, вы, вероятно, оцените предлагаемый здесь со все-
ми подробностями пример и используете его как образец. С уче-
том того, что сжатость заголовков разделов и большой объем их
описаний скрывают порядок и простоту, лежащие в основе ре-
зультирующего документа, в конце каждого пункта приводится
пример оформления на конкретное изделие. Вероятно, вам
опять не захочется читать все приложение целиком, поэтому
рекомендуется для начала бегло просмотреть его, чтобы полу-
чить представление, как выглядит типичное СТ в целом. Затем
можно будет обращаться к отдельным его разделам, чтобы
иметь дополнительные примеры, иллюстрирующие приводимый
материал.
13
2.1
Описание
программного
изделия
2.1.1 Наименование и шифры изделия
2.1.1.1
П
ОЛНОЕ НАИМЕНОВАНИЕ ИЗДЕЛИЯ
Указывается предлагаемое полное наименование изделия.
После утверждения СТ не должны использоваться никакие дру-
гие наименования для данного изделия, кроме сокращенных на-
именований, которые приводятся ниже.
Пример. ASK (произносится «аск»).
2.1.1.2
С
ОКРАЩЕННЫЕ НАИМЕНОВАНИЯ
Указываются все предлагаемые сокращения, которыми раз-
решается заменять наименование, приведенное в пункте 2.1.1.1.
После утверждения СТ не рекомендуется использовать никакие
другие сокращения. В противном случае делается пометка «От-
сутствуют».
2.1.1.3
Ш
ИФРЫ ИЗДЕЛИЯ
Указываются шифр или шифры изделия, присвоенные в со-
ответствии с требованиями удобства управления его конфигу-
рацией. Если предполагается выпуск печатных изданий и разра-
ботка планов поддержки, порядок присвоения шифров конеч-
ным результатам работы группы выпуска документации и груп-
пы поддержки может быть иным.
Пример. L301A.
2.1.1.4
Ш
ИФРЫ ПРОЕКТА
Приводятся все шифры проекта, используемые в процессе
разработки изделия.
Пример. C013.
2.1.2 Краткое описание изделия
Описываются кратко и в общих понятиях основные функ-
циональные свойства изделия. Если программное изделие явля-
ется расширением уже существующего, характеризуются только
его новые свойства.
14
Пример. ASK позволяет специалисту по финансовому ана-
лизу или другому лицу с аналогичными аналитическими зада-
чами в интерактивном режиме и на расстоянии запрашивать
ЭВМ серии Stella 100 выполнить поиск и обработку финансовой
информации из DATABASE, которая содержит фундаменталь-
ные сведения и зависимости по данным за 20 лет для большого
числа корпораций и отраслей. ASK может также формировать
дополнительные общедоступные или частные сведения, файлы
корпораций и отраслей, выражения и элементы и использовать
их вместе с информацией из DATABASE.
Программное изделие ASK в совокупности с DATABASE
образует сервисную систему ASK DATABASE; все три системы
являются собственностью фирмы ABC Services.
2.1.3 Сведения об авторском праве
Если предполагается заявить об установленной законом за-
щите авторских прав на данное изделие, это должно реализо-
ваться уже в CТ. В противном случае делается пометка «Не тре-
буется».
Пример. Copyright
©
1977 by ABC Computers Company.
2.1.4 Результирующие компоненты изделия
В данном разделе приводится таблица, подобная или экви-
валентная таблице 2.1. В данном случае использована заранее
подготовленная печатная форма, что уменьшает время подго-
товки информации и обеспечивает ее согласованность.
В указанной таблице в строке «Тип изделия» ставится метка
X против соответствующей характеристики «Основное» или
«Вспомогательное». Если изделие не используется для создания
других изделий, оно отмечается как основное. В противном слу-
чае (например, ассемблер, компилятор или генератор) оно отме-
чается как вспомогательное.
В графе «Уровень поддержки» выбирается метка 1, 2 или 3
в соответствии с пояснениями в бланке.
15
Каждый элемент изделия отмечается меткой X в графе
«Формируется целиком», если он будет создаваться заново, или
в графе «Модифицируется», если будут вноситься только до-
полнения или изменения. Метка X ставится в графе «Распро-
страняется» (за пределы группы разработки) или «Не распро-
страняется» (за пределы группы разработки) в зависимости от
того, что является правильным. В графе «Ответственная группа»
пишется Р, И, П или C — по ключу на бланке. Если предполага-
ется выпуск нестандартных изделий, этот факт отмечается в
графе «Другие спецификации» и описание соответствующих
документов дается сразу после таблицы.
Таблица 2.1 — Результирующие компоненты изделия
Ф
орм
ируе
тс
я
целико
м
М
одиф
ицир
уе
тс
я
Р
аспр
ос
тр
аня
ет
ся
Не
ра
сп
рос
тра
няе
тс
я
О
тв
етс
тв
ен
на
я
гр
уппа
Спецификации
Внешняя специ-
фикация
X
X
Р
Внутренняя спе-
цификация
X
X
Р
Спецификация
испытаний (не
надо)
Спецификация
сопровождения
(не надо)
Другие специфи-
кации
Документация
Техническое опи-
сание системы
Обозначения:
Основное изделие — не исполь-
зуется для создания других из-
делий
Вспомогательное изделие —
используется для создания дру-
гих изделий
Уровень поддержки 1: удовле-
творяются заявки на исправле-
ние дефектов; возможно сооб-
щение об изменениях; прини-
маются заявки на расширение
функциональных возможностей
изделия
Уровень поддержки 2: удовле-
творяются заявки на исправле-
ние дефектов; возможно сооб-
щение об изменениях; заявки на
расширение не принимаются
Уровень поддержки 3: удовле-
творяются заявки на исправле-
ние дефектов
Р — группа разработки
Справочное руко-
водство
X
X
Б