Гост по программному обеспечению виды документов. Оформление программы по госту (how to). Единая система программной документации

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

Техническое задание на разработку программного продукта

3.2. Описание программы

3.3. Текст программы

Программа и методика испытаний

3.5. Требования к программным документам, выполненным печатным способом

Приложение . Форма технического задания на разработку программного продукта (изделия, модели)

Введение. Общие сведения о Единой системе программной документации (ЕСПД).

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

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

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

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

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

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

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

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

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

ГОСТ 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.404-79 ЕСПД. Пояснительная записка. Требования к содержанию и оформлению.

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

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

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

ГОСТ 19.504-79 ЕСПД. Руководство программиста.

ГОСТ 19.505-79 ЕСПД. Руководство оператора.

ГОСТ 19.506-79 ЕСПД. Описание языка.

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

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

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

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

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

ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.

ГОСТ 34.601-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированной системы. Стадии создания.

ГОСТ Р ИСО/МЭК ТО 12182-2002 Информационная технология. Классификация программных средств.

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

ГОСТ Р ИСО/МЭК 14764-2002 Информационная технология. Сопровождение программных средств.

ГОСТ Р ИСО/МЭК 15026-2002 Информационная технология. Уровни целостности систем и программных средств.

ГОСТ Р ИСО/МЭК ТО 15271-2002 Информационная технология. Руководство по применению ГОСТ Р ИСО/МЭК 12207-99.

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

Международные стандарты ISO/IEC:

ISO/IEC 12207:2008 System and software engineering – Software life cycle processes.

ISO/IEC 15288:2008 System and software engineering – System life cycle processes.

IEEE 830-1998 Recommended practice for software requirements specifications.

IEEE 1233-1998 Guide for developing system requirements specifications.

IEEE 1016-1998 Recommended Practice for Software Design Descriptions.

ISO/IEC 42010 IEEE Std 1471-2000 System and software engineering – Recommended practice for architectural description of software-intensive systems.

ISO 9001:2000 Quality management systems – Requirements.

ISO/IEC 90003:2004 Software engineering – Guidelines for the application of ISO 9001:2000 to computer software.

ISO/IEC TR 90005:2008 Software engineering – Guidelines for the application of ISO 9001:2000 to system life cycle processes.

ISO/IEC 9126-1:2001 Software engineering – Product quality – Part 1: Quality model.

ISO/IEC 9126-2:2003 Software engineering – Product quality – Part 2: External metrics.

ISO/IEC 9126-3:2003 Software engineering – Product quality – Part 3: Internal metrics.

ISO/IEC 9126-4:2004 Software engineering – Product quality – Part 4: Quality in use metrics.

ISO/IEC 25051:2006 Software engineering – Software product Quality Requirements and Evaluation (SQuaRE) – Requirements for quality of Commercial Off-The-Shelf (COTS) software product and instructions for testing.

IEEE 829-1998 Standard for Software Test Documentation.

IEEE 829-2008 Standard for Software and System Test Documentation.

IEEE 1008-1987 (R1993, R2002) Standard for Software Unit Testing.

ISO/IEC 14598-1:1999 Information technology – Software product evaluation – Part 1: General overview.

ISO/IEC 14598-2:2000 Software engineering – Product evaluation – Part 2: Planning and management.

ISO/IEC 14598-3:2000 Software engineering – Product evaluation – Part 3: Process for developers.

ISO/IEC 14598-4:1999 Software engineering – Product evaluation – Part 4: Process for acquirers.

ISO/IEC 14598-5:1998 Information technology – Software product evaluation – Part 5: Process for evaluators.

ISO/IEC 14598-6:2001 Software engineering – Product evaluation – Part 6: Documentation of evaluation modules.

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

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

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

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

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

Г О С У Д А Р С Т В Е Н Н Ы Й С Т А Н Д А Р Т С О Ю З А С С Р

Единая система программной документации	ГОСТ 19.401-78 (СТ СЭВ 3746-82)

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

United system for program documentation. Text of program. Requirements for contents and form of presentation

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

