Жизненный цикл программного обеспечения (Software Development Life Cycle, SDLC) задаёт, когда и в какой последовательности создаётся продукт; жизненный цикл тестирования (Software Testing Life Cycle, STLC) — как проверяется качество и соответствие требованиям. STLC не сводится к функциональной сверке: в него входят проверки NFR, регресс, оценка рисков и при необходимости исследовательское тестирование (→ 08.02 Нефункциональные требования (НФТ) — классификация и стандарты). Аналитику нужны оба контура: первый определяет, где вы формулируете и согласовываете требования, второй — где ваши артефакты становятся основой для проверки качества. Эта статья — каркас для раздела «Введение»: фазы, артефакты и границы ответственности BA/SA/FA (→ 00.01 Кто такой аналитик (роли BA, SA, FA)); детали методологий — в 05.01 Waterfall и V-model, 05.02 Scrum и Kanban (аналитик в Agile).
1. Суть темы
SDLC — совокупность процессов от идеи продукта до его вывода из эксплуатации: планирование, анализ, проектирование, разработка, тестирование, внедрение, сопровождение и завершение жизни системы. Это не одна «водопадная» схема, а рамка: конкретная модель (Waterfall, V-model, Scrum, DevOps) накладывается поверх и определяет, идут ли фазы последовательно, параллельно или итеративно (→ 05.01 Waterfall и V-model, 05.04 DevOps и непрерывная поставка — влияние на анализ).
STLC — структурированный контур обеспечения качества: от анализа требований с точки зрения тестируемости до закрытия тестирования и sign-off релиза. STLC не заменяет SDLC: тестирование — одна из фаз или сквозная активность SDLC, а STLC детализирует как QA-команда планирует, проектирует и выполняет проверки.
flowchart TB
subgraph SDLC [SDLC — создание и поставка ПО]
P[Планирование]
R[Требования]
D[Проектирование]
Dev[Разработка]
T[Тестирование]
Dep[Внедрение]
M[Сопровождение]
P --> R --> D --> Dev --> T --> Dep --> M
end
subgraph STLC [STLC — контур QA]
RA[Анализ требований для тестов]
TP[Планирование тестирования]
TD[Проектирование тест-кейсов]
TE[Подготовка среды]
Ex[Выполнение тестов]
TC[Закрытие тестирования]
RA --> TP --> TD --> TE --> Ex --> TC
end
R -.->|спецификации| RA
Dev -.->|сборки| Ex
T --- STLC
TC -.->|sign-off| Dep
Диаграмма показывает упрощённую последовательность для ориентира. В Agile, DevOps и CD фазы SDLC и шаги STLC перекрываются и повторяются итерациями — линейная цепочка не описывает реальный календарь проекта.
Три «жизненных цикла», которые не стоит смешивать:
| Контур | Объект | Вопрос |
|---|---|---|
| Жизненный цикл ПО (SDLC) | Продукт или система целиком | Как мы создаём, поставляем, поддерживаем и выводим решение? |
| Жизненный цикл требования | Отдельное требование или user story | Какие состояния проходит одна потребность от идеи до реализации и изменения? (→ 02.05.05 Жизненный цикл требования) |
| Релизный / спринтовый цикл | Инкремент в Agile или релиз в CD | Что входит в текущую итерацию и когда оно готово к поставке? (→ 05.02 Scrum и Kanban (аналитик в Agile)) |
На проекте все три работают одновременно: SDLC задаёт общую дорожку, жизненный цикл требования — правила для каждого элемента бэклога, спринт — такт поставки.
2. Ключевые понятия
Фазы SDLC (обобщённая модель)
Названия и границы фаз зависят от организации и методологии; для аналитика важен смысл, а не канон из учебника:
| Фаза SDLC | Цель | Ключевой результат |
|---|---|---|
| Планирование / инициация | Обосновать целесообразность, границы, ресурсы | Business Case, Vision & Scope, roadmap |
| Анализ требований | Зафиксировать, что нужно бизнесу и системе | БТ, ФТ, НФТ, модели процессов |
| Проектирование | Описать как система реализует требования | Архитектурные и системные модели, контракты |
| Разработка | Реализовать решение в коде и конфигурации | Рабочий инкремент, CI-сборки |
| Тестирование | Проверить соответствие требованиям и качество | Отчёты о дефектах, sign-off |
| Внедрение | Доставить решение пользователям | Релиз, миграция, обучение |
| Сопровождение | Поддерживать и развивать продукт | Запросы на изменение, патчи |
| Вывод из эксплуатации | Безопасно завершить жизнь системы | Архив требований и документации, миграция или удаление данных, compliance |
Международная рамка процессов — ISO/IEC/IEEE 12207:2017 (acquisition, supply, development, operation, maintenance, disposal). Актуальные редакции и связь с другими стандартами — в 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148). Стандарт не навязывает Waterfall или Scrum — команда выбирает модель и «накладывает» на неё процессы из стандарта.
На фазе вывода из эксплуатации аналитик участвует точечно: фиксирует, какие требования и данные архивируются, какие интеграции отключаются, какие регуляторные обязательства сохраняются после retirement системы.
Фазы STLC
STLC детализирует работу QA; аналитик участвует на стыке, а не вместо тестировщика. Контур охватывает не только функциональные проверки, но и NFR, регрессию и риск-ориентированный отбор сценариев (→ 08.02 Нефункциональные требования (НФТ) — классификация и стандарты).
| Фаза STLC | Суть | Типичный вход от аналитика |
|---|---|---|
| Анализ требований для тестирования | Понять, что и как проверять | Спецификации, глоссарий, уточнение неоднозначностей |
| Планирование тестирования | Стратегия, ресурсы, сроки, scope тестов | Приоритеты с бизнес-стороны, границы релиза |
| Проектирование тест-кейсов | Сценарии, данные, ожидаемые результаты | Критерии приёмки, трассировка к требованиям |
| Подготовка тестовой среды | Данные, конфигурация, доступы | Тестовые наборы данных, описание ролей |
| Выполнение тестов | Прогон, фиксация дефектов | Разбор «баг в коде» vs «ошибка в требовании» |
| Закрытие тестирования | Отчёт, метрики, решение о релизе | Подтверждение покрытия требований, участие в UAT |
Связь SDLC и STLC: V-model как частный случай
В V-model (→ 05.01 Waterfall и V-model) каждой фазе проектирования слева соответствует уровень тестирования справа: требования ↔ приёмочные тесты, системное проектирование ↔ системные тесты и т.д. Для аналитика это означает: чем раньше зафиксированы требования и критерии приёмки, тем раньше QA может проектировать проверки. Соответствие уровней тестов и артефактов проектирования — в 05.01 Waterfall и V-model.
Shift-left: аналитик и качество «слева»
Shift-left — перенос проверок качества влево по временной шкале SDLC: не ждать готового кода, а проверять требования, дизайн и testability до разработки. Для аналитика это не «стать тестировщиком», а:
- писать проверяемые требования и критерии приёмки до старта разработки (→ 02.04.02 Критерии приёмки (Acceptance Criteria));
- участвовать в рецензировании спецификаций вместе с QA (→ 08.03 Тестирование требований (статическое тестирование), 08.04 Рецензирование и инспекции (техники Фейгана));
- поддерживать трассировку «требование → тест → результат» (→ 02.03.04 Трассировка требований (концепция)).
В Agile ту же идею реализуют через Three Amigos (PO / dev / QA на одну историю) и BDD-сценарии — детали в 05.02 Scrum и Kanban (аналитик в Agile).
3. Как применяется в работе аналитика
По фазам SDLC смещается акцент между бизнес- и системным анализом: в начале доминирует бизнес-контекст и «зачем», в середине — системная спецификация и «как», на приёмке снова выходит на первый план бизнес-валидация. Это не смена роли, а смещение фокуса BA и SA внутри одного контура (→ 00.02 Бизнес-анализ vs Системный анализ vs Требования).
Место BA, SA и FA по фазам SDLC
Роли из 00.01 Кто такой аналитик (роли BA, SA, FA) распределяются по фазам не равномерно: BA силён в начале и на приёмке, SA — в середине (требования → проектирование → поддержка dev/QA), FA — там, где решение строится на типовой платформе.
| Фаза SDLC | Цель для команды | Артефакты аналитика | Основные стейкхолдеры |
|---|---|---|---|
| Планирование | Согласовать «зачем» и границы | Vision & Scope, Business Case, high-level scope | Спонсор, PO, PM, архитектор |
| Анализ требований | Зафиксировать потребности и ограничения | BRD, user stories, модели AS-IS/TO-BE, карта стейкхолдеров | Бизнес-пользователи, PO, SA/FA |
| Проектирование | Описать поведение и структуру системы | SRS, Use Cases, ER/API-модели, NFR; контекст и границы системы (→ 03.01.02 Моделирование контекста системы (Context Diagram)) | SA, архитектор, разработчики, QA |
| Разработка | Реализовать инкремент | Уточнения, ADR по решению, актуализация спецификаций | Dev, SA, FA (кастом платформы) |
| Тестирование (в SDLC) | Подтвердить качество и соответствие | Критерии приёмки, матрица трассировки, участие в triage | QA, BA/SA, бизнес (UAT) |
| Внедрение | Безопасно вывести в prod | Release notes, инструкции, чеклисты миграции | Ops, поддержка, бизнес |
| Сопровождение | Управлять изменениями и инцидентами | Запросы на изменение, impact analysis | Поддержка, PM, BA/SA |
| Вывод из эксплуатации | Завершить жизнь системы без потери compliance | Архив спецификаций, план миграции данных, матрица «что сохраняем» | Бизнес, compliance, ops |
Форматы документов по фазам — в 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD); классификация БТ/ФТ/НФТ — в 02.03.01 Классификация требований (БТ, ФТ, НФТ).
Участие аналитика в STLC (без подмены QA)
Граница ответственности: QA владеет стратегией тестирования, тест-кейсами и выполнением; аналитик владеет ясностью требований и связью «бизнес-ожидание ↔ проверка». Triage дефектов обычно ведёт QA или dev-lead; аналитик подключается, когда нужно уточнить expected result или переклассифицировать дефект как проблему требования — но не берёт на себя написание и прогон тест-кейсов.
| Фаза STLC | Что делает аналитик | Что остаётся за QA |
|---|---|---|
| Анализ требований | Отвечает на вопросы QA, устраняет двусмысленности, оценивает testability | Формирует подход к покрытию, выявляет пробелы в спецификации |
| Планирование | Согласует приоритеты проверок с бизнес-рисками | План, ресурсы, инструменты, календарь |
| Проектирование тест-кейсов | Ревью сценариев на соответствие требованиям; дополняет критерии приёмки | Пишет и поддерживает тест-кейсы, автотесты |
| Подготовка среды | Описывает тестовые данные, роли, бизнес-сценарии для наполнения среды | Разворачивает среду, настраивает инструменты, проверяет доступы |
| Выполнение | Классифицирует дефекты (требование vs реализация), уточняет expected result | Прогон, регресс, отчётность |
| Закрытие / UAT | Организует или фасилитирует приёмку бизнесом (BA, FA) | Итоговый test summary, метрики качества |
UAT (User Acceptance Testing) — зона, где BA и FA чаще всего ведут бизнес-пользователей; формальная V&V и sign-off — см. 02.04.01 Верификация и валидация (V&V).
Непрерывная поставка: фазы «размываются»
При DevOps и continuous delivery (→ 05.04 DevOps и непрерывная поставка — влияние на анализ, 07.06 CICD и конвейеры — влияние на требования) SDLC перестаёт быть линией «раз в конце — тест». Аналитик работает потоком: уточнение stories в спринте, ревью PR с точки зрения требований, участие в release readiness. Каркас фаз остаётся полезным для понимания артефактов и handoff, даже если календарно всё идёт параллельно.
Практический ориентир
Перед передачей фичи в разработку проверьте минимум:
- Требование однозначно и проверяемо (→ 02.04.03 Управление качеством требований).
- Есть критерии приёмки, понятные QA и бизнесу.
- Зафиксирована трассировка к цели или epic.
- QA видел спецификацию до начала разработки (shift-left).
Чеклист перед стартом разработки — в 10.04 Чеклист аналитика перед стартом разработки.
4. Типовые ошибки и ограничения
- Путать SDLC с методологией. SDLC — что делаем на каждом этапе; Scrum/Kanban/Waterfall — как организуем работу. Одна и та же фаза «требования» в Scrum укладывается в спринт, в Waterfall — в отдельный документный этап.
- Подменять QA на этапе тестирования. Аналитик не должен единолично «закрывать качество»: без независимого QA теряется проверка предположений автора требований. Участие в triage — не то же самое, что владение тест-планом и прогоном.
- Игнорировать STLC до «готового билда». Позднее подключение QA ведёт к переделкам: требования оказываются неполными, критерии приёмки — после факта.
- Документировать всё upfront в Agile. В итеративной модели детальная спецификация нужна на горизонте спринта или релиза, а не на год — иначе scope creep и мёртвая документация (→ 02.05.03 Управление объёмом (Scope Creep) и ожиданиями).
- Смешивать жизненный цикл продукта и требования. Закрытие одной user story не означает конец SDLC; изменение одного NFR может затронуть несколько фаз — отслеживайте состояние каждого требования через 02.05.05 Жизненный цикл требования.
- Ожидать линейности в enterprise. Согласования через 02.05.02 Управление изменениями (Change Control Board) и регламенты растягивают фазы; аналитик часто становится «узким местом» на стыке бизнеса и IT — не локальная оптимизация документа, а согласование потока (→ 02.05.02 Управление приоритетами в условиях изменчивости).
Связи с другими разделами базы
- Роли аналитика: 00.01 Кто такой аналитик (роли BA, SA, FA)
- BA vs SA vs управление требованиями: 00.02 Бизнес-анализ vs Системный анализ vs Требования
- Стандарты жизненного цикла и требований: 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148)
- Архитектура и контекст системы (фаза проектирования): 03.01.01 Понятие архитектуры ИС и её виды (бизнес-, системная, техническая), 03.01.02 Моделирование контекста системы (Context Diagram)
- NFR в контуре тестирования: 08.02 Нефункциональные требования (НФТ) — классификация и стандарты
- Модели SDLC (Waterfall, V-model): 05.01 Waterfall и V-model
- Аналитик в Agile и спринтовый цикл: 05.02 Scrum и Kanban (аналитик в Agile)
- DevOps и непрерывная поставка: 05.04 DevOps и непрерывная поставка — влияние на анализ
- Управление изменениями: 02.05.02 Управление изменениями (Change Control Board)
- Спецификация и форматы артефактов: 02.03.03 Спецификация требований (SRS, Use Case, User Story), 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD)
- Критерии приёмки и V&V: 02.04.02 Критерии приёмки (Acceptance Criteria), 02.04.01 Верификация и валидация (V&V)
- Жизненный цикл отдельного требования: 02.05.05 Жизненный цикл требования
- Статическое тестирование требований (shift-left): 08.03 Тестирование требований (статическое тестирование)
- Чеклист перед разработкой: 10.04 Чеклист аналитика перед стартом разработки
Источники и дополнительные материалы
Книги и стандарты:
- ISO/IEC/IEEE 12207:2017 — Systems and software engineering — Software life cycle processes. Общая рамка процессов жизненного цикла ПО, включая disposal; не предписывает конкретную модель разработки. Актуальные редакции — см. 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148).
- ISO/IEC/IEEE 29148:2018 — процессы и артефакты инженерии требований в контексте жизненного цикла.
- Вигерс, К. и Битти, Дж. (2020). Разработка требований к программному обеспечению. 3-е изд. — связь фаз проекта с качеством требований и ролью аналитика на ранних этапах.
Статьи и онлайн-ресурсы:
- testRigor: STLC vs. SDLC: Key Differences and Phases Explained — сопоставление целей, scope и ролей двух контуров.
- Master Software Testing: Shift-Left Testing — перенос проверок качества на этап требований; участие BA и QA в collaborative test design.
- Master Software Testing: Requirements Analysis in Software Testing (STLC Phase Guide) — первая фаза STLC, testability, RTM; роль аналитика и QA.
- Software Testing Basics: Shift-Left Testing at the Requirements Phase — Three Amigos, ревью требований до разработки.
- ThousandEyes Learning: Software Development Life Cycle (SDLC) Phases — обзор фаз SDLC и связь с ISO/IEC 12207.