Спринт 1/14: Понимание профессии системного аналитика → Тема 3/9: Жизненный цикл ПО, этап разработки как часть жизненного цикла ПО → Урок 2/2

Модели жизненного цикла ПО

Введение в урок

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

Даня

Артём, меня мучает вопрос! Если при работе над ПО с сервера удаляется всё или какая-то значительная часть работы, происходит серьёзная ошибка, команда начинает делать всё заново?

Артём

Иногда да, а иногда нет — зависит от модели жизненного цикла ПО. Сейчас расскажу более подробно!

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

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

Продукт был инновационный — раньше такого никто не делал. Ожидания покупателей от продукта были колоссальными. К тому же вся информация о его разработке держалась в строжайшем секрете, что также подогревало интерес к Google Glass.

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

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

Модель жизненного цикла ПО — это схематичное представление о том, как развивается продукт. Существуют две принципиально разные модели жизненного цикла ПО:

Каскадная, или waterfall («водопад»);
Итерационная.

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

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

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

Цель «водопада» — получить готовый продукт, который строго соответствует изначальным требованиям. Поэтому у такой модели есть свои минусы:

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

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

Итерационная модель

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

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

У итерационной модели есть несколько подходов, самые популярные из них:

Инкрементальный (increment — приращение, прирост). Такой подход позволяет «есть слона по частям» — последовательно работать с разными элементами приложения так, чтобы они были близки к целевому виду. Для каждой части приложения проводятся этапы анализа, проектирования, дизайна, разработки, тестирования и внедрения. При этом продукт, который получается в промежуточном состоянии, пока не работает так, как надо. Он ещё не реализует всю требуемую функциональность, но его отдельные опции уже можно показывать пользователям.

Итеративный (iteration — повтор, повторение). При итеративном подходе результаты одной итерации улучшают в течение следующей итерации. Что это значит? Уже в результате первой итерации продукт содержит требуемую функциональность, пусть и в сильно упрощённом виде. С каждой следующей итерацией функциональность становится всё ближе к целевому состоянию. В этом случае продукт будут регулярно прогонять через этапы анализа и проектирования, а у заказчика и команды появится возможность вносить правки. На выходе и те, и другие получат именно то, что хотели, — продукт, который соответствует последним актуальным требованиям.

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

Возможен и комбинированный подход — итеративно-инкрементальный.

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

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

Сложно ответить на вопрос: «Когда появится полнофункциональный продукт, который так ждут пользователи?» Особенно наглядно эта проблема проступает при итеративном подходе.
Затраченное на проект время может увеличиться за счет того, что команда несколько раз возвращается к одному и тому же функционалу и дорабатывает его.

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

После каждого этапа внедрения у ПО появляется новая функциональность.

Инкрементальный подход

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

После каждого повторения цикла разработки появляются глубоко проработанные части ПО и дополненное общее видение продукта.

Итеративно-инкрементальный подход

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

После каждого этапа внедрения функциональность становится всё ближе и ближе к целевому состоянию.

Итеративный подход

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

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

Каскадная модель

Полное соответствие изначально поставленным требованиям — характерная особенность модели waterfall.

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

Итерационная модель

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