Жизненный цикл ПО
- Фазы. Этапы жизни ПО.
- Парадигмы. Набор основных идей, которыми нужно руководствоваться при разработке.
- Модели. Реализация парадигм.
На любом собесе вас будут спрашивать и про этапы, и про парадигмы, и про конкретные модели жизненных циклов – если вы не знаете этих тем, то вы не представляете, как вообще ведется разработка. Кроме того, основная методология сейчас – гибкая разработка, и вам нужно знать ее конкретные модели, потому что вы будете использовать их в работе.
Ниже мы даем вам структурированный материал о жизненном цикле ПО с примерами – этих знаний будет достаточно, чтобы уверенно отвечать на собеседовании.Жизненный цикл программного обеспечения – что это
С общим определением цикла разработки программных продуктов мы уже познакомились, здесь расскажем, зачем он нужен. Причина, как всегда, кроется в деньгах. Когда заказчик придумывает идею, которая должна принести деньги, ему нужно посчитать потенциальную прибыль. А чтобы посчитать ее, ему нужно знать, сколько он потратит на разработку. Чтобы посчитать ее, он приходит в отдел разработки и говорит: «Хочу сделать лучший в мире калькулятор и выпустить его на смартфоны. Сколько с меня?». И теперь уже отделу разработки нужно считать, сколько они возьмут, а для этого им нужно разбить весь процесс разработки на конкретные шаги и посчитать затраты на каждый шаг – получаем конкретные изолированные этапы в стадиях жизненного цикла продукта.
Но просто выделить этапы и посчитать деньги – недостаточно. Разработка – это динамичный процесс взаимодействия многих людей. На ранних этапах развития компьютеров действительно можно было накидать простенькую программу и отдать ее заказчику. Сейчас процесс стал намного более сложным: нужно где-то программу развернуть; нужно посмотреть, как она зайдет пользователям; нужно внести изменения и отловить баги; наконец, нужно улучшать приложение, если оно выходит в плюс. Чтобы учесть все эти факторы, нужно что-то более серьезное, чем этапы жизненного цикла.
Этим более серьезным является парадигма. Парадигма – это набор абстрактных мыслей о чем-либо.Первая из появившихся парадигм разработки – каскадная модель жизненного цикла. Основная идея – берем все требования заказчика, делаем их, отдаем результат, повторяем при необходимости. Очень похоже на то, что было на заре разработки ПО. Из этой парадигмы вышли модели «Водопад» и «Водоворот».
Со временем, когда рынок стал активнее, у каскадной парадигмы обнаружилась проблема: ее методы не умеют подстраиваться под динамику рынка. Microsoft запустила в разработку Windows 2000, 3 года делала ее из беты в релиз, когда Windows 2000 вышла – оказалось, что она никому уже не нужна, 3 года работы потрачены впустую. Чтобы такого не повторять, придумали новую парадигму: итеративная разработка. Основная мысль: собираем все требования заказчика и режем их на небольшие финализированные блоки. Сделали блок – получили какой-то минимальный продукт – выбросили его на рынок. Пользователям понравилось – взяли еще один блок функциональности, добавили в уже работающее приложение, снова выкинули на рынок. Все еще приносит прибыль – повторяем.
Если из каскадной парадигмы разработки вышло в лучшем случае 3-4 метода, то из итеративной парадигмы вышел десяток минимум. Есть еще пара методов на стыке методологий – спиральная модель, например – но основным циклом создания программного обеспечения считается Scrum, который – полностью итеративный. То есть история показала, что итерации – лучше для бизнеса, чем каскадная разработка.
Итак, промежуточный вывод: жизненный цикл ПО – это и стадии существования, и методы разработки программного обеспечения. Стадии лежат в его основе, а переходы между стадиями – это циклы разработки.
Если пока не очень понятно – ниже вы найдете примеры, которые все расставят по местам.Этапы жизненного цикла ПО
Чтобы разобраться в моделях жизненного цикла программного обеспечения, нам сначала нужно выделить стадии разработки. Вот они:
- Определение потребностей бизнеса. На этом шаге идея становится более оформленной: появляется аналитика, конкретные требования к продукту, потенциальная выгода и так далее.
- (только для аутсорса) Предпродажа. Заказчик ищет аутсорсинговую команда и предлагает ей реализовать идею. Аутсорс-компания прикидывает, сколько на этом можно заработать и как этот заказ повлияет на репутацию. Если аутсорс-компанию все устраивает – ПО переходит на следующий шаг.
- Инициация. С этого шага начинаются этапы SDLC (английская аббревиатура для жизненного цикла ПО), в которых принимает участие непосредственно команда разработки. ТОПы команды получают на руки ТЗ, анализируют его и называют +/- точные сроки и стоимость разработки. Если заказчика это не устраивает – начинаются обсуждения, если заказчика все устроило – ПО уходит в разработку.
- Проектирование/инженерный дизайн. Техлид и другие ответственные лица выбирают методологию разработки, разрезают ТЗ на изолированные части, выбирают технологии и так далее. Они готовят ПО к процессу разработки.
- Имплементация. Непосредственно разработка: написание кода, создание инфраструктуры для приложение, разработка интерфейса и внешнего вида в целом. Чем лучше инженеры поработали на шаге 4, тем проще разработчикам на шаге 5.
- Тестирование. Когда все задачи выполнены – ПО уходит на тестирование, в процессе которого то, что получилось, сравнивают с тем, что задумывалось. Тестирование может проводиться параллельно с имплементацией, может проводиться после нее.
- Внедрение. Продукт выпускают на рынок. Основные задачи здесь лежат на отделе маркетинга, от команды разработчиков требуется поддерживать инфраструктуру (сервера, например).
- Сопровождение. Этап, который может длиться бесконечно. На этом этапе нужно отлавливать баги информационных продуктов, закрывать дыры в безопасности, возможно – организовать горячую линию, которая будет заниматься исключительно этим программным обеспечением (более актуально для B2B-разработки).
- Смерть. Если продукт оказался нежизнеспособным или потерял актуальность – его закрывают: перестают поддерживать, закрывают сервера, перестают выделять финансирование на сопровождение.
Предположим, есть заказчик, который хочет создать калькулятор и выпустить его на смартфоны. Этапы жизненного цикла:
- Заказчик обращается к своим креативщикам и маркетологам, те одобрят идею и начинают писать ТЗ.
- Заказчик несет ТЗ в аутсорсинговую компанию. В компании решают, что калькулятор сильно поднимет их репутацию и принесет деньги.
- Заказчик и ТОПы аутсорс-компании обсуждают детали договора, сроки и суммы.
- Договор подписан – техлид одной из команд получает на руки ТЗ: должно быть 2 окошка для ввода чисел, переключатель операции (плюс, минус, умножить, делить), одно окошко для вывода результата. Вводим 2 числа, выбираем операцию – получаем результат. Техлид создает карточки в Jira: «окошко 1», «окошко 2», «окошко вывода», «переключатель», «логика калькуляции», «вывод результата».
- Карточки раздаются различным программистам, они пишут код.
- Калькулятор уходит тестировщикам, те начинают жаловаться: если попытаться поделить на 0, то смартфон взрывается в руках. Программисты говорят, что в ТЗ этого не было, и вообще на ноль делить можно, учите вышмат. В итоге кто-то все же исправляет баг.
- Калькулятор отправляется в Google Play и App Store.
- Заказчик на показах рекламы зарабатывает миллион долларов и соглашается на поддержку приложения за 100 000$/месяц. На линию выделяются два дежурных девопса, которые по 8 часов следят, чтобы ничего не упало (хотя своей инфраструктуры нет, и ничего упасть не может). Отдел маркетинга заказчика просит добавить возведение в степень, потому что в отзывах жалуются на отсутствие функции – новый функционал проходит все шаги, начиная с 3-го.
- Появился калькулятор конкурента, который задушил проект заказчика. Деньги закончились, сопровождение и разработка возведения в степень прекратились. Проект закрылся.
Парадигмы разработки ПО
Каскадная
Идея: делаем сразу весь функционал по ТЗ, смотрим на результат. Из примера с калькулятором: сразу разрабатываем все 3 окошка, переключатель и логику, выпускаем на рынок.
Плюсы парадигмы | Минусы парадигмы |
Заказчик сразу знает, сколько надо потратить на весь проект | Нулевая гибкость |
Если нужно добавить новый функционал в ТЗ – сначала надо подождать, пока закончится вся разработка по текущему ТЗ | |
Проект может потерять актуальность к моменту выхода на рынок |
Основные модели разработки: водопад, водоворот, V-образная.
Гибкая (итеративная)
Идея: делаем минимально жизнеспособный продукт, выпускаем на рынок, пошагово дорабатываем. Из примера с калькулятором: делаем два окошка ввода информации без переключателя и окошка вывода. Выпускаем в Google Play. Пользователям понравилось? Добавляем переключатель и выпускаем в App Store. Снова много скачиваний? Добавляем окошко вывода результата.
Плюсы парадигмы | Минусы парадигмы |
Быстрый результат | Затраты на финальный продукт – зачастую непредсказуемые |
Заказчик не переплачивает | Очень быстрая разработка – команда устает |
Можно быстро проверять бизнес-теории |
Основные модели разработки: Scrum, Kanban, Extreme Programming.
Парадигма на стыке
Есть еще парадигма, которую никто толком не описывает, но которая витает в воздухе. Она не имеет четкого названия, но неразрывно связана с циклом информационных разработок. Ее суть: смешение принципов каскадной и гибкой парадигмы в разных пропорциях. Из примера с калькулятором: на первом шаге создаем приложение со всеми окошками, логикой и действием «+», выпускаем на рынок; проводим аудит бизнеса, добавляем «-», выпускаем на рынок; …
Плюсы парадигмы | Минусы парадигмы |
Можно рассчитать приблизительную цену | За счет большого количества шагов цена на финальный продукт всегда получается высокой |
Относительно гибкая разработка | Довольно низкий темп разработки |
Основная модель разработки: спиральный цикл.
Конкретные модели разработки ПО
Waterfall
При этой разработке ТЗ выполняется полностью, только после этого продукт уходит на рынок. Одна из первых моделей, получивших широкое распространение.
Преимущества:
- Ясно, что получится в итоге.
- Понятно, сколько денег нужно потратить.
- Легко работать, потому что вся разработка разбита на шаги, выполняемые друг за другом.
Недостатки:
- Если в середине разработки обнаружилась проблема с архитектурой – все, эту проблему нельзя решить, пока разработка не закончилась.
- На разработку финального продукта уходит много времени.
Водоворот
Модификация предыдущей модели. Если на каком-то шаге разработки стало понятно, что результат будет так себе – команда откатывается на предыдущий шаг и пытается все исправить. Частично решает проблемы водопада, но все еще недостаточно, почему – объясним в разделе «Гибкие методологии разработки».
V-образная
Дальнейшее развитие водопада в сторону гибкости. Появились приемки и проверки, которые позволяют быстрее и безболезненнее откатиться на предыдущий этап, если поняли, что что-то идет не так.
Преимущества:
- Довольно гибкая система (по сравнению с водопадом).
- Наличие приемки позволяет получить фидбэк от заказчика/пользователей и подкорректировать последующие ТЗ.
Недостатки:
- Все еще высокая цена ошибки.
- Большая стоимость разработки из-за большого количества шагов.
- Сложная для построения система.
Спиральный цикл
Спиральную модель можно называть переходным вариантом между каскадной и гибкой методологией – именно дальнейшее развития спиральной структуры жизненного цикла привело к появлению Agile. При использовании спиральной модели весь цикл жизни делится на 4 фазы: определение задач; оценка потенциального результата; создание продукта; планирование следующей итерации. И эти фазы следуют одна за одной: придумали минимально жизнеспособный продукт, прикинули его выгоду, разработали, построили дальнейшие планы; придумали новый функционал, прикинули его выгоду, разработали и внедрили, построили дальнейшие планы; …
Преимущества:
- Удобно для создания программных комплексов высокой сложности – функционал разрабатывается постепенно, легче тестировать и полировать.
- Можно называть довольно точные сроки разработки следующей порции функционала.
- Можно собирать фидбэк от пользователей/заказчика и корректировать согласно с ним будущий функционал.
Недостатки:
- У стадий нет четкой выраженности, некоторые вообще могут пропускаться.
- Чем больше спиралей прошло – тем медленнее идет разработка (и, соответственно, повышается ее цена).
Гибкие методологии разработки
А теперь мы детально рассмотрим гибкую методологию и объясним, почему каскадные модели ей уступили. Agile-методология базируется на 12 принципах:
- Заказчик должен быть доволен, этого можно достичь путем быстрого выпуска продукта на рынок.
- Изменения ТЗ – это хорошо, даже если проект почти завершен.
- Релизы должны быть частыми, новая версия – от 2 до 8 недель.
- Разработчики должны ежедневно общаться с бизнесом.
- Разработчики должны быть мотивированы.
- Прямое общение – лучший способ коммуникации и решения проблем.
- Основной показатель прогресса – работающий продукт.
- Прогресс должен быть постоянным.
- Высокое качество проектирования повышает гибкость проекта.
- Лишнюю работу нужно сократить до минимума.
- Команды должны быть автономными и самоорганизованными.
- Нужно постоянно проводить анализ качества своей работы.
Из этих принципов мы получаем картину идеальной методологии разработки: высокомотивированная самоорганизующаяся команда делает быстрые релизы и постоянно совершенствует техническую и организационную часть как путем самоаудита, так и путем постоянного общения с заказчиком, что делает последнего крайне довольным (= вернется опять и заплатит больше денег). Звучит очень хорошо, но при классическом цикле это невозможно – каскадная модель ставит строгое соблюдение ТЗ выше, чем технический прогресс и потребности рынка, от чего страдают и заказчики (проверка теорий обходится дорого), и разработчики (медленный прогресс и далекий результат, что вызывает выгорание и снижает заинтересованность), и пользователи (новые версии выходят редко). Что делать? Взять понятия жизненного цикла и пересмотреть их с точки зрения этих 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.