В третьей части мы познакомились с понятием SDLC. Думаю, у части читающих могли возникнуть довольно обоснованные вопросы: "Действительно ли следуя этапам можно разработать качественный продукт? Что делать, если в ходе тестирования найдена ошибка и требуется доработать продукт, а этап разработки уже пройден?". Это базовые вопросы, которые приходят в голову, но если поразмыслить, можно придумать намного больше.
И тут нам на помощь приходят модели жизненного цикла. Для начала стоит дать определение.
Модель жизненного цикла ПО — описание того, как проходит процесс разработки ПО, какие этапы проходит ПО - от рождения идеи до завершения использования и что происходит с ПО на этих этапах.
Таких моделей достаточно много. В основном в литературе описываются следующие:
- Code and fix (модель кодирования и устранения ошибок).
- Waterfall Model (каскадная модель, или «водопад»).
- V-model (V-образная модель, разработка через тестирование).
- Incremental Model (инкрементная модель).
- Iterative Model (итеративная или итерационная модель).
- Spiral Model (спиральная модель).
- The chaos model (модель хаоса).
- Prototype Model (прототипная модель).
В данной статье я бы хотел рассмотреть четыре основные модели: водопадную, инкрементную, итеративную и инкрементно-итеративную как самые используемые в современной разработке.
Также хотел бы сразу ввести ещё один интересный термин:
Minimal Viable Product (MVP, минимально жизнеспособный продукт) — тестовая версия товара, услуги или сервиса с минимальным набором функций (иногда даже одной), которая несет ценность для конечного потребителя.
Waterfall Model (каскадная модель, или «водопад»)
Основная фишка этой модели — все этапы жизненного цикла (SDLC) выполняются последовательно и существуют определённые условия для перехода с одного этапа на другой. Отсутствует возможность начать следующий этап, не завершив предыдущий. Также после перехода на следующий этап либо невозможно вернуться назад, либо возврат назад очень сложен и ресурсозатратен. Тестирование в данной модели начинается поздно.
Водопадная модель обычно используется при создании ПО, для которого можно достаточно точно и полно сформулировать все требования на первых этапах SDLC. Её зачастую используют в государственных организациях, где требуется высокая отчётность; при позитивном опыте разработки похожих систем (когда риски возврата на предыдущий этап минимальные); для недорогих и несложных проектов.
Плюсы модели:
- Простота;
- В один момент времени выполняется только один этап - легко контролировать результаты проекта;
- Можно рано спрогнозировать стоимость проекта (за счёт проработанных требований).
Минусы модели:
- MVP получаем поздно (так как требуется последовательное выполнение всех этапов);
- Используется много документации (по завершению каждого этапа);
- Участники команды нагружены неравномерно (пока разработчики работают весь день, тестировщики только ждут, когда они закончат);
- Отсутствие обратной связи от пользователей;
- Высокая стоимость и сложность возврата на предыдущий этап при необходимости (например, для уточнения требований или фикса (исправления) ошибок).
Инкрементная модель
Разработка в этой модели идёт по так называемым "инкрементам".
Инкремент — это постоянно увеличивающаяся величина.
Продукт в процессе разработки постоянно увеличивается, «наращивается».
Первое, что создаётся в этой модели, — минимально работающий продукт (MVP), который можно быстро выпустить на рынок, получить обратную связь от пользователей, а затем продолжить его развивать, постепенно расширяя и улучшая функционал приложения.
К примеру, при разработке онлайн-магазина, мы можем в рамках одной SDLC цепи (всех этапов, которые есть в рамках SDLC) разработать и протестировать авторизацию, регистрацию и возможность бронирования продукта(-ов) в магазине. Да, мы реализовали не все функции, которые хотим в конечном продукте, НО мы уже сейчас можем выпустить данный сайт на рынок и собрать обратную связь, а также получить первую прибыль.
Далее, повторяя такой процесс циклично для следующих версий мы всегда будем иметь на рынке новый и рабочий инкремент.
Инкрементная разработка
Если привести совсем простую аналогию, то просто следуем взглянуть на данную иллюстрацию:
Тут изображено три инкремента. Целевая картина, конечно, третья. Но при этом уже на первом инкременте мы могли бы выставить картину (в нашем случае информационную систему) на рынок :)
Данная модель используется в проектах, в которых требования сформулированы заранее и необходима быстрая поставка на рынок.
Плюсы:
- Меньше расходов, чем в водопадной модели;
- Быстрая обратная связь от пользователей;
- Снижает риск неудач при изменении требований.
Минусы:
- Сложность в понимании какой функционал выбрать за текущий инкремент;
- Риск тенденции к откладыванию реализации сложной функциональности на последующие инкременты;
- Требуются чёткие и полные требования.
Итеративная или итерационная модель
Разработка идёт циклами, которые называют "итерациями". Каждая итерация представляет собой 'мини-водопад'. Результатом каждой итерации должна быть законченная часть (именно часть!) функционала.
На первом этапе в этой модели требования могут быть весьма условными или их может не быть вовсе. В процессе разработки требования разрабатываются, уточняются, изменяются в зависимости от потребностей заказчика, пользователей, состояния рынка и так далее.
К в таком случае бы выглядела наша "Мона Лиза"?
Плюсы:
- Быстрый выпуск MVP;
- Снижение рисков на ранних стадиях;
- Равномерная загрузка команды (тестировщики уже не отдыхают во время разработки);
- Раннее обнаружение ошибок;
- Можно работать в условиях неполной спецификации.
Минусы:
- Отсутствие фиксированного бюджета и сроков;
- Отсутствует понимание конечной цели (так как требования постоянно дополняются и меняются).
Модель отлично подходит для проектов с неопределенными или слабо определенными требованиями, а также для инновационных проектов, где высок риск изменения решений на каждом этапе SDLC.
Итеративно-инкрементная модель
Современная классика подходов к разработке ПО.
Ключевая особенность данной модели — разбиение проекта на относительно небольшие промежутки (итерации), каждый из которых включает в себя все или часть этапов SDLC.
Итогом итерации является приращение (инкремент) функциональности продукта, выраженное в новой версии.
Тем самым получаем вот такое:
Инкремент добавляет совершенно новые функции, тем самым расширяя объем предлагаемых функций. При этом каждый инкремент, скорее всего, также усовершенствует существующую функциональность, что делает его итеративным.
Дополнительная литература:
Всем спасибо за чтение! Жду вопросов и вашей обратной связи :)