# Инженерный тур заключительного этапа ## 📖 Предыстория В компании S есть возможность бронирования мест в пространствах, предназначенных под общее использование (open-space). На данный момент для бронирования места используются различные способы бронирования, разработанные в каждом офисе индивидуально. Администрации компании S требуется мобильное приложение, как для рядовых сотрудников, так и для администрации с возможностью просмотра забронированных мест. ## 📑 Системные требования к приложению - Минимальная версия ОС: Android 9.0 (API 28) - Целевая версия ОС: Android 16 (API 36) - Работоспособность приложения для платформ: mobile (смартфоны), tablet (планшеты) - Поддерживаемая ориентация: portrait (портретная), landscape (альбомная) - Поддержка языков: русский, английский - Разрешения: доступ к интернету ### Технический стек для frontend: - Kotlin - Ktor - MVVM/MVI ### Технический стек для backend: - Java 17 - Spring Boot - PostgreSQL - Liquibase - Docker - H2 ### Технический стек и платформы для дизайнеров: - PenPot - Material Design - Compose - Auto Layout - Interactive Prototypes ## 📂 Оцениваемые артефакты работы - Репозиторий команды клиентской части приложения в Gitea. - Репозиторий команды серверной части приложения в Gitea. - Файл доски с макетом клиентской части приложения в разделе Releases репозитория команды на Gitea. Файл должен быть с расширением .penpot. - Релизный APK-файл приложения в разделе Releases репозитория команды на Gitea. - FatJar-файл для запуска серверного приложения для заданий: 0, 1 и 2. FatJar-файл необходимо разместить в разделе Releases репозитория команды на Gitea. На 3-ем задании необходимо добавить Docker-файл для приложения и Docker-compose (с двумя контейнерами: PostgreSQL и само серверное приложение), с помощью которого можно развернуть и запустить серверную часть. **Важно**: если серверное приложение переведено на PostgreSQL, то наличие Docker-compose обязательно. Описанные выше артефакты оцениваются на каждом чекпоинте. APK-файл и JAR-файл должны иметь следующее имена: Client_vN.apk и Server_vN.jar, где N — номер Чекпоинта. ## ❗️ Чекпоинты Чекпоинт — фиксированный момент времени, в который начинается техническая экспертиза решения задания инженерного тура. Каждый чекпоинт содержит описание функциональности, которую необходимо реализовать участникам. Расписание чекпоинтов представлено ниже: **Чекпоинт 0 — 24.02 в 19:00** **Чекпоинт 1 — 25.02 в 14:00** **Чекпоинт 2 — 25.02 в 19:00** **Чекпоинт3 — 26.02 в 14:30** ## 🛠 Техническое задание Требуется доработать нативное мобильное приложение, выполненное в рамках второго отборочного этапа. Ссылки на проекты-заготовки: Клиентская часть: https://gitnto.innovationcampus.ru/NTO-2026/NTO-2026-Android-TeamTask-Template Серверная часть: https://gitnto.innovationcampus.ru/NTO-2026/NTO-2026-Backend-TeamTask-Template Верстка приложения должна полностью соответствовать макетам в PenPot. Соответствие макетам является обязательным и оценивается на каждом чекпоинте. В PenPot необходимо отдельно оформить палитру цветов, используемые шрифты и типографику, типы кнопок во всех состояниях, поля ввода во всех состояниях, а также элементы навигации. Приложение должно поддерживать дневную и ночную темы. Интерфейс обязан корректно адаптироваться к динамическому изменению ширины экрана и перестраивать компоновку без потери состояния. Состояние экранов и пользовательский ввод должны сохраняться при повороте устройства. ## Задание 0. Развертывание исходных данных (~2 часа) **Дедлайн сдачи артефактов: 24.02 в 19:00** Цель: настроить среду для последующей работы. Необходимо создать форки исходных репозиториев-заготовок в организации вашей команды в Gitea, а затем собрать все необходимые артефакты для оценивания работы. На доске в PenPot необходимо отдельно оформить палитру цветов, используемые шрифты и типографику (UI Kit). ## Задание 1. Усиливаем безопасность (~3 часа) **Дедлайн сдачи артефактов: 25.02 в 14:00** Цель: повысить безопасность системы авторизации, поскольку приложение в будущем будет опубликовано для широкой аудитории. Требования: - Заменить текущую систему ввода кода на логин и пароль. - Имплементировать один из протоколов авторизации (OAuth, CAS или т.п.) - Новый алгоритм авторизации должен быть поддержан во всем функционале приложения. - Предусмотреть возможность обработки ошибок во время авторизации, таких как отсутствие интернета у устройства и т.п. - Предусмотреть все состояния UI: пустые поля, ошибки валидации, ошибка "Неверный логин/пароль", состояние загрузки при запросе к серверу, состояние блокировки после 5 неудачных попыток. - Хранить авторизационные данные в защищенном хранилище или зашифрованном виде. - Предотвратить перебор логина и пароля на стороне клиента (уменьшить вредоносный трафик). Перебором считается ввод неверных данных более 5 раз. Добавить визуальную обратную связь пользователю при зафиксированном переборе пароля. - На уровне ОС ограничить возможность записи экрана и создания скриншотов (при поддержке ОС). - Доработать UI Kit. Ограничения: - Логин должен включать в себя следующий набор символов: .; a-z; A-Z; 0-9; - Пароль должен: - состоять не менее чем из 8 символов; - не повторять один и тот же символ 3 и более раз; - содержать не менее 1 спецсимвола; - не содержать в себе 3 и более символа из логина. Например, если логин user, то пароль не может содержать следующий набор символов: use, Use, ser, sEr и тп. Регистр значения не имеет. Поощряется добавление любых иных мер, усиливающих безопасность учетной записи. **Для прохождения на код-ревью, в приложение должны выполняться следующие сценарии:** - Корректная работа без интернета - Ввод неверных данных - Успешный вход