Целью преддипломной практики является получение практических навыков в области анализа, проектирования, разработки и тестирования веб-приложения для изучения дисциплины «Дискретная математика», а также закрепление теоретических знаний, накопленных в ходе обучения по направлению 38.03.05 «Бизнес-информатика» (профиль «Цифровая экономика»).
Для достижения поставленной цели в рамках практики были сформулированы следующие задачи:
изучение и анализ исходных данных: нормативно-правовых и организационных документов Университета, регламентирующих ИТ-инфраструктуру и практику;
выбор и обоснование бизнес-процесса, подлежащего автоматизации, и формализация его модели «AS IS»;
сбор и систематизация требований пользователей (преподавателей и студентов) к обучающему веб-приложению;
разработка технического задания на создание веб-сервиса с определением функциональных и нефункциональных требований;
проектирование архитектуры решения и структуры базы данных;
создание прототипов интерфейса и реализация серверной и клиентской части приложения;
подготовка и проведение тестирования программного продукта, оформление тест-плана, тест-кейсов и баг-репортов;
развертывание готового решения на бесплатном хостинге и оформление отчётной документации.
Преддипломная практика проходила с 12 мая по 8 июня 2025 г. на кафедре информационных систем Института бизнес-информатики ЧОУ ВО «МОСКОВСКИЙ УНИВЕРСИТЕТ ИМ. С.Ю. ВИТТЕ» (далее – Университет, МУИВ). Руководителем практики со стороны кафедры являлся доцент Блощук Андрей Алексеевич.
Для выполнения задач практики были использованы следующие источники:
официальная информация с корпоративного портала и раздела «Сведения об образовательной организации» Университета;
внутренние регламенты и методические пособия кафедры информационных систем;
стандарты и рекомендации по управлению проектами (PMBOK, ISO 21500);
документация по выбранным технологиям (Django, Flask, JavaScript-фреймворки);
учебные пособия и монографии по дискретной математике;
результаты опросов и интервью с потенциальными пользователями (преподавателями и студентами), подготовленные в ходе исследования требований.
В дальнейшем в работе будут подробно рассмотрены ход практики по каждому из этапов – от анализа исходных данных до тестирования и развёртывания готового веб-приложения.
АНАЛИЗ ОРГАНИЗАЦИИ И ИТ-ИНФРАСТРУКТУРЫ
Исходные данные для отчёта
Тема выпускной квалификационной работы: «Разработка обучающего веб-приложения для изучения дисциплины «Дискретная математика».
Процесс, рассматриваемый в рамках практики: обучение дисциплине «Дискретная математика» посредством веб-ресурса.
Подразделение, отвечающее за реализацию данного процесса: кафедра информационных систем Института бизнес-информатики.
Ссылка на git-репозиторий проекта:
https://gitflic.ru/project/denis_karakhtanov/discrete-math-edu
Учётные данные для тестирования (роль «студент»):
Логин: akuznetsov@uni.ru, пароль: StudPass123
Логин: eorlova@uni.ru, пароль: StudPass123
Учётные данные для тестирования (роль «преподаватель»):
Логин: petrov, пароль: 7B6-NP7-LKj-v2d
Учётные данные для тестирования (роль «администратор»):
Логин: user, пароль: 12345678
Анализ структуры Университета и нормативно-правовой документации
Организационно-штатная структура
Согласно официальным данным Университета [1, 2], высшим органом управления является Единственный Учредитель – АО «Современное образование», далее функционируют: Ректор, Ректорат, Ученый совет, после чего –:
Институты и факультеты (в том числе Институт бизнес-информатики, на котором базируется кафедра информационных систем) [1];
Департаменты центрального аппарата Университета, в том числе:
Департамент информационных технологий, возглавляемый Проректором по ИТ (Ставцев С. Б.) [1];
Департамент электронного обучения и сопровождения, ответственный за поддержку дистанционных образовательных платформ (рук. – Калашникова М. В.) [1];
Структурные подразделения при Институтах и факультетах (кафедры, лаборатории и пр.).
Ответственное подразделение
По индивидуальному заданию практика проходит на кафедре информационных систем Института бизнес-информатики. Однако управление и техническую поддержку информационных решений обеспечивает Департамент информационных технологий – именно он курирует разработку и внедрение новых веб-сервисов, предоставляет права на размещение на внутренних и внешних хостингах, а также обеспечивает выделение серверных ресурсов и СУБД [1, 2]. Организационная структура с фокусом на ответственное подразделение приведена на рисунке 1:
Рисунок 1 – Организационная структура
Нормативно-правовое обеспечение процесса
Регламентация разработки и внедрения программных продуктов на уровне Университета осуществляется следующими документами (раздел «Документы» сайта Университета) [2-5]:
Устав Университета – определяет общую структуру и полномочия органов управления;
Положение об информационных технологиях и автоматизированных системах управления – устанавливает правила разработки, тестирования и внедрения ПО;
Методические указания по прохождению преддипломной практики – регламентируют этапы и отчётность практиканта;
Положение о защите информации и политике безопасности ИТ – определяет требования к разграничению доступа и защите данных.
Порядок реализации процесса «Разработка обучающего веб-приложения»
Процесс будет реализован в следующем порядке выполнения этапов:
Постановка задачи и согласование. Выдача студенту индивидуального задания руководителем практики (кафедра информационных систем). Утверждение темы и требований у заведующего кафедрой и Проректора по ИТ;
Сбор и формализация требований. Интервью с конечными пользователями (преподаватели, студенты). Анализ нормативных требований и технических ограничений;
Проектирование решения. Разработка моделей «AS IS» и «TO BE» бизнес-процесса. Проектирование архитектуры и БД;
Разработка и тестирование. Итеративная реализация функционала в Git-репозитории. Проведение модульного, интеграционного и системного тестирования по утверждённому тест-плану;
Внедрение и сопровождение. Размещение приложения на бесплатном хостинге. Передача инструкций по эксплуатации и учетных данных. Поддержка и исправление выявленных дефектов.
В результате соблюдения данного порядка обеспечивается полное покрытие жизненного цикла ПО – от анализа требований до ввода в эксплуатацию.
Анализ ИТ-инфраструктуры выбранного подразделения
Для успешной разработки и развёртывания обучающего веб-приложения крайне важно понимать, в каких условиях будет функционировать система – какие аппаратные ресурсы доступны, как организована сеть, на каком программном обеспечении базируются существующие сервисы. Далее представлен обзор материально-технического обеспечения и программной платформы кафедры информационных систем, отвечающей за реализацию проекта [1].
Анализ материально-технического обеспечения
Кафедра информационных систем располагает небольшим серверным помещением со стойкой для вычислительного оборудования. На ней установлены два основных физических сервера:
Сервер разработки: процессор Intel Xeon E5-2620 v4 (8 ядер, 16 потоков), 64 ГБ ОЗУ, RAID-массив из четырёх SSD по 480 ГБ с высокой производительностью ввода-вывода. Используется для сборки и тестирования внутренних стендов, развёртывания промежуточных версий приложения;
Сервер продуктивной среды: процессор Intel Xeon E5-2630 v4 (10 ядер, 20 потоков), 128 ГБ ОЗУ, RAID-10 из 4 HDD 2 ТБ для хранения резервных копий и данных пользователей. На нём развёрнут внешний веб-сервис и СУБД, доступные пользователям через публичный адрес;
Сетевое оборудование представлено управляемым коммутатором Cisco Catalyst 2960 и маршрутизатором Cisco ISR 4321 с резервными каналами подключения к сети Internet и VPN-доступом для удалённой работы. Все серверы и сетевые устройства защищены системой бесперебойного питания APC Smart-UPS 1500VA, что исключает потерю данных при кратковременных отключениях электричества;
Для тестирования мобильного отображения приложений в лабораториях кафедры имеются ноутбуки на ОС Windows и Linux, настольные ПК с последними версиями браузеров (Chrome, Firefox, Edge, Яндекс.Браузер) и несколько планшетов и смартфонов на Android и iOS. Это позволяет убедиться в корректности рендеринга и адаптивности интерфейса на различных устройствах.
Анализ программного обеспечения
На уровне серверов и рабочих станций в инфраструктуре кафедры задействованы следующие программные компоненты:
Операционные системы: на серверах – Ubuntu Server 22.04 LTS с ядром Linux 5.15, что обеспечивает стабильность и долгосрочную поддержку безопасности;
На рабочих станциях – Windows 10 Pro, Ubuntu Desktop 22.04 LTS;
Веб-сервер и платформа исполнения: Nginx 1.22 в качестве обратного прокси и сервера статических файлов; Gunicorn 20.x для запуска приложения на Python/Django; поддерживается также PHP 8.1 (для вспомогательных модулей и тестирования совместимости);
СУБД: PostgreSQL 14 – основная база данных для хранения учебного контента и пользовательских данных; MySQL 8 – используется для тестирования миграций и резервного анализа объёмов таблиц;
Средства разработки и контроля версий: Python 3.10, Django 4.1, Flask 2.2 для прототипирования сервисов; Node.js 18 и npm для фронтенд-сборки (Webpack, Babel); Git 2.38
(репозиторий проекта расположен на GitFlic, https://gitflic.ru/project/denis_karakhtanov/discrete-math-edu);
Инструменты CI/CD и контейнеризации: GitHub Actions (для внешнего репозитория) – сборка, тестирование и развёртывание на staging-сервер; Docker 24 для локального тестирования и упаковки сервисов в контейнеры.
Такой набор аппаратных и программных средств позволяет реализовать надёжную, масштабируемую и безопасную среду для разработки, тестирования и эксплуатации веб-приложения по изучению дискретной математики.
Обоснование выбора бизнес-процесса для автоматизации (модель «AS IS»)
Предметом автоматизации является процесс обучения дисциплине «Дискретная математика» посредством веб-ресурса. До внедрения нового специализированного приложения («AS IS») студенты и преподаватели используют разрозненный набор инструментов (рисунок 2) [2, 6]:
Очные лекции и семинары. Преподаватель читает лекции в аудитории, студенты делают конспекты, задают вопросы устно;
Платформа LMS (Электронный университет). Преподаватель загружает конспекты и презентации в формате PDF/PowerPoint. Студенты скачивают материалы, решают домашние задания вручную, фотографируют работу и загружают сканы в систему;
Дополнительная коммуникация. Студенты задают уточняющие вопросы в общем чате или по электронной почте. Преподаватель отправляет разъяснения фрагментарно и не централизованно;
Рисунок 2 – Бизнес-процесс КАК ЕСТЬ
Проверка домашних заданий. Преподаватель вручную проверяет решения, отмечает ошибки, выставляет оценки в LMS;
Доступ к дополнительным ресурсам. Студенты ищут тематические видео или сторонние учебники в PDF, переключаясь между разными платформами.
На диаграмме активностей отражены четыре ключевых участника процесса:
Студент – инициирует обучение, выполняет задания и получает обратную связь.
Система (веб-ресурс) – обеспечивает хранение контента, автоматические проверки, уведомления и учёт прогресса.
Преподаватель – обеспечивает методическую часть: загружает материалы, проверяет задания и оставляет комментарии.
Администратор – управляет пользователями, курсами и правами доступа, поддерживая корректную работу системы.
Такая структура бизнес-процесса приводит к ряду проблем:
Фрагментация контента – отсутствует единый интерфейс и логика последовательного прохождения тем;
Ручная проверка – высокая нагрузка на преподавателя и задержки в обратной связи;
Отсутствие интерактивности – ограниченность автоматических тестов, визуализаций понятий, поток работы распылён между разными сервисами;
Низкая прозрачность процесса – затруднён учёт прогресса и анализ трудностей студентов;
Анализ требований пользователей к обучающему приложению
При подготовке технического задания ключевым этапом стало выяснение реальных потребностей будущих пользователей – студентов, преподавателей и администраторов [7, 8]. Для этого были проведены следующие мероприятия:
Интервью с преподавателями (3 человека, специализация – дискретная математика) Уточнялись пожелания по структуре курса, формам контроля знаний, возможностям комментирования и аналитики прогресса;
Опрос студентов (20 респондентов, группы 1–3 курса). Выявлены основные сложности при работе с существующей LMS – неудобная навигация, фрагментарная подача материала, отсутствие единых правил оформления заданий и долгий ручной разбор работ;
Анализ практик работы администратора (беседа с ИТ-администратором кафедры). Определены требования к учётным записям, разграничению прав и настройке курсов без привлечения разработчиков.
На основе собранных данных сформированы две группы требований: функциональные и нефункциональные.
Функциональные требования:
Навигация и доступ к разделам курса – студенты должны иметь интуитивно понятное меню с «хлебными крошками», позволяющее быстро переходить между теорией, примерами и задачами;
Интерактивные задания – реализация автоматической проверки тестов, задач на графы и логические выражения с мгновенной обратной связью;
Личный кабинет студента – просмотр прогресса по каждому модулю, история сдачи заданий и комментарии преподавателя;
Панель преподавателя – загрузка материалов (PDF, формулы LaTeX), просмотр статистики студентов, возможность ручной проверки сложных заданий и добавления комментариев;
Роли и права доступа – минимум три уровня – администратор, преподаватель, студент – с разнообразием функционала и ограничением доступа к администрированию системы;
Формирование отчётов – экспорт результатов в .xlsx и .docx для ведения учёта и аккредитационных процедур.
Нефункциональные требования:
Удобство использования (usability) – интерфейс должен быть адаптивным, с минимальным количеством кликов для основных действий и подсказками при вводе сложных математических выражений;
Производительность – ответ сервера – не более 300 мс для базовых операций (загрузка страницы, проверка теста);
Надёжность и отказоустойчивость – сохранение выполненных заданий при кратковременных разрывах связи, автоматическое восстановление после сбоев;
Безопасность – защищённые протоколы HTTPS, хранение паролей в хешированном виде и разграничение прав на уровне ролей;
Мультибраузерность и кроссплатформенность – корректное отображение и работа в последних версиях Chrome, Firefox, Edge, на десктопах и мобильных устройствах.
Таким образом, анализ требований позволил сформулировать чёткий и исчерпывающий список требований, гармонизированный с реальными сценариями использования – обучение может вестись последовательно: от ознакомления с материалом до получения оценки без переключения между разными системами и с минимальной загрузкой преподавателей.
Перечень служебных поручений и задач при прохождении производственной практики
В соответствии с индивидуальным заданием и профилем подготовки руководителем практики на кафедре информационных систем были сформулированы следующие служебные поручения и задачи:
Изучение нормативно-правовой базы и внутренних регламентов. Ознакомиться с Уставом Университета, положениями по ИТ-инфраструктуре и внутренними регламентами кафедры информационных систем. Цель – понять порядок согласования технических решений и требования к оформлению отчётных документов;
Сбор и формализация требований пользователей. Провести интервью и опросы среди преподавателей и студентов по дисциплине «Дискретная математика», систематизировать результаты в виде списка функциональных и нефункциональных требований. Результат – документ «Спецификация требований»;
Разработка технического задания на веб-ресурс. На основании формализованных требований составить ТЗ, включающее цели и назначение системы, характеристики объектов автоматизации, функциональные модули и план работ;
Проектирование архитектуры решения и базы данных. Создать модель «AS IS» и «TO BE» бизнес-процесса, подготовить архитектурную спецификацию веб-сервиса, разработать инфологическую ER-диаграмму и схему физического размещения таблиц СУБД;
Настройка и ведение репозитория разработки. Организовать проект в GitFlic: создать структуру веток, прописать правила именования веток и коммитов, обеспечить не менее 50 итеративных коммитов в ходе практики;
Разработка прототипа пользовательского интерфейса. Подготовить эскизы макетов основных страниц (главная, модуль курса, личный кабинет, панель преподавателя) и провести их согласование с руководителем;
Реализация функциональных модулей. Разработать фронтенд (HTML/CSS/JavaScript) и бэкенд (Django/Flask) части веб-приложения: регистрацию и авторизацию пользователей, управление курсами, проверку заданий, генерацию документов (.docx, .xlsx);
Подготовка тестовой документации и проведение тестирования. Сформировать тест-план, разработать не менее 10 тест-кейсов, провести позитивное и негативное, smoke- и регрессионное тестирование, оформить баг-репорты и устранить дефекты;
Развертывание и презентация результата. Разместить готовый веб-ресурс на бесплатном хостинге, подготовить инструкции для администраторов и пользователей, провести демонстрацию работы приложения перед руководителем практики.
Техническое задание на разработку веб-сервиса автоматизации контроля знаний
Техническое задание выполнено в соответствии с требованиями ГОСТ 34.602-2020 «Техническое задание на автоматизированную систему» [9] и носит название «ТЗ на разработку автоматизированной системы контроля знаний по дисциплине «Дискретная математика» посредством веб-ресурса».
Общие сведения
Полное наименование АС: Автоматизированная система контроля знаний по дисциплине «Дискретная математика».
Условное обозначение АС: «АС-КЗ-ДМ».
Шифр темы: при регистрации ВКР не предусмотрен.
Заказчик: Кафедра информационных систем Института бизнес-информатики Университета им. С. Ю. Витте.
Разработчик: студент Карахтанов Д. А. в рамках преддипломной практики.
Документы-основания:
Индивидуальное задание преддипломной практики (утв. заведующим кафедрой, 12.05.2025);
Положение об ИТ-инфраструктуре Университета (утв. проректором по ИТ, 01.09.2024);
ГОСТ 34.602-2020 «Техническое задание на автоматизированную систему» (утв. Росстандартом, 2020).
Плановые сроки выполнения работ:
Начало: 12 мая 2025 г.;
Окончание: 08 июня 2025 г.
Финансирование: работы выполняются в рамках учебной деятельности студента.
Цели и назначение автоматизированной системы
Цели создания АС:
Ускорение обратной связи – среднее время получения студентом результатов автоматической проверки должно быть не более 5 секунд;
Повышение точности оценки – уровень соответствия автоматической проверки решения теста и эталонного решения – не менее 98 %;
Снижение ручной нагрузки преподавателя – доля автоматизированных проверок должна составлять не менее 70 % от общего числа заданий;
Аналитика прогресса – система должна генерировать отчёты о результатах обучения в формате .xlsx и .docx по каждому студенту и группе за менее чем 10 секунд.
Критерии оценки достижения целей определяются приёмочными испытаниями (раздел 1.7.7).
Назначение АС – система предназначена для автоматизации контроля знаний студентов по дисциплине «Дискретная математика» посредством веб-ресурса: управление учебными модулями, проведение интерактивных тестов, хранение результатов, предоставление преподавателю инструментов для ручной проверки и анализа.
Характеристика объектов автоматизации
Объект автоматизации – процесс контроля знаний студентов по дисциплине «Дискретная математика» через веб-приложение.
Условия эксплуатации:
Окружающая среда – аудиторные и удалённые рабочие места студентов и преподавателей, доступ через браузеры Chrome, Firefox, Edge на ОС Windows, Linux, macOS, а также мобильные браузеры.
Сети – корпоративная локальная сеть Университета и Интернет-канал пропускной способностью не менее 100 Мбит/с.
Аппаратные требования – сервер на Ubuntu Server 22.04 LTS, не менее 8 ГБ ОЗУ и 100 ГБ дискового пространства.
Требования к автоматизированной системе
1.7.4.1 Требования к структуре АС
Система строится по трёхслойной архитектуре – клиентский (браузер), серверный (API на Django/Flask), уровень хранения данных (PostgreSQL).
Интерфейсы должны быть RESTful и поддерживать JSON.
1.7.4.2 Требования к функциям АС
Регистрация и аутентификация пользователей трёх ролей: студент, преподаватель, администратор.
Создание и редактирование тестов преподавателем (вопросы с множественным выбором, задачи на графы, логические выражения).
Автоматическая проверка формализуемых типов заданий и ручная проверка свободного текста.
Отображение студенту результатов с комментариями и статистикой прогресса.
Экспорт отчётов в .docx и .xlsx.
1.7.4.3 Требования к видам обеспечения АС
Программное обеспечение: Python 3.10, Django 4.1 или Flask 2.2, PostgreSQL 14.
Технологическое обеспечение: сервер Ubuntu 22.04 LTS, Nginx 1.22, Gunicorn 20.x.
Методическое обеспечение: учебные программы по дискретной математике и шаблоны отчётности.
1.7.4.4 Общие технические требования
Время отклика сервера на базовые запросы – не более 300 мс.
Надёжность: процент успешных операций за сутки – не менее 99 %.
Безопасность: шифрование HTTPS/TLS, хранение паролей с использованием bcrypt, контроль доступа по ролям.
Состав и содержание работ
Этапы разработки автоматизированной системы
Организация разработки – утверждение ТЗ, назначение ответственных;
Исходные данные – индивидуальное задание, спецификация требований, UML-модели;
Документация по окончании этапов – промежуточные отчёты, прототипы интерфейса, тестовый отчёт;
Экспертиза ТД – проверка соответствия ГОСТ 34.602-2020;
Макеты и испытания – прототипы страниц и интерактивных элементов, методики юзабилити-тестирования;
План совместных работ – согласование с руководителем практики;
Гарантийные обязательства – правка ошибок в течение 1 месяца после сдачи;
ТЭО и метрологическое обеспечение – расчёт ресурсоёмкости и проверка точности автоматической проверки.
Контроль и приёмка автоматизированной системы
Виды испытаний: модульные, интеграционные, системные, приёмочные.
Методы: функциональное тестирование, регрессионное тестирование, нагрузочное тестирование (см. раздел 4).
Приёмка: состав комиссии – руководитель практики, заведующий кафедрой, представитель ИТ-департамента; оформление акта приёмки на соответствие требованиям ТЗ.
Подготовка объекта автоматизации к внедрению
Организационные мероприятия: выделение серверных ресурсов, настройка хостинга, обучение администраторов.
Штатные мероприятия: назначение ответственных за поддержку, документирование процедур.
Обучение персонала: проведение инструктажей для преподавателей и администраторов по работе с системой.
Требования к документации
Перечень документов: ТЗ (6 экз.), руководство пользователя (10 экз.), руководство администратора (5 экз.), отчёт о тестировании (3 экз.).
Форматы: А4, электронные версии в PDF; использование ЕСКД и ЕСПД для схем и диаграмм.
Дополнительно: шаблоны отчётов по аккредитации и методические указания.
Источники разработки
Индивидуальное задание преддипломной практики (12.05.2025).
ГОСТ 34.602-2020 «Техническое задание на автоматизированную систему».
Спецификация требований к обучающему веб-ресурсу (раздел 1.5 отчёта).
Методические пособия по дискретной математике и документация Django 4.1, Flask 2.2, PostgreSQL 14.
Выводы по разделу 1
В результате выполнения раздела 1 отчёта – анализа организационной структуры, ИТ-инфраструктуры кафедры и формализации требований к обучающему веб-ресурсу – были достигнуты следующие ключевые результаты:
Проведён детальный анализ административно-организационной структуры Университета и выявлено ответственное подразделение (кафедра информационных систем), что обеспечило понимание порядка согласования и утверждения решений в рамках проекта;
Выполнен обзор материально-технического обеспечения и программной платформы кафедры, что позволило определить оптимальные аппаратные и программные средства для разработки и развёртывания веб-приложения;
Систематизированы требования пользователей (студентов, преподавателей, администраторов) по функционалу и нефункциональным характеристикам приложения, на их основе составлена спецификация требований и техническое задание;
Сформировано техническое задание на разработку АС «Автоматизированная система контроля знаний по дисциплине «Дискретная математика»» (АС-КЗ-ДМ), что стало основой для планирования, проектирования и последующей реализации решения.
Полученные в рамках раздела 1 профессиональные компетенции приведены в табл. 1:
Таблица 1
Выводы по разделу 1
ПРОЕКТИРОВАНИЕ ВЕБ-СЕРВИСА
Модель «TO BE» и оптимизация бизнес-процесса
В разделе 1 мы выявили основные узкие места текущего процесса обучения дискретной математике («AS IS»):
разрозненность материалов;
длительная ручная проверка;
отсутствие централизованной аналитики.
Рисунок 3 – Модель бизнес-процесса КАК ДОЛЖНО БЫТЬ
Модель «TO BE» предлагает объединить все этапы обучения в едином веб-ресурсе с интегрированными инструментами контента, интерактивной проверки и административного контроля.
Ключевые улучшения процесса:
Единый вход и навигация. Студент и преподаватель работают в одном интерфейсе вместо нескольких платформ;
Интерактивное изучение. Теоретические модули сопровождаются встроенными визуализациями и примерами прямо в браузере;
Автоматическая проверка. Задания с формализуемым ответом проверяются мгновенно – преподавателю остаётся обрабатывать лишь свободноформатные ответы;
Обратная связь и аналитика. Результаты и комментарии отображаются сразу в личном кабинете, а администратор получает сводные отчёты;
Формирование отчётов. Возможность экспортировать результаты в .docx/.xlsx одним кликом.
UML-диаграмма активностей модели «TO BE», иллюстрирующая оптимизированный процесс обучения приведена на рисунке 3.
Архитектурная спецификация компонентов веб-сервиса
В этой секции представлена иерархия функций разрабатываемого веб-приложения и её компонентная модель, иллюстрирующая взаимодействие ключевых подсистем.
Дерево функций (рисунок 4) иллюстрирует, какие именно возможности должна предоставить система пользователям: от базовых операций регистрации и авторизации до специализированных модулей проверки, генерации отчётов и уведомлений. При этом каждый узел дерева напрямую соотносится с одним или несколькими компонентами серверной части, показанными на UML-диаграмме (рисунок 5):
Рисунок – Дерево функций
Ветвь «Регистрация и аутентификация» реализуется компонентом Auth Module, который через REST-интерфейс обрабатывает запросы на вход, выход, восстановление пароля и проверяет права доступа;
Функции «Личный кабинет студента», «Панель преподавателя» и «Панель администратора» реализуются набором компонентов API-сервера:
Content Module отвечает за выдачу учебных материалов и управление структурой курсов;
Test Engine обрабатывает запросы на проведение тестов, запускает автоматическую проверку решений и сохраняет результаты;
Report Generator формирует сводные отчёты в формате .docx/.xlsx по данным, полученным из СУБД;
Notification Service через WebSocket информирует пользователя о новых результатах или комментариях;
Слой доступа к данным на диаграмме представлен базой PostgreSQL для структурированных записей (пользователи, курсы, результаты) и файловым хранилищем File Storage для контента (PDF, изображения, загруженные студентами сканы).
Рисунок 5 - UML-диаграмма компонентов АС
На диаграмме:
Web Client (React/Vue.js) обращается к API по REST и WebSocket;
API Server разделён на компоненты, каждый из которых отвечает за свой функционал;
PostgreSQL и File Storage служат системами хранения данных.
Таким образом, дерево функций задаёт «что» должна уметь система, а компонентная диаграмма – «как» эти функции разделены на взаимосвязанные подсистемы. Пользовательский фронтенд обращается к каждому компоненту через заданные интерфейсы, а серверные компоненты взаимодействуют с единым хранилищем данных. Такое разделение обеспечивает гибкость в развитии проекта – при появлении новых требований достаточно расширить соответствующий компонент или добавить новый, не затрагивая всю архитектуру целиком.
Составление плана разработки
В основе плана разработки лежит поэтапное и итеративное выполнение работ над веб-сервисом с учётом сроков преддипломной практики, согласования с руководителем и промежуточного тестирования. В качестве методологии выбран гибрид Agile – ежедневные короткие итерации с итоговым демо-просмотром каждые 3–4 дня (табл. 2).
Таблица 2
Этапы разработки АС
Проводятся ежедневные стендапы (5–10 мин) между студентом и руководителем практики для обсуждения прогресса и проблем. Итеративные демо каждые 3–4 дня с представлением текущего результата и сбором обратной связи. Управление версиями: все изменения фиксируются в GitFlic, не менее 50 коммитов, с подробными комментариями к каждому этапу.
Такая структура плана обеспечивает прозрачность работ, чёткое распределение ответственности и своевременную верификацию каждого этапа.
Настройка репозитория управления проектом
В исходных данных (п. 1.1) указана ссылка на удалённый репозиторий проекта: GitFlic: https://gitflic.ru/project/denis_karakhtanov/discrete-math-edu
Ниже приведён пошаговый процесс настройки локального Git-репозитория и подключения его к удалённому репозиторию на GitFlic (аналогично можно действовать для GitHub) на основе официальной документации https://gitflic.ru/help [10, 11].
Установка и первичная настройка Git:
Установить Git. Windows: скачать установщик с https://git-scm.com/download/win и следовать мастеру установки.
Настроить глобальные параметры:
git config --global user.name "Denis Karakhtanov"
git config --global user.email " 70197197@online.muiv.ru"
Проверить версию и конфигурацию:
git --version
git config --list
Создание и инициализация локального репозитория:
Перейти в корневую папку проекта
cd ~/projects/discrete-math-edu
Инициализировать локальный репозиторий
git init
Создать файл .gitignore (например, с помощью шаблона для Python/Django):
__pycache__/
*.py[cod]
.venv
node_modules/
dist/
*.log
Это предотвратит попадание в коммиты временных и конфиденциальных файлов.
Первичный коммит
git add .
git commit -m "Инициализация проекта: добавлен .gitignore и начальная структура"
Подключение к удалённому репозиторию на GitFlic:
Создать проект на GitFlic. Зайти на https://gitflic.ru, войти в учётную запись и нажать «Новый проект». Указать название discrete-math-edu, описание и права доступа (публичный/приватный).
Добавить удалённый адрес и отправить
git remote add origin https://gitflic.ru/project/denis_karakhtanov/discrete-math-edu.git
git push -u origin master
Организация ветвления и коммит-гайдлайн
Основные ветки
master (или main) – стабильная версия, развёрнутая в продакшн.
develop – интеграционная ветка для текущей разработки.
Фиче-ветки
Для каждой новой функциональности создаётся feature-ветка по шаблону:
feature/<описание-функционала>
Например: feature/auth-module.
Коммит-сообщения
Использовать формат: <тип>(<область>): <краткое описание>
Типы: feat – новая возможность, fix – исправление, docs – документация, refactor, test, chore.
Пример:
feat(auth): добавить эндпоинт восстановления пароля
Настройка CI/CD (опционально)
Для автоматической проверки качества кода и развёртывания можно подключить GitFlic CI по аналогии с GitHub Actions:
Создать файл .gitflic-ci.yml в корне проекта.
Определить этапы сборки, тестирования и деплоя (см. документацию https://gitflic.ru/help/ci).
Активировать CI в настройках репозитория на GitFlic.
Поддержка репозитория в ходе разработки
Регулярно делать git pull перед началом работы, чтобы синхронизироваться с удалённым репозиторием.
Выполнить не менее 50 коммитов в период практики, отражающих итеративное развитие проекта.
Писать понятные и информативные сообщения к коммитам и Pull Request (или Merge Request), чтобы упростить код-ревью руководителю.
В результате этих настроек обеспечивается централизованное хранение кода, удобная кооперация с руководителем практики, прозрачность историй изменений и возможность развёртывания каждой версии приложения.
Проектирование базы данных
Проектирование базы данных начинается с анализа предметной области – автоматизированного контроля знаний студентов по дисциплине «Дискретная математика» посредством веб-ресурса. В системе задействованы три ключевые роли (студент, преподаватель, администратор), образовательный контент разбит на курсы и модули, проверка знаний реализуется через тесты и задания, а результаты фиксируются для последующей отчётности [13].
Инфологическое проектирование БД (ER-диаграмма)
Основные сущности:
Student – студент, проходящий курс; хранит ФИО, логин, пароль, контактные данные;
Instructor – преподаватель, создающий и проверяющий задания; содержит ФИО, логин, пароль, специализацию;
Course – учебный курс («Дискретная математика»); описывает название, описание, дату начала/окончания;
Module – тематический модуль внутри курса; содержит название, порядок следования, ссылку на материалы;
Test – тест или задание в рамках модуля; хранит тип (авто/ручной), количество вопросов, максимальный балл.
Дополнительные сущности:
Question – отдельный вопрос теста; содержит текст вопроса, варианты ответов или шаблон проверки;
Submission – отправленная студентом работа; фиксирует время отправки, ответ, статус проверки;
Result – результат проверки (оценка, комментарии); связывает Submission и Instructor;
Role – роль пользователя (студент, преподаватель, администратор) для разграничения доступа;
Report – сформированный отчёт по результатам обучения для группы или отдельного студента.
Пользователь (Student) авторизуется и выбирает Course. Внутри курса он проходит Module, запускает Test и создаёт Submission. Автоматический или ручной модуль проверки (Instructor) формирует Result. Администратор управляет пользователями и генерирует Report на основании накопленных результатов.
Визуальное представление инфологической модели приведено ниже (рисунок 6):
Рисунок 6 – Инфологическая модель данных
Логическое проектирование БД (уточнённая ER-диаграмма)
На этапе логического проектирования к каждой сущности добавляются её реквизиты (атрибуты), а связи, в которых имеются собственные реквизиты, превращаются в промежуточные таблицы-ассоциативы (табл. 3, рисунок 7) [12-14].
Таблица 3
Сущности и описание полейы
Рисунок 7 – Уточненная ER-диаграмма (логическая модель)
Разработка схемы данных
На основании уточнённой ER-диаграммы формируется схема базы данных – перечень таблиц и их взаимосвязей. На схеме явно указаны первичные (PK) и внешние ключи (FK), а также типы связей (рисунок 8).
Таблица 3
Перечень таблиц и связи
Рисунок 8 – Схема данных
Enrollment реализует связь «Student–Course» (многие–к–многим) с атрибутами enrollment_date и completion_status.
Все остальные связи – «один–к–многим».
Физическое проектирование БД
2.5.4.1. Составление реляционных отношений
Ниже приведён список таблиц (табл. 4-14), которые будут созданы в PostgreSQL, с указанием колонок, типов данных и основных ограничений (PK – первичный ключ, FK – внешний ключ, NN – NOT NULL, UQ – UNIQUE).
Таблица 4
Сущность Student
Таблица 5
Сущность Instructor
Таблица 6
Сущность Role
Таблица 7
Сущность Course
Таблица 8
Сущность Module
Таблица 9
Сущность Test
Таблица 10
Сущность Question
Таблица 11
Сущность Submission
Таблица 12
Сущность Result
Таблица 13
Сущность Report
Таблица 14
Сущность Enrollment
2.5.4.2. Нормализация полученных отношений
Нормализация – это процесс структурирования отношений (таблиц) базы данных с целью устранения избыточности и аномалий обновления. Обычно рассматривают следующие формы [13, 14]:
Первая нормальная форма (1NF) – все атрибуты атомарны (каждое поле содержит неделимое значение).
Вторая нормальная форма (2NF) – отношение находится в 1NF и каждый неключевой атрибут полностью зависит от всего ключа, а не от его части.
Третья нормальная форма (3NF) – в 2NF и отсутствуют транзитивные зависимости неключевых атрибутов от ключевых.
Нормальная форма Бойса–Кодда (BCNF) – усиленная 3NF: каждая функциональная зависимость определяется ключом.
Наша схема из раздела 2.5.4.1 уже удовлетворяет требованиям 1NF–3NF:
1NF: все поля атомарны (нет списков или повторяющихся групп);
2NF: во всех таблицах первичный ключ либо простой (UUID), либо для ассоциативной таблицы Enrollment мы выделили искусственный ключ enrollment_id, поэтому никаких частичных зависимостей нет;
3NF: транзитивных зависимостей нет, так как справочные данные (роль пользователя) вынесены в отдельную таблицу Role, а связь «студент→курс» оформлена через Enrollment.
Проверка на BCNF показывает, что во всех таблицах каждый детерминант ключа – потенциальный ключ таблицы [15]. Например, в таблице Submission ни один неключевой атрибут не определяет другие атрибуты, а все функциональные зависимости (например, submission_id → student_id, test_id, …) исходят от ключа.
Таким образом, дальнейшей декомпозиции для устранения избыточности не требуется – все отношения приведены к BCNF. В результате нормализации структура данных остаётся без изменений по количеству отношений, но уверенность в корректности проекта повышается: каждая таблица однозначно отражает одну сущность или ассоциацию, без скрытых зависимостей.
2.5.4.3. Описание групп пользователей и прав доступа
При проектировании базы данных важно не только сама структура таблиц, но и разграничение прав для различных ролей системы. В АС-КЗ-ДМ выделены три основные группы пользователей: Администратор, Преподаватель и Студент. Для каждой группы смоделирована отдельная «внешняя схема» (набор таблиц и операций с ними), определяющая, какие данные и каким образом доступны пользователю.
