СОДЕРЖАНИЕ

АННОТАЦИЯ

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

В результате развития ЭС будет содержать следующие подсистемы:
Подсистема управления номерами
Подсистема управления финансами
Подсистема управления тарифами
Подсистема управления дилерами
Подсистема управления задачами
Подсистема управления складом
Подсистема создания отчетов
Подсистема администрирования
Подсистема управления кол-центром
Подсистема управления масками
Подсистема управления категориями номеров
Подсистема перевыпуска номеров


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

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

Масштабируемость
Биллинг работает на сервере под управлением 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 и выше

Используемые библиотеки:
"bezlimit/models": "~2.1",
"bezlimit/package-notify": "~1.1",
"bezlimit/yii2-grid": "1.0.8",
"bezlimit/yii2-theme": "1.0.4",
"bezlimit/package-mobile-api": "~1.1",
"bezlimit/package-dictionary": "~1.1",
"bogdaan/viber-bot-php": "^0.0.14",
"bower-asset/bootstrap": "3.4.1",
"bower-asset/bootstrap-duallistbox": "4.0.1",
"bower-asset/bootstrap-timepicker": "0.5.2",
"bower-asset/chart.js": "2.9.1",
"bower-asset/cropperjs": "1.5.6",
"bower-asset/devbridge-autocomplete": "1.4.10",
"bower-asset/dropzone": "4.3.0",
"bower-asset/fancybox": "3.5.7",
"bower-asset/jquery.easy-pie-chart": "2.1.6",
"bower-asset/jstree": "3.3.8",
"bower-asset/leaflet": "1.5.1",
"bower-asset/raty": "2.7.0",
"bower-asset/seiyria-bootstrap-slider": "9.7.0",
"creocoder/yii2-nested-sets": "0.9.0",
"enqueue/amqp-lib": ">=0.9.14",
"ext-curl": "*",
"ext-iconv": "*",
"ext-intl": "*",
"ext-json": "*",
"ext-mbstring": "*",
"ext-mysqli": "*",
"ext-openssl": "*",
"ext-simplexml": "*",
"ext-soap": "*",
"kartik-v/yii2-date-range": "1.7.1",
"kartik-v/yii2-detail-view": "1.8.2",
"kartik-v/yii2-editable": "1.7.8",
"kartik-v/yii2-export": "1.4.0",
"kartik-v/yii2-field-range": "1.3.5",
"kartik-v/yii2-grid": "~3.3",
"kartik-v/yii2-mpdf": "^1.0",
"kartik-v/yii2-password": "1.5.4",
"kartik-v/yii2-widget-datepicker": "1.4.7",
"kartik-v/yii2-widget-typeahead": "1.0.4",
"kartik-v/yii2-widgets": "3.4.1",
"longman/telegram-bot": "^0.70.1",
"mlocati/ip-lib": "1.9.0",
"php": ">=7.4",
"phpoffice/phpspreadsheet": "1.17.1",
"phpoffice/phpword": "0.16.0",
"picqer/php-barcode-generator": "0.2.2",
"sanmai/cdek-sdk": ">=0.6.36",
"unclead/yii2-multiple-input": "2.21.5",
"vova07/yii2-imperavi-widget": "1.3.2",
"yii2tech/csv-grid": "1.0.4",
"yii2tech/spreadsheet": "1.0.5",
"yiisoft/yii2-bootstrap": "2.0.10",
"yiisoft/yii2-imagine": "2.2.0",
"yiisoft/yii2-jui": "2.0.7",
"yiisoft/yii2-mongodb": "2.1.8",
"yiisoft/yii2-redis": "2.0.10",
"yiisoft/yii2-sphinx": "2.0.12",
"yiisoft/yii2-swiftmailer": "2.0.7",
"ext-imagick": "*",
"nex/yii2-graylog2": "dev-master",
"npm-asset/jquery-viewer": "^1.0",
"npm-asset/viewerjs": "^1.10",
"whichbrowser/parser": "^2.1",
"hflabs/dadata": "^20.12",
"mohorev/yii2-upload-behavior": "^0.2.3",
"smalot/pdfparser": "^2.2",
"halaxa/json-machine": "^1.1"

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

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

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

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

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

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 Порядок взаимодействия службы поддержки с пользователями
Получение жалоб и пожеланий пользователей:

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

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

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

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

• Аварийное:

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

• Обработка жалоб персоналом:

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

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

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

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

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

• Знание функциональных возможностей Биллинга.

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

• Знание API Биллинга.
• Знание структуры, функционала и настроек базы данных.

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

• Знание функциональных возможностей Биллинга.
• Знание API Биллинга.
• Знание структуры, функционала и настроек базы данных.
• Знание архитектуры Биллинга.

4.2 Уровень подготовки пользователя
Пользователь «АСР Биллинг — коммерческая комплексная программная платформа для реализации электронно-цифровых сервисов» должен иметь опыт работы со смартфоном и с мобильными приложениями.

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

5. Дорожная карта проекта (ключевые ближайшие 3 года)
Предполагается поэтапная реализация следующих подсистем:

5.1 Подсистема логистики (ориентировочно по июнь 2023 года)
Подсистема логистики предназначена для создания заказов доставки SIM-карт и управления ими.

Подсистема должна обеспечивать прием заказов с указанием:
— ФИО;
— контактного номера;
— заказанного номера;
— города;
— адреса пункта выдачи;
отображение списка адресов пунктов выдачи;
отображение списка заказов для самовывоза со следующими полями:
— дата создания;
— трек-номер;
— ФИО;
— контактный номер;
— адрес пункта выдачи;
— заказанный номер;
— планируемая дата доставки;
— номер SIM-карты;
— статус заявки;
— автор заявки;
отображение списка заказов для доставки в пункт выдачи со следующими полями:
— дата создания;
— трек-номер;
— ФИО;
— адрес доставки получателя;
— стоимость доставки;
— контактный номер;
— адрес пункта выдачи;
— заказанный номер;
— планируемая дата доставки;
— количество SIM-карт;
— статус заявки;
— автор заявки.

5.2 Подсистема управления маркетплейсами (ориентировочно по декабрь 2023 года)
Подсистема управления маркетплейсами предназначена для создания маркетинговых материалов для размещения на маркетплейсах OZON, Wildberries, Яндекс.Маркет, СберМегаМаркет.

Подсистема должна обеспечивать: 

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

5.3 Подсистема управления поставщиками услуг (ориентировочно по июнь 2024 года)
Подсистема управления поставщиками услуг предназначена для мониторинга статусов задач, отправленных поставщику услуг.

Подсистема должна обеспечивать:

• отображение главной очереди задач со следующими полями:
• ID задачи;
• номер;
• бан;
• статус;
• код услуги;
• новый номер SIM;
• связанная задача;
• источник заявки;
• статус в очереди;
• код ответа;
• номер запроса;
• контрольная проверка;
• дата создания;
• дата обновления;
• автор;
• отображение очереди задач по смене статуса со следующими полями:
• ID задачи;
• номер;
• бан;
• статус;
• код услуги;
• связанная задача;
• источник заявки;
• статус в очереди;
• код ответа;
• номер запроса;
• контрольная проверка;
• дата создания;
• дата обновления;
• автор.
• отображение очереди задач по смене SIM со следующими полями:
• номер;
• статус;
• автор;
• новый номер SIM;
• комментарий;
• статус заявки;
• кто изменил статус;
• дата создания;
• дата обновления;
• статус в очереди.

5.4 Подсистема управления бонусными баллами (ориентировочно по декабрь 2024 года)
Подсистема управления безналичными расчетами предназначена для учета безналичных транзакций всех бизнес-единиц и контрагентов.

Подсистема должна обеспечивать:

• отображение списка бизнес-единиц со следующими полями:
• название организации;
• реквизиты;
• фактический адрес;
• юридический адрес;
• генеральный директор ФИО;
• должность (по документам);
• бухгалтерия;
• менеджер;
• возможность редактировать информацию по бизнес-единице;
• возможность удаления бизнес-единиц;
• возможность добавления бизнес-единиц;
• возможность фильтрации списка бизнес-единиц;
• отображение списка контрагентов со следующими полями:
• сервис-провайдер
• название организации;
• реквизиты;
• фактический адрес;
• юридический адрес;
• генеральный директор ФИО;
• должность (по документам);
• email;
• менеджер;
• возможность редактировать информацию по контрагенту;
• возможность удаления контрагента;
• возможность добавления контрагентов;
• возможность фильтрации списка контрагентов;
• отображение списка групп номеров со следующими полями:
• название группы номеров;
• тип оповещения;
• контактное лицо;
• главный номер группы;
• контактный телефон;
• email;
• комментарий;
• возможность редактировать информацию по группе номеров;
• возможность удаления групп номеров;
• возможность добавления групп номеров;
• возможность фильтрации групп номеров;
• возможность экспорта списка групп номеров;
• отображение списка транзакций юрлиц со следующими полями:
• год;
• месяц;
• сервис-провайдер;
• название организации;
• сумма счета;
• сумма неоплаченных счетов;
• баланс компании;
• сумма платежей;
• статус оплаты счета;
• отправка в 1С;
• комментарий.
• возможность добавления транзакций;
• возможность фильтрации транзакций;
• возможность экспорта списка транзакций;
• возможность формирования документов по транзакции;
• отображение списка транзакций по группам номеров со следующими полями:
• год;
• месяц;
• название организации;
• тип оповещения;
• количество номеров;
• сумма счета;
• баланс группы;
• сумма платежей;
• к оплате;
• статус оплаты счета;
• возможность просмотра детализации;
• возможность фильтрации транзакций;
• возможность экспорта списка транзакций;
• отображение списка платежей со следующими полями:
• тип организации;
• дата зачисления платежа;
• номер;
• организация;
• сумма платежа;
• комментарий;
• дата создания;
• автор;
• тип платежа.
• возможность редактирования информации по платежам;
• возможность удаления информации по платежам;
• возможность добавления платежей;
• возможность фильтрации платежей;
• возможность экспорта списка платежей.

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

Подсистема должна обеспечивать:

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