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

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

Содержание:

ВВЕДЕНИЕ

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

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

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

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

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

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

- рассмотреть этапы разработки мобильных приложений,

- исследовать какие тестирования для мобильных приложений,

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

-разработать жизненный цикл мобильного приложения.

При написании работы использовались следующие методы исследования: анализ, сравнение, обобщение.

Теоретическую и информационную базу исследования составляют работы российских программистов и разработчиков, таких как Ахметов А.К., Вегнер А.И., Дейтел П., Зонин Н.А., Карпюк И.А. и др., материалы периодической печати, ресурсы сети Internet.

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

Этапы разработки мобильных приложений

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

Прежде всего, необходимо определить само понятие «мобильное приложение». «Мобильное приложение» — это специально разработанное приложение под конкретную мобильную платформу (iOS, Android, Windows Phone). Многие мобильные приложения предустановлены на самом устройстве или могут быть загружены на него из онлайновых магазинов приложений, таких как App Store, Google play market, Windows Phone Store, Яндекс.store — и других, бесплатно или за плату. Распространяющиеся мобильные приложения призваны облегчить жизнь пользователей мобильных устройств, а также ее разнообразить [7].

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

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

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

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

Наибольшее количество мобильных приложений сегодня ориентированы на сегмент b2c, в то время как b2b-приложения только начинают осваивать рынок. Однако, потенциал роста данного сегмента специалисты оценивают очень высоко [3].

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

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

2 этап. На практике существует три типа мобильных приложений.

  • Мобильные сайты, веб-приложения;
  • Гибридные приложения;
  • Нативные приложения.

Первый тип (Мобильные сайты, веб-приложения) самый распространенный тип приложений для мобильных устройств. Современные смартфоны в состоянии отобразить обычный сайт. Им доступно все то, что мы привыкли видеть в десктопных приложениях — поддержка HTML5 делает свое дело. Заметим, что веб-приложения отлично подходят для стартапа: именно они позволяют получить большой результат за маленькие деньги и за небольшой срок. Еще один плюс мобильного сайта по сравнению с другими мобильными приложениями – это кроссплатформенность. Однако есть и минус, притом весомый: с ними достаточно сложно заработать.

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

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

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

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

Виртуальная и дополненная реальность. Разработка новых устройств для виртуальной и дополненной реальности окажут очень серьезное влияние на развитие приложений в этих сегментах. Наибольший интерес здесь прогнозируется в категории игровых приложений. Однако, развиваться будут также и такие направления, как, например, СМИ.

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

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

Прототип обладает чудесным свойством устранять недопонимания между различными специалистами (менеджер, руководитель, дизайнер, программист, клиент), вовлеченными в проект, структурировать мысли и предотвращать ошибки и выполнение лишней работы еще на ранних стадиях разработки. Можно тестировать будущее приложение, используя фокус-группу, это поможет получить полезную информацию от будущих пользователей.
В ритме сегодняшней жизни при достаточно высокой цене человеко-часов, очень важно работать быстро и, желательно, без потери качества. Для этого было введено понятие “быстрое прототипирование”. Что поможет перейти от простого прототипа к быстрому? Это развивающиеся технологии, наличие огромного количества сервисов и, конечно, собственные мозги. Используем прототипы, которые мы вешаем на доску и стрелочками показываем, как будет происходит навигация (Рисунок 2).


Рисунок 2. Пример использования прототипов

При разработке дизайна обязательно используются гайдлайны.
Гайдлайн в общем понимании – это документ, который выпускает компания, и по которому дизайнеры и разработчики понимают принцип построения взаимодействия приложения с пользователем. Условно говоря, для iOS кнопки надо делать круглыми, а для Windows Phone – квадратными [9].

Однако мы используем и внутренние гайдлайны для разработчиков. Таким образом результат работы дизайнера чаще всего состоит из макетов, гайдлайнов и нарезки графики. Макеты лучше всего подавать «перелинкованными», например с помощью ProtoTypr, чтобы была понятна логика переходов. Гайдлайны содержат в себе информацию об отступах, размерах, визуальных эффектах, механике анимации и пр. Этот этап можно пропустить, если в вашем проекте один дизайнер и один разработчик, сидящие рядом друг с другом. Третья часть результата — нарезка графики — должна содержать минимум необходимых графических ресурсов (заботимся о весе приложения), иметь версии для разных разрешений экранов. Чаще всего есть риск для ретины и xhdpi-экранов. Далее идет подготовка для неретины и mdpi автоматизированными средствами (если допустимо их использование). Чаще всего руками приходится готовить hdpi-ресурсы.

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

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

Тестирование мобильных приложений

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

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

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

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

Тестировать приложение не должны его же разработчики.

Тип тестирования выбирают исходя из проверяемой характеристики приложения:

  • Функционал – должен соответствовать заявленному. Хорошо, если у подрядчика есть QA-команда, а у неё – план тестирования со списком всех функций приложения и его желаемым поведением. Но если таковой нет – необходимо позаботиться об этом и нанять специально обученных специалистов. Юзабилити – интерфейс мобильного приложения должен быть интуитивно понятным и дружелюбным. О проблемах с этими качествами вам лучше всего расскажут те, кто видят продукт впервые.
  • Производительность – никто не будет пользоваться приложением, которое грузит рабочий экран больше 10 секунд. И хотя производительность обычно тестируют на более поздних стадиях разработки, следить за временем отклика надо уже сейчас.
  • Дизайн – тут дизайнерам придётся ещё раз включиться в работу и удостовериться в том, что каждая деталь визуального стиля была реализована разработчиками в соответствии со стайлгайдом. Кстати, это ещё одна веская причина работать с компаниями, которые занимаются и разработкой, и дизайном.

Но и это ещё не всё:

  • Регрессионное тестирование – используется для проверки уже протестированного кода на ошибки, исправленные ранее, или возникшие в результате этих исправлений. Здесь на помощь вновь приходит QA-команда с чек-листами изменений, внесённых в код на каждом из спринтов.
  • Тестирование под платформу – существует бесчисленное количество комбинаций мобильных устройств и установленных на них операционных систем. Посмотрите, как приложение работает на смартфонах с разными размерами и разрешениями экранов, и запустите его на всевозможных версиях ОС [23] .

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

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

Тестирование обновлений – частые обновления операционной системы (относительно десктопов) приводят к необходимости обновлять приложение. Обновление должно проходить просто и не требовать от пользователя специфических знаний. Следует так же проверять различные возможные пути установки приложения (Wi-Fi, 3G, установка с ПК, на SD) [15].

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

Тестирование удобства пользования (usability). Этот вид тестирования является одним из важных, так как в условиях высокой конкуренции юзабилити приложения входит в список основных параметров, влияющих на популярность продукта. Позволяет выявить части приложения, которые недостаточно привлекательны или вызывают затруднения в навигации или использовании на сенсорных экранах. Следует так же убедиться, что модель потребления ресурсов приложением соответствует целевой аудитории. Например, приложения-напоминания не должны вызывать чрезмерное потребление энергии. Зачастую это тестирование проводится в виде бета-тестирования [23] .

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

Случайное тестирование (fuzzy testing, “monkey” testing) – приложение должно корректно реагировать на возникновение случайных и непредсказуемых событий. Мобильные устройства чаще других попадают в условия, в которых получают хаотичную бесполезную информацию (например, незаблокированный девайс в кармане), потому приложение должно адекватно реагировать на подобные потоки данных.

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

Лабораторное тестирование – имитация реальных условий качества связи и окружающей среды. Обычно неочевидно, как поведёт себя приложение, например, при нестабильном сигнале Wi-Fi или с нулевым балансом на счету в сети 3G. Данный вид тестирования позволяет проверить подобные случаи [23].

Аттестационное тестирование используется для подтверждения соответствия приложения стандартам, лицензионным соглашениям и условиям использования, например Android:

  • Установочный файл приложения (.apk) должен быть согласован с Program Policies .
  • В случае публикации обновлённой сборки желательно придерживаться порядка управления версиями (например, принятого порядка нумерации версий).
  • Приложение не должно противоречить документу UIG .

Так же для отдельных магазинов приложений (Amazon App Store, Samsung Apps, Yandex.Store и подобных) могут существовать свои собственные требования и гайдлайны [26].

Аттестационное тестирование используется для подтверждения соответствия приложения стандартам, лицензионным соглашениям и условиям использования, например iPhone:

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

Аттестационное тестирование используется для подтверждения соответствия приложения стандартам, лицензионным соглашениям и условиям использования, например Windows 7-8 Приложение должно соответствовать всем категориям app certification requirements.

Перечень моментов, которые должны быть протестированы:

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

  • Все элементы должны быть такого размера, чтобы пользователь мог однозначно попасть по ним.
  • Отсутствие пустых экранов в приложении – пользователь не должен оказываться в ситуации, в которой не очевидно, что сейчас происходит и что делать.
  • Следует проверять многократное быстрое нажатие на кнопку – часто при этом может случиться падение приложения. Так же следует проверять мультитач – нажатие на несколько кнопок одновременно.
  • Следует проверять наличие или отсутствие «нативных» жестов (pinch-to-zoom, doubletap) – если, например, поддерживается зум части приложения, то должен использоваться жест по умолчанию. А если нет необходимости выделять картинку, то по даблтапу она не должна выделяться.

2. Ресурсы устройства:

  • Утечки памяти. Особенно может проявляться на окнах, с большим количеством информации (длинные списки как пример), во время задач с длительным workflow (когда пользователь долго не выходит из приложения), при некорректно работающем кэшировании изображений.
  • Обработка ситуаций нехватки памяти для функционирования ОС, когда приложение активно или работает в фоне.
  • Недостаток места для установки или работы приложения.
  • Отсутствие в некоторых устройствах поддерживаемых приложением функций (3G, SD-карта и т. п.).
  • Установка или перенос приложения на карту SD.

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

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

4. Реакция приложения на внешние прерывания

  • Входящие и исходящие SMS, MMS, звонки, оповещения других приложений.
  • Выключение устройства, изъятие аккумулятора, разрядка устройства.
  • Переход в режим ожидания (в том числе и с защитой паролем). Смена ориентации устройства в режиме ожидания.
  • Отключение и подключение провода.
  • Отключение и включение сети, Bluetooth, авиарежима, GPS.
  • Потеря связи с сервером или прокси (подключение есть, но пакеты не доходят).
  • Отключение и подключение SD-карты, дополнительных устройств вроде физической клавиатуры или гарнитуры.
  • Зарядка устройства.
  • Работа с акселерометром.
  • Работа с физической клавиатурой (если в списке поддерживаемых моделей есть такие).

5. Платный контент внутри приложения:

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

6. Интернационализация (проверять и в портретном, и в ландшафтном режиме!):

  • Проверка корректности перевода.
  • Проверка того, что все надписи входят в соответствующие формы, кнопки и т.п.
  • Проверка форматов дат, разделителей в числах, специфических особенностей локализации (вроде пробела перед знаком вопроса во французской, верхних индексов “o” и “a” в порядковых числительных в испанской и других нетривиальных моментов).

7. Постоянная обратная связь с пользователем:

  • У всех нажимаемых элементов должно быть нажатое состояние (отклик на действие) – благодаря этому пользователь всегда будет видеть, действительно ли нажатие случилось. В Android-приложениях у элементов может быть ещё одно состояние – focused.
  • Реакция кнопок на нажатие. Скорость отклика элементов должна быть достаточно высокой. Желательно использовать для проверки этого пункта самые слабые устройства среди поддерживаемых.
  • Сообщения при загрузке контента или прогресс-бар.
  • Сообщения при ошибке доступа к сети, BT, GPS.
  • Наличие понятных сообщений при попытке удалить важную информацию.
  • Наличие экрана или сообщения при окончании процесса или игры.
  • Наличие и синхронность звуков или вибрации с уведомлениями и другими событиями на экране.

8. Обновления:

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

Различные версии ОС могут использовать отличные соглашения и правила (интерпретация жестов, правила навигации). Следует учитывать это при поддержке приложением нескольких версий ОС [23].

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

Мобильные устройства работают от аккумуляторов, и потому вынуждены автоматически переходить в режим ожидания спустя пару минут бездействия. Это значит, что вам придётся включать телефон перед каждым тестированием, что при одновременном тестировании нескольких телефонов, занимает приличное количество времени. Конечно, на многих устройствах можно отключить автоматическую блокировку (или хотя бы сделать время отключения довольно большим), но желательно всё же работать с самыми распространёнными среди пользователей настройками ОС.

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

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

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

Для тестирования GPS придётся вооружиться дополнительным инструментарием от энтузиастов и надеяться, что он работает достаточно похоже на реальные условия.

Для проверки слабого или отсутствующего Wi-Fi и 3G-сигнала обычно приходится либо сооружать лабораторию, либо использовать различные хитрости вроде коробочек из фольги.

Создание скриншотов и видео на мобильных устройствах так же зачастую нетривиальная работа, особенно если тестируется телефон, отключенный от компьютера по условиям теста или по каким-то иным причинам. Например, встроенная возможность снятия скриншота экрана на Android-устройствах появилась сравнительно недавно – с четвёртой версии. А про бесплатный способ снимать видеопоток с экрана Apple-устройства без jailbreak вообще мало кто может сказать что-то вразумительное.

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

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

Перед тем, как представить своё мобильное приложение миру, нужно позаботится о двух вещах: надёжном API-сервере и соблюдении правил Google Play Store и Apple App Store.


Рисунок 3. Внедрение на рынок

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

Публикация приложения в Google Play Store и Apple App Store – трудоёмкий процесс. Придётся убедиться в том, что приложение отвечает требованиям магазина, заполнить несколько форм для каждого из них, подготовить скриншоты и маркетинговые материалы, составить текст описания… а Apple ещё и тщательно в течение нескольких дней будет проверять само приложение и даже может не только потребовать изменений, но и отказать в публикации из-за “бессмысленности” приложения. Нет, я не исключаю вероятность того, что магазин примет приложение без лишних вопросов, и через несколько дней оно будет доступно для скачивания. Просто могут возникнуть возможные трудности, которые появятся с вероятностью в 99% [5].

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

Рисунок 4. Мониторинг

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

Современные системы аналитики мобильных приложений собирают информацию об аудитории приложения (распределение пользователей по полу, возрасту, местонахождению, языку и т.д.) и особенностях взаимодействия с ним (времени входа в приложение, времени, проведённом в приложении, количестве просмотренных экранов и пр.). Некоторые даже составляют тепловые карты, которые показывают, на какие кнопки пользователи нажимают чаще остальных. Используются эти данные как ориентиры на будущее: вкладывайтесь в доработку тех областей, в которых концентрация действий аудитории наиболее высока. Могут быть использованы такие инструменты как: Firebase, Яндекс.Метрика, Facebook Analytics, Apptentive, Google Analytics и Appsee.

Этот показатель нельзя измерить двумя предыдущими способами, но следить за ним необходимо. Как часто происходило то или иное действие и как долго оно длилось – вот вопросы, которые помогут оптимизировать работу приложения. Если простейшее действие занимает больше времени, чем ожидалось, это тревожный сигнал. Может быть использован такой инструмент как: Prometheus.

Оценки и отзывы в магазинах крайне важны, особенно для новых приложений. Всегда отвечайте комментаторам: благодарите за хорошие слова и постарайтесь помочь тем, кто столкнулся с трудностями при использовании вашего приложения. Комментаторы обычно не ожидают, что им ответят реальные разработчики. Чуть больше клиентоориентированности – и две звезды превращаются в пять, а ваша репутация взлетает до небес [8].

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

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

Разработка жизненного цикла мобильного приложения

Мобильное приложение будет называться "Вегаритариум". Цель и назначение мобильного приложения — предоставить справочную информацию о компонентах, которые могут быть использованы в товарах следующих категорий: продукты питания, одежда, косметика. Получение данной информации заинтересованными пользователями сделает процесс приобретения ими товаров еще более осмысленным и простым. Мобильное приложение с оффлайн-доступом к данным, содержащимся в нем — оптимальный вариант. Смартфон всегда под рукой, а значит, не нужно держать в голове кучу информации, относительно каких-либо компонентов сомнительного происхождения.

Первый этап проектирования, который предусматривается техническим заданием — это эскизный проект. Он включает в себя создание визуальных отображений: чертежей, графиков, планов и рисунков объекта, которые дают возможность увидеть общую концепцию будущего проекта. Рисование эскизов кажется простым делом, но это лишь на первый взгляд. Довольно сложно конвертировать мысли сразу в рабочее приложение или любой другой готовый продукт. При возникновении проблем на поздних этапах проекта, их исправление требует больших ресурсов, чем правки на начальных этапах. Поэтому важно соблюдать всю поэтапность реализации проекта. Концепция проекта должна четко отражать, как идея будет визуализирована в пользовательском интерфейсе. Как раз для этого и нужны эскизы. Все начинается с идеи, которую нужно перевести в пользовательский интерфейс. Недостаточно просто решить, что есть необходимость в разработке приложения, которое выполняет определенные функции. Необходимо знать, что пользователь увидит на каждом экране приложения, и что ему понадобиться сделать, что бы получить результат от выполнения заданных функций. На этапе создания эскиза возможно наглядно рассмотреть различные замыслы, прежде чем реализовывать итоговый вариант [17]. Перед тем как приступать к созданию макетов, было выполнено эскизирование приложения. Создание эскизов позволяет представить, как будет выглядеть веб-сайт, разработать удобство пользования им, продумать расположение элементов сайта. Эскизы экранов приложения представлены на рисунке 5.

Рисунок 5. Эскизы экранов приложения

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

Рисунок 6. Эскизы основной иконки

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

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

Таблица 1. Использование цвета.

Шестнадцатиричный код цвета

Визуальное представление

#6d986a

#bb6a00

#a50000

#efefef

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

Рисунок 7. Графические элементы приложения

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

Рисунок 8. Основная иконка приложения

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

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

Рисунок 9. Макет раздела «Пищевые добавки»

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

Рисунок 10. Макет раздела «Ингредиенты в косметике»

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

Рисунок 11. Макет экрана с информацией о компоненте

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

Для реализации данного способа необходимо собранную информацию преобразовать в файлы формата json. JSON (англ. JavaScript Object Notation) — текстовый формат обмена данными, основанный на JavaScript и обычно используемый именно с этим языком. В Android есть готовые классы для работы с JSON: JSONObject, JSONArray, JSONWriter, JSONStringer и т. д. Теперь перейдем к работе с анимацией в приложении и навигацией по нему. По задумке переход от одного раздела приложения к другому должен осуществляться с анимацией перелистывания из стороны в сторону по свайпу. Для реализации данного решения необходимо было подключить библиотеку Android Support Package. Использовать эту библиотеку можно для версий Android 1.6 и старше. Конкретно для данной задачи понадобятся классы ViewPager и PagerAdapter. ViewPager использует PagerAdapter, который создает компоненты View и заполняет их переданными данными. Для этого также необходимо наследовать класс от PagerAdapter и реализовать в нем некоторые методы. Добавление и удаление экранов реализуется с помощью методов instantiateItem() и destroyItem() соответственно. View для отображения можно создавать прямо в адаптере. Такой подход хорош тем, что ViewPager можно настраивать так, чтобы в адаптере не хранились все экраны сразу. По умолчанию адаптер хранит текущий экран, и по одному слева и справа от него. Это может сэкономить память, если содержание экранов слишком сложное. Для отображения нижнего меню необходимо подключить библиотеку Android Design Support Library. В ней нам нужен такой компонент, как BottomNavigationView. Это нижняя панель навигации, позволяющая переключаться между экранами приложения в одно касание, она предназначена в основном для смартфонов, поскольку расположение в нижней части экрана обеспечивает удобный и быстрый доступ для пользователя. Компоненту BottomNavigationView присваиваем «слушатель», который определяет нажатие на пункты панели по идентификаторам и прописываем нужные действия в конструкции switch. Слушатель (Listener) — это уведомляемый о некотором событии объект. Чтобы слушатель смог реагировать на определенное со- 45 бытие источника он должен быть им зарегистрирован, т.е. подключен к источнику. Listener должен реализовывать определенные методы для получения и обработки уведомлений о событии.

Приведем ряд основных моментов, которые нужно протестировать:

• установка и запуск приложения;

• выход из приложения; повторный вход;

• удаление приложения с мобильного устройства;

• мультитач и размер экрана.

Корректность удаления 2-х элементов или просмотр двух элементов, нажатием на них одновременно.

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

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

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

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

Стресс. Реакция приложения на внешние прерывания:

1. Входящие и исходящие SMS, MMS, звонки, оповещения других приложений.

2. Переход устройства в режим ожидания.

3. Выключение устройства, разрядка устройства.

4. Зарядка устройства.

5. Отключение интернета.

6. Переход в другое приложение.

7. Интернационализация. Проверка корректности работы приложения на разных языках (если данное приложение мультиязычное).

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

9. Корректность обновления приложения до новой версии.

10. Орфографические ошибки. Как показывает практика тестирования мобильных приложений, наиболее корректной работы приложения можно добиться при ручном тестировании на реальных мобильных устройствах [23].

Производительность приложения. Обработка любой операции на стороне клиента не должна превышать 2-х секунд. Предпочтительное время для простых операций — 0,7 секунды.

Потребление ресурсов — память. Для сложных действий (выборка больших массивов данных или сложная фильтрация по критериям) — до 1 секунды.

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

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

Операционное окружение. Приложение должно обеспечивать совместимость с операционными системами Android версии 4.0+. Повороты не 48 поддерживаются. Использование другого программного обеспечения (аналогов) допустимо, но при этом возможны отказы системы в обработке данных.

К моменту завершения работы над сервисом, можно привести следующую статистику по калькуляции проекта:

1. Проведен анализ 3 уже существующих аналогичных разработок.

2. Проанализировано более 300 и собрано около 150 компонентов для наполнения справочника информацией.

3. Создано более 10 эскизов интерфейса мобильного приложения.

4. Создано более 20 макетов мобильного приложения.

5. Разработано более 5 логотипов для справочника.

6. Разработано более 10 элементов дизайна сервиса.

7. Написано более 500 строчек кода для мобильного приложения.

ЗАКЛЮЧЕНИЕ

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

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

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Актуальная тема: Психология восприятия цвета [Электронный ресурс]. — Режим доступа: https://psynavigator.ru/publikacii/aktualnaya-temapsihologiya-vospriyatiya-cveta (дата обращения: 08.04.2020).

2. Ахметов А. К. Операционная система Android. Разработка приложений для платформы Android [Электронный ресурс]. — Режим доступа: https://cyberleninka.ru/article/n/operatsionnayasistema-android-istoriya-sozdaniya-i-razvitiya-razrabotka-prilozheniy-dlya-plat formy-android (дата обращения: 07.04.2020).

3. Вегнер А. И. Технологии разработки мобильных приложений. Плюсы и минусы разработки с помощью платформы Phonegap [Электронный ресурс]. — Режим доступа: https://core.ac.uk/download/pdf/80134923.pdf (дата обращения: 06.04.2020).

4. Гордеев А.В., Молчанов А.Ю. Системное программное обеспечение - Питер, 2011.– 213 с.

5. ГофманВ.Э., ХомоненкоА.Д. Delphi. Быстрый старт. - СПб.: БХВ-Петербург, 2012.– 201 с.

6. Дейтел П. Android для разработчиков [Текст] / П. Дейтель, Х. Дейтель, А. Уолд. — Санкт-Петербург: Питер, 2016. — 512 с. 7. Детальный анализ Android [Электронный ресурс]. — Режим доступа: https://xakep.ru/2014/07/03/art-vm/ (дата обращения: 04.04.2020).

7. Зонин Н. А. Рынок мобильных приложений Калининградской области [Текст] / Н. А. Зонин, М. А. Терре // Вопросы экономики и управления. — 2016. — №3.1. — С. 101–104.

8. Карпюк И. А. Сравнительный анализ мобильных приложений и инструментальных средств их разработки // Научно-методический электронный журнал «Концепт». — 2017. — Т. 31. — С. 826–830 [Электронный ресурс] / 52 И. А. Карпюк, Н. М. Куляшова. — Режим доступа: http://e-koncept.ru /2017/970180.htm (дата обращения: 04.04.2020).

9. Ким В. Ю. Особенности разработки дизайна пользовательского интерфейса для мобильного приложения [Текст] / В. Ю. Ким // Новые информационные технологии в автоматизированных системах. — 2015. — № 18. — С. 479–481.

10. Маклафлин Б. Объектно-ориентированный анализ и проектирование [Текст] / Б. Маклафлин. — Санкт-Петербург: Питер, 2013. — 608 с.

11. Непейвода Н.Н., Скопин И.Н. Основания программирования-Институт компьютерных исследований, 2013. – 192 с.

12. Нимейер П. Программирование на Java [Текст] / П. Нимейер, Д. Леук. — Москва: Эксмо, 2014. — 1216 с.

13. Норман Д. Дизайн привычных вещей [Текст] / Д. Норман. — Москва: Манн, Иванов и Фербер, 2013. — 272 с.

14. Одним словом. Нейминг для мобильных приложений [Электронный ресурс]. — Режим доступа: https://geekbrains.ru/posts/mob_naming (дата обращения: 07.04.2020).

15. Окулов С. Основы программирования - Бином. Лаборатория знаний, 2015. – 180 с.

16. Потопахин В. Искусство алгоритмизации [Текст] / В. Потопахин. — Москва: ДМК Пресс, 2014. — 320 с.

17. Применение средств дизайн-проектирования на занятиях по технологическому практикуму [Электронный ресурс]. — Режим доступа: https://elibrary.ru/item.asp?id=27176414 (дата обращения: 07.04.2020).

18. Разработка Android приложений [Электронный ресурс]. — Режим доступа: http://studbooks.net/2139366/informatika/printsip_rabotyandroid_and roid_prilozheniy (дата обращения: 08.04.2020).

19. Россияне попробуют Nemoloko в 2018 году [Электронный ресурс]. — Режим доступа: https://www.retail.ru/news/147481/ (дата обращения: 06.04.2020).

21. СанПиН 2.3.2.1293–03 Гигиенические требования по применению пищевых добавок [Электронный ресурс]. — Введ. 18.04.2003. — Режим доступа: http://docs.cntd.ru/document/901862338 (дата обращения: 05.04.2020).

22. Сидора А. А. Способы хранения данных в приложениях Android os [Текст] А. А. Сидора // Решетневские чтения. — 2015. — № 19. — С. 248–250.

23. Тестирование Android приложений [Электронный ресурс]. — Режим доступа: http://getbug.ru/testirovaniya-android-prilozheniy/ (дата обращения: 07.04.2020).

25. Форум Regard [Электронный ресурс]. — Режим доступа: https://www.ixbt.com/news/2018/02/24/ios-android-99-9.html (дата обращения: 07.04.2020).

26. Что такое файл apk, чем открыть его и как с ним работать [Электронный ресурс]. — Режим доступа: http://fb.ru/article/163321/chto-takoe-faylapk-chem-otkryit-ego-i-kak-s-nim-rabotat (дата обращения: 08.04.2020).

27. Android от А до Я: Что такое Dalvik [Электронный ресурс]. — Режим доступа: http://droidtune.com/2056/android-ot-a-do-ya-chto-takoe-dalvik .html (дата обращения: 08.04.2020).