Документы на программное обеспечение гост. Гост стандарт документирования программного обеспечения. Общая характеристика состояния
Единая система документации программной продукции – ЕСПД – относится к ГОСТ класса 19 и подразделяется на 10 групп:
1. Основополагающие стандарты.
2. Правила выполнения документации разработки.
3. Правила выполнения документации изготовления.
4. Правила выполнения документации сопровождения.
5. Правила выполнения эксплуатационной документации.
6. Правила обращения программной документации.
Стандарт с номером 0 содержит общие положения, стандарты 7 и 8 являются зарезервированными и к номеру 9 относятся прочие стандарты, не вошедшие в первые 6.
Это краткие описания ГОСТов класса 19, для более подробного ознакомления с ними необходимо обратиться к справочникам.
- ГОСТ 19.001-77 – единая система программной документации.
- ГОСТ 19.101-77 – виды программ и программных документов.
- ГОСТ 19.102-77 – стадии разработки программ и программной документации.
- ГОСТ 19.105-78 – требования к оформлению программных документов, комплексов и систем независимо от их назначения и области применения. ГОСТ 19.105-78 содержит полный перечень документации, которая должна сопровождать законченный программный продукт.
Перечень документации, декларируемой ГОСТ 19.105-78:
1. Документы, содержащие сведения, необходимые для разработки программного продукта, его изготовления.
1.1. Спецификация – состав программы и документации на нее.
1.2. Ведомость держателей подлинников – перечень предприятий, на которых хранятся подлинники программной документации.
1.3. Текст программы – запись текста программы с необходимыми комментариями.
1.4. Описание программы – сведения о логической и функциональной структуре программы.
1.5. Программа и методика испытаний – требования, подлежащие проверке при испытании программы, порядок и методы их контроля.
1.6. Техническое задание – назначение и область применения программы, технические и специальные требования, необходимые стадии и сроки разработки, виды испытаний.
2. Документы, используемые при эксплуатации программного продукта.
Ведомость эксплуатационных документов – перечень эксплуатационных документов на программу.
Формуляр – основные характеристики программы, комплектность, общие сведения об эксплуатации программы.
Описание применения – сведения о назначении программы, области применения, классе решаемых задач, ограничения на применение, необходимая конфигурация технических средств.
Руководство системного программиста – сведения для проверки и обеспечения функциональности, настройки программы.
Руководство программиста – сведения для эксплуатации настроенной программы.
Руководство оператора – сведения для обеспечения процедуры общения оператора с ЭВМ в процессе выполнения программы.
Описание языка – описание синтаксиса и семантики языка, используемого в программе.
Руководство по техническому обслуживанию – сведения для применения тестовых программ при обслуживании технических средств.
Другие ГОСТы класса 19:
- ГОСТ 19.201-78 – порядок построения и оформления технического задания на разработку программы или программного изделия.
- ГОСТ 19.202-78 – форма и порядок составления спецификации на программные продукты, определяемые в ГОСТ 19.101-77.
- ГОСТ 19.301-79 – программа и методика испытаний программных продуктов.
- ГОСТ 19.401-78 – порядок построения и оформления текста программы при разработке программных продуктов.
- ГОСТ 19.402-78 – описание программы.
- ГОСТ 19.403-79 – форма заполнения и содержание ведомости держателей подлинников, определяемой в ГОСТ 19.105-78.
- ГОСТ 19.404-79 – форма заполнения и содержание пояснительной записки, определяемой в ГОСТ 19.105-78.
- ГОСТ 19.501-78 – форма заполнения и содержание формуляра на программный продукт, определяемый в ГОСТ 19.105-78.
- ГОСТ 19.502-78 – форма заполнения и содержание описания применения, определяемого в ГОСТ 19.105-78.
- ГОСТ 19.503-79 – форма заполнения и содержание руководства системного программиста, определяемого в ГОСТ 19.105-78.
- ГОСТ 19.504-79 – форма заполнения и содержание руководства программиста, определяемого в ГОСТ 19.105-78.
- ГОСТ 19.505-79 – форма заполнения и содержание руководства оператора, определяемого в ГОСТ 19.105-78.
- ГОСТ 19.506-79 – форма заполнения и содержание описания языка, определяемого в ГОСТ 19.105-78.
- ГОСТ 19.507-79 – форма заполнения и содержание ведомости эксплуатационных документов, определяемой в ГОСТ 19.105-78.
- ГОСТ 19.508-79 – форма заполнения и содержание руководства по техническому обслуживанию, определяемому в ГОСТ 19.105-78.
- ГОСТ 19.701-90 – схемы алгоритмов, программ, данных и систем.
В свое время, когда я только начинал работать программистом, часто приходилось слышать “напиши, пожалуйста, документацию к своей программе”. Я честно все описывал, отдавал начальнику, после чего начинался сеанс черной магии. Начальник через некоторое время меня вызывал и начинал мычать нечленораздельные звуки, мять распечатку моего “самого лучшего” текста в руках, бегая глазами. Общий смысл его мычания заключался в том, что получилось “не то”, “не так”, и “посмотри, как делают другие”. Так как никакого другого ответа из него вытянуть было невозможно, я шел за примерами документов к “другим”. Как правило, это были веселые ребята, смысл речей которых заключался в том, что “вот примеры”, “вообще то по ГОСТу” и “это все никому не нужно”. Так я узнал впервые, что программист может соприкоснуться со страшными ГОСТами.
Поразительно, что среди многих десятков моих коллег, очень неглупых программистов, не было никого, кто бы относился к ГОСТам по другому. Даже те несколько человек, которые их знали и, вроде как, даже умели оформлять документы, относились к ним презрительно-формально. Ситуация, когда даже люди, ответственные за управление разработкой не понимают, зачем нужны ГОСТы и как их применят, встречается на многих предприятиях, сплошь и рядом. Да, были и компании, в которых понимали, чем “Описание программы” отличается от “Описания применения”, но таких было явное меньшинство. В интернете вообще господствует точка зрения, что ГОСТы для программистов - это явный рудимент, и нужны только если “нагибают” под них. Эскизный проект считают “сравнительно честным способом отъемы лишних дензнаков у заказчика”. Вникнуть и разобраться пришлось относительно недавно - в процессе разработки системы управления требованиями, заточенной под отечественную специфику. Документацию которая, разумеется, должна генерировать “по ГОСТу”.
Здесь я хочу сосредоточиться только на одной теме, с которой приходиться иметь дело программисту в отечественных предприятиях, особенно в НИИ - на наборе стандартов ЕСПД. Не считаю себя большим знатоком ЕСПД - есть люди, которые десятки лет по нему работают, и наверняка меня поправят. Статья скорее пытается набросать контуры «дорожной карты» для тех, кто только входит в курс дела.
Стандарты
Рассмотрим кратко, какие бывают стандарты (фокусируясь на ИТ-области).- международные. Отличительный признак - принят международной организацией. Пример такой организации - ISO (международная организация стандартизации). Пример её стандарта: ISO 2382-12:1988 (Переферийное оборудование). Распространены совместные стандарты ISO и международной электротехнической комиссии(IEC, в по русски - МЭК): например, ISO/IEC 12207:2008 (жизненный цикл ПО);
- региональные. Отличительный признак - принят региональной комиссией по стандартизации. К примеру, многие советские ГОСТы сейчас являются региональным стандартом, т.к. приняты межгосударственным советом, куда входят некоторые бывшие советские республики. Этим советом принимаются и новые стандарты - и они тоже получают обозначение ГОСТ. Пример: ГОСТ 12.4.240-2013;
- стандарты общественных объединений; К примеру, той же МЭК: IEC 60255;
- национальные стандарты. Для России в начале таких стандартов - “ГОСТ Р”. Могут быть трех типов:
- точные копии международных или региональных. Обозначаются неотличимо от “самописных” (национальных, написанных самостоятельно);
- копии международных или региональных с дополнениями. Обозначаются добавлением к шифру отечественного стандарта шифра международного, который был взят за основу. Например: ГОСТ Р ИСО/МЭК 12207;
- собственно, национальные стандарты. Например, ГОСТ Р 34.11-94.
Системы обозначений на каждом уровне и в каждой организации свои, для каждого случая придется разбираться отдельно. Чтобы быстро понять, “чей” стандарт перед глазами, можно использовать шпаргалку .
ГОСТ
Итак: стандарты бывают международные, межгосударственные(региональные) и национальные. ГОСТ, как мы выяснили, это региональный стандарт. ГОСТы имеют достаточно запутанную, на мой взгляд, систему обозначений. Полностью она изложена в ГОСТ Р 1.5-2004, я приведу минимум, что бы в ней ориентироваться. Во первых, надо различать обозначение ГОСТа и его классификацию. Обозначение - это, грубо говоря, уникальный идентификатор стандарта. Код по классификатору - это вспомогательный код, помогающий найти стандарт или определить, к какой области знаний он относиться. Классификаторов может быть много, в основном используются два: КГС (классификатор государственных стандартов) и его наследник ОКС (общероссийский классификатор стандартов). Например: “ГОСТ Р 50628-2000“ - это обозначение стандарта.По обозначению понятно только то, что он принят в 2000 году. Он имеет код по ОКС “33.100;35.160”: т.е. “33” - раздел “Телекоммуникации, аудио, видео”, “100” - подраздел “электромагнитная совместимость”. Однако он также входит в ветвь классификатора 35.160. “35” - “Информационные технологии. Машины конторские”, “160” - “Микропроцессорные системы....”. А по КГС он имеет код “Э02”, что означает “Э” - “Электронная техника, радиоэлектроника и связь”, “0” - “Общие правила и нормы по электронной технике, радиоэлектронике и связи”, и т.д.Если известно обозначение стандарта, то получить его коды по КГС и ОКС можно, к примеру, на вот этом толковом сайте .
Итак, вернемся к обозначениям ГОСТов. Их может быть два варианта:
- стандарт относиться к серии стандартов. В этом случае после индекса категории стандарта (например, ГОСТ, ГОСТ Р или ГОСТ РВ) идет код серии, точка и обозначение стандарта внутри серии. Правила обозначения стандартов внутри серии устанавливаются правилами серии. Например: ГОСТ РВ 15.201-2000, ГОСТ Р 22.8.0-99, ГОСТ 19.101-77;
- стандарт не относиться к серии стандартов. Тогда после индекса категории идет просто порядковый номер стандарта, тире и год принятия. Например, ГОСТ Р 50628-2000.
ЕСПД
ЕСПД - одна из таких серий ГОСТов, номер 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х уровнях.
Этот стандарт имеет ряд “дыр”, недостказанностей. К примеру, сказано: “иллюстрации, если их в данном документе более одной, нумеруют арабскими цифрами в пределах всего документа. “ Но если иллюстрация одна, то она ненумерованная, и как тогда на нее ссылаться? Аналогично и для таблиц. Для сносок ГОСТ не указывает способ их нумерации - в пределах всего документа или в пределах страницы.
Таблицы. В самом документе дана ссылка на ГОСТ 1.5.68. Судя по первой серии, несложно заключить, что это стандарт на разработку стандартов. Причем тут он, неясно. По смыслу он соответствует правилам оформления таблиц в ЕСКД, с небольшими исключениями. Этот стандарт был отменен, взамен веден, через несколько итераций, 1.5-2012, в котором правила оформления таблицы… просто исчезли. Еще в 1.5-2002 были, а уже в 1.5-2004 исчезли. В реальной жизни мы оформляем таблицы согласно ЕСКД.
Приложения. Стандарт не указывает, попадают ли рисунки, формулы и таблицы из приложений в общий перечень. Аналогично не сказано, нужно ли в оглавлении раскрывать структуру приложения, если оно содержит свои разделы, пункты и т.д. В нашей практике мы не раскрываем внутренности приложений.
Наконец, следует сказать об отступах. Абзацный отступ, равный 5 символам, является общим для:
- красной строки;
- отступа элемента структуры документа после раздела (подраздел, пункт, подпункт);
- элемент перечисления.
При этом текст, расположенный на следующей строку после строки с отступом, выравнивается уже по левому полю. Часто встречаются ошибки, когда отступ скачет - красная строка - одно значение, номер пункта - нас другим интервалом, в вложенные отступы в списках - так вообще обязательно.
В следующих частях планирую уже добраться до конца списка стандартов ЕСПД.
Программы для ЭВМ оформляются в соответствии с требованиями Единой системы программной документации (ЕСПД) . ЕСПД - набор ГОСТов, устанавливающих правила оформления, содержание, структуру программных документов.
Данный 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 см, проведённой в левой части страницы.
- Иллюстрации, если их в данном документе более одной, нумеруют арабскими цифрами в пределах всего документа.
- Формулы в документе, если их более одной, нумеруются арабскими цифрами, номер ставят с правой стороны страницы, в скобках на уровне формулы.
- Значение символов и числовых коэффициентов, входящих в формулу, должны быть приведены непосредственно под формулой. Значение каждого символа печатают с новой строки в той последовательности, в какой они приведены в формуле. Первая строка расшифровки должна начинаться со слова «где», без двоеточия после него.
- В программных документах допускаются ссылки на стандарты (кроме стандартов предприятий), технические условия и другие документы (например, документы органов Государственного надзора, правила и нормы Госстроя СССР). При ссылках на стандарты и технические условия указывают их обозначение.
- Ссылаться следует на документ в целом или на его разделы (с указанием обозначения и наименования документа, номера и наименования раздела или приложения). При повторных ссылках на раздел или приложение указывают только номер.
- В примечаниях к тексту и таблицам указывают только справочные и пояснительные данные.
- Одно примечание не нумеруется. После слова «Примечание» ставят точку.
- Несколько примечаний следует нумеровать по порядку арабскими цифрами с точкой. После слова «Примечание» ставят двоеточие.
- Сокращения слов в тексте и надписях под иллюстрациями не допускаются.
- Иллюстрированный материал, таблицы или текст вспомогательного характера допускается оформлять в виде приложений.
- Каждое приложение должно начинаться с новой страницы с указанием в правом верхнем углу слова «ПРИЛОЖЕНИЕ» и иметь тематический заголовок, который записывают симметрично тексту прописными буквами.
В ГОСТе присутствует образец листа, где указаны поля, места для нумерации страниц и шифра.
ГОСТ 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
Г О С У Д А Р С Т В Е Н Н Ы Й С Т А Н Д А Р Т С О Ю З А С С Р
|
Единая система программной документации |
ГОСТ 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)
