Аналитическая программа «SteamCardsFarmer»

1. Аналитическая программа «SteamCardsFarmer»

2. Разработчик

Компания «Pomoika Inc.»
Команда разработчиков:
1. Дмитрий Гайфулин (PM, разработчик).
2. Михаил Слинкин (разработчик GUI).
3. Арсений Поляк (аналитик).
4. Василий Каженцев (тестировщик, тех. писатель).

3. Цель

Создать программный продукт, способный находить и выдавать сущности –
«Игры» (вместе с их основными параметрами) – с наличием атрибута
«Коллекционные карты» в БД (Магазине) игровой платформы Steam, что
позволит определить предполагаемый шанс окупаемости игры на основе ее
стоимости и стоимости Коллекционных карточек, связанных с ней.

4. Задачи

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

5. Архитектура решения

Решение состоит из следующих частей:
1. Model
• SteamShopAPI
• SteamMarketAPI
• DataBase
2. View
3. ViewModel

6. Этапы разработки ПО

1.
2.
3.
4.
5.
6.
Определение требований.
Проектирование.
Разработка.
Тестирование.
Документирование.
Сдача в эксплуатацию.

7. Автоматизация процесса разработки

• Для упрощения, ускорения и повышения удобства процесса
разработки
было
решено
прибегнуть
к
помощи
автоматизированной системы сборки и тестирования проекта –
агенту CI (Continuous Integration)

8. Необходимость автоматизации процесса сборки и тестирования

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

9. Необходимость автоматизации процесса сборки и тестирования (продолжение)

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

10. Критерии выбора системы автоматизации процесса разработки

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

11. Выбор системы автоматизации процесса разработки

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

12. Пример использования системы автоматизации процесса разработки

• На рисунке приведён пример
конфигурации автоматической
сборки проекта. Как видно,
конфигурация
не
имеет
большого объёма – система
берёт на себя большую часть
работы,
что
настройку задания
облегчает

13. Результаты автоматизации процесса разработки

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

14. Результаты. API для Steam

Были разработаны классы SteamShopAPI и SteamMarketAPI,
которые включают в себя:
• Отправку HTTP запросов и получение HTML-страниц
• Парсинг HTML-страниц
• Алгоритм прогнозирования окупаемости
• Интерфейс взаимодействия с БД.

15. Результаты. База данных

При помощи EntityFramework была
разработана БД с использованием
подхода CodeFirst. БД содержит в
себе всего одну таблицу, записи
которой – игры, со всеми
необходимыми
для
работы
приложения атрибутами.

16. Результаты. Графический интерфейс.

Был разработан дизайн графического
интерфейса и логика, связывающая его с
разработанными API. Работа GUI
основана на привязке значений его
компонентов к ViewModel.

17. Результаты. Документация.

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

18. Техническое задание. Введение.

Наименование: «SteamCardsFarmer».
Область применения программы: платформа для продажи игр и
объектов, с ними связанными, под названием «Steam».
Объект, в котором используют программу: любой ПК с
установленной на нем ОС семейства Windows.

19. Техническое задание. Основания для разработки. Назначение разработки.

Документ, на основании которого ведется разработка:
Техническое задание.
Организация, утвердившая этот документ: кафедра БК №536,
Институт Кибернетики.
Дата утверждения: 08.02.2019.
Наименование темы разработки: аналитическая программа для
анализа
вероятности
получения
прибыли
от
игры,
расположенной на платформе «Steam».
Назначение разработки: автоматизация процесса поиска игр с
наличием атрибута «Коллекционные карты» в БД игровой
платформы Steam.

20. Техническое задание. Требования к программе или программному изделию.

Требования к системе в целом.
Система должна находить и выдавать упомянутые ранее
сущности (Игры) с их основными параметрами и наличием
атрибута «Коллекционные карты» в БД игровой платформы
Steam. Эти сущности должны храниться в локальной БД, которая
используется для подсчета вероятности получения прибыли из
игры, или хотя бы ее окупаемости, после продажи
Коллекционных карт.

21. Техническое задание. Требования к программе или программному изделию.

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

22. Техническое задание. Требования к программе или программному изделию.

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

23. Техническое задание. Требования к программе или программному изделию.

Требования к видам обеспечения.
Математическое обеспечение. Постановка задачи: у каждой
игры есть н карт (от 5 до 15) из которых случайным образом с
возможными повторениями выпадает ровно половина с
округлением в большую сторону. У каждой карты есть
стоимость. Разработать алгоритм (не перебор "в лоб"), который
будет подсчитывать (возможно, приблизительно) шанс того, что
общая стоимость выпавших карт минус некоторый процент
(константа) превысит стоимость игры, которой принадлежат эти
карточки.

24. Техническое задание. Требования к программе или программному изделию.

Требования к видам обеспечения.
Информационное обеспечение. Должна присутствовать область
временного хранения данных; информационный обмен
существует между API программы и моделью MVVM; сбор
данных в системе осуществляется с помощью специальной
программы для обработки HTML-страниц; при разработке
программного продукта должен использоваться язык C#, для
создания графического интерфейса – язык разметки XAML;
программный продукт должен работать на базе ОС Windows 10;
разработка должна вестись в IDE Microsoft Visual Studio 2017.

25. Техническое задание. Требования к программе или программному изделию.

Требования к надежности.
Достаточно предусмотреть вывод ошибок на экран, прежде чем
программа аварийно завершит свою работу. Обработку
возможных ошибок вести в основном в «узких местах»
программы.
Требования к составу и параметрам технических средств.
Основные требования – наличие ОС семейства Windows
(желательно, старше версии Windows 7), а также стабильного
подключения к сети Интернет.

26. Техническое задание. Требования к программной документации.

Первым документом, на основе которого ведется разработка,
является Техническое задание.
Документирование же программы должно производиться как в
исходном коде, так и в специальных файлах. Для
документирования следует использовать XML-комментарии,
поддерживаемые
IDE
Microsoft
Visual
Studio
2017.
Документирование тестовых прогонов программы не требуется.

27. Техническое задание. Стадии и этапы разработки. Порядок контроля и приемки.

Разработка выполняется в три этапа:
• Проектирование системы (1 месяц)
• Разработка системы (3 месяца).
• Тестирование и ввод в эксплуатацию (1 месяц).
Контроль и приемка программного продукта выполняются в два
этапа:
• Тестирование программы тестировщиком.
• Приемка программы руководителем компании.

28. Технологии, которые были применены

1.
2.
3.
4.
5.
Язык программирования C# (в том числе WPF)
Фреймворк HtmlAgilityPack
EntityFramework
Шаблон проектирования MVVM
XML-документация

29. Итоги работы

1. Был создан API магазина Steam, содержащий в себе парсер html-страниц,
а также взаимодействующий с базой данных и GUI.
2. Была создана база данных с помощью модели проектирования CodeFirst
из EntityFramework, хранящая в себе всю собранную информацию об
играх.
3. Был создан GUI, позволяющий сделать работу с программой более
удобной.
4. Была создана документация к коду.

30. Спасибо за внимание!

https://github.com/Mr-Dm1try/SteamCardsFarmer