Файл: Разработка системы сбора и анализа данных о пользовательском поведении.docx
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 30.10.2023
Просмотров: 1088
Скачиваний: 8
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
СОДЕРЖАНИЕ
Глава 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 веб сервера