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

Состав еспд

ГОСТ 19.004 ЕСПД. Термины и определения.

ГОСТ 19.101 ЕСПД. Виды программ и программных документов.

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

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

ГОСТ 19.104 ЕСПД. Основные надписи.

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

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

ГОСТ 19.201 ЕСПД. Техническое задание. Требование к содержанию и оформлению.

ГОСТ 19.202 ЕСПД. Спецификация. Требование к содержанию и оформлению.

ГОСТ 19.401 ЕСПД. Текст программы. Требование к содержанию и оформлению.

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

ГОСТ 19.501 ЕСПД. Формуляр. Требование к содержанию и оформлению.

ГОСТ 19.502 ЕСПД. Общее описание. Требование к содержанию и оформлению.

ГОСТ 19.503 ЕСПД. Руководство системного программиста. Требование к содержанию и оформлению.

ГОСТ 19.504 ЕСПД. Руководство программиста. Требование к содержанию и оформлению.

ГОСТ 19.505 ЕСПД. Руководство оператора. Требование к содержанию и оформлению.

ГОСТ 19.506 ЕСПД. Описание языка. Требование к содержанию и оформлению.

ГОСТ 19.601 ЕСПД. Общее правила дублирования, учета и хранения.

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

ГОСТ 19.603 ЕСПД. Общие правила внесения изменений.

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

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

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

В стандартах ЕСПД устанавливаются требования, регламентирующие

разработку,

сопровождение,

изготовление и

эксплуатацию программ.

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

В состав ЕСПД входят следующие группы стандартов:

0 – Общие положения.

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

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

3 – Правила выполнения документации выполнения.

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

5 – Правила выполнения эксплуатационной документации.

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

7 – Резервная группа.

8 – Резервная группа.

9 – Прочие стандарты.

ГОСТ 19.101 ЕСПД. Виды программ и программных документов.

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

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

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

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

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

Виды программных документов (выборка для условий проектирования программ для ПЭВМ):

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

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

Ведомость держателей подлинника. Перечень фирм, на которых хранят оригиналы программ и подлинники программной документации.

Текст программы. Запись программы с необходимыми коментариями.

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

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

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

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

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

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

ГОСТ 19.201 ЕСПД. Техническое задание. Требование к содержанию и оформлению.

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

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

Наименование и область применения.

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

Основание для разработки.

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

Назначение разработки.

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

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

В разделе должны содержаться следующие подразделы:

Требования к функциональным характеристикам.

Условия эксплуатации.

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

Требования к информационной и программной совместимости.

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

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

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

Технико-экономические показатели.

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

Стадии и этапы разработки.

Порядок контроля и приемки.

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

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

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

В разделе «Функциональное назначение» указывается назначение программы и приводят общее описание функционирования программы и сведения об ограничениях на применение.

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

Описание структуры программы и ее составных частей.

Описание функций составных частей и связей между ними.

Сведения о языке программирования.

Описание входных и выходных данных для каждой из составных частей.

Описание логики составных частей (при необходимости составляются описания схем программ).

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

ГОСТ 19.505 ЕСПД. Руководство оператора. Требование к содержанию и оформлению.

Документ должен содержать следующие разделы:

Назначение программы.

Условия применения.

Пуск программы.

Команды оператора.

Сообщения оператору.

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

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

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

ГОСТ 19.001-77 Общие положения

ГОСТ 19781-90 Термины и определения.

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

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

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

ГОСТ 19.104-78 Основные надписи

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

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

ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению

ГОСТ 19.202-78 Спецификация. Требования к содержанию и оформлению

ГОСТ 19.301-79 Программа и методика испытаний. Требования к содержанию и оформлению

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

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

ГОСТ 19.403-79 Ведомость держателей подлинников

ГОСТ 19.404-79 Пояснительная записка. Требования к содержанию и оформлению

ГОСТ 19.501-78 Формуляр. Требования к содержанию и оформлению

ГОСТ 19.502-78 Описание применения. Требования к содержанию и оформлению

ГОСТ 19.503-79 Руководство системного программиста. Требования к содержанию и оформлению

ГОСТ 19.504-79 Руководство программиста. Требования к содержанию и оформлению ГОСТ 19.505-79 Руководство оператора. Требования к содержанию и оформлению

ГОСТ 19.506-79 Описание языка. Требования к содержанию и оформлению

ГОСТ 19.507-79 Ведомость эксплуатационных документов

ГОСТ 19.508-79 Руководство по техническом обслуживанию. Требования к содержанию и оформлению

ГОСТ 19.601-78 Общие правила дублирования, учета и хранения

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

ГОСТ 19.603-78 Общие правила внесения изменений

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

ТЕХНИЧЕСКОЕ ЗАДАНИЕ.

ТРЕБОВАНИЯ К СОДЕРЖАНИЮ И ОФОРМЛЕНИЮ

ГОСТ 19.201-78

с 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. Техническое задание должно содержать следующие разделы:

введение;

· основания для разработки;

· назначение разработки;

· требования к программе или программному изделию;

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

· технико-экономические показатели;

· стадии и этапы разработки;

· порядок контроля и приемки;

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

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

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

(Измененная редакция, Изм. № 1)

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

· документ (документы), на основании которых ведется разработка;

· организация, утвердившая этот документ, и дата его утверждения;

· наименование и (или) условное обозначение темы разработки.

(Измененная редакция, Изм. № 1)

2.3. В разделе «Назначение разработки» должно быть указано функциональное и эксплуатационное назначение программы или программного изделия.

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

· требования к функциональным характеристикам;

· требования к надежности;

· условия эксплуатации;

· требования к составу и параметрам технических средств;

· требования к информационной и программной совместимости;

· требования к маркировке и упаковке;

· требования к транспортированию и хранению;

· специальные требования.

(Измененная редакция, Изм. № 1)

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

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

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

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

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

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

(Измененная редакция, Изм. № 1)

2.4.6. В подразделе «Требования к маркировке и упаковке» в общем случае указывают требования к маркировке программного изделия, варианты и способы упаковки.

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

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

(Введен дополнительно, Изм. № 1).

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

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

2.7. В разделе «Порядок контроля и приемки» должны быть указаны виды испытаний и общие требования к приемке работы.

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

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

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

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

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

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

ГОСТ 19.106-78

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

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

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

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

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

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

§ лист утверждения (не входит в общее количество листов документа);

§ титульный лист (первый лист документа);

§ информационная часть:

§ аннотация;

§ основная часть:

§ текст документа (с рисунками, таблицами и т.п.);

§ приложения;

§ перечень терминов;

§ перечень сокращений;

§ перечень рисунков;

§ перечень таблиц;

§ предметный указатель;

§ перечень ссылочных документов;

§ перечень символов и числовых коэффициентов;

§ часть регистрации изменений:

§ лист регистрации изменений.

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

(Измененная редакция, Изм. № 1)

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

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

(Введен дополнительно, Изм. № 1)

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

2.1. Построение документа.

2.1.1. При необходимости допускается делить документ на части. Деление на части осуществляется на уровне не ниже раздела. Каждую часть комплектуют отдельно. Всем частям присваивают обозначение документа в соответствии с ГОСТ 19.103-77.

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

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

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

Отдельная нумерация страниц документа в пределах раздела и подраздела не допускается.

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

2.1.2. Информационная и основная части программного документа выполняются по форме 1 или 2, где:

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

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

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

поле 4 - строка изменений; заполняется в соответствии с требованиями ГОСТ 19.604-78.

Рамку (границы) формата страниц документа допускается не наносить.

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

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

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

2.1.3, 2.1.4. (Измененная редакция, Изм. № 1).

2.1.5. Текст каждого документа, при необходимости, разбивается на пункты, а пункты - на подпункты, независимо от того, разделён документ на части, разделы и подразделы или нет.

2.1.6. Структурными элементами текста документа являются разделы, подразделы, пункты, подпункты и перечисления.

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

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

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

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

Абзац - логически выделенная часть текста, не имеющая номера.

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

Допускается помещать текст между заголовками раздела и подраздела, между заголовками подраздела и пункта.

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

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

(Измененная редакция, Изм. № 1).

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

Заголовки подразделов записывают с абзаца строчными буквами (кроме первой прописной).

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

Переносы слов в заголовках не допускаются. Точку в конце заголовка не ставят.

Если заголовок состоит из двух предложений, их разделяют точкой.

(Измененная редакция, Изм. № 1).

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

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

при выполнении рукописным способом - 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. Для выделения отдельных понятий допускается изменять интервалы между словами, а также печатать отдельные слова или части текста шрифтом, отличным от печати основного текста, например:

UNCATLG - указывает, что запись каталога, относящаяся кисходному набору данных, должна быть исключена.ТО = устройство = список - указывает носители данных, на которыеосуществляется...АВС3-91 СИНТАКСИЧЕСКАЯ ОШИБКАПРИЧИНА. Указанный в сообщении...ДЕЙСТВИЯ СИСТЕМЫ. Задание не выполняется...ДЕЙСТВИЯ ПРОГРАММИСТА. Необходимо обеспечить...

2.2.4. Необходимые пояснения к тексту документа могут оформляться сносками.

Сноска обозначается цифрой со скобкой, вынесенными на уровень линии верхнего обреза шрифта, например: «печатающее устройство2)...» или «бумага5)».

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

2.3. Иллюстрации.

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

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

В приложениях иллюстрации нумеруются в пределах каждого приложения в порядке, установленном для основного текста документа.

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

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

(Измененная редакция, Изм. № 1).

2.4. Формулы.

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

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

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

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

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

(Измененная редакция, Изм. № 1).

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

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) Для уменьшения простоев центрального процессора из-за операций ввода-вывода может быть использована магнитная лента.

2.7. Примечания.

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

Одно примечание не нумеруется. После слова «Примечание» ставят точку.

Несколько примечаний следует нумеровать по порядку арабскими цифрами с точкой. После слова «Примечание» ставят двоеточие.

Например:

П р и м е ч а н и е.

П р и м е ч а н и я:1. 2.

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

2.8. Сокращения.

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

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

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

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

(Измененная редакция, Изм. № 1).

2.9. Приложения

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

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

2.9.2. Каждое приложение должно начинаться с новой страницы с указанием в правом верхнем углу слова «ПРИЛОЖЕНИЕ» и иметь тематический заголовок, который записывают симметрично тексту прописными буквами.

При наличии в документе более одного приложения все приложения нумеруют арабскими цифрами (без знака №), например, ПРИЛОЖЕНИЕ 1, ПРИЛОЖЕНИЕ 2 и т. д.

При выпуске приложения отдельным документом, на титульном листе под наименованием документа следует указывать слово «ПРИЛОЖЕНИЕ», а при наличии нескольких приложений указывают также их порядковые номера.

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

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

(Измененная редакция, Изм. № 1).

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

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

(Измененная редакция, Изм. № 1).

Все приложения должны быть перечислены в листе «Содержание».

3. ТРЕБОВАНИЯ К ПРОГРАММНЫМ ДОКУМЕНТАМ, СОДЕРЖАЩИМ ТЕКСТ, РАЗБИТЫЙ НА ГРАФЫ.

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

3.2. Наименования разделов и подразделов записывают в виде заголовков строчными буквами (кроме первой прописной) и подчёркивают.

Расстояние между заголовком и последующим текстом, между текстом и последующим заголовком и между заголовками должны соответствовать указанным в п. 2.1.8.

3.3. Примечания в документе оформляются в порядке, изложенном в п. 2.7.

3.4. В таблицах и формах, имеющих строки, все записи размещают на каждой строке в один ряд.

Записи не должны сливаться с линиями, разграничивающими строки и графы.

Следует оставлять свободные строки между разделами и подразделами, а в документах большого объёма - также внутри разделов и подразделов.

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

(Измененная редакция, Изм. № 1).

ПРИЛОЖЕНИЕ 1

Справочное

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

СТ СЭВ 2088-80

Разд. 1 ГОСТ 19.106-78 соответствует разд. 1 и разд. 4 (п. 4.1) СТ СЭВ 2088-80.

Разд. 2 ГОСТ 19.106-78 соответствует разд. 4 (пп. 4.4-4.9) СТ СЭВ 2088-80.

(Введено дополнительно, Изм. № 1).

ПРИЛОЖЕНИЕ 2

Справочное

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

ОСНОВНЫЕ НАДПИСИ

United system for program documentation.

Постановлением Государственного комитета СССР по стандартам от 18 декабря 1978 г. № 3351 срок введения установлен

с 01.01 1980 г.

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

Стандарт соответствует СТ СЭВ 2088-80 в части оформления листа утверждения и титульного листа (см. справочное приложение 1).

1. ОСНОВНЫЕ ПОЛОЖЕНИЯ

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

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

наименование документа;

обозначение документа;

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

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

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

виза нормоконтролёра;

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

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

2. ОСНОВНЫЕ НАДПИСИ ЛИСТА УТВЕРЖДЕНИЯ (ЛУ)

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

2.2. Обозначение листа утверждения состоит из обозначения документа, к которому относится лист утверждения, и через дефис – шифра ЛУ.

Лист утверждения не входит в общее количество листов документа.

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

Второй и последующие листы утверждения оформляют в соответствии с разд. 1 ГОСТ 19.106-78, при этом в поле «Текст документа» приводят должности и подписи лиц, не уместившихся на первом листе листа утверждения.

2.4. Лист утверждения вносят в спецификацию после утвержденного документа и хранят на предприятии – держателе подлинника документа.

Лист утверждения спецификации также вносят в данную спецификацию.

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

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

2.5. Лист утверждения заполняют по форме, приведенной на чертеже:

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

Заполняют по требованию заказчика.

Выше поля 1, в правом верхнем углу, при необходимости ставится специальная отметка (гриф секретности, указание «С предприятия не выносить» и т.п.);

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

Согласующие и утверждающие организации, а также конкретные подписи должностных лиц регламентируют министерства и ведомства;

Наименование документа может быть опущено или объединено с наименованием программы;

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

поле 5 - общее количество листов утверждения, например, «Листов 3». Для одного листа поле 5 не заполняют;

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

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

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

Визы других должностных лиц, если они необходимы на документе, размещают на поле для подшивки ЛУ;

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

поле 10 - литера документа.

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

3. ОСНОВНЫЕ НАДПИСИ ТИТУЛЬНОГО ЛИСТА

3.1. Титульный лист заполняют по форме и правилам, установленным для ЛУ, при этом:

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

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

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

Наименование документа может быть опущено или объединено с наименованием продукта. Допускается указывать сокращённое наименование программы или программного изделия;

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

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

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

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

поле 7 - год издания (утверждения) документа (без указания слова «год» или «г»);

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

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

поле 10 - литера документа.

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

Утвержден----------------------обозначение ЛУ

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

4. ОСНОВНЫЕ НАДПИСИ В ТЕКСТЕ ДОКУМЕНТА.

ПРИЛОЖЕНИЕ 1

Справочное

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

СТ СЭВ 2088-80

Разд. 1 и 2 ГОСТ 19.104-78 соответствует разд. 2 СТ СЭВ 2088-80

Разд. 3 ГОСТ 19.104-78 соответствует разд. 3 СТ СЭВ 2088-80

ПРИЛОЖЕНИЕ 2

Справочное

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

СОГЛАСОВАНО

Руководитель ЦКБ

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

УТВЕРЖДАЮ

Начальник управления

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

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

Загрузчик

Руководство программиста

ЛИСТ УТВЕРЖДЕНИЯ

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

(вид носителя данных)

СОГЛАСОВАНО

Руководитель ВЦ

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

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

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

Представители

предприятия-разработчика

Главный инженер

НИИавтоматика

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

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

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

Руководитель разработки

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

Исполнитель

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

Нормоконтролер

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

ПРИЛОЖЕНИЕ 3

Справочное

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

УТВЕРЖДЕНО

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

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

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

Загрузчик

Руководство программиста

А.В.00001-01 33 01-1

(вид носителя данных)

|

следующая лекция ==> III. Состав разделов проектной документации на линейные объекты капитального строительства и требования к содержанию этих разделов III. Составление нормативной технологической документации Единая система программной документации (ЕСПД) - комплекс государственных стандартов, устанавливающих взаимосвязанные правила разработки, оформления и обращения программ и программной документации. В стандартах ЕСПД устанавливают требования, регламентирующие разработку, сопровождение, изготовление и эксплуатацию программ, что обеспечивает возможность: Унификации программных изделий для взаимного обмена программами и применения ранее разработанных программ в новых разработках; Снижения трудоемкости и повышения эффективности разработки, сопровождения, изготовления и эксплуатации программных изделий; Автоматизации изготовления и хранения программной документации. Сопровождение программы включает анализ функционирования, развитие и совершенствование программы, а также внесение изменений в нее с целью устранения ошибок. Быстрое увеличение сложности и размеров современных комплексов программ при одновременном росте ответственности выполняемых функций резко повысило требования со стороны заказчиков и пользователей к их качеству и безопасности применения. Испытанным средством обеспечения высокой эффективности и качества функционирования программ и программных комплексов являются международные стандарты, разработанные при участии представителей ведущих компаний отрасли. По мере расширения применения и увеличения сложности информационных систем ошибки или недостаточное качество программ могут нанести ущерб, значительно превышающий положительный эффект от их использования. ГОСТ 28195-89 устанавливает общие положения по оценке качества программных средств (ПС) вычислительной техники, поставляемых через фонды алгоритмов и программ (ФАП), номенклатуру и применяемость показателей качества ПС. Оценка качества ПС представляет собой совокупность операций, включающих выбор номенклатуры показателей качества оцениваемого ПС, определение значений этих показателей и сравнение их с базовыми значениями. Согласно ГОСТ 28195-89, оценка качества осуществляется на всех этапах жизненного цикла ПС при: Планировании показателей качества ПС; Контроле качества на отдельных этапах разработки (техническое задание, технический проект, рабочий проект); Контроле качества в процессе производства ПС; Проверке эффективности модификации ПС на этапе сопровождения. Оценку качества проводят специалисты организаций: разработчика - на этапах разработки ПС; фондодержателя - на этапах приемки ПС в фонд; испытательных центров и центров сертификации ПС - на этапах испытаний и внедрения; изготовителя - на этапах тиражирования ПС; пользователя - на этапах внедрения, сопровождения и эксплуатации ПС. Основные задачи, решаемые при оценке качества ПС: Планирование уровня качества; Контроль значений показателей качества в процессе разработки и испытаний; Эксплуатационный контроль заданного уровня качества; Выбор базовых образцов по подклассам и группам; Методическое руководство разработкой нормативно-технических документов по оценке качества. Методы определения показателей качества ПС различаются: По способам получения информации о ПС - измерительный, регистрационный, органолептический, расчетный; По источникам получения информации - традиционный, экспертный, социологический. Измерительный метод основан на получении информации о свойствах и характеристиках ПС с использованием инструментальных средств. Например, с использованием этого метода определяется объем ПС - число строк исходного текста программ и число строк - комментариев, число операторов и операндов, число исполненных операторов, число ветвей в программе, число точек входа (выхода), время выполнения ветви программы, время реакции и другие показатели. Регистрационный метод основан на получении информации во время испытаний или функционирования ПС, когда регистрируются и подсчитываются определенные события, например, время и число сбоев и отказов, время передачи управления другим модулям, время начала и окончания работы. Органолептический метод основан на использовании информации, получаемой в результате анализа восприятия органов чувств (зрения, слуха), и применяется для определения таких показателей как удобство применения, эффективность и т.п. Расчетный метод основан на использовании теоретических и эмпирических зависимостей (на ранних этапах разработки), статистических данных, накапливаемых при испытаниях, эксплуатации и сопровождении ПС. При помощи расчетного метода определяются длительность и точность вычислений, время реакции, необходимые ресурсы. Определение значений показателей качества ПС экспертным методом осуществляется группой экспертов-специалистов, компетентных в решении данной задачи, на базе их опыта и интуиции. Экспертный метод применяется в случаях, когда задача не может быть решена никаким другим из существующих способов или другие способы являются значительно более трудоемкими. Экспертный метод рекомендуется применять при определении показателей наглядности, полноты и доступности программной документации, легкости освоения, структурности. Социологические методы основаны на обработке специальных анкет-вопросников. Отечественный стандарт ГОСТ 28195-89 определяет иерархическую структуру, номенклатуру и содержание понятий качества программных средств. На верхнем уровне выделены шесть характеристик: надежность, корректность, удобство применения, эффективность, универсальность и сопровождаемость, которые детализируются на втором уровне 19 комплексными показателями. На третьем уровне дальнейшая детализация содержит более чем 200 оценочных элементов. Состав используемых показателей рекомендуется выбирать в зависимости от назначения, функций и этапов жизненного цикла программного средства. Однако методы оценки показателей отсутствуют. Методологии оценивания характеристик качества готовых ПП на различных этапах жизненного цикла посвящен международный стандарт ISO / IEC 14598-1-6:1998-2001. С момента вступления в силу ГОСТ 28195-89 произошли существенные изменения во многих аспектах общественной жизни, в том числе существенно изменились экономико-правовые отношения и в сфере разработки и эксплуатации программных средств. Например, в области коммерческих программных продуктов исчез фондодержатель, а разработчик и изготовитель обычно представляют собой одно и то же юридическое лицо. В рыночных условиях разработчик заинтересован в обеспечении качества своих продуктов в течение всего их жизненного цикла. Кроме того, изменился порядок сертификации продукции. Отчуждение права на компьютерную программу осуществляется на основе договора. Сторона договора (разработчик) об отчуждении исключительного права на отчуждаемую программу, которую передает или обязуется передать принадлежащей ей исключительное право, именуется правообладателем. Сторона, принимающая по договору об отчуждении исключительного права на отчуждаемую программу, именуется приобретателем. По договору об отчуждении исключительного права правообладатель передает или обязуется передать принадлежащее ему исключительное право приобретателю в полном объеме (пункт 1 статьи 1234 и ст. 1285 ГК РФ). В договоре об отчуждении исключительного права законодательно не требуется указание срока и территории, поскольку передача исключительного права на программу для ЭВМ в полном объеме подразумевает передачу на весь срок действия исключительного права без ограничения территории. По договору об отчуждении исключительного права приобретатель обязуется уплатить правообладателю предусмотренное договором вознаграждение, если договором не предусмотрено иное. Поскольку договор об отчуждении исключительного права на зарегистрированную программу для ЭВМ подлежит государственной регистрации, то согласно пункту 4 статьи 1234 ГК РФ исключительное право на такие результаты переходит от правообладателя к приобретателю в момент государственной регистрации этого договора. По лицензионному договору одна сторона - автор или иной правообладатель (лицензиар) предоставляет либо обязуется предоставить другой стороне (лицензиату) право использования этого произведения в установленных договором пределах (не в полном объеме). Лицензионный договор о предоставлении права использования программы ЭВМ обязательной регистрации не подлежит. Разработчик программы в договоре может разрешить другой стороне пользоваться программой на определенных условиях (по срокам, по территории, по сдаче в прокат и др.). В этом случае программа остается неотчуждаемой от ее автора. Наиболее распространенными вопросами, возникающим в процессе разработки программного обеспечения, считается: Недостаток прозрачности. В любой момент времени сложно сказать, в каком состоянии находится проект и каков процент его завершения. Данная проблема возникает при недостаточном планировании структуры (или архитектуры) будущего программного продукта, что чаще всего является следствием отсутствия достаточного финансирования проекта: программа нужна, сколько времени займёт разработка, каковы этапы, можно ли какие-то этапы исключить или сэкономить - следствием этого процесса является то, что этап проектирования сокращается. Недостаток контроля. Без точной оценки процесса разработки срываются графики выполнения работ и превышаются установленные бюджеты. Сложно оценить объем выполненной и оставшейся работы. Данная проблема возникает на этапе, когда проект, завершенный более, чем на половину, продолжает разрабатываться после дополнительного финансирования без оценки степени завершенности проекта. Недостаток трассировки. Недостаток мониторинга. Невозможность наблюдать ход развития проекта не позволяет контролировать ход разработки в реальном времени. С помощью инструментальных средств менеджеры проектов принимают решения на основе данных, поступающих в реальном времени. Данная проблема возникает в условиях, когда стоимость обучения менеджмента владению инструментальными средствами, сравнима со стоимостью разработки самой программы. Неконтролируемые изменения. У потребителей постоянно возникают новые идеи относительно разрабатываемого программного обеспечения. Влияние изменений может быть существенным для успеха проекта, поэтому важно оценивать предлагаемые изменения и реализовывать только одобренные, контролируя этот процесс с помощью программных средств. Данная проблема возникает вследствие нежелания конечного потребителя использовать те или иные программные среды. Например, когда при создании клиент-серверной системы потребитель предъявляет требования не только к операционной системе на компьютерах-клиентах, но и на компьютере-сервере. Недостаточная надежность. Самый сложный процесс - поиск и исправление ошибок в программах на ЭВМ. Поскольку число ошибок в программах заранее неизвестно, то заранее неизвестна и продолжительность отладки программ и отсутствие гарантий отсутствия ошибок в программах. Следует отметить, что привлечение доказательного подхода к проектированию ПО позволяет обнаружить ошибки в программе до ее выполнения. Данная проблема возникает при неправильном выборе средств разработки. Например, при попытке создать программу, требующую средств высокого уровня, с помощью средств низкого уровня. Например, при попытке создать средства автоматизации с СУБД на ассемблере. В результате исходный код программы получается слишком сложным и плохо поддающимся структурированию. Отсутствие гарантий качества и надежности программ из-за отсутствия гарантий отсутствия ошибок в программах вплоть до формальной сдачи программ заказчикам. Данная проблема не является проблемой, относящейся исключительно к разработке ПО. Гарантия качества - это проблема выбора поставщика товара (не продукта). Правовые, экономические и другие вопросы создания программного обеспечения Нормативно-правовая база программного обеспечения должна включать правовые нормы, регламентирующие: Права собственности на ПО и хранящуюся в нем информацию; Способы получения информации для заполнения соответствующих баз данных; Права юридических и физических лиц на информацию; Способы защиты прав государства и потребителя информации; Правоотношения (права, обязанности и ответственность) между лицами, обслуживающими ПО; Юридическую силу информации на носителях и документов, используемых при функционировании ПО. Основные положения, определяющие экономические основы создания программного обеспечения, сводятся к следующему: Финансирование работ по созданию и обеспечению функционирования ПО из федеральных бюджетных средств, выделяемых на государственное управление, из бюджетных средств ведомств (организаций, учреждений) - потенциальных пользователей информацией и вступивших в кооперацию с Мингосимуществом России по созданию ПО государственной собственности (ГС), а также за счет внебюджетных финансовых ресурсов; Осуществление контроля за использованием бюджетных средств, направляемых на создание и развитие ПО; Предоставление льгот по информационному обеспечению организациям, участвующим в управлении государственной собственностью, а также инвесторам ПО; Предоставление права Мингосимуществу России устанавливать цену на конкретные информационные продукты и услуги; Осуществление государственного контроля над ценами на определенный период или на определенный вид информационной продукции; Установление государством цен на информационную продукцию (услуги), выполненную по государственному заказу и за счет бюджетных средств. При этом решаются организационные вопросы, регламентирующие взаимодействие работников с техническими средствами и между собой в процессе разработки и эксплуатации программного обеспечения. Термин "интеллектуальная собственность" эпизодически употреблялся теоретиками - юристами и экономистами в XVIII и XIX веках, однако в широкое употребление вошел лишь во второй половине XX века, в связи с учреждением в 1967 году в Женеве Всемирной организации интеллектуальной собственности (ВОИС). Согласно учредительным документам ВОИС, "интеллектуальная собственность" включает права, относящиеся к: Литературным, художественным и научным произведениям: Исполнительской деятельности артистов, звукозаписи, радио и телевизионным передачам: Изобретениям во всех областях человеческой деятельности: Научным открытиям; Промышленным образцам; Товарным знакам, знакам обслуживания, Фирменным наименованиям и коммерческим обозначениям; Защите против недобросовестной конкуренции; А также все другие права, относящиеся к интеллектуальной деятельности в производственной, научной, литературной и художественной областях. Позднее в сферу деятельности ВОИС были включены исключительные права, относящиеся к географическим указаниям, новым сортам растений и породам животных, интегральным микросхемам, радиосигналам, базам данных, доменным именам. Каждый объект интеллектуальной собственности обладает свойством индивидуальности, так как при его создании были использованы достижения интеллекта человека, индивидуальные свойства мышления и восприятия. Объект интеллектуальной собственности всегда находятся в тесном взаимодействии с объектами вещного права и всегда получают свое воплощение в материальных предметах, но существуют обособленно, что позволяет использовать объект интеллектуальной собственности независимо от своего материального носителя. Особые общественные отношения, складывающиеся по поводу объекта интеллектуальной собственности, являются отдельным объектом правового регулирования. О постепенном изменении отношения государства к результатам интеллектуальной деятельности, которые все больше приобретают черты товара, созданного для функционирования на рынке, свидетельствует и введение правовой охраны на программ для ЭВМ. Программное обеспечение охраняется как объект интеллектуальной собственности нормами права. В отношении этого вида объекта существует специальное правовое регулирование, введенное Законом "О правовой охране программ для электронных вычислительных машин и баз данных", который вступил в силу с 20.10.1992 года. Вопросы для самопроверки 1. Какими показателями качества определяются программы? 2. Что такое программный продукт? 3. Что понимается под жизненным циклом программного обеспечения? 4. Для какой цели определяются спецификации программного обеспечения? 5. Какие существуют стадии разработки программного обеспечения? 7. Что понимается под верификацией и сертификацией программного продукта? 8. В чем сущность модульной структуры программного обеспечения? 9. В чем разница между автономной и комплексной отладками программного обеспечения? 10. Что такое - переносимость программ? 11. Какими свойствами обладают открытые системы? 12. Что понимается под Единой системой программной документации? 13. Как оформляется отчуждаемая программа? 14. Каким правовым законом охраняется интеллектуальная собственность на программы для ЭВМ? Литература Иванова Г.С. Технология программирования. - М.: КноРус, 2011. - 333 с. Камаев В.А. Технологии программирования. - М.: Высшая школа, 2006. - 454 с. Орлов С.А. Технология разработки программного обеспечения. - СПб.: Питер, 2004. 526 с. Рудаков А.В. Технология разработки программных продуктов. - М.: Академия, 2010. 207 с. http://sp.cmc.msu.ru/info/37techprog.htm - технология программирования. http://www.twirpx.com/file/27591/- технология программирования, лекции. http://www.intuit.ru/department/se/introprogteach/1/3.html - жизненный цикл программы. http://www.pervviurok.ru/Info/Internet Development/gl11/gl11.html - отладка модулей. http://citforum.ru/database/articles/art 19.shtml - открытые системы. http://www.mini-soft.ru/book/tech prog/- технология программирования. http://www.labfor.ru/?act=metod&target=metod leso1 1 - среда программирования. Основная задача этого текста - рассказать, что такое Единая система программной документации (ЕСПД) и как эти стандарты применять на практике. Начну с рассказа о том, какие бывают стандарты, и закончу опытом применения каждого из ЕСПДшных стандартов в отдельности. В свое время, когда я только начинал работать программистом, часто приходилось слышать “напиши, пожалуйста, документацию к своей программе”. Я честно все описывал, отдавал начальнику, после чего начинался сеанс черной магии. Начальник через некоторое время меня вызывал и начинал мычать нечленораздельные звуки, мять распечатку моего “самого лучшего” текста в руках, бегая глазами. Общий смысл его мычания заключался в том, что получилось “не то”, “не так”, и “посмотри, как делают другие”. Так как никакого другого ответа из него вытянуть было невозможно, я шел за примерами документов к “другим”. Как правило, это были веселые ребята, смысл речей которых заключался в том, что “вот примеры”, “вообще то по ГОСТу” и “это все никому не нужно”. Так я узнал впервые, что программист может соприкоснуться со страшными ГОСТами. Поразительно, что среди многих десятков моих коллег, очень неглупых программистов, не было никого, кто бы относился к ГОСТам по другому. Даже те несколько человек, которые их знали и, вроде как, даже умели оформлять документы, относились к ним презрительно-формально. Ситуация, когда даже люди, ответственные за управление разработкой не понимают, зачем нужны ГОСТы и как их применят, встречается на многих предприятиях, сплошь и рядом. Да, были и компании, в которых понимали, чем “Описание программы” отличается от “Описания применения”, но таких было явное меньшинство. В интернете вообще господствует точка зрения, что ГОСТы для программистов - это явный рудимент, и нужны только если “нагибают” под них. Эскизный проект считают “сравнительно честным способом отъемы лишних дензнаков у заказчика”. Вникнуть и разобраться пришлось относительно недавно - в процессе разработки системы управления требованиями, заточенной под отечественную специфику. Документацию которая, разумеется, должна генерировать “по ГОСТу”. Здесь я хочу сосредоточиться только на одной теме, с которой приходиться иметь дело программисту в отечественных предприятиях, особенно в НИИ - на наборе стандартов ЕСПД. Не считаю себя большим знатоком ЕСПД - есть люди, которые десятки лет по нему работают, и наверняка меня поправят. Статья скорее пытается набросать контуры «дорожной карты» для тех, кто только входит в курс дела. Стандарты Рассмотрим кратко, какие бывают стандарты (фокусируясь на ИТ-области). международные. Отличительный признак - принят международной организацией. Пример такой организации - ISO (международная организация стандартизации). Пример её стандарта: ISO 2382-12:1988 (Переферийное оборудование). Распространены совместные стандарты ISO и международной электротехнической комиссии(IEC, в по русски - МЭК): например, ISO/IEC 12207:2008 (жизненный цикл ПО); региональные. Отличительный признак - принят региональной комиссией по стандартизации. К примеру, многие советские ГОСТы сейчас являются региональным стандартом, т.к. приняты межгосударственным советом, куда входят некоторые бывшие советские республики. Этим советом принимаются и новые стандарты - и они тоже получают обозначение ГОСТ. Пример: ГОСТ 12.4.240-2013; стандарты общественных объединений; К примеру, той же МЭК: IEC 60255; национальные стандарты. Для России в начале таких стандартов - “ГОСТ Р”. Могут быть трех типов: точные копии международных или региональных. Обозначаются неотличимо от “самописных” (национальных, написанных самостоятельно); копии международных или региональных с дополнениями. Обозначаются добавлением к шифру отечественного стандарта шифра международного, который был взят за основу. Например: ГОСТ Р ИСО/МЭК 12207; собственно, национальные стандарты. Например, ГОСТ Р 34.11-94. Системы обозначений на каждом уровне и в каждой организации свои, для каждого случая придется разбираться отдельно. Чтобы быстро понять, “чей” стандарт перед глазами, можно использовать шпаргалку . ГОСТ Итак: стандарты бывают международные, межгосударственные(региональные) и национальные. ГОСТ, как мы выяснили, это региональный стандарт. ГОСТы имеют достаточно запутанную, на мой взгляд, систему обозначений. Полностью она изложена в ГОСТ Р 1.5-2004, я приведу минимум, что бы в ней ориентироваться. Во первых, надо различать обозначение ГОСТа и его классификацию. Обозначение - это, грубо говоря, уникальный идентификатор стандарта. Код по классификатору - это вспомогательный код, помогающий найти стандарт или определить, к какой области знаний он относиться. Классификаторов может быть много, в основном используются два: КГС (классификатор государственных стандартов) и его наследник ОКС (общероссийский классификатор стандартов). Например: “ГОСТ Р 50628-2000“ - это обозначение стандарта.По обозначению понятно только то, что он принят в 2000 году. Он имеет код по ОКС “33.100;35.160”: т.е. “33” - раздел “Телекоммуникации, аудио, видео”, “100” - подраздел “электромагнитная совместимость”. Однако он также входит в ветвь классификатора 35.160. “35” - “Информационные технологии. Машины конторские”, “160” - “Микропроцессорные системы....”. А по КГС он имеет код “Э02”, что означает “Э” - “Электронная техника, радиоэлектроника и связь”, “0” - “Общие правила и нормы по электронной технике, радиоэлектронике и связи”, и т.д. Если известно обозначение стандарта, то получить его коды по КГС и ОКС можно, к примеру, на вот этом толковом сайте . Итак, вернемся к обозначениям ГОСТов. Их может быть два варианта: стандарт относиться к серии стандартов. В этом случае после индекса категории стандарта (например, ГОСТ, ГОСТ Р или ГОСТ РВ) идет код серии, точка и обозначение стандарта внутри серии. Правила обозначения стандартов внутри серии устанавливаются правилами серии. Например: ГОСТ РВ 15.201-2000, ГОСТ Р 22.8.0-99, ГОСТ 19.101-77; стандарт не относиться к серии стандартов. Тогда после индекса категории идет просто порядковый номер стандарта, тире и год принятия. Например, ГОСТ Р 50628-2000. Итак, если совсем просто - то обозначение ГОСТа - это либо просто порядковый номер, тире, год, либо номер серии, точка и дальше в зависимости от серии. В реальности все сложнее (к примеру, можно встретить что то типа ГОСТ 11326.19-79, и это будет вовсе не серия 11326 - но программистам такое нужно очень редко. За подробностями - в ГОСТ Р 1.5-2004). ЕСПД ЕСПД - одна из таких серий ГОСТов, номер 19. Т.е. все стандарты, относящиеся к ЕСПД, начинаются с префикса “19.”: например, ГОСТ 19.106-78. Расшифровывается как “Единая система программной документации”. Существуют и другие серии: ГОСТ ЕСКД (единая система конструкторской документации, префикс “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. В настоящее время к этому стандарту приходиться обращаться очень редко: разве что забывается порядок следования основных частей документа. 19.106-78. Общие требования к программным документам, выполненным печатным способом Самый объемный стандарт из ЕСПД, уступающий разве что описанию R-схем. Является основным рабочим стандартом при оформлении документации. Вводит правила оформления текста, элементов структуры документа, изображений, формул и т.д. Однако в отличии от соответствующего 2.106 из ЕСКД, 19.106 существенно менее подробный, что приводит к многочисленным неопределенностям. Во первых, стандарт фактически не определяет межстрочное расстояние и величину вертикальных отступов между заголовками. Он вводит три правила определения интервала: для машинописного текста, машинного и типографского. Машинописный текст - это текст, набранный на печатной машинке. Смещение следующей строки относительно предыдущей производилось автоматически при так называемом «переводе каретки» - переходе к печати следующей строки, производимым перемещением специального рычага. Как правило, интервал мог быть вручную скорректирован поворотом вала протяжки бумаги, и имел “настройку”, позволяющую задать величину интервала - одинарный или двойной. Машинный - это, скорее всего, и есть распечатанный текст. Но для него есть только указание, что результат должен быть пригоден для микрофильмирования. Это неявная ссылка на 13.1.002-2003, в котором, к сожалению, задается межстрочный интервал (и, кстати, минимальная высота шрифта) только для рукописных документов (п.4.2.5). Типографский - текст, набранный в типографии. Учитывая год принятия стандарта, скорее всего речь идет о [высокой печати , где межстрочный интервал определялся используемыми литерами. Я не специалист в типографском деле, а информации о методах набора сейчас очень мало. Какой интервал использовать в итоге часто определяется местным нормоконтролем или СТО. Типичные значения - полуторный интервал и 14 размер шрифта. Часто вызывает много вопросов способ структурирования документа. 19.106 считает, что весь документ делится на разделы, подразделы, пункты и подпункты. У всех них (кроме раздела и подраздела) заголовок может быть и или не быть. При этом: “в содержание документа включают номер разделов, подразделов, пунктов и подпунктов, имеющих заголовок” (п. 2.1.4). Это прямое указание на то, что подпункт может иметь заголовок и включаться в оглавление; “допускается помещать текст между заголовками раздела и подраздела, между заголовками подраздела и пункта”. Важно обратить внимание, что ненумерованный текст может быть только между заголовками, и только на верхних 2х уровнях. В отличии от ЕСКД, в ЕСПД принят странный способ оформления рисунков: сначала идет название рисунка, потом сам рисунок, потом опциональный “подрисуночный текст”, и потом, на новой строке, “Рис. N”. Этот стандарт имеет ряд “дыр”, недостказанностей. К примеру, сказано: “иллюстрации, если их в данном документе более одной, нумеруют арабскими цифрами в пределах всего документа. “ Но если иллюстрация одна, то она ненумерованная, и как тогда на нее ссылаться? Аналогично и для таблиц. Для сносок ГОСТ не указывает способ их нумерации - в пределах всего документа или в пределах страницы. Таблицы. В самом документе дана ссылка на ГОСТ 1.5.68. Судя по первой серии, несложно заключить, что это стандарт на разработку стандартов. Причем тут он, неясно. По смыслу он соответствует правилам оформления таблиц в ЕСКД, с небольшими исключениями. Этот стандарт был отменен, взамен веден, через несколько итераций, 1.5-2012, в котором правила оформления таблицы… просто исчезли. Еще в 1.5-2002 были, а уже в 1.5-2004 исчезли. В реальной жизни мы оформляем таблицы согласно ЕСКД. Приложения. Стандарт не указывает, попадают ли рисунки, формулы и таблицы из приложений в общий перечень. Аналогично не сказано, нужно ли в оглавлении раскрывать структуру приложения, если оно содержит свои разделы, пункты и т.д. В нашей практике мы не раскрываем внутренности приложений. Наконец, следует сказать об отступах. Абзацный отступ, равный 5 символам, является общим для: красной строки; отступа элемента структуры документа после раздела (подраздел, пункт, подпункт); элемент перечисления. При этом текст, расположенный на следующей строку после строки с отступом, выравнивается уже по левому полю. Часто встречаются ошибки, когда отступ скачет - красная строка - одно значение, номер пункта - нас другим интервалом, в вложенные отступы в списках - так вообще обязательно. В следующих частях планирую уже добраться до конца списка стандартов ЕСПД. ГОСТ 19.101-77 Группа Т55 МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ Единая система программной документации ВИДЫ ПРОГРАММ И ПРОГРАММНЫХ ДОКУМЕНТОВ Unified system for program documentation. Types of programs and program documents МКС 35.080 Дата введения 1980-01-01 Постановлением Государственного комитета стандартов Совета Министров СССР от 20 мая 1977 г. N 1268 дата введения установлена 01.01.80 ИЗДАНИЕ (январь 2010 г.) с Изменением N 1, утвержденным в июне 1981 г. (ИУС 9-81). Настоящий стандарт устанавливает виды программ и программных документов для вычислительных машин, комплексов и систем независимо от их назначения и области применения. Стандарт полностью соответствует СТ СЭВ 1626-79. (Измененная редакция, Изм. N 1). 1. ВИДЫ ПРОГРАММ 1. ВИДЫ ПРОГРАММ 1.1. Программу (по ГОСТ 19781-90) допускается идентифицировать и применять самостоятельно и (или) в составе других программ. 1.2. Программы подразделяют на виды, приведенные в табл.1. Таблица 1 Вид программы Определение Компонент Программа, рассматриваемая как единое целое, выполняющая законченную функцию и применяемая самостоятельно или в составе комплекса Комплекс Программа, состоящая из двух или более компонентов и (или) комплексов, выполняющих взаимосвязанные функции, и применяемая самостоятельно или в составе другого комплекса 1.3. Документация, разработанная на программу, может использоваться для реализации и передачи программы на носителях данных, а также для изготовления программного изделия. 1.2, 1.3. (Измененная редакция, Изм. N 1). 2. ВИДЫ ПРОГРАММНЫХ ДОКУМЕНТОВ 2.1. К программным относят документы, содержащие сведения, необходимые для разработки, изготовления, сопровождения и эксплуатации программ. 2.2. Виды программных документов и их содержание приведены в табл.2. Таблица 2 Вид программного документа Спецификация Состав программы и документации на нее Перечень предприятий, на которых хранят подлинники программных документов Текст программы Запись программы с необходимыми комментариями Описание программы Сведения о логической структуре и функционировании программы Требования, подлежащие проверке при испытании программы, а также порядок и методы их контроля Техническое задание Назначение и область применения программы, технические, технико-экономические и специальные требования, предъявляемые к программе, необходимые стадии и сроки разработки, виды испытаний Пояснительная записка Схема алгоритма, общее описание алгоритма и (или) функционирования программы, а также обоснование принятых технических и технико-экономических решений Эксплуатационные документы Сведения для обеспечения функционирования и эксплуатации программы 2.3. Виды эксплуатационных документов и их содержание приведены в табл.3. Таблица 3 Вид эксплуатационного документа Перечень эксплуатационных документов на программу Формуляр Основные характеристики программы, комплектность и сведения об эксплуатации программы Описание применения Сведения о назначении программы, области применения, применяемых методах, классе решаемых задач, ограничениях для применения, минимальной конфигурации технических средств Сведения для проверки, обеспечения функционирования и настройки программы на условия конкретного применения Руководство программиста Сведения для эксплуатации программы Руководство оператора Сведения для обеспечения процедуры общения оператора с вычислительной системой в процессе выполнения программы Описание языка Описание синтаксиса и семантики языка Сведения для применения тестовых и диагностических программ при обслуживании технических средств 2.4. В зависимости от способа выполнения и характера применения программные документы подразделяются на подлинник, дубликат и копию (ГОСТ 2.102-68), предназначенные для разработки, сопровождения и эксплуатации программы. 2.5. Виды программных документов, разрабатываемых на разных стадиях, и их коды приведены в табл.4. Таблица 4 Код вида документа Вид документа Стадии разработки Эскизный проект Технический проект Рабочий проект компонент комплекс Спецификация Ведомость держателей подлинников Текст программы Описание программы Ведомость эксплуатационных документов Формуляр Описание применения Руководство системного программиста Руководство программиста Руководство оператора Описание языка Руководство по техническому обслуживанию Программа и методика испытаний Пояснительная записка Прочие документы Условные обозначения: - документ обязательный; - документ обязательный для компонентов, имеющих самостоятельное применение; - необходимость составления документа определяется на этапе разработки и утверждения технического задания; - - документ не составляют. 2.2-2.5. (Измененная редакция, Изм. N 1). 2.6. Допускается объединять отдельные виды эксплуатационных документов (за исключением ведомости эксплуатационных документов и формуляра). Необходимость объединения этих документов указывается в техническом задании. Объединенному документу присваивают наименование и обозначение одного из объединяемых документов. В объединенных документах должны быть приведены сведения, которые необходимо включать в каждый объединяемый документ. 2.7. На этапе разработки и утверждения технического задания определяют необходимость составления технических условий, содержащих требования к изготовлению, контролю и приемке программы. Технические условия разрабатывают на стадии "Рабочий проект". 2.8. Необходимость составления технического задания на компоненты, не предназначенные для самостоятельного применения, и комплексы, входящие в другие комплексы, определяется по согласованию с заказчиком. (Введен дополнительно, Изм. N 1). Электронный текст документа подготовлен АО "Кодекс" и сверен по: официальное издание Единая система программной документации: Сб. ГОСТов. - М.: Стандартинформ, 2010   Разделы ОС Программы Компьютер Мобильные Ноутбуки Реклама