Содержание к диссертации
Введение
1. Современное состояние проблемы поддержки пользователей в распределенных сетях 10
1 1.1 .Анализ требований к системе 10
1.1.1 . Прозрачность 10
1.1.2,Открытость 14
1.1.3 .Гибкость 15
1.1 АМасштабируемость 17
1.1.5 .Непротиворечивость и репликация 19
1.1 .6.Защита 21
1.1.7.Отказоустойчивость 25
1.1.8. Самообучаемость 27
1.1.9.Кроссплатформенность 28
1.2. Анализ существующих систем-аналогов, их достоинства и недостатки 29
1.2.1.HPOpenView Service Desk 29
1.2.2.Naumen Service Desk 37
1.2.3 .DocsVision ServiceDesk 49
1.3 .Технологическая база разрабатываемой системы 52
1.3.1 .Физический уровень 52
1.3.2.Сетевой уровень 53
1.3.3.Прикладной уровень. 54
1.4.Назначение основных функций системы, их преимущества 57
1.5.Выводы по главе 1 58
2. Построение имитационной модели системы на основе раскрашенных сетей Петри 59
2.1. Обоснование выбора математического аппарата и программы компьютерного моделирования 59
2.2.Построение модели и описание ее функциональных блоков 65
2.3.Построение временной модели 72
2.4.Анализ временной модели системы 73
2.5.Анализ эффективности системы поддержки пользователей 78
2.6. Сравнение по временным характеристикам с существующими аналогами 91
2.7.Выводы по главе 2 92
3 Разработка методов и алгоритмов функционирования системы поддержки пользователей 94
3.1 Подробная модель функционирования системы 94
3.2,Описание используемых алгоритмов 99
3.2.1 . Механизм построения очереди инцидентов на обработку 99
3.2.2. Алгоритм обработки инцидентов экспертной системой 110
3.2.3. Алгоритм обработки инцидентов системой устранения неполадок 110
3.2.4. Алгоритм обработки инцидентов системой обновлений 112
3.2.5.Метрики эффективности работы системы 113
3.3. Разработка структуры базы данных 113
3.3.1. Описание предметной области 113
3.3.2. Анализ информационных требований пользователя 114
3.3.3.Описание абстрактных объектов данных 120
3.3.4.Описание локальных взглядов пользователей и разработка концептуальной схемы данных 123
3.4. Выводы по главе 3 129
4 Проектирование интерфейсов взаимодействия пользователя и системы, применение на предприятии 130
, 4.1. Пользовательский интерфейс системы. 130
4.2.Интерфейс администратора 131
4.3.Внедрение системы поддержки пользователей в КИС 133
4.3.1.Описание существующей КИС 133
4.3,2. Внедрение системы 134
4.4.Выводы по главе 4 136
Заключение 137
Литература 138
Приложение 147
- Прозрачность
- Обоснование выбора математического аппарата и программы компьютерного моделирования
- Механизм построения очереди инцидентов на обработку
- Внедрение системы
Введение к работе
Актуальность проблемы
В настоящее время большинство специализированных систем, которые используются для поддержки пользователей в организациях, не достаточно самостоятельны и независимы. Все ключевые действия в таких системах выполняются человеком. Настоящая работа направлена на то, чтобы максимально автоматизировать процессы взаимодействия пользователя и корпоративной информационной системы (КИС), начиная от приема заявок, до успешного выполнения действий на компьютере пользователя.
В диссертации предложены универсальные алгоритмы и методы, которые при минимальных настройках можно будет применять на предприятии любого масштаба и уровня компьютеризации. Для начала необходимо обеспечить автоматизированный прием и регистрацию заявок от пользователей. Далее их классификацию по степени срочности, важности, по важности отправителя. После чего эти заявки должны быть обработаны. Для достижения этой цели в диссертации предлагается совместить воедино несколько параллельных методов обработки заявок от пользователей. Чтобы выбрать такие методы необходимо классифицировать поступающие заявки. По результатам анализа, выделяем четыре типа – вопрос, заявка на обновление, неисправность программного обеспечения, неисправность аппаратного обеспечения. В соответствии с данной классификацией в работе выделено четыре метода обработки данных заявок, три из которых полностью автоматизированы. Вопросы обрабатывает экспертная система, выдавая из своей базы ответы, заявки на обновление – система обновлений, автоматически загружающая и выполняющая данные обновления на компьютерах пользователей. Неисправности программного обеспечения тоже достаточно стандартны и их обработкой в автоматическом режиме занимается система устранения неисправностей. Все же не разрешимые для данных обработчиков вопросы и неполадки, а так же неисправности аппаратного обеспечения обрабатывает администратор системы- человек. При таком подходе опять не удается избежать зависимости от человека, но разрабатываемая система является обучаемой, т.е. каждую следующую неразрешимую для автоматики проблему администратор заносит в базу данных, откуда в следующий раз автоматика выбирает инструкции по устранению неисправностей.
Для пользователя система предстает абсолютно прозрачной, потому как для него важен только результат. В итоге мы получим совершенно уникальную на данный момент систему, которая может значительно снизить время обработки заявок и так же для предприятия позволит сэкономить на труде администраторов.
Цель и основные задачи исследования
Целью диссертации является повышение эффективности функционирования предприятия или производственного объединения за счет автоматизации процессов обработки заявок в системах поддержки пользователей КИС.
Для достижения указанной цели решены следующие задачи:
-
Проведен анализ существующих систем поддержки пользователей, выделены существующие проблемы в данном вопросе, сформулированы требования к функциональности систем, программному обеспечению, диалогам взаимодействия с пользователями.
-
Разработан метод построения очереди заявок с классификацией и сортировкой заявок по обработчикам.
-
Построена имитационная модель системы на основе сетей Петри, для оценки характеристик системы, которая позволяет получить количественные характеристики, такие как среднее время обработки заявок по каждому обработчику и для системы в целом.
-
Проведена оценка вычислительной эффективности предложенных методов и алгоритмов, вычислены основные характеристики системы, показывающие ее эффективность.
-
Разработаны интерфейсы взаимодействия пользователя и администратора с системой поддержки, с учетом требований прозрачности.
-
Разработана логическая модель базы данных, которая включает в себя заявки пользователей, ответы системы, а так же показатели метрик эффективности для каждой заявки по каждому обработчику.
При разработке системы использовались методы теории сетей Петри, анализа систем массового обслуживания.
Научную новизну работы составляют:
-
Метод формирования очереди на обработку пользовательских заявок, который позволяет классифицировать заявки по степени важности, по времени создания, а так же по степени значимости отправителя. Метод позволяет направлять заявки тем обработчикам, которые способны быстрее всего с ними справиться.
-
Имитационная модель, созданная на основе раскрашенных сетей Петри, которая позволяет получать выходные характеристики системы при изменяющихся внешних нагрузках. Данная модель иллюстрирует поведение системы в реальных условиях эксплуатации.
-
Модель системы автоматизированного устранения неполадок, особенность которой заключается в том, что она способна самостоятельно разрешить проблему пользователя от регистрации до успешного завершения, без участия администратора.
-
Модель базы данных, включающая в себя логическое описание совокупности ответов, инструкций, обновлений, при помощи которых обеспечивается быстрая и качественная работа системы поддержки пользователей КИС.
Обоснованность результатов диссертационной работы, полученных с использованием признанных научных положений и апробированных методов исследования, подтверждается корректным применением математического аппарата и согласованностью этих новых результатов с известными теоретическими положениями.
Достоверность результатов подтверждается расчетными данными, полученными с помощью математического моделирования, алгоритмов и программ моделирования и научных выводов.
Прозрачность
Важная задача распределенных систем состоит в том, чтобы скрыть тот факт, что процессы и ресурсы физически распределены по множеству компьютеров. Распределенные системы, которые представляются пользователям и приложениям в виде единой компьютерной системы, называются прозрачными (transparent). Рассмотрим сначала как прозрачность реализуется в распределенных системах, а затем зададимся вопросом, зачем вообще она нужна.
Концепция прозрачности, как видно из табл. 1.1, применима к различным аспектам распределенных систем:
Прозрачность доступа (access transparency) призвана скрыть разницу в представлении данных и в способах доступа пользователя к ресурсам. Так, при пересылке целого числа, с рабочей станции на базе процессора Intel на Sun SPARC необходимо принять во внимание,- что процессоры- Intel оперируют с числами формата «младший — последним (то есть, первым передается старший байт), а процессор SPARC использует формат «старший — последним» (то есть первым передается младший байт). Также в данных могут присутствовать и другие несоответствия. Например, распределенная система может содержать компьютеры с различными операционными системами, каждая из которых имеет собственные ограничения на способ представления имен файлов. Разница в ограничениях на способ представления имен файлов, так же как и собственно работа с ними, должны быть скрыты от пользователей и приложений [75].
Важная группа типов прозрачности связана с местоположением ресурсов.
Прозрачность местоположения (location transparency) призвана скрыть, от пользователя, где именно физически расположен в системе нужный ему ресурс. Важную роль в реализации прозрачности местоположения играет именование. Так, прозрачность местоположения может быть достигнута путем присвоения ресурсам только логических имен, то есть таких имен, в которых не содержится закодированных сведений о местоположении ресурса. Примером такого имени может быть URL: http// wiv.prenhall.com/index.html, в котором не содержится никакой информации о реальном местоположении главного web-сервера издательства Prentice Hall. URL также не дает никакой информации о том. находился ли файл index.html в указанном месте постоянно или оказался там недавно. О распределенных системах, в которых смена местоположения ресурсов не влияет на доступ к ним, говорят как об обеспечивающих прозрачность переноса {migration transparency). Более серьезна ситуация, когда местоположение ресурсов может измениться в процессе их использования, причем пользователь или приложение ничего не заметят. В этом случае говорят, что система поддерживает прозрачность смены местоположения {relocation transparency). Примером могут служить мобильные пользователи, работающие с беспроводным переносным компьютером и не отключающиеся (даже временно) от сети при перемещении с места на место.
Как мы увидим, репликация имеет важное значение в распределенных системах. Так, ресурсы могут быть реплицированы для их лучшей доступности или повышения их производительности путем помещения копии неподалеку от того места, из которого к ней осуществляется доступ. Прозрачность репликации {replication transparency} позволяет скрыть тот факт, что существует несколько копий ресурса. Для скрытия факта репликации от пользователей необходимо, чтобы все реплики имели одно и то же имя. Соответственно, система, которая поддерживает прозрачность репликации, должна поддерживать и прозрачность местоположения, поскольку иначе невозможно будет обращаться к репликам без указания их истинного местоположения.
Мы часто упоминаем, что главная цель распределенных систем — обеспечить совместное использование ресурсов. Во многих случаях совместное использование ресурсов достигается посредством кооперации, например в случае коммуникаций. Однако существует множество примеров настоящего совместного использования ресурсов. Например, два независимых пользователя могут сохранять свои файлы на одном файловом сервере или работать с одной и той же таблицей в совместно используемой базе данных. Следует отметить, что в таких случаях ни один из пользователей не имеет никакого понятия о том, что тот же ресурс задействован другим пользователем. Это явление называется прозрачностью параллельного доступа {concurrency transparency}. Отметим, что подобный параллельный доступ к совместно используемому ресурсу сохраняет этот ресурс в непротиворечивом состоянии. Непротиворечивость может быть обеспечена механизмом блокировок, когда пользователи, каждый по очереди, получают исключительные права на запрашиваемый ресурс. Более изощренный вариант — использование транзакций, однако, механизм транзакций в распределенных системах труднореализуем.
Прозрачность отказов {failure transparency} означает, что пользователя никогда не уведомляют о том, что ресурс (о котором он мог никогда и не слышать) не в состоянии правильно работать и что система далее восстановилась после этого повреждения. Маскировка сбоев — это одна из сложнейших проблем в распределенных системах и столь же необходимая их часть. Основная трудность состоит в маскировке проблем, возникающих в связи с невозможностью отличить неработоспособные ресурсы от ресурсов с очень медленным доступом. Так, контактируя с перегруженным web-сервером, браузер выжидает положенное время, а затем сообщает о недоступности страницы. При этом пользователь не должен думать, что сервер и правда не работает. Последний тип прозрачности, который обычно ассоциируется с распределенными системами, — это прозрачность сохранности (persistence transparency), маскирующая реальную (диск) или виртуальную (оперативная память) сохранность ресурсов. Так, например, многие объектно-ориентированные базы данных предоставляют возможность непосредственного вызова методов для сохраненных объектов. За сценой в этот момент происходит следующее: сервер баз данных сначала копирует состояние объекта с диска в оперативную память, затем выполняет операцию и, наконец, записывает состояние на устройство длительного хранения. Пользователь, однако, остается в неведении о том, что сервер перемещает данные между оперативной памятью и диском. Сохранность играет важную роль в распределенных системах, однако не менее важна она и для обычных (не распределенных) систем.
Обоснование выбора математического аппарата и программы компьютерного моделирования
Мы строим математическую модель для того чтобы спрогнозировать поведение системы перед вводом ее в эксплуатацию. Необходимо понять какие максимальные нагрузки она способна выдержать. А так же определить наилучшее соотношение между кол-вом обрабатываемых запросов и средним временем обработки. [65]
В качестве математического аппарата было решено выбрать Сети Петри. Сеть Петри - это графическое и математическое средство моделирования систем и процессов. Обычно сетями Петри моделируют асинхронные параллельные системы и процессы. Вначале предложенные в докторской диссертации Карла Петри в 1962 году они получили дальнейшее развитие в работах таких ученых как Тадао Мурата, Курт Иенсен, Виталий Котов, Анатолий Слепцов [34], [35].
Области применения сетей Петри включают исследование телекоммуникационных сетей, сетевых протоколов, вычислительных систем и вычислительных процессов, производственных и организационных систем.
Достаточно представительным является набор реальных проектов, в которых использована моделирующая система для раскрашенных сетей Петри Design/CPN: проектирование интеллектуальных сетей Deutsche Telekom; проектирование системы управления сетью в RC International A/S; проектирование архитектуры новых мобильных телефонов Nokia; система электронных платежей в США; хранилище электронных документов Bull AG; система безопасности и контроля доступа Dalcotech A/S; европейская система управления движением поездов; планирование операций в военно-воздушных силах США; военно-морская командная система в Канаде. Элементами сети Петри являются позиция, переход, дуга и фишка, которые имеют следующее графическое представление:
Срабатывает произвольный переход из множества разрешенных. При срабатывании переход изымает фишку из своих входных позиций и размещает фишку в свои выходные позиции. Срабатывание перехода происходит мгновенно.
Из множества разрешенных срабатывает лишь один переход, выбираемый произвольно. Это характеризует недетерминированный характер поведения сети. Итак, сеть Петри описывает множество различных допустимых вариантов поведения моделируемых систем и процессов. Отметим также, что недетерминированность поведения может представлять как параллелизм, так и конфликты (альтернативы). Пример сети Петри изображен на рис.2.4.
Для моделирования реальных объектов бывает удобно использовать кратные дуги, для которых условие срабатывания должно выполняться по каждому экземпляру дуги. Графически, как правило, изображают одну дугу, надписывая над ней ее кратность:
Процесс функционирования сети Петри может быть наглядно представлен графом достижимых состояний. Состояние сети однозначно определяется ее маркировкой - распределением фишек по позициям. Вершинами графа являются допустимые маркировки сети Петри, дуги обозначены символом срабатывающего перехода. Дуга строится для каждого возбужденного перехода. Построение прекращается, когда мы получаем маркировку, в которой не возбужден ни один из переходов, или маркировку, которая уже содержится в графе. Отметим, что граф достижимых маркировок представляет собой автомат.
Для моделирования сетей Петри существует множество программ, например PN Editor, Tina, CPN Tools. Они предоставляют разные возможности для разных целей. Но для наших целей — создать временную модель раскрашенной сети Петри идеально подошла программа CPN Tools. CPN Tools - это специальная моделирующая система, которая использует язык сетей Петри для описания моделей. Система была разработана в Университете Орхуса в Дании и свободно распространяется для некоммерческих организаций через сайт http://www.daimi.au.dk/CPNTools/. Уровень предоставляемого сервиса позволяет классифицировать CPN Tools как промышленную моделирующую систему. Она была использована в большом количестве реальных проектов, особенно в области телекоммуникаций. В последнее время корпорация Nokia применяет CPN Tools для управления моделью разработки нового поколения мобильных телефонов.
Интерфейс программы показан на рис.2.8.
Механизм построения очереди инцидентов на обработку
Шаг 1: формирование запроса
Пользователь данной системы формирует запрос на своем компьютере и сам может выбрать степень важности своего обращения, обработчика и тип запроса, ну и конечно ввести сам текст запроса. Если он затрудняется выбрать, то по умолчанию система сама автоматически проставит все параметры рис. 2.
Степени важности:
0. автоматический выбор
1. обычная
2. средняя
3. высокая
4. чрезвычайно высокая
Обработчики
0. автоматический выбор
1. администратор
2. экспертная система
3. система обновлений
Для правильной обработки фиксируем время отправки, записываем в контейнер данные из формы, которую заполнил пользователь, а так же в отдельном поле индекс отправителя.
Отправляем запрос на сервер.
Шаг 2: регистрация запросов и синхронизация часов
Регистрация запросов на сервере работает периодично в течение 1 минуты, а далее передает данные на следующий шаг. Регистрация представляет собой формирование чуть измененных контейнеров данных, с проставлением времени отправки этих сообщений по часам сервера. Это необходимо, потому что позволяет все принятые запросы отсортировать по времени их отправки, причем это время исчисляется по одним и тем же часам -серверным [75].
Время отправки по серверным часам вычисляется по простой формуле:
Тотпр. по серв.часам = Трегистрации на сервере - Тв пути (3.1)
Тв пути = Т регистрации на сервере - Т клиентской отправки (3.2)
Далее формируем контейнер запроса, для передачи на следующий шаг, (табл. 3.2.).
Шаг 3: классификация запросов
Теперь классифицируем запросы по степени их важности, и по степени значимости отправителя.
Сервер имеет список всех клиентов подключенных к распределенной сети, каждый клиент имеет свой собственный индекс. Сервер хранит данный список клиентов в порядке их следования по степени значимости.
Этот список выглядит следующим образом
Шаг 4: выбор обработчика.
В нашей системе обработчик может быть явно указан пользователем, тогда запрос отправится именно к нему.
Еще помимо явного указания обработчика, мы ввели такое понятие как «Тип запроса», если пользователь выберет один из типов запроса, то выбор обработчика у системы не вызовет затруднений: Вопрос - обрабатывает экспертная система обновление ПО - обрабатывает система обновлений неполадки в работе ПО - обрабатывает автоматизированная система устранения неполадок ремонт/замена оборудования - обрабатывает администратор
Если в заявке явно указан обработчик и тип заявки указан, но они не соответствуют друг другу, как показано выше, то такие заявки считаются спорными и отправляются администратору.
Шаг 5: построение очереди запросов.
Выберем произвольно 10 запросов (табл. 3.7.)
Таким образом, внедрив автоматизированных обработчиков в систему поддержки пользователей, удается разгрузить администратора на 50%. Выстраивая очередь запросов, мы сможем максимально удовлетворить потребности пользователей распределенной системы. Ответы на запросы будут приходить своевременно, важные задачи будут решаться в первую очередь. Пользователи, которые имеют приоритет, к примеру руководство, чья работа наиболее важна для предприятия, будут обслужены раньше остальных.
Исследование временных характеристик
В качестве основных временных показателей, которые могут характеризовать метод можно выделить следующие:
- среднее время обработки запроса — обозначим X сек;
- кол-во обработанных запросов в единицу времени - обозначим N шт.
В нашем методе запросы проходят ряд стадий сортировки и классификации перед тем как попасть обработчику, все эти стадии занимают время и это время необходимо учесть при расчете характеристик. Сначала происходит буферизация (время буферизации Тбуф=60 сек), далее сортировка по важности (время сортировки по важности Тв=3 сек) далее сортировка по времени получения (время сортировки Тпол=3 сек) и наконец сортировка по идентификатору отправителя (время такой сортировки Тид=3 сек).
Внедрение системы
В схеме работы предприятия сразу видны места, которые нуждаются в автоматизации, наша система позволит сильно упростить работу такой компании. Во-первых, прием и регистрация заявок должна происходить в автоматическом режиме, это позволит не только облегчить работу администратору, но и предоставлять сервис круглосуточно и в выходные. Далее, внедрив систему поддержки пользователей, мы имеем инструмент автоматизированного консалтинга, который позволит давать консультации с минимальным вмешательством администратора, а если область консультирования достаточно узкая и по опыту работы видно, что вопросы достаточно стандартные, то администратора можно выключить из цепочки.
Нам предстоит внедрить форму приема заявок на обслуживание пользователей в данный корпоративный сайт. Для этого немного модифицируем разработанный в 4.1 интерфейс.
После оказания пользователю определенных услуг, администратор составляет список таких услуг и отправляет во внутреннюю систему для подсчета затрат компании. Происходит это следующим образом: специальная обработка выбирает из базы нашей системы следующую информацию: название компании, ИНН/КПП, юр.адрес, список выполненных работ. После чего формируем файл xml (код приведен в приложении 1), который передается в систему 1С Управление торговлей 8.1. Данный файл передаем в 1С на исполнение, после открытия данного файла автоматом будет создана запись со списком выполненных работ. [17]
Похожие диссертации на Автоматизация процессов обработки заявок в системах поддержки пользователей корпоративных информационных систем
