Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ

«НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ

«ВЫСШАЯ ШКОЛА ЭКОНОМИКИ»

Факультет бизнеса и менеджмента

Выпускная квалификационная работа

по направлению подготовки 38.03.05 «Бизнес-информатика»

образовательная программа «Бизнес-информатика»

Разработка платформы краткосрочной аренды повседневной одежды

Умеренков Даниил Игоревич

Рецензент

кандидат экономических наук, доцент кафедры

бизнес-аналитики

А.Л. Бекларян

Москва 2019



ВВЕДЕНИЕ

У современного человека шеринг уже давно перестал ассоциироваться с понятиями «бывший в употреблении» или «секонд-хенда»: шеринг превратился в удобную модель дистрибуции, позволяющую клиенту разбить плату за услугу на много небольших платежей, при чем взымаемых только по факту, а не регулярно [1]. Это открыло многим возможность пользоваться товарами и сервисами, которые они раньше не могли себе позволить: машинами, собственным жильем в поездках, краткосрочными услугами высококвалифицированных специалистов, возможностью на ходу быстро и удобно просматривать абсолютно любой медиа-контент [2]. Шеринг превратился в глобальных тренд.

В странах Европы и Северной Америки данный сегмент рынка уже давно составляет заметную конкуренцию классическому рынку аренды: средний рост количества участников совместной экономики составляет приблизительно 10% в год и к 2020 году превысит треть от общего числа всех онлайн-пользователей [3][4].

В России рынок шеринга переживает взрывной рост: так, в 2016 году он составил 360 млн. рублей, в 2017 году - 384 млн. рублей, а в 2018 - уже превысит 500 млрд. рублей [5][6]. Прирост составляет 20-30%, что обеспечивает регулярные инвестиции в данную отрасль [5].

Главной причиной таких темпов роста является то, что в России осваивание данного сектора началось значительно позже остальных стран [5]. Москва, например, стала одним из последних крупных городов Европы, где запустился сервис шеринга автомобилей, однако, несмотря на это, автопарк стремительной растет: к 2018 году количество автомобилей "Belka Car" почти достигло 1800 против 100 изначальных [5].

Многие крупные отечественные компании такие как Mail.ru Group или Яндекс также вкладывают значительные средства в шеринг экономику страны. Первая, например, в 2016 запустила доску-объявлений "Юла", которая к 2018 году уже имела больше 27 млн активных объявлений [7], "Яндекс" же запустил сервис каршеринга "Яндекс.Драйв", который в короткие сроки стал одним из самых популярных в Москве [8].

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

С повсеместным вводом автоматизации и IT-решений рынок совместного использования также не прошел стороной и рынок одежды. На отечественном рынке уже есть одно подобное решение - "Rubaski club" [9]. Данный сервис предоставляет возможность взять в аренду небольшое количество рубашек на срок от одной до четырех недель, при этом вся ответственность по уходу с клиента снимается. В своих многочисленных интервью основатели сервиса [10][11][12] много говорили о проблемах и успехах сервиса. Например, остро стоит вопрос логистики рубашек от клиента до химчисток и обратно. Также многих клиентов отталкивает вопрос гигиены: рубашки носятся на голое тело и подобный шеринг может вызвать отторжение у потенциальных клиентов. Несмотря на это, сервис стабильно привлекает новых покупателей и собирается выйти на полную самоокупаемость уже к 6-му месяцу работы [12].

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

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

1. Анализ аудитории и предпочтений на основе качественного и количественного анализов: проверка гипотез путем customer development (custdev) и анализ предпочтений через массовый закрытый опрос.

2. Создание функциональных требований к системе, включая BPMN-схему.

3. Непосредственная разработка MVP-версии продукта с созданием реляционной базы данных, frontend и backend приложений.

4. Описание потенциального развития продукта и схемы вывода на рынок.



ГЛАВА 1. АНАЛИЗ ПРЕДПОЧТЕНИЙ АУДИТОРИИ

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

Программный продукт будет разрабатываться по методологии Minimum Viable Product (MVP). MVP (или минимально жизнеспособный продукт) - подход, при котором в продукте в начале реализуется наименьший набор функций, удовлетворяющий первых клиентов, чтобы как можно скорее получить от них отзывы о работе и сервисе в целом. Эти отзывы потом используются для корректировки функционала с предпочтениями клиентов, чтобы сгенерировать уже новые отзывы. Этот цикл (рисунок №1) повторяется несколько раз, пока итоговый продукт не начнет удовлетворять требованиям покупателей. Данный подход позволяет очень быстро создать продукт, при этом затратив гораздо меньше сил и ресурсов нежели при классической разработке [14].

Рисунок 1 - Цикл MVP

реляционный база данные frontend



1.1 Customer Development

Системы шеринга одежды не слишком широко распространены на массовом рынке, и их аудиторию и ее предпочтения еще только предстоит выяснить. Хорошим инструментом для этого станет custdev - методология, основывающаяся на принципе, что для перед созданием продукта обязательно нужно выявить предпочтения клиента, а уже потом подготавливать под них решение [16].

Делается это путем выдвижения гипотез - предположений о клиентах, аудитории или требуемом функционале. Затем находятся потенциальные клиенты - обычно не более 12 человек, с каждым из которых проводится интервью с открытыми вопросами, в ходе которого выдвинутые ранее гипотезы проверяются. Основываясь на результатах интервью можно довольно подробно изучить потенциальных потребителей и их желания (рисунок №2) [16].

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

· Обсуждать того, с кем вы разговаривайте, а не вашу идею.

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

· Меньше говорить, больше слушать.

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

1. Люди, в возрасте до 30, которые относятся к поколению «Y» или «Z» и уделяют большое значение своему внешнему виду.

2. Офисные сотрудники, которые придерживаются делового дресс-кода.

3. Те, кому нужна вечерняя одежда или костюмы (сотрудники фотостудий или театров).

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

Общие:

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

2. Гипотеза с геймификации (использование игровых подходов для неигровых процессов с целью повышения вовлеченности клиентов): по данным некоторых исследований ввод элементов игры и систем поощрений в бизнес-процессы серьезно увеличивает заинтересованность клиента в продукте и позволяет с большой вероятностью обеспечить повторение целевого действия [17][18].

Группа I:

1. Данную группу больше привлекает аренда одного комплекта одежды на короткий срок (1-2 дня).

2. Возможность самостоятельного подбора комплекта одежды.

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

4. Важным аспектом является внешний вид системы, так как приложение, не отвечающее современным стандартам, будет отпугивать данную аудиторию [19].

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

Группа II:

1. Возможность выбора уже готовых комплектов.

2. Данную группу больше привлекает аренда нескольких похожих вариантов одежды на срок до недели.

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

Группа III:

1. Широкий диапазон сроков аренды.

2. Наличие широкого ассортимента.

3. Возможность сдать свою одежду с целью получение дивидендов от ее ношения другими пользователями (или единоразовой выплаты).

4. Система отзывов, через которую можно было бы оценить состояние вещи.

В интервью принимало участие 12 человек (четыре человека в первой, пять во второй и три в третьей группах).

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

Также были проверены вышеописанные гипотезы:

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

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

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

4. Важным аспектом является внешний вид системы, так как простой серый сайт будет отпугивать данную аудиторию. Целевая аудитория этой группы (поколения «Y» и «Z») выросла в цифровом мире. Они не отделяют свою жизнь от мобильных устройств и интернета и искушены современным UX/UI дизайнами систем, поэтому для них будет особо важно, чтобы платформа внешне отвечала всем требованиям к приложению и была отзывчива в работе.

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

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

Гипотезы группы II:

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

2. Данную группу больше привлекает аренда нескольких похожих вариантов одежды на срок до недели. Данная гипотеза также была подтверждена.

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

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

Гипотезы группы III:

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

2. Наличие широкого ассортимента. Для специалистов, которым одежды нужна как рабочий реквизит, крайне важно наличие широкого ассортимента.

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

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

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

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

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

· Возможность точно выбрать срок аренды

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

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

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

· Возможность сдать свою одежду для регулярной химчистки

· Интеграция с популярными социальными сетями

· Геймификация

· Возможность сдать одежду в сервис с целью получения дивидендов

· Наличии вещей одежды нескольких сегментов: деловая, реквизит, вечерняя, «в тренде».

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

1.2 Опрос

Customer development проводится в форме неформального диалога с узким набором представителей целевых аудиторий с задачей более точно выявить функционал, в котором могут нуждаться эти аудитории. Было бы ошибкой слепо экстраполировать результаты custdev'а на всех представителей этих групп и сразу же приступить в разработке функциональных требований: гипотезы нужно проверить на более широкой публике [16].

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

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

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

Следующий вопрос выявлял были ли те, кто уже брали одежду в аренду (рисунок №3).



Рисунок 3

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

1. Результаты первых двух групп во всех уровнях доходов очень похожи. Это можно объяснить тем, что данные группы скорее всего использовали аренду только для особых случаев (праздники, мероприятия).

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

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

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

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

Рисунок 4

Из ответов респондентов видно, что общая заинтересованность составляет 22% на пике, что довольно низко, так как в вопросе нигде не уточнялась цена услуги, которая, учитывая сегмент, скорее всего была бы высока: наиболее платежеспособные клиенты практически не заинтересованы в услуге. Объясняется это тем, люди с высоким доходом вполне могут сами себе позволить одежду данного ценового сегмента, так что им не за чем брать ее в аренду.

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

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



Рисунок 4

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

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



Рисунок 5

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

Четвертый вопрос был призван проверить гипотезы о сроках аренды среди групп (рисунок №7).

Рисунок 6



Гипотезы групп подтвердились:

· Первая группа больше заинтересована в аренде на срок от одного до двух дней.

· Вторая группа предпочла бы аренду в срок от трех до 7 дней.

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

Следующий вопрос проверял гипотезы о заинтересованности пользователей в возможности самостоятельно выбирать комплекты одежды (рисунок №8).

Рисунок 7

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

Также были проверены остальные гипотезы (рисунки №9, №10, №11, №12 и №13):

1. Важность дизайна и удобства сайта для потребителей. Гипотеза подтверждена для всех групп.

2. Важность возможности делиться комплектами одежды в социальных сетях. Данная гипотеза верна для первой группы (как и предполагалось) и также оказалось важна третьей группе.

3. Возможность сдать свою одежду в химчистку. Данная гипотеза, вопреки custdev'у, была опровергнута для всех групп.

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

5. Важность системы отзывов. Гипотеза также подтверждена.

Рисунок 8

Рисунок 9



Рисунок 10

Рисунок 11

Рисунок 12



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

· Возможность детально указать срок аренды

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

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

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

· Упрощенная интеграция с популярными социальными сетями

· Геймификация

· Возможность комментировать и оценивать вещи

· Возможность отдать свою одежду сервису с целью получения дивидендов



ГЛАВА 2. РАЗРАБОТКА ФУНКЦИОНАЛЬНЫХ ТРЕБОВАНИЙ

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

2.1 Функциональные требования

Функциональные требования к гипотезам из первой главы:

· Возможность детально указать срок аренды. В данном случае пользователь должен мочь используя виджет календаря точно задать дату начала и конца аренды. Календарь должен также показывать те дни, в которые аренда невозможна.

· Возможность выбрать одежду из готовых комплектов, а также создать его самому. Архитектура системы должна быть простроена так, чтобы любой представленный комплект (будь то несколько вещей или одна) всегда представлял собой массив. В этом случае можно будет удобно выкладывать на «витрину» как сет из нескольких вещей (массив из двух или более элементов), так и вещи по одиночке (массив из одного). Все заказы будут разными пересечениями этих массивов.

· Возможность носить одежду первому при выборе деловой одежды. Функционал, при котором пользователь изъявляет желание носить одежду первым. В данном случае увеличивается срок доставки, администратором заказывается новый комплект у поставщика.

· Упрощенная интеграция с популярными социальными сетями. В сервисе должна быть предусмотрена авторизация через социальные сети, а также кнопка «поделиться».

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

· Возможность комментировать и оценивать вещи. Система оценок.

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

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

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

При интеграции с данными сервисами могут быть использованы два концептуально разных подхода: использование задач по расписанию или технологии webhooks:

· Webhooks. Данная методология заключается в том, что в начале удаленному провайдеру отправляется запрос (например, создание заявки в курьерской службе), при этом к телу запроса также прикладывается URL кого-то метода платформы, совершающей запрос. При возникновении кого-то события у стороннего сервиса (заказ доставлен, отменен или другое) провайдер вызывает этот URL, тем самым уведомляя об изменении. При уведомлении также передается информация, позволяющая применить ту или иную логику реакции[20].

· Задачи по расписанию. Совсем немногие сервисы предоставляют возможность использования технологии webhooks, чаще всего у них есть API, с помощью которой можно проверить то или иное изменение. Проблема в том, что инициирует этот запрос не провайдер, а сервис, подключающийся к нему, который не может точно знать о точном времени изменения и, соответственно, о времени, когда нужно производить запрос. В данном случае используются технологии по типу cron или hosted service [21], которые совершают действие (отправляют запрос или совершают иную операцию), а затем засыпают на заданный промежуток времени. В итоге получается задача, которая совершается с интервалом. Так как операция запроса к провайдеру является простой и потребляет крайне мало ресурсов сервера, можно, например, создать такую, которая бы раз в минуту проверяла изменение статуса у удаленного партнера и в случае положительного ответа применяла бы заданную логику [22].

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

Подписание документов может быть произведено только на клиентской стороне, так как закрытая часть ключа может быть извлечена с целью подписания только операционной системой компьютера, в который непосредственно вставлен сам токен (обычно выглядит в виде USB-флеш-накопителя). Подписание [23] должно производиться в соответствии с ГОСТ Р 34.10-2012 [24] и ГОСТ Р 34.10-2001 [25].

С учетом тех требований, которые уже сложись к проекту самым логичным было бы разработать платформу как web-приложения: frontend отдельно от backend, коммуникация между которыми бы велась через API. Это накладывает дополнительные требования к продукту.

Функциональность авторизации и регистрации:

· Регистрация. Каждый желающий может пройти регистрацию, заполнив поле с адресом email, паролем и пройдя проверку каптчей.

· Каптча. В качестве проверки пользователя при регистрации будет выступать reCaptcha от Google, которая позволит просто и эффективно отделить реальные пользователей от ботов [26]. Также третья версий reCaptcha может быть встроена в невидимом виде на все остальные страницы с целью анализа трафика.

· Проверка email. Email, указанный при регистрации, должен быть в обязательном порядке проверен, так как один из ключевых спам-фильтров во всех крупных сервисах электронной почты - email ящики, на которые шлется рассылка, должен существовать. Существует множество решений, позволяющих проверить реальность почтового адреса, однако они стоят денег и обладают низкой надежностью: они проверяют адрес по MX-записям почты и часто ошибаются, если хостинг существует, однако не настроен для проверки (такое, например, часто случается с почтой, зарегистрированной в Outlook или с корпоративными адресами) [27].

· Разбиение на роли. Пользователи должны быть разбиты по ролям: администратор, обычный пользователь и так далее. Один пользователь может находиться в нескольких ролях одновременно, что поможет в случае масштабировании системы.

· Авторизация. Пользователь должен быть авторизован пароль access-refresh токенов. В данной методологии access-токен, предоставляющий непосредственный доступ к данным, выдается на короткий срок (порядка 15-ти минут). Чтобы пользователю не приходилось каждый раз вводить пароль, ему также выдается длительный refresh-токен, с помощью которого можно перезапросить access-токен (рисунок №14). Данная схема позволяет укоротить время, на которой злоумышленник получит доступ к аккаунту пользователя, если перехватит токены [28].

Рисунок 14 - Схема работы aceess-refresh токенов

Навигация по ресурсу должна быть обеспечена перекрестной навигационной панелью (рисунок №15).

Рисунок 15 - Пример навигационной панели

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

В случае с web-приложением крайне важной является отзывчивость продукта к действиям пользователя - каждый клик должен вызывать незамедлительную реакцию [19]. Также важно чтобы любое изменение заказа или статуса отправлялось пользователю в режиме реального времени так как данная функциональность уже давно стала стандартом. Как и в интеграциях со сторонними сервисами проблема в том, что frontend не знает об изменениях на платформе, вызванных другими пользователями (заказ одобрен администратором). Так как frontend по определению не является сервером, то webhook'и ему не подходят. Можно было бы использовать методологию задач по расписанию, однако есть гораздо более удобный вариант: websocket'ы [29]. Данная технология представляет собой протокол, работающий отдельно от стандартного HTTP, и устанавливающий неразрывную связь между клиентом и сервером, при которой каждый из участников в любой момент в режиме реального времени может инициализировать отправку данных.

Архитектура backend и frontend частей должна представлять собой приложение, реализованное с использованием подхода IoT (inversion of control) [30]. Данное решение предполагает, что, в отличии от классического варианта, в котором программист полностью контролирует поток выполнения программы, за ходом выполнения следит фреймворк. Одной из спецификаций этого подхода является паттерн DI (dependency injection), при котором за внедрение зависимостей в программный объект отвечает отдельный специализированный механизм. Такой подход позволяет радикально упростить разработку программного продукта, так как, во-первых, фреймворк берет на себе всю работу за обеспечение базового функционала («слушает» порт, считывает URL, подставляет параметры и так далее), а, во-вторых, позволяет крайне просто повысить коэффициент повторного использования кода. Популярна микросервисная структура backend части приложения, при которой каждая небольшая часть кода, решающая свою часть общего бизнес-процесса, выносится в сервис, который потом с легкостью встраиваются друг в друга [31]. Таким образом, один раз написав метод, который, например, проверяет если ли новые пользователи в базе, с легкостью можно его встроить во все участки программы сколько бы их ни было и использовать его там. Единственная проблема в этом случае - зацикливание зависимостей, при которой класс А ссылается на Б, а Б - на А (явно или неявно). В этом случае создание А невозможно без Б, а Б без А - то есть ни один не может быть создан. Подобная проблема может быть решена только тщательным планированием архитектуры приложение заранее с целью избегания этого логического тупика [31].



2.2 BPMN

Рисунок 16 - BPMN-схема процесса

На данной схеме изображен основной бизнес-процесс платформы:

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

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

3. В случае отмены оплаты процесс прерывается.

4. В случае успешной оплаты удаленный сервис уведомляет об этом систему и отправляет закрывающие документы.

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

6. Заказ сформировывается и отправляется администратором в курьерскую службу. Пользователь получает об этом уведомления.

7. Курьерская служба доставляет клиенту его заказ, он им пользуется и потом передает обратно курьеру.

8. Курьер возвращает вещи на склад.

9. Раз в неделю (или при наступлении определенного объема) вся грязная одежда передается администратором в химчистку.

10. После окончания процедуры чистки одежда возвращается на склад и цикл завершается.

Эта схема представляет собой ранний бизнес-процесс до начала тестирования MVP версий продукта.

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

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



ГЛАВА 3. РАЗРАБОТКА ПРИЛОЖЕНИЯ

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

Стек технологий, выбранный для написания продукта:

· ASP.NET Core 2.2. Это открытый веб-фреймворк, разрабатываемый компанией Microsoft и сообществом разработчиков. Фреймворк состоит из четырех модулей: Entity Framework Core (ORM), Identity Core (аутентификация), MVC Core (вводит паттерн MVC) и Razor Core (механизм генерации HTML, XML и других шаблонов) [32]. ASP Core написан на языке C#, что позволяет использовать его встроенные возможны по распараллеливание потоков, работы с файлами и объектами, а также использовать всевозможные открытые NuGet пакеты [33]. Razor позволяет применять фреймворк как для серверной, так и для клиентской частей, однако в данном продукте Razor будет использован только как один из этапов генерации документов.

· Angular 7.2. Открытый frontend фреймворк, разрабатываемый компанией Google [34]. Основные отличия данного фреймворка от конкурентов (React, Vue, Ember) состоят в том, что в нем «из коробки» доступны все модули, полноценно поддерживается IoC и DI контейнеры, а также используется RxJS (типизированное реактивное программирование) [35]. Сам фреймворк построен на библиотеке zone.js. Это библиотека вводит понятие «зоны» - контекста выполнения, в которых можно удобно отслеживать выполнение асинхронных функций. Zone.js отслеживает изменения во всех областях и уведомляет (через RxJS) Angular и пользователя.

· Microsoft SQL Server 2016 (MS SQL). Система управления реляционными базами данных, разрабатываемая компанией Microsoft [36] [37].

· Entity Framework Core (EF Core). ORM (object-relational mapping), которая позволяет преобразовывать объекты языка C# в SQL-запросы [38].

Традиционно разработка делится на 3 основные части: база данных, серверная часть и клиентская.

3.1 База данных

При проектировке базы данных принялся подход code-first, при котором сущности в БД формируются из связанных с ними объектов классов [39]. Этот вариант отлично подходит для изначального построения базы, при котором еще до конца не ясны сущности, участвующие в процессе (а точнее их параметры) и многое меняется по ходу разработки. Данная методология позволяет быстро менять структуру базы и подгонять ее под нужды серверной части. Однако не надо забывать что code-first - всего лишь подход к проектированию и он никак не снижает важность БД и ни в коем случае не отводит ее на второй план: практически в каждой системе база данных является краеугольным камнем всего продукта и именно на ней завязана вся основная работа. Code-first позволяет снизить общее время, затрачиваемое на разработку. Если же система в будущем разрастется и возникнут проблемы оптимизации, то выбранная ORM (Entity Framework Core) будет не лучший выбором из-за относительно низкой скорости работы. В этом случае имеющийся стек можно будет дополнить ORM фреймворком Dapper, который позволит заметно увеличить скорость в read-only запросах (SELECT) [40].

Так как backend использует ASP.Core, то было принято решение чтобы сервис авторизации был основан на уже готовом решении: Identity Core. Оно само генерирует необходимые ему таблицы в базе (рисунок №17).



Рисунок 17 - Таблицы Identity Core

Как можно видеть из диаграммы, это решение использует claims-based аутентификацию. Данный тип аутентификации заключается в том, что у каждого пользователя есть ряд данных в формате ключ-значение (claim), которые описывают данного пользователя (его роль), хранящиеся в токене. Identity Core самостоятельно выдает внутренние токены и сверяет данные в claims с требованиями [41]. Таким образом можно, например, легко разграничить функциональность по ролям: доступ в некому методу разрешен только пользователям с ролью «admin». При попытке доступа авторизованного пользователя к этому ресурса фреймворк проверяет есть ли в его claims запись о том, к какой роли принадлежит клиент. В случае если запись присутствует и ее значение равняется искомому, что человек получит доступ к ресурсу, если нет - ошибку авторизации.

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

С целью удобства представления дальнейшие диаграммы строились в dbdiagram.io, позволяющей быстро и легко построить схему базы данных, а затем выгрузить ее. Unique тип данных - uniqueidentifier из MS SQL, который описывает guid (128-битный уникальный идентификатор).

Следующая часть базы описывает пользователя как бизнес объект. Таблица пользователей на диаграмме была сокращена для улучшения визуального восприятия. В реальности она содержит поля и Identity Core, и своей бизнес сущности (рисунок №18).

Рисунок 18 - Таблицы пользователя

· AspNetUsers. Пользователи системы. Хранит в себе личную информацию о каждом пользователе, его статус, а также настройки отправки уведомление (разрешено или нет).

· AspNetUsersStateHistory. История изменения статусов пользователя.

· UserTokens. Таблица, которая хранит в себе refresh токены. Данный функционал связан с особенностями авторизации через access-refresh токены и будет подробнее описать позже.

· DeliveryAddreses. Адреса доставок, указанные пользователем. Каждый пользователь может иметь несколько адресов и при очередном заказе указать ранее использовавшийся.

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

· UserInvites. Приглашения пользователей другими пользователями.

Данная часть БД хранит таблицы, хранящие информацию об одежде (рисунок №19).

Рисунок 19 - Таблицы об одежде

· Texts. Прикладная таблица, хранящая в себе крупные тексты.

· Clothes. Одна позиция одежды. Содержит в себе название, описание, статус. Данная таблица не хранит в себе записи о конкретных вещах.

· ClothesStateHistory. История изменения статусов позиций одежды.

· Sets. Сеты одежды. Один сет - одна позиция на «витрине» магазина, которая состоит из позиций в таблице Clothes. Доступность сета рассчитывается по доступности конкретных вещей в нем.

· ClothesSets. Таблица для осуществления связи много ко многим.

· ClothesPieces. Одна конкретная единица одежда. Привязана к позициям Clothes и обладает уникальными параметрами: размер, пол, статус, дата первого использования и первый, кто ее носил.

· ClothesPieacesAvailabilityWindows. Временные вилки, в которые единица одежды доступны. Если AvailableToDate равно null, то срок окончания бессрочный.

· ClothesPiecesStateHistory. История изменения статусов одежды.

Следующая часть базы данных описывает заказы и сопряженные таблицы (рисунок №20).

Рисунок 20 - Таблицы заказов

· 

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

· OrdersPromos. Таблица для осуществления связи много ко многим. Использованные в заказах промо-коды.

· OrderClothesPieces. Таблица для осуществления связи много ко многим. Вещи, которые попали в заказ.

· OrdersStateHistory. История изменения статусов заказов.

Далее описывается часть базы, отвечающая за уведомления для пользователей (рисунок 21).

Рисунок 21 - Таблицы уведомлений

· Notifications. Единая таблица для уведомлений всех типов. Уведомления определенного типа «наследуются» от нее.

· OrderNotifications. Уведомления об изменении статусов заявок.

Далее - геймификация (рисунок 22).



Рисунок 22 - Таблицы геймификации

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

· GamificationAchievementsUsersHistory. Список заработанных пользователями достижений.

· GamificationLevels. «Уровни», которые пользователи получают с помощью баллов. Баллы даются за выполнение целевых действий. Повышение уровня вознаграждается промо-кодом на ту или иную сумму.

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

· GamificationLevelsUsersHistory. История повышения пользователями уровней.

Комментирование (рисунок №23).



Рисунок 23 - Таблицы для комментирования

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

2. CommentsLikes. Лайки под комментариями, оставленные пользователями.



Рисунок 24 - Общая сехма базы

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

3.2 Backend

Серверная часть, как и говорилось ранее, написана с использованием фреймворка ASP.NET Core.

Разработка началась с того, кто было подготовлено начальное решение. Решение разрабатывалось в IDE Visual Studio 2019, позволяющее создавать новые проекты из шаблонов. В качестве исходного шаблона был выбрал шаблон Web-API, в котором предусмотрен модуль MVC Core, однако нет EF Core, представлений Razor и Identity Core.

Рисунок 25 - Изначальная структура проектов

Изначальная структура состоит из трех проектов в одном решении (рисунок №25). Решение - один логически-завершенный продукт, Проект - составная часть решения. Текущие проекты:

· Api. Содержит в себе конечные точки API (методы), Dto модели (объекты, которые отправляются на frontend). Проект также является точкой входа и содержит настройки использования сервиса и DI контейнера. Проект также отвечает за валидацию и за преобразование Dto моделей в бизнес объекты и обратно.

· Core. Содержит основную бизнес-логику работы с объектами и базой. Импортируется в Api.

· Domain. Хранит в себе модели бизнес объектов. Может быть импортирован во все проекты и не имеет зависимостей.

Разграничение зависимостей на данном этапе является очень важной задачей: два проекта не могут ссылаться друг на другу одновременно, поэтому нужно выстроить архитектуру так, чтобы при росте системы эти проблемы не возникли. В решение, изображенным на рисунке 25, видно, что Domain содержит все общие модели, которые могут понадобиться во всех частях проекта; Core - работу с бизнес объектами, которая также может быть в теории вызвана из нескольких частей проекта; Api - ссылается на Core и содержит уникальные Dto модели, которые больше нигде использоваться не будут.

Именно Api является Web-API, в то время как остальные проекты - библиотеки классов, то есть просто наборы объектов.

Следующим этапом была проведена конфигурация проекта. В ASP.Core за это отвечает класс Startup с двумя методами: ConfigureServices и Configure.

Метод ConfigureServices отвечает за регистрацию сервисов для DI контейнера. Каждый класс, добавленный в DI контейнер, называется сервисом и будет доступен во всех частях проекта, если указать зависимость от этого класса в конструкторе. ASP.Core поддерживает три уровня жизни сервиса:

· Transient. При каждом обращении к сервису экземпляр класса будет создан заново. То есть в каждую ссылку будет предоставлен свой уникальный объект.

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

· Singleton. В рамках жизни приложения для всех ссылок во все запросы будет предоставлен один и тот же экземпляр класса. Объект изменится только если перезапустить приложение. Разница такого класса с обычным статическим в том, что в Singleton также можно вставлять ссылки на сервисы из DI контейнера.

При добавлении класса в DI контейнер можно или указать сам класс, или же интерфейс, который он реализует (рисунки №26 и №27). В таком случае в качестве ссылки нужно указывать именно этот интерфейс. Нужно это для реализации принципов SOLID.



Рисунок 26 - Добавления сервиса в DI контейнер

Рисунок 27 - Получение сервиса из DI контейнера

В методе ConfigureServices также происходит добавлений конфига в DI контейнер. Сами конфиг называется appsetting.json и автоматически создается в папке с запускаемым проектом (рисунок № 29). Можно разграничивать конфиги в зависимости от среды. Например, если создать файл appsettings.development.json, то он применится только в случае dev сборки, при этом в файле не обязательно должны дублироваться те настройки, которые не зависят от версии: фреймворк будет смотреть только пересечения development и оригинального файла. Таким образом легко разделять базы данных, включать и выключать функционал в зависимости от версии или хранить разные ключи или соли для разных сред (рисунок №30).