Реферат единая система программной документации

Обновлено: 04.07.2024

с 01.01. 1980 г.
Настоящий стандарт устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения.
Стандарт полностью соответствует СТ СЭВ 1627-79.

1. ОБЩИЕ ПОЛОЖЕНИЯ
1.1. Техническое задание оформляют в соответствии с ГОСТ 19.106-78 на листах формата 11 и 12 по ГОСТ 2.301-68, как правило, без заполнения полей листа. Номера листов (страниц) проставляются в верхней части листа над текстом.
1.2. Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78.
Информационную часть (аннотацию и содержание), лист регистрации изменений допускается в документ не включать.
1.3. Для внесения изменений или дополнений в техническое задание на последующих стадиях разработки программы или программного изделия выпускают дополнение к нему. Согласование и утверждение дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания.
1.4. Техническое задание должно содержать следующие разделы:

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

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

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

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

перечень научно-исследовательских и других работ, обосновывающих разработку;

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

другие источники разработки.

ТРЕБОВАНИЯ К ПРОГРАММНЫМ ДОКУМЕНТАМ,

ВЫПОЛНЕННЫМ ПЕЧАТНЫМ СПОСОБОМ

ГОСТ 19.106-78
1.5. Программные документы оформляют:

на листах формата А4 (ГОСТ 2.301-68) - при изготовлении документа машинописным или рукописным способом (форма 1). Допускается оформление на листах формата А3 (форма 2);

на листах форматов А4 и А3, предусматриваемых выходными характеристиками устройств вывода данных - при изготовлении документа машинным способом. Допускаются отклонения размеров листов, соответствующих форматам А4 и А3, определяемые возможностями применяемых технических средств;

на листах типографических форматов - при изготовлении документа типографским способом.
Форма 1

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

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

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

2. ТРЕБОВАНИЯ К ПРОГРАММНЫМ ДОКУМЕНТАМ, СОДЕРЖАЩИМ В ОСНОВНОМ СПЛОШНОЙ ТЕКСТ.

2.1. Построение документа.
2.1.1. При необходимости допускается делить документ на части. Деление на части осуществляется на уровне не ниже раздела. Каждую часть комплектуют отдельно. Всем частям присваивают обозначение документа в соответствии с ГОСТ 19.103-77.
Части оформляют в соответствии с требованиями настоящего стандарта, при этом в конце содержания первой части следует перечислять названия остальных частей.
Допускается включать в документ частей текста программы, оформляемых в соответствии с правилами языка, на котором написан текст программы.
Нумерацию страниц документа, а также нумерацию разделов, рисунков и таблиц производят в пределах каждой части. Каждую часть начинают с титульного листа.
Отдельная нумерация страниц документа в пределах раздела и подраздела не допускается.
Лист утверждения выпускают на весь документ с обозначением первой части.
(Измененная редакция, Изм. № 1).
2.1.2. Информационная и основная части программного документа выполняются по форме 1 или 2, где:

поле 1 - порядковый номер страницы;

поле 2 - обозначение документа;

поле 3 - текст документа;

при выполнении документа машинописным способом - двум интервалам;

при выполнении рукописным способом - 10 мм;

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

при выполнении документа машинописным способом - трём машинописным интервалам;

при выполнении рукописным способом - не менее 15 мм;

при выполнении машинным способом - не менее четырёх высот шрифта.
Расстояние между основаниями строк заголовка принимают такие же, как в тексте.
При типографском способе издания документов указанные расстояния оформляют по правилам для типографских изданий.
2.1.9. Разделы, подразделы, пункты и подпункты следует нумеровать арабскими цифрами с точкой.
Разделы должны иметь порядковый номер (1, 2 и т. д.).
В пределах раздела должна быть сквозная нумерация по всем подразделам, пунктам и подпунктам, входящим в данный раздел.
Нумерация подразделов включает номер раздела и порядковый номер подраздела, входящего в данный раздел, разделённые точкой (2.1; 3.1 и т. д.).
При наличии разделов и подразделов к номеру подраздела после точки добавляют порядковый номер пункта и подпункта (3.1.1, 3.1.1.1 и т.д.).
Пример структуры текста программного документа и нумерации его разделов, подразделов, пунктов и подпунктов приведён в справочном приложении 2.
(Измененная редакция, Изм. № 1).
2.1.10. (Исключен, Изм. № 1)

2.2. Текст документа.
2.2.1. Текст документа должен быть кратким, четким, исключающим возможность неверного толкования.
Термины и определения должны быть едиными и соответствовать установленным стандартам, а при их отсутствии - общепринятым в научно-технической литературе, и приводиться в перечне терминов.
2.2.2. Допускаются сокращения слов в тексте и надписях под иллюстрациями по ГОСТ 2.316-68. Дополнительные сокращения, принятые в документе и не входящие в ГОСТ 2.316-68, следует приводить в перечне принятых сокращений.
2.2.3. Для выделения отдельных понятий допускается изменять интервалы между словами, а также печатать отдельные слова или части текста шрифтом, отличным от печати основного текста, например:

2.5. Ссылки.
2.5.1. В программных документах допускаются ссылки на стандарты (кроме стандартов предприятий), технические условия и другие документы (например, документы органов Государственного надзора, правила и нормы Госстроя СССР). При ссылках на стандарты и технические условия указывают их обозначение.
Ссылаться следует на документ в целом или на его разделы (с указанием обозначения и наименования документа, номера и наименования раздела или приложения). При повторных ссылках на раздел или приложение указывают только номер.
При ссылках на документ допускается проставлять в квадратных скобках его порядковый номер в соответствии с перечнем ссылочных документов.
Допускается указывать только обозначение документа и (или) разделов без указания их наименований. Ссылки на отдельные подразделы, пункты и иллюстрации другого документа не допускаются. Допускаются ссылки внутри документа на пункты, иллюстрации и отдельные подразделы.
(Измененная редакция, Изм. № 1).

2.6. Таблицы
2.6.1. Цифровой материал для достижения лучшей наглядности и сравнимости показателей, как правило, следует оформлять в виде таблицы.
2.6.2. Оформление таблиц должно производиться в соответствии с требованиями ГОСТ 1.5-68.
Таблица может иметь заголовок, который следует выполнять строчными буквами. Прописными должны печататься заглавные буквы и аббревиатуры.
(Измененная редакция, Изм. № 1).
2.6.3. Сноски к таблицам располагают непосредственно под таблицей. Например:

Наборы данных, используемые для распечатки

Для информационной распечатки

SSSSSSS1) Печатающее устройство2)

Для распечатки во время выполнения программы

РРРРРРРР Печатающее устройство2)
1) Имя SSSSSSS должно быть задано при настройке операционной системы.
2) Для уменьшения простоев центрального процессора из-за операций ввода-вывода может быть использована магнитная лента.

П р и м е ч а н и е.
или

П р и м е ч а н и я:1. 2.
2.7.2. Текст примечаний допускается печатать только через один интервал.

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

сокращений, установленных в ГОСТ 2.316-68, и общепринятых в русском языке;

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

3. ТРЕБОВАНИЯ К ПРОГРАММНЫМ ДОКУМЕНТАМ, СОДЕРЖАЩИМ ТЕКСТ, РАЗБИТЫЙ НА ГРАФЫ.
3.1. Программные документы, содержащие текст, разбитый на графы, при необходимости разделяют на разделы и подразделы, которые не нумеруют. Допускается линии, разграничивающие строки и графы, не наносить.
3.2. Наименования разделов и подразделов записывают в виде заголовков строчными буквами (кроме первой прописной) и подчёркивают.
Расстояние между заголовком и последующим текстом, между текстом и последующим заголовком и между заголовками должны соответствовать указанным в п. 2.1.8.
3.3. Примечания в документе оформляются в порядке, изложенном в п. 2.7.
3.4. В таблицах и формах, имеющих строки, все записи размещают на каждой строке в один ряд.
Записи не должны сливаться с линиями, разграничивающими строки и графы.
Следует оставлять свободные строки между разделами и подразделами, а в документах большого объёма - также внутри разделов и подразделов.
Если в графе документа записан текст в несколько строк, то в последующих графах записи начинают на уровне первой строки. Допускается помещать запись на уровне последней строки, если она занимает одну строку.
(Измененная редакция, Изм. № 1).
ПРИЛОЖЕНИЕ 1

ИНФОРМАЦИОННЫЕ ДАННЫЕ О СООТВЕТСТВИИ ГОСТ 19.106-78

СТРУКТУРА ТЕКСТА ПРОГРАММНОГО ДОКУМЕНТА

United system for program documentation.

1. ОСНОВНЫЕ ПОЛОЖЕНИЯ
1.1. В состав основных надписей листа утверждения и титульного листа в программных документах входят следующие структурные данные:

наименование министерства (ведомства);

сведения о носителе данных, на котором представляется подлинник;

общее количество листов утверждения, объём документа;

сведения о разработчике;

отметка об учёте и хранении;

сведения об изменении.

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

поле 3 - полное наименование программы или программного изделия (прописными буквами), наименование и вид документа.
Наименование документа может быть опущено или объединено с наименованием программы;

поле 4 - обозначение документа и указание вида носителя данных.
Вид носителя данных указывают только в случае выполнения документа на носителе данных;

поле 6 - в правой части поля - должности и подписи руководителя организации, выпустившей документ, руководителя подразделения, разработавшего документ, руководителя разработки (разработчика), исполнителей разработки документа и нормоконтролёра.
Справа от каждой подписи проставляют инициалы и фамилию лица, подписавшего документ, а ниже подписи - дату подписания.
При большом количестве согласующих подписей их размещают либо в левой части поля 2, либо в левой части поля 6.
Визы других должностных лиц, если они необходимы на документе, размещают на поле для подшивки ЛУ;

поле 8 - отметка об учёте и хранении по ГОСТ 19.601-78;

поле 9 - строка изменений по ГОСТ 19.604-78;

поле 10 - литера документа.
Пример заполнения ЛУ приведён в справочном приложении 2. Количество подписей в приложении приведено условно.

3. ОСНОВНЫЕ НАДПИСИ ТИТУЛЬНОГО ЛИСТА
3.1. Титульный лист заполняют по форме и правилам, установленным для ЛУ, при этом:

поле 1 - заполняют по требованию заказчика;

поле 2 - не заполняют;

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

поле 5 - указывают объём документа;

поле 6- не заполняют;

поле 8 - отметка об учёте и хранении по ГОСТ 19.601-78;

поле 9 - строка изменений по ГОСТ 19604-78;

поле 10 - литера документа.
3.2. На титульном листе в левом верхнем углу должна быть надпись:

Пример заполнения титульного листа приведён в справочном приложении 3.

4. ОСНОВНЫЕ НАДПИСИ В ТЕКСТЕ ДОКУМЕНТА.
4.1. Содержание и правила выполнения основных надписей в программных документах на конкретных носителях данных приведены в соответствующих государственных стандартах ЕСПД.
4.2. Содержание и правила выполнения основных надписей последующих листов программных документов, выполненных печатным способом, приведены в ГОСТ 19.106-78.
ПРИЛОЖЕНИЕ 1

ИНФОРМАЦИОННЫЕ ДАННЫЕ О СООТВЕТСТВИИ ГОСТ 19.104-78

ПРИМЕР ЗАПОЛНЕНИЯ ЛИСТА УТВЕРЖДЕНИЯ

(подпись) А. А. Петров

(подпись) Н. Н. Сизов

ЕДИНАЯ СИСТЕМА ЭЛЕКТРОННЫХ ВЫЧИСЛИТЕЛЬНЫХ

МАШИН ОПЕРАЦИОННАЯ СИСТЕМА

А.В.00001-01 33 01-1-ЛУ

(вид носителя данных)
Листов 2
СОГЛАСОВАНО
Руководитель ВЦ

(подпись) И. И. Павлов

Главный инженер завода

(подпись) А. А. Иванов

(подпись) А. В. Басов

15.02.1978
Начальник отдела 12

(подпись) Г. Ф. Сизов

(подпись) Л. А. Соколов

(подпись) А. М. Пашин

(подпись) Г. В. Громова

1982
Литера

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

Во-вторых, грамотно составленный (точнее, созданный) пакет ПД избавит от многих неприятностей. В частности, избавиться от назойливых вопросов и необоснованных претензий можно просто предоставив пользователю документацию. Это касается, прежде всего, важнейшего документа – Технического задания. Например, многомиллионный иск к компании IBM. Этот иск предъявило одно крупное издательство, неудовлетворенное качеством ВТ и программного обеспечения. IBM суд выиграла. И выиграла только благодаря тому, что предъявила подписанное обеими сторонами Техническое задание. Было это давно, еще в 70-х гг., однако сути дела это не меняет.

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

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

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

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

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

В состав ЕСПД входят:

- основополагающие и организационно методические стандарты;

- стандарты, определяющие форму и содержание программных документов применяемых для обработки данных;

- стандарты, обеспечивающие автоматизацию разработки программных документов.

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

Стандарты ЕСПД носят рекомендательный характер.

Стандарты ЕСПД разделяются на группы:

- 0 код - группы об общем положении;

- 1 код - группы основополагающей стандартов;

- 2 код - правила выполнения документации разработки;

- 3 код - правила выполнения документации изготовителя;

- 4 код - правила выполнения документации сопровождения;

- 5 код - правила выполнения эксплуатационных документов;

- 6 код - правила обращения программной документации;

- 7-8 резервные группы;

- 9 прочие стандарты.

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

В обозначении стандартов ЕСПД должны входить:

- цифры 1 и 9 присвоены классу стандартов ЕСПД;

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

- двузначное число, определяющее порядковый номер группы;

- двузначное число после тире (-) указывающее год регистрации стандартов (рисунок 27.1).

Рисунок 27 – Схемы алгоритмов программ данных и систем

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

1. ГОСТ 19.001-77 ЕСПД. Общие положения.

2. ГОСТ 19.101-77 ЕСПД. Виды программ и программных документов (переиздан в ноябре 1987г с изм.).

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 ЕСПД. Описание языка.

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

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

23. ГОСТ 19.781-90. Обеспечение систем обработки информации программное.

Основополагающие стандарты

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

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

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

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

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

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

1. Спецификация – содержит состав, программу и документацию на нее.

2. Ведомость держателей подлинников - это перечень предприятий, на которых хранят подлинники программных документов (код 05).

3. Текст программы – это запись программы с необходимыми комментариями (код 12).

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

5. Программа и методика испытаний содержит требования подлежащие проверке при испытании программы, а так же порядок и методы их контроля (код 51).

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

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

Эксплуатационные документы содержат сведения для обеспечения функционирования и эксплуатации программы. К эксплуатационным документам относятся:

а) ведомость эксплуатационных документов, содержащая перечень эксплуатационных документов на программу (код 20);

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

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

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

д) руководство программиста, содержащее сведения для эксплуатации программ (код 32);

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

ж) описание языка, содержащее описание синтаксиса и семантики языка (код 35);

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

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

Стадии разработки программ

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

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

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

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

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

5. Внедрение. На этапе подготовки передачи программ осуществляют подготовку передачи программы и программной документации для сопровождения и изготовления, оформляют и утверждают акт о передаче программы на сопровождение и изготовление, передают программу в фонд алгоритмов и программ. [29]

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

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

Стандарты

международные. Отличительный признак — принят международной организацией. Пример такой организации — ISO (международная организация стандартизации). Пример её стандарта: ISO 2382-12:1988 (Переферийное оборудование). Распространены совместные стандарты ISO и международной электротехнической комиссии(IEC, в по русски — МЭК): например, ISO/IEC 12207:2008 (жизненный цикл ПО);
региональные. Отличительный признак — принят региональной комиссией по стандартизации. К примеру, многие советские ГОСТы сейчас являются региональным стандартом, т.к. приняты межгосударственным советом, куда входят некоторые бывшие советские республики. Этим советом принимаются и новые стандарты — и они тоже получают обозначение ГОСТ. Пример: ГОСТ 12.4.240-2013;
стандарты общественных объединений; К примеру, той же МЭК: IEC 60255;
национальные стандарты. Для России в начале таких стандартов — “ГОСТ Р”. Могут быть трех типов:
1. точные копии международных или региональных. Обозначаются неотличимо от “самописных” (национальных, написанных самостоятельно);
2. копии международных или региональных с дополнениями. Обозначаются добавлением к шифру отечественного стандарта шифра международного, который был взят за основу. Например: ГОСТ Р ИСО/МЭК 12207;
3. собственно, национальные стандарты. Например, ГОСТ Р 34.11-94.
Системы обозначений на каждом уровне и в каждой организации свои, для каждого случая придется разбираться отдельно. Чтобы быстро понять, “чей” стандарт перед глазами, можно использовать шпаргалку.

Итак: стандарты бывают международные, межгосударственные(региональные) и национальные. ГОСТ, как мы выяснили, это региональный стандарт. ГОСТы имеют достаточно запутанную, на мой взгляд, систему обозначений. Полностью она изложена в ГОСТ Р 1.5-2004, я приведу минимум, что бы в ней ориентироваться. Во первых, надо различать обозначение ГОСТа и его классификацию. Обозначение — это, грубо говоря, уникальный идентификатор стандарта. Код по классификатору — это вспомогательный код, помогающий найти стандарт или определить, к какой области знаний он относиться. Классификаторов может быть много, в основном используются два: КГС (классификатор государственных стандартов) и его наследник ОКС (общероссийский классификатор стандартов). Например: “ГОСТ Р 50628—2000“ — это обозначение стандарта.По обозначению понятно только то, что он принят в 2000 году. Он имеет код по ОКС “33.100;35.160”: т.е. “33” — раздел “Телекоммуникации, аудио, видео”, “100” — подраздел “электромагнитная совместимость”. Однако он также входит в ветвь классификатора 35.160. “35” — “Информационные технологии. Машины конторские”, “160” — “Микропроцессорные системы. ”. А по КГС он имеет код “Э02”, что означает “Э” — “Электронная техника, радиоэлектроника и связь”, “0” — “Общие правила и нормы по электронной технике, радиоэлектронике и связи”, и т.д.
1. стандарт относиться к серии стандартов. В этом случае после индекса категории стандарта (например, ГОСТ, ГОСТ Р или ГОСТ РВ) идет код серии, точка и обозначение стандарта внутри серии. Правила обозначения стандартов внутри серии устанавливаются правилами серии. Например: ГОСТ РВ 15.201-2000, ГОСТ Р 22.8.0-99, ГОСТ 19.101-77;
2. стандарт не относиться к серии стандартов. Тогда после индекса категории идет просто порядковый номер стандарта, тире и год принятия. Например, ГОСТ Р 50628—2000.
- ГОСТ ЕСКД (единая система конструкторской документации, префикс “2.”);
- ГОСТ ЕСТД (единая система технологической документации, префикс “3.”);
- ГОСТ Р, Система разработки и постановки продукции на производство, префикс “15.”;
- ГОСТ РВ, Вооружение и военная техника. Система разработки и постановки продукции на производство, префикс “15.”;
- ГОСТ, Система технической документации на АСУ, префикс “24.”;
- ГОСТ, Комплекс стандартов на автоматизированные системы, префикс “34.”.
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.
В настоящее время к этому стандарту приходиться обращаться очень редко: разве что забывается порядок следования основных частей документа.
- Для учеников 1-11 классов и дошкольников
- Бесплатные сертификаты учителям и участникам
Описание презентации по отдельным слайдам:

Канд. пед. наук, доцент И.В.Гаврилова
2014

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

определяют основные термины, относящиеся к программным продуктам и документам.
ГОСТ 19.004-80. Единая система программной документации. Термины и определения
ГОСТ 19.101-77. Единая система программной документации. Виды программ и программных документов

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

ГОСТ 19781-90
Не ЕСПД
ПО
Составная часть АС и АПК
Должно входить в спецификацию комплекса, раздел:
Комплексы, если ПО удовлетворяет определению комплекса;
Прочие изделия, если ПО- самостоятельный и единственный компонент
Комплекты, если ПО – совокупность программных компонентов, имеющих общее эксплуатационное назначение вспомогательного характера, но не выполняющих взаимосвязанные функции
4

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

6
Виды эксплуатационных документов (19.101)

ПД и стадии
7
Условные обозначения:
- документ обязательный;
- документ обязательный для компонентов, имеющих самостоятельное применение;
- необходимость составления документа определяется на этапе разработки и утверждения технического задания;
- - документ не составляют.

Правила обозначения ПД по ГОСТ 19.103-77
Другие ПД
8

Стадии разработки по ГОСТ 19.102-77
9

Стадии разработки по ГОСТ 19.102-77
10

Стадии разработки по ГОСТ 19.102-77
11

34.201-89 - Руководство пользователя

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

Рекомендации
При проектировании АПК и АС удобно вести параллельную разработку аппаратной и программной частей по правилам ЕСКД и КСАС с учетом специфики, накладываемой требованиями ЕСПД.
Целесообразно для ПО АПК не разрабатывать ни руководство оператора, ни руководство пользователя, а порядок работы с ПО излагать в руководстве по эксплуатации комплекса, используя рекомендации по построению руководства пользователя АС.

Текст программы (19.401-78)
Структуру и оформление документа устанавливают в соответствии с ГОСТ 19.105-78.
Составление информационной части (аннотация и содержание) является необязательным. Для текста программы на исходном языке при наличии аннотации в нее включают краткое описание функций программы.
Основная часть документа должна состоять из текстов одного или нескольких разделов, которым даны наименования.
Допускается вводить наименования также и для совокупности разделов.
Каждый из разделов реализуется одним из типов символической записи, например:
символическая запись на исходном языке;
символическая запись на промежуточных языках;
символическое представление машинных кодов и т.п.
В символическую запись разделов рекомендуется включать комментарии, которые могут отражать, например, функциональное назначение, структуру.
20

Описание программы (19.402-78)
Структуру и оформление документа устанавливают в соответствии с ГОСТ 19.105-78.
Составление информационной части (аннотации и содержания) является обязательным.
Описание программы должно содержать следующие разделы:
общие сведения;
функциональное назначение;
описание логической структуры;
используемые технические средства;
вызов и загрузка;
входные данные;
выходные данные.
В зависимости от особенностей программы допускается вводить дополнительные разделы или объединять отдельные разделы.
Допускается содержание разделов иллюстрировать пояснительными примерами, таблицами, схемами, графиками.
В приложение к описанию программы допускается включать различные материалы, которые нецелесообразно включать в разделы описания.

Руководство системного программиста Содержание разделов
28

Читайте также: