Главная Коллекция "Revolution" Программирование, компьютеры и кибернетика Разработка инструментария контроля функционирования информационно-аналитической системы мониторинга комплексного развития городской среды

Разработка инструментария контроля функционирования информационно-аналитической системы мониторинга комплексного развития городской среды

Анализ информационно-аналитической системы комплексного развития городской среды. Решение проблемы мониторинга эффективности подсистем ИАС МКР. Список метрик для анализа нагрузки подсистем. Разработка проекта системы логирования, тестирования и отладки.

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 01.12.2019
Размер файла 4,8 M
рефераты на заказ со скидкой

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Страница:

· последний запуск метода сервиса (дата);

· наименование последнего запускаемого метода;

· общий показатель работоспособности сервиса в данной подсистеме.

В функционале вкладки сервисов необходимо реализовать разделение сервисов на группы. Это позволит разделять сервисы на те, от которых ИАС МКР получает данные и те, которым ИАС МКР данные поставляет. Также пользователи смогут реализовать свои, удобные именно для них, наборы групп, повышая удобство используемой подсистемы для пользователей. Группы должны быть доступны для редактирования, удаления и создания (рисунок 2.9).

Рисунок 2.9 Макет настройки группы сервисов отдельной подсистемы

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

Диаграмма, отражающая работоспособность сервиса, должна отображать сервис и результат его отработки. Таким образом, по вертикали необходимо отображать наименование метода, а по вертикали - даты. Даты должны быть доступны для выбора в календаре, чтобы была возможность просмотреть историю. Результат отработки должен быть отображен в виде элемента с соответствующей цветовой раскраской (см. рисунок 2.10).

Рисунок 2.10 Макет отображения работоспособности интеграции в виде диаграммы

Цветовая индикация в диаграмме должна соответствовать легенде, описанной в таблице ниже (таблица 2.3).

Таблица 2.3

Цветовая индикация отработанных методов сервиса

Результат

Цвет

Не запускалось

Серый

В процессе (Запущено)

Синий

Ошибка

Красный

Исправлено

Желтый

Успешно

Зеленый

Диаграмма должна быть доступна для фильтрации по методам и результатам их вызова. Фильтр необходимо реализовать в виде элемента combobox с множественным выбором. При фильтрации диаграмма меняется в соответствии с выбранными полями.

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

· ID сессии - необходимо для быстрого поиска разработчикам и устранения неполадки в случае не выполнения;

· название метода;

· дата старта (время, дата);

· дата окончания (время, дата);

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

При нажатии на наименование метода вертикальной оси диаграммы таблица должна фильтроваться, отображая список вызовов выбранного метода за установленный период времени в календаре (см. рисунок 2.11).

Для просмотра всех методов интеграции в выбранной сессии необходимо реализовать поиск по ID сессии. Это необходимо, если метод был не успешно запущен в определенную сессию, и необходимо узнать, успешно ли были вызваны другие методы выбранной сессии.

Рисунок 2.11 Макет таблицы детализации работоспособности интеграции

Для того, чтобы участнику группы разработки не нужно было просматривать данные сессии в СУБД, при нажатии на наименовании сессии необходимо реализовать отображение всех её вызванных методов с данными (рисунок 2.12):

· наименование метода сессии;

· время запуска метода;

· результат отработки метода текущей сессии.

Рисунок 2.12 Макет отображения детализации сессии со списком методов

В детализации сессии нет необходимости строить график, однако необходимо реализовать поиск методов в сессии.

Для быстрого составления отчетов необходимо реализовать экспорт данных в табличный формат xlsx и текстовый docx. Такая возможность позволит собирать данные по нескольким сервисам одной подсистемы, либо по одному сервису нескольких подсистем для дальнейшего изучения.

Расчет кубов подсистемы

Вкладка «Расчет кубов» визуально должна быть аналогична вкладке «Сервисы». Необходимо более детально ознакомиться с понятием многомерных данных.

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

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

Приведем пример построения куба ИАС МКР в подсистеме Мониторинга уровня оплаты труда (рисунок 2.13). В качестве источников рассматриваются учреждения из системного справочника учреждений, а также категории работников. Категории работников так же получены из системного справочника, который обновляется после каждого издания приказа правительства на обновление статистической формы сбора данных о заработной плате. В данном кубе рассчитывается число каждой категории работников каждого учреждения с дополнительным измерением временной шкалы (месяц) [11].

Рисунок 2.13 Куб подсистемы мониторинга уровня оплаты труда, отображающий данные о численности работников определенной категории

Многомерная БД ИАС МКР реализована в качестве системы многомерной оперативной аналитической обработки (MOLAP). Ее особенностью является то, что она хранит данные в многомерных структурах. Системы MOLAP, как правило, содержат средства для обработки разреженных массивов и применяет хеширование для поиска данных при выполнении запросов.

