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

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

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

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

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

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

Выпускная квалификационная работа - БАКАЛАВАРСКАЯ РАБОТА

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

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

Коробин Сергей Юрьевич

Москва, 2019

Оглавление

Введение

Глава №1 - Обзор литературы

1.1 Блок технических инструментов

1.2 Блок архитектурного решения

1.3 Блок исследования социальной среды

Глава №2 - Анализ рынка решений

2.1 Описание и анализ найденных решений

2.2 Составление критериев сравнения

Глава №3 - Проектирование и разработка интерактивного сервиса

3.1 Первичная концепция продукта

3.2 Обновленная концепция продукта

3.3 Этап формулирования требований

3.4 Этап проектирования модулей

3.5 Этап разработки сервиса

3.6 Оценка дальнейшего развития сервиса

Заключение

Список литературы



Введение

сервис интерактивный инвалид

Актуальность

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

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

Цель исследования

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

Задачи исследования

Для достижения выше поставленной цели проведена её декомпозиция на следующие задачи:

1. Провести анализ решений, существующих на рынке

2. Разработать объективные критерии для сопоставления и сравнения продуктов

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

4. Установить требования для модулей сервиса

5. Провести проектирование архитектуры и всех составляющих частей сервиса

6. Разработать архитектуру сервиса

7. Разработать индивидуально каждый модуль, входящий в сервис

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

9. Предложить план выпуска программного продукта

Предмет и объект исследования

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

Практическая значимость

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

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

Определение ключевых терминов

Работа специализируется на узкой теме разработки продукта на рынке социальных услуг. При этом использовалась специфичная для сферы исследования терминология. В их состав входят определения из информационных технологий, отдельно, в частности, формулируется упомянутый в названии исследования термин «социальная среда». Далее представлен список определений:

Модуль - это программный компонент или часть программы, которая содержит одну или несколько процедур. Один или несколько независимо разработанных модулей составляют программу. Программное приложение корпоративного уровня может содержать несколько различных модулей, и каждый модуль выполняет уникальные и отдельные бизнес-операции. (Techopedia.com, 2016) [1]

Пользовательский интерфейс (UI - англ. user interface) - аспекты компьютерной системы или программы, которые может видеть (или слышать или воспринимать иным образом) пользователь, а также команды и механизмы, которые пользователь использует для управления своей работой и ввода данных. (Dictionary of Computer Science, Engineering and Technology, 2000) [2]

API (англ. Application Programming Interface) - это набор определений, протоколов и инструментов для разработки ПО и приложений. API-интерфейс разрабатывается для упрощения создания программ, путем предоставления всех необходимых функциональных блоков. API может быть разработано для веб систем, операционных систем и баз данных, предоставляя среду для разработки приложений используя конкретный язык программирования. Например, программист, который разрабатывает приложения для Android может использовать Android API для взаимодействия с аппаратной частью. [3]

REST API - это API, который следует за принципами REST и в большинстве случаев использует протокол HTTP и те же HTTP-глаголы (GET, PUT, POST и DELETE), которые веб-браузеры используют для извлечения веб-страниц и объектов. Термин REST появился и приобрел популярность после того, как Рой Филдинг в 2000 году представил его в своей докторской диссертации «Архитектурные стили и проектирование сетевых программных архитектур» в Калифорнийском университете. Он применил REST для описания желаемого стиля веб-архитектуры, который мог бы помочь с решением проблем путём сравнения альтернативных решений, при этом гарантируя, что расширения протокола не будут нарушать основным ограничениям, которые делают сеть успешной. [4]

Паттерн разработки (англ. design pattern) - многоразовые решения для разработки программного обеспечения. Они служат шаблонами, которые программисты могут использовать при создании приложений. Они не специфичны для отдельных языков программирования, а представляют собой лучшие практики или эвристику, которые могут применяться в различных средах программирования. (Christensson, P., 2016) [5]

