Опыт применения ЕСПД
Основная задача этого текста — рассказать, что такое Единая система программной документации (ЕСПД) и как эти стандарты применять на практике. Начну с рассказа о том, какие бывают стандарты, и закончу опытом применения каждого из ЕСПДшных стандартов в отдельности.
В свое время, когда я только начинал работать программистом, часто приходилось слышать “напиши, пожалуйста, документацию к своей программе”. Я честно все описывал, отдавал начальнику, после чего начинался сеанс черной магии.
Начальник через некоторое время меня вызывал и начинал мычать нечленораздельные звуки, мять распечатку моего “самого лучшего” текста в руках, бегая глазами. Общий смысл его мычания заключался в том, что получилось “не то”, “не так”, и “посмотри, как делают другие”. Так как никакого другого ответа из него вытянуть было невозможно, я шел за примерами документов к “другим”. Как правило, это были веселые ребята, смысл речей которых заключался в том, что “вот примеры”, “вообще то по ГОСТу” и “это все никому не нужно”. Так я узнал впервые, что программист может соприкоснуться со страшными ГОСТами.
СУДЬБА ЧЕЛОВЕКА — ЭТО ПРОГРАММА | ЖИЗНЬ И ЕЁ СЦЕНАРИЙ | ЛЮДИ ПРЕДЧУВСТВУЮТ КАТАСТРОФЫ
Поразительно, что среди многих десятков моих коллег, очень неглупых программистов, не было никого, кто бы относился к ГОСТам по другому. Даже те несколько человек, которые их знали и, вроде как, даже умели оформлять документы, относились к ним презрительно-формально.
Ситуация, когда даже люди, ответственные за управление разработкой не понимают, зачем нужны ГОСТы и как их применят, встречается на многих предприятиях, сплошь и рядом. Да, были и компании, в которых понимали, чем “Описание программы” отличается от “Описания применения”, но таких было явное меньшинство.
В интернете вообще господствует точка зрения, что ГОСТы для программистов — это явный рудимент, и нужны только если “нагибают” под них. Эскизный проект считают “сравнительно честным способом отъемы лишних дензнаков у заказчика”. Вникнуть и разобраться пришлось относительно недавно — в процессе разработки системы управления требованиями, заточенной под отечественную специфику. Документацию которая, разумеется, должна генерировать “по ГОСТу”.
Здесь я хочу сосредоточиться только на одной теме, с которой приходиться иметь дело программисту в отечественных предприятиях, особенно в НИИ — на наборе стандартов ЕСПД. Не считаю себя большим знатоком ЕСПД — есть люди, которые десятки лет по нему работают, и наверняка меня поправят. Статья скорее пытается набросать контуры «дорожной карты» для тех, кто только входит в курс дела.
Стандарты
- международные. Отличительный признак — принят международной организацией. Пример такой организации — 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.
ЕСПД
- ГОСТ ЕСКД (единая система конструкторской документации, префикс “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. Общие требования к программным документам, выполненным печатным способом
Источник: habr.com
ГОСТ 19.103-77 Единая система программной документации. Обозначения программ и программных документов
Текст ГОСТ 19.103-77 Единая система программной документации. Обозначения программ и программных документов
Единая система программной документации
ОБОЗНАЧЕНИЯ ПРОГРАММ И ПРОГРАММНЫХ ДОКУМЕНТОВ
Unified system for program documentation. Indexing of programs and program documents
Дата введения 1980-01-01
Постановлением Государственного комитета стандартов Совета Министров СССР от 20 мая 1977 г. N 1268 дата введения установлена 01.01.80
ПЕРЕИЗДАНИЕ. Январь 2010 г.
1. Настоящий стандарт устанавливает структуру обозначения программ и программных документов для вычислительных машин, комплексов и систем независимо от их назначения и области применения.
2. Обозначение программ и документов должно состоять из групп знаков, разделенных точками (после кода страны и кода организации-разработчика), пробелами (после номера редакции документа и кода вида документа), дефисами (после регистрационного номера и номера документа данного вида).
3. Устанавливается регистрационная система обозначения программ и программных документов.
Структура обозначения программы и ее программного документа — спецификации:
4. Структура обозначения других программных документов:
5. Код страны-разработчика и код организации (предприятия)-разработчика присваивают в установленном порядке.
Регистрационный номер присваивают в соответствии с Общесоюзным классификатором программ, утверждаемым Госстандартом, в установленном порядке.
До утверждения Общесоюзного классификатора программ* допускается присваивать регистрационный номер в порядке возрастания, начиная с 00001 до 99999, для каждой организации (предприятия)-разработчика.
* Классификатор не утвержден. — .
Номер издания программы или номер редакции документа присваивают в порядке возрастания с 01 до 99.
6. Код вида документа присваивают в соответствии с требованиями ГОСТ 19.101-77.
7. Номер документа данного вида присваивают в порядке возрастания с 01 до 99.
8. Номер части одного и того же документа присваивают в порядке возрастания с 1 до 9.
Примечание. Если документ состоит из одной части, то дефис и порядковый номер части не указывают.
9. Номер редакции спецификации и ведомости эксплуатационных документов на программу должен совпадать с номером издания этой же программы.
Электронный текст документа
Единая система программной документации:
Сборник национальных стандартов. —
allgosts.ru
Превью ГОСТ 19.103-77 Единая система программной документации. Обозначения программ и программных документов
Источник: allgosts.ru
Обозначение программ и программных документов
настоящему стандарту и включать в указанной последовательности:
— номер редакции документа;
— код вида документа;
— номер документа данного вида в комплекте программных докумен-
В обозначении программы и ее программного документа — специфика-
ции код вида документа и номер документа данного вида не приводят.
8.4.1.1 Регистрационный номер присваивают в соответствии с Клас-
сификатором программ. Допускается присвоение регистрационного номера
(от 00001 до 99999) по указанию кафедры, организующей проектирование.
8.4.1.2 Номер редакции документа присваивают в порядке возраста-
8.4.1.3 Код вида документа присваивают по ГОСТ 19.101.
8.4.1.4 Номер документа данного вида присваивают в порядке воз-
растания с 01 до 99.
1 Обозначение программы и ее программного документа — специфика-
ции, разработанных при выполнении курсового проекта студентом ФСУ:
—T— —T— -T- Номер редакции
2 Обозначение пояснительной записки того же курсового проекта:
ФСУ КП.00007-01 81 01
——-T——- T- -T- Номер документа
Обозначение программы ¦ ¦ ¦ данного вида
¦ Код вида документа
Обозначение документов на автоматизированные системы
8.5.1 Обозначение документов в работах, темой которых является
создание автоматизированных систем, используемых в различных сферах
деятельности (управление, исследование, проектирование и т.п.), должно
соответствовать ГОСТ 34.201.
Приложение А (обязательное) Форма титульного листа выпускной квалификационной работы
¦ | Наименование ведомства, в систему которого входит вуз -| ¦
¦ | строчными буквами кроме первой прописной | ¦
¦ | Наименование вуза — прописными буквами | ¦
¦ L — — -T- — — — — — — — — — — — — — — — — — — — — -T- — — — ¦
¦ | Наименование выпускающей кафедры — | ¦
¦ | строчными буквами кроме первой прописной | ¦
¦ К ЗАЩИТЕ ДОПУСТИТЬ ¦
¦ | Тема работы — прописными буквами | ¦
¦ | Наименование текстового документа работы — | ¦
¦ | строчными буквами кроме первой прописной | ¦
¦ L — — — T — — — — — — — — — — — — — — T — — — — — ¦
¦ | Обозначение (при наличии) | ¦
¦ СОГЛАСОВАНО Студент гр.(номер) ¦
¦ Консультант по . (подпись) И.О.Фамилия ¦
¦ (должность,ученая степень,звание) (дата) ¦
¦ Консультант по . (должность, ученая ¦
¦ (должность,ученая степень,звание) степень, звание) ¦
¦ (подпись) И.О.Фамилия (подпись) И.О.Фамилия ¦
Приложение Б (обязательное) Форма титульного листа тематического реферата, курсового проекта, курсовой работы
¦ | Наименование ведомства, в систему которого входит вуз -| ¦
¦ | строчными буквами кроме первой прописной | ¦
¦ | Наименование вуза — прописными буквами | ¦
¦ | строчными буквами кроме первой прописной | ¦
¦ | Тема работы — прописными буквами | ¦
¦ | Наименование текстового документа работы | ¦
¦ | и название учебной дисциплины — | ¦
¦ | строчными буквами кроме первой прописной | ¦
¦ L — — — T — — — — — — — — — — — — — T — — — — — ¦
¦ | Обозначение (при наличии) | ¦
¦ | Место | (должность, ученая ¦
¦ |для оценки| степень, звание) ¦
¦ L — — — — — — (подпись) И.О.Фамилия ¦
Приложение В (справочное) Примеры оформления титульных листов
¦ Министерство общего и профессионального образования ¦
¦ ТОМСКАЯ ГОСУДАРСТВЕННАЯ АКАДЕМИЯ СИСТЕМ УПРАВЛЕНИЯ ¦
¦ И РАДИОЭЛЕКТРОНИКИ (ТАСУР) ¦
¦ Кафедра культурологии и социологии (КС) ¦
Источник: poisk-ru.ru
ГОСТ 19.103-77
Единая система программной документации. Обозначения программ и программных документов
Распространяем нормативную документацию с 1999 года. Пробиваем чеки, платим налоги, принимаем к оплате все законные формы платежей без дополнительных процентов. Наши клиенты защищены Законом. ООО «ЦНТИ Нормоконтроль»
Наши цены ниже, чем в других местах, потому что мы работаем напрямую с поставщиками документов.
Способы доставки
- Срочная курьерская доставка (1-3 дня)
- Курьерская доставка (7 дней)
- Самовывоз из московского офиса
- Почта РФ
Устанавливает структуру обозначения программ и программных документов для вычислительных машин, комплексов и систем независимо от их назначения и области применения.
Переиздание. Январь 2010 г.
| 01.01.1980 |
| 01.09.2013 |
| 01.01.2021 |
Этот ГОСТ находится в:
- Раздел Строительство
- Раздел Стандарты
- Раздел Другие государственные стандарты, применяемые в строительстве
- Раздел 35 Информационные технологии. Машины конторские
- Раздел Экология
- Раздел 35 ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ. МАШИНЫ КОНТОРСКИЕ
- Раздел 35.080 Программное обеспечение
- Раздел Электроэнергия
- Раздел 35 ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ. МАШИНЫ КОНТОРСКИЕ
- Раздел 35.080 Программное обеспечение
Организации:
| Утвержден | Государственный комитет стандартов Совета Министров СССР | 1268 |
| Издан | Издательство стандартов | 1988 г. |
| Издан | Стандартинформ | 2005 г. |
| Издан | Стандартинформ | 2010 г. |
Unified System for program documentation. Indexing of programs and program documents
Нормативные ссылки:
Чтобы бесплатно скачать этот документ в формате PDF, поддержите наш сайт и нажмите кнопку:
- Сканы страниц ГОСТа
- Текст ГОСТа
ЕДИНАЯ СИСТЕМА
ПРОГРАММНОЙ ДОКУМЕНТАЦИИ
ОБОЗНАЧЕНИЯ ПРОГРАММ
И ПРОГРАММНЫХ ДОКУМЕНТОВ
Стандартинформ
Единая система программной документации
ОБОЗНАЧЕНИЯ ПРОГРАММ И ПРОГРАММНЫХ ДОКУМЕНТОВ
Unified System for program documentation.
Indexing of programs and program documents
ГОСТ
19.103-77
Переиздание. Январь 2010 г.
Постановлением Государственного комитета стандартов Совета Министров СССР от 20 мая 1977 г. № 1268 дата введения установлена
1. Настоящий стандарт устанавливает структуру обозначения программ и программных документов для вычислительных машин, комплексов и систем независимо от их назначения и области применения.
2. Обозначение программ и документов должно состоять из групп знаков, разделенных точками (после кода страны и кода организации-разработчика), пробелами (после номера редакции документа и кода вида документа), дефисами (после регистрационного номера и номера документа данного вида).
3. Устанавливается регистрационная система обозначения программ и программных документов.
Структура обозначения программы и ее программного документа — спецификации:
4. Структура обозначения всех других программных документов:
5. Код страны-разработчика и код организации (предприятия) — разработчика присваивают в установленном порядке.
Регистрационный номер присваивают в соответствии с Общесоюзным классификатором программ, утверждаемым Госстандартом СССР, в установленном порядке.
До утверждения Общесоюзного классификатора программ допускается присваивать регистрационный номер в порядке возрастания, начиная с 00001 до 99999, для каждой организации (предприятия) — разработчика.
Номер издания программы или номер редакции документа присваивают в порядке возрастания, начиная с 01 до 99.
6. Код вида документа присваивают в соответствии с требованиями ГОСТ 19.101-77.
7. Номер документа данного вида присваивают в порядке возрастания, начиная с 01 до 99.
8. Номер части одного и того же документа присваивают в порядке возрастания, начиная с 1 до 9.
Примечание. Если документ состоит из одной части, то дефис и порядковый номер части не указывают.
9. Номер редакции спецификации и ведомости эксплуатационных документов на программу должен совпадать с номером издания этой же программы.
Источник: standartgost.ru