УЦН 2.0 в дипломе: как превратить государственный проект в защищаемую ВКР по ИТ-инфраструктуре
25 марта 2026 года CNews опубликовал итоги второго этапа проекта устранения цифрового неравенства: за 2021–2025 годы устойчивая мобильная связь пришла туда, где её раньше не было, и 1,8 млн человек впервые оказались в онлайне. Для выпускника это не просто новость. Это готовый полигон для ВКР: масштабная распределённая инфраструктура, реальные метрики покрытия, открытые требования регулятора и куча узких мест, которые как раз и должны разбирать дипломники.
Проблема в том, что большинство студентов видят в телеком-проекте «что-то сетевое» и не понимают, как прикрутить его к собственной специальности. Ниже — разбор, как из этой новости вытащить тему, архитектуру, метрики и защищаемые выводы. Спойлер: работы хватит и на «Программную инженерию», и на «Информационные системы», и на «Прикладную информатику».
Три темы ВКР, которые рождаются из этой новости
Тема 1. Информационная система мониторинга покрытия мобильной сети в труднодоступных районах
Актуальность. Раз связь развернули на 1,8 млн пользователей, значит, кто-то должен был это считать, визуализировать и отчитываться. В статье прямо сказано про устойчивое покрытие — то есть речь о непрерывном мониторинге, а не разовой установке вышек.
Цель: разработать прототип системы сбора и визуализации телеметрии базовых станций с расчётом покрытия и SLA.
- Задача 1. Проанализировать существующие решения (Zabbix, Prometheus + Grafana, специализированные OSS).
- Задача 2. Спроектировать архитектуру сбора данных с использованием OpenTelemetry и очереди сообщений.
- Задача 3. Реализовать модуль расчёта зон покрытия и дашборды по населённым пунктам.
- Задача 4. Провести нагрузочное тестирование и оценить RTO/RPO.
Структура: Глава 1 — обзор телеком-мониторинга и стандартов (ISO/IEC 25010, ГОСТ 34.602-89). Глава 2 — проектирование (UML-диаграммы, схема развёртывания в Kubernetes). Глава 3 — реализация, тестирование, экономика внедрения (расчёт TCO против коммерческих решений).
Тема 2. Алгоритм оптимизации размещения базовых станций на основе геоданных
Актуальность. УЦН 2.0 — это история про то, куда физически поставить вышку, чтобы покрыть максимум жителей при минимальном бюджете. Классический случай для дипломной задачи оптимизации.
Цель: реализовать алгоритм покрытия (жадный + генетический) и оценить качество относительно существующих раскладок.
- Задача 1. Собрать открытые данные о населённых пунктах и рельефе.
- Задача 2. Формализовать целевую функцию (число покрытых жителей / стоимость).
- Задача 3. Реализовать и сравнить два алгоритма.
- Задача 4. Оценить результаты, построить тепловые карты покрытия.
Структура: Глава 1 — теория покрытия и модели радиораспространения. Глава 2 — проектирование алгоритма и структур данных. Глава 3 — эксперименты, метрики, внедрение.
Тема 3. Микросервисная платформа отчётности для распределённого телеком-проекта
Актуальность. За пять лет — 1,8 млн новых пользователей. Кто-то эти цифры собирал по регионам, сверял и публиковал. Это работа для распределённой системы отчётности с консолидацией данных.
Цель: спроектировать и реализовать платформу сбора KPI по регионам с REST API и экспортом в аналитические отчёты.
- Задача 1. Провести сравнительный анализ монолита и микросервисов.
- Задача 2. Спроектировать схему БД и API (OpenAPI 3.x).
- Задача 3. Реализовать сервисы, настроить CI/CD-пайплайн.
- Задача 4. Провести нагрузочное тестирование, обосновать выбор СУБД.
Аналитическая глава: как использовать статью для обоснования темы
Первая глава ВКР обычно самая скучная — и самая уязвимая на защите. Здесь новость из CNews работает как якорь: не нужно выдумывать «актуальность», у вас есть дата, цифра и государственный контекст.
| Что писать в главе 1 | Как привязать к статье |
|---|---|
| Обзор предметной области | УЦН 2.0 как пример крупного проекта с 1,8 млн бенефициаров |
| Постановка проблемы | Развёрнутая инфраструктура требует наблюдаемости и учёта |
| Обзор аналогов | Сравнение OSS-инструментов мониторинга (Prometheus, Zabbix, NetBox) |
| Стандарты | ISO/IEC 25010 (качество ПО), ISO/IEC 27001 (безопасность), ГОСТ 34.602-89 (ТЗ) |
Отдельно стоит вынести сравнение вариантов архитектуры. Например, монолит против микросервисов для системы отчётности, или push-модель сбора телеметрии против pull-модели. Обязательно указывайте критерии: масштабируемость, стоимость сопровождения, порог входа команды.
Проектная часть: где именно появляются схемы
Вторая глава — это место, где дипломники чаще всего «плывут». Спасает конкретика. Сразу зафиксируйте: контекстная диаграмма (C4 Level 1), диаграмма компонентов (C4 Level 2 или UML component), sequence-диаграмма для критичного сценария и ER-модель.
Если тема связана с мониторингом, обязательно откройте диаграмму развёртывания: где крутится Kubernetes, где брокер сообщений, где база временных рядов (например, TimescaleDB или VictoriaMetrics), как проходит поток метрик через OpenTelemetry Collector.
Схема потока данных (упрощённо):
base_station → otel-collector → kafka → aggregator → timeseries_db → grafana
Такая схема — уже половина защиты. Потому что комиссия любит спрашивать «а почему Kafka, а не RabbitMQ» и «почему именно временные ряды». Если у вас есть обоснование в тексте — вы победили.
Тестирование и метрики: где взять цифры для третьей главы
Финальная глава ВКР без чисел — это провал. Источники метрик можно взять из нескольких мест: открытые порталы с геоданными, документация проекта УЦН, синтетические данные, сгенерированные нагрузочные тесты.
| Метрика | Как измерять | Целевое значение |
|---|---|---|
| Пропускная способность API | Apache JMeter / k6 | от 500 rps |
| RTO | Сценарий отказа узла | ≤ 15 мин |
| RPO | Репликация PostgreSQL | ≤ 5 мин |
| Доступность сервиса | SLA-мониторинг | 99,5%+ |
| Время отклика UI | Lighthouse / WebPageTest | ≤ 2,5 с (LCP) |
Отдельно опишите схему нагрузочного тестирования: сколько виртуальных пользователей, какой профиль, как эмулировались базовые станции. Даже если вы тестируете прототип на ноутбуке — это нормально, главное — методология.
Чему вы научитесь, если возьмёте такую тему
- Проектировать распределённые системы с обоснованием каждого компонента.
- Работать с инструментами наблюдаемости: OpenTelemetry, Prometheus, Grafana.
- Оформлять техническую документацию по ГОСТ 34.602-89 и ГОСТ 19.201-78.
- Строить UML- и C4-диаграммы, защищать архитектурные решения.
- Считать экономику внедрения и сравнивать альтернативы по TCO.
- Проводить нагрузочное тестирование и корректно интерпретировать метрики.
Типичные ошибки студентов при работе с такими темами:
- Подмена понятий «проект» и «система». УЦН — это проект, а вы пишете ВКР про информационную систему. Разделяйте: что делает государство, а что делает ваш софт. Иначе комиссия утопит в вопросах.
- Отсутствие метрик эффективности. Фраза «система работает быстро» — не аргумент. Нужны числа: rps, latency, RTO/RPO, процент покрытия.
- Игнорирование ГОСТ при оформлении ТЗ. ГОСТ 34.602-89 никто не отменял. Если в задании на ВКР указан этот стандарт — оформляйте техническое задание строго по нему, иначе снимут баллы на нормоконтроле.
- Копирование архитектуры из чужих дипломов. Схема из интернета без адаптации под вашу задачу видна сразу. Перерисовывайте под свои компоненты.
Чек-лист «Что проверить перед сдачей»
- Ссылка на первоисточник (CNews, 25.03.2026) стоит в аналитической главе и в списке литературы.
- Задачи из введения дословно совпадают с выводами по главам.
- Все схемы подписаны, имеют номера и упоминаются в тексте.
- ТЗ оформлено по ГОСТ 34.602-89, если этого требует вуз.
- Метрики в третьей главе сопоставлены с целевыми значениями.
- Список литературы содержит не менее 20 источников, из них 5–7 — свежие (2023–2026).
- Проверка на антиплагиат пройдена, оригинальность не ниже порога кафедры.
- Все аббревиатуры расшифрованы при первом упоминании.
FAQ: что чаще всего спрашивают перед защитой
Обязательно ли писать рабочий код для такой темы?
Не всегда. Если тема ближе к анализу или проектированию, достаточно прототипа и подробных схем. Но если в задании указано «разработать», без кода не обойтись. Минимально — рабочий MVP с ключевой функцией и тестами.
Где брать тестовые данные о населённых пунктах и покрытии?
Открытые источники: OpenStreetMap, Росстат, портал Госуслуг по проекту УЦН, данные операторов в открытой печати. Плюс всегда можно сгенерировать синтетические данные с реалистичным распределением.
Как оформить UML-диаграммы, если вуз не требует конкретную нотацию?
Используйте C4 для архитектуры (контекст, контейнеры, компоненты) и UML для последовательностей и классов. Инструменты: PlantUML, diagrams.net, Mermaid. Главное — единый стиль по всей работе.
Насколько сложно защищать тему, если я не телеком-инженер?
Проще, чем кажется. Вы защищаете ИТ-решение, а не работу базовой станции. Комиссия оценивает архитектуру, обоснование стека и метрики — это чистая software-инженерия.
Если тема уже выбрана, но непонятно, как её разложить на главы, задачи и метрики — начните с бесплатной консультации. Мы поможем спроектировать структуру ВКР, подобрать стек и оформить документацию. Средний объём работы под ключ — 120 часов, сроки обсуждаем индивидуально.
Источник: 1,8 млн человек появились в онлайне — за пять лет реализации второго этапа проекта устранения цифрового неравенства (опубликовано 2026-03-25)