Кубы в системе ИАС МКР собираются ранним утром раз в сутки. Обозначено именно это время ввиду того, что в основном каждая подсистема предназначена для сбора данных, а сбор происходит для пользователей в дневное время. Таким образом, в кубы попадают «свежие» данные и предоставляются пользователям пересчитанные значения.

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

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

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

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

При переходе на вкладку «Расчет кубов» необходимо отображать диаграмму, отображающую анализ отработанных методов и сопутствующую диаграмме таблицу. Диаграмма должна быть реализована аналогично вкладке «Сервисы». По горизонтальной оси должны располагаться дни выбранного периода, а по вертикали - наименования методов (рисунок 2.14). Цветовая индикация должна соответствовать легенде (см. таблица 2.3).

Рисунок 2.14 Макет диаграммы, отображающей аналитику рассчитанных кубов

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

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

· дата сессии;

· название метода;

· дата старта;

· дата окончания;

· статус выполнения.

Рисунок 2.15 Макет таблицы, отображающей детализацию сбора кубов

Диаграмма и таблица должны быть доступны для фильтрации по методам и результатам их вызова. Фильтр необходимо реализовать в виде элемента combobox с множественным выбором. При фильтрации диаграмма и таблица меняются в соответствии с выбранными полями.

Для поиска сессии в аналитическом отчете необходимо реализовать соответствующий поиск. Реализовать нужно через элемент textbox. При вводе каждого элемента в textbox должен автоматически проходить поиск по значению, введенному значению. Значение должно содержаться в уникальном идентификаторе сессии.

При нажатии на уникальный идентификатор сессии необходимо реализовать «проваливание». Должна открываться детализация с данными:

· название метода;

· время запуска;

· результат.

В качестве результата должно быть взято значение из внутрисистемного справочника (см. таблица 2.3). Любая из таблиц подсистемы должна быть доступна для выгрузки (экспорта данных) в форматах xlsx, docx.

2.7 Требования к разработке мониторинга ИАС МКР

Подсистема «Мониторинг систем ИАС МКР» должна быть разработана в соответствии с принятыми технологиям разработки для всей системы. Иначе говоря, необходимо подстраиваться под текущие технологии ИАС МКР.

В разработке распределенной системы мониторинга ИАС МКР применены веб-технологии. Система, главным образом, основана на технологиях Ajax, php [13].

База данных должна быть реализована в СУБД Oracle. Схема БД должна соответствовать концептуальной и логической схемам. Однако по факту схемы могут быть изменены разработчиками в зависимости от наличия специфических параметров и методов определенной подсистемы.

Макеты с шага прототипирования должны быть актуализированы дизайнером ИАС МКР. Подсистема должна быть разработана на основе принятых стандартов.

Выводы по главе

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

информационный аналитический мониторинг городской среда

Глава 3. Разработка подсистемы мониторинга ИАС МКР

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

3.1 Методика разработки подсистемы мониторинга здоровья

Компанией PRO IT используется RAD-модель. Эта модель является разновидностью инкрементной модели, в ней компоненты и функции разрабатываются несколькими командами параллельно, как несколько проектов, в данном случае подсистем. Временные рамки каждого цикла разработки жестко ограничены рамками государственного контракта. Созданные подсистемы интегрированы в один рабочий прототип - систему ИАС МКР. Именно эти части системы необходимо объединить в разрабатываемой подсистеме мониторинга здоровья с целью постоянного отслеживания их работоспособности.

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

При разработке концепции подсистемы мониторинга ИАС МКР было выделено три основных объекта:

1. Объект мониторинга - система ИАС МКР, представляющая интерес задаче мониторинга. Объект задается динамическими параметрами, характеризующими состояние системы разными контрольными точками (датчиками).

2. Ядро подсистемы (сервер) - программная часть системы, обеспечивающая хранение информации мониторинга и взаимодействие их объектов.

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

Ввиду того, что объект мониторинга - сама система ИАС МКР, то разработка началась с установки и сбора показателей подсистем. Показатели были разделены на три типа:

· показатели эффективности, собранные с Яндекс Метрики;

· показатели отработки методов интеграций;

· показатели отработки методов расчетов кубов.

В данном пункте главы рассмотрена аналитика отработки методов интеграций и построения OLAP-кубов.

1. Показатели отработки методов интеграций

Интеграции ИАС МКР задокументированы и сопровождаются схемами информационного взаимодействия. В схемах прописано наименование каждого передаваемого параметра и функции взаимодействий. Так, для того чтобы определить, относится метод к интеграциям или расчетам кубов, в схемах логирования были созданы метки для вызываемых методов. Метка является «флагом», то есть логической переменной со значениями: 0 - если метод работает для осуществления взаимодействий и 1 - если метод относится к внутренним операциям, расчетам.

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

