Жизненный цикл разработки ПО (SDLC): этапы и модели

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

ISO/IEC 12207 — международный стандарт, который определяет структуру и описывает процессы жизненного цикла программного обеспечения (SDLC), охватывая все этапы — от анализа и разработки до эксплуатации, сопровождения и вывода из эксплуатации. Этот стандарт широко применяется компаниями по всему миру для стандартизации процессов разработки и сопровождения ПО, повышения качества продуктов и обеспечения соответствия международным требованиям.

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

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

На следующем рисунке представлено графическое представление разных этапов типичного SDLC.

Фаза планирования – наиболее важный и критический шаг в создании успешной системы.

Цель: определить, что именно нужно сделать и какие ресурсы потребуются.

Основные задачи:

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

Результат: По итогам анализа принимается решение: создать новую систему, улучшить существующую или оставить всё как есть. На этом этапе важна активная коммуникация с заказчиком.

QA Engineer участвует в обсуждении бизнес-целей и требований. Помогает сделать требования понятными, измеримыми и тестируемыми, указывает на возможные риски и формирует критерии качества, и начинает составлять тест-план.

Цель: понять, что нужно заказчику и как это можно реализовать. Для определения начальных требований к продукту привлекаются эксперты из разных отраслей: заказчики, клиенты, специалисты разных отделов (продаж, разработки, аналитики, тестирование и т.п.), эксперты по схожим продуктам. Бизнес-аналитики (BA) прорабатывают полученную информацию, детализируют ее и превращают в технические требования к системе, которые называются Software Requirement Specification (SRS).

Помимо SRS на этом этапе::

• Определяются требования к качеству (SQA, Software Quality Attributes)
• Проводится анализ рисков (RA, Risk Analysis)
• Создаются планы валидации и верификации (V&V Plans, Test Plans)
• Определяются критерии приема ПО (AC, Acceptance Criteria). требования к качеству продукта.

Результат: Анализ требований — это этап, на котором уточняют, что должен делать продукт, проверяют реализуемость и фиксируют это в документе SRS (Software Requirements Specification - Спецификация требований к программному обеспечению). SRS — это НЕ проектирование, а требования. SRS — это документ с требованиями к продукту (что система должна делать, какие функции и ограничения). Он обычно создаётся на этапе анализа требований (раньше, чем проектирование). Здесь важно понять, что SRS является одним из входных документов (входных данных) для этапа проектирования, а не его результатом.

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

Цель: разработать технический стек (архитектуру) и структуру программы на основе требований.

Основные задачи:

• Определить, из каких техник, инструментов и технологий будет состоять проект (технологический стек).
• Разработка архитектурного дизайна (High-Level Design). Спроектировать общую структуру системы и её ключевые компоненты.
• Продумать детали реализации: модули, базы данных, интерфейсы (Low-Level Design).

Результат: Техническая документация DDS (Design Document Specification), описывающий выбранный стек, архитектуру и технические решения. DDS — это документ, который создают на этапе проектирования. То есть: SRS — исходные требования, DDS — результат проектирования, основанный на этих требованиях SRS.

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

Цель: Написание кода на основе созданного дизайна.

Основные задачи:

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

Результат: Готовый программный продукт или модули, требующие тестирования. На этом этапе SDLC начинается фактическая разработка и сборка продукта. Программный код генерируется в соответствии с DDS на данном этапе.

QA Engineer параллельно с разработчиками уточняет детали реализации, пишет тест-кейсы, автоматизированные тесты, настраивает окружения для тестирования и обеспечивает «shift-left тестирование» — ранний поиск дефектов.

Этот этап обычно является подмножеством всех этапов, поскольку в современных моделях тестирования SDLC в основном затрагивает все этапы SDLC. Однако этот этап касается только этапа тестирования продукта, на котором дефекты продукта регистрируют, отслеживают, исправляют и повторно тестируют, пока продукт не достигнет стандартов качества, определенных в SRS.

Цель: Проверить программное обеспечение на наличие ошибок и соответствие требованиям.

Основные задачи:

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

Результат: Протоколы тестирования, подтверждение соответствия требованиям. Дефекты продукта регистрируют, отслеживают, исправляют и повторно тестируют, пока продукт не достигнет стандартов качества.

На этой стадии QA Engineer полностью реализует основные задачи: ручное и автоматизированное тестирование, анализ багов, взаимодействие с разработчиками по исправлению дефектов, выпуск отчётов о качестве тестового покрытия.

Цель: Запуск программного обеспечения в реальной среде использования. Продукт передают заказчику.

Основные задачи:

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

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

QA Engineer проводит финальное (smoke, sanity) тестирование после выката релиза и следит за успешным развертыванием приложения в боевом окружении, готовит, если нужно, планы отката.

Цель: Поддерживать и обновлять программное обеспечение после его развертывания.

Основные задачи:

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

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

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

QA Engineer должен подключаться с самого старта SDLC, участвовать во всех ключевых этапах и быть неотъемлемой частью команды на всём жизненном цикле разработки — от требований до сопровождения продукта.

Существует несколько ключевых моделей жизненного цикла разработки программного обеспечения (SDLC — Software Development Life Cycle). Каждая модель процесса следует серии шагов, уникальных для своего типа, чтобы обеспечить успех в процессе разработки программного обеспечения.

Ниже приведены наиболее важные и популярные модели SDLC, используемые на практике:

• Водопадная модель (Waterfall)

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

• Итерационная модель (Iterative Model)

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

• Спиральная модель (Spiral Model)

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

• V-модель (V-Model, Verification and Validation Model)

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

• Модель “Большого взрыва” (Big Bang Model)

Минимальное планирование: все ресурсы вкладываются в разработку, а требования формируются и меняются по ходу работы. Обычно используется для маленьких и исследовательских проектов.

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

Другие модели SDLC:

• Гибкие методологии (Agile Model)

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

• RAD-модель (Rapid Application Development Model)

Быстрая разработка за счет активного прототипирования и вовлечения заказчика. Позволяет выпускать рабочие версии продукта за короткие сроки.

• Модель прототипирования (Prototype Model)

Создается рабочий прототип, который демонстрирует основные функции продукта для сбора обратной связи и уточнения требований перед финальной разработкой.

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