«Этапы разработки, тестирования и ввода в эксплуатацию мобильных приложений»

Содержание:

ВВЕДЕНИЕ

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

Согласно определению, мобильное приложение – это самостоятельный программный продукт, устанавливаемый под необходимую операционную систему смартфона, планшетного компьютера или иного мобильного устройства. Наиболее популярными операционными системами для мобильных устройств сегодня являются Android, IOS и Windows.

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

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

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

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

Объектом исследования в данной работе является поэтапное тестирование мобильных приложений.

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

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

1. определить основные этапы разработки мобильных приложений;

2. определить характеристики мобильных приложений.

Теоретико-методической основой исследования послужили труды зарубежных и российских программистов, которые посветили свои труды программированию в использовании мобильных приложений: Дейтел П., Дейтел Х., Уолд А., НильсенЯ., БудиуР., Арлоу Дж., Нейштадт А.Бурнет Э.

Глава 1. Основные этапы разработки мобильных приложений

1.1 Основные этапы и их описание

При разработке любого мобильного приложения можно выделить следующие ключевые этапы:

1. Бизнес-анализ целевого рынка.
2. Выработка итогового согласованного решения.
3. Прототипирование.
4. Написание кода и внедрение технологий.
5. Тестирование.
6. Создание предрелизной (тестовой) версии.
7. Добавление приложения в магазин.
8. Последующая техническая поддержка и маркетинговое продвижение.

Рассмотрим данные этапы более подробно.

Бизнес-анализ целевого рынка

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

Вот перечень ориентировочных вопросов, на которые стоит найти ответы, прежде чем формулировать техническое задание и заказывать разработку приложения^[3]:

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

Выработка согласованного решения^[4]

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

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

Прототипирование

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

Прототипы разрабатываются дизайнером при помощи инструментов для прототипирования, таких как Framer, Indigo Studio, Mockingbird, etc.

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

Написание кода и внедрение технологий

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

Тестирование

На различных этапах разработки приложения обязательным является внутреннее тестирование приложения, как на симуляторах, так и на реальных устройствах^[6]. Более подробно этот процесс будет рассмотрен в пункте 1.2 «Процесс тестирования мобильных приложений».

Создание предрелизной версии

В результате серии тестов и доработок приложения, должна быть получена рабочая версия. Именно эту версию и предстоит добавить в магазин приложений: Apple App Store, Google Play, магазин приложений Windows Phone (в зависимости от того, для какой платформы ведется разработка) или любой аналогичный сервис для дистрибуции приложений^[7].

Добавление приложения в магазин

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

Дальнейшая техническая поддержка и маркетинговое продвижение приложения^[8]

Данный этап нельзя однозначно назвать основным, но при желании заказчика возможно предоставление дополнительных услуг, таких как техническая поддержка приложения, дальнейший выпуск новых версий под обновляемые версии мобильных ОС, а также маркетинговое продвижение^[9].

Поскольку эти услуги предоставляются отдельно от основного пакета услуг, то и, как правило, оплачиваются отдельно. Помимо маркетинга и техподдержки возможно также размещение приложения в App Store или Google Play от имени заказчика (услуга White Label) и обеспечение серверной поддержки для приложения.

1.2. Процесс тестирования мобильных приложений

Тестирование – очень важный этап разработки мобильных приложений^[10]. 

Стоимость ошибки в релизе мобильного приложения высока. Приложения попадают в Google Play в течении нескольких часов, в Appstore -нескольких недель. Неизвестно сколько времени будут обновляться пользователи. Ошибки вызывают бурную реакцию: пользователи оставляют низкие оценки и негативные отзывы. Новые пользователи, видя это, не устанавливают приложение. Качественное и полное тестирование приложения позволяет свести эти риски к минимуму.

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

Тестирование требований

Тестирование начинается еще до разработки. Отдел дизайна передает тестировщикам навигационную схему и макеты экранов, менеджер проекта – требования, невидимые на дизайне. Если дизайн предоставляет заказчик, макеты до передачи в отдел тестирования проверяются дизайнерами^[11].

Тестировщик анализирует требования на полноту и противоречивость. Если в проекте исходные требования содержат противоречивую информацию, такие вопросы решаются еще до начала разработки. Так же часто бывает, что в проекте предоставлены не полные требования: не хватает макетов второстепенных экранов, ограничений на поля ввода, отображения ошибок или есть незадействованные кнопки^[12]. Неочевидны невидимые на макетах вещи: анимации, кеширование картинок и содержимого экранов, работа в нестандартных ситуациях. Недостатки требований обсуждаются с менеджером проекта, разработчиками и дизайнерами. После 2-3 итераций вся команда гораздо лучше понимает проект, вспоминает забытый функционал, фиксирует решения по спорным вопросам. На этом этапе используется используются системы управления проектами, например, «Basecamp».

После формирования полных, не противоречащих друг другу требований, тестировщик составляет так называемые smoke-тесты – первичные, самые грубые тестирования, направленные на то, чтобы выявить наиболее очевидные ошибки, и функциональные тесты, покрывающие исходные данные^[13].

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

Для хранения и проведения тестирования используются системы управления тестированием, такие как «Sitechсo», «TestLink», «Cradle» и т.д.

Ниже приведен пример использования системы «Sitechсo».

Для проекта Trava на этом этапе было написано 1856 тестов.

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

Билд-сервер

Билд – сервер^[14] – это инструмент для осуществления непрерывной интеграции при разработке программного обеспечения. Билд-серверы также часто называют серверами непрерывной интеграции или просто CI-серверами (от англ. «continuous integration servers»). Существуют билд – серверы как с открытым исходным кодом, так и с предоставлением коммерческих опций. Большинство крупных продуктов поддерживает множество различных систем управления версиями, а также множество различных вариантов того, когда и как инициировать сборку, что делать в рамках сборки (например, запускать тесты, развертывать на промежуточном сервере) и способы уведомления членов команды о результатах.

Для примера рассмотрим сборку на билд-сервере TeamCity.

Если менеджер проекта поставит галочку «для тестирования», тестировщикам уходит письмо о новой сборке для тестирования. Ее номер отображается на мониторе в кабинете тестировщиков^[15]. Красным отображаются сборки, выпущенные за последние сутки. Их нужно тестировать активнее, чем старые, помеченные белым^[16].

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

Тестирование сборок бывает быстрое и полное. Рассмотрим каждый тип отдельно.

Быстрое тестирование

Быстрое тестирование проводится после завершения итерации разработки, если сборка не пойдет в релиз^[17]. Для начала проводятся smoke-тесты, чтобы понять имеет ли смысл тестировать сборку. Затем из системы отслеживания ошибок выгружаются все выполненные задачи и исправленные за текущую итерацию ошибки и проверяется соответствие результата описанию задания. Если при этом задача также включала в себя новые элементы интерфейса, она отправляется дизайнерам для сверки с макетами^[18]. Некорректно выполненные задачи переоткрываются. Все ошибки заносятся в систему отслеживания ошибок. Ко всем ошибкам обязательно прикладываются логи со смартфона, а к ошибкам отображения или, как их еще называют, UI багам (от англ. «User Interface») - скриншоты с пометками и комментариями. После этого выполняются функциональные тесты текущей итерации. Если были найдены ошибки, не покрытые тест-кейсами, создается новый тест-кейс.

Для андроид приложений выполняются monkey тесты^[19] - тестирование, при котором команда тестировщиков вводит в приложение случайные произвольные данные и наблюдает за поведением приложения.

Для этого выполняются следующие скрипты:

adb shell monkey -p ru.stream.droid --throttle 50 --pct-syskeys 0 --pct-ap

pswitch 0 -v 5000

По окончании тестирования ставится галочка «тестирование багов пройдено» в билд-сервере^[20].

Если в процессе тестирования не было найдено blocker, critical и major ошибок, ставится галочка «можно показывать заказчику». Ни один билд не отсылается заказчику без одобрения отдела тестирования. (По согласованию с заказчиком иногда высылаются билды с major багами)^[21].

Критичность бага определяется по таблице^[22].

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

Полное тестирование

Полное тестирование проводится непосредственно перед релизом. Оно включает себя в себя быстрое тестирование, регрессионное тестирование, monkey-тестирование на большом числе устройств (сто устройств или больше) и тестирование обновлений^[23].

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

Очень важный шаг – тестирование обновлений. Почти все приложения хранят данные локально (даже если это cookie логина) и важно удостовериться, что после обновления приложения все данные пользователя сохранятся^[25]. Тестировщик скачивает сборку из магазина, создает сохраняемые данные (логин, плейлисты, транзации учета финансов), обновляет приложение на тестовую сборку и проверяет работоспособность приложения, а также наличие и корректность всех введенных данных. Затем прогоняет smoke-тест. Процесс повторяется на нескольких устройствах^[26]. 

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

Релизный monkey-тест проводятся как на iOS, так и на Android устройствах (есть в техническом задании была заложена работоспособность на обеих ОС) при помощи сервисов тестирования мобильных приложений, например Appthwack^[27]. В конце полного тестирования, кроме письма, вручную составляется подробный отчет.

Сборка уходит в релиз только при прохождении всех тест-кейсов.

Тестирование внешних сервисов

Тестировать интеграцию с системами сбора статистики, такими как Google Analytics или Flurry, как и с системой статистики заказчика непросто. Высока вероятность того, что в итоговый релиз уйдет сборка с нерабочим Google Analytics, и данный акт останется незамеченный вплоть до того момента, как данный функционал понадобится заказчику ^[28].
Поэтому в обязательном порядке для внешних сервисов создается тестовый аккаунт, который проверяется при полном тестировании. Кроме того, отправка статистики фиксируется в логах, которые проверяются тестировщиками. При релизе тестовый аккаунт подменяется основным^[29].

Учет времени

Учет времени тестировщиков производится в отдельном проекте системы управления проектами. На составление тест-кейсов, прогон тестов, написание отчетов по проекту заводится отдельная задача и стандартными средствами в ней отмечается затраченное время^[30].

1.3. Планирование работ по тестированию

После определения границ тестирования можно приступать к планированию самих работ^[31]. Необходимо отметить, что тестирование мобильного приложения занимает значительно больше времени, чем, например, веб-сайта или десктопного приложения, т.к. требуется учесть некоторые особенности и заложить время на следующие дополнительные проверки^[32]:

• тестирование требований на полноту и внутреннюю непротиворечивость;
• тестирование совместимости версий АПИ;
• тестирование работы приложения на разных физических устройствах;
• юзабилити-тестирование.

Подробнее рассмотрим каждый из этих пунктов.

Тестирование требований

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

Тестирование совместимости API

Еще один фактор, увеличивающий время тестирования, – это постоянно меняющаяся функциональность тех веб-приложений, по аналогии с которым реализовывалось мобильное приложение. Релизы программы не успевают за изменениями веб-версии, структура данных меняется, и веб-сервисы перестают возвращать нужные для мобильного приложения данные^[35]. В связи с этим неотъемлемой частью процесса стало тестирование API (от англ. – «Application Programming Interface» - набор готовых классов, процедур, функций, структур и констант, предоставляемых приложением (библиотекой, сервисом) для использования во внешних программных продуктах). Проверка состава и формата передаваемых и возвращаемых через REST-сервисы данных позволяет своевременно обнаруживать и исправлять те места, где мобильное приложение отстает от веб-версии^[36].

Тестирование на физических устройствах

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

• переход в фоновый режим при поступлении звонков и sms, срабатывании будильника;
• работу приложения при подключении к другим устройствам;
• работу с разными видами интернет-подключений (Wi-Fi, 4G, 3G);
• обработку ситуаций отсутствия связи (вывод сообщений при отключении интернет-соединения и корректное продолжение работы при его восстановлении);
• процесс переустановки и обновления приложения до новой версии^[37].

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

Юзабилити-тестирование

Еще одним неотъемлемым этапом тестирования мобильного приложения является юзабилити-тестирование^[39]. Здесь очень важно обеспечить для пользователя максимальный комфорт при работе с приложением, который подразумевает выполнение следующих требований^[40]:

• быстрота работы;
• простота и понятность интерфейса;
• минимальный ввод данных с клавиатуры;
• наличие индикации (отклика) на действия пользователя.

Также необходимо, чтобы приложение соответствовало общепринятым стандартам (руководствам) по стилю.

Итак, при разработке мобильных приложений, и при их тестировании, следует учитывать ряд моментов^[41] :

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

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

Вывод первой главы

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

Глава 2. Характеристики мобильных приложений

2.1 Проблема безопасности. Угрозы мобильной информационной безопасности и меры защиты

По оценкам отраслевых экспертов, к 2019 году число мобильных работников по всему миру достигнет 1,8 млрд. человек^[42].

Предполагается также, что к этому времени 75% всех работников в США будут мобильными – в том смысле, что они будут использовать мобильные информационные устройства для выполнения по меньшей мере 20% своей работы^[43]. По данным другого исследования, 36% владельцев мобильных телефонов либо теряли свой телефон, либо становились жертвами воров. Если сопоставить эти цифры, получится, что в ближайшем будущем примерно четверть всех работников потеряют свои мобильные устройства (возможно, вместе с конфиденциальной информацией). Так что нет ничего удивительного в том, что проблема безопасности мобильной информационной техники стоит сегодня для организаций на первом плане. Несмотря на все эти тревоги, лишь немногие органы. Многие компании отказались от реализации всесторонней стратегии мобильной информационной безопасности, поскольку считают, что это слишком дорого и трудоемко. В то же время мобильная информационная технология продолжает все шире внедряться в повседневные рабочие процессы, а нарушения безопасности приводят к значительным убыткам. В 2017 году каждый инцидент в среднем обходился в 6,75 млн. долларов^[44].

Большинство компаний имеют правила информационной безопасности, и стоящая перед ними задача разделяется на две части:

1. Адаптация правил безопасности к мобильной рабочей среде.

2. Выбор средства управления информационными устройствами и обеспечения соблюдения правил. Первый шаг в разработке стратегии мобильной информационной безопасности – определение угроз^[45].

Косвенные убытки от инцидентов информационной безопасности часто значительно превышают прямые расходы на ликвидацию повреждений. Нарушения могут не только повлечь затраты на восстановление данных и возможные штрафы за несоблюдение нормативных требований, но и привести к потере конкурентоспособности. Компании или их руководители могут быть скомпрометированы в глазах общественности и столкнуться с юридическими проблемами. Существует риск потери клиентов и утраты доверия партнеров^[46]. И безусловно, нарушения безопасности могут повредить репутации компании и негативно сказаться на ее деятельности. С учетом того, что мобильные ИТ становятся основой повседневных операций, компании, разрабатывающие стратегию мобильной информатизации, должны решить и задачу обеспечения безопасности^[47].

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

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

Рассмотрим каждый тип угроз в отдельности. Риски, сопряженные с потерей или кражей информационных устройств Мобильные устройства легко теряются, и нет оснований полагать, что в будущем ситуация улучшится^[49]. Потеря устройства может сопровождаться утратой ценных данных. Несмотря на это, во многих случаях к защите данных, обрабатываемых в мобильных устройствах, не принимается никаких мер. В упоминавшемся выше исследовании, где было обнаружено, что более трети владельцев мобильных телефонов в США либо теряли свой аппарат, либо становились жертвой воров, отмечен также следующий поразительный факт^[50]. Почти у 90% из этих людей не было возможности ни удаленно заблокировать свои устройства, ни удалить информацию из них. Кроме того, больше половины пользователей смартфонов не использовали в своих аппаратах никакой парольной защиты^[51].

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

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

Несанкционированный доступ к данным^[52].

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

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

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

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

Только в Великобритании ежегодно похищают примерно 1,3 млн. мобильных телефонов.

В крупных американских корпорациях еженедельно похищается 1 985 USB-накопителей, 1 075 смартфонов и 640 портативных компьютеров^[55].

В Чикаго в такси ежегодно оставляют 120 000 мобильных телефонов.

В США каждую минуту теряется 113 мобильных телефонов.

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

• Формализованный ввод в эксплуатацию мобильных приложений – уполномоченные сотрудники наделяют пользователей правами запуска тех или иных приложений. Таким образом обеспечивается один из уровней жесткого контроля доступа к служебной информации.
• Удаленная настройка – возможность удаленно изменять настройки устройства и права доступа позволяет обеспечить соблюдение установленных правил^[57].
• Мониторинг и регистрация событий и активности – позволяет быстро выявлять нарушения безопасности и автоматически контролировать доступ к служебным данным.

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

Организации, позволяющие своим сотрудникам применять одни и те же устройства и в служебных, и в личных целях, получают значительные преимущества. Работники, которые могут использовать предпочтительную для себя технику, с большей вероятностью станут работать с мобильными бизнес-приложениями, так как это будет для них проще^[58]. Кроме того, если разрешить сотрудникам работать с личными устройствами, это значительно сократит стоимость регулярной модернизации информационной техники. В то же время такой подход сопряжен с рисками. Компании совершенно правы в своем беспокойстве насчет ответственности, которую им придется понести, если их сотрудники станут использовать свои телефоны ненадлежащим образом. И что произойдет со служебной информацией, если сотрудник уволится или продаст свой смартфон? Рычаги для решения этих проблем может дать стратегия мобильной информационной безопасности, предусматривающая применение правил безопасности и средств управления информационной техникой^[59].

• • Обособление бизнес-функций в мобильном устройстве – средства обеспечения безопасности мобильной техники позволяют компаниям обособлять служебную информацию и программы и контролировать их использование^[60].
  • Удаленное стирание данных – позволяет обеспечивать надлежащий вывод техники из эксплуатации. Например, если сотрудник покидает компанию, на его устройстве можно стереть служебные программы и данные так, что это никак не повлияет на целостность личных программ, данных и настроек. Аналогичным образом действующий механизм обеспечения правил безопасности позволяет автоматически стирать всю служебную информацию в любом изымаемом из эксплуатации устройстве^[61].
  • Автоматическое стирание данных при отсутствии подключения к сети в течение определенного времени. Недостатки в управлении устройствами и обеспечении исполнения правил Эффективность правил безопасности определяется способностью организации обеспечить их соблюдение.

Таблица 1.Сводная таблица угроз и мер защиты^[62]

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

2.2 Построение стратегии мобильной безопасности в соответствии с циклом эксплуатации. Угроза меры защиты

Работа с мобильными устройствами и данными на мобильных устройствах связана с риском их потери и кражи, а также с риском несанкционированного доступа к ним. По данным исследований, в больших компаниях в среднем происходит 91% краж мобильных устройств, 53% краж в офисе, 24% потерь мобильных устройств на корпоративных мероприятиях, 50% пользователей сохраняли персональные данные, номера банковских счетов на мобильных устройствах и другую конфиденциальную информацию^[63]. Статистика утверждает, что в мире похищают в среднем 1 лэптоп каждые 53 секунды. В связи с этим крупные компании задумались над обеспечения защиты данных в корпоративной сети. Поэтому набирает популярность тенденция (Bring Your Own Device - BYOD) - «принеси свой собственный устройство», что дает сотрудникам свободу в выборе собственных средств телекоммуникации. Срок BYOD появился достаточно давно (как минимум с 2004 года)^[64]. BYOD - «принеси свой собственное устройство». Данная концепция отвечает на вопрос «что делать с личными мобильными устройствами сотрудников при их использовании в корпоративном среде»^[65]. Тем не менее, взрывную популярность эта идея нашла сравнительно недавно и в основном за счет активности поставщиков IT-услуг и стремительного развития функционала и разнообразия облачных сервисов^[66].

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

В связи с этим было предложено некоторые общие правила защиты мобильных устройств:

1. Блокирование устройства.

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

2. Использование криптографических средств.

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

3. Запрет на сохранение паролей в браузере мобильного устройства.

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

4. Запрет использования менеджеров паролей для корпоративных учетных записей^[68].

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

5. Запрет на установку ПО с непроверенных источников.

Желательно использовать ПО известных разработчиков.

6. Использование корпоративных политик и средств антивирусной защиты.

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

7. Ограничить список данных, которые можно передавать через облачные сервисы^[69].

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

Для облегчения управления мобильными устройствами работников компаний было сформировано и предложены принципы построения политики защиты мобильных устройств «Bring Your Own Device» и «Mobile Device Management»^[70]. Они включают в себя вышеуказанные правила защиты мобильных устройств, а также учитывают особенности введения корпоративной деятельности.

 Исходя из функциональных возможностей систем типа MDM было предложено общий сценарий внедрение MDM^[71]:

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

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

Разработка политики и стандарта применения мобильных устройств и разработка регламентов защиты и управление мобильными устройствами^[72].

3. Внедрение

Настройка базовых компонентов управления, опытная эксплуатация механизмов управления, масштабирования системы.

4. Сопровождение

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

5. Вывод устройств из обращения

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

2.3. Мобильная информационная безопасность как образ жизни

С мобильной безопасностью связана значительная часть технических решений для защиты данных. В последние годы мы наблюдаем также развитие стандартов и практик безопасности – в дополнение к техническим решениям^[74]. Разработчики пытаются защитить данные, обеспечивая их безопасность при хранении, обработке и передаче. Но они, как правило, не следуют практикам безопасной разработки и не всегда обеспечивают достаточный уровень безопасности на своей стороне. 

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

К сожалению, приложения являются достаточно легкой добычей: их легко взломать, отключить всю рекламу и даже отвязать от сервисов верификации. То есть вы, прилагая значительные усилия для создания хорошего приложения и надеясь получить с него прибыль, в итоге можете не только не достигнуть успеха, но и в какой-то мере “потерять” продукт^[75].

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

Применительно к Android реверс инжиниринг представляет собой процесс извлечения исходного кода и ресурсов из APK файла. APK целевого приложения может быть изъят из телефона путем использования ADB или скачивания из Google Play Market^[76].

Подавляющее большинство приложений для мобильных криптовалютных кошельков имеет плохую систему безопасности. Такие данные предоставила компания по безопасности High-Tech Bridge из Сан-Франциско, на основе исследований 2000 приложений в Google Play и анализа их безопасности^[77].

В первых 30 криптографических приложениях из 100 000 общих установок, 93% содержат, по крайней мере, три уязвимости «среднего риска» и 90% содержат, по крайней мере, две уязвимости с высоким уровнем риска. Среди наиболее скачиваемых приложений цифры немного лучше, но не слишком высокие. 94% приложений, из более чем 500 000 установленных, содержат по меньшей мере три уязвимости «среднего риска» и 77% содержат, по крайней мере, две уязвимости высокого риска^[78]. Наиболее распространенными уязвимостями, согласно анализу, являются: «небезопасное хранение данных», что означает, что информация, которая должна быть частной, может оказаться доступной посторонним лицам; «недостаточная безопасность», которая свидетельствует о том, что используемое для защиты данных ПО работает недостаточно эффективно. Данная проблема весьма актуальна в свете растущего спроса на криптовалюту и ее стремительного роста цен, когда пользовательские средства могут быть похищены из-за имеющихся проблем безопасности их мобильных приложений^[79].

Количество применяемых уровней защиты зависит от конкретного приложения. К примеру, если приложение вообще не является клиент-серверным, не содержит никаких КВД, а также не оперирует ценными внутренними алгоритмами, то вообще нет смысла навешивать на него какую-либо защиту^[80]. Если же приложение ориентировано, например, на выполнение банковских операций, или хранение пользовательских паролей, то степень его безопасности должна быть наивысшей. Однако перечисленные ранее общие уязвимости мобильного сектора достаточно легко могут быть исключены из приложения, чаще всего это не вносит особых дополнительных затрат, если применение требуемого уровня защиты было начато на ранних этапах разработки приложения. А вот внедрение защиты пост-фактум в уже работающее приложение вполне может быть сопряжено со значительными затратами сил и времени разработчиков. Поэтому выбор и согласование уровня защищенности, а также перечня КВД в разрабатываемом приложении, должны выполняться на самых ранних этапах проектирования^[81].

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

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

Вывод второй главы

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

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

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

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

ЗАКЛЮЧЕНИЕ

Тестирование – очень важный этап разработки мобильных приложений. 

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

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

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

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

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

1. Размер экрана и touch-интерфейс;

2. Ресурсы телефона;

3. Различные разрешения экрана и версии ОС.

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1. Развитие интернета в регионах России [Электронный ресурс] URL: https://yandex.ru/company/researches/2016/ya_internet_regions_2016
2. Android Studio Features. [Электронный ресурс] URL: https://developer.android.com/studio/features.html
3. Appery.io: Enterprise Mobile App Builder & MBaaS. [Электронный ресурс] URL: https://appery.io/
4. BYOD (Bring your own device) [Электронный ресурс] – Режим доступа: http://www.artoint.ru/solutions/byod/
5. MDM и BYOD – смешать, но не взбалтывать [Электронный ресурс] – Режим доступа: http://www.volgablob.ru/ blog/?p=101
6. Mobile Device Management [Электронный ресурс] – Режим доступа: http://www.lanit.ru/business/ 238/
7. Mobile Device Management. Управление жизненным циклом мобильных устройств [Электронный ресурс] – Режим доступа: http://library.croc. ru/
8. MVP and MVC Architectures in Android. [Электронный ресурс] URL: https://www.techyourchance.com/mvp-mvc-android-1
9. Архитектура Android-приложений. Часть II – архитектурные стили и шаблоны. [Электронный ресурс] URL: https://habrahabr.ru/post/140655/
10. Бурнет Э. Привет, Android! Разработка мобильных приложений. 2-е издание. – СПб.: Издательство «Питер», 2012. – 256 с.
11. Буч Г., Рамбо Дж., Джекобсон А. Язык UML. Руководство пользователя. – СПб.: Издательство «Питер», 2003. – 432 с.
12. Градусов Д.А., Зайцева О.А. Методики выбора устройств для тестирования мобильных приложений // Инновации в науке: сб. ст. по матер. LVII междунар. науч.-практ. конф. № 5(54). Часть I. – Новосибирск: СибАК, 2016. – С. 52-58.
13. Дейтел П., Дейтел Х., Уолд А. Android для разработчиков. 3-е из- дание. – СПб.: Издательство «Питер», 2016. – 512 с.
14. Использование концепции BYOD и других компонентов [Электронный ресурс] – Режим доступа: http://h17007.www1.hp.com/ru/ru/ solutions/technology/BYOD/

DEvIQ – Build Server. Take pride in your code. [Электронный ресурс] URL:https://deviq.com/build-server/

1. Корпоративная мобильность Bring Your Own Device – BYOD [Электронный ресурс] – Режим доступа: http://www.tadviser.ru/index.php/ (Bring_Your_Own_Device_-_BYOD)
2. Машнин, Т.С. Google App Engine Java и Google Web Toolkit: разработка Web-приложений / Т.С. Машнин. - СПб.: BHV, 2014. - 352 c.
3. Мобильная безопасность: Защита мобильных устройств в корпоративной среде [Электронный ресурс] – Режим доступа: https://xakep.ru/2011/10/13/57058/Услуги и возможности в области
4. Нахавандипур, В. iOS. Разработка приложений для iPhone, iPad и iPod / В. Нахавандипур. - СПб.: Питер, 2013. - 864 c.
5. НильсенЯ., БудиуР. Mobile Usability. Как создавать идеально удобные приложения для мобильных устройств. – М.: Эксмо, 2013. – 256 с.
6. Основы создания приложений. [Электронный ресурс] URL: https://developer.android.com/guide/components/fundamentals.html.
7. Приложения в Google Play – SplittPay подели чек с другом! [Элек- тронный ресурс] URL: https://play.google.com/store/apps/details?id=com.github.rchugunov.splitpay&h l=ru
8. Руби, С. Гибкая разработка веб-приложений в среде Rails / С. Руби. - СПб.: Питер, 2013. - 464 c.
9. Фиртман, М. jQuery Mobile: разработка приложений для смартфонов и планшетов / М. Фиртман; Пер. с англ. С. Иноземцев. - СПб.: БХВ-Петербург, 2013. - 256 c.
10. Хеффельфингер, Д. Разработка приложений Java EE 6 в NetBeans 7 / Д. Хеффельфингер. - М.: ДМК Пресс, 2013. - 330 c.
11. Шилдт Г. Java 8. Полное руководство. – М.: Издательский дом «Вильямс», 2017. – 1376 с.
12. Экспозито, Д. Разработка веб-приложений с использованием ASP.NET и AJAX / Д. Экспозито. - СПб.: Питер, 2012. - 400 c.

Приложение

О вводе в промышленную эксплуатацию мобильных приложений для интерактивного сервиса «Личный кабинет налогоплательщика индивидуального предпринимателя»

Управление стандартов и международного сотрудничества во исполнение приказа ФНС России от 21.03.2017 № ММВ-7-6/230@ «О вводе в промышленную эксплуатацию мобильных приложений для интерактивного сервиса «Личный кабинет налогоплательщика индивидуального предпринимателя» для операционных систем iOS и Android» поручает обеспечить проведение мероприятий по информированию налогоплательщиков о вводе в промышленную эксплуатацию мобильных приложений для интерактивного сервиса «Личный кабинет налогоплательщика индивидуального предпринимателя» и их функциональных возможностях. Указанное выше мобильное приложение сервиса «Личный кабинет налогоплательщика индивидуального предпринимателя» создано для платформ iOS и Андроид и доступно для скачивания в магазинах приложений AppStore и GooglePlay, а также на официальном сайте ФНС России на странице сервиса «Личный кабинет налогоплательщика индивидуального предпринимателя». Авторизоваться в мобильном приложении можно с помощью того же логина и пароля, что используются для входа в сервис «Личный кабинет налогоплательщика для физических лиц». Мобильное приложение «Личного кабинета индивидуального предпринимателя» позволяет пользователю: •получать выписку из ЕГРИП в отношении самого себя, а также сведения обо всех постановках на учет в налоговых органах; •получать актуальную информацию о налоговой задолженности, суммах начисленных и уплаченных налоговых платежей, наличии переплат, решениях налоговых органов о зачете и возврате излишне уплаченных (излишне взысканных) сумм, об урегулированной задолженности, о неисполненных налогоплательщиком требованиях на уплату налога и других обязательных платежей, мерах принудительного взыскания задолженности. Также в мобильном приложении индивидуальный предприниматель может просматривать сведения о применяемой системе налогообложения, о ККТ, отслеживать информацию о прохождении своих документов и многое другое.

1. Развитие интернета в регионах России [Электронный ресурс] URL: https://yandex.ru/company/researches/2016/ya_internet_regions_2016 ↑

2. Хеффельфингер, Д. Разработка приложений Java EE 6 в NetBeans 7 / Д. Хеффельфингер. - М.: ДМК Пресс, 2013. С.9 ↑

3. Бурнет Э. Привет, Android! Разработка мобильных приложений. 2-е издание. – СПб.: Издательство «Питер», 2012. С.14 ↑

4. Основы создания приложений. [Электронный ресурс] URL: https://developer.android.com/guide/components/fundamentals.html. ↑

5. Мобильная безопасность: Защита мобильных устройств в корпоративной среде [Электронный ресурс] – Режим доступа: https://xakep.ru/2011/10/13/57058/Услуги и возможности в области ↑

6. Нахавандипур, В. iOS. Разработка приложений для iPhone, iPad и iPod / В. Нахавандипур. - СПб.: Питер, 2013.С.45 ↑

7. Руби, С. Гибкая разработка веб-приложений в среде Rails / С. Руби. - СПб.: Питер, 2013.С.32 ↑

8. Нахавандипур, В. iOS. Разработка приложений для iPhone, iPad и iPod / В. Нахавандипур. - СПб.: Питер, 2013.С.76 ↑

9. Основы создания приложений. [Электронный ресурс] URL: https://developer.android.com/guide/components/fundamentals.html. ↑

10. Шилдт Г. Java 8. Полное руководство. – М.: Издательский дом «Вильямс», 2017.С.108 ↑

11. Мобильная безопасность: Защита мобильных устройств в корпоративной среде [Электронный ресурс] – Режим доступа: https://xakep.ru/2011/10/13/57058/Услуги и возможности в области ↑

12. Основы создания приложений. [Электронный ресурс] URL: https://developer.android.com/guide/components/fundamentals.html ↑

13. Бурнет Э. Привет, Android! Разработка мобильных приложений. 2-е издание. – СПб.: Издательство «Питер», 2012. С.81 ↑

14. DevIQ – Build Server. Take pride in your code. [Электронный ресурс] URL:https://deviq.com/build-server/ ↑

15. Градусов Д.А., Зайцева О.А. Методики выбора устройств для тестирования мобильных приложений // Инновации в науке: сб. ст. по матер. LVII междунар. науч.-практ. конф. № 5(54). Часть I. – Новосибирск: СибАК, 2016. – С. 52 ↑

16. Там же. С.53 ↑

17. Бурнет Э. Привет, Android! Разработка мобильных приложений. 2-е издание. – СПб.: Издательство «Питер», 2012.С.109 ↑

18. Мобильная безопасность: Защита мобильных устройств в корпоративной среде [Электронный ресурс] – Режим доступа: https://xakep.ru/2011/10/13/57058/Услуги и возможности в области ↑

19. НильсенЯ., БудиуР. Mobile Usability. Как создавать идеально удобные приложения для мобильных устройств. – М.: Эксмо, 2013. ↑

20. Приложения в Google Play – SplittPay подели чек с другом! [Электронный ресурс] URL: https://play.google.com/store/apps/details?id=com.github.rchugunov.splitpay&h l=ru ↑

21. Руби, С. Гибкая разработка веб-приложений в среде Rails / С. Руби. - СПб.: Питер, 2013.С.110 ↑

22. Там же ↑

23. НильсенЯ., БудиуР. Mobile Usability. Как создавать идеально удобные приложения для мобильных устройств. – М.: Эксмо, 2013.С.118 ↑

24. Градусов Д.А., Зайцева О.А. Методики выбора устройств для тестирования мобильных приложений // Инновации в науке: сб. ст. по матер. LVII междунар. науч.-практ. конф. № 5(54). Часть I. – Новосибирск: СибАК, 2016. – С. 53 ↑

25. Приложения в Google Play – SplittPay подели чек с другом! [Элек- тронный ресурс] URL: https://play.google.com/store/apps/details?id=com.github.rchugunov.splitpay&h l=ru ↑

26. Бурнет Э. Привет, Android! Разработка мобильных приложений. 2-е издание. – СПб.: Издательство «Питер», 2012.С.83 ↑

27. Фиртман, М. jQuery Mobile: разработка приложений для смартфонов и планшетов / М. Фиртман; Пер. с англ. С. Иноземцев. - СПб.: БХВ-Петербург, 2013.С.154 ↑

28. Мобильная безопасность: Защита мобильных устройств в корпоративной среде [Электронный ресурс] – Режим доступа: https://xakep.ru/2011/10/13/57058/Услуги и возможности в области ↑

29. Машнин, Т.С. Google App Engine Java и Google Web Toolkit: разработка Web-приложений / Т.С. Машнин. - СПб.: BHV, 2014. С.124 ↑

30. НильсенЯ., БудиуР. Mobile Usability. Как создавать идеально удобные приложения для мобильных устройств. – М.: Эксмо, 2013.С.201 ↑

31. Мобильная безопасность: Защита мобильных устройств в корпоративной среде [Электронный ресурс] – Режим доступа: https://xakep.ru/2011/10/13/57058/Услуги и возможности в области ↑

32. Нахавандипур, В. iOS. Разработка приложений для iPhone, iPad и iPod / В. Нахавандипур. - СПб.: Питер, 2013. С.328 ↑

33. Машнин, Т.С. Google App Engine Java и Google Web Toolkit: разработка Web-приложений / Т.С. Машнин. - СПб.: BHV, 2014.С.210 ↑

34. Мобильная безопасность: Защита мобильных устройств в корпоративной среде [Электронный ресурс] – Режим доступа: https://xakep.ru/2011/10/13/57058/Услуги и возможности в области ↑

35. Основы создания приложений. [Электронный ресурс] URL: https://developer.android.com/guide/components/fundamentals.html ↑

36. Дейтел П., Дейтел Х., Уолд А. Android для разработчиков. 3-е из- дание. – СПб.: Издательство «Питер», 2016.С.243 ↑

37. Руби, С. Гибкая разработка веб-приложений в среде Rails / С. Руби. - СПб.: Питер, 2013.С.320 ↑

38. Хеффельфингер, Д. Разработка приложений Java EE 6 в NetBeans 7 / Д. Хеффельфингер. - М.: ДМК Пресс, 2013.С.193 ↑

39. Экспозито, Д. Разработка веб-приложений с использованием ASP.NET и AJAX / Д. Экспозито. - СПб.: Питер, 2012. С.106 ↑

40. Фиртман, М. jQuery Mobile: разработка приложений для смартфонов и планшетов / М. Фиртман; Пер. с англ. С. Иноземцев. - СПб.: БХВ-Петербург, 2013.С.67 ↑

41. Мобильная безопасность: Защита мобильных устройств в корпоративной среде [Электронный ресурс] – Режим доступа: https://xakep.ru/2011/10/13/57058/Услуги и возможности в области ↑

42. Основы создания приложений. [Электронный ресурс] URL: https://developer.android.com/guide/components/fundamentals.html ↑

43. Мобильная безопасность: Защита мобильных устройств в корпоративной среде [Электронный ресурс] – Режим доступа: https://xakep.ru/2011/10/13/57058/Услуги и возможности в области ↑

44. Приложения в Google Play – SplittPay подели чек с другом! [Электронный ресурс] URL: https://play.google.com/store/apps/details?id=com.github.rchugunov.splitpay&h l=ru ↑

45. Нахавандипур, В. iOS. Разработка приложений для iPhone, iPad и iPod / В. Нахавандипур. - СПб.: Питер, 2013.С.219 ↑

46. Бурнет Э. Привет, Android! Разработка мобильных приложений. 2-е издание. – СПб.: Издательство «Питер», 2012.С.174 ↑

47. Машнин, Т.С. Google App Engine Java и Google Web Toolkit: разработка Web-приложений / Т.С. Машнин. - СПб.: BHV, 2014.С.198 ↑

48. Мобильная безопасность: Защита мобильных устройств в корпоративной среде [Электронный ресурс] – Режим доступа: https://xakep.ru/2011/10/13/57058/Услуги и возможности в области ↑

49. Фиртман, М. jQuery Mobile: разработка приложений для смартфонов и планшетов / М. Фиртман; Пер. с англ. С. Иноземцев. - СПб.: БХВ-Петербург, 2013.С.100 ↑

50. Мобильная безопасность: Защита мобильных устройств в корпоративной среде [Электронный ресурс] – Режим доступа: https://xakep.ru/2011/10/13/57058/Услуги и возможности в области ↑

51. НильсенЯ., БудиуР. Mobile Usability. Как создавать идеально удобные приложения для мобильных устройств. – М.: Эксмо, 2013. С.178 ↑

52. Приложения в Google Play – SplittPay подели чек с другом! [Электронный ресурс] URL: https://play.google.com/store/apps/details?id=com.github.rchugunov.splitpay&h l=ru ↑

53. Дейтел П., Дейтел Х., Уолд А. Android для разработчиков. 3-е из- дание. – СПб.: Издательство «Питер», 2016.С.318 ↑

54. MVP and MVC Architectures in Android. [Электронный ресурс] URL: https://www.techyourchance.com/mvp-mvc-android-1 ↑

55. Android Studio Features. [Электронный ресурс] URL: https://developer.android.com/studio/features.htm ↑

56. MDM и BYOD – смешать, но не взбалтывать [Электронный ресурс] – Режим доступа: http://www.volgablob.ru/ blog/?p=101 ↑

57. Градусов Д.А., Зайцева О.А. Методики выбора устройств для тестирования мобильных приложений // Инновации в науке: сб. ст. по матер. LVII междунар. науч.-практ. конф. № 5(54). Часть I. – Новосибирск: СибАК, 2016. – С. 52 ↑

58. Использование концепции BYOD и других компонентов [Электронный ресурс] – Режим доступа: http://h17007.www1.hp.com/ru/ru/ solutions/technology/BYOD/ ↑

59. Архитектура Android-приложений. Часть II – архитектурные стили и шаблоны. [Электронный ресурс] URL: https://habrahabr.ru/post/140655 ↑

60. MVP and MVC Architectures in Android. [Электронный ресурс] URL: https://www.techyourchance.com/mvp-mvc-android-1 ↑

61. Appery.io: Enterprise Mobile App Builder & MBaaS. [Электронный ресурс] URL: https://appery.io/ ↑

62. Использование концепции BYOD и других компонентов [Электронный ресурс] – Режим доступа: http://h17007.www1.hp.com/ru/ru/ solutions/technology/BYOD/ ↑

63. Приложения в Google Play – SplittPay подели чек с другом! [Электронный ресурс] URL: https://play.google.com/store/apps/details?id=com.github.rchugunov.splitpay&h l=ru ↑

64. Использование концепции BYOD и других компонентов [Электронный ресурс] – Режим доступа: http://h17007.www1.hp.com/ru/ru/ solutions/technology/BYOD/ ↑

65. Корпоративная мобильность Bring Your Own Device – BYOD [Электронный ресурс] – Режим доступа: http://www.tadviser.ru/index.php/ (Bring_Your_Own_Device_-_BYOD) ↑

66. Основы создания приложений. [Электронный ресурс] URL: https://developer.android.com/guide/components/fundamentals.html. ↑

67. Мобильная безопасность: Защита мобильных устройств в корпоративной среде [Электронный ресурс] – Режим доступа: https://xakep.ru/2011/10/13/57058/Услуги и возможности в области ↑

68. Приложения в Google Play – SplittPay подели чек с другом! [Электронный ресурс] URL: https://play.google.com/store/apps/details?id=com.github.rchugunov.splitpay&h l=ru ↑

69. Нахавандипур, В. iOS. Разработка приложений для iPhone, iPad и iPod / В. Нахавандипур. - СПб.: Питер, 2013. С.287 ↑

70. Использование концепции BYOD и других компонентов [Электронный ресурс] – Режим доступа: http://h17007.www1.hp.com/ru/ru/ solutions/technology/BYOD/ ↑

71. MVP and MVC Architectures in Android. [Электронный ресурс] URL: https://www.techyourchance.com/mvp-mvc-android-1 ↑

72. Использование концепции BYOD и других компонентов [Электронный ресурс] – Режим доступа: http://h17007.www1.hp.com/ru/ru/ solutions/technology/BYOD/ ↑

73. Машнин, Т.С. Google App Engine Java и Google Web Toolkit: разработка Web-приложений / Т.С. Машнин. - СПб.: BHV, 2014.С.281 ↑

74. Мобильная безопасность: Защита мобильных устройств в корпоративной среде [Электронный ресурс] – Режим доступа: https://xakep.ru/2011/10/13/57058/Услуги и возможности в области ↑

75. MVP and MVC Architectures in Android. [Электронный ресурс] URL: https://www.techyourchance.com/mvp-mvc-android-1 ↑

76. Корпоративная мобильность Bring Your Own Device – BYOD [Электронный ресурс] – Режим доступа: http://www.tadviser.ru/index.php/ (Bring_Your_Own_Device_-_BYOD) ↑

77. Приложения в Google Play – SplittPay подели чек с другом! [Электронный ресурс] URL: https://play.google.com/store/apps/details?id=com.github.rchugunov.splitpay&h l=ru ↑

78. Приложения в Google Play – SplittPay подели чек с другом! [Электронный ресурс] URL: https://play.google.com/store/apps/details?id=com.github.rchugunov.splitpay&h l=ru ↑

79. Машнин, Т.С. Google App Engine Java и Google Web Toolkit: разработка Web-приложений / Т.С. Машнин. - СПб.: BHV, 2014.С.269 ↑

80. Экспозито, Д. Разработка веб-приложений с использованием ASP.NET и AJAX / Д. Экспозито. - СПб.: Питер, 2012. С.312 ↑

81. Дейтел П., Дейтел Х., Уолд А. Android для разработчиков. 3-е из- дание. – СПб.: Издательство «Питер», 2016.С.219 ↑

82. НильсенЯ., БудиуР. Mobile Usability. Как создавать идеально удобные приложения для мобильных устройств. – М.: Эксмо, 2013.С.193 ↑

83. Приложения в Google Play – SplittPay подели чек с другом! [Элек- тронный ресурс] URL: https://play.google.com/store/apps/details?id=com.github.rchugunov.splitpay&h l=ru ↑