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

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

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

Стандарты

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

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.003-80 Взамен ГОСТ 19428-74
СХЕМЫ АЛГОРИТМОВ И ПРОГРАММ.ОБОЗНАЧЕНИЕ УСЛОВНЫЕ ГРАФИЧЕСКИЕ
United system for program documentation. Graphical flowchart symbols.

Постановлением Государственного комитета СССР по стандартам от 24 апреля 1980 г. ¹ 1867 срок введения установлен

с 01.07 1981 г.

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

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

Стандарт устанавливает перечень, наименование, форму, размеры символов и отображаемые символами функции.

Стандарт соответствует МС ИСО 1028-73 в части обозначений символов

1. ПЕРЕЧЕНЬ, НАИМЕНОВАНИЕ, ОБОЗНАЧЕНИЕ СИМВОЛОВ И ОТОБРАЖАЕМЫЕ ИМИ ФУНКЦИИ

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

Таблица 1.

Наименование	Обозначение и размеры в мм	Функция
1. Процесс		Выполнение операций или группы операций, в результате которых изменяется значение, форма представления или расположение данных
2. Решение		Выбор направления выполнения алгоритма или программы в зависимости от некоторых переменных условий
3. Модификация		Выполнение операций, меняющих команды или группу команд, изменяющих программу
4. Предопределенный процесс		Использование ранее созданных и отдельно описанных алгоритмов или программ
5. Ручная операция		Автономный процесс, выполняемый вручную или при помощи неавтоматически действующих средств
6. Вспомогательная операция		Автономный процесс, выполняемый устройством, не управляемым непосредственно процессором
7. Слияние		Объединение двух или более множеств в единое множество
8. Выделение		Удаление одного или нескольких множеств из единого множества
9. Группировка		Объединение двух или более множеств с выделением нескольких других множеств
10. Сортировка		Упорядочение множества по заданным признакам
11. Ручной ввод		Ввод данных вручную при помощи неавтономных устройств с клавиатурой, набором переключателей, кнопок
12. Ввод-вывод		Преобразование данных в форму, пригодную для обработки (ввод) или отображения результатов обработки (вывод)
13. Неавтономная память		Ввод-вывод данных в случае использования запоминающего устройства, управляемого непосредственно процессором
14. Автономная память		Ввод-вывод данных в случае использования запоминающего устройства, не управляемого непосредственно процессором
15. Документ		Ввод-вывод данных, носителем которых служит бумага
16. Перфокарта		Ввод-вывод данных, носителем которых служит перфокарта
17. Колода перфокарт		Отображение набора перфокарт
18. Файл		Представление организованных на основе общих признаков данных, характеризующих в совокупности некоторый объект обработки данных. Символ используется в сочетании с символами конкретных носителей данных, выполняющих функции ввода-вывода
19. Перфолента		Ввод-вывод данных, носителем которых служит перфолента
20. Магнитная лента		Ввод-вывод данных, носителем которых служит магнитная лента
21. Магнитный барабан		Ввод-вывод данных, носителем которых служит магнитный барабан
22. Магнитный диск		Ввод-вывод данных, носителем которых служит магнитный диск
23. Оперативная память		Ввод-вывод данных, носителем которых служит магнитный сердечник
24. Дисплей		Ввод-вывод данных, если непосредственно подключенное к процессу устройство воспроизводит данные и позволяет оператору ЭВМ вносить изменения в процессе их обработки
25. Канал связи		Передача данных по каналам связи
26. Линия потока		Указание последовательности между символами
27. Параллельные действия		Начало или окончание двух и более одновременно выполняемых операций
28. Соединитель		Указание связи между прерванными линиями потока, связывающими символами
29. Пуск – останов		Начало, конец, прерывание процесса обработки данных или выполнения программы
30. Комментарий		Связь между элементом схемы и пояснением

1.2. Перечень, наименование, обозначение и размеры рекомендуемых символов и отображаемые ими функции в алгоритме и программе обработки данных должны соответствовать указанным в табл. 2.

Таблица 2

Наименование	Обозначение и размеры в мм	Функция
1. Межстраничный соединитель		Указание связи между разъединенными частями схем алгоритмов и программ, расположенных на разных листах
2. Магнитная карта		Ввод-вывод данных, носителем которых служит магнитная карта
3. Ручной документ		Формирование документа в результате выполнения ручных операций
4. Архив		Хранение комплекта упорядоченных носителей данных в целях повторного применения
5. Автономная обработка		Преобразование исходных данных в результате выполнения автономных операций
6. Расшифровка		Считывание с носителя данных, перекодирование и печать на том же или другом носителе данных в результате выполнения автономной операции
7. Кодирование		Нанесение кодированной информации на носитель в результате выполнения автономной операции
8. Копирование

Программы для ЭВМ оформляются в соответствии с требованиями Единой системы программной документации (ЕСПД) . ЕСПД - набор ГОСТов, устанавливающих правила оформления, содержание, структуру программных документов.
Данный how-to содержит выдержки из ЕСПД. Полные сведения можно получить непосредственно из ГОСТов.

Краткий алгоритм оформления программы

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

Оформление программного документа

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

Каждый отдельный программный документ оформляется по (общим для всех докуметнов ЕСПД) требованиям ГОСТ 19.101-77 , ГОСТ 19.103-77 , ГОСТ 19.104-78 , ГОСТ 19.105-78 , ГОСТ 19.106-78 , ГОСТ 19.604-78 (более подробное описание данных ГОСТов следует ниже) и ГОСТа для конкретного программного документа.

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

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

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

Важно отметить, что данный ГОСТ не распространяется на программный документ "Текст программы".

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

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

В аннотации указывают издание программы, кратко излагают назначение и содержание документа. Если документ состоит из нескольких частей, в аннотации указывают общее количество частей. Содержание документа размещают на отдельной (пронумерованной) странице (страницах) после аннотации, снабжают заголовком «СОДЕРЖАНИЕ», не нумеруют как раздел и включают в общее количество страниц документа.

Форматирование текста:

• Программный документ выполняют на одной стороне листа, через два интервала; допускается через один или полтора интервала.
• Аннотацию размещают на отдельной (пронумерованной) странице с заголовком «АННОТАЦИЯ» и не нумеруют как раздел.
• Заголовки разделов пишут прописными буквами и размещают симметрично относительно правой и левой границ текста.
• Заголовки подразделов записывают с абзаца строчными буквами (кроме первой прописной).
• Переносы слов в заголовках не допускаются. Точку в конце заголовка не ставят.
• Расстояние между заголовком и последующим текстом, а также между заголовками раздела и подраздела должно быть равно:
  • при выполнении документа машинописным способом - двум интервалам.
• Для разделов и подразделов, текст которых записывают на одной странице с текстом предыдущего раздела, расстояние между последней строкой текста и последующим заголовком должно быть равно:
  • при выполнении документа машинописным способом - трём машинописным интервалам.
• Разделы, подразделы, пункты и подпункты следует нумеровать арабскими цифрами с точкой.
• В пределах раздела должна быть сквозная нумерация по всем подразделам, пунктам и подпунктам, входящим в данный раздел.
• Нумерация подразделов включает номер раздела и порядковый номер подраздела, входящего в данный раздел, разделённые точкой (2.1; 3.1 и т. д.).
• При наличии разделов и подразделов к номеру подраздела после точки добавляют порядковый номер пункта и подпункта (3.1.1, 3.1.1.1 и т.д.).
• Текст документа должен быть кратким, четким, исключающим возможность неверного толкования.
• Термины и определения должны быть едиными и соответствовать установленным стандартам, а при их отсутствии - общепринятым в научно-технической литературе, и приводиться в перечне терминов.
• Необходимые пояснения к тексту документа могут оформляться сносками.
• Сноска обозначается цифрой со скобкой, вынесенными на уровень линии верхнего обреза шрифта, например: «печатающее устройство2)...» или «бумага5)».
• Если сноска относится к отдельному слову, знак сноски помещается непосредственно у этого слова, если же к предложению целом, то в конце предложения. Текст сноски располагают в конце страницы и отделяют от основного текста линией длиной 3 см, проведённой в левой части страницы.
• Иллюстрации, если их в данном документе более одной, нумеруют арабскими цифрами в пределах всего документа.
• Формулы в документе, если их более одной, нумеруются арабскими цифрами, номер ставят с правой стороны страницы, в скобках на уровне формулы.
• Значение символов и числовых коэффициентов, входящих в формулу, должны быть приведены непосредственно под формулой. Значение каждого символа печатают с новой строки в той последовательности, в какой они приведены в формуле. Первая строка расшифровки должна начинаться со слова «где», без двоеточия после него.
• В программных документах допускаются ссылки на стандарты (кроме стандартов предприятий), технические условия и другие документы (например, документы органов Государственного надзора, правила и нормы Госстроя СССР). При ссылках на стандарты и технические условия указывают их обозначение.
• Ссылаться следует на документ в целом или на его разделы (с указанием обозначения и наименования документа, номера и наименования раздела или приложения). При повторных ссылках на раздел или приложение указывают только номер.
• В примечаниях к тексту и таблицам указывают только справочные и пояснительные данные.
• Одно примечание не нумеруется. После слова «Примечание» ставят точку.
• Несколько примечаний следует нумеровать по порядку арабскими цифрами с точкой. После слова «Примечание» ставят двоеточие.
• Сокращения слов в тексте и надписях под иллюстрациями не допускаются.
• Иллюстрированный материал, таблицы или текст вспомогательного характера допускается оформлять в виде приложений.
• Каждое приложение должно начинаться с новой страницы с указанием в правом верхнем углу слова «ПРИЛОЖЕНИЕ» и иметь тематический заголовок, который записывают симметрично тексту прописными буквами.

В ГОСТе присутствует образец листа, где указаны поля, места для нумерации страниц и шифра.

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

Эта таблица есть во всех версиях Windows: 10, 8, 7, Vista, XP. И работает она везде одинаково. Подробно для Windows 7 описано .

Как найти Таблицу символов на своем устройстве

Это можно сделать одним из трех вариантов, предложенных ниже:

1) В строке Поиск нужно ввести без кавычек “таблица символов”. В результате поиска должна появиться ссылка на Таблицу символов.

2) Либо в главном меню: Пуск - Программы - Стандартные - Служебные - Таблица символов.

3) Третий вариант для того, чтобы найти таблицу символов. Используем , то есть:

• нажимаем одновременно две клавиши «Win+R».
• Появится окно “Выполнить”, в котором набираем без кавычек «charmap.exe».
• После чего щелкаем “ОК”, и откроется «Таблица символов».

Таблица символов дает возможность посмотреть все символы, которые входят в какой-либо шрифт. Рассмотрим это на конкретном примере.

Таблица символов Windows для шрифта Times New Roman

Для наглядности эта таблица представлена ниже на рисунке:

Рис. 1. Таблица символов Windows для шрифта Times New Roman. Выделен символ “Параграф”. Указаны клавиши для ввода параграфа: Alt+0167

Порядок расположения символов в Таблице символов такой:

• сначала идут знаки препинания,
• затем цифры,
• английские буквы,
• далее языковые.
• И только после всего этого идут символы, которые отсутствуют на клавиатуре, такие как: ⅜, ∆, ™, ₤ и так далее.

Как скопировать символ из Таблицы символов и поместить его туда, где требуется?

Предлагаю для этого два способа:

1. Скопировал (в Таблице символов) - Вставил (там, где требуется).
2. С помощью сочетания клавиш (то есть, используя горячие клавиши).

Первый способ: Скопировал в Таблице - Вставил там, где нужно.

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

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

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

Чтобы скопировать символ в память компьютера, нам надо его выделить. Для этого достаточно кликнуть по необходимому символу (цифра 1 на рис. 2).

Затем щелкаем по кнопке «Выбрать» (2 на рис. 2):

Рис. 2. Кликнуть по необходимому символу и нажать на кнопку “Выбрать”

В итоге символ попадет в строку “Для копирования” (1 на рис. 3). Для того, чтобы символ оказался в буфере обмена, надо кликнуть по кнопке «Копировать» (2 на рис. 3):

Рис. 3. Копируем символ из Таблицы в буфер обмена

Есть и быстрый вариант:

По символу кликнуть два раза мышкой и он будет скопирован в буфер обмена.

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

Для этого надо поставить в приложении (в , текстовом редакторе и т.п.) курсор в нужное место и нажать на две клавиши Ctrl+V (они выполняют команду “Вставить”).

Если не получается с клавишами Ctrl+V, тогда кликаем правой кнопкой мыши там, где должен быть помещен символ. Откроется меню, в котором щелкаем команду “Вставить”. После этого появится скопированный символ.

Заметим, что можно в Таблице символов в строку “Для копирования” поместить сразу несколько символов и одновременно все их скопировать. Тогда произойдет вставка сразу всех скопированных символов туда, где это требуется (в Блокнот, в какое-то приложение и т.п.)

Второй способ: копируем символ с помощью сочетания клавиш

Для каждого символа в Таблице имеется строго свое сочетание клавиш.

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

Например, для знака параграфа § следует нажать сочетание клавиш Alt+0167, при этом можно использовать только цифры с малой цифровой клавиатуры.

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

Упражнение по компьютерной грамотности:

1) Откройте Таблицу символов Windows. Выберите шрифт, которым Вы чаще всего пользуетесь. Найдите два-три символа, которых нет на клавиатуре, выделите и скопируйте их в буфер обмена.

2) Откройте текстовый редактор (например, Блокнот) и вставьте из буфера обмена скопированные туда ранее символы.

Видео “Таблица символов Windows”

Как присвоить документу «код по госту»

Михаил Острогорский , 2010

Зачем нужны обозначения документов

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

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

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

Таким образом, присвоение документам гостированных обозначений сегодня в значительной мере лишено смысла и представляет собой «магический ритуал». Как быть, если заказчик все-таки настаивает на его исполнении? Разумеется, исполнять.

Обозначения документов по автоматизированным системам

Структура обозначения системного документа в соответствии с ГОСТ 34.201-89 показана ниже. Расшифровка частей обозначения приведена в таблице.

A.B.CCC.DD.EE.F-G.M

Часть обозначения	Значение
A	код организации-разработчика системы. В ГОСТ 34.201-89 сказано: «Код организации-разработчика присваивают в соответствии с общесоюзным классификатором предприятий, учреждений и организаций (ОКПО) или по правилам, установленным отраслевыми НТД». По известным причинам общесоюзного классификатора сегодня с нами нет, зато существует Общероссийский классификатор предприятий и организаций (ОКПО). Код ОКПО входит в состав официальных реквизитов организации, и его должны знать у вас в бухгалтерии. Если вам очень не хочется звонить в бухгалтерию, попробуйте найти свою компанию в онлайновом справочнике , но имейте в виду, что надпись на табличке у дверей офиса не всегда совпадает с названием юридического лица. Кроме того, по ГОСТ 2.201-80 организации-разработчику должен быть присвоен четырехбуквенный код для формирования обозначений конструкторских документов. Централизованным присвоением кодов занимаются уполномоченные организации, например, ФГУП «Стандартинформ » и ОАО «Стандартэлектро ». Это реально существующая практика, некоторые компании даже публикуют на своих сайтах свидетелсьтва о присвоении им кода
B	код классификационной характеристики типа системы или ее части. Согласно ГОСТ 34.201-89, этот код следует выбирать из общесоюзного классификатора продукции, на смену которому сегодня пришел Общероссийский классификатор продукции (ОКП) . Он многократно опубликован в Интернете, вы без труда найдете его по приведенной здесь ссылке или с помощью поисковика. В этом классификаторе собрана вся возможная продукция от шагающих экскаваторов до булавок. Раздел классификатора, посвященный автоматизированным системам, начинается строкой 425000 Программно-технические комплексы для автоматизированных систем . Возможно, в классификаторе имеются другие строки, которые вам больше подходят по специфике системы. Попробуйте найти их обычной функцией поиска по тексту страницы. В качестве альтенативы ОКП стандарт предлагает использовать общесоюзный классификатор подсистем и комплексов задач АСУ (ОКПКЗ). Насколько нам известно, он был отменен, но ничем другим не заменен, таким образом, эта ссылка делается достоянием истории
CCC	регистрационный номер автоматизированной системы или ее части. Предполагается, что разработчик организовал у себя учет выпускаемых автоматизированных систем и присваивает им регистрационные номера. Если у вас в компании это не принято, значит, вы не можете полноценно соблюдать требования КСАС. Начните новую жизнь, заведите журнал регистрации выпущенных систем. Нумерация систем ведется по каждому типу (т. е. коду классификационной характеристики, см. выше) систем отдельно. Как быть организации, которая ухитрилась выпустить 1000 однотипных автоматизированных систем, стандарт не говорит
DD	код документа (точнее, типа документа) по ГОСТ 34.201-89 . Например, код руководства пользователя — И3 (и-три), а код программы и методики испытаний — ПМ .
EE	номер документа одного наименования. Допустим, у вас в комплекте документации три технологические инструкции для трех разных функциональных ролей. В этом случае у них будут номера 01, 02 и 03 . Правила назначения этих номеров (по дате выпуска документа, по названиям в алфавитном порядке или как-нибудь иначе) не уточняются. Главное, чтобы номера шли последовательно с единицы. Если в комплект входит только один документ некоторого типа, например, одна пояснительная записка к техническому проекту, номер не присваивают, а соответствующая позиция в обозначении пропускается
F	номер редакции документа. Речь идет о тех редакциях, которые вы официально передаете заказчику, а он их официально принимает и утверждает. Если в процессе рецензирования и согласования документа заказчик многократно присылал вам замечания, а вы ему в ответ исправленный файл, о новых редакциях документа речь не идет, это рабочие материалы и только. Новая редакция возникает в том случае, если заказчик утверждает новый вариант документа, сохраняя при этом предыдущий, и в принципе в каких-нибудь ситуациях может пользоваться ими обоими. В противном случае устаревший вариант можно аннулировать и забыть о нем навсегда. Номера присваивают редакциям, начиная со второй. В первой редакции соответствующая позиция в обозначении пропускается
G	номер части документа. Документ можно физически разделить на несколько частей. Обычно так поступают, чтобы документ было удобнее читать или переплетать. Если документ не разделен на части, номер не присваивают, а соответствующая позиция в обозначении пропускается
M	в 1989 году электронные документы еще были явлением новым и непривычным. Типичный документ представлял собой лист или стопку листов бумаги с согласующими и утверждающими подписями. Тот факт, что дискета или магнитная лента с записанным на ней текстом тоже может быть документом, требовал отдельного осмысления. Поэтому к обозначению таких документов добавляли букву M . Как ни странно, эта практика и теперь не лишена оснований, поскольку у нас в стране в официальном документообороте фигурируют именно бумажные документы с оригинальными подписями компетентных лиц и «мокрыми» печатями организаций. Поэтому, например, технологическая инструкция, за несоблюдение которой сотрудника можно официально наказать, должна быть выполнена именно в таком виде. Но если заказчик требует от нас, допустим, текст программы (документ, предусмотренный ЕСПД), мы все-таки можем предоставить ему не грузовик листингов, а компакт-диск. Обозначение такого документа должно завершаться буквой M, которую отделяют от предыдущей части точкой (а не дефисом!)

В качестве примера присвоим обозначение технологической инструкции для пользователя этого сайта. Сайт будем рассматривать в качестве автоматизированной системы, которую мы разработали сами для себя, причем это был наш первый опыт разработки систем такого типа. Пользователем будем считать сотрудника «Философта», который публикует на сайте статьи. Условимся также, что ответственный за публикацию — не единственная функциональная роль. Еще у нас есть ответственный за размещение рекламных баннеров, для которого написана своя технологическая инструкция. Действует первая редакция технологической инструкции, документ не разделен на части, существует в виде бумажного оригинала с подписями и печатями. С учетом перечисленных обстоятельств обозначение получается таким:

63755082.425750.001.И2.01, где

63755082 — код ООО «Философт» согласно ОКПО.

425750 — код строки Программно-технические комплексы для автоматизации обработки информации в торговле, материально-техническом обеспечении согласно ОКП. Автор статьи полистал ОКП, подумал и решил, что данная характеристика подходит нашему сайту лучше всех остальных там предлагаемых. Возможно, он заблуждается.

001 — регистрационный номер автоматизированной системы этого типа в нашем внутреннем учете (давайте считать, что мы его ведем).

И2 — код технологической инструкции по ГОСТ 34.201-89.

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

Обозначение технического задания на автоматизированную систему

В п. 3.2 ГОСТ 34.602-89 есть фраза, в которой упоминается некий код ТЗ: «Номера листов (страниц) проставляют, начиная с первого листа, следующего за титульным листом, в верхней части листа (над текстом, посередине) после обозначения кода ТЗ на АС». Вместе с тем, в ГОСТ 34.201-89 приведены коды документов, разрабатываемых на стадиях, начиная с эскизного проекта, но кода для ТЗ там нет, что несколько сбивает с толку.

При формировании кода ТЗ на АС можно принять во внимание п. 3.5. ГОСТ 34.602-89, в котором сказано: «При необходимости на титульном листе ТЗ на АС допускается помещать установленные в отрасли коды, например: гриф секретности, код работы, регистрационный номер ТЗ и др.», и присвоить код произвольно, сославшись на то, что так принято в отрасли или определено НТД конкретного предприятия. Кроме того, можно вспомнить, что по ГОСТ 24.101-80 у технического задания был код 2А, и присвоить документу обозначение по схеме, описанной выше. Но в общем это все уже напоминает схоластический подсчет количества чертей на кончике иглы.

Обозначения документов по программам

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

A.B.CCCCC-DD EE FF-G

Часть обозначения	Значение
A	код страны. В наше время разумно указывать двухбуквенный код в соответствии со стандартом ISO 3166-1 : RU для России, KZ для Казахстана и т. д.
B	код организации-разработчика. По аналогии с системными документами можно указывать код ОКПО
CCCCC	регистрационный номер программы. Согласно ГОСТ 19.103-77 , он должен присваиваться «в соответствии с Общесоюзным классификатором программ, утверждаемым Госстандартом в установленном порядке». Как соблюдать это требование сегодня, нам неизвестно. Обратите внимание на год утверждения стандарта: 1977. Многое изменилось с тех пор в нашей жизни
DD	номер редакции документа
EE	код вида документа в соответствии с ГОСТ 19.101-77
FF	номер документа данного вида
G	номер части документа

Начальная часть обозначения, A.B.CCCCC-DD, служит обозначением самой программы и одновременно главного связанного с ней документа, спецификации.

Обозначения конструкторских документов

Любую программу или автоматизированную систему можно рассматривать как изделие и документировать на общих основаниях, руководствуясь ЕСКД (ГОСТ 2) . Этой же серией стандартов следует пользоваться при документировании технических средств , например серверов, рабочих станций, всевозможных специализированных устройств и т. п. Правила присвоения обозначений конструкторским документам устанавливает ГОСТ 2.201-80. Здесь мы воздержимся от пересказа этого документа, но не сомневаемся, что теперь читатель без труда найдет и освоит его.

Обозначения листов утверждения

Если документ снабжен листом утверждения, у последнего должно быть свое обозначение. Оно формируется по элементарному правилу: к обозначению документа следует добавить шифр ЛУ, отделив его дефисом, например: 63755082.425750.001.И2.01-ЛУ.

О пользе обозначений со сдержанным оптимизмом

Внимательный читатель заметил, что если бы все организации аккуратно придерживались таких правил, обозначения документов оказались бы уникальными в пределах страны. Тогда можно было бы, предположим, учредить национальный каталог технической документации, через который любой инженер мог бы запросить нужный ему документ. Наверно это облегчило бы интеграцию автоматизированных систем разных ведомств, а ведь мы сегодня испытываем много всяких бюрократических неудобств именно из-за их изолированности. Например, пенсионеры вынуждены брать в ЗАГСе справку, что они еще живы, и лично доставлять ее в Собес, только тогда им выписывают всякие надбавки и льготы. Спрашивается, почему бы автоматизированным системам ЗАГСа и Собеса не работать с единым массивом данных. С другой стороны, умудренный опытом читатель заметит, что эти рассуждения грешат утопизмом, и будет прав.

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