Гост 34.201-89 информационная технология (ит). комплекс стандартов на автоматизированные системы. виды, комплектность и обозначение документов при создании автоматизированных систем (с изменением n 1)

Раздел 6 «Порядок контроля и приемки системы» /п. 2.8 ГОСТ 34.602-89/

1. Испытания делятся на следующие виды:

• Предварительные.
• Опытная эксплуатация.
• Приемочные.

2. Предварительные (а частично и приемочные) испытания в свою очередь делятся на:

• Автономные (без интеграции со смежными системами).
• Комплексные (в комплексе со смежными системами).

1. Предварительные автономные испытания частей системы.2. Предварительные автономные испытания системы в целом.3. Предварительные комплексные испытания.4. Опытная эксплуатация.5. Приемочные испытания.

• Для предварительных и приемочных испытаний это «Программа и методика предварительных (приемочных) испытаний». Указания для составления документа содержатся сразу в двух стандартах. Вкратце — в ГОСТ 34.603-92 (п. 2.2.2 и 4.1) и более подробно — в РД 50-34.698-90 «Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов».
• Для опытной эксплуатации предусматривается документ «Программа опытной эксплуатации», содержание которого приводится в п. 3.1 ГОСТ 34.003-90. Также следует прописать использование «Журнала опытной эксплуатации» (см. п. 3.2 ГОСТ 34.603-92), в который будут заноситься недостатки и результаты их устранения.

9.2. Подраздел 6.2. «Общие требования к приемке работ по стадиям» /п. 2.8.2 ГОСТ 34.602-89/

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

4.2 Требования к документации

4.2.1 ПО СИ должно сопровождаться
документацией, соответствующей требованиям стандартов Единой системы
программной документации. Документация должна полно и однозначно описывать
назначение, основные функции, структуру и другие необходимые параметры и
характеристики ПО.

4.2.2 Минимальный набор
документов, сопровождающих ПО СИ, например при его аттестации, рекомендуется
представлять в следующем составе:

— техническое задание по ГОСТ
19.201;

— спецификация по ГОСТ
19.202;

— описание применения по ГОСТ
19.502;

— схемы алгоритмов,
программ, данных и систем по ГОСТ
19.701;

— руководство
пользователя.

В перечисленных
документах отображают, как минимум, следующую информацию, необходимую для
проведения аттестации ПО:

— обозначение ПО,
включающее в себя его наименование, обозначение его версии или версий его
модулей;

— описание назначения ПО,
его структуры и выполняемых функций;

— описание методов и
способов идентификации ПО, а также его метрологически значимых частей, функций
и параметров;

— описание реализованных
в ПО расчетных алгоритмов, а также их блок-схемы;

— описание интерфейсов
пользователя, всех меню и диалогов;

— описание интерфейсов
связи ПО для передачи, обработки и хранения данных (в том числе посредством
открытых или закрытых сетей связи);

— описание реализованных
методов защиты ПО и данных;

— описание способов
хранения измеренных данных на встроенном, удаленном или съемном носителе;

— описание требуемых
системных и аппаратных средств, если эта информация не приведена в руководстве
пользователя.

4.2.3 В отдельных
случаях, при необходимости, при проведении аттестации ПО СИ его документацию
рекомендуется дополнять текстами программ или их фрагментами в соответствии с ГОСТ
19.401. При этом может быть заключен договор о соблюдении
конфиденциальности.

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

ВИДЫ ПРОГРАММНЫХ ДОКУМЕНТОВ

2.1. К программным относят
документы, содержащие сведения, необходимые для разработки, изготовления, сопровождения
и эксплуатации программ.

2.2. Виды программных
документов и их содержание приведены в

(Измененная редакция, Изм. № 1).

2.3. Виды эксплуатационных
документов и их содержание приведены в табл. 3.

Таблица
3

(Измененная редакция, Изм. № 1).

2.4. В зависимости от
способа выполнения и характера применения программные документы подразделяются на
подлинник, дубликат и копию (ГОСТ 2.102-68),
предназначенные для разработки, сопровождения и эксплуатации программы.

2.5. Виды программных
документов, разрабатываемых на разных стадиях, и их коды приведены в .

Условные обозначения:

 — документ обязательный;

 — документ обязательный
для компонентов, имеющих самостоятельное применение;

О —
необходимость составления документа определяется на этапе разработки и
утверждения технического задания;

— — документ
не составляют.

2.4, 2.5 (Измененная редакция, Изм. № 1).

2.6. Допускается объединять
отдельные виды эксплуатационных документов (за исключением ведомости
эксплуатационных документов и формуляра). Необходимость объединения этих
документов указывается в техническом задании. Объединенному документу
присваивают наименование и обозначение одного из объединяемых документов.

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

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

Технические условия
разрабатывают на стадии «Рабочий проект».

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

(Введен дополнительно, Изм. № 1).

4.3 Требования к разделению программного обеспечения и его идентификации

