УДК 004

ОБОСНОВАНИЕ ПРОЕКТНЫХ РЕШЕНИЙ ПО ВНЕДРЕНИЮ СИСТЕМЫ МОНИТОРИНГА ИНЦИДЕНТОВ МУЛЬТИСЕРВИСНОЙ СЕТИ

Виноградова Анастасия Сергеевна1, Новикова Татьяна Борисовна1
1Магнитогорский Государственный Технический Университет им. Г.И. Носова

Аннотация
Детально рассматривается система мониторинга инцидентов мультисервисной сети. Описаны общие требования выдвигаемые к системе, а так же прописано положение об образе проекта.

Ключевые слова: мониторинга инцидентов, мультисервисная сеть, система мониторинга инцидентов мультисервисной сети


THE RATIONALE FOR DESIGN DECISIONS TO IMPLEMENT THE SYSTEM OF MONITORING OF INCIDENTS OF A MULTISERVICE NETWORK

Vinogradova Anastasia Sergeevna1, Novikova Tatyana Borisovna1
1Magnitogorsk State Technical University of G.I. Nosov

Abstract
Considers in detail the system of monitoring of incidents of a multiservice network. Describes the General requirements made to the system, but in the same prescribed position on the image of the project.

Библиографическая ссылка на статью:
Виноградова А.С., Новикова Т.Б. Обоснование проектных решений по внедрению системы мониторинга инцидентов мультисервисной сети // Современная техника и технологии. 2016. № 11. Ч. 2 [Электронный ресурс]. URL: http://technology.snauka.ru/2016/11/11453 (дата обращения: 28.05.2017).

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

Общие требования к системе

С учетом анализа узких мест и уточнений бизнес – целей предметной области, можно сформулировать бизнес – требования к системе.

Бизнес – требования.

Исходные данные, возможности бизнеса и нужды клиента:

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

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

Ежедневно сотрудника ремонтного отдела эксплуатации сети оповещает о текущих заявках сотрудник технической поддержки, в заявке содержится информация о начальном участке линии, на которой находится неисправность. Сотрудник отдела эксплуатации сети собирает сведения о поступивших заявках [1, 2, 3]. По карте монтажник смотрит местонахождение неполадки и прокладывает себе маршрут возможных проблемных мест на линии. После ремонта оборудования, сотрудник возвращается в офис и сообщает сотруднику технической поддержки об устранении неисправности, что влечет за собой закрытие заявок.

Каждый сотрудник отдела эксплуатации сети выбирает заявки по приоритету обслуживания, вследствие чего менее приоритетные заявки могут быть закрыты только после заявок с большим приоритетом. Вследствие этого может возникнуть ситуация, что заявки с меньшим приоритетом могут оставаться открытыми более чем 24 часа.

Одним из недостатков, существующих на предприятии, является долгая обработка заявок, многие заявки могут “висеть” необработанными в течение суток, а иногда и более. Это связано, прежде всего, с нехваткой высококвалифицированного персонала. К тому же кадровый состав постоянно меняется, что приводит к потере времени на обучение новых сотрудников. На предприятии наблюдается низкая возможность карьерного роста, что приводит к уходу высококвалифицированных сотрудников в другие организации.

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

Бизнес – цели и критерии успеха.

Бизнес – цель 1. Уменьшить среднее время на обработку одной заявки до 15 минут в течение 4 недель после первого выпуска информационной системы.

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

Факторы бизнес – риска.

Фактор бизнес – риска 1. Не все сотрудники организации готовы к работе с новой ИС. Потребуются финансовые и временные ресурсы на обучение персонала. Вероятность = 0,3.

Образ решения.

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

Основные функции.

Основные функции 1. Создание нового объекта (узла).

Основные функции 2. Удаление объекта.

Основные функции 3. Редактирование данных об узле: добавление, изменение, удаление.

Основные функции 4. Отображение сигналов о неполадках в работе оборудования.

Основные функции 5. Обеспечение доступа к системе через корпоративную сеть Интранет.

Предположения и зависимости.

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

Предположения и зависимости 2. Имеется сервер, на котором будет установлено необходимое программное обеспечение.

Масштабы и ограничения проекта.

Ограничения и исключения.

Ограничения и исключения 1. Информационная система будет применяться только для компании.

Требования пользователей.

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

Для каждого пользователя перечислим варианты использования (см. таблицу 3).

Таблица 3 – Варианты использования.

Действующее лицо (актер) Вариант использования (прецедент)
Сотрудник отдела администрирования и безопасности сети Просмотр зависимостей узлов на линии мультисервисной сети.

Просмотр состояния узлов, через которые подключен клиент.

Своевременное оповещение клиентов об аварийно-восстановительных работах.

Добавление новых объектов.

Редактирование данных.

Сотрудник отдела эксплуатации сети Просмотр зависимостей узлов на линии мультисервисной сети.

Проведение аварийно-восстановительных работ с пометками в ИС.

Отключение неиспользуемых объектов.

Формирование ТЗ на внедрение системы мониторинга инцидентов мультисервисной сети

1. Введение

1.1. Назначение. Этот документ описывает функциональные и нефункциональные требования к выпуску единой АИС версии 1.0 «Система по мониторингу состояния мультисервисной» г. Магнитогорска» (далее «Мониторинг») [4, 5, 6].

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

2. Общее описание

2.1. Общий взгляд на продукт. «Мониторинг» – это новая система, которая заменит текущие процессы мониторинга за состоянием мультисервисной сети и сократит время обработки заявок пользователей.

2.2. Классы и характеристики пользователей

Таблица 4 – Классы пользователей.

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

2.3. Операционная среда

Операционная среда – 1. «Мониторинг» работает на основе АИС «Zabbix».

Операционная среда – 2. Система взаимодействует с клиентской базой данных MySQL [10].

Операционная среда – 3. Система будет установлена на сервере, работающем под управлением текущих утвержденных корпорацией версий FreeBSD и Apache HTTP Server.

Операционная среда – 4. АИС должна осуществлять доступ зарегистрированных пользователей через локальную сеть.

2.4. Ограничения дизайна и реализации

Ограничения дизайна и реализации – 1. Документация системы по конструкции, коду и сопровождению должна соответствовать стандарту

Ограничения дизайна и реализации – 2. Система должна использовать текущую версию корпоративного стандарта процессора базы данных MySQL [7, 8, 9].

2.5. Документация для пользователей

Документация для пользователей – 1. Система должна предоставлять иерархическую и связанную систему справки, описывающую и иллюстрирующую все функции системы.

2.6. Предположения и зависимости

Предположения и зависимости – 1. Доступ к системе открыт для пользователей ежедневно, включая выходные и праздничные дни.

3. Функции системы

3.1. Описание и приоритет.

1)                              Просмотр данных, хранящихся в БД. Приоритет – средний.

2)                              Редактирование данных (изменение, добавление, удаление). Приоритет – высокий.

3)                              Поиск данных по шаблону. Приоритет – средний.

4)                              Внутренний контроль данных (отслеживание). Приоритет – высокий.

5)                              Создание объекта (оборудование). Приоритет – высокий.

6)                              Удаление объекта. Приоритет – высокий.

7)                              Изменение стиля объекта (отображение состояния). Приоритет – высокий.

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

4.1. Интерфейсы пользователя

Интерфейс пользователя – 1. Система, по запросу пользователя, должна предоставлять справку, объясняющую, как пользоваться той или иной функцией системы.

Интерфейс пользователя – 2. Приложение должно обеспечивать возможность интуитивно доступной навигации по нему.

4.2. Интерфейсы оборудования

Интерфейсы оборудования не выявлены.

4.3. Программные интерфейсы

Используется универсальный механизм доступа к данным ActiveX.

5. Другие нефункциональные требования

5.1. Требования к производительности

Требования к производительности – 1. Загрузка ответов на запросы на экран должна занимать не более 10 секунд с момента запроса.

Требования к производительности – 2. Система должна поддерживать возможность внесения новых данных.

5.2. Требования к охране труда

Требования к охране труда – 1. Определены внутрикорпоративным стандартом на этот вид деятельности.

Требования к охране труда – 2. Определены санитарно-гигиеническими нормами работы с вычислительной техникой и коммуникационным оборудованием.

5.3. Требования к безопасности

Требования к безопасности – 1. Все сетевые транзакции, включающие финансовую или поддающуюся учету личную информацию, должны быть зашифрованы 128-битным шифрованием.

Требования к безопасности – 2. Каждый пользователь должен проходить процесс аутентификации при входе в систему.

5.4. Атрибуты качества

Доступность – 1. Система должна быть доступна сотрудникам компании по локальной сети круглосуточно.

Надежность – 1. Если работа системы прерывается во время внесения новых данных, система должна позволять пользователю восстановить внесённые изменения, за счёт резервного копирования внесённых изменений.


Библиографический список
  1. Белоусова И.Д., Курзаева Л.В., Лактионова Ю.С., Агдавлетова А.М. Онтологическая модель управления требованиями в процессе профессиональной подготовки ИТ-специалистов // Успехи современной науки. -2016. – Т. 1. – № 3. – С. 98-100.
  2. Давлеткиреева Л.З. Применение методологии управления непрерывностью бизнеса при разработке ИТ-стратегии организации//Современные проблемы науки и образования. -2012. -№ 5; URL: http://www.science-education.ru/105-7307.
  3. Давлеткиреева Л.З. Проблемы применения принципов управления непрерывностью бизнеса для предоставления дистанционных образовательных услуг//Инновационные информационные технологии: материалы Междунар. науч.-практ. конф. (Прага, 23-27 апреля 2012 г.)/под ред. С.У. Увайсова; отв. за вып. И.А. Иванов [и др.]. -М.: МИЭМ, 2012. -С. 527-529.
  4. Давлеткиреева Л.З., Скокова И.К. Актуальность проведения заочных конференций посредством применения веб-технологий для удаленной активизации научной деятельности/Актуальные проблемы развития вертикальной интеграции системы образования, науки и бизнеса: экономические, правовые и социальные аспекты: материалы II Международной научно-практической конференции 23-24 октября 2014г. -Т. 4/под ред. С.Л. Иголкина. -Воронеж: ВЦНТИ, 2014 -250 с. -С. 180-183.
  5. Курзаева Л.В. Совершенствование методов идентификации требований к результатам профессионального обучения на основе экспертной информации // Информатизация образования и науки. – 2015. – № 4 (28). – С. 167-175.
  6. Курзаева Л.В., Овчинникова И.Г., Чичиланова С.А. К вопросу о совершенствовании методики оценки эффективности решения задач управления качеством образования на основе экспертной информации // Фундаментальные исследования. – 2015. – № 6-3. – С. 473-478.
  7. Мавлянов Т.Б., Курзаева Л.В. Поддержка методов принятия управленческих решений с использованием “Mpriority 1.0″ // Коммуникативные и образовательные возможности современных технологий : сборник материалов и докладов IV всероссийской научно-практической конференции. Общество с ограниченной ответственностью “Информационно-образовательный центр Инфометод”. 2016. С. 82-86.
  8. Соколова А.А., Кириллов Д.В., Курзаева Л.В. Cовершенствование методов обработки информации для задач управления образовательным процессом на основе инженерии знаний // Коммуникативные и образовательные возможности современных технологий : сборник материалов и докладов IV всероссийской научно-практической конференции. Общество с ограниченной ответственностью “Информационно-образовательный центр Инфометод”. 2016. С. 154-161.
  9. Чернова Е.В., Давлеткиреева Л.З., Ошурков В.А., Правовое регулирование процесса распространения явлений киберэкстремизма в современном Интернете // Информационная безопасность и вопросы профилактики киберэкстремизма среди молодежи (сборник статей)/под ред. Г.Н. Чусавитиной, Е.В. Черновой., МГТУ, Магнитогорск, 2014, 185 -188-Русский
  10. Швалев И.С., Чусавитина Г.Н., Давлеткиреева Л.З. Сравнительная характеристика автоматизированных инструментальных средств управления информационными рисками // Современные научные исследования и инновации // [Электронный ресурс]. 2012. URL: http://web.snauka.ru/issues/2012/11/18524. 23. Пиший С.А., Давлеткиреева Л.З., Назарова О.Б. Общее описание систем интернет-банкинга//Современная техника и технологии. 2013. № 10 (26). С. 10.


Все статьи автора «Виноградова Анастасия Сергеевна»


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

Связь с автором (комментарии/рецензии к статье)

Оставить комментарий

Вы должны авторизоваться, чтобы оставить комментарий.

Если Вы еще не зарегистрированы на сайте, то Вам необходимо зарегистрироваться: