Этапы разработки, тестирования и ввода

Содержание:

Введение

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

Мне помогали в написании курсовой работы источники с различных сайтов. Надежность источников подтверждается, что они находится не первый год на рынке. Например, компания CMS Magazine которая была основана в 2007 году. В компании было зарегистрировано более 4 500 вэб-студий, 650 SEO-компаний и 550 CMS.

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

Глава 1 Этапы разработки

Анализ требований.

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

Проектирование.

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

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

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

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

поиск критических участков проекта;

формирование окончательной архитектуры создаваемой системы;^[2]

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

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

определение основных требований к безопасности разрабатываемого ПО.

Кодирование.

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

Тестирование и отладка.

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

Отдел отладки затем локализует и исправляет обнаруженные ошибки кода, «вылизывая» его до практически идеального состояния. Эти два этапа занимают не меньше 30% затрачиваемого на весь проект времени, так как от их качественного исполнения зависит судьба созданного силами программистов программного обеспечения. Нередко функции тестировщика и отладчика исполняет один отдел, однако самым оптимальным будет распределить эти обязанности между разными исполнителями, что позволит увеличить эффективность поиска имеющихся в программном коде ошибок. ^[4]

Внедрение.

Процедура внедрения программного обеспечения в эксплуатацию является завершающей стадией разработки и нередко ^[5]происходит совместно с отладкой системы. Как правило, ввод в эксплуатацию ПО осуществляется в три этапа:

первоначальная загрузка данных;

постепенное накопление информации;

вывод созданного ПО на проектную мощность.

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

Также стоит упомянуть и о стоимости всей разработки.

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

Сколько стоит разработка мобильного приложения? Стоимость разработки приложений для iOS или Android определяется двумя главными критериями.

• Первый критерий - исполнитель. Например, если вы живете в США и закажете приложение у местных разработчиков, то стоимость его будет в 2-3 раза выше, чем если бы им занимались специалисты из Восточной Европы.
• Второй критерий - сложность или трудоемкость приложения. Чем больше функционала и чем он сложнее в реализации, тем дороже будет стоить приложение.

Обзор стоимости приложений по странам мира

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

Запросы разработчиков приблизительно одинаковой квалификации за 1 час рабочего времени:

• США и Австралия (50-150 $)
• Великобритания (60-70 £)
• Западная Европа (60-70 €)
• Восточная Европа (35-50 $)
• Индия (8-30$). 

Стоимость приложений в Восточной Европе

Простое приложение требует 1-2 месяца разработки или 300 часов, а сложное приложение - более 4 месяцев.^[8]

Разработка мобильных приложений: цена на фрилансе

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

В Украине фриланс развивается очень стремительно, сейчас страна находится на 4-м месте в мире по объемам разработки на Upwork (раньше Elance-oDesk). Потому, что качество разработки мобильных приложений очень высокое, а цены в 2-3 раза ниже в сравнении с США

Нужно ли ездить в офис, чтобы сделать мобильное приложение?

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

Сколько времени уходит на разработку приложения?

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

• Бесплатная оценка стоимости (1-3 дня)
• Подробное изучение задачи, анализ рынка и конкурентов (1-5 дней)
• Прототипирование. Написание технического задания (5-15 дней)
• Дизайн (5-15 дней)
• Программирование (18-60+ дней)
• Тестирование (5-10 дней)^[9]

Оценка стоимости приложения

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

Оценка происходит в два этапа:
 

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

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

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

Хорошо, если компания уже создавала приложения с похожими функциями. В этом случае, ответ на вопрос "сколько стоит разработать мобильное приложение?" будет точнее, чем если бы разработчики не имели опыта в подобных приложениях.

Также у разработчиков уже могут быть наработки, которые можно перенести в новый проект.^[11]
 

Кто разрабатывает приложение?

В среднем над работой одного приложения трудится 6-10 человек: менеджер проекта, UX/UI дизайнер, арт-директор, программисты, инженер по тестированию и технический директор.

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

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

На что стоит обращать внимание при заказе приложения?

Анализ

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

Прототип

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

Техническое задание

Самым важным документом в разработке является ТЗ (техническое задание). По этому документу, вникая в каждую мелочь, работают программисты. Срок разработки приложения для Android или iOS - длительный, объем работы большой, и если что-то забыли написать в ТЗ, то это, скорее всего, сделано не будет. Потому на данный документ стоит обратить особое внимание.^[12]

Мобильное приложение - это постоянный труд

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

Вывод

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

Глава 2 Тестирование

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

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

Целевая аудитория (пользователь, компания, образовательная среда).

Канал, по которому распространяется приложение (например, App Store, Google Play или раздача напрямую).

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

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

Основные сценарии функциональных тестов:

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

Убедиться, что обязательные поля отображаются на экране не так, как необязательные.^[14]

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

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

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

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

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

Убедиться, что приложение поддерживает платежные операции через системы оплаты Visa, Mastercard, Paypal и др.

Проверить адекватность работы сценариев прокрутки страницы.

Проверить, присутствует ли надлежащая навигация между важными модулями приложения.

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

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

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

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

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

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

Проверить, как приложение работает на всех устройствах поколений 2G, 3G и 4G.^[16]

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

Убедиться, что существует доступное руководство пользователя.

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

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

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

регистрация: с логином и паролем, без пароля, через соц.сети и т.д.;

авторизация: с логином и паролем, через соц.сети и т.д.;

восстановление пароля;

выход из системы: самостоятельный, по истечению сессии и т.д.

Позитивные сценарии:

Регистрация в приложении доступна всеми описанными в ТЗ способами.^[17]

Можно зарегистрироваться, заполнив только обязательные поля.

Можно зарегистрироваться, заполнив полностью все поля.

После регистрации можно авторизоваться в приложении. При этом введенные данные корректно сохранены в профиле (e-mail, пароль, личная информация и т.д.).

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

Выход из системы работает корректно.

Восстановление пароля работает корректно.

Негативные сценарии (самое очевидное):

Повторная регистрация на один и тот же e-mail, с одним и тем же логином недоступна.

Регистрация без заполнения обязательных полей недоступна.

Регистрация, если все поля оставлены пустыми, недоступна.

Регистрация, если формат введенных данных не соответствует требованиям, недоступна.

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

Авторизация с неправильным/удаленным/заблокированным логином недоступна.

Авторизация с неправильным паролем недоступна.

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

Позитивные сценарии:

Создание, изменение, просмотр и удаление контактов доступны.

Создание контакта с минимальным набором данных доступно.^[18]

Создание контакта с максимальным набором данных доступно.

При создании корректно обрабатываются все описанные в ТЗ типы данных.

После создания контакт доступен для просмотра.

Изменение учитывает обязательные поля/данные/элементы. Сохранить контакт без них недоступно.

После удаления контакт больше не доступен.

Негативные сценарии:

Создание двух одинаковых контактов недоступно (это может быть и позитивным сценарием).

Создание контакта с отсутствующими обязательными элементами/данными недоступно.

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

Проверка экранов на совпадение с макетами.

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

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

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

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

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

Основные задачи:

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

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

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

Проверить поведение приложения в стресс-условиях.

Проверить работу в условиях «разросшейся» базы данных — насколько быстро выполняются запросы.

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

Основные сценарии тестирования производительности мобильных приложений:

Определить, работает ли приложение одинаково в разных условиях загрузки сети.^[20]

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

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

Найти различные узкие места приложения и инфраструктуры, которые снижают производительность приложения.^[21]

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

Оценить способность продукта и/или аппаратного обеспечения справляться с планируемыми объемами нагрузки.

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

Проверить работу приложения в случаях перехода из Wi-Fi-сети в мобильную 2G/3G-сеть и наоборот.

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

Убедиться в том, что потребление батареи и утечка памяти не выходят за пределы нормы, а работа различных ресурсов и сервисов, таких как GPS-навигация или камера, соответствует требованиям.

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

Проверить эффективность сети в условиях, когда устройство находится в движении.

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

Тестирование безопасности

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

Основная цель этого типа тестирования — обеспечить безопасность сети и данных приложения.

Ниже приведены ключевые действия для проверки безопасности мобильного приложения.^[22]

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

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

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

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

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

Защитить приложение от атак типа SQL-injection.

Найти случаи неуправляемого кода и устранить его последствия.

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

Защитить приложение и сеть от DoS-аттак.

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

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

Проверить все криптографические коды и, если необходимо, исправить ошибки.

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

Проанализировать взаимодействие файлов системы, выявить и скорректировать уязвимые места.

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

Защитить приложение от вредоносных атак на клиентов.^[23]

Защитить систему от вредоносных внедрений в момент работы программы.

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

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

Предотвратить возможные вредоносные действия файлов cookie.

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

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

Обезопасить систему от случаев переполнения буфера или нарушения целостности информации в памяти.

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

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

Юзабилити-тестирование проводится для создания быстрых и простых в обращении приложений. Главная цель — обеспечить удобство пользования приложением, создать интуитивный, соответствующий принятым стандартам интерфейс.

Итак, для проведения юзабилити-тестирования следует:

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

Поместить кнопки в одной области экрана, чтобы не вызвать замешательства у пользователей.^[24]

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

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

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

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

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

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

Убедиться в том, что текст прост, ясен и виден пользователю.

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

Найти оптимальный размер шрифта.

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

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

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

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

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

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

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

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

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

Правильность (accuracy) — сколько ошибок сделал пользователь во время работы с приложением?

Активизация в памяти (recall) — как долго пользователь помнит о том, как пользоваться приложением, после приостановки работы с ним на длительный период времени? (Повторное выполнение операций после перерыва должно проходить быстрее, чем у нового пользователя).

Эмоциональная реакция (emotional response) — Как пользователь себя чувствует после завершения задачи: растерян, испытал стресс или, наоборот, ему все понравилось? Порекомендует ли пользователь систему своим друзьям?

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

«Защита от дурака». Если поле предполагает ввод номера телефона, то стоит ограничить диапазон ввода только цифрами и соответствующим образом сформировать клавиатуру. Аналогично для e-mail и остальных элементов, которые предполагают пользовательский ввод данных.

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

Конфигурационное тестирование

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

Важнейшие сценарии конфигурационного тестирования:

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

Убедиться в том, что текст легко читается на любом устройстве.

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

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

На клиентском уровне можно выделить:

Тип устройства: смартфон, планшет и т.д.

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

Тип и версия операционной системы. iOS 6, 7; Android 4.2.2 и т.д.

Тип сети: Wi-Fi, GSM.

Перед проведением конфигурационного тестирования рекомендуется

Создавать матрицу покрытия (матрица покрытия — это таблица, в которую заносят все возможные конфигурации).^[28]

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

Шаг за шагом, в соответствии с расставленными приоритетами, проверяют каждую конфигурацию.

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

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

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

Проверка восстановления после сбоя системы и сбоя транзакций.

Проверка эффективного восстановления приложения после непредвиденных сценариев сбоя.

Проверка способности приложения обрабатывать транзакции в условиях сбоя питания (разряженная батарея / некорректное завершение работы приложения).

Проверка процесса восстановления данных после перерыва в соединении.^[29]

Другие важные области проверки^[30]:

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

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

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

Проверка наличия нефункциональных клавиш.

Проверка экрана загрузки приложения.

Проверка возможности ввода с клавиатуры во время сбоев сети.

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

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

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

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

Проверка уровня потребления энергии приложением.

Проверка побочных эффектов приложения.

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

Сюда попадают все сценарии, связанные с различного рода прерываниями во время работы с приложением:

произошел телефонный звонок;

поступило смс;

на экране появилось уведомление другого приложения;

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

приложение было свернуто в трей;

приложение переведено в фоновый режим и т.д.

Данные случаи должны быть предусмотрены при разработке и тестировании приложения.^[31]

Давайте рассмотрим немного другой алгоритм действий.

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

Итак, приступим. Что делает пользователь мобильного приложения в первую очередь? Правильно: устанавливает. Вот вам первый этап тестирования. QA инженер обязан убедиться, что пользователь не испытает боль и страдания в процессе установки. Здесь нужно определить: будет ли приложение устанавливаться на различные операционные системы. ^[32]

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

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

Недостаток оперативной памяти;

Недостаток дискового пространства;

Определенные типы процессора и операционной системы;

Совместимость между различными типами операционных систем.

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

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

Внешние факторы: скорость/стабильность подключения к сети, переключение между Wi-Fi и 3G/4G, прием звонков/сообщений в процессе работы приложения, подключение периферийных устройств (наушники, bluetooth гаджеты и т. д.), выемка/замена SIM или SD-карты, пока телефон включен, включение/выключение спящего режима, температура воздуха и т. д.^[33]

Внутренние факторы: нехватка оперативной памяти или места на диске, низкий заряд аккумулятора, отключение каких-либо услуг (например, GPS) и т. д.

Нагрузочное тестирование

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

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

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

Жесты;

Физическая/экранная клавиатура;

Ориентация экрана (горизонтальная/вертикальная);

Нестандартные элементы управления.

Тестирование локализации

Шестой этап. В процессе тестирования локализации, особое внимание уделяется контенту и пользовательскому интерфейсу. А именно:

Какие языки поддерживает приложение;

Точность перевода различных элементов интерфейса;

Точность перевода документации и разделов FAQ/Help;

Корректность текущей даты, времени и т.д.

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

Седьмой этап призван оценить UX мобильного приложения. Для чего вообще нужно юзабилити? Для упрощения работы с приложением, адаптации программы к потребностям пользователей и, в конечном итоге, для увеличения популярности продукта и повышения конверсии. В процессе тестирования юзабилити QA инженер выявляет ошибки в навигации и прочие баги, связанные с экраном приложения. Например:

Элементы графического интерфейса;

Объем данных;

Оперативность взаимодействия элементов;

Цветовая гамма и т. д.

Автоматизированное тестирование

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

Приложение полностью соответствует функциональным требованиям;^[35]

Жизненный цикл разработки приложения занимает слишком много времени;

Функциональность приложения перманентно растет. ^[36]

Вывод

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

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

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

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

Интерфейс — общая граница между двумя функциональными объектами, требования к которой определяются стандартом; совокупность средств, методов и правил взаимодействия (управления, контроля и т. д.) между элементами системы (источник: wikipedia.org).^[37]

Это точное, но скучноватое определение.

А вот иными словами, но интереснее: пользовательский интерфейс (UI) — это «способ, которым вы выполняете какую-либо задачу с помощью какого-либо продукта, а именно совершаемые вами действия и то, что вы получаете в ответ» (источник: Джеф Раскин, «Интерфейс. Новые направления в проектировании компьютерных систем»^[38]).

В повседневной жизни мы постоянно сталкиваемся с интерфейсами. Это и сайты соцсетей, и элементы управления в салоне автомобиля, и пульт ДУ для телевизора, и голосовое управление умным домом, и панель кнопок в лифте.^[39]

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

Зачем нужен UI 

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

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

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

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

Разработка UI

Чтобы у нас с вами не возникло проблем при использовании какого-либо приложения, умные люди визуализируют его функциональные возможности в виде понятных элементов, и за этой визуализацией кроется целая кухня UX/UI-дизайна.^[41]

Грань между UX (User Experience) и UI (User Interface) очень тонка, но если разобраться, то становится ясно, что UX помогает понять пользователя. В UX-дизайне больше психологического аспекта, нежели технологического. UX изучает пользователя: как пользователь живёт, что он думает, как и что делает и что его окружает. Перед дизайнером ставится задача — помочь обычному человеку легко разобраться с вашим программным продуктом и получить при этом удовлетворение от работы с ним.

А понять пользователя очень важно. Никому не захочется заполнить двадцать полей формы для регистрации на сайте или перещелкать штук пятнадцать вкладок, прежде чем добраться до нужной функции. «Пользователя не следует заставлять взаимодействовать с программой дольше, чем абсолютно необходимо для решения той или иной задачи» (Алан Купер, «Психбольница в руках пациентов»^[42]).

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

Концепция

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

Создание мокапа

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

