Жизненный цикл программного обеспечения. Это обязан знать каждый на собесе в IT

• Определение бизнес-потребности (Business need definition)
• Предпродажа (Presale)
  • отсутствует в продуктовых компаниях, характерен только для модели аутсорса
• Инициация (Initiation)
• Проектирование и дизайн (Elaboration and Design)
• Имплементация (Implementation)
• Тестирование (Testing)
• Внедрение (Deployment)
• Сопровождение (Support)
• Смерть продукта (Product Death)

Рассмотрим каждый из них подробнее. 

Определение бизнес-потребности (Discovery). На этом этапе совместно работают маркетологи и менеджеры по продажам, подключаются к команде бизнес-аналитики для первичной проработки требований к продукту. Команда должна понимать, для какого рынка будет разрабатываться продукт, как продукт может принести пользу пользователям, для чего вообще будет тратиться время команды и средства клиента. Тут может быть 2 варианта развития.

• Если программный продукт создается не под заказ и предполагается выход на рынок программных средств, маркетинг выполняется в полном объеме: изучаются программные продукты-конкуренты и аналоги, обобщаются требования пользователей к программному продукту, устанавливается потенциальная емкость рынка сбыта, дается прогноз цены и объема продаж. Оцениваются материальные, трудовые и финансовые ресурсы, ориентировочная длительность основных этапов жизненного цикла программного продукта.
• Если программный продукт создается как заказной программный продукт для определенного клиента, на данном этапе также важно правильно сформулировать и документировать причины и цели его разработки. 

Основные проблемы, с которыми встречаются команды разработки на данном этапе, — это нежелание клиента проводить дискавери-фазу в полном объеме (т.к. это требует времени и средств) или проводить ее вообще (из разряда «я знаю лучше, что надо делать»). Как результат, команда будет делать продукт «как сказал заказчик», а не «как требует рынок». Больше половины написанных продуктов не выпускаются заказчиком в релиз именно из-за отсутствия хотя бы минимальной дискавери-фазы. 

Предпродажа. Этот этап характерен только для аутсорсной модели разработки ПО. На данном этапе заказчик проекта формирует запрос на коммерческое предложение (Request for Proposal),  дальше сейлз-специалисты и маркетологи подробно работают с клиентом, чтобы определить, интересен ли такой заказчик с точки зрения прибыли и имиджа для компании. Потом подключаются бизнес-аналитики для формирования бизнес-требований и налаживания коммуникаций между заказчиком и IT-компанией. И наконец, техническая команда (разработчики и проектные менеджеры) определяет, возможна ли реализация продукта с технической стороны. Если все ок, то оформляется коммерческое предложение (Proposal). Если интересы заказчика и IT-компании сходятся, то начинается непосредственно работа над проектом.

Инициация. Одна из самых важных фаз SDLC. На этом этапе сотрудничают все участники процесса, а также подключаются юристы и специалисты по финансам. Хорошее техническое задание четко и однозначно определяет требования к проекту и для команды, и для бизнеса, делая прозрачными конечные цели и задачи. Если техническое задание составлено понятно, то уточнять требования к проекту по ходу разработки нужно существенно реже, а приемка готового продукта будет быстрее и четче. Сейлз-менеджеру также следует курировать проект, чтобы без какой-либо существенной причины его стоимость не увеличивалась или не изменялись, например, условия по гарантии (часто юристы так поступают для перестраховки). В противном случае заказчик может запросто разорвать контракт.

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

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

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

Внедрение. Когда продукт достаточно протестирован и готов к развертыванию, наступает следующий этап жизненного цикла. Существует 2 варианта выпуска продукта на рынок.

• Продукт сразу выпускают на целевой рынок и делают доступным всей потенциальной аудитории.
• Продукт сначала выпускают на ограниченный сегмент (soft launch), тестируют в реальной жизни, а затем с учетом отзывов и улучшений он выпускается для всеобщего использования.
  • В случае аутсорсной b2b-разработки (business-to-business) проект раскатывают сначала на 1-2 департамента, а потом уже на все предприятие целиком. 

Сопровождение. На этом этапе жизненного цикла осуществляется периодическая техническая поддержка программного обеспечения.  Постоянное сопровождение позволяет убедиться, что система соответствует современным стандартам и технологиям, происходят постоянные обновления, которые направлены на оптимальное поддержание работоспособности продукта. Для многих аутсорсных IT-компаний сопровождение — это отдельное довольно прибыльное направление бизнеса, если его правильно продавать: одно дело, когда на стороне поддержки сидят низкоквалифицированные специалисты (чаще всего — индусы), которые могут помочь только в самых простых случаях (типа «перезагрузите компьютер»), и совсем другое — когда поддержкой и сопровождением занимаются высококвалифицированные разработчики, которые 24/7 могут исправлять баги и решать проблемы клиента. 

Смерть продукта. На этом этапе происходит официальное закрытие продукта. 

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

Каскадная или водопадная модель (Waterfall model)

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

Плюсы:

• При такой модели легко управлять проектом, т.к. модель управления простая и последовательная.
• Требования к каждому этапу формально определены и документированы заранее.
• Четко определено, когда заканчивается предыдущий этап и начинается следующий. 

Минусы:

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

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

V-образная модель (V-model)

Эта модель работает по принципу «шаг за шагом», как и каскадная модель, но процесс тестирования начинается уже на стадии написания требований. 

Плюсы:

• Четкое разделение этапов разработки.
• Тестирование на промежуточных этапах процесса разработки.

Минусы:

• Нет возможности динамического внесения изменений заказчиком.
• Длительное время разработки (иногда длится до нескольких лет), как и в каскадной модели, приводит к тому, что продукт может быть уже не нужен заказчику, поскольку его потребности меняются.
• Невозможно качественно проанализировать риски, т.к. горизонт планирования проекта исчисляется годами. 

Спиральная модель

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

• определение целей,
• оценка и разрешение рисков,
• разработка и тестирование,
• планирование следующей итерации.

Плюсы:

• Особое внимание уделяется рискам.
• Дополнительные функции в разрабатываемый продукт могут быть добавлены на поздних этапах разработки.
• Существует возможность гибкого проектирования.

Минусы:

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

Гибкая методология (Agile) и Scrum

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

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

Плюсы:

• Быстрая обратная связь от специалистов в разных сферах (дизайнеров, архитекторов, тестировщиков и пр.) за счет коротких (1-2 недели) итераций.
• Легко вносить изменения благодаря итеративному подходу разработки.
• Самостоятельная и самоорганизованная команда.

Минусы:

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

Краткие итоги

• Жизненный цикл ПО состоит из 9 этапов, но эти этапы необязательно выполняются последовательно. Некоторые этапы могут проходить параллельно, а некоторые — пересекаться друг с другом. 
• Существует множество моделей разработки ПО. Выбор варианта всегда зависит от особенностей и требований проекта, целей и задач, которые стоят перед разработчиками, моделей оплаты. Зачастую методологии пересекаются и похожи друг на друга, но тем не менее каждая находит своих почитателей. 
• Абсолютное большинство белорусских IT-компаний работают, используя гибкие подходы к разработке ПО.

P.S. Если сравнивать самые популярные модели разработки ПО по таким критериям, как: а) последовательная или итеративная реализация продукта и б) формальность/неформальность модели разработки ПО, то мы получим следующую диаграмму: