57
2.2.2. Характеристика нормативно-справочной, входной и оперативной
информации
В данном дипломном проекте используются входящие данные, такие как
заявка на почту от представителя банка, заявка от сотрудника М3 или
сотрудника банка по телефону. Автоматизированная генерация заявки в
программе М3 по факту обнаружения/появления ошибки на банкомате. Письмо
и информация о неисправности должна содержать понятный характер. Пример
почтового сообщения от сотрудника банка можно увидеть на рисунке 5 и
рисунке 6.
Рисунок 5
Рисунок 6
58
После поступления заявки на почту, диспетчеру необходимо создать и
обработать поступившую заявку и создать её в системе М3 вручную. Для
создания заявки, необходимо знать серийный номер банкомата и ФИО
заявителя. Обычно, заявитель указывается в роли отправителя электронного
письма. Пример создания заявки в системе М3 можно увидеть на рисунке 7. В
данном примере, сотрудник банка выявил ошибку картридера и отправил
электронное сообщение в мониторинг для последующего выезда инженера.
Рисунок 7
Инцидент возникает как следствие неисправности УС или элементов
инфраструктуры. Факт неисправности определяется одним из методов:
Метод 1. Автоматически на основании данных о сбое в работе УС
(получаемых Агентом М3, установленным на УС). Этот метод работает
при возникновении неисправности, которая была определена на
основании:
данных, полученных из протокола обмена УС и Хоста;
59
данных, полученных от ПО управления функционированием УС;
Метод 2. По получении информации из альтернативных источников:
сообщения клиентов и сотрудников с мест установки УС, отключения УС
от системы технического мониторинга, уведомления о предстоящих
работах на месте установки УС или на объектах инфраструктуры от
третьих (кроме Заказчика Услуги или Поставщика Услуги) сторон.
Определение плана шагов по восстановлению работоспособности УС после
инцидента происходит на основании атрибутов неисправности:
Источника неисправности – аппаратного или программного модуля,
элемента инфраструктуры передачи данных или места установки УС;
Характера неисправности – т.е. технический сбой, окончание
возобновляемого ресурса, организационно-технические планы,
нарушающие процесс функционирования УС.
План шагов по восстановлению работоспособности УС определяется системой
М3 автоматически в привязке к неисправности, ее характеру и конкретному
УС. Типовые планы описаны на сервере М3. При необходимости планы могут
быть скорректированы или добавлены новые. План представляет собой
последовательность действий, характеризуемых следующими атрибутами:
Действие – характеризует суть работ, которые необходимо выполнить
Подрядчику по заданию Заказчика;
Заказчик – организация-участник процесса, заинтересованная в
выполнении Действия Подрядчиком;
Подрядчик – организация-участник, ответственная за выполнение
Действия, заказанного Заказчиком;
Продолжительность Действия – плановая продолжительность Действия,
определяемая Регламентом оказания Услуги. В отличие от других
атрибутов шага плана, может изменяться в ходе выполнения действия,
например, при изменении.
60
Характер неисправности определяет подрядчика, который будет
выполнять основные работы по восстановлению после инцидента, а также
квалификацию непосредственного исполнителя.
61
2.2.3. Характеристика результатной информации
В данном дипломном проекте, результирующей информацией будет
являться отчёт по выполненным заявкам по связи. Пример запроса такого
отчёта можно увидеть на рисунке 8.
Рисунок 8
Готовый отчёт генерируется системой и сохраняется в М3 для последующей
выгрузки на компьютер. Отчёт хранится бессрочно на сервере, и может быть
62
удалён принудительно арбитром или контролером. Отчёт содержит в себе
следующие поля:
Дата создания заявки
Заявитель
ID банкомата
Источник неисправности
Описание неисправности
Адрес расположения УС
Исполнитель
Статус заявки
Дополнительная информация
Данные формируются и отбираются из базы с заявками. Пример такого
отчёта показан на рисунке 9.
Рисунок 9
63
2.3. Программное обеспечение задачи
2.3.1. Общие положения (дерево функций и сценарий диалога)
В данном дипломном проекте рассмотрена информационная система
Octopus. Взаимодействие системы М3 с филиалами, диспетчерской и
сервисным предприятием показано на рисунке 10.
Рисунок 10
64
2.3.2. Характеристика базы данных
Базу данных можно представить в виде, который отображен в таблице
18.
Таблица 18
registered_request
ID address
ID history
ID classification
ID
ID_address
ID_history
ID_classification
data_create
city
incident
keyPhrases
req_create
address
data
ID_group
req_title
point
information
inzhener
req_body
info
serviceCent
ID_address
ID group
ID_group
name_group
attributes
incident_id
ID_history
ID_classification
Между ними изображены возможные связи, согласно ключевым полям.
У данных таблиц есть и вторичные ключи, и индексируемые поля для поиска.
Таблица «registered_request», что означает созданную заявку в системе
М3. В таблице 19 обозначены поля:
Таблица 19
Поле
Тип данных
Длина
ID
Целое число
(ключевое поле)
12
Data_create
Дата
10
Req_create
Дата
10
Req_title
Строка
50
Req_body
Строка
250
ID_address
Целое число
5
ID_history
Целое число
5
ID_classification
Целое число
5
65
Таблица «ID_address», имеет следующие поля – таблица 20:
Таблица 20
Поле
Тип данных
Длина
ID_address
Целое число
(ключевое поле)
12
City
Строка
10
Address
Строка
250
Point
Строка
20
Info
Строка
50
Следующая таблица называется «ID_history». В ней содержатся поля для
отображения истории по инцидентам (заявкам). Вся информация о полях
представлена в таблице 21.
Таблица 21
Поле
Тип данных
Длина
ID_history
Целое число
(ключевое поле)
12
Incident
Логическая
12
Data
Строка
10
Information
Строка
50
Таблица «ID classification» носит в себе набор ключевых слов.
Информация отображена в таблице 22.
Таблица 22
Поле
Тип данных
Длина
ID_classification
Целое число
(ключевое поле)
12
KeyPhrases
Строка
12
ID_group
Целое число
12
Inzhener
Строка
50
ServiceCent
Строка
250
66
2.3.3. Структурная схема пакета (дерево вызова процедур и программ)
Основной программный продукт М3 ATM Monitoring System работает с
создаваемыми заявками через клиента М3 на УС. В таблице 23 приведена схема
с основными модулями и их функционалом и описанием.
Таблица 23
№
Наименование модуля
Описание/функционал модуля
1
Форма «первичное
принятие заявки»
Содержит в себе переменные ошибок,
описание неисправности.
2
Форма «авторизация»
Данная форма содержит в себе запрос логина и
пароля для входа в интерфейс программы М3.
3
Форма «о программе»
Форма содержит в себе информацию о
созданной программе.
4
Форма «банкоматы»
Данная форма содержит в себе список всех
подключенных банкоматов к системе М3.
5
Форма «инцидеты»
Форма инцидентов содержит в себе список
всех инцидентов, расположенных в порядке их
появления по дате.
6
Форма «отчёт»
Данная форма содержит в себе интерфейс
создания отчёта по заданным критериям.
В документе есть разделы, предназначенные для ознакомления всеми
операторами, а также относящимися только для операторов, исполняющих
определенные роли.
Элементы консоли. Общий раздел. Приведено описание общего вида
консоли М3 и элементов управления планом восстановления после
инцидента.
Обобщенные этапы реализации плана устранения причин
инцидента. Общий раздел. Приведено описание регламента с участием
всех операторов в контексте взаимодействия участников процесса.
Регламент Арбитра Диспетчерской. Приведено описание регламента
только для Арбитра Диспетчерской.
Регламент Диспетчера. Приведено описание регламента только для
сотрудников Диспетчерской.
Регламент 2-й линии поддержки. Приведено описание регламента
только для сотрудников 2-й линии поддержки Диспетчерской.