Файл: Разработка системы сбора и анализа данных о пользовательском поведении.docx
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 30.10.2023
Просмотров: 180
Скачиваний: 2
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
СОДЕРЖАНИЕ
Глава 1. Теоретическое обоснование и актуальность проблематики
Анализ современных систем метрик активности
Глава 2. Исследование проблемы
2.1. Анализ современных систем отслеживания активности пользователя
2.2. Анализ возможных решений для улучшения отслеживания активности пользователей
2.3. Обоснование выбранного решения путем анкетирования
3.1. Общее описание архитектуры системы
3.3. Диаграммы сценариев и последовательностей
3.5. Последовательность интеграции модуля в клиентскую часть пользовательского приложения
3.6. Последовательность интеграции серверной части системы
2.3. Обоснование выбранного решения путем анкетирования
Среди разработчиков ПО было проведено анкетирование [5][6][10], образец анкеты приведён в Приложении 4. Известно, что руководство медицинской организации сильно обеспокоено конфиденциальностью и безопасностью данных о пользовательской активности в программных продуктах, которые использует медицинский персонал. Проверим [19], насколько команда разработчиков согласна с обеспокоенностью руководства их основного клиента.
Для этих целей проведём анкетирование [7][8][9].
В анкетировании участвовало 47 человек. Должности от руководителя до младшего разработчика. Людей, не принимающих непосредственное участие в разработке среди опрашиваемых нет. Небольшая часть разработчиков отказалась участвовать.
Рис. 1. Собственное решение или стороннее
Рис. 2. Доверие к сторонним решениям
Как видно из диаграмм на рис. 1 и рис. 2, в настоящий момент, большинство респондентов, участвуют в проектах, которые используют облачные решения, не отвергают их на корню, однако доверия данные решения не вызывают. Однако вместе с тем, более половины считают, что доверять облачным сервисам пользовательскую аналитику довольно рискованно.
Рис. 3. Варианты системы
Вопрос на рис.3 направлен на выяснение, какая причина могла бы сподвигнуть команду для внедрения своей системы учета активности. Вопрос не давал множества вариантов, респонденты выбирали только одну главную причину. Такая вариативность говорит о том, что все варианты одинаково важны, что означает что при выборе варианта системы респонденты хотят удовлетворить все потребности.
Рис. 4. Готовность реализовать
Рис. 5. Предпочтение независимого решения
Согласно ответам на группу вопросов изображенных на рис.4 и рис.5, большинство респондентов затруднились ответить на поставленные вопросы. Можно сделать вывод, что по вопросам ресурсов и выбору конкретных технологий, в большинстве случаев в команде принимает решение руководство.
Рис. 6. Безопасность и конфиденциальность
Рис. 7. Конфиденциальность и правила защиты
85% считает вопросы на рис.6 и рис.7 безопасности и конфиденциальности очень важным. И действительно, в программном обеспечении для медицинских нужд эти два аспекта информационной политики сложно переоценить.
Рис. 8. Обеспокоенность утечкой данных
Рис. 9. Обеспокоенность возможными утечками данных
Большинство респондентов беспокоятся о возможных утечках данных и неавторизованном доступе к данным о пользовательской активности.
Это может указывать на то, что респонденты ценят безопасность данных и склонны к выбору решений, которые предлагают улучшенные функции защиты данных. Это может включать в себя как использование сторонних решений с хорошей репутацией в области безопасности, так и рассмотрение возможности создания собственного решения для аналитики пользовательской активности.
Рис. 10. Контроль над хранилищем персональных данных
Рис. 11. Использование хранилища внутри организации
82% респондентов одобряют контроль над хранилищем персональных данных. 87% считают, что контроль должен осуществляться на оборудовании внутри организации. Это означает, что разработчики ценят безопасность и приватность данных и предпочитают иметь полный контроль над хранением и обработкой данных пользователей.
Рис. 12. Выбор собственной системы анализа
Рис. 13. Оценка преимуществ своей системы анализа
Большинство респондентов хотели бы иметь возможность полностью владеть и контролировать данные аналитики активности пользователей. Однако 74% затруднились оценить ответить на вопрос в контексте аналитики.
Это говорит о том, что респонденты возможно понимают, что сначала надо попробовать готовое новое решение, а уже потом делать выводы о преимуществах.
Рис. 14. Возможные проблемы
Вариативность ответа на данный вопрос подтверждает осведомленность респондентов о возможных проблемах при внедрении своей системы.
Рис. 15. Оценка важности системы аналитики в целом
74% понимают преимущества, которые будут получены после реализации собственного решения, с локальным хранилищем и внутриорганизационной поддержкой. Очевидно, в целом сотрудники поддерживают такое решение и считают его важным.
2.4. Итоги исследования
В итоге, сделав гипотезу, предположив возможное решение и сделав опрос предполагаемых пользователей системы, появилось основание считать, что выбранное решение будет эффективным. Результаты анкетирования показали, что система, если будет сделана качественно, будет востребована прежде всего у сотрудников, которые работают над созданием ПО. Остается разработать само приложение и убедиться во всем на практике.
Глава 3. Разработка
3.1. Общее описание архитектуры системы
Архитектура [13] нашего решения состоит из js-модуля, который внедряется в приложение, для которого нужна регистрация активности и веб-сервиса, работающего в режиме приема статистических данных о пользовательской активности, а также части, отдающей SPA приложение и данные для формирования отчетов по REST запросу.
Архитектура клиент-серверная, клиентская часть представляет собой пользовательское приложение, а серверная часть обеспечивает сбор и анализ данных о пользовательском поведении.
Более подробное описание элементов архитектуры:
-
JS-модуль регистрации активности, который может быть внедрён в любое веб приложение. -
Серверную часть представляет собой центральный узел системы, ответственный за прием, хранение и обработку данных, полученных от модуля регистрации активности. Серверная часть обеспечивает функциональность сбора, хранения и анализа данных о пользовательском поведении. -
Клиентская часть системы интерфейс, через который пользователи взаимодействуют с системой. Клиентская часть отвечает за сбор и передачу данных о пользовательском поведении на сервер. -
Хранилище данных: так как данных не очень много, используется модуль, который просто умеет загружать и выгружать данные в текстовом файле, каждая строка которого описывает одну сущность пользовательской активности. -
Сервисы обработки и анализа данных предназначен для предварительной обработки и упаковки полученных от модуля регистрации данных. Они используют линейную агрегацию для отчетов.
Взаимодействие между компонентами системы происходит в соответствии с архитектурой REST, которая обеспечивает ясную и эффективную передачу данных между модулями системы.
Сущность в системе всего одна, это EventData. Однако для неё потребуется пять Data Transport Objects (DTO), соответствующих каждому отчету.
Отобразим выделенные сущности и их зависимости в ER диаграмме, Рис. 22.
Рис. 16. ER диаграмма
C точки зрения хранения данных сущностей, построим DFD диаграмму на рис.16.
DFD диаграмма сервера представлена на рис.17.
Рис. 17. DFD диаграмма веб-сервиса
Процессов в нашей системе, относительно сохранения и отображения данных о пользовательской активности не очень много. Поэтому можно отобразить всю REST архитектуру в одной BPMN 2.0 диаграмме на рис.18.
Рис. 18. BPMN 2.0 диаграмма
Таким образом мы описали довольно подробно архитектуру системы. Однако для выполнения задуманного ещё нужно разработать конкретное техническое задание.
3.2. Техническое задание
Цель системы состоит в сборе, хранении и анализе данных о поведении пользователей веб-приложений медицинской организации.
Область системы
Система должна быть развернута в рамках веб-проекта.
Данные должны быть сохранены на сервере организации.
Заинтересованные стороны:
-
Конечные пользователи: Пользователи, взаимодействующие с продуктом организации -
Разработчики: Технический персонал, ответственный за интеграцию, обслуживание и обновление системы -
Аналитики: Сотрудники, ответственные за анализ собранных данных о поведении пользователей -
Администраторы системы: Технический персонал, ответственный за обслуживание сервера и обеспечение безопасности системы
Системные требования:
-
Операционная система: Windows 10 64-разрядная -
Процессор: Intel Core более высокого уровня, чтобы обрабатывать одновременные запросы и обрабатывать данные -
Память (ОЗУ): 8 ГБ ОЗУ -
Хранилище: 1 ТБ ssd -
Сеть: Стабильное и быстрое интернет -
База данных: текстовый файл -
Требования к программному обеспечению: .NET Core для запуска IIS веб сервера