В публикации мы рассказываем про этапы разработки мобильных приложений: от аналитики и создания ТЗ до публикации приложения в маркетплейсах и поддержки.
Аналитика и ТЗ
Первый шаг к созданию мобильного приложения – это разговор с клиентом, где мы выясняем цели и задачи приложения. Иногда клиент может сам не до конца представлять эти цели – мы поможем разобраться. Дальше исследуем рынок, изучаем уже существующие решения, проводим анализ конкурентов и целевой аудитории. Продумываем приложение так, чтобы оно было удобным и понятным для пользователя. Обсуждаем возможности по обеспечению безопасности, чтобы требования клиента к безопасности приложения соответствовали возможностям реализации.
Аналитика – это важный этап и про него не стоит забывать.
Когда мы понимаем, каким будет наполнение и функционал мобильного приложения, переходим к этапу составления ТЗ. ТЗ – это документ, который подробно и четко описывает требования к функционалу и дизайну приложения, а также описывает технические требования.
Что обязательно должно быть в ТЗ?
- Общая информация о проекте – его цели и задачи, совместимость с платформами
- Функциональные требования – какие экраны будут в приложении, сценарии взаимодействия с пользователем, интеграции с другими сервисами, архитектура баз данных, логика работы приложения, дополнительные функции
- Требования к дизайну
- Технические требования – такие как минимальная версия операционной системы iOS и Android, минимальный размер экрана устройства, адаптивность интерфейса и другие. Например, если приложение не может корректно использоваться без камеры, то в технических требованиях будет указано требование к устройству – наличие камеры.
Проработка структуры приложения
На этапе проектирования приложения создается вайрфрейм – визуализация структуры приложения. Можно сказать, что это образ дизайна низкой точности. Варфрейм выполняется в виде схем с элементами приложения, показывающих, что произойдет, если пользователь нажмёт на ту или иную ссылку. Обычно выполняется в черно-белых цветах. Вайрфреймы просты и создаются быстро, поэтому хорошо подходят для обсуждения внутри команды.
Далее идет этап прототипирования. Прототипирование показывает предварительный дизайн приложения и симулирует взаимодействие между пользователем и интерфейсом. Благодаря прототипированию мы можем примерно показать клиенту, что его ждет на выходе приложения. Прототип может быть нарисован и на бумаге, но чаще всего его конструируют в специальных программах. Он может быть более или менее детализированным – всё зависит от возможностей и требований в конкретном случае. В самых продвинутых прототипах можно протестировать почти весь функционал.
Разработка дизайна
Когда ТЗ готово, в дело вступают дизайнеры. Разрабатывается концепция дизайна - основные цвета, шрифты и стилистика. Прорабатывается каждый графический элемент UI-кита – меню, кнопки, формы, поля. Готовим макеты экранов приложения. В самом конце, при необходимости, «оживляем» приложение с помощью анимаций.
Все макеты готовятся с учетом технических требований – для каких устройств разрабатывается приложение. Дизайнер учитывает специфику работы мобильных приложений, требования к дизайну в iOS и Android. Следит за тем, чтобы дизайн мобильного приложения хорошо реагировал на каждое установленное разрешение на обеих мобильных платформах.
Разработка
Дальше разработчики пишут код – самая важная и трудозатратная часть создания приложения. Разработка делится на три этапа:
- Перенос макетов дизайна в код платформы. Для Android это xml или kotlin код, для iOS это SwiftUI, для Flutter это Dart.
- Написание кода в соответствии с требованиями из ТЗ и связывание работы кода с кодом платформы.
- Проверка работоспособности на эмуляторах и физических устройствах и оптимизация.
Тестирование
Функционал и дизайн приложения должен соответствовать заявленному. Для этого привлекаются тестировщики. В ходе тестирования выявляются различные недоработки и баги.
Тестирование — это проверка всех этапов, не только после программирования, но и после дизайна и прототипирования. Например, если в прототипе или дизайне не указали кнопку, а в ТЗ написано, что кнопка должна быть, то это баг на этапе прототипа. Также этап тестирования включает предварительный запуск приложения – бета тест.
Конечная цель тестирования – обеспечить надежное и функциональное приложение, полностью соответствующее ТЗ.
Публикация приложения
Превращаем альфа/бета версию в рабочую версию. Для публикации приложения готовим материалы – лицензию, соглашения, скриншоты и многое другое. Далее сборка проекта загружается в магазин приложений – AppStore или Google Play.
Затем приложение проходит модерацию. Сроки модерации зависят от конкретного магазина – в Google Play она проводится за пару дней, а вот в App Store займет до месяца. После прохождения модерации приложение становится доступным для скачивания из магазина.
Дальнейшая поддержка
Ни одно приложение не обходится без дальнейших доработок или развития. Иногда заказчик хочет внести правки по дизайну или функционалу, иногда нужно исправить ошибки в работе приложения, а иногда оптимизировать под новые версии операционных систем. Невозможно учесть все сценарии, и чем сложнее приложение, тем больше вероятность возникновения ошибок. Для этого и нужна техническая поддержка приложения.
В NJSoft мы всегда предусматриваем такие сценарии развития (возникновения непредвиденных ошибок) и по возможности добавляем функционал превентивного реагирования на такие случаи.