Жизненный цикл ПО

Жизненный цикл ПО – это описание типичного пути развития программного обеспечения, от идеи (рождения) до прекращения поддержки (смерти). Жизненный цикл программного обеспечения включает в себя:

• Фазы. Этапы жизни ПО.
• Парадигмы. Набор основных идей, которыми нужно руководствоваться при разработке. 
• Модели. Реализация парадигм.

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

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

Жизненный цикл программного обеспечения – что это

С общим определением цикла разработки программных продуктов мы уже познакомились, здесь расскажем, зачем он нужен. Причина, как всегда, кроется в деньгах. Когда заказчик придумывает идею, которая должна принести деньги, ему нужно посчитать потенциальную прибыль. А чтобы посчитать ее, ему нужно знать, сколько он потратит на разработку. Чтобы посчитать ее, он приходит в отдел разработки и говорит: «Хочу сделать лучший в мире калькулятор и выпустить его на смартфоны. Сколько с меня?». И теперь уже отделу разработки нужно считать, сколько они возьмут, а для этого им нужно разбить весь процесс разработки на конкретные шаги и посчитать затраты на каждый шаг – получаем конкретные изолированные этапы в стадиях жизненного цикла продукта.

Но просто выделить этапы и посчитать деньги – недостаточно. Разработка – это динамичный процесс взаимодействия многих людей. На ранних этапах развития компьютеров действительно можно было накидать простенькую программу и отдать ее заказчику. Сейчас процесс стал намного более сложным: нужно где-то программу развернуть; нужно посмотреть, как она зайдет пользователям; нужно внести изменения и отловить баги; наконец, нужно улучшать приложение, если оно выходит в плюс. Чтобы учесть все эти факторы, нужно что-то более серьезное, чем этапы жизненного цикла.

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

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

Со временем, когда рынок стал активнее, у каскадной парадигмы обнаружилась проблема: ее методы не умеют подстраиваться под динамику рынка. Microsoft запустила в разработку Windows 2000, 3 года делала ее из беты в релиз, когда Windows 2000 вышла – оказалось, что она никому уже не нужна, 3 года работы потрачены впустую. Чтобы такого не повторять, придумали новую парадигму: итеративная разработка. Основная мысль: собираем все требования заказчика и режем их на небольшие финализированные блоки. Сделали блок – получили какой-то минимальный продукт – выбросили его на рынок. Пользователям понравилось – взяли еще один блок функциональности, добавили в уже работающее приложение, снова выкинули на рынок. Все еще приносит прибыль – повторяем.

Если из каскадной парадигмы разработки вышло в лучшем случае 3-4 метода, то из итеративной парадигмы вышел десяток минимум. Есть еще пара методов на стыке методологий – спиральная модель, например – но основным циклом создания программного обеспечения считается Scrum, который – полностью итеративный. То есть история показала, что итерации – лучше для бизнеса, чем каскадная разработка.

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

Если пока не очень понятно – ниже вы найдете примеры, которые все расставят по местам.

Этапы жизненного цикла ПО

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

1. Определение потребностей бизнеса. На этом шаге идея становится более оформленной: появляется аналитика, конкретные требования к продукту, потенциальная выгода и так далее.
2. (только для аутсорса) Предпродажа. Заказчик ищет аутсорсинговую команда и предлагает ей реализовать идею. Аутсорс-компания прикидывает, сколько на этом можно заработать и как этот заказ повлияет на репутацию. Если аутсорс-компанию все устраивает – ПО переходит на следующий шаг.
3. Инициация. С этого шага начинаются этапы SDLC (английская аббревиатура для жизненного цикла ПО), в которых принимает участие непосредственно команда разработки. ТОПы команды получают на руки ТЗ, анализируют его и называют +/- точные сроки и стоимость разработки. Если заказчика это не устраивает – начинаются обсуждения, если заказчика все устроило – ПО уходит в разработку.
4. Проектирование/инженерный дизайн. Техлид и другие ответственные лица выбирают методологию разработки, разрезают ТЗ на изолированные части, выбирают технологии и так далее. Они готовят ПО к процессу разработки.
5. Имплементация. Непосредственно разработка: написание кода, создание инфраструктуры для приложение, разработка интерфейса и внешнего вида в целом. Чем лучше инженеры поработали на шаге 4, тем проще разработчикам на шаге 5.
6. Тестирование. Когда все задачи выполнены – ПО уходит на тестирование, в процессе которого то, что получилось, сравнивают с тем, что задумывалось. Тестирование может проводиться параллельно с имплементацией, может проводиться после нее.
7. Внедрение. Продукт выпускают на рынок. Основные задачи здесь лежат на отделе маркетинга, от команды разработчиков требуется поддерживать инфраструктуру (сервера, например).
8. Сопровождение. Этап, который может длиться бесконечно. На этом этапе нужно отлавливать баги информационных продуктов, закрывать дыры в безопасности, возможно – организовать горячую линию, которая будет заниматься исключительно этим программным обеспечением (более актуально для B2B-разработки).
9. Смерть. Если продукт оказался нежизнеспособным или потерял актуальность – его закрывают: перестают поддерживать, закрывают сервера, перестают выделять финансирование на сопровождение.

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

1. Заказчик обращается к своим креативщикам и маркетологам, те одобрят идею и начинают писать ТЗ.
2. Заказчик несет ТЗ в аутсорсинговую компанию. В компании решают, что калькулятор сильно поднимет их репутацию и принесет деньги.
3. Заказчик и ТОПы аутсорс-компании обсуждают детали договора, сроки и суммы.
4. Договор подписан – техлид одной из команд получает на руки ТЗ: должно быть 2 окошка для ввода чисел, переключатель операции (плюс, минус, умножить, делить), одно окошко для вывода результата. Вводим 2 числа, выбираем операцию – получаем результат. Техлид создает карточки в Jira: «окошко 1», «окошко 2», «окошко вывода», «переключатель», «логика калькуляции», «вывод результата».
5. Карточки раздаются различным программистам, они пишут код.
6. Калькулятор уходит тестировщикам, те начинают жаловаться: если попытаться поделить на 0, то смартфон взрывается в руках. Программисты говорят, что в ТЗ этого не было, и вообще на ноль делить можно, учите вышмат. В итоге кто-то все же исправляет баг.
7. Калькулятор отправляется в Google Play и App Store.
8. Заказчик на показах рекламы зарабатывает миллион долларов и соглашается на поддержку приложения за 100 000$/месяц. На линию выделяются два дежурных девопса, которые по 8 часов следят, чтобы ничего не упало (хотя своей инфраструктуры нет, и ничего упасть не может). Отдел маркетинга заказчика просит добавить возведение в степень, потому что в отзывах жалуются на отсутствие функции – новый функционал проходит все шаги, начиная с 3-го.
9. Появился калькулятор конкурента, который задушил проект заказчика. Деньги закончились, сопровождение и разработка возведения в степень прекратились. Проект закрылся.

Парадигмы разработки ПО

Каскадная

Идея: делаем сразу весь функционал по ТЗ, смотрим на результат. Из примера с калькулятором: сразу разрабатываем все 3 окошка, переключатель и логику, выпускаем на рынок.

Плюсы парадигмы	Минусы парадигмы
Заказчик сразу знает, сколько надо потратить на весь проект	Нулевая гибкость
	Если нужно добавить новый функционал в ТЗ – сначала надо подождать, пока закончится вся разработка по текущему ТЗ
	Проект может потерять актуальность к моменту выхода на рынок

Основные модели разработки: водопад, водоворот, V-образная.

Гибкая (итеративная)

Идея: делаем минимально жизнеспособный продукт, выпускаем на рынок, пошагово дорабатываем. Из примера с калькулятором: делаем два окошка ввода информации без переключателя и окошка вывода. Выпускаем в Google Play. Пользователям понравилось? Добавляем переключатель и выпускаем в App Store. Снова много скачиваний? Добавляем окошко вывода результата.

Плюсы парадигмы	Минусы парадигмы
Быстрый результат	Затраты на финальный продукт – зачастую непредсказуемые
Заказчик не переплачивает	Очень быстрая разработка – команда устает
Можно быстро проверять бизнес-теории

Основные модели разработки: Scrum, Kanban, Extreme Programming.

Парадигма на стыке

Есть еще парадигма, которую никто толком не описывает, но которая витает в воздухе. Она не имеет четкого названия, но неразрывно связана с циклом информационных разработок. Ее суть: смешение принципов каскадной и гибкой парадигмы в разных пропорциях. Из примера с калькулятором: на первом шаге создаем приложение со всеми окошками, логикой и действием «+», выпускаем на рынок; проводим аудит бизнеса, добавляем «-», выпускаем на рынок; …

Плюсы парадигмы	Минусы парадигмы
Можно рассчитать приблизительную цену	За счет большого количества шагов цена на финальный продукт всегда получается высокой
Относительно гибкая разработка	Довольно низкий темп разработки

Основная модель разработки: спиральный цикл.

Конкретные модели разработки ПО

Waterfall

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

Преимущества:

• Ясно, что получится в итоге.
• Понятно, сколько денег нужно потратить.
• Легко работать, потому что вся разработка разбита на шаги, выполняемые друг за другом.

Недостатки:

• Если в середине разработки обнаружилась проблема с архитектурой – все, эту проблему нельзя решить, пока разработка не закончилась.
• На разработку финального продукта уходит много времени.

Водоворот

Модификация предыдущей модели. Если на каком-то шаге разработки стало понятно, что результат будет так себе – команда откатывается на предыдущий шаг и пытается все исправить. Частично решает проблемы водопада, но все еще недостаточно, почему – объясним в разделе «Гибкие методологии разработки».

V-образная

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

Преимущества:

• Довольно гибкая система (по сравнению с водопадом).
• Наличие приемки позволяет получить фидбэк от заказчика/пользователей и подкорректировать последующие ТЗ.

Недостатки:

• Все еще высокая цена ошибки.
• Большая стоимость разработки из-за большого количества шагов.
• Сложная для построения система.

Спиральный цикл

Спиральную модель можно называть переходным вариантом между каскадной и гибкой методологией – именно дальнейшее развития спиральной структуры жизненного цикла привело к появлению Agile. При использовании спиральной модели весь цикл жизни делится на 4 фазы: определение задач; оценка потенциального результата; создание продукта; планирование следующей итерации. И эти фазы следуют одна за одной: придумали минимально жизнеспособный продукт, прикинули его выгоду, разработали, построили дальнейшие планы; придумали новый функционал, прикинули его выгоду, разработали и внедрили, построили дальнейшие планы; …

Преимущества:

• Удобно для создания программных комплексов высокой сложности – функционал разрабатывается постепенно, легче тестировать и полировать.
• Можно называть довольно точные сроки разработки следующей порции функционала.
• Можно собирать фидбэк от пользователей/заказчика и корректировать согласно с ним будущий функционал.

Недостатки:

• У стадий нет четкой выраженности, некоторые вообще могут пропускаться.
• Чем больше спиралей прошло – тем медленнее идет разработка (и, соответственно, повышается ее цена).

Гибкие методологии разработки

А теперь мы детально рассмотрим гибкую методологию и объясним, почему каскадные модели ей уступили. Agile-методология базируется на 12 принципах:

1. Заказчик должен быть доволен, этого можно достичь путем быстрого выпуска продукта на рынок.
2. Изменения ТЗ – это хорошо, даже если проект почти завершен.
3. Релизы должны быть частыми, новая версия – от 2 до 8 недель.
4. Разработчики должны ежедневно общаться с бизнесом.
5. Разработчики должны быть мотивированы.
6. Прямое общение – лучший способ коммуникации и решения проблем.
7. Основной показатель прогресса – работающий продукт.
8. Прогресс должен быть постоянным.
9. Высокое качество проектирования повышает гибкость проекта.
10. Лишнюю работу нужно сократить до минимума.
11. Команды должны быть автономными и самоорганизованными.
12. Нужно постоянно проводить анализ качества своей работы.

Из этих принципов мы получаем картину идеальной методологии разработки: высокомотивированная самоорганизующаяся команда делает быстрые релизы и постоянно совершенствует техническую и организационную часть как путем самоаудита, так и путем постоянного общения с заказчиком, что делает последнего крайне довольным (= вернется опять и заплатит больше денег). Звучит очень хорошо, но при классическом цикле это невозможно – каскадная модель ставит строгое соблюдение ТЗ выше, чем технический прогресс и потребности рынка, от чего страдают и заказчики (проверка теорий обходится дорого), и разработчики (медленный прогресс и далекий результат, что вызывает выгорание и снижает заинтересованность), и пользователи (новые версии выходят редко). Что делать? Взять понятия жизненного цикла и пересмотреть их с точки зрения этих 12 принципов.

Так и сделали. Первым результатом стал Extreme Programming, затем «подтянулись» Scrum и Kanban (последний эволюционировал из Lean).

Extreme Programming

Extreme Programming реализовывает основные принципы Agile «в лоб». В основе лежат короткие (до нескольких недель) циклы разработки, все они описаны в расписании релизов. На каждом цикле делается одна конкретная фича (иногда – несколько мелких), после разработки фича тут же уходит в тестирование. Глобально разработка фичи контролируется и корректируется на ежедневных митингах (созвонах), локально разработка контролируется за счет пар программистов – один смотрит, что там накодил другой (эта практика не особо прижилась). Наличие ежедневных созвонов, быстрых релизов, цикличной разработки в целом – все это соответствует принципам Agile.

Преимущества:

• Быстрые релизы.
• Легко откатить или изменить то, что уже сделано.
• Высокая степень согласованности как внутри команды, так и у команды с заказчиком.

Недостатки:

• Мотивации работников не уделяется достаточно внимания.

Scrum

Scrum отталкивается от спринтов – коротких (2-8 недель) промежутков, на которые команда ставит себе определенные задачи. Задачи берутся из бэклога – списка задач к выполнению. Вне зависимости от результатов спринта (выполнили задачи на спринт или нет) лидер команды проводит анализ результатов спринта и при необходимости вносит изменения в работу.

Но Scrum – это не столько про разработку, сколько про команду. В «правильных» Scrum-командах есть специальный Scrum-менеджер, который занимается только вопросами соблюдения методологии. Он же организует регулярные митинги, следит за полнотой коммуникации внутри команды и предоставляет инвентарь/площадку для специальных Scrum-событий – planning poker, например, условно-карточной игры, с помощью которой команда определяет сложность той или иной фичи. В конце прошлого десятилетия вышло большое мета-исследование по Scrum, в котором есть такие выводы:

• Полное следование методологии Scrum увеличивает продуктивность команды на 300-400%.
• Частичное следование методологии (Scrum-like) дает прирост всего в 20%.
• Почти никто не использует истинный Scrum из-за лени, непонимания методологии или нежелания тратиться на Scrum-мастера.

Преимущества методологии:

• Огромный прирост продуктивности.
• Методология включает в себя приемы для мотивирования команды.
• Фиксированная длина спринтов делает разработку предсказуемой.

Недостатки:

• Очень сложно соблюдать истинный Scrum.

Kanban

Kanban строится вокруг досок (Trello, Jira) и изолированных задач. Здесь тоже есть бэклог, из которого достаются фичи для реализации. Каждая фича затем делится на простые задачи, которые выкладываются на доску.

В изначальном Kanban любой разработчик мог брать понравившуюся ему задачу в работу, но иногда этой практикой пренебрегают, и Project Manager сам назначает ответственных.

Kanban появился как развитие Lean и наследует его основную фишку. Lean – это концепция управления производством, основанная на минимизации бесполезных действий – так называемое «бережливое производство». Достигается оно за счет предварительного планирования бэклога – если он был хорошо составлен, все необходимые действия будут в него записаны, и лишних задач не будет. Это хорошо и для бизнеса (просто рассчитывать сроки/суммы), и для команды (все уверены, что их работу не выкинут в мусорку).

Преимущества:

• Бережливое производство.
• Каждый берет в работу то, что ему нравится.
• Легко оценивать затраты ресурсов.

Недостатки:

• Kanban – для маленьких команд и проектов, организовать по Kanban работу большой команды или крупного проекта крайне тяжело.

Что лучше использовать?

Если смотреть на теорию, то Agile – лучший вариант в моделях SDLC, а каскадная разработка должна уйти в прошлое. В реальности же каскадные методы живут и процветают, хотя и уступили немалую часть рынка Agile-методу. Почему они живы?

Дело в том, что идеального метода разработки не существует. Да, Agile очень хорош для бизнеса с нестабильным рынком, но вы никогда не сможете построить разработку новой версии Windows по Agile – на середине разработки все ваши отлаженные процессы рухнут под напором восьмичасовых созвонов, у разработчиков не останется времени ни на что другое. Выбор правильной методологии разработки (в том числе и Waterfall при необходимости) – это решение, зависящее от десятков факторов, и не все из них говорят в пользу Agile.

Еще один момент – в большинстве случаев команды используют несколько методологий разработки. Одна команда использует Scrum, но непосредственно внутри спринта использует Kanban – разработчики сами берут себе карточки из доступных, а после спринта PM анализирует результативность. Другая команда использует Kanban, но внутри него использует Waterfall – в каждой карточке описаны большие куски фич или целые фичи, которые могут реализовываться сразу несколькими разработчиками. Поэтому запомните главное: методологии для разработчиков, а не разработчики для методологий.

Если какая-то смесь будет идеально работать для вашей команды – нужно отбросить принципы и использовать смесь.

Где учить методологии разработки ПО?

Для программиста методология – это важная информация; для прождект менеджера методология – это его хлеб. Если вам нужно досконально знать методологии и сферы их применения, вам стоит присмотреться к платным курсам, на которых вы получите необходимую практику:

• Профессия Project Manager в IT. Курс длится 12 месяцев, по итогу вы получаете полноценную профессию PM. Вам расскажут про жизненный цикл ПО, про все разработанные методологии, покажут сферы их применения и дадут практические работы, которые вы сможете разместить в своем портфолио. Стоимость курса – от 4 800 рублей в месяц при рассрочке на 2 года.
• Project Management. Курс для широкой аудитории. Рассказывают и про жизненный цикл, и про методологии, и про инструменты организации работы команды. Отдельно большое внимание уделяется анализу продуктивности команды и методам повышения этой продуктивности. Длительность – 1 год, стоимость – 6 000 рублей в месяц.
• Project manager. Относительно короткий курс – 8 месяцев. Курс позволяет получить профессию. Помогают с трудоустройством, выдают диплом о профессиональной переподготовке. Стоимость курса – 5 100 рублей при рассрочке на 2 года.

Подведем итоги

Тезисно:

• Жизненный цикл ПО – это стадии, через которые проходит приложение, от идеи до смерти.
• На стадиях жизненного цикла строятся парадигмы разработки: каскадная и Agile.
• Каскадная парадигма – это когда разработка ведется строго по ТЗ. Прозрачный, но медленный подход, основные модели: водопад, водоворот.
• Гибкая парадигма – это когда разработка ведется небольшими итерациями. Заказчик получает быстрый результат, команда получает фидбэк и мотивацию. Основные модели: Scrum, Kanban.
• Идеальной модели разработки не существует – чаще всего применяется смесь из нескольких моделей, наиболее удобная для всей команды. Выбор модели (или смеси моделей) – задача Project Manager.