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

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

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

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

Например : Загрузка программы осуществляется набором в командной строке DOS имени загрузочного модуля – SBM80N.EXE с возможным указанием имени файла данных.

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

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

По-прежнему обязательным является составление информационной части - аннотации и содержания.

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

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

· наименование программы,

· дата создания программы,

· номер версии,

· дата последней модификации.

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

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

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

испытаний. Грамотно составленная программа и методика испытаний – это залог подписания акта сдачи-приемки, т.е. того, во имя чего вы потратили столько сил и времени.

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

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

Объект испытаний

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

Цель испытаний

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

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

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

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

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

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

· программа и методика испытаний (ГОСТ 19.301-79);

· текст программы (ГОСТ 19.401-78).

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

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

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

1. Запуск программы осуществляется ….

2. Выбирается …

3. Нажимается …

4. Последовательно выбираются …

Тестовые примеры

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

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

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

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

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

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

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

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

· допустимо оформление на листах формата А3;

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

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

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

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

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

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

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

Аннотация;

- лист содержания;

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

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

- перечень терминов и их определений;

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

Приложения;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· сокращений, применяемых для обозначения программ, их частей

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

алфавита.

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

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

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

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

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

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

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

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

с модификацией программ.

В связи с этим следует различать две категории пользователей: ординарных пользователей программы и администраторов. Ординарный пользователь программы (end-user) использует программу для решения своих задач (в своей предметной области). Это может быть инженер, проектирующий техническое устройство, или кассир, продающий железнодорожные билеты с помощью данной программы. Он может и не знать многих деталей работы компьютера или принципов программирования. Администратор программы (system administrator) управляет использованием программы ординарными пользователями и осуществляет сопровождение программного средства, не связанное с модификацией программ. Например, он может регулировать права доступа к программе между ординарными пользователями, поддерживать связь с поставщиками программы или выполнять определенные действия, чтобы поддерживать программу в рабочем состоянии, если оно включено как часть в другую систему.

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

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

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

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

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

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

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

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

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

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

Документация по сопровождению программного средства (system documentation) описывает программное средство с точки зрения ее разработки.

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

Документация по сопровождению программного средства можно разбить на две группы:

1. документация, определяющая строение программ и структур данных ПС и технологию их разработки;

2. документацию, помогающую вносить изменения в программное средство.

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

Внешнее описание программного средства (Requirements document). Описание архитектуры программного средства (description of the system

architecture), включая внешнюю спецификацию каждой ее программы.

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

Для каждого модуля - его спецификация и описание его строения

(design description).

Тексты модулей на выбранном языке программирования (program source code listings).

Документы установления достоверности программного средства (validation documents), описывающие, как устанавливалась достоверность

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

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

Документация второй группы содержит

Руководство по сопровождению программного средства (system maintenance guide), которое описывает известные проблемы вместе с программным средством, описывает, какие части системы являются аппаратно- и программнозависимыми, и как развитие программного средства принято в расчет в его строении (конструкции).

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

Заключение Быстрое увеличение сложности и размеров современных комплексов

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

В России в области обеспечения жизненного цикла и качества сложных комплексов программ в основном применяется группа устаревших ГОСТов, которые отстают от мирового уровня на 5-10 лет.

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

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 В процессе нормоконтроля пояснительных записок курсовых проектов (работ) и ВКР проверяется:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

14 Отзыв на ВКР

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приложение А

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

Приложение Б

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

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

____________ ________________

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

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

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

на тему _________________________________________________________________________

_____

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

___________ _________________________________________________________________

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

________________________________________________________________________________

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

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

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

Приложение В

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

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

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

Факультет _______________________________________________________

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

Кафедра _________________________________________________________

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

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

____________ ________________

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

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

___________________________________________________________________________

___________________________________________________________________________

___________________________________________________________________________

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

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

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

Дата введения с 01.01.80

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

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

1. ВИДЫ ПРОГРАММ

1.1. Программу (по ГОСТ 19781-90) допускается идентифицировать и применять самостоятельно и (или) в составе других программ.

1.2. Программы подразделяют на виды, приведенные в табл. 1

Таблица 1

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

1.2,1.3.

2. ВИДЫ ПРОГРАММНЫХ ДОКУМЕНТОВ

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

2.2. Виды программных документов и их содержание приведены в табл. 2.

Таблица 2

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

2.3. Виды эксплуатационных документов и их содержание приведены табл.3.

Таблица 3

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

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

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

Таблица 4

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

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

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

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

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

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

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

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

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

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

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

с 01.01. 1980 г.

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

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

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

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

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

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

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

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

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

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

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

Стандарты

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

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

ГОСТ

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

1. стандарт относиться к серии стандартов. В этом случае после индекса категории стандарта (например, ГОСТ, ГОСТ Р или ГОСТ РВ) идет код серии, точка и обозначение стандарта внутри серии. Правила обозначения стандартов внутри серии устанавливаются правилами серии. Например: ГОСТ РВ 15.201-2000, ГОСТ Р 22.8.0-99, ГОСТ 19.101-77;
2. стандарт не относиться к серии стандартов. Тогда после индекса категории идет просто порядковый номер стандарта, тире и год принятия. Например, ГОСТ Р 50628-2000.

ЕСПД

• ГОСТ ЕСКД (единая система конструкторской документации, префикс “2.”);
• ГОСТ ЕСТД (единая система технологической документации, префикс “3.”);
• ГОСТ Р, Система разработки и постановки продукции на производство, префикс “15.”;
• ГОСТ РВ, Вооружение и военная техника. Система разработки и постановки продукции на производство, префикс “15.”;
• ГОСТ, Система технической документации на АСУ, префикс “24.”;
• ГОСТ, Комплекс стандартов на автоматизированные системы, префикс “34.”.

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

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

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

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

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

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

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

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

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

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

• как было уже сказано, часто предприятие не хочет раскрывать информацию о разработчике. Отделение ЛУ и его “зажатие” позволяет это сделать (штампа, в отличии от ЕСКД, в ЕСПД на листах документа нет, вся информация локализована только в ЛУ);
• на ряде предприятий используется смешанный документооборот: подлинники документов хранятся в электронном виде в архиве предприятия, а ЛУ на них (с оригиналами подписей) - в бумажном;

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

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

• “в содержание документа включают номер разделов, подразделов, пунктов и подпунктов, имеющих заголовок” (п. 2.1.4). Это прямое указание на то, что подпункт может иметь заголовок и включаться в оглавление;
• “допускается помещать текст между заголовками раздела и подраздела, между заголовками подраздела и пункта”. Важно обратить внимание, что ненумерованный текст может быть только между заголовками, и только на верхних 2х уровнях.

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

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

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