Разработка программного обеспечения: методологии, этапы и результаты процесса, стоимость

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

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

У нас в NLABTEAM сейчас в работе более восьми крупных проектов одновременно — и мы ведём их, используя проверенные подходы. На выходе клиенты получают решение, которое на 100% решает поставленные задачи: будь то автоматизация процессов, масштабирование собственного IT-продукта или преобразование целой отрасли.

В этой статье делимся экспертизой. Прочитав её, вы узнаете:

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

Что такое разработка программного обеспечения, и какую пользу приносит готовый продукт

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

Поможет, если вы нацелены:

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

Ниже — несколько ярких примеров, как хорошее ПО помогает решать вышеперечисленные задачи.

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

X (ранее Twitter) изначально использовалась внутри компании-разработчика Odeo. Решение так понравилось сотрудникам, что продукт коммерциализировали. Сегодня у социальной сети более 550 миллионов пользователей.

Имитатор нагрузки на систему видеоконференцсвязи (ВКС). Известнейший отечественный производитель ВКС-систем обратился к нам за разработкой имитатора нагрузки, который помог бы всесторонне протестировать его ВКС-систему, зафиксировать и устранить баги и продемонстрировать своё решение конечному заказчику.

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

Читать кейс: разработка имитатора нагрузки ВКС-систем

Методологии разработки ПО

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

Ниже разобрали, в чём особенность каждой модели, кому она подходит, какие плюсы и минусы учитывать при выборе.

Agile-модель (гибкая)

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

Например, мы проводим разработку каждой последующей фичи одновременно с тестированием фичи, разработанной до неё. Как только одна функциональность выходит из разработки, она поступает в отдел QA. Разработчики сразу берутся за следующую задачу. И так — пока не напишем и не оттестируем весь код.

Ключевой принцип Agile — как можно быстрее собрать работающий продукт. Уже после первых итераций заказчик получает функциональный прототип (MVP), пусть и с минимальным набором функций. А дальше с каждой итерацией продукт обрастает новыми возможностями в соответствии с приоритетами бизнеса.

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

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

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

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

Кому подойдёт Agile-модель:

• среднему и крупному бизнесу — при создании сложного, многокомпонентного ПО;
• стартапам на стадии роста, имеющем стабильный источник инвестиций на разработку продукта.

Каскадная (водопадная) модель

Каскадная или водопадная модель (от английского waterfall) — классическая парадигма разработки.

В водопадной модели последовательность этапов фиксирована:

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

Работа идёт только в одном направлении — мы практически никогда не возвращаемся на предыдущие этапы. Разрабатываем продукт целиком, тестируем — тоже целиком, затем выпускаем. Так, в отличие от Agile, в процессе мало гибкости.

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

Тем не менее у модели есть своё место: она хорошо ложится на простые проекты — например, разработку компонентов приложений, небольших утилит или скриптов — маленьких задач, в которых нет неопределённости, а все требования понятны заранее, устойчивы.

Кому подойдёт каскадная модель: небольшим проектам с чётким набором требований, которые точно не поменяются в процессе работы.

Инкрементная (Incremental)

Инкрементная модель совмещает две вышеописанные модели — гибкую и каскадную.

Из каскадной модели заимствуется планирование: требования и общий дизайн системы фиксируются в начале проекта. Из Agile итеративность: команда движется инкрементами, и каждый цикл реализует заранее определённый набор функций.

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

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

Кому подойдёт инкрементная модель: проектам со строго ограниченным бюджетом и срочным запросом на разработку.

Итеративная (Iterative)

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

Работа строится циклами. Каждая итерация начинается с мини-каскада: проектируем систему или фичу, пишем код и тестируем. И так раз за разом, пока не получим финальную версию.

В итеративной модели клиент вовлечён в процесс сильнее, чем в инкрементной, но слабее, чем в гибкой:

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

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

Этапы разработки программного обеспечения

Разберём, из каких этапов состоит процесс разработки программного обеспечения.

Сбор спецификаций

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

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

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

Результат этапа: проработанное с командой разработчиков техническое задание, дорожная карта проекта, чёткое понимание сроков и бюджетов проекта.

Выбор модели разработки

Что делаем: выбираем модель разработки под проект:

• гибкую;
• каскадную;
• инкрементую;
• итеративную;
• иную (моделей очень много).

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

Результат этапа: клиент получает план разработки с учётом требований проекта и выбранной с разработчиком модели. Формируется понимание, как будет реализовываться проект. Правильный выбор модели закладывает прочную основу для дальнейших работ.

