Модели разработки ПО: минусы и плюсы

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

Давайте рассмотрим основные модели.

1. Каскадная или водопадная модель.

Суть каскадной модели в том, чтобы все делалось строго пошагово, как показано в примере на схеме:

Программисты начинают свою работу только после формулировки требований, а тестировщики — после того, как работа программистов окончена.

Эта модель довольно проста: ее легко контролировать, планировать бюджет. Однако на разработку уходит много времени, а то, что тестирование происходит в самом конце, может привести к позднему обнаружению ошибок и долгому их исправлению.

2. V-модель — по сути продвинутая водопадная:

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

V-модель сохранила все плюсы своего предшественника. А еще улучшилось качество, ведь теперь тестирование происходит сразу на каждом этапе, и не нужно ждать завершения проекта. Минусы этой модели такие же, как и у каскадной.

3. Инкрементная модель.

В этом варианте с каждым релизом в проекте появляются какие-то новые доработки, а тестирование проводится при каждой новой итерации. 

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

Готовый продукт мы видим максимально рано, так что из плюсов этой модели — готовые в самом начале спецификации. Мы знаем, какой будет финальный продукт, еще на старте.

Из минусов — достичь конечной цели можно будет нескоро. А еще это может быть дорого и сложно спланировать.

4. Эволюционная модель.

В отличие от инкрементной при такой модели нет технического задания сразу на весь продукт. Функции наращиваются постепенно. 

В примере ниже — создание соцсети Facebook.  Изначально у Марка Цукерберга была компактная идея: общение между студентами. Все остальные функции добавлялись по ходу эволюции продукта:

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

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

На  курсе Аудит и оптимизация QA-процессов мы подробно разбираем модели и методологии разработки ПО, а наши студенты примеряют их на свои проекты. 

Вот вопрос от студентки курса:

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

Отвечает Людмила Лихогляд – сотренер курса и тест-менеджер с 11-летним опытом:

— Добрый день! Вы правы в своих выводах. Действительно, не так часто можно встретить абсолютно чистую ту или иную модель. Со временем ПО переходит на новые этапы, и тогда закономерен переход от одной модели к другой.

Более подробно о процессах в QA и  о том, как выявлять зоны риска и причины проблем в вашем проекты, мы говорим на курсе «Аудит и оптимизация QA-процессов».

Полная программа курса – по ссылке. Старт 19 августа!

Отзывы выпускников курса:

Олеся П.: Дельный курс. Легкая подача нелегкого материала. Отличные домашние задания, которые реально использовать на практике для улучшения ситуации на проекте. Рекомендую!

Карина А.: Курс однозначно помог! Мы стали использовать Jira как основной инструмент сбора показателей эффективности и качества реализации задач. Также на данный момент мы находимся в процессе деления на продуктовые команды, после чего собираемся внедрять метрики качества для измерения прогресса.