Синтаксис - это специфичный для каждого языка общий набор правил: каким образом должны быть структурированы слова и предложения. В компьютерном программировании синтаксис служит той же цели, определяя, как должны быть организованы объявления, функции, команды и другие операторы. (Christensson, P., 2011) [6]

Сервис - (англ. information technology service) - это услуга, предназначенные для облегчения использования технологий предприятиями и конечными пользователями. Сервис (иначе технологическая услуга в сфере IT) предоставляет специализированные технологические решения, объединяет в себе процессы и функции программного обеспечения, оборудования, сетей, телекоммуникаций и электроники. (Techopedia.com, 2016) [7]

Социальная среда - это понятие включает в себя непосредственную физическую среду, социальные отношения и культурную среду, в которой функционируют и взаимодействуют определенные группы людей. Взаимодействовать с социальной средой возможно в разных масштабах, часто одновременно, в них включаются: домашние хозяйства, кварталы, города и районы. Социальная среда динамична и изменяется со временем в результате как внутренних, так и внешних сил. (Barnett, E., & Casper, M. (2001). A definition of "social environment". American journal of public health, 91(3), 465.) [8]

Методы и результаты исследования

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

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

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

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

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

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

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

Состав работы

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

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

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



Глава №1 - Обзор литературы

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

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

1.1 Блок технических инструментов

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

Одним из модулей разрабатываемой системы является мобильное приложение. Выбор такого варианта решения взаимодействия с конечными пользователями сделан исключительно по причине ориентированности сервиса на быстроту, доступность и удобство в работе, что как раз сочетает в себе современный смартфон или планшет. В качестве платформы реализации была выбрана созданная компанией Apple операционная система iOS. Необходимо сделать еще один выбор: какой язык программирования использовать для реализации приложения? По правде говоря, конечный выбор не очевиден, поскольку у существующих главных двух альтернатив есть ряд сильных различий, выделяющий сильные и слабые стороны каждого из них. В данном контексте речь пойдет о языках программирования Swift и Objective-C. [9] В рассмотренной интернет статье, имеющей название «Swift vs Objective-C: 15 Ways Swift Supersedes Objective-C», показана наиболее актуальная информация о данных двух языках программирования, приведен ряд ключевых факторов сравнения. Автор данной работы напрямую выделяет некоторые преимущества языка программирования Swift. Во-первых, выделяется полная поддержка передовых технологий (именно языком Swift), поскольку в разрабатываемом модуле сервиса (мобильном приложении) планируется использование большого списка встроенных служб, включая оптимизированные и актуальные обновления и дополнения. К этому же пункту автор статьи относит еще несколько преимуществ: быстрое подключение обновленных библиотек, возможность аппаратного ускорения работы - являются определяющими факторами успешного и облегченного поддержания будущей работоспособности мобильного приложения, включая возможность реализации обновлений. Следующий важный по мнению автора аспект - уменьшение средней скорости разработки, по причине более лаконичной и простой структуры файлов в проекте по сравнению с аналогичной, реализованной с помощью Objective - C. Улучшенная система управления памятью, на текущий момент уже интегрированная в ядро Swift - это еще один пример преимущества. Разумеется, автор выделяет и недостатки языка, а именно: более длительное время компилирования и очень частые серьезные обновления синтаксиса языка, которые открывают новые возможности для разработчиков, но в то же время создают множество проблем, поскольку требуют лишнего обучения и принудительного переделывания проектов, разработанных на старых версиях языка.

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