То есть начинаем с варфрейма (план расположения элементов на странице), а заканчиваем созданием из этого плана красивой картинки. В случае разработки приложений под Android и iOS труд дизайнера облегчается гайдлайнами — правилами оформления и расположения элементов интерфейса, регламентом UX/UI, который был создан непосредственно экспертами по дизайну из Google и Apple.

User Flow Diagram (карта экранов)

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

Утверждение структуры

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

Выбор стиля UI

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

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

Согласование стиля

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

Интерактивный прототип

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

Для более наглядной демонстрации работы приложения инвесторам и потенциальным пользователям можно заняться разработкой интерактивного прототипа. Хотя стоит отметить, что это не обязательный этап, так как мокап+user flow diagram вполне себе является прототипом, описывающим будущий продукт с точки зрения UX. Однако интерактивный прототип даст более полное представление и о возможностях приложения, и об объеме работ по их реализации.

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

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

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

Утверждение результата

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

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

Далее рассматривается более подробно о разработке дизайна по определенным стандартам и инструкций популярных площадок.

Задача дизайна

Как и большинство студий разработки сайтов и мобильных приложений, Лайв Тайпинг создаёт функциональные сервисы, которые призваны решать реальные человеческие проблемы максимально удобным способом. В этом помогает дизайн. Его назначение — не развлекать людей или выделять продукт на фоне остальных за счёт кричащих цветов и нестандартных функций, а делать так, чтобы пользоваться продуктом было приятно, удобно и эффективно.^[47]

Что вам нужно понимать

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

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

Гайдлайны

Самое важное в создании дизайна приложений — соблюдать гайдлайны Apple и Material Design. Гайдлайны Apple — это рекомендации по тому, как сделать дизайн пользовательского интерфейса таким же красивым и удобным, как и у других продуктов бренда. Но с гайдами для Android-устройств немного сложнее. Здесь следование гайдлайнам Material Design помогает не только делать продукт удобным, но и экономить время на его разработку.^[49]

Почему так?

Согласно данным, размещённым в Google Play Developer Console, на момент написания этой статьи операционную систему Android поддерживает 15 105 уникальных моделей устройств. Все эти устройства отличаются разным набором кнопок, разными разрешениями экранов и другим.

Ещё для Android-устройств характерен феномен фрагментации. В чём он заключается? При выходе новой официальной версии операционной системы вся огромная армияAndroid-пользователей не спешит дружно на неё переехать, как это происходит с пользователями Apple.^[50]

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

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

Accessibility

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

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

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

Stark. Это плагин для Sketch. Он открывается в виде окна, через которое просвечивается уже готовый дизайн, и проверяет элементы по тому же принципу, что и Contrastchecker.

Итоги этапа

На основе проектирования и с учётом гайдлайнов дизайнеры рисуют в Sketch дизайн-макеты для приложений и сайтов, а иллюстрации и анимации создают в продуктах Adobe.

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

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

Создание концепции

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

На этом этапе могут быть затронуты и такие аспекты, как размеры и расположение кнопок и форм, шрифты и многие другие аспекты структуры интерфейса. Давайте сравним финтех-приложение и сервис такси-компании.^[52]

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

Брейнсторминг и эскизы

Как только концепция проекта ясна, двигаемся к следующему этапу — брейнстормингу. Он нужен, чтобы превратить идею интерфейса в реальность. Можно использовать ручку и лист бумаги — это быстрее, чем использование таких продвинутых инструментов, как Balsamiq Mockups, Sketch, Photoshop и InVision.^[53]

ДИАГРАММА ПЕРЕХОДОВ

Создание эскиза дает нам структуру интерфейса. Но как пользователь должен взаимодействовать с ним? Здесь поможет User Flow Diagram. Она проиллюстрирует логику продукта, показав всевозможные способы взаимодействия с интерфейсом, дорожную карту этих взаимодействий и состояние интерфейса на каждом этапе.

Утверждение структуры и диаграммы переходов

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

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

Выбор стиля интерфейса

