Размещено на http://www.Allbest.Ru/

Размещено на http://www.Allbest.Ru/

Размещено на http://www.Allbest.Ru/

Пермский филиал федерального государственного автономного образовательного учреждения высшего образования

Национальный исследовательский университет «Высшая школа экономики»

Факультет экономики, менеджмента и бизнес-информатики

Кафедра информационных технологий

Образовательная программа «Бизнес-информатика»

Выпускная квалификационная работа

по направлению подготовки 38.03.05 Бизнес-информатика

Тема:

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

Выполнила Жидяевская А.А.

к.п.н., доцент, А.А. Петренко

Пермь, 2019 год



Аннотация

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

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

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

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

Объем работы составляет 83 страницы, на которых размещены 12 таблиц и 42 рисунка, а также 6 приложений. Библиографический список содержит 21 наименование.



Оглавление

• Список терминов и сокращенных наименований
• Введение
• Глава 1. Анализ системы ИАС МКР
• 1.1 Принципы разработки ИАС МКР
• 1.2 Компоненты ИАС МКР
• 1.3 Принцип функционирования компонентов системы ИАС МКР
• 1.4 Анализ схемы интеграций ИАС МКР
• 1.5 Архитектура ИАС МКР
• 1.6 Проблемы функционирования ИАС МКР
• Выводе по главе
• Глава 2. Проектирование подсистемы мониторинга ИАС МКР
• 2.1 ИАС МКР как система систем
• 2.2 Инструменты анализа эффективности систем
• 2.3 Общие требования к реализации Мониторинга систем
• 2.4 Проектирование базы данных подсистемы мониторинга систем
• 2.5 Логирование данных ИАС МКР
• 2.6 Проектирование интерфейса мониторинга систем ИАС МКР
• 2.6.1 Проектирование навигационной панели
• 2.6.2 Проектирование карточек подсистем ИАС МКР
• 2.6.3 Проектирование детализации работоспособности
• 2.7 Требования к разработке мониторинга ИАС МКР
• Выводы по главе
• Глава 3. Разработка подсистемы мониторинга ИАС МКР
• 3.1 Методика разработки подсистемы мониторинга здоровья
• 3.2 Средства разработки подсистемы «Мониторинг здоровья»
• 3.3 Разработка схемы базы данных мониторинга систем
• 3.4 Интерфейс подсистемы мониторинга систем
• 3.5 Тестирование подсистемы мониторинга ИАС МКР
• 3.6 Перспективы разработки инструмента мониторинга ИАС МКР
• Вывод по главе
• Заключение
• Библиографический список
• Приложения



Список терминов и сокращенных наименований

Сокращения и термины	Определение
ИАС МКР, Система	Информационно-аналитическая система мониторинга комплексного развития
СТП	Служба технической поддержки
ЧТЗ, ТЗ	Частное техническое задание, техническое задание
ИС	Информационная система
ОС	Операционная система
БД	Программное обеспечение/База данных
СУБД	Система управления базами данных
ИТ	Информационные технологии
РД	Руководящий документ
ОИВ	Органы исполнительной власти
ГУ	Государственное учреждение
КСП	Контрольно-счетная палата
ЕАИСТ	Единая Автоматизированная Информационная Система Торгов
АСУ ГФ	Автоматизированная Система Управления Городскими Финансами
АС УР	Автоматизированной системе "Единая система ведения и управления реестрами, регистрами, справочниками и классификаторами"
АСУ ОДС	Автоматизированная Система Управления Объединенной Диспетчерской Службы
ЕМИАС	Единая медицинская информационно-аналитическая система
Мосгорстат	Автоматизированная система Территориального органа Федеральной службы государственной статистики по городу Москве
АСКД	Аналитическая система контрольной деятельности Главного контрольного управления города Москвы
АИС ЖСЛ	Автоматизированная информационная система жилищных субсидий и возмещения выпадающих доходов от льгот
РСОИ Соцзащита	Распределённая автоматизированная система обработки информации по социальной защите населения
УАИС БУ	Универсальная Автоматизированная Система Бюджетного Учета
АИС УИД	Автоматизированная Информационная Система Управления Инвестиционной деятельностью
ИС ММЦ	Информационная Система Многофункциональный Миграционный Центр
АИС ЭОР	Автоматизированная Информационная Система Электронные Образовательные Ресурсы
АИС ОПН	Автоматизированная Информационная Система координации работы органов исполнительной власти города Москвы по обеспечению поступления в бюджет города Москвы доходов от отдельных видов налогов и сборов
АИС ГИН	Автоматизированная Информационная Система Государственной инспекции по контролю за использованием объектов недвижимости
ИС РЕОН	Информационная Система Реестра Единых Объектов Недвижимости
АРМ	Автоматизированное Рабочее Место
xml	eXtensible Markup Language - расширяемый язык разметки
SQL	Structured Query Language - язык структурированных запросов



Введение

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

По данным новостного агентства в сфере ИТ CNews [3], расходы на реализацию государственных ИТ-проектов в России растут с каждым годом. Компания PRO IT занимается разработкой ИТ-решений для различных департаментов. Одними из ключевых заказчиков являются Правительство Российской Федерации, Администрация Президента, Росавтодор, Федеральная служба охраны и другие.

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

· время, за которое обнаруживается проблема, включает время обнаружения проблемы пользователем, написание обращения и его обработки;

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

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

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

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

В соответствии с ТЗ, разрабатываемая подсистема названа «Мониторинг систем» («Мониторинг здоровья»). С точки зрения пользовательского интерфейса, для отслеживания функционирования подсистем необходимо получать в «Мониторинге систем» следующую информацию:

1. Перечень интеграций с внешними сервисами каждой подсистемы.

2. Перечень рассчитанных кубов с данными о сессиях, методах, результатах вызова.

3. Все вызванные методы подсистем с результатом отработки.

4. Число пользователей подсистем и системы в целом за час/ 3 часа/ 6 часов/ сутки.

5. Данные о нагрузке на подсистемы в моменте/ за час/ за три часа/ за сутки.

6. Общая оценка работоспособности подсистем.

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

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

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

1. Анализ системы ИАС МКР:

1.1 Выполнить анализ архитектуры.

1.2 Выполнить анализ схемы БД.

1.3 Построить модели бизнес-процесса.

1.4 Выполнить сравнение инструментов web-аналитики.

2. Проектирование инструмента мониторинга функционирования ИАС МКР:

2.1 Составить список метрик для анализа нагрузки подсистем.

2.2 Разработать проект системы логирования.

2.3 Перепроектировать схему БД.

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

2.5 Составить постановку на разработку подсистемы в соответствии с ТЗ [8].

3. Разработка инструмента мониторинга функционирования ИАС МКР:

3.1 Выполнить тестирование разрабатываемой подсистемы и её отладку.

3.2 Развернуть подсистему с локального сервера на Production-сервер и ввести в опытную эксплуатацию.

3.3 Провести анализ результатов внедрения разработанного инструмента мониторинга ИАС МКР.

Разработка инструментария контроля предполагает моделирование бизнес-процессов в нотации EPC, построение диаграммы вариантов использования и диаграммы активности. В работе предлагается применение средства веб-аналитики Яндекс Метрика. Разработка подсистемы проводится на языках php, ajax. В качестве СУБД предлагается использование Oracle.

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



Глава 1. Анализ системы ИАС МКР

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

1.1 Принципы разработки ИАС МКР

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

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

В соответствии с РД 50-680-88РД 50-680-88 - руководящий документ с методическими указаниями автоматизации системы, при развитии системы ИАС МКР руководствуются принципами [4]:

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

2. Принцип развития (открытости) - исходя из перспектив развития объекта автоматизации, система должна создаваться с учетом возможности пополнения и обновления функций и состава системы без нарушения ее функционирования.

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

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

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

6. Принцип развития (модифицируемости) - система должна обеспечивать возможность развития, расширения и интеграции с другими системами.

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

1.2 Компоненты ИАС МКР

Рисунок 1.1 Подсистемы ИАС МКР

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

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

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

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

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

4. АРМ Руководителя.

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

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

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

8. Подсистема мониторинга уровня оплаты труда работников государственных учреждений города Москвы.

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

10. Подсистема мониторинга показателей КСП.

11. Мобильное приложение ИАС МКР.

12. Подсистема информационного взаимодействия.

13. Подсистема администрирования.

14. Подсистема хранения данных.

15. Подсистема управления и настройки.

16. Подсистема информационной безопасности.

17. Подсистема информационно-справочного обеспечения пользователей.

18. Подсистема информационной безопасности.

19. Подсистема информационно-справочного обеспечения пользователей.

20. Подсистема взаимодействия ОИВ по вопросам финансирования городских мероприятий.

1.3 Принцип функционирования компонентов системы ИАС МКР

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

Таблица 1.1

Общее представление матрицы ролей

Наименование роли	Доступный функционал
Администратор	Обновление новостных разделов, редактирование периодов ввода и форм ввода
Оператор ввода	Ввод финансовых показателей в формы ввода данных определенных учреждений
Утверждающий органа власти	Проверка и согласование заполненных форм ввода
Аналитик отчетов	Просмотр раздела отчетов и построение отчетов по показателям группы учреждений
Аналитик по подсистеме	Просмотр всех разделов без возможности редактирования

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

Рисунок 1.2 Обобщенная модель вариантов использования бизнес-процессов утверждения отчетных форм в подсистемах ИАС МКР

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

Таблица 1.2

Описание прецедента согласования формы Утверждающим ОИВ

Наименование варианта использования	Согласовать данные отчетной формы утверждающему ОИВ
Действующее лицо (Actor)	Утверждающий ОИВ
Описание	Перевод отчетной формы учреждения на следующий уровень согласования
Триггер	Утверждающий ОИВ обязан проверить отчетную форму учреждения в определенных временных рамках
Предусловия	1. Учетная запись в ИАС МКР. 2. Доступ к соответствующей подсистеме и ролью к ней «Утверждающий ОИВ». 3. Авторизация в ИАС МКР. 4. Отчетная форма отправлена Оператором ввода на статус «На рассмотрение в ОИВ».
Постусловия	Отчетная форма будет отправлена на рассмотрение в Министерство Финансов.
Основной сценарий	1. Авторизация в системе. 2. Открытие подсистемы. 3. Выбор / поиск учреждения в списке учреждений. 4. Нажатие кнопки для открытия отчетной формы ввода учреждения. 5. Система выводит заполненную оператором ввода форму на экран. 6. Проведение проверки данных отчетной формы. 7. Нажатие кнопки для подтверждения согласования данных.
Альтернатив-ные сценарии	1а. На шаге 1 основного сценария пользователь не авторизовывается в системе:1. Авторизация не осуществляется.2. Система выводит сообщение о введении неверных данных. 3. Пользователь вводит корректные данные.4. Возврат к шагу 1 основного сценария, пользователь авторизуется в системе. 3a. В шаге 3 основного сценария если утверждающий не нашел не учреждение в списке, система выводит сообщение о необходимости проверки, реорганизовано ли учреждение.1. Пользователь проверяет в специальном разделе подсистемы данные о реорганизованных учреждениях. 2. Утверждающий ОИВ ознакомился с данными о реорганизации искомого учреждения, переходит при необходимости к шагу 2 основного сценария для утверждения других отчетных форм. 3b. В шаге 3 основного сценария если утверждающий не нашел не учреждение в списке, система выводит сообщение о необходимости проверки, реорганизовано ли учреждение.1. Пользователь проверяет в специальном разделе подсистемы данные о реорганизованных учреждениях. 2. Утверждающий ОИВ не нашел данные о реорганизации учреждения и обращается в СТП. 7а. В шаге 7 основного сценария если Утверждающий ОИВ не может принять данные отчетной формы, он не подписывает ее:1. Утверждающий ОИВ нажимает кнопку «Вернуть на доработку». 2. Утверждающий вводит причину отправки на редактирование. 3.Оператор ввода проверяет причину и перезаполняет форму.4. Оператор ввода отправляет форму на согласование к Утверждающему ОИВ.5. Переход к шагу 1 основного сценария.
Частота использования	При каждом запуске системы пользователем при каждом открытии нового отчетного периода.
Дополнительные требования	1.В качестве СУБД использовать Oracle. 2.При разработке использовать технологии JavaScript, Jquery, Ajax, php.
Предположения	Предполагается что Утверждающий ОИВ осведомлен в том, что в справке подсистемы есть Руководство пользователя ОИВ.

1.4 Анализ схемы интеграций ИАС МКР

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

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

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

В целях создания единого информационного пространства осуществлена интеграция ИАС МКР со следующими ИС (расшифровка представлена в пункте Список терминов и сокращенных наименований):

1. ЕАИСТ

2. АСУ ГФ

3. АС УР

4. АСУ ОДС

5. Мосгорстат

6. ЕМИАС

7. АСКД

8. Портал «Наш город»

9. УАИС БУ

10. АИС ЖСЛ

11. РСОИ Соцзащита

Составлена схема текущих интегарций систем ИАС МКР (рисунок 1.3). Предназначение каждого сервиса и описание принимаемых/ отправляемых данных описано в приложении Б.

Рисунок 1.3 Схема текущего информационного взаимодействия ИАС МКР с внешними системами

В рамках ЧТЗ, должна быть расширена существующая интеграция в рамках перечня получаемых данных со следующими ИС:

1. АСУ ГФ

2. ЕАИСТ

3. УАИС БУ

4. АСУ ОДС

5. Портал «Наш город»

Более того, должна быть реализована интеграция с новыми сервисами (ИС):

1. АИС УИД

2. ИС ММЦ

3. АИС ЭОР

4. АИС ОПН

5. АИС ГИН

6. ИС РЕОН

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

Рисунок 1.4 Перспективная схема информационного взаимодействия ИАС МКР

Ввиду усложнения числа и работы сервисов, а также увеличения объема данных, необходимо ввести систему логирования. Логирование позволит отслеживать время и метод получения и отправки данных, его результат [10]. В логах необходимо учитывать вид сервиса: принимаются или отправляются данные, частоту взаимодействия, подсистемы, с которыми настроена интеграция. Данные логов необходимо визуализировать в пользовательском интерфейсе подсистемы «Мониторинг систем».

1.5 Архитектура ИАС МКР

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

Рисунок 1.5 Существующая архитектура Системы ИАС МКР



1.6 Проблемы функционирования ИАС МКР

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

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

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

Действующие способы обнаружения ошибки в системе являются неэффективными, как можно заметить, проанализировав диаграмму EPC состояния AS-IS («как есть») [2], которая расположена в приложении В, и диаграмму активности текущего БП (см. рисунок 1.6). Аналитик, помимо своих основных задач, обязан выполнять ряд задач (выражены в виде функций на диаграмме активности) не автоматизированного бизнес-процесса решения ошибочной ситуации функционирования ИАС МКР.



Рисунок 1.6 Диаграмма активности не автоматизированного БП

Схема бизнес-процесса «Как есть» в нотации EPC также отображает деятельность аналитика бизнес-процесса обнаружения и решения проблем функционирования ИАС МКР. На диаграмме AS-IS видно, что аналитик получает заявку об ошибке в работе системы и устанавливает источник, сообщивший об ошибке - СТП, либо другие аналитики (см. приложение В). Далее происходит длительный процесс взаимодействия с источником, анализ и проверка ошибки. При необходимости дополнительных сведений происходит повторный этап взаимодействия с источником, сообщившем об ошибке. Процесс взаимодействия с пользователями и коллегами из СТП может быть автоматизирован тем, что ошибка будет обнаружена ранее руками аналитика или разработчика. Это позволит сократить время решения проблемы и предотвратить появление срочных задач. Автоматизируемая часть бизнес-процесса отображена на рисунке ниже (рисунок 1.7).

Рисунок 1.7 Автоматизируемый участок диаграммы бизнес-процесса EPC AS-IS

Текущее обнаружение ошибок охарактеризовано следующими недостатками:

1. Обнаружение пользователем неточности в разработке раньше непосредственной группы разработки.

2. Повышенная загруженность СТП.

3. Большое число доработок.

4. Возникновение числа доработок в этапы сдачи подсистем заказчику, что увеличивает нагрузку на разработчиков.

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

6. Сценарий для промежуточного тестирования не составляется, ввиду этого чаще всего тестируется не полный функционал.

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

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

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

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

Кроме недостатков, выделено несколько достоинств:

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

2. Повышается уровень коммуникации с пользователями.

Ввиду проблем, возникающих из-за не автоматизированного процесса обнаружения неполадок в работе системы, создается новая вспомогательная подсистема «Мониторинг систем». Функционирование этой подсистемы должно обеспечить улучшенное управление настройки и поддержания работоспособности ИС [7]. Ввод в эксплуатацию такой системы позволит автоматизировать процесс ведения подсистем и отслеживания их работоспособности [5].

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

В первой главе описана система ИАС МКР: принципы разработки, архитектура. Обнаружены и описаны проблемы, возникающие в функционировании (см. диаграмму EPC AS-IS в приложении В) [9]. Приведено обоснование актуальности разработки, необходимости создания подсистемы мониторинга систем, подкрепленное диаграммой активности. Поставлены цели и задачи разработки.



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

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

2.1 ИАС МКР как система систем

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

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

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

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



Рисунок 2.1. Перспективная архитектура ИАС МКР

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

2.2 Инструменты анализа эффективности систем

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

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

Этот сервис создан для сайтов и электронной коммерции. Он дает возможность анализировать следующие данные [12]:

· аудиторию (посетителей) сайта;

· поведение посетителей;

· выручку и конверсию;

· эффективность интернет-рекламы;

· источники трафика;

· доступность сайта;

· скорость работы сайта.

Инструменты Яндекс.Метрики являются бесплатными, кроме услуги целевого звонка. Яндекс.Метрика отслеживает целевую аудиторию сайта, источники трафика и поисковые запросы, по которым был совершён переход.

2. GoogleAnalytics

GoogleAnalytics - бесплатный сервис от компании Google для формирования статистики посещений веб-сайтов. Статистика собирается на сервере Google [14].

GoogleAnalytics позволяет анализировать продажи и конверсии, предоставляет актуальные данные о действиях пользователей на сайте, о том, как они перешли на него. Также GoogleAnalytics позволяет просматривать карту кликов по ссылкам на сайте.

3. Checklist

Checklist - сервис комплексной аналитики сайта. Есть возможность создания подробного аналитического отчета по сайту и выявить ошибки всех факторов, влияющих на конверсию клиента. Можно выделить следующие преимущества:

· сервис проверяет больше пятисот различных факторов, влияющих на ключевые показатели: удобство, продажи, ранжирование;

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

· осуществляется подробное тестирование адаптивности и верстки на всех устройствах и браузерах;

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

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

4. Open Web Analytics

OpenWebAnalytics - это инструмент с открытым исходным кодом, который можно установить на личном хостинге. Были выделены следующие преимущества [19]:

· нет ограничений по количеству данных;

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

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

· данные хранятся на собственном сервере.

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

5. Результат анализа аналогов

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

Таблица 2.1

Сравнительный анализ инструментов веб-аналитики

Критерий	Яндекс Метрика	Гугл Аналитика	Checklist	Оpen Web Analytics
Анализ посетителей	+	+	-	+
Анализ нагрузки	+	+	+	+
Анализ времени получения данных с БД	-	-	-	-
Журнал действий пользователя на сайте	+	+	+	-
Интеграция с другими системами	+	-	-	-
Невидимый счетчик	+	+	+	+
Анализ используемых пользователями браузеров	+	+	+	+
Возможность создания аналитического отчета	+	+	+	+
Осуществление тестирования адаптивности	-	-	+	-
Осуществление тестирования верстки	-	-	+	-
Аналитика технических запросов	-	-	+	-
Возможность установки для нескольких ресурсов	+	+	-	+
Данные хранятся на собственном сервере	-	-	-	+

Таким образом, наиболее подходящими сервисом является Checklist, так как он позволяет проводить тестирование верстки и адаптивности, а также аналитику технических запросов. Однако, в отличие от ОpenWebAnalytics, сервис не анализирует посетителей и нагрузку на сайт. Более того, у сервиса данные хранятся не на своем сервере, как у ОpenWebAnalytics, и его нельзя устанавливать на несколько ресурсов.

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

Диаграмма 1. Процентное соотношение, полученное при сравнении инструментов веб-аналитики

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

2.3 Общие требования к реализации Мониторинга систем

Подсистема Мониторинга систем создается с целью получения актуальных сведений о работоспособности подсистем и системы в целом, а также отображении данных о внешних интеграциях [8]. Эта подсистема должна отображать аналитику работоспособности каждой функциональной единицы системы [20].

Предполагается, что подсистема должна отображать:

1. Список метрик Системы.

2. Список метрик каждой подсистемы.

3. Данные о функционировании подсистем.

4. Данные об интеграциях каждой подсистемы.

5. Данные об отработанных методах интеграций.

6. Данные об отработанных внутрисистемных методах.

7. Самые вызываемые методы подсистемы пользователями.

8. Свод данных по своду показателей работоспособности каждой подсистемы за любой промежуток времени.

9. Визуализированные данные нагрузки на подсистемы и систему в общем.

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

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

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

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

Таким образом, в соответствии с данными, которые планируется отображать в подсистеме, можно сделать вывод, что бизнес-процесс изменится (см. приложение Г, схема БП нотации EPC TO-BE). Изменение касается исполнителей и функционала [15]. Если на данный момент аналитик узнает о системной проблеме через СТП, либо после тестирования, то после разработки подсистемы можно будет просто просматривать данные раз в день и иметь аналитику работоспособности. Это избавит аналитика от необходимо постоянного взаимодействия со СТП и тем самым снизит нагрузку как на СТП, так и на аналитика.

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

2.4 Проектирование базы данных подсистемы мониторинга систем

Проектирование базы данных для подсистемы «Мониторинг систем ИАС МКР» проводилось в два этапа [21]:

1. Концептуальное проектирование.

2. Логическое проектирование.

Концептуальное проектирование - это построение семантической модели предметной области, то есть информационной модели наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБД.

На первом шаге была спроектирована концептуальная схема в инструменте Visio. Схема была составлена исходя из представлений о разработке ИАС МКР [18]. Определены следующие основные сущности: подсистема, сервис, куб. Cхема содержит связи один ко многим и многие ко многим (см. приложение И)

Сущности БД описаны ниже (см. приложение Д). На концептуальной схеме не отображены таблицы для реализации связи многие ко многим, а также уникальные идентификаторы. Эти данные отображены на логической схеме БД (рисунок 2.2).

Рисунок 2.2 Логическая схема БД мониторинга систем ИАС МКР

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

Всего логическая схема содержит одиннадцать таблиц. Как видно на схеме, таблицы «Группа сервисов» и «Сервисы подсистемы» необходимы для реализации связи многие ко многим. Сущности таблиц, а также их атрибуты (обязательность заполнения, значения по умолчанию) описаны в приложении Д.

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

2.5 Логирование данных ИАС МКР

Логирование информации позволяет провести анализ того, что происходит как на компьютере конкретного пользователя, так и в локальной сети. Запись информации ИАС МКР в логиjavascript:open_win('/dictionary/dict.php?phrase=%eb%ee%e3'); на данный момент не полностью реализована в силу меньшей приоритетности, чем работа самой системы. Целью разработки системы логирования является контроль вызываемых методов в БД, их анализ и последующее отображение в разрабатываемом инструменте мониторинга. Ввиду того, что подсистемы разработаны различными программистами, интерпретировать информацию ИАС МКР необходимо с учетом специфики каждой подсистемы.

Для хранения (логирования) информации для подсистемы мониторинга ИАС МКР необходимо расширить текущее логирование в соответствии в тем, как оно реализовано в системе на данный момент, а именно, с помощью триггеров. Логирование на триггерах применяется в ИАС МКР ввиду простоты реализации и хранения. Триггером является процедура, которую пользователь не вызывает непосредственно, а исполнение которой обусловлено действием по модификации данных.

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

Редактированием является обновление данных, то есть повторный вызов функций. Редактирование необходимо разделять на уровне БД на редактирование кубов (перепостроение) и сервисов (обновление интеграции). Далее данные необходимо разделять на результаты отработки методов (успешно, не вызван, в процессе, ошибка). Для логирования необходимо создать таблицы, идентичные по структуре с логируемыми (см. пример на рисунке 2.3). В таблицы необходимо добавить поля:

1. Тип операции.

2. Дата операции.

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

Рисунок 2.3 Пример структуры таблицы-клона для хранения изменений в таблицах схемы данных для таблицы «Сервисы»

2.6 Проектирование интерфейса мониторинга систем ИАС МКР

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

2.6.1 Проектирование навигационной панели

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

1. Навигационная панель подсистемы должна быть доступна и видна всегда.

2. Навигационная панель должна включать в себя иконку системы и наименование подсистемы.

3. На панели должен быть размещен функционал для выхода из подсистемы к перечню всех подсистем.

4. На навигационной панели подсистемы мониторинга систем необходимо расположить перечень показателей, наименование и методика расчета которых описана ниже (см. таблица 2.2). Составлен следующий перечень показателей (см. рисунок 2.4):

4.1 Среднее время отклика системы.

4.2 Количество пользователей on-line.

4.3 Максимальное количество пользователей за текущие сутки.

4.4 Общая пользовательская нагрузка на систему за …

4.4.1 В моменте

4.4.2 Последние 10 часов

4.4.3 Последние 11 часов

4.4.4 Последние 12 часов

4.4.5 Последние 13 часов

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

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

Таблица 2.2

Перечень общих показателей работоспособности системы ИАС МКР

№ п/п	Наименование показателя	Методика расчета	Единица измерения	Отображение индикатора в интерфейсе
1	Среднее время отклика системы	Отношение общего времени обработки запросов пользователей к количеству всех запросов за минуту.	Секунда	Зеленый - среднее время отклика системы находится в диапазоне от 0 до 0,2 секунд
				Желтый - находится в диапазоне от 0,2 до 0,5 с
				Красный - находится в диапазоне от 0,5 и более с
2	Количество пользователей on-line	Количество аутентифицированных пользователей системы, обращающихся к back-end в текущий момент времени. Расчет берется за последнюю минуту.	Пользователь	Синий - количество пользователей on-line находится в диапазоне от 0 до 1500
				Желтый - находится в диапазоне от 1501 до 3000
				Красный - находится в диапазоне от 3001 и более
3	Максимальное количество пользователей за текущие сутки	Максимальное количество аутентифицированных пользователей системы, обращающихся к back-end за текущие сутки.	Пользователь	Зеленый - число уникальных пользователей не превышает 1500
				Желтый - число находится в диапазоне от 1501 до 3500
				Красный - число равно 3501 и более
4	Общая пользовательская нагрузка на систему: · В моменте · За последние10 ч. · За последние 11 ч. · За последние 12 ч. · За последние 13 ч.	Рассчитывается из «Среднее время отклика системы» и сопоставляется со шкалой баллов.	Балл	Зеленый - общая нагрузка на систему находится в диапазоне от 0 до 2 баллов
		3 балла - от 0,2 до 0,3 секунды; 4 балла - от 0,3 до 0,4 секунды; 5 баллов - от 0,5 до 0,6 секунды;		Желтый - общая нагрузка на систему находится в диапазоне от 3 до 6 баллов
		6 баллов - от 0,7 до 0,8 секунды; 7 баллов - от 0,8 до 0,9 секунды; 8 баллов - от 1 до 1,2 секунды;		Красный - общая нагрузка на систему находится в диапазоне от 7 до 9 баллов
		9 баллов - от 1,2 до 1,4 секунды; 10 баллов - более 1,4 секунды.		Бордовый - общая нагрузка на систему находится в диапазоне от 9 до 10 баллов
5	Число интеграций	Число получений данных из внешних источников / число распаковок за последние 24 часа	Штука	Показатель не отображается в интерфейсе цветовым индикатором. Шаблон отображения: «n / m», где n- число успешных, m - общее число
6	Число рассчитанных кубов	Число успешно построенных кубов за последние 24 часа / всего построений кубов	Штука	Показатель не отображается в интерфейсе цветовым индикатором. Шаблон отображения: «n / m», где n- число успешных, m - общее число

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

Рисунок 2.5. Макет графика детализации показателя работоспособности

Фильтр данных должен позволять выбирать ...