задачи по разработке мобильного приложения
Цели и задачи создания мобильного приложения
Министерство образования Омской области
бюджетное профессиональное образовательное учреждение
Омской области«Омский государственный колледж управления
и профессиональных технологий»
Специальность 09.02.05Прикладная информатика (по отраслям)
Разработка мобильного приложения
Для фитнес-клуба
Руководитель О. А. Тимощенко
Омский государственный колледж управления и профессиональных технологий
Отделение управления и гуманитарных наук
ЗАДАНИЕ
на курсовой проект
Даркину Андрею Александровичу
Разработка мобильного приложения для фитнес-клуба
Срок представления проекта к защите
Целевая установка:Создание мобильного приложения для фитнес-клуба на основе шаблонов сервиса AppsBuilder и Java-скриптов
Содержание пояснительной записки:
Введение (цель и задачи проекта, актуальность темы проекта)
Содержание
Цели и задачи создания мобильного приложения
Проектированиеинтерфейса мобильного приложения
Разработка мобильного приложения и сборка
Заключение(основные выводы по работе, достигнутые результаты, перспективы использования)
Список литературы
1.Харди Б., Филлипс Б., Стюарт К., Марсикано К.Андроид. Программирование для профессионалов. 2-е изд. — СПб.: Питер, 2016. — 640 с.: ил. — (Серия «Для профессионалов»). ISBN 978-5-496-02051-0.
2. Дейтел П., Дейтел Х., ДейтелЭ.Андроид для разработчиков. — СПб.: Питер, 2015. — 384 с.: ил. — (Серия «Библиотека программиста»). ISBN 978-5-496-01517-2.
Руководитель работы ____________________________________________________
(подпись, дата, инициалы, фамилия)
Задание получил: _____________________________________
(подпись, дата, инициалы, фамилия)
1Цели и задачи создания мобильного приложения. 6
1.1Техническое задание. 6
1.2Целевая аудитория. 7
1.3 Диаграмма варианта использования приложения. 9
2 Проектирование интерфейса мобильного приложения. 11
2.1 Виды мобильных приложений. 12
2.2 Сравнение платформ для разработки. 15
2.3 Обзор сервисов для работы с шаблонами. 18
3 Разработка мобильного приложения и сборка. 20
3.1 Внешний вид мобильного приложения. 20
3.2 Компоненты форм приложения. 21
3.3 Программирование элементов. 26
4 Тестирование мобильного контента. 28
Список литературы.. 32
Введение
С развитием высоких технологий, позволяющих создавать персональные мобильные устройства и различные гаджеты, рынок мобильных приложений получил мощнейший стимул к развитию. Телефоны играют важную роль в повседневной работе: с их помощью читают файлы, заходят на почту, печатают документы при помощи сетевого принтера. В связи с изменениями, на рынке постепенно сформировался отдельный сегмент – мобильные приложения.
Специфика данного сегмента в том, что разработка приложений должна проводиться с учетом особенностей мобильных устройств: отличиями интерфейса, другим размером экрана, сенсорным управлением. Если интерфейс рассчитан на тактильное управление, необходимо увеличить размеры отображаемых элементов. В процессе проектирования мобильных приложений обязательно рассматриваются варианты того, как ограничить поток информации.
Благодаря тому, что рынок предлагает огромное многообразие версий мобильных устройств, каждое из них требует определенного вида платформы для работы с приложениями. Сегодня наибольшей популярностью пользуются платформы Андроид и iOS, а также BlackBerry и Linux – они актуальны для работы с корпоративными приложениями. А вот не менее популярнаяWindowsPhone ориентирована на консьюмерский сегмент.
Мобильное приложение — инструмент, с помощью которого можно помогать бизнесу продавать больше товаров и услуг и привлекать клиентов.Для сферы здоровья и фитнеса мобильные приложения разрабатываются с целью поддерживать постоянный, прямой и ненавязчивый контакт с клиентами;поддерживать свой имидж и формировать у клиента положительное отношение к своему заведению; подключить бонусную систему;накапливать положительные отзывы. Для фитнес-клуба требуются приложения, которые позволяют просматривать информацию и заказывать услуги в их заведении.
Функция EnergyZoneпомогает клиентам посмотреть курсы программ, узнать цену и заказать услугу, не тратя времени на звонки. К тому же когда клиент звонит в фитнес клуб, телефоны могут быть заняты.
Поэтому целью курсового проекта является создание мобильного приложения на основе распространённых онлайн-сервисов и элементов программного кода.В качестве задания заказчика представленомобильное приложение дляфитнес-клуба.
· оценить целевую аудиторию приложения;
· представить диаграмму варианта использования приложения;
· спроектировать интерфейс и выбрать дизайн мобильного приложения;
Цели и задачи создания мобильного приложения
Техническое задание
Полное наименование системы
Мобильное приложение «Фитнес-клубEnergyZone» для операционной системы Андроид.
Краткое наименование системы
Мобильное приложение «EnergyZone» для платформы Андроид.
Приложение «EnergyZone» предназначено для упрощения процедуры заказауслуг фитнес-клубапо Сибирскому федеральному округу. Помогая клиентам выбрать курс занятий и узнать стоимость услуг.
Цели создания системы
Приложение «EnergyZone» создается с целью:
— приём заказов на занятия в фитнес-клубе;
— реализация удобного пользовательского интерфейса;
— содействие администратору в выполнении задач управления заведением.
Требования к приспособляемости системы к изменениям
Обеспечение приспособляемости системы должно выполняться за счет:
— своевременного обновления информации об услугах;
— модернизации архитектуры и интерфейса в соответствии с новыми требованиями;
— своевременного администрирования сервера;
— оперативного реагирования на пожелания пользователей.
— приложение должно предоставлять пользователю удобный и интуитивно понятный интерфейс для быстрого доступа к информации. Интерфейс приложения должен соответствовать общей стилистике платформы.
— проектирование архитектуры и интерфейса приложения;
— сбор информации о сетифитнес-клубов;
— оптимизация и тестирование первой версии приложения;
—оптимизация и тестирование приложения;
Целевая аудитория
Оценка потенциальных пользователей или целевой аудитории позволяет:
— скорректировать виденье проекта и убрать лишнее, сэкономить средство на разработку;
— повысить эффективность работы пользователей для их удовлетворенности;
— определить только те функции, которые нужны пользователю;
— понять, что привлекает пользователя;
Изучение потенциальных пользователей и целевой аудитории необходимо для корректировки элементов интерфейса и проектирования взаимодействия в целом.
Универсальных приложений не существует. Поэтому существуют приложения, ориентированные на определенный сегмент пользователей. Пользователь во многом определяет, каким должно быть приложение. С другой стороны, приложение изначально должно быть ориентированно на определенного пользователя и создаваться исходя из его проблем, интересов, привычек и предпочтений.
Сегментация пользователей – это процесс разделения их на группы по некоторым критериям.
Определение основных сегментов пользователей приложения производится на основе значимых параметров. Среди них выделяют:
— география (США, Япония, Франция, Россия и т. д.);
— платформа и характеристики девайса (iOS, Андроид, WindowsPhone);
— социальные и демографические показатели (пол, возраст);
— дополнительные факторы, которые важны для приложения (например, сезонность);
— источники трафика (откуда пользователи заходят на страницу приложения);
Вопросы сегментации и определения целевой аудитории важны для проектирования и дизайна приложения. Дизайн, графика, объем контента, возможности приложения будут зависеть от групп предположительных пользователей продукта, т.е. мобильного приложения.
Сегментация пользователей позволяет локализировать приложение и персонализировать маркетинговую коммуникацию, что должно сказаться на эффективности коммуникационной политики мобильного приложения.
Зная, кто потенциальный пользователь приложения, можно правильно использовать ресурсы для проведения маркетинговой кампании по привлечению трафика для приложения и получению коммерческого успеха.
Сегментирование позволяет создателям приложения избежать некоторых ошибок и выделяет основные рынки сбыта приложения, а также показывает значимые сегменты пользователей, что помогает в проведении маркетинговой кампании приложения. Анализ пользователей и сегментации позволяет предвидеть различное поведение схожих сегментов пользователей, но в разных странах или условиях и избежать стереотипных представлений о пользователях.
Таким образом, для правильной сегментации необходимо:
— выделить значимые для приложения показатели пользователей;
— определить по каким законам функционирует каждый из выделенных сегментов.
Сегментация и анализ потенциальных пользователей полезен для развития и управления приложением и управлением маркетинговыми активностями.
Оценка потенциальных пользователей мобильного приложения используемого для фитнес-клубапредставлена в таблице 1.
Таблица 1 – Оценка потенциальных пользователей и сегментирования
Дата добавления: 2018-04-05 ; просмотров: 8800 ; Мы поможем в написании вашей работы!
Как сделать техническое задание на мобильное приложение
При знакомстве со студией клиент рассказывает, какое приложение он хочет получить. Все его характеристики от внешнего вида до функций фиксируются в техническом задании (ТЗ). Этот документ — руководство к действию, на него студия опирается во время разработки, чтобы создать для клиента продукт, который соответствует его ожиданиям. Но как его написать?
ТЗ по ГОСТу: поможет ли оно сделать классное приложение
У ТЗ на разработку мобильного приложения есть стандарты качества: отечественные ГОСТы и зарубежные SRS (software requirements specification). У SRS более разветвлённая структура: его содержание похоже на реферат с введением, главами, подглавами и заключением. Но и в том и в том стандарте есть общие смысловые части:
SRS популярен на западе — на российском рынке он пока не прижился. ТЗ по ГОСТу необходимо только госсектору и тем компаниям, которые с ним тесно связаны. У крупных корпораций, которые заказывают приложение, могут быть свои стандарты качества — тогда студия оформляет документы по их образцу.
Поскольку в законодательстве нет жёстких требований к проектной документации, студии мобильной разработки «настраивают» ТЗ под себя. Некоторые продолжают писать по ГОСТу — такой документ удобнее проверять: вы открываете стандарт, открываете техзадание и сверяете разделы. Ну, а больше плюсов мы не нашли. Из минусов:
Кто пишет техническое задание на мобильную разработку
Независимо от формата написать такой документ одному сложно. Клиент хорошо объясняет идею приложения на языке своего бизнеса, но не может перевести её в терминологию айти, что естественно. Для этого и существуют технические писатели и аналитики. Они помогают клиенту на техническом языке сформулировать его ожидания и закрепляют это в документе.
Люди, которые привыкли к формату официальных документов, могут спокойно работать с ТЗ по ГОСТу. Но чаще техзадание сокращают до ёмких инструкций и схем.
Проблема любых больших документов, особенно аналитических, в том, что их сложно читать как клиентам, так и самим разработчикам, поэтому мы не пропагандируем ТЗ по определённым форматам, будь то ГОСТ или зарубежные стандарты. Я за то, чтобы делать ТЗ под конкретный проект. Более того, я сторонник подхода «меньше текста без ущерба смыслу — лучше». Если можно обойтись без документа и заменить его на изображения или схемы, тем самым сократив объём, то лучше сделать именно так.
Помните, что даже самая хорошая проектная документация не гарантирует, что всё пойдёт по плану. Успех проекта зависит не от документов, а от команды разработчиков. А вот ТЗ, составленное неправильно, может навредить вашему приложению.
Как понять, что вы попали к плохому аналитику
Тратить много часов на разработку проектной документации — нормально. Не спешите убегать от аналитика, который пишет ТЗ на сложные проекты неделями. Насторожитесь, если:
Сколько стоит техническое задание
В масштабах всего проекта цена, которую клиент платит за ТЗ, небольшая. Час работы техписателя оценивается в 1500–2000 рублей. На простое приложение без бэкенда уходит 60 часов, а на сложный eCommerce можно потратить больше двухсот. Но экономить на ТЗ нельзя. В мобильной разработке оно выполняет ту же роль, что и чертёж в строительстве дома: одна неправильная линия и всё может рухнуть. Поэтому вкладываться нужно с самого начала. Компании IBM выяснила: если вы найдёте ошибку на ранних этапах разработки, исправить её будет дешевле.
Вдумчивая и внимательная работа аналитиков убережёт вас от финансовых потерь. Исключая ошибки на этапе написания технических требований, они подготовят документацию, которая станет надёжным каркасом для разработки приложения. А ещё ТЗ для вашего проекта — один раз и на всю жизнь. Вы можете передавать его вместе с приложением другой студии на поддержку и развитие. Хорошо составленное ТЗ поможет им быстрее разобраться в новом проекте.
Сейчас я работаю над приложением, в котором чувствуется необходимость ТЗ. Это нестандартный проект, у клиента имеется своя команда по разработке бэкенда, они управляют всеми заданиями, которые идут к нам. Но по тем или иным причинам информации нам недостаточно — приходится почти по каждой задаче обращаться к клиенту с вопросами, что сильно увеличивает затрачиваемое время.
— Иван Леонтьев, «Лайв Тайпинга»
Можно ли скачать готовый шаблон ТЗ
Из миллиона готовых шаблонов выбрать свой тяжело. В интернет выкладывают примеры, созданные под другие приложения, поэтому они не смогут помочь вашему бизнесу достигнуть цели. Скачивая шаблон, вы принимаете на веру потребности чужого приложения и не анализируете свои. В нём могут быть лишние пункты, которые не нужны вашему приложению. В то же время многие важные для проекта вещи останутся непрописанными, ведь автор шаблона не знал о них, когда делал ТЗ. Доверять интернету рискованно — лучше доверьтесь людям, которые напишут проектную документацию под ваши задачи.
Техническое задание без ошибок, воды, повторов — наш подход к проектной документации
Из чего может состоять проектная документация в «Лайв Тайпинге»:
1. Функциональное задание
Функциональное задание (ФЗ) — самый мощный артефакт в нашей проектной документации. К нему обращаются на каждом этапе разработки от прототипирования до релиза. На его основе дизайнеры создают экраны, разработчики пишут код, а отдел QA проводит тестирование. И при этом у него нет ни одного магического свойства. Сила ФЗ в том, что оно подробно описывает функции, которые доступны пользователю при работе с приложением. На интервью с клиентом мы узнаём, какие ролевые модели (администратор, модератор, простой пользователь) предусмотрены в приложении, и описываем набор функций для каждой роли: куда пользователь может пойти, что сделать и какой результат его ждёт. Пока мы с клиентом готовим этот артефакт, дизайнеры делают прототипы экранов, которые соответствуют возможностям приложения, прописанным в ФЗ. Готовый документ проверяют разработчики.
На этапе проектирования я полностью читаю готовое ФЗ на один раз — у меня складывается общая картина приложения. Затем я начинаю читать ФЗ на второй раз, это позволяет мне: 1) задать вопросы, которые меня интересуют, чтобы проверить документ на ошибки; 2) дополнить конкретные моменты в приложении исходя из своего опыта; 3) дать более точную оценку проекту.
— Павел Разуваев, «Лайв Тайпинга»
2. Функциональные схемы
Функциональные схемы (ФС) иллюстрируют, как простые функции приложения группируются в более сложные и взаимодействуют друг с другом. Те, у кого много очков опыта в айти, легко воспользуются этим артефактом. Но если вы ещё не подняли скилл до нужно уровня, прочитать функциональные схемы вам поможет описание компонентов системы.
3. Описание компонентов системы
Вспомогательный артефакт, который уточняет работу ФС. Схемы изображают функциональные модули и их связи, а описание подробно рассказывает о том, что это за компоненты, чтобы человеку было удобнее читать схему. Нужен, когда мы хотим пояснить детали людям из команды клиента: это могут быть как разработчики, так и те, кто не связан с программированием напрямую. Пишем его по необходимости, поэтому по шкале важности он получает только один огонёк из трёх.
4. Технические заметки
Артефакт описывает, как разработчики реализуют функции из ФЗ. Мы не хотим тратить деньги клиента на очевидные вещи, поэтому делаем технические заметки только на те места, которые кажутся нам рискованными и требующими внимания: любые алгоритмы, расчёты, интеграции.
До начала работы над проектом в техзаметках фиксируется информация, которая помогает более комплексно понимать технические требования проекта и быстро включает в него новых людей. Заметки избавляют от необходимости рассуждать на митингах, как именно реализовать ту или иную фичу. Благодаря этому ты меньше отвлекаешь тиммейтов во время работы, а тиммейты — тебя.
— Андрей Дёмин, «Лайв Тайпинга»
Мы бы очень хотели видеть технические заметки в проектах, которые приходят к нам на поддержку и развитие. Когда к нам поступает новая система, нам нужно понять, как она работает внутри. Если артефакта нет, то нам приходится разбираться в чужой работе самостоятельно — обычно это долго и больно.
5. Спецификация API (application programming interface)
API — язык, на котором приложение «общается» с серверной частью. Когда пользователь совершает действие, внутри приложения формируется запрос, который улетает в сервер, обрабатывается и возвращается в виде ответа. Спецификация устанавливает нормы этой коммуникации. Артефакт не используется в приложения без бэкенда.
6. Карта рисков
Мы составляем карту рисков для того, чтобы показать клиенту опасные места в проекте: размытые задачи и интеграции, с которыми мы ещё не работали. Почему это важно? Есть задачи, выполнение которых нельзя точно оценить в процессе проектирования. Если мы не скажем об этом клиенту, у него сложатся неверные ожидания по срокам и стоимости проекта. Артефакт получает одну комету, потому что такие задачи в нашей практике появляются редко.
7. Документация на фичу
Этот артефакт — референс к гостовскому ТЗ: он собирает технические и функциональные характеристики на одну фичу в одном месте. Нужен, когда к нам на поддержку приходит готовый проект и мы добавляем в него новые функции или исправляем баги.
Есть обязательные артефакты, без которых невозможно представить приложение, — это функциональное задание и технические заметки. В проектах, которые приходят на поддержку, их заменяет документация на фичу. Наличие остальных артефактов зависит от сложности проекта и опыта команды. Мы делаем некоторые вещи с закрытыми глазами, поэтому собираем только те документы, которые несут реальную пользу проекту. Этот подход выгоден и нам, и клиенту: мы не тратим ресурсы на банальные вещи и больше вкладываемся в то, что повлияет на работоспособность приложения и оценку пользователей.
Как «Лайв Тайпинг» сокращает затраты клиента на документацию
Чтобы вы лучше представили, как набор артефактов меняется от проекта к проекту, и поняли, что не нужно делать всё и сразу, мы расскажем про документацию, которую готовили для наших последних проектов: спортивного дневника, приложения по доставке еды и мобильного eCommerce.
Этапы разработки мобильного приложения: аналитика и техническое задание
Практическое руководство от команды студии мобильной разработки Winfox для тех, кто начинает делать свое приложение.
Что именно входит в создание приложения? Вопрос, который нам чаще всего задают клиенты. Они хотят знать, сколько денег и времени от них потребуется, как строится работа, с чего начать и как в результате заработать, а не потерять.
Этот важный вопрос, на который нельзя ответить в двух словах, вдохновил нас на публикацию этого цикла статей. В них не будет туманных советов из серии «как сделать приложение: три простых шага». Зато будет опыт, накопленный нами за пять с лишним лет работы на рынке мобильной разработки, примеры из практики и руководство к действию.
В предыдущих материалах мы рассказывали:
Сейчас поговорим о том, как строится работа над созданием мобильного приложения: что включает в себя этап аналитики и что должно быть в техническом задании.
Мы в студии обычно строим работу так:
Каждый проект — особенный. Для одного можно объединить несколько этапов в один, чтобы реализовать задуманное быстрее и дешевле. Для другого целесообразно пройти все этапы. Мы поможем выбрать оптимальный путь.
Каждое приложение начинается с идеи. Вы рассказываете нам, какие задачи должен решать будущий сервис, и мы приступаем к сбору аналитики. Глубокий срез рынка, анализ уже существующих решений, изучение конкурентов и моделей поведения покупателей… На каждом этапе анализа мы помним о конечном пользователе и продумываем жизненный цикл клиента. Это помогает нам вместе понять, как люди будут использовать новое приложение — и сделать его максимально удобным, понятным и полезным. Такой сервис принесет пользу и вашему бизнесу.
Что в результате: референсы по функциональности и дизайну.
Аналитика — принципиально важный этап. Не надо от него отказываться и начинать работу над проектом с технического задания. В процессе анализа мы понимаем, кто есть на рынке, на кого ориентироваться, а как лучше не делать. Мы обычно собираем лучшие практики и предлагаем клиенту проверенные решения, которые 100% сработают.
Мы составляем подробное описание функциональности и дизайна будущего приложения. Определяем персонажи пользователей, описываем пользовательские истории (User Story), составляем карту путешествия пользователей (Customer Journey Map) и формируем технические требования к сервису. То есть фиксируем, каким должно быть приложение, что оно должно уметь и как это будет работать.
Благодаря такому техническому заданию (ТЗ) наша команда дизайнеров и разработчиков четко понимает, какой сервис хочет получить заказчик, и поэтапно реализует первоначальную идею.
Пользовательские истории (User Story) пошагово описывают, как пользователь ведет себя в приложении: проходит авторизацию, просматривает каталог, оформляет заказ, совершает покупку. Такая история описывает задачу пользователя, которую он решает с помощью и приложения, и его конечную выгоду. В результате мы получаем список требований, который позволяет определить функциональность будущего приложения и сделать его максимально удобным для пользователя.
Допустим, вы хотите сделать приложение, с помощью которого можно будет распечатывать фотографии как фотоальбом. Основными пользовательскими историями будут создание аккаунта, выбор фотографий из фотогалереи, выбор размера альбома, оплата за альбом с помощью карты, доступ к истории заказов. Мы всегда работаем над пользовательскими историями всей командой и обязательно вместе в заказчиком. Это помогает продумать все нюансы и взглянуть на всю систему целиком, а в будущем избежать сложностей на этапе проектирования и разработки.
Карта путешествия пользователя (Customer Journey Map) позволяет наглядно представить, как разные персонажи будут пользоваться приложением в каждой из пользовательских историй. На такой карте виден весь путь пользователя — перемещение между экранами и клики на кнопки.
Составление карты помогает понять, как технически реализовать все функции приложения.
Мы делаем карту путешествия пользователя в Miro. Вся команда может работать над картой в реальном времени, а заказчик — смотреть результат в режиме презентации.
У каждой студии разработки свой подход к составлению этого документа. Мы считаем, что для успешной реализации проекта в нем должно быть отражено следующее.
2. Функциональные требования к приложению:
3. Нефункциональные требования к приложению:
4. Реализация функциональности приложения:
Не отказывайтесь от этапа аналитики. В процессе анализа мы понимаем, кто есть на рынке, на кого ориентироваться, а как лучше не делать.
Благодаря грамотно составленному ТЗ наша команда дизайнеров и разработчиков четко понимает, какой сервис хочет получить заказчик, и поэтапно реализует первоначальную идею. Чтобы правильно составить ТЗ, используйте наш чек-лист.
В следующем материале мы расскажем, что нужно знать заказчику про проектирование, дизайн и разработку.
Этот цикл статей основан на книге, которую мы недавно сделали для своих клиентов. В этой книге мы постарались ответить на основные вопросы, которые у них возникают:
Остались вопросы? Не согласны с нами? Хотите высказать свою точку зрения или поделиться опытом? Пишите в комментариях. Давайте обсуждать!