Когда клиент все утверждает — можно двигаться дальше. Что будем делать? Выберем стиль интерфейса. Есть множество вариантов: от минимализма и Metro до material design и скевоморфизма. На этом этапе у клиентов просят прислать несколько ссылок на примеры стиля интерфейса, который им нравится, а также спрашивается об их планах на ближайшее будущее продукта. Уделяется внимание текущим трендам, масштабированию интерфейса, определяется время, которое необходимо на разработку и внедрение дизайна.^[54]

Подтверждение стиля

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

Прототипирование, дизайн и их демонстрация

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

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

Макет

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

Кликабельный прототип

Это уже детализированный прототип финального продукта. Он эмулирует взаимодействие пользователя с интерфейсом. Например, позволяет кликать по элементам управления, использовать формы и проверять другие моменты, включая анимацию. Тем не менее создание такого прототипа — процесс, который требует большого количества времени.^[55]

Анимированные flow

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

Утверждение дизайна

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

Вывод

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

Заключение

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

Библиография

IntechCore Этапы разработки программного обеспечиния. URL: https://ru.intechcore.com/stages-software-development/

Woxaap Стоимость разработки мобильного приложения URL: https://woxapp.com/ru/app-development-cost/

Wikipedia URL: https://ru.wikipedia.org

CMS Magazine Мобильное тестирование: полное руководство URL: https://cmsmagazine.ru/journal/items-testing-mobile-apps/

JetRuby Этапы тестирования мобильных приложений URL: https://jetruby.com/ru/blog/testirovanie-mobilnyh-prilozhenii/

Live Typing Что такое разработка пользовательского интерфейса и зачем её заказывать URL: https://livetyping.com/ru/blog/chto-takoe-razrabotka-polzovatelskogo-interfeisa-i-zachem-tt-zakazyvat

Live Typing Как мы делаем проекты: дизайн URL: https://livetyping.com/ru/blog/kak-my-delaem-proekty-dizajn

Алан Купер. Психбольница в руках пациентов. URL: https://www.e-reading.club/book.php?book=31710

Джеф Раскин. Интерфейс. Новые направления в проектировании компьютерных систем. URL: https://www.e-reading.club/book.php?book=89632

Хабр 8 этапов процесса разработки интерфейса мобильного приложения URL: https://habr.com/ru/company/skillbox/blog/416641/

Приложение

*

Пример перегруженного дизайна. Источник: https://livetyping.com/ru/blog/chto-takoe-razrabotka-polzovatelskogo-interfeisa-i-zachem-tt-zakazyvat

*

Пример чистого дизайна. Источник: https://livetyping.com/ru/blog/chto-takoe-razrabotka-polzovatelskogo-interfeisa-i-zachem-tt-zakazyvat

*

Skeuomorphic design и flat design. Источник: https://livetyping.com/ru/blog/chto-takoe-razrabotka-polzovatelskogo-interfeisa-i-zachem-tt-zakazyvat

*

User Flow Diagram. Источник: https://livetyping.com/ru/blog/chto-takoe-razrabotka-polzovatelskogo-interfeisa-i-zachem-tt-zakazyvat

*

Пример мокапа. Источник: https://livetyping.com/ru/blog/chto-takoe-razrabotka-polzovatelskogo-interfeisa-i-zachem-tt-zakazyvat

1. https://ru.intechcore.com/stages-software-development/ ↑

2. https://ru.intechcore.com/stages-software-development/ ↑

3. https://ru.intechcore.com/stages-software-development/ ↑

4. https://ru.intechcore.com/stages-software-development/ ↑

5. ↑

6. https://ru.intechcore.com/stages-software-development/ ↑

7. https://woxapp.com/ru/app-development-cost/ ↑

8. https://woxapp.com/ru/app-development-cost/ ↑

9.  https://woxapp.com/ru/app-development-cost/ ↑

10. https://woxapp.com/ru/app-development-cost/ ↑

11. https://woxapp.com/ru/app-development-cost/ ↑

12. https://woxapp.com/ru/app-development-cost/ ↑

13. https://woxapp.com/ru/app-development-cost/ ↑

14. https://cmsmagazine.ru/journal/items-testing-mobile-apps/ ↑