Проектирование архитектуры ПО

Что делаем: продумываем, как устроена система и как взаимодействуют её компоненты.

Зачем: архитектура определяет:

• какие компоненты нужны и как между ними будет выстроен обмен данными,
• как обеспечить безопасность, масштабируемость и отказоустойчивость.

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

Создание прототипа

Что делаем: создаём интерактивный прототип продукта.

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

Результат этапа: кликабельный чёрно-белый дизайн-прототип.

Дизайн

Что делаем: разрабатываем финальное визуальное представление продукта. Создаём детализированные макеты экранов, иконки, и иллюстрации. Готовим адаптивные дизайн-макеты под различные разрешения экрана.

Результат этапа: полный набор дизайн-макетов для всех экранов и состояний продукта. Библиотеки UI-элементов, иконок, иллюстраций, разработанных в стиле бренда. Детальные спецификации для разработчиков по стилям, отступам, шрифтам и цветам.

Разработка

Что делаем: разрабатываем клиентскую и серверную части приложения на основе дизайн-макетов. На клиентской части реализуем интерфейс, а на серверной — основную бизнес-логику.

Результат этапа: бесперебойно работающее программное обеспечение.

Тестирование

Что делаем: проводим всестороннюю проверку системы. Тестируем её на соответствие изначальным требованиям с помощью 20+ видов тестов. Выявляем баги и недочёты, проверяем, насколько стабильно и быстро проект работает под нагрузкой.

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

Результат этапа: протестированное приложение, которое полностью готово к эксплуатации: ожидаемым нагрузкам, сценариям использования и пр.

Развёртывание

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

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

Управление и сопровождение

Что делаем: анализируем обратную связь реальных пользователей, собираем статистику использования, выявляем узкие места.

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

Результат этапа: стабильно работающий и активно развивающийся продукт, который приносит пользу бизнесу и пользователям. Некоторые подрядчики оказывают поддержку по гарантии в течение какого-то времени после запуска продукта: например, у нас в NLABTEAM клиент получает гарантию на поддержку в течение 6 месяцев сразу после релиза.

Что влияет на стоимость разработки ПО

Вот четыре основных фактора:

• Кол-во специалистов в проектной команде. От размера команды зависит командная ставка — усреднённая оценка одного часа работы всех вовлечённых специалистов. Большая команда стоит дороже, но если она работает слаженно, и выбрана правильная методология ведения проекта, работа идёт быстрее — а значит, и стоимость снижается соответственно.
• Сложность работы. Чем сложнее проект, тем больше времени требуется на реализацию и тем больший стоит закладывать бюджет. Разработка простого приложения может занять 3 месяца и стоить от 3 млн руб. а на многокомпонентное решение (например, разработку ERP-системы) могут потребоваться десятки миллионов в зависимости от требований к системе.
• Технологический стек. Напрямую влияет на командую ставку. Так получается, потому что оклад разработчиков зависит от технологии, её сложности, востребованности, редкости специалиста, владеющего технологией хорошо. Например, в нашей команде есть разработчики, которые пишут на C# и C++, и, поскольку людей, знающих эти языки программирования, мало, разработка удорожается.
• Грейды специалистов. Чем больше количество Senior и Middle-специалистов объективно нужны под проект, тем дороже обойдётся разработка. А чтобы предложить оптимальный прайс, хороший IT-подрядчик комбинирует специалистов разных грейдов в проектной команде, включая Junior, чтобы при высоком качестве продукта стоимость была оптимальной.

Коротко о главном

1. Разработка программного обеспечения — это процесс, в ходе которого создаётся полноценный цифровой продукт.
2. ПО используется в самых разных сферах бизнеса. Например, в медицине — сокращает количество «бумажной» работы и помогает врачам сосредоточиться на пациентах. В промышленности — помогает специалистом обмениваться документами и хранить данные в общем хранилище. В изготовлении красок — управлять колеровочным оборудованием. Примеров много.
3. Основные методологии ведения проектов в IT — Agile (гибкая), Waterfall (водопадная), инкрементная и итеративная. Однако используются и другие, всё зависит от проекта и подходов вашего подрядчика.
4. В процесс создания ПО входят этапы: сбор требований, выбор модели / методологии разработки, проектирование архитектуры, прототипирование и дизайн, разработка, тестирование и развёртывание. По результатам каждого этапа клиент получает конкретный результат.
5. На стоимость разработки влияют сложность и длительных проекта, количество и грейды специалистов и выбранный технологический стек.