Опубликовано: 15.09.2026 | Источник: CNews (новости)

Мобильный банк для МСБ в ВКР: разбор кейса «БСПБ.Бизнес» и три защищаемые темы

24 марта 2026 года банк «Санкт-Петербург» выпустил обновление «БСПБ.Бизнес» — мобильного приложения для клиентов малого и среднего бизнеса. За сухим пресс-релизом стоит вполне инженерная история: обновление клиента неизбежно тянет за собой пересборку API-шлюза, пересмотр модели прав доступа для нескольких ролей (владелец ИП, бухгалтер, подписант), доработку push-уведомлений и повторную валидацию качества по ISO/IEC 25010. Именно этот пласт и интересен выпускнику: он ложится в главы 2–3 диплома без «воды» и легко проверяется на защите. Ниже — как из новости сделать тему ВКР, какие артефакты приложить и какие метрики посчитать, чтобы комиссия увидела инженера, а не реферат.

Основная часть: от кейса банка к структуре работы

Поддомен здесь — Backend/Frontend и мобильная архитектура финтех-сервиса. Роль эксперта — архитектор ПО. Держите в голове три сущности, вокруг которых строится защита: C4/UML для проектирования, OWASP MASVS для безопасности мобильного клиента и ISO/IEC 25010 для измеримого качества. ГОСТ 34.601 задаёт стадии, поэтому главы работы удобно разложить по его логике: анализ → проектирование → реализация → испытания.

Тема 1. Проектирование платёжного модуля для МСБ с идемпотентным API

Актуальность: обновление «БСПБ.Бизнес» показывает, что банки конкурируют не за фичи, а за надёжность массовых платежей. Цель: спроектировать и реализовать модуль проведения платежей с гарантией «ровно один раз».

Задачи: 1) проанализировать предметную область и роли пользователей; 2) построить C4-диаграммы контекста и контейнеров; 3) реализовать REST-эндпоинт с ключом идемпотентности; 4) провести нагрузочное тестирование и снять метрики p95/p99.

Структура: Глава 1 — анализ МСБ-сегмента и аналогов; Глава 2 — проектирование (C4, OpenAPI-спека, схема БД); Глава 3 — реализация, нагрузочные тесты, расчёт SLO 99,9% и бюджета ошибок.

Тема 2. Оценка качества мобильного банка по ISO/IEC 25010

Актуальность: любое обновление клиента — это релиз, который надо измерить. Цель: построить методику оценки восьми характеристик качества на примере приложения для МСБ.

Задачи: 1) формализовать метрики (crash-free sessions, время холодного старта, точность синхронизации); 2) собрать данные через OpenTelemetry; 3) рассчитать интегральный показатель; 4) сравнить с предыдущим релизом (регресс/улучшение).

Структура: Глава 1 — теория качества ПО и стандарт; Глава 2 — методика, выбор инструментов, схема сбора телеметрии; Глава 3 — эксперимент, таблицы метрик, выводы и рекомендации банку-прототипу.

Тема 3. Безопасность мобильного клиента для бизнеса по OWASP MASVS

Актуальность: корпоративный банкинг — цель №1 для мобильных атак, а MASVS даёт готовую матрицу проверок. Цель: провести аудит прототипа и закрыть критичные категории риска.

Задачи: 1) разобрать MASVS-L1/L2; 2) внедрить OAuth 2.0 с PKCE и хранение токенов в защищённом хранилище; 3) проверить устойчивость к перехвату (SSL pinning, root detection); 4) составить отчёт с матрицей угроз STRIDE.

Структура: Глава 1 — модель угроз и нормативная база; Глава 2 — архитектура защиты, схемы последовательностей аутентификации; Глава 3 — результаты пентеста прототипа и план устранения.

Что показать в главе 2: OpenAPI и идемпотентность

Не прячьте код в приложения «для галочки» — фрагмент должен появляться прямо в тексте главы с пояснением. Минимальный рабочий контракт платёжного эндпоинта выглядит так:

paths:
  /v1/payments:
    post:
      operationId: createPayment
      parameters:
        - name: Idempotency-Key
          in: header
          required: true
          schema: { type: string, format: uuid }
      requestBody:
        content:
          application/json:
            schema: { $ref: '#/components/schemas/PaymentRequest' }
      responses:
        '201': { description: Создан }
        '409': { description: Дубликат ключа }
        '422': { description: Ошибка валидации реквизитов }

Дальше — псевдокод обработки: ключ идемпотентности пишется в Redis с TTL 24 часа до начала транзакции, при повторе возвращается закешированный ответ. Это 15 строк, которые комиссия любит больше, чем «мы использовали микросервисы». Диаграмму последовательности для аутентификации по OAuth 2.0 + PKCE рисуйте в PlantUML — её легко сгенерировать в SVG и вставить как рисунок по ГОСТ.

Что считать в главе 3

Три группы метрик закрывают вопрос «а где эффективность?». Технические: p95/p99 задержки, throughput, error rate, доступность. Продуктовые: конверсия из логина в платёж, retention, время до первой транзакции. Инженерные: частота деплоев, lead time, доля откатов. Свяжите их с SLO и посчитайте бюджет ошибок — это уже уровень зрелой защиты, а не студенческой.

FAQ

Насколько сложна тема на фоне остальных ВКР?

Средняя. Основная сложность — не код, а дисциплина проектирования: C4-схемы, контракты, метрики. Если у вас есть базовый опыт с REST и Docker, вы укладываетесь в стандартный семестр. Помощь с дипломом здесь чаще нужна не в реализации, а в приведении артефактов к ГОСТ.

Где брать данные, если банк закрыт для исследований?

Синтетические датасеты на генераторах + публичные API-песочницы. Требования к приложению для МСБ берите из открытых спецификаций и пресс-релизов (как у «БСПБ.Бизнес»), а тестовые данные генерируйте скриптом — это законная практика и её ценят на защите.

Как оформить схемы — UML или C4?

Оба. C4 даёт верхнеуровневую картину (контекст, контейнеры), UML — детали (последовательности, состояния). ГОСТ 34.601 не требует конкретной нотации, поэтому согласуйте с нормоконтролем единый стиль подписей и нумерации рисунков.

Можно ли «заказать диплом» по такой теме целиком?

Технически можно, но комиссия задаёт вопросы по коду и метрикам — поэтому проще взять тему и собрать её с консультантом, разобравшись в деталях. Так вы защититесь уверенно.

Чек-лист перед сдачей

Типичные ошибки студентов

Источник: Банк «Санкт-Петербург» обновил «БСПБ.Бизнес» (опубликовано 2026-03-24)