Г О С У Д А Р С Т В Е Н Н Ы Й С Т А Н Д А Р Т С О Ю З А С С Р

Система технической документации на АСУ	ГОСТ 24.207-80
ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ДОКУМЕНТОВ ПО ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ
System of technical documentation for computer control systems. Requirements for contents of documents on software

Постановлением Государственного комитета СССР по стандартам от 14 мая 1980 г. № 2101 срок введения установлен

с 01.01 1981 г.

Настоящий стандарт распространяется на техническую документацию на автоматизированные системы управления (АСУ) всех видов, разрабатываемые для всех уровней управления (кроме общегосударственного), и устанавливает требования к содержанию документов, входящих в соответствии с ГОСТ 24.101-80 в состав документации программного обеспечения в проектах АСУ.

1. ОБЩИЕ ПОЛОЖЕНИЯ

1.1. Документация программного обеспечения предназначена:

• для описания проектных решений по программному обеспечению в документе «Описание программного обеспечения АСУ».
• для установления требований к программе (комплексу программ) в документе «Техническое задание»;
• для описания решений, обеспечивающих сопровождение, изготовление и эксплуатацию программы (комплекса программ) в документах «Пояснительная записка», «Описание применения», «Описание программы», «Спецификация», «Руководство программиста», «Руководство оператора», «Текст программы», «Формуляр», «Порядок и методика испытаний»;
• для проверки работоспособности программы (комплекса программ) в документе «Описание контрольного примера».

1.2. При разработке документов на части АСУ содержание разделов каждого документа ограничивают рамками соответствующей части.

1.3. В зависимости от назначения и специфических особенностей создаваемых АСУ допускается включать в документы дополнительные разделы, требования к содержанию которых не установлены настоящим стандартом. Отсутствие проектных решений по разделу документа фиксируют в соответствующем разделе с необходимыми пояснениями.

1.4. Требования к содержанию документов «Техническое задание», «Пояснительная записка», «Описание применения», «Спецификация», «Руководство оператора», «Текст программы», «Формуляр», «Порядок и методика испытаний» установлены ГОСТ 19.201-78 , ГОСТ 19.404-79 , ГОСТ 19.502-78 , ГОСТ 19.202-78 , ГОСТ 19.505-79 , ГОСТ 19.401-78 , ГОСТ 19.501-78 и ГОСТ 19.301-79 .

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

2. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ДОКУМЕНТОВ

2.1. Описание программного обеспечения АСУ

2.1.1. Документ должен содержать вводную часть и разделы:

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

2.1.2. Вводная часть должна содержать основные сведения о техническом, информационном и других видах обеспечения АСУ, необходимые для разработки программного обеспечения, или ссылку на соответствующие документы проекта АСУ.

2.1.3. Раздел «Структура программного обеспечения» должен содержать перечень частей программного обеспечения с указанием их взаимосвязей и обоснованием выделения каждой из них.

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

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

2.1.5. Раздел «Методы и средства разработки программного обеспечения» должен содержать перечень методов программирования и средств разработки программного обеспечения АСУ с указанием частей программного обеспечения, при разработке которых следует использовать соответствующие методы и средства.

2.1.6. Раздел «Операционная система» должен содержать:

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

2.1.7. Раздел «Средства, расширяющие возможности операционной системы» должен содержать подразделы, в которых для каждого используемого средства, расширяющего возможности операционной системы, следует указать:

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

2.2. Описание программы

2.2.2. Для программы (комплекса программ), получаемой за счет использования ранее разработанных программных средств, документ «Описание программы» следует дополнять разделом «Настройка программных средств».

2.2.3. Раздел «Настройка программных средств» должен содержать:

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

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

2.3.1. Документ по составу разделов и их содержанию должен соответствовать ГОСТ 19.504-79 и, кроме того, включать раздел «Сведения о форме представления программы (комплекса программ)».

2.3.2. Раздел «Сведения о форме представления программы (комплекса программ)» должен содержать сведения о носителе, на котором записана программа, о содержании и системе кодирования информации, записанной на носителе, а также сведения, необходимые для чтения информации с носителя.

2.3.3. Для программы (комплекса программ), допускающей настройку на условия конкретного применения, в документ «Руководство программиста» включают разделы:

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

2.3.4. Разрешается для программы (комплекса программ), допускающей настройку на условия конкретного применения, вместо разделов, перечисленных в п. 2.3.3, разрабатывать отдельный документ «Руководство системного программиста», удовлетворяющий требованиям ГОСТ 19.503-79 .

2.4. Описание контрольного примера

2.4.1. Документ должен содержать разделы:

• назначение;
• исходные данные;
• результаты расчета;
• проверка программы (комплекса программ).

2.4.2. Раздел «Назначение» должен содержать перечень параметров и краткую характеристику функции, из числа реализуемых программой (комплексом программ), проверяемых контрольным примером.

2.4.3. Раздел «Исходные данные» должен содержать описание исходных данных для проверки программы (комплекса программ) с приведением исходных данных. Допускается исходные данные представлять в виде распечатки с АЦПУ.

2.4.4. Раздел «Результаты расчета» должен содержать результаты обработки исходных данных программой (комплексом программ), позволяющие оценить правильность выполнения проверяемых функции и значение проверяемых параметров. Допускается результаты расчета приводить в виде распечатки с АЦПУ.

2.4.5. Раздел «Проверка программы (комплекса программ)» должен содержать:

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

* Переиздание (май 1986 г.) с Изменением № 1, утвержденным в августе 1985 г. (ИУС 11-85).

КУЛЬТУРА РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Любое программное обеспечение , от простого Web-сайта до мощных систем управления базами данных , является высокотехнологичным изделием и должно отвечать следующим критериям:

• надежности;
• адекватной обработке нештатных ситуаций;
• легкой модернизируемости.

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

Общие этапы разработки программ :

• определение требований к программе;
• разработка технического задания;
• разработка проекта программы;
• кодирование программы;
• сборка программы;
• тестирование программных модулей;
• опытная эксплуатация программы;
• доводка программного обеспечения;
• ввод программы в постоянную эксплуатацию;
• поддержка программы;
• определение требований к новой версии программы;

Для определения требований к программе разработчику необходимо получить ответ на вопрос: «Насколько заказчик заинтересован в разработке программы?»

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

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

• Какова(-ы) цель(-ли) программы?
• Круг пользователей программы.
• Нормативная (правовая, справочная) база, на которую опираются процессы, алгоритмизируемые в программе.
• Возможность и необходимость дальнейшего развития программы.
• Контактное лицо, уполномоченное решать все вопросы от лица заказчика.
• Наличие материалов, которые есть или заказчик планирует подготовить для использования в программе (!!! Этот пункт особенно важен для разработки Web-сайтов).

Разработка технического задания в идеале должна осуществляться заказчиком. На практике зачастую это делает разработчик по причине отсутствия у заказчика квалифицированных специалистов, сведущих в области разработки программного обеспечения. Техническое задание, как правило, разрабатывается на основе ГОСТа 19.201-78 «ЕСПД. Техническое задание. Требования к содержанию и оформлению». В случаях разработки технического программного обеспечения в составе автоматизированных систем применяется ГОСТ 34.602-89 «Информационная технология. Техническое задание на создание автоматизированной системы».

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

На основе утвержденного технического задания разрабатывается проектная документация (проект ). Содержание проекта зависит от типа программного обеспечения и традиций предприятия разработчика.

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

• пояснительная записка (по ГОСТу 19.404-79 «ЕСПД. Пояснительная записка. Требования к содержанию и оформлению»).
• описание программы (по ГОСТу 19.402-78 «ЕСПД. Описание программы»).
• перечень терминов, используемых в проекте. Для web-сайтов в состав проекта включаются:
• эскиз дизайна сайта;
• перечень материалов, используемых в составе сайта;
• структура баз данных (в случае наличия таковых)

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

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

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

