SDLC-модели: как выбрать правильный подход к разработке

0
71
views

Вадим Кулага, проектный менеджер EPAM Anywhere, в своей статье на proglib.io рассказал об основных моделях разработки программного обеспечения (SDLC), их плюсах и минусах, а также о реальных примерах их использования.

Photo by fauxels from Pexels

Более половины ИТ-проектов заканчиваются провалом. Одни из самых распространенных причин неудач ИТ-проектов – неправильная интерпретация бизнес-целей, игнорирование клиентов, неправильная расстановка приоритетов. Но у всех у них общий корень проблемы: неправильный подход к разработке программного обеспечения.

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

Методология разработки программного обеспечения (SDLC) представляет собой последовательность действий, которые необходимо выполнить, чтобы получить готовое решение. Проще говоря, это способ создания программного продукта.

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

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

Это линейная и последовательная модель разработки программного обеспечения, в которой фазы проекта следуют одна за другой и включают:

  • Исследование. Группа разработчиков собирает требования к проекту и включает их в документ «Спецификации требований к программному обеспечению» (SRS).
  • Дизайн. Команда анализирует все требования и выкатывает прототип системы.
  • Кодирование. Как только заинтересованные стороны проекта согласовывают прототип, начинается фаза написания кода.
  • Тестирование. Команда QA запускает каждый модуль через различные сценарии тестирования и интегрирует их в систему. Как только все компоненты на месте, они тестируют систему целиком.
  • Развертывание. Решение доставляется заказчику в полностью рабочем состоянии.
  • Обслуживание. Команда разработчиков следит за проектом и при необходимости вносит обновления.
Схема модели Waterfall

Плюсы и минусы подхода

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

Каким проектам подходит

Каскадная модель – хороший вариант, если выполняются эти условия:

  • Проект короткий и с нулевым риском.
  • Требования фиксированные.
  • Технологии стабильны.
  • Доступны все необходимые ресурсы.

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

V-образная модель SDLC

V-образная модель – это своего рода другая версия каскада, но в её основе лежит контроль качества каждой фазы. Например, когда группа разработчиков собирает требования к проекту, QA-специалисты пишут приемочные тесты на основе этих сценариев. Точно так же на этапе проектирования системы создаются сценарии тестирования и так далее. После написания кода команда QA проверяет продукт на соответствие заранее написанным тестам (правая часть буквы «V»).

Схема V-образной модели SDLC
ПлюсыМинусы
Легко реализовывать.В V-образной модели внести изменения в середине проекта крайне сложно.
Тест-кейсы создаются заранее.При таком большом количестве процедур тестирования остается меньше времени на код.
Бюджет и продолжительность проекта предсказуемы.По сравнению с каскадной эта модель требует больше специалистов.
У каждого этапа есть свои результаты, и все хорошо задокументировано.Модель не подходит для проектов с быстро меняющимися требованиями.
Это структурированный подход с четко определенными ролями и функциями.Не подходит для больших и сложных проектов.

Каким проектам подходит

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

Модель эволюционного прототипирования

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

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

Каким проектам подходит

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

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

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

  • Планирование. Собираются все требования к проекту и делятся на составляющие.
  • Реализация модулей. Каждая итерация представляет собой «мини-каскад», который имеет такой же процесс: анализ требований модуля, проектирование, реализация и тестирование модулей, интеграция и тестирование всей системы, выпуск версии и оценка. Процесс повторяется до тех пор, пока не будут выполнены все требования.
Схема инкрементальной и итеративной модели SDLC
ПлюсыМинусы
Модель инкрементальной и итеративной разработки обеспечивает быструю и регулярную «доставку» работающего программного обеспечения клиентам.Во время интеграции модуля могут возникнуть архитектурные проблемы.
Легче и дешевле учесть изменения в требованиях проекта.Несмотря на некоторую гибкость, систему следует планировать с самого начала; в противном случае его нельзя разделить на модули.
Обратная связь от клиента на ранней стадии.Участие клиентов может быть проблематичным.
Небольшие части программного обеспечения легче тестировать и исправлять.Не всегда можно разбить систему на сегменты.
Экономия на издержках.Хотя выпуск одного модуля дешевле, общие затраты на систему будут увеличиваться по мере интеграции новых модулей.

Каким проектам подходит

Модель будет эффективна в следующих случаях:

  • Если система состоит из нескольких сегментов с чёткими требованиями.
  • Ограниченные ресурсы на проекте или есть ограничения по времени выхода решения на рынок.
  • Для стартапов, проходящих инвестиционные раунды.
  • Масштабные проекты.
  • Проекты, в основе которых новые технологии.
  • Проекты, которые потребуется развивать после выпуска.

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

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

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

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

Затем, на основе отзывов пользователей и заинтересованных сторон, планируется следующая итерация.

Схема спиральной модели

Как видите, продукт неоднократно проходит через эти этапы, и в конце каждого цикла создаётся и выпускается лучшая версия продукта. И, как и в итеративном подходе, продукт состоит из серии релизов.

ПлюсыМинусы
Анализ рисков на каждой итерации увеличивает шансы проекта на успех.Требуется опыт управления рисками.
Этот метод позволяет создавать стабильные и надёжные системы, поскольку они тщательно тестируются в каждом цикле.Модель подразумевает работу с большим объёмом документации.
Можно менять требования между циклами.Нельзя изменить требования в середине цикла.
Раннее вовлечение разработчиков помогает согласовать бизнес-требования и технические возможности.Каждый кружок в спирали развития представляет собой «мини-каскад», а это значит, что вы не можете пропускать фазы.
Частые выпуски позволяют получать регулярную обратную связь от клиентов даже на ранних этапах цикла.Поскольку ограничений на количество итераций нет, сложно предсказать, сколько кругов потребуется для создания окончательной версии продукта.

Каким проектам подходит

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

  1. Больших, сложных продуктов, состоящих из нескольких компонентов.
  2. Проектов с частыми релизами.
  3. Проектов средней и высокой степени риска.
  4. Проектов с неясными требованиями.

Microsoft, IBM и Tata Consultancy используют спиральную модель.

Модели гибкой разработки программного обеспечения

Вопреки распространённому мнению Agile не является ни структурой, ни методологией. Это философия с набором принципов, ориентированных на ускорение процесса разработки программного обеспечения, обеспечение 100% удовлетворённости клиентов и предоставление высококачественных решений в быстро меняющейся среде. Фактически, существует 12 принципов гибкой разработки, которые сводятся к следующим ценностям:

  • Люди и взаимодействие важнее процессов и инструментов.
  • Рабочее программное обеспечение над обширной документацией.
  • Сотрудничество с клиентами вместо переговоров по контракту.
  • Реагирование на изменения вместо следования плану.

Ценности Agile породили более 50 методологий, из которых Scrum является самой популярной.

Scrum

Скрам-проекты разбиты на спринты. Спринт – это небольшой объём работы, который необходимо выполнить в течение определённого периода времени. Обычно заказчику доставляется часть проекта, которая была завершена во время спринта (инкремент продукта, от англ. increment). Скрам подразумевает активное общение и сотрудничество между всеми участниками проекта. Наряду с ежедневными 15-минутными встречами разработчиков, есть также:

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

Сердце процессов Scrum – это backlog, своего рода список задач, которые необходимо сделать для завершения проекта. По мере того, как проект продвигается, и команда узнаёт о нём больше, они редактируют бэклог продукта, добавляя, удаляя и переупорядочивая его элементы. Тем не менее, нельзя сделать что-то, если этого нет в очереди продукта.

Scrum

Но на самом ли деле всё так гладко и красиво в Agile? Посмотрим на его основные варианты использования, а также на плюсы и минусы.

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

Примеры использования

Большинство современных проектов требуют определённого уровня «маневренности», особенно когда:

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

В общем, Agile кажется именно тем, что нужно большинству проектов во времена неопределённости. Неудивительно, что более 70% компаний применяют Agile, включая Microsoft, IBM, Procter & Gamble и другие. И EPAM не исключение.

Резюме

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

ОСТАВЬТЕ ОТВЕТ

Please enter your comment!
Please enter your name here