4.3.1.1 Для СИ,
применяемых в сфере государственного регулирования, на этапе разработки
рекомендуется выделение метрологически значимой части ПО, т.е. выделение той
его части, которая подлежит аттестации.

Примечание — Разделение ПО СИ
рекомендуется проводить его разработчикам, поскольку такое разделение
предоставляет возможность модификации метрологически незначимых частей ПО без нарушения
его соответствия утвержденному ПО. Если разделение ПО не проведено, то все оно
рассматривается как метрологически значимое.

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

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

4.3.1.4 Данные,
отображаемые на дисплее и/или передаваемые на устройство печати, сформированные
метрологически незначимым ПО, должны быть визуально четко отделены от данных,
получаемых из метрологически значимых частей ПО.

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

Любая модификация
метрологически значимой части ПО приводит к изменению его идентификации,
необходимости его повторной аттестации и внесения изменений в описание типа СИ.

4.3.1.8 Требования к
особенностям взаимодействия между метрологически значимыми и незначимыми
частями ПО изложены в .

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

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

4.3.2.2 Идентификация,
проводимая пользователем, может быть осуществлена либо по его команде, либо
выполнена в процессе штатного функционирования ПО.

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

4.3.2.3 Для получения
идентификационных данных (признаков) уполномоченными органами (организациями)
необходимо предусмотреть возможность доступа к исполняемому коду метрологически
значимой части ПО с помощью известных интерфейсов связи.

4.3.2.4 Идентификационные
данные (признаки) должны иметь структуру, которая однозначно определяет
метрологически значимое ПО (используемое при утверждении типа), а также
метрологически незначимое ПО.

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

4.3.2.5 Идентификация не
распространяется на операционную систему и драйверы, не относящиеся
непосредственно к выполнению измерительной задачи (например, видеодрайверы,
драйверы принтера, драйверы дисков и т.п.), но распространяется на драйверы,
используемые для выполнения измерительных задач.

4.3.2.6 Алгоритм
идентификации относится к метрологически значимой части ПО СИ.

4.3.2.7 При отсутствии
или невозможности разделения ПО (см. )
идентификации подлежит все ПО СИ.

4.3.2.8 Техническая
документация на ПО СИ должна содержать полный перечень и изложение способов
идентификации метрологически значимого ПО, а также описание структуры
идентификации и интерфейсов связи (при необходимости).

ВИДЫ ПРОГРАММНЫХ ДОКУМЕНТОВ

2.1. К программным относят документы, содержащие сведения, необходимые для разработки, изготовления, сопровождения и эксплуатации программ.

2.2. Виды программных документов и их содержание приведены в табл. 2.

Издание официальное ★

Перепечатка воспрещена

) Издательство стандартов, 1977 СТАНДАРТИНФОРМ, 2010

Издание (январь 2010 г.) с Изменением № 1, утвержденным в июне 1981 г. (ИУС 9—81).

Таблица 2

2.3. Виды эксплуатационных документов и их содержание приведены в табл. 3.

Таблица 3

Вид

эксплуатационного документа

Содержание эксплуатационного документа

Ведомость эксплуатационных документов Формуляр

Описание применения

Руководство системного программиста

Руководство программиста Руководство оператора

Описание языка Руководство по техническому обслуживанию

Перечень эксплуатационных документов на программу

Основные характеристики программы, комплектность и сведения об эксплуатации программы

Сведения о назначении программы, области применения, применяемых методах, классе решаемых задач, ограничениях для применения, минимальной конфигурации технических средств

Сведения для проверки, обеспечения функционирования и настройки программы на условия конкретного применения

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

Сведения для обеспечения процедуры общения оператора с вычислительной системой в процессе выполнения программы

Описание синтаксиса и семантики языка

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

2.4. В зависимости от способа выполнения и характера применения программные документы подразделяются на подлинник, дубликат и копию (ГОСТ 2.102—68), предназначенные для разработки, сопровождения и эксплуатации программы.

2.5. Виды программных документов, разрабатываемых на разных стадиях, и их коды приведены в табл. 4.

Таблица 4

Продолжение таблицы 4

Условные обозначения:

• — документ обязательный;

С — документ обязательный для компонентов, имеющих самостоятельное применение;

О — необходимость составления документа определяется на этапе разработки и утверждения технического задания;

—документ не составляют.

Заключение

Разработка и управление требованиями к ПОпример ТЗ, который я писал много лет назад

• Презентацией Юрия Булуя Классификация требований к программному обеспечению и ее представление в стандартах и методологиях.
• Анализ требований к автоматизированным информационным системам. Лекция 11: Документирование требований.
• Правила составления Software requirements specification (читать вместе с комментариями)
• Примеры ТЗ и другой документации по разработке АС для МЭР
• ГОСТ-овский стиль управления. Статья Gaperton по правильной работе с ТЗ по ГОСТ
• Шаблоны документов для бизнес-аналитиков из группы ВК «Business Analysis Magazine»