15. https://cmsmagazine.ru/journal/items-testing-mobile-apps/ ↑

16. https://cmsmagazine.ru/journal/items-testing-mobile-apps/ ↑

17. https://cmsmagazine.ru/journal/items-testing-mobile-apps/ ↑

18. https://cmsmagazine.ru/journal/items-testing-mobile-apps/ ↑

19. https://cmsmagazine.ru/journal/items-testing-mobile-apps/ ↑

20. https://cmsmagazine.ru/journal/items-testing-mobile-apps/ ↑

21. https://cmsmagazine.ru/journal/items-testing-mobile-apps/ ↑

22. https://cmsmagazine.ru/journal/items-testing-mobile-apps/ ↑

23. https://cmsmagazine.ru/journal/items-testing-mobile-apps/ ↑

24. https://cmsmagazine.ru/journal/items-testing-mobile-apps/ ↑

25. https://cmsmagazine.ru/journal/items-testing-mobile-apps/ ↑

26. https://cmsmagazine.ru/journal/items-testing-mobile-apps/ ↑

27. https://cmsmagazine.ru/journal/items-testing-mobile-apps/ ↑

28. https://cmsmagazine.ru/journal/items-testing-mobile-apps/ ↑

29. https://cmsmagazine.ru/journal/items-testing-mobile-apps/ ↑

30. https://cmsmagazine.ru/journal/items-testing-mobile-apps/ ↑

31. https://cmsmagazine.ru/journal/items-testing-mobile-apps/ ↑

32. https://jetruby.com/ru/blog/testirovanie-mobilnyh-prilozhenii/ ↑

33. https://jetruby.com/ru/blog/testirovanie-mobilnyh-prilozhenii/ ↑

34. https://jetruby.com/ru/blog/testirovanie-mobilnyh-prilozhenii/ ↑

35. https://jetruby.com/ru/blog/testirovanie-mobilnyh-prilozhenii/ ↑

36. https://jetruby.com/ru/blog/testirovanie-mobilnyh-prilozhenii/ ↑

37. https://ru.wikipedia.org ↑

38. https://www.e-reading.club/book.php?book=89632 ↑

39. https://livetyping.com/ru/blog/chto-takoe-razrabotka-polzovatelskogo-interfeisa-i-zachem-tt-zakazyvat ↑

40. https://livetyping.com/ru/blog/chto-takoe-razrabotka-polzovatelskogo-interfeisa-i-zachem-tt-zakazyvat ↑

41. https://livetyping.com/ru/blog/chto-takoe-razrabotka-polzovatelskogo-interfeisa-i-zachem-tt-zakazyvat ↑

42. https://www.e-reading.club/book.php?book=31710 ↑

43. https://livetyping.com/ru/blog/chto-takoe-razrabotka-polzovatelskogo-interfeisa-i-zachem-tt-zakazyvat ↑

44. https://livetyping.com/ru/blog/chto-takoe-razrabotka-polzovatelskogo-interfeisa-i-zachem-tt-zakazyvat ↑

45. https://livetyping.com/ru/blog/chto-takoe-razrabotka-polzovatelskogo-interfeisa-i-zachem-tt-zakazyvat ↑

46. https://livetyping.com/ru/blog/chto-takoe-razrabotka-polzovatelskogo-interfeisa-i-zachem-tt-zakazyvat ↑

47. https://livetyping.com/ru/blog/kak-my-delaem-proekty-dizajn ↑

48. ↑

49. https://livetyping.com/ru/blog/kak-my-delaem-proekty-dizajn ↑

50. https://livetyping.com/ru/blog/kak-my-delaem-proekty-dizajn ↑

51. https://livetyping.com/ru/blog/kak-my-delaem-proekty-dizajn ↑

52. https://habr.com/ru/company/skillbox/blog/416641/ ↑

53. https://habr.com/ru/company/skillbox/blog/416641/ ↑

54. https://habr.com/ru/company/skillbox/blog/416641/ ↑

55. https://habr.com/ru/company/skillbox/blog/416641/ ↑

56. https://habr.com/ru/company/skillbox/blog/416641/ ↑