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-маршрута первого релиза.