Платформа онлайн дистрибуции Store

Платформа онлайн дистрибуции Store

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

СОДЕРЖАНИЕ

АННОТАЦИЯ

Программа для ЭВМ «Платформа онлайн-дистрибуции» (далее — Store) создана в целях предоставления дилерам виртуального оператора сотовой связи возможности самостоятельно подключать новых пользователей.

Store позволяет искать красивые номера с помощью фильтров, бронировать понравившиеся номера, оформлять контракты и заказывать доставку SIM-карт.
Реализована возможность получения бонусов за активации номеров, возможность оплаты бонусами услуг связи, а также вывод заработанных бонусов на банковскую карту.
Создана двухуровневая структура дилеров, позволяющая дилерам верхнего уровня получать бонусы за активации субдилеров.
Разработана программа лояльности, увеличивающая количество бонусов, начисляемых за активации в зависимости от количества активаций в текущем месяце.
Реализована система поддержки пользователей, система информирования и раздел FAQ.
Store выполнен в клиент-серверной архитектуре, с двумя вариантами клиентского приложения: мобильное приложение и веб-версия.
Store состоит из отдельных модулей, реализующих различные функции системы и независимых друг от друга. Каждый модуль Store имеет собственный программный интерфейс на основе API, позволяющий осуществлять интеграцию модулей между собой и с внешними системами.

1. Архитектура и Инфраструктура

Программа для ЭВМ «Платформа онлайн-дистрибуции» создана в целях предоставления дилерам виртуального оператора сотовой связи возможности самостоятельно подключать новых пользователей. «Платформа онлайн-дистрибуции» позволяет искать красивые номера с помощью фильтров, бронировать понравившиеся номера, оформлять контракты и заказывать доставку SIM-карт.

Реализована возможность получения бонусов за активации номеров, возможность оплаты бонусами услуг связи, а также вывод заработанных бонусов на банковскую карту. Создана двухуровневая структура дилеров, позволяющая дилерам верхнего уровня получать бонусы за активации субдилеров.

Store выполнен в клиент-серверной архитектуре, с двумя вариантами клиентского приложения: мобильное приложение и веб-версия.

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

Масштабируемость

Store работает на сервере под управлением Linux:
Debian 8 Linux
Ubuntu 18.04 или выше

1.2 Основные подсистемы

2. Процессы жизненного цикла программного обеспечения

2.1 Жизненный цикл ПО

Жизненный цикл разработки ПО основан на ГОСТ 34.601-90.

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

Разработка технического задания
Разработка и утверждение технического задания на создание ПО
Определение рабочей группы, ответственной на разработку
Построение плана-графика по отчетным встречам разработки ПО

Эскизный проект
Разработка предварительных проектных решений по системе и её частям
Разработка документации и комментирование кода

Рабочая документация
Разработка рабочей документации на АС и её части
Разработка API-методов

Разработка и адаптация программ
Разработка методов, сервисов, программ
Настройка сетевой безопасности
Подготовка резервированной БД
Подготовка пресс-релизной версии
Аудит ПО на предмет соответствия требованиям

Тестирование ПО
Тестирование безопасности
Функциональное тестирование
Тестирование производительности
Юзабилити тестирование
Подготовка отчета о тестировании

Ввод в эксплуатацию
Обучение персонала
Сбор обратной связи от персонала

Сопровождение ПО
Выполнение работ в соответствии с гарантийными обязательствами
Послегарантийное обслуживание

2.2 Данные о процессе разработки ПО

Данные о персонале, задействованном в процессе разработки, приведены в главе 4.

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

2.3 Процессы поддержки ПО, в которые вовлечены разработчики

Процесс управления документацией:

• Определение критериев для сопровождения документации.
• Актуализация и доработка документации при изменении ПО.

Управление конфигурацией ПО:

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

2.4 Рекомендуемые ТТХ ПК

Разработка ведется в изолированном сегменте офисной сети с 9 АРМ разработчиков и одним выделенным сервером.

Аппаратная часть:
Язык программирования, применявшийся при разработке ПО — PHP 7.4 и выше, фреймворк Yii2.

Среда разработки ПО:
Изолированная подсеть на основе ОС Ubuntu 20.04, в составе сервера, 9 АРМ программистов.

Для корректной работы с платформой необходима следующая конфигурация автоматизированного рабочего места пользователя:

Минимальные требования к системе 

• 4 ядра
• 4 Gb RAMM доступной памяти на 1 ядро системы
• 100Gb SSD

Поддерживаемые ОС:
Debian 8 Linux
Ubuntu 18.04 или выше

Необходимое ПО сторонних производителей:
Open-source Mysql MariaDB
Open-source ПО GrayLog
GIT (с системой автоматической установки и обновления кода через GitLab)
Composer
Docker

Операционные системы:
Windows (10, 11)
Mac OS (Big Sur, Monterey, Ventura).

Языки программирования:
PHP 7.4 и выше

Используемые библиотеки:
"yiisoft/yii2": "2.0.38",
"bezlimit/package-dictionary": "1.116.1",
"bezlimit/models": "2.182.1",
"bezlimit/package-logs": "1.1.1",
"bezlimit/api-clients": "dev-feature/bonus",
"yiisoft/yii2-imagine": "^2.2",
"zircote/swagger-php": "2.0.16",
"bower-asset/swagger-ui": "^3.0",
"yiisoft/yii2-httpclient": "~2.0.0",
"longman/telegram-bot": "0.55.1",
"enqueue/amqp-lib": ">=0.9.14",
"php-amqplib/php-amqplib": "^2.10",
"yiisoft/yii2-swiftmailer": "~2.0.0",
"frostealth/yii2-aws-s3": "~2.0",
"sanmai/cdek-sdk": "^0.6.28",
"aksafan/yii2-fcm-both-api": "*",
"thamtech/yii2-ratelimiter-advanced": "0.5",
"bacon/bacon-qr-code": "^2.0",
"bezlimit/package-i18n": "1.0.5",
"nex/yii2-graylog2": "dev-master",
"yiithings/yii2-dotenv": "1.0.2",
"phpoffice/phpspreadsheet": "^1.25"

Как построен процесс разработки
Разработка осуществляется средствами разработчика с помощью ПО PhpStorm или другого редактора PHP. Хранение кодовой базы на серверах компании в дата-центре Selectel https://selectel.ru/.

Как обрабатываются процессы, на каких серверах
Обработка и хранение данных осуществляется силами backend-отдела компании на серверах дата-центра Selectel. В качестве интерфейса взаимодействия используется любой web-браузер, точка входа https://api.bezlimit.ru/. Для хранения данных используются базы данных MariaDB(MySQL), Redis.

2.5 Поддержание жизненного цикла системы

Поддержание жизненного цикла программного обеспечения обеспечивается за счет следующих процессов:

Расширение функционала Store в соответствии с собственным планом доработок и/или на основе отзывов пользователей.
Разработки новых методов API, необходимых для организации взаимодействия Store с базой данных и другими информационными системами.
Устранение сбоев и технических проблем, выявленных в процессе эксплуатации Store.
Внесение изменений в Store с целью оптимизации его работы (улучшение взаимодействия, повышение эффективности использования серверных ресурсов, повышение удобства пользовательского интерфейса и др.)
Осуществление поддержки пользователей по вопросам эксплуатации Store.

3. Порядок технической поддержки ПО

3.1 Формирование заявки

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

Регистрацию обращений в Битрикс выполняют преимущественно специалисты 1-й линии технической поддержки, кроме случаев выявления проблем инженерами других линий (2, 3 линии).

3.2 Обработка заявки специалистом servicedesk (1-я линия)

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

Специалист 1-й линии выполняет работы по обращениям и инцидентам всеми доступными ему силами и средствами (собственные навыки, консультации с другими сотрудниками IT-инфраструктуры, знания, получаемые из иных компетентных источников).

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

3.3 Эскалация заявки

Эскалация заявки с 1-й линии технической поддержки на вторую происходит в следующих случаях:
Для выполнения заявки требуются доступы к базе данных, которых нет у специалистов 1-й линии технической поддержки.
Для выполнения заявки требуется более высокий уровень компетенции, чем есть у специалистов 1-й линии технической поддержки.

3.4 Обработка заявки 2-й линией

Инженеры 2-й линии технической поддержки:

• Решают инциденты, переданные с первого уровня. Если для первого уровня поддержки ожидается, что он решает 80% инцидентов, то от второго уровня поддержки ожидается, что он решает 75% инцидентов, переданных ему первым уровнем, то есть 15% от числа зарегистрированных инцидентов. Остальные инциденты передаются на третий уровень.
• Определяют причины проблем. Второй уровень поддержки определяет причины проблем и предлагает меры по их обходу или устранению. Они привлекают и управляют другими ресурсами по мере необходимости для определения причин. Решение проблем передается на третий уровень, когда причина заключается в архитектурном или техническом вопросе, который превышает их уровень квалификации.
• Обеспечивают реализацию исправлений и устранений проблем. Второй уровень поддержки обеспечивает инициирование запросов на изменения в проектах, ведущихся в организациях разработчиков, для реализации планов устранения известных ошибок. Они обеспечивают документирование найденных решений, сообщают о них персоналу первого уровня и реализуют их в инструментах.
• Второй уровень поддержки пытается идентифицировать проблемы до возникновения инцидентов посредством наблюдения за компонентами инфраструктуры и принятия корректирующих действий при обнаружении дефектов или ошибочных тенденций.
• Заблаговременно анализируют тенденции инцидентов. Уже случившиеся инциденты исследуются для того, чтобы определить, не свидетельствуют ли они о наличии проблем, которые следует исправить, чтобы они не вызвали новые инциденты. Исследуются те инциденты, которые закрыты и не сопоставлены известным проблемам на предмет наличия потенциальных проблем.

