Skip to content
Danil Otmakhov edited this page Mar 25, 2026 · 13 revisions

Веб-приложение для записи студентов на проекты

1. Основная проблема

В рамках учебных курсов (например, ОПРПО, УПРПО, ВвНСУБД) студентам необходимо объединяться в команды и распределяться по проектам. На практике этот процесс сопровождается рядом проблем:

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

Проект решает проблему автоматизации, прозрачности и управляемости процесса распределения студентов по проектам.


2. Цель проекта

Разработать веб-приложение, которое:

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

3. Категории пользователей и их потребности

3.1 Студент

Цель: попасть на интересный проект в составе удобной команды.

Что важно студенту:

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

Студент ориентирован на:

  • удобство,
  • прозрачность,
  • своевременные уведомления,
  • честность распределения.

3.2 Администратор

Цель: организовать и корректно выполнить распределение с учетом ограничений.

Что важно администратору:

  • управление курсами;
  • редактирование описания, дедлайнов, размера команд, отображения курса;
  • управление списком проектов;
  • контроль заполненности проектов;
  • настройка параметров распределения (размер команд, сроки);
  • запуск алгоритма распределения;
  • визуализация текущих результатов;
  • выявление проблем (нераспределенные студенты, пустые проекты);
  • возможность корректировки результатов;
  • просмотр сформированных команд;
  • подтверждение или отклонение обменов.

Администратор ориентирован на:

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

4. Анализ требований

4.1 Функциональные требования

Управление курсами

  • Создание, редактирование, удаление курсов.
  • Каждый курс — отдельная сущность (например, «ОПРПО 2026»).
  • Настройка дедлайнов и параметров.

Авторизация и роли

  • JWT-аутентификация.
  • Роли: студент, администратор.
  • Разграничение прав доступа.

Импорт данных

  • Импорт списка студентов из CSV.
  • Импорт списка проектов из CSV.
  • Валидация данных при загрузке.

Формирование команд

  • Отправка запроса на объединение.
  • Подтверждение или отклонение запроса.
  • Создание команды.

Выбор проектов

  • Отправка заявки на выбранные проекты.
  • Сохранение предпочтений в системе.

Автоматическое распределение

  • Запуск вручную или по расписанию.
  • Учет ограничений (размер команды, дедлайны).
  • Назначение нераспределенных студентов.

Обмен проектами

  • Инициация обмена между командами.
  • Подтверждение администратором.
  • Обновление распределения после подтверждения.

Визуализация

  • Дашборд:
    • список команд;
    • назначенные проекты;
    • заполненность;
    • нераспределенные студенты;
    • статистика по проектам.

4.2 Нефункциональные требования

  • Backend: Node.js + NestJS (TypeScript)
  • Frontend: Vue 3 + TypeScript
  • База данных: MySQL
  • Контейнеризация: Docker + Docker Compose
  • Документация API: OpenAPI (Swagger)
  • Покрытие тестами:
    • unit-тесты
    • интеграционные тесты
  • Масштабируемость и расширяемость архитектуры

5. Сценарии использования

5.1 Диаграмма вариантов использования

Диаграмма отражает взаимодействие ролей с системой:

Use Case Diagram


5.2 Студент

Основной сценарий:

Авторизация → Просмотр списка курсов → Просмотр деталей курса → Просмотр проектов → Формирование команды → Отправка заявки → Получение уведомления → Просмотр распределения → Инициация обмена (при необходимости)

  1. Авторизация → вход в систему.
  2. Просмотр списка курсов → отображение актуальных курсов.
  3. Просмотр деталей курса → описание и дедлайны.
  4. Просмотр списка проектов → список доступных проектов.
  5. Формирование команды:
    • отправка запроса;
    • получение запроса;
    • подтверждение или отказ.
  6. Отправка заявки.
  7. Уведомление о распределении.
  8. Просмотр дашборда.
  9. Обмен проектами:
    • инициация;
    • подтверждение или отказ.

5.3 Администратор

Основной сценарий:

Авторизация → Настройка параметров
→ Просмотр курсов → Настройка курса → Запуск распределения → Анализ результатов → Корректировка → Публикация → Просмотр распределения → Подтверждение обмена

  1. Авторизация.
  2. Просмотр курсов.
  3. Просмотр деталей курса.
  4. Настройка курса:
    • редактирование описания;
    • изменение дедлайнов, размера команд, отображения курса;
    • редактирование списка проектов.
  5. Настройка параметров распределения.
  6. Запуск алгоритма.
  7. Визуализация результатов.
  8. Корректировка.
  9. Публикация итогов.
  10. Просмотр дашборда.
  11. Подтверждение или запрет обмена.

6. Архитектура данных

6.1 ER-модель

ER-модель описывает структуру базы данных и связи между сущностями (курсы, пользователи, команды, проекты, заявки и т.д.).

ER Diagram

6.2 API и OpenAPI-документация

OpenAPI