стадии разработки мобильного приложения
Основные этапы разработки мобильных приложений
Перед вами — набор типичных этапов в создании мобильного приложения с нуля, которые студия Componentix практикует к своей деятельности.
Бизнес-анализ целевого рынка
На этом этапе заказчику стоит определиться, зачем он планирует использовать приложение, какова итоговая цель разработки мобильного инструмента коммуникации с аудиторией. Вот перечень ориентировочных вопросов, на которые стоит найти ответы, прежде чем формулировать ТЗ и заказывать разработку приложения:
Перед началом разработки необходимо получить от заказчика техническое задание (ТЗ) или предоставить ему бриф для заполнения и дальнейшей работы по этому документу.
После получения заполненного брифа и / или ТЗ можно приступать к прототипированию и составлению пользовательских профилей для оценки возможностей итогового продукта.
На основе видения дизайнера, бизнес-оценки и согласования подробностей ТЗ можно запускать процесс разработки.
Прототипирование
Прототипы разрабатываются дизайнером и мгут быть как статическими, так и интерактивными. Для этого можно воспользоваться одним или несколькими инструментами для прототипирования, о которых мы рассказывали ранее.
Статические прототипы и интерактивные макеты должны составляться с учетом технической и программной базы, которую планируется использовать для создания приложения.
Написание кода и внедрение технологий
С готовым дизайном приложение переходит к разработчикам: им предстоит на основе языков программирования, фреймворков и различных технологий создать мобильное приложение в соответствии с ТЗ, брифом и утвержденным прототипом.
Тестирование
На различных этапах разработки приложения обязательным является внутреннее тестирование приложения как на симуляторах, так и на реальных устройствах. Цель тестирования — убедиться, что взаимодействие приложения с аппаратной и программной платформой смартфонов и планшетов будет именно таким, как предполагалось на этапе прототипирования.
Создание предрелизной версии
В результате серии тестов и доработок приложения должна быть получена рабочая версия приложения. Именно эту версию и предстоит добавить в магазин приложений: Apple App Store, Google Play, магазин приложений Windows Phone (в зависимости от того, для какой платформы ведется разработка) или любой аналогичный сервис для дистрибуции приложений.
Добавление приложения в магазин
Финальный этап работы студии — добавление приложения на ревью в один из указанных выше магазинов приложений (в случае Componentix речь идет об App Store или о Google Play).
Необязательный этап: дальнейшая техническая поддержка и маркетинговое продвижение приложения
При желании заказчика возможно предоставление дополнительных услуг, таких как техническая поддержка приложения, дальнейший выпуск новых версий под обновляемые версии мобильных ОС, а также маркетинговое продвижение.
Поскольку эти услуги предоставляются отдельно от основного пакета услуг, то и оплачиваются отдельно. Помимо маркетинга и техподдержки возможно также размещение приложения в App Store или Google Play от имени заказчика (услуга White Label), обеспечение серверной поддержки для приложения.
Этапы разработки мобильного приложения: пьеса в 7 действиях
Время чтения: 7 минут
Отправим вам статью на:
Знаете ли вы, что около 6 140 мобильных приложений выходят в Google Play ежедневно? А к 2020 году число релизов в App Store достигнет 5 миллионов? Статистика говорит об одном: пора разрабатывать своё мобильное приложение. Если вы всерьёз задумались над разработкой приложения, наш обзор вам поможет.
Неважно, что вы планируете создать — инструмент для бизнеса или стартап с широкой аудиторией. Мы развеем ваши страхи и опишем этапы разработки мобильного приложения.
Итак, пьеса “Процесс разработки мобильного приложения” в 7 действиях.
Действующие лица
Клиент — заказчик мобильного приложения, идейный вдохновитель проекта
Azoft — разработчики приложения
Project manager — менеджер проекта
Бизнес-аналитик — исследователь и хранитель знаний о требованиях к продукту
UI/UX дизайнер — создатель интуитивного и привлекательного интерфейса приложения
Разработчик — инженер, который пишет код приложения
QA инженер — специалист по тестированию приложения
Пролог
Сначала клиент приходит с идеей мобильного приложения. Мы просим клиента предоставить нам техническое задание (ТЗ), а если его нет — высылаем бриф на разработку мобильного приложения. Бриф помогает расставить приоритеты, обозначить цели и задачи приложения.
Все приложения разные, и мы используем разные методологии разработки: каскадную модель — Waterfall, и гибкую — Agile. Что бы вы не выбрали, процесс создания мобильного приложения включает оценку, аналитику, дизайн, разработку, тестирование, багфиксинг, релиз и поддержку после релиза. Ключевое различие состоит в подходах. В каскадной модели продукт разрабатывается сразу полностью. В гибкой — приложение разрабатывается итерациями, каждая из которых объединяет в себе все перечисленные стадии разработки.
На выходе:
Действие первое — Планирование и оценка
Первый вопрос, который интересует клиента: “Сколько это будет стоить?”. Следующий за ним: “Когда будет готово мобильное приложение?”. Чтобы ответить на оба вопроса, Azoft проводит оценку и составляет план работ. На этом этапе к проекту обычно присоединяется менеджер проекта. Он может выступать со стороны заказчика или со стороны команды разработчиков. Задачи менеджера проекта: координировать работу команды и общаться с заказчиком.
Но что же означает загадочное слово “оценка”? На этом этапе мы изучаем техническую документацию. Рассчитываем, сколько времени потребуется на разработку и тестирование. Выявляем не описанные сценарии и узкие места в ТЗ.
Экспресс-оценка занимает от нескольких часов до одного дня и даёт примерное представление о трудозатратах. Детальная оценка может длиться от нескольких дней до недели, но она позволяет точно определить, как, когда и какое приложение вы получите в результате. Если бизнес-аналитик подключается к проекту на этапе оценки, клиенту и разработчикам легче получить единое представление о приложении и всё точно рассчитать.
Но какой бы детальной ни была оценка, случается, что заказчики добавляют новые фичи прямо по ходу проекта. Когда мы делали приложение Pro Photo Shoot, соцсеть для фотографов и моделей, его автор, стартапер Уильям Апшоу на этапе разработки понял, каких функций не хватает. Список задач увеличился, мы сделали повторную оценку и сдвинули дату релиза. В итоге бюджет подрос, но мы разработали соцсеть для профи из фотоиндустрии в полном соответствии с требованиями клиента.
На выходе:
Действие второе — Aналитика
Аналитика не всегда входит в процесс разработки мобильного приложения. Бывает, что клиенты самостоятельно выполняют бизнес-анализ приложения, либо приходят с готовым списком требований. Но те приложения, которые прошли этот этап у компании-разработчика, выигрывают, — именно аналитика помогает бизнесу и разработчикам достичь единого видения, и уже на основе этого сделать переоценку требуемых работ и получить детальный бюджет проекта.
Бизнес-аналитики в Azoft выявляют требования к мобильному приложению, предлагают варианты реализации, строят схемы взаимодействия пользователя с приложением, создают основу UI — wireframes.
Большую работу провели наши аналитики на проекте для крупной сети супермаркетов. Заказчик искал способ, как через приложение мотивировать покупателей на дополнительные покупки. Мы проанализировали возможные пути решения и предложили наиболее эффективный вариант — интегрировать в мобильное приложение систему рекомендаций. Программа на базе AI советует пользователям товары на основе их предпочтений и истории покупок.
На выходе:
Действие третье — Дизайн приложения
Иногда клиенты приходят с готовым дизайном. Если дизайна у заказчика нет, мы создаём UI/UX с нуля. Когда аналитик передаёт дизайнеру основу графического интерфейса, вайерфреймы, мы приступаем к визуальному дизайну. Отрисовываем карту экранов, графические элементы, детализированный прототип с учётом различных сценариев использования.
На этом этапе UI/UX дизайнер создаёт статичные прототипы и, по запросу клиента, интерактивные прототипы приложения. Так мы показываем, как будет выглядеть приложение и какого поведения от него ожидать с учётом запланированных фич. Всё зависит от конкретных задач и пожеланий клиента.
Во время отрисовки дизайна приложение обретает свой будущий облик. Здесь очень важно получить обратную связь от бизнес-аналитика и клиента, чтобы дизайн мобильного приложения в полной мере отвечал требованиям.
На выходе:
Действие четвёртое — Разработка
Когда есть развёрнутое ТЗ и оценка, готов дизайн и утверждён прототип мобильного приложения, начинается хардкор. Команда разработчиков пишет код, чтобы реализовать запланированное поведение приложения и соединить логику приложения с серверной частью, если она предусмотрена. А также мы воплощаем готовый дизайн в коде — прописываем все стили и элементы UI, с которыми взаимодействует пользователь приложения.
В нативной разработке мы применяем языки Java и Kotlin для Android, Objective-C и Swift для iOS, и самые современные фреймворки и библиотеки. В кроссплатформенных решениях работаем с React Native и NativeScript.
Как только часть функционала разработана, мы её тестируем и продолжаем трудиться над остальными функциями.
Важно во время разработки, когда сверстали дизайн, подключить дизайнера. Дизайнер проверит, насколько хорошо разработчики реализовали скрины приложения: все ли стили соответствуют выбранным, тот ли выбран цвет, каково соотношение сторон, как скруглили углы и т.д.
На выходе:
Действие пятое — Тестирование и багфиксинг
QA инженеры Azoft подключаются к проекту на старте и тестируют так часто, как только возможно. Это гарантирует высокий уровень качества и помогает клиенту не раздуть бюджет.
На этапе оценки мы тестируем ТЗ. Параллельно с разработкой пишем тестовую документацию, например, тест-кейсы. Когда часть функционала готова, начинается тестирование. Все баги вносим в систему баг-репортинга, после исправления проверяем, что баги пофиксили и это не повлияло на остальной функционал. Перед релизом приложения делаем приёмочное тестирование: проходим основные бизнес-кейсы приложения, чтобы убедиться — поведение приложения соответствует тестовой документации и требованиям клиента.
Когда мы разрабатывали StoryApp — приложение для чтения коротких рассказов, заказчик не сразу определился, какие функции будут в приложении. Мы описали тестовую спецификацию с подробными характеристиками экранов и фич на основании озвученных требований клиента. Когда же во время разработки появились новые функции, например, покупки в приложении, мы были к этому готовы — расширили тестовую спецификацию непосредственно в разгаре проекта.
На выходе:
Действие шестое — Релиз
Когда серия тестов и доработок приложения завершена, а разработчики, аналитики, тестировщики и дизайнеры дружно одобряют результат, приходит время добавить приложение в магазин приложений — Apple App Store, Google Play или любой другой сервис по желанию клиента.
Чтобы приложение прошло ревью сторов, клиент может обратиться к разработчикам за помощью в релизе, а может подготовить и выложить приложение в магазин самостоятельно.
На выходе:
Действие седьмое — Техподдержка и развитие
После публикации мобильного приложения его история не заканчивается. Если клиент обнаруживает баги после релиза, мы их фиксим. Если же первые месяцы жизни приложения показывают, где и что нужно допилить или переделать, есть два варианта: заключить договор на сопровождение или запустить новую фазу разработки с учётом новых переменных.
На выходе:
Эпилог
Разработка мобильного приложения это непросто. Нет такой схемы “Раз-два, и готово”. Многие этапы могут пересекаться друг с другом или идти параллельно. Инстаграму потребовалось больше трёх лет, чтобы стать удобным и любимым миллионами приложением. И они до сих пор продолжают вносить улучшения и добавлять новые фичи. Перед тем как фантазировать, куда вы вложите деньги от продажи своего приложения IT-гиганту вроде Google, приготовьтесь — будет много работы. Смотрите действие первое.
Подпишитесь
Оставьте адрес, и каждый месяц мы будем высылать свежую статью
о новых трендах в разработке програмного обеспечения.
Этапы разработки мобильного приложения: от проектирования до релиза
Современный человек не может обойтись без таких устройств, как смартфон или планшет. Именно поэтому для успешного развития бизнеса необходимо собственное мобильное приложение, создание которого доступно каждому. Благодаря программе для телефона возрастает эффективность взаимодействия с бизнес-партнерами и клиентами, ведь в приложении содержится много полезной информации о компании. Помимо этого, платформой для телефона удобно пользоваться и она доступна всегда, даже при отсутствии интернет-связи.
В 2020 году каждый месяц в мире выпускается 113 тысяч мобильных приложений через Google Play и еще 2 миллиона доступно через App Store. Вне зависимости от назначения утилиты для iPhone или Android, процесс ее создания обычно состоит из ряда последовательных этапов.
Этапы разработки мобильного приложения для iOS, Android, Windows
Процесс проектирования и разработки программ для телефона происходит в несколько этапов. Рассмотрим их подробнее.
Процесс определения целевого рынка
На этапе определения целевого рынка заказчику необходимо определиться с целью разработки мобильного приложения, ролью, которая отводится платформе для налаживания общения с целевой аудиторией. Основные моменты, которые необходимо знать до заказа проектирования и разработки веб-сервиса:
Дополнительно стоит определить приложения, которыми пользуется целевая аудитория — как ваша, так и конкурентов. Важно выяснить, готовы ли они сделать выбор в пользу разрабатываемого приложения и отказаться от аналогов.
Основы аналитики
Работа над проектированием и созданием нового мобильного приложения начинается с идеи. Заказчик рассказывает исполнителю, какие задачи приложение призвано решить. Исполнитель, в свою очередь, собирает аналитику: анализирует рынок, конкурентов, уже имеющиеся решения, поведенческие модели покупателей. Это позволяет понять, как ПО будет использоваться людьми и как сделать его максимально полезным и удобным. Только такой сервис может быть полезен для бизнеса. Результат аналитической работы перед проектированием в том, что исполнитель получает представление о том, каким должен быть дизайн и функционал будущего продукта.
Этапом аналитики не следует пренебрегать. Ошибка многих — начинать работу по проектированию непосредственно с составления технического задания. Анализ помогает получить информацию об игроках рынка: какие практики достойны внимания, а какие — нет, выработать решения, которые с большой вероятностью сработают в пользу бизнеса.
Составление подробного технического задания (ТЗ)
Техническое задание представляет собой описание желаемого функционала и дизайна приложения. На этом этапе определяется, как пользователь будет работать с сервисом (User Story, Customer Journey Map), формируется свод технических требований. Результат создания ТЗ:
User Story — что это?
Пользовательская история представляет собой описание поведения человека при пользовании сервисом:
Таким образом, User Story описывает, как именно покупатель пользуется приложением, чтобы решить свою проблему и получить выгоду. Ее разработка позволяет выявить требования, определяющие удобство и функциональность будущей мобильной платформы для пользователя.
Например, вы хотите сделать приложение для интернет-магазина. Основу пользовательской истории составляют: создание учетной записи, выбор нужного товара (для упрощения задачи — фильтры и специальная поисковая строка), виртуальная корзина, история заявок, выбор способа оплаты и доставки. Подобный взгляд на всю систему в целом позволяет продумать детали заранее и избежать многих проблем на стадиях проектирования и разработки сервиса.
Карта путешествий
Customer Journey Map — карта путешествий — показывает, как человек пользуется мобильным приложением. Карта отображает перемещения от одного экрана к другому и клики на кнопки. Благодаря карте удается понять, как воплотить в жизнь функционал утилиты для телефона.
Таким образом, ТЗ включает следующую информацию.
Общие сведения: цель создания мобильного приложения, совместимость с ОС, масштабируемость (способность адаптироваться к изменению условий), возможность выполнения функций при отказе одного компонента или нескольких.
Возможности неавторизованных и зарегистрированных пользователей, обмен данными, поддержка работы с другими приложениями (платежные, почтовые сервисы), администрирование ПО.
Список нефункциональных требований: безопасность, возможность сохранения отчетов об ошибках, производительность.
Проектирование функционала: экран загрузки, порядок регистрации (авторизации), меню, способы поиска нужной информации, уведомления для пользователей.
Стадия проектирования
Проектирование, или UX-дизайн, предполагает взаимодействие между составными частями приложения. На этом этапе можно увидеть, как мобильный сервис будет работать при различных вариантах пользовательского сценария:
Этап проектирования — проверка логики мобильного сервиса. Здесь же, если это необходимо, выполняется корректировка модели. Проектирование особенно актуально для стартапов, где степень неопределенности особенно высока.
Прототипирование
Прототипы — макеты пробной версии программы — разрабатываются дизайнером. Различают статические и интерактивные прототипы. Последние снабжены переходами и управляющими кнопками. Специалист-аналитик, который занимается прототипированием, продумывает порядок работы приложения и алгоритм действий пользователя в нем. Возможно, придется скорректировать первоначальную идею с поправкой на целевую аудиторию и проблемы, которые предстоит устранить при помощи мобильного приложения.
После разработки прототип согласовывается с заказчиком. При необходимости в него вносятся коррективы, и проект передается дизайнеру. Последний выбирает стиль, в котором будет оформлено приложение. При этом используются рекомендации от Material design guidelines и iOS Human Interface Guidelines: размеры, отступы, применение элементов анимации.
Рекомендуется выполнять интерактивное прототипирование, пользуясь онлайн-инструментом Figma. Если перейти по ссылке, можно рассматривать мобильное приложение так, будто оно уже готово и установлено на гаджет. Допустимо переходить с одной страницы на другую, пользоваться управляющими кнопками и т. д. Интерактивные прототипы одинаково полезны для заказчика и исполнителя. Последний сможет выявить и быстро устранить ошибки, а заказчик будет заранее иметь представление о том, как работает мобильное приложение и насколько удобно им пользоваться.
Дизайн веб-приложений
UI-дизайн — то, как будет выглядеть веб-приложение. Дизайнер подбирает цветовую гамму, работает над созданием интерфейса. Если компания имеет собственный стиль и корпоративные цвета, дизайн разрабатывается в соответствии с ними. Важно получить обратную связь от клиента, чтобы понять, что получилось именно то, что ему необходимо.
Создание программы для ОС Android и iOS
Программирование — важнейший этап проекта. Создание кода сервиса разделяется на 2 стадии:
Фронтенд предполагает проектирование и разработку клиентской части приложения — интерфейс, бизнес-логика. Различают 2 разновидности приложений: нативные и кросс-платформенные.
Особенность нативного приложения в том, что оно предназначено для определенной операционной системы: Андроид, Windows или iOS. Нативные платформы дают возможность использовать все возможности операционной системы, поэтому очень удобны. Есть и другие плюсы создания нативных программ:
Из недостатков можно отметить большие затраты как на стадии старта, так и при последующей поддержке.
Для кроссплатформенного приложения пользуются набором средств для проектирования и разработки мобильных приложений — SDK. Расходы на создание подобного проекта значительно меньше, по сравнению с нативным проектом. Преимущества этого варианта:
Однако кроссплатформенные программы имеют и недостатки:
Выбор конкретного варианта зависит от таких факторов:
Бэкенд — это создание серверной части сервиса, которая ответственна за передачу информации. На сервере хранятся данные о задолженностях покупателей, наличии товаров в магазине и количестве складских запасов. Важно продумать сервер таким образом, чтобы обмен информацией между ним и внешним интерфейсом осуществлялся без проблем. По окончании этого этапа получается мобильное приложение в первом варианте, готовое к тестированию.
Тестирование, багфиксинг
Под тестированием понимают поиск ошибок во вновь созданном мобильном сервисе. Распространенная ошибка клиентов — недооценка значения стадии тестирования, стремление поскорее запустить проект, а от возможных багов избавляться «по ходу». Ошибки рано или поздно придется исправлять, но при подобном подходе это обходится дороже. Тестирование приложения проводят на всех стадиях разработки. Проверяют удобство интерфейса, уровень безопасности, быстродействие, отзывчивость. Это дает возможность для своевременного исправления ошибок и получения на выходе нормально функционирующего продукта.
Кроме основного тестирования, специалисты рекомендуют выполнять регрессионное. Его назначение — убедиться в том, что после устранения одних ошибок не возникли новые, а те части кода, которые не были затронуты, функционируют без сбоев. Этап тестирования достаточно затратный и трудоемкий, но делать его статьей экономии не нужно.
Функциональность платформы для телефона: регистрация, авторизация, оформление и оплата покупок.
Доступность для различных ОС и разнообразного оборудования.
Производительность, работа сервиса при различных нагрузках: от нормальной до максимальной. На этом этапе оценивается взаимодействие между внешним интерфейсом и сервером, скорость передачи данных.
Безопасность — пользователи иногда удаляют мобильные платформы из-за того, что они не являются безопасными. Поэтому обязательное условие — гарантия того, что личная информация не будет доступна посторонним.
Этап багфиксинга — это только исправление в приложении имеющихся ошибок, без добавления новых «фишек». Это окончательная проверка, перед тем как будет выпущен релиз.
Релиз, поддержка после релиза
Заключительным этапом разработки мобильного сервиса является добавление его в специальный магазин приложений: App Store или Google Play. Однако поддержка после релиза также важна. Надо следить за тем, чтобы сервер справлялся с нагрузкой, ошибки оперативно устранялись, а на диске было достаточно свободного пространства. Рекомендуется позаботиться и об улучшении приложения: изучать отзывы клиентов и на их основе выполнить доработку: выпустить обновления, расширить функционал.
Поддержка приложения после релиза включает в себя:
Этапы разработки мобильного ПО описаны в статье лишь в общих чертах, на самом деле, это трудоемкая кропотливая работа с множеством нюансов. Компания Ясно https://yasno.mobi/team/ готова вам помочь с экспертизой на любом из этапов. Ознакомиться с услугами подробнее можно здесь.
2 способа разработки мобильных приложений
Есть 2 варианта проектирования и создания сервисов для гаджетов:
Второй вариант, безусловно, более дорогостоящий, зато он позволяет получить качественный функциональный продукт, который выходит за рамки общедоступных шаблонов. Конкретная цена проектирования и создания приложения для iOS или Android зависит от разновидности и функций ПО. Но подобные денежные вложения окупаются в перспективе.