AS-IS ПРОЦЕССНАЯ КАРТА
Сайт факультета + Портфолио + БРС
Дата фиксации: 2026-04-26

Документ собирает в одном месте подтвержденный текущий маршрут работы студента и преподавателя
на основании текстового описания процесса и присланных скриншотов.

1. Ключевой общий вывод

На текущий момент существуют не одна, а две связанные, но организационно и технически разные системы:

1. faculty-side контур:
   - сайт факультета gtifem.ru
   - модуль портфолио
   - загрузка работ студентами
   - преподавательская проверка
   - рецензия
   - уровневое решение
   - подпись результата по работе

2. BRS-side контур:
   - система СФОП / БРС на xfem.ru
   - ведомости
   - колонки занятий
   - ручной ввод числовых баллов
   - сохранение
   - блокировка/подпись колонок

Главный архитектурный вывод:
между faculty-side решением и BRS-side фиксацией результата уже сейчас есть разрыв.
Именно этот разрыв и является основной зоной для автоматизации.

2. Подтвержденный текущий маршрут "как есть"

2.1. До загрузки работы

Преподаватель проводит занятие и выдает задание.
Задание:
- относится к одному или нескольким кодам компетенций;
- относится к одному из справочников типов работ;
- относится к конкретному учебному модулю.

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

Эта тройка является будущей опорой для Rule Pack.

2.2. Загрузка работы студентом

Студент под своим логином и паролем входит на сайт факультета.
Далее:
- переходит в Портфолио;
- открывает форму загрузки;
- выбирает:
  - модуль
  - тип работы
  - компетенцию или несколько компетенций
  - преподавателя
  - при необходимости руководителя
  - вариант
  - название работы
- прикрепляет файл;
- нажимает кнопку "Загрузить и Подписать".

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

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

2.3. Преподавательская очередь работ на сайте факультета

Преподаватель входит в личный кабинет на gtifem.ru и открывает таблицу портфолио.

В таблице есть:
- дата и время
- модуль
- название документа
- ФИО студента / проверяющего / руководителя
- группа
- тип / компетенция
- статус
- рецензия
- управление

Поддерживаются фильтры:
- год
- группа
- модуль
- тип
- статус
- ФИО студента

Управляющие действия:
- Проверить
- Удалить
- Изменить компетенцию

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

2.4. Получение файла преподавателем

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

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

Это одно из ключевых ограничений текущего контура.

2.5. Преподавательское решение в модальном окне "Рецензировать"

После просмотра работы преподаватель нажимает "Проверить".
Открывается модальное окно "Рецензировать".

Подтвержденные поля:
- Статус
- Оценка
- Тема
- Рецензия

Подтвержденные значения статуса:
- Принято
- На доработку

Подтвержденная шкала оценки:
- Уровень не сформирован
- Пороговый уровень выполнения работы
- Базовый уровень выполнения работы
- Продвинутый уровень выполнения работы

Подтвержденные особенности:
- тема работы подтягивается в форму;
- рецензия вводится преподавателем вручную;
- уровень выбирается вручную;
- после заполнения преподаватель переходит к следующему этапу;
- финальная кнопка - "Подписать".

2.6. Финальный экран подписания результата по работе

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

Подтвержденные элементы экрана:
- реквизиты образовательной программы;
- модуль;
- группа;
- ФИО студента;
- текст рецензии преподавателя;
- таблица с:
  - компетенцией
  - видом работы
  - наименованием работы
  - уровнем освоения компетенции;
- строка подписи преподавателя;
- дата;
- кнопка "Подписать".

Ключевой вывод:
в текущем faculty-side процессе существует официальная точка академического решения.
Она уже отделена от чернового просмотра и имеет форму отдельного этапа подписи.

2.7. Вид результата после подписания на faculty-side

После подписи в преподавательской таблице:
- статус становится "Принято";
- указывается дата;
- виден текст рецензии;
- доступен "Отчет".

Именно это можно считать завершением faculty-side цикла.

3. Подтвержденный текущий контур БРС / СФОП

3.1. Вход и общая структура

БРС-система находится в отдельном контуре xfem.ru.
По скриншотам подтверждается отдельный вход и отдельная информационная система:

"Система фиксации хода образовательного процесса (СФОП) ФЭМ СПбГТИ(ТУ)"

Слева отображается дерево учебных ведомостей:
- учебные модули по учебным годам;
- группы;
- дисциплины.

Подтвержденный вывод:
БРС - это отдельный контур, а не страница внутри gtifem.ru.

3.2. Шкала перевода в баллы

На стартовом экране БРС подтверждена числовая шкала итогового курса:
- 0–60,99 -> неудовлетворительно
- 61,00–70,99 -> удовлетворительно
- 71,00–80,99 -> хорошо
- 81,00–100 -> отлично

Это очень важное подтверждение:
faculty-side использует уровневую шкалу по работе,
а BRS-side использует числовой контур накопления баллов.

Следовательно, между ними обязательно должен существовать формализованный конвертер:

"уровень по работе -> числовой вклад в ведомость БРС"

3.3. Открытие таблицы баллов

В БРС преподаватель открывает:
- группу;
- дисциплину;
- раздел "Баллы";
- экран "Таблица баллов".

На таблице видны:
- студенты по строкам;
- множество ведомостей/колонок по занятиям;
- суммирующие столбцы:
  - ЛКЦ
  - ПРЗ
  - ИНЗ
  - ПРА
  - ЛИК
  - Итог курса

По заголовкам колонок подтверждается структура ведомости:
- краткий код ведомости;
- дата;
- краткий комментарий / наименование;
- фамилия преподавателя;
- ограничение по максимуму.

