Повышение качества поддержки пользователей в Ухтинском Государственном Техническом Университете

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

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

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

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

 

В настоящий момент на предприятии уже существует единый сервер под управлением ОС Windows 2003 Server, на котором установлены Web-сервер Appatch и Mysql версии 4.1, служащий для различных информационных системы ВУЗа и сайта предприятия.

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

Конфигурация сервера:

• центральный процессор Intel-Core-i7, 2.7ГГц
• оперативная память DDR3-2100 32Gb
• сетевые карты 1Gb

Клиентские приложения разрабатываются для работы под  управлением ОС семейства Windows, а именно Windows XP\Vista\7. Клиентская часть должна быть не требовательна к аппаратным ресурсам и запускаться на всех компьютерах сети ВУЗа.

5. Требования к интерфейсу

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

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

• Форму авторизации пользователя в системе;
• Форму поиска и просмотра путей решения проблемы (работа с «Базой Знаний»);
• Форму работы с запросами (формирование запроса, контроль за ходом исполнения, подтверждение выполнения запроса)

Интерфейс администратора системы должен включать в себя:

• Форму авторизации пользователя в системе;
• Форму редактирования «Базы Знаний» (работа с «Базой Знаний»);
• Форму работы с запросами (просмотр поступивших запросов, фиксация факта обработки запроса)
• Форму формирования отчета

 

3. Разработка программного продукта

 

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

1. Разработка структуры программного продукта

 

В общем виде работу всей системы можно представить в виде схемы, изображенной на рисунке 2.

 

Рисунок 2 –Общая структура разрабатываемой системы

 

Ниже приведён состав функционала и необходимых данных внутри подсистем.

 

1) Подсистема поиска в Базе Знаний

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

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

 

2) Подсистема формирования  запросов

Данная подсистема служит для формирования запроса в сектор администрирования для решения  задачи, ответа на которую нет в  Базе Знаний.

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

1. Время возникновения проблемы
2. Описание проблемы
3. Тип проблемы (если есть возможность определить)

После этого информация о запросе записывается в БД, внося следующую информацию:

1. Время поступления запроса
2. Время возникновения проблемы
3. Описание проблемы
4. Имя компьютера, на котором возникла эта проблема
5. Имя пользователя, сформировавшего запрос

 

В дальнейшем через эту же подсистему пользователь может просмотреть статус выполнения запроса:

1. Не обработан

2. В обработке (администратор  знает о проблеме)

3. Обработан (администратор устранил проблему)

4. Закрыт (проблема разрешена)

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

 

3) Подсистема обработки  запросов

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

Также эта подсистема осуществляет формирование месячных отчетов администратора.

4) Подсистема формирования  базы знаний

После того как запрос меняет свой статус на «Закрыт». Администратор  может добавить его в базу знаний. После чего исходное описание проблемы и метод ее решения становятся доступными для поиска оператору.

2.  Разработка алгоритмов работы программного продукта

 

В данной главе будут  рассмотрены алгоритмы работы разрабатываемой  системы.

В разрабатываемой системе можно выделить 3 основных решаемых задачи:

• решение возникшей проблемы со стороны пользователя;
• решение возникшей проблемы со стороны администратора;
• формирование базы знаний администратора.

 

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

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

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

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

Алгоритм работы администратора с системой показан в приложении Б.

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

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

В конце месяца администратор  может сформировать отчет по работе за месяц на основе обработанных запросов.

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

3. Разработка интерфейса

 

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

Рисунок 3 – Общая схема интерфейса клиентских приложений системы

 

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

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

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

 

Заключение

 

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

• В результате выполненого анализа предметной области было описана механизм поддержки пользоватлей, осущнествляетмый в настоящий момент, были выделены основные функции, требующие автоматизации;
• Осуществлен обзор аналогов, представленных в настоящий момент на рынке. В результате сравнения аналогов была выявлено что все из них обладают избыточной функционалностью и высокой стоимостью. В результате было п<span class="dash041e_0431_044b_0447_043d_044b_0439__Char" st