еспд коды программных документов

Опыт применения ЕСПД

Введение

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

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

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

Стандарты

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

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

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. Общие требования к программным документам, выполненным печатным способом

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

Источник

Стандарты ЕСПД

ГОСТ 19.001-77 Общие положения
ГОСТ 19.002-80 Схемы алгоритмов и программ. Правила выполнения
ГОСТ 19.003-80 Схемы алгоритмов и программ. Обозначения условные графические
ГОСТ 19.004-80 Термины и определения
ГОСТ 19.005-85 Р-схемы алгоритмов и программ. Обозначения условные графические и правила выполнения
ГОСТ 19.101-77 Виды программ и программных документов
ГОСТ 19.102-77 Стадии разработки
ГОСТ 19.103-77 Обозначение программ и программных документов
ГОСТ 19.104-78 Основные надписи
ГОСТ 19 105-78 Общие требования к программным документам
ГОСТ 19.106-78 Требования к программным документам, выполненным печатным способом
ГОСТ 19.201-78 Техническое задание. Требования к содержанию и оформлению
ГОСТ 19.202-78 Спецификация. Требования к содержанию и оформлению
ГОСТ 19.301-79 Программа и методика испытаний. Требования к содержанию и оформлению
ГОСТ 19.401-78 Текст программы. Требования к содержанию и оформлению
ГОСТ 19.402-78 Описание программы. Требования к содержанию и оформлению
ГОСТ 19.403-79 Ведомость держателей подлинников
ГОСТ 19.404-79 Пояснительная записка. Требования к содержанию и оформлению
ГОСТ 19.501-78 Формуляр. Требования к содержанию и оформлению
ГОСТ 19.502-78 Описание применения. Требования к содержанию и оформлению
ГОСТ 19.503-79 Руководство системного программиста. Требования к содержанию и оформлению
ГОСТ 19.504-79 Руководство программиста. Требования к содержанию и оформлению
ГОСТ 19.505-79 Руководство оператора. Требования к содержанию и оформлению
ГОСТ 19.506-79 Описание языка. Требования к содержанию и оформлению
ГОСТ 19.507-79 Ведомость эксплуатационных документов
ГОСТ 19.508-79 Руководство по техническому обслуживанию. Требования к содержанию и оформлению
ГОСТ 19.601-78 Общие правила дублирования, учета и хранения
ГОСТ 19.602-78 Правила дублирования, учета и хранения программных документов, выполненных печатным способом
ГОСТ 19.603-78 Общие правила внесения изменений
ГОСТ 19.604-78 Правила внесения изменений в программные документы, выполненные печатным способом
ГОСТ 19.701-90 Схемы алгоритмов, программ, данных и систем. Условные Обозначения и правила выполнения

Так же:

С целью персонализации сервисов, повышения удобства пользования веб-сайтом и проведения статистических исследований мы используем файлы «cookie». «Cookie» представляют собой небольшие файлы, содержащие информацию о настройках браузера. Продолжая использовать наш сайт, вы даете согласие на обработку файлов cookie, если вы не хотите использовать файлы «cookie», измените настройки браузера.

Источник

Еспд коды программных документов

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

ЕДИНАЯ СИСТЕМА ПРОГРАММНОЙ ДОКУМЕНТАЦИИ

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

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

ЕДИНАЯ СИСТЕМА ПРОГРАММНОЙ ДОКУМЕНТАЦИИ

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

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

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

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

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

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

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

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

Определение

Программа, рассматриваемая как единое целое, выполняющая законченную функцию и применяемая самостоятельно или в составе комплекса

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

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

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

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

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

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

Вид программного документа

Содержание программного документа

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

Ведомость держателей подлинников

Перечень предприятий, на которых хранят подлинники программных документов

Запись программы с необходимыми комментариями

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

Программа и методика испытаний

Требования, подлежащие проверке при испытании программы, а также порядок и методы их контроля

Назначение и область применения программы, технические, технико-экономические и специальные требования, предъявляемые к программе, необходимые стадии и сроки разработки, виды испытаний

Схема алгоритма, общее описание алгоритма и (или) функционирования программы, а также обоснование принятых технических и технико-экономических решений

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Код вида документа

Ведомость держателей подлинников

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

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

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

Программа и методика испытаний

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

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

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

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

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

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

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

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

Источник

ГОСТ 19.101-77* «Единая система программной документации. Виды программ и программных документов»

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

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

ЕДИНАЯ СИСТЕМА ПРОГРАММНОЙ ДОКУМЕНТАЦИИ

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

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

ЕДИНАЯ СИСТЕМА ПРОГРАММНОЙ ДОКУМЕНТАЦИИ

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

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

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

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

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

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

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

Определение

Программа, рассматриваемая как единое целое, выполняющая законченную функцию и применяемая самостоятельно или в составе комплекса

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

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

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

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

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

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

Вид программного документа

Содержание программного документа

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

Ведомость держателей подлинников

Перечень предприятий, на которых хранят подлинники программных документов

Запись программы с необходимыми комментариями

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

Программа и методика испытаний

Требования, подлежащие проверке при испытании программы, а также порядок и методы их контроля

Назначение и область применения программы, технические, технико-экономические и специальные требования, предъявляемые к программе, необходимые стадии и сроки разработки, виды испытаний

Схема алгоритма, общее описание алгоритма и (или) функционирования программы, а также обоснование принятых технических и технико-экономических решений

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Код вида документа

Ведомость держателей подлинников

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

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

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

Программа и методика испытаний

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

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

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

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

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

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

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

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

Источник