гост оформление кода программы

Оформление текстовых документов: новые требования ГОСТ

Общие требования к текстовым документам ГОСТ 2.105-95 и ГОСТ Р 2.105-2019 — это свод правил, призванный стандартизировать форму заполнения конструкторской документации. Они содержат нормы, которым должны подчиняться структура и состав текстов в сфере строительства, приборостроения и машиностроения.

Общие моменты

С 1 июля 2020 года вступит в силу приказ Федерального агентства по техническому регулированию и метрологии от 29.04.2019 № 175-ст, которым предусмотрено два нововведения:

Дополнительно в этой сфере приняты:

На практике при выполнении работы применяются те стандарты, которые выставляет заказчик, поскольку требования ЕСКД (единых систем конструкторской документации) и в целом ГОСТы в РФ считаются добровольными. Если документация оформляется для российского рынка, используйте правила оформления из национального свода. Если вы готовите бумаги для партнеров из ЕАЭС, стоит продолжать работу по ГОСТ 2.105-95. В ситуациях, когда документами пользуются компании и из России, и из других стран, укажите наименование стандарта, который использован при их подготовке.

Способы оформления

Разрешается заполнять документацию:

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

Техническое оформление: общие требования

Формулировки основных правил ГОСТ оформления текстовых документов несколько отличаются в зависимости от того, как утвержден стандарт. Таблица покажет, в чем разница и сходство редакций:

Межгосударственный стандарт ГОСТ 2.105-95

Национальный стандарт ГОСТ Р 2.105-2019

Высота символов — не менее 2,5 мм

· шрифт Times New Roman или Arial размером 14 для основного текста и размером 12 для приложений, примечаний, сносок и примеров;

· допускается использование шрифта размером 13 и 11 для основного текста и размером 12 и 10 для приложений, примечаний, сносок и примеров соответственно.

Расстояние между боковыми линиями формы и текстом должно составлять минимум 3 мм

Абзац начинается с красной строки, минимальный отступ — 15 — 17 мм

Абзацы начинается с отступа, равного 12,5 — 17 мм

От нижней и верхней границ следует отступать не менее 10 мм

Интервал между строками — не менее 8 мм

· текст оформляют с использованием полуторного межстрочного интервала;

· допускается использование двойного межстрочного интервала.

· расстояние между заголовком и текстом при выполнении документа машинописным способом равно 3, 4 интервалам, при выполнении рукописным способом — 15 мм;

· расстояние между заголовками раздела и подраздела — 2 интервала, при выполнении рукописным способом — 8 мм.

· расстояние между заголовком и текстом, между заголовками раздела и подраздела — не менее 4 высот шрифта, которым набран основной текст. Расстояние между строками заголовков подразделов и пунктов принимают таким же, как в тексте;

· при выполнении машинописным способом интервал равен 3 или 4 интервалам, при выполнении рукописным способом — не менее 15 мм.

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

Относительно копий в ГОСТ 2.105-95 заявлено, что их (здесь и далее приведены выдержки из текста):

выполняют одним из следующих способов:

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

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

Что касается нумерации, ЕСКД при оформлении документов позволяет сделать ее как сквозной, так и отдельной для каждого раздела.

Чего делать нельзя

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

Помимо этого, требования ЕСКД 2020 года запрещают:

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

Источник

Оформление программы по ГОСТу (how to)

Содержание

Краткий алгоритм оформления программы

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

Оформление программного документа

Каждый отдельный программный документ оформляется по (общим для всех докуметнов ЕСПД) требованиям ГОСТ 19.101-77, ГОСТ 19.103-77, ГОСТ 19.104-78, ГОСТ 19.105-78, ГОСТ 19.106-78, ГОСТ 19.604-78 (более подробное описание данных ГОСТов следует ниже) и ГОСТа для конкретного программного документа.

ГОСТ 19.105-78 устанавливает общие требования к оформлению программных документов.

По данному ГОСТу, программный документ должен состоять из следующих частей:

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

ГОСТ 19.101-77 устанавливает виды программ и программных документов для вычислительных машин, комплексов и систем, независимо от их назначения и области применения.

ГОСТ устанавливает 2 вида программ:

Также ГОСТ определяет виды и содержание программных документов.