3.5 Механизм эскалации инцидента со 2-й линии на 3-ю

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

3.6 Данные о процессе поддержки

Данные о персонале, задействованном в процессе поддержки, приведены в главе 4.

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

3.7 Порядок взаимодействия службы поддержки с пользователями

Получение жалоб и пожеланий пользователей:

• Периодическое:

— Опрос пользователей в определенные периоды по электронной почте и/или телефону (ежемесячно).
— Сбор данных и решение вопросов совместимости по электронной почте и телефону при выходе плановых обновлений Store (по мере выхода обновлений).

• Непериодическое:

— Сбор отзывов пользователей о Store по электронной почте (регулярно, круглосуточно).
— Сбор данных и решение вопросов совместимости по электронной почте и телефону при выходе новых версий Биллинга или существенных обновлений для устранения обнаруженных ошибок.
— Сбор данных и решение вопросов совместимости по электронной почте и телефону при обновлении пользователями приложений.

• Аварийное:

— Взаимодействие с пользователями при возникновении аварийной ситуации по электронной почте, телефону.

Обработка жалоб персоналом:
Сообщение заказчика заносится в систему Битрикс, где его статус меняется по мере устранения проблемы и сохраняется как «решенная проблема» после устранения. В процессе устранения задействуется как сервисный специалист, имеющий навыки системного администратора и минимальные навыки разработчика, так и специалисты разработки системы при необходимости согласно этапам п. 3.1—3.5.

3.8 Возможные ошибки

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

4.Требования к персоналу

4.1 Персонал, обеспечивающий техническую поддержку и модернизацию

Общие требования к специалистам, обеспечивающим техническую поддержку, интеграцию и развитие «АСР Биллинг — коммерческой комплексной программной платформы для реализации электронно-цифровых сервисов» на первой линии поддержки:
Знание функциональных возможностей Биллинга.

Общие требования к специалистам, обеспечивающим техническую поддержку, интеграцию и развитие «Платформы онлайн-дистрибуции» на второй линии поддержки:
Знание API Store.
Знание структуры, функционала и настроек базы данных.

Общие требования к специалистам, обеспечивающим техническую поддержку, интеграцию и развитие «Платформы онлайн-дистрибуции» на третьей линии поддержки:
Знание функциональных возможностей Store.
Знание API Store.
Знание структуры, функционала и настроек базы данных.
Знание архитектуры Store.

4.2 Уровень подготовки пользователя

Пользователь «Платформы онлайн-дистрибуции» должен иметь опыт работы со смартфоном и с мобильными приложениями.

4.3 Данные о персонале, задействованном в процессе разработки (количество, квалификация)

Данные о персонале, задействованном в процессе разработки ПО, приведены в таблице ниже:

4.4 Данные о персонале, задействованном в процессе тестирования, отладки и установки ПО (количество, квалификация)
Данные о персонале, задействованном в процессе тестирования, отладки и установки ПО приведены в таблице ниже:

4.5 Данные о персонале, задействованном в процессе поддержки, эксплуатации и модернизации ПО (количество, квалификация)

5. Дорожная карта проекта (ключевые ближайшие 3 года)

5.1 Подсистема логистики (ориентировочно по июнь 2024 года)

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

Подсистема должна обеспечивать отображение лучших дилеров:
за день;
за неделю;
за месяц.

5.2 Игровая подсистема (ориентировочно по декабрь 2024 года)

Игровая подсистема предназначена для повышения лояльности пользователей ЭС благодаря использованию игровых механик и улучшению пользовательского опыта.

Подсистема должна обеспечивать возможность:
встраивания в ЭС мини-игр с вознаграждением в виде бонусов;
учета времени, проведенного пользователем в игровом разделе;
отслеживания действий пользователей в приложении для создания «квестов»;
получения геолокационной информации о местонахождении пользователя для организации «геоквестов»;
отображения лучших результатов (рейтинга) пользователей;
делать ставки на лидеров рейтинга;
создания команд из пользователей для совместного заработка максимального количества бонусов.

5.3 Подсистема учета метрик (ориентировочно по декабрь 2025 года)

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

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