Интерфейс системы мониторинга IP-конференций на базе Cisco Call Manager
АННОТАЦИЯ
В дипломном проекте разработан интерфейс системы мониторинга
IP-конференций на базе Cisco Call Manager.
Система определяет состав участников IP-конференции и предоставляет его в
графическом виде пользователю.
Использование системы позволяет четко определить состав участников
IP-конференции и при необходимости изменять его - добавляя или удаляя
участников.
СОДЕРЖАНИЕ
ВВЕДЕНИЕ
1. ИССЛЕДОВАНИЕ ВАРИАНТОВ
ПОСТРОЕНИЯ СИСТЕМЫ МОНИТОРИНГА IP-КОНФЕРЕНЦИЙ НА БАЗЕ CISCO CALL MANAGER
1.1 Структура сети IP
телефонии в ИВЦ
1.2 IP-телефония
1.3 Основные системные
возможности Cisco Сall Manager
1.4 Основные
пользовательские функции
1.5 Протоколы IP-телефонии
поддерживаемые Cisco CallManager
1.5.1 Набор рекомендаций
Н.323
1.5.2 Протокол SIP
1.5.3 Протокол MGCP
1.5.4 Протокол RTP
1.5.5 Протокол SCCP
1.6 Интерфейс JTAPI
1.7 Типы конференций Cisco
Call Manager
1.8 Анализ конференций
различных типов
2. РАЗРАБОТКА СИСТЕМЫ
МОНИТОРИНГА
2.1 Способы решения
поставленной задачи
2.2 Взаимодействие системы
мониторинга с сервером
2.3 Взаимодействие
приложений системы мониторинга
2.4 Развёртка и настройка
системы
3. ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ
СИСТЕМЫ МОНИТОРИНГА КОНФЕРЕНЦИЙ
3.1 Основное приложение
3.2 Приложение конференции
4. ОПИСАНИЕ ГРАФИЧЕСКОГО
ИНТЕРФЕЙСА
5. ОБОСНОВАНИЕ ЭКОНОМИЧЕСКОЙ
ЭФФЕКТИВНОСТИ
5.1 Определение
экономических инвестиций
5.2 Чистый
дисконтированный доход
5.3 Доходы и
рентабельность
5.4 Заключение по разделу
6. ОХРАНА ТРУДА
6.1 Общая оценка
напряженности трудового процесса
6.2 Протокол оценки
условий труда по показателям напряженности трудового процесса
6.3 Оценка изменений
напряженности труда, с использованием проектируемой ИС
6.3.1 Изменения, связанные
с сенсорными нагрузками
6.3.2 Изменения, связанные
с монотонностью нагрузок
6.4 Вывод и рекомендации
СПИСОК ИСПОЛЬЗУЕМЫХ
ИСТОЧНИКОВ
ПРИЛОЖЕНИЕ 1
ПРИЛОЖЕНИЕ 2
ВВЕДЕНИЕ
Обеспечение услуг телефонии на базе сети передачи данных позволяет
избавиться от необходимости эксплуатации раздельных сетей для передачи данных и
телефонной связи и обеспечивает возможность более полного удовлетворения
потребностей предприятий в услугах телефонии. Продукция Cisco IP телефонии
позволит заказчику уменьшить расходы на внедрение, поддержку и расширение
объединенной сети и, как следствие, повысить рентабельность телекоммуникационной
сети. Вот лишь несколько достоинств использования IP телефонии:
· возможность построения единой телекоммуникационной инфраструктуры на базе
корпоративной IP сети;
· простота построения распределенных телефонных и
телекоммуникационных систем за счет распределенной природы архитектуры Cisco
AVVID;
· снижение общей стоимости владения системой;
· сокращение расходов на каналы за счет возможности
эффективного использования каналов для совместной передачи голосового трафика,
данных и трафика видеоприложений;
· сокращение расходов на оплату междугородних переговоров;
· упрощение настройки, поддержки и администрирования
телекоммуникационной инфраструктуры;
· возможность использования современных приложений,
использующих преимущества
· интеграции голоса, видео и данных в рамках единой
телекоммуникационной инфраструктуры;
· ориентация на поддержку открытых протоколов и интерфейсов для
разработки приложений (API), обеспечивающая возможность интеграции с широким
спектром современных приложений, предлагаемых в настоящее время различными
производителями;
· возможность разработки собственных приложений, интегрирующихся с сетями
на базе архитектуры Cisco AVVID.[1]
В
один из основных видов голосовой связи в Информационно-вычислительном центре
Октябрьской железной дороги является IP-телефония (VoIP). VoIP - общее название
коммуникационных протоколов, технологий и методов, обеспечивающих передачу
речевого сигнала
<#"651109.files/image001.gif">
Рисунок 1.1 - Структура сети IP
телефонии в ИВЦ
1.2
IP-телефония
Простейший вариант построения сери IP телефонии - локальная/кампусная
сеть с интеграцией голоса и данных (а также, возможно, видеоприложений).
В этом случае сетевая инфраструктура представлена коммутируемой сетью на
базе технологий Ethernet / Fast Ethernet / Gigabit Ethernet. Пользовательские
IP телефоны подключаются в пределах локальной/кампусной сети и работают под
управлением сервера Cisco CallManager.
Один сервер Cisco CallManager может поддерживать до 7 500 IP телефонов (в
зависимости от серверной платформы максимальное число телефонов на сервер может
изменяться в пределах от 100 до 7 500 телефонов). В целях масштабирования
системы и для обеспечения отказоустойчивости серверы Cisco CallManager могут
быть объединены в кластер.
В локальной/кампусной сети экономия полосы пропускания не является
критичной, поэтому для голосовых звонков в пределах локальной сети сжатие
голоса обычно не используется.
Серверы пользовательских приложений, таких как система голосовой почты
или интерактивных голосовых меню, расположенные в пределах кампусной сети,
обеспечивают дополнительные сервисы для абонентов системы.Unified
Communications Manager представляет собой центральный компонент решения
унифицированных коммуникаций Cisco. [6]
Сервер предназначен для выполнения основных управляющих функций в
системе, таких как:
1. Управление установлением телефонных соединений;
2. Настройка и управление системой IP-телефонии с помощью удобного
графического интерфейса, в том числе настройка IP телефонов, шлюзов, настройка
номерного плана, сбор и анализ статистической информации о функционировании
системы и т. Д. (предусмотрена возможность централизованной, а также удаленной
настройки системы);
. Дополнительные функции для пользователей в системе корпоративной
IP-телефонии, в том числе поддержка аудиоконференций, интеграция с
корпоративной директорией абонентов на базе протокола LDAP и др.;
. Интеграция с пользовательскими приложениями, в том числе
системой голосовой почты / унифицированной обработки сообщений (Unified
Messaging), системой интерактивных голосовых меню / автоматическим оператором
(IP IVR/AA) и т. Д.;
. Поддержка открытых интерфейсов, таких как TAPI, JTAPI, XML для
разработки телефонных приложений.
В качестве аппаратной платформы для программного обеспечения Cisco
callmanager используются серверы Cisco Media Convergence Server (MCS), а также
сертифицированные модели серверов других производителей (IBM, HP). В комплекте
с программным обеспечением Cisco callmanager поставляется набор дополнительных
голосовых и служебных приложений, в том числе: приложение Cisco callmanager
Attendant Console (графическая консоль секретаря), программное приложение для
организации аудиоконференций, приложение Bulk Administration Tool (BAT),
представляющее собой средство для автоматизации ряда настроек в системе, CDR
Analysis and Reporting Tool (CAR) для анализа статистики по телефонным
соединениям в системе и набор средств для мониторинга системы администратором
Admin Serviceability Tool (AST).
Asterisk
в комплексе с необходимым оборудованием обладает всеми возможностями
классической АТС <#"651109.files/image002.gif">
Рисунок 1.2 - Архитектура SIP
Клиент SIP (SIP user agent) - может быть представлен как устройством
(IP-телефон, шлюз или другой пользовательский терминал), так и программным
приложением для ПК, PDA и т. д. Обычно SIP-клиент содержит и клиентскую, и
серверную часть (User Agent Client, или UAC, и User Agent Server, или UAS).
Основные функции данного компонента - инициирование и завершение вызовов.
Прокси-сервер SIP - управляет маршрутизацией вызовов и работой
приложения. Прокси-сервер не может инициировать или терминировать вызовы.сервер
SIP - перенаправляет звонки согласно заданным условиям.
Сервер регистрации SIP (registrar/location) - осуществляет регистрацию
пользователей и ведет базу соответствия имен пользователей их адресам,
телефонным номерам и т. д. [14]
1.5.3
Протокол MGCP
MGCP (Media Gateway Control Protocol представляет собой группу
протоколов: SGCP, IPDC, MGCP, MEGACO, H.248. Эти спецификации не только очень
схожи концептуально, но и являются "близкими родственниками".
Основная идея MGCP очень проста. Она состоит в том, что управление
сигнализацией (Call Control) сосредоточено на центральном управляющем
устройстве, называемом контроллером сигнализаций (Call Agent, CA), и полностью
отделено от медиа-потоков (bearer). Эти потоки обрабатываются
"тупыми" шлюзами или абонентскими терминалами, которые способны
исполнять лишь ограниченный набор команд, исходящих от управляющего устройства.
Архитектура протокола MGCP-сети также очень проста (рис. 1.3), в ней выделяются
всего два функциональных компонента. Первый может быть представлен шлюзом
(Media Gateway, MG) или IP-телефоном, а второй - устройством управления
вызовами, которое может называться контроллером сигнализаций (CA), контроллером
шлюза (Media Gateway Controller, MGC) или программным контроллером (Softswitch,
SS).
Рисунок 1.3 - Архитектура протокола MGCP
Контроллеры обмениваются со шлюзами (или IP-телефонами) данными в простом
текстовом формате (в случае H.248 возможен и бинарный обмен), а функциональное
назначение каждого шлюза определяется набором команд, которые он
"понимает". Манипулируя наборами команд, можно получать
специализированные шлюзы: транковые (Trunking gateways, TGW), абонентские
(Residential gateways, RGW), шлюзы доступа (Access gateways, AGW) и т. д.
Контроллер сигнализаций CA воспринимает сеть как набор двух логических
элементов - устройств (end-points) и соединений (connections) между ними.
Устройства могут быть физическими (например, IP-телефоны или линии на шлюзах)
или виртуальными (например, линии к серверам голосовых сообщений). Соединения
могут быть ориентированы на передачу голоса, факс-сообщений или данных.
Управление этими элементами, т. е. организация соединений между устройствами,
происходит путем посылки команд в виде текстовых (ASCII) сообщений по протоколу
UDP - при этом может использоваться уже знакомый нам протокол SDP. Как правило,
управляющие воздействия контроллера СА инициируются какими-то событиями
(events). [9]
1.5.4
Протокол RTP
Протокол
RTP переносит в своём заголовке данные, необходимые для восстановления голоса
или видеоизображения в приёмном узле, а также данные о типе кодирования
информации (JPEG <#"651109.files/image004.gif">
Рисунок 1.4 - конференция типа Ad-hock
me - тип конференции при котором один из участников конференции создаёт
конференцию, к которой потом подключаются участники, звоня на номер телефона
создающего (рис.1.5.).
Рисунок 1.5 - конференция типа Meet-me
1.8 Анализ
конференций различных типов
В списке функций сервера Cisco Call Manager есть пункт «Возможность
просмотра списка участников конференции на телефонном аппарате, возможность
удаления участника», посте долгих поисков было определено, что данная функция
относится только к конференциям типа Ad-hock. Благодаря этой функции создатель
конференции может с помощью телефонного аппарата просматривать список
участников конференции и удалять из неё ненужных. Эта функция вызывается с
помощью программируемой клавиши на телефонном аппарате - «Список», почти все
телефоны, используемые в ИВЦ, поддерживают эту функцию. Администратор, через
web-интерфейс сервера может просматривать списки участников всех конференций,
удалять участников или полностью закрыть конференцию. Участники конференции с
помощью той же клавиши - «Список» могут просматривать список участников.
При изучении работы конференций этого типа был выявлен ряд недостатков
таких конференций, вследствие чего нежелательность их использования.
Основным недостаткам конференций созданных по типу Ad-hock является не
большое количество участников конференции, которое составляет 3-4 человека. При
увеличении количества участников, в процессе разговора появляются задержки и
искажения голоса, вызванные, скорее всего из-за специфического для конференции
данного типа, способа связи участников. Всю работы по взаимодействию участников
конференции и мультиплексированию голосового трафика берет на себя тот
телефонный аппарат, который создаёт конференцию. А так как вычислительные
способности телефонного аппарата несравнимо ниже, чем у сервера, он не в
состоянии обработать большой поток трафика в реальном времени, вследствие чего
появляются задержки и искажения.
2. РАЗРАБОТКА СИСТЕМЫ МОНИТОРИНГА
В результате проведенных исследований, было найдено два возможных решения
поставленной задачи. При их сравнении был выбран наилучший. Описание обоих
решений приведено ниже.
2.1
Способы решения поставленной задачи
Первый способ решения поставленной задачи. Система мониторинга,
основанная на конференции типа - meet-me. Схема работы системы представлен на
рис. 2.1.
Рисунок 2.1 - Первый способ решения
Перед началом конференции инициатор должен создать конференцию в
специально разработанном графическом интерфейсе. (Инициатор конференции -
человек ответственный за создание конференции, в его права входит: добавление и
удаление участников конференции, создание и завершение конференции.) Затем
участники должны подключиться к конференции путём набора номера конференции на
своём телефонном аппарате. После набора номера, система «снимает трубку», при
этом определяя номер звонящего. После этого номер сравнивается со списком
участников конференции: при положительном результате (номер есть в списке), он
помечается как активный и вызов перенаправляется на фактический номер
конференции, при отрицательном - происходит разрыв соединения. Пока проводится
конференция, модуль проверяет, положена ли трубка участника конференции или
нет. В тот момент, когда участник положит трубку, модуль определит данный факт
и изменит состояние участника на неактивное. При завершении конференции
происходит отключение всех участников от конференции.
Второй способ решения поставленной задачи. В этом случае система основывалась
на конференциях типа Ad-hoсk. Принцип работы изображен на рис. 2.2.
Рисунок 2.2 - Второй способ решения
Система по указанию инициатора конференции, сама звонит всем её бедующим
участникам в соответствии составленному списку. Возможности сервера Cisco Call
Manager позволяют получать полную информацию о состоянии конференции, но не
через интерфейс JTAPI, а через графический интерфейс самого сервера ССМ. Минусы
данного способа:
· большая сложность разработки из-за нестандартного получения данных от
сервера ССМ
· возможно, будут задержки при обновлении информации о статусе
участников
· необходимо достаточно мощный сервер (группа серверов) для
обработки и сведения голосового трафика, вследствие чего большие финансовые
затраты несоответствующие поставленной задачи
Вследствие вышесказанного можно сделать вывод, что основной способ
является более приемлемым для решения поставленной задачи.
2.2
Взаимодействие системы мониторинга с сервером
Взаимодействие системы мониторинга с сервером Cisco Call Manager можно
представить следующим образом рис. 2.3.
Телефонные аппараты общаются с сервером Cisco Call Manager по протоколу
SCCP, их состояние проверяет система мониторинга Conference Service
подключенная к серверу по интерфейсу. Пользователи мониторинга взаимодействуют
с ним с помощью графического интерфейса, разработанного в виде web-приложения,
по протоколу HTTP. В свою очередь система мониторинга взаимодействует с
сервером по интерфейсу JTAPI.
Рисунок 2.3 - Взаимодействие системы мониторинга с сервером
2.3
Взаимодействие приложений системы мониторинга
Система мониторинга состоит из нескольких приложений. Принцип
взаимодействия которых отображен на рис. 2.4.- Conference Service - ядро системы
обеспечивающее связь и взаимодействие всех её компонентов.- графический
web-интерфейс, благодаря которому производится управление системой и
взаимодействие с пользователем.- sql-сервер для хранения всей информации о
системе.
ССМ -
Cisco Call Manager - сервер ip-телефонии.
Приложение 1…n - приложения, следящие за состоянием какой-то определенной
конференции, запускаются и завершаются при создании и завершении конференции
соответственно.
Рисунок 2.4 - Взаимодействие приложений системы
2.4
Развёртка и настройка системы
Данная система мониторинга написана на языке высокого уровня - Java, так
как этот язык является кроссплатформенным, то систему можно развернуть на любой
операционной системе, на которой установлена Java-машина.
Развёртка системы начитается и ядра системы. Вначале необходимо правильно
настроить приложения - указать серверы ССМ и БД (SQL), затем запустить
приложение ядра. После старта ядра администратору станет доступен графический
интерфейс, в котором администратор системы добавляет пользователей и создаёт
для них конференции. Как и при создании конференций типа meet-me без участия
данной системы, на сервере ССМ также следует указать необходимые настройки, но
кроме этого нужно также добавить учётные записи для приложений, которые
использует система для приёма вызовов.
3. ПРОГРАММНОЕ
ОБЕСПЕЧЕНИЕ СИСТЕМЫ МОНИТОРИНГА КОНФЕРЕНЦИЙ
Данная система состоит из двух приложений: основного и приложения
конференции. Оба приложения написаны на языке высокого уровня - Java,
разработка проводилась в среде для разработок NetBeans.
3.1
Основное приложение
Основное приложение содержит в себе GUI (графический интерфейс
пользователя) и CS (Conference service - ядро системы) согласно схеме на рис.
9. При создании конференций, для каждой конференции, данное приложение
запускает свой экземпляр приложение конференции. Обмен данными между
приложениями происходит в одностороннем порядке, от приложения конференций к
основному приложению, при помощи файла логов, в который приложение конференции
записывает все события конференции, а основное приложение отображает их в
графическом интерфейсе. При завершении конференции основное приложение
завершает приложение конференции, при этом приложение конференции завершает все
активные соединения.
Классы приложения:
· Main.java - основной класс сервиса.
· Conference.java - класс для работы с конференциями.
· Session.java - класс для работы с сессиями.
· Applications.java - класс для взаимодействия с приложениями
конференций.
· ConferenceList.java - класс для формирования списка
участников конференции.
· Logs.java - класс для записи событий системы в файл.
· Пакет «Interface» - пакет, содержащий страницы интерфейса:
· Login.jsp - страница авторизации.
· AdmConference.jsp - страница администратора конференций.
· AddUser.jsp - страница добавления пользователя к конференции.
· DellUser.jsp - страница удаления пользователя из конференции.
· InfoNum.jsp - страница отображающая информацию о номере
абонента.
· Conference.jsp - страница отображающая список конференций.
· User.jsp - страница отображающая информацию о пользователе
системы.
· Users.jsp - страница отображающая пользователей конференции.
· Find.jsp - страница поиска пользователей и конференций.
· Setting.jsp - страница настройки сервиса.
Схема основного приложения рис. 3.1.
Рисунок 3.1 - Схема основного приложения
3.2
Приложение конференции
Приложение конференции отвечает непосредственно за создание конференции и
запускается отдельно для каждой конференции, на схеме рис. 9 ему соответствует:
Приложение 1, Приложение 2 … Приложение N.
· MakeCall.java - класс для вызова абонента (код представлен в приложении)
· ReCall.java - класс для переадресация вызова (код представлен
в приложении)
· StopSignal.java - класс для разрыв соединения (код
представлен в приложении)
· Main.java - основной класс приложения
· Logs.java - класс для записи событий конференции в файл
Схема приложения конференции рис. 3.2.
Рисунок 3.2 - Схема приложения конференции
4. ОПИСАНИЕ ГРАФИЧЕСКОГО ИНТЕРФЕЙСА
На рис. 4.1 - 4.6. изображен интерфейс инициатора конференции.
На первом (рис. 4.1.) отображен интерфейс входа в систему, для
идентификации пользователя.
Рисунок 4.1 - Интерфейс авторизации
На следующем рисунке (рис. 4.2.), представлен интерфейс управления
конференцией. В оглавлении страницы после слова «Конференция» стоит имя
конференции, в данном случае «Конференция 1».
Ниже следует таблица отображающая состояние участников конференции. В
первом столбце, цветом отображено состояние участника: красный - отключен,
зеленый - присутствует в конференции. Во втором номер телефона участника. В
следующем - имя участника, затем время присутствия в конференции: первое -
время подключения к конференции, через тире - время отключения, пока участник
присутствует, на месте второго времени символ «…».
Напротив каждого участника стоят две кнопки: «Вызвать/Отключить»,
«Удалить». Кнопка «Вызвать/Отключить» - вызывает абонента и подключает его к
конференции / отключает абонента от конференции. Кнопка «Удалить» - удаляет
участника из конференции, после чего он не может подключиться к данной
конференции.
В левой части окна указано время начала и окончания конференции, пока
конференция не завершена, на месте времени завершения символ «…». Ниже две
кнопки: «Завершить конференцию» и «Добавить участника». Кнопка «Завершить
конференцию» - завершает конференцию, при этом происходит разрыв соединений со
всеми её участниками. Кнопка «Добавить участника» - добавляет участника в
конференцию, при этом можно выбрать: сразу позвонить и присоединить абонента
или просто добавить в список участников конференции.
Далее расположены ссылки для перехода в другие разделы интерфейса:
«Список конференций», «Удалённые из конференции» и ссылка «Назад» - для
перехода в предыдущий раздел.
В самом низу страницы отображено имя пользователя системы и кнопка
«Выход» для завершения текущей сессии.
На рис. 4.3 изображен список пользователей, которые были удалены из
конференции.
В центре окна таблица. В первом столбце имя пользователя. В следующем IP
адрес телефонного аппарата. В следующем дата и время удаления участника. В
последнем имя конференции, из которой был удален пользователь. Так как
пользователь может пользователь может состоять в разных конференциях, то он
может встречаться несколько раз.
Напротив каждой записи есть кнопка восстановить, добавляющая пользователя
обратно в конференцию.
В правой части окна расположена кнопка «Очистить», позволяющая очистить
список участников которые были удалены, с возможностью удалить либо всех, либо
в период с одной даты, по вторую, если оставить одну из дат пустой, то удалятся
все пользователи или до или после введенной даты соответственно.
В самом низу страницы отображено имя пользователя системы и ниже кнопка
«Выход» для завершения текущей сессии.
На рис. 4.4 изображен интерфейс, позволяющий добавить участника в
конференцию.
По центру, после слов «Добавить в конференцию» идёт название конференции,
в которую будет добавлен участник.
Ниже этой надписи идут поля для ввода номер имени пользователя, если
пользователь уже существует в системе, т.е. у телефона уже соответствует имя,
то оно будет введено автоматически.
Ниже две кнопки «Добавить» и «Добавить и позвонить». Первая просто
добавляет пользователя к конференции, вторая после добавления сразу звонить
данному пользователю и подключает его в конференцию, но эта кнопка активна
только в том случае, если конференция создана.
В самом низу страницы отображено имя пользователя системы и кнопка
«Выход» для завершения текущей сессии.
На рис. 4.5 - интерфейс с информацией о номере.
Сверху после слов «Информация о номере» - номер участника.
Первая строка содержит имя участника, вторая - IP телефонного аппарата,
следующая - список конференций, к которым может подключиться пользователь,
затем - комментарий.
В самом низу страницы отображено имя пользователя системы и кнопка
«Выход» для завершения текущей сессии.
На следующем рисунке (рис. 4.6.) изображен интерфейс с информацией о
доступных конференциях для данного пользователя.
По центру окна расположена таблица с доступными конференциями. В первом
столбце изображен статус конференции - начата/завершена, соответственно зелёный
или красный прямоугольник, в следующем столбце расположен номер конференции,
затем имя, потом столбец с названием «Блок» отображающий доступна ли
конференция или временно заблокирована администратором. В последнем столбце
расположен комментарий к конференции.
Напротив каждой записи расположена кнопка «Завершить/Начать» -
соответственно для завершения и начала данной конференции.
В самом низу страницы отображено имя пользователя системы и кнопка
«Выход» для завершения текущей сессии.
Далее на рис. 4.7. - 4.10. представлен интерфейс администратора системы.
На рис. 4.7 отображен интерфейс пользователей системы.
По центру окна расположена таблица с данными о пользователях. В первом
столбце показан статус конференции - активна или нет, соответственно зелёный
или красный цвет. Во втором - номер телефонного аппарата пользователя. В
третьем - имя пользователя, затем его пароль. В последнем столбце комментарий.
Напротив каждой записи две кнопки: «Конференции» и «Удалить». Кнопка
«Конференции» отображает список конференций доступных для данного пользователя.
Кнопка «Удалить» - удаляет пользователя из системы.
В правой части окна расположена кнопка «Добавить пользователя»,
позволяющая добавить пользователя в систему.
Ниже этой кнопки расположены ссылки для перехода по разделам: «Поиск»,
«Настройки» и «Назад».
В самом низу страницы отображено имя администратора системы и кнопка
«Выход» для завершения текущей сессии.
На следующем рис. 4.8 отображена информация о конференциях одного
пользователя.
Сверху после слова «Пользователь», идёт имя пользователя.
По центру окна таблица содержащая информацию о конференциях пользователя.
В первом столбце отображен статус конференции: зеленый означает конференция
начата, красный - завершена, серый - заблокирована. Во втором столбце
телефонный номер конференции. Затем имя конференции и комментарий к
конференции.
Напротив каждой строки расположены две кнопки: «Удалить» и
«Заблокировать/Разблокировать». Кнопка «Удалить» - удаляет конференцию,
«Заблокировать/Разблокировать» - блокирует или разблокирует использование конференции.
В правой части окна рассоложена кнопка «Добавить конференцию» -
позволяющая добавить конференцию.
Ниже - ссылки для перехода по разделам: «Пользователи», «Поиск»,
«Настройки» и «Назад».
В самом низу страницы отображено имя администратора системы и кнопка
«Выход» для завершения текущей сессии.
На рис. 4.9. отображен интерфейс для поиска пользователей и конференций.
В центре окна два поля. Первой «Пользователь» - куда вводится имя
пользователя или его телефон или IP адрес его телефонного аппарата, сразу за
этим поле кнопка найти. Второе поле «Конференция» - поиск проводиться
аналогичным образом.
Справа - ссылки для перехода по разделам: «Пользователи», «Настройки» и
«Назад».
В самом низу страницы отображено имя администратора системы и кнопка
«Выход» для завершения текущей сессии.
На рис. 4.10. изображен интерфейс настроек сервера.
В центре окна поле и кнопка. Поле «Обновление списков, сек» - отучает за
то, как часто будут обновляться страницы со списками конференций, пользователей
и т.д. Кнопка «Состояние сервиса» - останавливает и делает доступным данный
сервис.
Справа расположены ссылки для перемещения по раздела «Пользователи»,
«Поиск» и «Назад».
В самом низу страницы отображено имя администратора системы и кнопка
«Выход» для завершения текущей сессии.
5. ОБОСНОВАНИЕ ЭКОНОМИЧЕСКОЙ ЭФФЕКТИВНОСТИ
Целью данного дипломного проекта является разработка мониторинга
IP-конференций. Важным элементом разработки является оценка экономической
эффективности данного проекта.
5.1
Определение экономических инвестиций
При определении стоимостных и трудовых затрат на разработку программной
системы был использован метод экспертных оценок. Результаты расчета приведены в
табл. 5.1.
Таблица 1 - Смета затрат на разработку ПС
|
Статьи расходов
|
|
Основная зарплата
|
100000
|
|
Единый социальный налог (30%)
|
30000
|
|
Накладные расходы (20%)
|
20000
|
|
Расходы на ПК
|
27000
|
|
Итого себестоимость разработки
|
177000
|
Основная заработная плата (ОЗП) определяется исходя из количества
разработчиков (1), времени выполнения разработки (4 месяца) и заработной платы
в расчете на 1 месяц (25000 руб.) .
Отчисления на социальное страхование составляют 30% от основной и дополнительной
заработной платы.
Накладные расходы определяются в процентном отношении от ОЗП и для
лабораторий ПГУПС составляют 20%.
Расходы на ПК определяются эксплуатационными расходами на ПК в течение
срока разработки ПС, стоимостью компьютера и временем разработки программного
продукта.
В эксплуатационные расходы входят:
1. расходы на электроэнергию;
2. стоимость расходных материалов;
. расходы на ремонт;
. заработная плата ремонтника;
. дополнительные расходы - уборка помещения, охрана, аренда, коммунальные
услуги;
. амортизационные затраты на ПК и ПО.
Расходы на электроэнергию определяются мощностью компьютера, стоимостью
1кВт/ч электроэнергии и временем использования компьютера (8 часов в день, 21
день в месяц, 4 месяца) и составляют:
. (1)
После подстановки известных значений в формулу (1) получим:
Стоимость расходных материалов в течение всего срока эксплуатации
компьютера (3 года) составляет примерно 10% от его стоимости. Следовательно,
можно определить подобные расходы за период создания ПС (4 месяца из 36).
. (2)
После подстановки значений в формулу (2) получим:
По статистике расходы на комплектующие изделия (
) для ремонта ПК составляют 10% от
стоимости ПК за срок его эксплуатации.
После подстановки известных значений в формулу (3) получим:
На ремонт 50 компьютеров требуется один инженер-системотехник. Его
среднемесячная заработная плата
. Тогда в пересчете на один компьютер его заработная плата
составит
. (4)
При ЗП, равной 20000 руб. в месяц, в расчете на один компьютер за период
разработки ПО, равный четырем месяцам, заработная плата ремонтника составит:
Амортизационные отчисления на ПК с учетом всего срока его
эксплуатации (3 года) равны:
Подставив значения в формулу (5) получим:
При разработке программной системы срок морального устаревания ПО
принимается равным 3 года. Таким образом, амортизация ПО за срок разработки
программной системы составляет:
Подставив значения в формулу (6) получим:
Используемое ПО:
операционная система Windows 7 pro (7000 руб.);
средство автоматизированного тестирования TestComplete 9 (64760 руб.);
Дополнительные расходы (уборка помещения, охрана, аренда, коммунальные
услуги) оценить трудно, поэтому они принимаются равными заработной плате
инженера-системотехника за весь срок разработки программной системы.
.
Суммарные эксплуатационные расходы на один ПК составят:
, (9)
После подстановки известных значений в формулу (9) получим:
уб.
Результаты расчетов сведены в табл. 5.2
Таблица 2 - Эксплуатационные расходы на ПК
|
Статьи расхода
|
Затраты (руб.)
|
|
Расходы на электроэнергию
|
564,28
|
|
Стоимость расходных материалов
|
333,3
|
|
Расходы на комплектующие изделия
|
333,3
|
|
Расходы на ремонт
|
1600
|
|
Амортизация ПК
|
3000
|
|
Амортизация ПО
|
65838
|
|
Дополнительные расходы
|
|
Итого эксплуатационные расходы на ПК
|
73713,2
|
Себестоимость создания среды определяется как сумма статей таблицы 5.1.
Полученная величина рассматривается как необходимые инвестиции в создание
данного проекта.
5.2 Чистый
дисконтированный доход
Соизмерение затрат, результатов и эффектов в течение расчетного периода
осуществляется с помощью метода дисконтирования. Дисконтирование основано на
прогнозе будущих затрат и результатов, на использовании процентной ставки или
нормы дисконта Е.
Чистый дисконтированный доход (ЧДД) рассчитывается как разность
накопленного дисконтированного дохода от реализации проекта и дисконтированных
единовременных затрат на внедрение инновации. ЧДД определенного периода
рассчитывается по формуле:
где T - расчетный период;- результат в t-ом году; Зt - затраты, текущие
издержки и инвестиции в t-й год; E - норма дисконта;
- коэффициент дисконтирования.
Для расчета нормы дисконта Е воспользуемся формулой:
= a + b + c, (11)
где a -доходность альтернативных вложений;-уровень премии за риск; c
-уровень инфляции.
В данном проекте, в качестве альтернативных вложений средств, необходимых
для реализации данного проекта, взят средний банковский депозитный процент -
11% годовых в рублях.
Премия за риск рассчитывается, исходя из среднего класса инновации,
определяемого на основании морфологической таблицы 1.3, по формуле (12):
, (12)
где
- средний класс инновации;- класс
сложности инновации по i-му классификационному признаку;- количество
классификационных признаков.
Таким образом, исходя из таблицы 5.3:
.
По данным агентства РБК, уровень годовой инфляции рубля в 2011 г.,
составил 6.1 %. Поэтому для дальнейших расчетов значение уровня инфляции (c)
примем равным 6.1 %.
Таблица 3 - Классификация нововведений и инновационных процессов по
группам риска
|
Признаки разделения на группы
|
Значения признаков, определяющих группу риска
|
Класс по признаку
|
|
Тип новатора (сфера создания новшества)
|
Образовательные учреждения
|
7
|
|
Уровень инноватора
|
Подразделение вуза
|
7
|
|
Масштаб распространения нововведения
|
Единичная реализация
|
5
|
|
Длительность инновационного процесса
|
Долгосрочные (более 3 лет)
|
8
|
|
Сумма строк:
|
27
|
В соответствии с табл. 5.4. параметр при расчете коэффициента
дисконтирования будет составлять 20%.
Таблица 4 - Соотношение среднего класса инновации и средней премии за
риск, устанавливаемой для инновации данного класса.
|
Средний класс инновации
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
8
|
|
Премия за риск, %
|
0
|
0,5
|
1
|
2
|
5
|
10
|
20
|
50
|
Таким образом, значение нормы дисконта для расчета экономической
эффективности данного проекта:
Чтобы определить дисконтированный доход данного проекта, необходимо
рассчитать эксплуатационные расходы по каждому периоду.
Расходы на электроэнергию определяются мощностью одного ПК, на котором
будет реализовываться проект - 0,3кв/ч, стоимостью 1кВт/ч электроэнергии и
временем использования (24 часов в сутки, 356 дней в году) сервера составят:
Амортизационный период ПК в настоящее время равен сроку морального
старения вычислительной техники и составляет 3 года. Следовательно, амортизация
оборудования составит:
.
Заработная плата двух тестировщиков составляет 50000 руб. в месяц. С
учетом ЕСН эта сумма составляет 65000 руб. в месяц. За год эта сумма составляет
780000 руб.
Дополнительные расходы - прочие расходы, обеспечивающие хозяйствующую
деятельность, то есть коммунальные услуги, арендные платежи, уборка помещения,
охрана, связь и т.п. Для данного проекта примем их равными 20% от общей суммы,
расходов указанных выше. Следовательно, за год данная сумма расходов составит:
159606 руб.
Таким образом, эксплуатационные расходы равны:
Доходы (Д) можно рассмотреть в качестве заработной платы тестировщиков,
которых можно сократить при внедрении автоматизированного тестирования.
Учитывая увеличение скорости тестирования, в небольшом проекте количество
тестировщиков с пяти до одного. Таким образом доход за год составит:
.
Кроме того, доход можно представить, как убытки, которые не произошли,
благодаря своевременному и качественному тестированию. Однако, такие убытки
численно оценить очень сложно. Он может варьироваться от затрат на проведение дополнительного
тестирования, до полного закрытия проекта.
Результаты расчетов сведены в табл. 5.5.
Таблица 5 - Расчет дисконтированного дохода
|
2012
|
2013
|
2014
|
2015
|
2016
|
|
Капиталовложения
|
250713
|
0
|
0
|
0
|
0
|
|
Эксплуатационные расходы
|
957633
|
957633
|
957633
|
957633
|
957633
|
|
Доходы
|
1170000
|
1170000
|
1170000
|
1170000
|
1170000
|
|
Прибыль
|
-38346
|
212367
|
212367
|
212367
|
212367
|
|
Коэффициент дисконтирования
|
1
|
0,72
|
0,51
|
0,37
|
0,26
|
|
ДД
|
-38346
|
148657
|
106184
|
78576
|
55216
|
|
ДД с нарастающим итогом
|
-38346
|
110311
|
216495
|
295071
|
350284
|
По результатам произведенных расчетов видно, что с самого начала значение
показателя «дисконтированный доход» (ДД) является положительным, что
свидетельствует об экономической выгодности (эффективности) данного проекта.
Чем больше ДД, тем эффективнее проект.
Рисунок 5.1 - Дисконтированный доход с нарастающим итогом
5.3 Доходы
и рентабельность
Индекс доходности - это отношение суммарного дисконтированного дохода к
суммарным дисконтированным затратам:
, (14)
где
- доходы i-го периода реализации проекта;
- затраты
i-го периода реализации проекта;
E - норма дисконта;
n - количество периодов реализации проекта.
По
формуле (14) получим:
1,12.
В данном случае индекс доходности больше 1, следовательно, данный проект
экономически эффективен.
Среднегодовая рентабельность проекта является разновидностью индекса
доходности, соотнесенного со сроком реализации проекта. Этот показатель
указывает, какой доход приносит вложенная в проект единица инвестиций:
(14)
где ИД - индекс доходности;- количество периодов реализации проекта.
Таким образом по формуле (14):
Критерием экономической эффективности инновационного проекта является его
положительная рентабельность.
5.4
Заключение по разделу
Данный проект является экономически эффективным. Является выгодным в
плане затрат на тестирование ПО. Он окупается в течении второго года его
реализации и имеет индекс доходности 1,12.
В разделе охраны труда необходимо произвести оценку напряженности
трудового процесса сменного работника, главными задачами которой являются:
· слежение за мониторингом группы серверов
· исправление незначительных неисправностей в работе серверов
· сообщение о неисправностях в работе серверов администраторам
и начальнику смены
Необходимо произвести оценку всех показателей до использования
проектируемой ИС и с её использованием. Все изменения необходимо
прокомментировать и подтвердить расчетами. В конце раздела пишется заключение
по оценке напряженности, а также приводятся рекомендации по компенсации
изменений в сторону ухудшения, если таковые имеют место.
6.1 Общая
оценка напряженности трудового процесса
Независимо от профессиональной принадлежности (профессии) учитываются все
23 показателя, перечисленные в табл. 18 (Приложение Х). Не допускается
выборочный учет каких-либо отдельно взятых показателей для общей оценки
напряженности труда.
По каждому из 23 показателей в отдельности определяется свой класс
условий труда. В том случае, если по характеру или особенностям
профессиональной деятельности какой-либо показатель не представлен (например,
отсутствует работа с экраном видеотерминала или оптическими приборами), то по
данному показателю ставится 1 класс (оптимальный) - напряженность труда легкой
степени.
При окончательной оценке напряженности труда.
«Оптимальный»
(1 класс <#"651109.files/image056.gif">
