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

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

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

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

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

(ПензГТУ)

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

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

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

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

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

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

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

Пенза, 2016 г.

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

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

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

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

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

5)EA - Sparx Enterprise Architect

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

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

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

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 Реализация функции надежности модуля

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

ЗАКЛЮЧЕНИЕ

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

ПРИЛОЖЕНИЕ А

ПРИЛОЖЕНИЕ Б

ПРИЛОЖЕНИЕ В

ПРИЛОЖЕНИЕ Г

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На рисунке 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-телефонииAsteriskFreeSWITCHFreePBXElastixПротоколы соединенияSIP, H.323, IAX, MGCP, VOFR, XMPP, Google Talk, TDMSIP, NAT-PMP, STUN, SIMPLE, XMPP, Google Talk (Jingle), IAX, H.323, MRCP, RSS, SkypeSIP, IAX, H323, XMPPSIP, IAX, H323, XMPPПротоколы шифрования соединенияTLS, SRTPTLS, SRTP, ZRTPTLS, SRTP, ZRTP-Дата выхода последней версии9.10.2014 г.23.09.2015 г.1.10.2014 г.6.02.2013 г.Оценка объема документации системы10765Оценка величины пользовательского сообщества10853

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

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

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

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

Эту проблему должен решить 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 как самостоятельного программного продукта не противоречит законодательным актам РФ.

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

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

) Программа для обработки данных 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]. Эту книгу можно назвать «альма-матером» новичка системы Asterisk. В данной книге наиболее подробно описаны процесс установки, конфигурации и улучшения функционала системы, а также объяснена концепция диалплана - основного компонента платформы Asterisk. Также в книге приведены первоначальные рекомендации к разработке дополнений к системе.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

) Операционная система 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

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

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

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

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

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

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

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

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

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

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

.1 Общие сведения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.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 в бизнес-процессах организации позволит избавиться от этих проблем.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Диаграмму компонентов, разработанную в ходе выполнения данной курсового проекта, можно увидеть в приложении Б. В данной модели отмечено взаимодействие платформы IP-телефонии Asterisk со встраиваемым модулем sip_response. Главным компонентом платформы Asterisk является диалплан, принимающий клиентский запрос как речевой сигнал и воспроизводящий сгенерированный запрос как простой аудиофайл. После приема входных данных диалплан перенаправляет их на вход модулю sip_response, где в свою очередь поочередно активизируются подсистемы, обрабатывающие запрос в различном формате. Также в данной диаграмме описано хранилище данных модуля в качестве простого объекта, включающего в себя TCP-порт 3306, используемый для соединения с самой системой IP-телефонии.

.5 Разработка модели хранилища информации

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

На стадии формализации была сформирована схема базы данных встраиваемого модуля Asterisk sip_response, распределены данные по таблицам в соответствии с теориями нормальных форм, выделены сущности, атрибуты, ключи, связи между таблицами - компоненты, формирующие БД. Стадия применения графических средств отображения модели была реализована инструментом визуального моделирования Sparx Enterprise Architect посредством добавления таблиц, атрибутов, формирования первичных и внешних ключей и визуализации конечной схемы БД. Стадия реализации состояла заключалась впереносе структурной схемы хранилища данных непосредственно в РСУБД посредством запуска сгенерированного SQL-кода. Стадия проверки заключалась в отображение диаграмм как анализируемой, так и отредактированной БД в графическом формате. При тестировании реализации хранилища данных в данном случае использовался веб-инструмент администрирования СУБД phpMyAdmin.

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

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

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

Таблицы спроектированы в соответствии с теорией пяти нормальных форм:

)значения всех атрибутов таблицы атомарны (неделимы);

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

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

)отсутствуют многозначные зависимости, не являющиеся функциональными зависимостями;

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

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

В соответствии с теорией нормальных форм информация об истории звонков была разделена на 4 таблицы: call_info (время и продолжительность звонка, ссылка на mp3-файл записи звонка), call_members (ID диктора, голос которого был использован во время звонка и личные данные клиента: имя, фамилия, место проживания), call_number (абонентский номер) и call_status (номер канала соединения и статус ответа на звонок). В таблицах 2.5.1.1-2.5.4.4 представлена структура вышеперечисленных таблиц, атрибуты, тип данных атрибутов, а также выделены атрибуты, играющие роль первичного ключа (PK) и внешнего ключа (FK).

Таблица 2.5.1.1 - Таблица БД call_info

call_id (int)call_date (datetime)duration (time)call_record (varchar(30))PK

Таблица 2.5.1.2 - Таблица БД call_status

call_id (int)speaker_id (int)channel_number (int)status (varchar(20))PK+FK (call_info)FK (speakers)

Все таблицы, содержащие информацию о звонках, используют в качестве первичного ключа уникальный ID звонка. Таблицы call_status, call_member и call_number связаны с таблицей call_info через внешний ключ - столбец call_id (вид связи: один ко многим). Также стоит отметить, что телефонный номер разделен на три атрибута для соблюдения правила атомарности атрибутов. В атрибуте call_record содержатся ссылки на записи звонков, а не сами аудиофайлы, так как хранение медиафайлов в БД замедляет работу с ней.

Таблица 2.5.1.3 - Таблица БД call_member

call_id (char)country_code (varchar)operator_code (int)phone_number (int)PK+FK (call_info)

Таблица 2.5.1.4 - таблица БД call_number

call_id (int)customer_fname (varchar)customer_lname (varchar)city (varchar)PK+FK (call_info)

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

Таблица 2.5.1.5 - Таблица БД speakers

speaker_id (char)speaker_fname (char)speaker_lname (char)gender (char)birth_day (int)birth_month (int)birth_year (int)speak_sample (varchar)PK

Словарь модуля был разбит на 2 таблицы: dictionary_word (таблица слов) и dictionary_phrase (таблица фраз). В обоих таблицах роль первичного ключа играет связка двух атрибутов: ID диктора + слово. Данный первичный ключ был выбран по той причине, что ни одно значение в данных таблицах не является уникальным: как один диктор может произнести несколько фраз, так и одно слово может быть записано несколько раз разными дикторами. Однако связка этих атрибутов будет иметь уникальное значение. В таблице dictionary_word хранится ссылка на запись слова определенным диктором и транскрипция слова, наличие которой упростит распознавание речи клиента. В таблице dictionary_phrase отсутствует транскрипция, так как сложно распознать длинную звуковую последовательность; эта таблица хранит шаблонные фразы, часто произносимые операторами call-центра для упрощения процедуры генерации ответа на клиентский запрос. В таблицах 2.5.1.6-2.5.1.7 наглядно представлена структура вышеперечисленных таблиц.

Таблица 2.5.1.6 - Таблица БД dictionary_word

speaker_id (char)word (char)transcription (char)word_record (char)PK+FK (speakers)

Таблица 9 - Таблица БД dictionary_phrase

speaker_id (char)phrase_name (char)phrase_record (char)PK+FK (speakers)

.5.2 Проектирование диаграммы «сущность-связь»

Для наглядности предметной области была спроектирована диаграмма БД «сущность-связь» с применением графических средств отображения модели. В качестве средства визуализации был использован программный продукт EA 12. Сначала были созданы таблицы проектируемой БД. Затем были добавлены атрибуты с выделением первичных ключей и присвоением ограничения «NOT NULL» для некоторых атрибутов. Напоследок средствами EA была проведена визуализация полученной базы данных с последующим нанесением связей между таблицами. В приложении В показана итоговая физическая схема БД.

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

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

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

)сформулированный комплекс UML-диаграмм, отображающих концепцию проекта в формате, понятном как профессионалом предметной области, так и целевой аудитории модуля (руководители банков, интернет провайдеров, транспортных компаний и т.д.), который можно увидеть в приложении Б;

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

3. ПРОЕКТИРОВАНИЕ МОДУЛЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ IP-ТЕЛЕФОНИИ

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

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

.1 Общие сведения о разработке информационной системы

Согласно ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания» выделяют следующие основные стадии создания и этапы разработки автоматизированной системы (АС).

)Формирование требований к АС.

)Разработка концепции АС.

)Техническое задание.

)Эскизный проект.

)Технический проект.

)Рабочая документация.

)Ввод в действие.

8)Сопровождение АС.

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

Данный подход (с небольшими отклонениями) был применен при формировании этапов проектирования модуля системы Asterisk sip_response. Наиболее ярко процесс проектирования можно представить с помощью диаграммы Ганта. Диаграмма Ганта (Gantt chart, также ленточная диаграмма) - это популярный тип столбчатых диаграмм (гистограмм), который используется для иллюстрации плана, графика работ по какому-либо проекту. Является одним из наиболее популярных методов планирования проектов. Используется в приложениях по управлению проектами.

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

Рисунок 3.1.1 - диаграмма Ганта

3.2 Анализ хранилища информации системы Asterisk

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

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

Структура хранения данных Asterisk состоит из двух БД. Основная БД - asterisk - состоит из 220 таблиц и содержит общую информацию системы IP-телефонии, поступающей с диалплана (механизма, направляющего каждый звонок от источника в пункт назначения). Дополнительная БД - asteriskcdrdb - содержит CDR-записи. CDR - сервис, обеспечивающий журналирование работы телекоммуникационного оборудования.

Asteriskcdrdb хранит метаданные, описывающие каждую телекоммуникационную транзакцию, но не описывающие контент данной транзакции. В общей сложности это 48 атрибутов, разбросанных по двум таблицам (cdr и cel), содержащих оперативные данные, заполняющиеся динамически. Информативные атрибуты таблицы cdr: ID абонента (src), название используемого канала (channel), состояние ответа (disposition), начало, конец и длительность звонка (start, end, duration), количество оплачиваемых секунд (bill). Информативные атрибуты таблицы cel: имя и номер абонента (cid_name, cid_num), время начала звонка (eventtime), название приложения, используемого диалпланом (appname), имя стороннего канала (peer).

БД asterisk содержит как справочные данные, так и оперативные. Справочными данными является информация об администраторах и пользователях системы (таблицы admins и users), резервном копировании системы телефонии (таблица backup), информация о напоминаниях пользователям (таблица areminder), устройствах, подключенных к телефонии (таблица devices). Динамическими данными является информация о соединениях, использующих широковещательное соединение (таблицы broadcast, conferencespro), факс-соединениях (таблица fax), входящих звонках (таблица incoming) и полученных СМС-сообщениях (таблица sms_messages).

БД встраиваемого модуля, названная sip_response также содержит набор справочных и оперативных данных. Всего БД содержит 7 таблиц. Справочными данными является информация о дикторах, принявших участие в разработке модуля (таблица speakers), словари слов и фраз, из которых программа генерирует ответ пользователю (таблицы dictionary_word и dictionary_phrase). Динамическими данными является информация обо всех звонках, в которых был задействован модуль sip_response (таблицы call_info, call_status, call_members и call_number).

В приложении В включительно представлены графические схемы баз данных платформы Asterisk, визуализированные посредством инструмента администрирования СУБД MySQL phpMyAdmin. Также в данном приложении представлен отрывок SQL-кода, предназначенный для создания таблицы call_members.

.3 Реализация хранилища информации модуля

В текущем ходе разработки модуля sip_response была протестирована реализация добавления базы данных модуля в рабочую СУБД.

База данных на основе SQL кода была создана с помощью командной оболочки bash.

Листинг 3.3.1 - создание базы данных в MySQL

cd /optDATABASE sip_response;sip_responsesip_response < database2.sql

После создания БД с последующим добавлением таблиц РСУБД MySQL появилась совокупность структурированных и связанных между собой таблиц, но данные до сих пор отсутствуют Следующей задачей является заполнение созданной БД значениями. Также необходимо создать запись о модуле в таблицы modules существующей БД asterisk.

Существуют 2 способа добавления записей в таблицы: с помощью команды INSERT и с помощью загрузки записей из текстового файла (команда LOAD DATA LOCAL INFILE). Первый способ более удобен для добавления небольшого количества записей (не больше 5), второй способ - для большого количества записей. В данной задаче наиболее целесообразным выглядит добавление записей из текстового файла. Для этого для каждой таблицы необходимо создать отдельный текстовый файл, записать в него данные в специальном формате (табуляция между значениями полей, NULL-значения обозначаются как '\N) и загрузить данные из файла в таблицу при помощи командной строки MySQL. Для добавления записи о модуле достаточно выполнения команды INSERT. Для начального заполнения базы данных были созданы 7 текстовых файлов. На рисунке 5 показан формат записи строк в файл.

Рисунок 5 - формат текстового файла для добавления значений в БД

Затем был создан SQL-скрипт, состоящий из нескольких команд добавления данных из файла в таблицы, а также добавления записи о модуле sip_response, а именно версия модуля, имя и флаг доступности 1. Уникальный ID модуля СУБД создаст сама с помощью функции авто-инкремента значений в столбце. В листинге 3.3.2 указан список скрипт, использованный для заполнения БД.

Листинг 3.3.2 - SQL-скрипт заполнения БД

USE sip_response;DATA LOCAL INFILE '/opt/call_info.txt' INTO TABLE call_info;DATA LOCAL INFILE '/opt/call_members.txt' INTO TABLE call_members;DATA LOCAL INFILE '/opt/call_number.txt' INTO TABLE call_number;DATA LOCAL INFILE '/opt/call_status.txt' INTO TABLE call_status;DATA LOCAL INFILE '/opt/speakers.txt' INTO TABLE speakers;DATA LOCAL INFILE '/opt/dictionary_word.txt' INTO TABLE dictionary_word;DATA LOCAL INFILE '/opt/dictionary_phrase' INTO TABLE dictionary_phrase;asterisk;INTO modules (modulename, version, enabled) VALUES (sip_response, 0.1.0, 1);

На рисунках 6-7 показаны результаты работы команд. В общей сложности в каждую таблицу, хранящую информацию о звонках, добавлено по 20 значений, в таблицы-словари - по 10, в таблицу информации о дикторах - 5.

Рисунок 6 - результат работы команды LOAD DATA в таблице call_info (БД sip_response)

Рисунок 7 - результат работы команды INSERT в таблице modules (БД asterisk)

.4 Формирование алгоритмов реализации компонентов модуля

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

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

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

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

.4.1 Запускаемый файл модуля

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

В зависимости от входных данных происходит объявление переменных и вызов той или иной подсистемы. Например, если модуль имеет переменную со значением «request» и ссылку на аудиофайл с клиентским запросом в качестве входных данных, то он запускает подсистему идентификации обработки речевых сигналов, передавая ей ссылку на файл. Или если в качестве входных данных модуля будет переменная со значением hangup, то в исполняемом файле будет вызвана подсистема контроля вызова для протоколирования завершенного вызова. Для этого программа отправляет переменную, полученную из диалплана, на вход подсистемы.

Для обмена данными между модулем sip_response и диалпланом Asterisk используются методы библиотеки agilib - встроенной библиотеки Python, предназначенной для работы Python-скриптов в формате AGI.

.4.2 Подсистема обработки речевых сигналов

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

)прием от диалплана Asterisk записанного звукового файла с голосовым запросом клиента;

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

)формирование текстового файла на основании распознанного речевого сигнала;

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

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

Для идентификации звукового сигнала используется сторонний инструмент распознавания речи Google Speech. Google Speech - это прикладной программный интерфейс (API), созданный компанией Google и находящийся в свободном доступе. Основным предназначением Google Speech является конвертация речи из аудиоформата в текстовый формат посредством использования моделей нейронных сетей. Интерфейс Google Speech может распознать более 80 языков, в том числе и русский язык, на основе которого модуль sip_response обменивается информацией с клиентов.

Обмен данными между модулем sip_response и Google Translate (сервисом реализации Google Speech) осуществляется через HTTP-запросы. Для реализации запросов используется библиотека Python urllib2. Перед непосредственным осуществлением запроса аудиофайл преобразуется из формата gsm в формат flac для корректной работы Google Speech API. Ответ на запрос от Google Translate записывается в текстовый файл формата JSON с помощью встроенной библиотеки json. Затем из JSON-файла извлекается ответ и записывается в текстовый файл. Путь к текстовому файлу передается на вход подсистеме контроля вызова. Исходный код подсистемы обработки речевых сигналов содержится в исполняемом файле recognition.py. Псевдокод работы исполняемого файла recognition.py указан в приложении Г.

.4.3 Подсистема контроля вызова

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

)прием на вход текстового файла с обработанным клиентским запросом;

)обработка запроса на предмет его корректности;

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

)поиск информации из клиентской БД целевой организации;

)формирование полноценных фразы как ответа на клиентский запрос;

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

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

)передача диалплану Asterisk сигнала о перенаправлении вызова клиенту в случае отсутствия подходящего ответа на запрос;

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

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

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

Формирование готового ответа в виде аудиофайла реализуется посредством объединения нескольких файлов, соответствующих словам и словосочетаниям из БД. Для самого объединения вызываются методы библиотеки audiolab - сторонней библиотеки языка Python.

Статус выполнения подсистемы возвращается главному файлу sip_response.py, запускаемому диалпланом Asterisk. В случае прерывания соединения запускается обработка ошибок, в которой предусмотрен возврат диалплану статуса «hangup», говорящего о том, что соединение завершено.

Исходный код подсистемы контроля вызова содержится в исполняемом файле control.py. Псевдокод работы исполняемого файла sip_response.py указан в приложении Г.

.4.4 Конфигурация диалплана системы Asterisk

Любая операция, происходящая с соединением по каналу связи, управляется Asterisk исходя из настроек, указанных в файле диалплана. В операционных системах GNU/Linux полным названием файла диалплана является /etc/asterisk/extensions.conf. В контексте конфигурации диалплана для реализации модуля sip_response подразумевается:

)запуск кода на Python в ситеме Asterisk;

)последующая конфигурация логики диалплана для обмена данными с модулем.

Запуск стороннего программного кода решается посредством оформления специальных AGI-скриптов. Под аббревиатурой AGI подразумевается шлюзовой интерфейс Asterisk (Asterisk Gateway Interface), позволяющий расширять семантику диалплана Asterisk. Фактически модуль работает в виде отдельного приложения, где исполняемый файл sip_response.py будет запускаться встроенной функцией диалплана AGI(). Интерфейс CGI может выполнять программы на многих языках программирования при наличии соответствующих библиотек, однако создателями Asterisk рекомендуется использовать язык Python, выбранный для разработки модуля.

Обмен данными между диалпланом и подсистемами модуля sip_response также будет сконфигурирован путем использования стандартных функций диалплана. Основной концепцией будет передача данных в потоках stdin, stdout и stderr, что является основой межпроцессорного взаимодействия в операционных системах GNU/Linux.

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

.5 Экономическое обоснование эффективности модуля

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

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

Бюджет на реализацию проекта практически не составляет финансовых затрат. Система Asterisk, на которую нацелен модуль sip_response, является бесплатной и предоставлена в открытом доступе сети Интернет. Разработка и последующая модификация модуля ведется в операционной системе Fedora, основанной на ядре Linux и являющейся свободным программным обеспечением, доступным бесплатно. В ходе разработки также используются Open-Source решения, такие, как среда разработки PyCharm, система контроля версий Git, интерпретатор Python 3 и AGI-библиотека интеграции Python-программ в систему Asterisk. То же самое касается и тестовой платформы, где все программные продукты (ОС AsteriskNOW, СУБД MySQL, платформа виртуализации VirutalBox, утилита управления виртуальными машинами Vagrant) распространяются бесплатно. Программа Sparx Enterprise Architect 11, использованная для создание ER-диаграммы БД и проектирования UML-диаграмм, является платным программным обеспечением, но лицензия на данный продукт приобретена университетом для образовательных целей. Таким образом, использование EA не является платным с точки зрения реализации программного продукта. Также следует отметить, что программное обеспечение как продукт не облагается НДС, что уменьшает себестоимость проекта и упрощает процесс его окупаемости.

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

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

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

.5.1 Расчет себестоимости модуля

Себестоимость - это стоимостная оценка используемых в процессе производства продукции (работ, услуг) природных ресурсов, сырья, материалов, топлива, энергии, основных фондов, трудовых ресурсов и других затрат на её производство и реализацию.

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

Расчет стоимости времени, затраченного на реализацию программного продукта (З). З = 500 (оценка полного рабочего дня разработчика в рублях) x 120 (примерное количество полных рабочих дней, потраченных на создание проекта) = 60000 руб..

Расчет стоимости времени, затраченного на модификацию программного продукта, исходя из потребностей заказчика (М). М = 500 (оценка полного рабочего дня разработчика в рублях) x 5 (примерное количество полных рабочих дней, потраченных на создание проекта) = 2500 руб..

Расчет амортизации персонального компьютера (А1). А = 30000 (общая стоимость комплектующих ПК) / 5 (гарантия на пользование ПК, лет) / 3 (подсчет амортизации за количество полных рабочих дней, потраченных на создание проекта) = 2000 руб..

Сумма дивидендов с реализации программного продукта (Д) = 3000 руб.

Расходы на сопровождение программного продукта за 6 мес. (С) = 15000 руб.

Полная себестоимость проекта (П): П = З + М + С +Ф + Д = 60000 + 2500 + 2000 + 3000 + 15000 = 82583 руб.

.5.2 Расчет сроков окупаемости модуля sip_response

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

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

Э= З1 - З2,(1)

где:

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

З2 - элементы производственных затрат, связанные с использованием новой информационной технологии.

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

Следовательно, З1 = 20000 * 10 * 12 + 5 * 20000 / 5 = 2500000 (руб.)

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

Следовательно, З2 = 82583 + 15000 = 97583 (руб.)

По формуле, эффект от использования модуля sip_response будет:

Э = З1 - З2 = 2500000 - 97583 = 2402417 (руб.)

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

Ток = А0/Э,(2)

где:

А - затраты, связанные с созданием программного продукта;

Э - эффект от использования программного продукта.

Следовательно, Ток = 82500 / 2402417 = 0,034

Таким образом, срок окупаемости данного проекта составляет 0,034 лет, (примерно 12 дней).

.5.3 Расчет точки безубыточности модуля sip_response

Точка безубыточности (break-evenpoint- BEP) - объем продаж, при котором прибыль предпринимателя равна нулю. Для того чтобы рассчитать точку безубыточности в натуральном выражении, необходимо использовать следующие показатели:

)Постоянные затраты на объем (FC);

)Цена единицы товара (услуги, работы) (P);

)Переменные затраты на единицу продукции (AVC).

Рассчитать точку безубыточности в натуральном выражении можно по следующей формуле:

=FC/(P-AVC)(3)

Условия расчета точки безубыточности (данные берутся за 1 год).

Цена товара (P) = 82583 руб.

Постоянные издержки (FC = A1 + З) = 62000 руб.

Переменные издержки (FC = С*2 + М + А2) = 32583 руб.

=62000/60000 = 1.03

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

.6 Безопасность и надежность модуля

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

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

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

.6.1 Анализ возможных угроз информационной безопасности

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

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

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

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

.6.2 Анализ модели противодействия угрозам ИБ системы Asterisk

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

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

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

.6.3 Реализация функции надежности модуля

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

Решением данной проблемы является реализация многоступенчатой аутентификации пользователя перед доступом к личным данным. Количество этапов аутентификации и её подвиды оговариваются в индивидульном порядке с заказчиком.

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

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

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

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

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

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

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

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

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

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

) формирование алгоритмов, на основе которых реализуется исходный код модуля sip_response.

В ходе выполнения курсового проекта:

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

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

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

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

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

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

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

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

В виде дальнейших перспектив планируется:

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

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

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

)

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

1.Дж. ван Меггелен, Ярд Смит, Лейф Маадсен. Asterisk - будущее телефонии/ 4-e издание. - СПб, Питер, 2015 г. - 656 с.

.Фиайли К. SQL. Руководство по изучению языка. - М., ДМК Пресс, 2014 г. - 454 с.

.Шварц Б., Ткаченко В. MySQL. Оптимизация производительности. - М., Символ-плюс, 2013 г. - 832 с.

.Пилгрим М. Погружение в Python. -М., Абак-пресс, 2013 г. - 148 с.

.Кригель А., Трухнов Б. SQL. Библия пользователя. - М., Вильямс, 2011 г. - 752 с.

.ФЗ N-149 Об информации, информационных технологиях и о защите информации/ от 27.07.2006 (с изм. и доп., вступ. в силу с 10.01.2016)

7.Database Engineering with Enterprise Architect 12 // Youtube. Режим доступа: https://www.youtube.com/watch?v=LLtp49TU1H8, свободный (дата обращения: 12.03.2016 г.). - Заголовок с экрана.

8.CDR Fields // Dashboard - Asterisk Project Wiki. Режим доступа: https://wiki.asterisk.org/wiki/display/AST/CDR+Fields, свободный (дата обращения: 12.03.2016 г.). - Заголовок с экрана.

9.CEL Events and Fields // Dashboard - Asterisk Project Wiki. Режим доступа: https://wiki.asterisk.org/wiki/display/AST/CEL+Events+and+Fields, свободный (дата обращения: 12.03.2016 г.). - Заголовок с экрана.

.Проблемы правового регулирования IP-телефонии и современных мессенджеров в России // КПФМ | Корпоративное право и финансовый менеджмент. Режим доступа: http://kpfm.ru/publikacii/blog/problemy-pravovogo-regulirovaniya-ip-telefonii-i-sovremennyx-messendzherov-v-rossii/, свободный (дата обращения: 12.03.2016 г.). - Заголовок с экрана.

.IP-телефония в компьютерных сетях // Национальный Открытый Университет "ИНТУИТ" | Бесплатное образование. Режим доступа: http://www.intuit.ru/studies/courses/8/8/info, свободный (дата обращения: 12.03.2016 г.). - Заголовок с экрана.

.Информационно-поисковая система // ФИПС - Федеральное государственное бюджетное учреждение Федеральный институт промышленной собственности. Режим доступа:http://www1.fips.ru/wps/wcm/connect/content_ru/ru/inform_resources/inform_retrieval_system/, свободный (дата обращения: 12.03.2016 г.). - Заголовок с экрана.

.Лекция 11: Унифицированный язык визуального моделирования Unified Modeling Language (UML) // Национальный Открытый Университет "ИНТУИТ" | Бесплатное образование. Режим доступа: http://www.intuit.ru/studies/courses/2195/55/lecture/163, свободный (дата обращения: 12.03.2016 г.). - Заголовок с экрана.

14.Asterisk Community. Режим доступа: http://community.asterisk.com, свободный (дата обращения: 12.03.2016г.). - Заголовок с экрана.

.Распознавание речи в ROS с Google Speech API // Публикации. Режим доступа: https://habrahabr.ru/post/247539/, свободный (дата обращения: : 12.03.2016 г.). - Заголовок с экрана.

.Псевдокод на русском // Публикации. Режим доступа: https://habrahabr.ru/post/168949/, свободный (дата обращения: 19.04.2016г.). - Заголовок с экрана

8)

ПРИЛОЖЕНИЕ А

(обязательное)

Техническое задание

«Утверждаю»

_______________ ИВАНОВ И.И.

__ ____ 2016г.

Разработка модуля информационной системы IP-телефонии sip_response

Техническое задание

Действует с __________

г.

1. ОБЩИЕ СВЕДЕНИЯ

Полное наименование системы и ее условное обозначение - Модуль информационной системы IP-телефонии Asterisk sip_response. (далее «система»).

Предприятие-заказчик: ОАО «ПриветБанк» Представители заказчика: Иванов И.И., директор

Исполнитель: Чинков М.Ю., IT-специалист;

Перечень документов, на основании которых создается система:

-техническое задание на проектирование (данный документ).

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

начало: с момента подписания договора на услуги

окончание: 1 мая 2017 г.

Сметная стоимость проекта: 20000 руб.

Детальное описание работ по проекту представлено в приложении 1.

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

Разработанная система устанавливается на сервере, где предварительно установлена и сконфигурирована программная платформа IP-телефонии Asterisk, база данных которой содержится в реляционной СУБД. Тестовая эксплуатация системы проводится сотрудниками ОАО «ПриветБанк» и Чинковым М.Ю.. В ходе тестовой эксплуатации разработчиком устраняются выявленные ошибки и неточности.

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

2. Назначение и цели создания

Модуль информационной системы IP-телефонии Asterisk sip_response предназначен для автоматизации обслуживания клиентов ОАО «ПриветБанк».

Основные цели разработки:

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

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

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

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

3. Краткая характеристика объекта автоматизации

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

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

Целевым субъектом системы является запрос клиента об оказании информационной услуги со стороны банка. Это может быть как информация о состоянии баланса, так и консультация по вопросам настройки личного кабинета. Запрос посылается в виде ответа на сгенерированный вопрос системы. «Отправной точкой» между клиентом и автоматизированным call-центром является стартовый вопрос, ответ на который должен определить сущность потребности клиента.

Ключевыми моментами системы являются:

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

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

)диалплан системы IP-телефонии Asterisk, сконфигурированный в соответствии с работой модуля sip_response.

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

Возможные варианты работы модуля по условию.

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

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

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

4. Требования к системе

4.1 Общие требования к системе

1) аппаратное устройство объединения телефонной сети общего пользования (ТФОП) и IP-сети;

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

) операционная система AsteriskNOW или любая другая операционная система GNU/Linux;

) интерпретатор языка Python (3 версия);

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

) реляционная СУБД, хранящая базу данных платформы Asterisk;

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

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

4.2 Требования к защите информации от несанкционированного доступа

Защита информации от несанкционированного доступа обеспечивается функционалом платформы Asterisk по умолчанию. Задача формирования программного кода, отвечающего требованиям безопасности, в модуле sip_response, решается в процессе комплексного тестирования программного продукта.

4.3 Требования по стандартизации и унификации

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

5. Порядок контроля и приемки

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

6. Модификация КОМПОНЕНТОВ системы

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

Возможно внесение дополнительных функций в систему за дополнительную плату.

7. Порядок внесения изменений

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

Руководитель

Иванов И.И. _________________________________

Исполнитель

Чинков М.Ю.________________________________

Приложение 1

План работ по проекту

Наименование вида работ Стоимость, р1. Предпроектное исследование1.1 Исследование предметной области1.2 Формирование требований на проектирование1.3 Визуализация концепции проекта (UML-диаграммы)2. Проектная часть2.1 Разработка структуры базы данных2.2 Разработка подсистемы обработки речевых сигналов2.3 Разработка подсистемы контроля абонентских вызовов2.4 Конфигурация диалплана системы IP-телефонии3. Отладка и тестирование модуля3.1 Формирование тестового окружения аппаратного и программного обеспечения3.2 Нагрузочное тестирование3.3 Приемочное пользовательское тестирование3.4 Тестирование качества программного продукта4. Реализация модуля4.1 Конфигурация диалплана существующей системы IP-телефонии4.2 Установка модуля 4.3 Формирование документации по установке модуля и его управлениюИТОГО:

Руководитель

Иванов И.И. _________________________________

Исполнитель

Чинков М.Ю._________________________________

ПРИЛОЖЕНИЕ Б

UML-диаграммы проекта

Рисунок Б.1 - диаграмма вариантов использования (use case diagram)

Рисунок Б.2 - диаграмма деятельности (activity diagram)

Рисунок Б.3 - диаграмма состояний (state diagram)

Рисунок Б.4 - диаграмма развертывания (deployment diagram)

Рисунок Б.5 - диаграмма последовательности (1 вариант исмользования)

Рисунок Б.6 - диаграмма последовательности (2 вариант исмользования)

Рисунок Б.7 - диаграмма компонентов

ПРИЛОЖЕНИЕ В

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

База данных модуля sip_response

Рисунок В.1 - физическая схема базы данных стороннего модуля Asterisk sip_response в EA

Рисунок В.2 - схема подструктуры базы данных Asterisk в phpMyAdmin

Рисунок В.3 - схема подструктуры базы данных Asterisk в phpMyAdmin

Рисунок В.4 - схема базы данных asteriskcdrdb в phpMyAdmin

Рисунок В.5 - схема базы данных стороннего модуля Asterisk sip_response в phpMyAdmin

DROP TABLE IF EXISTS `call_members` CASCADE;TABLE `call_members`

