Модели жизненного цикла ПО
Бывает такое, что в процессе работы могут изменяться требования к ПО. Люди могут допускать ошибки или рынок может скорректировать процесс разработки.
Как команда будет вести себе во время таких ситуаций зависит от жизненного цикла и подходах к его развитию.
Модель жизненного цикла ПО — это схематичное представление о том, как развивается продукт.
Существуют две принципиально разные модели жизненного цикла ПО:
Каскадная модель (waterfall)
В этой модели все этапы строго зависят друг от друга. Следующий этап начинается только когда завершился предыдущий.
Цель такой модели получить продукт, который будет строго соответствовать изначальным требованиям. У это модели есть минусы из-за этого:
- Все требования к продукту нужно определить на этапе анализа. Заказчик должен четко понимать, что он хочет, а аналитик должен задать все необходимые вопросы. Оба этих сценария случаются очень редко.
- В ходе разработки не получится внести изменения
- Если на одном из этапов произойдет ошибка, команда о ней узнаёт только в конце, а значит уйдёт больше времени и ресурсов на ее исправление
Но у такой модели есть и плюсы:
- Можно просчитать ресурсы и затраты на реализацию
- Всегда понятно где команда находится сейчас и что осталось сделать для реализации
- Не требует больших затрат на коммуникацию
"Водопад" хорошо подходит для ситуаций, когда точно известно, что нужно получить в итоге.
Итерационная модель
Итерационная модель предполагает, что продукт появится в итоге не одного цикла, а в результате нескольких итераций.
Это значит, что в процессе создания ПО все этапы повторяются несколько раз. Это и является ключевым отличием от каскадной модели
У итерационной модели есть несколько подходов. Вот самые популярные из них:
Такой подход позволяет последовательно работать с разными элементами приложения таким образом, чтобы они были близки к целевому виду.
Для каждой части приложения проводятся этапы анализа, проектирования, дизайна, разработки, тестирования и внедрения.
При этом продукт, который получается в промежуточном состоянии, пока не работает так, как надо. Он ещё не реализует всю требуемую функциональность, но его отдельные опции уже можно показывать пользователям.
При итеративном подходе результаты одной итерации улучшают в течение следующей итерации. С каждой следующей итерацией функциональность становится всё ближе к целевому состоянию. В этом случае продукт будут регулярно прогонять через этапы анализа и проектирования, а у заказчика и команды появится возможность вносить правки. На выходе и те, и другие получат именно то, что хотели, — продукт, который соответствует последним актуальным требованиям.
В отличие от каскадной модели, итерационная позволяет вносить изменения по ходу разработки и учитывать эти правки в следующих итерациях. Тем самым повышается качество и актуальность конечного продукта. Но это ещё не значит, что такая модель лучше всего подходит для работы. У неё тоже есть свои недостатки: