Полный HTML-пример

Пример ВКР по ГОСТ 2026: полный HTML-образец оформления

Смотрите документ как цельную ВКР: от титульного листа и задания до источников и приложения. Пример нужен для сверки структуры и внешнего вида, а не для копирования чужого текста.

Times New Roman, 14 пт, интервал 1,5, учебная структура ВКР, сквозная логика содержания, ссылок, таблиц, рисунков и приложений.

Титульный листтитульный

Федеральное государственное бюджетное образовательное учреждение

высшего образования "Примерный государственный университет"

Институт цифровых технологий и управления

Кафедра информационных систем

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА

по направлению подготовки 09.03.03 Прикладная информатика

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

Выполнил:студент группы ПИ-41
Соколов Артем Игоревич

Руководитель:канд. техн. наук, доцент
Лебедева Марина Олеговна

Москва 2026
Заданиестр. 2

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

ФГБОУ ВО "ПРИМЕРНЫЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ"

Институт цифровых технологий и управления

ЗАДАНИЕ НА ВЫПУСКНУЮ КВАЛИФИКАЦИОННУЮ РАБОТУ

по направлению подготовки 09.03.03 Прикладная информатика

Тема ВКРРазработка веб-сервиса для проверки и оформления учебных документов
Практический результатВеб-сервис для загрузки учебных работ, проверки структуры и оформления, формирования HTML-предпросмотра и подготовки результата к выгрузке в документ.
НазначениеАвтоматизация проверки курсовых и выпускных работ: фиксация исходного файла, диагностика нарушений, показ примера корректного оформления и подготовка рекомендаций пользователю.
Основные функции1. Загрузка учебного документа пользователем.
2. Проверка структуры, заголовков, таблиц и источников.
3. Формирование HTML-предпросмотра с реальными стилями.
4. Выдача диагностического отчета по найденным нарушениям.
5. Подготовка итогового файла и истории проверок.
Используемые технологииJavaScript, React, Node.js, Express, PostgreSQL, REST API, HTML, CSS.
Решаемые задачи1. Проанализировать предметную область и выявить проблемы ручного оформления учебных документов.
2. Сформировать требования к веб-сервису проверки и пользовательским сценариям.
3. Спроектировать архитектуру системы и модель данных.
4. Реализовать модули импорта документа, диагностики, HTML-предпросмотра и отчетности.
5. Провести тестирование основных сценариев работы.
Состав технической документацииПояснительная записка ВКР, описание архитектуры, описание модели данных, сценарии тестирования, фрагменты интерфейса, приложения.
Состав графической частиДиаграмма архитектуры веб-сервиса, ER-диаграмма базы данных, схема пользовательского сценария, макеты основных экранов.
Планстр. 3

ПЛАН РАБОТЫ НАД ВКР

ЭтапСрок выполнения
Анализ предметной области и требований1-3 неделя
Проектирование архитектуры и базы данных4-7 неделя
Реализация модулей веб-сервиса8-13 неделя
Тестирование, оформление и подготовка защиты14-18 неделя

Руководитель ВКР ____________________ / Новикова Елена Павловна /

Студент ____________________ / Соколов Артем Игоревич /

Аннотациястр. 4

АННОТАЦИЯ

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

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

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

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

Содержаниебез номера
Введениестр. 6

ВВЕДЕНИЕ

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

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

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

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

При проектировании используются требования к структуре работы и оформлению источников, приведенные в нормативных документах [1, 2]. Подходы к проектированию информационных систем и веб-сервисов раскрыты в работах [3, 4].

Для достижения поставленной цели необходимо решить следующие задачи:

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

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

3. Спроектировать архитектуру системы, структуру базы данных и пользовательские сценарии.

4. Реализовать основные модули веб-сервиса и провести тестирование результата.

6
Глава 1стр. 7

ГЛАВА 1. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ И ПОСТАНОВКА ЗАДАЧИ

1.1 Характеристика процессов проверки документов

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

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

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

1.2 Обзор существующих решений

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

7
Глава 1стр. 8

1.3 Требования к разрабатываемому веб-сервису

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

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

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

Таблица 1 - Основные требования к веб-сервису

Группа требованийСодержание
ФункциональныеИмпорт документа, проверка структуры, предпросмотр и отчет
НефункциональныеДоступность интерфейса, защита данных, устойчивость к ошибкам
АналитическиеОтчеты по типовым ошибкам, статусам проверок и динамике исправлений

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

8
Глава 2стр. 9

ГЛАВА 2. ПРОЕКТИРОВАНИЕ ВЕБ-СЕРВИСА ПРОВЕРКИ ДОКУМЕНТОВ

2.1 Архитектура и структура системы

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

В системе выделяются несколько основных модулей: модуль аутентификации, модуль импорта документа, модуль проверки правил, модуль HTML-предпросмотра, модуль отчетности и административный модуль. Такое разделение упрощает дальнейшее развитие проекта и позволяет локализовать изменения при доработке отдельных функций. Общая архитектура веб-сервиса представлена на рисунке 1.

КлиентAPIБаза данных
ДокументыПравилаОтчеты

Рисунок 1 - Общая архитектура веб-сервиса проверки документов

2.2 Проектирование базы данных

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

Для обеспечения целостности данных используются связи между таблицами. Например, каждый документ должен иметь автора, дату загрузки и набор результатов проверки. История изменений позволяет восстановить последовательность обработки и определить, на каком этапе возникло нарушение. При проектировании структуры данных учитывались рекомендации по работе с базами данных [5].

9
Глава 2стр. 10

2.3 Пользовательские сценарии

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

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

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

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

10
Глава 3стр. 11

ГЛАВА 3. РЕАЛИЗАЦИЯ И ОЦЕНКА РЕЗУЛЬТАТА

3.1 Реализация основных модулей

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

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

3.2 Тестирование веб-сервиса

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

3.3 Оценка эффективности решения

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

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

11
Глава 3стр. 12

Таблица 2 - Оценка результата внедрения веб-сервиса

ПоказательДо внедренияПосле внедрения
Проверка структурыВручную по методичкеАвтоматически по набору правил
Поиск ошибокРазрозненные замечанияЕдиный диагностический отчет
ПредпросмотрТребует отдельного файлаДоступен сразу в HTML-интерфейсе
12
Заключениестр. 13

ЗАКЛЮЧЕНИЕ

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

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

В третьей главе описана реализация основных функций системы и проведена оценка результата. Разработанный веб-сервис позволяет загружать документ, проверять его структуру, показывать HTML-предпросмотр, хранить результаты диагностики и получать базовую аналитику по типовым ошибкам. Требования к интерфейсу и архитектуре решения дополнительно соотнесены с источниками [7, 8].

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

13
Источникистр. 14

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

  1. ГОСТ 7.32-2017. Отчет о научно-исследовательской работе. Структура и правила оформления. - М. : Стандартинформ, 2017.
  2. ГОСТ Р 7.0.100-2018. Библиографическая запись. Библиографическое описание. Общие требования и правила составления. - М. : Стандартинформ, 2018.
  3. Грекул В.И. Проектирование информационных систем : учебное пособие / В.И. Грекул, Г.Н. Денищенко. - М. : Интернет-Университет, 2022. - 304 с.
  4. Зуев С.В. Веб-приложения и сервисы : учебное пособие / С.В. Зуев. - СПб. : Питер, 2021. - 256 с.
  5. Кузнецов М.В. Базы данных в информационных системах : учебное пособие / М.В. Кузнецов. - М. : Юрайт, 2023. - 218 с.
  6. Орлов А.А. Разработка клиент-серверных приложений / А.А. Орлов // Прикладная информатика. - 2024. - № 1. - С. 55-63.
  7. Романов П.С. Проектирование пользовательских интерфейсов : учебное пособие / П.С. Романов. - М. : ДМК Пресс, 2022. - 192 с.
  8. Фаулер М. Архитектура корпоративных программных приложений / М. Фаулер ; пер. с англ. - М. : Вильямс, 2021. - 544 с.
14
Приложениестр. 15

ПРИЛОЖЕНИЕ А

Фрагмент структуры базы данных

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

Таблица А.1 - Основные таблицы базы данных веб-сервиса

ТаблицаНазначение
usersХранение данных пользователей и ролей доступа
documentsХранение загруженных документов и статусов проверки
diagnosticsХранение найденных нарушений и рекомендаций по исправлению
check_historyФиксация повторных проверок и изменений результата
15