ВКР по разработке информационной системы: структура, стек и что согласовать заранее

В «текстовой» ВКР результат — это анализ и выводы. Здесь результат — программа, а текст доказывает, что она сделана осознанно: обоснована, спроектирована и проверена. Комиссия оценивает и то и другое, поэтому слабое место в любой из частей тянет вниз всю оценку.

• Систему нужно показать на защите — вживую, на видео или скриншотами. Как именно, лучше решить заранее (об этом ниже).
• Текст должен объяснять решения: почему такой стек, такая модель данных, такие роли. «Так было удобнее» — не обоснование.
• Типичные темы — учёт и автоматизация: учёт рабочего времени, складской учёт, приём заявок, электронный документооборот, запись клиентов. Общая черта — несколько ролей пользователей и база данных.

Требования к структуре и объёму задаёт методичка вашей кафедры. Всё, что ниже, — типичная картина, которую стоит сверять с ней.

Чаще всего работа состоит из трёх глав. Объём — ориентир; у разных кафедр он заметно отличается, а приложения в него обычно не входят.

Удобно, когда задачи во введении один к одному соответствуют разделам глав: «проанализировать существующие решения» → раздел 1.2, «спроектировать модель данных» → раздел 2.3 и так далее. Тогда заключение пишется по тем же пунктам, а комиссия видит, что каждая задача решена.

Самая частая претензия к первой главе: «А чем ваша система лучше того, что уже есть?» Если сравнения нет, руководитель попросит его добавить, и тогда придётся переписывать обоснование, требования, а иногда и функции системы. Дешевле сделать его сразу.

1. Выберите 3–5 реальных решений для вашей задачи: коробочные продукты, облачные сервисы, модули крупных систем.
2. Определите критерии сравнения, важные для вашего объекта: стоимость, нужные функции, разграничение ролей, работа через браузер, возможность доработки, требования к инфраструктуре.
3. Сведите всё в таблицу и сделайте вывод: чего не хватает существующим решениям именно для вашего объекта.
4. Из этого вывода выведите требования к своей системе. Тогда глава 2 вытекает из главы 1, а не существует отдельно.

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

Для ВКР выигрывает не самый модный стек, а тот, который вы успеете довести до работающего состояния и сможете объяснить на защите. Частые варианты:

Обоснование стека в тексте строится так же, как сравнение аналогов: критерии, таблица, вывод. Если стек выбран «потому что знаю», это тоже аргумент — сформулируйте его как «сокращение сроков разработки и снижение рисков».

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

• Как система будет показана на защите: локально на ноутбуке, в Docker-контейнере, на сервере с доступом из интернета или видеозаписью. Сервер (VPS) и домен — это ежемесячные расходы; если руководитель ждёт именно их, лучше узнать об этом в начале, а не за неделю до защиты.
• Тип приложения: веб, настольное или мобильное. Если настольное — под какую операционную систему.
• Стек: есть ли у кафедры требования или запреты на языки и платформы.
• Роли пользователей и ключевые функции: что обязательно, а что «было бы хорошо».
• Нужно ли техническое задание по ГОСТ 34.602-2020 и в каком объёме.
• Какие схемы ожидаются: IDEF0 или DFD для процессов, UML (варианты использования, классы, последовательности), ER-диаграмма для базы данных.
• Нужен ли акт внедрения или справка от организации, если тема привязана к реальному предприятию.
• Требования к приложениям: листинги кода, руководство пользователя, шаблоны форм документов.

Главное правило — фиксировать договорённости письменно: в переписке, в почте, в комментариях к плану работы. Не для того, чтобы потом «ловить» руководителя, а чтобы у обоих была одна и та же картина. Если требования всё-таки меняются, у вас есть основание обсудить сроки и объём, а при серьёзном разногласии — аргументы для разговора с кафедрой.

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

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

1. Роли и права. Для учётной системы это, например, сотрудник, специалист по кадрам или учёту, руководитель, администратор. Для каждой роли — список функций и данных, которые она видит.
2. Сценарии использования: диаграмма вариантов использования и краткое описание ключевых сценариев («сотрудник подаёт заявление», «руководитель согласует», «формируется отчёт»).
3. Модель данных: ER-диаграмма, описание основных таблиц и связей. Здесь же — как обеспечивается целостность данных.
4. Архитектура: из каких частей состоит система (интерфейс, серверная часть, база данных) и как они взаимодействуют.
5. Интерфейс: макеты основных экранов для каждой роли.

Каждую схему подписывайте и объясняйте в тексте. Схема без пояснения выглядит как картинка «для объёма».

В третьей главе не нужно пересказывать код построчно. Покажите ключевые решения и результат:

• интерфейс основных экранов для каждой роли — со скриншотами и пояснениями;
• фрагменты кода только там, где решение нетривиально: разграничение доступа, расчёты, формирование отчётов. Полные листинги — в приложения;
• инструкцию пользователя: как войти, выполнить основные действия, получить отчёт;
• тестирование: таблица сценариев «действие — ожидаемый результат — фактический результат», включая ошибочный ввод и попытки доступа к чужим данным;
• итог тестирования: что работает, какие ошибки найдены и исправлены, что можно развивать дальше.

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

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

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

• Способ демонстрации, тип приложения и стек согласованы с руководителем письменно.
• В первой главе есть сравнение с аналогами, и из него выведены требования.
• Задачи во введении совпадают с разделами глав и выводами в заключении.
• Схемы подписаны, объяснены в тексте и соответствуют реальной системе.
• Выбор стека обоснован по критериям.
• Есть таблица тестирования основных сценариев, включая ошибочные.
• Приложения пронумерованы (А, Б, В), на каждое есть ссылка в тексте.
• Список источников оформлен по ГОСТ Р 7.0.100-2018, документация и стандарты указаны с датой обращения.
• Демонстрация отрепетирована, запасной вариант готов.