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

МИНОБРНАУКИ РОССИИ

Федеральное государственное бюджетное образовательное учреждение

высшего образования

"Пензенский государственный технологический университет"

(ПензГТУ)

Факультет информационных и образовательных технологий

Кафедра "Информационные технологии и системы"

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА

на тему: "Модуль автоматизации обслуживания клиентов предприятия в информационной системе IP-телефонии"

Выполнил: студент группы 13ИС2б Чинков М.Ю.

Руководитель: доцент каф. ИТС Коновалов А.В.

Пенза, 2016 г.

Перечень принятых сокращений

1) ВКР - выпускная квалификационная работа

2) БД - база данных

3) СУБД - система управления баз данных

4) РСУБД - реляционная система управления баз данных

5) ТФОП - телефонная сеть общего пользования

6) EA - Sparx Enterprise Architect

7) ПО - программное обеспечение

8) СПО - свободное программное обеспечение

9) ИС - информационная система

Содержание

• Перечень принятых сокращений
• Введение
• 1. Описание инфрмационной системы
• 1.1 Постановка задачи
• 1.2 Основная концепция системы
• 1.3 Анализ требований к системе
• 1.4 Описание предметной области
• 1.5 Сравнение систем IP-телефонии
• 1.5.1 Анализ существующих аналогов проектируемого модуля
• Выводы по разделу
• 2. Проектирование информационной системы
• 2.1 Разработка UML-диаграмм
• 2.1.1 Разработка моделей AS-IS
• 2.1.2 Разработка моделей TO-BE
• 2.1.2.1 Диаграмма вариантов использования (use-case diagram)
• 2.1.2.2 Диаграмма деятельности (activity diagram)
• 2.1.2.3 Диаграмма состояний (state diagram)
• 2.1.2.4 Диаграмма развертывания (deployment diagram)
• 2.1.2.5 Диаграмма последовательности (sequence diagram)
• 2.1.2.6 Диаграмма компонентов (component diagram)
• 2.2 Проектирование модели хранилища информации
• 2.2.1 Выделение сущностей, атрибутов, ключей, связей
• 2.2.1.1 Проектирование клиентской базы данных
• 2.2.1.2 Проектирование базы данных информационной системы
• 2.2.2 Проектирование диаграмм "сущность-связь"
• 2.3 Выводы по разделу
• 3. Реализация информационной системы
• 3.1 Формирование окружения для разработки системы
• 3.1.1 Система контроля версий
• 3.1.2 Контейнеризация тестового окружения
• 3.1.3 Выбор SIP-клиента
• 3.2 Реализация баз данных системы
• 3.3 Разработка модулей системы
• 3.3.1 Разработка диалплана информационной системы
• 3.3.2 Разработка основного модуля
• 3.3.3 Разработка подсистемы речевой обработки данных
• 3.3.4 Разработка подсистемы контроля вызовов
• 3.3.5 Разработка интерфейса базы данных
• 3.4 Тестирование работы системы
• 3.5 Реализация требований к модулю
• 3.6 Выводы по разделу
• Заключение
• Библиографический список
• Приложения

Введение

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

Задачи, поставленные в рамках выполнения выпускной квалификационной работы:

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

2) постановка задачи, выбор целевого потребителя, формирование концепции проекта, описываемого в работе, выбор необходимых инструментов для реализации;

3) проектирование составных компонентов модуля системы IP-телефонии, баз данных, необходимых для поддержки проекта;

4) реализация модуля информационной системы IP-телефонии sip_response посредством переноса концепции проекта в исходный код, предварительно выбрав инструменты для формирования окружения и тестирования проекта.

Предметной областью выпускной квалификационной работы является IP-телефония. Под IP-телефонией подразумевается набор коммуникационных протоколов, технологий и методов, обеспечивающих традиционные для телефонии набор номера, дозвон и двустороннее голосовое общение, а также видеообщение как по сети Интернет, так и по локальной сети. IP-телефония является современным аналогом телефонной сети общего пользования (далее - ТФОП), позволяя реализовать те задачи, которые реализуются в ТФОП, проще и дешевле. Модуль информационной системы IP-телефонии sip_response, работающий на базе платформы Asterisk, нацелен на усовершенствование такой функции IP-телефонии, как двухстороннее речевое общение в формате диалога.

Данная работа включает в себя 3 основных раздела:

1) анализ информационной системы: описание предметной области, а также модуля sip_response в частности; постановка задачи, поставленной перед непосредственной реализацией проекта; анализ требований, в рамках которых реализуется встраиваемый модуль; сравнение существующих систем IP-телефонии с последующим выбором одной из них, а также сравнение потенциальных конкурентов модуля на рынке;

2) проектирование модуля информационной системы: описание концепции проекта посредством реализации UML-диаграмм, проектирование составных компонентов (подмодулей) модуля sip_response, а также проектирование БД для поддержки работы модуля;

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

Также данная работа в качестве приложения содержит:

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

2) SQL-скрипты создания баз данных;

3) результаты работы проекта в виде снимков тестового окружения проекта.

1. Описание инфрмационной системы

В данном разделе приводится описание системы sip_response как модуля ИС IP-телефонии Asterisk. В данной части выпускной квалификационной работы описываются:

1) поэтапная постановка задач,

2) анализ требований к целевому программному продукту,

3) описание предметной области, на базе которой происходит реализация модуля,

4) анализ систем IP-телефонии, после которого сделан окончательный выбор базовой платформы для разработки модуля;

5) анализ существующих на рынке аналогов разрабатываемому модулю sip_response.

1.1 Постановка задачи

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

1) Внедрение ИС, отвечающей текущим и будущим потребностям целевой организации;

2) Повышение эффективности вложений.

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

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

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

Модуль взаимодействует с клиентом IP-телефонии через диалплан системы Asterisk. Диалплан (номерной план) - формальное описание схемы маршрутизации и обработки телефонных звонков. Диалплан подробно описывает, что система должна делать со входящими и исходящими звонками: передавать их дальше, сохранять, отвечать на них самостоятельно и так далее. В случае взаимодействия с модулем sip_response диалплан записывает клиентский запрос в аудиофайл и передает его на вход модулю. Модуль состоит из основной системы и связанных с ней подсистем.

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

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

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

3) если запрос выбран правильно (об этом система предварительно спрашивает пользователя), то пользователю отдается сформированный ответ на основании данных из клиентской базы.

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

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

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

телефония модуль информационная система

1.2 Основная концепция системы

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

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

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

После того, как стала известна цель проекта, сформирован следующий перечень основных задач со стороны заказчика ООО "ПриветБанк":

Интеграция решения с существующей инфраструктурой организации. В данном случае целевыми продуктами интеграции являются система IP-телефонии Asterisk, через которую происходит обработка клиентских запросов и СУБД PostgreSQL, в которой хранятся данные о клиентах организации.

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

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

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

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

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

1.3 Анализ требований к системе

При постановке задачи на внедрение/разработку ИС выполняется определение следующих требований:

1) функциональные требования;

2) требования к безопасности;

3) требования к удобству использования;

4) требования к производительности;

5) требования к срокам внедрения;

6) требования к ПО для сопровождения проекта;

7) требования к расходам на сопровождение проекта.

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

1) обработка базовых клиентских запросов (перечень запросов устанавливается на этапе проектирования модуля исходя из пожеланий заказчика);

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

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

1) Прослушать историю операций на банковском счете;

2) Получить информацию о действующих пенсионных программах;

3) Получить информацию о действующих кредитах;

4) Получить информацию о действующих вкладах;

5) Получить состояние пенсионной программы на банковском счете;

6) Получить состояние кредитов на банковском счете;

7) Получить состояние депозитов на банковском счете;

8) Получить последние новости нашего банка;

9) Получить информацию о текущем курсе валют нашего банка.

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

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

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

Под требованиями к удобству использования подразумевается простота установки, настройки и сопровождения программного продукта. В случае реализации модуля IP-телефонии sip_response появляется требование в автоматической установке модуля в существующую систему IP-телефонии без ручной установки дополнительного ПО.

Требования к производительности рассматривают:

1) идентичность поведения системы IP-телефонии в двух ситуациях: до и после установки модуля;

2) добавление модулем сравнительного небольшой нагрузки на систему в процессе работы;

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

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

Проектируемый модуль должен для корректной работы взаимодействовать с внешним ПО. В процессе постановки задач сформирован следующий перечень ПО, необходимого для запуска и эксплуатации модуля sip_response на сервере. Данный перечень показан в таблице 1.2.1 В системах, поле версии которых содержат символ "*", отсутствуют какие-либо требования по версии продукта.

Таблица 1.2.1 - перечень ПО, необходимый для работы модуля sip_response

№	Название	Тип	Версия	Описание
1	Linux	ОС (ядро)	>= 2.6	Платформа IP-телефонии Asterisk может работать только на Linux-дистрибутивах
2	Asterisk	Платформа IP-телефонии	>= 1.2	Целевая платформа запуска модуля sip_response
3	PostgreSQL	СУБД	>= 9.0	Необходим доступ к 2-м БД: клиентской БД и БД для модуля sip_response
4	Python	Интерпретатор ЯП	2.7	Необходим для запуска модуля
5	pip	Пакетный менеджер Python	*	Необходим для установки модулей Python, используемых модулем sip_response
6	ffmpeg	Программа	*	Транскодер mp3-файлов в wav
7	sox	Программа	*	Транскодер gsm-файлов в wav
8	libpq-dev	Системная библиотека	*	Системная библиотека для разработки под PostgreSQL
9	psycopg2	Модуль Python	*	Интерфейс к PostgreSQL
10	pyst2	Модуль Python	*	Интерфейс к Asterisk
11	pydub	Модуль Python	*	Интерфейс к ffmpeg
12	SpeechRecognition	Модуль Python	*	Интерфейс к API распознавания голосовых сигналов
13	gTTS	Модуль Python	*	Интерфейс к API конвертации текста в речь

1.4 Описание предметной области

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

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

IP-телефония является приложением более общей технологии VoIP (англ. Voice over IP) для организации двустороннего общения. Технология VoIP в общем случае подразумевает все варианты передачи голоса через IP, в том числе не имеющие никакого отношения к телефонии и общению людей.

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

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

2) конференция, переадресация звонка, автоматическое повторение номера, определение номера звонящего, предоставляются бесплатно, тогда как в традиционных телекоммуникационных компаниях обычно выставляются в счёт;

3) независимость от месторасположения. Нужно только Интернет-соединение для подключения к провайдеру IP-телефонии;

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

На рисунке 1.4.1 представлена обобщенная схема работы IP-телефонии, а также возможность её синхронизации с ТФОП.

Рисунок 1.4.1 - схема работы IP-телефонии

Стоимость вызова в IP-телефонии определяется по так называемой "системе с минимальной стоимостью маршрутизации звонка" (LCR, Least Cost Routing System), которая основана на том, что осуществляется проверка пункта назначения каждого телефонного звонка, как только он сделан внутри сети, что даёт потребителю самую низкую цену. Протоколы IP-телефонии обеспечивают регистрацию клиентского устройства (шлюз, терминал или IP-телефон) на сервере провайдера, вызов или переадресацию вызова, установление соединения, передачу имени и номера абонента. В настоящее время широкое распространение получил протокол SIP - протокол сеансового установления связи, обеспечивающий передачу голоса, видео, сообщений систем мгновенного обмена сообщений и произвольной нагрузки, для сигнализации обычно использует порт 5060 протокола установления соединения UDP. Поддерживает контроль присутствия.

1.5 Сравнение систем IP-телефонии

В настоящее время на рынке свободного программного обеспечения существует немало решений для развертывания системы IP-телефонии на базе серверного программного обеспечения. Ниже приводится таблица сравнения платформ для развертывания серверного программного обеспечения IP-телефонии. Критерии объема документации системы и величины пользовательского сообщества оценивались по десятибалльной шкале (0 - отсутствие критерия в структуре программного продукта, 10 - компонент программного обеспечения доведен до совершенства и является одним из его основных преимуществ).

Таблица 1.5.1 - Сравнение серверного ПО IP-телефонии по данным на 03.12.2015 г.

Сервер IP-телефонии	Asterisk	FreeSWITCH	FreePBX	Elastix
Протоколы соединения	SIP	+	+	+	+
	H.323	+	+	+	+
	VOFR	+	-	-	-
	XMPP	+	+	+	+
	IAX	+	+	+	+
	GT	+	+	-	-
	TDM	+	-	-	-
	Skype	-	+	-	-
Релизный цикл	1 год	1 год	1 год	2 года
Оценка объема документации системы	10	9	7	6
Оценка величины пользовательского сообщества	10	8	5	4

Самые известные из рассмотренных в таблице платформ - это Asterisk и FreeSwitch. В рамках анализа предметной области и разработки модуля распознавания и обработки речевых сигналов в качестве базового ПО выбран сервер Asterisk, так как информация о конфигурации и основных принципах работы данной системы более понятна и доступна, чем в FreeSwitch, что наиболее важно для новичков в области IP-телефонии. Также весьма важным фактором является разделение рассматриваемых систем на рынке по популярности. Таким образом, спроектированный модуль sip_response будет иметь все возможности использования свойства популярности базовой платформы.

1.5.1 Анализ существующих аналогов проектируемого модуля

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

В ходе анализа существующих аналогов модуля sip_response найдено небольшое количество похожих решений, имеющих ограниченный функционал по сравнению с реализуемым программным продуктом. В таблице 1.5.2 приводятся результаты сравнения подобных программных модулей, работа которых имеет общую аналогию с модулем sip_response. Стоит добавить, что оба модуля имеют лицензирование GPL (General Public License), продукты которого распространяются бесплатно с возможностью участия в дальнейшей разработке ПО.

Таблица 1.5.2 - Сравнение аналогов программного модуля sip_response

Название модуля	res_speech	ASR
Платформа IP-телефонии	Asterisk	FreeSWITCH
Функция распознавания речи.	+	+
Лицензирование модуля	GPL	GPL
Конвертация речи в текстовый формат.	-	+
Грамматическая проверка сообщения.	+	-
Наличие полноценной документации.	-	-
Наличие бизнес-логики.	-	-

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

Выводы по разделу

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

2. Проектирование информационной системы

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

В данном разделе ВКР описана основная концепция системы, выделена идея, которая отображена в формате UML-диаграмм. Далее в разделе приведено описание проектирования хранилища данных, состоящего из двух баз данных - БД приложения sip_response и БД клиентов организации (в данном случае банка).

2.1 Разработка UML-диаграмм

2.1.1 Разработка моделей AS-IS

Модель AS-IS - модель существующего состояния организации (в переводе с английского означает "как есть"). Данная модель позволяет систематизировать протекающие в данный момент процессы, а также используемые информационные объекты. На основе этого выявляются узкие места в организации и взаимодействии бизнес-процессов, определяется необходимость тех или иных изменения в существующей структуре. Такую модель часто называют функциональной и выполняют с использованием различных графических нотаций и case-средств. На этапе построения модели AS-IS важным считается строить максимально приближенную к действительности модель, основанную на реальных потоках процессов, а не на их идеализированном представлении.

В разработанном комплексе диаграмм UML в качестве моделей AS-IS воспринята та модель процессов организации, которая существовала до начала использования модуля IP-телефонии sip_response. Модель AS-IS описана в виде диаграммы вариантов использования, показанной на рисунке 2.2.1 Данная диаграмма показывает следующий подход к обработке запросов клиентов. В любом случае в любой момент времени на запрос отвечает оператор первой линии технической поддержки. Перенаправление на рабочую станцию оператора осуществляет диалплан сконфигурированной системы Asterisk. После консультации и удовлетворения потребности пользователя в информации вызов завершается. Однако даже после вызова происходит рутинная работа со стороны оператора. Оператор протоколирует сведения о вызове через специальное приложение для работы с базой данных организации.

Рисунок 2.2.1 - диаграмма вариантов использования (use-case) до внедрения модуля sip_response

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

2.1.2 Разработка моделей TO-BE

Проектирование информационных систем и управление процессами подразумевает построение модели AS-IS и дальнейший переход к модели TO-BE, что является залогом автоматизации "правильных", усовершенствованных процессов.

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

В разработанном комплексе диаграмм UML в качестве моделей TO-BE можно представить следующие виды диаграмм:

1) диаграмма вариантов использования;

2) диаграмма деятельности;

3) диаграмма состояний;

4) диаграмма развертывания;

5) диаграмма последовательности;

6) диаграмма компонентов;

7) диаграмма классов.

2.1.2.1 Диаграмма вариантов использования (use-case diagram)

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

Полный вариант диаграммы вариантов использования показан в приложении А. Основными компонентами данной диаграммы являются актеры и варианты использования.

Диаграмма включает в себя следующих актеров:

1) пользователь системы - главный актер в системе, который передает запрос и принимает ответ на него, а также может в любой момент прервать соединение;

2) диалплан IP-телефонии - механизм управления модулем sip_response от лица системы IP-телефонии Asterisk; подтверждает завершение вызова и выводит сообщение клиенту системы;

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

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

1) запрос в службу технической поддержки организации;

2) формирование ответа на запрос (включает в себя процесс запроса в службу поддержки, а также подпроцессы преобразования сообщения в текстовый формат, проверку контекста запроса и аутентификацию пользователя);

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

4) завершение вызова (включает запись информации о вызове в базу данных);

5) перенаправление вызова специалисту центра технической поддержки.

Диаграмму можно сравнить с аналогичной моделью AS-IS, описанной выше. Целью проектирования модели являлся подробный обзор улучшений, вносимых в существующую систему IP-телефонии модулем sip_response. Большинство вариантов использования, направленных на обработку запроса клиента как актера use-case диаграммы, происходят без участия человека. Исключением является ситуация, когда запрос является нестандартным и подсистема контроля вызова не может сгенерировать ответ. В таком случае вызов перенаправляется в узкоспециализированный центр поддержки (в диаграмме данный вариант указан в виде соединения extent). Каждый вариант использования можно представить как ассоциацию между клиентом организации и средствами автоматизации области клиентской поддержки.

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

2.1.2.2 Диаграмма деятельности (activity diagram)

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

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

1) Диалплан IP-телефонии - данная подсистема воспроизводит пользователю стартовый вопрос, ответ на пользовательский запрос, сгенерированный модулем sip_response, перенаправляет вызов в центр технической поддержки, а также обрабатывает процесс завершения вызова;

2) Модуль распознавания речи - данная подсистема в качестве основной задачи имеет процесс преобразование пользовательского запроса из речевого формата в текстовый посредством запросов к API внешней системы распознавания речи Google Speech;

3) Модуль контроля вызова - данный модуль обрабатывает множество условий, от которых зависит результат ответа на пользовательский запрос и запускает процессы формирования ответа на запрос, аутентификации пользователя, а также записи в базу данных;

4) Интерфейс БД - данная подсистема отправляет запросы к базам данных, полученные от модуля контроля вызова, и передает их в окончательном итоге;

5) Хранилище данных - под хранилищем данных представлены 2 базы данных - БД организации-клиента и БД модуля sip_response, из которых считывается информация подсистемами модуля sip_response.

2.1.2.3 Диаграмма состояний (state diagram)

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

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

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

Данная диаграмма показывает следующие состояния работы модуля sip_response:

1) преобразование ответа в текстовый формат - голосовое сообщение пользователя преобразуется в текстовый формат, при этом текст хранится в файле;

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

3) формирование ответа на клиентский запрос - после подтверждения личности пользователя система генерирует полноценный ответ на запрос на основании найденного запроса и данных из клиентской БД;

4) преобразование ответа в речевой формат - сформированный текст запроса преобразуется в голосовое сообщение с помощью запроса к системе обработки речевых сигналов;

5) вывод голосового сообщения - диалплан воспроизводит пользователю сформированное голосовое сообщение, ожидая его ответ;

6) соединение со специалистом - система может перейти в данное состояние только в том случае, если система не нашла запрос, удовлетворяющий потребностям клиента; в таком случае происходит ручная обработка запроса специалистом центра технической поддержки;

7) завершение соединения - система может перейти в данное состояние в любой момент времени, когда пользователь повесил трубку, тем самым разорвав соединение с системой; на данном этапе происходит обработка данных о вызове и запись сформированной информации в базу данных.

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

2.1.2.4 Диаграмма развертывания (deployment diagram)

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

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

Список компонентов, показанных на диаграмме развертывания:

1) телефон пользователя, с которого пользователь совершает вызов в систему;

2) банк каналов - инструмент преобразования аналогового сигнала, полученного от линии АТС, в сетевые пакеты, которые впоследствии передаются по IP-сети;

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

4) операционная система - ПО абстракции пользовательских программ от особенностей и спецификаций аппаратного обеспечения на машине;

5) система IP-телефонии - ПО, обрабатывающее пользовательские запросы;

6) модуль IP-телефонии sip_response - объект проектирования данной работы;

7) СУБД PostgreSQL - система, которая управляет базами данных, используемыми в процессе работы модуля sip_response;

8) телефон специалиста - устройство, на которое система IP-телефонии перенаправляет запрос в том случае, если модуль sip_response его не может обработать;

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

2.1.2.5 Диаграмма последовательности (sequence diagram)

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

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

Рисунок 2.1.2.5.1 - диаграмма последовательности обработки клиентского запроса

Данная диаграмма описывает обработку запроса модулем IP-телефонии sip_response в состоянии, когда запрос обработан успешно. В данном случае сам запрос не является чрезвычайно сложным для модуля и соединение с клиентом не разорвано. Каждый компонент схемы (клиент как актер, подсистемы модуля как activity-классы) выполняет определенную операцию, результатом которой является перенос управления работой информационной системы к другому компоненту.

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

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

Рисунок 2.1.2.5.2 - диаграмма последовательности процесса обработки разрыва соединения

Данная диаграмма описывает последовательность действий модуля после завершения соединения с клиентом и обработки клиентского запроса в частности. Задачей совместной работы структурных компонентов диаграммы является запись в БД модуля sip_response информации о соединении (дата начала и окончания, текст запроса, факт успешной обработки запроса системой, факт перенаправления запроса в центр поддержки):

1) диалплан вызывает подсистему контроля вызова через основную подсистему для записи информации о вызове в базу данных;

2) подсистема контроля вызова фиксирует данные соединения с пользователем и отправляет их в базу модуля sip_response через SQL-запрос;

3) запрос проходит через интерфейс базы данных, установивший соединение с СУБД PostgreSQL.

2.1.2.6 Диаграмма компонентов (component diagram)

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

Диаграмму компонентов, можно увидеть в приложении А. На диаграмме указаны следующие компоненты:

1) система IP-телефонии Asterisk;

2) диалплан как компонент системы IP-телефонии;

3) модуль системы IP-телефонии sip_response (объект проектирования данной выпускной квалификационной работы);

4) подсистемы модуля sip_response (основная подсистема, подсистема контроля вызова, интерфейс БД);

5) клиентская БД, в которой хранятся сведения о клиентах организации;

6) БД модуля sip_response, в которой хранится информация, необходимая для обработки пользовательского запроса;

7) СУБД PostgreSQL, которая управляет доступом к данным БД, перечисленных выше;

8) хранилище аудиофайлов, представленное в виде директории в файловой системе сервера;

9) транскодер аудиофайлов, преобразующий аудиофайлы в формат wav и gsm;

10) система распознавания речи Google Speech.

Основные процессы взаимодействия между компонентами:

взаимодействие между пользователем и системой IP-телефонии (диалплан записывает пользовательский запрос, отправляет его на обработку в модуль sip_response, и по окончанию обработки отправляет пользователю, сгенерированный модулем ответ на запрос);

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

взаимодействие между подсистемой обработки речевых сигналов и транскодером FFmpeg (транскодер преобразовывает аудиофайлы в форматы wav и gsm, отправляя ссылку на сгенерированные файлы подсистеме обработки речевых сигналов);

взаимодействие между подсистемой обработки речевых сигналов и системой распознавания речи Google Speech (подсистема обработки речевых сигналов отправляет запрос на распознавание в Google Speech API через модуль Python SpeechRecognition и получает ответ в виде текста, записывая его в файл);

взаимодействие между основной подсистемой и подсистемой контроля вызовов (основная подсистема вызывает функции поиска запроса, аутентификации и генерирования ответа на пользовательский запрос);

взаимодействие между подсистемой контроля вызовов и интерфейсом БД (подсистема контроля вызова отправляет запрос на выборку или вставку данных в базу через интерфейс);

взаимодействие между подсистемой контроля вызовов и хранилищем аудиофайлов (подсистема контроля вызовов находит по абсолютному пути к файлу необходимую фразу-шаблон и вставляет её в ответ пользователю);

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

2.2 Проектирование модели хранилища информации

С точки зрения теории разработку модели хранилища информации можно разделить на 5 стадий: выбора СУБД, формализации, графического отображения, реализации и проверки корректности схемы БД. Перед началом разработки модели рассмотрено встроенное хранилище данных системы IP-телефонии Asterisk - NoSQL базу данных BerkleyDB, которая данные в формате ключ-значение. В ходе анализа сформулирована мысль о непригодности данного формата хранения информации для нужд модуля sip_response, поэтому хранилище информации разрабатывалось независимо от решения в системе Asterisk.

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

Среди наиболее популярных РСУБД (PostgreSQL, MySQL, SQLite, Firebird, Oracle, MS SQL) для реализации хранилища информации выбрана платформа PostgreSQL. Выбор сделан по той причине, что PostgreSQL является продуктом СПО, имеет открытый исходный код, проста в эксплуатации небольших баз данных и имеет более высокий темп развития по сравнению с аналогами.

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

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