Сервисы планирования задач в ВКР: архитектура, метрики и экономика внедрения
25 марта 2026 года аналитики Yota опубликовали любопытную цифру: интерес россиян к сервисам планирования с начала года вырос почти вдвое. Это не абстрактный «тренд на продуктивность» — это рост числа активных сессий, регистраций и уведомлений, то есть реальная нагрузка на инфраструктуру. Для выпускника ИТ-направления такая новость — подарок. Во-первых, появляется внешнее, проверяемое обоснование актуальности (комиссия это ценит выше фразы «в современном мире»). Во-вторых, сам предмет — планировщик — даёт богатую почву для архитектурных решений: синхронизация, часовые пояса, оффлайн-режим, уведомления. Ниже — как разложить эту тему на три главы, чем наполнить расчётную часть и какие метрики не стыдно показать на защите.
Три темы ВКР, которые вырастают из этой статьи
1. Кроссплатформенный планировщик с синхронизацией календарей
Актуальность. Рост спроса в 2 раза означает, что пользователь уже попробовал минимум один сервис и готов мигрировать, если новый закрывает боль синхронизации между устройствами.
Цель: сократить долю ручных операций при переносе задач между календарями до нуля за счёт двусторонней синхронизации по CalDAV.
- проанализировать аналоги (Google Calendar, Notion Calendar, TickTick) по критериям из таблицы ниже;
- спроектировать модель данных и контракт API, устойчивый к конфликтам версий;
- реализовать повторяющиеся события через RFC 5545 (RRULE);
- провести нагрузочное тестирование и посчитать стоимость владения.
Структура: Глава 1 — анализ рынка и постановка задачи; Глава 2 — архитектура, ER-модель, UML-диаграммы; Глава 3 — реализация, тестирование, экономика внедрения.
2. Прогнозирование пиковой нагрузки сервиса по телеметрии
Актуальность. Резкий приток пользователей — это скачки трафика в понедельник утром и в начале месяца. Без прогноза автоскейлинг либо переплачивает, либо роняет сервис.
Цель: построить модель краткосрочного прогноза RPS с ошибкой MAPE не выше 15%.
- собрать метрики через OpenTelemetry и сохранить их в Prometheus;
- подготовить временные ряды и разметить аномалии;
- сравнить SARIMA, Prophet и градиентный бустинг;
- оценить экономический эффект от упреждающего масштабирования.
Структура: Глава 1 — обзор методов прогнозирования; Глава 2 — пайплайн сбора данных и архитектура; Глава 3 — эксперименты и расчёт экономии.
3. Интеллектуальный планировщик с оптимизацией расписания
Актуальность. Массовый пользователь уже умеет создавать задачи; следующий шаг продукта — расставлять их самому. Это логичное продолжение тренда, зафиксированного в статье.
Цель: автоматизировать распределение задач по временным слотам с учётом дедлайнов, длительности и приоритетов.
- формализовать задачу как вариант задачи о ранце / job-shop;
- реализовать эвристику и сравнить с точным решением на малых размерностях;
- встроить планировщик в существующий REST API;
- оценить субъективную и объективную эффективность расписания.
Структура: Глава 1 — теория расписаний; Глава 2 — алгоритм и интеграция; Глава 3 — метрики качества расписаний.
Аналитическая глава: сравнение решений и обоснование стека
Первая глава не должна превращаться в реферат. Сделайте её инструментом: таблица сравнения аналогов сразу задаёт критерии, которым потом подчиняется проектирование.
| Критерий | Готовые SaaS | Открытые решения (self-hosted) | Ваш прототип |
|---|---|---|---|
| Двусторонняя синхронизация | Есть, по проприетарному протоколу | CalDAV, есть ограничения | CalDAV + вебхуки |
| Оффлайн-режим | Частично | Зависит от клиента | PWA + IndexedDB |
| Открытый API | Ограничен тарифом | Полный доступ | REST + OpenAPI 3.1 |
| Стоимость владения | Подписка на пользователя | Зависит от инфраструктуры | Инфраструктурная себестоимость |
| Расширяемость | Нет | Плагины | Модули ядра |
Обоснование стека удобно привязать к требованиям ISO/IEC 25010: под каждый атрибут качества — конкретная технология. Комиссия любит такую связку: не «взяли PostgreSQL, потому что популярный», а «выбрали PostgreSQL, потому что нужны транзакции и частичные индексы для задач с разными типами повторения».
| Атрибут качества | Решение | Обоснование |
|---|---|---|
| Производительность | Redis + материализованные представления | Кэш агрегированного дня, инвалидация по событию |
| Масштабируемость | Kubernetes, HPA | Горизонтальное масштабирование под пики начала недели |
| Надёжность | Репликация, бэкапы, RPO ≤ 15 мин | Требование к сохранности пользовательских данных |
| Сопровождаемость | CI/CD-пайплайн, линтеры, тесты | Снижение стоимости изменений |
Проектная часть: схемы, протоколы и одна честная деталь
Оформляйте диаграммы заранее и по правилам: схемы алгоритмов и данных — по ГОСТ 19.701-90, функциональные требования — по ГОСТ 34.602-89. UML-диаграммы (use case, последовательности, развёртывания) не заменяют ГОСТ, а дополняют его. Типичный набор для планировщика: контекстная диаграмма, ER-модель, sequence для сценария синхронизации, deployment для Kubernetes.
Отдельно продумайте идемпотентность: повторная отправка задачи из оффлайн-клиента не должна плодить дубликаты. В дипломе это отличный инженерный аргумент — покажите контракт с ключом идемпотентности и объясните логику разрешения конфликтов.
POST /api/v1/tasks
Idempotency-Key: 6f1c9a2e-...
{
"title": "Спринт-ревью",
"rrule": "FREQ=WEEKLY;BYDAY=FR;COUNT=12",
"timezone": "Europe/Moscow",
"sync_targets": ["caldav", "webpush"]
}
Обратите внимание на часовой пояс: хранение времени только в UTC и конвертация на клиенте — это классика, за которую не снимут баллы, но её отсутствие гарантирует вопросы на защите.
Тестирование и метрики: что показать вместо «работает быстро»
Здесь статья из CNews работает как источник реалистичного сценария нагрузки: рост интереса в 2 раза — это ваш входной параметр для расчёта пикового RPS. Дальше — измеримые величины.
- SLO: p95 времени ответа на GET /tasks — не выше 200 мс при 500 RPS;
- RTO/RPO: восстановление сервиса за 30 минут, потеря данных не более 15 минут;
- Нагрузочное тестирование: k6 или Yandex Tank, профиль «понедельник, 09:00»;
- Наблюдаемость: метрики OpenTelemetry → Prometheus → Grafana, трассировка критического пути синхронизации.
Пример recording rule, который пригодится и в работе, и на защите:
record: task_api:latency_p95
expr: histogram_quantile(0.95,
sum(rate(http_request_duration_seconds_bucket{job="task-api"}[5m])) by (le))
Метрики удобно свести в одну таблицу с целевыми и фактическими значениями — это снимает половину вопросов комиссии о достоверности расчётов.
| Показатель | Цель | Факт (прототип) | Метод измерения |
|---|---|---|---|
| p95 отклика API | ≤ 200 мс | 170 мс | k6, 500 RPS |
| Пропускная способность | ≥ 800 RPS | 910 RPS | Нагрузочный профиль |
| Время синхронизации | ≤ 3 с | 2,4 с | Трассировка |
| Доступность | 99,5% | 99,7% | Мониторинг |
Чему вы научитесь на такой теме
- проектировать сервис под реальный, а не выдуманный пользовательский сценарий;
- обосновывать выбор технологий через атрибуты качества, а не через моду;
- собирать и интерпретировать телеметрию, строить SLO и защищать числами;
- оформлять ТЗ и схемы по ГОСТ 34 и ГОСТ 19 без последних правок в ночь перед сдачей;
- считать экономику внедрения, а не ограничиваться разделом «выводы».
Типичные ошибки студентов
- Подмена терминов SaaS/PaaS/self-hosted без обоснования. Комиссия ловит это мгновенно. Решение: в аналитической главе дайте определения и укажите, к какому классу относится ваш прототип.
- Отсутствие метрик эффективности. «Система работает быстро» — не результат. Решение: минимум три измеримых показателя с целевыми значениями и методикой замера.
- Игнорирование ГОСТ 34.602-89 при оформлении ТЗ. Решение: вынесите ТЗ в приложение и сверьте состав разделов до защиты, а не после замечаний рецензента.
Частые вопросы
Обязательно ли писать работающий код?
Зависит от требований кафедры, но прототип резко усиливает защиту. Достаточно MVP: создание задачи, синхронизация, базовый мониторинг. Остальное можно описать как перспективы развития.
Где брать тестовые данные, если нет реальных пользователей?
Публичные наборы активности календарей плюс генератор синтетических расписаний. Обязательно опишите методику генерации — это снимает вопрос о репрезентативности.
Как измерить производительность, если нет выделенного сервера?
Локальный Kubernetes (kind, minikube) даёт воспроизводимые результаты при фиксированных лимитах CPU и памяти. Указывайте эти лимиты в главе с тестированием — иначе цифры не проверяемы.
Нужны ли UML-диаграммы, если есть схемы по ГОСТ?
Да, они решают разные задачи: ГОСТ фиксирует состав системы и алгоритмы, UML показывает взаимодействие компонентов. Дублирования не будет, если разнести их по разным разделам.
Чек-лист «Что проверить перед сдачей»
- каждая задача из введения отражена в выводах по главам;
- актуальность подтверждена ссылкой на источник с датой публикации;
- все рисунки и таблицы пронумерованы и упомянуты в тексте;
- ТЗ и схемы соответствуют ГОСТ 34.602-89 и ГОСТ 19.701-90;
- метрики содержат целевые значения и способ измерения;
- список литературы оформлен единообразно, ссылки живые.
Если тема уже выбрана, но непонятно, как собрать из неё цельную работу — начните с бесплатной консультации. Мы поможем разложить проект на главы, подобрать стек и оформить расчёты: в среднем на сопровождение уходит около 120 часов, и эти часы можно потратить на защиту, а не на поиск структуры. Помощь с дипломом возможна по любой теме — от мобильного планировщика до аналитики нагрузок.
Источник: Жизнь по плану: с начала года интерес к сервисам для планирования увеличился почти в два раза (опубликовано 2026-03-25)