Разработка билетной системы для городского наземного транспорта
Мы приняли участие в разработке билетной системы для городского наземного транспорта в формате автоматизированного рабочего места (АРМ), предназначенного для сотрудников и администраторов системы.
Клиент
ИТ-разработчик в области транспортных систем.
Задача
Основная бизнес-задача — перенести накопленный опыт управления билетной системой подземного транспорта на наземный транспорт, адаптировав решение под особенности работы городских перевозчиков. При этом необходимо было создать универсальную систему, которую можно масштабировать на большое количество компаний-перевозчиков без необходимости разрабатывать отдельное решение для каждой из них.
Со стороны разработки перед нами стояли следующие задачи:
-
спроектировать масштабируемую архитектуру, способную поддерживать подключение новых перевозчиков и расширение функциональности;
-
учесть недостатки архитектурных решений, использовавшихся в аналогичной системе для подземного транспорта, не допустить повторения существующих проблем;
-
обеспечить стабильную работу приложения при высоких нагрузках и большом объёме данных;
-
сделать пользовательский интерфейс максимально отзывчивым, чтобы сотрудники могли эффективно работать с системой в повседневных операционных процессах;
-
реализовать управление пользователями, правами доступа, справочными данными и транзакциями, связанными с покупкой проездных билетов.
Решение
Мы планировали создать полноценное автоматизированное рабочее место, объединяющее основные инструменты управления билетной системой наземного транспорта.
В качестве основного фронтенд-фреймворка выбрали Angular. При выборе технологии ориентировались на необходимость поддерживать строгую структуру проекта, обеспечивать единообразие подходов к разработке и создавать основу для дальнейшего масштабирования приложения.
На начальном этапе особое внимание уделялось архитектуре. В процессе разработки MVP мы рассмотрели несколько архитектурных вариантов, чтобы найти подход, который позволил бы развивать систему без существенного усложнения её дальнейшей поддержки.
Этапы разработки
Этап 1. Разработка MVP
На первом этапе в течение одного месяца создана минимально жизнеспособная версия приложения. Основная задача —сформировать основу системы, проверить выбранные архитектурные подходы и реализовать базовые сценарии работы.
В ходе разработки MVP мы попробовали несколько вариантов архитектуры. Это позволило уточнить требования к структуре приложения и определить направление дальнейшего развития.
Этап 2. Разработка полноценного приложения
После формирования базовой архитектуры мы перешли к расширению функциональности и реализации основных бизнес-сценариев. Для этого потребовалось около 12 месяцев.
В рамках этого этапа были разработаны:
-
система авторизации пользователей
-
система управления правами доступа к различным разделам и функциям приложения
-
большое количество справочников, необходимых для работы билетной системы
-
учёт транзакций, связанных с покупкой проездных билетов
-
инструменты управления тарифами, скидками, видами проездных билетов и физическими устройствами, устанавливаемыми на транспортные средств
-
административная панель для взаимодействия с сотрудниками, управления их аккаунтами и уровнями доступа, а также статистикой
-
сбор обезличенной информации об использовании проездных билетов
По мере развития проекта стало понятно, что для дальнейшего совершенствования пользовательского интерфейса необходим отдельный дизайнерский этап. Поэтому в проект были привлечены дизайнеры, хотя изначально такая работа не входила в план.
Это потребовало разработки собственного UI-kit (набор готовых компонентов и правил для создания единообразных интерфейсов) поверх выбранного технологического стека. Он стал основой для унификации компонентов интерфейса и обеспечения согласованности пользовательского опыта в разных разделах приложения.
Этап 3. Передача на поддержку и дальнейшее развитие
После решения основных архитектурных задач и формирования функциональной основы проекта команда была перестроена таким образом, чтобы обеспечить устойчивое дальнейшее развитие приложения.
К работе подключились мидл-разработчики, которые занимались поддержкой системы и небольшими доработками. Сеньор-разработчики, участвовавшие в решении наиболее сложных архитектурных задач, постепенно вышли из проекта.
Такой подход позволил разделить первоначальную разработку сложной системы и её последующую эксплуатационную поддержку.
Результат
В результате разработали приложение для централизованного управления билетной системой городского наземного транспорта.
Система позволяла сотрудникам работать с различными видами проездных билетов, тарифами и скидками, вести учёт транзакций по покупке проездных и управлять физическими устройствами, устанавливаемыми на транспортные средства во время рейсов.
Административная панель обеспечивала управление сотрудниками, сведениями об их занятости и расписании работы, а также разграничение доступа к различным разделам системы в соответствии с назначенными правами.
Дополнительно реализовали возможность собирать обезличенную информацию об использовании проездных билетов, создавая основу для последующего анализа их использования.
В процессе разработки также сформировали архитектурную основу для дальнейшего развития приложения, а создание собственного UI-kit позволило систематизировать подход к реализации пользовательского интерфейса.
Бизнес-эффект
Главным бизнес-результатом стало применение опыта управления билетной системой подземного транспорта в сфере городских наземных перевозок.
Разработанное решение объединило основные процессы работы с билетами, тарифами, скидками, транзакциями и транспортными устройствами в одном приложении. Это создало основу для централизованного управления билетной системой и её адаптации под потребности различных компаний-перевозчиков.
Масштабируемая архитектура и возможность дальнейшего развития приложения позволили заложить основу для подключения новых участников системы и расширения её функциональности.
Трудности
На этапе разработки MVP потребовалось опробовать несколько архитектурных подходов. Изначально выбранная структура приложения не могла рассматриваться как окончательная без проверки её пригодности для масштабирования и дальнейшего развития.
По этой причине архитектурные решения уточнялись в процессе работы. Это потребовало дополнительных усилий на раннем этапе, но помогло сформировать основу для полноценного приложения.
Одной из незапланированных задач стало привлечение дизайнеров спустя несколько месяцев после начала разработки.
Появление отдельного этапа проектирования интерфейса потребовало адаптировать уже существующие подходы к реализации UI и создать собственный UI-kit поверх открытой библиотеки PrimeNG. Это позволило заложить основу для единообразного оформления компонентов и упростить дальнейшее развитие интерфейса.
Проект требовал не только реализовать большой набор бизнес-функций, но и предусмотреть возможность дальнейшего развития системы без постоянного участия сеньор-разработчиков.
Для этого архитектурные задачи решались на ранних этапах, а после формирования основной функциональности поддержка и небольшие доработки были переданы мидл-разработчикам. Это позволило организовать дальнейшую работу над приложением с учётом распределения задач по сложности.
Технологии
Angular, rxjs, ngrx, html, scss, primeNG, PostgreSQL, java.
