Модуль информационной системы IP-телефонии

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

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

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

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

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

(ПензГТУ)

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

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

КУРСОВОЙ ПРОЕКТ

Дисциплина «Методы и средства проектирования информационных систем и технологий»

на тему: «Модуль информационной системы IP-телефонии»

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

Руководитель: ст. преподаватель кафедры ИТС Пискаев К.Ю.

Пенза, 2016 г.



ПЕРЕЧЕНЬ ПРИНЯТЫХ СОКРАЩЕНИЙ

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

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

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

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

5) EA - Sparx Enterprise Architect

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

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



СОДЕРЖАНИЕ

• ВВЕДЕНИЕ
• 1. АНАЛИЗ СОВРЕМЕННОГО СОСТОЯНИЯ IP-ТЕЛЕФОНИИ
• 1.1 Общие сведения о предметной области
• 1.2 Общие сведения о проекте
• 1.3 Анализ современных систем IP-телефонии
• 1.4 Анализ правоохранительных документов в системах IP-телефонии
• 1.4.1 Анализ законодательных актов РФ
• 1.4.2 Патентный поиск в области IP-телефонии
• 1.5 Источники информации о предметной области
• 1.6 Технические требования к проектируемому системному модулю
• Выводы по разделу
• 2. АНАЛИЗ, РАЗРАБОТКА МОДЕЛЕЙ И ТРЕБОВАНИЙ К ПРОЕКТУ
• 2.1 Общие сведения
• 2.2 Разработка моделей AS-IS
• 2.3 Разработка требований к проекту
• 2.4 Разработка моделей TO-BE
• 2.5 Разработка модели хранилища информации
• 2.5.1 Выделение сущностей, атрибутов, ключей, связей
• 2.5.2 Проектирование диаграммы «сущность-связь»
• Выводы по разделу
• 3. ПРОЕКТИРОВАНИЕ МОДУЛЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ IP-ТЕЛЕФОНИИ
• 3.1 Общие сведения о разработке информационной системы
• 3.2 Анализ хранилища информации системы Asterisk
• 3.3 Реализация хранилища информации модуля
• 3.4 Формирование алгоритмов реализации компонентов модуля
• 3.4.1 Запускаемый файл модуля
• 3.4.2 Подсистема обработки речевых сигналов
• 3.4.3 Подсистема контроля вызова
• 3.4.4 Конфигурация диалплана системы Asterisk
• 3.5 Экономическое обоснование эффективности модуля
• 3.5.1 Расчет себестоимости модуля
• 3.5.2 Расчет сроков окупаемости модуля sip_response
• 3.5.3 Расчет точки безубыточности модуля sip_response
• 3.6 Безопасность и надежность модуля
• 3.6.1 Анализ возможных угроз информационной безопасности
• 3.6.2 Анализ модели противодействия угрозам ИБ системы Asterisk
• 3.6.3 Реализация функции надежности модуля
• Выводы по разделу
• ЗАКЛЮЧЕНИЕ
• БИБЛИОГРАФИЧЕСКИЙ СПИСОК
• ПРИЛОЖЕНИЕ А
• ПРИЛОЖЕНИЕ Б
• ПРИЛОЖЕНИЕ В
• ПРИЛОЖЕНИЕ Г

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

1) техническое задание на проект;

2) разработанные модели, отображающие концепцию проекта;

3) схематическое представление хранилища данных и отрывок SQL-кода создания таблиц БД;

4) псевдокод, описывающий алгоритм работы подсистем модуля.



1. АНАЛИЗ СОВРЕМЕННОГО СОСТОЯНИЯ IP-ТЕЛЕФОНИИ

1.1 Общие сведения о предметной области

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

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

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

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

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

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

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

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

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

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

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

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

1.2 Общие сведения о проекте

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

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

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

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

Диалпланом системы IP-телефонии называется механизм, который описывает логику работы Asterisk, а именно, обработку входящих вызовов, маршрутизацию исходящих вызовов, обработку звонков и событий по разнообразным правилам. Диалплан - это сердце Asterisk. За работу диалплана отвечает файл extensions.conf в системе Asterisk. Файл поделен на контексты, в каждом из которых прописана логика работы.

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

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

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

1.3 Анализ современных систем IP-телефонии

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

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

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

Сервер IP-телефонии	Asterisk	FreeSWITCH	FreePBX	Elastix
Протоколы соединения	SIP, H.323, IAX, MGCP, VOFR, XMPP, Google Talk, TDM	SIP, NAT-PMP, STUN, SIMPLE, XMPP, Google Talk (Jingle), IAX, H.323, MRCP, RSS, Skype	SIP, IAX, H323, XMPP	SIP, IAX, H323, XMPP
Протоколы шифрования соединения	TLS, SRTP	TLS, SRTP, ZRTP	TLS, SRTP, ZRTP	-
Дата выхода последней версии	9.10.2014 г.	23.09.2015 г.	1.10.2014 г.	6.02.2013 г.
Оценка объема документации системы	10	7	6	5
Оценка величины пользовательского сообщества	10	8	5	3

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

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

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

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

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

1.4 Анализ правоохранительных документов в системах IP-телефонии

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

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

1.4.1 Анализ законодательных актов РФ

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

Однако в ближайшее время ситуация с регулированием IP-телефонии и её абонентских соединений в частности может выйти из-под контроля и не соответствовать выдержке из закона, приведенной выше. В момент написания данной курсового проекта в Государственной думе готовился проект поправок в Закон «О связи», направленный против операторов, использующих при междугородных и международных звонках интернет-каналы, а именно -- против подмены номера при междугородных и международных звонках. Закон ударит по компаниям-посредникам, которые с помощью IP-телефонии помогают экономить абонентам крупных операторов. В обосновании проекта его авторы указывают, что звонки через Интернет с подменой номера угрожают проведению оперативно-розыскных мероприятий, не обеспечивают качество связи и снижают доходы государства из-за того, что крупные операторы недополучают деньги за междугородную и международную связь и платят меньше налогов. В документе указано, что оператор, участвующий в установлении телефонного соединения, обязан передавать в неизменном виде информацию о номере абонента. При звонке через такой сервис телефонный номер звонящего отображается как местный номер, но перезвонить на него нельзя. Оператор, нарушивший это требование, может быть лишён лицензии.

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

Что касается возможности прослушивания телефонных разговоров, то данная деятельность является незаконной по законодательству РФ. Согласно Конституции РФ, каждый имеет право на тайну переписки, телефонных переговоров, почтовых, телеграфных и иных сообщений; ограничение этого права допускается только на основании судебного решения [6, ст. 23, ч. 2].

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

1.4.2 Патентный поиск в области IP-телефонии

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

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

Источником патентного поиска являлась российская база патентов ФИПС. Патентный поиск в системе ФИПС был выполнен в бесплатной базе данных от лица гостевого пользователя. Поиск выполнялся по трем ключевым словам: «информационная», «система» и «IP-телефония». В результате поиска были найдены 2 документа, где были описаны патенты на полезную модель. Данные патенты удовлетворяют целям патентного исследования, но при этом основная концепция запатентованных проектов различается с концепцией модуля sip_response. Таким образом, создание модуля sip_response как самостоятельного программного продукта не противоречит законодательным актам РФ.

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

1) «Программный комплекс анализа и воспроизведения речевых сообщений IР-телефонии» (номер заявки: 2013616278). Программный комплекс предназначен для мониторинга и последующего воспроизведения речевых сообщений приложений IP-телефонии. В процессе функционирования программный комплекс позволяет осуществлять выявление в регистрируемом сетевом трафике протокольных блоков данных, содержащих данные IP-телефонии, их отбор, изменение и ретрансляцию на вход воспроизводящего комплекса.

2) Программа для обработки данных IP-телефонии (номер заявки: 2014662097). Программа предназначена для обработки сигналов, а также сообщений, IP-телефонии и применяется в системах цифровой пакетной передачи речевых сообщений. Программа обеспечивает автоматическое распознавание и обработку сигналов систем сигнализации IP-телефонии по протоколам DSS-1, SIP, RTCP, а также выделение речевых сообщений, кодированных согласно Рекомендациям ITU-T G711, G711a, G711u, G722, G723, G728, G729, GSM 610, SPEEX в сеансах связи по протоколу RTP.

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

1.5 Источники информации о предметной области

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

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

1) Книга «Астериск - будущее телефонии»[1]. Эту книгу можно назвать «альма-матером» новичка системы Asterisk. В данной книге наиболее подробно описаны процесс установки, конфигурации и улучшения функционала системы, а также объяснена концепция диалплана - основного компонента платформы Asterisk. Также в книге приведены первоначальные рекомендации к разработке дополнений к системе.

2) Форум Asterisk Community[14]. В данном форуме можно найти немало информации о реализации тех или иных задач при разработке системного модуля, а также проконсультироваться в случае возникновения тех или иных проблем.

3) IRC-канал (#asterisk). IRC (Internet Relay Chat) -- протокол прикладного уровня для обмена сообщениями в режиме реального времени. Разработан в основном для группового общения, также позволяет общаться через личные сообщения и обмениваться данными, в том числе файлами.

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

IRC-канал (#asterisk-dev). В отличие от основного IRC-канала #asterisk уделяет больше внимание процессу разработки как самой системы Asterisk, так и всевозможных дополнений к системе. Наиболее важным вопросом остается методология разработки программного продукта под платформу IP-телефонии, а именно: что и как нужно использовать для эффективного написания программного кода и какие инструменты обычно используются для тестирования.

1.6 Технические требования к проектируемому системному модулю

В данном подразделе описываются требования к модулю платформы Asterisk sip_response как к субъекту сферы IP-телефонии в целом, а также как к интегрируемому дополнению к серверной платформе Asterisk.

Основные требования.

1) Совместимость модуля с версией платформы Asterisk, являющейся последней на момент формирования этапов разработки проекта (версия 13.5).

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

3) Представление основного функционала системного модуля в качестве Open Source-решения без коммерческой выгоды, подтверждая этот факт лицензией GPL.

4) Поддержка совместимости со всеми Linux-дистрибутивами, на которых может работать система Asterisk.

5) Соответствие законодательным актом как внутри РФ (раздел 1.3), так и международным законодательным актам.

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

1) Аппаратное устройство объединения телефонной сети общего пользования (ТФОП) и IP-сети. Это может быть банк каналов, позволяющий подключить до 30 линий ТФОП к IP-сети. Решение довольно интересное как по финансовым затратам, так и по функционалу. На рисунке 1.6.1 представлена схема работы банка каналов.

Рисунок 1.6.1 - схема работы банка каналов.

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

3) Операционная система AsteriskNOW или любая другая операционная система GNU/Linux, поддерживающая работу платформы Asterisk. Здесь следует отметить, что система AsteriskNOW будет являться наиболее оптимальным и простым решением. AsteriskNOW 6.12 - дистрибутив семейства Linux. Данный дистрибутив создан на основе операционной системы CentOS 6.5, в которую дополнительно были добавлены Web-интерфейс конфигурации IP-телефонии FreePBX 5.211 и сервер IP-телефонии Asterisk 11. СУБД MySQL также была включена в дистрибутив с развернутыми БД asterisk и asteriskcdrdb. На рисунке 1.6.2 показан стартовый экран операционной системы AsteriskNOW.

Рисунок 1.6.2 - стартовый экран операционной системы AsteriskNOW

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

5) Интерпретатор языка программирования Python версии 3 (доставляется в системы GNU/Linux посредством установки пакетов python и python-dev).

6) Реляционная СУБД, хранящая базу данных платформы Asterisk. Это может быть, как MySQL, так и PostgreSQL, и Oracle Database.

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

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

Общую структуру программно-аппаратного комплекса системы IP-телефонии можно увидеть в виде UML-диаграммы развертывания. Данная диаграмма указана в приложении Б.4.

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

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



2. АНАЛИЗ, РАЗРАБОТКА МОДЕЛЕЙ И ТРЕБОВАНИЙ К ПРОЕКТУ

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

2.1 Общие сведения

Стадии формирования модели предметной области:

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

2) применение графических средств отображения модели;

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

4) обеспечение оценки эффективности реализации модели предметной области на основе определенных методов и вычисляемых.

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

Унифицированный язык объектно-ориентированного моделирования Unified Modeling Language (UML) явился средством достижения компромисса между этими подходами. Существует достаточное количество инструментальных средств, поддерживающих с помощью UML жизненный цикл информационных систем, и, одновременно, UML является достаточно гибким для настройки и поддержки специфики деятельности различных команд разработчиков.

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

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

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

Анализ требований включает три типа деятельности.

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

2) Анализ требований -- определение, являются ли собранные требования неясными, неполными, неоднозначными или противоречащими; решение этих проблем; выявление взаимосвязи требований.

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

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

AS-IS - модель «как есть», модель существующего состояния организации.

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

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

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

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

2.3 Разработка требований к проекту

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

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

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

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

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

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

3) Система должна корректно сформировать ответ на клиентский запрос, удовлетворив его потребность.

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

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

Техническое задание позволяет исполнителю проекта понять суть задачи, показать заказчику «технический облик» будущего программного изделия или автоматизированной системы, отказаться от выполнения работ, не указанных в ТЗ, а заказчику -- осознать, что именно ему нужно, требовать от исполнителя соответствия продукта всем условиям, оговорённым в ТЗ. Также техническое задание позволяет избежать ошибок, связанных с изменением требований (на всех стадиях и этапах создания, за исключением испытаний).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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