Главная > Компьютеры  > Гост стандарт документирования программного обеспечения. Подготовка документации на программу по гост Гост для программного обеспечения

Гост стандарт документирования программного обеспечения. Подготовка документации на программу по гост Гост для программного обеспечения

Программы для ЭВМ оформляются в соответствии с требованиями Единой системы программной документации (ЕСПД) . ЕСПД - набор ГОСТов, устанавливающих правила оформления, содержание, структуру программных документов.
Данный 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-й серии ГОСТ ЕСПД. Но уже тогда у программистов возникало много претензий к этим стандартам. Что-то требовалось неоправданно дублировать в документации много раз, а многое не было предусмотрено, например, отражение специфики документирования программ, работающих с базой данных.

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

2. Общая характеристика состояния

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

Стандарты ЕСПД охватывают ту часть документации, которая создается в процессе разработки программы, и связаны с документированием функциональных характеристик. Не стоит забывать, что стандарты ЕСПД (ГОСТ 19) носят рекомендательный характер. Впрочем, это относится и к другим стандартам в области разработки программ таким, как: ГОСТ 34, Международному стандарту ISO/IEC, и др. В соответствии с Законом РФ «О стандартизации» эти стандарты становятся обязательными только на контрактной основе – то есть при ссылке на них в договоре на разработку программы.

Говоря о состоянии ЕСПД в целом, можно констатировать, что большая часть стандартов морально устарела.

К основным недостаткам ЕСПД можно отнести:

  • ориентацию на единственную, «каскадную» модель жизненного цикла программы;
  • отсутствие четких рекомендаций по документированию характеристик качества;
  • отсутствие связей с другими действующими отечественными системами стандартов, например ЕСКД;
  • плохо выраженный подход к документированию программы, как товарной продукции;
  • отсутствие рекомендаций по внутреннему документированию, как например экранные меню, справка по работе с программой итд.;
  • отсутствие рекомендаций по составу, содержанию и оформлению документов на программу, согласованных с международными и региональными стандартами.

Из этого выходит, что ЕСПД нуждается в полном пересмотре на основе стандарта ИСО/МЭК 12207-95, (об этом стандарте далее будет расказанно более подробнее).

Стоит заметить что, кроме ЕСПД в официальной нормативной базе РФ в области документирования программ и в смежных областях есть ряд перспективных стандартов, например:

  • международный стандарт ISO/IEC 12207: 1995-08-01 на организацию жизненного цикла продуктов программного обеспечения.
  • Стандарты комплекса ГОСТ 34 на создание и развитие автоматизированных систем.

2.1. Краткое описание имеющихся стандартов ЕСПД

Даже не смотря на свои недостатки многие стандарты ЕСПД могут с пользой применяться для документирования программ по тому что:

  • стандарты ЕСПД вносят характерный порядок в процесс документирования программ;
  • предусмотренный стандартами ЕСПД состав программных документов возможно видоизменять внося в комплект документации дополнительные виды документов.
  • стандарты ЕСПД позволяют изменять структуру и содержание исходя из конкретных требований заказчика и пользователя.

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

Стандарты ЕСПД подразделяют на группы, приведнные в таблице:

Обозначение стандарта ЕСПД строят по классификационному признаку:

Обозначение стандарта ЕСПД должно состоять из:

  • числа 19 (присвоенных классу стандартов ЕСПД);
  • одной цифры (после точки), обозначающей код классификационной группы стандартов, указанной таблице;
  • двузначного числа (после тире), указывающего год регистрации стандарта.

Перечень документов ЕСПД:

  1. ГОСТ 19.001-77 ЕСПД. Общие положения.
  2. ГОСТ 19.101-77 ЕСПД. Виды программ и программных документов.
  3. ГОСТ 19.102-77 ЕСПД. Стадии разработки.
  4. ГОСТ 19.103-77 ЕСПД. Обозначение программ и программных документов.
  5. ГОСТ 19.104-78 ЕСПД. Основные надписи.
  6. ГОСТ 19.105-78 ЕСПД. Общие требования к программным документам.
  7. ГОСТ 19.106-78 ЕСПД. Требования к программным документам, выполненным печатным способом.
  8. ГОСТ 19.201-78 ЕСПД. Техническое задание. Требования к содержанию и оформлению.
  9. ГОСТ 19.202-78 ЕСПД. Спецификация. Требования к содержанию и оформлению.
  10. ГОСТ 19.301-79 ЕСПД. Порядок и методика испытаний.
  11. ГОСТ 19.401-78 ЕСПД. Текст программы. Требования к содержанию и оформлению.
  12. ГОСТ 19.402-78 ЕСПД. Описание программы.
  13. ГОСТ 19.404-79 ЕСПД. Пояснительная записка. Требования к содержанию и оформлению.
  14. ГОСТ 19.501-78 ЕСПД. Формуляр. Требования к содержанию и оформлению.
  15. ГОСТ 19.502-78 ЕСПД. Описание применения. Требования к содержанию и оформлению.
  16. ГОСТ 19.503-79 ЕСПД. Руководство системного программиста. Требования к содержанию и оформлению.
  17. ГОСТ 19.504-79 ЕСПД. Руководство программиста.
  18. ГОСТ 19.505-79 ЕСПД. Руководство оператора.
  19. ГОСТ 19.506-79 ЕСПД. Описание языка.
  20. ГОСТ 19.508-79 ЕСПД. Руководство по техническому обслуживанию. Требования к содержанию и оформлению.
  21. ГОСТ 19.604-78 ЕСПД. Правила внесения изменений в программные документы, выполняемые печатным способом.
  22. ГОСТ 19.701-90 ЕСПД. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения.
  23. ГОСТ 19.781-90. Обеспечение систем обработки информации программное.

Термины и определения

Из всех стандартов ЕСПД мы остановимся на тех, которые могут чаще использоваться в практике разработки программы.

Первым стандартом, который можно использовать при формировании технических заданий на программирование является ГОСТ (СТ СЭВ) 19.201-78 (1626-79). ЕСПД.
(Техническое задание. Требование к содержанию и оформлению.).

Техническое задание на разработку программы содержит совокупность требований к программе и может использоваться как набор критериев необходимых для проверки и приемки разработанной программы. Поэтому достаточно полно составленное техническое задание является одним из первоначальных документов проекта.

В техническое задание на разработку программы необходимо включить следующие разделы:

  • введение;
  • основания для разработки;
  • назначение разработки;
  • требования к программе или программному изделию;
  • требования к программной документации ;
  • технико-экономические показатели;
  • стадии и этапы разработки;
  • порядок контроля и приемки;
  • различные приложения (по необходимости).

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

Вторым стандартом является ГОСТ (СТ СЭВ) 19.101-77 (1626-79). ЕСПД.
Виды программ и программных документов).
Этот стандарт устанавливает виды программ и программных документов для вычислительных машин, комплексов и систем независимо от их назначения и области применения.

Виды программ:

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

Вид программного документа Содержание программного документа
Спецификация Состав программы и документации на нее
Перечень предприятий, на которых хранят подлинники программных документов
Текст программы Запись программы с необходимыми комментариями
Описание программы Сведения о логической структуре и функционировании программы
Требования, подлежащие проверке при испытании программы, а также порядок и методы их контроля
Техническое задание Назначение и область применения программы, технические, технико-экономические и специальные требования, предъявляемые к программе, необходимые стадии и сроки разработки, виды испытаний
Пояснительная записка Схема алгоритма, общее описание алгоритма и (или) функционирования программы, а также обоснование принятых технических и технико-экономических решений
Эксплуатационные документы Сведения для обеспечения функционирования и эксплуатации программы

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

Вид эксплуатационного документа Содержание эксплуатационного документа
Перечень эксплуатационных документов на программу
Формуляр Основные характеристики программы, комплектность и сведения об эксплуатации программы
Описание применения Сведения о назначении программы, области применения, применяемых методах, классе решаемых задач, ограничениях для применения, минимальной конфигурации технических средств
Сведения для проверки, обеспечения функционирования и настройки программы на условия конкретного применения
Руководство программиста Сведения для эксплуатации программы
Руководство оператора Сведения для обеспечения процедуры общения оператора с вычислительной системой в процессе выполнения программы
Описание языка Описание синтаксиса и семантики языка
Сведения для применения тестовых и диагностических программ при обслуживании технических средств

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

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

Код вида документа Вид документа Стадии разработки
Эскизный проект Технический проект Рабочий проект
компонент комплекс
- Спецификация - - ! +
05 Ведомость держателей подлинников - - - ?
12 Текст программы - - + ?
13 Описание программы - - ? ?
20 Ведомость эксплуатационных документов - - ? ?
30 Формуляр - - ? ?
31 Описание применения - - ? ?
32 Руководство системного программиста - - ? ?
33 Руководство программиста - - ? ?
34 Руководство оператора - - ? ?
35 Описание языка - - ? ?
46 Руководство по техническому обслуживанию - - ? ?
51 Программа и методика испытаний - - ? ?
81 Пояснительная записка ? ? - -
90-99 Прочие документы ? ? ? ?

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

…………………………………………………………

ГОСТ 19.102-77. ЕСПД. Стадии разработки.

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

Стадии разработки программы, этапы и содержание работ

Стадии разработки Этапы работ Содержание работ
Техническое задание Обоснование необходимости разработки программы Постановка задачи.
Сбор исходных материалов.
Выбор и обоснование критериев эффективности и качества разрабатываемой программы.
Обоснование необходимости проведения научно-исследовательских работ.
Научно-исследовательские работы Определение структуры входных и выходных данных.
Предварительный выбор методов решения задач.
Обоснование целесообразности применения ранее разработанных программ.
Определение требований к техническим средствам.
Обоснование принципиальной возможности решения поставленной задачи.
Разработка и утверждение технического задания Определение требований к программе.
Разработка технико-экономического обоснования разработки программы.
Определение стадий, этапов и сроков разработки программы и документации на нее.
Выбор языков программирования.
Определение необходимости проведения научно-исследовательских работ на последующих стадиях.
Согласование и утверждение технического задания.
Эскизный проект Разработка эскизного проекта Предварительная разработка структуры входных и выходных данных.
Уточнение методов решения задачи.
Разработка общего описания алгоритма решения задачи.
Разработка технико-экономического обоснования.
Утверждение эскизного проекта Разработка пояснительной записки.
Согласование и утверждение эскизного проекта
Технический проект Разработка технического проекта Уточнение структуры входных и выходных данных.
Разработка алгоритма решения задачи.
Определение формы представления входных и выходных данных.
Определение семантики и синтаксиса языка.
Разработка структуры программы.
Окончательное определение конфигурации технических средств.
Утверждение технического проекта Разработка плана мероприятий по разработке и внедрению программ.
Разработка пояснительной записки.
Согласование и утверждение технического проекта.
Рабочий проект Разработка программы Программирование и отладка программы
Разработка программной документации Разработка программных документов в соответствии с требованиями ГОСТ 19.101-77.
Испытания программы Разработка, согласование и утверждение программы и методики испытаний.
Проведение предварительных государственных, межведомственных, приемо-сдаточных и других видов испытаний.
Корректировка программы и программной документации по результатам испытаний.
Внедрение Подготовка и передача программы Подготовка и передача программы и программной документации для сопровождения и (или) изготовления.
Оформление и утверждение акта о передаче программы на сопровождение и (или) изготовление.
Передача программы в фонд алгоритмов и программ.

Примечания:

  1. Допускается исключать вторую стадию разработки, а в технически обоснованных случаях – вторую и третью стадии. Необходимость проведения этих стадий указывается в техническом задании.
  2. Допускается объединять, исключать этапы работ и (или) их содержание, а также вводить другие этапы работ по согласованию с заказчиком.

ГОСТ 19.103-77 ЕСПД. Обозначение программ и программных документов

Код страны-разработчика и код организации-разработчика присваивают в установленном порядке.

  • Регистрационный номер присваивается в порядке возрастания, начиная с 00001 до 99999, для каждой организации-разработчика.
  • Номер издания программы или номер редакции. номер документа данного вида, номер части документа присваиваются в порядке возрастания с 01 до 99. (Если документ состоит из одной части, то дефис и порядковый номер части не указывают).
  • Номер редакции спецификации и ведомости эксплуатационных документов на программу должны совпадать с номером издания этой же программы.

ГОСТ 19.105-78 ЕСПД. Общие требования к программным документам

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

Программный документ может быть представлен на различных типах носителей данных и состоит из следующих условных частей:
титульной;
информационной;
основной.

Правила оформления документа и его частей на каждом носителе данных устанавливаются стандартами ЕСПД на правила оформления документов на соответствующих носителях данных.

ГОСТ 19.106-78 ЕСПД. Требования к программным документам, выполненным печатным способом

Программные документы оформляют:

  • на листах формата А4 (ГОСТ 2.301-68) при изготовлении документа машинописным или рукописным способом;
  • допускается оформление на листах формата А3;
  • при машинном способе выполнения документа допускаются отклонения размеров листов, соответствующих форматам А4 и А3, определяемые возможностями применяемых технических средств; на листах форматов А4 и А3, предусматриваемых выходными характеристиками устройств вывода данных, при изготовлении документа машинным способом;
  • на листах типографических форматов при изготовлении документа типографским способом.

Расположение материалов программного документа осуществляется в следующей последовательности:

Титульная часть:

  • лист утверждения (не входит в общее количество листов документа);
  • титульный лист (первый лист документа);
информационная часть:
  • аннотация;
  • лист содержания;
основная часть:
  • текст документа (с рисунками, таблицами и т.п.)
  • перечень терминов и их определений;
  • перечень сокращений;
  • приложения;
  • предметный указатель;
  • перечень ссылочных документов;
часть регистрации изменений:
  • лист регистрации изменений.

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

Следующий стандарт ориентирован на документирование результирующего продукта разработки:

ГОСТ 19.402-78 ЕСПД. Описание программы

Состав документа «Описание программы» в своей содержательной части может дополняться разделами и пунктами, почерпнутыми из стандартов для других описательных документов и руководств: ГОСТ 19.404-79 ЕСПД. Пояснительная записка, ГОСТ 19.502-78 ЕСПД. Описание применения, ГОСТ 19.503-79 ЕСПД. Руководство системного программиста, ГОСТ 19.504-79 ЕСПД. Руководство программиста, ГОСТ 19.505-79 ЕСПД. Руководство оператора.

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

Надо также выделить

ГОСТ 19.301-79 ЕСПД. Программа и методика испытаний, который (в адаптированном виде) может использоваться для разработки документов планирования и проведения испытательных работ по оценке готовности и качества ПС.

Наконец, последний по году принятия стандарт.

ГОСТ 19.701-90 ЕСПД. Схемы алгоритмов, программ, данных и систем. Обозначения условные графические и правила выполнения.

Он устанавливает правила выполнения схем, используемых для отображения различных видов задач обработки данных и средств их решения и полностью соответствует стандарту ИСО 5807:1985.

Наряду с ЕСПД на межгосударственном уровне действуют еще два стандарта, также относящихся к документированию ПС и принятых не так давно, как большая часть ГОСТ ЕСПД.

ГОСТ 19781-90 Обеспечение систем обработки информации программное. Термины и определения. Разработан взамен ГОСТ 19.781-83 и ГОСТ 19.004-80 и устанавливает термины и определения понятий в области программного обеспечения (ПО) систем обработки данных (СОД), применяемые во всех видах документации и литературы, входящих в сферу работ по стандартизации или использующих результаты этих работ.

ГОСТ 28388-89 Системы обработки информации. Документы на магнитных носителях данных. Порядок выполнения и обращения. Распространяется не только на программные, но и на конструкторские, технологические и другие проектные документы, выполняемые на магнитных носителях.

2.2. Стандарты комплекса ГОСТ 34

ГОСТ 34 задумывался в конце 80-х годов как всеобъемлющий комплекс взаимоувязанных межотраслевых документов. Мотивы и получившиеся результаты описаны ниже в «Особенностях» ГОСТ 34. Объектами стандартизации являются АС различных (любых!) видов и все виды их компонентов, а не только ПО и БД.

Комплекс рассчитан на взаимодействие заказчика и разработчика. Аналогично ISO12207 предусмотрено, что заказчик может разрабатывать АС для себя сам (если создаст для этого специализированное подразделение). Однако формулировки ГОСТ 34 не ориентированы на столь явное и, в известном смысле, симметричное отражение действий обеих сторон, как ISO12207. Поскольку ГОСТ 34 в основном уделяет внимание содержанию проектных документов, распределение действий между сторонами обычно делается отталкиваясь от этого содержания.

Из всех существующих и не реализованных групп документов будем основываться только на Группе 0 «Общие положения» и Группе 6 «Создание, функционирование и развитие АС» . Наиболее популярными можно считать стандарты ГОСТ 34.601-90 (Стадии создания АС), ГОСТ 34.602-89 (ТЗ на создание АС) и методические указания РД 50-34.698-90 (Требования к содержанию документов) . Стандарты предусматривают стадии и этапы выполнения работ по созданию АС, но не предусматривают сквозных процессов в явном виде.

Для общего случая разработки АС стадии и этапы ГОСТ 34 приведены в таблице:

1. ФТ – Формирование требований к АС. 1.1. Обследование объекта и обоснование необходимости создания АС;
1.2. Формирование требований пользователя к АС;
1.3. Оформление отчета о выполненной работе и заявки на разработку АС (тактико-технического задания);
2. РК – Разработка концепции АС. 2.1. Изучение объекта;
2.2. Проведение необходимых научно-исследовательских работ;
2.3. Разработка вариантов концепции АС, удовлетворяющей требованиям пользователя
2.4. Оформление отчета о выполненной работе
3. ТЗ – Техническое создание АС. 3.1. Разработка и утверждение технического задания на задание.
4. ЭП – Эскизный проект. 4.1. Разработка предварительных проектных решений по системе и ее частям;
4.2. Разработка документации на АС и ее части.
5. ТП – Технический проект. 5.1. Разработка проектных решений по системе и ее частям;
5.2. Разработка документации на АС и ее части;
5.3. Разработка и оформление документации на поставку изделий для комплектования АС и/или технических требований (технических заданий) на их разработку;
5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации.
6. РД – Рабочая документация. 6.1. Разработка рабочей документации на систему и ее части;
6.2. Разработка или адаптация программ.
7. ВД – Ввод в действие. 7.1. Подготовка объекта автоматизации к вводу АС в действие;
7.2. Подготовка персонала;
7.3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями);
7.4. Строительно-монтажные работы;
7.5. Пуско-наладочные работы;
7.6. Проведение предварительных испытаний;
7.7. Проведение опытной эксплуатации;
7.8. Проведение приемочных испытаний.
8. Сп – Сопровождение АС. 8.1. Выполнение работ в соответствии с гарантийными обязательствами;
8.2. Послегарантийное обслуживание.

Описано содержание документов, разрабатываемых на каждом этапе. Это определяет потенциальные возможности выделения на содержательном уровне сквозных работ, выполняемых параллельно или последовательно (то есть по сути – процессов), и составляющих их задач. Такой прием может использоваться при построении профиля стандартов ЖЦ проекта, включающего согласованные подмножества стандартов ГОСТ 34 и ISO12207.

Главный мотив: разрешить проблему «вавилонской башни».

В 80-х годах сложилось положение, при котором в различных отраслях и областях деятельности использовалась плохо согласованная или несогласованная НТД – «нормативно-техническая документация». Это затрудняло интеграцию систем, обеспечение их эффективного совместного функционирования. Действовали различные комплексы и системы стандартов, устанавливающие требования к различным видам АС.

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

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

В этих условиях можно было провести анализ такого многообразия и далее поступить, например, одним из двух во многом противоположных способов:

  1. Выработать одну обобщенную понятийную и терминологическую систему, общую схему разработки, общий набор документов с их содержанием и определить их как обязательные для всех АС;
  2. Определить также одну общую понятийную и терминологическую систему, обобщенный комплекс системных требований, набор критериев качества, но предоставить максимальную свободу в выборе схемы разработки, состава документов и других аспектов, наложив только минимум обязательных требований, которые позволяли бы:
    • определять уровень качества результата;
    • выбирать те конкретные методики (с их моделями ЖЦ, набором документов и др.), которые наиболее подходят к условиям разработки и соответствуют используемым Информационным Технологиям;
    • работать, таким образом, с минимальными ограничениями эффективных действий проектировщика АС.

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

Степень адаптивности формально определяется возможностями:

  • опускать стадию эскизного проектирования и объединять стадии «Технический проект» и «Рабочая документация»;
  • опускать этапы, объединять и опускать большинство документов и их разделов;
  • вводить дополнительные документы, разделы документов и работы;
  • динамически создавая т. н. ЧТЗ – частные технические задания – достаточно гибко формировать ЖЦ АС; как правило, этот прием используется на уровне крупных единиц (подсистем, комплексов), ради которых считается оправданным создавать ЧТЗ, однако нет никаких существенных оснований сильно ограничивать этот способ управления ЖЦ.

Стадии и этапы, выполняемые организациями – участниками работ по созданию АС, устанавливаются в договорах и техническом задании, что близко к подходу ISO.

Введение единой, достаточно качественно определенной терминологии, наличие достаточно разумной классификации работ, документов, видов обеспечения и др. безусловно полезно. ГОСТ 34 способствует более полной и качественной стыковке действительно разных систем, что особенно важно в условиях, когда разрабатывается все больше сложных комплексных АС, например, типа CAD-CAM, которые включают в свой состав АСУТП, АСУП, САПР-конструктора, САПР-технолога, АСНИ и др. системы.

Определено несколько важных положений, отражающих особенности АС как объекта стандартизации, например: «в общем случае АС состоит из программно-технических (ПТК), программно-методических (ПМК) комплексов и отдельных компонентов организационного, технического, программного и информационного обеспечения».

Разделение понятий ПТК и АС закрепляло принцип, по которому АС есть не «ИС с БД», но:

  • «организационно-техническая система, обеспечивающая выработку решений на основе автоматизации информационных процессов в различных сферах деятельности (управление, проектирование, производство и т. д.) или их сочетаниях» (по РД 50-680-88), что особенно актуально в аспектах бизнес-реинжиниринга;
  • «система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций» (по ГОСТ 34.003-90).

Эти определения указывают на то, что АС – это, в первую очередь, персонал, принимающий решения и выполняющий другие управляющие действия, поддержанный организационно-техническими средствами.

Степень обязательности:

прежняя полная обязательность отсутствует, материалы ГОСТ34 по сути стали методической поддержкой, причем чаще для заказчиков, имеющих в стандарте набор требований к содержанию ТЗ и проведению испытаний АС. При этом польза ГОСТ34 может многократно возрасти в случае их более гибкого использования при формировании профиля ЖЦ АС.

Ключевым документом взаимодействия сторон является ТЗ – техническое задание на создание АС. ТЗ является основным исходным документом для создания АС и его приемки, ТЗ определяет важнейшие точки взаимодействия заказчика и разработчика. При этом ТЗ разрабатывает организация-разработчик (по ГОСТ 34.602-89), но формально выдает ТЗ разработчику заказчик (по РД 50-680-88).

2.3. Государственные стандарты РФ (ГОСТ Р)

В РФ действует ряд стандартов в части документирования ПС, разработанных на основе прямого применения международных стандартов ИСО. Это? самые «свежие» по времени принятия стандарты. Некоторые из них впрямую адресованы руководителям проекта или директорам информационных служб. Вместе с тем они неоправданно мало известны в среде профессионалов. Вот их представление.

ГОСТ Р ИСО/МЭК 9294-93 Информационная технология. Руководство по управлению документированием программного обеспечения. Стандарт полностью соответствует международному стандарту ИСО/МЭК ТО 9294:1990 и устанавливает рекомендации по эффективному управлению документированием ПС для руководителей, отвечающих за их создание. Целью стандарта является оказание помощи в определении стратегии документирования ПС; выборе стандартов по документированию; выборе процедур документирования; определении необходимых ресурсов; составлении планов документирования.

ГОСТ Р ИСО/МЭК 9126-93 Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению. Стандарт полностью соответствует международному стандарту ИСО/МЭК 9126:1991. В его контексте под характеристикой качества понимается «набор свойств (атрибутов) программной продукции, по которым ее качество описывается и оценивается». Стандарт определяет шесть комплексных характеристик, которые с минимальным дублированием описывают качество ПС (ПО, программной продукции): функциональные возможности; надежность; практичность; эффективность; сопровождаемость; мобильность. Эти характеристики образуют основу для дальнейшего уточнения и описания качества ПС.

ГОСТ Р ИСО 9127-94 Системы обработки информации. Документация пользователя и информация на упаковке для потребительских программных пакетов. Стандарт полностью соответствует международному стандарту ИСО 9127:1989. В контексте настоящего стандарта под потребительским программным пакетом (ПП) понимается «программная продукция, спроектированная и продаваемая для выполнения определенных функций; программа и соответствующая ей документация, упакованные для продажи как единое целое». Под документацией пользователя понимается документация, которая обеспечивает конечного пользователя информацией по установке и эксплуатации ПП. Под информацией на упаковке понимают информацию, воспроизводимую на внешней упаковке ПП. Ее целью является предоставление потенциальным покупателям первичных сведений о ПП.

ГОСТ Р ИСО/МЭК 8631-94 Информационная технология. Программные конструктивы и условные обозначения для их представления. Описывает представление процедурных алгоритмов.

2.4. Международный стандарт ISO/IEC 12207: 1995-08-01

Первая редакция ISO12207 подготовлена в 1995 году объединенным техническим комитетом ISO/IEC JTC1 «Информационные технологии, подкомитет SC7, проектирование программного обеспечения».

По определению, ISO12207 – базовый стандарт процессов ЖЦ ПО, ориентированный на различные (любые!) виды ПО и типы проектов АС, куда ПО входит как часть. Стандарт определяет стратегию и общий порядок в создании и эксплуатации ПО, он охватывает ЖЦ ПО от концептуализации идей до завершения ЖЦ.

Очень важные ЗАМЕЧАНИЯ СТАНДАРТА:

  1. Процессы, используемые во время ЖЦ ПО, должны быть совместимы с процессами, используемыми во время ЖЦ АС. (Отсюда понятна целесообразность совместного использования стандартов на АС и на ПО.)
  2. Добавление уникальных или специфических процессов, действий и задач должно быть оговорено в контракте между сторонами. Контракт понимается в широком смысле: от юридически оформленного контракта до неформального соглашения, соглашение может быть определено и единственной стороной как задача, поставленная самому себе.
  3. Стандарт принципиально не содержит конкретные методы действий, тем более – заготовки решений или документации. Он описывает архитектуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить услуги и задачи, включенные в процессы, не предназначен для предписывания имени, формата или точного содержимого получаемой документации. Решения такого типа принимаются использующим стандарт.

ОПРЕДЕЛЕНИЯ СТАНДАРТА:

  1. Система – это объединение одного или более процессов, аппаратных средств, программного обеспечения, оборудования и людей для обеспечения возможности удовлетворения определенных потребностей или целей.
  2. Модель жизненного цикла – структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения программного продукта в течение всей жизни системы, от определения требований до завершения ее использования.
    Множество процессов и задач сконструировано так, что возможна их адаптация в соответствии с проектами ПО. Процесс адаптации является процессом исключения процессов, видов деятельности и задач, не применимых в конкретном проекте. Степень адаптивности: максимальная
  3. Требование квалификации – набор критериев или условий (квалификационные требования), которые должны быть удовлетворены для того, чтобы квалифицировать программный продукт как подчиняющийся (удовлетворяющий условиям) его спецификациям и готовый для использования в целевой окружающей среде.

Стандарт не предписывает конкретную модель ЖЦ или метод разработки ПО, но определяет, что стороны-участники использования стандарта ответственны за выбор модели ЖЦ для проекта ПО, за адаптацию процессов и задач стандарта к этой модели, за выбор и применение методов разработки ПО, за выполнение действий и задач, подходящих для проекта ПО.

Стандарт ISO12207 равносильно ориентирован на организацию действий каждой из двух сторон: поставщик (разработчик) и покупатель (пользователь); может быть в равной степени применен, когда обе стороны – из одной организации.

Каждый процесс ЖЦ разделен на набор действий, каждое действие – на набор задач. Очень важное отличие ISO: каждый процесс, действие или задача инициируется и выполняется другим процессом по мере необходимости, причем нет заранее определенных последовательностей (естественно, при сохранении логики связей по исходным сведениям задач и т. п.).

В стандарте ISO12207 описаны:

  1. 5 основных процессов ЖЦ ПО:
    • Процесс приобретения. Определяет действия предприятия-покупателя, которое приобретает АС, программный продукт или сервис ПО.
    • Процесс поставки. Определяет действия предприятия-поставщика, которое снабжает покупателя системой, программным продуктом или сервисом ПО.
    • Процесс разработки. Определяет действия предприятия-разработчика, которое разрабатывает принцип построения программного изделия и программный продукт.
    • Процесс функционирования. Определяет действия предприятия-оператора, которое обеспечивает обслуживание системы (а не только ПО) в процессе ее функционирования в интересах пользователей. В отличие от действий, которые определяются разработчиком в инструкциях по эксплуатации (эта деятельность разработчика предусмотрена во всех трех рассматриваемых стандартах), определяются действия оператора по консультированию пользователей, получению обратной связи и др., которые он планирует сам и берет на себя соответствующе обязанности.
    • Процесс сопровождения. Определяет действия персонала сопровождения, который обеспечивает сопровождение программного продукта, что представляет собой управление модификациями программного продукта, поддержку его текущего состояния и функциональной пригодности, включает в себя инсталляцию и удаление программного изделия на вычислительной системе.
  2. 8 вспомогательных процессов, которые поддерживают реализацию другого процесса, будучи неотъемлемой частью всего ЖЦ программного изделия, и обеспечивают должное качество проекта ПО:
    • решения проблем;
    • документирования;
    • управления конфигурацией;
    • гарантирования качества, который использует результаты остальных процессов группы обеспечения качества, в которую входят:
      • Процесс верификации;
      • Процесс аттестации;
      • Процесс совместной оценки;
      • Процесс аудита.
  3. 4 организационных процесса:
    • Процесс управления;
    • Процесс создания инфраструктуры;
    • Процесс усовершенствования;
    • Процесс обучения.

К ним примыкает особый Процесс адаптации, который определяет основные действия, необходимые для адаптации стандарта к условиям конкретного проекта.

Под процессом усовершенствования здесь понимается не усовершенствование АС или ПО, а улучшение самих процессов приобретения, разработки, гарантирования качества и т. п., реально осуществляемых в организации.

Каких-либо этапов, фаз, стадий не предусмотрено, что дает описываемую ниже степень адаптивности.

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

  • выполнение Процесса приобретения в части анализа и фиксации требований к системе или ПО может вызывать исполнение соответствующих задач Процесса разработки;
  • в Процессе поставки поставщик должен управлять субподрядчиками согласно Процессу приобретения и выполнять верификацию и аттестацию по соответствующим процессам;
  • сопровождение может требовать развития системы и ПО, что выполняется по Процессу разработки.

Такой характер позволяет реализовывать любую модель ЖЦ.

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

При этом разработчик должен установить и документировать как требования к программному обеспечению:

  1. Функциональные и возможные спецификации, включая исполнение, физические характеристики и условия среды эксплуатации, при которых единица программного обеспечения должна быть выполнена;
  2. Внешние связи (интерфейсы) с единицей программного обеспечения;
  3. Требования квалификации;
  4. Спецификации надежности, включая спецификации, связанные с методами функционирования и сопровождения, воздействия окружающей среды и вероятностью травмы персонала;
  5. Спецификации защищенности,
  6. Человеческие факторы спецификаций по инженерной психологии (эргономике), включая связанные с ручным управлением, взаимодействием человека и оборудования, ограничениями на персонал и областями, нуждающимися в концентрированном человеческом внимании, которые являются чувствительными к ошибкам человека и обучению;
  7. Определение данных и требований базы данных;
  8. Установочные и приемочные требования поставляемого программного продукта в местах функционирования и сопровождения (эксплуатации);
  9. Документация пользователя;
  10. Работа пользователя и требования выполнения;
  11. Требования сервиса пользователя.
  1. (Интересно и важно, что эти и аналогичные характеристики хорошо корреспондируются с характеристиками АС, предусматриваемыми в ГОСТ 34 по видам обеспечения системы.)

Стандарт содержит предельно мало описаний, направленных на проектирование БД. Это можно считать оправданным, так как разные системы и разные прикладные комплексы ПО могут не только использовать весьма специфические типы БД, но и не использовать

Итак, ISO12207 имеет набор процессов, действий и задач, охватывающий наиболее широкий спектр возможных ситуаций при максимальной адаптируемости.

Он показывает пример того, как должен строиться хорошо организованный стандарт, содержащий минимум ограничений (принцип «нет одинаковых проектов»). При этом детальные определения процессов, форм документов и т. п. целесообразно выносить в различные функциональные стандарты, ведомственные нормативные документы или фирменные методики, которые могут быть использованы или не использованы в конкретном проекте.

По этой причине центральным стандартом, положения которого берутся за начальный «стержневой» набор положений в процессе построения профиля стандартов ЖЦ для конкретного проекта, полезно рассматривать именно ISO12207. Этот «стержень» может задавать модель ЖЦ ПО и АС, принципиальную схему гарантирования качества, модель управления проектом

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

В настоящее время во ВНИИ стандартов подготовлены предложения по совершенствованию и развитию комплекса стандартов по документированию ПС.

Сегодня мы поговорим об отечественных стандартах на проектную документацию. Как эти стандарты работают на практике, чем они плохи и чем хороши. При разработке документации для государственных и серьезных частных заказчиков у нас обычно нет выбора - в требования по документированию ТЗ вписано соблюдение стандартов. На практике мне приходилось сталкиваться с различными примерами недопонимания структуры стандартов, того, что должно быть в документах и зачем эти документы нужны. В итоге из-под пера техписателей, аналитиков и специалистов выходят порой такие перлы, что непонятно, в каком состоянии сознания они писались. А ведь на самом деле все достаточно просто. Поиск по Хабру не вернул ссылок на более-менее целостный материал на данную тему, потому предлагаю закрасить этот досадный пробел.

Что такое стандарты на документацию?

В серии 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

  1. Полное и точное следование стандарту . Добровольно никто, естественно, такую тучу документов писать не будет. Поэтому полный комплект документов готовится только по настоятельной просьбе заказчика, которую он закрепил в ТЗ и еще договором сверху придавил. В таком случае требуется понимать все буквально и отдать заказчику физические «книжки», на которых будут стоять названия документов из таблицы 2 ГОСТ 34.201-89 за исключением совсем уж ненужных, перечень которых вы обязательно должны обговорить и закрепить письменно. Содержание документов также должно без всякой фантазии соответствовать РД 50-34.698-90, вплоть до названия разделов. Для того, чтобы у заказчика взорвался мозг, иногда большую систему делят на подсистемы, и для каждой подсистемы выпускают отдельную проектную документацию. Выглядит это устрашающе и нормальному контролю при помощи земного разума не подлежит. Особенно в части интеграции подсистем. Что значительно упрощает приемку. Главное, чтобы вы сами при этом не запутались и чтобы ваша система все-таки заработала как надо.
  2. Мы просто любим ГОСТы . В серьезных больших компаниях любят стандарты. Потому, что они помогают людям лучше понимать друг друга. Если ваш заказчик замечен в любви к порядку и стандартизации, постарайтесь придерживаться стандартной идеологии ГОСТ при разработке документов, даже если этого не требует ТЗ. Вас лучше поймут и одобрят согласующие специалисты, а вы сами не забудете включить в документацию важную информацию, лучше будете видеть целевую структуру документов, точнее планировать работы по их написанию и сэкономите себе и коллегам массу нервов и денег.
  3. Нам плевать на документацию, лишь бы все работало . Исчезающий вид безответственного заказчика. Подобный взгляд на документацию пока еще можно встретить у небольших и бедных заказчиков, а также в оставшихся со времен перестройки авторитарных «идиотократиях», где босс окружен верными друзьями - директорами, и все вопросы решаются в личных беседах. Вы вольны в подобных условиях забивать на документирование вообще, но лучше, все таки, прицел не сбивать и хотя бы схематично наполнять содержимым документацию. Если не этому заказчику, так следующему передадите (продадите).

Заключение

Эта статья была о наших ГОСТах на документирование АСУ. ГОСТы старые, но, как оказалось, до сих пор очень даже полезные в хозяйстве. Не считая некоторые явные рудименты, структура документации обладает свойствами полноты и непротиворечивости, а следование стандарту снимает многие проектные риски, о существовании которых мы можем по началу не догадываться.

Надеюсь, изложенный материал был вам полезен, или, как минимум, интересен. Несмотря на внешнюю скуку, документирование является важной и ответственной работой, аккуратность в которой так же важна, как и при написании хорошего кода. Пишите хорошие документы, коллеги! А я на следующей неделе отправляюсь в две подряд командировки, так что публикацию новых материалов не гарантирую (загашника у меня нет, пишу из головы).

КУЛЬТУРА РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Любое программное обеспечение , от простого Web-сайта до мощных систем управления базами данных , является высокотехнологичным изделием и должно отвечать следующим критериям:

  • надежности;
  • адекватной обработке нештатных ситуаций;
  • легкой модернизируемости.

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

Общие этапы разработки программ :

  • определение требований к программе;
  • разработка технического задания;
  • разработка проекта программы;
  • кодирование программы;
  • сборка программы;
  • тестирование программных модулей;
  • опытная эксплуатация программы;
  • доводка программного обеспечения;
  • ввод программы в постоянную эксплуатацию;
  • поддержка программы;
  • определение требований к новой версии программы;

Для определения требований к программе разработчику необходимо получить ответ на вопрос: «Насколько заказчик заинтересован в разработке программы?»

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