Следующие источники дополняют полученную ранее информацию о языке разработки, приоткрывая особенности практического использования и рекомендациями по использованию синтаксических структур языка. Официальный главный документ с правилами синтаксиса языка находится в онлайн формате, в виде документации «Apple Developer Documentation», отсортированной по разработанным компанией Apple пакетам. [10] Следующий источник - пособие по изучению языка Swift «IOS 12 Programming Fundamentals with Swift: Swift, Xcode, and Cocoa Basics» хорошо известного в сообществе разработчиков издателя. [11] В данной книге автор подробно описывает и предоставляет разбор нововведений последней на момент публикации версии языка программирования 4.2. Книга «Beginning iPhone Development with Swift 4: Exploring the IOS SDK» является источником информации по базовому взаимодействию со всеми основными возможностями среды разработки Xcode и знакомит с наиболее часто встречающимися сценариями и элементами в разработке, используя при этом широкий и актуальный ряд встроенного функционала. [12] После завершения процесса изучения перечисленных источников стало возможным аргументированно и взвешенно признать доминирование преимуществ языка, и выделить в качестве основополагающих, в ключе разрабатываемого продукта, быстродействие и интеграцию последних актуальных технологий. Это лишний раз помогло принято решение в сторону использования языка Swift в качестве языка разработки модуля.

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

В процессе разработки данного модуля использовались известные практики, например некоторые рекомендации описаны в руководстве по созданию REST API серверов «Build RESTful API in Go and MongoDB». [13] Из названия и начального контекста онлайн статьи можно заметить, что автор раскрывает особенности конкретной реализации такого модуля, который совпадает с первичным видением необходимых функциональных способностей API создаваемого модуля. При этом для создания REST API используется язык программирования Go, а в качестве базы данных используется не реляционная Mongo DB. В случае конкретного решения выбор таких инструментов разработки был сделан по причине наличия опыта в разработке таких решений, с целью экономии времени разработки, а также по причине наличия популярности и большого количества работоспособных проектов, которые в своём ядре используют абсолютно такую же связку технологий. Стоит заметить, что выбор и сравнение с альтернативными вариантами имеет очень глубокий и тонкий технический характер, получается, что его включение в данную работу не несёт такой ценности, как описание, к примеру выбранной архитектуры связи модулей и разработки финального продукта.

Завершает перечисление, представленное в этой секции, модуль, который представляет собой удобное средство для проверки работоспособности основных модулей сервиса, сбора и аналитики данных, а также для возможности удаленного администрирования. Произведен поиск и отбор доступных вариантов реализации таких решений. Учитывая особенности рынка и самого разрабатываемого сервиса было принято использовать максимально легкое в подключении и конфигурации решение, для подключения к которому не понадобится большое количество шагов и усилий. Поскольку данный модуль содержит в себе доступ к контролю за состоянием работы других модулей, безопасность подключения и передачи данных - приоритетная задача. К счастью, такое решение существует - это Telegram бот. В работе «The Rise of Bots: A Survey of Conversational Interfaces,

Patterns, and Paradigms» помимо описания причин стремительного роста использования ботов, предоставляется перечисление преимуществ использования ботов как для пользователей, так и для разработчиков. [14] Начнём со стороны пользователей. По мнению авторов статьи реализация такого средства, как бот позволяет: получить мгновенный доступ к нужным функциям, поскольку настройка и скачивание бота на устройство попросту отсутствуют, все расчёты и работа выполняется на выделенном отдельно сервере, следовательно так и добивается высокая скорость работы и безопасности; не зацикливаться на конкретной платформе использования, поскольку чат-приложения, в которые встраиваются боты - это кроссплатформенные решения (пример: Telegram, Messenger, WhatsApp); встроенная аутентификация пользователей, для аналогичных онлайн решений везде необходимо прохождение трудного и нудного процесса создания аккаунта, безопасность входа и работы с ботами гарантирует чат-приложение в которое уже произвел вход пользователь; быстрота работы с ботом: поскольку архитектура написания таких решений, а вернее четкая декомпозиция функционала вместе с фактом асинхронности выполнения задач, позволяет выполнять большое количество запросов одновременно; облегченный интерфейс и не перегруженность контентом - основные преимущества пользовательского интерфейса известных чат-приложений, следовательно боты реализованные внутри платформы наследуют ровно тот же самый интерфейс взаимодействия; ограниченные требования к данным и свободному месту: как уже было сказано в начале, боты не устанавливаются непосредственно на само устройство, а количество переданных и полученных данных (по траффику) крайне мало, поскольку преимущественно используются протоколы передачи текстовых данных, которые используются в технологии мгновенной передачи сообщений и имеют крайне сниженный объем передаваемых данных. Так же авторы приводят пример конкретных форм и панелей быстрого взаимодействия, встроенных во все популярные чат-приложения. Это и ранее описание преимущества реализованы в приложении Telegram, его выбор продиктован еще и реализованными эффективными средствами шифрования.

