жизненный цикл разработки мобильного приложения
Введение в жизненный цикл разработки мобильных приложений
Некоторые аспекты при разработке мобильных приложений
В этой статье рассматриваются жизненный цикл разработки мобильных приложений и некоторые принципы, необходимые для разработки мобильных проектов. Для разработчиков, желающих перескочить дальше и сразу начать строить проекты, эта статья может быть пропущена и прочитана позже, для более глубокого понимания основ разработки для мобильных устройств.
Обзор
В этом документе мы проведём тщательную экспертизу создания и развития мобильных приложений, включая:
Этот документ предназначен для того, чтобы ответить на фундаментальные вопросы о разработке мобильных приложений, одновременно как для начинающих, так и для опытных разработчиков. Требуется комплексный подход, что бы ознакомиться с большинством из вопросов, с которыми Вы столкнетесь во время всего Жизненного цикла разработки программного обеспечения (SDLC). Однако этот документ может не быть не обязательным для всех. Если у Вас уже чешутся руки начать разработку приложений, мы рекомендуем проскочить вперед или к обучающим программам Введение в разработку для мобильных устройств, Hello, Android или Hello, iPhone, а затем возвратиться к этому документу позже.
Жизненный цикл разработки программного обеспечения
Жизненный цикл разработки мобильных приложений практически ничем не отличается от SDLC для веб и настольных приложений. Как и в случае с ними, существуют, как правило, 5 основных фаз процесса:
Зачастую многие из этих фаз перекрывают друг друга, например, когда разработка уже идёт полным ходом, в то время, когда пользовательский интерфейс ещё только завершается, и разработка может изменить первоначальную версию UI. Кроме того, приложение может быть в стадии опытной эксплуатации, а в фазе разработки уже добавили новые функции, которые будут закреплены в новой версии программы.
Кроме того, эти фазы могут использоваться в любом количестве методологий SDLC таких как Гибкая методология разработки, Спиральная модель, Каскадная модель и т.д.
Давайте теперь рассмотрим, какую определенную роль каждая из этих фаз играют в развитии мобильного приложения.
Начальная стадия
Широкое распространение мобильных устройств и уровень взаимодействия людей с ними подразумевает, что почти у каждого человека есть идея для мобильного приложения. Мобильные устройства открывают совершенно новый способ взаимодействия с вычислительной техникой, интернетом и даже корпоративной инфраструктурой.
Начальная стадия — это определение и уточнение идеи приложения. Для создания успешного приложения, важно задать некоторые фундаментальные вопросы. Например, если вы разрабатываете приложение для распространения в общественном магазине приложений (App Store, Google Play), некоторые соображения являются:
Если Вы планируете для приложения взаимодействие с уже существующими проектами:
Кроме того, следует оценить использование приложения в мобильном форм-факторе:
Дизайн мобильных приложений
Как только у Вас есть замечательная идея того, что Вы хотите проектировать, следующий шаг – начать проектировать User eXperience или UX.
UX Дизайн
В UX обычно используют каркасы или макеты с помощью таких инструментов, как Balsamiq, Mockingbird, Visio, или просто с помощью старых и добрых инструментов: ручки и бумаги. UX-макеты позволяют быстро разрабатывать UX, без необходимости беспокоиться о фактическом дизайне пользовательского интерфейса:
При создании UX-макетов, важно учитывать рекомендации для интерфейса различных платформ, для которых вы разрабатываете. Придерживаясь этих рекомендаций, вы можете быть уверены, что ваши приложения будут чувствовать себя как дома на каждой платформе. Вы сможете найти рекомендации для различных платформ по ссылкам:
Например, у каждого типа приложения есть метафора для переключения между разделами в приложении. iOS использует таббар внизу экрана, Android использует таббар cверху экрана, и Windows Phone использует панораму:
Кроме того, сами аппаратные средства также диктуют решения для UX. Например, устройства на iOS физически не имеют кнопки «Назад», и поэтому вводится метафора Навигационного диспетчера:
Форм-фактор также влияет на UX решения. Планшет имеет гораздо большую площадь, так что на экран вы можете поместить больше информации, и зачастую несколько экранов телефона сжимается в один экран для планшета:
И из-за большого количества форм-факторов зачастую используются форм-факторы среднего размера (что-то между телефоном и планшетом), для которого вы можете настроить таргетинг.
Дизайн пользовательского интерфейса (UI)
Что бы вдохновиться хорошим дизайном, посетите следующие ресурсы:
Кроме того, вы можете найти портфолио графических дизайнеров на таких сайтах, как Behance.com и Dribbble.com. Дизайнеров со всего мира можно найти чаще всего в тех местах, где обменный курс наиболее благоприятен, так что хороший графический дизайн не обязательно должен стоить много.
Разработка
Этап разработки, как правило, начинается очень рано. На самом деле, как только идея имеет некоторое созревание в фазе концепция / вдохновение, зачастую уже работает разработанный прототип, который проверяет функциональность, предположения, и помогает дать представление о масштабах работы.
Пробная эксплуатация (Стабилизация)
Стабилизация является процессом работы над ошибками в вашем приложении. Не только с функциональной точки зрения, например: «Программа выходит из строя при нажатии на эту кнопку», но и удобство использования и производительность Лучше всего начать стабилизацию как можно раньше в процессе разработки, так, что бы изменения курса смогли произойти прежде, чем они станут очень затратными. Как правило, приложения проходят стадии: Прототип, Альфа, Бета и Релиз-кандидат. Разные люди по-разному определяют их, но они как правило, следуют следующему шаблону:
Никогда не рано начать тестирование приложения. Например, если основная проблема обнаруживается на стадии прототипа, UX все еще можно изменить для его изменения. Если проблема функционала обнаруживается на альфа-стадии, следует, как можно раньше изменить архитектуру, перед тем, как основной код будет основываться на не верном базисе.
Как правило, когда приложение перемещается дальше по своему жизненному циклу, оно становится доступным для большего количества людей, чтобы его попробовать, протестировать, обеспечивать обратную связь, и т.д. Например, прототип приложения может быть показан и доступен только для ключевых заинтересованных сторон, тогда как релиз-кандидат приложения может распространяться среди клиентов, которые подписались для раннего доступа.
Для раннего тестирования и развертывания на относительно небольшое число физических устройств, обычно достаточно развертывание прямо с компьютера разработки. Однако, когда аудитория расширяется, это может быстро стать не удобным. На этот случай существует несколько тестовых вариантов развертывания, которые заметно облегчают этот процесс, позволяя Вам пригласить людей в пул тестирования, предоставляют релиз сборки через Интернет и средства для обратной связи с пользователем.
Некоторые, наиболее популярных из этих сервисов:
Распространение
После того как вы стабилизировался приложение, пришло время, чтобы доставить его в мир. Есть целый ряд различных вариантов распространения, в зависимости от платформы.
Xamarin.iOS и Objective-C приложения распространяются таким же образом:
Android
Все Android приложения должны быть подписаны перед распространением. Разработчики должны подписать своё приложение, используя свой собственный сертификат, защищенный закрытым ключом. Этот сертификат предоставляет цепочку достоверности, которая связывает разработчика и приложения, которые он создал и распространяет. Необходимо отметить, что, хотя сертификат разработчика для Android может быть подписан доверенным центром сертификации, большинство разработчиков не предпочитают использовать эти услуги и самостоятельно подписывать свои сертификаты. Основной целью использования сертификатов является необходимость различать разных разработчиков и приложений. Андроид использует эту информацию для разрешения выполнения и делегирования прав доступа приложениям и компонентам, запущенными в ОС Android.
В отличие от других популярных мобильных платформ, Android проявляет очень открытый подход к распространению приложения. Устройства не привязаны к единственному, одобренному хранилищу приложений. Напротив, любой в праве создать своё хранилище приложений, и большинство телефонов на базе Android позволяет приложениям быть установленными из этих сторонних магазинов.
Это позволяет разработчикам иметь потенциально более крупный, еще более сложный канал для распространения своих приложений. Google Play — это официальное хранилище приложений Google, но есть и многие другие. Вот несколько наиболее популярных:
Windows Phone
Приложения Windows Phone распространяются пользователям через Windows Store. Разработчики предоставляют свои приложения в Центр Разработки (Dev Center) Windows Phone для утверждения, после чего они появятся в магазине.
Microsoft предоставляет подробные инструкции для развертывания приложений Windows Phone, в процессе разработки.
Выполните следующие действия для бета-тестирования и публикации в магазине. Разработчики могут представить свои приложения, а затем предоставить установочную ссылку для тестеров, прежде чем приложение будет рассмотрено и опубликовано.
Аспекты разработки мобильных приложений
Разработка мобильных приложений принципиально не отличается, от разработки традиционных веб или настольных приложений с точки зрения процесса или архитектуры, но есть некоторые аспекты, которые следует иметь в виду.
Для начала рассмотрим общие аспекты, а затем мы рассмотрим специфические аспекты для каждой платформы.
Общие аспекты
Многозадачность
Есть две существенные проблемы с многозадачностью (имея несколько приложений, работающих одновременно) на мобильном устройстве. Во-первых, учитывая ограниченный по площади экран, трудно одновременно отображать несколько приложений. Таким образом, на мобильных устройствах только одно приложение может быть одновременно на переднем плане. Во-вторых, наличие нескольких открытых приложений и выполнение задач могут быстро съесть заряд батареи.
Каждая платформа обрабатывает многозадачности по-своему, что мы немного рассмотрим.
Форм-фактор
Мобильные устройства обычно делятся на две категории: телефоны и планшеты, с несколькими устройствами кроссоверами между ними. Проектирование для этих форм-факторов как правило, очень похоже, однако, разработка приложений для них могут быть очень разными. Телефоны имеют очень ограниченный пространством экран. А планшеты имеют экран иногда даже больший, чем у большинства ноутбуков, хотя являются по-прежнему мобильными устройствами с меньшим пространством на экране. Вследствие этого элементы управления пользовательского интерфейса мобильной платформы были разработаны специально для того, чтобы быть эффективным на малых форм-факторов.
Устройство и фрагментация ОС
Важно принимать во внимание различия устройств на протяжении жизненного цикла разработки программного обеспечения:
Ограниченность ресурсов
Мобильные устройства постоянно становятся все более мощными, но они до сих пор являются мобильными устройствами, которые имеют ограниченные возможности по сравнению с настольными или портативными компьютерами. Например, разработчики настольных приложений вообще не беспокоиться о ёмкости памяти; они привыкли к тому, что как физическая, так и виртуальную память всегда в избытке, в то время как на мобильных устройствах вы можете быстро израсходовать всю доступную память только при загрузке несколько высококачественных фотографий.
Кроме того ресурсоемкие приложения, такие как игры или программы распознавания текста может серьёзно загрузить мобильный процессор и отрицательно повлиять на производительность устройства.
Исходя из подобных соображений, важно писать очень хороший код, а также как можно раньше и чаще обращаться к физическим устройствам для проверки реагирования.
Аспекты iOS
Многозадачность
Многозадачность очень жёстко контролируется в iOS, и существует целый ряд правил и режимов, которым ваше приложение должно соответствовать, особенно когда другое приложение выходит на передний план, в противном случае ваше приложение будет прекращено iOS.
Специфические для устройства ресурсы
В рамках конкретных форм-факторов аппаратное обеспечение может сильно отличаться у различных моделей. Например, некоторые устройства имеют заднюю камеру, некоторые также имеют фронтальную камеру, у некоторых нет ни одной.
Некоторые старые устройства (iPhone 3G и старше) даже не поддерживают многозадачности.
Из-за этих различий между моделями, устройства важно проверить на наличие компонента, прежде чем пытаться его использовать.
Специфические аспекты ОС
Для того чтобы убедиться, что приложения отвечают и безопасны, ОС iOS заставляет соблюдать ряд правил, которые приложения должны соблюдать. В дополнение к правилам в отношении многозадачности, существует целый ряд методов событий, из которых ваше приложение должно вернуться в определенное количество времени, в противном случае оно будет прекращено ОС.
Также стоит отметить, что приложения работают в среде, известной как «песочница», которая обеспечивает соблюдение мер безопасности, которые ограничивают, к каким ресурсам ваше приложение может получить доступ. Например, приложение может читать и записывать свой собственный каталог, но если оно попытается записать в каталог другого приложения, оно будет прекращено.
Аспекты Android
Многозадачность
Многозадачность в Android имеет две составляющей; во-первых, это жизненный цикл Активности. Каждый экран Android-приложения может находится находится в разных состояниях Активности, и существует определенный набор событий, которые происходят, когда приложение находится в фоновом режиме или выходит на передний план. Приложения должны придерживаться этого жизненного цикла для создания отзывчивого и «хорошо себя ведущего» приложения. Для получения дополнительной информации обратитесь к руководству жизненный цикл Активности.
Вторая составляющая многозадачности в Android является использование сервисов. Сервисы — долго работающие процессы, существующие независимо от приложения и используются для совершения действий, в то время как приложение работает в фоновом режиме. Для получения дополнительной информации обратитесь к руководству по созданию сервисов.
Множество устройств и множество форм-факторов
В отличие от iOS, которая имеет небольшой набор устройств, или даже Windows Phone, которая работает только на рекомендуемых устройствах, удовлетворяющих минимальный набор требований к платформе, Google не накладывает никаких ограничений, на каких устройствах можно запустить Android OS. Результат этой открытой парадигмы в среде устройства – множество различных устройств с очень разными аппаратными характеристиками, разрешениями и пропорциями экрана, возможностями и потенциалом.
Из-за крайней фрагментация Android устройств большинство людей выбирают наиболее популярные 5 или 6 моделей для проектирования и тестирования, и ориентируются на них.
Аспекты безопасности
Приложения в ОС Android все работают под отдельным, изолированным пользователем с ограниченными правами. По умолчанию приложения мало что могут делать. Например, без специальных разрешений, приложение не может отправить текстовое сообщение, определить состояние телефона, или даже получить доступ к Интернету! Для доступа к этим функциям, приложения обязаны указать в своем файле манифеста, какие права они хотели бы получить. При установке приложения, операционная система считывает эти разрешения, уведомляет пользователя о том, что приложение запрашивает эти разрешения, а затем позволяет пользователю продолжить или отменить установку. Это является важным шагом в модели распространения Android, из-за открытой модели магазина приложений, поскольку приложения не рассматриваются магазином, как, например, для iOS. Для получения списка разрешений для приложений см. справочную статью Manifest.Permissions в Android документации.
Аспекты Windows Phone
Многозадачность
Многозадачность в Windows Phone также имеет две составляющих: жизненный цикл для страниц и приложений, а также фоновые процессы. Каждый экран в приложении является экземпляром класса Page, который имеет события, связанные состояниями активности или неактивности (со специальными правилами обработки в неактивном состоянии или состояния «убит»). Для получения дополнительной информации см. Обзор выполнения модели для Windows, Телефон документации Обзор модели выполнения для Windows Phone.
Возможности устройства
Хотя аппаратное обеспечение Windows Phone является довольно однородным из-за строгих указаний, предоставленных Microsoft, все еще существуют компоненты, которые считаются дополнительными, и поэтому требуют специального рассмотрения во время программирования. Дополнительные аппаратные возможности включают в себя камеру, компас и гироскоп. Существует также особый класс низкой памяти (low-memory = 256 МБ), который требует особого внимания или разработчики могут отказаться от поддержки low-memory.
Базы данных
Обе ОС, iOS и Android содержат ядро базы данных SQLite, которое позволяет организовать сложное хранилище данных и является кросс-платформенным. Windows Phone 7 вообще не поддерживает базы данных, в то время как Windows Phone 7.1 и 8 имеет локальное ядро базы данных, к которому можно выполнять только LINQ to SQL запросы и оно не поддерживает запросы Transact-SQL. Тем не менее, существует библиотека SQLite с открытым исходным кодом, которое может использоваться в приложениях Windows Phone, чтобы обеспечить поддержку знакомого Transact-SQL и кросс-платформенную совместимость.
Аспекты безопасности
Приложения Windows Phone запускаются с ограниченным набором разрешений, которые изолируют их друг от друга и ограничивают операции, которые они могут выполнять. Доступ к сети должны выполняться через конкретных API и взаимодействия между приложениями может быть сделано только через контролируемые механизмы. Доступ к файловой системе тоже ограничен. API-интерфейс изолированного хранилища предоставляет пару «ключ значение» для хранения и возможность создавать файлы и папки в в управляемом режиме.
Доступ приложения к функциям аппаратного обеспечения и операционной системы контролируется возможностями, перечисленными в его файле манифеста (по аналогии с Android). Манифест должен объявлять используемые функции, необходимые для работы приложения, так, что бы пользователи могли увидеть и согласиться с этими разрешениями, а также тем, что операционная система позволяет получить доступ к API. Приложения должны запрашивать доступ к функциям, таким как контакты или информация об оборудовании, камеры, местоположение, медиа-библиотека и многое другое.
Этапы разработки мобильного приложения: аналитика и техническое задание
Практическое руководство от команды студии мобильной разработки Winfox для тех, кто начинает делать свое приложение.
Что именно входит в создание приложения? Вопрос, который нам чаще всего задают клиенты. Они хотят знать, сколько денег и времени от них потребуется, как строится работа, с чего начать и как в результате заработать, а не потерять.
Этот важный вопрос, на который нельзя ответить в двух словах, вдохновил нас на публикацию этого цикла статей. В них не будет туманных советов из серии «как сделать приложение: три простых шага». Зато будет опыт, накопленный нами за пять с лишним лет работы на рынке мобильной разработки, примеры из практики и руководство к действию.
В предыдущих материалах мы рассказывали:
Сейчас поговорим о том, как строится работа над созданием мобильного приложения: что включает в себя этап аналитики и что должно быть в техническом задании.
Мы в студии обычно строим работу так:
Каждый проект — особенный. Для одного можно объединить несколько этапов в один, чтобы реализовать задуманное быстрее и дешевле. Для другого целесообразно пройти все этапы. Мы поможем выбрать оптимальный путь.
Каждое приложение начинается с идеи. Вы рассказываете нам, какие задачи должен решать будущий сервис, и мы приступаем к сбору аналитики. Глубокий срез рынка, анализ уже существующих решений, изучение конкурентов и моделей поведения покупателей… На каждом этапе анализа мы помним о конечном пользователе и продумываем жизненный цикл клиента. Это помогает нам вместе понять, как люди будут использовать новое приложение — и сделать его максимально удобным, понятным и полезным. Такой сервис принесет пользу и вашему бизнесу.
Что в результате: референсы по функциональности и дизайну.
Аналитика — принципиально важный этап. Не надо от него отказываться и начинать работу над проектом с технического задания. В процессе анализа мы понимаем, кто есть на рынке, на кого ориентироваться, а как лучше не делать. Мы обычно собираем лучшие практики и предлагаем клиенту проверенные решения, которые 100% сработают.
Мы составляем подробное описание функциональности и дизайна будущего приложения. Определяем персонажи пользователей, описываем пользовательские истории (User Story), составляем карту путешествия пользователей (Customer Journey Map) и формируем технические требования к сервису. То есть фиксируем, каким должно быть приложение, что оно должно уметь и как это будет работать.
Благодаря такому техническому заданию (ТЗ) наша команда дизайнеров и разработчиков четко понимает, какой сервис хочет получить заказчик, и поэтапно реализует первоначальную идею.
Пользовательские истории (User Story) пошагово описывают, как пользователь ведет себя в приложении: проходит авторизацию, просматривает каталог, оформляет заказ, совершает покупку. Такая история описывает задачу пользователя, которую он решает с помощью и приложения, и его конечную выгоду. В результате мы получаем список требований, который позволяет определить функциональность будущего приложения и сделать его максимально удобным для пользователя.
Допустим, вы хотите сделать приложение, с помощью которого можно будет распечатывать фотографии как фотоальбом. Основными пользовательскими историями будут создание аккаунта, выбор фотографий из фотогалереи, выбор размера альбома, оплата за альбом с помощью карты, доступ к истории заказов. Мы всегда работаем над пользовательскими историями всей командой и обязательно вместе в заказчиком. Это помогает продумать все нюансы и взглянуть на всю систему целиком, а в будущем избежать сложностей на этапе проектирования и разработки.
Карта путешествия пользователя (Customer Journey Map) позволяет наглядно представить, как разные персонажи будут пользоваться приложением в каждой из пользовательских историй. На такой карте виден весь путь пользователя — перемещение между экранами и клики на кнопки.
Составление карты помогает понять, как технически реализовать все функции приложения.
Мы делаем карту путешествия пользователя в Miro. Вся команда может работать над картой в реальном времени, а заказчик — смотреть результат в режиме презентации.
У каждой студии разработки свой подход к составлению этого документа. Мы считаем, что для успешной реализации проекта в нем должно быть отражено следующее.
2. Функциональные требования к приложению:
3. Нефункциональные требования к приложению:
4. Реализация функциональности приложения:
Не отказывайтесь от этапа аналитики. В процессе анализа мы понимаем, кто есть на рынке, на кого ориентироваться, а как лучше не делать.
Благодаря грамотно составленному ТЗ наша команда дизайнеров и разработчиков четко понимает, какой сервис хочет получить заказчик, и поэтапно реализует первоначальную идею. Чтобы правильно составить ТЗ, используйте наш чек-лист.
В следующем материале мы расскажем, что нужно знать заказчику про проектирование, дизайн и разработку.
Этот цикл статей основан на книге, которую мы недавно сделали для своих клиентов. В этой книге мы постарались ответить на основные вопросы, которые у них возникают:
Остались вопросы? Не согласны с нами? Хотите высказать свою точку зрения или поделиться опытом? Пишите в комментариях. Давайте обсуждать!