Разработка биллинговой системы SAAS-среды аренды сайтов

Размещено на http://www.allbest.ru/

Пермский филиал федерального государственного автономного образовательного учреждения высшего образования «Национальный исследовательский университет «Высшая школа экономики»

Факультет экономики, менеджмента и бизнес-информатики

Проект Выпускной квалификационной работы

по направлению подготовки 38.03.05 Бизнес-информатика

образовательная программа «Бизнес-информатика»

РАЗРАБОТКА БИЛЛИНГОВОЙ СИСТЕМЫ SAAS-СРЕДЫ АРЕНДЫ САЙТОВ

Клейн Александр Дмитриевич

Пермь, 2018

Аннотация

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

Во введении отражена актуальность выбранной темы, цель работы и основные задачи, которые необходимы для достижения поставленной цели. В работе описан анализ предметной области, выполнено проектирование биллинговой системы и её частей - биллинговой платформы и системы контроля доступа. Описан процесс разработки и интеграции биллинговой системы. Текстовая часть исследовательской работы занимает страницы на листах формата А4и состоит из 3 глав, включает 27 иллюстраций, 1 таблицу, а также 3 приложения.

Ключевые слова: биллинговая система, SaaS модель, аренда сайтов, биллинговая платформа, система контроля доступа, моделирование бизнес-процессов, проектирование, разработка, интеграция.

Введение

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

Одним из самых недорогих и эффективных подходов для создания и поддержки работы сайтов является аренда сайтов. Услуга аренды сайтов относится к SaaS услугам. SaaS (Software-as-a-Service) - модель обслуживания, предоставляющая программное обеспечение как услугу. При этом сайт размещается в «облачной» среде поставщика приложения, а не на сервере заказчика. Такая модель позволяет переложить часть забот по поддержке работоспособности приложения на поставщика, уменьшить затраты и увеличить доступность сайта.

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

В качестве проблем исследования были выявлены:

1. Низкая производительность ручного труда - сотрудникам приходится вручную обрабатывать каждую заявку;

2. Человеческий фактор - при заполнении письменной формы отчетности сотрудники допускают ошибки, обусловленные человеческим фактором;

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

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

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

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

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

1. Провести анализ предметной области исследования, включая построение модели существующего процесса аренды сайтов AS-IS и описание требований к системе;

2. Спроектировать архитектуру биллинговой системы включая построение модели работы биллинговой системы TO-BE и выбор способов её реализации;

Глава 1. Анализ предметной области

В данной главе будет произведен анализ предметной области биллинговых систем аренды сайтов. Для этого будут проведен обзор основных понятий и функций биллинговых систем, проведен анализ бизнес-процесса аренды сайтов. На основе полученных результатов будет построена модель существующего процесса аренды сайтов. Основываясь на построенной модели существующего процесса аренды сайтов, будут определены требования для разработки биллинговой системы. Так как система разрабатывается для интеграции с порталом permarea.ru, данный портал будет проанализирован и рассмотрена его структура. Далее будет рассмотрена биллинговая платформа Billmanager, использование которой является одним из требований заказчика.

1.1 Понятие и функции биллинговых систем

Биллинг - в переводе с английского «billing» - выписывать счет. Изначально это понятие не имело ничего общего с телекоммуникационными системами и означало предоставление клиенту общего счета за оказанные услуги.

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

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

В результате, на сегодняшний день к биллинговым системам предъявляются следующие требования:

- Учет и тарификация использования клиентами телекоммуникационных услуг в реальном времени;

- Своевременное выставление счетов за использование услуги;

- Информирование клиентов об использовании услуг и состоянии счета;

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

1.2 Описание бизнес-процессов аренды сайтов

ООО «Инновационные технологии информационных систем» (ИТИС) - достаточно молодая компания (организована как самостоятельное юридическое лицо в 2010 году), однако её коллектив прошел долгий путь, начиная с 1998г. в составе других, более крупных организаций, до создания своей собственной компании. Основным профилем работы компании является создание и продвижение веб-сайтов, разработка новых технических идей в области веб-технологий.

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