(

`call_id` INT NOT NULL,

`customer_fname` VARCHAR(20) NOT NULL,

`customer_lname` VARCHAR(20) NOT NULL,

`city` VARCHAR(20),

CONSTRAINT `PK_call_members` PRIMARY KEY (`call_id`)

);

TABLE `call_members`

ADD INDEX `IXFK_call_members_call_info` (`call_id` ASC);

TABLE `call_members`

ADD INDEX `IXFK_call_members_speakers` ();

TABLE `call_members`

ADD CONSTRAINT `FK_call_members_call_info`

FOREIGN KEY (`call_id`) REFERENCES `call_info` (`call_id`) ON DELETE Restrict ON UPDATE Restrict;

FOREIGN_KEY_CHECKS=1

Листинг В.1 - создание связанной таблицы базы данных call_members

ПРИЛОЖЕНИЕ Г

(дополнительное)

Описание алгоритмов модуля sip_response

import libs= agi.get_variable(module_call)= agi.get_variable(request_file)var

"request":

full_request_name = request + ".gsm"

text_file = recognition(full_request_name)

response_status, playback_file = control(text_file)

"hangup":

control(hangup)

return 0= response_status= playback_filefile == ""

return status

return status, file

Листинг Г.1 - псевдокод запускаемого файла модуля sip_response.

import libs= get_parameter(request, gsm, flac)= string.replace (request, "gsm", "flac")= open(request)= f.read().close()_api = urllib2.request('https://www.google.com/speech-api&lang=ru-RU', data=data, headers={'Content-type': 'audio/x-flac; rate=16000'})= urllib2.openurl(call_api)_api = ret.read()= json.loads(response_API)_answer = json.getmessage()_file = "request" + random() + ".txt"= open(request_file).write(total_answer).closerequest_file

Листинг Г.2 - псевдокод подсистемы обработки речевых сигналов.

libs

answer_analyze(customer_request)

string func_status = ""

array keywords = check_keywords(customer_request)

if length.keywords >= 3

func_status = "possible"

return func_status

else

func_status = "impossible"

return func_status

request_file=get_argument()= fopen(request_file)keyword_counter = 0status = ""end_of_file

current_word = fread(word)

status=sql_request("dictionary_word", word)

if status == 0

counter++

customer_request = customer_request + current_word.close()counter <= 2

status = "incorrect"

return status

string analyze_status = answer_analyze(customer_request)

if analyze_status == "impossible"

status = "redirect"

return status

else

string answer_condition = ""

while answer_condition != "ready"

array answer_files = new array[20]

answer_word = sql_request("dictionary_word")

array_items = length.answer_files

answer_files[array_items] = answer_ford

if length.answer_files > 5

answer_condition == "ready"

string total_answer = "response" + random()

int item_counter = 0

while item_counter != length.answer_files

a, fs, enc = audiolab.wavread(total_answer)

b, fs, enc = audiolab.wavread(answer_files[counter])

c = scipy.merge((a,b))

audiolab.wavwrite(c, total_answer', fs, enc)

status = "success"

return status, total_answer

connection_breakdown

status = "hangup"

return status

Листинг Г.3 - псевдокод подсистемы контроля вызова.

[incoming]=> 88005553535, 1, Playback(first_question)=> 88005553535, 2, WaitExten(20)=> 88005553535, n, Set(request_file=request_${RAND()})=> 88005553535, n, Record(${request_file}:gsm)=> 88005553535, n, Set(module_call=request)=> 88005553535, n, AGI(sip_response.py, ${module_call}, ${request_file})=> 88005553535, n, Set(module_answer=${answer})=> 88005553535,n,GotoIf($[${module_answer} = "incorrect"]?label1) => 88005553535,n,GotoIf($[${module_answer} = "success"]?label2) => 88005553535,n,GotoIf($[${module_answer} = "redirect"]?label3)=> 88005553535,n,GotoIf($[${module_answer} = "hangup"]?label4)

=> 88005553535, n(label1), Playback(retry_question)=> 88005553535, n(label1), Goto(88005553535,2)

=> 88005553535, n(label2), Set(answer_file=${out_file})=> 88005553535, n(label2), Set(next_question=${question_file})=> 88005553535, n(label2), Playback(${answer_file})=> 88005553535, n(label2), Playback(${next_question})=> 88005553535, n(label2), Goto(88005553535,2)

=> 88005553535, n(label3), Playback(redirect_message)=> 88005553535, n(label3), Dial(SIP/Specialist,30)

=> 88005553535, n(label4), Set(module_call=hangup)=> 88005553535, n, AGI(sip_response.py, ${module_call})=> 88005553535, n(label4), Hangup()

=> 88005553535,n,Hangup()

Листинг Г.4 - конфигурация диалплана Asterisk.