Тщательно в коде должен быть описан смысл входных и выходных данных каждого модуля, а также смысл и функции самого модуля. Это важно для успеха сборки программы.

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

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

1. Определяется набор аппаратуры для производства тестирования.
2. Разрабатываются сценарии (контрольные примеры) для тестирования.
3. На основе сценариев проверяется работа программы в штатном режиме (проверяется правильность выполнения тех функций, которые программа и должна выполнять).
4. Проверяется работа программы в нештатных режимах (проверяется, устойчиво ли работает программа в режимах, которые могут возникать только при нарушении пользователями правил эксплуатации программы, например, ввод букв в цифровое поле).
5. Производится тестирование на удобство управления программой и качество интерфейсов.
6. Данные тестирования и его результаты обрабатываются и оформляются в соответствии с ГОСТом 34.603-92 «Информационная технология. Виды испытаний автоматизированных систем».
7. По мере выявления ошибок последние исправляются, и тестирование производится повторно.
8. После исправления всех ошибок программа передается в опытную эксплуатацию.

Заказчику на стадии опытной эксплуатации передается программа и обязательный пакет документации:

• ведомость эксплуатационных документов (по ГОСТу 19.507-79 «ЕСПД. Ведомость эксплуатационных документов»)
• формуляр (по ГОСТу 19.501-78 «ЕСПД. Формуляр. Требования к содержанию и оформлению»)
• описание применения (по ГОСТу 19.502-78 «ЕСПД. Описание применения. Требования к содержанию и оформлению»)
• руководство системного программиста (по ГОСТу 19.503-79 «ЕСПД. Руководство системного программиста. Требования к содержанию и оформлению»)
• руководство оператора (по ГОСТу 19.505-79 «ЕСПД. Руководство оператора. Требования к содержанию и оформлению»).

В зависимости от вида задачи дополнительно могут передаваться:

• руководство программиста (по ГОСТу 19.504-79 «ЕСПД. Руководство программиста. Требования к содержанию и оформлению»)
• руководство по т/о (по ГОСТу 19.508-79 «ЕСПД. Руководство по техническому обслуживанию. Требования к содержанию и оформлению»).

На стадии опытной эксплуатации программы фиксируются замечания заказчика и выявленные ошибки.

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

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

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

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

Только грамотный процесс разработки программ обеспечивает их высокое качество и долгую жизнь!!!

ГОСТ 19.101-77

Группа Т55

МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ

Единая система программной документации

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

Unified system for program documentation. Types of programs and program documents

МКС 35.080

Дата введения 1980-01-01

Постановлением Государственного комитета стандартов Совета Министров СССР от 20 мая 1977 г. N 1268 дата введения установлена 01.01.80

ИЗДАНИЕ (январь 2010 г.) с Изменением N 1, утвержденным в июне 1981 г. (ИУС 9-81).


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

Стандарт полностью соответствует СТ СЭВ 1626-79.

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

1. ВИДЫ ПРОГРАММ

1. ВИДЫ ПРОГРАММ

1.1. Программу (по ГОСТ 19781-90) допускается идентифицировать и применять самостоятельно и (или) в составе других программ.

1.2. Программы подразделяют на виды, приведенные в табл.1.

Таблица 1

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

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

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

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

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

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

Таблица 2

Вид программного документа
Спецификация	Состав программы и документации на нее
	Перечень предприятий, на которых хранят подлинники программных документов
Текст программы	Запись программы с необходимыми комментариями
Описание программы	Сведения о логической структуре и функционировании программы
	Требования, подлежащие проверке при испытании программы, а также порядок и методы их контроля
Техническое задание	Назначение и область применения программы, технические, технико-экономические и специальные требования, предъявляемые к программе, необходимые стадии и сроки разработки, виды испытаний
Пояснительная записка	Схема алгоритма, общее описание алгоритма и (или) функционирования программы, а также обоснование принятых технических и технико-экономических решений
Эксплуатационные документы	Сведения для обеспечения функционирования и эксплуатации программы

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

Таблица 3

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

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

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

Таблица 4

Код вида документа	Вид документа	Стадии разработки
		Эскизный проект	Технический проект	Рабочий проект
				компонент	комплекс
	Спецификация
	Ведомость держателей подлинников
	Текст программы
	Описание программы
	Ведомость эксплуатационных документов
	Формуляр
	Описание применения
	Руководство системного программиста
	Руководство программиста
	Руководство оператора
	Описание языка
	Руководство по техническому обслуживанию
	Программа и методика испытаний
	Пояснительная записка
	Прочие документы

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

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

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

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

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

2.2-2.5. (Измененная редакция, Изм. N 1).

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

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

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

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

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

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



Электронный текст документа
подготовлен АО "Кодекс" и сверен по:
официальное издание
Единая система программной
документации: Сб. ГОСТов. -
М.: Стандартинформ, 2010

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

В свое время, когда я только начинал работать программистом, часто приходилось слышать “напиши, пожалуйста, документацию к своей программе”. Я честно все описывал, отдавал начальнику, после чего начинался сеанс черной магии. Начальник через некоторое время меня вызывал и начинал мычать нечленораздельные звуки, мять распечатку моего “самого лучшего” текста в руках, бегая глазами. Общий смысл его мычания заключался в том, что получилось “не то”, “не так”, и “посмотри, как делают другие”. Так как никакого другого ответа из него вытянуть было невозможно, я шел за примерами документов к “другим”. Как правило, это были веселые ребята, смысл речей которых заключался в том, что “вот примеры”, “вообще то по ГОСТу” и “это все никому не нужно”. Так я узнал впервые, что программист может соприкоснуться со страшными ГОСТами.
Поразительно, что среди многих десятков моих коллег, очень неглупых программистов, не было никого, кто бы относился к ГОСТам по другому. Даже те несколько человек, которые их знали и, вроде как, даже умели оформлять документы, относились к ним презрительно-формально. Ситуация, когда даже люди, ответственные за управление разработкой не понимают, зачем нужны ГОСТы и как их применят, встречается на многих предприятиях, сплошь и рядом. Да, были и компании, в которых понимали, чем “Описание программы” отличается от “Описания применения”, но таких было явное меньшинство. В интернете вообще господствует точка зрения, что ГОСТы для программистов - это явный рудимент, и нужны только если “нагибают” под них. Эскизный проект считают “сравнительно честным способом отъемы лишних дензнаков у заказчика”. Вникнуть и разобраться пришлось относительно недавно - в процессе разработки системы управления требованиями, заточенной под отечественную специфику. Документацию которая, разумеется, должна генерировать “по ГОСТу”.

Здесь я хочу сосредоточиться только на одной теме, с которой приходиться иметь дело программисту в отечественных предприятиях, особенно в НИИ - на наборе стандартов ЕСПД. Не считаю себя большим знатоком ЕСПД - есть люди, которые десятки лет по нему работают, и наверняка меня поправят. Статья скорее пытается набросать контуры «дорожной карты» для тех, кто только входит в курс дела.

Стандарты

Рассмотрим кратко, какие бывают стандарты (фокусируясь на ИТ-области).

1. международные. Отличительный признак - принят международной организацией. Пример такой организации - ISO (международная организация стандартизации). Пример её стандарта: ISO 2382-12:1988 (Переферийное оборудование). Распространены совместные стандарты ISO и международной электротехнической комиссии(IEC, в по русски - МЭК): например, ISO/IEC 12207:2008 (жизненный цикл ПО);
2. региональные. Отличительный признак - принят региональной комиссией по стандартизации. К примеру, многие советские ГОСТы сейчас являются региональным стандартом, т.к. приняты межгосударственным советом, куда входят некоторые бывшие советские республики. Этим советом принимаются и новые стандарты - и они тоже получают обозначение ГОСТ. Пример: ГОСТ 12.4.240-2013;
3. стандарты общественных объединений; К примеру, той же МЭК: IEC 60255;
4. национальные стандарты. Для России в начале таких стандартов - “ГОСТ Р”. Могут быть трех типов:
   1. точные копии международных или региональных. Обозначаются неотличимо от “самописных” (национальных, написанных самостоятельно);
   2. копии международных или региональных с дополнениями. Обозначаются добавлением к шифру отечественного стандарта шифра международного, который был взят за основу. Например: ГОСТ Р ИСО/МЭК 12207;
   3. собственно, национальные стандарты. Например, ГОСТ Р 34.11-94.

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

ГОСТ

Итак: стандарты бывают международные, межгосударственные(региональные) и национальные. ГОСТ, как мы выяснили, это региональный стандарт. ГОСТы имеют достаточно запутанную, на мой взгляд, систему обозначений. Полностью она изложена в ГОСТ Р 1.5-2004, я приведу минимум, что бы в ней ориентироваться. Во первых, надо различать обозначение ГОСТа и его классификацию. Обозначение - это, грубо говоря, уникальный идентификатор стандарта. Код по классификатору - это вспомогательный код, помогающий найти стандарт или определить, к какой области знаний он относиться. Классификаторов может быть много, в основном используются два: КГС (классификатор государственных стандартов) и его наследник ОКС (общероссийский классификатор стандартов). Например: “ГОСТ Р 50628-2000“ - это обозначение стандарта.По обозначению понятно только то, что он принят в 2000 году. Он имеет код по ОКС “33.100;35.160”: т.е. “33” - раздел “Телекоммуникации, аудио, видео”, “100” - подраздел “электромагнитная совместимость”. Однако он также входит в ветвь классификатора 35.160. “35” - “Информационные технологии. Машины конторские”, “160” - “Микропроцессорные системы....”. А по КГС он имеет код “Э02”, что означает “Э” - “Электронная техника, радиоэлектроника и связь”, “0” - “Общие правила и нормы по электронной технике, радиоэлектронике и связи”, и т.д.

Если известно обозначение стандарта, то получить его коды по КГС и ОКС можно, к примеру, на вот этом толковом сайте .
Итак, вернемся к обозначениям ГОСТов. Их может быть два варианта:

1. стандарт относиться к серии стандартов. В этом случае после индекса категории стандарта (например, ГОСТ, ГОСТ Р или ГОСТ РВ) идет код серии, точка и обозначение стандарта внутри серии. Правила обозначения стандартов внутри серии устанавливаются правилами серии. Например: ГОСТ РВ 15.201-2000, ГОСТ Р 22.8.0-99, ГОСТ 19.101-77;
2. стандарт не относиться к серии стандартов. Тогда после индекса категории идет просто порядковый номер стандарта, тире и год принятия. Например, ГОСТ Р 50628-2000.

Итак, если совсем просто - то обозначение ГОСТа - это либо просто порядковый номер, тире, год, либо номер серии, точка и дальше в зависимости от серии. В реальности все сложнее (к примеру, можно встретить что то типа ГОСТ 11326.19-79, и это будет вовсе не серия 11326 - но программистам такое нужно очень редко. За подробностями - в ГОСТ Р 1.5-2004).

ЕСПД

ЕСПД - одна из таких серий ГОСТов, номер 19. Т.е. все стандарты, относящиеся к ЕСПД, начинаются с префикса “19.”: например, ГОСТ 19.106-78. Расшифровывается как “Единая система программной документации”. Существуют и другие серии:

• ГОСТ ЕСКД (единая система конструкторской документации, префикс “2.”);
• ГОСТ ЕСТД (единая система технологической документации, префикс “3.”);
• ГОСТ Р, Система разработки и постановки продукции на производство, префикс “15.”;
• ГОСТ РВ, Вооружение и военная техника. Система разработки и постановки продукции на производство, префикс “15.”;
• ГОСТ, Система технической документации на АСУ, префикс “24.”;
• ГОСТ, Комплекс стандартов на автоматизированные системы, префикс “34.”.

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

19.001-77. Общие положения

Описывает правила присвоения обозначений стандартов в серии ЕСПД. В практической жизни не нужен.

19.102-80. Схемы алгоритмов и программ. Правила выполнения.

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

19.003-80. Схемы алгоритмов и программ. Обозначения условные графические

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

19.004-80. Термины и определения.

Скудный глоссарий. Из интересного - содержит формальные определения программного и эксплуатационного документов.

19.005-85. Р-схемы алгоритмов и программ

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

19.101-77. Виды программ и программных документов

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

19.102-77. Стадии разработки

Важный и нужный стандарт, в котором описаны виды документов и приведены коды видов программных документов. Этот стандарт (совместно с 19.103-77) является одним из ключей к “разгадке” обозначений документов подобных АБВГ.10473-01 32 01-1.
В стандарте вводится понятие комплекса и компонента (на ряде предприятий добавляют третий вид - комплект, когда речь идет о несвязанных программных элементах), дается разделение: какие документы эксплуатационные, какие нет.
Следует аккуратно относиться к таблице 4, в которой показано, какой документ на какой стадии разработки выполняется. Стадии разработки обычно регламентируются в стандартах на выполнения ОКР, и там-же указывается, какие документы нужно предъявлять заказчику на каждом этапе.

19.102-77. Стадии разработки

На моей памяти этот стандарт не применялся ни разу: кто что делает на каком этапе и чем отчитывается прописывается в ТТЗ или делается отсылка к ГОСТам, где это прописано более четко (например, ГОСТ РВ 15.203). При этом для новичка он содержит неплохой в своей лаконичности конспект работ на основных этапах ОКР.

19.103-77. Обозначения программ и программных документов

Нужен, в основном, для того, что бы научиться читать обозначения документов подобных приведенному выше. Однако понимание схемы обозначений полезно в случае, когда приходиться выходить за рамки типовых работ: к примеру, помнить, что документы с кодами после 90 - пользовательские, т.е. любые. В моей практике мы выпускали документ 93, который назвали “Ведомость программной документации”, 96 документ - “Инструкция по сборке”.
Распространенное словосочетание “вариант исполнения” в ЕСПД отсутствует, и заменяется “номером редакции”. С одной стороны, это не совсем корректно: номер редакции задумывался для отслеживания эволюции программы: вначале выходит первая редакция, потом, к примеру, после доработки - вторая. Но на практике, когда нужно выпустить версию ПО для нескольких операционных систем (кросс-платформенное ПО), другого выхода нет. Точнее - есть, но неправильный: присвоить версии для каждой операционки свое обозначение - и закладывать в архив несколько дисков с исходниками (по числу операционок), разрабатывать (фактически - копировать) весь комплект документации и т.д… Т.е. чистой воды бестолковая и сбивающая с толку деятельность. Решение в виде присвоения версии под каждую операционку своего номера редакции позволяет часть документов сделать общими.
В ЕСПД используется смущающее многих программистов обозначение исходных текстов программы и результата сборки “документами”. Документ “текст программы”, согласно 19.101-77, имеет обозначение 12. Дальше принято, что исходники обозначаются как 12 01 - т.е. 01(первый) документ вида 12, а бинарники - как 12 02 - т.е. второй документ вида 12. В ряде случаев для сборки программы требуются дополнительные инструментальные средства - компиляторы, генераторы инсталляторов и т.д. Т.е. программы, которые не входят в поставку, но нужны для сборки. Решением может быть их обозначение как 12 03 - т.е. третий документ вида 12.

19.104-78. Основные надписи

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

• как было уже сказано, часто предприятие не хочет раскрывать информацию о разработчике. Отделение ЛУ и его “зажатие” позволяет это сделать (штампа, в отличии от ЕСКД, в ЕСПД на листах документа нет, вся информация локализована только в ЛУ);
• на ряде предприятий используется смешанный документооборот: подлинники документов хранятся в электронном виде в архиве предприятия, а ЛУ на них (с оригиналами подписей) - в бумажном;

