Жизненный цикл разработки мобильного ПО

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

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

1. Процесс — процесс разработки ПО, называется жизненным циклом разработки программного обеспечения (SDLC). Мы рассмотрим все этапы разработки мобильных приложений SDLC, в том числе создание, проектирование, разработка, стабилизация, развертывание и обслуживание.
2. Рекомендации — при создании мобильных приложений следует учитывать ряд моментов, которые отличают их от классических приложений и традиционных веб-приложений. Мы рассмотрим, как они влияют на разработку мобильных приложений.

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

Жизненный цикл мобильного ПО для разработки

Жизненный цикл разработки мобильных приложений по большей части совпадает с жизненным циклом для классических или веб-приложений. Его также можно разбить на 5 основных стадий:

1. Зарождение — любое приложение начинается с формирования идеи. Как правило, хорошо продуманная идея представляет собой прочный фундамент для дальнейшей разработки приложения.
2. Проектирование — на стадии проектирования вы определяете механизм взаимодействия приложения с пользователем, его общий макет, принципы работы и другие моменты, а также проектируете на их основе пользовательский интерфейс (как правило, для этого применяется графический конструктор).
3. Разработка — как правило, это наиболее ресурсоемкая стадия создания приложения, которая заключается в его фактическом построении.
4. Стабилизация — на определенной стадии разработки обычно начинается оптимизация качества приложения путем его тестирования и исправление выявленных ошибок. Часто приложения выпускаются в виде версий для ограниченного бета-тестирования, на стадии которого более широкая пользовательская аудитория имеет возможность познакомиться с вашим приложением и поделиться своими отзывами о нем.
5. Развертывание

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

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

В последующих разделах каждая из этих стадий будет описана более подробно.

Начало

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

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

• Конкурентные преимущества — существуют ли аналогичные приложения? Если да, то чем ваше приложение выгодно отличается от других?

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

• Интеграция с инфраструктурой — в какую существующую инфраструктуру будет интегрироваться приложение и какие дополнительные возможности оно привнесет?

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

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

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

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

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

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

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

Проектирование механизма взаимодействия с пользователем

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

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

1. Apple - рекомендации по работе с человеческим интерфейсом
2. Android — рекомендации по разработке
3. UWP — основы проектирования UWP

Например, в каждом приложении реализуется концепция переключения между различными разделами приложения. В iOS для этого используется панель вкладок в нижней части экрана, в Android — панель вкладок вверху экрана, а в UWP — элемент управления Pivot или вкладка.

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

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

На современном рынке представлены устройства самых разных форм-факторов, включая промежуточные (например, между телефоном и планшетом).

Проектирование пользовательского интерфейса

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

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

Разработка

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

В оставшихся учебниках мы сосредоточимся преимущественно на стадии разработки.

Стабилизация

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

1. Прототип — приложение находится на стадии экспериментальной проверки концепции. При этом работают только его отдельные функции или части. На этом этапе в приложении могут присутствовать серьезные ошибки.
2. Альфа-версия — обычно готов код основных функциональных возможностей, однако его полное тестирование еще не завершено. На этом этапе по-прежнему присутствуют серьезные ошибки и могут отсутствовать некоторые дополнительные функции.
3. Бета-версия — большая часть функциональных возможностей завершена и прошла хотя бы предварительное тестирование с устранением ошибок. На этом этапе могут по-прежнему присутствовать основные известные проблемы.
4. Версия-кандидат — все функциональные возможности завершены и прошли тестирование. За исключением новых ошибок, приложение готово к публичному выпуску.

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

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

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

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

Распределение

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

iOS

Приложения Xamarin.iOS и Objective-C распространяются абсолютно одинаковыми способами:

1. Apple App Store — глобальный интернет-репозиторий приложений, встроенный в Mac OS X с помощью iTunes. На данный момент это самый популярный канал распространения приложений на рынке, требующий от разработчиков минимальных затрат усилий.
2. Развертывание внутри компании — предназначено для внутреннего распространения корпоративных приложений, которые не публикуются в App Store.
3. Специальное развертывание — предназначено преимущественно для разработки и тестирования и позволяет развертывать ограниченное число надлежащим образом подготовленных устройств. Так, к этой категории относится развертывание устройств с помощью Xcode или Visual Studio для Mac.

Android

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

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

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

1. AppBrain
2. Amazon App Store для Android
3. Handango
4. GetJar

UWP

Приложения UWP распространяются среди пользователей через магазин Microsoft Store. Приложения могут появиться в Store только после того, как разработчики отправят их на утверждение. Дополнительные сведения о публикации приложений Windows см. в документации UWP о публикации приложений.

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

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

Общие соображения

Multitasking

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

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

Форм-фактор

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

Фрагментация устройств и операционных систем

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

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

Ограниченные ресурсы

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

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

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

Особенности iOS

Multitasking

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

Зависящие от устройств ресурсы

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

Некоторые старые устройства (например, iPhone 3G и более ранние) и вовсе не поддерживают многозадачность.

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

Ограничения операционной системы

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

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

Особенности Android

Multitasking

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

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

Множество устройств и форм-факторов

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

Из-за столь сильной фрагментации сегмента устройств с Android, большинство разработчиков выбирают для проектирования и тестирования 5 или 6 популярных устройств, ориентируясь в работе именно на них.

Вопросы безопасности

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

Рекомендации по использованию Windows

Multitasking

Реализация многозадачности в UWP также основана на двух компонентах: жизненном цикле страниц и приложений и фоновых процессах. Каждый экран приложения представляет собой экземпляр класса Page, с которым связаны различные события активного и неактивного состояния (и специальные правила обработки таких состояний или "отметки об остановке").

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

Возможности устройства

Несмотря на то что спектр оборудования для UWP достаточно однороден, все еще существуют необязательные компоненты, которые требуют особого внимания при написании кода. К ним относятся камера, компас и гироскоп. Также существует особый класс устройств с небольшой памятью (до 256 МБ), поддержку которых разработчик может не реализовывать. Тем не менее, если они используются, этому также следует уделять особое внимание.

Вопросы безопасности

Сведения о вопросах безопасности в UWP см. в документации по безопасности.

Итоги

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

Следующие шаги

• Что такое Xamarin?
• Начало работы с Xamarin
• Совместное использование кода несколькими платформами