Информационно-образовательный портал НЧИ КФУ

Техническое задание (эскиз) · 22 сентября 2026
Черновик — на согласовании с заказчиком

1. Общие сведения

Создаётся единый портал Набережночелнинского института (филиала) КФУ: публичный сайт + личные кабинеты + учебная информационная система + СДО. Система заменяет разрозненные инструменты и становится единой точкой входа для ~8000 студентов вуза и колледжа, сотрудников и абитуриентов.

2. Пользователи и роли

Система рассчитана на ~10 000 активных учётных записей: ~8000 студентов (вуз + колледж), преподаватели и сотрудники, плюс сезонный пик абитуриентов летом. Ролевая модель — RBAC с совмещением ролей у одного человека (преподаватель = сотрудник деканата, студент = лаборант).

РольКол-во (оценка)Основные права
Студент (вуз)~6350ЛК, расписание, оценки, СДО, заявления и справки
Студент (колледж, СПО)~1650 (факт, 13 специальностей — kpfu.ru/chelny/iek)то же, но учебные планы и документы по стандартам СПО
Преподаватель~400журналы, ведомости, курсы СДО, нагрузка
Сотрудник деканата / учебного отдела~50контингент, приказы, сессии, отчёты
Сотрудник приёмной комиссии~30 (сезонно)модуль абитуриента, конкурсные списки
Абитуриентдо ~5000 в сезонЛК абитуриента: заявление, документы, статус конкурса
Контент-редактор~10публичный сайт, новости, страницы подразделений
Администратор системы2–3роли, справочники, интеграции, аудит

Авторизация — единый SSO для всех модулей; вариант интеграции с единой учёткой КФУ — в разделе 10.

3. Архитектура и состав модулей

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

flowchart TD
  SSO[SSO / единая авторизация] --> LKS[ЛК студента]
  SSO --> LKR[ЛК сотрудника]
  SSO --> LKA[ЛК абитуриента]
  LKS --> CORE[(Ядро: контингент,
учебные планы, оценки)] LKR --> CORE LKA --> ABIT[Модуль приёма] ABIT -->|зачисление| CORE CORE --> SDO[СДО / дистанционное
обучение] CORE --> REP[Конструктор отчётов] CORE <--> ESB[Интеграционный слой] ESB <--> KFU[Системы головного КФУ]

Чтение схемы: личные кабинеты — интерфейсы над ядром; модуль приёма передаёт зачисленных в контингент одной операцией; обмен с КФУ идёт только через интеграционный слой, а не из каждого модуля напрямую. Публичный сайт работает отдельно от ядра — падение одного не валит другое.

Технологический стек фиксируется на этапе эскизного проекта. Базовые требования: веб-приложение без установки клиента, адаптивная вёрстка, размещение на серверах в РФ, реестровое ПО в базе требование для госвуза — уточнить.

4. Публичный сайт

Сайт — витрина института и точка входа в ЛК; управляется через CMS силами контент-редакторов без участия разработчиков. Текущее представительство института — раздел на портале головного вуза (kpfu.ru/chelny); структура нового сайта наследует его логику.

4.1. Текущая структура (анализ kpfu.ru/chelny от 22.09.2026)

4.2. Требования к новому сайту

5. Личные кабинеты

5.1. ЛК студента

5.2. ЛК преподавателя / сотрудника

6. Дистанционное обучение (СДО)

Рекомендуемый подход — не разрабатывать LMS с нуля, а развернуть Moodle или использовать существующую СДО КФУ do.kpfu.ru (Moodle; категория «Набережночелнинский институт КФУ» там уже есть) — решение за заказчиком — и глубоко интегрировать её с ядром Портала.

7. Учебная деятельность (ядро системы)

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

7.1. Контингент

7.2. Учебные планы и дисциплины

7.3. Успеваемость и сессии

7.4. Расписание

Автоматическое составление расписания (генерация с проверкой конфликтов) исключено из объёма проекта; при необходимости — отдельным этапом в будущем.

8. Приёмная кампания (модуль абитуриента)

Ключевой открытый вопрос: приём в филиал уже идёт через «Единый портал абитуриента» головного вуза (abiturient.kpfu.ru — на него ссылается страница «Поступающим» филиала). От ответа заказчика зависит, строим ли мы полный модуль приёма или витрину + обмен данными с КФУ. См. раздел 13.

9. Отчётность по свободным формам

10. Интеграция с головным вузом КФУ

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

ПотокНаправлениеДанные
КонтингентНЧИ → КФУчисленность, движение, приказы
УспеваемостьНЧИ → КФУитоги сессий, ГИА, дипломы
Приёмная кампанияКФУ ↔ НЧИзаявления, конкурсные списки, приказы о зачислении
СправочникиКФУ → НЧИнаправления, коды специальностей, подразделения
КадрыКФУ ↔ НЧИППС, ставки — если кадры ведутся централизованно
SSOКФУ → НЧИединая учётная запись студента/сотрудника КФУ

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

ПараметрТребование
Пользователи~10 000 учётных записей; пик 1500–2000 одновременных (закрытие сессии, публикация списков)
Время ответа≤ 2 с для страниц ЛК при пиковой нагрузке
Доступность99,5% в учебное время; регламентные работы — ночью
Резервное копированиеБД — ежедневно, хранение 30 дней; RTO ≤ 4 ч, RPO ≤ 24 ч
Безопасность152-ФЗ: ИСПДн класс защищённости — определить, хранение данных в РФ, TLS, парольные политики, журнал аудита действий с ПДн
Совместимостьактуальные версии Chrome/Firefox/Safari/Яндекс.Браузер, мобильные браузеры
Доступность средыверсия для слабовидящих на публичной части (ГОСТ Р 52872)
Эксплуатациямониторинг, алёрты, централизованные логи; документация администратора

12. Этапы внедрения и приёмка

ЭтапСрок (от старта)Содержание
1. Обследованиемес 1–2интервью с подразделениями, детальное ТЗ, прототипы интерфейсов, ответы на открытые вопросы
2. MVPмес 3–5публичный сайт, SSO, ЛК, ядро контингента с приказами
3. Учебный процессмес 6–8ведомости, сессии, БРС (балльно-рейтинговая система), расписание, СДО
4. Приём и отчётымес 9–10модуль абитуриента (готов к июню — к старту кампании), конструктор отчётов
5. Интеграция и ОЭмес 11–12обмены с КФУ, опытная эксплуатация, устранение замечаний, приёмка

13. Открытые вопросы к заказчику

  1. Приёмная кампания: ведётся ли приём централизованно через головной КФУ (abiturient.kpfu.ru)? Что остаётся филиалу?
  2. Какие ИС головного КФУ используются филиалом сейчас (ИАС «Электронный университет» / shelly.kpfu.ru — подтверждено) и какие API/форматы обмена доступны (запрос в ДИТ КФУ)?
  3. СДО: у КФУ есть Moodle do.kpfu.ru с категорией НЧИ. Разворачиваем свою или интегрируемся с существующей?
  4. SSO: возможен ли вход по единой учётке КФУ?
  5. Есть ли требование реестрового ПО / импортозамещения по стеку?
  6. Домен и брендинг: останется ли сайт в зоне kpfu.ru или у филиала свой домен? Требования КФУ к сайтам филиалов.
  7. Хостинг: сервера филиала, ЦОД КФУ или внешняя площадка?
  8. Из каких систем мигрируем данные (текущий учёт контингента, оценок)?
  9. Параметры БРС (балльно-рейтинговой системы: деление баллов между семестром и экзаменом, пороги оценок, допуски), шаблоны приказов и справок — передать образцы.
  10. Ориентировочный бюджет и желаемый срок запуска (влияет на состав MVP).