· «Не запускалось»;

· «Исправлено»;

· «В процессе»;

· «Успешно»;

· «Ошибка»;

· «Прервано»;

· «Выполнено с предупреждением».

Статусная модель вызываемых методов отображена на рисунке ниже (см. рисунок 3.1). При прохождении метода одного из перечисленных состояний, соответствующий статус логируется и отображается в БД. У каждого не запущенного метода по умолчанию за минуту до вызова присваивается статус «Не запускалось». При запуске метода происходят прохождения контрольных точек. Результатом прохождения первой контрольной точки является присвоение методу статуса «В процессе». Это означает, что метод был вызван первый раз и не завершен. Методы делятся на группы в соответствии с типом интеграции:

· методы, от которых ИАС МКР только получаем данные;

· методы, с которыми происходит взаимодействие в обе стороны;

· методы, в которых ИАС МКР только отправляет данные.

По окончании отработки метода формируется xml-файл. Для дальнейшего определения статуса метода проверяется, сформирован ли xml-файл. Если он сформирован, то считается, что метод отработан успешно и методу присваивается статус «Успешно» для отображения в интерфейсе подсистемы мониторинга ИАС МКР. Если файл не сформирован, но метод не сработал, ему присваивается статус «Прервано» и происходит повторный вызов метода.

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

Метод для нахождения ошибок в xml строится на проверке данных по соответствующим требованиям. Например, в xml может содержаться информация об ОКВЭД учреждения. Тогда для проверки ИНН применяется правило: «Состоит из цифр, не отрицательное, длина 10 или 12 символов»

Рисунок 3.1 Статусная модель методов интеграций

Для отображения в отчете интерфейса подсистемы мониторинга собран список атрибутов методов, перечисленных в таблице ниже (см. таблица 3.1).

Таблица 3.1

Атрибутивный состав отработки методов интеграций ИАС МКР

Наименование атрибута

Тип данных

Значение по умолчанию

Принимаемые значения

Наименование

Текстовый

-

-

Статус выполнения

Текстовый

Не запущено

Не запускалось, Исправлено, Ошибка, В процессе, Успешно, Прервано, Выполнено с предупреждениями

Дата начала последнего запуска

Дата, время

-

Любая дата и время, ранее «Даты конца последнего запуска»

Дата конца последнего запуска

Дата, время

-

Любая дата и время после «Дата начала последнего запуска»

ID сессии

Текстовый

-

-

Дата начала следующего запуска

Дата, время

-

Любая дата и время с сегодняшнего дня и позже

Планируемая дата окончания следующего запуска

Дата, время

-

Любая дата и время с сегодняшнего дня и далее, которая позже «Даты начала следующего запуска»

Наличие xml

Логический

Нет

Да / Нет

В соответствии со статусной моделью отработки методов интеграций, данные собираются в единый отчет подсистемы мониторинга ИАС МКР - «Отчет о сервисах».

2. Показатели отработки методов расчета кубов

Показатели отработки методов расчета кубов отличаются от методов интеграций тем, что по итогу расчетов не строится файл формата xml, т.к. данные и их расчеты хранятся в БД. В связи с этим, по итогу проверки отработки методов, не происходит проверка файла xml (см. рисунок 3.2).

Для мониторинга сбора OLAP-кубов необходимо в ручном режиме ответственным разработчикам определять связь куба - его расчета - источника данных. Далее в соответствии с найденными связями происходит расстановка контрольных точек и унификация. Этот процесс должен быть проведен для каждой подсистемы.

Рисунок 3.2 Статусная модель методов, относящихся к расчетам

Аналогично по итогам проверки работы метода атрибуты таблицы 3.1. рассчитываются и передаются в аналитику подсистемы мониторинга здоровья ИАС МКР (см. таблица 3.2).

Не разработан и не автоматизирован функционал, необходимый при появлении в системе ИАС МКР новых данных с новыми расчетами. То есть при появлении новых расчетов в OLAP-кубах их необходимо в ручном режиме добавлять для мониторинга разработчикам, ответственным за расчеты. В соответствии со статусной моделью отработки методов расчетов OLAP, данные собираются в единый отчет подсистемы мониторинга ИАС МКР - «Отчет о расчетах кубов».

Таблица 3.2

Атрибутивный состав аналитического отчета отработки методов расчета кубов

Наименование атрибута

Тип данных

Значение по умолчанию

Принимаемые значения

Наименование

Текстовый

-

-

Статус выполнения

Текстовый

Не запущено

Не запускалось, Исправлено, Ошибка, В процессе, Успешно

Дата начала последнего запуска

Дата, время

-

Любая дата и время, ранее «Даты конца последнего запуска»

Дата конца последнего запуска

Дата, время

-

Любая дата и время после «Дата начала последнего запуска»

ID сессии

Текстовый

-

-

Наименование куба

Текстовый

-

-

Дата начала следующего запуска

Дата, время

-

Любая дата и время с сегодняшнего дня и позже

Планируемая дата окончания следующего запуска

Дата, время

-

Любая дата и время с сегодняшнего дня и далее, которая позже «Даты начала следующего запуска»

3.2 Средства разработки подсистемы «Мониторинг здоровья»

Разработка подсистемы мониторинга здоровья главным образом сопровождалась тремя средствами. Для работы с БД и сбора показателей работоспособностей использовалось ПО DataGrip, более того, для сбора показателей использовался инструмент веб-аналитики Яндекс Метрика. Для непосредственной разработки подсистемы использовалось ПО PhpStorm.

1. DataGrip

DataGrip - комплексная среда для работы с СУБД. предназначенную для работы с системами управлениями базами данных MySQL, PostgreSQL, Oracle, SQL Server, Sybase, DB2, SQLite. Инструмент удобен оптимальным автозавершением кода и многострочным способом ведения задач TODO.

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

2. Яндекс Метрика

Целью добавления счетчиков Яндекс Метрики в систему ИАС МКР является сбор данных о нагрузке на систему. Инструмент аналитики «Яндекс.Метрика» работает по принципу счетчика посещений на коде JavaScript. Этот код позволяет считывать данные о каждом посещении и действии пользователя.

В связи с этим был проанализирован перечень предлагаемых счетчиков инструментом веб-аналитики. Ниже (таблица 3.3) перечислен ряд инструментов, которые были установлены в ИАС МКР для сбора статистики и ее последующей интеграции в подсистему мониторинга.

Таблица 3.3

Перечень опций Яндекс Метрики для внедрения в ИАС МКР

Наименование опции

Цель применения

На какие страницы

Карта кликов

Измерения и отображения статистики по кликам. Карта отображает клики по всем элементам страницы

Все подсистемы

Вебвизор

Запись действий посетителей на странице

При успешной авторизации пользователя (1 страница)

Асинхронный код

Отслеживание статистики посещаемости

Все подсистемы

Отслеживание хеша в адресной строке

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

Все подсистемы

Часть кода Яндекс метрики для размещения на веб-странице отражена ниже:

<!-- Yandex.Metrika informer -->

<a href="https://metrika.yandex.ru/stat/?id=-----&amp;from=informer"

target="_blank" rel="nofollow">

<img src="https://informer.yandex.ru/informer/-----

/1_1_EFEFEFFF_EFEFEFFF_0_uniques"

style="width:80px; height:15px; border:0;"

alt="Яндекс.Метрика" title="Яндекс.Метрика: данные за сегодня

(уникальные посетители)"

class="ym-advanced-informer" data-cid="-----" data-lang="ru" /> </a>

<!-- /Yandex.Metrika informer -->

<!-- Yandex.Metrika counter -->

<script type="text/javascript">

(function(m,e,t,r,i,k,a){

m[i]=m[i]||function(){

(m[i].a=m[i].a||[]).push(arguments)};

m[i].l=1*new Date();

k=e.createElement(t), a=e.getElementsByTagName(t)[0], k.async=1,

k.src=r,a.parentNode.insertBefore(k,a)

})

(window, document, "script", "https://mc.yandex.ru/metrika/tag.js", "ym");

ym(-----, "init",

{ clickmap:true, trackLinks:true, accurateTrackBounce:true, webvisor:true,

trackHash:true });

</script>

<!-- /Yandex.Metrika counter -->

После процесса считывания показателей по сервису Яндекс Метрики со всех подсистем ИАС МКР и помещению их в хранилище БД, необходимо провести расчеты общих показателей эффективности системы. С перечнем показателей можно ознакомиться в Главе 2. Рассмотрим некоторые из них:

· Среднее время загрузки системы - среднее арифметическое суммы загрузки всех подсистем ИАС МКР за последние 24 часа.

$AvgTime = array_sum($avgTimes) / $count (1)

· Среднее количество пользователей ИАС МКР онлайн - среднее арифметическое суммы чисел всех пользователей всех подсистем в моменте.

$AvgOmline = array_sum($avgTimes) / $count (2)

· Коэффициент критичности состояния системы ИАС МКР. определяется динамически, задано значение по умолчанию.

$AvgMin = 0.2 (3)

· Коэффициент влияния числа пользователей на работоспособность ИАС МКР. определяется автоматически, задано значение по умолчанию.

$AvgMax = 10(4)

· Общий показатель работоспособности ИАС МКР - показатель, отображающий общее состояние системы.

$result = ($AvgMin + 1) / ($AvgMin *(5)

* ($AvgTime / pow($AvgOnline, exp: 1/$AvgMax)) + $AvgMin + 1);

3. Инструмент PhpStorm

PhpStorm - кросс-платформенная интегрированная среда разработки для языка программирования PHP. PhpStorm представляет собой редактор для PHP, HTML и JavaScript с возможностями динамического анализа кода, предотвращения ошибок в коде и автоматизированными средствами рефакторинга.

3.3 Разработка схемы базы данных мониторинга систем

По спроектированным ранее (Глава 2) логической и концептуальной схемам БД была реализована физическая схема. Как видно, схема соответствует построенной ранее схеме на концептуальном и логическом уровнях. В перспективе дальнейшей разработки инструмента БД должна быть модифицируема (см. рисунок 3.3).

Рисунок 3.3 Схема базы данных на физическом уровне

3.4 Интерфейс подсистемы мониторинга систем

Финальный этап разработки подсистемы мониторинга здоровья ИАС МКР подразумевает разработку конечного пользовательского интерфейса и функционала. Далее приведено описание основного пользовательского сценария с отображением разработанного интерфейса. Подсистема с текущим дизайном введена в эксплуатацию.

Пользователь авторизуется в ИАС МКР и переходит на разработанный инструмент мониторинга здоровья ИАС МКР. При этом отображается страница, разделенная на шапку с показателями общими по работоспособности системы и перечнем доступных подсистем. Именно аналитика работоспособности этих подсистем может быть проверена пользователем (см. рисунок 3.4).

Рисунок 3.4 Приветственная страница авторизации подсистемы мониторинга здоровья ИАС МКР

Рисунок 3.5 График отображения детализации общих показателей работоспособности ИАС МКР (количество уникальных посетителей за 24 часа)

Пользователю доступен просмотр графика детализации посещаемости системы в целом. Для этого необходимо нажать на показатель в шапку страницы подсистемы мониторинга ИАС МКР, например, на показатель «Количество уникальных пользователей за 24 часа». График открывается в модальном окне с доступным фильтром отображаемых данных (рисунок 3.5).

Для фильтрации данных графика необходимо раскрыть соответствующий блок и выбрать период отображаемых данных, а также подсистему (рисунок 3.6). Можно выбрать только одну подсистему.

Рисунок 3.6 Фильтрация отображаемых данных в графиках детализации общих показателей

На странице с перечнем подсистем каждая подсистема отображается в виде карточки. Карточка подсистемы содержит общие данные о работоспособности: нагрузка, состояние (рисунок 3.7).

Рисунок 3.7 Карточка подсистемы ИАС МКР

При нажатии на карточку подсистемы отображается перечень сервисов. Могут быть отображены как «рабочие» сервисы, то есть те, которые по факту интегрируют с данной подсистемой, так и «не рабочие» (см. рисунок 3.8).

Рисунок 3.8 Перечень настроенных сервисов выбранной подсистемы ИАС МКР

Сервисы объединяются в группы с помощью функционала группировки, реализованного в интерфейсе (рисунок 3.9). Группы можно создавать и редактировать.

Рисунок 3.9 Настройка группы сервисов выбранной подсистемы ИАС МКР

Карточка сервиса отражает наименование и степень работоспособности, основанную на числе успешно отработанных методов (см. рисунок 3.10). Также на карточке интеграции отображаются данные по последнему вызову метода, относящегося к текущей интеграции.

Рисунок 3.10 Карточка сервиса подсистемы

Нажатие на карточку сервиса инициирует открытие детализации интеграции (рисунок 3.11). В детализации отображается график с раскрашенными клеточками в соответствии с цветовой индикацией статуса отработки метода. График подтверждается таблицей с данными о запусках методов и сессиях данного сервиса.

Рисунок 3.11 Детализация работоспособности методов сервиса

Нажатие на поле таблицы инициирует открытие детализации сессии, указанной в первом столбце таблицы рисунка 3.11. В детализации сессии доступен поиск по наименованию метода (см. рисунок 3.12).

Рисунок 3.12 Детализация отработки методов интеграции выбранной сессии

Нажатие на клеточку графика инициирует фильтрацию таблицы (рисунок 3.13).

Рисунок 3.13 Фильтрация таблицы детализации по выбранному элементу графика

При переходе на вкладку «Расчет кубов» открывается аналогичная таблица с графиком. Однако здесь приведены данные по методам, которые относятся к расчетам в системе ИАС МКР (см. рисунок 3.14).

