SDLC и SSDLC: сравнение подходов к разработке ПО

Программное обеспечение в процессе создания проходит несколько этапов, называемых жизненным циклом разработки (Software development lifecycle, SDLC). Это концепция, цель которой — выпуск на рынок качественного продукта, отвечающего запросам потребителей. Рассмотрим подробнее существующие модели SDLC и этапы разработки, которые в них входят.

Модели SDLC

Рассмотрим особенности, преимущества и недостатки трех моделей.

Водопадная

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

Она используется в разработке программного обеспечения, к которому есть строгие устоявшиеся требования. Для больших проектов водопадная модель Software Development Life Cycle не подойдет, поскольку они требуют регулярной обратной связи и постоянных изменений в процессе создания.

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

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

Минусы водопадной модели SDLC:

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

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

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

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

Итеративная модель подходит для работы над инновационными продуктами и большими проектами, которые необходимо постоянно дополнять новой функциональностью.

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

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

Среди минусов можно выделить «плавающий» бюджет и неопределенные сроки выпуска продукта, поскольку требования к ПО в ходе разработки постоянно расширяются.

Гибкие методологии Agile

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

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

Преимущества такой методологии и построения цикла SDLC:

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

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

Этапы SDLC

Жизненный цикл SDLC можно условно разделить на шесть ключевых этапов:

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

Начиная с этапа разработки внедряются различные методы анализа ПО. Например:

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

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

Методология SSDLC и ее отличия от SDLC

Подход Security Software Development Life Cycle предполагает заботу о безопасности, начиная с первого этапа разработки ПО. Это и есть главное отличие от традиционной методологии жизненного цикла SDLC. Рассказываем, как реализуется подход:

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

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

Контроль безопасности ПО с помощью Solar appScreener в ходе разработки по методологии SSDLC

Solar appScreener — российская платформа для комплексного контроля безопасности программных продуктов. Она предоставляет инструменты для проведения различных видов тестирований: SAST и DAST, анализа состава приложений SCA, SCS-проверки цепочки поставок.

Преимущества внедрения Solar appScreener в разработку ПО в рамках жизненного цикла SSDLC:

• Поддержка 36 языков программирования.
• Безболезненная и быстрая интеграция в цикл разработки.
• Реализация уникального алгоритма Fuzzy Logic Engine, сокращающего количество ложноположительных сигналов при проведении тестирования SAST.
• Интеграция со всеми распространенными инструментами разработки и сборки программных продуктов.
• Дружелюбный пользовательский интерфейс для удобного управления инструментами анализатора.
• Возможность корреляции результатов статического и динамического тестирований.

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

Продукт будет полезен и в том случае, если созданием ПО занимаются подрядчики. Благодаря инструментам, которые предоставляет Solar appScreener, можно будет обнаружить все проблемы безопасности — от ошибок в коде до неправильной реализации функций. Благодаря SCA-анализу выявятся все потенциально опасные заимствованные компоненты, SCS-проверка позволит спрогнозировать угрозы из-за заимствованных библиотек, которые могут проявиться в дальнейшем.