Как правильно оформить приложение в дипломе (основные правила). Приложение в курсовой работе (пример) Как оформить несколько приложений в проекте пример
В приложениях к дипломному проекту могут приводиться копии учредительных документов, бухгалтерских балансов, статистических отчетов, на основе которых выполнен дипломный проект (ВКР).
Приложения нумеруются по порядку русскими прописными буквами: А, Б, В, …. На приложение обязательно должна быть сноска в тексте (например: «Это подтверждают данные баланса, приведенные в приложении А»).
Оформляются приложения следующим образом: по центру листа приложения (независимо от того, печатный это лист или копия бланка документа) пишется: «Приложение А». Приложения указываются в содержании, но не включаются в объем дипломного проекта (ВКР).
3 Подготовка к защите и защита дипломного проекта (вкр)
После написания проекта дипломник должен подготовиться к его защите. Этот организационный процесс предусматривает последовательное прохождение следующих стадий.
Печать работы после проверки ее нормоконтролером , закрепленным за группой.
Формирование папки дипломного проекта (вкр).
Выпускная квалификационная работа (дипломный проект) представляется в папке с твердой обложкой, имеющей три отверстия для надежной шнуровки листов.
Оформленная папка дипломного проекта (ВКР) включает:
1 Наклейка (форменный бланк) на корешок папки дипломного проекта (ВКР). Наклейка должна быть зафиксирована на папке при помощи скотча.
2 Отзыв руководителя дипломного проекта (ВКР) в прозрачном файле перед титульным листом (к работе не подшивается).
3 Рецензия на дипломный проект. Вкладывается в прозрачный файл перед титульным листом (к работе не подшивается).
4 Титульный лист, подписанный студентом-дипломником, консультантами, руководителем, рецензентом и заведующим выпускающей кафедры.
5 Задание на выполнение дипломного проекта (ВКР), подписанное студентом, консультантами, руководителем и заведующим выпускающей кафедрой.
6 Аннотация.
8 Основной текст дипломного проекта (ВКР).
9. Заключение
10. Список литературы
12. Приложения
13 Иллюстративный (раздаточный) материал, подписанный студентом-дипломником, научным руководителем и заведующим выпускающей кафедрой. Подшивается после приложений к дипломному проекту .
Раздаточный материал представляется на защиту в виде презентации, выполненной в MS Power Point.
В работе раздаточный материал оформляется как графическая часть на 8-10 листах. Первый лист графической части (презентации) - титульный лист, на котором указывается тема работы, группа и ФИО студента и ФИО руководителя работы. Листы графической части оформляются в большой рамке.
14. СD-диск с работой (пояснительная записка, презентация, титульные листы), помещенный в конверт, подписанный студентом и руководителем.
Порядок подписей работы:
1. Студент
2. Консультант с предприятия
3. Руководитель
4. Нормоконтролер
5. Рецензент
5. Зав кафедрой
Общая оценка дипломного проекта (ВКР) дается руководителем при получении письменного отзыва руководителя.
Рецензентами могут быть специалисты сферы производства. Студент сам выбирает рецензента. В рецензии должно быть отмечено значение темы, ее актуальность, уровень проработки дипломником теоретических вопросов и решения практических задач, степень обоснованности всех предложений и рекомендаций с выделением достоинств и недостатков. В заключении рецензент дает общую оценку выпускной работы, ее практической значимости, соответствия квалификационным требованиям и выставляет оценку в явном вид е («отлично», «хорошо», «удовлетворительно», «неудовлетворительно»), которая учитывается членами ГАК при рассмотрении итогов защиты.
5. Оформление приложения к проекту
1. Проект может иметь приложения (положения, планы, программы, отчеты, перечни, таблицы, списки, образцы бланков и так далее). Проект, имеющий несколько приложений, нумеруется арабскими цифрами без указания знака N. В случае если к проекту имеется одно приложение, то нумерация его не указывается. При ссылках на приложения в тексте проекта знак N также не указывается.
2. Юридическая сила приложений и решения Думы города, к которому они относятся, одинакова.
3. Все документы, прилагаемые к проекту ссылками "прилагается", "согласно приложению", "Приложение 1", оформляются как приложения к проекту в соответствии с настоящим Порядком. Использование курсива, подчеркивание или иные выделения текса не допускаются.
4. Отметка "Приложение" с указанием даты и номера проекта размещается в правом верхнем углу страницы, выравнивается по левому краю, печатается строчными буквами размером шрифта 14.
Приложение
к решению Думы
города Нижневартовска
от___.___._____ N ____
5. Наименование приложения должно соответствовать наименованию, указанному в проекте, печатается нежирным шрифтом размером 14 строчными буквами, выравнивается по центру.
6. Текст приложения начинается с абзацного отступа, печатается строчными буквами, размером шрифта 14, выравнивается по ширине.
7. Приложение может иметь может иметь следующие основные структурные элементы текста:
1) раздел;
4) подпункты;
5) абзацы.
8. Структура приложения к проекту и необходимость включения в него тех или иных структурных элементов текста определяется исходя из объема и содержания проекта. Структурные элементы текста приложения к проекту располагаются в последовательности, обеспечивающей логическое развитие темы, переход от общих положений к конкретным.
9. Раздел и глава имеют заголовок, порядковый номер, обозначаемый арабскими цифрами. Заголовок раздела, главы печатается строчными буквами, нежирным шрифтом, размером 14 и выравнивается по центру. Если в проекте нет глав, раздел не вводится.
10. Все пункты приложения к проекту начинаются с красной строки. Пункты имеют единую (сквозную) для всего приложения или главы (раздела) нумерацию, которая обозначается арабскими цифрами с точкой, заголовков не имеют.
11. Пункты приложения к проекту могут подразделяться на подпункты, которые обозначаются арабскими цифрами со скобкой без точки. После цифровых обозначений со скобкой подпункты начинаются со строчной буквы и отделяются точкой с запятой. Если подпункт проекта включает в себя несколько абзацев, они отделяются друг от друга точками.
12. Абзац проекта представляет собой часть текста между двумя отступами (красными строками).
13. Если в приложении к проекту многократно упоминается тот или иной объект либо то или иное понятие, то при первом упоминании такого объекта или понятия оно приводится полностью, а в скобках дается сокращенное наименование по форме: "(далее -___)". При этом нужно иметь в виду, что введенное сокращение не носит нормативного характера и употребляется в конкретном тексте. Не употребляются в проекте сокращенные наименования органов государственной власти Российской Федерации, органов государственной власти субъектов Российской Федерации, органов местного самоуправления муниципальных образований.
Наименования упоминаемых в проекте органов, организаций и других объектов приводятся в полном соответствии с их официальными наименованиями, предусмотренными уставами, положениями о них, решениями об их создании или переименовании и так далее. Употребление сокращенных наименований допускается лишь в нетекстовых приложениях к проектам.
Тема сложная и интересная. Я и сама не так давно в ней разобралась. Раньше, например, думала, что гриф «Для служебного пользования» может применяться во всех организациях. Оказалось, нет.
Правила применения грифа ограничения доступа есть и они меняются, в связи с введением новых нормативных актов. Например, статья 139 ГК РФ «О служебной и коммерческой тайне» утратила силу. Теперь действуют ФЗ «О коммерческой тайне» и «Положение о порядке обращения со служебной информацией» (ссылки ниже). А методические рекомендации к ГОСТ Р 7.0.97 -2016 наконец разъяснили правила оформления грифа. И это порадовало.
Давайте разберемся какие бывают грифы ограничения доступа и в каких случаях их нужно применять.
Гриф ограничения доступа — это реквизит документа, который ограничивает распространение информации. Его применяют при оформлении конфиденциального документа. Именно это и отличает конфиденциальный документ от обычного.
Конфиденциальный документ — носитель документированной информации, оформленный определенным образом и содержащий сведения, которые относятся к коммерческой, служебной или иной тайне, доступ к которому охраняется законодательством и его обладателем.
Конфиденциальная информация отличается от конфиденциального документа тем, что может быть и устной. А устную информацию контролировать довольно трудно. С материальными носителями все проще. Поэтому для документов, флешек, дисков существует гриф ограничения доступа.
Работодатель сам решает (кроме гостайны) какую информацию следует отнести к конфиденциальной, но это не должно противоречить законодательству. Поэтому нужно сначала изучить нормативные акты по этому вопросу.
После изучения нормативных документов работодатель должен решить какой гриф(ы) ограничения доступа будет использоваться в организации и будет ли. Затем правила работы с конфиденциальной информацией и использования грифа следует закрепить в нормативных документах организации. Тогда сотрудники будут знать какая информация относится к конфиденциальной и как с ней работать.
Виды грифов ограничения доступа:
«Секретно», «Совершенно секретно», «Особой важности»
.
Использование этих грифов допускается только для засекречивания информации, составляющей государственную тайну. Применяется в основном в государственных организациях или организациях, осуществляющих государственное управление. Правила отнесения сведений к гостайне определяет Правительство Российской Федерации.
Совершенно секретно
Экз.№ 1
Государственная тайна — это защищаемые государством сведения в области его военной, внешнеполитической, экономической, разведывательной, контрразведывательной и оперативно-розыскной деятельности, распространение которых может нанести ущерб безопасности Российской Федерации.
«Для служебного пользования»
.
Используется для работы со служебной информации ограниченного распространения (служебная тайна). Этот гриф используется только в федеральных органах исполнительной власти для работы с информацией, которую можно отнести к несекретной.
Какую информацию отнести к несекретной определяет исполнитель и должностное лицо, подписывающее документ. Они несут ответственность за обоснованность этого решения и за соблюдение ограничений в отношении этой информации.
Для служебного пользования
Экз.№ 1
«Коммерческая тайна»
Используется для информации, которая позволяет организации увеличить доходы, сократить расходы, сохранить положение на рынке и получить коммерческие выгоды.
Коммерческая тайна
Акционерное общество
«ИнтелИнвест»
Норвежская ул., д. 24,
г. Казань, 657533
В документах, содержащих сведения, составляющие коммерческую тайну, указывается полное наименование юридического лица и место его нахождения.
«Конфиденциально» или «Конфиденциальная информация»
Если в организации есть конфиденциальные документы, которые не отвечают признакам какой-либо тайны, то организация вправе сама определить форму грифа. Например, ввести гриф «Конфиденциально» или «Конфиденциальная информация».
Конфиденциально
Экз.№ 2
Это самые распространенные грифы ограничения доступа. Организация также может установить грифы, связанные с профессиональной деятельностью — «Банковская тайна», «Налоговая тайна», «Врачебная тайна» и другие. На практике встречается и гриф «Персональные данные», но в 80% случаях для ограничения доступа к этой информации организации используют гриф «Конфиденциально».
1 толщина слоя должна быть от 0,5 до 20 мм.
2 рисунок 1 – 14
Цифры в графах таблиц должны проставляться так, чтобы разряды чисел во всей графе были расположены один под другим , если они относятся к одному показателю. В одной графе должно быть соблюдено, как правило, одинаковое количество десятичных знаков для всех значений величин.
При наличии в документе небольшого по объему цифрового материала его нецелесообразно оформлять таблицей , а следует давать текстом, располагая цифровые данные в виде колонок.
Пример
Предельные отклонения размеров профилей всех номеров:
по высоте................................................. 2,5 %
по ширине полки.................................... 1,5 %
по толщине стенки................................. 0,3 %
3.3 Оформление математических формул
Оформление формул в курсовом или дипломном проекте выполняется согласно ГОСТ 2.105-95 и ГОСТ 7.32-2001.
Математические формулы в документах отделяются от текста сверху и снизу одной свободной строкой.
Перенос формулы осуществляется после указания математического знака (=,+,-, : ,х) с его повторением на новой строке. Между знаками арифметических действий и стоящими рядом символами или числами делаются пропуски в один пробел (например: 6 х 9 = 54 ; А - С = Д).
Пояснение к значениям символов приводится непосредственно под формулой, написание которой заканчивается запятой. Пояснения начинают после слова “где”, двоеточие при этом не ставится. Слово “где” пишется на один интервал ниже формулы. Значение каждого символа пишут с новой строки, один под другим. Значение первого символа пишется после одного пробела после слова “где”. В конце каждого пояснения ставится точка с запятой. Последнее пояснение заканчивается точкой. Применение машинописных и рукописных символов в одной формуле не допускается.
Если формул в тексте несколько, их следует нумеровать. Нумерация осуществляется арабскими цифрами, которые проставляются на одном уровне с формулой у границы правого поля листа в круглых скобках. Нумерация может быть сквозной или связанной с номером раздела (главы) текста, но не с номерами пунктов или подпунктов.
Примеры сквозной нумерации: (1), (6). Нумерация, связанная с разделами (главами) выглядит следующим образом: (1.3), (6.5) и т.д. Здесь 1 и 6 - номера разделов (глав), 3 и 5 - номера формул в них. При ссылке в документе на формулу, ее выполняют по примеру: согласно формуле (3); в соответствии с формулой (2.5).
Пример
Плотность каждого вида образца вычисляют по формуле (1).
где m - масса образца, кг;
V - объем образца (м 3) ;
- плотность образца(кг/м 3).
Формулы , следующие одна за другой и не разделенные текстом, разделяют запятой .
3.4 Оформление приложений
Оформление приложений в курсовом или дипломном проекте выполняется согласно ГОСТ 2.105-95 и ГОСТ 7.32-2001.
Приложениями могут быть, например, графический материал, таблицы большого формата, описание алгоритмов и программ решения задач и т.д.
В тексте документа на все приложения должны быть ссылки. Приложения располагают в порядке ссылок на них в тексте документа.
Каждое приложение следует начинать с новой страницы с указанием наверху посередине страницы слова “Приложение” и его обозначения, а под ним в круглых скобках для обязательного приложения пишут слово “(обязательное)”, а для информационного - “(рекомендуемое)” или “(справочное)”.
Приложение должно иметь заголовок, который записывают симметрично относительно текста с прописной буквы отдельной строкой.
Приложения обозначают заглавными буквами русского алфавита, начиная с А, за исключением букв Ё, З, Й, О, Ч, Ь, Ъ. После слова “Приложение” следует буква, обозначающая его последовательность.
Если в документе одно приложение, оно обозначается “Приложение А”.
Приложение должно иметь общую с остальной частью документа сквозную нумерацию страниц.
Все приложения должны быть перечислены в содержании документа с указанием их имен и заголовков. Ссылки на приложение оформляются следующим образом: “Сведения о современных ЭВМ представлены в приложении А”.
Приложение А (обязательное) Современные микроЭВМ Рисунок А.1 – Notebook Таблица А.1 – Характеристики ПК IBM PC
|
Рисунок 3.4 – Пример оформления приложения
Сфера проектного управления весьма обширна, от организации мероприятий (не материальный результат), до строительных (дом - очень материальный результат). И в этой сфере отдельно можно выделить категорию проектов «разработка компьютерных приложений».
Нужно очень хорошо понимать отличие этих проектов от остальных и особенно от проектов внедрения компьютерных приложений в бизнес-процессы организации.
Существует два риска, которые очень часто выливаются в проблемы:
1. те кто специализируется на разработке ПО, не замечает как ступают на территорию внедрения и проект начинает надуваться… как правило с летальным исходом;
2. те кто специализируются на внедрении и организационных проектах, без понимания сложности, начинают разработку и качество результатов начинает существенно падать - и это в лучшем случае;
Для тех кто занимается чистым внедрением или чистой разработкой - эти проблемы неведомы. Но это редкие счастливчики.
Отличительные особенности
Для начала давайте разберем критерии, по которым мы можем отличить проект разработки компьютерных приложений:1. результатом такого проекта является компьютерное приложение (web, windows, android, iOS …), модуль (функциональный блок) или какое-то существенное изменение (что такое «существенное изменение» - разберем ниже);
2. эти проекты требуют глубоких знаний архитектуры компьютерных приложений и соответствующего стека технологий, но при этом подразумевают минимальное взаимодействие с пользователями или сотрудниками задействованных в каких-либо бизнес-процессах.
П.2 - в части «мало затрагивают взаимодействие с пользователями» - это ключевая особенность, отличающая проект разработки компьютерного приложения от проекта внедрения компьютерного приложения в бизнес-процессы. Это не значит что такого взаимодействия нет, конечно же есть, просто оно минимально.
Если в ходе проекта разработки, доля взаимодействия с людьми начинает возрастать, то такой проект рискует перерасти в проект внедрения, а это уже другая весовая категория сложности и рисков.
Существенные изменения
Отдельной подкатегорией можно выделить проекты, которые стоит запускать, когда речь заходить о группе изменений, объединенных одной целью, которые могут длиться продолжительное время и затрагивать несколько версий (релизов).Если изменение или группа изменений помещается в один релиз - затевать проект не стоит.
Но если одно изменение, тянет за собой серию других изменений, вот тут уже стоит задуматься о запуске проекта, потому что:
1. Эти изменения нужно кому-то коорденировать, т.к. изменения могут вносить различные специалисты, и должен быть кто-то, кто будет в курсе и сможет коордентировать разных людей
2. Одно изменение может потянуть за собой изменения других механизмов системы, это вызывает различные риски, которые также нужно учитывать и быть к ними готовыми - лучше всего это делать через проектное управление
3. Часто изменение вынуждает разработчиков дублировать различные механизмы, делать новые рядом со старыми и старые механизмы по завершению серии изменений нужно будет удалить из системы. Без координации - эти «ошметки» могут там остаться навсегда и это влечет за собой печальные последствия в долгосрочной перспективе.
Например :
В системе управления задачами, нужно было расширить блок Участники. Добавить возможность выбора не только сотрудников, но и группы
Начали с проработки интерфейса, оказалось что нужно менять подсистему доступа
Начали менять подсистему доступа, поняли что нужно оставить старую на некоторое время, потому рядом создали новый механизм, без ломки старого
Внесли изменения в интерфейс, подружили с новой моделью, отладили новый
Теперь нужно удалить старый механизм
Все 4 пункта - растянулись на 5 месяцев и 3 версии разработки. Без координации - было бы на много дольше, а в результате могли бы просто потерять вектор цели и забыть про то что старый механизм нужно удалить.
Опасный момент
Очень опасной, но также и крайне распространенной является ситуация, когда заказчик просит разработать некую систему: учет финансов, работа менеджеров по продажам или что-то типа того.Вроде бы с первого взгляда это обычный проект разработки. Нужно что-то разработать.
Но шансов на успех у этого проекта не много, т.к. очень скоро окажется что приложение готово, но заказчик почему то не доволен. Система не работает.
Причина в том, что внедрение - это отдельная область знаний. А проекты внедрения - это отдельная категория проектов.
Долгое время мне удавалось реализовывать различные ИТ-проекты, лишь краем затрагивая разработку. Это вызывало дикие проблемы, потому старался всегда разработчиков обходить стороной. Лучше внедрить типовой продукт типа 1С УПП 8, а после чего можно дорабатывать. И это вполне реально, хоть многие 1С-разработчики в это не очень то верят
Итого
Однако за последний год меня угораздило мне повезло заниматься проектами внедрения, вплотную завязанным на проекты разработки. Это был крайне тяжелый год.После чего выработались те определения, которые вы прочитали в начале статьи.
Наверное для разработчиков приложений - я не открыл ничего нового. Те кто сидят за стенкой из Интернет в далеке от конечных пользователей - занимаются только проектами разработки компьютерных приложений - все это понятно как ясень день.
Но вот те кто работают в отделах ИТ различных организаций, вот для них это все суровые «трудовыебудни».
Готов поспорить, что в большинстве организаций нет таких процессов:
1. управление проектами разработки
2. управление релизами
3. управление изменениями по релизам
Хоть практика ITIL и говорит что они нужны, но многие этими рекомендациями пренебрегают. Или попытались, но не получилось.
Мне чаще приходится иметь дело с проектами внедрения, но за этот год пришлось углубиться в тему разработки и поставить вышеперечисленные процессы на поток.
Что заметил?
1. проще стало прогнозировать ресурсы и затраты на развитие информационной системы
2. у разработчиков больше позитива в работе, когда закрываешь не просто изменение или релиз, а целый проект, который целенаправленно вели и коорденировали долгое время
3. особенно хорошо, когда проект закрывает сам разработчик. Это уже не мелкое изменение - это уже проект. Совсем другие ощущения.
4. ну и конечно же качество разработки - хвосты не теряются, серии изменений проходят точнее и с меньшими ошибками
5. на сколько удалось понять, в SCRUM - аналогом проекта является «запрос» или «заказ», который может поступить от «Заказчика», и который затем нужно разбить на задачи, которые могут закрываться в разных релизах.