Рисунок 3.14 Детализация работоспособности методов расчетов кубов выбранной подсистемы

Как на вкладке сервисов, так и на вкладке расчетов кубов, график и таблица доступны для фильтрации. Реализован фильтр только по результатам отработки методов и поиску метода по наименованию сессии (рисунок 3.15).

Рисунок 3.15 Фильтрация детализации методов по статусной модели выполнения

Данные каждой детализации доступны для скачивания. Реализован экспорт документов в форматы xlsx и docx (рисунок 3.16). Это позволяет быстро получать аналитику работоспособности за определенный период для дальнейшей аналитики.

Рисунок 3.16 Экспорт аналитических отчетов детализации

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

3.5 Тестирование подсистемы мониторинга ИАС МКР

Разработка подсистемы мониторинга ИАС МКР не сопровождалась автоматизированным тестированием ввиду особенностей разработки всей системы. Ввиду этого проверка соответствия разрабатываемой системы требованиям основана на проверке функционала методом черного ящика - black box testing (таблица 3.4).

Таблица 3.4

Описание тест-кейсов тестирования подсистемы мониторинга ИАС МКР методом черного ящика

Предмет

Наименование теста

№ шага

Описание шага

Ожидаемый результат

Реальный результат

Примечание

Авторизация

Авторизация в ИАС МКР с выданными правами на просмотр мониторинга систем

1

Открыть систему ИАС МКР в браузере по: http://gp.mos.ru/

Открытие страницы авторизации ИАС МКР

+

-

2

Ввести логин и пароль, авторизоваться

Авторизация прошла успешно

+

3

Перейти к списку вспомогательных подсистем

Подсистема "Мониторинг здоровья" отображается

+

4

Открыть подсистему мониторинга ИАС МКР

Подсистема успешно открылась на странице перечня подсистем

+

Авторизация в ИАС МКР без выданных прав на использование мониторинга ИАС МКР

1

Открыть систему ИАС МКР в браузере по ссылке: http://gp.mos.ru/

Открытие страницы авторизации ИАС МКР

+

-

2

Ввести логин и пароль, авторизоваться

Авторизация прошла успешно

+

3

Перейти к списку вспомогательных подсистем

Подсистема "Мониторинг здоровья" не отображается в перечне доступных подсистем

+

Общие показатели эффективности ИАС МКР

Отображение графика среднего времени отклика системы

1

В шапке подсистемы нажать на значение показателя

Открытие модального окна с графиком времени отклика системы за последние сутки

+

Предполагается после выполнения теста №1

2

Перейти в фильтр графика

Открытие перечня фильтров

+

3

Применить фильтр по подсистемам и датам "С", "ДО"

График отображает данные, соответствующие заданному фильтру

+

Отображение графика числа онлайн пользователей

1

В шапке подсистемы нажать на значение показателя

Открытие модального окна с графиком пользователей онлайн

+

Предполагается после выполнения теста №2

2

Перейти в фильтр графика

Открытие перечня фильтров

+

3

Применить фильтр по подсистемам и датам "С", "ДО"

График отображает данные, соответствующие заданному фильтру

+

Отображение графика уникальных пользователей за 24 часа

1

В шапке подсистемы нажать на значение показателя

Открытие модального окна с графиком уникальных пользователей

+

Предполагается после выполнения теста №3

2

Перейти в фильтр графика

Открытие перечня фильтров

+

3

Применить фильтр по подсистемам и датам "С", "ДО"

График отображает данные, соответствующие заданному фильтру

+

Карточка подсистемы

Проверка соответствия показателей эффективности общему признаку работоспособности подсистем

1

Проанализировать одну из отображаемых подсистем

Отображаются данные, соответствующие действительности (проверка по БД)

+

Предполагается после выполнения теста №1

2

Проанализировать соответствие отображаемого индикатора (красный, оранжевый, зеленый) и значений показателей

Индикатор отображается соответствующим цветом

+

Настройка и просмотр интеграций подсистемы

Формирование перечня интеграций

1

Перейти на карточку подсистемы

Открытие пустой страницы с сообщением о необходимости настройки групп сервисов

+

Предполагается после выполнения теста №6

2

Нажать на кнопку "Настройка сервисов"

Открытие модального окна для формирования групп интеграций

+

3

Нажать "Добавить группу"

Появление строки для создания группы

+

4

Ввести наименование группы, сохранить

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

+

5

Добавить в группу интеграции

Сохранение группы

+

6

Перейти к списку групп интеграций

Отображение созданной группы

+

Редактирова-ние перечня интеграций

1

Перейти на карточку подсистемы

Открытие страницы групп интеграций

+

Предполагается после выполнения теста №6

2

Нажать на кнопку "Настройка сервисов"

