01 Feb Модели жизненного цикла программного обеспечения Хабр

К примеру, хочется создать масштабную социальную сеть, но какие функции в ней будут, еще не определено. То есть изначальная задача ясна — создать базовый вариант, где люди могут создавать профиль, обмениваться сообщениями и фото. А следующие версии могут включать либо обмен видео, либо появление «стены» записей, либо вообще разворот в сторону социальной сети для поиска пары. В последние этап требований (Requirements Phase) годы BIM-технологии стали неотъемлемой частью строительной отрасли, привнося в нее инновации и улучшения. Согласно данным за период 2018–2022 гг., объем рынка BIM-технологий увеличился более чем в два раза, достигнув впечатляющей отметки в 10,1 млрд руб. Одной из основных причин такого роста являются обязательства со стороны государства перейти на использование BIM-технологий.

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

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

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

• Вместо линейного продвижения проекта, процесс как бы «располовинивается» после этапа имплементации и создания кода, визуально формируя специфическую V-образную модель.
• Концепция подойдет для масштабных приложений инновационного характера.
• Итерации (в терминологии Scrum — «спринты») длятся 2-4 недели, спринту предшествует тщательное планирование, а после его завершения проводится оценка результатов.
• Давайте рассмотрим, как проходила разработка реальных проектов, чтобы понять, как эта модель может быть применена.

Определение целей, альтернатив, ограничений, или фаза планирования. Команда разработчиков формулирует цели проекта, основные требования (такие как, например, Business Requirement Specifications, или BRS, System Requirement Specifications, или SRS), возможный дизайн и т.д. На последующих спиралях требования формируются согласно отзывам, полученным от заказчика. Именно поэтому постоянная коммуникация между заказчиком и командой крайне важна.

Популярные модели SDLC, по шкале линейности/спонтанности операций, и формальности/неформальности подходов:

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

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

Что такое модели SDLC?

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

Каждый следующий этап стартует только тогда, когда закончен предыдущий. В этом кроется главное преимущество «водопада» и главный недостаток. Стоит отметить, что процессом (или технологическим процессом) называют и набор процессов, увязанных для совместного решения более крупной задачи, например, всей совокупности деятельностей, входящих в жизненный цикл ПО. Таким образом, процессы могут разбиваться на подпроцессы, решающие частные подзадачи той задачи, с которой работает общий процесс. Жизненный цикл тестирования ПО является процессом, которого нельзя избежать.

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

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

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

Разработка ПО (Building or Developing the Product)

В соответствии с уточненными требованиями выбираются наиболее подходящие проектные решения. Таким образом, этот этап предполагает сбор требований к разрабатываемому программному обеспечению, их систематизацию, документирование, анализ, а также выявление и разрешение противоречий. Инкрементная модель в целом следует той же структуре, что и каскадная, однако, как можно понять из названия, все этапы проходят несколько раз в течение жизненного цикла ПО. Соответственно, V-образная модель также подходит для небольших и средних по объемам проектов, где вся документация четко прописана и требуется определенный уровень качества (высокий). Это могут быть приложения безопасности, наблюдения за тяжелобольными пациентами, ПО для атомных электростанций и так далее. Команда разработчиков XBSoftware применяла принципы спиральной модели, а также принципы Scrum.

Этапы разработки жизненного цикла ПО на примере каскадной модели

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