Какой массив инструментов и практик понадобится для реализации такого модуля? В качестве основного инструмента выступает единый сервис, разработанный командой Telegram специально для создания, конфигурации, настройки ботов, которые будут написаны для этой платформы. Вся документация для разработчиков находится в одном месте, на информационном веб сайте. [15] Bot API содержит в себе все необходимые для работы с ботом команды. Получить первичное понимание работы с новым инструментом можно изучив серию из обучающих статей «Introduction to the Telegram Bot API», получив при этом не только практические советы и демонстрацию работы бота, но и глубинные теоретические знания внутреннего процесса общения бота с клиентским чат-приложением. [16] При этом какой язык программирования использовать для разработки модуля остаётся за конкретным разработчиком, поскольку большой разницы при выборе из различных вариантов наблюдаться не будет.

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

1.2 Блок архитектурного решения

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

Сделав выбор языка программирования создаваемого мобильного приложения, следующим логичным шагом является определение используемой архитектуры, а точнее выбор дизайн шаблона (паттерна разработки), который наилучшим способом подойдет для решения всех бизнес-кейсов сервиса. Выделяется ограниченное множество популярных архитектур строения мобильных приложений. Определяющими различиями между ними являются: разделение обязанностей между тремя основными структурами (Представление, Контроллер и Модель), иногда могут появляться дополнительные логические объекты, которые забирают на себя часть обязанностей; наличие или отсутствие связей между основными сущностями, согласно этому признаку возможно определить тип реализации архитектуры. В статье «iOS Architecture Patterns. Demystifying MVC, MVP, MVVM and VIPER» крайне подробно описаны популярные методологии построения архитектуры мобильных приложений, разрабатываемых для платформы iOS на языке Swift. [17] Автор проводит параллель между описанными архитектурами шаг за шагом начиная со стандартного представления приложения MVC (рисунок 1), сравнивая его с предложенным самой компанией Apple альтернативным подходом к связям в паттерне MVC, и заканчивая более специфичными и узко ориентированными MVVM и VIPER. Как я уже заметил ранее основными различиями между дизайнами шаблонов приложений являются логические сущности и связи, существующие между ними. Таким образом при выборе архитектурного паттерна стоит принимать во внимание как бизнес-кейсы стоящие перед приложением, так и способы взаимодействия приложения с внешними модулями комплексной системы. В случае данного разрабатываемого продукта ими являются: сервер с развернутым API и база данных с основной информацией о пользователях и сессиях, существующих между ними.

Рисунок 1: Архитектура традиционного паттерна MVC (Model-View-Controller)

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

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

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

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

Как можно заметить, на традиционном представлении, которое можно рассмотреть на рисунке 1, находятся характерные связи между сущностями. Предложенная Apple модель MVC, которую можно наблюдать на рисунке 2, предлагает иное расположение связей при сохранении того же набора сущностей. Основное отличие состоит в разделении любых прямых связей между Представлением и Моделью.

Рисунок 2: Архитектура предложенного Apple паттерна MVC (Model-View-Controller)

Заметно, что Контроллер, наконец приобретает влияние и теперь является прямым посредником, освобождая другие две сущности от, порой путающих разработчиков, связей между друг другом. Такой паттерн разработки мобильных приложений отражает теоретически верную и оптимизированную структуру, на практике же наблюдается совмещение двух сущностей (Контроллера и Представления) в одну, при том, что логический объект Модели остаётся неизменным. Тем самым значительно нарушается предложенная теоретическая модель, упрощаются связи между сущностями, происходит нарушение принципа переиспользования Представлений, поскольку теперь они совмещены вместе с Контроллером. Далее, новейший дизайн шаблон подробно описанный автором - это MVVM (Model - View - View Model).

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

Рисунок 3: Архитектура паттерна MVVM (Model-View-View Model)

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

В случае текущего разрабатываемого решения, данный паттерн не является оптимальным выбором, поскольку мобильное приложение будет иметь минимальное количество экранов и не требует такого усложнения структуры актуализации данных на интерфейсе. С примером реализации подходящих приложений можно ознакомиться в книге «Mastering MVVM With Swift», где подробно представлены технические и бизнес кейсы использования и внедрения данного паттерна разработки. [18]

Особое внимание было обращено на руководство по построению архитектур мобильных приложений «Mobile Application Architecture Guide» от компании Microsoft, поскольку именно из этого источника была взята архитектура, которая максимально подходила под первичное видение. [19] Описанная автором многослойная структура проекта представляет из себя три упорядоченных и связанных логических слоя:

· Presentation Layer (Слой представления) - сущности и связи между ними, которые обеспечивают отрисовку и отображение графического наполнения приложения, т.е. UI.

· Business Layer (Бизнес слой) - представляет собой слой-посредник, порой обладающий сущностями, которые максимально приближены к объектам существующим в реальном мире.

· Data Layer (Информационный слой) объединяет в себе многообразие конкретных реализованных функций приложения, менеджмента хранением данных и иных технических реализаций, которые позволяют получать и отправлять данные.

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

Рисунок 4: Архитектура мобильного приложения, предложенная Microsoft

Источник: Mobile Application Architecture Guide, Microsoft, 2008

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

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

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

· возможность детального тестирования каждого отдельного элемента логики;

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

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

· разграничение логики ведёт к потенциальному уменьшению ошибок.

Для приложения, разрабатываемого в контексте данной работы, был использован идеологически идентичный паттерн, который наследует все преимущества и особенности, которые были описаны для многослойного шаблона. Он носит название SOA (Service-Oriented Architecture), иначе Сервисно-ориентированная архитектура. Основное его отличие - это выделение центрального слоя в виде Service Layer / Сервизного слоя. Логическая связывание логики перетекающей из верхнего уровня (Слой представления) в нижний, именуемый в данном паттерне Core Layer / Функциональным слоем, который выполняет все те же функции, однако его название указывает не более узконаправленное действие блоков сущностей внутри описанного слоя. Примерами блоков внутри Функционального слоя могут являться: блок выполнения запросов к сети, блок записи данных в локальную базу данных, блок парсинга полученных данных и блок обработки Bluetooth подключений. При этом упомянутый выше слой (Сервисный слой) помимо бизнес логики, теперь обязан содержать специальные облегченные сущности равные количеству блоков из Функционального слоя. Таким образом достигается необходимая абстракция, т. е. невозможность обращения из верхнего слоя к нижнему напрямую и соблюдается контроль за количеством инициализированных сущностей, другими словами затраты на используемую приложением память при грамотном использовании такого способа будут уменьшаться, а понимание работы кода для не знакомых с проектом разработчиков - увеличиваться. Конкретно это описание структуры SOA разработано специализированно для использования при проектировании мобильных приложений и некоторых легковесных приложений для персональных компьютеров.

Источником информации о глобальных принципах Сервисно-ориентированной архитектуры является книга «SOA Design Patterns». [20] Такой дизайн шаблон достаточно детализирован, однако при этом распространяем на большое количество платформ и типов создаваемых решений.

Завершает перечисление, представленное в этой секции, определение архитектурных особенностей проектирования модуля API с присоединённой базой данных Mongo DB. Остановимся на рассмотрении лучших практик в проектировании REST API, поскольку именно такой тип API включен в создаваемый сервис. Найденные веб-ресурсы «Clean Architecture for a Go REST API» и «REST API Best Practices» помогли разобраться и принять решение в сторону использования части описанных советов. [21] [22] Необходимо заметить, что была обнаружена общность построения типичных API решений, их структура крайне проста, из - за этого факта не существует большого вариативного ряда дизайн шаблонов. Подробнее о реализации данного модуля можно узнать в соответствующей главе данного исследования.

1.3 Блок исследования социальной среды

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

Основным источником информации стал Федеральный закон «О социальной защите инвалидов в Российской Федерации», в котором закреплен ряд принятых на государственном уровне мер по содействию и поддержке людей с инвалидностью. [23] Следовательно, при дальнейшем поиске информации о доступных для инвалидов видах помощи, необходимо учитывать, что все найденные услуги, возможности главным образом описаны в указанном федеральном законе. Одним интересным фактом является регулярная изменяемость и пополняемость документа правками и новыми статьями, что может говорить лишь об обеспокоенности и заинтересованности государства в помощи данной группе населения. В качестве одного из таких нововведений можно считать включение программы реабилитации и абилитации инвалидов (Глава III) в основное тело документа в декабре 2014 года и последующие ежегодные правки в различных главах федерального закона. Учёт таких действий государства помогает понять так же еще и наличие тренда по поиску инновационных и новых решений для борьбы с уже хорошо знакомыми проблемами. Однако перед тем как говорить о потенциальных решения и планах необходимо разобраться с текущей ситуацией.

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

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

·  бесплатный проезд в транспорте;

·  услуги социального такси;

·  услуги центра мобильности в метро;

·  бесплатную парковка для инвалидов.

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

Источником информации о перспективах развития социального сектора является документ «Стратегия-2020: Новая модель роста - новая социальная политика». [25] Предложенная стратегия предлагает осуществить маневр, который не был доступен ранее по ряду причин, при этом учитывать в качестве конкурентного преимущества - высокое качество человеческого капитала, сделать ставку на рост инновационной деятельности и, в качестве нововведения, самодеятельность профессиональных сообществ будет занимать особое место в новой политике государства. Все эти факты косвенно влияют на описываемую в исследовании проблему, но всё же четко начинает показываться тренд движения государства к подключению дополнительных ресурсов для создания эффективных решений. Этот факт приоткрывает возможность создания и внедрения таких сервисов/продуктов, как описываемый в данной работе.



Глава №2 - Анализ рынка решений

2.1 Описание и анализ найденных решений

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

Первое найденное решение - общественное движение «Доступ открыт» существующее с 2013 года, изначально будучи группой неравнодушных людей, загорелись идеей создать мобильное приложение, с целью упрощения организацию поездок. [26] Такое решение могло помочь связать волонтеров и инвалидов, но было специализированно исключительно для помощи с сопровождением на концерты/массовые мероприятия. К сожалению, приложение не было особо популярным и на данный момент его нельзя найти ни на одной из известных платформ. В качестве одной из причин отсутствия должного успеха приложения может быть встраивание функций социальной сети без качественного, детального связывания с основным функционалом и механикой работы приложения. Несмотря на то, что в ключе данного приложения вставка элементов, хорошо знакомых из социальных сетей, действительно могла улучшить продукт, однако этого не произошло. В качестве еще одной вероятной причины сворачивания проекта мобильного приложения мог послужить крайне специализированный характер выбранного вектора предоставления помощи. Ровно этот же факт я отношу и к особенностям продукта, поскольку именно это отделяет его от других решений на рынке. Продолжая размышлять на тему трудностей при выпуске данного приложения, на ум приходит очевидная мысль, вполне возможно, что существовали сложности и с распространением решения, поскольку продукт не имел выверенного канала или набора каналов распространения. Обратимся к описанию мобильного приложения, оно имело ценностное предложение со следующей формулировкой: поможем инвалидам найти волонтеров. Команда, которая разработала и придумала этот проект, в своей официальной заявке на краудфандинге объяснила, что приложение «Доступ открыт» поможет людям с инвалидностью найти друзей и волонтеров, вместе с которыми они смогут посетить места, которые ранее были для них недоступны. Необходимо выделить, что краудфандинговая компания была пройдена успешно и за 2015 год было собрано 162% необходимой суммы, такой проект можно честно назвать успешным. Данный проект имел крупную поддержку на краудфандинге, имел современный подход к выбору платформы распространения продукта, частично согласуется по специфике не реализуемый в данном исследовании сервис, именно поэтому данный проект был выбран в качестве полноценного примера.

Несмотря на неуспешность описанного проекта, данное общественное движение нельзя списывать со счетов. На момент написания исследования оно имеет крупный интернет портал на котором представлена информация: о возможности вступления в организованные движением клубы добровольцев; онлайн форма для поиска инвалидами - волонтеров; обзоры, интервью, описания и анонсы событий. На чём стоит заострить внимание на примере этой общественной организации, так это на наличие у организации двух продуктов. Мобильное приложение было принято отнести к сегменту - решение содержащее инструмент поиска волонтера для аудитории людей с ограниченными возможностями. Почему во внимание были взяты другие сегменты, если данный выглядит самодостаточным? Ответом на этот вопрос может послужить факт того, что хоть и такой сегмент является наиболее приоритетным и прямолинейным со стороны поставленной перед продуктом задачи - помогать людям с ограниченными возможностями преодолевать трудности с передвижением, на рынке в процессе анализа и поиска были найдены решения, которые помогают в разрешении всего того же перечня проблем, однако в ином ключе. Еще одно решение, которое относится к первому сегменту - это замеченная выше онлайн форма по поиску волонтёров на официальном сайте общественного движения. [27] Очевидно, что решение концептуально уступает мобильному приложению со стороны удобства пользования веб форма может показаться неинтуитивной, неудобной (рисунок 5), в то время, когда формат мобильного приложения, вместе с встроенной системой диалогов и чатов создан для того, чтобы пользователю было комфортно поддерживать связь с волонтером. Оба данных продукта не обладают достаточно важным фактором - скоростью предоставления помощи, поскольку процесс поиска волонтера может затянуться на неопределенный срок или же актуальность помощи может уже исчерпать себя.

Рисунок 5: Форма для заполнения заявки на поиск волонтера

Источник: Сайт общественной организации «Доступ открыт» - URL: http://dostup-otkryt.ru/ya-khochu-nayti-volontera

Следующий найденный продукт - это онлайн форма подачи заявки на сопровождение лиц в Московском Метрополитене. [28] Крайне схожая концепция с недавно рассмотренной онлайн формой поиска волонтеров. Люди с инвалидностью или испытывающие иные проблемы теперь обладают возможностью получения помощи при передвижении по метрополитену города Москвы, однако для подтверждения и использования такой услуги необходимо заполнить детальную форму на официальном веб сайте (рисунок 6). Это говорит о некотором низком уровне доступности решения и, как правило, рассчитывать на высокую скорость получения помощи не приходится. Предположим, инвалид оказавшись в метро, не имеет никакой возможности получить помощь быстро, поскольку регистрация и подтверждение такой услуги проводится исключительно заранее и через упомянутый официальный сайт Московского Метрополитена. Неподготовленный человек вынужденно встретился с такой проблемой и на сегодняшний день её, используя известные инструменты, решить практически невозможно. Выделенная проблема показывает главные недостатки, но что же о особенностях и выгодах пользователей? В рамках текущего решения, таким положительным фактором является большой реестр волонтеров, сотрудников Метрополитена. При выполнении всех условий, заполнив заявку заранее или договорившись о сопровождении заблаговременно каждый обратившийся получит помощь, т. е. нехватка кадров помощи крайне маловероятна, поскольку Московский Метрополитен - это государственное предприятие, которое обладает достаточными ресурсами для найма или связи с волонтерскими центрами. Как и в случае ранее описанной формы для поиска волонтеров на сайте общественной организации, это решение относится к сегменту - решение содержащее инструмент поиска волонтера для аудитории людей с ограниченными возможностями, хотя в данном случае оно чуть ли не полностью построено на решении этой проблемы.

...