с 01.01. 1980 г.

1. Настоящий стандарт устанавливает требования к содержанию и оформлению программного документа «Текст программы», определённого ГОСТ 19.101-77 .

Стандарт полностью соответствует СТ СЭВ 3746-82.

2. Структуру и оформление документа устанавливают в соответствии с ГОСТ 19.105-78 .

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

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

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

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

4. Каждый из этих разделов реализуется одним из типов символической записи, например:

символическая запись на исходном языке;
символическая запись на промежуточных языках;
символическое представление машинных кодов и т.п.

Переиздание (Ноябрь 1987 г.) с Изменениями № 1, утвержденным в марте 1983 г. (ИУС 7-83)

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

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

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

К эксплуатационным документам относят:

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

Основная часть программной документации составляется на стадии рабочего проекта. Необходимость того или иного документа определяется на этапе составления технического задания. Допускается объединять отдельные виды документов. Эксплуатационный документ «Описание языка» включается в программную документацию, если разработанный программный продукт реализует некий язык программирования, управления заданиями, организации вычислительного процесса и т. П. Эксплуатационный документ «Руководство по техническому обслуживанию» включается в программную документацию, если разработанный программный продукт требует использования тестовых или диагностических программ.

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

1. Количество операторов на строчке должно быть равно 1.
2. Все операторы, входящие в составной оператор, должны быть сдвинуты вправо на одинаковое количество позиций, при этом операторные скобки (т. Е. то, что ограничивает составной оператор), относящиеся к одному блоку, должны располагаться следующим образом: открывающая скобка должна находиться на той же строчке, что и оператор, открывающий блок, а закрывающая должна находиться в той же колонке, с которой начинается оператор, открывающий блок. Допускается располагать открывающую скобку на строке, следующей за оператором, открывающим блок, в той же колонке, с которой начинается этот оператор.
3. Строка исходного текста программы должна целиком располагаться в одной типографской строке (до 80 символов в зависимости от шрифта). Несоблюдение этого правила говорит о слишком большой вложенности блоков, что означает неудачный алгоритм или структуру программы. В таком случае рекомендуется переосмыслить структуру программы, ввести дополнительные функции, заменив какие-то большие части кода их вызовами, переделать алгоритм и т.п.
4. Если синтаксис языка позволяет, желательно отделять знаки операций пробелами от операндов. Как и в обычном тексте, после запятых должен следовать пробел.
5. Определения функций или логические части программы следует отделять друг от друга пустыми строками.
6. Идентификаторы (названия переменных, типов, подпрограмм) должны быть значимыми настолько, чтобы читающий текст программы мог понимать их смысл без присутствия рядом автора. При необходимости объявление переменной или типа может сопровождаться комментарием.
7. Текст программы должен содержать комментарии, отражающие функциональное назначение того или иного блока программы, структуру программы.

Документ Описание программы содержит:

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

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

Документ Описание применения относится к эксплуатационным документам и состоит из следующих разделов:

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

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

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

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

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

Документ Руководство оператора относится к эксплуатационным документам и состоит из следующих разделов:

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

При оформлении текстовых и графических материалов, входящих в программную документацию следует придерживаться действующих стандартов. Некоторые положения этих стандартов приведены ниже. Оформление текстового и графического материала. Текстовые документы оформляют на листах формата А4, причем графический материал допускается представлять на листах формата A3. Поля на листе определяют в соответствии с общими требованиями: левое - не менее 30, правое - не менее 10, верхнее - не менее 15, а нижнее - не менее 20 мм . В текстовых редакторах для оформления записки параметры страницы заказывают в зависимости от устройства печати. При ручном оформлении документов параметры страницы выбирают из соображений удобства. Нумерация всех страниц - сквозная. Номер проставляется сверху справа арабской цифрой. Страницами считают, как листы с текстами и рисунками, так и листы приложений. Первой страницей считается титульный лист. Номер страницы на титульном листе не проставляют. Наименование разделов пишут прописными буквами в середине строки. Расстояние между заголовками и текстом, а также между заголовками раздела и подразделов должно быть равно:

* При выполнении документа машинописным способом - двум интервалам.
* При выполнении рукописным способом - 10 мм.

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

* При выполнении документа машинописным способом - трем интервалам.
* При выполнении рукописным способом - не менее 15 мм.
* При использовании текстовых редакторов - определяется возможностями редактора.

Разделы и подразделы нумеруются арабскими цифрами с точкой. Разделы должны иметь порядковые номера 1, 2, и т. Д. Номер подраздела включает номер раздела и порядковый номер подраздела, входящего в данный раздел, разделенные точкой. Например: 2.1, 3.5. Ссылки на пункты, разделы и подразделы указывают, используя порядковый номер раздела или пункта, например, «в разд. 4», «в п. 3.3.4». Текст разделов печатают через 1,5-2 интервала. При использовании текстовых редакторов высота букв и цифр должна быть не менее 1,8 мм (шрифты № 11-12). Перечисления следует нумеровать арабскими цифрами со скобкой, например: 2), 3) и т. Д. - с абзацного отступа. Допускается выделять перечисление простановкой дефиса перед пунктом текста или символом, его заменяющим, в текстовых редакторах. Оформление рисунков, схем алгоритмов, таблиц и формул. В соответствии с ГОСТ 2.105-79 «Общие требования к текстовым документам» иллюстрации (графики, схемы, диаграммы) могут быть приведены как в основном тексте, так и в приложении. Все иллюстрации именуют рисунками. Все рисунки, таблицы и формулы нумеруют арабскими цифрами последовательно (сквозная нумерация) или в пределах раздела (относительная нумерация). В приложении - в пределах приложения. Каждый рисунок должен иметь подрисуночную подпись - название, помещаемую под рисунком, например: Рис.12. Форма окна основного меню.

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

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

Схемы алгоритмов должны быть выполнены в соответствии со стандартом ЕСПД. Толщина сплошной линии при вычерчивании схем алгоритмов должна составлять от 0,6… 1,5 мм. Надписи на схемах должны быть выполнены чертежным шрифтом, высота букв и цифр должна быть не менее 3,5 мм.

Номер таблицы размещают в правом верхнем углу или перед заголовком таблицы, если он есть. Заголовок, кроме первой буквы, выполняют строчными буквами. Ссылки на таблицы в тексте пояснительной записки указывают в виде слова «табл.» и номера таблицы. Например: Результаты тестов приведены в табл. 4.

Номер формулы ставится с правой стороны страницы в круглых скобках на уровне формулы. Например: z:=sin(x)+ln(y); (12)

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

Рисунки и таблицы, помещаемые в приложении, нумеруют арабскими цифрами в пределах каждого приложения с добавлением буквы «П», Напри-мер: Рис. П. 12 - 12-й рисунок приложения; Рис. П1.2 - 2-й рисунок 1-го приложения.

Если в приложении приводится текст программы, то каждый файл оформляют как рисунок с наименованием файла и его назначением, например: Рис. П2.4. Файл menuran.pas - программа движения курсора основного меню.

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

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

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

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

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

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

Стандарты

Рассмотрим кратко, какие бывают стандарты (фокусируясь на ИТ-области).

международные. Отличительный признак - принят международной организацией. Пример такой организации - 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” - “Общие правила и нормы по электронной технике, радиоэлектронике и связи”, и т.д.

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

стандарт относиться к серии стандартов. В этом случае после индекса категории стандарта (например, ГОСТ, ГОСТ Р или ГОСТ РВ) идет код серии, точка и обозначение стандарта внутри серии. Правила обозначения стандартов внутри серии устанавливаются правилами серии. Например: ГОСТ РВ 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 символам, является общим для:

красной строки;
отступа элемента структуры документа после раздела (подраздел, пункт, подпункт);
элемент перечисления.

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

	Правила оформления и требования к содержанию курсовых		Редакция 2
	проектов (работ) и выпускных квалификационных работ		стр. 39 из 73


Сборочный чертёж сборочной единицы
под номером 8, входящей в изделие 1		ПК.760108.000 СБ
Сборочный чертёж отдельной сборочной
единицы 4		ПК.760004.000 СБ
Чертёж общего вида отдельной сборочной
единицы 4		ПК.760004.000 ВО
Чертёж детали под номером 16, входящей в
сборочную единицу 8 изделия 1
Чертёж детали под номером 120, входящей в
отдельную сборочную единицу 4
Схема электрическая принципиальная изделия 1		ПК.760100.000 Э3
Схема кинематическая принципиальная отдель-
ной сборочной единицы 4		ПК.760400.000 К3
Спецификация сборочной единицы 8 изделия 1

10 Оформление технологических документов

10.1 Технологические документы курсовых проектов (работ) и выпускных квалификационных работ оформляются в соответствии с требованиями стандартов ЕСТД.

10.2 Технологические документы должны включать:

– титульный лист, оформленный в соответствии с ГОСТ 3.1105-84 «ЕСТД. Форма и правила оформления документов общего назначения» (форма 2а).

– маршрутную карту, оформленную по ГОСТ 3.1118-82 «ЕСТД. Формы и правила оформления маршрутных карт»;

– операционные карты механической обработки и операционные

расчётно-технологические карты на технологические операции, на станках с ЧПУ − по ГОСТ 3.1404-86 «ЕСТД. Формы и правила оформления документов на технологические процессы и операции обработки резанием»;

– операционные карты слесарных, слесарно-сборочных работ по ГОСТ 3.1407-86 «ЕСТД. Формы и требования к заполнению и оформлению документов на технологические процессы (операции), специализированные по методам сборки»;

– карты эскизов (в случае необходимости) по ГОСТ 3.1105-84 и ГОСТ 3.1128-93 «ЕСТД. Общие правила выполнения графических технологических документов»;

– операционные карты технологического контроля по ГОСТ 3.1502-85 «ЕСТД. Формы и правила оформления документов на технический контроль»;

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

10.3 Ремонтные чертежи выполняются в соответствии с правилами, предусмотренными ГОСТ 2.604-88 «Чертежи ремонтные».

10.4 Технологические документы должны быть сброшюрованы

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

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

11.1 Разработанные в курсовых проектах (работах) и выпускных квалификационных работах документы различных проблемных областей должны быть оформлены следующим образом:

– программные документы – в соответствии с требованиями ЕСПД,

– документы для автоматизированной системы управления – по государственным стандартам системы технологической документации на АСУ. 11.2 Программные документы (листинги программ) должны включать:

– текст программы, оформленный согласно ГОСТ 19.401;

– описание программы, выполненное согласно ГОСТ 19.402;

– описание примечания, приведённое согласно ГОСТ 19.502;

– другие программные документы (при необходимости).

11.3 Листинги программ размещаются в приложениях с обязательными ссылками на них в ПЗ.

11.4 Программный код может быть сопровождён комментариями. При оформлении листингов рекомендуется использовать шрифт Courier New, размер – 12 пт, межстрочный интервал – одинарный. Рекомендуется отделять смысловые блоки пустыми строками, а также визуально обозначать вложенные конструкции с помощью отступов.

11.5 Ключевые слова и комментарии в листинге программ могут быть выделены с помощью курсива. В основном тексте ПЗ курсивом следует выделять имена библиотек, подпрограммы, константы, переменные и т.д.

11.6 Листинги программ должны иметь порядковую нумерацию в пределах приложения. Номер листинга должен состоять из обозначения приложения и порядкового номера листинга, разделенных точкой, например: «Листинг А.3» – третий листинг приложения А. Если в проекте (работе) содержится только один листинг, он обозначается «Листинг 1». При ссылке на листинг в тексте ПЗ следует писать слово «Листинг» с указанием его номера.

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

Пример оформления листинга программы Листинг А.3 – Программа « Вывод двумерного массива»

mas:array of integer; {объявление двухмерного массива } i,j:integer;

Правила оформления и требования к содержанию курсовых проектов (работ) и выпускных квалификационных работ – 09.1

{ Ввод значений элементов массива} for i:=1 to 5 do

for j:=1 to 5 do readln(mas);

{Вывод значений элементов массива} for i:=1 to 5 do begin

for j:=1 to 5 do write(" ",mas); writeln;

12 Нормоконтроль

12.1 Нормоконтроль является завершающим этапом разработки документов курсового проекта (работы) и ВКР.

12.2 Нормоконтроль должен соответствовать требованиям ГОСТ 2.111.

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

12.4 Нормоконтроль выполняется нормоконтролёром с учётом требований, действующих на данный момент, стандартов и нормативно-технических документов.

12.5 В процессе нормоконтроля пояснительных записок курсовых проектов (работ) и ВКР проверяется:

– соблюдение правил оформления согласно настоящему Положению;

– внешний вид ПЗ;

– комплектность ПЗ в соответствии с заданием на проектирование;

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

– правильность заполнения ведомости проекта (работы);

– наличие и правильность рамок, основных надписей на всех страницах;

– выделение заголовков, разделов и подразделов, наличие красных строк;

– правильность оформления содержания, соответствие названий разделов и подразделов в содержании соответствующим названиям в тексте записки;

– правильность нумерации страниц, разделов, подразделов, рисунков, таблиц, формул;

– правильность оформления рисунков;

– правильность оформления таблиц;

– правильность размерностей физических величин, их соответствие СИ;

– соответствие нормам современного русского языка;

– правильность примененных сокращений слов;

– наличие и правильность ссылок на используемые источники;

– наличие и правильность ссылок на нормативные документы;

– правильность оформления списка использованных источников;

– правильность оформления приложений.

12.6 В процессе нормоконтроля графических документов курсовых проектов (работ) и ВКР проверяется:

– соответствие оформления чертежей требованиям действующих стандартов;

– выполнение чертежей в соответствии с требованиями нормативных документов;

– соблюдение форматов, правильность их оформления;

– правильность начертания и применения линий;

– соблюдение масштабов, правильность их обозначения;

– достаточность изображений (видов, разрезов, сечений), правильность их обозначения и расположения;

– соблюдение условных обозначений элементов в схемах и правил их выполнения в соответствии с требованиями ЕСКД.

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

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

12.9 Проверенные нормоконтролёром в присутствии студента-разработчика документы вместе с перечнем замечаний (если он составляется) возвращаются студенту для внесения исправлений и переработки. Если замечания существуют, пометки нормоконтролёра сохраняются до подписания им документа. Если документ заново перерабатывается студентом, то на повторный контроль сдаются оба экземпляра: с пометками нормоконтролера и переработанный.

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

в графе «Н.контр.» основной надписи.

12.11 Запрещается без ведома нормоконтролёра вносить какие-либо изменения в документ после того, как этот документ подписан и завизирован нормоконтролёром.

12.12 Нормоконтролёр имеет право в обоснованных случаях не подписывать предоставленный документ:

– при невыполнении требований нормативных документов;

– при отсутствии обязательных подписей;

– при небрежном выполнении;

– при нарушении установленной комплектности.

12.13 Нормоконтролёр несёт ответственность за соблюдение в разрабатываемой документации требований действующих стандартов и других нормативно-технических документов наравне с разработчиками документации.

13 Рецензирование ВКР

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

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

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

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

13.4 Рецензия оформляется в письменном виде и содержит аргументированные оценки:

– актуальности темы ВКР;

– соответствии содержания ВКР заданию на его разработку;

– правильности логической структуры ВКР;

– эффективности и обоснованности проектных решений;

– достоинства и недостатков ВКР, соответствие ее квалификационным требованиям выпускника по направлению подготовки;

– оформления ВКР.

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

13.5 Объем рецензии на выпускную квалификационную работу должен составлять 2-3 страницы печатного или четко написанного от руки текста. Подписанная рецензия должна быть представлена на кафедру, не позднее, чем за три дня до защиты ВКР.

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

13.7 На защиту ВКР в комиссию по государственной аттестации можно дополнительно представить отзыв ведущей организации, по заказу которой

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

14 Отзыв на ВКР

14.1 Отзыв на выпускную квалификационную работу составляется непосредственно ее руководителем. Отзыв должен характеризовать ВКР с разных сторон: со стороны содержания, структуры, полноты раскрытия выбранной темы и т.д.

14.2 Руководитель должен изложить в отзыве свое объективное мнение о выпускной квалификационной работе студента. В частности, отзыв должен содержать сведения:

– об актуальности темы работы;

– о соответствии выпускной квалификационной работы требованиям, предъявляемым стандартами;

– о владении студентом методами сбора, обработки и анализа информации применяемой в сфере профессиональной деятельности;

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

– о положительных сторонах работы;

– о недостатках и замечаниях по содержанию работы и др.

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

14.4 В заключении отзыва, руководитель делает вывод о возможности представления к защите выпускной квалификационной работы к защите в ГАК.

14.5 Текст отзыва руководителя на ВКР печатается на листах формата А4 и подписывается научным руководителем. Форма отзыва на ВКР представлена в приложении Ф.

15 Доклад и презентация

15.1 Доклад (выступление) – это работа презентативного характера, отражающая суть ВКР.

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

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

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

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

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

Материал должен иллюстрировать все тезисы, выведенные в докладе.

15.5 Показ презентации может быть осуществлен двумя способами:

– с помощью проектора и на стенде;

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

Объём презентации может быть от 8 до 12 слайдов.

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

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

в 1-2 предложениях рассмотреть рекомендации для решения поставленных проблем.

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

15.8 Курсовой проект (работа) и ВКР сдаются в архив вместе с презентацией, выполненной в электронном виде и записанной на цифровом носитель (например, CD/DVD-диск).

Приложение А

Приложение Б

(наименование факультета)

(наименование кафедры)

____________ ________________

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

к курсовому проекту (работе) по дисциплине (модулю)__

(наименование учебной дисциплины (модуля))

на тему _________________________________________________________________________

_____

	_______________________	______________________________

Направление/специальность, профиль/специализация:

___________ _________________________________________________________________

код направления наименование направления (специальности)

________________________________________________________________________________

наименование профиля (специализации)

Обозначение курсового проекта (работы) _________________________ Группа ________

Ростов-на-Дону

Приложение В

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«ДОНСКОЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ» (ДГТУ)

Факультет _______________________________________________________

(наименование факультета)

Кафедра _________________________________________________________

(наименование кафедры)

Зав. кафедрой «______________»

____________ ________________

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

к дипломному проекту (работе) на тему:

___________________________________________________________________________

			__________________________
	(подпись, дата)
Обозначение дипломного проекта ______________________				Группа ______________
Направление (специальность) ___________		___________________________________
				(наименование)
Руководитель проекта (работы)			____________________________
	(подпись, дата)			(должность, И.О.Ф.)
Консультанты по разделам:
_______________________________				_____________________
(наименование раздела)		(подпись, дата)		(должность, И.О.Ф.)
_______________________________				_____________________
(наименование раздела)		(подпись, дата)		(должность, И.О.Ф.)
Нормоконтроль				_____________________
		(подпись, дата)		(должность, И.О.Ф.)

Ростов-на-Дону

Печать

Также интересно:

Dark Sector: Прохождение Глава VIII: Неестественная история

Что делать если на компе нету диска D?

Как откатить или удалить проблемное обновление Windows Откат к предыдущей сборке windows 10

Рекомендуем почитать:

2023-08-11 00:02:15

Оператор для работы с наборами UNION Объединение запросов union

2023-08-11 00:02:15

IBM создала самый мощный в мире компьютер Топ 10 самых мощных компьютеров в мире

2023-08-10 00:03:18

Мы знаем далеко не все: какие социальные сети существуют в интернете Путешествия и отдых

В продолжение темы:

Windows

Компьютеры с процессором intel i5 Конфигурация тестовых стендов

Часть вторая : "Важнейшие характеристики каждого семейства процессоров Intel Core i3/i5/i7. Какие из этих чипов представляют особый интерес" Введение Сначала мы приведём...