Системы мониторинга сети телефонных линий компании в режиме реального времени

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

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

Аннотация

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

В данной работе описан процесс планирования и непосредственной разработки системы мониторинга сети телефонных линий компании в режиме реального времени. Система мониторинга представляет собой веб-приложение, ориентированное на использование руководством и менеджментом компании, а также менеджментом компаний-клиентов (с ограниченными возможностями). Разработка системы мониторинга состоит из теоретической и практической частей. В теоретическую часть входят обзор предметной области и выбор методов, средств и подходов к разработке. Практическая часть включает в себя разработку архитектуры веб-приложения, структуры данных, дизайна интерфейса и алгоритмов системы. В качестве основного языка программирования используется JavaScript (Node.js для серверной части и React для клиентской). Процесс разработки производился согласно Agile-принципам.

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

авторизации;

мониторинга состояний телефонных линий;

мониторинга активности операторов;

мониторинга и прослушивания активных звонков на линиях;

удобной навигации по информации.

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



Annotation

This paper describes the process of planning and development of a system for monitoring the network of telephone lines of a company in real-time regime. Monitoring system is a web-application for primarily company's management, as well as for the management of client companies (with limited functionality). Development of a monitoring system consists of two main parts - theoretical and practical. Theoretical part includes a review of the subject area and the choice of methods, tools and approaches for development. Practical part includes development of a web application architecture, data structure, interface design and system algorithms. JavaScript is used as the main programming language (namely, Node.js for backend-development and React for frontend-development). Development process was carried out according to Agile-principles.

Monitoring system was developed in order to improve the efficiency of telephone lines work and its operator's organization process and to implement the following key features:

authorization process;

monitoring current state of telephone lines;

monitoring the activity of operators;

monitoring and listening to active calls on the lines;

easy navigation through system data.

Application works in all modern web-browsers and has a fully responsive interface in order to be able to use it from any mobile device. Equipment of company is used as a business telephone system and server equipment.

The size of the report without attachment is 75 pages. The number of illustrations in the work - 16, tables - 5, sources used - 48.



Оглавление

Введение

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

1.1 Информационные технологии в бизнесе сегодня

1.2 IP-телефония и веб-приложения

1.3 Контакт-центры и существующие технические проблемы

1.4 Функциональные требования

2. Выбор методов, средств и подходов к разработке

2.1 Основные подходы к разработке

2.2 Сравнительная характеристика языков программирования

2.3 Способы развёртывания программного обеспечения

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

3.1 Архитектура системы мониторинга

3.2 Процесс проектирования разработки

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

3.4 Выбор СУБД и особенности структуры базы данных

3.5 Разработка интерфейса веб-приложения

3.6 Выбор технологий для разработки основных алгоритмов веб-приложения

4. Практическая реализация проекта

4.1 Введение

4.2 Разработка дизайна интерфейса приложения и его «карты»

4.3 Создание структуры базы данных

4.4 Разработка программных алгоритмов и развёртывание приложения

4.4.1 Алгоритмы авторизации

4.4.2 Алгоритмы взаимодействия АТС, сервера и интерфейса

4.4.3 Алгоритмы интерфейса

4.4.4 Алгоритмы онлайн-трансляции звонков

Заключение

Список использованных источников

Приложение



Введение

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

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

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

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



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

1.1 Информационные технологии в бизнесе сегодня

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

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

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

Только в России совокупный объём корпоративных венчурных инвестиций в информационные технологии превысил 570 миллионов долларов (по оценкам портала выбора технологий TAdviser, рисунок 1). [1]

Рис. 1. Оценочный объём венчурных инвестиций в России за 2016-2018 годы

В мире же по данным FinTech Global в информационные технологии инвестировано около 3.4 миллиардов долларов (рисунок 2). [2] При этом очевидно, что рост инвестиций является закономерным от года в год.

Рис. 2. Инвестиции в информационные технологии за 2014-2018 годы



Наиважнейшей вехой в развитии бизнес-процессов в компаниях, использующихся сегодня повсеместно, безусловно стало вовлечение сетевых технологий (использование сети Интернет), а также различных других технологий коммуникации, таких, например, как IP-телефония. Ещё недавно все использование сети Интернет в компаниях заключалось в коммуникации через электронную почту. Сегодня невозможно представить себе эффективно работающую фирму, не обладающую собственным сайтом. Бизнес процессы протекают с большей скоростью и в большем количестве благодаря сетевым мессенджерам и дешевой телефонии. Интернет в разы ускорил и удешевил коммуникацию между сотрудниками компаний, коммуникацию с парнёрами и клиентами, намного усилил традиционные инструменты маркетинга. [3]

1.2 IP-телефония и веб-приложения

IP-телефония (англ., Voice over Internet Protocol - VoIP) представляет собой группу технологий для передачи пакетов медиа-данных (аудио, видео, текст) через сети, работающие с использованием IP-протоколов (англ., Internet Protocol), например, SIP, RTP, XMPP и других. [4]

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

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

лучшая эффективность использования пропускной способности сети, возможность её гибкого распределения;

при проблемах в работе сети она снижает свою пропускную способность для абонентов, но при этом абоненты в сети не «выбрасываются» из неё;

снижение стоимости звонков. Стоимость звонков в сетях IP-телефонии заметно ниже стоимости аналоговых звонков;

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

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

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

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

Безусловно сети IP-телефонии обладают и своими недостатками, наиболее весомым из которых является то, что при отсутствии сетевого подключения или же доступа к сети, пользование сетью становится невозможным. К тому же IP-телефония обладает «помехами», также связанными с подключением к выделенной сети. Примерами может является запаздывание звука, потеря информации без возможности восстановления и другое. Наконец, сети IP-телефонии, как и все другие сети, работающие через Интернет, подвержены DoS-атакам, а потому требуют особых мер для обеспечения безопасной и безотказной работы. [6]

Однако с уверенностью можно сказать, что достоинства IP-телефонии в значительной мере превышают недостатки. Для корпораций особенно важным является значительное снижение стоимости коммуникаций и высокая доступность решения. Так, например, согласно подсчётам TMR (Transparency Market Research) из-за всех своих достоинств к 2020 году количество компаний, использующих VoIP вырастет на 35% по сравнению с декабрём 2018 года, а глобальная количество пользователей индустрии VoIP в бизнесе поднимется с отметки со 150 миллионов до 350 миллионов. [7]

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

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

Важным достоинством веб-приложений является также упрощённое обеспечение кроссплатформенности. Кроссплатформенность в данном случае обеспечивается не оперативной системой, установленной на компьютере, но веб-браузерами. Конечно, разные браузеры обладают своими особенностями. Различные браузеры могут поддерживать какую-либо новую технологию (например, WebRTC или LocalStorage), а какие-то нет, или же обладают совершенно другим API взаимодействия с данной технологией. Тоже касается и графических составляющих браузеров, а именно отличий в отображении определённых HTML-элементов. Однако для решения этой проблемы существуют специально разработанные стандарты, которых браузеры должны придерживаться, например, W3C (World Wide Web Consortium). [8]

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

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

1.3 Контакт-центры и существующие технические проблемы

Главной проблемой контакт-центров сегодня является необходимость содержать большое количество работников (абонентов, «продажников», менеджеров и прочих), и, как следствие, обеспечивать контроль за ними. Зачастую, траты на заработные платы работников и связанные с этим дополнительные расходы могут составлять до 70% от общих месячных издержек компании. [9] Кроме того, чем крупнее та или иная фирма, тем более сложной технологической структурой она обладает.

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

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

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

Структурно процесс работы контактного центра можно представить следующим видом (рисунок 3):

Рис. 3. Процессы взаимодействия в работе контакт-центра

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

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

В мире существует довольно большое количество программного обеспечения для работы с автоматизированными телефонными системами, например, Asterisk, SIP Foundry, Elastix, OpenSIP, Nextiva, Vonage Business, RingCentral, 8x8, Jive и другие. [10] Такие решения позволяют избежать «низкоуровневой» настройки IP-телефонии, однако для работы с ними также требуются квалифицированные специалисты.

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

автоматизации мониторинга и контроля за телефонными линиями и операторами;

эффективного распределения времени операторов и тайм-менеджмента в целом;

контроля за рабочими процессами.

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

В таких случаях компания начинает разработку собственного ПО, соответствующего всем критериям бизнес-логики компании. Такие решения, как правило, являются более дорогими, но всегда более гибкими.



1.4 Функциональные требования

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

авторизации пользователей;

задания фильтров мониторинга и возможностью их запоминания;

отображения текущей информации по выделенным линиям;

отображения текущей информации по звонкам;

отображения текущей информации по операторам;

мониторинга за отдельными операторами;

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

прослушивание звонков текущих и завершённых в целях контроля качества;

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

особого отображения неполадок на выделенных линий;

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

просмотра только входящих звонков на линиях;

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

отображения только информации о звонках в отельном виде;

отображения только информации о состояниях линий в отдельном виде;

быстрого поиска по операторам/линиям/звонкам, как по ключевым словам, так и по словосочетаниям;

использования приложения с любого устройства;

логгингом состояния системы;

отправки широковещательных сообщений в системе.

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



2. Выбор методов, средств и подходов к разработке

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

2.1 Основные подходы к разработке

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

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

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

Реализация. Данный этап условно состоит из следующих четырёх составляющих:

дизайна;

кодирования;

тестирования;

документирования.

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

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

Для реализации обозначенных выше этапов могут использоваться различные подходы к циклу разработки, наиболее популярные из которых: [13]

каскадный цикл разработки ПО (англ., waterfall);

V-модель;

Agile-разработка;

Итерационная модель (англ., Iterative Model).

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

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

Главный недостаток каскадной разработки - это в первую очередь то, что изначально заказчик программного продукта может не иметь полного представления о требованиях к продукту до тех пор, пока не будет готов прототип продукта. Как следствие, внесение изменений в продукт на поздних этапах разработки становится процессом трудоёмким и ресурсозатратным. [13]

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

V-модель можно считать расширением каскадной модели, но в отличие от линейного движения «сверху вниз» от одного этапа разработки к другому, последовательность меняет своё направление (на стадии кодинга), тем самым визуально формируя форму латинской буквы «V» (рисунок 4). [14]

Рис. 4. V-модель



V-модель демонстрирует взаимоотношение между каждым этапом жизненного цикла разработки программного продукта. Горизонтальная и вертикальная оси в модели представляют соответственно время (или иногда степень завершённости проекта) и уровни абстракции (например, детализация проекта, тестирование, компоновка). [14]

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

Несмотря на это достоинство, а также на простоту понимания модели, V-модель не является «гибкой», и тем самым не обладает способностью быстро адаптироваться для внесения изменений в процесс разработки. Также V-модель не рассчитана на работу с параллельными событиями. [15] Наконец, некоторые из результатов разработки можно просмотреть только достигнув низа буквы «V» - стадии кодинга.

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

Существует также несколько известных и распространённых методик, основанных на Agile, например, Scrum и Kanban, которые по своей сути не являются самостоятельными методиками, а основываются на принципах Agile-разработки и определённым образом расширяют её. [16]

Достоинства Agile-разработки: [17]

возможность быстрых изменений программного продукта (англ., high response to change speed);

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

возможность постоянных беглых ревью (review cycles);

высокая гибкость релиза.

Недостатки:

Частое непонимание принципов организации Agile (в особенности между целями разработки и бизнеса);

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

Частая невозможность «предсказывания» результатов разработки;

Слабая масштабируемость подхода.

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

Тем самым итерационная модель отлично подходит для тех случаев, когда подразумевается использование новых для команды разработчиков технологий, а также для случаев, когда некоторые из ресурсов, необходимых для разработки, не доступны на определённых начальных этапах. Возможно выполнение параллельных задач. И важно заметить, что итерационная модель фокусируется не на плотном документировании, но больше на дизайне процесса разработки и архитектуры программного продукта. [18] [19]

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

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

2.2 Сравнительная характеристика языков программирования

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

Сравнение языков программирования будем проводить по следующим N признакам. [20] [21] Результаты сравнения представлены в таблице 1, где:

«+» означает «да»;

«+/-» означает «скорее да, чем нет»;

«-/+» означает «скорее нет, чем да»;

«-» означает «нет».

Таблица 1. Сравнительный анализ языков веб-программирования

	JS	PHP	C#	Python	Ruby	Perl	Java
Простота освоения	+/-	+/-	+/-	+/-	-/+	-/+	+/-
Быстродействие	+/-	+/-	-/+	+	-/+	-	-/+
Большая коммьюнити	+	+	+/-	+	+/-	-/+	+
Open-Source компилятор	+	+	+	+	+	+	+
Кроссплатформенность	+	+	-/+	+	+/-	+	+
Низкие ресурсозатраты	+/-	+	-/+	+/-	-/+	-/+	+/-
Низкие трудозатраты	+	+	+/-	+/-	-	-	+/-
Возможность создания сложных интерфейсов	+	-/+	+/-	+/-	-	-	-/+
Серверный рендеринг	+/-	+	+	+	+	+	+
Поддержка MVC / MVVM	+	+	+	+/-	+	+/-	+
Сборщик мусора	+	+	+	+	+	+	+
Большое количество подключаемых пакетов	+	-/+	+	+	-/+	+/-	+

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

2.3 Способы развёртывания программного обеспечения

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

использовать собственные ресурсы (собственное сетевое оборудование);

арендовать серверное оборудование в дата-центрах для размещения ПО;

использовать решения-провайдеры (облачные решения).

Преимущества использования собственного оборудования: [22]

полная гибкость решения;

полный «прозрачный» контроль за тратой вычислительных ресурсов;

часто - более высокая защищённость данных;

возможность масштабирования решения;

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

Недостатки использования собственного оборудования:

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

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

наличие дополнительных IT-специалистов;

приобретение дорогостоящего серверного оборудования.

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

В то же время аренда сервисного оборудования в дата-центрах позволяет избежать большой части затрат, а также в определённой мере ответственности за оборудование, так как весь присмотр за серверами, а также обеспечение условий для их работоспособности, гарантируются сотрудниками дата-центра. [23]

Третье решение - использовать облачные решения для разворачивания программных продуктов, таких, например, как Microsoft Azure, Amazon Web Services (AWS), Google Cloud и прочие. Облачные решения обладают большим количеством положительных черт, таких как: [24]

нет необходимости в покупке дорогостоящего серверного оборудования;

повышение эффективности IT-инфраструктуры;

минимизация проблем с облуживанием серверов;

нет необходимости продумывать инфраструктуру серверов;

лёгкая масштабируемость;

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

доступность.

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



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

3.1 Архитектура системы мониторинга

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

Рис. 5. Архитектура системы мониторинга

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

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

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

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

3.2 Процесс проектирования разработки

Для разработки веб-приложения использовалась Agile-разработка в виду необходимости расширения функциональности разрабатываемого программного обеспечения «на ходу».

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

Для выявления основной функций разработки и её составных частей, использовались функциональные диаграммы. Процессы проектирования и непосредственной разработки программного продукта представлены на функциональных диаграммах нулевого, первого и второго уровней (рисунки 6-11). Диаграммы отражают взаимосвязи между функциями разрабатываемого ПО. Каждая функциональная диаграмма создаётся по следующему шаблону: прямоугольники являются графическим отображением определённой функции, основывающейся на некоторых исходных данных (изображаются слева от функции), управлении (сверху) и механизме (снизу). [25] Справа изображаются выходные данные - результаты, ожидаемые или полученные, после реализации данной функции. Детализация диаграмм увеличивается с каждым последующим уровнем. Это позволяет представить план разработки программного продукта наиболее наглядным и удобным образом. [26]

Рис. 6. Функциональная диаграмма нулевого уровня

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

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

Рис. 7. Функциональная диаграмма первого уровня

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

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



Рис. 8. Функциональная диаграмма второго уровня «Собрать требования»

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

Рис. 9. Функциональная диаграмма второго уровня «Разработать программный продукт»

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

Рис. 10. Функциональная диаграмма второго уровня «Реализовать проект»

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



Рис. 11. Функциональна диаграмма второго уровня «Протестировать полученные результаты и внедрить в эксплуатацию»

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

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

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

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

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

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

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

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

Также из-за специфики приложения, следует понимать, что клиентская часть (frontend) должна обладать интерфейсом с частыми обновлениями элементов в браузере, а потому производительность в клиентской части приложения играет наиболее важную роль. Лучшим выбором для создания сложных интерфейсов сегодня является язык программирования JavaScript со спецификацией ES2018 (ECMAScript 2018). Сегодня JavaScript обладает большими возможностями и удобен в использовании. [20] [28]

Более того, для работы с языком программирования нет необходимости использовать какие-либо тяжелые интегрированные среды разработки программного обеспечения (IDE), как например, Oracle для Java или Microsoft Visual Studio для С# (ASP.NET MVC). Для написания кода можно использовать любой текстовый редактор. В данной работе в качестве IDE использовались Sublime Text 3 и Microsoft Visual Studio Code - легковесные и обладающие следующими возможностями, упрощающими процесс написания кода:

стилизацией синтаксиса;

автоматическим дополнением;

регулярными выражениями для поиска и замены символов и слов;

возможностью сравнения файлов;

подключением сторонних пакетов, плагинов и многими другими. [29]

Практически все современные браузеры в полной мере поддерживают функциональность JavaScript последней версии, а потому обеспечение кроссплатформенности не является существенной проблемой в современной веб-разработке. [30] Однако всё же необходимо учитывать особенности различных браузеров и их версий. Помимо различий в отображении элементов интерфейса и анимации, существуют и различия функциональные. Так, например, браузер Internet Explorer 11 не обладает LocalStorage, а потому для поддержки работы приложения в данном браузере необходимо придумывать специальные обходные процессы. [31] Для проверки работы веб-приложения в данной работе использовались браузеры Google Chrome, Mozilla Firefox, Yandex Browser, Internet Explorer 11, Microsoft Edge, Safari и Opera 11 версии и выше.

Несмотря на то, что данный язык программирования является однопоточным, он предоставляет богатый выбор инструментов для работы с асинхронными операциями, и, что наиболее важно, имеет ряд фреймворков (англ., frameworks), обладающих поддержкой реактивности. Наиболее распространённые сегодня JavaScript фрэйморки - это React, Vue, Angular.

Перечисленные фреймворки во многом предоставляют схожую функциональность, однако каждый обладает своими достоинствами. Для React - это наличие шаблонизатора JavaScript XML (JSX), технология построения и работы с виртуальным DOM (Document Object Model) веб-страницы. Преимущества Vue - это очень лёгкая интеграция и встраивание фрейморка. Angular же строго придерживается архитектуры MVC и предоставляет множество инструментов для работы с DOM веб-страницы. [32]

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

В связке с препроцессорами языка стилизации CSS - SCSS и SASS, разработка интерфейса приложения стала процессом удобным, быстрым, поддерживаемым и легко масштабируемым.

В качестве языка программирования серверной части приложения изначально планировалось использование PHP 7 в связи с его распространённостью среди программных продуктов компании и наличием ряда достоинств, аналогичных JavaScript. Однако, современные возможности Node.js - языка серверного программирования, основанного на JavaScript, - не уступают возможностям PHP и, безусловно, взаимодействие клиентской и серверной частей приложения, работающих на одном программном «движке» V8, в значительной степени упрощено. [33] В связи с этим, языком для программирования серверной части приложения стал Node.js.

Node.js обладает главным недостатком - необходимостью написания большого количества кода для реализации необходимой функциональности. Чтобы избавиться от этого недостатка, было решено использовать фрейморк для Node.js, а именно - Koa. В качестве других возможных кандидатов рассматривались Express.js и Hapi. [34]

Koa является относительно новым open-source продуктом и в отличие от других двух упомянутых Node.js фреймворков обладает более широкими возможностями в конфигурации проекта и более лаконичным синтаксисом. Подобно аналогам, функциональность Koa может быть легко расширена путём подключения сторонних плагинов и мидлвэров (англ., middleware). Отличительной особенностью Koa является также повсеместное использование современных возможностей JavaScript для работы с асинхронным кодом (например, async/await функции или генераторы). [35] В свою очередь, данные возможности фреймворка позволили создать такую архитектуру серверного приложения, которая исключает утечку памяти в связи с чётким контролем стека операций Node.js.

3.4 Выбор СУБД и особенности структуры базы данных

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

Перед непосредственным выбором СУБД сперва необходимо было определиться с хранилищем данных. Были рассмотрены следующие три варианта:

арендовать облачное хранилище данных;

арендовать внешнее серверное оборудование;

использовать собственное серверное оборудование.

Первый вариант является, пожалуй, наиболее хорошим вариантом в плане сохранности данных, так как современные облачные решения, такие как Microsoft Azure или Amazon Web Services, обладают многочисленными возможностями репликации и кодирования данных. [36] Однако такое решение также является и наиболее дорогим и латентность при отправке и получении данных может быть выше, чем при использовании серверов, расположенных географически близко к офисам компании. Кроме того, при аренде облачных хранилищ, приватные данные пользователей компании будут храниться на серверном оборудовании сторонней компании, что может теоретически стать проблемой доверия.

Аналогично при аренде серверного оборудования у сторонних компаний возникает проблема доверия персональных данных пользователей сторонним лицам. [37]

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

При планировании процесса разработки рассматривались два вида баз данных - SQL-подобные и NoSQL-подобные, а именно - MySQL, являющейся представителем SQL-подобных баз данных, и MongoDB, являющейся представителем NoSQL-подобных баз данных. Так как собственное серверное оборудование использует оперативную систему Linux, то сложность установки и настройки той или иной СУБД не играло первичной роли, также как и их стоимость, так как и MySQL, и MongoDB, являются бесплатно распространяемыми решениями.

...