Разработка подсистемы управления проблемами распределенной системы управления телекоммуникационными услугами на базе платформы CPN TOOLS для Ставропольского филиала ОАО "ЮТК"
Дипломная работа - Компьютеры, программирование
Другие дипломы по предмету Компьютеры, программирование
равление поставщиками.
-процессы разрешения (Resolution processes) - разработчики стандарта фокусируются на инцидентах, которые удалось предотвратить или успешно разрешить - управление проблемами, управление инцидентами.
-процессы контроля (Control processes) - в данном разделе рассматриваются процессы управления изменениями и конфигурациями.
-процессы управления релизами (Release process) - речь идёт о выработке новых и коррекции уже имеющихся решений.
ГОСТ Р ИСО/МЭК 20000-1 основан на международном стандарте ISO 20000 [2]. Этот стандарт способствует принятию в повседневной практике поставщика комплексного процессного подхода к эффективному предоставлению управляемых услуг, соответствующих требованиям бизнеса и заказчика. Для эффективной работы организации необходимо определить и управлять многочисленными взаимосвязанными видами деятельности. Деятельность, использующая ресурсы и управляемая iелью предоставления возможности преобразования входов в выходы, может рассматриваться как процесс. Часто выход одного процесса формирует вход для другого процесса.
3.3 Проектирование функциональной структуры подсистемы
.3.1 Построение дерева функционирования системы
На рисунке 3.1 представлено дерево функционирования подсистемы. Указаны главная цель и подцели.
Рисунок 3.1 - Дерево целей подсистемы
Главной целью создания подсистемы является повышение эффективности процесса управления проблемами. Для достижения этой цели необходима возможность поиска решения среди аналогичных и уже известных проблем, а значит необходима централизованная база данных проблем. Важной составляющей эффективности любого процесса является его быстродействие. Для увеличения быстродействия необходимо снизить количество обрабатываемой в ручную информации, а также уменьшение времени, необходимого на передачу информации о проблеме на другие уровни. Также для повышения эффективности управления проблемами необходимо прогнозировать будущие проблемы, для этого требуется возможность составления отчётов.
3.3.2 Построение функциональной структуры подсистемы
На рисунке 3.2 представлена функциональная диаграмма подсистемы, созданная на основе дерева целей.
Рисунок 3.2 - Функциональная диаграмма подсистемы
Подсистему управления проблемами можно разбить на несколько частей:
-обработка новой проблемы - реализует поиск решения среди уже известных и решённых проблем, а также сохраняет результаты своей работы в базу данных проблем;
-эскалация нерешённых проблем - увеличивает приоритет и передаёт информацию о проблеме на следующий уровень;
-формирования отчётов - реализует генерацию отчётов, в соответствии с заданными параметрами.
3.4 Разработка алгоритма работы подсистемы
Алгоритм работы автоматизированной подсистемы управления проблемами представлен на рисунке 3.3.
Рисунок 3.3 - Алгоритм работы подсистемы управления проблемами
На вход системы поступают запросы, которые могут генерировать пользователи и автоматические устройства диагностики. Запросы могут быть трёх типов: запрос на создание отчёта, добавление решённой проблемы, добавление не решённой проблемы. В случае, если решение проблемы не было найдено в базе данных, то производится увеличение приоритета проблемы и передача её на следующий уровень. Всего существует три уровня. Первый уровень представлен Центром обработки сообщений и Участком диагностики и ремонта. Второй уровень - Группа технической поддержки. Третий уровень - Линейно-технический участок.
3.5 Разработка модели в среде CPN Tools
Алгоритм работы подсистемы управления проблемами реализован в программе CPN Tools. Рассмотрим реализацию подробнее.
Начальными позициями являются Client и Devices (рисунки 3.4 и 3.5, соответственно), в этих позициях находятся метки, описывающие проблемы в момент их возникновения. Класiветов этих меток объявлен как p.
Рисунок 3.4 - Позиция Client
Рисунок 3.5 - Позиция Devices
Из позиции Client проблема поступает в переход Set priorety (рисунок 3.6), в котором происходит присвоение проблеме приоритета, в зависимости от её типа. Затем формируется запрос, принадлежащий классу цветов r.
Код перехода Set priorety:
input (pp);(rq);
(case #3 pp of
obryv lini => (roblem, mas, password, (#1 pp, #2 pp,#3 pp, 3, #5 pp, 1,,#8 pp, #9 pp))
|zapros spravochnoi informacii => (problem,mas,password,(#1 pp,#2 pp,#3 pp,1,#5 pp,1,,#8 pp,#9 pp))
|otsutstvuet dostup v internet => (problem,mas,password,(#1 pp,#2 pp,#3 pp,2,#5 pp,1,,#8 pp,#9 pp)));
Рисунок 3.6 - Переход Set priorety
Затем запрос поступает в метку Users PC, откуда передаётся в переход Identification Autotentification, связанный с позицией Users DB, которая является базой данных пользователей и хранит метки класса u (рисунок 3.7).
Переход Identification Autotentification выполняется только при правильном имени пользователя и пароле: [#2 rq = #1 uu andalso #3 rq = #2 uu].
Рисунок 3.7 - Переход Identification Autotentification
Затем запрос поступает в позицию Request, а оттуда, в зависимости от типа, поступает в один из трёх переходов: Request for solve ([#1 rq = solve]), Request for report ([#1 rq = report]), Request for problem ([#1 rq = problem]) (рисунок 3.8).
В переходах Request for solve и Request for problem из запроса извлекается проблема следующим образом:
input (rq);(pp);
(#4 rq);
Рисунок 3.8 - Разделение запросов по типу
В