Введение Постановка задачи. Прикладная система - это программное обеспечение, предназначенное для выполнения задач предметной области с помощью интерфейса между человеком и компьютером [1]. Некоторые прикладные системы позволяют изменять или расширять их функциональность с помощью плагинов, т. е. программных модулей, которые динамически подключаются к основной программе и предназначены для расширения и (или) использования её возможностей. В настоящее время многие компании для формализации рабочих процессов и обеспечения выполнения работ в срок и в надлежащем качестве используют разнообразные прикладные системы. Руководство компаний может быть заинтересовано в получении актуальной информации о том, как их сотрудники работают в таких прикладных системах, как CRM (Customer Relationship Management, система управления взаимоотношениями с клиентами), системы управления проектами, системы документооборота, системы электронного обучения, системы поддержки пользователей (Help Desk, Service Desk) и др. В системах электронного обучения и поддержки пользователей может быть интересна статистика, касающаяся не только сотрудников, но и клиентов, а также любых других объектов, о которых собирается информация. В рамках нашего исследования все учётные записи в прикладных системах рассматриваются как учётные записи пользователей, у которых есть свои различные задачи, действия, цели, свойства характера и пр. Интересно также рассмотрение различных типов пользователей, определение их потребностей и доработка прикладной системы для их удовлетворения. Проблемы в работе сотрудников с прикладными системами, замеченные вовремя, позволят снизить риски, которые могут привести к невыполнению задач в срок или несоответствующему качеству их выполнения (например, из-за нечёткого разграничения ответственности, неправильной расстановки приоритетов, отсутствия организационной политики, искажения данных о выполняемой работе). На основе данных статистики можно определить, сколько времени тратит сотрудник на выполняемые задачи, достаточно ли трудовых ресурсов и их квалификации для выполнения работ; выявить ошибки оценки бюджета, ресурсов, трудозатрат, сложности, сроков выполнения работ в прикладных системах [2]. Задачей нашего исследования было создание инструмента для сбора статистики и анализа запросов пользователей при работе с прикладными системами на примере Redmine - информационной системы для коллективной работы [3]. Исследования проводились на основе технологий и алгоритмов, разработанных в рамках положений по управлению проектами с использованием глоссария, предложенного в [4]. Собранная информация может быть полезна для планирования и контроля работы пользователей системы, принятия управленческих решений и доработки прикладной системы. Кроме того, она позволит собрать ряд метрик использования системы, например: какие функции системы наиболее часто используются, сколько пользователей находилось в системе в заданный период. Для этого потребуется собирать статистику посещений и определять пути пользователей в приложении (т. е. последовательность запросов каждого пользователя). Принципы работы предлагаемого инструмента Созданный инструмент является плагином для Redmine. В то же время предлагаемые подход и алгоритмы могут быть применены и для других прикладных систем. Благодаря открытому коду Redmine, его можно дорабатывать под собственные нужды. Пользователи могут в этой системе создавать проекты и задачи, добавлять новости, файлы и комментарии, разрабатывать документацию, отмечать трудозатраты, заниматься планированием работ, в том числе с помощью диаграммы Ганта. Система позволяет подразделять задачи по категориям, трекерам (типам), статусам, приоритетам и др. Задачи могут быть связаны с изменениями (коммитами) в репозитории. Предлагаемый плагин использует ту же среду разработки, что и Redmine (Ruby и Rails). Код предлагаемого инструмента приведён в [5]. Далее слово «контроллер» (controller) употребляется в том же значении, что и в среде Rails: класс в программном коде, обрабатывающий запросы пользователей и отправляющий результаты обработки. Action - это функция (метод) контроллера, связанная с обработкой пользовательских запросов определённого вида. В контроллере может быть несколько таких функций, объединённых общей предметной областью или по другим признакам. Модуль анализа статистики включает в себя алгоритмы вычисления метрик и статистического анализа, в частности поиск ассоциаций (для поиска сочетаний запросов, которые чаще всего выполняются в течение одной сессии). Под словом «метрика» в рамках нашего исследования понимается вычисляемое значение или набор значений на основе статистики, характеризующие некоторые её свойства. В качестве примеров анализа статистики в этом плагине реализованы следующие метрики: - количество просмотров за день или зáданный период (количество запросов к сайту или определённой странице); - количество визитов за день или зáданный период (количество сессий просмотров); - количество посетителей за день или зáданный период (количество пользователей, открывших сайт/страницу в зáданный период); - количество просмотров по источникам переходов (в том числе по подсистемам - по названию контроллера: главная страница, поиск, список проектов и т. д.); - пути просмотра и глубина просмотра (количество страниц, открытых одним пользователем за один визит); - наиболее посещаемые страницы (в т. ч. по сочетанию controller и action); - страницы входа (с какой страницы начался просмотр) и выхода (какой страницей он закончился). В качестве критериев составления путей используются следующие: - сессия описывает запросы только одного пользователя; - между загрузками страниц за одну сессию проходит не более 30 минут. Это не новые метрики, а уже известные по продуктам компаний Яндекс и Google, которые предлагают решения для сбора статистики и анализа всего сайта. Эти решения имеют недостаток: им недоступен код и данные исследуемой прикладной системы, а доступно только то, что получает браузер. Кроме того, эта статистика хранится в Интернете (вне сервера, на котором размещён сайт), что может быть расценено как угроза безопасности. Предлагаемый инструмент позволяет собирать и анализировать статистику запросов, используя код и базу данных интегрируемой системы, что позволит получать и обрабатывать более детальную статистику. Вся собранная информация хранится в базе данных системы, в которую она интегрирована. Плагин для Redmine для сбора статистики о запросах пользователя redmine_access_logger [6], аналогичный по принципу работы, предназначен только для сбора информации и не может быть использован полноценно - для анализа полученной статистики. Он записывает посещения в текстовом файле, что затрудняет операции группировки, поиска и т. п.; не сохраняет адрес страницы и источник перехода на текущую страницу. Плагин для сбора и анализа статистики, предлагаемый в этой работе, встраивается в последовательность обработки запросов к прикладной системе Redmine, благодаря чему в базу данных записывается каждый запрос к ней, кроме запросов на чтение изображений и файлов CSS и JS. В ходе установки разработанного плагина создаётся таблица logs для хранения записей об обращениях (табл. 1). Таблица 1 Структура таблицы logs Атрибут таблицы logs Тип значения Комментарий id Целое число Уникальный номер записи, первичный ключ http_method Строка HTTP-метод (GET, POST и др.) query Строка URI, кроме названия домена parameters Строка Параметры запроса из адресной строки и отправленной формы, записанные в виде JSON user_id Целое число Номер пользователя в системе, внешний ключ response_code Целое число HTTP-код ответа (200, 404 и др.) created_at Дата и время Дата и время создания записи updated_at Дата и время Дата и время последнего изменения записи controller Строка Название контроллера, обрабатывающего запрос referer Строка URI источника перехода на текущую страницу referer_controller Строка Название контроллера источника перехода на текущую страницу first_id Целое число Номер записи в таблице logs, с которой началась текущая сессия В интерфейсе Redmine появляется параметр, включающий или отключающий сбор статистики, его можно найти на странице настроек плагина. Тестирование Для тестирования созданного плагина была подготовлена среда разработки на основе Redmine 3.0.1, Ruby 2.1, PostgreSQL 9.3.6. Для заполнения таблицы тестовыми данными были взяты реальные данные у компании, внедрившей этот инструмент. Данные были обезличены и не содержат конфиденциальную и персональную информацию, по которой возможно идентифицировать человека [7]. Тестовые данные содержат в себе запросы 121 пользователя за 7 дней, всего 34 461 запись. Были протестированы обе составляющие плагина: сбор статистики и анализ статистики. В базу данных записывалось каждое обращение к серверу (это можно отследить по количеству запросов в браузере и количеству строк в таблице logs, используемой для хранения статистики). Как показало тестирование, во всех случаях плагин правильно записывает данные, кроме одного: когда не запущен Redmine или СУБД (в этом случае и Redmine не работает). Сбоев не обнаружено. Плагин также определяет и записывает дополнительную информацию о запросе: код ответа, название контроллера, обрабатывающего текущий запрос (если он был определён по адресу запроса), адрес источника (если браузер передаёт эту информацию), контроллер источника (определяется всегда, кроме случаев, когда браузер не передаёт адрес источника или когда источником не является данный запущенный экземпляр Redmine). Для проверки алгоритмов анализа статистики сравнивались результаты, выдаваемые плагином, с результатами, полученными при выполнении SQL-запросов и ручных операций. Например, для получения количества строк в таблице можно использовать функцию SQL count; для получения путей просмотра, страниц входа и выхода можно фильтровать записи по значению столбца first_id, в нём хранится id первой записи данной сессии. Модуль анализа статистики определяет количество просмотров по количеству записей в таблице logs (можно фильтровать выборку по датам, пользователям и т. д.). Количество визитов определяется по количеству записей, которые являются первыми в сессии. Количество посетителей считается как количество уникальных посетителей, т. е. количество первых заходов посетителей в течение всего заданного периода. Для определения сочетаний запросов, которые чаще всего выполняются в течение одной сессии, нужно решить задачу поиска ассоциаций. Для этого предлагается использовать алгоритм Apriori [8, 9]. На вход этого алгоритма подаётся набор данных, называемых транзакциями. Каждая транзакция содержит список строк, состоящих из названия HTTP-метода и адреса (query) по каждому пользовательскому запросу за одну сессию. Алгоритм составляет набор правил, т. е. ассоциативных выражений вида , где X и Y - наборы элементов транзакций; support - доля транзакций, содержащих X и Y («поддержка»), среди всех транзакций; confidence - доля транзакций, содержащих Y, среди транзакций, содержащих X. Результатом работы алгоритма является набор правил, удовлетворяющих заданным параметрам работы алгоритма: min_support (минимальное значение поддержки) и min_confidence (минимальное значение достоверности). Результаты, полученные в ходе тестирования алгоритмов анализа статистики, приведены в табл. 2-5: в табл. 2 - количество просмотров, визитов и посетителей, в табл. 3 - список контроллеров и количество обращений по ним, в табл. 4 - самые частые запросы при тестировании, в табл. 5 - ассоциативные правила при параметрах алгоритма Apriori min_support = 0,01 и min_confidence = 0,6. Таблица 2 Количество просмотров, визитов и посетителей (на основе тестовых данных) День Количество просмотров визитов посетителей 1 255 9 7 2 102 4 4 3 6 652 439 104 4 7 117 395 106 5 6 769 370 101 6 9 752 381 102 7 3 814 169 89 Всего уникальных 34 461 1 767 121 Сумма по дням 34 461 1 767 513 Таблица 3 Контроллеры с наибольшим количеством обращений (на основе тестовых данных) Таблица 4 Самые частые запросы (на основе тестовых данных; выборка по controller и action) Контроллер Количество просмотров issues 18 905 screen 3 147 my 1 637 attachments 1 469 projects 811 repositories 757 bulk_time_entries 680 account 666 users 653 search 463 Действие Количество просмотров issues#show 9 541 issues#index 4 506 screen#index 3 174 issues#edit 2 359 issues#update 2 071 my#page 1 752 issues#update_form 1 379 attachments#thumbnail 954 account#login 769 issues#new 595 Таблица 5 Ассоциативные правила по результатам тестирования X (левая часть ассоциативного правила) Y (правая часть ассоциативного правила) Confidence (достоверность) POST /projects/devcawm/issues GET /projects/devcawm/issues/new 1,0 GET /issues?page=2&set_filter=0 GET /issues?set_filter=0 0,97 POST /issues/bulk_update POST /issues/bulk_edit.js 0,97 POST /issues/bulk_edit.js POST /issues/bulk_update 0,97 GET /login GET / 0,95 GET /projects?level_limits[]=118&level_limits[]=117&offset=25&page=2 GET /projects 0,95 POST /projects/devcawm/issues/update_form.js GET /projects/devcawm/issues/new 0,91 POST /projects/accounts/issues GET /projects/accounts/issues/new 0,89 GET /projects/devcawm/issues/new POST /projects/devcawm/issues/update_form.js 0,88 POST /projects/accounts/issues/update_form.js GET /projects/accounts/issues/new 0,82 POST /issues GET /issues?set_filter=0 0,7 По результатам статистического анализа тестовых данных можно сделать вывод о том, что на этом наборе данных самая востребованная часть системы - это работа с задачами (issues). Отметим, что 9 из 11 найденных ассоциативных правил связано с просмотром и редактированием задач. Выводы Использование доработанного программного обеспечения для управления проектами позволило ускорить разработку инструмента для анализа запросов пользователей и его тестирование на типовых данных. Представленный инструмент, выполненный на примере Redmine, показывает, что предлагаемое решение может эффективно использоваться различными пользователями при анализе больших объёмов данных, собираемых в прикладных системах. Созданный продукт может быть применён в текущей работе в управлении проектами для анализа ситуации и разработки управленческих решений. Собранная статистика может быть полезна для разработчиков систем коллективной работы и систем управления проектами, в том числе для разработки средств планирования и контроля. Возможно ограничить сбор статистики по критерию «Количество пользователей» и другим критериям. Применённый подход и созданные алгоритмы могут быть использованы при разработке других приложений.