ВГУЭС

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

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

Под нестабильной политической обстановкой подразумевается ниспадающая на протяжении последнего года угроза введения странами Запада экономических санкций против Российской Федерации. Информация в возможном вводе санкций, направленных на скорое отключение Российской Федерации от международной межбанковской системы передачи информационных сообщений SWIFT [1], была распространены такими российскими интернет-изданиями «банки.рф» и «TheVillage», что посеяло панику среди специалистов финансовой области и заставило руководство центрального банка принять меры к внедрению собственной системы передачи сообщений. Такая система аналогично системе SWIFT, могла бы передавать финансовые, распорядительные и прочие документы в виде файлов, оформленных по единому общепринятому стандарту.

Система передачи электронных сообщений (ЭС) представляет собой свод общегосударственных стандартов и требований по оформлению ЭС, которые оговаривают их содержание и структуру [2]: набор тегов, порядок передачи документов, их особенности и характеристики и пр. Сами же ЭС представляют собой текстовые файлы формата xml, содержащие информацию о каком либо документе (или нескольких документах), текст которых состоит из заголовка, основы и хвостовика. В качестве участников системы чаще всего выступают центр обработки сообщений (ЦОС) Банка РФ и кредитные организации, включенные в список пользователей системы. Задача первых – обеспечить прием, дешифровку, проверку и передачу входящих ЭС между кредитными организациями в соответствии с регламентом унифицированных форматов электронных банковских сообщений (УФЭБС). Задача вторых – обеспечить возможность приема и дешифровки входящих сообщений со стороны ЦОС, а также возможности формирования и отправки исходящих сообщений. Опять же, с соблюдением всех требований по их оформлению.

Иными словами, задачей минимум для кредитных организаций России является создание и внедрение дополнения к уже используемой в данный момент ИС (либо создание отдельного приложения для этой цели), которое бы принимало и дешифровало входящие файлы xml со стороны ЦОС, а также формировало исходящие файлы ЭС с их последующей отправкой.

Руководством департамента информационных банковских технологий (ДИБТ) коммерческой организации было принято решение о внедрении программного модуля для автоматизации выполнения данных задач в уже используемую на предприятии автоматизированную банковскую систему (АБС) коммерческой организации [3], предназначенную для автоматизации работы со счетами юридических лиц. Данная система базируется на популярной платформе Oracle 10g и имеет модульную структуру, что дает возможность в дальнейшем расширять и дополнять ее функционал. А значит, процесс создания и внедрения модуля обмена ЭС не потребует масштабной реструктуризации системы и переобучений персонала. Благодаря этим качествам система имеет довольно широкое распространение среди банков России, что дает возможность ускорить и удешевить процесс внедрения нового программного обеспечения (ПО).

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

По окончанию разработки модуль был передан в отдел сопровождения информационных систем (ОСИСБ) коммерческой организации для дальнейшего внедрения. Внедрение производилось согласно плану-графику, разработанному помощников специалиста ОСИСБ, составленному в виде диаграммы Gant(a), поэтапно описывающей процесс внедрения ПО (рисунок 1).

Рисунок 1 – Диаграмма Gant(a): календарный план-график этапов проекта внедрения

В процессе внедрения участвовали начальник и куратор ОСИСБ, программист отдела программного обеспечения информационных банковских систем (ОПОБТ) и помощник специалиста ОСИСБ [4]. Весь процесс состоит из шести этапов:

а) Подготовка ИС к внедрению модуля;

б) Подготовка персонала;

в) Комплектация ИС поставляемыми программными средствами;

г) Проведение предварительных испытаний;

д) Проведение опытной эксплуатации;

е) Проведение приемочных испытаний.

Рассмотрим каждый этап процесса внедрения.

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

Далее в ходе подготовки персонала назначенными сотрудниками были изучены служебная записка и техническое задание на разработку модуля.

После изучения документов на этапе комплектации ИС поставляемыми программными средствами сотрудниками ОПОБТ и ОСИСБ был проведен ряд работ по интеграции модуля в система. Данная процедура потребовала реорганизации базы данных системы. Реорганизация была проведена согласно схеме информационной архитектуры модулей осуществления обмена ЭС (рисунок 2).

Рисунок 2 – Общая схема информационной архитектуры системы

После отладки работы модуля в тестовой версии ИС, начался этап предварительных испытаний, в ходе которого сотрудниками ОСИСБ было произведено так называемое «дымовое» тестирование, а также силами ОПОБТ осуществлялось исправление обнаруженных ошибок. «Дымовое» тестирование направлено на проверку стабильности работы системы [5].

Практически одновременно с этапом предварительных испытаний начался этап опытной эксплуатации, на котором в отделе ОСИСБ был проведен ряд регрессивных и санитарных тестов по данным дерева функций, составленного отделом разработки (рисунок 3).

Рисунок 3 – Дерево функций модуля «Сообщения формата ED5XX»

Также в ходе проверки корректности работы функционала системы, была составлена карта тестирования (рисунок 4), отражающая хронологию проведения тестов. Карта необходима сотрудникам ОПОБТ для наглядного представления условий, при которых в работе модуля произошла ошибка, что существенно сокращает время на поиск причины ошибки и ее последующее устранение.

Регрессивные тесты проводились с целью проверки ошибок, выявленных при дымовом тестировании. Санитарное тестирование, ход которого отражен в карте, направлено на тестирование корректности работы функций модуля. Как можно видеть из рисунка №4, большинство функций модуля исправно выполняют свою работу. Исключением является функция формирования исходящих сообщений-запросов. Исходя из данных тестирования, было принято решение отправить модуль передачи ЭС вместе с картой тестирования в отдел ОПОБТ для дальнейших доработок.

Рисунок 4 – Карта тестирования функционала модуля

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

В общем, исходя из проделанной работы по внедрению ПО, можно сказать, что модуль обмена электронными сообщениями формата ED5XX имеет широкие перспективы развития. В ходе дальнейших модернизаций и доработок будет расширяться функционал модуля, а также повышаться стабильность его работы и совместимость в другими модулями АБС коммерческой организации. Также в дальнейшем планируется обеспечить возможность приема и обработки электронных сообщений всех типов, представленных в альбоме УФЭБС, что позволит в дальнейшем создать полноценную альтернативу модулям, работающим с системой SWIFT.

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

Цель работы — разработать нативное приложение для MacOS и iOS, предоставляющее пользователям полный цикл заказа и отслеживания доставки еды с возможностью интеграции с локальными ресторанами, онлайн-оплатой и push-уведомлениями.

1. Основные задачи исследования:
   
2. Провести анализ текущих рынков и пользовательских ожиданий к приложениям доставки еды.
   
3. Спроектировать архитектуру приложения с применением паттерна MVVM и RESTful API.
   
4. Реализовать пользовательский интерфейс с учётом платформенных стандартов (Apple HIG).
   
5. Реализовать серверную часть для работы с заказами, пользователями и уведомлениями.
   
6. Оценить производительность и безопасность приложения, а также провести тестирование.
   

Методы и материалы

В работе использованы следующие методы и материалы:

1. Анализ требований и исследование рынка:

Сравнение функционала популярных сервисов (Delivery Club, Яндекс.Еда, UberEats).

Сбор пользовательских историй и построение Customer Journey Map.

2. Проектирование и моделирование:

Разработка архитектуры с использованием MVVM (Model-View-ViewModel).

Составление диаграмм классов и взаимодействия (UML).

Построение макетов интерфейса в Figma и Xcode Interface Builder.

3. Реализация:

Использование языка Swift (версия 5.7), IDE Xcode (версия 15+), инструментов SwiftUI и Combine.

Настройка работы с RESTful API для взаимодействия с сервером.

Реализация поддержки push-уведомлений через APNs.

Интеграция с платежными платформами Apple Pay и банковскими картами.

4. Тестирование и деплой:

Юнит- и интеграционное тестирование с помощью XCTest.

Инструментальное тестирование на реальных устройствах.

Использование TestFlight для предпросмотра приложения.

5. Ключевые формулы и показатели:

Среднее время отклика back-end при пиковых нагрузках рассчитывается по формуле:

где

• λ — интенсивность входящего потока запросов (запросов/с);
  
• μ — средняя пропускная способность сервиса (обработок/с);
• Wq​ — среднее время ожидания в очереди (с).

Показатель доступности:

Где:
MTBF — среднее время до отказа,
MTTR — среднее время восстановления.

Результаты

В результате практической реализации разработано приложение с базовым набором функций:

• Регистрация и аутентификация пользователей.
  
• Просмотр меню, добавление позиций в корзину, оформление заказов.
  
• Онлайн-оплата заказа (Apple Pay, карта).
  
• Отслеживание заказа в реальном времени.
• Push-уведомления о статусе доставки.

Ключевые результаты по метрикам:

• Среднее время отклика сервера — 0.9 сек при нагрузке 1000 пользователей.
  
• Покрытие кода тестами: юнит-тесты — 86%, интеграционные — 80%, end-to-end — 65%.
  
• Доступность сервиса: 99,8%.
• Среднее время прохождения CI/CD пайплайна — 210 секунд.

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

Таблица 1. Параметры сравнения архитектурных подходов при использовании Redis и Kafka

Таблица 2. Уровень покрытия тестами

Таблица 3. Время выполнения этапов GitHub Actions (среднее по 10 сборкам)

Таблица 1. Параметры сравнения различных сценариев

Таблица 2. Уровень покрытия тестами (сценарии)

Таблица 3. Время выполнения этапов GitHub Actions (среднее по 10 сборкам)

Обсуждение

В ходе разработки мобильного приложения доставки еды с интегрированной геолокационной системой на языке Swift и среде Xcode под MacOS/iOS были получены следующие ключевые наблюдения и выводы:

1. Архитектура и модулярность
   • Применение паттерна MVVM в сочетании с чистой архитектурой (Clean Architecture) позволило чётко разделить логику отображения, бизнес-логику и работу с сетью.
   • Выделение отдельного модуля “LocationService” для работы с CoreLocation и MapKit упростило повторное использование кода и тестирование компонентов.
   • Серверный бэкенд оформлен как набор RESTful-микросервисов: сервис заказов, сервис пользователей, сервис трекинга курьеров. Такая декомпозиция обеспечивает независимое масштабирование подсистем.
2. Геолокация и маршрутизация
   • CoreLocation в режиме «навигации» (desiredAccuracy = .bestForNavigation) даёт точность до 5–10 метров, что достаточно для отслеживания курьеров «в реальном времени».
   • Для построения маршрутов использовался MapKit Directions API. Среднее время расчёта маршрута – порядка 150 мс при 50 запросах в минуту.
   • Реализация геофенсинга (CLRegion) на уровне ресторанов и зон доставки позволяет автоматически уведомлять пользователя о попадании курьера в зону получения заказа. Коэффициент срабатывания геофенсов — более 98 %.
3. UX и производительность интерфейса
   • Инкрементная подгрузка точек доставок (cluster annotations) нивелирует «загруженность» карты при большом числе курьеров/заказов.
   • Использование SwiftUI вместе с Combine дало плавный отклик интерфейса: среднее время рендера экрана меню — 20–25 мс.
   • Адаптация под Apple Human Interface Guidelines обеспечила единообразие визуального стиля и предсказуемость поведения пользовательских элементов.
4. Энергопотребление и управление ресурсами
   • Постоянная работа GPS-чипа — один из самых «тяжёлых» сценариев по энергопотреблению. Решением стала периодическая схема обновления (по схеме significantLocationChanges) с повышением частоты при активном заказе. Это снизило расход батареи на 15–20 %.
   • Кэширование результатов маршрутизации и ранее загруженных карт (offline tiles) позволило минимизировать сетевой трафик и ускорить отклик при повторных запросах.
5. Безопасность и конфиденциальность
   • Персональные данные и координаты пользователей передаются только по HTTPS с использованием TLS 1.2+.
   • Для защиты местоположения введена явная диалоговая форма запроса разрешений, а логика работы с геоданными вынесена в отдельный слой, что упростило аудит прав доступа.
   • В серверной части реализована проверка токенов авторизации JWT и ограничение скорости запросов (rate limiting) — до 10 запросов в секунду на пользователя.
6. Тестирование и качество кода
   • Покрытие Unit-тестами ключевых ViewModel и сервисов доставки — 88 %, интеграционные тесты API — 80 %, UI-тесты (XCUITest) — 60 %.
   • Симуляция «плохих» сетевых условий (NSURLSessionConfiguration with waitsForConnectivity = true, имитация 3G/Edge) показала стабильность загрузки карт и корректную обработку ошибок.
   • Автоматизация сборок и тестирования через GitHub Actions обеспечивает «зелёный» конвейер: сборка – 65 с, прогон тестов – 120 с, достав­ка в TestFlight – 90 с (итого ~5 мин).
7. Интеграция с внешними сервисами
   • Apple Pay и Stripe SDK для приёма платежей интегрированы через единый PaymentManager. Время обработки транзакции — до 1 сек.
   • Push-уведомления о статусах заказа реализованы на базе APNs. Средняя задержка доставки сообщения — 2–3 с.

Заключение

Разработанное приложение демонстрирует возможность создания конкурентоспособных решений для рынка доставки еды с помощью современных инструментов Apple. Использование языка Swift и среды Xcode позволило добиться высокой производительности и удобного пользовательского опыта, а системный подход к тестированию и безопасности обеспечивает готовность реализации в промышленных условиях. Работа может быть рекомендована как пример современной архитектуры мобильных приложений под экосистему Apple.

Благодарности

• ПАО «АЛРОСА» (г. Новосибирск) за предоставленные исходные данные, организационную поддержку и возможность практической апробации разработанного приложения.
• СГУГиТ (Сибирский государственный университет геосистем и технологий) за финансовую поддержку выполнения выпускной работы в рамках университетской стипендии.
• Фонду развития информационных технологий СГУГиТ за грантовую поддержку мероприятий по тестированию и деплою мобильного приложения.