Разработка программного обеспечения: этапы и методологии
Чтобы найти достойного подрядчика для разработки ПО и суметь ещё на берегу оценить его экспертность, начать лучше всего с изучения основ. Например, познакомиться с современными этапами создания ПО и методологиями управления проектами.
У нас в NLABTEAM сейчас в работе более восьми крупных проектов одновременно — и мы ведём их, используя проверенные подходы. В этой статье делимся знаниями.
Прочитав её, вы узнаете:
- какие этапы входят в процесс разработки ПО;
- какие бывают методологии разработки;
- какой полезный результат даёт каждый из этих этапов;
- от чего зависит стоимость проекта.
Поехали!
Этапы разработки программного обеспечения
Представленные этапы разработки могут идти строго друг за другом, а могут параллельно в зависимости от проекта. Сначала рассмотрим, какие бывают этапы и что в них входит, после перейдём к вопросам выбора последовательности в рамках существующих методологий.
Сбор спецификаций
Что делаем: изучаем процессы заказчика и глубоко погружаемся в задачи бизнеса на интервью с ключевыми стейкхолдерами.
На основе полученных данных формируются требования к продукту: аналитик прописывает пользовательские сценарии, роли и активности пользователей в системе. Исходя из этого — выводит основные функции и технические требования.
В гибких (адаптивной, инкрементной и итеративной) моделях видение дорабатывается по ходу проекта. Его можно и нужно подстраивать под реалии рынка. В негибких (каскадная) это не допускается — спецификации фиксируется финально и больше не меняются.
Результат этапа: проработанное с командой разработчиков техническое задание, дорожная карта проекта, чёткое понимание сроков и бюджетов проекта.
Выбор методологии разработки
Что делаем: выбираем методологию разработки под проект:
- гибкую;
- каскадную;
- инкрементую;
- итеративную;
- иную (методологий много, и о наиболее популярных вы сможете прочитать ниже в статье).
Модель определяет, как будет проходить работа. Если у вас сложный проект, в котором требования могут менять по ходу работы и вы хотите, чтобы результаты демонстрировались раз в две недели, то присмотритесь к гибкой или итеративной модели. Если требования понятны заранее — вам подойдёт каскадная или инкрементная. Мы помогаем клиенту правильно подобрать модель исходя из специфики проекта.
Результат этапа: клиент получает план разработки с учётом требований проекта и выбранной с разработчиком модели. Формируется понимание, как будет реализовываться проект. Правильный выбор модели закладывает прочную основу для дальнейших работ.
Проектирование архитектуры ПО
Что делаем: продумываем, как устроена система и как взаимодействуют её компоненты.
Зачем: архитектура определяет:
- какие компоненты нужны и как между ними будет выстроен обмен данными,
- как обеспечить безопасность, масштабируемость и отказоустойчивость.
Результат этапа: архитектурная документация будущей системы, где описана модель обмена данными и логика продукта, в том числе показана графически.
Создание дизайн-прототипа
Что делаем: создаём интерактивный прототип продукта.
Зачем: Прототип представляет из себя кликабельный макет, в котором реализованы ключевые экраны в рамках карты пути пользователя. После утверждения прототипа и, если требуется, проведения UX-исследования, дизайнеры готовят детальные макеты интерфейсов.
Результат этапа: кликабельный чёрно-белый дизайн-прототип.
Дизайн
Что делаем: разрабатываем финальное визуальное представление продукта. Создаём детализированные макеты экранов, иконки, и иллюстрации. Готовим адаптивные дизайн-макеты под различные разрешения экрана.
Результат этапа: полный набор дизайн-макетов для всех экранов и состояний продукта. Библиотеки UI-элементов, иконок, иллюстраций, разработанных в стиле бренда. Детальные спецификации для разработчиков по стилям, отступам, шрифтам и цветам.
Разработка
Что делаем: разрабатываем клиентскую и серверную части приложения на основе дизайн-макетов. На клиентской части реализуем интерфейс, а на серверной — основную бизнес-логику.
Результат этапа: бесперебойно работающее программное обеспечение.
Тестирование
Что делаем: проводим всестороннюю проверку системы. Тестируем её на соответствие изначальным требованиям с помощью 20+ видов тестов. Выявляем баги и недочёты, проверяем, насколько стабильно и быстро проект работает под нагрузкой.
Тест-кейсы автоматизируются там, где это возможно, чтобы ускорить этап QA. Все найденные баги документируются и оперативно устраняются, клиент видит полностью соответствующий требованиям результат.
Результат этапа: протестированное приложение, которое полностью готово к эксплуатации: ожидаемым нагрузкам, сценариям использования и пр.
Развёртывание
Что делаем: на этом этапе мы готовим систему к эксплуатации в реальных условиях. В зависимости от специфики проекта и потребностей клиента, мы либо готовим финальный релиз для широкой аудитории, либо разворачиваем систему в инфраструктуре клиента.
Результат этапа: продукт установлен и готов к использованию целевой аудиторией. Все необходимые данные перенесены, интеграции настроены, пользователи обучены. Бизнес начинает получать отдачу от внедрения новой системы.
Управление и сопровождение
Что делаем: анализируем обратную связь реальных пользователей, собираем статистику использования, выявляем узкие места.
Если обнаруживаются критические ошибки, разработчики оперативно выпускают хотфиксы и патчи. В то же время они планируют дальнейшее развитие системы, дорабатывают функциональность, масштабируют инфраструктуру под растущую нагрузку.
Результат этапа: стабильно работающий и активно развивающийся продукт, который приносит пользу бизнесу и пользователям. Некоторые подрядчики оказывают поддержку по гарантии в течение какого-то времени после запуска продукта: например, у нас в NLABTEAM клиент получает гарантию на поддержку в течение 6 месяцев сразу после релиза.
Методологии разработки ПО
Каждая методология предполагает свою очерёдность этапов, рассмотренных выше.
Agile-модель (гибкая)
В Agile работа ведётся короткими спринтами (итерациями), каждый из которых представляет собой мини-проект со своим этапом анализа, проектирования, разработки и тестирования. При этом все этапы, которые можно запустить параллельно друг другу, идут параллельно.
Например, мы проводим разработку каждой последующей фичи одновременно с тестированием фичи, разработанной до неё. Как только одна функциональность выходит из разработки, она поступает в отдел QA. Разработчики сразу берутся за следующую задачу. И так — пока не напишем и не оттестируем весь код.
Ключевой принцип Agile — как можно быстрее собрать работающий продукт. Уже после первых итераций заказчик получает функциональный прототип (MVP), пусть и с минимальным набором функций. А дальше с каждой итерацией продукт обрастает новыми возможностями в соответствии с приоритетами бизнеса.
При этом качество — выше, чем при использовании других моделей. Так получается, потому что команда выстраивает процесс разработки максимально прозрачно: клиент видит, как формируется продукт практически в реальном времени, и в любой момент может высказать свои пожелания и скорректировать направление работы.
На каждый спринт выделяется жёстко очерченный период: например, две недели. В рамках итерации команда создаёт легко измеримый план и обозначает сроки готовности функционала, согласуя все решения и приоритизацию задач вместе с клиентом. Вначале берутся функции, которые приносят больше всего ценности для бизнеса.
При этом, если появляются новые идеи или требования — их органично вписывают в бэклог, а низкоприоритетные вещи переносят в другие спринты.
Так, продукт эволюционирует и подстраивается под требования и ожидания клиентов. Происходит это на протяжении всех этапов разработки. Исключается вероятность, что команда проделает ненужную работу из-за недопониманий с клиентом. Это экономит клиенту время и деньги — ведь всё время команды уходит только на нужные активности.
Кому подойдёт Agile-модель:
- среднему и крупному бизнесу — при создании сложного, многокомпонентного ПО;
- стартапам на стадии роста, имеющем стабильный источник инвестиций на разработку продукта.
Каскадная (водопадная) модель
Каскадная или водопадная модель (от английского waterfall) — классическая парадигма разработки.
В водопадной модели последовательность этапов фиксирована:
- Мы описываем требования.
- Проектируем архитектуру, интерфейс и структуры данных.
- Разрабатываем серверную и клиентскую части полностью.
- Тестируем решение и отлаживаем отдельные модули.
- Интегрируем и внедряем решение в контуре клиента / проводим релиз.
Работа идёт только в одном направлении — мы практически никогда не возвращаемся на предыдущие этапы. Разрабатываем продукт целиком, тестируем — тоже целиком, затем выпускаем. Так, в отличие от Agile, в процессе мало гибкости.
В этом и кроется главный подвох: каскадная модель не терпит ошибок и изменений. Это нормально, что недочёты закрадываются на ранней стадии, но плохо, если отловить их получается, когда работы уже проделана, а бюджет потрачен. Сроки увеличиваются — проект удорожается.
Тем не менее у модели есть своё место: она хорошо ложится на простые проекты — например, разработку компонентов приложений, небольших утилит или скриптов — маленьких задач, в которых нет неопределённости, а все требования понятны заранее, устойчивы.
Кому подойдёт каскадная модель: небольшим проектам с чётким набором требований, которые точно не поменяются в процессе работы.
Инкрементная (Incremental)
Инкрементная модель совмещает две вышеописанные модели — гибкую и каскадную.
Из каскадной модели заимствуется планирование: требования и общий дизайн системы фиксируются в начале проекта. Из Agile итеративность: команда движется инкрементами, и каждый цикл реализует заранее определённый набор функций.
Так, базовый функционал приложения наращивается от инкремента к инкременту. После каждой итерации продукт тестируется и демонстрируется заказчику.
При этом объём работ и сроки по каждому инкременту определяются на старте и остаются неизменными. В этом и есть главное отличие от Agile. В гибкой модели планы зачастую меняются, а требования подстраиваются на основе обратной связи и заказчика, и пользователей.
Кому подойдёт инкрементная модель: проектам со строго ограниченным бюджетом и срочным запросом на разработку.
Итеративная (Iterative)
Если в инкрементной модели мы на старте определяем полный набор требований и общий дизайн системы, то в итеративной — начинаем с базовых требований, а детали формулируем постепенно от итерации к итерации, в результате каждой получаем минимально жизнеспособный результат, который потом совершенствуется. В этом главное отличие двух моделей.
Работа строится циклами. Каждая итерация начинается с мини-каскада: проектируем систему или фичу, пишем код и тестируем. И так раз за разом, пока не получим финальную версию.
В итеративной модели клиент вовлечён в процесс сильнее, чем в инкрементной, но слабее, чем в гибкой:
- В отличие от инкрементной модели, где заказчик утверждает требования на начальном этапе, в итеративной модели требования корректируются по ходу работы.
- Гибкая же модель нацелена в первую очередь на безупречное качество, в отличие от итеративной модели она бескомпромиссна к этому вопросу.
Кому подойдёт итеративная модель: проектам, в которых нельзя детализировать все требования на старте, но нужны чёткие временные рамки по итерациям.
Коротко о главном
- Разработка программного обеспечения — это процесс, в ходе которого создаётся полноценный цифровой продукт.
- ПО используется в самых разных сферах бизнеса. Например, в медицине — сокращает количество «бумажной» работы и помогает врачам сосредоточиться на пациентах. В промышленности — помогает специалистом обмениваться документами и хранить данные в общем хранилище. В изготовлении красок — управлять колеровочным оборудованием. Примеров много.
- Основные методологии ведения проектов в IT — Agile (гибкая), Waterfall (водопадная), инкрементная и итеративная. Однако используются и другие, всё зависит от проекта и подходов вашего подрядчика.
- В процесс создания ПО входят этапы: сбор требований, выбор модели / методологии разработки, проектирование архитектуры, прототипирование и дизайн, разработка, тестирование и развёртывание. По результатам каждого этапа клиент получает конкретный результат.
- На стоимость разработки влияют сложность и длительных проекта, количество и грейды специалистов и выбранный технологический стек.
