Руслан Мусагитов
Алгоритм проектирования перед разработкой или с чего стоит начать любой проект?
Разработка мобильного приложения как и любого технически сложного продукта не простая задача. А так как каждое приложение уникально по своим целям и техническим решениям, задача вдвойне сложнее. Эта статья ответит на такие вопросы клиента как:
- Как будет проходить наши с ним работа?
- На какие этапы будет разделен весь процесс?
- Какие результаты клиент получит на каждом из этапов?
- Как будет проходить наши с ним работа?
- На какие этапы будет разделен весь процесс?
- Какие результаты клиент получит на каждом из этапов?
Руслан Мусагитов
Управляющий партнер, iOS - разработчик
Все участники процесса, как заказчики так и разработчики, хотят на выходе получить стабильно работающий продукт. Сдать проект в срок и не выйти за рамки бюджета.
Соблюсти все эти требования поможет качественная предварительно разработанная техническая документация.
Мы в BytePace называем это этапом проектирования. И делим этот этап на 4 обязательных шага:
Соблюсти все эти требования поможет качественная предварительно разработанная техническая документация.
Мы в BytePace называем это этапом проектирования. И делим этот этап на 4 обязательных шага:
- Сбор требований к продукту
- Разработка мокапа (англ. - mockup) продукта
- Разработка диаграммы активностей
- Разработка диаграммы классов
Сбор требований к продукту
Требования к продукту - это стартовая точка этапа проектирования. На этом этапе мы задаем клиенту много вопросов касательно продукта и его целей. Требования отвечают на следующие вопросы:
Результат:
Клиент получает документ со структурированным набором требований к продукту.
Польза:
Этот этап позволяет не двусмысленно зафиксировать функционал приложения. Синхронизировать видение заказчика и разработчика, чтобы они были "на одной волне".
- Что делает продукт?
- Как он это делает?
- Какую проблему пользователя решает?
- Какие задачи клиента решает?
Результат:
Клиент получает документ со структурированным набором требований к продукту.
Польза:
Этот этап позволяет не двусмысленно зафиксировать функционал приложения. Синхронизировать видение заказчика и разработчика, чтобы они были "на одной волне".
Разработка диаграммы активностей
Цель диаграммы - показать логику взаимодействия пользователя с продуктом и порядок работы продукта. Схема представляет из себя алгоритм работы приложения.
Результат:
Клиент получает диаграмму активностей в виде алгоритма.
Польза:
Диаграмма активностей позволяет устранить противоречия в алгоритме работы продукта. Это позволит ускорить визуализацию продукта - создание карты приложения и дизайна
Клиент получает диаграмму активностей в виде алгоритма.
Польза:
Диаграмма активностей позволяет устранить противоречия в алгоритме работы продукта. Это позволит ускорить визуализацию продукта - создание карты приложения и дизайна
Разработка мокапа продукта
На основании диаграммы активностей, мы разрабатываем мокап продукта. Мокап представляет собой карту приложения без дизайна. На карте приложения изображаются все экраны. Стрелками изображаются переходы пользователя от экрана к экрану. Определяется какой функционал на каком экране будет реализован.
Результат:
Клиент получает карту приложения без дизайна выполненную в Figma.
Польза:
Мокап позволяет устранить противоречия при разделении функционала по экранам приложения и будет основой для разработки дизайна приложения и диаграммы классов.
Клиент получает карту приложения без дизайна выполненную в Figma.
Польза:
Мокап позволяет устранить противоречия при разделении функционала по экранам приложения и будет основой для разработки дизайна приложения и диаграммы классов.
Разработка диаграммы классов:
Завершающий этап подготовки. Представляет из себя архитектуру и структуру классов продукта. Позволяет при программировании точнее разбить продукт на задачи.
Результат:
Клиент получает диаграмму классов.
Польза:
Диаграмма классов позволяет минимизировать количество ошибок, заранее выявить проблемы и решить их на этапе проектирования. Избежать проблем на этапе разработки, когда исправление будет стоить дороже. Также диаграмму классов полезно использовать при поддержке или расширения продукта.
Клиент получает диаграмму классов.
Польза:
Диаграмма классов позволяет минимизировать количество ошибок, заранее выявить проблемы и решить их на этапе проектирования. Избежать проблем на этапе разработки, когда исправление будет стоить дороже. Также диаграмму классов полезно использовать при поддержке или расширения продукта.
По завершении всех этапов мы разбиваем разработку на этапы, уточняем сроки и приступаем к написанию кода.
Спасибо за внимание!