Открытие модального окна для редактирования групп интеграций

+

3

Нажать "Добавить группу"

Появление строки для создания группы

+

4

Ввести наименование группы, сохранить

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

+

5

Добавить в группу интеграции

Сохранение группы

+

6

Перейти к списку групп интеграций

Отображение всех групп

+

Детализация интеграций подсистем

Переход к детализации интеграции

1

В списке интеграций нажать на карточку какой-либо интеграции

Открытие страницы детализации с таблицей и графиком

+

Предполагается после выполнения теста №7 или №8

Просмотр детализации интеграции

1

Нажать на элемент фильтра "Результат выполнения"

Вывод элементов для фильтра

+

Предполагается после выполнения теста № 9

2

Выбрать "Не запускалось" и "Ошибка"

Таблица детализации отфильтрована в соответствии с выбранным результатом, как и график

+

3

Нажать на "Данные за…"

Открытие календаря

+

4

Выбор календаря "Март 2019"

Данные таблицы и графика отражают информацию с установленным фильтром по методам за Март 2019

+

5

Нажать на квадратик графика

Отображение таблица под графиком только по данным, выбранным на графике нажатием

+

6

Нажать на наименование сессии

Открытие детализации сессии: методы, время запуска и результат

+

7

Нажать "Экспорт" - экспорт в DOCX

Скачивается файл соответствующего формата с данными таблицы

+

8

Нажать "Экспорт" - экспорт в XLSX

Скачивается файл соответствующего формата с данными таблицы

+

9

Вернуться назад

Открытие страницы с интеграциями выбранной подсистемы

+

10

Нажать "Экспорт" - экспорт в XLSX

Скачивается файл соответствующего формата с данными таблицы

+

Просмотр отработки кубов

Просмотр отработки кубов подсистемы

1

Перейти на вкладку "Расчет кубов"

Открытие страницы детализации отработки методов с графиком и таблицей

+

Предполагается после выполнения теста № 6

Настройка и просмотр отработки методов подсистемы

1

Нажать на элемент фильтра "Поиск по сессии", вести ИД сессии из таблицы под графиком и провести поиск

График и таблица отфильтрованы по сессии - отображаются только отработки методов данной сессии

+

Предполагается после выполнения теста № 11

2

Нажать "Экспорт" - экспорт DOCX

Скачивается файл соответствую-щего формата с данными

+

3

Открыть скаченный файл

Данные файла соответствуют таблице

+

4

Закрыть документ. Нажать на квадратик метода в таблице методов расчета кубов

Открытие детализации сессии у методов расчета интеграций

+

5

Вернуться назад

Открытие страницы с перечнем отработанных методов

+

6

Нажать на строку в таблице

Открытие детализации метода

+

Выход из подсистемы

Переход к подсистемам

1

Нажать "Выход" - К списку подсистем

Откроется на список подсистем

+

-

Выход из подсистемы

1

Нажать "Выход" - Перейти к выходу

Произойдет выход из ИАС МКР

+

-

3.6 Перспективы разработки инструмента мониторинга ИАС МКР

В рамках подписания нового государственного контракта был проработан перечень задач для развития подсистемы мониторинга ИАС МКР. Задачи были проработаны с главным аналитиком, разработчиком и приняты заказчиком. В перспективе необходимо реализовать следующие функциональные возможности:

· разработать сводный отчет по отработке интеграций;

· завести логирование всех отчетов ИАС МКР;

· реализовать возможность группировки подсистем;

· разработать для каждой подсистемы аналитику активности с детализацией до времени авторизации пользователей;

· реализовать возможность группировки данных (по месяцам, неделям, дням, часам) в графиках детализации работы системы;

· должна быть возможность просмотра графика по индикатору общей нагрузки на систему;

· разработать интерфейс подключения подсистем к мониторингу здоровья;

· разработать фильтрацию в блоке отображения сервисов;

· реализовать поиск по наименованию сервиса в списке сервисов;

· разработать центр оповещения пользователя уведомлениями о работе подсистем;

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

Вывод по главе

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

Заключение

В данной работе была изучена система ИАС МКР, разрабатываемая компанией PRO IT. Проанализированы принципы, технологии, специфика разработки, схема БД системы. В процессе анализа была изучена возможность разработки инструмента анализа работоспособности ИАС МКР.

Инструмент анализа работоспособности ИАС МКР проектировался в качестве новой подсистемы. Поставлена цель - разработать подсистему мониторинга ИАС МКР. Составлены задачи для достижения поставленной цели.

Проведен анализ подобных инструментов веб-аналитики и составлены функциональные, нефункциональные требования. Смоделированы диаграммы бизнес-процесса обнаружения неполадок в системе в нотации EPC состояний AS-IS и TO-BE. Диаграммы состояний сравнены, результатом сравнения стал вывод о том, что БП усовершенствован.

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

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