Если намерения заказчика серьезны, то определение требований к программе, скорее всего, вопрос не одной встречи (совещания), на которых необходимо выяснить и уточнить вопросы:

  • Какова(-ы) цель(-ли) программы?
  • Круг пользователей программы.
  • Нормативная (правовая, справочная) база, на которую опираются процессы, алгоритмизируемые в программе.
  • Возможность и необходимость дальнейшего развития программы.
  • Контактное лицо, уполномоченное решать все вопросы от лица заказчика.
  • Наличие материалов, которые есть или заказчик планирует подготовить для использования в программе (!!! Этот пункт особенно важен для разработки Web-сайтов).

Разработка технического задания в идеале должна осуществляться заказчиком. На практике зачастую это делает разработчик по причине отсутствия у заказчика квалифицированных специалистов, сведущих в области разработки программного обеспечения. Техническое задание, как правило, разрабатывается на основе ГОСТа 19.201-78 «ЕСПД. Техническое задание. Требования к содержанию и оформлению». В случаях разработки технического программного обеспечения в составе автоматизированных систем применяется ГОСТ 34.602-89 «Информационная технология. Техническое задание на создание автоматизированной системы».

Техническое задание проходит процедуру согласования между заказчиком и разработчиком после проверки правильности его оформления службой нормоконтроля разработчика.

На основе утвержденного технического задания разрабатывается проектная документация (проект ). Содержание проекта зависит от типа программного обеспечения и традиций предприятия разработчика.

Обязательными составляющими проекта должны быть:

  • пояснительная записка (по ГОСТу 19.404-79 «ЕСПД. Пояснительная записка. Требования к содержанию и оформлению»).
  • описание программы (по ГОСТу 19.402-78 «ЕСПД. Описание программы»).
  • перечень терминов, используемых в проекте. Для web-сайтов в состав проекта включаются:
  • эскиз дизайна сайта;
  • перечень материалов, используемых в составе сайта;
  • структура баз данных (в случае наличия таковых)

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

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

Для осуществления кодирования программы проектировщик выдает задания программисту на кодирование модулей программы. В задании определяются требования к структуре входных и выходных данных модуля, к названиям переменных, используемых в модуле, к алгоритму обработки данных модулем, к приемам программирования (в случае необходимости). Программный код сопровождается подробным комментарием, от качества которого зависит возможность выпуска последующих версий программы.

Тщательно в коде должен быть описан смысл входных и выходных данных каждого модуля, а также смысл и функции самого модуля. Это важно для успеха сборки программы.

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

Тестирование программы производится следующим образом:

  1. Определяется набор аппаратуры для производства тестирования.
  2. Разрабатываются сценарии (контрольные примеры) для тестирования.
  3. На основе сценариев проверяется работа программы в штатном режиме (проверяется правильность выполнения тех функций, которые программа и должна выполнять).
  4. Проверяется работа программы в нештатных режимах (проверяется, устойчиво ли работает программа в режимах, которые могут возникать только при нарушении пользователями правил эксплуатации программы, например, ввод букв в цифровое поле).
  5. Производится тестирование на удобство управления программой и качество интерфейсов.
  6. Данные тестирования и его результаты обрабатываются и оформляются в соответствии с ГОСТом 34.603-92 «Информационная технология. Виды испытаний автоматизированных систем».
  7. По мере выявления ошибок последние исправляются, и тестирование производится повторно.
  8. После исправления всех ошибок программа передается в опытную эксплуатацию.

Заказчику на стадии опытной эксплуатации передается программа и обязательный пакет документации:

  • ведомость эксплуатационных документов (по ГОСТу 19.507-79 «ЕСПД. Ведомость эксплуатационных документов»)
  • формуляр (по ГОСТу 19.501-78 «ЕСПД. Формуляр. Требования к содержанию и оформлению»)
  • описание применения (по ГОСТу 19.502-78 «ЕСПД. Описание применения. Требования к содержанию и оформлению»)
  • руководство системного программиста (по ГОСТу 19.503-79 «ЕСПД. Руководство системного программиста. Требования к содержанию и оформлению»)
  • руководство оператора (по ГОСТу 19.505-79 «ЕСПД. Руководство оператора. Требования к содержанию и оформлению»).

В зависимости от вида задачи дополнительно могут передаваться:

  • руководство программиста (по ГОСТу 19.504-79 «ЕСПД. Руководство программиста. Требования к содержанию и оформлению»)
  • руководство по т/о (по ГОСТу 19.508-79 «ЕСПД. Руководство по техническому обслуживанию. Требования к содержанию и оформлению»).

На стадии опытной эксплуатации программы фиксируются замечания заказчика и выявленные ошибки.

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

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

  • консультации;
  • обслуживание аппаратных средств, на которых используется программа;
  • проверка и анализ баз данных;
  • верификация правильности технологий обработки данных;
  • документирование и анализ новых требований к программе.

Последний пункт и является основой для начала разработки новой версии программы .

Только грамотный процесс разработки программ обеспечивает их высокое качество и долгую жизнь!!!


На верх

ГОСТ 19.105-78* (Общие требования к программным документам)

Из данного ГОСТа мы получаем общие требования к оформлению программных документов. Ниже приведены наиболее важные разделы.

  • Настоящий стандарт устанавливает общие требования к оформлению программных документов для вычислительных машин, комплексов и систем, независимо от их назначения и области применения и предусмотренных стандартами Единой системы программной документации (ЕСПД) для любого способа выполнения документов на различных носителях данных.
  • Программный документ состоит из следующих условных частей:
    • титульной;
    • информационной;
    • основной;
    • регистрации изменений.
  • Титульная часть состоит из листа утверждения и титульного листа. Правила оформления листа утверждения и титульного листа устанавливаются по ГОСТ 19.104-78.
  • Информационная часть должна состоять из аннотации и содержания.
    • Необходимость включения информационной части в различные виды программных документов установлена соответствующими стандартами ЕСПД на эти документы.
    • В аннотации приводят сведения о назначении документа и краткое изложение его основной части.
    • Содержание включает перечень записей о структурных элементах основной части документа, в каждую из которых входят:
      • обозначение структурного элемента (номер раздела, подраздела и т.д.);
      • наименование структурного элемента;
      • адрес структурного элемента на носителе данных (например, номер страницы, номер файла и т.п.).
  • Состав и структура основной части программного документа устанавливаются стандартами ЕСПД на соответствующие документы.
  • Часть регистрации изменений (должна присуствовать в каждом программном документе)
    • О каждом изменении программного документа в этой части делается запись в соответствии с требованиями ГОСТ 19.603-78.
