Внешние сущности и интеграции

Контекст

Для демонстрации потоков взаимодейтсвия между проектируемой системой и внешними сущностями воспользуемся контекстным уровнем диаграммы С4:

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

Внешние сущности

Пользователи и их взаимодействие с системой

1. Студент

• Вход в систему
• Просмотр материалов по курсу
• Выполнение заданий
• Прохождение экзаменов

2. Преподаватель

• Вход в систему
• Создание и редактирование курсов
• Оценка заданий и экзаменов
• Просмотр отчетов успеваемости
• Просмотр отчетов проведения экзамена

3. Проктор

• Вход
• Контроль процесса проведения экзамена
• Анализ видеопотока

4. Администратор учебного подразделения

• Назначение ролей
• Управление учетными записями
• Настройка параметров экзаменов

Внешние интеграции и их обоснование

1. Интеграция с системой единого входа (SSO)

• Студенты и преподаватели используют единые корпоративные учётные данные. Нет необходимости запоминать ещё один логин и пароль.
• Учётная запись в платформе создаётся автоматически при первом входе, синхронизация атрибутов (ФИО, email, группа) происходит из SSO
• При отсутствии внешнего SSO платформа может выступать собственным Identity Provider.

2. Интеграция с LMS (Moodle)

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

3. Интеграция с облачным объектным хранилищем

• Использование сертифицированных российских облаков (Яндекс.Облако, VK Cloud) с аттестацией ФСТЭК позволяет выполнить требования 152-ФЗ о хранении персональных данных на территории РФ и использовании сертифицированных средств защиты.
• Провайдеры (Яндекс.Облако, VK Cloud, AWS S3) обеспечивают репликацию данных в нескольких дата-центрах, гарантируя сохранность даже при выходе из строя оборудования.

4. Интеграция с SFU-сервером

• Организация низколатентной видеосвязи с десятками одновременных участников для бесперебойного контроля проведения экзамена

Стейкхолдеры

Сценарии использования системы прокторинга

Сценарий 1. Вход студента в систему

Цель

Вход студента в систему с назначением корректной роли.

Условия начала

1. Студент зарегистрирован в университете.
2. SSO доступен.
3. Аккаунт студента не заблокирован.

Основной поток (Happy path)

1. Студент открывает платформу и выбирает “Войти”.
2. Система запрашивает сведения через SSO.
3. SSO возвращает токен.
4. Система назначает роль - “студент”.
5. Система загружает профиль и доступные курсы.
6. Система открывает личный кабинет.

Результат

Студент авторизован и имеет доступ к курсам.

Исключения (нештатные ситуации)

1. Неверные данные авторизации

• 1.1 SSO не вернула токен.
• 1.2 Платформа выдаёт ошибку.

2. Токен пользователя истёк

• 3.1 Платформа повторяет запрос наполучение токена

3. Пользователь заблокирован

• 4.1 Платформа отклоняет авторизацию и выдаёт сообщение о блокировке.

Режимы деградации (как продолжаем работать)

1. SSO недоступен

• 1.1 Активировать резервную учетную запись на самой платформе
• 1.2 Осуществить доступ по резервной записи

Сценарий 2. Проведение экзамена с прокторингом

Цель

Проведение экзамена с обязательным видеомониторингом и фиксацией сессии.

Условия начала

1. Студент авторизован.
2. Экзамен доступен для выполнения.
3. Камера и микрофон доступны.

Основной поток (Happy path)

1. Студент открывает страницу экзамена.
2. Студент соглашения с условиями проведения экзамена.
3. Запрашивается доступ к камере/микрофону.
4. Студент нажимает кнопку “Начать экзамен”.
5. Создаётся прокторинг-сессия.
6. Видеопоток подключается к стриминг-сервису.
7. Включается античит-система.
8. Студент получает экзаменационные задания.
9. Запускается таймер.
10. Студент выполняет задания.
11. Записи камеры, микрофона, экрана фиксируются.
12. Результаты экзамена сохраняются вместе с записями.

Результат

Экзамен проведен, данные сохранены, прокторинг-сессия зарегистрирована.

Исключения (нештатные ситуации)

1. Камера или микрофон недоступны

• 1.1 Система блокирует начало экзамена.
• 1.2 Кнопка начать экзамен недоступна

2. Потеря интернет-соединения

• 2.1 Система детектирует потерю связи и уведомляет студента: “Соединение потеряно. Экзамен продолжается в автономном режиме.”
• 2.2 Таймер экзамена приостанавливается на 5 минут для компенсации времени простоя.
• 2.3 Все действия студента сохраняются локально
• 2.4 При восстановлении соединения данные синхронизируются с сервером.
• 2.5 Таймер возобновляется с момента разрыва, студент продолжает экзамен.
• 2.6 Если соединение не восстановлено до конца экзамена — данные сохраняются локально и отправляются при следующем входе в систему.

Режимы деградации

1. Сервис стриминга недоступен

• 1.1 Разрешить запись локально на устройство студента с последующей загрузкой.
• 1.2 Создать хеш видео-записи и подписать его для обеспечение неподдельности видеозаписи

Сценарий 3. Обнаружение нарушения во время экзамена

Цель

1. Зафиксировать и обработать потенциальное нарушение.

Условия начала

1. Экзамен в процессе.
2. Проктор доступен (онлайн-прокторинг)
3. Подозрительное событие со стороны экзаменуемого.

Основной поток (Happy path)

1. Система обнаруживает подозрительное событие (второе лицо в кадре, переключение вкладки, уход из кадра).
2. Система фиксирует потенциальное нарушение с описанием и временем.
3. Проктор получает уведомление.
4. Проктор просматривает фрагмент видео.
5. Проктор принимает решение и при необходимости шлет предупреждение экзаменуемому
6. Решение фиксируется в системе.

Результат

Событие зарегистрировано, решение зафиксировано в логах.

Исключения (нештатные ситуации)

1. Ложное срабатывание Античита

• 1.1 Проктор меняет статус потенциального нарушения на “Ложное”.

2. Массовые алерты (перегрузка)

• 2.1 Система расставляет приоритеты потенциальным нарушениям по уровню риска.

Режимы деградации

1. Проктор недоступен

• 1.1 Решение по нарушениям принимается после экзамена при проверке записи (офлайн-прокторинг).

Сценарий 4. Управление политиками прокторинга администратором

Цель

Настроить правила прокторинга и политики безопасности.

Условия начала

1. Администратор УО авторизован.

Основной поток (Happy path)

1. Администратор УО открывает “Настройки прокторинга”.
2. Настраивает параметры: допустимое количество переключений вкладок, чувствительность античита.
3. Сохраняет изменения.
4. Новые изменения логируются (кто внес, время, старое и новое значение параметра)
5. Система применяет новые параметры.
6. Параметры применяются к новым экзаменам.

Результат

Настройки прокторинга обновлены и активны.

Исключения (нештатные ситуации)

1. Конфликт параметров

• 1.1 Система уведомляет о конфликте и требует исправления.

2. Массовые алерты

• 2.1 Система расставляет приоритеты потенциальным нарушениям по уровню риска.

Режимы деградации

1. Античит недоступен

• 1.1 Параметры античита будут переданы ему, когда он станет доступен.

Сценарий 5. Апелляция студента по результатам экзамена

Цель

1. Обеспечить прозрачный процесс пересмотра результатов.

Условия начала

1. Экзамен завершён.
2. Студент имеет основания для подачи апелляции.

Основной поток (Happy path)

1. Студент нажимает “Подать апелляцию”.
2. Указывает причину и, при необходимости, прикрепляет комментарии.
3. Система фиксирует заявку.
4. Преподаватель (или администратор) получает уведомление.

Результат

Апелляция студента зарегистрирована и передана на рассмотрение.

Исключения (нештатные ситуации)

1. Видео отсутствует

• 1.1 Решение по апелляции принимается на основе доступных логов и данных.

Режимы деградации

1. БД платформы недоступна

• 1.1 Апелляция ставится в очередь и отправляется автоматически после восстановления работы БД.

Требования к системе с т.з. стейкхолдеров (SR-SH)

SR-SH-1 (Студент - доступ к обучению и экзаменам)

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

SR-SH-2 (Студент - понятность и предсказуемость экзамена)

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

SR-SH-3 (Студент - защита результатов при сбоях)

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

SR-SH-4 (Студент - прозрачность прокторинга и право на оспаривание)

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

SR-SH-5 (Преподаватель - управление контентом)

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

SR-SH-6 (Преподаватель - контроль результатов обучения)

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

SR-SH-7 (Преподаватель - работа с инцидентами прокторинга)

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

SR-SH-8 (Проктор - наблюдаемость экзаменационной сессии)

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

SR-SH-9 (Мин. Обр. – соответствие регламенту)

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

SR-SH-10 (Администратор учебного центра - управление доступом и ролями)

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

SR-SH-11 (Поставщик платформы - управляемость работы платформы)

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

SR-SH-12 (Образовательная организация – интеграция в существующую инфраструктуру)

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

SR-SH-13 (Образовательная организация - проведение обучения и аттестации)

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

SR-SH-14 (Образовательная организация - аналитика и отчётность)

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

SR-SH-15 (Юрист - правомерность и проверяемость)

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

Системные требования

Системные требования (SR-SYS)

SR-SYS-1 (Сценарий 1 - Переход в SSO)

При выборе пользователем команды “Войти” система должна перенаправлять пользователя на страницу SSO университета.

Верификация: функциональный тест (нажатие кнопки входа => открывается SSO).

SR-SYS-2 (Сценарий 1 - Успешная аутентификация через SSO)

При успешной аутентификации в SSO и получении валидного токена система должна создавать авторизованную пользовательскую сессию.

Верификация: функциональный тест (валидный токен => пользователь входит в систему).

SR-SYS-3 (Сценарий 1 - Назначение роли студента)

После успешной аутентификации через SSO система должна назначать пользователю роль “студент”.

Верификация: функциональный тест (после входа у пользователя доступны только функции студента).

SR-SYS-4 (Сценарий 1 - Загрузка профиля и курсов)

После успешного входа система должна загружать профиль студента и список доступных ему курсов.

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

SR-SYS-5 (Сценарий 1 - Блокировка входа для заблокированного пользователя)

Если аккаунт пользователя имеет статус “заблокирован”, система должна отклонять авторизацию и показывать сообщение о блокировке.

Верификация: функциональный тест (заблокированный пользователь => вход запрещён, сообщение показано).

SR-SYS-6 (Сценарий 1 - Обработка истёкшего токена)

Если токен пользователя истёк, система должна запрашивать повторную авторизацию через SSO.

Верификация: функциональный тест (истёкший токен => требуется повторный вход).

SR-SYS-7 (Сценарий 1 - Недоступность SSO)

Если SSO недоступен в момент начала входа, система должна активировать резервную учетную запись и показать соотвествующее уведомление

Верификация: функциональный тест (SSO недоступен => пользователю показано уведомление об использовании резервной записи).

SR-SYS-8 (Сценарий 2 - Допуск к старту экзамена)

Система должна разрешать запуск экзамена только авторизованному студенту в пределах открытого окна экзамена.

Верификация: функциональный тест (авторизованный студент + наступило время экзамена => запуск разрешён).

SR-SYS-9 (Сценарий 2 - Проверка попыток и доступа к экзамену)

При нажатии студентом команды “Начать экзамен” система должна проверять доступ к экзамену и допустимость новой попытки.

Верификация: функциональный тест (нет доступа или попытки исчерпаны => запуск отклонён).

SR-SYS-10 (Сценарий 2 - Запрос доступа к камере и микрофону)

Перед началом экзамена система должна запрашивать доступ к камере и микрофону.

Верификация: функциональный тест (старт экзамена => появляется запрос разрешений).

SR-SYS-11 (Сценарий 2 - Блокировка старта без камеры/микрофона)

Если камера или микрофон недоступны, система должна блокировать начало экзамена и показывать сообщение об ошибке.

Верификация: функциональный тест (доступ к камере/микрофону отсутсвтует => старт заблокирован).

SR-SYS-12 (Сценарий 2 - Создание прокторинг-сессии)

При успешном старте экзамена система должна создавать прокторинг-сессию.

Верификация: функциональный тест (старт экзамена => создана прокторинг-сессия).

SR-SYS-13 (Сценарий 2 - Подключение видеопотока)

После создания прокторинг-сессии система должна подключать видеопоток к SFU-сервису.

Верификация: интеграционный тест (после старта экзамена видеопоток передаётся в SFU-сервис).

SR-SYS-14 (Сценарий 2 - Включение античита)

После создания прокторинг-сессии система должна включать античит-анализ для текущего экзамена.

Верификация: интеграционный тест (после старта экзамена античит получает данные сессии).

SR-SYS-15 (Сценарий 2 - Выдача вопросов и запуск таймера)

После успешной инициализации экзамена система должна выдавать студенту вопросы и запускать таймер экзамена.

Верификация: функциональный тест (после старта отображаются вопросы и начинается отсчёт времени).

SR-SYS-16 (Сценарий 2 - Фиксация записи камеры, микрофона и экрана)

Во время экзамена система должна фиксировать записи камеры, микрофона и экрана.

Верификация: функциональный тест (во время экзамена создаются записи всех предусмотренных источников).

SR-SYS-17 (Сценарий 2 - Сохранение результатов вместе с записями)

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

Верификация: функциональный тест (после завершения экзамена доступны результаты и связанные записи).

SR-SYS-18 (Сценарий 2 - Потеря интернет-соединения)

При потере интернет-соединения во время экзамена система должна сохранять текущее состояние экзаменационной сессии для последующего продолжения или корректного завершения.

Верификация: функциональный тест (разрыв соединения => текущее состояние сохранено).

SR-SYS-19 (Сценарий 2 - Недоступность стриминг-сервиса)

Если SFU-сервис недоступен, система должна разрешать локальную запись с последующей загрузкой.

Верификация: интеграционный тест (SFU недоступен => запись продолжается локально).

SR-SYS-20 (Сценарий 2 - Недоступность античита)

Если античит недоступен, система должна позволять проводить экзамен без анализа в реальном времени при сохранении записи сессии.

Верификация: функциональный тест (античит отключён => экзамен продолжается, запись сохраняется).

SR-SYS-21 (Сценарий 3 - Регистрация подозрительного события)

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

Верификация: функциональный тест (произвести моделирование события => запись о возмодном нарушении создана).

SR-SYS-22 (Сценарий 3 - Уведомление проктора)

После регистрации потенциального нарушения система должна уведомлять проктора.

Верификация: функциональный тест (создано потенциальное нарушение => проктор получает уведомление).

SR-SYS-23 (Сценарий 3 - Доступ проктора к фрагменту записи)

Для зарегистрированного потенциального нарушения система должна предоставлять проктору доступ к связанному фрагменту видео.

Верификация: функциональный тест (проктор видит сообщение о нарушении => доступен видеофрагмент).

SR-SYS-24 (Сценарий 3 - Фиксация решения проктора)

Система должна позволять проктору фиксировать решение по потенциальному нарушению.

Верификация: функциональный тест (проктор принимает решение => запись решения сохранена).

SR-SYS-25 (Сценарий 3 - Подтверждённое нарушение)

Если проктор подтверждает нарушение, система должна уведомить об этом экзаменуемого.

Верификация: функциональный тест (подтверждение нарушения => уведомление экзаменуемого).

SR-SYS-26 (Сценарий 3 - Ложное срабатывание)

Система должна позволять проктору менять статус потенциального нарушения на “Ложное”.

Верификация: функциональный тест (проктор отмечает ложное срабатывание системы аналаза => статус изменён на “Ложное”).

SR-SYS-27 (Сценарий 3 - Массовые алерты)

При массовом поступлении алертов система должна расставлять приоритеты потенциальных нарушений по уровню риска.

Верификация: нагрузочный/функциональный тест (набор алертов => события отсортированы по риску).

SR-SYS-28 (Сценарий 3 - Режимы деградации при недоступности проктора)

Если проктор недоступен, то система должна обспечивать возможность принять решение о результате проведения экзамена по записи после его завершения.

Верификация: функциональный тест (проктор недоступен => решение переносится на пост-проверку записи).

SR-SYS-29 (Сценарий 3 - Режимы деградации при недоступности античита)

Если античит недоступен, система должна обеспечивать возможность проверки записи после экзамена

Верификация: функциональный тест (античит недоступен => решение переносится на пост-проверку записи).

SR-SYS-30 (Сценарий 4 - Доступ администратора к настройкам прокторинга)

Система должна предоставлять только авторизованному администратору учебного подразделения доступ к разделу “Настройки прокторинга”.

Верификация: функциональный тест (пользователь с ролью “Администратор уч. подразделения” имеет доступ к настройкам. Пользователь с иной ролью такого доступа не имеет).

SR-SYS-31 (Сценарий 4 - Настройка допустимых переключений вкладок)

Система должна позволять администратору учебного подразделения задавать допустимое количество переключений вкладок во время экзамена.

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

SR-SYS-32 (Сценарий 4 - Настройка срока хранения записей)

Система должна позволять администратору учебного подразделения задавать срок хранения записей экзамена.

Верификация: функциональный тест (изменение срока хранения сохраняется и отображается в настройках).

SR-SYS-33 (Сценарий 4 - Настройка параметров античита)

Система должна позволять администратору учебного подразделения изменять настройки античит-системы.

Верификация: функциональный тест (изменённые параметры фиксируются, доставляются античит-системе и там также сохраняются).

SR-SYS-34 (Сценарий 4 - Сохранение истории параметров античита)

Система должна сохранять историю изменения настроек античита.

Верификация: функциональный тест (параметры изменены => появилась соотвествующая запись в истории изменений).

SR-SYS-35 (Сценарий 4 - Сохранение и применение новых политик)

После сохранения изменений система должна применять обновлённые настройки прокторинга к новым экзаменам.

Верификация: функциональный тест (новые экзамены используют новые параметры, а не старые).

SR-SYS-36 (Сценарий 4 - Вопроизведение настроек экзаменов, прошедших перед внесением изменений)

При проверке экзамена, который был проведен до изменения настрек, должен быть оценен по тем правилам и настройкам, что были введены на тот момент. Эти конкретные настройки должны воспроизводиться для конкретного экзамена.

Верификация: функциональный тест (новые экзамены используют новые параметры; ранее созданные — актуальные на тот момент).

SR-SYS-37 (Сценарий 4 - Конфликт параметров)

Если введённые администратором параметры настроек конфликтуют между собой, система должна отклонять сохранение и требовать исправления.

Верификация: функциональный тест (конфликтные параметр => сохранение заблокировано).

SR-SYS-38 (Сценарий 4 - Недоступность античита при передаче настроек)

Если античит-сервис недоступен в момент сохранения параметров, система должна передавать настройки античита после восстановления его доступности.

Верификация: интеграционный тест (античит недоступен при сохранении => новые параметры ставится в очередь, с последующей отправкой при восстановлении).

SR-SYS-39 (Сценарий 5 - Доступность подачи апелляции)

Система должна позволять студенту подать апелляцию только по завершённому экзамену.

Верификация: функциональный тест (по завершённому экзамену подача доступна, по незавершённому или неначатому - нет).

SR-SYS-40 (Сценарий 5 - Обязательность указания причины)

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

Верификация: функциональный тест (без причины апелляция не отправляется).

SR-SYS-41 (Сценарий 5 - Регистрация апелляции)

После отправки апелляции система должна фиксировать заявку студента на пересмотр результата.

Верификация: функциональный тест (апелляция отправлена => заявка зарегистрирована).