Инструмент мониторинга ИАС МКР сдавался в рамках государственного контракта предыдущего бюджетного цикла за 2018 год. В текущем бюджетном цикле определены рамки развития подсистемы мониторинга ИАС МКР. Создан перечень из девятнадцати доработок подсистемы, определенных заказчиком.

Библиографический список

1. Избачков Ю.С. Анализ и проектирование информационных систем // Информационные системы. Методология проектирования информационных систем. Третье издание. 2010. С. 23-54.

2. Ильин В.В. Моделирование бизнес-процессов. Практический опыт разработчика.

3. Лидеры рынка ИТ-услуг 2018.

4. Методические указания разработки автоматизированных систем РД 50-680-88.

5. Национальный стандарт РФ «Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий». ГОСТ Р ИСО/МЭК 15408-1-2012

6. Сорокин А.В. Реинжиниринг бизнес-процессов // Министерство образования и науки РФ Рубцовский индустриальный ун-т. Серия: Информационные технологии. 2015. С. 8-13.

7. Тельнов Ю.Ф. Реинжиниринг бизнес-процессов // Международный образовательный консорциум «Открытое образование». Серия: Информационные технологии. 2004. С. 16-32.

8. Техническое задание по заявке №3 Функционального заказчика ИАС МКР по государственному контракту №ГК 6401/16-2516.

9. Федорова О.В. Применение методологий SADT И ARIS для моделирования и управления бизнес-процессами информационных систем // Вестник Воронежского государственного университета инженерных технологий. 2018. С. 105-109.

10. Шабанец Я.Р. Мультиплатформенный сервис логирования // Компьютерные системы и сети. Материалы 49-ой научной конференции аспирантов, магистрантов и студентов. 2013. С. 130-131.

11. Шакирова Ю.К. Применение инструментария извлечения знаний на основе компьютерных технологий. // Дистанционное и виртуальное обучение. 2015. С. 66-72.

12. Яндекс Метрика

13. A. Noyon. A Study of Ajax Template Injection in Web Applications. International Journal of Engineering & Technology, Volume 7, pp 123-127.

14. GoogleAnalytics

15. E.Sinz. A Short Comparison of Business Process Modelling Methods under the Perspective of Structure and Behavior. International journal of conceptual modelling EMISAJ (Enterprise Modelling and Information Systems Architecture), Volume 13, pp 63-68.

16. D. Brown. System and method for logging queries, U.S. Patent No.US 7,127,456 B1. 2006.

17. J. Henrard. Strategies for Data Reengineering in Ninth Working Conference on Reverse Engineering, Richmond, USA, WCRE, 2002, pp. 211-221.

18. H. Wang. Model-Driven Reengineering of DB in World Congress on Software Engineering, Xiamen, China, WRI, 2009, pp 113-117.

19. OpenWebAnalytics.

20. R.Rabiser. Developing and evolving a DSL-based approach for runtime monitoring of systems of systems. Automated Software Engineering, Volume 25, pp 875-915.

21. R. Hogan. A Practical Guide to Database Design. CRC Press, 2018, pp 1-14.

Приложение А

Подсистемы ИАС МКР

Наименование подсистемы

Тип

Стадия разработки

Описание

Подсистема мониторинга социально-экономического развития

Функциональная

Не требует развития

Повышения качества анализа социально-экономических показателей развития города и формирования прогноза социально-экономического развития

Подсистема оценки эффективности деятельности органов исполнительной власти

Функциональная

Не требует развития

Обеспечение процессов мониторинга и оценки деятельности органов исполнительной власти

Подсистема мониторинга реализации мер социальной поддержки

Функциональная

Не требует развития

Сбор и актуализация данных по мерам социальной поддержки

Подсистема мониторинга инвестиционной деятельности

Функциональная

Не требует развития

Мониторинга инвестиционной деятельности на основании первичных данных

АРМ Руководителя (автоматизированное рабочее место руководителя)

Функциональная

Требует модернизации

Визуализация сводных показателей и отчетных форм

Подсистема аналитики по группам расходов

Функциональная

Требует модернизации

Аналитическая обработка и отображение сводных показателей по мероприятиям развития

Подсистема сбора и актуализации данных по работам на объектах городского хозяйства

Функциональная

Требует модернизации

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

Подсистема мониторинга деятельности государственных учреждений

Функциональная

Требует модернизации

Мониторинг эффективности использования государственного имущества

Наименование подсистемы

Тип

Стадия разработки

Описание

Подсистема мониторинга и контроля реализации государственных программ

Функциональная

Требует модернизации

Поддержка ...

Страница:


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены