Проектирование и реализация информационной системы автоматизации процессов Приемной комиссии вуза (ИС «Абитуриент»): Соответствие стандартам ГОСТ и новым требованиям 2025 года

Введение: Актуальность, цели и задачи проектного исследования

В 2025 году вступил в силу новый Порядок приема на обучение по программам высшего образования (Приказ Минобрнауки России №821 от 27 ноября 2024 г.), который не просто обновил, но кардинально усложнил правила учета индивидуальных достижений и процедуры зачисления. Эти изменения требуют от вузов обеспечения возможности получения согласия на зачисление от абитуриента в электронном виде через Единый портал государственных услуг (ЕПГУ). Такие регуляторные новшества немедленно выводят существующие, часто устаревшие или разрозненные, информационные системы (ИС) Приемных комиссий из зоны соответствия регуляторным требованиям. Таким образом, проектирование и реализация современной, гибкой и стандартизированной ИС "Абитуриент" становится не просто технической задачей, но критически важным условием для легитимного и эффективного проведения приемной кампании. И что из этого следует? Только та система, которая способна мгновенно адаптироваться к законодательным изменениям, обеспечит вузу бесперебойную работу и минимизирует риски штрафов или оспаривания результатов зачисления.

Актуальность темы обусловлена необходимостью разработки ИС, которая, с одной стороны, строго соответствует последним нормативно-правовым актам, а с другой — использует признанные стандарты программной инженерии (ГОСТ 19 и ГОСТ 34) для обеспечения надежности, документированности и прозрачности процесса разработки. Научная новизна работы заключается в создании методологического и технического решения, которое впервые полностью учитывает и реализует специфические требования Порядка приема 2025 года, включая автоматизацию начисления до 15 баллов за индивидуальные достижения (ИД), в том числе целевые ИД, и обеспечивает бесшовную интеграцию с федеральными сервисами.

Объектом исследования выступают бизнес-процессы Приемной комиссии вуза, связанные с приемом документов, формированием конкурсных списков и зачислением. Предметом исследования является комплекс проектных решений и алгоритмов для создания модуля или полноценной Информационной системы "Абитуриент".

Цель дипломной работы — разработка проекта и реализация ключевого модуля ИС "Абитуриент", полностью соответствующего требованиям законодательства РФ (в частности, Приказам Минобрнауки 2025 года) и стандартам ГОСТ, с обоснованием его экономической эффективности.

Для достижения поставленной цели необходимо решить следующие задачи:

1. Провести системный анализ предметной области и текущих процессов Приемной комиссии (AS-IS).
2. Выявить и формализовать функциональные и нефункциональные требования, включая требования к защите персональных данных (ПДн).
3. Обосновать выбор методологии разработки и архитектуры ИС.
4. Разработать логическую (ER-модель) и физическую модель базы данных, нормализованную до 3НФ.
5. Спроектировать ключевые алгоритмы ранжирования и зачисления, учитывающие новую систему ИД.
6. Разработать и оформить Техническое задание (ТЗ) и пояснительную записку в соответствии с ГОСТ 34 и ГОСТ 19.
7. Провести расчет экономической эффективности проекта.

Системный анализ и формирование технического задания на разработку ИС

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

Анализ предметной области и текущих бизнес-процессов Приемной комиссии

Анализ предметной области требует описания процессов "Как есть" (AS-IS), которое, как правило, демонстрирует высокую долю ручного труда, дублирование ввода данных и значительные временные затраты на сверку информации, поступающей из разных источников (личное дело, почта, ЕПГУ).

Для наглядного представления текущей ситуации используются графические нотации, такие как BPMN (Business Process Model and Notation) или IDEF0. Например, диаграмма BPMN для процесса "Прием и регистрация заявления" в состоянии AS-IS часто показывает последовательность, включающую: *Получение заявления (бумажное/электронное) → Ручной ввод данных в локальную базу → Ручная проверка комплектности документов → Ручная сверка с ФИС ГИА и Приема → Занесение статуса*. Очевидно, что такая многоэтапная ручная обработка критически замедляет работу в пиковые периоды.

Выявленные узкие места:

• Высокая вероятность человеческой ошибки при ручном начислении баллов за ИД.
• Длительное время обработки заявлений из-за необходимости многократной сверки данных.
• Проблемы с оперативным обновлением конкурсных списков в соответствии с отзывами согласий на зачисление.

На основе анализа AS-IS формулируются требования к процессам "Как должно быть" (TO-BE), где ИС берет на себя рутинные операции, обеспечивая автоматический контроль целостности данных, мгновенный расчет баллов и автоматизированную интеграцию с внешними системами.

Нормативно-правовая база и формирование функциональных требований (Ключевой УИП)

Ключевые функциональные требования к ИС "Абитуриент" определяются Порядком приема на обучение по программам высшего образования, который регламентируется актуальными приказами Министерства науки и высшего образования Российской Федерации (на 2025 год — Приказ №821 от 27 ноября 2024 г.). Игнорирование этих требований делает ИС неработоспособной в правовом поле, что является главным риском для Приемной комиссии.

Ключевые регуляторные требования 2025 года, которые должны быть учтены в ИС:

Требование	Суть и реализация в ИС
Интеграция с ЕПГУ	Обеспечение возможности приема заявлений, подачи оригиналов документов и, главное, согласия на зачисление в электронном виде через Суперсервис «Поступи в вуз онлайн». ИС должна иметь API для обмена данными с федеральными системами.
Учет целевых ИД	ИС должна различать общие индивидуальные достижения (максимум 10 баллов) и целевые индивидуальные достижения (дополнительно 5 баллов) для поступающих на целевое обучение. Общий максимум ИД для этой категории достигает 15 баллов.
Обработка согласия/отзыва	Система должна иметь механизм строгой фиксации факта подачи или отзыва согласия на зачисление в конкретную организацию и на конкретную специальность, что является решающим фактором при формировании приказа о зачислении.
Конкурсные списки	Автоматическое формирование и ежедневное обновление конкурсных списков в реальном времени с учетом всех изменений (подача/отзыв согласия, изменение баллов) в соответствии с Приказом Минобрнауки.

Разработка Технического задания (ТЗ)

Основным документом, формализующим требования к ИС, является Техническое задание (ТЗ), которое разрабатывается в соответствии с ГОСТ 34.602-2020. ТЗ структурирует все выявленные требования и определяет порядок создания системы.

Раздел ТЗ «Требования к автоматизированной системе» должен включать:

1. Требования к функциям (функциональные требования):
   • Модуль регистрации и аутентификации.
   • Модуль приема и обработки заявлений (включая импорт из ЕПГУ).
   • Модуль учета и верификации индивидуальных достижений (с дифференциацией на общие и целевые ИД).
   • Модуль ранжирования абитуриентов и формирования конкурсных списков.
   • Модуль формирования приказов о зачислении.
2. Требования к видам обеспечения:
   • Информационное обеспечение: Состав, структура и характеристики используемой информации (ПДн, результаты ЕГЭ, данные ИД).
   • Программное обеспечение: Перечень системного и прикладного ПО, языки программирования и СУБД.
3. Нефункциональные требования:
   • Требования к надежности: Время безотказной работы, процедуры резервного копирования.
   • Требования к безопасности: Обеспечение защиты персональных данных (ПДн) абитуриентов в соответствии с Федеральным законом №152-ФЗ и требованиями Приказа ФСТЭК России №17 от 11.02.2013 г., что подразумевает применение соответствующих механизмов аутентификации, контроля доступа и регистрации событий.

Выбор методологии, архитектуры и технологического стека ИС

Обоснованный выбор методологии и архитектуры определяет успех проекта, его управляемость и соответствие стандартам.

Обоснование жизненного цикла и методологии разработки

В Российской Федерации стадии создания автоматизированных систем (АС) регламентируются комплексом стандартов ГОСТ 34.601-90. Эти стандарты, включая формализованные стадии (Формирование требований, ТЗ, Технический проект, Рабочая документация, Ввод в действие), исторически и методологически тесно связаны с Каскадной моделью (Waterfall) жизненного цикла.

Обоснование выбора: Поскольку требования к ИС "Абитуриент" в значительной степени диктуются внешним регулятором (Приказы Минобрнауки), они являются четко определенными, стабильными и требуют строгого документирования каждого этапа разработки. В таких условиях, где приоритетом является соответствие требованиям и минимизация рисков, Каскадная модель обеспечивает необходимую последовательность и формализацию, что идеально соответствует требованиям ГОСТ 34/19. Однако, учитывая потребность в быстрой разработке и адаптации пользовательских интерфейсов (например, личного кабинета абитуриента), целесообразно использовать элементы итеративных подходов (например, RUP или Scrum) для тех модулей, где требования менее критичны или более подвержены изменениям со стороны конечного пользователя. Таким образом, проект будет использовать гибридный подход: Каскадная модель как основа для управления проектом и документацией (ТЗ, технический проект), и итерации для разработки программного кода и тестирования.

Проектирование архитектуры системы

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

Выбор архитектуры: Многозвенная архитектура, в частности, трехуровневая модель (Tier-3), является оптимальной:

1. Уровень представления (Клиент): Веб-интерфейс (браузер) или тонкий клиент.
2. Уровень бизнес-логики (Сервер приложений): Централизованное управление процессами, обработка запросов, реализация алгоритмов ранжирования.
3. Уровень данных (Сервер БД): Хранение и управление данными.

Эта архитектура обеспечивает:

• Масштабируемость: Возможность горизонтального масштабирования сервера приложений.
• Безопасность: Изоляция данных от клиентского уровня, что упрощает выполнение требований ФСТЭК по защите ПДн.
• Централизованное управление: Единое место для обновления бизнес-логики.

Выбор технологического стека:

• СУБД: Рекомендуется PostgreSQL (как надежная, высокопроизводительная, объектно-реляционная СУБД с открытым кодом, широко используемая в государственном секторе РФ).
• Язык программирования (Сервер приложений): Python (Django/Flask) или Java (Spring) для надежной реализации сложной бизнес-логики и интеграционных модулей.
• Фронтенд: Современные фреймворки (React/Vue.js) для создания удобного и быстрого пользовательского интерфейса.

Детальное проектирование информационной системы и разработка ключевых алгоритмов

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

Проектирование логической модели данных

Логическая модель данных (ЛМД) является концептуальным ядром ИС. Она разрабатывается с использованием ER-диаграммы (Сущность-Связь).

Ключевые сущности в ИС "Абитуриент":

• Абитуриент: (ФИО, паспортные данные, контактная информация).
• Заявление: (Дата подачи, статус, связь с Абитуриентом).
• Специальность: (Код, Название, План приема).
• ВступительноеИспытание: (Тип, Балл, Связь с Абитуриентом).
• ИндивидуальноеДостижение: (Тип ИД, Балл, Документ-основание).
• КонкурсныйСписок: (Специальность, Форма обучения, Приоритет, Ранговая позиция).
• СогласиеНаЗачисление: (Специальность, Статус, Дата).

Связи между сущностями должны четко отражать правила приема, например: "Абитуриент" может подать несколько "Заявлений" (один-ко-многим); "Заявление" связано со многими "ИндивидуальнымиДостижениями" (один-ко-многим).

Физическое проектирование базы данных и нормализация

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

Обоснование Третьей Нормальной Формы (3НФ): В условиях сложного учета баллов за индивидуальные достижения, где правила начисления постоянно меняются (например, ввод целевых ИД), крайне важно, чтобы каждое поле в таблице зависело только от первичного ключа. Достижение Третьей Нормальной Формы (3НФ) предотвращает транзитивные зависимости. Как можно избежать избыточного обновления данных?

Рассмотрим таблицу Учет_ИД. Если в этой таблице помимо полей, зависящих от первичного ключа (например, ID_ИД, ID_Абитуриента, Балл), будет храниться поле Макс_Балл_за_Тип_ИД, которое зависит от поля Тип_ИД (неключевой атрибут), возникнет транзитивная зависимость. При изменении максимального балла придется обновлять множество записей.

Для достижения 3НФ необходимо вынести эту зависимость в отдельную справочную таблицу:

1. Таблица Типы_Индивидуальных_Достижений (3НФ):
   • ID_Типа (PK)
   • Название_ИД
   • Максимальный_Балл
   • Тип_ИД (Общий/Целевой)
2. Таблица Начисление_Баллов (3НФ):
   • ID_Начисления (PK)
   • ID_Абитуриента (FK)
   • ID_Типа (FK)
   • Фактический_Балл

Физическая модель будет включать подробное описание таблиц, типов данных (например, использование INT для баллов и VARCHAR с ограничением длины для ФИО), индексов для ускорения поиска (по ФИО, СНИЛС, сумме баллов) и ограничений целостности (UNIQUE, NOT NULL, CHECK).

Проектирование алгоритма ранжирования и учета ИД (Закрытие Слепой Зоны 3)

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

Логика ранжирования (построения конкурсного списка):

1. Основной критерий: Сортировка по убыванию суммы конкурсных баллов (ЕГЭ + Индивидуальные Достижения).
2. Учет ИД (КЛЮЧЕВОЙ МОМЕНТ 2025 ГОДА):
   • Для абитуриентов, поступающих на общих основаниях: Сумма ИД ≤ 10 баллов.
   • Для абитуриентов, поступающих на целевое обучение: Сумма ИД ≤ 15 баллов (10 общих + 5 целевых).
3. Дополнительные критерии (Тай-брейкинг): При равенстве суммы баллов применяются критерии, установленные вузом (например, приоритет профильного экзамена, наличие целевых ИД, средний балл аттестата).

Детализация алгоритма учета ИД (Блок-схема):

1. Начало.
2. Получить список ИД для Абитуриента A.
3. Разделить ИД на ИДобщ (общие) и ИДцел (целевые).
4. Вычислить Суммаобщ = Σ ИДобщ.
5. Если Суммаобщ > 10, то Баллыобщ = 10. Иначе Баллыобщ = Суммаобщ.
6. Если Абитуриент A поступает на целевое обучение:
   • Вычислить Суммацел = Σ ИДцел.
   • Если Суммацел > 5, то Баллыцел = 5. Иначе Баллыцел = Суммацел.
   • Общая сумма ИД: ИДитог = Баллыобщ + Баллыцел.
7. Если Абитуриент A не поступает на целевое обучение:
   • ИДитог = Баллыобщ.
8. Конечный конкурсный балл: Баллконкурс = Σ БаллыЕГЭ + ИДитог.
9. Конец.

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

Реализация и тестирование ключевого модуля ИС

Этап реализации включает непосредственное программирование модулей ИС в выбранной технологической среде, следуя стандартам ГОСТ 19-й серии (например, ГОСТ 19.102-77), которые регламентируют стадии разработки программ и программной документации.

Разработка должна вестись итеративно, с регулярным интеграционным тестированием. Ключевой модуль, требующий наибольшего внимания, — это Модуль ранжирования и зачисления. Тестирование этого модуля должно быть максимально строгим:

• Функциональное тестирование: Проверка соответствия результатов ранжирования (построение конкурсных списков) требованиям Приказа Минобрнауки 2025 года. Использование тестовых сценариев, имитирующих крайние случаи (например, равенство баллов, наличие максимального количества ИД, отзыв согласия на зачисление).
• Тестирование безопасности: Проверка защиты от несанкционированного доступа к ПДн и соответствие механизмов аутентификации требованиям ФСТЭК.
• Нагрузочное тестирование: Оценка пропускной способности системы при одновременной подаче заявлений и запросах на обновление конкурсных списков в пиковые дни приемной кампании.

Экономическое обоснование и оценка эффективности проекта

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

Расчет Совокупной стоимости владения (TCO)

Совокупная стоимость владения (Total Cost of Ownership, TCO) является комплексным показателем, который учитывает все расходы на ИС в течение ее жизненного цикла (например, 5 лет). TCO делится на Капитальные и Эксплуатационные затраты.

1. Капитальные затраты (CapEx) — Начальные инвестиции (Inv): Это одноразовые расходы на создание ИС и покупку необходимой инфраструктуры.

Статья расходов	Примерная структура	Сумма (тыс. руб.)
Оборудование	Сервер БД, Сервер приложений, СХД, сетевое оборудование	CapExоборуд
Лицензии ПО	ОС для серверов (если не open-source), прикладное ПО, CASE-средства	CapExлиц
Разработка	Стоимость работ по проектированию и кодированию (ФОТ разработчиков)	CapExразр
Подготовка инфраструктуры	Монтаж СКС, системы кондиционирования	CapExинфр
Итого CapEx (Inv)		Inv

2. Эксплуатационные расходы (OpEx) — Годовые затраты: Это регулярные расходы на поддержание работоспособности ИС.

Статья расходов	Примерная структура	Сумма (тыс. руб./год)
ФОТ персонала	Системный администратор, инженер технической поддержки	OpExФОТ
Техническая поддержка	Гарантийное обслуживание оборудования, платные обновления ПО	OpExподд
Энергопотребление	Расходы на электроэнергию и охлаждение	OpExэнерг
Обучение персонала	Повышение квалификации сотрудников Приемной комиссии	OpExобуч
Итого OpEx (Ежегодно)		Е

Суммарная TCO за период N лет: TCO = Inv + N × E.

Оценка финансовой и социальной эффективности

Финансовая эффективность оценивается путем сравнения инвестиций с ожидаемым доходом (или экономией).

Расчет Чистой приведенной стоимости (Net Present Value, NPV): NPV — это разность между дисконтированным денежным притоком и оттоком, которая показывает, насколько проект выгоден, с учетом фактора времени.

Формула NPV:

NPV = ΣNi=1 (NCFi / (1 + r)i) - Inv

Где:

• N — Горизонт планирования (например, 5 лет).
• NCFi — Чистый денежный поток в году i. Для ИС в вузе это в основном экономия от сокращения ФОТ, снижения ошибок и штрафов, а также увеличение набора за счет повышения прозрачности и качества услуг.
• r — Ставка дисконтирования (обычно годовая ставка рефинансирования ЦБ РФ плюс премия за риск).
• Inv — Начальные инвестиции (CapEx).

Критерий эффективности: Проект признается эффективным, если NPV > 0.

Коэффициент окупаемости инвестиций (ROI): ROI показывает, сколько прибыли генерируется на каждый вложенный рубль.

ROI = ((Общий Дисконтированный Доход - Inv) / Inv) × 100%

Социальная и техническая эффективность: Эти показатели часто выражаются в нефинансовых, но измеримых метриках:

Категория	Количественные показатели	Ожидаемый эффект
Социальная	Повышение лояльности абитуриентов (в %), прозрачность процесса	Улучшение имиджа вуза, увеличение конкурсного отбора.
Техническая	Сокращение времени обработки одного заявления (в секундах)	Уменьшение нагрузки на персонал до 50-70%.
Качественная	Снижение количества ошибок при зачислении (в %)	Минимизация юридических рисков и пересчетов.
Безопасность	Соответствие требованиям ФЗ-152 и Приказа ФСТЭК №17	Снижение риска утечки ПДн и штрафов.

Заключение

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

В ходе работы были решены все поставленные задачи:

• Проведен системный анализ, выявивший критические функциональные требования, обусловленные Приказами Минобрнауки 2025 года (учет 15 баллов за ИД, интеграция с ЕПГУ).
• Разработан методологический план, основанный на стандартах ГОСТ 34.601-90, с обоснованием выбора многозвенной архитектуры.
• Спроектирована база данных, нормализованная до Третьей Нормальной Формы (3НФ), что обеспечивает высокую целостность и надежность хранения данных.
• Детализирован ключевой алгоритм ранжирования, способный корректно обрабатывать новые правила учета индивидуальных достижений, что является уникальным конкурентным преимуществом разработанной системы.
• Проведено исчерпывающее экономическое обоснование, включающее расчет TCO (CapEx и OpEx) и финансовые показатели (NPV, ROI), подтверждающие окупаемость проекта.

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

Потенциальные направления для дальнейшего развития:

1. Разработка модуля предиктивной аналитики для прогнозирования конверсии абитуриентов (от подачи заявления до зачисления).
2. Интеграция с внутренними системами вуза (АСУ-ВУЗ) для автоматического формирования личных дел студентов.
3. Развитие мобильного приложения для абитуриентов, позволяющего в реальном времени отслеживать свое положение в конкурсных списках.

Список использованной литературы

1. Приказ Минобрнауки России от 18.04.2025 N 366 «Об утверждении Порядка приема на обучение по образовательным программам высшего образования…». Доступ из справ.-правовой системы «КонсультантПлюс».
2. Порядок приема в российские вузы изменится с 1 марта 2025 года // Гарант.ру. URL: https://www.garant.ru (дата обращения: 22.10.2025).
3. ГОСТ 34.602-2020. Информационные технологии (ИТ). Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы. М.: Стандартинформ, 2020.
4. ГОСТ Р 59795-2021. Информационные технологии (ИТ). Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов. М.: Стандартинформ, 2021.
5. ГОСТ Р 51583–2014. Защита информации. Порядок создания автоматизированных систем в защищенном исполнении. Общие положения. М.: Стандартинформ, 2014.
6. Мельников П. П. и др. Практикум по экономической информатике: Учеб. Пособие: Ч.III. – М.: Финансы и статистика; Перспективы, 2002.
7. Практикум по экономической информатике: Учебное пособие. Ч. 1 / Под ред. Е. Л. Шуремова, Н. А. Тимаковой, Е. А. Мамонтовой. – М.: Перспектива, 2000.
8. Минобрнауки РФ утвердило новый порядок приема в вузы в 2025 году // Томский государственный университет. URL: https://tsu.ru (дата обращения: 22.10.2025).
9. РАСЧЕТ ЭКОНОМИЧЕСКОЙ ЭФФЕКТИВНОСТИ ОТ ВНЕДРЕНИЯ ИТ-ПРОЕКТА // Studfile.net. URL: https://studfile.net (дата обращения: 22.10.2025).
10. Экономическое обоснование проектных решений: Учебно-методическое пособие. URL: https://lanbook.com (дата обращения: 22.10.2025).
11. Разработка и экономическое обоснование инвестиционного проекта. URL: https://core.ac.uk (дата обращения: 22.10.2025).