3.4. Создание новой ведомости

Преподаватель создает новую колонку кнопкой "Добавить ведомость".

После этого:
- выбирает категорию ведомости.

Подтвержденные категории:
- Инд.задан.
- Лекции
- Аттестация
- Практика
- Оц.лич.кач

После выбора категории открывается форма "Новая ведомость".

Подтвержденные поля формы:
- Категория
- Название ведомости
- Комментарий к ведомости
- Дата проведения занятия
- Максимальный балл
- Минимальный балл

Подтвержденные наблюдения:
- категория влияет на размещение и тип колонки;
- "тип занятия" в организационном смысле важен для структуры;
- по вашему описанию отдельные значения типа не влияют на академическую логику сами по себе;
- название и комментарий фактически идентифицируют колонку для пользователя;
- дата привязывает ведомость к занятию/контрольной точке.

3.5. Ввод баллов

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

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

3.6. Сохранение и завершение редактирования

После ввода баллов преподаватель:
- сохраняет значения;
- выходит из режима редактирования;
- после этого выполняет подписание / блокировку колонки.

На скриншотах подтверждаются:
- зеленые галочки;
- иконки замков;
- изменение состояния ведомости после подписания.

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

Это означает, что BRS-side имеет собственную "точку официальности", отличную от faculty-side подписи по работе.

4. Подтвержденный разрыв между двумя системами

На сегодняшний день процесс разделен на два независимых решения:

Этап A. Faculty-side
- работа оценивается на уровне компетенции и уровня освоения;
- преподаватель пишет рецензию;
- преподаватель подписывает результат по работе.

Этап B. BRS-side
- преподаватель вручную создает колонку;
- выбирает категорию;
- задает параметры ведомости;
- вручную конвертирует уровень в числовой балл;
- вручную вносит баллы;
- вручную сохраняет;
- вручную подписывает колонку.

Именно здесь и находится главная зона рутинной нагрузки.

5. Строгий экспертный вывод по архитектуре

Существующий процесс уже цифровой, но он логически разорван.

Проблема не в том, что нет сайта, таблиц или подписей.
Проблема в следующем:

1. система faculty-side оперирует академическими уровнями, рецензией и логикой работы;
2. система BRS-side оперирует числовыми баллами, колонками ведомостей и режимом блокировки;
3. преподаватель сам выполняет роль "ручного адаптера" между двумя системами.

Следовательно:
проект MVP должен строиться не как "еще один интерфейс оценки", а как мост между:
- результатом анализа работы;
- teacher approval;
- числовым переносом в BRS-side контур.

6. Что уже можно уверенно считать будущими точками интеграции

6.1. На стороне faculty-side
- работа
- модуль
- тип работы
- компетенция
- преподаватель
- статус
- уровень
- рецензия
- подписанный отчет

6.2. На стороне BRS-side
- группа
- дисциплина
- категория ведомости
- название ведомости
- комментарий
- дата
- max/min
- строка студента
- ячейка ведомости
- состояние подписания / блокировки

6.3. Ключевой промежуточный объект для MVP

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

"approved transfer record"

Его состав минимально должен включать:
- student_id
- group_id
- module_id
- work_id
- work_type
- competency_code
- teacher_approved_level
- transfer_score
- target_brs_column
- transfer_status
- version
- signed_faculty_timestamp
- signed_brs_timestamp

7. Что из присланного описания особенно ценно для MVP

7.1. Наличие автоматических писем
Это значит, что система уже умеет инициировать события и уведомления.
Следовательно, event-driven логика для ИИ-контура организационно уместна.

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

7.3. Разделение "уровень -> балл"
Это ключевая проблема и ключевой шанс для автоматизации.

7.4. Блокировка подписанных ячеек
Это очень важное ограничение.
После BRS-side подписи произвольная перезапись результата уже невозможна без отдельной пересборки процесса.

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

8. Практический вывод для MVP

Самая правильная реализация MVP на основе текущего процесса:

1. ИИ помогает сформировать faculty-side решение:
   - уровень
   - черновик рецензии
   - объяснение

2. Преподаватель утверждает и подписывает результат по работе.

3. Система автоматически готовит draft для BRS-side:
   - рекомендуемую ведомость
   - категорию
   - название / комментарий
   - числовое значение для студента

4. На первом MVP:
   - либо преподаватель подтверждает перенос вручную;
   - либо система в полуавтоматическом режиме подставляет баллы в незаблокированные ячейки.

5. Только после проверки преподавателем колонка подписывается в БРС.

9. Что еще остается технически неустановленным

Несмотря на сильную картину процесса, пока еще не подтверждены:
- реальные HTTP/API-запросы faculty-side;
- реальные HTTP/API-запросы BRS-side;
- способ аутентификации между системами;
- наличие CSRF/hidden parameters;
- формат данных при сохранении ячейки;
- формат данных при создании новой ведомости;
- формат данных при подписании / блокировке.

Это уже следующий слой анализа: F12 / Network / запросы и ответы.

10. Итоговый экспертный вывод

На основании всех скриншотов и описания процесс уже понятен достаточно хорошо, чтобы переходить к жесткому проектированию MVP.

Мы уже надежно понимаем:
- где студент создает запись;
- где преподаватель принимает академическое решение;
- где появляется официальная подпись по работе;
- где преподаватель вручную превращает уровень в балл;
- где именно в БРС происходит главная рутинная операция;
- где возникает техническая блокировка после подписи.

Следующий правильный шаг:
строить не абстрактную концепцию, а формальный As-Is / To-Be / Gap Analysis с выделением:
- системных сущностей;
- ручных операций;
- точек автоматизации;
- точек риска;
- MVP-маршрута первого релиза.
