МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ РОССИЙСКОЙ
ФЕДЕРАЦИИ
Федеральное государственное автономное образовательное учреждение
высшего образования
«Дальневосточный федеральный университет»
ШКОЛА ЕСТЕСТВЕННЫХ НАУК
Кафедра информационных систем управления
Максимов Валерий Александрович
СОЗДАНИЕ СИСТЕМЫ СБОРА, ОБРАБОТКИ И АНАЛИЗА
БОЛЬШИХ ДАННЫХ РЫНКА МОБИЛЬНЫХ ПРИЛОЖЕНИЙ
ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА
по образовательной программе подготовки бакалавров по
направлению 09.03.03 – «Прикладная информатика»
профиль – «Прикладная информатика в экономике»
г. Владивосток
2019
Автор
работы
(подпись)
«___» ________________ 2019г.
Руководите
ль,
доцент кафедры
ИСУ
Д.А.
Оськин
(подпись)
«___» ________________ 2019г.
Защищена в ГАК с
оценкой
«Допустить к защите»
Заведующий кафедрой, к.т.н.,
доцент
А.И.
Сухомлинов
Секретарь ГАК
(подпись)
И.О. Фамилия
«___» ________________ 2019г.
(подпись)
«___» ________________ 2019г.
3
МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ РОССИЙСКОЙ
ФЕДЕРАЦИИ
Федеральное государственное автономное образовательное
учреждение
высшего образования
«Дальневосточный федеральный университет»
ШКОЛА ЕСТЕСТВЕННЫХ НАУК
Кафедра информационных систем управления
ЗАДАНИЕ
на выпускную квалификационную работу
студенту Максимову Валерию Александровичу группы Б8419
(фамилия, имя, отчество)
на тему «Создание системы сбора, обработки и анализа Больших
Данных рынка
мобильных приложений»
Вопросы, подлежащие разработке (исследованию):
1. Описание предметной области (описание деятельности компаний,
занимающихся разработкой мобильных приложений;
исследование процесса анализа рынка мобильных приложений;
выявление проблем процесса анализа)
2. Разработка проекта создания системы сбора, обработки и анализа
данных
3. Описание технологии решения задачи (описание постановки
задачи; проектирование системы; формирование требований к
системе; проектирование информационного обеспечения системы;
поиск и обзор систем-аналогов; сравнительный анализ
программных продуктов)
4. Разработка системы сбора, обработки и анализа Больших Данных
рынка мобильных приложений
5. Расчет экономической эффективности
Основные источники информации и прочее, используемые для
разработки темы
1. Материалы по производственной практике по получению
профессиональных умений и опыта профессиональной
деятельности
2. Материалы по производственной практике (научно-
4
исследовательской работе)
3. Материалы по преддипломной практике
4. Справочная, научная, учебная литература
5. Ресурсы интернет
Срок представления
работы
«___» __________ 2019г.
Дата выдачи задания
«___» __________ 2019г.
Руководитель ВКР доцент
кафедры информационных систем
управления
Д.А. Оськин
(подпись)
Задание получил
(И.О. Фамилия)
В.А.Максимов
(подпись)
(И.О. Фамилия)
МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ РОССИЙСКОЙ
ФЕДЕРАЦИИ
Федеральное государственное автономное образовательное
учреждение
высшего образования
«Дальневосточный федеральный университет»
ШКОЛА ЕСТЕСТВЕННЫХ НАУК
Кафедра информационных систем управления
ГРАФИК
подготовки и оформления выпускной квалификационной работы
студента Максимова Валерия Александровича группы Б8419
(фамилия, имя, отчество)
на тему «Создание системы сбора, обработки и анализа Больших Данных
рынка
мобильных приложений»
№
п/
п
1.
2.
Выполняемые работы и мероприятия
Выбор темы и согласование с
руководителем
Подбор первичного материала, его
изучение и обработка. Составление
предварительной библиографии
Срок
выполнения
Отметка о
выполнен
ии
до 25
сентября
до 20
ноября
5
3.
4.
5.
6.
7.
8.
9.
10
.
11
.
Составление плана работы и согласования с
руководителем
Разработка и представление руководителю
первой части работы
Разработка и представление руководителю
второй части работы
Подготовка и согласование с руководителем
выводов и предложений, введения и
заключения. Подготовка презентации
работы
Доработка ВКР в соответствии с
замечаниями руководителя
Получение отзыва научного руководителя и
предзащита ВКР на заседании
выпускающей кафедры
Доработка ВКР в соответствии с
замечаниями, высказанными на
предзащите, окончательное оформление
Завершение подготовки к защите (доклад,
раздаточный материал, презентация в
Power Point)
до 01
декабря
до 01
февраля
до 01 июня
до 22 июня
до 28 июня
до 01 июля
до 06 июля
до 06 июля
июль
Защита ВКР в ГАК
Студент
В.А. Максимов
(подпись)
(И.О. Фамилия)
(подпись)
(И.О. Фамилия)
«___» __________ 2019г.
Руководитель ВКР
Д.А. Оськин
«___» __________ 2019г.
6
Аннотация
Тема выпускной квалификационной работы: «Создание
системы
обработки
и
анализа
Больших
Данных
рынка
мобильных приложений».
Объём работы 67 страниц, на которых размещены 39
рисунков
и
10
таблиц.
При
написании
диплома
использовалось 25 литературных источников.
Ключевые
слова:
«Большие
Данные»,
визуализация,
мобильные приложения, анализ данных, обработка данных,
Data Mining, Python.
Цель – разработка системы для проведения анализа
рынка приложений для мобильных устройств.
Объектом
исследования
являются
компании,
занимающиеся разработкой мобильных приложений.
Предметом
исследования
является
процесс
анализа
рынка мобильных приложений, выполняемый аналитиком.
Практическая значимость исследования заключается в
разработке
WEB-приложения
автоматизирующего
деятельность аналитика.
Выпускная
введения,
двух
квалификационная
глав,
заключения,
работа
списка
состоит
из
используемых
источников, приложений.
Введение раскрывает актуальность выбранной темы,
цель
исследования,
раскрывает
теоретическую
и
практическую значимость работы.
В
первой
главе
рассматривается
существующее
состояние предметной области («КАК ЕСТЬ»). Выявляются
проблемы и недостатки в работе аналитика рынка мобильных
7
приложений
и
дается
обоснование
предложений
по
устранению выявленных недостатков.
Во второй главе описываются решения, принятые по
всей вертикали проектирования информационной системы и
дан контрольный пример.
В
заключении
подводятся
итоги
исследования,
формируются окончательные выводы по рассматриваемой
теме, оценка степени выполнения поставленных задач.
8
Оглавление
Введение.........................................................................................................4
1 Анализ процесса анализа рынка мобильных приложений.....................7
1.1 Описание процесса анализа рынка мобильных приложений..........7
1.2 Экономическая сущность комплекса экономических
информационных задач аналитика........................................................10
1.3 Обоснование необходимости и цели использования
автоматизированной системы анализа..................................................13
1.3.1 Обоснование автоматизации решения задачи.......................13
1.3.2 Цели и задачи автоматизации.................................................17
1.3.3 Анализ существующих разработок и сравнительная
характеристика программного обеспечения...................................17
1.4 Общая характеристика организации решения задачи
автоматизации процессов сбора и обработки информации по
мобильным приложениям.........................................................................21
1.4.1 Постановка задачи....................................................................21
1.4.2 Входная информация................................................................23
1.4.3 Выходная информация..............................................................24
2 Проектирование системы анализа и разработка программного
обеспечения.................................................................................................30
2.1 Разработка проекта системы автоматизации работы аналитика. .30
2.1.1 Описание содержания проекта................................................30
2.1.2 Оценка длительности операций...............................................33
2.2 Анализ требований к разрабатываемой системе............................39
2.3 Проектирование системы анализа...................................................44
2.4 Архитектура системы и ее программное обеспечение..................46
2.5 Информационное обеспечение задачи анализа.............................49
2.6 Технологическое обеспечение задачи сбора и обработки
информации о мобильных приложениях...............................................53
2.7 Обоснование экономической эффективности проекта...................55
2.8 Описание контрольного примера реализации проекта..................61
Заключение..................................................................................................65
Список литературы.....................................................................................66
Приложение А.............................................................................................68
Приложение Б.............................................................................................71
Модуль считывания данных с Google Play Store...................................71
Фрагмент модуля обработки данных......................................................76
Фрагмент модуля формирования графиков...........................................78
Шаблон HTML-страницы коллекции......................................................81
Приложение В.............................................................................................83
9
Введение
В
настоящее
время
информационных
в
рамках
технологий
развития
активно
сферы
развиваются
мобильные технологии, что сопровождается развитием рынка
мобильных приложений.
Если учитывать лишь приложения из самых популярных
магазинов Android и iOS, рынок мобильных приложений уже
насчитывает около 6 миллионов приложений, однако даже с
такой
статистикой
разработчиков,
так
появление
и
целых
как
небольших
компаний,
групп
занимающихся
разработкой приложений, не прекращается.
Любая
подобная
новая
компания
сталкивается
с
вопросом о том, с чего какое приложение позволит компании
удачно выйти на рынок и получить наибольшую прибыль. Для
ответа на этот вопрос нужно определить целевую аудиторию
популярных
категорий
приложений,
выявить
приложений,
наиболее
определить
актуальные
основную
ценовую
категорию наиболее популярных приложений и так далее.
Решением этих задач обычно занимается аналитик
рынка
мобильных
приложений.
Он
занимается
отслеживанием динамики появления новых пользователей у
популярных
оценок,
приложений,
собирает
изменение
множество
пользовательских
различных
дополнительных
данных о ценах, возрастных категориях и многом другом.
Объем всей этой информации огромен, а отслеживание
динамики оценок, скачиваний и других показателей требует
серьёзных
трудозатрат,
так
как
в
свободном
доступе
подобных сведений нет, и получить их можно лишь путём
ручного
мониторинга
каждого
мобильного
приложения
4
непосредственно
в
магазине.
К
тому
же
аналитику
потребуется использовать дополнительные программы для
агрегирования всех полученных данных и получения общей
картины рынка. При ручном проведении анализа на такую
трудоемкую работу будет затрачено множество времени, а,
следовательно, и денежных средств.
В настоящий момент на рынке существует не так много
готовых
решений
позволяющих
проанализировать
рынок
мобильных приложений. При этом все доступные решения
предоставляют
лишь
данные
относительно
одного
конкретного приложения: количество пользователей этого
приложения (число скачиваний), средняя пользовательская
оценка приложения, рассчитанная на основе набора всех
выставленных пользователями оценок и так далее.
То есть все существующие продукты не позволяют
производить
анализ
рынка
мобильных
приложений,
а
позволяют отслеживать лишь определенные приложения, что
ограничивает
аналитика
при
принятии
решений
на
начальных этапах разработки, когда принимается решение о
назначении и функционале будущего приложения.
Поэтому
становится
актуальной
задача
создания
системы, которая позволит автоматизировать сбор данных из
магазина приложений, их обработку и представление в такой
форме, которая будет удовлетворять всем потребностям
аналитика при принятии решения о том, какое именно
приложение требуется разработать.
Целью выпускной квалификационной работы является
разработка
приложений
системы
для
для
проведения
мобильных
устройств
анализа
по
рынка
выбранным
5
критериям, способной собирать, хранить и обрабатывать
данные
рынка мобильных
приложений.
Данная
система
избавит аналитика от выполнения трудоемкой, длительной и
дорогой работы по сбору необходимых ему данных и будет
предоставлять
данные
рынка
мобильных
приложений
аналитику в форме, удобной для проведения анализа.
Для создания системы необходимо решить следующие
задачи:
• проанализировать предметную область, охватываемую
системой;
• определить
существующих
требования
решений
в
к
системе,
данной
путем
области,
анализа
выделения
минусов и плюсов аналогов, и выработка на их основе
требований к системе;
• выполнить
архитектурное
проектирование
будущей
системы, и построить модели выполнения технологических
процессов, которые она должна выполнять;
• реализовать систему, то есть выполнить работы по
написанию кода, разработке базы данных системы, верстке
веб-страниц,
подключению
созданию
базы
серверной
данных
к
системе,
части
системы,
тестированию
и
доработке системы.
Объектом исследования является отдел маркетинга в
компании,
занимающейся
разработкой
мобильных
приложений.
Предметом
исследования
является
процесс
анализа
рынка мобильных приложений, выполняемый аналитиком.
6
1
Анализ
процесса
анализа
рынка
мобильных
приложений
1.1 Описание процесса анализа рынка мобильных
приложений
Большие
данные
(англ.
Big
Data)
–
обозначение
структурированных и неструктурированных данных огромных
объёмов
и
значительного
обрабатываемых
многообразия,
горизонтально
эффективно
масштабируемыми
программными инструментами. Однако в частности термин
Big Data описывает не только сами данные, но и технологии
их обработки и использования, а также методы поиска
необходимой информации в больших массивах данных [3].
Google Play (прежнее название – Android Market) –
магазин приложений, игр, книг, музыки и фильмов компании
Google
и
других
компаний,
позволяющий
владельцам
устройств с операционной системой Android устанавливать и
приобретать различные приложения [10].
Знание
статистики
и
тенденций
присутствующих
в
Google Play Store данных является ценным инструментом как
для разработчиков приложений, так и для разработчиков
продуктов Android.
Каждое приложение включает в себя ряд мета-данных:
количество скачиваний приложения;
пользовательский рейтинг;
стоимость приложения;
наличие встроенных покупок;
верхняя и нижняя граница стоимости встроенных
покупок (при их наличии);
возрастная категория приложения;
7
жанр приложения.
Для компаний, занимающихся разработкой мобильных
приложений агрегированная информация по приложениям,
находящимся в топах, позволит решить множество вопросов,
связанных
с
разработкой,
которые
возникают
на
её
начальном этапе.
На
рисунке
1
представлена
предполагаемая
организационная структура предприятия, занимающегося
разработкой мобильных приложений под устройства с ОС
Android. Данная организационная структура была составлена
в результате сбора и агрегирования информации о реальных
организационных
структурах
следующих
компаний-
разработчиков мобильных приложений: RedMadRobot, Agima,
Omega-R и Touch Instinct.
Оргструктура
основные
структуры
предприятия
компании
и
позволяет
выделить
определить
основные
бизнес-процессы, выполняемые на предприятии.
Рисунок 1 – Типовая организационная структура
предприятия по разработке мобильных приложений
8
Основной
мобильных
деятельностью
приложений
компании
является
по
разработке
непосредственно
сам
процесс разработки мобильных приложений, однако помимо
него
компания
осуществляет
и
другие
процессы,
поддерживающие её работу.
Директор по найму – руководитель отдела по работе с
кадрами, в обязанности которого входит управление отделом
найма сотрудников. В состав отдела, помимо директора,
входят
также
HR
непосредственно
менеджер
подбором
–
лицо,
занимающееся
персонала,
требующегося
компании, и наставник по работе со стажерами – лицо,
занимающееся
обучением
стажеров
и
выполняющее
наблюдение за выполнением их обязанностей.
Главный
программный
инженер
–
руководитель
инженерного отдела, осуществляющий общий контроль над
процессами проектирования iOS и Android приложений, а
также баз данных к этим приложениям. В состав отдела,
помимо главного инженера, также входят разработчик баз
данных, занимающийся проектированием и разработкой баз
данных к разрабатываемым приложениям, и инженеры iOS и
Android,
занимающиеся
моделированием
функциональным
приложений
под
и
структурным
соответствующие
платформы.
Главный
программист
–
руководитель
отдела
программирования, выполняющий контроль над процессами
разработки и тестирования разрабатываемых приложений. В
состав отдела, кроме главного программиста, также входят
программисты
непосредственно
iOS
и
Android,
написанием
занимающиеся
приложений
под
9
соответствующие платформы по составленным инженерным
отделом
моделям,
занимающийся
и
разработчик
разработкой
UI/UX
дизайна
интерфейсов,
пользовательских
интерфейсов приложений и их программированием.
Директор
маркетинга,
решения
по
маркетингу
принимающий
по
развитию
–
руководитель
ключевые
предприятия
отдела
стратегические
и
продвижению
приложений. В состав отдела маркетинга также входят PRменеджер, занимающийся вопросами рекламы приложений,
а
также
разрабатывающий
стратегии
продвижения
приложений на рынке, менеджер по работе с клиентами,
выполняющий процессы сбора и анализа отзывов от клиентов
по выпущенным приложениям для разработки стратегий
продвижения этих приложений, и аналитик рынка мобильных
приложений, занимающийся сбором и анализом отзывов,
пользовательских оценок, количеств скачиваний и других
метаданных
приложений
конкурентов,
пользующихся
популярностью у пользователей, с целью развития стратегий
и формирования идей по созданию приложений, способных
конкурировать с приложениями конкурентов.
1.2
Экономическая
сущность
комплекса
экономических информационных задач аналитика
Одним
из
ключевых
актеров
в
маркетинговой
деятельности является аналитик. Он выполняет задачи по
анализу рынка мобильных приложений, в которые входят:
сбор необходимых для анализа данных, обработка собранных
данных (проверка на ошибки и аномальные значения, а
также
приведение
данных
к
виду,
необходимому
для
10
дальнейшей работы с ними), построение различных схем и
диаграмм, необходимых для проведения анализа, анализ и
принятие решений по результатам произведенного анализа.
Основанием для большинства решений, принятых в ходе
маркетинговых
полученная
исследований,
именно
служит
аналитиком.
информация,
Аналитик
формирует
отчеты, отображающие текущее состояние рынка (объем
рынка, распределение приложений в топах по категориям),
показатели,
влияющие
пользовательские
цена),
и
их
на
оценки,
спрос
наличие
динамика,
(категории,
встроенных
особенности
покупок,
ценообразования
(зависимость цен приложений от пользовательских оценок),
по
результатам
проведенных
исследований
рынка
и
данных
и
предоставляет их директору по маркетингу.
Для
оценки
временных
затрат
на
сбор
обработку данных существует 3 основных методики:
- PERT
(Program
(Project)
Evaluation
and
Review
Technique, «оценка по трем точкам») – методика определения
ожидаемой продолжительности работы по формуле
t п +4 t нв +t о
,
6
где tп – пессимистичная оценка, tнв – наиболее вероятная
оценка, tо – оптимистичная оценка;
- экспертная оценка;
- опытная оценка (экспериментальная оценка).
Так
как
представлений
методика
о
PERT
времени,
подразумевает
которое
будет
наличие
затрачено
на
выполнение задачи в лучшем случае (оптимистичная), в
худшем
случае
(пессимистичная)
и
при
обычных
обстоятельствах (наиболее вероятная), то эта методика в
11
данном случае неприменима, так как никаких данных о
длительности выполнения задач сбора и обработки данных
нет.
Для применения экспертной оценки требуется наличие
экспертов в изучаемом вопросе, что тоже в данном случае
невозможно.
В
связи
с
экспериментальных
этим
была
исследований,
выбрана
позволившая
методика
изучить
процессы сбора и обработки данных «изнутри», а также
оценить реальные временные затраты на выполнение этих
процессов. Для этого был создан файл Excel с созданными
заранее таблицами, в которые, впоследствии, вносились
данные из каждой коллекции (топа). Для изучения было
решено собрать и обработать по 5 приложений из каждой
коллекции,
необходимо
после
чего
умножить
полученные
на
количество
результаты
было
приложений
в
коллекциях.
Таким образом, на сбор данных по 5 приложениям в
каждой коллекции было затрачено 20 минут, то есть по 5
минут на каждые 5 приложений. А значит в среднем, для
сбора информации за одни сутки по всем приложениям,
находящимся в топах (2000 приложений), аналитик затратит
более
31-33
часов
при
наличии
стабильного
интернет-
соединения, и при условии того, что аналитик является
опытным ПК-пользователем.
На обработку собранной информации опытный аналитик
затратит около одного часа, на визуализацию – также около
часа.
12
Таким образом, на проведение анализа данных по
коллекциям, сформированным на сутки, опытный аналитик
затратит около 33-35 часов, что превышает длительность
суток и тем более длительность рабочего дня. То есть для
того,
чтобы
успеть
выполнить
сбор
данных,
аналитику
придётся пожертвовать 1600 строками данных (придётся
собирать данные лишь по 100 приложениям в каждой
коллекции, вместо 500 возможных), что ухудшит общий
показатель анализа. Также, если аналитик получает оплату
за
каждый
ускоряющей
час
работы,
процессы
то
сбора
использование
и
обработки
системы,
информации,
позволит компании сэкономить значительное количество
средств.
Информация о необходимых аналитику данных была
собрана
из
статей
аналитиков
изучаемой
сферы
деятельности. В частности, статья «Analysis of Apps in the
Google Play Store» автора Yulia Norenko [9] позволила
выделить основные показатели, необходимые аналитику при
проведении анализа, а статья «A Statistical Analysis of the
Apple App Store» автора Colin Eberhardt [8] разъяснила
основной
принцип
мышления
при
проведении
анализа
агрегированных данных рынка мобильных приложений.
Так как Google не предусмотрели функционала в своих
API, позволяющего программными средствами выполнять
сбор
необходимой
информации,
возникает
ключевая
проблема – невозможность быстрого получения мета-данных
по приложениям.
Сбор этой информации в разрабатываемой системе было
решено
реализовать
посредством
WEB-Scrapping'а.
В
13
широком понимании веб-скрапинг – это сбор данных с
различных
интернет-ресурсов,
общий
принцип
работы
которого можно объяснить следующим образом: некий код,
автоматизирующий выполнение запросов на целевой сайт, и
получая
ответ,
исследует
HTML-документ,
ищет
в
нем
необходимые данные и преобразует их в заданный формат
[16][3][4].
1.3
Обоснование
необходимости
и
цели
использования автоматизированной системы анализа
1.3.1 Обоснование автоматизации решения задачи
Чтобы
обосновать
автоматизацию
решения
задачи
необходимо дать характеристику, существующей технологии
решения
задачи.
Для
этого
был
проведен
структурно-
функциональный анализ решаемой задачи, в ходе которого
были разработаны диаграммы модели IDEF0 «КАК-ЕСТЬ»
(AS-IS), приведенные ниже на рисунках 2-5.
На
рисунке
2
представлена
контекстная
AS-IS
диаграмма процесса анализа рынка мобильных приложений.
14
Рисунок 2 – Контекстная диаграмма модели AS-IS
15
На рисунке 3 приведена декомпозиция контекстной ASIS
диаграммы
процесса
анализа
рынка
мобильных
приложений.
Рисунок 3 – Декомпозиция контекстной диаграммы
На рисунке 4 представлена декомпозиция процесса
«Сбор
мета-данных
о
приложениях»,
построенная
по
методологии IDEF3, позволяющая отобразить цикличность
процесса сбора данных.
Как
видно
на
диаграмме,
основным
исполнителем
(объектом-инициатором) процесса сбора является аналитик,
который вручную выполняет сбор данных.
16
При сборе данных аналитик использует электронные
таблицы
Microsoft
Excel,
позволяющие
ему
сохранить
собранные данные, обработать их и выполнить необходимый
ему анализ.
Рисунок 4 – Декомпозиция процесса «Сбор метаданных о
приложениях»
На рисунке 5 представлена декомпозиция процесса
«обработка и визуализация собранных данных», построенная
по методологии IDEF3, позволяющая отобразить цикличность
процесса обработки данных.
17
При этом есть вероятность обнаружить ошибку во время
обработки данных, что вынудит аналитика повторить сбор
данных по приложению с ошибкой.
Рисунок 5 – Декомпозиция процесса «Обработка и
визуализация собранных данных»
При
анализе
данных
диаграмм
были
выделены
следующие недостатки в работе аналитика:
1. Процесс
зависимости
данные
за
от
сбора
целей
разные
данных
цикличен,
аналитика,
даты,
а
могут
значит
при
этом
в
потребоваться
этот
цикл
может
продолжаться довольно длительное время.
2. Вызывает сложности процесс проверки собранных
данных, так как аналитик, в силу человеческого фактора,
может
упустить
аномальные
(выбивающиеся
из
общего
формата) данные из виду, следствием чего может стать
18
снижение
качества
будущего
анализа
и
принимаемых
решений.
3. Большое количество данных и построенных графиков
может
значительно
вычислительной
замедлить
машины,
что
скорость
также
работы
усложнит
работу
аналитика.
4. Высокая стоимость затрат (при условии, что аналитик
получает почасовую оплату в размере 400 рублей в час) на
проведение процессов сбора и обработки данных.
1.3.2 Цели и задачи автоматизации
Процесс сбора информации по мобильным приложениям
является
отправным
мобильных
для
проведения
приложений.
Ручной
анализа
сбор
рынка
информации
значительно увеличивает время проведения анализа рынка
мобильных
приложений.
Автоматизация
сбора
данных
позволит значительно ускорить процесс анализа и снизит
нагрузку на аналитика.
Автоматизация
процесса
обработки
данных
также
позволит снизить нагрузку на аналитика и ускорить процесс
проведения анализа.
За
счет
использования
разрабатываемой
системы,
аналитик сможет использовать собранные системой данные в
построении собственных графиков, использовать графики,
построенные
системой.
Также
руководство
предприятия
сможет значительно снизить затраты на оплату работы
аналитика.
19
1.3.3
Анализ
сравнительная
существующих
разработок
характеристика
и
программного
обеспечения
Для оценки конкурентоспособности разрабатываемого
продукта был произведен анализ и сравнение с выбранным
аналогом
по
функциональному
назначению,
основным
техническим и эксплуатационным параметрам, областям
применения. Подобный анализ осуществляется при помощи
оценки
эксплуатационно-технического
уровня
разрабатываемого продукта с использованием метода бальноиндексного оценки в соответствии с ГОСТом Р ИСО/МЭК
9126-93.
Эксплуатационно-технический
разрабатываемого
характеристика
возможностей,
продукта
его
степени
уровень
–
это
(ЭТУ)
обобщенная
эксплуатационных
новизны,
являющихся
свойств,
основой
качества продукта.
При изучении предметной области решаемой задачи
было
выбрано
два
аналога
разрабатываемой
системы
«MobAStA» – «AppAnnie» и «APPFOLLOW». Однако прямых
аналогов разрабатываемой системе, которые выполняют те
же функции, найдено не было. Поэтому к рассмотрению были
приняты системы, которые имеют схожую направленность с
разрабатываемой
системой.
Показатели
качества
были
выбраны в соответствии с требованиями к разрабатываемой
системе «MobAStA». Коэффициенты весомости для каждого
показателя были выставлены в соответствии со значимостью
этих показателей в разрабатываемой системе «MobAStA». По
20
системам-аналогам показатели качества были выставлены в
соответствии с отзывами пользователей.
Расчет обобщенных показателей качества для каждой
системы приведен в таблице 1.
Т а б л и ц а 1 – Расчет обобщенных показателей качества
Показатели
качества
Коэффици
ент
весомости
, Bj
1. Простота
использования
2. Новизна
(соответствие
современным
требованиям)
3. Агрегирование
данных
4. Разнообразность
представляемой
информации
App
Annie
APPFOLLO
W
Xj
Bj *
Xj
Xj
Bj *
Xj
Xj
Bj *
Xj
0,15
4
0,6
3
0,45
5
0,75
0,1
3
0,3
3
0,3
2
0,2
0,25
5
1,25
3
0,75
2
0,5
0,15
3
0,45
5
0,75
2
0,3
0,2
5
1
1
0,2
3
0,6
0,15
4
0,6
3
0,45
1
0,15
5. Стоимость
6. Визуализация
предоставляемой
информации
MobAStA
Обобщенный показатель
качества JЭТУ
Оправданность
J1 = 4,20
разработки
J2 = 2,90
J3 = 2,50
собственной
системы
определяется коэффициентом технического уровня, который
является
отношением
разрабатываемой
обобщенного
системы
к
показателя
обобщенному
качества
показателю
качества аналогов.
Коэффициент технического уровня для системы «App
Annie»:
A1=
J 1 4,20
=
=1,45
J 2 2,90
21
Коэффициент
технического
уровня
для
системы
«APPFOLLOW»:
A2=
J 1 4,20
=
=1,68
J 3 2,50
По полученным коэффициентам технического уровня
видно, что разработка собственной системы «MobAStA» с
технической
точки
зрения
вполне
оправдана,
так
как
коэффициенты больше 1.
Низкие обобщенные показатели качества для системаналогов объясняются тем, что выбранные системы не имеют
функций
агрегирования
данных
и
их
визуализации,
являющихся основными для разрабатываемой системы.
1.3.4
Обоснование
выбора
технологии
проектирования
Методология
проектирования
представляет
собой
принципы проектирования, реализуемые набором методов
проектирования,
поддерживаемых
средствами
проектирования. Главный принцип построения различных
систем – принцип иерархической декомпозиции. Данный
принцип
включает
две
группы
методологий:
объектно-
ориентированная методология и структурно-функциональная
методология [2][6].
Объектно-ориентированный
изначальном
выделении
подход
объектов.
строится
Так
как
на
в
рассматриваемой предметной области выделить полноценные
объекты, а также определить связь между ними довольно
сложно,
для
исследования
предметной
области
выбран
структурно-функциональный подход, в основе которого лежит
принцип функциональный декомпозиции.
22
В структурном анализе используются в основном две
группы средств, иллюстрирующих функции, выполняемые
системой и отношения между данными. Каждой группе
средств
соответствуют
определенные
виды
моделей
(диаграмм), наиболее распространенными среди которых
являются следующие:
- SADT (Structured Analysis and Design Technique) модели
и соответствующие функциональные диаграммы;
- DFD (Data Flow Diagrams) диаграммы потоков данных;
- ERD
(Entity-Relationship
Diagrams)
диаграммы
«сущность-связь».
Модели SADT, а в частности IDEF0 и IDEF3, наиболее
часто
используемые
при
построении
функциональных
моделей, так как они наглядно отражают функциональную
структуру объекта, а именно выполняемые процессы и связи
между этими процессами. Благодаря чему можно определить
логику
процессов,
взаимодействие
их.
выполняемых
Основным
на
плюсом
предприятии,
данной
и
нотации
является то, что можно получить достаточную информацию о
каждом процессе. Благодаря ей можно определить все
недостатки
процесса
и
его
реализации:
дублирование
функций, отсутствие механизмов, регламентирующих данный
процесс, отсутствие контрольных переходов и т.д.
DFD
предоставляет
возможность
рассмотреть
информационное пространство системы. Она используется
для описания потоков информации внутри ИС, что позволяет
использовать DFD диаграммы как дополнение к модели
бизнес-процессов, выполненной в IDEF0 (IDEF3) [6].
23
ERD модели позволяют отобразить набор объектов, их
атрибутов
и
связей
между
ними
в
рассматриваемой
предметной области. Эти модели значительно упрощают
процесс проектирования базы данных системы. На основе
данной модели строится процесс моделирования базы данных
в методологии IDEF1X, позволяющей практически в полной
мере описать конечный вид физической модели реляционной
базы данных [7].
1.4 Общая характеристика организации решения
задачи автоматизации процессов сбора и обработки
информации по мобильным приложениям
1.4.1 Постановка задачи
Создание системы сбора и обработки информации о
мобильных
приложениях
маркетингового
разработкой
отдела
–
одна
в
мобильных
из
основных
компаниях,
приложений.
задач
занимающихся
Информация
о
приложениях, которую может предоставить разрабатываемая
система,
необходима
при
проведении
анализа.
Знать
преобладающие категории в каждой коллекции, средние
рейтинги приложений и подобную информацию необходимо
для того, чтобы можно было наметить основополагающие
характеристики разрабатываемого приложения. Важнейшим
процессом
в
маркетинговом
отделе
является
процесс
принятия решений о дальнейшем пути разработки. Не имея
требуемой информации (или при её ручном сборе), процесс
принятия решений может значительно затянуться и снизить
эффективность работы маркетингового отдела.
24
Использование
ИС
сбора
и
обработки
данных
о
мобильных приложениях даст следующие эффекты:
- аналитик
сможет
сократить
время
на
анализ
информации;
- начальный
набор
графиков
позволит
аналитику
сократить время на их построение;
- повысится
качество
исследования
за
счет
компьютерной обработки собранных данных;
- эффективность деятельности маркетингового отдела
значительно повысится за счет сокращения времени анализа.
В таблицах 2 и 3 отображено формализованное описание
входных
показателей
и
формализованное
описание
результатных показателей. Это необходимо для будущего
проектирования программного продукта и базы данных.
Т а б л и ц а
2 – Входные данные
Наименование входного
показателя
Дата считывания данных i-той
коллекции
Идентификатор
входного показателя
Date_point
Наименование приложения
Title
Цена приложения
Price
Платное / Бесплатное
Free
Встроенные покупки: есть / нет
IAP
Ранжирование встроенных покупок
Возрастной рейтинг
Количество скачиваний
Категория
IAP Range
Content rating
Installs
Category
Так как система помимо сбора и обработки данных
выполняет
и
визуализацию
основной
статистики
по
25
собранным
данным,
то в результативных
данных
будут
именно графики, описывающие статистику по показателям,
определенным на вход, а также описывающие отношение
между некоторыми из этих показателей.
Т а б л и ц а
3 – Результатные данные
Алгоритм
предоставления
результата
Наименование результатного
показателя
N
Среднее значение i-го показателя j-той
коллекции по выборке из N приложений
∑ ik
k=1
N
N
Отношение i-того и k-того параметров jтой коллекции по выборке из N
приложений
∑ in
n=1
N
∑ km
m=1
1.4.2 Входная информация
На вход система получает код DOM-дерева страницы на
языке разметки HTML, пример которого представлен на
рисунке 6.
26
Рисунок 6 – Пример HTML-кода страницы, поступающего на
вход
Данный
выделяются
записываются
код
анализируется
необходимые
системой
системой,
после
данные.
Выделенные
в
данных,
базу
чего
данные
откуда
и
используются системой в дальнейшем. Из базы в систему
данные поступают в формате JSON-объекта, пример которого
представлен на рисунке 7.
27
Рисунок 7 – Пример JSON-объекта, поступающего на вход
1.4.3 Выходная информация
На
выход
система
предоставляет
набор
графиков,
которые могут помочь аналитику в принятии решений.
Каждый график предоставляет определенный вид сводной
информации.
статистики
Так
по
на
рисунке
жанрам,
8
представлен
отображающий
график
количество
приложений в каждом жанре.
Рисунок 8 – Гистограмма статистики по количеству
приложений в каждом жанре
На
рисунке
9
изображена
круговая
диаграмма
статистики по наличию встроенных покупок, отображающая
процентное
соотношение
приложений,
имеющих
и
не
имеющих встроенные покупки к общему числу приложений,
28
а также средняя минимальная и средняя максимальная цены
на единичную встроенную покупку.
Рисунок 9 – Круговая диаграмма по наличию встроенных
покупок
На рисунке 10 приведена гистограмма, отображающая
статистику
по
возрастным
категориям,
отображающая
количество приложений в каждой возрастной категории.
29
Рисунок 10 – Гистограмма статистики по количеству
приложений в каждой возрастной категории
Гистограмма, отображающая средние пользовательские
рейтинги в каждой категории приведена на рисунке 11.
Рисунок 11 – Гистограмма средних рейтингов в каждой
категории
Круговая
диаграмма,
отражающая
процентное
соотношение платных и бесплатных приложений к общему
числу приложений представлена на рисунке 12.
30
Рисунок 12 – Круговая диаграмма статистики по платным и
бесплатным приложениям
Статистика по рейтингам при наличии или отсутствии
встроенных
покупок
отображена
на
гистограмме,
представленной на рисунке 13.
Рисунок 13 – Гистограмма статистики по рейтингам при
наличии или отсутствии встроенных покупок
31
Статистика средних рейтингов в каждой возрастной
категории приведена на гистограмме, представленной на
рисунке 14.
Рисунок 14 – Гистограмма статистики по рейтингу в
возрастных категориях
Гистограмма, отображающая статистику по средним
количествам скачиваний в каждой возрастной категории,
приведена на рисунке 15.
32
Рисунок 15 – Гистограмма статистики по скачиваниям в
возрастных категориях
Статистика, отображающая среднее число скачиваний в
каждой категории приложений отражена на гистограмме,
приведенной на рисунке 16.
Рисунок 16 – Гистограмма статистики по скачиваниям в
жанрах
Гистограмма, на которой отображена статистика по
среднему
количеству
скачиваний
в
каждой
группе
пользовательских рейтингов.
33
Рисунок 17 – Гистограмма статистики по скачиваниям в
рейтинговых группах
Графики, формируемые системой, были выбраны на
основании научных статей аналитиков в данной области, в
результате
изучения
которых
можно
определить
какая
именно информация интересна аналитику при проведении
анализа рынка мобильных приложений.
34
2 Проектирование системы анализа и разработка
программного обеспечения
2.1 Разработка проекта системы автоматизации
работы аналитика
2.1.1 Описание содержания проекта
Иерархическая структура работ – это метод разбиения
всей работы, которую необходимо выполнить для достижения
целей проекта, на более мелкие операции и действия до
элементарных, то есть таких, которые могут быть оценены.
Первый этап при разработке проекта – составление
иерархической структуры для разрабатываемого проекта.
Целью данного проекта будет являться разработка системы
для проведения анализа рынка приложений для мобильных
устройств по выбранным критериям, способной собирать,
хранить
и
приложений.
обрабатывать
Данная
данные
система
рынка
избавит
мобильных
аналитика
от
выполнения трудоемкой, длительной и дорогой работы по
сбору
необходимых
ему
данных
и
будет
предоставлять
данные рынка мобильных приложений аналитику в форме,
удобной для проведения анализа. Плановый срок начала
проекта – 01.12.2018, а крайний срок выполнения проекта –
23.06.19.
35
Итоговая структура работ проекта представлена на
рисунке 18.
Рисунок 18 – Структура проекта
Задачи, выполняемые при создании системы обработки и
анализа Больших Данных рынка мобильных приложений, и
представленные на рисунке 18, описывают последовательный
подход к созданию системы.
Так первым при создании системы была выделена фаза
«Формирование системных требований», включающая в себя
следующие задачи:
1. Анализ
предметной
области
–
исследование
предметной области с целью определения ее сущностей,
36
первоначальных требований к функциональности системы и
определения границы проекта.
2. Анализ
существующих
решений
–
изучение
существующих решений с целью выявления их плюсов и
минусов.
3. Определение и анализ требований к разрабатываемой
системе – разработка, на основе анализа существующих
решений
и
анализа
предметной
области,
требований
к
системе, их систематизация, выявление взаимосвязей, а
также документирование.
Следующей
была
выделена
фаза
«Проектирование
системы», которая определяет следующие задачи:
1. Структурное моделирование – построение диаграммы
классов,
диаграммы
компонентов
и
диаграммы
–
построение
развертывания.
2. Функциональное
моделирование
диаграммы системных прецедентов, диаграммы деятельности
и диаграммы взаимодействия.
3. Разработка макетов страниц.
4. Проектирование базы данных.
Завершающей
была
определена
фаза
«Реализация
системы», на которой выполняются задачи:
1. Реализация
разработка
механизма
модуля,
получения
занимающегося
данных
сбором
–
требуемых
данных.
2. Реализация
алгоритмов
обработки
–
реализация
алгоритмов обработки собранных данных.
3. Реализация базы данных.
37
4. Реализация серверной части системы – реализация
сервера, объединяющего в себе готовые части системы,
работающие с данными.
5. Верстка пользовательской части системы – верстка
веб-страниц,
на
которых
данные
будут
представлены
пользователю в форме, удобной для проведения анализа.
6. Тестирование системы.
7. Доработка системы.
2.1.2 Оценка длительности операций
Для определения ожидаемой продолжительности работы
Tож применяется метод PERT (Program Evaluation and Review
Technique). Оценка осуществляется по формуле 1:
где tмин
tмин +4 tнв +t макс
(1
)
,
– кратчайшая продолжительность данной работы
T ож =
6
(оптимистическая оценка);
tмакс
–
самая
большая
продолжительность
работы
(пессимистическая оценка);
tнв – наиболее вероятная продолжительность работы
(реалистическая оценка).
Для получения целочисленных значений, расчет был
произведен в минутах.
Таким образом для каждой задачи был произведен
расчет, результаты которого приведены в таблице 4.
Т а б л и ц а 4 – Оценка продолжительности работ
Виды работ
Оптимис
т.
оценка,
tмин
Реалист.
оценка,
tнв
Пессимис
т. оценка,
tмакс
Ожидаем
ая
продолж.
работы,
Tож
38
Анализ предметной
области
2880
7200
11520
7200
Анализ существующих
решений
1440
4320
7200
4320
2016
2592
40320
2736
0
20160
1296
0
37440
1728
0
Определение и анализ
требований к системе
0
0
Структурное
моделирование
5760
Функциональное
моделирование
8640
Разработка макетов
страниц
2880
7200
11520
7200
Проектирование базы
данных
1440
4320
7200
4320
Пессимис
т. оценка,
tмакс
Ожидаем
ая
продолж.
работы,
Tож
86400
7632
0
37440
2592
0
20160
1152
0
44640
4032
0
43200
3024
0
1296
0
1440
0
Окончание таблицы 4
Виды работ
Реализация механизма
получения данных
Определение
алгоритмов обработки
данных
Реализация базы
данных
Реализация серверной
части системы
Верстка
пользовательской
части системы
Подключение базы
данных к системе
Оптимис
т.
оценка,
tмин
Реалист.
оценка,
tнв
4896
0
8064
0
2016
0
2448
0
8640
1008
0
3600
0
4032
0
2304
0
2880
0
1440
2880
4320
2880
Тестирование системы
2880
7200
11520
7200
Доработка системы
1440
2880
4320
2880
ИТОГО (в днях)
129
190
269
193
39
Как видно итоговые результаты таблицы, а в частности
ожидаемая продолжительность работ близка к выбранной
реалистичной оценке. Из этого следует, что план составлен с
довольно высокой степенью оптимальности.
В процессе создания системы принимает участие не
только ее непосредственный исполнитель – студент, но и
руководитель дипломной работы. Именно он обеспечивает
студента необходимыми материалами по дипломной работе, а
также
сопровождает
формирования
студента
системных
при
требований
выполнении
и
фазы
отслеживает
выполнение поставленных студентом задач, и корректирует
их.
Помимо
научного
руководителя,
при
написании
дипломной работы, студент консультируется по вопросам
моделирования с преподавателем, которого также требуется
учесть.
40
Определенные
в
данном
проекте
трудовые
и
материальные ресурсы представлены на рисунке 19.
Рисунок 19 – Ресурсы проекта
Как было описано ранее, роль научного руководителя
(Оськина
Д.
А.)
заключается
в
контроле
исполнения
студентом задач по созданию системы и консультировании
по
различным
вопросам,
а
также
в
предоставлении
материала студенту для его изучения, с целью использования
при
выполнении
фазы
«Формирование
системных
требований».
Студент
исполнитель
(Максимов
задач.
В.
А.)
Научный
–
непосредственный
руководитель
занимается
поддержкой студента при выполнении научной работы, но
выполнением работ занимается сам студент. Произведение
анализа
предметной
области,
анализа
аналогов,
моделирования системы, её разработки и так далее – всё это
входит в задачи студента.
Преподаватель
консультанта,
то
(Бедрина
есть
С.
помогает
Л.)
выполняет
студенту
при
роль
решении
вопросов в области моделирования системы.
При
распределении
выделенных
трудовых
и
материальных ресурсов на исполнение задач учитывался тот
факт, что в большинстве задач научный руководитель, как и
41
преподаватель, либо не участвует вовсе, либо занимается
контролем или поддержкой исполнения того или иного этапа
выполнения
работы
студентом,
что
нельзя
назвать
незначительным, однако загрузка данных исполнителей при
этом составит от 15% до 50% от их максимально возможной
загруженности.
Результат распределения ресурсов по задачам можно
увидеть на рисунке 20 в поле «Названия ресурсов».
Рисунок 20 – Распределение ресурсов по задачам
42
В результате было рассчитано, что сумма всех затрат на
достижение цели проекта, учитывая стандартные ставки
преподавательского состава ДВФУ и стандартную стоимость
пачки
бумаги,
необходимой
для
набросков
алгоритмов,
чертежей блок-схем и других задач, составит 6 962 р. Из них
1 050 р. составляют затраты на материальные ресурсы,
расходуемые в ходе выполнения задач.
2.1.4
Идентификации
рисков
и
разработка
стратегии их смягчения
Каждая задача, описанная в содержании проекта, тем
или иным образом подвержена влиянию рисков.
Управление рисками проекта – это систематический
процесс
идентификации,
анализа
и
реагирования
на
проектные риски.
Начать идентификацию рисков следует с определения
задач, составляющих критический путь. Выполняется это с
использованием встроенных средств программного продукта
«Microsoft Project».
На рисунке 21 приведена диаграмма Ганта, где задачи,
лежащие на критическом пути помечены красным.
43
Рисунок 21 – Задачи критического пути проекта
Как видно на рисунке 21, при указании длительности
работ равной определенной ранее ожидаемой длительности
работ, все задачи проекта имеют довольно внушительный
временной резерв, а окончание самого проекта происходит
практически за месяц до крайнего срока.
Однако выделить риски, которые могут возникнуть при
выполнении
наиболее
задач
можно.
трудоемкой
Так,
задачи
по
например,
длительность
реализации
механизма
получения данных может быть значительно увеличена по
причине
изменения
формы
хранения
и
представления
данных на сайте Google Play. Так как механизм получения
данных не является универсальным, то малейшие изменения
в форме хранения этих данных может привести к полной
неработоспособности
этого
механизма,
а
значит
его
разработку потребуется начинать с самого начала.
Планы смягчения данного риска приведены на рисунке
22.
44
Рисунок 22 – Планы по смягчению риска задержки
определения темы ВКР
Так как данный проект, в результате оптимизации, не
имеет задач, лежащих на критическом пути, а временной
резерв
имеется
практически
у
каждой
задачи,
то
идентификация рисков, связанных с выполнением этих задач,
не является сложной задачей.
Однако
ресурсных
сложности
рисков.
может
Например,
составить
невозможность
появление
встречи
с
научным руководителем. Такие риски имеют невысокую
вероятность, но требуют описания плана по их смягчению во
избежание проблем, которые они могут составить.
Таким
образом
был
составлен
план
по
смягчению
описанного ранее риска, приведенный на рисунке 23.
Рисунок 23 – План по смягчению ресурсного риска
Бюджетные
превышением
риски
–
ограничений
вид
по
рисков,
связанный
установленному
с
бюджету.
45
Учитывая
то,
ограничения
что
по
при
создании
бюджету
системы
не
на
студента
накладываются,
то
и
рассмотрение рисков данного вида не имеет смысла.
2.2 Анализ требований к разрабатываемой системе
После анализа модели AS-IS было выявлено, что процесс
сбора данных цикличен, при этом в зависимости от целей
аналитика, могут потребоваться данные за разные даты, а
значит этот цикл может продолжаться довольно длительное
время.
А
также
опасным
является
процесс
проверки
собранных данных, так как аналитик, в силу человеческого
фактора, может упустить аномальные (выбивающиеся из
общего формата) данные из виду, следствием чего может
стать снижение качества будущего анализа и принимаемых
решений.
При
построенных
скорость
этом
графиков
работы
большое
количество
может
значительно
вычислительной
машины,
данных
и
замедлить
что
также
усложнит работу аналитика.
По результатам исследования недостатков деятельности
аналитика
была
построена
структурно-функциональная
модель деятельности, в соответствии со стандартом IDEF0,
описывающая организацию работы на предприятии «как
должно быть» (TO-BE), приведенная ниже.
TO-BE
позволит
модель
автоматизируемого
определить
основные
процесса
требования
к
анализа
системе,
направленной на автоматизацию деятельности производимой
аналитиком
в
компаниях
по
разработке
мобильных
приложений.
46
На
рисунке
24
представлена
контекстная
TO-BE
диаграмма процесса анализа рынка мобильных приложений.
Рисунок 24 – Контекстная диаграмма модели TO-BE
Данная
выходные
диаграмма
данные
описывает
процесса
основные
анализа
рынка
входные
и
мобильных
приложений, но не отображает обмена данными между
подпроцессами, происходящими внутри данного процесса.
47
На рисунке 25 приведена декомпозиция контекстной TOBE
диаграммы
процесса
анализа
рынка
мобильных
приложений.
Рисунок 25 – Декомпозиция контекстной диаграммы
На рисунке 26 представлена декомпозиция процесса
«Сбор
мета-данных
о
приложениях»,
построенная
по
методологии IDEF3, позволяющая отобразить цикличность
процесса
сбора
данных,
а
также
изменение
объектов
инициаторов.
48
Как видно объект «Аналитик» был заменен объектом
«Разрабатываемая система», а объект «MS Excel» был удалён,
так
как
теперь
хранением
собранных
данных
также
занимается «Разрабатываемая система».
Рисунок 26 – Декомпозиция процесса «Сбор метаданных о
приложениях»
На рисунке 27 представлена декомпозиция процесса
«обработка и визуализация собранных данных», построенная
по методологии IDEF3, позволяющая отобразить цикличность
процесса обработки данных, а также изменение объектовинициаторов.
49
Как видно объект «Аналитик», как и в предыдущем
процессе,
был
заменен
объектом
«Разрабатываемая
система», а объект «MS Excel» был удалён, так как все
данные
предоставляются
единым
хранилищем
разрабатываемой системы.
Рисунок 27 – Декомпозиция процесса «Обработка и
визуализация собранных данных»
Как показано на рисунках, бизнес-процессы не понесли
значительных
технологических
изменений,
однако
на
рисунке 25 видно, что теперь аналитик участвует только в
процессе анализа и принятия решений, а процессы сбора,
обработки
и
визуализации
данных
теперь
выполняются
исключительно разрабатываемой системой. Таким образом
наиболее
трудоёмкие,
а,
следовательно,
и
затратные
процессы, будут выполняться системой, что снизит нагрузку
на аналитика.
50
По рисункам 26 и 27 можно определить основные
требования к системе:
1. Разрабатываемая система должна выполнять сбор
метаданных о приложениях из коллекций: «топ бесплатных»,
«топ
платных»,
«бестселлеры»
и
«набирающие
популярность»;
2. Разрабатываемая
система
должна
выполнять
обработку собранных данных (поиск и устранение аномалий,
преобразование
данных
к
форме,
удобной
для
их
дальнейшего использования);
3. Разрабатываемая система должна визуализировать
обработанные данные и предоставить аналитику широкий
набор графиков, которые помогут ему в проведении анализа
и принятии решений;
4. Разрабатываемая система должна иметь простой и
понятный пользователю интерфейс;
5. Разрабатываемая
система
должна
быть
легкодоступной для аналитика.
2.3 Проектирование системы анализа
Для определения требований к хранилищу данных была
построена
DFD-модель
визуализации
Накопители
данных
данной
процесса
сбора,
магазина
Google
диаграммы
обработки
Play
отображают
и
Store.
отдельные
объекты единой базы данных системы, с каждым из которых
взаимодействует тот или иной процесс.
Эта
модель
позволит
представить
принцип
взаимодействия процессов, выполняемых системой, с базой
данных, а также изучить основные объекты, поставляющие
51
данные в систему, или получающие данные из неё. То есть
DFD
диаграмма
позволит
наглядно
изучить
с
какими
объектами базы данных будет взаимодействовать тот или
иной
процесс.
Контекстная
же
диаграмма
в
частности
позволит определить, какие лица, взаимодействующие с
системой, какую информацию будут получать.
На
рисунке
28
модели,
которая
описывает
внешних
магазина
объектов:
Google
приведена
контекстная
взаимодействие
разработчика,
Play
Store.
аналитика
Основным
диаграмма
с
системой
и
самого
пользователем
системы будет являться аналитик, который и направляет
запросы на получение данных (открытие WEB-страниц) к
системе. Разработчик вносит начальные данные, которые
система будет использовать в дальнейшем. Google Play Store
же является основным источником данных для системы.
52
Рисунок 28 – Контекстная диаграмма DFD-модели процесса
сбора обработки и визуализации данных магазина Google Play
Store
На
рисунке
описывающая
29
приведена
внутреннее
декомпозиция
перемещение
процесса,
данных
между
подпроцессами. Так запросы, поступающие от аналитика,
обрабатываются рядом процессов, часть из которых получает
данные непосредственно из самого магазина и записывает
эти
данные
представленное
во
внутреннее
четырьмя
хранилище
основными
системы,
накопителями,
соответствующие таблицам единого хранилища, в которых
будут храниться данные приложений каждой коллекции.
53
Другая
часть
процессов
использует
данные
из
внутреннего хранилища и использует их для формирования
WEB-страниц, которые и предоставляются аналитику.
Рисунок 29 – Декомпозиция DFD-модели процесса сбора
обработки и визуализации данных магазина Google Play Store
2.4 Архитектура системы и ее программное
обеспечение
При разработке мобильного приложения использовались
следующие программные средства, описанные ниже.
PyCharm
–
интегрированная
среда
разработки
для
языка программирования Python. Предоставляет средства
для анализа кода, графический отладчик, инструмент для
запуска
юнит-тестов
и
поддерживает
веб-разработку
на
Django. PyCharm разработана компанией JetBrains на основе
54
IntelliJ IDEA. Данная среда разработки доступна для Windows,
OS X и Linux.
PhpStorm
–
коммерческая
интегрированная
среда
кросс-платформенная
разработки
для
PHP.
Разрабатывается компанией JetBrains на основе платформы
IntelliJ IDEA.
Anaconda – это платформа для научных исследований,
основанная на языке программирования Python. Основная
цель этого пакета - предоставить организациям возможность
успешно защищать, интерпретировать, масштабировать и
хранить данные, которые имеют решающее значение для
повседневной работы.
phpMyAdmin – веб-приложение с открытым кодом,
написанное на языке PHP и представляющее собой вебинтерфейс
для
PhpMyAdmin
администрирования
позволяет
через
браузер
СУБД
и
MySQL.
не
только
осуществлять администрирование сервера MySQL, запускать
команды SQL и просматривать содержимое таблиц и баз
данных. Приложение пользуется большой популярностью у
веб-разработчиков,
MySQL
без
так
как
позволяет
непосредственного
ввода
управлять
СУБД
SQL
команд,
диаграмма
пакетов
предоставляя дружественный интерфейс.
На
рисунке
30
приведена
информационной системы, отображающая структуру проекта
системы,
а
также
принципы
взаимодействия
между
модулями.
55
Рисунок 30 – Диаграмма пакетов
Как видно из рисунка 30, было выделено два основных
пакета: клиентская и серверная части. Клиентская часть
обрабатывает запросы пользователя, связанных с выбором
коллекций, данные по которым необходимо выводить, а
также с выбором периода и скачиванием данных за этот
период в формате электронных таблиц MS Excel. Серверная
часть выполняет внутренние обработки по сбору и обработке
данных, а также по формированию страниц, представляемых
пользователю.
В пакетах «Клиентская часть» и «Серверная часть»
также были выделены пакеты, сформированные по основным
функциональным направлениям системы.
Клиентская часть:
-
WEB-интерфейс
(соответствует
фрагменту
кода
приложения А, пункта «Шаблон HTML-страницы коллекции»)
– пакет, отвечающий за обработку запросов пользователя со
стороны клиента, в том числе и запросов, связанных со
скачиванием данных за определенный период, импортируя
функции модуля обработки выбора дат;
56
- модуль обработки выбора дат – пакет, занимающийся
обработкой
полей
формы,
предназначенной
для
выбора
периода, за который клиенту необходимо получить данные.
Серверная часть:
- модуль сбора данных (соответствует фрагменту кода
приложения А, пункта «Модуль считывания данных с Google
Play
Store»)
–
подключение
к
пакет,
Google
функции
Play
которого
Store
и
сбор
выполняют
данных
по
приложениям с него;
- модуль обработки данных (соответствует фрагменту
кода приложения А, пункта «Фрагмент модуля обработки
данных»)
–
пакет,
функции
аномальных значений
которого
в данных,
выполняют
поиск
а также форматируют
данных, приводя их к виду, удобному для дальнейшего
использования;
- модуль работы с базой данных – пакет, выполняющий
подключение к базе данных и обрабатывающий процессы
внесения данных в базу и получения данных из неё с
использованием функций пакетов «Модуль сбора данных» и
«Модуль обработки данных», а также выполняющий процесс
формирования файла электронных таблиц MS Excel, который
будет использован модулем формирования WEB-страниц для
последующей передачи файла пользователю;
- модуль формирования WEB-страниц (соответствует
фрагменту кода приложения А, пункта «Фрагмент модуля
формирования графиков») – пакет, формирующий страницы,
запрошенные пользователем, используя при этом данные,
полученные из базы при помощи модуля работы с базой
данных.
57
2.5 Информационное обеспечение задачи анализа
Даталогическая
модель
–
модель
данных,
ориентированная на выбранный тип СУБД и представляет
собой отображение логических связей между элементами
данных, то есть модель хранилища системы, реализованного
на
основе
реляционной
базы
данных
и
СУБД
MySQL.
Физическая модель системы представлена на рисунке 32
ниже.
Инфологическая
модель
базы
данных
–
модель,
представляющая собой описание объектов (сущностей), с
набором атрибутов и связей между ними, выявленных в
процессе исследования как входных, так и выходных данных
[8, 9]. Цель инфологического моделирования – обеспечение
наиболее
естественных
для
человека
способов
сбора
и
представления той информации, которую предполагается
хранить
в
инфологическую
создаваемой
модель
базе
данных
данных.
пытаются
Поэтому
строить
по
аналогии с естественным языком (последний не может быть
использован в чистом виде из-за сложности компьютерной
обработки текстов и неоднозначности любого естественного
языка).
Основными
конструктивными
элементами
инфологических моделей являются сущности, связи между
ними и их свойства (атрибуты).
58
Инфологическая модель системы, описанная в нотации
П. Чена, приведена на рисунке 31.
Рисунок 31 – Инфологическая модель разрабатываемой
системы
Даталогическая
ориентированная
модель
на
–
выбранный
это
тип
модель
данных,
СУБД,
которая
представляет собой отражение логических связей между
элементами данных [7, 9]. Она является представлением
объектов (таблиц, атрибутов) в виде, который применим к
выбранному типу СУБД.
59
Даталогическая модель, отражающая структуру базы
данных,
основанную
на
реляционной
модели
данных,
разрабатываемой системы, приведена на рисунке 32.
Рисунок 32 – Даталогическая модель разрабатываемой
системы
Более подробное описание каждой сущности и атрибутов
даталогической
модели
приведено
в
таблицах
1
–
6
приложения А.
60
На
основе
даталогической
была
разработана
база
данных, физическая модель которой представлена на рисунке
33.
Рисунок 33 – Физическая модель хранилища данных
Как видно, в отличии от даталогической модели, при
реализации базы данных было решено разделить сущность
«App» на 4 таблицы в соответствии с коллекциями, в которых
они
собираются.
Такой
занимаемой
памятью,
отклика
запросы
на
подход
значительно
пользователя
позволяет,
жертвуя
увеличить
скорость
при
загрузке
WEB-
страницы. Причиной этого является то, что при отправке
пользователем запроса на агрегацию и визуализацию данных
61
по одной из коллекций вычислительная машина не будет
затрачивать время на перебор и сравнение многочисленных
записей, имеющихся в базе, а выведет все записи из
соответствующей запросу таблицы. Эмпирическим методом, с
использованием
монитора
ресурсов,
встроенного
в
Яндекс.Браузер, была выявлена разница между временем
загрузки WEB-страницы «Бестселлеры» при использовании
схемы
базы
данных
с
одной
таблицей
и
с
четырьмя
таблицами приложений: при одной общей таблице загрузка
страницы занимает приблизительно 26 секунд, а при четырёх
таблицах – приблизительно 15 секунд.
Поля
даталогической
соответствуют
полям
модели
физической
имеют
модели,
полностью
включая
наименование и типы данных.
На рисунке 34 приведён пример хранимой информации
из таблицы «history_top_grossing».
Рисунок 34 – Пример хранения информации в базе
62
2.6 Технологическое обеспечение задачи сбора и
обработки информации о мобильных приложениях
Так как данные по Android-приложениям возможно
получить лишь непосредственно с сайта Google Play Store,
было решено реализовать сбор этих данных методом WEBscrapping’а, который подразумевает считывание исходного
кода
страницы
и
вычленение
из
него
необходимой
информации [4, 5].
Общий
принцип,
соответствующий
фрагменту
кода,
приведенному в приложении А пункте «Модуль считывания
данных с Google Play Store» работы системы приведен на
диаграмме деятельности, представленной на рисунке 35.
63
Рисунок 35 – Диаграмма деятельности, описывающая процесс
сбора данных
64
Основной для любого WEB-сайта является модель его
структуры, а именно «Карта сайта». В данной работе был
построен вариант модели «Карта сайта» в форме графа,
который показывает не только структуру сайта, но и порядок
перехода между страницами сайта (рисунок 36).
Рисунок 36 – Модель «Граф страниц»
Как видно из модели, приведенной на рисунке 35,
пользователь
должен
иметь
возможность
перейти
по
гиперссылкам из любой страницы в любую страницу.
2.7
Обоснование
экономической
эффективности
проекта
Расчет был произведен по отраслевому стандарту ОСТ
4.071.030.
Для
исследования
разрабатываемой
экономической
системы
был
эффективности
выбран
метод
65
инвестиционного
анализа,
позволяющий
оценить
эффективность разрабатываемой системы на основе затрат.
Чтобы
рассчитать
показатели
экономической
эффективности, необходимо сравнить данные по затратам до
внедрения информационной системы анализа деятельности
предприятия и после внедрения.
Трудоемкость работ по внедрению ИС определяется с
учетом
срока
окончания
работ,
объема
выполняемых
функций, выбранной среды программирования. Рассчитанная
трудоемкость работ, согласно графика работ, представлена в
таблице 5.
Т а б л и ц а 5 – Комплекс работ по разработке проекта
Загрузка
Процен
Дни
ты
Формирование системных требований
Научный
Анализ
1,5
30%
руководитель
предметной
5
области
Студент
4
80%
Научный
Анализ
0,45
15%
руководитель
существующих
3
решений
Студент
0,6
20%
Определение и
Научный
9,5
50%
анализ
руководитель
19
требований к
Студент
19
100%
системе
Итого по
Научный
11,45
этапу
руководитель
«Формирован
27
ие
Студент
23,6
системных
требований»
Проектирование системы
Научный
3,6
40%
Структурное
руководитель
моделировани
9
Преподаватель
1,35
15%
е
Студент
9
100%
Содержание
работ
Исполнители
Длительно
сть
Функциональн
Преподаватель
12
2,4
20%
66
ое
моделировани
е
Разработка
макетов
страниц
Проектирован
ие базы
данных
Итого по
этапу
«Проектиров
ание
системы»
Студент
Научный
руководитель
Студент
5
Студент
3
Научный
руководитель
Преподаватель
9,6
80%
0,75
15%
1
20%
3
100%
4,35
29
3,75
Студент
22,6
Реализация системы
Реализация
механизма
получения
данных
Реализация
алгоритмов
обработки
данных
Студент
53
37,1
70%
Студент
18
2,7
15%
Окончание таблицы 5
Содержание
работ
Реализация
базы данных
Реализация
серверной
части системы
Верстка
пользовательс
кой части
системы
Подключение
базы данных к
системе
Тестирование
системы
Доработка
системы
Итого по
этапу
«Реализация
системы»
Итого по
Загрузка
Процен
Дни
ты
Исполнители
Длительно
сть
Студент
8
0,4
5%
Студент
28
28
100%
Студент
21
2,1
10%
Студент
2
2
100%
Студент
5
5
100%
Студент
2
2
100%
Студент
137
79,3
Студент
193
125,5
67
проекту
Научный
руководитель
15,8
Преподаватель
3,75
Капитальные вложения, связанные с автоматизацией
обработки информации рассчитываются по формуле К =К п + К р,
где
Кп – капитальные вложения на проектирование (руб.), а
Кр – капитальные вложения на реализацию проекта (руб).
Суммарные затраты на проектирование системы и ее
разработку, и отладку на компьютере определяются по
формуле 2:
(2
)
m – количество работников, участвующих в
К п=¿
где
разработке проекта;
Зoi – затраты на основную заработную плату работника iй категории, руб. (таблица 6);
Т а б л и ц а 6 – Расчет основной зарплаты работников
Должность
Средня
я
дневна
я
ставка
17950
854,76
Должност
ной
оклад,
руб.
Научный
руководитель
Преподаватель
35900
Затраты
времени на
разработку
ti, человекодней
15,8
1709,52
3,75
Итого Зо
Wd
–
коэффициент,
учитывающий
ОЗП Зоi,
руб.
13505,24
6410,71
19915,9
5
дополнительную
заработную плату в долях к основной заработной плате (Wd =
0,4);
Wс
–
социальные
коэффициент,
нужды,
в
учитывающий
долях
к
отчисления
сумме
основной
на
и
68
дополнительной заработной платы разработчиков (Wс =
0,262);
Wн – коэффициент, учитывающий накладные расходы
организации,
в
долях
к
основной
заработной
плате
разработчиков (Wн = 0,6);
СM – затраты на материалы (таблица 7);
Т а б л и ц а 7 – Расчет затрат на материалы
Тетрадь общая
шт.
Требуемо
е
количест
во
2
Ручка гелевая
шт.
3
30
90
пачка
1
350
350
Единица
измерения
Материалы
Бумага офисная
Цена
за
единиц
у, руб.
50
Итого
Сумма
, руб.
100
540
Мв – затраты на использование машинного времени
(таблица 8) рассчитываются по формуле 3.
Т а б л и ц а 8 – Расчет затрат на использование машинного
времени
Затраты на
использование
машинного
времени Мв
Машинное
время на
проект tмв
Стоимость
одного часа
Sмч
Коэф.
мультипрограммн
ости Kм
506,50
953,87
0,531
1
(3
)
– машинное время компьютера, необходимое для
M в=t мв Sмч K м ,
где
tмв
разработки системы;
Sмч – стоимость 1 часа машинного времени (взята
средняя
стоимость
в
бюджетных
учреждениях
в
г.
Владивосток);
69
Км – коэффициент мультипрограммности (из расчета, что
машина будет использоваться исключительно в целях работы
над проектом, коэффициент будет равен 1).
Список затрат на разработку приведен в таблице 9.
Т а б л и ц а 9 – Общие затраты на разработку
Статьи затрат
Сумма, руб.
Основная заработная плата Зо
19915,95
Дополнительная зарплата Wd
7966,38
Отчисления на социальные нужды
7305,17
Затраты на материалы
540,00
Затраты на машинное время
506,50
Накладные расходы организации
11949,57
ИТОГО
Капитальные
48183,58
вложения
на
реализацию
проекта
рассчитываются по формуле 4:
где
Кр = Ко + Кдд + Кпп + Ксв + Киб + Кпк,
(4)
Ко – затраты на основное и вспомогательное
оборудование, руб.;
Кзд – затраты на строительство, реконструкцию здания и
помещений, руб.;
Кпп – затраты на приобретение типовых разработок,
пакетов, руб.;
Ксв – затраты на прокладку линий связи, руб.;
Киб – затраты на создание информационной базы, руб.;
Кпк – затраты на подготовку и переподготовку кадров,
руб.
В
связи
с
рассматриваемой
тем,
в
что
данном
для
внедрения
проекте,
не
было
системы,
затрат,
связанных с прокладкой линии связи, затрат на основное и
вспомогательное оборудование, затрат на реконструкцию и
строительство зданий, то данные затраты для внедрения
70
системы не учитывают. Также не принимаются в расчет
затраты по подготовке и переподготовке кадров, затраты на
создание информационной базы и затраты на приобретение
типовых
разработок.
Однако
учитывая
то,
что
для
функционирования системы, разрабатываемой в форме сайта,
требуется оплатить хостинг.
Затраты на хостинг будут отнесены к капитальным
вложениям на реализацию проекта и будут браться как
средняя стоимость хостинга за месяц.
В итоге суммарные затраты на разработку проекта
составят: K =K п + K р =48183,58+150=48333,58 руб .
Так как разрабатываемая система и системы-аналоги
позиционируются как сторонние WEB-сайты, то следует
учесть затраты на оплату хостинга. Так как все хостинги, как
и аналоги разрабатываемой системы, имеют ежемесячную
оплату, то расчет их стоимости будет произведен за год (т.е.
12 месяцев).
Таким образом эксплуатационные затраты будут равны
Зэ =З м=150∗12=1800руб .
из
расчета,
что
средняя
сумма
ежемесячного платежа за услуги хостинга равна 150 руб.
Затраты же, связанные с использованием аналогов,
получаются
из
расчета,
что
каждый
аналог
требует
ежемесячной оплаты, и исчисляются за год. То есть затраты
в год на использование аналогов, определенных в первой
лабораторной работе, будут составлять 100$ * 12 = 1200$ ≈
79000 рублей для сайта-аналога «AppAnnie» и 5500 * 12 =
66000 рублей для сайта-аналога «APPFOLLOW».
Для
требуется
расчета
показателя
рассчитать
экономического
приведенные
затраты
на
эффекта
единицу
71
работ, выполняемых с помощью разрабатываемой системы и
системы-аналога.
Учитывая, что системы являются сторонними WEBсервисами, то затрат на их внедрение не предполагается,
однако каждая система имеет себестоимость, в данном
случае,
равную
стоимости
хостинга
в
разрабатываемой
системе и ежемесячный платёж для системы-аналога. Расчет
будет произведен за год (т.е. 12 месяцев).
Таким
образом
показатель
экономического
эффекта
будет равен:
Э=( З1∗Ak−З2 )∗N =( 79000∗1,45−1800 )∗1=112750
После определения годового экономического эффекта
необходимо
рассчитать
срок
окупаемости
затрат
на
разработку продукта:
Т ок =
К 48333,58
=
≈ 0,4
Э
112750
Затем
был
рассчитан
фактический
коэффициент
экономической эффективности разработки (Еф) и сопоставлен
с нормативным значением коэффициента эффективности
капитальных вложений Ен =0,33:
Еф =
1
1
=
=2,5
Т ок 0,4
Фактический
коэффициент
эффективности
разработки
нормативный,
поэтому
получился
разработка
экономической
больше,
и
чем
внедрение
разрабатываемого продукта является эффективной.
Таким образом, в ходе проделанной работы найдены все
необходимые данные, доказывающие целесообразность и
эффективность данной разработки, которые приведены в
таблице 10.
72
Таблица
10 – Результаты экономического обоснования
проекта
Характеристика проекта
Значение
Затраты на разработку и внедрение проекта, руб.
48333,58
Общие эксплуатационные затраты, руб.
1800
Экономический эффект, руб.
112750
Коэффициент экономической эффективности
2,5
Срок окупаемости, лет
0,4
2.8 Описание контрольного примера реализации
проекта
Так как разрабатываемая система представляется в виде
сайта, в качестве контрольного примера будут приведены
страницы
приведена
разработанного
страница,
сайта.
На
отображающая
рисунках
набор
37-38
графиков,
построенных на основе данных приложений, попавших в
коллекцию «Бестселлеры».
73
Рисунок 37 – Первая часть страницы системы, отображающая
статистику по коллекции «Бестселлеры»
На рисунке 37 приведены графики, отражающие общую
информацию о количестве приложений каждого жанра, о
количестве приложений, имеющих и не имеющих встроенные
покупки,
средние
минимальную
и
максимальную
цены
встроенных покупок, о количестве приложений в каждой
возрастной категории и о средних пользовательских оценках
для каждого жанра.
74
Анализируя информацию, приведенную на странице,
можно заметить, что приложения в категориях «Знакомства»
и «Развлечения» имеют самые низкие средние показатели
рейтингов ~3,6 баллов.
Рисунок 38 – Первая часть страницы системы, отображающая
статистику по коллекции «Бестселлеры»
На
рисунке
информацию
о
38
приведены
количестве
графики,
платных
и
отражающие
бесплатных
75
приложений,
о
средних
пользовательских
оценках
приложений, имеющих и не имеющих встроенные покупки, о
средних пользовательских оценках в каждой возрастной
категории, о среднем количестве скачиваний в каждой
возрастной категории, о количестве скачиваний в каждой
рейтинговой группе.
По
этим
графикам
можно
заметить,
что
группа
развлечений находится не на последнем месте по числу
скачиваний. По этой информации разработчик мобильных
приложений может сделать вывод о том, что пользователи, в
силу широкой популярности этой категории, возможно, будут
искать альтернативы с более высоким рейтингом, а значит,
разработка такого приложения имеет шанс попасть в поле
зрения пользователя [8, 9].
Аналогичными методами можно произвести широкий
спектр аналитических расчётов и построения гипотез по
различным
показателям:
категории
пользователей
(возрастной рейтинг), влияние наличия встроенных покупок
на
количество
скачиваний
и
рейтинги
пользователей,
влияние цен приложений на скачивания и рейтинги и так
далее.
Подобный
подход
к
анализу
данных
позволит
разработчику широко оценить текущее состояние рынка
«лучших»
Android-приложений
и
принять
различные
решения, которые повлияют на качество, направленность и
формат разрабатываемого приложения.
Помимо формирования стандартных графиков система
позволяет
пользователю
получить
выгрузку
данных
за
определенный период. Для этого пользователю требуется
76
выбрать
необходимый
период,
находясь
на
странице
выгружаемой коллекции и нажать на кнопку «Скачать
данные» в верхней части страницы, приведенной на рисунке
39.
Рисунок 39 – Поле выбора дат и загрузки необходимых
данных за выбранный период
Результат
сформированной
приложении В на рисунке В.1.
выборки
приведен
в
Заключение
В
ходе
выполнения
выпускной
квалификационной
работы были закреплены и углублены знания в области
информационных
систем
самостоятельного
решения
и
экономики
реальных
путем
производственно-
хозяйственных, экономических и управленческих проблем,
полученные в ходе обучения.
Рассмотрено
области
(«КАК
состояния
ЕСТЬ»)
существующей
процесса
предметной
проведения
анализа,
характеристики объекта и аппарата управления.
Выявлены
проблемы
и
недостатки
в
процессе
проведения анализа рынка мобильных приложений. Также
был представлен и обоснован путь устранения выявленных
недостатков. Произведено описание входной и выходной
информации. Определены цели автоматизации и произведено
описание
решений,
принятых
по
всей
вертикали
проектирования и продемонстрирован контрольный пример.
77
При выполнении данной выпускной квалификационной
работы были решены следующие задачи:
–
произведен
маркетинга
анализ
компаний,
предметной
области
занимающихся
отдела
разработкой
мобильных приложений;
–
выявлены
недостатки
в
процессе
анализа
и
предложены решения по автоматизации процессов;
–
была
спроектирована
информационная
система
сбора, обработки и визуализации информации по мобильным
приложениям;
–
была
реализована
спроектированная
информационная система.
В
дальнейшем
планируется
усовершенствование
интерфейса приложения, а также добавление функций по
выделению негативных отзывов пользователей, по выбору
временного
интервала,
для
которого
была
выведена
статистика и т.д.
78
Список литературы
Нормативно-правовые акты
1. Отраслевой стандарт «Автоматизированная система
управления
предприятием.
Создание
системы»
//
ОСТ
4.071.030
Учебники и учебные пособия
1. Бабич А.В. Введение в UML. Учебное пособие/ А.В.
Бабич — М.: НОУ ИНТУИТ, 2016. - 209 c.
2. Барсегян А.А., Куприянов М.С., Степаненко В.В.,
Холод И.И. Методы и модели анализа данных: OLAP и Data
Mining - СПб.: БХВ-П., 2007 – 331 c.
3. Барсегян А.А., Куприянов М.С. Технологии анализа
данных. Data Mining, Visual Mining, Text Mining, OLAP. - СПб.:
БХВ-П., 2007 – 384 с.
4. Бриггс, Джейсон Python для детей. Самоучитель по
программированию / Джейсон Бриггс. - Москва: Огни, 2013. 177 c.
5. Бэрри, Пол Изучаем программирование на Python /
Пол Бэрри. - М.: Эксмо, 2016. - 332 c.
6. Васильев, А. Н. Python на примерах. Практический
курс по программированию / А.Н. Васильев. - М.: Наука и
техника, 2016. - 432 c.
7. Васильев, Александр Николаевич Python на примерах.
Практический курс по программированию. Руководство. - М.:
Наука и техника, 2017. - 752 c.
8. Гуриков,
С.Р.
Основы
алгоритмизации
и
программирования на Python / С.Р. Гуриков. - М.: Форум,
2018. - 991 c.
9. Гуриков,
С.Р.
Основы
алгоритмизации
и
79
программирования на Python. Учебное пособие. Гриф МО РФ.
- М.: Инфра-М, Форум, 2018. - 707 c.
10. Златопольский, Д. М. Основы программирования на
языке Python / Д.М. Златопольский. - М.: ДМК Пресс, 2017. 277 c.
11. Каюмова А.В. Визуальное моделирование систем в
StarUML. Учебное пособие. Казань. – Казанский федеральный
университет, 2013. –104с.
12. МакГрат,
Майк
Python.
Программирование
для
начинающих / Майк МакГрат. - М.: Эксмо, 2013. - 727 c.
13. Маклаков, С.В. BPWIN и ERWIN. Case - средства
разработки информационных систем. – М.: ДИАЛОГ-МИФИ,
2009. – с. 163.
14. Туманов
В.Е.
Проектирование
реляционных
хранилищ данных. Учебное пособие – М.: Диалог-МИФИ,
2007. - 333с.
Электронные ресурсы
1. A
Statistical
[Электронный
Analysis
of
источник]
the
Apple
–
App
Store
URL:
https://blog.scottlogic.com/2014/03/20/app-store-analysis.html
2. Analysis of Apps in the Google Play Store [Электронный
источник]
–
URL:
https://nycdatascience.com/blog/student-
works/web-scraping/analysis-of-apps-in-the-google-play-store/
3. Google Play Store Apps [Электронный источник] – URL:
https://play.google.com/store/apps
4. Number of Android apps on Google Play [Электронный
источник] – URL: https://www.appbrain.com/stats/number-ofandroid-apps
5. SQLite Studio [Электронный ресурс] // «SQLiteStudio»
80
[сайт]. Режим доступа: https://sqlitestudio.pl/index.rvt
6. Малышева,
систем.
Е.Н.
Проектирование
информационных
Объектно-ориентированная
проектирования
информационных
case-технология
систем
[Электронный
ресурс]: учебное пособие. — Электрон. дан. — Кемерово:
КемГУКИ
(Кемеровский
государственный
университет
культуры и искусств), 2009. — 70 с.
7. Обзор
[Электронный
ресурс]
//
“FileZilla”
[сайт].
Режим доступа: https://filezilla-project.org/
8. Руководство к своду знаний по управлению проектами,
5 издание [Электронный ресурс]. Режим доступа: http://pmfiles.com/sites/default/files/file/C/C-1/C-1-1/pmbok_5th_2013_rus.
pdf
9. Современные методы анализа данных [Электронный
источник]
–
URL:
http://riep.ru/upload/iblock/031/031173bb40e099800b248497db
44cb88.pdf
10. Юридический
отдел:
обязанности
и
функции
[Электронный ресурс] // “Генеральный директор” [сайт].
Режим доступа: https://www.gd.ru/articles/8920-yuridicheskiyotdel
Приложение А
Описание сущностей и атрибутов даталогической
модели
Сущность «App» – основная сущность, которая отражает
представление самого приложения в базе данных.
Т а б л и ц а 1 – Описание сущности «App»
Наименование
атрибута
Тип
атрибута
Описание атрибута
81
date_point
date
app_id
varchar
(255)
title
score
text
float
Первичный ключ. Хранит дату
записи приложения в базу данных
Первичный ключ. Хранит
текстовый ID приложения,
присвоенный ему разработчиком
при публикации приложения в
магазине
Наименование приложения
Средняя пользовательская оценка
price
integer (7)
Цена приложения
free
boolean
iap
boolean
varchar
(30)
varchar
(50)
varchar
(15)
iap_range
size
installs
Внешний ключ. Хранит одно из
двух значений: «платное
приложение» или «бесплатное
приложение»
Внешний ключ. Хранит одно из
двух значений: «приложение
имеет встроенные покупки» или
«приложение не имеет встроенных
покупок»
Диапазон стоимостей встроенных
покупок
Размер приложения
Число скачиваний приложения
content_rating
integer (1)
Внешний ключ. Хранит код
возрастной категории приложения
category
integer (3)
Внешний ключ. Хранит код жанра
приложения
collection
integer (1)
Внешний ключ. Хранит код
коллекции приложения
Сущность «free» – вспомогательная сущность, которая
хранит
в
себе
варианты
распространения
приложения
(платно или бесплатно).
Т а б л и ц а 2 – Описание сущности «free»
Наименование
атрибута
id_free
Тип
атрибута
boolean
Описание атрибута
Первичный ключ. Хранит код
значения
82
name_free
varchar (4)
Текстовое представление значения
(«True» / «False»)
translate_free
varchar
(10)
Текстовое представление значения
на русском языке
Сущность «iap» – вспомогательная сущность, которая
хранит в себе варианты наличия встроенных покупок в
приложении (есть или нет).
Т а б л и ц а 3 – Описание сущности «iap»
Наименование
атрибута
Тип
атрибута
id_iap
boolean
name_iap
varchar (4)
translate_iap
varchar
(10)
Сущность
«category»
Описание атрибута
Первичный ключ. Хранит код
значения
Текстовое представление значения
(«True» / «False»)
Текстовое представление значения
на русском языке
–
вспомогательная
сущность,
которая хранит в себе список всех жанров, которые могут
иметь приложения.
Т а б л и ц а 4 – Описание сущности «category»
Наименование
атрибута
Тип
атрибута
Описание атрибута
id_category
integer (3)
name_category
varchar
(255)
Первичный ключ. Хранит код
жанра
Текстовое представление жанра на
английском языке
translate_category
varchar
(255)
Текстовое представление жанра на
русском языке
Сущность
«collection»
–
вспомогательная
сущность,
которая хранит в себе список коллекций, к которым могут
относиться приложения.
83
Т а б л и ц а 5 – Описание сущности «collection»
Наименование
атрибута
Тип
атрибута
Описание атрибута
id_collection
integer (1)
name_collection
varchar
(15)
Первичный ключ. Хранит код
коллекции
Текстовое представление
коллекции на английском языке
translate_collection
varchar
(15)
Текстовое представление
коллекции на русском языке
Сущность «content_rating» – вспомогательная сущность,
которая хранит в себе список возрастных категорий, которые
могут иметь приложения.
Т а б л и ц а 6 – Описание сущности «content_rating»
Наименование
атрибута
Тип
атрибута
Описание атрибута
id_c_rating
integer (1)
Первичный ключ. Хранит код
возрастной категории
name_c_rating
varchar
(10)
Текстовое представление
возрастной категории
84
Приложение Б
Фрагменты кода разрабатываемой системы
В
данном
приложении
приведены
только
основные
фрагменты кода, так как полный листинг системы слишком
большой.
Модуль считывания данных с Google Play Store
import play_scraper
import MySQLdb
import datetime
import time
from colorama import Fore
from threading import Thread, BoundedSemaphore as bs
start_time = time.time()
sem = bs() # Семафор, способный держать в себе 1 поток (default).
Аргумент 'value' хранит количество потоков в очереди.
def scrapy(table, collection, nums, page):
while True:
print(Fore.LIGHTBLUE_EX, page, "Repeat!")
global apps_collection, row
# Флаг на продолжение цикла for, если одно из приложений
окажется битым и вылетет exception
continue_flag = False
# Флаг на прерывание цикла for, если стек приложений коллекции
заполнен (500 из 500)
full_stack_flag = False #
try:
apps_collection = play_scraper.collection(collection=collection,
results=nums, page=page)
print(page, "Получили коллекцию приложений!")
conn = MySQLdb.connect('localhost', 'VProgramMist',
'1998Vm0000', 'mobasta_history', charset='utf8mb4',
use_unicode=False)
cursor = conn.cursor()
cursor.execute("SET CHARACTER SET utf8mb4;")
cursor.execute("SET character_set_connection=utf8mb4;")
85
# Курсоры для получения внешних ключей
cursor_cat = conn.cursor()
cursor_rait = conn.cursor()
cursor_free = conn.cursor()
cursor_iap = conn.cursor()
cursor_key_checker = conn.cursor()
print(Fore.WHITE, page, "Связались с базой и получили
курсоры!")
for app in apps_collection:
while True:
try:
sql_str = "SELECT * FROM " + table + " WHERE app_id =
%s AND date_point = %s;"
cursor_key_checker.execute(sql_str,
(app['app_id'], datetime.date.today()))
if not cursor_key_checker.fetchone() is None:
print(page, Fore.YELLOW + "Приложение ",
app['app_id'], " уже в базе!")
break
print(Fore.GREEN, page, "Совпадений нет!")
try:
row = play_scraper.details(
app['app_id']) # Ищем каждое приложение, для
получения детальных записей
except:
print(Fore.RED, page, "Приложение болезненное!
Переходим к другому...")
continue_flag = True
break
print(Fore.WHITE, page, "Нашли приложение и собрали по
нему данные!", row['title'])
if not row['iap_range'] is None:
if not row['iap_range'][0].strip().startswith('RUB'):
row['iap_range'] = play_scraper.details(row['app_id'])
['iap_range'][0]
row['iap'] = 'True'
else:
row['iap'] = 'False'
sql_str = "SELECT id_category FROM category WHERE
name_category = %s;"
cursor_cat.execute(sql_str,
[row['category'][0]])
sql_str = "SELECT id_c_rating FROM content_rating WHERE
name_c_rating = %s;"
cursor_rait.execute(sql_str,
86
[row['content_rating'][0]])
sql_str = "SELECT id_free FROM free WHERE name_free =
%s;"
cursor_free.execute(sql_str,
[str(row['free'])])
sql_str = "SELECT id_iap FROM iap WHERE name_iap =
%s;"
cursor_iap.execute(sql_str,
[str(row['iap'])])
print(Fore.CYAN, page, "Получили внешние ключи!")
sem.acquire()
# Через семафор позволяем одному потоку выполнить
запись строки в базу
# и блокируем доступ к записи в базу строк другими
потоками
sql_str = "SELECT * FROM " + table + " WHERE app_id =
%s AND date_point = %s;"
cursor_key_checker.execute(sql_str,
(app['app_id'], datetime.date.today()))
if not cursor_key_checker.fetchone() is None:
print(page, Fore.YELLOW + "Приложение ",
app['app_id'], " уже в базе!")
sem.release()
break
sql_str = """INSERT
INTO """ + table + """(app_id, title, score, price, free, iap,
iap_range, size, installs, content_rating,
date_point, category)
VALUES (%s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s,
%s);"""
# Блок проверки числа записей. Если число записей за
текущий день = 500, то прерываем
# обновление. Требуется для получения более
достоверных данных при анализе данных.
cursor.execute(
"SELECT COUNT(*), DATEDIFF(MAX(date_point),
MIN(date_point)), MAX(date_point) FROM " + table)
row_count = cursor.fetchone()
if (row_count[0] - 500 * row_count[1]) >= 500 and
row_count[2] == datetime.date.today():
continue_flag = False
full_stack_flag = True
sem.release()
87
break
cursor.execute(sql_str, (row['app_id'], row['title'],
row['score'],
row['price'], str(int(cursor_free.fetchone()
[0])),
str(int(cursor_iap.fetchone()[0])),
row['iap_range'], row["size"], row['installs'],
cursor_rait.fetchone()[0],
datetime.date.today(),
cursor_cat.fetchone()[0]))
print(Fore.GREEN, page, "Записали строку в базу!")
conn.commit() # Фиксируем все изменения в базе
sem.release() # Через семафор освобождаем очередь
потоков для записи
print(Fore.GREEN, page, row['app_id'])
except:
print(Fore.RED, page, "Проблемы с базой!")
try:
sem.release()
except:
pass
conn.commit() # Фиксируем все изменения в базе
if row['price'] is None:
break
cursor_cat.close()
cursor_rait.close()
cursor_free.close()
cursor_iap.close()
cursor.close()
conn.close()
print(Fore.YELLOW, page, "Закрыли проблемное
соединение!")
conn = MySQLdb.connect('localhost', 'VProgramMist',
'1998Vm0000', 'mobasta_history',
charset='utf8mb4',
use_unicode=False)
cursor = conn.cursor()
cursor.execute("SET CHARACTER SET utf8mb4;")
cursor.execute("SET character_set_connection=utf8mb4;")
88
# Курсоры для получения внешних ключей
cursor_cat = conn.cursor()
cursor_rait = conn.cursor()
cursor_free = conn.cursor()
cursor_iap = conn.cursor()
cursor_key_checker = conn.cursor()
print(Fore.YELLOW, page, "Открыли соединение
повторно!")
continue
break
if continue_flag:
continue
if full_stack_flag:
break
cursor_cat.close()
cursor_rait.close()
cursor_free.close()
cursor_iap.close()
cursor.close()
conn.close()
print(Fore.LIGHTRED_EX, page, "Закрыли соединение!")
except:
print(Fore.RED, page, "Проблемы с сетью!")
continue
break
dic_coll = {
'history_top_free': 'TOP_FREE',
'history_top_paid': 'TOP_PAID',
'history_trending': 'TRENDING',
'history_top_grossing': 'TOP_GROSSING',
}
for i in dic_coll:
# Блок проверки числа записей. Если число записей за текущий день
= 500, то прерываем обновление.
# Требуется для получения более достоверных данных при анализе
данных.
conn = MySQLdb.connect('localhost', 'VProgramMist', '1998Vm0000',
'mobasta_history', charset='utf8mb4',
use_unicode=False)
cursor = conn.cursor()
cursor.execute("SELECT COUNT(*), DATEDIFF(MAX(date_point),
MIN(date_point)), MAX(date_point) FROM " + i)
89
t = cursor.fetchone()
if (t[0] - 500 * t[1]) >= 500 and t[2] == datetime.date.today():
continue
# Если число записей за текущие сутки < 500 то приступаем к
выполнению скрипта
thread1
thread2
thread3
thread4
thread5
=
=
=
=
=
Thread(target=scrapy,
Thread(target=scrapy,
Thread(target=scrapy,
Thread(target=scrapy,
Thread(target=scrapy,
args=(i,
args=(i,
args=(i,
args=(i,
args=(i,
dic_coll.get(i),
dic_coll.get(i),
dic_coll.get(i),
dic_coll.get(i),
dic_coll.get(i),
108,
108,
108,
108,
108,
1))
2))
3))
4))
5))
thread1.start()
thread2.start()
thread3.start()
thread4.start()
thread5.start()
thread1.join()
thread2.join()
thread3.join()
thread4.join()
thread5.join()
Фрагмент модуля обработки данных
def get_data_from_table(table, key):
warnings.filterwarnings("ignore")
conn = MySQLdb.connect('localhost', 'VProgramMist', '1998Vm0000',
'mobasta_history', charset='utf8mb4',
use_unicode=False)
cursor = conn.cursor()
cursor.execute("SELECT * FROM {table} LIMIT 1".format(table=table))
cursor.execute("""SELECT date_point, app_id, title, score, price,
free_translate, iap_translate, iap_range,
size, installs, name_c_rating, category_translate
FROM ((( {table} LEFT JOIN category
ON {table}.category = category.id_category) LEFT JOIN
content_rating
ON {table}.content_rating = content_rating.id_c_rating) LEFT JOIN
free
ON {table}.free = free.id_free) LEFT JOIN iap
ON {table}.iap = iap.id_iap""".format(table=table))
cf = cursor.fetchall()
cursor.close()
conn.close()
90
# Коллекция для данных, полученных из базы
dt = {"Date point": [],
"ID": [],
"Title": [],
"Rating score": [],
"Price": [],
"Free": [],
"IAP": [],
"IAP Range": [],
"Size": [],
"Installs": [],
"Content rating": [],
"Category": []}
for i in cf:
for j, c in zip(i, dt.keys()):
if c == "Category":
dt[c].append(j.decode(encoding="utf-8", errors="strict"))
else:
dt[c].append(j)
data = pd.DataFrame(dt, columns=dt.keys())
# Реформат полей из байт-строк в строки
data['Installs'] = data['Installs'].apply(
lambda x: float(x.decode(encoding="utf-8", errors="strict").replace('+',
'').replace(',', '')))
for i in dt.keys():
bstr_to_str(data, i)
# Группировка приложений по жанрам
if key == 'Category count':
return (data.groupby('Category')
['Installs'].agg(np.size)).sort_values(ascending=False).to_dict()
# Группировка приложений по наличию встроенных покупок
elif key == 'IAP count':
return (data.groupby('IAP')['Installs'].agg(np.size)).to_dict()
# Группировка приложений по возрастным категориям
elif key == 'Content rating count':
return (data.groupby('Content rating')
['Installs'].agg(np.size)).sort_values(ascending=False).to_dict()
# Средняя цена встроенных покупок (ранжирование)
91
elif key == 'IAP Range':
dic = {0: [], 1: []}
for i in data['IAP Range']:
if not i is None:
a = i.replace('RUB ', '').replace('RUB\xa0', '').replace(',', '')
if '-' in a:
dic[0].append(float(a.split(' - ')[0]))
dic[1].append(float(a.split(' - ')[1]))
else:
dic[0].append(float(a))
dic[1].append(float(a))
return {0: np.average(dic[0]), 1: np.average(dic[1])}
# Средние оценки по категориям
elif key == 'Category and Rating':
return (data.dropna().groupby('Category')['Rating
score'].agg(np.average)).sort_values(ascending=False). \
to_dict()
# Количество платных / бесплатных приложений
elif key == 'Free count':
return (data.groupby('Free')['Installs'].agg(np.size)).to_dict()
# Средняя оценка по приложениям с наличием встроенных покупок
и без...
elif key == 'IAP and Rating':
return (data.dropna().groupby('IAP')['Rating
score'].agg(np.average)).to_dict()
# Средняя оценка по возрастным категориям
elif key == 'Content and Rating':
return (data.dropna().groupby('Content rating')['Rating
score'].agg(np.average)).sort_values(ascending=False). \
to_dict()
# Среднее количество скачиваний по возрастным категориям
elif key == 'Content rating and Installs':
return (data.groupby('Content rating')
['Installs'].agg(np.average)).sort_values(ascending=False).to_dict()
# Среднее количество скачиваний по категориям
elif key == 'Category and Installs':
return (data.groupby('Category')
['Installs'].agg(np.average)).sort_values(ascending=False).to_dict()
92
# Среднее количество скачиваний по оценкам
elif key == 'Installs and Rating':
return (data.dropna().groupby('Rating score')
['Installs'].agg(np.average)).sort_values(ascending=False). \
to_dict()
Фрагмент модуля формирования графиков
def top_grossing(request):
category_count_char = FusionCharts("column2d", "category-count",
"95%", "500", "category-count-char", "json",
get_chart('history_top_grossing', 'category_count'))
iap_count_char = FusionCharts("pie2d", "iap-count", "600", "400", "iapcount-char", "json",
get_chart('history_top_grossing', 'iap_count'))
cont_rating_count_char = FusionCharts("column2d", "cont-rait-count",
"800", "400", "cont-rating-count-char", "json",
get_chart('history_top_grossing',
'content_rating_count'))
category_and_rating_char = FusionCharts("column2d", "cat-and-rait",
"95%", "500", "category-and-rating-char",
"json", get_chart('history_top_grossing',
'category_and_rating'))
free_count_char = FusionCharts("pie2d", "free-count", "600", "400",
"free-count-char", "json",
get_chart('history_top_grossing', 'free_count'))
iap_and_rating_char = FusionCharts("column2d", "iap-and-rating", "600",
"400", "iap-and-rating-char",
"json", get_chart('history_top_grossing',
'iap_and_rating'))
content_and_rating_char = FusionCharts("column2d", "content-andrating", "600", "400", "content-and-rating-char",
"json", get_chart('history_top_grossing',
'content_and_rating'))
content_rating_and_installs_char = FusionCharts("column2d", "contentrating-and-installs", "600", "400",
"content-rating-and-installs-char", "json",
get_chart('history_top_grossing',
'content_rating_and_installs'))
category_and_installs_char = FusionCharts("column2d", "category-andinstalls", "95%", "500",
"category-and-installs-char", "json",
93
get_chart('history_top_grossing',
'category_and_installs'))
installs_and_rating_char = FusionCharts("column2d", "installs-andrating", "95%", "500", "installs-and-rating-char",
"json", get_chart('history_top_grossing',
'installs_and_rating'))
return render(request, 'index.html', {
'output': [
iap_count_char.render(),
category_count_char.render(),
cont_rating_count_char.render(),
category_and_rating_char.render(),
free_count_char.render(),
iap_and_rating_char.render(),
content_and_rating_char.render(),
content_rating_and_installs_char.render(),
category_and_installs_char.render(),
installs_and_rating_char.render()
],
'title': 'бестселлерам',
'iap_range': get_chart('history_top_grossing', 'iap_range'),
'today': datetime.date.today().strftime("%Y-%m-%d"),
'table': "top_grossing",
})
import json
from collections import OrderedDict
# Common base class for FC
class FusionCharts:
baseTemplate = """
<script type="text/javascript">
FusionCharts.ready(function () {
__FC__
});
</script>"""
constructorTemplate = """new FusionCharts(__constructorOptions__);"""
renderTemplate = """FusionCharts("__chartId__").render();"""
eventTemplate =
"""FusionCharts("__chartId__").addEventListener("_fceventname_",_fceventb
ody_);"""
# constructor
def __init__(self, type, id, width, height, renderAt, dataFormat,
dataSource):
94
self.eventOptions = OrderedDict()
self.constructorOptions = {}
self.constructorOptions['type'] = type
self.constructorOptions['id'] = id
self.constructorOptions['width'] = width
self.constructorOptions['height'] = height
self.constructorOptions['renderAt'] = renderAt
self.constructorOptions['dataFormat'] = dataFormat
#dataSource = unicode(dataSource, errors='replace')
self.constructorOptions['dataSource'] = dataSource
def addEvent(self, eventName, funcName):
self.eventOptions[eventName] = funcName
def addMessage(self, messageName, messageValue):
self.constructorOptions[messageName] = messageValue
# render the chart created
# It prints a script and calls the FusionCharts javascript render method
of created chart
def render(self):
# Serialize constructorOptions to a JSON formatted
self.readyJson = json.dumps(self.constructorOptions,
ensure_ascii=False)
# Create Fusioncharts constructor from template and insert JSON data
in it
self.readyJson =
FusionCharts.constructorTemplate.replace('__constructorOptions__',
self.readyJson)
# Iterate and attach EventHandler from template
for key, value in self.eventOptions.items():
self.readyJson = self.readyJson +
FusionCharts.eventTemplate.replace('__chartId__',
self.constructorOptions['id'])
self.readyJson = self.readyJson.replace("_fceventname_",
key).replace("_fceventbody_", value)
# FusionCharts Render method will create chart
self.readyJson = self.readyJson +
FusionCharts.renderTemplate.replace('__chartId__',
self.constructorOptions['id'])
self.readyJson = FusionCharts.baseTemplate.replace("__FC__",
self.readyJson)
self.readyJson = self.readyJson.replace('\\n', '')
self.readyJson = self.readyJson.replace('\\t', '')
if(self.constructorOptions['dataFormat'] == 'json'):
95
self.readyJson = self.readyJson.replace('\\', '')
self.readyJson = self.readyJson.replace('"{', "{")
self.readyJson = self.readyJson.replace('}"', "}")
return self.readyJson
Шаблон HTML-страницы коллекции
<!DOCTYPE html>
{% load staticfiles %}
<html lang="en">
<head>
<meta charset="UTF-8">
<link rel="stylesheet" href="{% static 'css/styles.css' %}">
{% load static %}
<script type="text/javascript" src="{% static 'js/fusioncharts.js'
%}"></script>
<script type="text/javascript" src="{% static
'js/themes/fusioncharts.theme.fusion.js' %}"></script>
<script src="https://d3js.org/d3.v5.min.js"></script>
<title>Apps Analytics</title>
</head>
<body>
<header>
<!-- <img src="{% static 'images/Logo.png' %}" alt="Logo" id="logoimg"> -->
<h1 id="logo-title">Статистика по {{ title }}</h1>
</header>
<div class="overlay">
<nav class="overlayMenu">
<ul role="menu">
<li><a role="menuitem" href="{% url 'all' %}">Все показатели!
</a></li>
<li><a role="menuitem" href="{% url 'top_grossing'
%}">Бестселлеры!</a></li>
<li><a role="menuitem" href="{% url 'top_free' %}">Топ
бесплатных!</a></li>
<li><a role="menuitem" href="{% url 'top_paid' %}">Топ
платных!</a></li>
<li><a role="menuitem" href="{% url 'trending'
%}">Набирающие популярность!</a></li>
</ul>
</nav>
</div>
<div class="navBurger" role="navigation" id="navToggle"></div>
<div class="date-picker">
96
<form action="{% url 'download' %}" class="date-picker"
method="post" target="_blank">
{% csrf_token %}
<a href="#" class="show-data">Отобразить</a>
<input hidden type="text" name="table" value="{{ table }}">
<input min="2019-03-01" max="{{ today }}" type="date"
name="date_start" id="date_start" value="{{ today }}">
<input min="2019-03-01" max="{{ today }}" type="date"
name="date_end" id="date_end" value="{{ today }}">
<button type="submit" class="download">Скачать данные</button>
</form>
</div>
<main>
<div id="category-count-char"></div>
{{ output.0|safe }}
<div class="line"></div>
<div class="iap">
<div id="iap-count-char"></div>
{{ output.1|safe }}
<h2 id="iap-min">Средняя минимальная цена: {{iap_range.0|
floatformat:2}}</h2>
<h2 id="iap-max">Средняя максимальная цена: {{iap_range.1|
floatformat:2}}</h2>
</div>
<div id="cont-rating-count-char"></div>
{{ output.2|safe }}
<div class="line"></div>
<div id="category-and-rating-char"></div>
{{ output.3|safe }}
<div class="line"></div>
<div id="free-count-char"></div>
{{ output.4|safe }}
<div id="iap-and-rating-char"></div>
{{ output.5|safe }}
<div class="line"></div>
<div id="content-and-rating-char"></div>
{{ output.6|safe }}
<div id="content-rating-and-installs-char"></div>
{{ output.7|safe }}
<div class="line"></div>
<div id="category-and-installs-char"></div>
{{ output.8|safe }}
<div class="line"></div>
<div id="installs-and-rating-char"></div>
{{ output.9|safe }}
</main>
<script
src='https://cdnjs.cloudflare.com/ajax/libs/jquery/3.1.1/jquery.min.js'></
script>
<script>
97
$("#navToggle").click(function() {
$(this).toggleClass("active");
$(".overlay").toggleClass("open");
$("body").toggleClass("locked");
});
$('.overlay').click(function() {
$(this).removeClass('open');
$('.navBurger').removeClass('active');
});
</script>
</body>
</html>
98
Приложение В
Пример выгрузки данных
Рисунок В.1 – Пример выгрузки данных, сформированной системой, за 06.2019г. по коллекции
«Бестселлеры»
Отзывы:
Авторизуйтесь, чтобы оставить отзыв