Преподаватель который помогает студентам и школьникам в учёбе.

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

Содержание:

ВВЕДЕНИЕ

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

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

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

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

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

- изучить теоретические основы мобильных приложений;

- разработать мобильное приложение для Android.

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

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

1.1 Основы разработки приложений для ОС Android

Операционная система Android – это открытая платформа, а значит, что она не привязана к одному провайдеру. Это помогает Android завоевать рынок, так как любой производитель и провайдер может создавать и продавать устройства, поддерживающие эту операционную систему. Исходный код Android доступен каждому для изучения или модифицирования. Это позволяет дать широкий простор для создания удобных интерфейсов и приложений для Android-устройств [1].

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

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

Android приложение пишется на языке Java, однако при разработке необходимы также документы XML. Язык Java используется здесь не в полнофункциональном варианте, а только в небольшом подмножестве, которое иногда называют виртуальной машиной Davlik. В этом подмножестве не используются те классы Java, которые не могут быть применены или не имеют смысла при разработке приложений на мобильные устройства.

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

Намерения (intents) составляют систему сообщений на Android. Намерение состоит из действия (action), которое необходимо выполнить (посмотреть, редактировать и др.) и данных. Действие – это то, что должно быть совершено при получении намерения и данных, с которыми необходимо оперировать.

Намерения используются при запуске деятельности и при коммуникации между различными частями Android системы. Приложение может получать или отправлять намерения.

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

Если просто отправить намерение, это не означает, что что-то произойдет автоматически. Для этого необходимо зарегистрировать приемник намерений (intent receiver), который получает намерение и указывает Android системе, что нужно сделать: выполнить задачу в новой деятельности или запустить другое приложение. Если же имеется несколько приемников для получения intent, можно создать инструмент, позволяющий пользователю самому выбрать необходимое действие. Одним намерением могут быть найдены несколько приемников, поэтому пользователь лично определяет action, которое нужно выполнить. Например, при долгом нажатии на изображение в галерее, появляется инструмент выбора, который предлагает отправить картинку через e-mail или социальные сети, редактировать или удалить и др.

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

Виджеты и видовые окна.

Видовое окно (view) представляет собой базовый элемент управления интерфейса в виде прямоугольной области, где можно рисовать и обрабатывать события. Примерами видовых окон являются: контекстное меню (ContextMenu), меню (Menu), вид (View), поверхность рисования (SurfaceView).

Виджеты (widgets) – это более продвинутые элементы пользовательского интерфейса, например, флажки с переключателями, где можно выбрать одно из нескольких возможных состояний. Виджеты являются теми элементами управления, с которыми взаимодействует пользователь. Виджетами являются: кнопка (Button), выбор даты (DatePicker), галерея (Gallery), флажок (CheckBox) и др.

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

Ассинхронные вызовы.

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

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

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

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

Фоновые службы.

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

Архитектура Android приложения.

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

Деятельности состоят из видовых окон (View). Общую структуру стандартного Android приложения можно представить в виде схемы (рисунок 1).

Рисунок 1 – Структура Android приложения

1.2 Основы программного обеспечения для устройств

Тесты существенно по задачам, которые с их решаются, и по используемой . Различие тестирования приводит, образом, к необходимости весьма разнообразные (виды) . Принято подразделять на виды по следующим [3]:

по объектам (элементам) , часто на виды тестов по критерию называют тестирования на уровни;

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

Тем не , основная классификация на виды производится в с традиционными качества, которые с их помощью [4].

Уровни :

Модульное тестирование ( или Unit-):

Входные требования – компонентов или модель « уровня» системы ( Design или Low Design).

Объект – разработанные компоненты.

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

тестирование (Сборочное , integration или interface testing) [6]:

требования – Архитектура или модель «верхнего » системы ( Design или High Design).

Объект – собранная из компонентов или подсистема.

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

Комплексное тестирование не на проверку каждого из компонентов, а на взаимодействия компонентов в с «Архитектурой системы».

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

тестирование ( testing):

Входные – системные спецификации ( Specification).

Объект – разработанная .

Определение: после , как система собрана из компонентов, она должна протестирована на «Системным спецификациям» – ли все функциональные и нефункциональные к разрабатываемой системе.

На уровне приложение или система ( или более приложений) .

Приемочное тестирование ( тестирование или testing):

Входные – требования (requirements).

тестирования – разработанная .

Определение: на уровне завершенное (система) тестируется заказчиком, конечными пользователями или уполномоченными с определения соответствия «Требованиям Заказчика» и системы к внедрению. испытания процесс передачи от Разработчика Заказчику. В от особенностей продукта и от Заказчика они проводиться в различной . Например, в виде альфа- или [10].

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

Бета - тестирование, этапом программного обеспечения альфа-тестирования. Программное в стадии бета - также как betaware [27]. Бета - обычно начинается, программное обеспечение законченным продуктом, но , , содержит ряд известных или ошибок [27]. Программное в фазе бета - , как правило, гораздо больше , чем в законченном программном обеспечении, а также вопросы / производительности и может привести к или потери данных. В внимания бета - является воздействия на пользователей, включая юзабилити-тестирование. Процесс бета - тестирования до продукт бета - версией, и как , это первый раз, когда обеспечение доступно за и организации, над ним. Бета - версия обеспечения часто полезно для демонстрации и просмотров в организации и для потенциальных . Некоторые разработчики эту версию в качестве просмотра, версии, прототипа, просмотра, или ранний [28]. Некоторые программные хранятся в постоянной бета - , где новые возможности и постоянно добавляют к обеспечению без создания фирмы «» выпуска .

Приёмочное тестирование с системным тестированием, но со различием:

Системное проверяет, что система соответствует требованиям;

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

Операционное (Release Testing):

требования – Бизнес (Business Case или Model).

тестирования – Разработанная .

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

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

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

(Verification) – это процесс системы или её с целью определения ли результаты текущего разработки условиям, в начале этапа [21]. Т.е. выполняются ли цели, сроки, по разработке проекта, в начале фазы.

Валидация () – это определение соответствия, ПО ожиданиям и потребностям , требованиям к [21].

Основное разделение на виды по объектам , или, точнее, на уровни , было нами при определении модели. Уровни приведены выше. Для уровня могут использоваться виды тестирования, для из которых, в свою , могут различные типы испытаний [25].

2. Практическое и работа с VCS

2.1 мобильных приложений

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

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

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

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

анализирует требования на и противоречивость. В проекте исходные содержат противоречивую . Мы их решаем еще до начала . Так же в каждом требования неполны, что сложность в работе: не макетов второстепенных , ограничения на х ввода, отображения , поставленные кнопки не , и т.д. (Приложение 1). Неочевидны на макетах : анимации, кеширование и содержимого экранов, в нестандартных ситуациях [14].

требований с менеджером проекта, и дизайнерами.

После 2-3 , вся команда гораздо понимает , вспоминает забытый , фиксирует решения по вопросам.

В основном на этапе basecamp [8].

Когда стали полны и , тестировщик составляет -тесты и тесты, покрывающие данные.

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

Для и прогона тестов мы TFS. (Приложение 2).

Например, для Avocado на этом этапе написано 335 .

Первый шаг тестирования . Проект уходит в . (Приложение 3).

Если проекта галочку «для », тестировщикам, уходит о новой сборке для . Ее номер на мониторе в кабинете .

Красным отображаются выпущенные за последние , их нужно активнее, чем белые [20].

Без « монитора» (работает на ) часто тестировали сборки . А новая сборка с багами попадала . Теперь перед тестового достаточно взглянуть на , путаница разрешилась.

сборок программы быстрое и .

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

тестирование проводится завершения итерации , если не пойдет в релиз.

Для проводятся smoke-, чтобы понять ли смысл сборку.

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

Некорректно выполненные переоткрываются. Баги заносятся в TFS. К не UI обязательно логи со смартфона. К UI скриншоты с пометками что не так [2]. ( 5).

После этого функциональные этой итерации. были найдены , не покрытые тест-кейсами, новый .

Для андроид приложений monkey тесты.

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

0 -v 5000

По окончании ставится отметка « багов пройдено» в -сервере [13]. ( 3).

Если в процессе не было найдено b, critical и major (Приложение 7), то отметка «можно заказчику». Ни один не отсылается заказчику без отдела . (По согласованию с заказчиком высылаются билды с багами). Критичность определяется по . (Приложение 5). После тестирования M получает письмо-отчет. (Приложение 6).

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

тестирование проводится релизом.

Включает в себя быстрое , регрессионное , monkey-тестирование на 100 и тестирование обновлений.

тестирование прогон тест-кейсов по проекту.

не только за последнюю , но и за все предыдущие и общие кейсы по . Это занимает день - три на устройство в зависимости от .

Очень важный шаг — обновлений.

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

скачивает билд из , создает данные (логин, , транзакции учета ), обновляет приложение на сборку и , что все на месте [19].

Затем smoke-тест.

повторяется на 2-3 устройствах.

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

Релизный -тест мы проводим на 10 IOS и 80 устройствах при помощи Appthwack.

В конце тестирования, кроме , вручную составляется отчет. (Приложение 8).

уходит в только при 100% всех тест-кейсов.

2.5 внешних сервисов [10]

интеграцию с Analytics (URL: https://www.google.com/analytics), (URL: https://y.flurry.com) или системой заказчика непросто. , что в релиз сборки с нерабочим Analytics и никто не на это внимания.

Поэтому в порядке для сервисов создается аккаунт, и он проверяется при тестировании. Кроме , отправка фиксируется в логах, проверяются тестировщиками [11].

2.6 времени

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

2.7 Работа в VCS

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

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

Как бы мы не сделать окружения , конфигурационные файлы отличаться: тестовые и аккаунты, , ID, внешние веб-сервисы и .NET предлагает отличное поддержание конфигураций в виде: конфигов. «Из коробки» они только в веб-приложения. К трансформации достаточно добавить и в приложения.

Начинающие часто находятся в недоумении при трансформаций Web.config’а на машинах: в от App.config’ов они хранятся на приложения, а не в папке bin, при локальной сборке не происходит. применяются при публикации . Если нам действительно обойти это ограничение, создать Web.template.config и добавить на PostBuild приложения.

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

NET предоставляет 2 для версионирования

[assembly: AssemblyVersion(

[assembly: AssemblyFileVersion(

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

В ходе исследования использованы различные внедрения CI на основе для мобильных - Avocado (Приложение 11), выявлены следующие , протекающие с использованием CI. рассмотрены .

2.8 SSDT-проект

(URL: https://.microsoft.com/en-us/mt186501)

: процесс создания и БД напоминает то, как вы это бы с Management Studio, т.е. очень легко и . Правила формирования БД и лежат на программы, что позволяет освоить данную .

Минусы: сложность миграционных . Т.к. инкрементальные изменения сам проект, сохранность обеспечивается за счет и post--скриптов. Придется на наличие/отсутствие полей в БД или «» таблицу schema , уже реализованную в движках.

2.9 ECM7 Migrator

миграций с открытым м (URL: https://github.com/117/ecm7).

Плюсы: поддерживаются СУБД, если вас не устраивает, код открыт. поддерживается и новыми функциями. И, , самое важное, несколько ключей в одной данных. Это может очень полезно, ваше приложение и поддерживает в том или ином виде. плагин может свои миграции и при использовать БД
Минусы: нет особенностей Framework Migrations.

2.10 Framework Migrations

(: https://msdn.microsoft.com/en-us/library/591621 (v=vs.113).aspx)

: работает из коробки, создает миграции по Db-, понимает из консоли visual , миграции публикуются с стандартного Publish из Studio.

: зависит от Entity .

Нумерация Автоматизация приложения:

В 2012 система web-проектов была улучшена. В первую это касается профилей .Если мы ем приложение в azure, то можно просто с портала. В противном его нужно создать. (Приложение 9).

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

Выводы

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

Integration , которая направлена на качества тестирования, что всего благополучно на работе тестировщиков. Есть ряд и не очень приятных для работников, которые возникнуть.

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

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

Бывает, что при сборке тестовые могут теряться. тратить на их восстановление. Нужно сохранность данных.

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

СI позволило работать на качества тестирования, это всего сказывается на работе тестировщиков. Также отметить, что увеличивается тестирования, т.е. скорость без использования CI. При приложения Avocado происходил только полного багов приложения в текущей итерации, а после полной кода на сервере. Время и исправления багов от количества найденных , в данном этот процесс 32 часа. (Приложение 12). При CI, тестировщикам не нужно ждать публикации кода , это позволило работать с ним но. В конкретном случае это 15 часов.(13) Все это может свидетельствовать о том, что CI позволяет работать над приложением более и качественно.

ЗАКЛЮЧЕНИЕ

Доля мобильного интернета растет ежедневно [15]. Многие люди проводят по нескольку часов в день, играя в различные компьютерные игры, в особенности в то время, когда ничего другого сделать нельзя, например, по дороге на работу, учебу, в поезде и т.д. Регулярно выходят новые компьютерные игры для телефонов и других мобильных устройств. Скачивание мобильных приложений не требует долгого времени и специальных навыков, установка также проста и понятна. В рамках работы было разработано мобильное приложение для Android. Для достижения данной цели были решены следующие задачи: 1) осуществлена постановку задачи, выделены требования к приложению; 2) произведен обзор существующих решений для разделения чеков; 3) изучены современные средства разработки мобильных приложений для Android; 4) определены требования и спроектировано мобильное приложение; 5) реализовано и протестировано мобильное приложение. Все поставленные задачи были решены, цель достигнута. Разработанное приложение имеет перспективы дальнейшего развития. С учетом усложнения бизнес-процесса и ростом требований заказчика, возникает потребность в расширении функционала системы. Перспективы дальнейшего развития мобильного приложения могут быть следующими: 1) программа должна давать пользователю возможность сохранения новых позиций чека при ручном вводе; 2) программа должна выводить детализацию выбранных и невыбранных позиций чека; 3) программа должна проверять наличие скидки на отдельные позиции чека или на всю сумму чека; 4) программа должна применять скидку к товарам пользователя при ее наличии; 5) программа должна уметь экспортировать фото и имена пользователей из контактов устройства; 6) программа должна уметь рассылать распознанные позиции с помощью списка контактов устройства.

СПИСОК ЛИТЕРАТУРЫ

1. Android Studio Features. [Электронный ресурс] URL: https://developer.android.com/studio/features.html (дата обращения: 20.08.19).

2. Appery.io: Enterprise Mobile App Builder & MBaaS. [Электронный ресурс] URL: https://appery.io/ (дата обращения: 20.08.19).

3. Кулямин В. Компонентная архитектура среды для тестирования на основе моделей. Программирование. 2010. Т. 5.

4. Кулямин В. В. Тестирование на основе моделей, URL: http://panda.ispras.ru/~kuliamin/lectures-mbt/Lecture04.pdf. (дата обращения 05.04. 2016).

5. Fork of Tesseract Tools for Android. [Электронный ресурс] URL: https://github.com/rmtheis/tess-two/ (дата обращения: 20.08.19).

6. Салмре И. Конечный автомат для пользовательского интерфейса. Программирование мобильных устройств на платформе .NET Compact Framework. Москва, Санкт-Петербугр, Киев : Вильяме, 2006.

7. Introduction to Material Design. [Электронный ресурс] URL: https://material.google.com/ (дата обращения: 20.08.19).

8. Kaner, Falk, Nguyen. Testing Computer Software. – USA: Wiley Computer Publishing, 1999. – 42 с.

9. MVP and MVC Architectures in Android. [Электронный ресурс] URL: https://www.techyourchance.com/mvp-mvc-android-1/ (дата обращения: 20.08.19).

10. Филиппов В. А., Хатько E. E. Модели для мультизадачных пользовательских комплексов. Информационные, сетевые и телекомуникационные технологии. 2012 . Т. 4.

11. Арлоу Дж., Нейштадт А. UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование. 2-е издание. – М.: Издательство «Символ-Плюс», 2007. – 624 с.

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

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

14. Буч Г., Рамбо Дж., Джекобсон А. Язык UML. Руководство пользователя. – СПб.: Издательство «Питер», 2003. – 432 с.

15. ВЕДОМОСТИ – Интернет-аудитория России растет за счет мобильных устройств. [Электронный ресурс] URL: https://www.vedomosti.ru/technology/articles/2016/01/28/625779-internet-auditoriya-rossiirastet-schet-mobilnih-ustroistv/ (дата обращения: 20.08.19).

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

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

18. Операции. [Электронный ресурс] URL: https://developer.android.com/guide/components/activities.html (дата обращения: 20.08.19).

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

20. Приложения в Google Play – Clever Bill Splitter. [Электронный ресурс] URL: https://play.google.com/store/apps/details?id=com.cleverturtles.splitter&hl=ru (дата обращения: 20.08.19).

21. The Next Generation 1996 Lexicon A to Z". Next Generation. No. 15. Imagine Media. Alpha software generally barely runs and is missing major features like gameplay and complete levels. March 1996.

22. "The Next Generation 1996 Lexicon A to Z". Next Generation. No. 15. Imagine Media. March 1996. p. 30.

23. "Technology Preview a Scope". Red Hat. 2015.

24 IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004

25. Robinson Н. Graph Theory Techniques in Model-Based Testing. 1999.

Приложение 1

навигационная схема за три моря