Как написать диплом на 1с
Состав и содержание работ по подготовке объекта автоматизации к вводу подсистемы в действие. Реализация пользовательского интерфейса "Менеджер". Создание проекта в программе "1С: Предприятие". Экономическая эффективность внедрения программного продукта.
Подобные документы
Краткая характеристика предприятия и его организационная структура, описание технического и программного обеспечения. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие. Расчет трудоемкости внедрения.
отчет по практике, добавлен 11.12.2013
Объекты и методы проведения предпроектного обследования предприятия, анализ результатов . Схема организационной структуры управления и документооборота. Назначение информационной подсистемы. Реализация подсистемы "Helpdesk" на основе "1С: Предприятие".
дипломная работа, добавлен 24.06.2011
Реализация подсистемы управления файлами, использующей в качестве способа физической организации файла связанный список блоков. Разработка общей структуры модуля. Описание реализуемых в программе алгоритмов. Ввод в действие программного комплекса.
курсовая работа, добавлен 10.07.2015
Диагностический анализ системы управления предприятия, построение функциональной схемы. Анализ информационного, технического и программного обеспечения. Разработка информационной подсистемы "Заработная плата" и экономическая эффективность проекта.
дипломная работа, добавлен 21.06.2011
Назначение и цели создания программы, требования к ее функциональности и возможностям, к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие. Расчет экономической эффективности от внедрения разработанной базы данных.
дипломная работа, добавлен 27.05.2015
Характеристика составляющих компонент раздела "Управление конфигурациями и активами услуги". Создание справочников и подсистемы, отчетной формы. Область применения продукта и стандарты управления ИТ инфраструктурой. Описание демо-версии 1С:ITIL ПРОФ.
дипломная работа, добавлен 10.07.2017
"1С: Предприятие" - система программ для автоматизации различных областей экономической деятельности предприятия. Технологическая платформа и конфигурации системы. Создание мини-системы "Шиномонтаж" с использование программного продукта "1С: Предприятие".
курсовая работа, добавлен 19.01.2016
Проектирование структуры информационной базы и разработка программного комплекса, позволяющего автоматизировать процесс учета налогоплательщиков. Разработка конфигурации и создание интерфейса базы данных, форм и отчетов в программе "1С Предприятие".
дипломная работа, добавлен 21.06.2015
Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие. Средства, расширяющие возможности операционной системы. Руководство пользователя. Функции "Учет пациентов". Ввод в действие, методика испытаний.
дипломная работа, добавлен 29.07.2016
Проектирование структуры и архитектуры программного продукта. Реализация программы конвертера файлов баз данных. Описание пользовательского интерфейса. Выбор порядка конвертации dbf файлов. Создание и исполнение шаблонов. Расчет себестоимости продукта.
Все началось более 2-х лет тому назад, и я перешел на 4-й курс специальности "Бизнес-информатика" Томского Государственного Университета Систем Управления и Радиоэлектроники (ТУСУР). До окончания ВУЗА оставалась не много времени, и перспектива написания диплома уже маячила перед глазами. Мысль о покупке готовой работы не рассматривалась. Хотелось реально что-то сделать самому. Вариантов тем дипломных проектов рассматривалось много: и проекты конфигураций для автоматизации производственных нужд компании и проект внедрения Документооборота своими силами на 3 территориальные единицы и более 500 активных пользователей и внедрение ЭДО. Короче много всего что было в голове, но ничего из этого не вдохновляло. А это было главное.
В это время я работал в одной уважаемой компании и по делам службы познакомился с одним классным программистом и вообще хорошим человеком Андреем Щегловым (Привет Андрей!) и как =-то за разговором он у меня спросил, слышал ли я что-нибудь об OneScript и языке сценариев Gherkin. На что и получил ответ что нет, не слышал. Естественно, вечернее гугление/яндексение и бессонная ночь привела на мысль что вот он — мир неизведанного. Но идея о том, что это может стать темой дипломной работы пока не зарождалась. Рутинный круг обязанностей составлял обычную работу в Конфигураторе 1С по-задачно, как вы понимаете с ручным тестированием и не позволял полностью погрузиться в новый подход в мире 1С.
Незнакомые понятия
Первая трудность с чем я столкнулся, это неимоверное количество различных терминологий и инструментов, о которых вообще не слышал — так как я в тот момент был «типичным одинэсником» (в этот момент начинается холивар…) Особо не владея никакими другими языками программирования, и к тому же методологии большого IT для меня были абсолютно не знакомыми, мне приходилось прыгать с темы на тему, чтобы хоть как-то наполнить свой глоссарий.
Практически в этот же момент я (мы – и мои коллеги) столкнулись с довольно специфичной проблемой. Приняли программный модуль от подрядчика, проверили на копии. Вроде все работает. Но так как работы было очень много, то подписали акт выполненных работ и закинули в продуктив. Все было хорошо в течении полугода, пока данных в этой подсистеме не превысило допустимого. И начали происходить очень странные вещи. Проведение документа из модуля стало происходить по 5-10 минут, появились куча ошибок ну и.т.п. Просмотр программного кода привел в ужас (не спрашивайте почему это не сделали раньше при приемке…). Количество вложенных циклов было просто за гранью разумного. Единственный запрос в четвертом цикле и обращение через 4 точки были мелочами, перебор всех предыдущих документов для заполнения текущего документа, 10-ти кратный копипаст одного и того же блока и много еще чего.
Дублирование полей в макете:
Причем для заполнения этих полей, 14-ти кратный кописпаст.
И пока переменная ФФ не достигнет 15:
Ну и еще куча других не менее уникальных произведений искусства.
Вдруг я вспомнил, что для OneScript есть простенькая библиотека для расчета "цикломатичности" модуля(1) (сложности модуля или метода). Нашел, рассчитал. Получил значение 163 единицы, при допустимом значении не более 10. И пришел к выводу, что приемочное тестирование программного кода должно быть обязательно и оно должно быть автоматическим и непрерывным. Тогда я узнал о Continuous Inspection — причем как оказалось еще в 2006 году компания IBM сделала(2) публикацию на эту тему.
Дальше больше. Наверное, многие работающие в крупных компаниях встречались с проблемой разворачивания копии рабочей базы на локальной машине разработчика. Когда эта база весит 5-10 гбт – это не проблема, а когда она только в бэкапе весит почти терабайт то это уже серьезно. В итоге для того, чтобы развернуть у себя свежую копию тратилось по 5-6 часов рабочего времени. Когда мне это надоело я начал пользоваться очень хорошим инструментом 1C-Deploy-and-CopyDB (Антон спасибо!) Тогда я понял, что автоматизация – это классно.
Дальше были другие задачи, например, регулярное обновление основной и распределенной базы из хранилища ночью, тестирование форм, сценарные тесты и.т.д. Что-то было из этого реализовано, а что-то нет.
Но все это нужно было только мне. При поиске единомышленников в своем городе практически потерпел фиаско. Их нет. Хотя жутко странно, так как проблемы типичные. В этот момент я уже знал, что хочу написать свою дипломную работу именно по этой теме. Но что писать – не знал. Поэтому пришлось подключиться к сообществу в качестве уже не просто читающего, а как минимум пишущего и задающего вопросы. Основными местами, где можно задавать вопросы оказались
Ну и как средство быстрой связи — профильные группы в Gitter
Начался сбор материала. Волею судеб мне удалось мне связаться на форуме XDD с Алексеем Лустиным alexey-lustin (Привет Алексей!) и рассказать про мою идею диплома. На что, с удивлением услышал, одобрительный отзыв и даже приглашение пройти в компании «Серебряная Пуля» преддипломную практику. Это была уже победа. В течении нескольких часов мы придумывали тему и содержание диплома. Ставили задачи на практические работы. Получил руководителя дипломного проекта от компании — Артур Аюханов (Артур привет!) Как юный падаван получил доступ к видеокурсу релиз-инженера и возможности неограниченно доставать Никиту Грызлова (Привет Никита!) своими вопросами, за что ему очень признателен.
В итоге:
Тема диплома — «Автоматизированное управление жизненным циклом информационных систем — системная и программная инженерия решений на платформе 1С: Предприятие в условиях непрерывного улучшения качества процесса производства».
Цель выпускной квалификационной работы (ВКР) — выявление взаимосвязи программных инструментов и описание бизнес-процесса работы контура DevOps в области 1С.
Теоретическим обоснованием проекта был стандарт непрерывного улучшения качества сервиса из ITIL 3.0, а в качестве практического объекта было выбрано построение контура непрерывной интеграции для нового прикладного решения, которое мы разработали – личный кабинет покупателя. Для этого был развернут сервер исходных кодов GitLab и сборочный контур Jenkins. Прогон тестов осуществлялся на выделенном сервере (Windows Slave). Выгрузка конфигурации из хранилища 1С осуществлялась посредством библиотеки Gitsync, редакция 3.0
(в настоящий момент размещен в ветке develop) уже с наработками Алексея Хорева (Леха привет!) с периодичностью 30 минут в ветку develop. Причиной выбора именно этой версии была возможность подключения к хранилищу через протокол tcp, который, к сожалению, не поддерживал на тот момент типовой GitSync 2.x. Если в GitLab фиксировались изменения, то автоматически запускался прогон контура непрерывной интеграции.
Так как бюджет всего мероприятия был нулевым, и возможности построить полноценную проверку качества программного кода без покупки модуля для SonarQube было невозможно, то в качестве упрощенного решения использовалась типовая проверка синтаксиса 1С. Хотя разовые выгрузки все-таки были сделаны, а результаты были получены и проанализированы. Также были использованы дополнительные проверки на цикломатичность и на наличие повторно используемого кода.
На этапе тестирования функционала были задействованы 2 фреймворка Vanessa-Behavior и XUnitFor1C в их объединенном варианте под названием Vanessa Automation Driven Development (Vanessa ADD). Первый использовался для запуска тестировании ожидаемого поведения, вторым осуществлялась проверка открытия форм (дымовое тестирование). Результатом прохождения контура непрерывной интеграции были автоматически сгенерированные отчеты.
По результатам тестирования, релиз – инженер принимал решение о слиянии ветки develop и master, и запускал (уже вручную) третью задачу – публикацию изменений в продуктивную базу. Продуктивная база не подключена к хранилищу и полностью закрыта от ручных изменений. Обновление осуществляется только через поставку, причем в автоматическом режиме.
Для описания бизнес-процесса работы контура была сформирована диаграмма IDEF0 состоящая из 4 последовательных блоков, формирующих прохождение контура. Ошибка возникающая при прохождении любого из этапов прерывает сборочный процесс с оповещением релиз-инженера и передает управление на 5 блок сборочного процесса, где и формируются отчеты в в формате ALLURE, JUNIT и конечно cucumber.json.
Описание модели IDEF0
Процесс «Выгрузка исходников в GIT»
Обязательным условием существования контура является наличие файлов исходного текста. С версии платформы 8.3.6 компания 1С предоставила возможность выгрузки исходных кодов конфигурации в файлы. Следует учесть, что данный процесс может иметь несколько вариантов исполнения, зависящих от специфики разработки в IT отделе. В текущем варианте для упрощения процесса перехода сотрудников к новой методике была выполнена интеграция с текущим процессом разработки через хранилище конфигурации и используя конфигуратор 1С.
На этапе выполнения процесса «Выгрузка исходников в GIT» будет произведено создание файловой, служебной информационной базы 1С; осуществлено ее подключение к хранилищу конфигурации под служебной учетной записью; получены все изменения на текущий момент времени (или последнему коммиту в хранилище); произведена выгрузка исходников в сборочную директорию; сделан коммит в систему хранения версий GIT; изменения отправляются на сервер исходных кодов GitLab
Процесс «Тестирование качества исходного кода»
На момент старта данного процесса, исходный код хранится в репозитарии GitLab. С помощью управляющего (сборочного) скрипта производится получение его в сборочную директорию. Средствами платформы 1С: Предприятие, на основании этих исходных кодов разворачивается служебная информационная база. Производится анализ ошибок средствами платформы. В случае, если при выполнении анализа будут обнаружены ошибки программного кода, не позволяющие собрать конфигурацию, то процесс прервется. Цель данного шага – исключение потерь времени на анализ программного кода неработоспособной конфигурации.
После проверки на ошибки запускается подсчет цикломатической сложности программного кода. Увеличение этого коэффициента существенно отражается на отладке и анализе программного кода. Максимально допустимое значение 10. При превышении вызывается исключение, и код возвращается на доработку.
Заключительным шагом анализа качества программного кода является проверка на соответствие стандартов разработки. Для этих целей в предложенной схеме используется сервис SonarQube и разработанным для него модулем поддержки синтаксиса 1С от компании «Серебряная пуля». По результатам анализа система рассчитывает значение технического долга для каждого сотрудника, разместившего программный код.
Процесс «Тестирование функционала»
В процессе разработки могут происходить ситуации, что новый функционал может нарушить работу уже существующих подсистем. Это может проявляться как формировании исключений, так и выводе не ожидаемого результата. Для этих целей производится тестирование ожидаемого поведения системы.
Для данного контура применимо несколько методов разработки и тестирования: TDD (Test Driven Development) и BDD (Behaviour Driven Development)
На момент написания ВКР, для выполнения тестов по Методике BDD использовался фреймворк Vanessa-bahavior, для TDD – XunitFor1C. В настоящий момент они объединены под одним продуктом Vanessa-ADD. Поддержка старых продуктов разработчиком прекращена. Результаты тестирования выводятся в файлы отчетов Yandex Allure и Xunit.
Процесс «Сборка поставки»
В данном процессе происходит окончательная сборка поставки конфигурации для развертывания в целевой системе. Проверенный исходный код находится в ветке develop репозитария исходных кодов GitLab. Для формирования поставки необходимо, что бы изменения из ветки develop появились в ветке master. Это действие может происходить как вручную, так и автоматически и регламентируются требованиями IT подразделения использующего контур CI/CD. После слияния веток запускается процесс сборки готовой поставки. Для этого опять в сборочной директории, на основании существующих исходников, создается служебная информационная база, и затем, средствами платформы 1С: Предприятие формируется поставка конфигурации и архивируется. Поставка конфигурации является финальным продуктом сборочного процесса и поставляется заказчику по установленным каналам связи или же устанавливается непосредственно в продуктивную информационную систему.
Процесс «Публикация результатов»
При выполнении этапов процесса, инструменты тестирования создают как побочный продукт файлы отчета в определенных форматах. Задача данного процесса произвести группировку, преобразование и публикацию для удобства анализа данных. В случае формирования исключения на каком-то этапе сборки и при наличии нужной настройки система должна автоматически уведомить администратора контура о наличии проблем. Этот этап выполняется в постобработке сборочного процесса и должен выполниться вне зависимости от результатов предыдущих процессов.
Результатами моего проекта стала защита ВКР в конце мая этого года с результатом «отлично». Дополнительно, была актуализирована методическая информация по формированию контура.
Общие выводы:
- Экономический эффект возможен только в долгосрочной перспективе. По опыту замечено, что при запуске проекта имплементации инженерных практик фиксируется снижение производительности разработки на 20-30% от текущего уровня. Этот период временный, и как правило производительность возвращается к первоначальным значениям через три – четыре месяца эксплуатации. Снижение производительности связанно прежде всего, с тем, что разработчику приходится привыкать к новым требованиям разработки: написанию сценариев, тестов, формированию технической документации.
- Существенно повысилось стабильность продуктивной информационной системы, за счет тестирования программного кода. Гарантированная работа критически важных подсистем обеспечена покрытием сценарными тестами. За счет этого снизились риски компании на критически важном направлении — оперативное взаимодействие с клиентами.
- Исключение динамических исправлений на продуктивной информационной базе позволило более конструктивно планировать разработку и исключить попадание программного кода в обход контура тестирования.
- Снижение трудозатрат на сервисное обслуживание информационной базы, за счет автоматизации сборочного контура.
- Использование обратной связи через Slack позволило в оперативном режиме контролировать и исправлять проблемы жизненного цикла системы. По отзывам команды, использование месенджера, удобнее почтовой рассылки (хотя она тоже присутствует).
- Использование автоматизированной проверки программного кода (Continuous Inspection) на соответствие стандартам разработки (SonarQube) вынуждает разработчиков самостоятельно повышать компетенцию, а исправление выявленного технического долга непосредственно при разработке программного модуля происходит гораздо быстрее, так как не надо тратить время на восстановление контекста задачи.
- Включение функционала авто-документации и генерации видео-инструкций позволяют снизить количество обращений пользователей.
- В ходе выполнения проекта был сформирован бизнес-процесс, описывающий жизненный цикл разработки и тестирования прикладных решений 1С, который в свою очередь повлиял на формирование проекта имплементации инженерных практик. Сформирован набор инструментов и документации, позволяющий быстро развернуть окружение на любых проектах 1С.
Если говорить о сложностях с которыми я столкнулся во время реализации проекта, то они абсолютно такие же как в статье Сопротивления автоматизации тестирования. В 90% случаев связанны либо со внутренним сопротивлением компании на изменение существующей модели разработки либо отсутствием на тот момент достаточных знаний.
Что же касается личных результатов, то они такие:
В заключении, хочу сказать, что 1С хоть и медленно, но двигается к полноценному DevOps. В настоящее время достаточно инструментов для построения контуров, но несколько тормозит процесс развития — это недостаточное количество специалистов DevOps в среде 1С и незнание руководителей о существовании таких возможностей.
Буду очень признателен, если Вы приведете свое мнение о концепции DevOps в 1С. Чего по вашему мнению не хватает отрасли?
Астрологи объявили неделю дипломов на Тостере. Количество вопросов про выбор темы для диплома удесятеряется.
Необходимо выбрать тему для написания диплома. Преддипломная практика будет в 1С франчайзи, соответственно нужно придумать что то с программированием 1С. Прочитана только одна книга: Радченко М. "1C Предприятие 8.2 Практическое пособие разработчика". И месяц практики в том же франче. Причем по факту в общей сложности на этой практике пилил конфигурацию всего часов 60-80 в сумме. В общем что то сложное не потяну, но и скучное не хочется. Кафедра созванивалась с франчем, но темы они придумать не смогли, хотя одногруппнице которая диплом там же писать будет (с программированием разбираться вообще только начала) тему придумали.
Идей нет вообще.
P.S. Сам с франчем пока не связывался, может человек который у меня был руководителем практики от предприятия что подскажет, но надежды мало. Скорее он одобрит или отклонит то что я предложу. Может с изменениями.
- Вопрос задан более трёх лет назад
- 5083 просмотра
"Автоматизация документооборота на платформе 1С Предприятие 8.2 рекламного агенства"
Не так уж и сложно, но и материала было не мало.
Спасибо, может и подойдет. Хотя у нашей кафедры странные понятия о дипломах. Хотят либо сайт на CMS вообще без допиливания и на бесплатном шаблоне, либо нечто что представить так же просто как и тессеракт.
CMS из коробки - это как представить болдженос. Если с веб соберёшься делать, то можешь напилить, что нибудь по типу тестирования сотрудников. Так же делали веб сайт + бд + оболочка для интернет провайдера. Сочувствую.
Всем привет, меня зовут Александр и в этом году я заканчиваю магистратуру.
Так получилось, что сейчас я пишу 2 диплома или, правильнее сказать, 2 магистерских диссертации одновременно: одну на русском языке по российским стандартам, а вторую — на английском языке по немецким стандартам. Почему так получилось, я расскажу как нибудь потом (совсем другая история), а сейчас, я бы хотел поделиться своими знаниями в области написания работ бакалавров и магистерских диссертаций в преддверии летних защит.
Введение. Фундамент работы
Как и в твоём дипломе, в моей статье тоже должно быть введение. О структуре поговорим позже, а сейчас, хотел бы сказать с чего всё начинается.
А начинается всё с того, что тебе необходимо что-то сделать, например, если ты бакалавр, то твоя работа должна быть более проектной (70% Техническая часть 30% Исследовательская часть). Обычно, работы бакалавров в Computer Science заключаются в создании какого либо приложения, которое автоматизирует определенную задачу, например «Автоматизированная система библиотеки».
Работы магистров формально и фактически должны состоять в большей степени из исследовательской части и в меньшей из технической (70/30). Но зачастую, программисты делают магистерские работы аналогичными бакалаврским, только в более расширенном варианте и пытаются притянуть за уши какую-никакую «науку» в них.
Если хочешь написать хороший диплом, задумайся об этом за 1 год, а ещё лучше за 2. Если ты бакалавр, то можешь начать спрашивать на кафедре про проекты, в которых ты бы мог принять участие. Если кафедра разрешает писать дипломы по своим собственным проектам — тоже хорошо. Если ты магистр, то самым простым вариантом будет продолжать делать то, что ты уже делал в бакалавриате, пытайся изобрести что-нибудь новое или же использовать что-то существующее в новой задаче. Публикация статей и поездки на конференции формируют бэкграунд для того, чтобы успешно написать свою работу и суметь её защитить.
Личный пример: Тема моего бакалаврского диплома находится на стыке Computer Science и Natural Language Processing (NLP) и называлась так: «Разработка диалоговой системы для помощи студентам и абитуриентам ВУЗа». Этакий ВУЗовский чатбот. В данной работе большее внимание я уделял написанию веб-приложения и меньше рассматривал отдельные методы из NLP, которые я использовал в своём чатботе. В магистерской диссертации наоборот, я большее внимание уделяю конкретным методам и подзадачам. Изучаю влияние входных данных на качество выхода и так далее. Разработке приложения уделяется минимальное внимание, в этом и разница.
Итак, что же нужно делать? Если ты бакалавр — пиши приложение, если магистр — делай исследование. В обоих случаях старайся ездить на конференции и публиковать статьи — это поможет заложить крепкий фундамент выпускной квалификационной работы.
Когда это нужно делать? Начинать нужно за 1-2 года до срока сдачи диплома, а заканчивать стоит за 1-2 месяца до сдачи. Это время тебе понадобится на написание отчёта, о котором поговорим далее.
Зачем это нужно делать? В первую очередь для себя. Если ты сможешь написать простенькое CRUD приложение, то у тебя есть все шансы пойти работать Junior разработчиком в локальную ИТ-конторку. А ещё, тебе нужно выпуститься из ВУЗа, так что код писать в любом случае придётся.
Написание отчёта
Обычно, под дипломом студенты понимают именно отчёт, особенно такое мнение популярно в России. Более того, я знаю человека, который часть своего диплома написал с помощью генератора текста (о котором и был его диплом). К сожалению, такой подход, по моему мнению, ошибочен, ведь отчёт — это всего лишь описание того, что ты сделал. А о том, что нужно делать мы уже поговорили в предыдущей части.
Перед тем, как писать отчёт — тебе необходимо почитать научные статьи по твоей тематике, желательно те, которые ты потом сможешь использовать в списке литературы своей работы. Выбери 15-20 статей (50% русских, 50% зарубежных) и начни штудировать. Искать статьи можно тут: E Library и Google Scholar. Так же полезно иметь парочку полноценных книг по твоей теме, из них можно брать фундаментальные понятия, например про принципы ООП. Искать книги можно тут: Вконтакте Документы OZON. Можешь не читать всё целиком, а лишь бегло и осознанно пробежаться по основным пунктам, впоследствии, для уточнения деталей ты ещё не раз будешь возвращаться к той или иной статье.
После того, как ты ознакомился с литературой, можешь начинать накидывать «скелет» твоего диплома. Где это делать — решать тебе, обычно все пишут в Ворде, можно делать в Гугл Доке, а если ты преисполненный и умеешь пользоваться LaTeX, то ищи соответствующий шаблон и пиши там! Примерная структура диплома программиста в соответствие с ГОСТом 7.32 выглядит следующим образом:
- Титульный лист (зависит от вашего ВУЗа)
- Реферат (пишется по госту, примерная длина — одна страница)
- Определения (прописываем все определения, например «Инкапсуляция — . ». Всё в алфавитном порядке)
- Обозначения и сокращения (прописываем в алфавитном порядке все аббревиатуры)
- Введение (описание важности проблемы, статистика, описание самой проблемы, цель и задачи)
- 1. Теоретические и технические основы (описывает основные понятия и технологии, которые вы используете)
- 2. Описание предложенного подхода (для бакалавров — проектирование программного продукта со всеми вытекающими, для магистров постановка и описание экспериментов, описание предлагаемых методов решения задачи)
- 3. Имплементация (для бакалавров — описание процесса разработки, для магистров — описание процесса проведения экспериментов, анализ результатов и выведенные инсайды).
- Заключение (подведение итогов, обзор выполненных задач и цели, ограничения работы и последующая работа)
- Список использованных источников (в порядке цитирования, можно юзать сервис snoska.info)
- Приложения (может быть листинг кода, модели данных и т.д.)
Ещё, к данной структуре диплома могут быть добавлены две главы: Экономическое обоснование и Защита информации. Всё зависит от требований вашей кафедры или университета.
По поводу оформления — я бы не хотел вдаваться в подробности в этой статье, требования достаточно полно описаны в ГОСТе 7.32.
Личный пример: диплом бакалавра я писал в Ворде и с этого получил очень много баттхёрта, теперь я пишу диплом в Гугл Доках и пока не заморачиваюсь по поводу оформления. К слову сказать, в Германии нет жёстких требований по оформлению — главное содержание. Но, об этом, в следующей статье.
Итак, что же нужно делать? Найди 15-20 научных статей и пробегись по ним. Создай документ в Ворде (или в чем-то другом), накидай его структуру в соответствие с приведенным тут содержанием и начинай шаг за шагом писать текст. Далее, открой ГОСТ и скорректируй оформление.
Когда это нужно делать? Начинай писать отчёт за 2-3 месяца до сдачи диплома.
Зачем это нужно делать? Это формальность, которая позволит тебе выпуститься из ВУЗа. Есть и приятный бонус: написание отчёта помогает тебе структурировать в голове все знания, полученные в процессе работы.
Подготовка презентации
Окей, ты проделал большую работу и написал отчёт, осталось это красиво презентовать. Начинай готовить слайды, когда отчёт уже почти завершен. Структура презентации должна примерно соответствовать структуре твоего отчёта, а оформление слайдов индивидуально для каждого ВУЗа или кафедры.
Чего НЕ нужно делать:
- Вставлять код на слайды
- Вставлять длинные схемы алгоритмов на слайды
- Писать длинные определения
- Заполнять слайд текстом на 100%
Личный пример: я всегда структурирую слайды для презентации по тому же принципу, как и в отчёте. Готовлю слайды в зависимости от требований по оформлению, если сторих рамок нет, то использую LaTeX, если есть строгие правила по оформлению и нет шаблона в LaTeX, то использую Power Point.
Итак, что же нужно делать? Создай структуру слайдов в соответствии с оглавлением твоего отчета и заполни их шаг за шагом. Затем, по тому же принципу напиши доклад и отрепетируй презентацию.
Когда это нужно делать? Начинай готовить презентацию за 2-3 недели до защиты.
Зачем это нужно делать? Опять же, это формальность, которая позволит тебе выпуститься из ВУЗа. А ещё, это поможет тебе научиться грамотно презентовать твоё исследование.
Заключение
Вместо заключения хотел бы пожелать всем, кто в этом году заканчивает ВУЗ — удачных защит, а тем, кто это будет делать позже — «готовьте сани летом». Если лень читать, просто пробегись по пунктам, выделенным жирным шрифтом, там я постарался собрать краткую выжимку из каждого параграфа. Жду ваши комментарии внизу!
Состав и содержание работ по подготовке объекта автоматизации к вводу подсистемы в действие. Реализация пользовательского интерфейса "Менеджер". Создание проекта в программе "1С: Предприятие". Экономическая эффективность внедрения программного продукта.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | дипломная работа |
Язык | русский |
Дата добавления | 01.07.2011 |
Размер файла | 7,2 M |
Подобные документы
Экономическая эффективность внедрения программного продукта "1С: Бухгалтерия 8.0". Назначение технологической платформы "1С: Предприятие" и конфигурации "Бухгалтерия предприятия". Создание подсистем, справочников, документов, отчетов и интерфейса.
реферат [967,0 K], добавлен 15.06.2015
Краткая характеристика предприятия и его организационная структура, описание технического и программного обеспечения. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие. Расчет трудоемкости внедрения.
отчет по практике [167,4 K], добавлен 11.12.2013
Объекты и методы проведения предпроектного обследования предприятия, анализ результатов . Схема организационной структуры управления и документооборота. Назначение информационной подсистемы. Реализация подсистемы "Helpdesk" на основе "1С: Предприятие".
дипломная работа [6,9 M], добавлен 24.06.2011
Реализация подсистемы управления файлами, использующей в качестве способа физической организации файла связанный список блоков. Разработка общей структуры модуля. Описание реализуемых в программе алгоритмов. Ввод в действие программного комплекса.
курсовая работа [666,0 K], добавлен 10.07.2015
Диагностический анализ системы управления предприятия, построение функциональной схемы. Анализ информационного, технического и программного обеспечения. Разработка информационной подсистемы "Заработная плата" и экономическая эффективность проекта.
дипломная работа [5,6 M], добавлен 21.06.2011
Назначение и цели создания программы, требования к ее функциональности и возможностям, к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие. Расчет экономической эффективности от внедрения разработанной базы данных.
дипломная работа [762,5 K], добавлен 27.05.2015
Характеристика составляющих компонент раздела "Управление конфигурациями и активами услуги". Создание справочников и подсистемы, отчетной формы. Область применения продукта и стандарты управления ИТ инфраструктурой. Описание демо-версии 1С:ITIL ПРОФ.
Читайте также: