Опыт применения еспд. Оформление по еспд программной документации, еспд Документация на программное обеспечение гост
Дата введения с 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)
Программы для ЭВМ оформляются в соответствии с требованиями Единой системы программной документации (ЕСПД) . ЕСПД - набор ГОСТов, устанавливающих правила оформления, содержание, структуру программных документов.
Данный 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 Единая система программной документации. Виды программ и программных документов
ГОСТ 19.101-77
МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ
ЕДИНАЯ СИСТЕМА ПРОГРАММНОЙ ДОКУМЕНТАЦИИ
ВИДЫ ПРОГРАММ И ПРОГРАММНЫХ ДОКУМЕНТОВ
Издание официальное
Стандартинформ
УДК 002:651.7/.78:006.354
Группа Т55
МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ
Единая система программной документации
ВИДЫ ПРОГРАММ И ПРОГРАММНЫХ ДОКУМЕНТОВ
Unified system for program documentation.
Types of programs and program documents
Постановлением Государственного комитета стандартов Совета Министров СССР от 20 мая 1977 г. № 1268 дата введения установлена
Настоящий стандарт устанавливает виды программ и программных документов для вычислительных машин, комплексов и систем независимо от их назначения и области применения.
Стандарт полностью соответствует СТ СЭВ 1626-79.
(Измененная редакция, Изм. № 1).
1. ВИДЫ ПРОГРАММ
1.1. Программу (по ГОСТ 19781-90) допускается идентифицировать и применять самостоятельно и (или) в составе других программ.
1.2. Программы подразделяют на виды, приведенные в табл. 1.
1.3. Документация, разработанная на программу, может использоваться для реализации и передачи программы на носителях данных, а также для изготовления программного изделия.
1.2, 1.3. (Измененная редакция, Изм. № 1).
2. ВИДЫ ПРОГРАММНЫХ ДОКУМЕНТОВ
2.1. К программным относят документы, содержащие сведения, необходимые для разработки, изготовления, сопровождения и эксплуатации программ.
2.2. Виды программных документов и их содержание приведены в табл. 2.
Издание официальное ★
Перепечатка воспрещена
) Издательство стандартов, 1977 © СТАНДАРТИНФОРМ, 2010
Издание (январь 2010 г.) с Изменением № 1, утвержденным в июне 1981 г. (ИУС 9-81).
Таблица 2
|
Вид программного документа | |
|
Спецификация |
Состав программы и документации на нее |
|
Ведомость держателей подлин- |
Перечень предприятий, на которых хранят подлинники программ- |
|
ных документов |
|
|
Текст программы |
Запись программы с необходимыми коментариями |
|
Описание программы |
Сведения о логической структуре и функционировании программы |
|
Программа и методика испыта- |
Требования, подлежащие проверке при испытании программы, а также |
|
порядок и методы их контроля |
|
|
Техническое задание |
Назначение и область применения программы, технические, технико-экономические и специальные требования, предъявляемые к программе, необходимые стадии и сроки разработки, виды испытаний |
|
Пояснительная записка |
Схема алгоритма, общее описание алгоритма и (или) функционирования программы, а также обоснование принятых технических и технико-экономических решений |
|
Эксплуатационные документы |
Сведения для обеспечения функционирования и эксплуатации программы |
2.3. Виды эксплуатационных документов и их содержание приведены в табл. 3.
Таблица 3
эксплуатационного документа
Ведомость эксплуатационных документов Формуляр
Описание применения
Руководство программиста Руководство оператора
Описание языка Руководство по техническому обслуживанию
Перечень эксплуатационных документов на программу
Основные характеристики программы, комплектность и сведения об эксплуатации программы
Сведения о назначении программы, области применения, применяемых методах, классе решаемых задач, ограничениях для применения, минимальной конфигурации технических средств
Сведения для проверки, обеспечения функционирования и настройки программы на условия конкретного применения
Сведения для эксплуатации программы
Сведения для обеспечения процедуры общения оператора с вычислительной системой в процессе выполнения программы
Описание синтаксиса и семантики языка
Сведения для применения тестовых и диагностических программ при обслуживании технических средств
2.4. В зависимости от способа выполнения и характера применения программные документы подразделяются на подлинник, дубликат и копию (ГОСТ 2.102-68), предназначенные для разработки, сопровождения и эксплуатации программы.
2.5. Виды программных документов, разрабатываемых на разных стадиях, и их коды приведены в табл. 4.
Таблица 4
|
Код вида документа |
Вид документа |
Стадии разработки |
|||
|
Эскизный |
Технический |
Рабочий проект |
|||
|
компонент |
комплекс |
||||
|
Спецификация | |||||
|
Ведомость держателей подлин- | |||||
|
Текст программы | |||||
|
Описание программы | |||||
|
Ведомость эксплуатационных | |||||
|
документов | |||||
|
Формуляр | |||||
Продолжение таблицы 4
|
Код вида документа |
Стадии разработки | ||||
|
Вид документа |
Эскизный |
Технический |
Рабочий проект |
||
|
компонент |
комплекс |
||||
|
Описание применения | |||||
|
Руководство системного программиста | |||||
|
Руководство программиста | |||||
|
Руководство оператора | |||||
|
Описание языка | |||||
|
Руководство по техническому обслуживанию | |||||
|
Программа и методика испытаний | |||||
|
Пояснительная записка | |||||
|
Прочие документы | |||||
Условные обозначения:
Документ обязательный;
С - документ обязательный для компонентов, имеющих самостоятельное применение;
О - необходимость составления документа определяется на этапе разработки и утверждения технического задания;
Документ не составляют.
2.2-2.5. (Измененная редакция, Изм. № 1).
2.6. Допускается объединять отдельные виды эксплуатационных документов (за исключением ведомости эксплуатационных документов и формуляра). Необходимость объединения этих документов указывается в техническом задании. Объединенному документу присваивают наименование и обозначение одного из объединяемых документов.
В объединенных документах должны быть приведены сведения, которые необходимо включать в каждый объединяемый документ.
2.7. На этапе разработки и утверждения технического задания определяют необходимость составления технических условий, содержащих требования к изготовлению, контролю и приемке программы.
Технические условия разрабатывают на стадии «Рабочий проект».
2.8. Необходимость составления технического задания на компоненты, не предназначенные для самостоятельного применения, и комплексы, входящие в другие комплексы, определяется по согласованию с заказчиком.
(Введен дополнительно, Изм. № 1).
- ГОСТ 19.001-77 Единая система программной документации. Общие положения
- ГОСТ 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 Единая система программной документации. Правила внесения изменений в программные документы, выполненные печатным способом
- ГОСТ 28195-89 Оценка качества программных средств. Общие положения
- ГОСТ 34.601-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания
- ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы
- ГОСТ Р 56447-2015 Месторождения газовые, газоконденсатные, нефтегазовые и нефтегазоконденсатные. Программное обеспечение для обработки и интерпретации данных сейсморазведки. Основные функциональные и технические требования
- ГОСТ Р 56448-2015 Месторождения газовые, газоконденсатные, нефтегазовые и нефтегазоконденсатные. Программное обеспечение для геологического моделирования месторождений. Основные функциональные и технические требования
- ГОСТ Р 56450-2015 Месторождения газовые, газоконденсатные, нефтегазовые и нефтегазоконденсатные. Программное обеспечение для гидродинамического моделирования систем сбора и подготовки углеводородов. Основные функциональные и технические требования
- ГОСТ Р 55711-2013 Комплекс технических средств автоматизированной адаптивной ВЧ (КВ) дуплексной радиосвязи. Алгоритмы работы
- ГОСТ Р 56566-2015 Информационные технологии. Оценка процессов. Часть 9. Профили целевого процесса
- ГОСТ Р 55692-2013 Модули электронные. Методы составления и отладки тест-программ для автоматизированного контроля
- ГОСТ Р 56449-2015 Месторождения газовые, газоконденсатные, нефтегазовые и нефтегазоконденсатные. Программное обеспечение для гидродинамического моделирования месторождений. Основные функциональные и технические требования
- ГОСТ Р 56413-2015 Информационные технологии. Европейские профили профессий ИКТ-сектора
- ГОСТ Р ИСО/МЭК 15026-1-2016 Системная и программная инженерия. Гарантирование систем и программного обеспечения. Часть 1. Понятия и словарь
- ГОСТ Р ИСО/МЭК 15026-4-2016 Системная и программная инженерия. Гарантирование систем и программного обеспечения. Часть 4. Гарантии жизненного цикла
- ГОСТ Р 56920-2016 Системная и программная инженерия. Тестирование программного обеспечения. Часть 1. Понятия и определения
- ГОСТ Р 56921-2016 Системная и программная инженерия. Тестирование программного обеспечения. Часть 2. Процессы тестирования
- ГОСТ Р ИСО/МЭК 26555-2016 Системная и программная инженерия. Инструменты и методы технического менеджмента линейки продуктов
- ГОСТ Р ИСО/МЭК 29155-1-2016 Системная и программная инженерия. Структура сопоставительного анализа эффективности выполнения проектов информационных технологий. Часть 1. Понятия и определения
- ГОСТ Р 54360-2011 Лабораторные информационные менеджмент-системы (ЛИМС). Стандартное руководство по валидации ЛИМС
- ГОСТ Р 54593-2011 Информационные технологии. Свободное программное обеспечение. Общие положения
- ГОСТ Р ИСО/МЭК 12207-2010 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств
- ГОСТ Р 53798-2010 Стандартное руководство по лабораторным информационным менеджмент-системам (ЛИМС)
- ГОСТ Р ИСО/МЭК 15504-1-2009 Информационные технологии. Оценка процессов. Часть 1. Концепция и словарь
- ГОСТ Р ИСО/МЭК 15504-2-2009 Информационная технология. Оценка процесса. Часть 2. Проведение оценки
- ГОСТ Р ИСО/МЭК 15504-3-2009 Информационная технология. Оценка процесса. Часть 3. Руководство по проведению оценки
- ГОСТ Р 57098-2016 Системная и программная инженерия. Управление жизненным циклом. Руководство для описания процесса
- ГОСТ Р 57100-2016 Системная и программная инженерия. Описание архитектуры
- ГОСТ Р 57101-2016 Системная и программная инженерия. Процессы жизненного цикла. Управление проектом
- ГОСТ Р 57102-2016 Информационные технологии. Системная и программная инженерия. Управление жизненным циклом. Часть 2. Руководство по применению ИСО/МЭК 15288
- ГОСТ Р 57122-2016 Месторождения газовые, газоконденсатные, нефтегазовые и нефтегазоконденсатные. Программное обеспечение для проектирования строительства скважин. Основные функциональные и технические требования
- ГОСТ Р 57193-2016 Системная и программная инженерия. Процессы жизненного цикла систем
- ГОСТ Р ИСО/МЭК 15504-5-2016 Информационные технологии. Оценка процессов. Часть 5. Образец модели оценки процессов жизненного цикла программного обеспечения
- ГОСТ 34009-2016 Средства и системы управления железнодорожным тяговым подвижным составом. Требования к программному обеспечению
- ГОСТ Р 57318-2016 Системы промышленной автоматизации и интеграция. Применение и управление процессами системной инженерии
- ГОСТ Р ИСО/МЭК 25001-2017 Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Планирование и управление
- ГОСТ Р ИСО/МЭК 33004-2017 Информационные технологии. Оценка процесса. Требования к эталонным моделям процесса, моделям оценки процесса и моделям зрелости
- ГОСТ Р ИСО/МЭК 15414-2017 Информационные технологии. Открытая распределенная обработка. Эталонная модель. Язык описания предприятия
- ГОСТ IEC 60848-2016 Язык спецификаций GRAFCET для последовательных функциональных схем
- ГОСТ Р ИСО/МЭК 25051-2017 Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Требования к качеству готового к использованию программного продукта (RUSP) и инструкции по тестированию
- ГОСТ Р ИСО/МЭК 33001-2017 Информационные технологии. Оценка процесса. Понятия и терминология
- ГОСТ Р ИСО/МЭК 33002-2017 Информационные технологии. Оценка процесса. Требования к проведению оценки процесса
- ГОСТ Р ИСО/МЭК 33003-2017 Информационные технологии. Оценка процесса. Требования к системам измерения процесса
- ГОСТ Р ИСО/МЭК 33020-2017 Информационные технологии. Оценка процесса. Система измерения процесса для оценки возможностей процесса
- ГОСТ Р 57640-2017 Информационные технологии. Эталонная модель процесса (ЭМП) для управления информационной безопасностью
- ГОСТ Р ИСО/МЭК 30121-2017 Информационные технологии. Концепция управления рисками, связанными с проведением судебной экспертизы свидетельств, представленных в цифровой форме
- ГОСТ Р 58041-2017 Месторождения газовые, газоконденсатные, нефтегазовые и нефтегазоконденсатные. Система стандартов по программному обеспечению для решения задач поиска, разведки и разработки месторождений. Основные положения и технические требования
- ГОСТ Р 58042-2017 Месторождения газовые, газоконденсатные, нефтегазовые и нефтегазоконденсатные. Основные требования к исходным данным программных комплексов для решения задач поиска, разведки и разработки месторождений
- ГОСТ Р ИСО/МЭК 10746-1-2004 Информационная технология. Открытая распределенная обработка. Базовая модель. Часть 1. Основные положения
- ГОСТ Р ИСО/МЭК 10746-4-2004 Информационная технология. Открытая распределенная обработка. Базовая модель. Часть 4. Архитектурная семантика
- ГОСТ Р ИСО/МЭК 12119-2000 Информационная технология. Пакеты программ. Требования к качеству и тестирование
- ГОСТ Р ИСО/МЭК 12207-99 Информационная технология. Процессы жизненного цикла программных средств
- ГОСТ Р ИСО/МЭК 14764-2002 Информационная технология. Сопровождение программных средств
Сегодня мы поговорим об отечественных стандартах на проектную документацию. Как эти стандарты работают на практике, чем они плохи и чем хороши. При разработке документации для государственных и серьезных частных заказчиков у нас обычно нет выбора - в требования по документированию ТЗ вписано соблюдение стандартов. На практике мне приходилось сталкиваться с различными примерами недопонимания структуры стандартов, того, что должно быть в документах и зачем эти документы нужны. В итоге из-под пера техписателей, аналитиков и специалистов выходят порой такие перлы, что непонятно, в каком состоянии сознания они писались. А ведь на самом деле все достаточно просто. Поиск по Хабру не вернул ссылок на более-менее целостный материал на данную тему, потому предлагаю закрасить этот досадный пробел.
Что такое стандарты на документацию?
В серии 34, о которой идет речь, существует всего 3 основных стандарта по документированию:Самый любимый и популярный стандарт по разработке ТЗ. Единственное, не стоит забывать, что он крепко связан с другими стандартами серии и если вы получили ТЗ, выполненное по данному стандарту, крайне желательно придерживаться и других стандартов, даже если об этом нет прямых требований. Хотя бы в плане общей идеологии (о которой ниже)
Это базовый документ, в котором приводится полный перечень документации ГОСТ 34, рекомендации по кодированию документов, к каким стадиям проекта относятся документы (стадии описываются в ГОСТ 34.601-90), а также как их можно объединить между собой.
Фактически, этот стандарт представляет собой большую таблицу с комментариями. Ее можно загнать в Excel для удобства использования.
Объемистый стандарт, с различной степенью детальности описывающий содержание проектных документов. В качестве индекса используется упомянутый выше ГОСТ 34.201-89.
К стандарту РД 50-34.698-90 существует множество вопросов и трактовок его положений, которые ввиду их неконкретности, часто понимают по-разному заказчик и исполнитель или даже члены проектной команды. Но ничего более конкретного у нас, к сожалению, нет.
Рассмотрим теперь плюсы и минусы стандартов, начав традиционно с минусов.
Минусы стандартов
Основной минус всем очевиден - стандарты старые. В них заложено устаревшее представление об архитектуре автоматизированной системы. Например:- приложения двухуровневые, состоящие из клиентской программы и сервера СУБД (никаких трех- и более «уровневых» приложений, никаких Weblogic или JBoss)
- структура таблиц базы данных, будучи описана, даст представление о логической модели данных (то, что между приложением и базой может находиться какой-нибудь Hibernate, тогда казалось нехорошим излишеством)
- пользовательский интерфейс однооконный (а разве бывает другой? А что такое «браузер»?)
- Отчетов в системе немного, все они бумажные и печатаются на матричном принтере
- Разрабатываемая программа ориентирована на решение «задачи обработки информации», которая имеет четкий вход и выход и узко специализирована. В основе обработки информации лежит «алгоритм». Иногда «алгоритмов» бывает несколько. (Объектно-ориентированное программирование тогда делало лишь свои первые шаги и серьезно не рассматривалось).
- администратор базы данных понимает, какая информация лежит в таблицах и активно участвует в редактировании системных справочников (а разве бывает один сервер СУБД для 50 разных приложений?)
5.8. Чертеж формы документа (видеокадра)
В документе должно быть приведено изображение формы документа или видеокадра в соответствии с требованиями государственных стандартов унифицированной системы документации Р 50-77 и необходимые пояснения.
Смысл документа в том, что на советских предприятиях использовались так называемые «Участки печати», где стояли матричные скоростные принтеры, драйверы к которым часто писали сами инженеры. Поэтому они должны были поддерживать реестр всех документов, которые требовалось печатать для гарантии того, что в напечатанном виде документы будут выглядеть так, как положено.
«Видеокадр» - это тоже документ, который выводился на текстовый дисплей. Дисплеи не всегда поддерживали нужные символы и нужное количество символов по горизонтали и строк по вертикали (а графику вообще не поддерживали). Поэтому тут тоже надо было дополнительно согласовывать формы всех экранных документов.
Сейчас уже нам ничего не говорят слова «машинограмма», «видеокадр», «АЦПУ». Я тоже их не застал в употреблении, хотя заканчивал профильный институт в 90-е. Это было время появления Windows 3.1, VGA дисплеев, трехдюймовых дискет и первых отечественных интернет-сайтов. Но в стандарте эти слова есть, и заказчик иногда капризно требует предоставить ему полный комплект документации в соответствии с ГОСТ 34.201-89. Более того, подобные формулировки в ТЗ кочуют из одного министерства в другое и стали уже неким негласным шаблоном, в который вбивают содержательную часть.
Так что документ с дурацким названием «Чертеж формы документа (видеокадра)» в проекте должен быть и должен быть не пустым.
Что в стандарте хорошо
Любой стандарт хорош уже тем, что он позволяет заказчику и исполнителю говорить на одном языке и дает гарантию, что, по крайней мере, претензий «по форме» к передаваемым результатам у заказчика не будет.А стандарты ГОСТ 34 хороши еще и тем, что они составлялись умными людьми, обкатывались годами и у них есть четкая цель - максимально полно описать на бумаге сложную абстрактную сущность, которую представляет собой любая АСУ.
Когда вам требуется грамотно поставить задачу западным подрядчикам, которые про наши ГОСТы слыхом не слыхивали, можно также опираться на эти стандарты, а точнее на их контент, смысловую составляющую. Потому что, повторюсь, гарантия полноты информации дорогого стоит. Как бы мы себя не тешили высоким уровнем своего профессионализма, мы можем забыть включить в состав наших требований элементарные вещи, тогда как тот же ГОСТ 34.602-89 «помнит» обо всем. Если вам непонятно, как должен выглядеть результат работы западных подрядчиков, посмотрите на требования к документированию, к рекомендуемым разделам. Уверяю вас, лучше не придумать! Скорее всего, есть западные аналоги наших стандартов, в которых все может быть полнее, современнее и лучше. К сожалению, я с ними не знаком, так как не было пока ни одного случая, чтобы наших ГОСТов было бы недостаточно.
Можно смеяться над тем, что создатели стандартов ничего не знали о java или.NET, о HD мониторах и Интернете, но я бы не советовал недооценивать масштаб проделанной ими работы и ее ценность для нашего профессионального сообщества.
Как читать и понимать стандарты документации по ГОСТ серии 34
Стандарт делит все документы по двум осям - время и предметная область. Если посмотреть таблицу 2 в ГОСТ 34.201-89, то хорошо видно это деление (колонки «Стадия создания» и «Часть проекта»Стадии создания АСУ
Стадии создания определены в ГОСТ 34.601-90. Имеют отношение к документированию из них три:- Эскизный проект (ЭП)
- Технический проект (ТП)
- Разработка рабочей документации (РД)
Технический проект описывает будущую систему со всех ракурсов. Документы стадии ТП должны после прочтения оставлять после себя полную ясность в предлагаемых подходах, методах, архитектурных и технических решениях. На следующей фазе уже поздно будет описывать подходы и обосновывать технические решения, так что фаза П является ключом к успешной сдаче работ, так как все многообразие требований ТЗ должно находить отражение в документах фазы П. На этапе П система может вообще не существовать.
Рабочая документация предназначена для успешного развертывания, ввода в действие и дальнейшей эксплуатации новой системы. Это документы, содержащие совершенно конкретные сведения, описывающие физически существующие сущности, в отличие от фазы П, где описывается будущее великолепие.
Части (разделы) проектной документации по созданию АСУ
Предметная область разделена на «Обеспечения». Поначалу кажется, что такое деление избыточно и ненужно. Но когда начинаешь на практике работать этим инструментарием, постепенно доходит вложенная в него идеология.Автоматизированная система в представлении составителей ГОСТ представляет собой совокупность железа, софта и каналов связи, которая обрабатывает приходящую из разных источников информацию в соответствии с некими алгоритмами и выдает результаты обработки в виде документов, структур данных или управляющих воздействий. Примитивная модель простейшего автомата.
Для того, чтобы полностью описать этот «автомат», сделаны следующие разрезы (как в черчении):
Математическое обеспечение (МО) , отвечающее на вопросы: какая логика зашита внутри «черного ящика»? Почему выбраны именно эти алгоритмы, именно такие формулы и именно такие коэффициенты?
Математическое обеспечение ничего не знает ни о процессорах, ни о базах данных. Это отдельная абстрактная область, обитель «сферических коней в вакууме». Но математическое обеспечение бывает очень плотно связано с предметной областью, aka Реальная жизнь. Например, управляющие алгоритмы для систем управления дорожным движением требуется согласовать в ГИБДД перед тем, как их будет согласовывать заказчик. И тут понимаешь, зачем их выделяют в отдельную книжицу. Потому что в ГИБДД никому не интересно, на какой ОС будет работать сервер приложения, а вот какой знак и ограничение скорости выскочит на табло в дождь или в снег очень даже интересно. Они отвечают за свою часть, и ничего другого подписывать не собираются. С другой стороны, когда они подписали, не будет вопросов к технической стороне вопроса - почему выбрали те, а не другие табло или светофоры. Мудрость «предков» как раз и проявляется в таких вот практических кейсах.
Информационное обеспечение (ИО) . Еще один срез системы. На этот раз делается прозрачным черный ящик нашей системы и мы смотрим на циркулирующую в нем информацию. Представьте себе модель кровеносной системы человека, когда все остальные органы невидимы. Вот что-то подобное и есть Информационное обеспечение. В нем описываются состав и маршруты прохождения информации внутри и снаружи, логическая организация информации в системе, описание справочников и систем кодирования (кто делал программы для производства, тот знает, как они важны). Основная описательная часть приходится на этап ТП, но в этап РД перетекают некоторые «рудименты», наподобие документа «Каталог баз данных». Понятно, что раньше он содержал именно то, что написано в названии. Но сегодня попробуйте для сложной комплексной системы сформировать такой документ, когда очень часто в составе системы используются покупные подсистемы со своими загадочными информационными хранилищами. Я уж не говорю о том, что этот документ не особенно сейчас и нужен.
Или вот «Ведомость машинных носителей информации». Понятно, что раньше в нем были номера магнитных барабанов или бобин с пленкой. А сейчас что туда вносить?
Короче, на фазе РД документы Информационного обеспечения представляют собой довольно зловредный рудимент, так как формально они быть должны, но наполнять их особенно нечем.
Программное обеспечение (ПО) . Любимая всеми часть проектной документации. Да хотя бы потому, что это всего один документ! И потом, всем понятно, что туда нужно записывать. Но я, все-же, повторю.
В этом документе мы должны рассказать, при помощи каких программных средств выполняются алгоритмы, описанные в МО, обрабатывающие информацию, описанная в ИО. То есть, не нужно дублировать тут информацию из других разделов. Тут дается архитектура системы, обоснование выбранных программных технологий, их описание (всякие системные вещи: языки программирования, фреймворки, операционки и т.п.). Также в этом документе мы описываем как организованы средства обработки информации (очереди сообщений, хранилища, средства резервного копирования, решения по доступности, всякие пулы приложений и т.п.). В стандарте есть подробнейшее описание содержания этого документа, которое поймет любой специалист.
Техническое обеспечение (ТО) . Не менее любимая всеми часть проектной документации. Радужную картину омрачает только обилие документов, которые требуется разрабатывать. Всего по стандарту требуется разработать 22 документа, из них 9 на стадии ТП.
Дело в том, что стандарт предусматривает описание всего технического обеспечения, включая компьютерное «железо» и сети, инженерные системы и даже строительную часть (если потребуется). А это хозяйство регламентируется громадным количеством стандартов и нормативных актов, согласуется в разных организациях и поэтому удобнее все дробить на части и согласовывать (править) по частям. В то же время стандарт позволяет объединять некоторые документы друг с другом, что имеет смысл делать, если всю кучу согласует один человек.
Не забывайте также, что комплекс стандартов качества подразумевает учет и хранение технических документов, и наши «книжицы» у заказчика могут разойтись по разным архивам, в зависимости от предмета описания. Это еще один аргумент в пользу дробления документации.
Организационное обеспечение (ОО) . Подавив в себе нормальное для технаря желание проскочить этот раздел поскорее, наоборот, рассмотрю его более подробно. Так как, коллеги, в последнее время на проектах наметились нехорошие тенденции, которые требуют внесения ясности именно в этот раздел.
На стадии ТП раздел содержит всего один документ «Описание организационной структуры », в котором мы должны рассказать заказчику, к чему он должен готовиться в плане изменения оргштатной структуры. Вдруг требуется организовать новый отдел для эксплуатации вашей системы, ввести новые должности и т.п.
На стадии РД появляются другие, более интересные документы, которые мне бы хотелось рассмотреть отдельно.
Руководство пользователя . Комментарии излишни, я думаю.
Методика (технология) автоматизированного проектирования . В этот документ при необходимости можно поместить описание процесса сборки ПО, управления версиями, тестирования и т.п. Но это если в ТЗ заказчик желает самолично осуществлять сборку ПО. Если он этого не требует (и не платит за это), то вся ваша внутренняя кухня не его ума дело, и этот документ делать не нужно.
Технологическая инструкция . В связи с модой на формализацию бизнес процессов, в этот документ ушлый заказчик иногда стремится запихнуть регламенты работы службы эксплуатации. Так вот, делать этого ни в коем случае не нужно.
Описание бизнес-процессов, ролевые и должностные инструкции, регламенты работы - все это ОРД, то есть организационно-распорядительная документация. Которая является продуктом консалтингового проекта, который у вас, насколько я понимаю, не покупали. А покупали у вас проект технический и документацию к нему тоже техническую.
Технологическая инструкция является прослойкой между ОРД и руководством пользователя. РП подробно описывает как нужно делать те или иные действия в системе. Технологическая инструкция говорит о том, какие действия необходимо выполнять в тех или иных случаях, связанных с эксплуатацией системы. Грубо говоря, технологическая инструкция это краткий дайджест по РП для конкретной должности или роли. Если у заказчика роли не сформированы или он хочет, чтобы вы сами сформировали роли и требования к должностям, включите в документ самые базовые роли, например: оператор, старший оператор, администратор. Замечания заказчика на тему, «а у нас не так» или «а нам не нравится» должны сопровождаться перечнем ролей и описанием должностных обязанностей. Потому что бизнес-процессы мы не ставим . Мы эти бизнес-процессы автоматизируем .
Об описанных граблях я еще напишу отдельно, с красочными примерами, так как это повторяется уже не первый раз и в разных отраслях «народного хозяйства».
Описание технологического процесса обработки данных (включая телеобработку) . Жалкий рудимент пещерного века, когда были специально выделенные «Операторы ЭВМ», скармливающие машине перфокарты и упаковывающие распечатку результата в конвертик. Эта инструкция - для них. Что в нее писать в XXI веке - я вам точно сказать не могу. Выкручивайтесь сами. Самое лучшее, это просто забыть про этот документ.
Общесистемные решения (ОР) . Стандартом предусмотрено 17 документов раздела ОР. Во-первых, это почти все документы предварительной фазы Эскизного проектирования. Во-вторых, это всевозможные сметы, расчеты и краткие описание автоматизируемых функций. То есть, информация для людей не с основного ИТ-производства, а для вспомогательного персонала - менеджеров, сметчиков, специалистов по закупкам, экономистов и т.п.
А в-третьих, в состав ОР входит мега-документ под названием «Пояснительная записка к техническому проекту», который по задумке представляет собой некий Executive Summary, а по факту многие проектанты пихают в него вообще все полезное содержание стадии ТП. Подобный радикальный подход бывает оправдан и даже взаимно выгоден и заказчику и исполнителю работ, но в определенных случаях.
Варианты использования ГОСТ 34
- Полное и точное следование стандарту . Добровольно никто, естественно, такую тучу документов писать не будет. Поэтому полный комплект документов готовится только по настоятельной просьбе заказчика, которую он закрепил в ТЗ и еще договором сверху придавил. В таком случае требуется понимать все буквально и отдать заказчику физические «книжки», на которых будут стоять названия документов из таблицы 2 ГОСТ 34.201-89 за исключением совсем уж ненужных, перечень которых вы обязательно должны обговорить и закрепить письменно. Содержание документов также должно без всякой фантазии соответствовать РД 50-34.698-90, вплоть до названия разделов. Для того, чтобы у заказчика взорвался мозг, иногда большую систему делят на подсистемы, и для каждой подсистемы выпускают отдельную проектную документацию. Выглядит это устрашающе и нормальному контролю при помощи земного разума не подлежит. Особенно в части интеграции подсистем. Что значительно упрощает приемку. Главное, чтобы вы сами при этом не запутались и чтобы ваша система все-таки заработала как надо.
- Мы просто любим ГОСТы . В серьезных больших компаниях любят стандарты. Потому, что они помогают людям лучше понимать друг друга. Если ваш заказчик замечен в любви к порядку и стандартизации, постарайтесь придерживаться стандартной идеологии ГОСТ при разработке документов, даже если этого не требует ТЗ. Вас лучше поймут и одобрят согласующие специалисты, а вы сами не забудете включить в документацию важную информацию, лучше будете видеть целевую структуру документов, точнее планировать работы по их написанию и сэкономите себе и коллегам массу нервов и денег.
- Нам плевать на документацию, лишь бы все работало . Исчезающий вид безответственного заказчика. Подобный взгляд на документацию пока еще можно встретить у небольших и бедных заказчиков, а также в оставшихся со времен перестройки авторитарных «идиотократиях», где босс окружен верными друзьями - директорами, и все вопросы решаются в личных беседах. Вы вольны в подобных условиях забивать на документирование вообще, но лучше, все таки, прицел не сбивать и хотя бы схематично наполнять содержимым документацию. Если не этому заказчику, так следующему передадите (продадите).
Заключение
Эта статья была о наших ГОСТах на документирование АСУ. ГОСТы старые, но, как оказалось, до сих пор очень даже полезные в хозяйстве. Не считая некоторые явные рудименты, структура документации обладает свойствами полноты и непротиворечивости, а следование стандарту снимает многие проектные риски, о существовании которых мы можем по началу не догадываться.Надеюсь, изложенный материал был вам полезен, или, как минимум, интересен. Несмотря на внешнюю скуку, документирование является важной и ответственной работой, аккуратность в которой так же важна, как и при написании хорошего кода. Пишите хорошие документы, коллеги! А я на следующей неделе отправляюсь в две подряд командировки, так что публикацию новых материалов не гарантирую (загашника у меня нет, пишу из головы).
Единая система документации программной продукции – ЕСПД – относится к ГОСТ класса 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 – схемы алгоритмов, программ, данных и систем.
