Определение требований к мобильным приложениям

1. Цели создания мобильного приложения
2. Модели сотрудничества
3. Нативное или кроссплатформенное приложение
4. Внешние интеграции
5. Определение логики мобильного приложения и функциональности
6. Автор записи

Рынок мобильных приложений развивается очень динамично в последние годы, но создание эффективной мобильной команды и эффективное управление ею требует постоянной компетентности и больших усилий. Мобильными приложениями пользуются самые разные устройства - умные часы с 1,5-дюймовыми экранами, смартфоны, планшеты, автомобили и 100-дюймовые телевизоры Smart TV. Независимо от того, на каком устройстве приложение должно работать и какие платформы использовать, проектные работы, связанные с его созданием, всегда должны начинаться с анализа бизнес-требований .

Цели создания мобильного приложения

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

Модели сотрудничества

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

Модели сотрудничества

Нативное или кроссплатформенное приложение

Определение требований стоит начать с ответа на несколько вопросов. Первое касается выбора платформ, на которых мы создаем приложение - iOS, Android, Windows Phone? Если клиент заинтересован почти в 100% охвате рынка - он решает все, но если необходимо ограничить бюджет - он выбирает только ключевые. Каждая платформа отличается и требует разного подхода при разработке функциональности. Это специфика мобильного мира - к проектам предъявляются одинаковые требования, но результирующие приложения немного отличаются. Каждое приложение адаптировано к стандартам пользовательского интерфейса целевой платформы, адаптировано к предлагаемым услугам и разработано интуитивно понятным образом для пользователей данной системы.

Вышеуказанные различия приводят к ключевому вопросу в мобильных проектах: создавать нативно или кроссплатформенно?

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

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

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

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

Внешние интеграции

Мобильные приложения обычно не работают независимо. Данные в приложении загружаются через Интернет - через механизм, называемый API (Application Programming Interface) или веб-сервисом.
Получатель услуги может также иметь свои собственные системы и базы данных для интеграции с приложением. В качестве альтернативы, поставщик услуг может создать Система управления контентом CMS (Система управления контентом), работающая через Интернет и позволяющая легко редактировать контент мобильного приложения в браузере компьютера.

Определение логики мобильного приложения и функциональности

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

Типичные этапы разработки приложения:
1. Функциональная спецификация - описывает, что должно быть включено в приложение, какие функции являются ключевыми, а какие необязательными. На этом этапе вы также должны определить целевую группу и устройства, на которых должно работать приложение.
2. Интерактивный прототип пользовательского интерфейса - на этом этапе создается прототип, представляющий приложения UX и UI. Дизайнер фокусируется на создании экранов, переходах между ними и расположении элементов пользовательского интерфейса, таких как кнопки, картинки, текст и т. Д. На этом этапе окончательный вид создается не только макетом элементов. Подготовленный таким образом прототип можно «щелкнуть», чтобы ознакомиться с работой приложения, способом представления индивидуальной информации и интуитивным характером службы. После первоначального тестирования запрашиваются исправления, а затем внедренные изменения повторно проверяются. На данном этапе они намного дешевле, чем вводить их после первой версии приложения, поэтому крайне важно усовершенствовать проект перед началом реализации.
3. Графика - после того, как прототип был утвержден, заключительным этапом является создание окончательного графика для разработанного макета элементов.

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

Прочитайте вторую часть этой статьи: Как эффективно тестировать мобильные приложения

Автор записи

Павел Смагал, JCommerce SA

Менеджер по доставке, PMO

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

Похожие

Комментарии