Разработка информационной системы анализа турнирных результатов спортсменов

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

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

· Автоматизированная информационная поддержка принятия решений;

· Автоматизированный учет, планирование и управление ресурсами спортивной отрасли;

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

· Разработка методического обеспечения создания автоматизированных инструментов управления спортивным предприятием для анализа эффективности тактических решений и вариантов маркетингового поведения;

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

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

Также, в случае ориентированности информационной системы на конечного пользователя, особенно выделяется значимость наличия удобного и интуитивно понятного интерфейса [22]. В исследовании, проведенном относительно желания пользователей обращаться к информационному сервису национальных игр Чжанхуа (Тайвань), авторам удалось выявить, что пользователи в основном полагались на стабильность системы для получения требуемой информации. Высокое качество проработки системы позволило пользователям с легкостью взаимодействовать с интерфейсом программы и получать оперативные ответы сервиса. Таким образом, именно качество системы вкупе с удобством интерфейса оказывают значительное влияние на желание пользователя обращаться к услугам данного сервиса вновь.

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

цифровой интерфейс сервер аналитика

Глава 2. Анализ требований к системе

2.1 Системы оценивания участников на соревновании

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

Рисунок 2.1 Турнирная таблица оценок WDSF Grand Slam Moscow 2019

На приведенном выше рисунке проиллюстрирована итоговая таблица позиций участников в турнире классификации Grand Slam и их оценками за каждый танец. Пара под номером 120 приняла участие в трех турах данного соревнования (1/64, 1/32, 1/16). На стадии 1/16 паре удалось набрать 44 креста для прохода в 1/16 (пороговое значение для прохода в следующий тур на данном этапе составляло 33 креста). В своем последнем туре данной парой было набрано 13 крестов, а пороговое значение для прохода в следующий тур было 26 крестов - 50% от требуемого количества. Можно заметить неравномерное распределение крестов по танцам (в то время как за первые три танца пара получила в сумме только 5 крестов, за один последний танец ей удалось набрать такое же количество крестов от судейской коллегии). В силу того, что набранное количество крестов не проходит пороговое значение, пара выбывает из участия в соревновании на данном этапе.

Также, в последних турах соревнования (финалы международных турниров и заключительные туры особо крупных соревнований) имеют другую систему оценивания. Например, в финальных турах международных соревнований арбитры используют уже не бинарную систему, а оценивают участников по шкале, размер которой соответствует количеству участников финального тура. Поставленная оценка в таком случае отвечает за итоговое место, которое выбрал член жюри для пары в конкретном танце программы. Официальное названия системы оценивания такого типа «Skating system» [23]. Существует и другая система оценивания, которая применяется на финальных стадиях особо крупных турнирах - оценка каждой пары по определенным параметрам исходя из 10-ти балльной шкалы (Judging System 3.0 [24]).

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



Рисунок 2.2 Мировой рейтинг WDSF категории любители в программе Европейских танцев

2.2 Существующие сервисы, обеспечивающие аналитику результатов спортсменов

Основным источником для проведения анализа спортивных результатов международных турниров на сегодняшний день является сводка с официального сайта федерации wdsf.com о конкретном турнире (пример приведен на рис 2.1). По своей сути это обычная турнирная таблица, которая представлена в виде матрицы (по горизонтали расположены участники соревнования, а по вертикали - члены судейской коллегии). В ячейке пересечения этих параметров показывается оценка члена судейской коллегии за отдельный танец (рис 2.3).

Из приведенного примера на данном рисунке видно, что в данном туре за конкретный танец Судьи №1, №3 и №6 поставили участникам кресты, тем самым показали свое намерение увидеть эту пару в следующем туре, в то время как Судьи №2, №4 и №5 не оценили выступление пары в конкретном танце и не поставили им оценку на выход в следующий тур. Таким же образом формируются оценки и по всем остальным танцам программы и по совокупности определяется, проходят ли участники отбор данного тура.

Рисунок 2.3 Пример таблицы с оценками

По своей сути это простая визуализация оценивания судейской коллегии, на основе которой участники соревнования могу судить об успешности своего выступления на турнире. Однако этими сводками результатов с сайта вся предоставляемая федерацией информация касательно выступления участников заканчивается. Никакая более глубокая аналитика сервисом WDSF не предусмотрена, и оценивание результатов спортсменам приходится делать вручную. Помимо этого, зачастую это действительно сложно сделать с помощью подручных средств, так как сайт федерации не является адаптивным - интерфейс таблиц оценок не подстраивается под девайс, с которого заходит пользователь. Поэтому множеству спортсменов чрезвычайно неудобно пользоваться этим сервисом с подручных средств (телефон, планшет и др.). Это обусловлено тем, что в большинстве случаев участники находятся в поездках или, например, непосредственно на турнире и доступа к персональному компьютеру не имеют. Вследствие этого получить требуемую пользователями информацию своевременно не удается. Таким образом, у данного источника информации можно выделить несколько недостатков:

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

· Неудобный для пользования интерфейс;

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

Рисунок 2.4 Аналитика судейства сервисом ballroom.ru

Данная диаграмма показывает анализ судейства каждого члена жюри для определенной пары. Можно сделать вывод, что судья №9 относился к выступлению пары наиболее положительно, в то время как судья №1 - наиболее отрицательно. Эта информация может быть полезной для участников, но, по существу, данная аналитика предназначена для спортивной организации и организаторам конкретного турнира и не направлена на потребление конечным пользователем. Кроме этого, она поступает в общий доступ только спустя некоторое продолжительное время после проведения турнира. Более того, стоит отметить, что данный веб-ресурс также не адаптирован под мобильные девайсы, это обычный веб-сайт с весьма устаревшим интерфейсом, который в основном предназначен для взаимодействия с персонального компьютера. Еще одним недостатком этого сервиса является то, что он ориентирован на российскую индустрию танцевального спорта и описанную выше аналитику для зарубежных турниров и некоторых внутренних турниров классификации WDSF он не предоставляет.

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

2.3 Проведение анкетирования среди спортсменов

Для подтверждения значимости разработки ИС для аналитики турнирных результатов, а также определения основного функционала такой системы было проведено анкетирование среди спортсменов с помощью сервиса Google Forms. Опрос включает в себя основные вопросы касательно удовлетворенности пользователей от взаимодействия с существующими сервисами, а также затрагивает потребность в разработке специальной информационной системы и ее функционала. В анкетировании приняло участие более 120 спортсменов, основной контингент составляет Москва (приблизительно 60% опрошенных). Это неудивительно, танцевальный спорт гораздо более развит именно в столичном регионе по сравнению с остальными. Полные результаты опроса изложены в Приложении 1.

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

Более двух третьих опрошенных принимают участие в заграничных турнирах.



Рисунок 2.5 Круговая диаграмма участия в заграничных турнирах

Рисунок 2.6 Круговая диаграмма влияния судейской коллегии на участие в турнире

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

Рисунок 2.7 Круговая диаграмма аналитики турнирных результатов

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

Рисунок 2.8 Круговая диаграмма удобства пользования сервисом WDSF

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

Рисунок 2.9 Круговая диаграмма осведомленности спортсменов о существования сервиса ballroom.ru

Примерно четверть спортсменов в принципе не знает о существовании сервиса для аналитики независимости оценивания судьи на турнире, предоставляемого сайтом ballroom.ru, что свидетельствует о низком уровне востребованности данного сервиса.

Рисунок 2.10 Круговая диаграмма частоты пользования сервисом ballroom.ru

Всего 21% опрошенных регулярно пользуется услугами данного сервиса. Порядка 40% спортсменов знают о его существовании, но тем не менее очень редко обращаются к нему. И практически 20% принявших участие в опросе утверждают, что не понимают аналитику, который предоставляет данный сервис. Это свидетельствует о сложности предоставляемой информации и, как итог, снижения уровня лояльности пользователя по отношению к сервису в целом.

Рисунок 2.11 Круговая диаграмма потребности спортсменов в системе для аналитики

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

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

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

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

2.4 Описание разрабатываемой системы

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

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

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

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

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

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

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

· Получение данных с сервиса WDSF;

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

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

· Формирование графиков, содержащих запрашиваемую информацию;

· Взаимодействие с внешними сервисами для автоматизации процессов;

Заинтересованные в реализации данного проекта лица можно разделить на две категории:

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

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

После формирования бизнес-требований проекта следует обратить внимание на пользовательские требования, описывающие данный проект с точки зрения пользовательских задач, которые должна решать разрабатываемая система и описания ее поведения с помощью сценария использования (Use Case) [26].

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

· Регистрация пользователя;

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

· Получение запрашиваемой информации

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

Рисунок 2,13 Диаграмма взаимодействия прецедентов системы

Таблица 2.1 иллюстрирует виды возможных отношений между прецедентами:

Таблица 2.1 Виды связей прецедентов

Обозначение связи	Описание
<<include>>	Вызов исходного прецедента включает в себя функциональность целевого элемента.
<<invoke>>	Вызов исходного прецедента в определенный момент вызывает выполнение целевого элемента
<<extend>>	Целевой прецедент расширяет поведение исходного

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

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

· Пользователю должна быть предоставлена возможность зарегистрироваться или авторизоваться;

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

· Пользователю должна быть доступна возможность удобного пополнения баланса внутри приложения;

· Система должна предоставлять следующую аналитику:

o Подробная информация по выступлению спортсменов на последних турнирах;

o Аналитика предрасположенности члена судейской коллегии к определенной паре;

o Выведение удобных информационных графиков;

o Прогнозирование места спортсменов на турнире исходя из состава участников и состава судейской коллегии;

o Динамика изменения позиции пары в общем рейтинге WDSF;

Нефункциональные требования отвечают за набор характеристик разрабатываемой системы и производительность их выполнения. Данный свод требований необходим для описания качества функционирования всей системой в целом. Атрибутами для оценки качества разрабатываемой системы являются:

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

· Актуальность информации, предоставляемой пользователям;

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

· Быстрое взаимодействие с внешним источником для проведения платежа и обеспечение его надежности;

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

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

2.5 Классификация требований к разрабатываемой системе

С точки зрения успешности реализации ИС, факторы влияющие на ее воздействие на организацию были подробно разобраны в первой главе данного исследования - это качество реализации самой системы, качество информации, используемой системой, и качество сервиса, обслуживающего ее. Для более четкого определения требований к самой системе существует специальный подход классификации FURPS+ [27]. Это аббревиатура, где за каждой буквой стоит требование к системе:

· Functionality - функциональные требования к системе, которые описывают основные функции и свойства системы;

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

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

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

· Supportability - требования поддерживания системы, связаны с адаптивностью к внешней среде, гибкой возможностью настройки и модификации, масштабируемостью и локализацией продукта;

· Ограничения («+» в аббревиатуре):

o Design - ограничения в проектировании, определяют и ограничивают основные технологии, которые должны быть использованы в системе;

o Implementation - ограничения в разработке, отвечают за использование только определенных программных средств и инструментов для реализации системы;

o Interface - ограничения интерфейса, определяют используемые в системе форматы данных и протоколы взаимодействия, внешние системы;

o Physical - физические ограничения, отвечают за всевозможные ограничения внешней среды, определяют физические ограничения используемой аппаратуры;

o И другие возможные ограничения;

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

Функциональность.

· Система должна представлять пользователю возможность зарегистрироваться при помощи почты или номера телефона;

· Система также должна предоставлять пользователю возможность авторизоваться в личном кабинете;

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

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

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

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

· В системе должна бать реализована поддержка различных языков;

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

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

· Система должна выводить графики, содержащие запрашиваемую пользователем информацию;

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

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

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

Удобство использования.

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

· Должна быть реализована защита от человеческого фактора;

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

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

· Информация, предоставляемая система, должна выводиться в удобном для восприятия формате;

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

Надежность.

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

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

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

· Система должна быть доступна 24 часа в сутки 7 дней в неделю;

Производительность.

· Система должна оперативно взаимодействовать с базой данных для извлечения запрашиваемой информации;

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

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

Поддерживаемость.

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

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

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

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

Ограничения.

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

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

Глава 3. Проектирование системы

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

3.1 Описание процесса работы системы

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

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

· Программным способом извлекать данные с сайта WDSF;

· Интегрировать взаимодействие с базой данных самой федерации для упрощения процесса получения данных;

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

Самой важной частью системы является аналитика турнирных результатов. Описанный ранее востребованный среди пользователей функционал в обобщенном виде включает в себя проведение аналитики, построение таблиц и графиков, а также предсказания будущих результатов. Все описанные функции должно производиться полностью автоматически, только с помощью программных средств. Поэтому для системы обязательно внедрение готовых или предварительно разработанных библиотек для реализации функционала. По факту, для большинства функций не требуется разработка сложных библиотек, потому что они формируют отчеты, основываясь на данных. То есть основная программная часть системы отвечает за непосредственную работу c данными без интеграции специальных алгоритмов. Однако для функционала, обеспечивающего предсказание занимаемой участником позиции на турнире, потребуется внедрение в программный функционал системы алгоритмов машинного обучения (например, линейная регрессия, решающих деревьев, случайных лесов и т. д.) [28]. Всю описанную часть работы системы можно отнести к «бэкенду» - программной составляющей системы, которая выполняется на стороне сервера.

Реализация вывода подготовленной информации для пользователя уже относится к «фронтенду» разрабатываемой системы. Сама система базируется на веб-сайте и на мобильных платформах IOS и Android, которые позволяют приложениям выводить удобные для просмотра таблицы и графики. Поэтому на данном этапе важна проработка самого сервиса с точки зрения пользователя - функциональность приложения и удобство его интерфейса.

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

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

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

Рисунок 3.2 Обработка данных сервером и выдача информации пользователю

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

3.2 Архитектура системы и ее компоненты

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

· Компонент регистрации новых пользователей или авторизации зарегистрированных;

· Компонент предоставления справочной информации о системе для пользователя;

· Компонент личного кабинета пользователя;

· Компонент произведения оплаты подписки;

· Компонент взаимодействия с внешними сервисами;

· Компонент настроек (нотификация, изменение аккаунта и пр.);

· Компонент получения запрашиваемой статистики пользователем;

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

В настоящее время распространено два подхода к построению архитектуры системы: монолитная и микросервисная архитектура.

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

· Клиентский пользовательский интерфейс;

· Серверное приложение, отвечающее за бизнес-логику;

· Взаимодействие с базой данных;

Рисунок 3.3 Монолитная архитектура системы

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

Плюсами реализации такой архитектуры являются:

· Простота разработки на начальном этапе;

· Простота тестирования и выявления ошибок;

· Простота масштабируемости и развертывания сервиса;

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

Однако, у монолитной архитектуры существует и ряд минусов, среди которых можно выделить:

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

· Усложнение внедрения новых технологий;

· Низкая гибкость системы в целом;

· Низкая надежность системы: возникновение ошибки в одно месте, может стать причиной сбоя всей системы;

Архитектура микросервисов подразумевает создание ряда автономных компонентов, которые слабо взаимосвязаны друг с другом [30]. Каждый компонент системы отвечает за четко поставленную перед ним задачу и направлен только на ее решение. В отличие от монолитной архитектуры, созданной как единое целое, микросеврисы по своей сути объединяют множество разрозненных независимых компонентов. Каждый компонент развернут как отдельный модуль в системе, что позволяет достигать более высокой гибкости системы. Также у такой архитектуры есть возможность интегрировать несколько единиц развертывания, соответственно каждый сервис развертывается самостоятельно. Еще одной отличительно особенностью микросервисной архитектуры в некоторых случаях является наличие собственной базы данных у каждого из компонентов системы, это позволяет достичь более слабой зависимости между отдельными сервисами.



Рисунок 3.4 Архитектура микросервисов

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

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

· Упрощение разработки, тестирования и внедрения;

· Повышенная гибкость системы;

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

· Простота понимания функционала для разработчиков;

· Загрузка системы производится быстрее;

· Независимые сбои, которые не сказываются на работе всей системы;

Однако, несмотря на значительное количество плюсов использования данной архитектуры, существуют и определенные недостатки:

· Сложность реализации, требует тщательного планирования;

· Проблемы безопасности;

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

· Возрастающее потребление памяти;

· Потребность во внедрении механизмов межсервисной коммуникации;

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

3.3 Реализация архитектуры

Так как в разрабатываемой системе будет реализована одна реляционная база данных, нужды в разделении баз данных для различных сервисов нет. Для эффективного взаимодействия клиента со всеми сервисами используется прослойка - proxy server (API), которая по своей сути представляет из себя описание способов для получения и отправки запросов на сервер. В большинстве интернет платформ на сегодня принято использования принципов REST для более упорядоченного взаимодействия клиентов с сервером посредством использования HTTP запросов [31]. Поэтому, для повешения производительности и эффективности системы следует использовать следующую архитектуру микросервисов:

Рисунок 3.5 Структура компонентов системы

Проиллюстрированная структура на рисунке 3.5 отображает взаимодействие всех компонент системы с сервисом API, к которому обращается клиент (мобильное приложение или веб-браузер). Запросы к некоторым сервисам включают в себя последовательные взаимодействия. Например, чтобы изменить настройки личного кабинета, пользователям требуется обратиться сначала к сервису личного кабинета, а только потом перейти в его настройки. Также из личного кабинета можно произвести оплату подписки, которая реализуется благодаря внешнему ресурсу - платежной системы, взаимодействие с которой тоже предусматривает наличие у такой системы API сервиса. Помимо этого, некоторые сервисы содержат в себе несколько компонентов - обращаясь к сервису аналитики для получения информации прогнозирования, сервис прогнозирования содержит сервис обработки и анализа данных. Для осуществления взаимодействия с базой данных используется подход CRUD, включающий в себя основной набор функций для работы с БД и относящийся к одним из принципов реализации принципам REST. Он реализует 4 операции: «create» - создание новых элементов, «read» - чтение и получение данных, «update» - обновление, редактирование информации и «delete» - удаление данных.

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

3.5 Проектирование базы данных

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

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

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

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

Итак, в базу данных разрабатываемой системы должны входить следующие сущности:

· Спортсмен;

· Танцевальная пара;

· Судья;

· Танец;

· Турнир;

· Тур;

· Результаты Турнира;

· Рейтинг;

Сущность «Спортсмен» описывает отдельно взятого спортсмена, который принимает участие в турнирах под эгидой WDSF. Данная сущность содержит в себе такие атрибуты: ID Спортсмена (PK), ID Пары (FK), MIN WDSF, Имя, Фамилия, Страна, Дата рождения, Категория, Лицензия.

Сущность «Танцевальная Пара» представляет из себя описание танцевальной пары, которая состоит из двух спортсменов: партнера и партнерши. В этой сущности содержатся следующие атрибуты: ID Пары (PK), ID Рейтинга (FK), ID Результаты Турнира (FK), Страна, Категория, Статус, Программа, Рейтинговые очки.

Сущность «Судья» описывает члена судейской коллегии, который оценивает турниры WDSF. Данная сущность содержит в себе следующие атрибуты: ID Судьи (PK), MIN WDSF, Имя, Фамилия, Национальность, Год Рождения, Страна Федерации, Фотография.

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

Сущность «Турнир» описывает целое соревнование WDSF, которое состоит из нескольких туров. Атрибутами данной сущности являются: ID Турнира (PK), Название, Город Проведения, Страна Проведения, Дата проведения, Организатор, Квалификация, Коэффициент, Статус.

Сущность «Тур» является описанием отдельного тура на соревновании WDSF и агрегатором описанных ранее таблиц. В данной сущности содержится информация об оценке, поставленной членом жюри танцевальной паре за отдельный танец в конкретном туре конкретного турнира. Поэтому она должна содержать в себе следующие атрибуты: ID Тура (PK), ID Турнира (FK), Раунд турнира, Система оценивания и Оценка.

Сущность «Результаты Турнира» отвечает за распределение мест на соревновании WDSF между участниками турнира. Данная сущность включает в себя: ID Результаты Турнира (PK), Номер Пары, Место, Базовые Рейтинговые Очки;

Сущность «Рейтинг» является описанием международного рейтинга танцевальных пар WDSF. Рейтинговых таблиц WDSF на самом деле существует много в зависимости от программы, категории участников и возрастов. Для простоты реализации будет использоваться единая таблица рейтинга, которую можно впоследствии разбить на несколько отдельных. Эта сущность включает в себя следующие атрибуты: ID рейтинга (PK), Категория, Возраст, Позиция, Программа, Дата Обновления.

После описания сущностей следует построить модель базы данных с отображением связей между сущностями для более удобной визуализации. Логическая модель базы данных представляет из себя модель БД без привязки к конкретной СУБД (совокупности программных и лингвистических средств, обеспечивающих управления базами данных). В этой модели описан основные объекты БД и определены связи между этими объектами. Логическая модель разрабатываемой БД показана на рисунке 3.6.

Рисунок 3.6 Логическая модель базы данных

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

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

3.6 Графический интерфейс системы

Одним из важных составляющих разработки системы является реализация ее клиентской части - пользовательского интерфейса. Как обозначалось в требованиях к системе, с точки зрения клиента будет реализовано два подхода - веб-сайт и мобильное приложение на платформе IOS и Android. Для удобства визуализации были разработаны упрощенные схемы прототипирования пользовательского интерфейса сервиса на мобильной платформе (рис 3.7) с учетом требований к системе и пользовательских сценариев взаимодействия с сервисом.



Рисунок 3.7 Схема экранов пользовательского интерфейса мобильной платформы

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

Для более глубокого понимания основного функционала сервиса был разработан прототип экрана выбора вида аналитики, и экранов предоставления пользователям подробной информации о турнирах и предрасположенности судей (экраны № 5, 8, 9 на рис 3.7).

Рисунок 3.8 Прототипы экранов аналитики и предрасположенности судей

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

...