В связи с этим компания ИТИС начала предоставлять SaaS (Softwareasa Servise) услуги аренды сайтов. Это значит, что компания ИТИС не только разрабатывает сайты, но и полностью берет на себя их обслуживание, включая предоставление хостинга, обновление и их бесперебойную работу.

Основным потребителем услуг аренды сайтов компании ИТИС является портал муниципальных образований Пермского краяpermarea.ru.

Именно для портала permarea.ru по заказу компании ИТИС будет разрабатываться данная биллинговая система.

1.3 Анализ существующего процесса аренды сайтов

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

В процессе аренды сайтов участвуют несколько актеров:

- Заказчик;

- Менеджер по работе с клиентами;

- Бухгалтер;

- Разработчик;

- Директор

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

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

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

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

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

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

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

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

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

При не продлении клиентом договора аренды или отсутствии платы, клиенту закрывается доступ к сайту

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

1.4 Построение модели AS-IS существующего процесса аренды сайтов

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

Для этого необходимо построить модель существующего процесса аренды сайтов «AS-IS». Для построения модели необходимо описать как сам процесс аренды сайтов, так и его подпроцессы - получение заказа, заключение договора, продление и завершение аренды.

Для построения модели бизнес-процесса аренды сайтов выбрана методология моделирования бизнес-процессов -BPMN. Нотация BPMNописывает бизнес-процессы нижних уровней, поэтому она является подходящей для создания модели «AS-IS» бизнес-процесса аренды сайтов.

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

1. Заказ сайта

Началом подпроцесса является заказ клиента услуги аренды сайтов компании ИТИС. Компания ИТИС может получить заказ от клиента несколькими способами:

1) Выиграв тендерные торги (обычно проводятся крупными компаниями и при государственных закупках);

2) Получив техническое задание на разработку и аренду сайта;

3) Напрямую получив заказ от клиента (по телефону или электронной почте).

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

Формализованная модель «AS-IS» подпроцесса заказа сайта бизнес-процесса аренды сайтов представлена на рисунке 1.1.



Рисунок 1.1 -Модель подпроцесса заказа сайта процесса аренды сайтов

2. Аренда сайта

Подпроцесс аренды сайта начинается после разработки компанией ИТИС сайта для заказчика и предоставления данных для доступа к управлению сайтом.

Для сохранения доступа к сайту клиент оплачивает услугу аренды сайта. По запросу клиента или окончании текущего периода оплаты сайтов, сотрудниками компании ИТИС проверяется оплата аренды сайта и включается или отключается доступ к нему в зависимости от наличия оплаты.

Формализованная модель «AS-IS» подпроцесса аренды сайта бизнес-процесса аренды сайтов представлена на рисунке 1.2.

Исходя из построенной модели «AS-IS» бизнес-процесса аренды сайтов можно выделить недостатки существующего процесса аренды сайтов:

1) При заказе аренды сайта, клиентам приходится звонить в офис или писать на электронную почту компании, а не заказывать на сайте;

2) Сотрудникам ИТИС приходится вручную проверять оплату и включать или отключать доступ к множеству сайтов;



Рисунок 1.2 - Подпроцесс аренда сайта процесса аренды сайтов

3) Для включения сайта после оплаты аренды, клиентам приходится звонить в офис компании;

4) Финансовые документы составляются бухгалтером вручную.

1.5 Определение требований к биллинговой системе

Следующим шагом, после построения модели и определения недостатков существующих бизнес-процессов аренды сайтов, является определение основных требований к биллинговой системе.

Основной проблемой существующего бизнес-процесса аренды сайтов является отсутствие автоматизации.

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

- Доступ к оплате услуг аренды сайтов;

- Автоматическая обработка и тарификация поступающих платежей;

- Передача данных об оплате аренды для формирования финансовых документов;

- Подключение и отключение доступа клиентам к сайту в зависимости от наличия или отсутствия платы за аренду сайтов;

- Информирование клиентов о состоянии счета, договора аренды, важной информации, касающейся аренды сайтов, и т.д.

Кроме основных требований к биллинговой системе, при разработке системы обязательно должны учитываться требования заказчика. В соответствии с поставленным требованием заказчика - компании ИТИС для разработки биллинговой системы должна использоваться существующая биллинговая платформа Billmanager.

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

1.6 Описание портала муниципальных образований Пермского края permarea.ru

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

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

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

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

Преимуществами создания сайта для муниципального образования на основе портала permarea.ru является отсутствие капитальных затрат на разработку отдельного сайта, вывод на аутсорсинг непрофильных для органов местного самоуправления функций (разработка, поддержка, модификация, хостинг сайта, содержание своего сервера), единый официальный стиль оформления с другими муниципальными образованиями и высокая защищенность сайта.

После общения с заказчиком - компанией ИТИС, разработавшей данный портал и занимающейся предоставлением услуг аренды сайтов для портала муниципальных образований Пермского края permarea.ru была составлена архитектура сайтов, входящих в состав портала permarea.ru.

Формализованная модель архитектуры сайта муниципального образования портала муниципальных образований Пермского края permarea.ru в виде диаграммы классов представлена на рисунке 1.3.

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



Рисунок 1.3 - Диаграмма классов сайта муниципального образования портала permarea.ru

1.7 Описание платформы Billmanager

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

Billmanager - это биллинговая платформа для управления хостинговой компанией.

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

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

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

Основными операциями, которые может выполнять Billmanager являются:

- Зарегистрировать клиентов;

- Предоставлять скидки;

- Получать платежи;

- Услуги по заказу и обработке;

- Создание бухгалтерских документов;

- Предоставлять службы поддержки;

- Отправлять уведомления клиентам;

- Создание отчетов;

- Интеграция сайтов.

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

Подводя итоги первой главы, в которой проводился анализ предметной области работы, были рассмотрены основные понятия и функции биллинговых систем. После этого были рассмотрены и проанализированы процессы аренды сайтов, была построена модель существующих процессов «AS-IS», выделены недостатки существующего процесса. После этого, на основе анализа функций биллинговых систем и результатах построения модели бизнес-процессов, были определены основные требования, предъявляемые системе. Также были рассмотрены Портал муниципальных образований Пермского края permarea.ru, с которым будет интегрирована биллинговая система, и биллинговая платформа Billmanager, которая при разработке будет адаптирована для использования в биллинговой системе.

Глава 2. Проектирование биллинговой системы

В данной главе будет проектирование биллинговой системы. Для это, на основе построенной модели AS-IS существующих процессов и технических требований к системе, будут описаны бизнес-процессы и проведено моделирование процесса работы TO-BE биллинговой системы. Затем, на основе полученной модели всей системы, будут выбраны средства для разработки системы и определена структура проектируемой системы. После этого, каждая часть системы будет спроектирована отдельно.

2.1 Описание бизнес-процесса работы биллинговой системы

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

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

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

2.2 Построение модели работы TO-BE биллинговой системы

Для того чтобы понять, как должна работать биллинговая система, необходимо построить модель работы TO-BE биллинговой системы, на основе описанных бизнес-процессов.

На основе описанного бизнес-процесса работы биллинговой системы можно выделить основных актеров бизнес-процесса:

- Пользователь сайта;

- Владелец сайта(администратор);

- Биллинговая система.

Как и модель AS-ISпроцесса аренды сайтов (Рисунок 1.1-2), модель TO-BEтакже описывается в нотации BPMN, так как она позволяет показать взаимодействие пользователей с биллинговой системой.

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

1. Подключение к сайту

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

Модель подпроцесса подключения к сайту процесса аренды сайтов представлена на рисунке 2.1



Рисунок 2.1 - Подпроцесс подключение к сайту процесса аренды сайтов TO-BE

2. Оплата аренды сайта

Биллинговая система автоматически проверяет оплату аренды сайта и автоматически включает или выключает доступ к сайту.

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

Модель подпроцесса подключения к сайту процесса аренды сайтов представлена на рисунке 2.2



Рисунок 2.2 - Подпроцесс оплаты сайта процесса аренды сайтов TO-BE

2.3 Определение средств разработки

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

Исходя из требований к системе и проанализировав модель TO-BEпроцесса аренды сайтов, можно определить, что система, в целом, должна состоять из двух частей:

1. Биллинговая платформа - занимается сбором и обработкой информации о платежах, и передаче обработанной информации;

2. Система контроля доступа - находится на серверах арендуемых сайтах и управляет доступом к данным сайтам.

В соответствии и требованиями заказчика - компании ИТИС, в качестве биллинговой платформы будет использоваться существующая биллинговая платформа Billmanager.

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

2.4 Проектирование биллинговой платформы

Для проектирования биллинговой платформы необходимо описать бизнес-процесс аренды сайтов для биллинговой платформы, построить модель её работы и определить требования для её адаптации.

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

В общем процесс аренды сайтов для биллинговой платформы описывается так: биллинговая платформа предоставляет информацию о состоянии и оплате услуги аренды сайтов. У услуги есть информация о доступном оплаченном сроке работы, уменьшающимся с течением времени. Если услуга оплачена и активна, то оплата услуги продляет соответствующий срок работы на оплаченное время. Если услуга не оплачена, внесение оплаты повторно активирует ее и продляет срок работы. После окончания оплаченного срока работы, услуга деактивируется.

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

Чтобы понять логику работы биллинговой платформы, на основе описанного процесса аренды сайтов для биллинговой платформы необходимо построить модель его работы. Наиболее подходящей нотацией, описывающей процессы, проходящие в биллинговой платформе, является Диаграмма последовательности (sequence diagram) UML.

Модель процесса аренды сайтов биллинговой платформы представлена на рисунке 2.3.



Рисунок 2.3 - Диаграмма последовательности UML процесса аренды сайтов биллинговой платформы

Определение требований для адаптации биллинговой платформы

На основе построенной модели процесса аренды сайтов биллинговой платформы необходимо требования, необходимые для адаптации биллинговой платформы для процесса аренды сайтов.

Для процесса аренды сайтов нам понадобятся следующие элементы, поддерживаемые платформой Billmanager:

- Дата-центры - данный модуль выделяет мощности сервера для обработки услуг;

- Обработчики услуг - данный модуль непосредственно обрабатывает услуги в соответствии с установленными правилами для обработки;

- Типы продуктов - этот модуль задает параметры предоставляемой услуги;

- Тарифные планы - данный модуль настраивает правила для обработки для соответствующего продукта.

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

1) Создать услугу аренды сайтов с помощью модуля «Типы продуктов»;

2) Создать дата-центр для выделения серверных мощностей для обработки услуг;

3) Создать обработчик услуг для услуги аренды сайтов и поместить его в созданный дата-центр;

4) Создать тарифный план для услуги аренды сайтов и подключить к нему обработчик услуг.

2.5 Выбор способа разработки системы контроля доступа

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

1) Отдельное приложение

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

Преимуществами такого подхода являются:

1. Единый центр управления доступом к сайтам - в приложении можно задать правила управления доступом как для всех сайтов, так и для каждого в отдельности;

2. Возможность настроить доступ к сайтам даже при отсутствии доступа к биллинговой системе.

Недостатками данного подхода являются:

1. Между сайтом и биллинговой системой включается дополнительный посредник, возможное отсутствие доступа, к которому нарушает стабильность работы системы;

2. Необходимо содержать отдельный сервер для работы приложения;

3. Между изменением состояния услуги аренды сайта в биллинговой платформе и включением или отключением доступа к сайту пройдет некоторое время;

4. В любом случае необходимо внедрять в сайт сервис, включающий или отключающий доступ к нему.

2) Включение системы в архитектуру сайта

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

Преимуществами такого подхода являются:

1. Повышение стабильности работы системы по сравнению с отдельным приложением - система работает пока есть доступ к основному сайту;

2. Доступ к сервису включается или выключается одновременно с изменениями статуса услуги в биллинговой системе;

3. Нет необходимости устанавливать дополнительные сервисы включения или отключения доступа.

Недостатками данного подхода являются:

1. Повышение нагрузки на сервер, пропорциональное увеличению количества пользователей сайта.

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

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

2.6 Проектирование системы контроля доступа

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

На основе построенной модели общей работы биллинговой системы, мы можем описать, как будет осуществляться контроль доступа клиента к сайту и построить модель её работы.

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

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

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

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

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

2.7 Выбор инструментов разработки системы контроля доступа

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

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

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

XML (eXtensible Markup Language) - расширяемый язык разметки, широко используемый в интернете. Это простой, гибкий формат, пригодный как для машинной обработки, так и для чтения человеком и позволяющий авторам добавлять новые тэги для обработки документов.

XML является упрощённой формой SGML (стандартный обобщенный язык разметки), предназначенный для документов, публикуемых в Интернете.

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

Для разработки системы контроля доступа к сайту был выбран язык веб-разработки PHP5.

PHP5 (Hypertext Preprocessor) - скриптовый язык применяемый для разработки веб-приложений. В настоящее время язык PHPявляется самым популярным языком для создания динамических веб-сайтов. В настоящий момент PHP5 поддерживается подавляющим большинством хостинг-провайдеров.

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

Для обработки XML-документов будет использоваться стандартным модулем DOM, встроенным в PHP5.

Document Object Model (DOM) -это программный интерфейс, позволяющий программам и скриптам работать с HTML и XML документами. Данный интерфейс является независимым от платформы или языка.

Модель DOM описывает стандартный набор объектов для XML и HTML предоставляет стандартный интерфейс для работы и манипуляций с ними. При этом DOMне накладывает ограничений на структуру документа.

Таким образом язык PHP5полностью удовлетворяет требованиям для разработки системы контроля доступа биллинговой системы.

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

Глава 3. Разработка биллинговой системы

В данной главе будет проведена разработка биллинговой системы. Для этого будет проведена адаптация биллинговой платформы. После этого будет разработана система контроля доступа биллинговой системы. После этого биллинговая система будет интегрирована с Порталом муниципальных образований Пермского края permarea.ru.

3.1 Адаптация биллинговой платформы

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

Настраиваемая часть биллинговой платформы для процесса аренды сайтов - доступная только сотрудникам ИТИС состоит из 4 основных модулей:

1) Тип продукта - Аренда сайта

В данном модуле настроена основная информация о типе услуги - аренде сайта. Настройки модуля Тип продукта - Аренда сайта представлены на Рисунках. 3.1-3.2.



Рисунок 3.1 - Настройки модуля Тип продукта - Аренда сайта

2) Дата-центры - Дата-центр1

В данном модуле хранятся обработчики услуг.

Настройки модуля Дата-центры - Дата-центр1 представлены на Рисунке. 3.3.



Рисунок 3.2 - Настройки модуля Тип продукта - Аренда сайта

Рисунок 3.3 - Настройки модуля Дата-центры - Дата-центр1

3) Обработчики услуг - Обработчик аренды сайта

В данном модуле обрабатываются услуги аренды сайтов.

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

Настройки модуля Обработчики услуг - Обработчик аренды сайта представлены на Рисунке. 3.4

Рисунок 3.4 - Настройки модуля Обработчики услуг - Обработчик аренды сайта

4) Тарифные планы - Аренда сайта

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

Настройки модуля Тарифные планы - Аренда сайта представлены на рисунках. 3.5-3.6.



Рисунок 3.5 - Настройки модуля Тарифные планы - Аренда сайта



Рисунок 3.6 - Настройки модуля Тарифные планы - Аренда сайта

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

Если появится необходимость вручную изменить состояние или информацию о предоставляемой услуге для конкретного пользователя, сотрудники компании ИТИС могут изменить их на вкладке Услуги - Аренда сайтов.

ВкладкаУслуги - Аренда сайтов представлена на рисунке3.7.

Рисунок 3.7 - Вкладка Услуги - Аренда сайтов

Для работы с биллинговой платформой, можно настроить полномочия учетных записей различных сотрудников. Учетные записи сотрудников можно настраивать в модуле «Сотрудники»

Модуль «Сотрудники» представлен на рисунке. 3.8.

Рисунке 3.8 - Модуль «Сотрудники»

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

1) Административная

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

Полномочия административной учетной записи представлены на рисунке 3.9

2) Рабочая

Данная учетная запись предназначена для работы с услугой аренды сайтов.

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

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



Рисунке 3.9 - Полномочия административной учетной записи

Рисунке 3.10 - Полномочия рабочей учетной записи



Рисунке 3.11 - Полномочия рабочей учетной записи для модуля «Аренда сайта»

3) Техническая

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

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



Рисунке 3.12 - Полномочия технической учетной записи

Рисунке 3.13 - Полномочия технической учетной записи для модуля «Аренда сайта»

Кроме учетных записей сотрудников, существует еще один тип учетных записей - пользователи:

4) Пользователь

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

Вкладки личного кабинета пользователя представлены на Рисунках. 3.14-3.16.

Рисунок 3.14-Основная вкладка личного кабинета пользователя

Рисунок 3.15 - Вкладка Заказы личного кабинета пользователя

3.2 Разработка системы контроля доступа

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



Рисунок 3.16 - Настройки личного кабинета пользователя

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

1) Сервис проверки оплаты

Данная часть состоит из файла check.php

Любая страница сайта, на которую переходит пользователь должна ссылаться на файл check.php, в котором проводится проверка оплаты аренды сайта.

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

В ответ биллинговая система высылает XMLфайл с данными об оплате услуг аренды сайтов.

После этого с помощью DOM библиотеки PHPскрипт ищет в полученном файле информацию об оплате услуги аренды данного сайта.

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

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

Алгоритм работы сервиса проверки оплаты представлен на рисунке 3.17.

Листинг кода сервиса проверки оплаты check.php представлен в Приложении Б.

2) Страница - «Заглушка»

Данная часть состоит из страницы cap.php и CSSфайла стилей style.css.

При отсутствии оплаты, скрипт проверки оплаты аренды сайтов перенаправляет пользователей на данную страницу, показывающею отсутствие доступа к сайту.

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

Внешний вид страницы “заглушки”cap.phpпредставлен на рисунке 3.18.



Рис 3.17 - Алгоритм работы сервиса проверки оплаты



Рис 3.18 - Внешний вид страницы «заглушки» cap.php

3.3 Интеграция с порталом муниципальных образований Пермского края permarea.ru

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

Формализованная модель архитектуры сайта муниципального образования портала муниципальных образований Пермского края permarea.ru включая биллинговую систему в виде диаграммы классов представлена на Рисунках 3.19-3.20.



Рисунок 3.19- Диаграмма классов сайта муниципального образования портала permarea.ru включающая в себя биллинговую систему

Рисунок 3.20 - Класс, описывающий биллинговую системы

Класс billsystem (описывающий биллинговую систему) и класс framework (описывающий построение страниц портала) имеют связь композиция - рисунок 3.19.

Рисунок 3.21 - Связь классов billsystem и framework.

Это значит, что класс billsystem является частью классаframework, при этом один из параметров классаframeworkявляется объектом класса billsystem.

Листинг кода классаframeworkи принадлежащего ему класса billsystem представлены в приложении В.

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

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

- userlogin - поле содержит логин, под которым зарегистрирован владелец сайта в биллинговой платформе, тип String;

- billurl - поле содержит ссылку на личный кабинет владельца сайта в биллинговой платформе, тип String.

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

Диаграмма развертывания UML биллинговой системы, интегрированной с порталом permarea.ru, представлена на рисунке 3.21.

Рисунок 3.21 - Диаграмма развертывания биллинговой системы

Для того, чтобы сотрудники ИТИС могли интегрировать биллинговую систему с порталом муниципальных образований Пермского края permarea.ru, необходимо составить пошаговую инструкцию, основываясь на которой можно интегрировать биллинговую систему с каждым сайтом муниципальных образований, входящих в состав портала permarea.ru.

Инструкция для интегратора:

1) Разархивировать архив, содержащий файлы системы контроля доступа в корневую папку сервера портала;

2) Закрыть доступ к папке с файлами системы от арендатора (стандартное название папки, содержащей файлы системы контроля доступа -acs (Access Control System)).

3) Создатьв основной базе данных сайта таблицу с названием billsystem, включающей в себя поля userlogin (тип String) и billurl (тип String), содержащие в себе логин владельца сайта, под которым он зарегистрирован в биллинговой системе, и ссылку на личный кабинет пользователя соответственно.

4) В файле сервиса проверки оплаты check.php (расположен в папке acs) необходимо прописать данные для подключения к базе данных сайта (строки 4-7):

1. $host -адрес сервера;

2. $database -имя базы данных;

3. $user -имя пользователя базы данных;

4. $password -пароль для входа в базу данных.

Пример заполнения:

$host = 'localhost';

$database = 'database';

$user = 'root';

$password = '1234567';

Если же были изменены перемежённые, стандартно заданные в файле check.php, например, названия полей таблицы в базе данных, необходимо изменить соответствующие переменные с установленными параметрами.

5) Для запроса контроля доступа необходимо прописать обращение к файлу acs/check.php (например, прописать функцию “include ("./acs/check.php");”); Обращение должно прописываться в основной файл сайта (по умолчанию index.php), если необходимо осуществлять контроль доступа ко всему сайту, или прописываться на отдельных страницах сайта, доступ к которым необходимо контролировать.

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

3.4 Тестирование системы

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

Тестирование по методу черного ящика представлено в таблице 3.1

Таблица 3.1. Тестирование по методу черного ящика

№ теста	Действие	Входные данные	Ожидаемый результат	Реальный результат
1	Переход на сайт	Любая страница сайта …/somepagephp Аренда сайта оплачена	Вывод окна сайта	Вывод окна сайта
2	Переход на сайт	Любая страница сайта …/somepagephp Аренда сайта не оплачена	Переадресация на страницу - заглушку	Переадресация на страницу - “заглушку”
3	Переход на сайт	Страница сервиса контроля доступа check.php	Запрет доступа к странице	Запрет доступа к странице
4	Переход на сайт	Отсутствие доступа к проверке оплаты аренды сайта биллинговой платформыBillmanager	Переадресация на страницу - заглушку	Переадресация на страницу - заглушку
5	Переход на сайт	Отсутствие доступа к базе данных сайта	Переадресация на страницу - заглушку	Переадресация на страницу - заглушку
6	Запрос биллинговой системы	Неправильная авторизация в системеBillmanager	Отказ в выдаче информации об услугах аренды сайтов	Отказ в выдаче информации об услугах аренды сайтов
7	Запрос биллинговой системы	Отсутствие услуги аренды сайтов у владельца сайта	Возврат статуса услуги - услуга не активна	Возврат статуса услуги - услуга не активна
8	Запрос биллинговой системы	Услуга вручную остановлена администратором биллинговой платформы	Возврат статуса услуги - услуга не активна	Возврат статуса услуги - услуга не активна

Таким образом, биллинговая система адекватно реагирует на ошибки и нестандартные ситуации, что говорит о её отказоустойчивости.

В данной главе была разработана биллинговая система. Для этого была проведена адаптация биллинговой платформы для процесса аренды сайтов. Затем была разработана система контроля доступа, включая сервис проверки оплаты и страницу “заглушку”. После этого была проведена интеграция биллинговой системы с порталом муниципальных образований Пермского края permarea.ru, для чего была написана инструкция для интегратора. В конце было проведено тестирование разработанной биллинговой системы для проверки её реакции на различные нестандартные ситуации.

сайт автоматизированный управление бизнес

Заключение

Подводя итоги, в первой главе были рассмотрены основные понятия и функции биллинговых систем. После этого были рассмотрены и проанализированы процессы аренды сайтов, была построена модель существующих процессов «AS-IS». После этого, на основе полученной модели, были определены основные требования, предъявляемые системе. Затем были проанализирован Портал муниципальных образований Пермского края permarea.ru, с которым была интегрирована биллинговая система, и была рассмотрена биллинговая платформа Billmanager, используемая в разработке биллинговой системы.

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

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

Результатом данной работы является автоматизированная биллинговая система, состоящая из биллинговой платформы и системы контроля доступа, включающей в себя сервис проверки оплаты и страницу “заглушку”. Данная система была интегрирована с Порталом муниципальных образований Пермского края permarea.ru

Таким образом все поставленные в начале научной работы задачи были достигнуты:

1. Проведен анализ предметной области исследования, включая построение модели существующего процесса аренды сайтов AS-IS и описание требований к системе;

2. Спроектирована архитектура биллинговой системы включая построение модели работы биллинговой системы TO-BE и выбор способов её реализации;

Библиографический список

1. Аржененко А.Ю., Байраковский С.А., Вестяк В.А. Реализация механизма подключения провайдера в биллинговой системе авиапредприятия, настройка интерфейса взаимодействия с конечным пользователем // Труды МАИ. 2010. № 41. С. 17.

2. Бабенко М.Н. Требования, предъявляемые к биллинговым системам // Информационное противодействие угрозам терроризма. 2006. № 6. С. 157-169.

3. Взаимодействие через API -- ISPWiki [Электронный ресурс] / ISPWiki - документация на программное обеспечение для хостинга

4. Влад Мержевич «Учебник по HTML» [Электронный ресурс] / WebReference - Самоучитель HTML

5. Глухова Т.В., Брежнева А.И. Совершенствование инструментов управления информационными ресурсами предприятия // Мир науки и образования. 2015. № 4. С. 5.

6. Изучение PHP [Электронный ресурс] / PHP.SU - PHP, MySQL и другие веб-технологии

7. Кельдюшов С.С. Основные функции и критерии выбора биллинговых систем. // В сборнике: Мобильный бизнес: перспективы развития и реализации систем радиосвязи в России и за рубежом сборник материалов XXXIV международной конференции РАЕН. Конференция организована региональным отделением. 2013. С. 12-21.

8. Модель объектов XML-документов (DOM)[Электронный ресурс] / Microsoft Docs - Техническая документация, материалы по API и примеры кода

9. Петренко С.А., Петренко А.А Декомпозиция процессов организации // Защита информации. Инсайд. 2010. № 4 (34). С. 8-17.

10. Писаренко В.П., Вегера Д.В., Шиманчук К.А. Технология объединения биллинговой и платёжной системы для доступа к сети интернет // В сборнике: Информационные технологии XXI века сборник научных трудов. Хабаровск, 2017. С. 484-490.

11. Портал муниципальных образований Пермского края [Электронный ресурс] / Permarea - Портал муниципальных образований Пермского края

12. Портнов Е.М., Баин А.М., Чумаченко П.Ю. Методика натурного моделирования распределенных автоматизированных систем управления бизнес-процессами предприятий // Оборонный комплекс - научно-техническому прогрессу России. 2010. № 4. С. 27-30.

13. Разработка сайтов в Перми, компания «Инновационные технологии информационных систем»

14. Сметанин Ю.М., Бусоргин А.В. Особенности формирования и моделирования бизнес-систем: закономерности и процессы // Вестник Удмуртского университета. Серия Экономика и право. 2010. № 2-2. С. 32-41.

15. Сусов Р.В. ОЦЕНКА ПРИМЕНИМОСТИ ТЕХНОЛОГИЙ МОДЕЛИРОВАНИЯ ДЛЯ РАЗЛИЧНЫХ ЭТАПОВ ЖИЗНЕННОГО ЦИКЛА УПРАВЛЕНИЯ БИЗНЕС-ПРОЦЕССАМИ // Перспективы науки. 2012. № 1 (28). С. 86-90.

16. Школа PHP Программирования - курс уроков php, mysql, html, js[Электронный ресурс] / School-PHP: Школа PHP Программирования

17. Шпаков М.А., Латышев К.С. Концепция модели универсальной биллинговой системы // Вестник Балтийского федерального университета им. И. Канта. Серия: Физико-математические и технические науки. 2008. № 10. С. 99-103.

...