ГОСТ 19.103-77 устанавливает структуру обозначения программ и программных документов для вычислительных машин, комплексов и систем независимо от их назначения и области применения.

Проще говоря, данный ГОСТ описывает каким должен быть шифр документа вида А.В.ХХХХХ-ХХ ХХ ХХ-Х, и что означает каждое поле данного шифра.

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

В ГОСТе есть примеры титульного листа и листа утверждения, а также общая форма листа, разбитая на поля. Также можно посмотреть пример.

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

Важно отметить, что данный ГОСТ не распространяется на программный документ «Текст программы».

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

В аннотации указывают издание программы, кратко излагают назначение и содержание документа. Если документ состоит из нескольких частей, в аннотации указывают общее количество частей. Содержание документа размещают на отдельной (пронумерованной) странице (страницах) после аннотации, снабжают заголовком «СОДЕРЖАНИЕ», не нумеруют как раздел и включают в общее количество страниц документа.

В ГОСТе присутствует образец листа, где указаны поля, места для нумерации страниц и шифра.

Примеры

Мои наиболее актуальные (2016 год) шаблоны.

Источник

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

Введение

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

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

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

Стандарты

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

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

19.001-77. Общие положения

Описывает правила присвоения обозначений стандартов в серии ЕСПД. В практической жизни не нужен.

19.102-80. Схемы алгоритмов и программ. Правила выполнения.

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

19.003-80. Схемы алгоритмов и программ. Обозначения условные графические

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

19.004-80. Термины и определения.

Скудный глоссарий. Из интересного — содержит формальные определения программного и эксплуатационного документов.

19.005-85. Р-схемы алгоритмов и программ

Практически забытый язык. В свое время Р-схемы широко использовались в ракетно-космической отрасли, став стандартом де-факто для написания программ управления пусками и моделирования запусков. Однако ныне этот язык полностью предан забвению. В своей работе я ни разу не сталкивался с Р-схемами. Хотя по сравнению с блок-схемами они имеют заметные преимущества: компактны, подходят для визуализации нелинейных алгоритмов (например, классов в С++) или структур данных. При этом в интернете информации по ним практически нет: мне показались полезными вот этот и вот этот сайты. В любом случае, если бы сейчас мне пришлось вставлять в программную документацию схему алгоритма, я бы выбрал Р-схемы, а не блок-схемы.

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

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

19.102-77. Стадии разработки

Важный и нужный стандарт, в котором описаны виды документов и приведены коды видов программных документов. Этот стандарт (совместно с 19.103-77) является одним из ключей к “разгадке” обозначений документов подобных АБВГ.10473-01 32 01-1.
В стандарте вводится понятие комплекса и компонента (на ряде предприятий добавляют третий вид — комплект, когда речь идет о несвязанных программных элементах), дается разделение: какие документы эксплуатационные, какие нет.
Следует аккуратно относиться к таблице 4, в которой показано, какой документ на какой стадии разработки выполняется. Стадии разработки обычно регламентируются в стандартах на выполнения ОКР, и там-же указывается, какие документы нужно предъявлять заказчику на каждом этапе.

19.102-77. Стадии разработки

На моей памяти этот стандарт не применялся ни разу: кто что делает на каком этапе и чем отчитывается прописывается в ТТЗ или делается отсылка к ГОСТам, где это прописано более четко (например, ГОСТ РВ 15.203). При этом для новичка он содержит неплохой в своей лаконичности конспект работ на основных этапах ОКР.

19.103-77. Обозначения программ и программных документов

Нужен, в основном, для того, что бы научиться читать обозначения документов подобных приведенному выше. Однако понимание схемы обозначений полезно в случае, когда приходиться выходить за рамки типовых работ: к примеру, помнить, что документы с кодами после 90 — пользовательские, т.е. любые. В моей практике мы выпускали документ 93, который назвали “Ведомость программной документации”, 96 документ — “Инструкция по сборке”.
Распространенное словосочетание “вариант исполнения” в ЕСПД отсутствует, и заменяется “номером редакции”. С одной стороны, это не совсем корректно: номер редакции задумывался для отслеживания эволюции программы: вначале выходит первая редакция, потом, к примеру, после доработки — вторая. Но на практике, когда нужно выпустить версию ПО для нескольких операционных систем (кросс-платформенное ПО), другого выхода нет. Точнее — есть, но неправильный: присвоить версии для каждой операционки свое обозначение — и закладывать в архив несколько дисков с исходниками (по числу операционок), разрабатывать (фактически — копировать) весь комплект документации и т.д… Т.е. чистой воды бестолковая и сбивающая с толку деятельность. Решение в виде присвоения версии под каждую операционку своего номера редакции позволяет часть документов сделать общими.
В ЕСПД используется смущающее многих программистов обозначение исходных текстов программы и результата сборки “документами”. Документ “текст программы”, согласно 19.101-77, имеет обозначение 12. Дальше принято, что исходники обозначаются как 12 01 — т.е. 01(первый) документ вида 12, а бинарники — как 12 02 — т.е. второй документ вида 12. В ряде случаев для сборки программы требуются дополнительные инструментальные средства — компиляторы, генераторы инсталляторов и т.д. Т.е. программы, которые не входят в поставку, но нужны для сборки. Решением может быть их обозначение как 12 03 — т.е. третий документ вида 12.

19.104-78. Основные надписи

19.105-78. Общие требования к программным документам

Вводится общая структура документа, не зависящая от способа его исполнения. Т.е. еще в 1978 году было заложено в стандарт, что документ может быть не обязательно бумажным. В частности, вводиться понятие содержания для полностью электронных документов. Для бумажного исполнения, распространенного в то время, был принят ГОСТ 19.106-78.
В настоящее время к этому стандарту приходиться обращаться очень редко: разве что забывается порядок следования основных частей документа.

19.106-78. Общие требования к программным документам, выполненным печатным способом

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

Источник

Курс молодого бойца: Об оформлении программной документации (документация)

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

ТЕХНИЧЕСКОЕ ЗАДАНИЕ (ГОСТ 19.201-78)

2. Содержание разделов

СТАДИИ РАЗРАБОТКИ (ГОСТ 19.102-77)

ОПИСАНИЕ ПРОГРАММЫ (ГОСТ 19.402-78)

ТЕКСТ ПРОГРАММЫ (ГОСТ 19.401-78)

ПРОГРАММА И МЕТОДИКА ИСПЫТАНИЙ (ГОСТ 19.301-79)

ТРЕБОВАНИЯ К ПРОГРАММНЫМ ДОКУМЕНТАМ, ВЫПОЛНЕННЫМ ПЕЧАТНЫМ СПОСОБОМ (ГОСТ 19.106-78)

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

Как двигаться вперед

Подготовка документации на программные средства (ПС) в соответствии с имеющимися ГОСТами

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

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

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

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

И еще одно. Важно создать первый пакет ПД. Этого будет достаточно, чтобы на его основе строить все последующие, используя его как образец или шаблон. Но сделать это надо очень качественно. Не спеша. Очень основательно.

Начнем с общих положений о Единой системе программной документации (которые тоже определены в соответствующем стандарте ГОСТ 19.001-77).

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

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

Как видно, основная часть комплекса ЕСПД была разработана в 70-е и 80-е годы. Частично эти стандартны морально устарели, к тому же они не лишены некоторых недостатков. Во-первых, в них не отражены некоторые современные тенденции оформления программ и программной документации, во-вторых, в этих стандартах наличествует многократное дублирование фрагментов программной документации. Тем не менее, за неимением лучшего ориентироваться приходится именно на них.

Согласно ГОСТу, настоящий стандарт (переизданный в ноябре 1987 г.) устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения.

Техническое задание оформляют на листах формата А4 и/или А3, как правило, без заполнения полей листа. Номера листов (страниц) проставляют в верхней части листа над текстом.

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

Техническое задание должно содержать следующие разделы:

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

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

В разделе Основание для разработки должны быть указаны:

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

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

Иными словами, здесь начинается конкретика. Описывается то, что должна делать программа и как она должна выглядеть.

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

Например : Программа должна позволять … вычислять … строить… создавать …

Исходные данные : текстовый файл с заданной …

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

Здесь «выгадать» что-то сложно. В лучшем случае может пройти вариант, при котором ваша программа работает только с абсолютно корректными данными. Обычно Заказчик на это не идет, но попробовать можно.

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

С этим пунктом сложностей обычно не возникает. К сожалению, пункт о профессиональности пользователя Заказчиком подразумевается обязательно. Это, конечно, лишний повод придраться к вашей программе. Впрочем, здесь можно ограничиться фразами вида «Условия эксплуатации программы совпадают с условиями эксплуатации ПЭВМ IBM PC и совместимых с ними ПК», «Программа должная быть рассчитана на непрофессионального пользователя.» и т.п.

Требования к составу и параметрам технических средств. Указывают необходимый состав технических средств с указанием их технических характеристик.

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

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

Например: Специальных требований к временным характеристикам программы не предъявляется. Специальных требований к емкостным характеристикам программы не предъявляется.

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

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

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

Основными и непременными стадиями и этапами являются само техническое задание, эскизный проект, технический и рабочий проекты.

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

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

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

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

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

Этот стандарт устанавливает стадии разработки программ, программной документации, а также этапы и содержание работ:

Обоснование необходимости разработки программы

Постановка задачи.
Сбор исходных материалов.
Выбор и обоснование критериев эффективности и качества разрабатываемой программы.
Обоснование необходимости проведения научно-исследовательских работ.

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

Разработка и утверждение технического задания

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

Разработка эскизного проекта

Предварительная разработка структуры входных и выходных данных.
Уточнение методов решения задачи.
Разработка общего описания алгоритма решения задачи.
Разработка технико-экономического обоснования.

Утверждение эскизного проекта

Разработка пояснительной записки.
Согласование и утверждение эскизного проекта

Разработка технического проекта

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

Утверждение технического проекта

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

Программирование и отладка программы

Разработка программной документации

Разработка программных документов в соответствии с требованиями ГОСТ 19.101-77.

Разработка, согласование и утверждение программы и методики испытаний.
Проведение предварительных государственных, межведомственных, приемо-сдаточных и других видов испытаний.
Корректировка программы и программной документации по результатам испытаний.

Подготовка и передача программы

Подготовка и передача программы и программной документации для сопровождения и (или) изготовления.
Оформление и утверждение акта о передаче программы на сопровождение и (или) изготовление.
Передача программы в фонд алгоритмов и программ.

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

Строго говоря, существуют два разных документа, имеющих, правда, много общего. Это ОБЩЕЕ ОПИСАНИЕ (ГОСТ 19.502-78) и ОПИСАНИЕ ПРОГРАММЫ (ГОСТ 19.402-78). Однако, в силу того, что реально создать качественно и тот, и другой, не прибегая к почти полному дублированию, выдирая куски, весьма сложно, было бы достаточно реализовать один, более общий, «гибридный» документ. Назовем его «Описанием программы».

На самом деле «Описание программы» в своей содержательной части может дополняться разделами и пунктами, взятыми и из стандартов для других описательных документов и руководств: ГОСТ 19.404-79 ЕСПД. Пояснительная записка, ГОСТ 19.503-79 ЕСПД. Руководство системного программиста, ГОСТ 19.504-79 ЕСПД. Руководство программиста, ГОСТ 19.505-79 ЕСПД. Руководство оператора и т.п. В частности, из Пояснительной записки можно взять схему алгоритма, общее описание алгоритма и (или) функционирования программы, а также обоснование принятых технических и технико-экономических решений.

Основная часть документа должна состоять из вводной части и следующих разделов:

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

Например: Программа «Автоматизированное рабочее место разработчика САУ» предназначена для … реализована на …. Программа поддерживает …

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

Например: Программа предназначена для решения задач … Программа представляет собой ядро автоматизированного рабочего места …

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

В разделе » Описание логики » указывают:

(например: В состав программы входит следующее:

Например : Программа состоит из шести модулей: интерфейсный модуль; модуль определения …; модуль расчета …; модуль …и т.п..

Модуль определения … Он является …

Модуль расчета …и т.д.

Например : Программа написана на языке …с использованием компилятора …

Например : ВХОДНЫЕ ДАННЫЕ. Входными данными для программы является текстовый файл, описывающий расширенную матрицу инциденций графа исследуемой системы.

ВЫХОДНЫЕ ДАННЫЕ. Выходными данными являются:

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

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

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

Например : Программа эксплуатируется на персональном компьютере (ПК) типа IBM PC/AT. Для работы в диалоговом режиме используется экран дисплея, клавиатура и манипулятор типа «мышь». Для поддержки графического режима необходим адаптер EGA (VGA). Входные данные хранятся на флоппи- и/или жестком дисках. Программа работает под управлением ОС …

В приложение к описанию могут быть включены справочные материалы (иллюстрации, таблицы, графики, примеры и т.п.)

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

Вызова и загрузки системы

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

Текст каждого программного файла начинается с «шапки», в которой указывается:

Ниже приведен пример подобного хорошо читаемого текста программы (взят с сайта Николая Гехта, e-mail:geht@omskreg.ru, http://users.omskreg.ru/

/* Исходные тексты Windows’98

Автор: Nobody Really

Формально этот ГОСТ используется для разработки документов планирования и проведения испытательных работ по оценке готовности и качества программной системы. Документ содержит описание объекта и цели испытаний, требования к программе и к программной документации, средства и порядок испытаний, а также описание тестовых примеров.

Составные части этого документа проще и нагляднее описывать сразу в виде примеров.

Пример: Объектом испытаний является программа …, предназначенная для …

Пример: Проверка надежности функционирования программы.

Требования к программе

Пример: Функционирование программы не должно приводить к сбою (фатальному нарушению работы системы). Организация диалога должна предусматривать защиту от ввода некорректных данных. Программа должна выдавать диагностику состояния системы и сообщения о любых возникших ошибках … и т.п.

Требования к программной документации

Пример: Состав программной документации, предъявляемой на испытании:

Средства и порядок испытаний

Пример: Программа работает в соответствии с условиями эксплуатации ОС MS DOS (версия не ниже 3.0) на ПК типа IBM PC/AT, а также на совместимых с ним. Для работы необходим также адаптер EGA (VGA).

Порядок проведения испытаний:

Пример: Для проведения испытаний предлагаются …, описание которых содержатся в файлах …Содержимое тестовых файлов и результаты работы программы приведены в Приложении 1.

И, наконец, рассмотрим последний стандарт ЕСПД, который называется

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

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

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

Повреждение листов документов, помарки и следы не полностью удаленного текста (графики) не допускаются.

Программные документы оформляют на листах формата А4. Кроме того:

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

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

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

Аннотацию размещают на отдельной странице (страницах), снабжают заголовком «АННОТАЦИЯ», нумеруют и включают в содержание документа.

Содержание документа размещают на отдельной странице (страницах), снабжают заголовком «СОДЕРЖАНИЕ» и включают в общее количество страниц документа. В содержании документа дается перечисление наименований разделов и подразделов и номеров страниц.

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

Разделы, подразделы, пункты и подпункты следует нумеровать арабскими цифрами с точкой. Разделы должны иметь порядковый номер (1, 2 и т.д.)

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

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

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

В приложениях иллюстрации нумеруются в пределах каждого приложения в порядке, установленном для основного текста документа. Ссылки на иллюстрации дают по типу: «рис.12» или «(рис.12)». Иллюстрации могут иметь тематический заголовок и подрисуночный текст, поясняющий содержание иллюстрации.

Формулы. Формулы в документе, если их более одной, нумеруются арабскими цифрами, номер ставят с правой стороны страницы, в скобках на уровне формулы. В пределах всего документа или его частей, в случае деления документа на части, формулы имеют сквозную нумерацию.

Ссылки в тексте на порядковый номер формулы дают в скобках, например: «в формуле (3)». При делении документа на части номер части ставится перед порядковым номером формулы и отделяется от последней точкой, например: «в формуле (1.4)».

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

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

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

Примечания. В примечаниях к тексту и таблицам указывают только справочные и пояснительные данные. Одно примечание не нумеруется. После слова «Примечание» ставят точку. Несколько примечаний следует нумеровать по порядку арабскими цифрами с точкой. После слова «Примечание» ставят двоеточие. Текст примечаний допускается печатать только через один интервал.

Сокращения. Сокращения слов в тексте и надписях под иллюстрациями не допускаются, за исключением:

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

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

Приложение 1, Приложение 2 и т.д.

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

Источник