Каскадная модель (Waterfall) и V-модель (V-model) — две предиктивные (plan-driven) модели жизненного цикла: фазы идут последовательно, а качество требований на ранних этапах определяет стоимость всего проекта. Эта заметка детализирует две конкретные predictive-модели из общей карты SDLC и STLC (→ 00.03 Жизненный цикл ПО и место аналитика (SDLC, STLC)): когда выбирать каскад или V, чем они отличаются для аналитика и где заканчивается «учебная схема», а начинается отраслевой стандарт вроде V-Modell XT.

1. Суть темы

Waterfall в учебниках — линейная цепочка фаз от анализа до сопровождения. V-model — не «другой процесс», а детализация того же предиктивного SDLC с акцентом на парность «спецификация слева ↔ проверка справа» и на сдвиг подготовки тестов влево по времени.

Обе модели опираются на formal gates: переход к следующей фазе возможен только после выполнения entry criteria (что должно быть готово до входа) и exit criteria (что подписывается при выходе). После фиксации baseline требований любое изменение scope проходит через формальную процедуру (→ 02.05.02 Управление изменениями (Change Control Board)) — именно поэтому predictive-модели уместны при стабильном scope и fixed-price контрактах.

1.1 Waterfall: история и учебная схема

В 1970 году Уинстон Ройс опубликовал статью «Managing the Development of Large Software Systems», которую часто называют источником Waterfall. Важно: Ройс критиковал наивный однопроходный каскад без обратной связи и рекомендовал итерации между стадиями и как минимум два прохода разработки. То, что в учебниках называют «классическим Waterfall», — упрощённая педагогическая схема, а не дословное воспроизведение статьи Ройса.

На практике каскад редко бывает «чистым»: встречаются incremental waterfall (многофазная поставка по этапам — на крупных программах часто сочетается с масштабируемыми фреймворками, см. 05.03 SAFe и LeSS — аналитик в масштабируемых фреймворках), overlapping phases (следующая фаза начинается до полного закрытия предыдущей) и другие гибриды. Жёсткость модели — свойство договорённости о gates и baseline, а не неизбежность диаграммы.

flowchart LR
    A[Анализ требований] --> B[Проектирование]
    B --> C[Разработка]
    C --> D[Тестирование]
    D --> E[Внедрение]
    E --> F[Сопровождение]
    D -.->|исправление дефектов in-phase| C
    B -.->|уточнение in-phase, не смена baseline| A

Учебная схема Waterfall. Пунктирные стрелки — ограниченные итерации внутри фазы или по согласованию change control до sign-off; это не откат baseline после formal gate. Смена scope после sign-off SRS — отдельная процедура CCB, на диаграмме она не показана.

1.2 V-model: та же линейность, другой акцент

V-модель возникла в оборонных и embedded-проектах (одна из ранних публикаций — Paul Rook, 1986) как способ связать уровни спецификации с уровнями тестирования. На диаграмме буква V: левая ветвь — нисходящее уточнение требований и проектных решений, правая — восходящая интеграция и проверка, в основании — реализация.

Правая ветвь V — каркас STLC (Software Testing Life Cycle): unit → integration → system → UAT. Детали уровней тестирования, роли QA и место аналитика на приёмке — в 00.03 Жизненный цикл ПО и место аналитика (SDLC, STLC); здесь важна парность «артефакт слева ↔ уровень проверки справа».

Не путать: диаграмму «generic V» в медицине, авионике и enterprise QA и V-Modell XT — немецкий процессный стандарт с ролями, продуктами, tailoring и контрактными обязательствами. На совещании «рисуем V» обычно имеют в виду парность уровней; в контракте с госзаказчиком Германии — V-Modell XT как normative process framework.

flowchart TD
    subgraph "Левая сторона (спецификация)"
        A[Бизнес-требования] --> B[Системные требования]
        B --> C[Высокоуровневое проектирование]
        C --> D[Детальное проектирование]
    end
    D --> E[Реализация]
    subgraph "Правая сторона (проверка / STLC)"
        E --> F[Модульное тестирование]
        F --> G[Интеграционное тестирование]
        G --> H[Системное тестирование]
        H --> I[Приёмочное тестирование]
    end
    B -.->|верификация| H
    A -.->|валидация| I
    C -.->|верификация| G
    D -.->|верификация| F

Пунктир — проверочная связь «артефакт ↔ уровень теста». Термины верификация и валидация — по 02.04.01 Верификация и валидация (V&V): системное тестирование верифицирует SRS; UAT валидирует бизнес-потребность.

1.3 Мост: одна фаза «Проектирование» в Waterfall и две ступени в V

В упрощённом Waterfall проектирование — одна фаза (архитектура, интерфейсы, БД). V-model раскладывает её на две ступени с разными парами тестов:

Waterfall (одна фаза)V-model (левая ветвь)Парный уровень тестирования
Проектирование (целиком)Высокоуровневое проектирование (HLD)Интеграционное тестирование
(внутри той же фазы)Детальное проектирование (LLD)Модульное тестирование

Пары HLD↔integration и LLD↔unit — типовое соответствие учебной схемы. В части организаций и стандартов (DO-178C, V-Modell XT, IEEE 1012) mapping уровней документации и тестов настраивается (tailoring) — особенно на границе component vs integration. Зафиксируйте пары в плане V&V проекта, а не копируйте таблицу «на экзамен».

Фазы анализ требований и системные требования (SRS) в V соответствуют первой фазе Waterfall; фаза тестирование в Waterfall агрегирует все уровни правой ветви V. V-model не добавляет новых видов работ — делает явными уровни документации и момент, когда пишутся тест-кейсы.

2. Ключевые понятия

2.1 Фазы Waterfall: артефакты и gates

ФазаСодержаниеКлючевые артефакты аналитикаEntry criteriaExit criteria
Анализ требованийСбор, анализ, документированиеBRD, SRS, Use Case, NFRУтверждён Vision/Scope, назначены stakeholders, план elicitationSign-off SRS, baseline требований; [[02.04.03 Управление качеством требований
ПроектированиеАрхитектура, интерфейсы, модель данныхHLD/LLD, [[03.01.01 Понятие архитектуры ИС и её виды (бизнес-, системная, техническая)архитектура ИС]], [[10.01.13 Шаблон архитектурного решения (ADR)ADR]], спецификации интерфейсов (→ 03.01.04 Интерфейсы и интеграционные взаимодействия)
РазработкаРеализация по проектуУточнения и CR только через CCB после baseline (→ 02.05.02 Управление изменениями (Change Control Board))Подписаны HLD/LLD, трассировка к SRSCode complete
ТестированиеПроверка на соответствие требованиямМатрица «требование ↔ тест», участие в UATГотовые test plans/cases, тестовая среда, code completeTest complete, акт приёмки
ВнедрениеПередача в эксплуатациюRelease notes, обновление документацииПройдены exit criteria тестирования, план cutoverGo-live sign-off
СопровождениеПоддержка и эволюцияChange Requests, impact analysisПринята система в эксплуатациюCCB-решение по изменениям

Baseline требований после sign-off SRS обычно владеет заказчик, уполномоченный представитель или владелец контракта (в продуктовых командах product owner — частный случай) при поддержке BA/SA; PM отвечает за процесс gate и журнал изменений. Аналитик обеспечивает качество и полноту спецификации до baseline — см. 10.04 Чеклист аналитика перед стартом разработки.

В учебном Waterfall трассировка желательна; в regulated V-model — обязательна с двунаправленной прослеживаемостью для аудита (→ 02.03.04 Трассировка требований (концепция), 10.01.15 Шаблон матрицы трассировки).

2.2 Уровни V-model: требования ↔ тесты

Уровень (левая сторона)Артефакт аналитикаУровень тестированияТип V&V
Бизнес-требованияBRD, критерии успехаUATВалидация
Системные требованияSRS, Use CaseСистемное тестированиеВерификация
Высокоуровневое проектированиеHLD, контракты APIИнтеграционное тестированиеВерификация
Детальное проектированиеLLD, алгоритмы; FRD — если принято на проектеМодульное тестированиеВерификация

Привязка FRD к детальному проектированию зависит от стандарта проекта: в одних организациях функциональная спецификация фиксируется на уровне SRS; в regulated V-model отдельный FRD может жить рядом с LLD. Уточняйте mapping в 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD) и в плане V&V проекта. Пары «уровень дизайна ↔ уровень теста» — subject to tailoring (см. §1.3).

2.3 Сравнение моделей

ХарактеристикаWaterfall (учебная схема)V-model
ФокусПоследовательность фазПарность спецификации и тестирования
ПроектированиеОдна фазаHLD + LLD с разными тест-парами
Планирование тестовЧасто откладывают до фазы «Тестирование»; допустимо параллельно, но схема это не подчёркиваетТест-дизайн и статическое рецензирование на левой ветви, до кода
ТрассировкаЖелательнаОбязательна (особенно regulated)
Изменения после baselineДорогиДороги + пересмотр тест-пакета
Типичный контекстНебольшие проекты, stable scopeКритические системы, сертификация, fixed-price enterprise

Процессные группы ISO/IEC/IEEE 12207 (разработка, верификация, валидация, управление конфигурацией) накладываются на обе модели; стандарт не диктует выбор Waterfall или Agile (→ 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148)). Для планов V&V в enterprise-среде см. IEEE 1012; для качества и структуры SRS на gate baseline — ISO/IEC/IEEE 29148.

3. Как применяется в работе аналитика

3.1 Что меняется для аналитика: Waterfall vs V

Общие компетенции BA/SA (интервью, SRS, stakeholders) одинаковы в любой модели — см. 02.03.03 Спецификация требований (SRS, Use Case, User Story). Отличия predictive-моделей для аналитика:

АспектWaterfallV-model
Момент участия QA/тест-дизайнаПреимущественно после разработки (фаза «Тестирование»)Совместно на левой ветви: тест-кейсы из SRS до кода
Статическое рецензирование SRSРекомендуется перед baselineGate перед переходом к проектированию (→ 08.03 Тестирование требований (статическое тестирование), 08.04 Рецензирование и инспекции (техники Фейгана))
ТрассировкаМатрица по мере зрелостиПолная bidirectional trace: требование ↔ дизайн ↔ тест
Критерии приёмкиФиксируются в SRS / UAT-сценарияхЯвная связь AC с UAT и бизнес-требованиями (→ 02.04.02 Критерии приёмки (Acceptance Criteria))
ИзмененияCCB после baselineCCB + пересчёт покрытия тестами затронутых уровней

В V-model аналитик формулирует тестируемые требования: каждое утверждение SRS должно иметь проверяемый критерий и строку в матрице трассировки. «Заморозка» после фазы — часть жизненного цикла требования в predictive-контуре.

3.2 Когда уместны сегодня

Predictive-модели не вытеснены Agile. Они оправданы, когда:

  • требования стабильны и scope маловероятно существенно изменится;
  • нужна сертификация или audit trail (авионика DO-178C, медизделия ISO 13485, госзаказ — контекст compliance см. 08.06 Юридические и регуляторные требования РФ (PCI-DSS));
  • контракт fixed price опирается на детальный SRS/baseline;
  • организация сознательно выбирает полную документированную трассируемость вместо скорости итераций.

Не использовать как единственный критерий: «команда распределена» — async Agile и документо-ориентированные процессы тоже возможны; важнее стабильность требований и регуляторика, а не география.

Для быстрых итеративных подходов «до Agile» см. 05.05 Методология быстрой разработки (RAD, XP); для value-driven итераций — 05.02 Scrum и Kanban (аналитик в Agile).

3.3 Гибриды и mini-V в итерации

На практике часто комбинируют: Vision/BRD и NFR фиксируют предиктивно, разработка идёт спринтами. Внутри релиза или спринта возможен mini-V-цикл:

flowchart LR
    subgraph "Итерация / инкремент"
        R[Уточнение slice требований] --> D[Дизайн slice]
        D --> C[Реализация]
        C --> T[Unit + integration tests]
        T --> A[Demo / UAT slice]
    end
    R -.->|release-level SRS baseline| BL[Baseline релиза]
  • Release-level (один раз на версию): baseline SRS, архитектурные решения, regulatory trace — полная левая ветвь V.
  • Iteration-level (каждый спринт): уточнение slice требований → дизайн фичи → код → автотесты → demo; полный регресс и формальный UAT — на границе релиза.

Unit- и integration-тесты на левой ветви mini-V в гибридах обычно автоматизируются в CI/CD (→ 07.06 CICD и конвейеры — влияние на требования); V-model не сводится к ручным test cases — важна прослеживаемость от требования до прогона в pipeline.

Без такого разделения утверждение «каждая итерация проходит mini-V» остаётся декларацией: зафиксируйте в проектных правилах, что обязательно в спринте, а что — только при release sign-off.

4. Типовые ошибки и ограничения

Ошибки:

  • Считать статью Ройса «каноном жёсткого каскада» и игнорировать итерации и change control, которые он сам описывал.
  • Отождествлять диаграмму V с V-Modell XT в контракте без tailoring и без ролевой модели стандарта.
  • Писать ТЗ/SRS на фазе проектирования — в типовой практике спецификация требований закрывается до HLD/LLD (→ 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD)).
  • Подписывать «валидацию» на системном тесте — путаница с 02.04.01 Верификация и валидация (V&V); validation — зона UAT и бизнес-критериев.
  • Неверно размещать FRD — см. §2.2 и 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD).
  • Запускать V-model без матрицы трассировки в regulated-контуре — аудит не пройдёт.

Ограничения обеих моделей:

Waterfall в «карикатурном» однопроходном виде — удобный антипример в сравнении с Agile; на реальных enterprise-проектах чаще встречаются gates, overlapping phases и гибриды, а не literal waterfall.

Связи с другими разделами базы

Источники и дополнительные материалы

Книги и статьи

  • Winston Royce. «Managing the Development of Large Software Systems» (1970) — первоисточник; автор описывает итерации и критикует наивный однопроходный каскад: https://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf
  • Paul Rook. «Controlling software projects». Software Engineering Journal, Vol. 1, No. 1, January 1986, pp. 7–16 (GEC Software Ltd.) — ранняя публикация V-диаграммы: https://doi.org/10.1049/sej.1986.0003
  • Ian Sommerville. Software Engineering, 10th ed., Pearson, 2016. Гл. 2 «Software processes» (§2.1.1 — waterfall; V-model и связь test plans с фазами — Fig. 2.7 в контексте validation).

Стандарты

  • ISO/IEC/IEEE 12207:2017 «Systems and software engineering — Software life cycle processes»: https://standards.ieee.org/standard/12207-2017.html
  • ISO/IEC/IEEE 15288 (systems life cycle processes) — при акценте на системах, а не только на ПО.
  • ISO/IEC/IEEE 29148:2018 «Systems and software engineering — Life cycle processes — Requirements engineering» — качество и структура SRS на gate baseline.
  • IEEE 1012 «Standard for System, Software, and Hardware Verification and Validation» — планы V&V в enterprise и regulated-контексте.
  • V-Modell XT — официальный портал (процессный стандарт, не тождественен учебной V-диаграмме): https://www.cio.bund.de/Webs/CIO/DE/digitaler-wandel/Achitekturen_und_Standards/V_Modell_XT/v_modell_xt-node.html

Дополнительно