На верх
==================================
ГОСТ 19.106-78* (Общие требования к программным документам, выполненным печатным
способом)
Из данного ГОСТа мы получаем общие правила для печатного способа выполнения программных документов . Ниже приведены наиболее важные разделы.
  • Настоящий стандарт устанавливает правила выполнения программных документов для вычислительных машин, комплексов и систем независимо от их назначения и области применения и предусмотренных стандартами Единой системы программной документации (ЕСПД) для печатного способа выполнения.
  • Стандарт не распространяется на программный документ «Текст программы».
  • Состав и структура программного документа устанавливается по ГОСТ 19.105-78.
  • Программный документ выполняют на одной стороне листа, через два интервала; допускается через один или полтора интервала.
  • Программные документы оформляют:
    • на листах формата А4 (ГОСТ 2.301-68) - при изготовлении документа машинописным или рукописным способом (форма 1). Допускается оформление на листах формата А3.


  • Материалы программного документа располагают в следующей последовательности:
    • титульная часть:
      • лист утверждения (не входит в общее количество листов документа);
      • титульный лист (первый лист документа);
    • информационная часть:
      • аннотация;
      • лист содержания;
    • основная часть:
      • текст документа (с рисунками, таблицами и т.п.);
      • приложения;
      • перечень терминов, перечень сокращений, перечень рисунков, перечень таблиц, предметный указатель, перечень ссылочных документов;
    • часть регистрации изменений:
      • лист регистрации изменений.
  • Аннотацию размещают на отдельной (пронумерованной) странице с заголовком «АННОТАЦИЯ» и не нумеруют как раздел.
    • В аннотации указывают издание программы, кратко излагают назначение и содержание документа. Если документ состоит из нескольких частей, в аннотации указывают общее количество частей.
  • Содержание документа размещают на отдельной (пронумерованной) странице (страницах) после аннотации, снабжают заголовком «СОДЕРЖАНИЕ», не нумеруют как раздел и включают в общее количество страниц документа.
  • Заголовки разделов пишут прописными буквами и размещают симметрично относительно правой и левой границ текста.
  • Заголовки подразделов записывают с абзаца строчными буквами (кроме первой прописной).
  • Переносы слов в заголовках не допускаются. Точку в конце заголовка не ставят.
  • Расстояние между заголовком и последующим текстом, а также между заголовками раздела и подраздела должно быть равно:
    • при выполнении документа машинописным способом - двум интервалам.
  • Для разделов и подразделов, текст которых записывают на одной странице с текстом предыдущего раздела, расстояние между последней строкой текста и последующим заголовком должно быть равно:
    • при выполнении документа машинописным способом - трём машинописным интервалам.
  • Разделы, подразделы, пункты и подпункты следует нумеровать арабскими цифрами с точкой.
  • В пределах раздела должна быть сквозная нумерация по всем подразделам, пунктам и подпунктам, входящим в данный раздел.
  • Нумерация подразделов включает номер раздела и порядковый номер подраздела, входящего в данный раздел, разделённые точкой (2.1; 3.1 и т. д.).
  • При наличии разделов и подразделов к номеру подраздела после точки добавляют порядковый номер пункта и подпункта (3.1.1, 3.1.1.1 и т.д.).

Пример структуры текста программного документа и нумерации его разделов, подразделов, пунктов и подпунктов.

  • Текст документа должен быть кратким, четким, исключающим возможность неверного толкования.
  • Термины и определения должны быть едиными и соответствовать установленным стандартам, а при их отсутствии - общепринятым в научно-технической литературе, и приводиться в перечне терминов.
  • Необходимые пояснения к тексту документа могут оформляться сносками.
    • Сноска обозначается цифрой со скобкой, вынесенными на уровень линии верхнего обреза шрифта, например: «печатающее устройство 2) ...» или «бумага 5) ».
    • Если сноска относится к отдельному слову, знак сноски помещается непосредственно у этого слова, если же к предложению целом, то в конце предложения. Текст сноски располагают в конце страницы и отделяют от основного текста линией длиной 3 см, проведённой в левой части страницы.
  • Иллюстрации, если их в данном документе более одной, нумеруют арабскими цифрами в пределах всего документа.
  • Формулы в документе, если их более одной, нумеруются арабскими цифрами, номер ставят с правой стороны страницы, в скобках на уровне формулы.
  • Значение символов и числовых коэффициентов, входящих в формулу, должны быть приведены непосредственно под формулой. Значение каждого символа печатают с новой строки в той последовательности, в какой они приведены в формуле. Первая строка расшифровки должна начинаться со слова «где», без двоеточия после него.
  • В программных документах допускаются ссылки на стандарты (кроме стандартов предприятий), технические условия и другие документы (например, документы органов Государственного надзора, правила и нормы Госстроя СССР). При ссылках на стандарты и технические условия указывают их обозначение.
  • Ссылаться следует на документ в целом или на его разделы (с указанием обозначения и наименования документа, номера и наименования раздела или приложения). При повторных ссылках на раздел или приложение указывают только номер.
  • В примечаниях к тексту и таблицам указывают только справочные и пояснительные данные.
    • Одно примечание не нумеруется. После слова «Примечание» ставят точку.
    • Несколько примечаний следует нумеровать по порядку арабскими цифрами с точкой. После слова «Примечание» ставят двоеточие.
  • Сокращения слов в тексте и надписях под иллюстрациями не допускаются.
  • Иллюстрированный материал, таблицы или текст вспомогательного характера допускается оформлять в виде приложений.
  • Каждое приложение должно начинаться с новой страницы с указанием в правом верхнем углу слова «ПРИЛОЖЕНИЕ» и иметь тематический заголовок, который записывают симметрично тексту прописными буквами. (в итоге, для создания проекта, нам понадобится только лист регистрации изменений).
    • Настоящий стандарт устанавливает правила внесения изменений в программные документы, предусмотренные стандартами Единой системы программной документации (ЕСПД) и выполненные печатным способом.
    Из за значительного объема информации в данном ГОСТе и для экономии места на данной странице рекомендую самостоятельно просмотреть ГОСТ 19.604-78* . Готовый пример оформления "листа регистрации изменений" Вы можете просмотреть в любом программном документе, предоставленном в разделе СКАЧАТЬ

    На верх
    ==================================

Рекомендуем также