Оформление программы по ГОСТу (how to)
Краткий алгоритм оформления программы
Кратко алгоритм оформления программы и виды программных документов изображены на рисунке. Более подробно процесс оформления описан далее.
Оформление программного документа
Программный документ — документ, содержащий сведения, необходимые для разработки, изготовления, сопровождения и эксплуатации программ.
Каждый отдельный программный документ оформляется по (общим для всех докуметнов ЕСПД) требованиям ГОСТ 19.101-77, ГОСТ 19.103-77, ГОСТ 19.104-78, ГОСТ 19.105-78, ГОСТ 19.106-78, ГОСТ 19.604-78 (более подробное описание данных ГОСТов следует ниже) и ГОСТа для конкретного программного документа.
Общие требования к программным документам. ГОСТ 19.105 — 78
ГОСТ 19.105-78 устанавливает общие требования к оформлению программных документов.
По данному ГОСТу, программный документ должен состоять из следующих частей:
- Титульная часть. Титульная часть состоит из листа утверждения и титульного листа. Правила оформления листа утверждения и титульного листа описаны далее.
- Информационная часть. Информационная часть должна состоять из аннотации и содержания.
- В аннотации приводят сведения о назначении документа и краткое изложение его основной части.
- Содержание включает перечень записей о структурных элеметнах основной части документа.
Необходимость наличия информационной части в разных видах программных документов определяется соответствующими ГОСТами на эти программные документы.
Как оформить реферат по ГОСТУ 2020 года за 5 минут (Пример правильного оформления)
- Основная часть. Состав и структура основной части программного документа устанавливаются стандартами ЕСПД на соответствующие документы.
- Часть регистрации изменений. В этой части делается запись о каждом изменении программного документа в соответствии с требованиями ГОСТ 19.603 — 78.
Вид программного документа. ГОСТ 19.101 — 77
ГОСТ 19.101-77 устанавливает виды программ и программных документов для вычислительных машин, комплексов и систем, независимо от их назначения и области применения.
ГОСТ устанавливает 2 вида программ:
- Компонент — программа, рассматриваемая как единое целое, выполняющая законченную функцию и применяемая самостоятельно или в составе комплекса;
- Комплекс — программа, состоящая из двух или более компонентов и(или) комплексов, выполняющих взаимосвязанные функции, и применяемая самостоятельно или в составе другого комплекса.
| Спецификация | Состав программы и документации на нее |
| Ведомость держателей подлинников | Перечень предприятий, на которых хранят подлинники программных документов |
| Текст программы | Запись программы с необходимыми комментариями |
| Описание программы | Сведения о логической структуре и функционировании программы |
| Программа и методика испытаний | Требования, подлежащие проверке при испытании программы, а также порядок и методы их контроля |
| Техническое задание | Назначение и область применения программы, технические, технико-экономические и специальные требования, предъявляемые к программе, необходимые стадии и сроки разработки, виды испытаний |
| Пояснительная записка | Схема алгоритма, общее описание алгоритма и (или) функционирования программы, а также обоснование принятых технических и технико-экономических решений |
| Эксплуатационные документы | Сведения для обеспечения функционирования и эксплуатации программы |
КРУТИХИН: Россия сократит добычу нефти вдвое. Ремонт «Северных потоков». Газ из Турции / Труба #33
Обозначение программ и программных документов. ГОСТ 19.103 — 77
ГОСТ 19.103-77 устанавливает структуру обозначения программ и программных документов для вычислительных машин, комплексов и систем независимо от их назначения и области применения.
Проще говоря, данный ГОСТ описывает каким должен быть шифр документа вида А.В.ХХХХХ-ХХ ХХ ХХ-Х, и что означает каждое поле данного шифра.
Основные надписи. ГОСТ 19.104 — 78
ГОСТ 19.104-78 устанавливает формы, размеры, расположение и порядок заполнения основных надписей листа утверждения и титульного листа в программных документах, предусмотренных стандартами ЕСПД, независимо от способа их выполнения.
В ГОСТе есть примеры титульного листа и листа утверждения, а также общая форма листа, разбитая на поля. Также можно посмотреть пример.
Требования к программным документам, выполненным печатным способом. ГОСТ 19.106 — 78
ГОСТ 19.106-78 устанавливает правила выполнения программных документов для печатного способа выполнения.
Важно отметить, что данный ГОСТ не распространяется на программный документ «Текст программы».
Материалы программного документа должны располагаться в следующей последовательности:
- Титульная часть:
- лист утверждения (не входит в общее количество листов документа);
- титульный лист (первый лист документа);
- аннотация;
- лист содержания;
- текст документа (с рисунками, таблицами и т.п.);
- приложения;
- перечень терминов, перечень сокращений, перечень рисунков, перечень таблиц, предметный указатель, перечень ссылочных документов;
- часть регистрации изменений:
- лист регистрации изменений.
- Программный документ выполняют на одной стороне листа, через два интервала; допускается через один или полтора интервала.
- Аннотацию размещают на отдельной (пронумерованной) странице с заголовком «АННОТАЦИЯ» и не нумеруют как раздел.
- Заголовки разделов пишут прописными буквами и размещают симметрично относительно правой и левой границ текста.
- Заголовки подразделов записывают с абзаца строчными буквами (кроме первой прописной).
- Переносы слов в заголовках не допускаются. Точку в конце заголовка не ставят.
- Расстояние между заголовком и последующим текстом, а также между заголовками раздела и подраздела должно быть равно:
- при выполнении документа машинописным способом — двум интервалам.
- при выполнении документа машинописным способом — трём машинописным интервалам.
В ГОСТе присутствует образец листа, где указаны поля, места для нумерации страниц и шифра.
Примеры
Мои наиболее актуальные (2016 год) шаблоны.
Примеры оформления взяты с данного сайта.
- Описание применения
- Описание программы
- Текст программы
| ГОСТ 19.101-77 | Виды программ и программных документов |
| ГОСТ 19.103-77 | Обозначение программ и программных документов |
| ГОСТ 19.104-78 | Основные надписи |
| ГОСТ 19.105-78 | Общие требования к программным документам |
| ГОСТ 19.106-78 | Требования к программным документам, выполненным печатным способом |
| ГОСТ 19.401-78 | Текст программы |
| ГОСТ 19.402-78 | Описание программы |
| ГОСТ 19.502-78 | Описание применения |
Ссылки
- www.swrit.ru — можно скачать ГОСТы в pdf
- ru.wikipedia.org
Источник: srns.ru
ГОСТ 19.101-77 Виды программ и программных документов
Настоящий стандарт устанавливает виды программ и программных документов для вычислительных машин, комплексов и систем независимо от их назначения и области применения.
Стандарт полностью соответствует СТ СЭВ 1626-79.
1. ВИДЫ ПРОГРАММ
1.1. Программу (по ГОСТ 19781-90) допускается идентифицировать и применять самостоятельно и (или) в составе других программ.
1.2. Программы подразделяют на виды, приведенные в табл. 1
1.3. Документация, разработанная на программу, может использоваться для реализации и передачи программы на носителях данных, а также для изготовления программного изделия.
1.2,1.3. (Измененная редакция, Изм. № 1).
2. ВИДЫ ПРОГРАММНЫХ ДОКУМЕНТОВ
2.1. К программным относят документы, содержащие сведения, необходимые для разработки, изготовления, сопровождения и эксплуатации программ.
(Измененная редакция, Изм. № 1).
| Ведомость эксплуатационных документов | Перечень эксплуатационных документов на программу |
| Формуляр | Основные характеристики программы, комплектность и сведения об эксплуатации программы |
| Описание применения | Сведения о назначении программы, области применения, применяемых методах, классе решаемых задач, ограничениях для применения, минимальной конфигурации технических средств |
| Руководство системного программиста | Сведения для проверки, обеспечения функционирования и настройки программы на условия конкретного применения |
| Руководство программиста | Сведения для эксплуатации программы |
| Руководство оператора | Сведения для обеспечения процедуры общения оператора с вычислительной системой в процессе выполнения программы |
| Описание языка | Описание синтаксиса и семантики языка |
| Руководство по техническому обслуживанию | Сведения для применения тестовых и диагностических программ при обслуживании технических средств |
(Измененная редакция, Изм. № 1).
2.4. В зависимости от способа выполнения и характера применения программные документы подразделяются на подлинник, дубликат и копию (ГОСТ 2.102-68), предназначенные для разработки, сопровождения и эксплуатации программы.
2.5. Виды программных документов, разрабатываемых на разных стадиях, и их коды приведены в табл click. 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)
Источник: www.prj-exp.ru
Информационная безопасность
При проектировании различных систем ИТ, инфраструктуры или систем информационной безопасности, не смотря на явное разграничение для многих менеджеров, не подкованых в технической части, остается «секретом за семья печатями» отличие процессов разработки документации по ГОСТ 34 и ГОСТ 19. В нескольких прошлых статьях мы уже касались описания ГОСТ 34 (разработка АС). Сегодня же хотелось уделить внимание родственному ГОСТ 19 направленному на разработку ПО
Предмет нашего сегодняшнего материала, это размышление на тему АС против ПО или к вопросу о разнице между ГОСТ 34 и ГОСТ 19
И так, давайте обратимся к документах и узнаем, какая разница кроется между родственными ГОСТ 34 и 19
1. ГОСТ 19.781-90 «Единая система программной документации. Программное обеспечение систем обработки информации. Термины и определения» задает следующие определения:
- Программа – данные, предназначенные для управления конкретными компонентами системы обработки информации в целях реализации определенного алгоритма.
- Программное обеспечение – совокупность программ системы обработки информации и программных документов, необходимых для эксплуатации этих программ.
2. ГОСТ 34.003-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения» дает следующее определение:
Автоматизированная система, AC (automated system, AS) – система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций.
В зависимости от вида деятельности выделяют, например, следующие виды АС:
- автоматизированные системы управления (АСУ),
- системы автоматизированного проектирования (САПР),
- автоматизированные системы научных исследований (АСНИ)
В зависимости от вида управляемого объекта (процесса) АСУ делят, например, на:
- АСУ технологическими процессами (АСУТП),
- АСУ предприятиями (АСУП)
При этом ГОСТ 34 выделяет в составе АС следующие виды обеспечения:
- 2.3 организационное
- 2.4 методическое
- 2.5 техническое
- 2.6 математическое
- 2.7 программное обеспечение автоматизированной системы – совокупность программ на носителях данных и программных документов, предназначенная для отладки, функционирования и проверки работоспособности АС
- 2.8 информационное
- 2.9 лингвистическое
- 2.10 правовое
- 2.11 эргономическое
Таким образом, АС не тождественна своему программному обеспечению, а лишь содержит его среди прочих видов обеспечения и других компонент АС, таких как пользователи и эксплуатационный персонал.
В отличие от программного продукта АС не может быть создана в отрыве от конкретной организации/пользователя, растиражирована, продана любому, кто пожелает её приобрести.
АС всегда представляет собой не только техническое, но и организационное решение, затрагивающее порядок работы людей, деятельность которых автоматизируется.
В целом, можно утверждать следующее:
ТЗ по ГОСТ 19.ххх устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения.
То есть ГОСТ 34.ххх. описывает систему в целом, а ГОСТ 19.ххх описывает её программные модули.
Так, согласно «конкурсной дрокументации» комплект документов системы должен разрабатываться в соответствии с ГОСТ 34.ххх. То есть ТЗ на систему в целом описывется по ГОСТ 34.ххх А в качестве примера , ТЗ на одну из подсистем разрабатываемой системы будет написано по ГОСТ 19.ххх .
Источник: ipiskunov.blogspot.com
СПКД123 / СПДК / Единая система программной документации
Единая система программной документации (ЕСПД) — отечественный комплекс стандартов на программную документацию. В профессиональном просторечии его еще называют «девятнадцатым гостом», что не совсем правильно, поскольку речь идет не об одном, а примерно о 30 разных нормативно-технических документах.
В основном стандарты ЕСПД содержат требования к составу, содержанию и оформлению документов, описывающих программу на разных стадиях ее жизненного цикла. Кроме того, несколько документов посвящено порядку хранения и обновления документации.
Стандарты ЕСПД практически лишены методической составляющей. Они не объясняют разработчику, как надо писать документацию, чтобы она получилась полезной, понятной, информативной, удобной и т. д. Они дают только перечень типов документов и список разделов первого уровня для каждого из них. Правда, о каждом разделе сказано, какие сведения должны быть в нем изложены.
Стандарты ЕСПД были приняты в конце 70-х годов и дошли до нас в виде, близком к первоначальному. В них отражена практика работы ведомственных вычислительных центров, где эксплуатировались большие ЭВМ. Взаимодействие человека с компьютерной системой тогда было построено совсем не так, как теперь, и осуществлялось через громоздкие пульты, перфокарты и распечатки, а для «простых смертных», решающих прикладные задачи, еще и при посредничестве квалифицированного персонала. Надо ли долго объяснять, насколько эти стандарты к настоящему времени устарели? Достаточно сказать, что им неведомы такие распространенные сегодня документы, как руководство пользователя и руководство администратора.
И все-таки ими продолжают активно пользоваться. Формально «девятнадцатому» есть современная альтернатива. Переведены на русский язык и приняты в России на правах национальных некоторые стандарты ИСО/МЭК в области системной и программной инженерии. Но крупные, в том числе, государственные заказчики переходить на них не торопятся. Это можно объяснить их косностью (или верностью традиции, как вам больше нравится), но лишь отчасти.
Дело в том, каждый стандарт ЕСПД при небольшом (страницы три максимум) объеме представляет собой набор довольно формальных и поэтому легко проверяемых требований к документу или к комплекту документации. Строго говоря, это не мешает разработчику документации писать правильно оформленные глупости. Но поскольку ЕСПД четко определяет, из чего должен состоять и как должен выглядеть результат, мы можем, по крайней мере, сразу отклонить пачку бумаги, которая в эти рамки не вписывается. Что существенно упрощает задачу сдачи-приемки документации как для заказчика, так и для исполнителя.
Стандарты ИСО/МЭК, напротив, содержат много разумных правил содержательного характера, но сложно представить себе процедуру их формальной проверки. Впрочем, никто не мешает применять оба ряда стандартов одновременно, благо, они касаются разных аспектов документирования и друг другу практически не противоречат.
Состав нормативно-технических документов
Обозначение
Наименование
Единая система программной документации. Общие положения
Источник: studfile.net
Зачем нужны ГОСТы для программной документации?
Часто возникает вопрос: а зачем вообще нужны все эти ГОСТы? Почему вообще нельзя обойтись без них, ведь они такие формальные и старые?
В нашей стране госты серий 19 и 34 часто применяются при создании программ и автоматизированных систем, особенно, когда в качестве заказчиков выступают государственные или крупные коммерческие организации. Стандарты эти таковы, что руководители проектов и разработчики технической документации, сталкиваясь с ними впервые, обычно приходят в замешательство.
Отчасти это связано с объемом стандартов и своеобразием употребляемой в них терминологии, но в первую очередь наверно все-таки с тем, что начинающие не видят смысла в стандартизированной технической документации. У них складывается впечатление, что госты – бюрократическое наследие Советского Союза, по недоразумению продолжающее отравлять нам жизнь.
Программы и автоматизированные системы
Бывают программы, а бывают автоматизированные системы. Еще бывают аппаратно-программные комплексы и много разных других видов продукции, но пока мы их для простоты оставим в покое.
Под программой обычно подразумевают машинный код (часто еще добавляют, представленный в объективной форме), который может быть выполнен компьютером. Если вы на языке PHP написали скрипт, формирующий страничку с надписью «Слава труду!», то вы произвели на свет программу. Вы можете поместить эту программу в подходящие условия, например, на компьютер, где уже функционируют интерпретатор PHP и какой-нибудь HTTP-сервер, и она будет работать. Если к тому же вы допускаете применение этого скрипта более-менее широким кругом лиц и обеспечили им такую возможность, то получился программный продукт.
Теперь представим себе, что Министерство труда и занятости решило в целях повышения трудолюбия населения страны создать сайт, на главной странице которого при загрузке отображается какой-нибудь полезный лозунг. Для этого оно делает следующее:
– выделяет в здании министерства кабинет;
– ставит в этот кабинет компьютер и подключает его к Интернету;
– устанавливает на этот компьютер HTTP-сервер Apache, интерпретатор PHP и ваш скрипт;
– вменяет в обязанность кому-нибудь из сотрудников раз в неделю менять текст лозунга.
В результате этой работы возникает автоматизированная система. Что она в себя включает? Прежде всего, мы наблюдаем целенаправленную автоматизированную деятельность, в данном случае пропагандистскую работу. Осуществляет ее назначенный для этого персонал, пускай даже в количестве одного человека.
Наконец, у системы есть технические средства (компьютер) и программное обеспечение (операционная система, интерпретатор PHP, HTTP-сервер Apache и скрипт). Вообще говоря, автоматизированная система может включать в себя много чего еще, но четыре перечисленные составляющие обязательны, иначе это не автоматизированная система.
Участники разработки
В процессе создания программы или автоматизированной системы всегда обязательно есть три роли: разработчик, заказчик и пользователь. Это утверждение может показаться странным, потому что если фирма производит программный продукт и продает его в магазине, то какой же там заказчик? И какое участие в его создании программного продукта или автоматизированной системы принимает пользователь?
Какой-то заказчик есть всегда. В компании, которая выпускает программные продукты, эта функция возлагаются на сотрудников, например, на менеджеров по продуктам, выставляющих производственным подразделениям внутренний заказ. На практике это далеко не всегда соблюдается, но тогда довольно быстро разработка приходит в состояние, именуемое в просторечии бардаком.
То же самое касается разработки автоматизированной системы силами организации для собственных нужд. Участников необходимо поделить на две команды, разработчиков и заказчиков. Иначе вместо целенаправленной работы по созданию системы получится тот самый ремонт, который, по словам классика, нельзя закончить, а можно только прекратить.
Случается, что пользователи принимают непосредственное участие в разработке программ и автоматизированных систем. Аналитики могут опрашивать их на стадии формирования требований, пользователи могут принимать участие в тестировании и т.п. Но это не главное. Гораздо важнее, что программные продукты и системы разрабатываются на базе многочисленных в разной степени обоснованных предположений о целях, задачах, свойствах и действиях пользователей. Образно говоря, пользователь остается за кадром, но на всем мы видим его гигантскую тень.
Типы и функции технической документации
Абстрагируясь от различий между разными стандартами, методологиями и другими источниками знания, мы можем сказать, что развитие любой продукции проистекает следующим образом:
– заказчик и разработчик решают, что и зачем они собираются создать;
– разработчик создает, а заказчик принимает продукцию;
– результат передается пользователю для целевого применения.
Исходя из этого техническую документацию можно условно разделить на два типа: документацию разработки и документацию продукции. Документацией разработки обмениваются друг с другом непосредственные участники этой деятельности. Документацию продукции передают пользователю (в широком смысле), чтобы он мог применять программу или автоматизированную систему по назначению. Некоторые стандарты выделяют еще третий тип: документацию управления проектом, но это документы скорее организационно-распорядительного, чем технического характера, и здесь мы их рассматривать не будем.
Очевидная функция технической документации – сохранение и передача всевозможных сведений технического характера. Из этих соображений техническая документация должна быть как можно более понятной, информативной, удобной и т.п. Формализовать эти качества сложно, но можно, существуют стандарты и методики, в которых это с большим или меньшим успехом делается.
Другая важная функция технической документации нормативная. Техническая документация при должном ее оформлении (например, в качестве приложения к договору на создание программы или автоматизированной системы) фиксирует взаимные обязательства участников разработки. Госты серий 19 и 34 в значительной мере направлены на то, чтобы техническая документация эффективно работала в этом качестве.
Стандартизация документации разработки
Разработка программ и автоматизированных систем – это не вечеринка, которая может оказаться удачной или не очень, но в конце концов все разъедутся по домам, а сложная, продолжительная и дорогостоящая деятельность, в которую вовлечены разные организации (или их подразделения), специалисты, начальники разного ранга. У них есть свои групповые и персональные интересы.
Если что-то пойдет не так, например, на программный продукт не окажется спроса, или внедрение автоматизированной системы провалится, то пострадавшие примутся искать виноватого, а когда найдут, попытаются получить с него моральную и материальную компенсацию в максимально возможном размере. Поскольку оказаться крайним и «остаться без штанов» обычно никто не хочет, каждый заинтересован в как можно более четком ограничении собственной зоны и меры ответственности. На уровне финансов, сроков, имущественных прав и т.п. взаимные обязательства фиксируются в договорах. На содержательном уровне – в технической документации.
По завершении каждой стадии создания программы или автоматизированной системы заказчик и разработчик фиксируют полученные результаты в технической документации и утверждают последнюю. Это линия отреза. После того, как техническая документация утверждена, пересмотр ее содержания заказчиком или разработчиком в одностороннем порядке юридически невозможен.
Пример 1. Если в утвержденном техническом задании (ТЗ) на автоматизированную систему сказано, что посетитель сайта должен видеть лозунг «Слава труду», заказчик не имеет права вдруг потребовать еще и демонстрации рекламного ролика на эту тему. Вполне возможно, что показывать ролик — неплохая идея, но заказчику следовало высказать ее раньше, когда разработчик согласовывал с ним техническое задание. С другой стороны, если вместо положенного текста система будет выдавать рекламу ночного клуба, у заказчика появятся все основания потребовать от разработчика внесения в систему необходимых изменений, и не платить ему денег, пока система не будет приведена в соответствие техническому заданию.
Пример 2. Если в утвержденном техническом проекте зафиксировано, что для реализации автоматизированной системы используется скрипт на PHP, разработчик не имеет права огорошить заказчика предложением вместо бесплатного интерпретатора этого языка приобрести Lotus Domino.
Но, с другой стороны, и заказчик не может потребовать от разработчика вместо нормального сервера использовать компьютер БК 0010, завалявшийся в кладовке с советских времен. Бюрократически правильное ведение технической документации заставляет всех участников разработки вести себя предсказуемо по отношению друг к другу, что конечном счете, всем выгодно, несмотря на дополнительные затраты. Ведение технической документации позволяет предотвратить многие недоразумения и злоупотребления. В том случае, если заказчик и разработчик так испортят отношения, что дело дойдет до арбитража, техническая документация будет служить для ущемленной стороны средством доказать свою правоту. Без технической документации вероятность и болезненность всевозможных склок и «разборок» сильно повышается.
Всякая бюрократизация подразумевает соблюдение определенных форм. Формы договоров и основных финансовых документов продиктованы законодательством. Аналогично, формы технических документов продиктованы гостами. При этом техническая документация на программы описывается Единой системой программной документации (ГОСТ 19), а техническая документация на автоматизированные системы Комплексом стандартов на автоматизированные системы (ГОСТ 34).
Стандартизация документации продукции
Документация продукции (или, иными словами, эксплуатационная документация) фактически представляет собой часть этой продукции, поскольку без нее целевое применение последней невозможно или сильно затруднено. Стандартизация эксплуатационной документации позволяет не описывать в договоре или в техническом задании подробные требования к эксплуатационной документации, а сослаться на соответствующие стандарты или их разделы.
Требования к составу и содержанию эксплуатационной документации на программу приведены в гостах серии 19. Требования к составу и содержанию эксплуатационной документации на автоматизированную систему приведены в гостах серии 34.
Обязательность соблюдения гостов
В России действует федеральный закон «О техническом регулировании», в соответствии с которым соблюдение стандартов (за исключением некоторых) дело добровольное. Хорошо ли это, вопрос второй, но на данный момент времени дело обстоит именно так. Соблюдение определенного стандарта становится обязательным для заказчика и разработчика, если они включают это условие в договор. Правда, ограничиваться одним этим условием опасно, в самом договоре или в каком-нибудь из приложений к нему полезно привести более четкие требования к технической документации, но это уже другая тема.
Источник: techwrconsult.com