Что касается оформления ЛУ, то сплошь и рядом на предприятиях используется смесь - часть надписей ЛУ оформляется по ЕСПД, часть - по ЕСКД, а часть - по своему. Поэтому лучше всего прежде, чем делать ЛУ самому, поискать, нет ли стандарта предприятия (СТО), или взять пример у местного нормоконтроля.
Также следует помнить, что ЛУ не нумеруется, и первый лист - титульный, а первый лист, на котором ставится номер - следующий за титульным. Но в том случае, если ЛУ больше одного (это бывает, если все подписи не влезли на лист), то ЛУ нумеруются отдельно.

19.105-78. Общие требования к программным документам

Вводится общая структура документа, не зависящая от способа его исполнения. Т.е. еще в 1978 году было заложено в стандарт, что документ может быть не обязательно бумажным. В частности, вводиться понятие содержания для полностью электронных документов. Для бумажного исполнения, распространенного в то время, был принят ГОСТ 19.106-78.
В настоящее время к этому стандарту приходиться обращаться очень редко: разве что забывается порядок следования основных частей документа.

19.106-78. Общие требования к программным документам, выполненным печатным способом

Самый объемный стандарт из ЕСПД, уступающий разве что описанию R-схем. Является основным рабочим стандартом при оформлении документации. Вводит правила оформления текста, элементов структуры документа, изображений, формул и т.д. Однако в отличии от соответствующего 2.106 из ЕСКД, 19.106 существенно менее подробный, что приводит к многочисленным неопределенностям.
Во первых, стандарт фактически не определяет межстрочное расстояние и величину вертикальных отступов между заголовками. Он вводит три правила определения интервала: для машинописного текста, машинного и типографского.
Машинописный текст - это текст, набранный на печатной машинке. Смещение следующей строки относительно предыдущей производилось автоматически при так называемом «переводе каретки» - переходе к печати следующей строки, производимым перемещением специального рычага. Как правило, интервал мог быть вручную скорректирован поворотом вала протяжки бумаги, и имел “настройку”, позволяющую задать величину интервала - одинарный или двойной.
Машинный - это, скорее всего, и есть распечатанный текст. Но для него есть только указание, что результат должен быть пригоден для микрофильмирования. Это неявная ссылка на 13.1.002-2003, в котором, к сожалению, задается межстрочный интервал (и, кстати, минимальная высота шрифта) только для рукописных документов (п.4.2.5).
Типографский - текст, набранный в типографии. Учитывая год принятия стандарта, скорее всего речь идет о
[высокой печати , где межстрочный интервал определялся используемыми литерами. Я не специалист в типографском деле, а информации о методах набора сейчас очень мало.
Какой интервал использовать в итоге часто определяется местным нормоконтролем или СТО. Типичные значения - полуторный интервал и 14 размер шрифта.
Часто вызывает много вопросов способ структурирования документа. 19.106 считает, что весь документ делится на разделы, подразделы, пункты и подпункты. У всех них (кроме раздела и подраздела) заголовок может быть и или не быть. При этом:

• “в содержание документа включают номер разделов, подразделов, пунктов и подпунктов, имеющих заголовок” (п. 2.1.4). Это прямое указание на то, что подпункт может иметь заголовок и включаться в оглавление;
• “допускается помещать текст между заголовками раздела и подраздела, между заголовками подраздела и пункта”. Важно обратить внимание, что ненумерованный текст может быть только между заголовками, и только на верхних 2х уровнях.

В отличии от ЕСКД, в ЕСПД принят странный способ оформления рисунков: сначала идет название рисунка, потом сам рисунок, потом опциональный “подрисуночный текст”, и потом, на новой строке, “Рис. N”.
Этот стандарт имеет ряд “дыр”, недостказанностей. К примеру, сказано: “иллюстрации, если их в данном документе более одной, нумеруют арабскими цифрами в пределах всего документа. “ Но если иллюстрация одна, то она ненумерованная, и как тогда на нее ссылаться? Аналогично и для таблиц. Для сносок ГОСТ не указывает способ их нумерации - в пределах всего документа или в пределах страницы.
Таблицы. В самом документе дана ссылка на ГОСТ 1.5.68. Судя по первой серии, несложно заключить, что это стандарт на разработку стандартов. Причем тут он, неясно. По смыслу он соответствует правилам оформления таблиц в ЕСКД, с небольшими исключениями. Этот стандарт был отменен, взамен веден, через несколько итераций, 1.5-2012, в котором правила оформления таблицы… просто исчезли. Еще в 1.5-2002 были, а уже в 1.5-2004 исчезли. В реальной жизни мы оформляем таблицы согласно ЕСКД.
Приложения. Стандарт не указывает, попадают ли рисунки, формулы и таблицы из приложений в общий перечень. Аналогично не сказано, нужно ли в оглавлении раскрывать структуру приложения, если оно содержит свои разделы, пункты и т.д. В нашей практике мы не раскрываем внутренности приложений.
Наконец, следует сказать об отступах. Абзацный отступ, равный 5 символам, является общим для:

• красной строки;
• отступа элемента структуры документа после раздела (подраздел, пункт, подпункт);
• элемент перечисления.

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

В следующих частях планирую уже добраться до конца списка стандартов ЕСПД.

Г О С У Д А Р С Т В Е Н Н Ы Й С Т А Н Д А Р Т С О Ю З А С С Р

Единая система программной документации	ГОСТ 19.101-77 (СТ СЭВ 1626-79)
ВИДЫ ПРОГРАММ И ПРОГРАММНЫХ ДОКУМЕНТОВ
United system for program documentation. Types of programs and program documents

Дата введения с 01.01.80

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

Стандарт полностью соответствует СТ СЭВ 1626-79.

1. ВИДЫ ПРОГРАММ

1.1. Программу (по ГОСТ 19781-90) допускается идентифицировать и применять самостоятельно и (или) в составе других программ.

1.2. Программы подразделяют на виды, приведенные в табл. 1

Таблица 1

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

1.2,1.3.

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

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

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

Таблица 2

Вид программного документа	Содержание программного документа
Спецификация	Состав программы и документации на нее
	Перечень предприятий, на которых хранят подлинники программных документов
Текст программы	Запись программы с необходимыми комментариями
Описание программы	Сведения о логической структуре и функционировании программы
	Требования, подлежащие проверке при испытании программы, а также порядок и методы их контроля
Техническое задание	Назначение и область применения программы, технические, технико-экономические и специальные требования, предъявляемые к программе, необходимые стадии и сроки разработки, виды испытаний
Пояснительная записка	Схема алгоритма, общее описание алгоритма и (или) функционирования программы, а также обоснование принятых технических и технико-экономических решений
Эксплуатационные документы	Сведения для обеспечения функционирования и эксплуатации программы

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

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

Таблица 3

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

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

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

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

Таблица 4

Код вида документа	Вид документа	Стадии разработки
		Эскизный проект	Технический проект	Рабочий проект
				компонент	комплекс
-	Спецификация	-	-
05	Ведомость держателей подлинников	-	-	-
12	Текст программы	-	-
13	Описание программы	-	-
20	Ведомость эксплуатационных документов	-	-
30	Формуляр	-	-
31	Описание применения	-	-
32	Руководство системного программиста	-	-
33	Руководство программиста	-	-
34	Руководство оператора	-	-
35	Описание языка	-	-
46	Руководство по техническому обслуживанию	-	-
51	Программа и методика испытаний	-	-
81	Пояснительная записка			-	-
90-99	Прочие документы

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

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

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

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

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

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

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

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

Переиздание (Ноябрь 1987 г.) с Изменением № 1, утвержденным в июне 1981 г (ИУС 9-81)