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

В 2020 году Рафаэль Жардим, Маркус дус Сантус и Э. Нету опубликовали разбор проекта, знакомого всем, кто работал с государственным заказчиком: разработки системы обороны для Вооружённых сил Бразилии. Исходная ситуация была типичной. Правила инженерии требований формально существовали, но записаны были не везде. За одним столом сидели военные и разработчики с разной подготовкой и разными интересами, и договориться о том, что именно строится, было трудно. Команда собрала жизненный цикл, в котором каскадная модель (Waterfall Model) соединена с рекомендациями стандарта ISO/IEC/IEEE 29148:2018 по инженерии требований. По оценке авторов, военным командам стали понятны процессы, а требования к системе удалось специфицировать детально.

Кейс показывает, где каскадный подход силён. Это проекты, в которых цена недоговорённости выше цены медленного старта, участников много, а результат нужно зафиксировать документом, который выдержит проверку. Логика модели простая: проект проходит фазы жизненного цикла строго по очереди — требования, проектирование, реализация, тестирование, внедрение, сопровождение. Следующая фаза начинается только после того, как предыдущая закрыта и её результат принят. Atlassian ссылается на опрос 2020 года: 56% специалистов по проектам за предыдущий год работали с традиционными, каскадными моделями. Леонард Виджаясарати и Чарльз Батлер (2015) по опросу руководителей проектов и участников команд пришли к похожему выводу. Гибкие методы за десять лет распространились, но каскад остаётся популярным, а многие организации совмещают в одном проекте несколько методологий.

Дальше разберём, откуда взялась модель и почему её авторство спорно, из каких фаз она состоит, что о ней говорят эмпирические сравнения и где она ломается. В конце — пошаговый план проекта по каскаду и разбор бесплатного тренажёра OrgDevTools для этого плана.

Происхождение и исследовательская база: каскадная модель от Бенингтона до Ройса

Модель обычно приписывают одному человеку и одной статье. Если проследить её путь по источникам, линий оказывается несколько, и они не во всём совпадают.

Линия 1. Герберт Бенингтон, 1956: многофазный цикл и прототип

Самое раннее описание поэтапной разработки программ приводят Википедия и EBSCO Research Starters. 29 июня 1956 года на симпозиуме Symposium on Advanced Programming Methods for Digital Computers Герберт Бенингтон рассказал о многофазном цикле создания программного обеспечения. В 1983 году он переиздал доклад с предисловием и уточнил две вещи. Первая: фазы были выстроены по специализации задач, то есть по тому, кто какую работу делает. Вторая: на практике процесс не шёл строго сверху вниз и опирался на прототип. Получается, что один из первоисточников последовательной схемы прямо говорит о прототипе, хотя популярные пересказы изображают каскад как движение без единого шага назад.

Линия 2. Уинстон Ройс, 1970: схема, которую позже назвали водопадом

Каноническая точка отсчёта — статья Уинстона Ройса (Winston W. Royce) «Managing the Development of Large Software Systems» 1970 года. TechTarget уточняет, что Ройс работал в Lockheed Software Technology Center и писал на основе опыта разработки программ для спутников. По формулировке Википедии, первую формальную детальную диаграмму процесса «часто приписывают» этой статье, при этом слова «waterfall» в ней нет. Atlassian признаёт, что Ройс так модель не называл, но считает его автором линейной строгой системы управления проектами. В блоге Lucid та же статья описана как работа о неэффективности программных проектов и сказано, что индивидуального создателя у методологии нет.

Каскадная модель — не изобретение одного автора, а схема, которую индустрия собрала из нескольких источников и закрепила за статьёй 1970 года.

Отсюда первое расхождение популярных пересказов с источниками. «Модель Ройса» — устоявшаяся атрибуция, а не бесспорный факт. Расхождение есть и в устройстве схемы. В обзоре arXiv 2510.03894 (2025) собраны четыре структурных прочтения каскада: (а) линейное, (б) двухпроходное, (в) с обратной связью к предыдущей фазе, (г) с обратной связью к любой предыдущей фазе. Строго линейная картинка без возвратов — лишь одно из них.

Линия 3. Белл и Тейер, 1976: появление слова «waterfall»

Сам термин, по данным Википедии, впервые встречается, вероятно, в статье Белла и Тейера 1976 года. Метафора прижилась: вода течёт с уступа на уступ и обратно не поднимается. Отсюда русские названия — «каскадная» и «водопадная» модель.

Линия 4. Учебная традиция

В учебниках модель стала стандартным первым примером процессной модели. Tutorialspoint называет её первой внедрённой моделью процесса и линейно-последовательной моделью жизненного цикла (linear-sequential life cycle model). В учебнике Иэна Соммервилла (издания 2011 и 2016 годов, по ссылке в arXiv 2510.03894) фаз пять: анализ и определение требований; проектирование системы и ПО; реализация и модульное тестирование; интеграция и системное тестирование; эксплуатация и сопровождение. В курсе Университета Олд Доминион (Steven Zeil, CS333) каскад назван самой распространённой моделью процесса, а эволюционная, спиральная и унифицированная модели вынесены за рамки курса. По оценке BMC, каскад десятилетиями оставался стандартом жизненного цикла разработки де-факто.

Линия 5. Эмпирические сравнения с прототипированием

Конспект курса MIT «Software Engineering Concepts» (2005) приводит два сравнения. У Барри Боэма каскад лучше справлялся с рисками управления продуктом и процессом. Продукт получался надёжнее и проще в сопровождении, а проблем при отладке и интеграции было меньше, потому что проектирование было продумано тщательнее. Прототипирование лучше решало задачи пользовательского интерфейса. В сравнении Алави на информационной системе пользователи прототипа были настроены позитивнее и сильнее вовлечены, а каскад дал более надёжные и эффективные структуры данных. Вывод обоих сравнений один: каскад выигрывает во внутреннем качестве системы и проигрывает в вовлечении пользователя.

Линия 6. Исследования выбора методологии

• Халифа и Вернер (2000) на основе поведенческих теорий построили и проверили модель, объясняющую, насколько глубоко и широко команды используют каскад и прототипирование. Главными факторами оказались качество процесса (process quality) и благоприятствующие условия (facilitating conditions). Иными словами, метод используют, когда он даёт качественный процесс и когда в организации есть условия его поддерживать.

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

• Виджаясарати и Батлер (2015) показали, что выбор методологии связан с характеристиками организации, проекта и команды. Гибридные схемы распространены.

• Тезинг, Фельдманн и Бурхардт (2021) сопоставили план-ориентированные (plan-driven) методы классического каскада с гибкими, итеративными и ориентированными на тесты. На основе систематического анализа литературы они построили модель решения для выбора подхода под конкретный проект.

Линия 7. Академическая критика и моделирование

Башар Нюсейбе (2001) описал механизм главной проблемы. Организация выбирает, с чего начать — с требований или с архитектуры. Начав с требований, она получает каскад с «искусственно замороженными» документами требований. Начав с архитектуры, получает систему, которая сопротивляется неизбежным и желательным изменениям. Нюсейбе указывает, что спиральная модель снимает многие недостатки каскада: она инкрементальна и раз за разом переоценивает риски проекта.

Аденово и Аденово (2013) в обзоре сравнили каскад с объектно-ориентированным подходом. По их выводам, каскад подходит для последовательного, процедурного проектирования. Ошибки в нём обнаруживаются в конце процесса, повторить цепочку фаз трудно, а созданное так ПО сложнее сопровождать и обновлять из-за слабой интеграции компонентов.

Юссеф Бассиль (2012) построил имитационную модель каскада из пяти фаз. Сбои, перерасходы бюджета и срывы сроков он связывает с тем, что руководители неверно распределяют людей и ресурсы по фазам: где ресурсов не хватает, фаза задерживается. В модели заложены допущения: 70% входящих проектов малые, 25% средние, 5% крупные. Для малых проектов вероятность ошибки после каждой фазы задана как 10%, и при ошибке задача возвращается на предыдущий шаг. Это параметры симуляции, а не измерения реальных проектов, и цитировать их как статистику отрасли нельзя.

Линия 8. Новые контексты: безопасность, стандарты, ИИ-агенты

Хеагер и Нильсен (2018) в систематическом обзоре разобрали спор о том, как разрабатывать системы с критичной безопасностью — медицинские устройства, управление движением, обнаружение патогенов. Обсуждаются два варианта: традиционный каскад или более быстрые гибкие процессы. Бразильский кейс Жардима и соавторов (2020) относится к той же области: в регулируемой и оборонной разработке каскад сочетают со стандартами требований. Неожиданная линия — ChatDev (Цянь и соавторы, 2023). Авторы отмечают, что многие работы применяли глубокое обучение к отдельным фазам каскада: проектированию, кодированию, тестированию. Модели разных фаз оказывались технически несовместимы, и процесс распадался. ChatDev предлагает агентов на больших языковых моделях, которые проходят цепочку фаз через «цепочку диалогов» (chat chain). Фазы каскада здесь служат каркасом для разделения работы между агентами.

Ключевые идеи и принципы: как устроена каскадная модель

1. Принцип: фазы идут по очереди и не перекрываются

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

2. Принцип: результат фазы — вход следующей

   Каждая фаза выдаёт конкретный артефакт, и следующая фаза строится на нём, а не на устных договорённостях. Требования оформляются в спецификацию, по ней делается проект, по проекту пишется код, код проверяется на соответствие требованиям. Поэтому каскад называют документо-ориентированным (document driven), а спиральную модель, по конспекту MIT, — риск-ориентированной (risk driven).

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

3. Принцип: формальное подтверждение перехода (sign-off)

   Фаза закрывается подписью: заказчик или ответственный подтверждает, что результат принят и на нём можно строить дальше. У каждой фазы есть свои артефакты и процедура проверки (review process), отмечает Tutorialspoint. В учебных материалах Университета Олд Доминион спецификация требований описана как договор между клиентом и исполнителем. Подпись под ней — юридическая и управленческая точка, после которой изменения проходят через отдельную процедуру.

4. Принцип: шесть фаз жизненного цикла

   Число фаз у разных авторов разное: у Соммервилла и GeeksforGeeks пять, у Lucid и в нашем фрейме шесть, в Википедии девять. Содержание при этом одно и то же.

   • Требования (Requirements, Requirements Analysis and Specification). Устанавливается, что заказчику нужно от системы. Требование — это либо описание того, что система должна делать (внешнее поведение), либо ограничение, в котором она должна работать. Формулировка бывает от абстрактной до детальной математической. Итог фазы — спецификация требований к ПО (SRS, Software Requirements Specification). Сюда же входит технико-экономическое обоснование (feasibility study). Код на этой фазе не пишут. Подробнее о документе — в методике Спецификация требований к ПО (SRS).

   • Проектирование (Design, System Design). Спецификация превращается в архитектуру. Высокоуровневый проект (HLD, High-Level Design) описывает общую структуру, низкоуровневый (LLD, Low-Level Design) — модули. Отдельно проектируются база данных и макеты интерфейса. В курсе ODU архитектурные решения названы «глобальными»: хранить данные в файлах или в базе, работает система на одном компьютере или распределена, как обрабатывать ошибки во время выполнения.

   • Реализация (Implementation, Development). Код пишется по проектным документам, работа делится на модули, каждый модуль проходит модульное тестирование. Обычно это самая длинная фаза.

   • Тестирование (Testing, Verification, Integration and Testing). Модули собираются в систему и проверяются на соответствие требованиям. Тестирование — это выполнение программы на подобранных данных, чтобы найти дефекты. Отладка — другое: поиск ошибочного кода, из-за которого тест упал. Тестирование — самая распространённая, но не единственная форма верификации и валидации (V&V).

   • Внедрение (Deployment, Acceptance, Installation). Система проходит приёмку, устанавливается и передаётся пользователям.

   • Сопровождение (Maintenance). Исправление найденных в эксплуатации дефектов, доработки, адаптация к изменениям среды.

   Википедия добавляет фазы, о которых в коротких пересказах забывают: предварительный анализ (preliminary analysis) перед требованиями, а после сопровождения — оценку (evaluation) и вывод из эксплуатации (disposal). Для руководителя это напоминание: проект живёт дольше, чем длится разработка, и стоимость владения системой закладывается ещё на первой фазе.

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

5. Принцип: поздно найденная ошибка дороже рано найденной

   Логика модели держится на простом рассуждении. Ошибка в требовании, найденная на тестировании, тянет за собой переделку всего, что на ней построено: проекта, кода, тестов. Найденная до проектирования, она стоит правки одного документа. Отсюда вывод: в ранние фазы вкладывают непропорционально много строгости.

   Как именно растёт стоимость, источники пакета не измеряют. Популярные пересказы называют рост «экспоненциальным» и приводят множитель «×10 за фазу», который приписывают Боэму. В исследованиях брифа таких цифр нет. Множитель ×10 в нашем фрейме — условная иллюстрация масштаба, а не закон. Сам принцип подтверждают данные Боэма из конспекта MIT: при продуманном проектировании проблем на интеграции и отладке меньше. В книге Смит и Уильямс «Performance Solutions» (2001) та же идея применена к производительности. Авторы противопоставляют реактивное управление производительностью, когда проблему ищут после сборки, проактивному. Проактивное начинается с оценки рисков производительности, выбора критичных сценариев использования и постановки целевых показателей.

6. Принцип: требования должны быть стабильными

   Модель работает, когда требования понятны с самого начала и не будут сильно меняться. Tutorialspoint пишет, что каскад хорош для небольших проектов с хорошо понятными требованиями. Lucid добавляет: для небольших проектов с ясной целью команда с первого дня видит общий результат и меньше тонет в деталях. Когда требования нестабильны, модель превращается в источник дорогих возвратов.

7. Принцип: преимущества каскада

   Конкуренты называют одни и те же сильные стороны:

   • Ясная структура. Модель проста для понимания и применения (Tutorialspoint, Lucid).

   • Управляемость. Линейный порядок упрощает распределение людей и ресурсов (Netrio). Жёсткость самой модели облегчает контроль (Tutorialspoint).

   • Цель определена рано. Конечный результат известен до начала реализации (Lucid).

   • Передача знаний. Документы переживают смену людей в команде (Lucid).

   • Оценки. Каскад опирается на глубокую аналитику и более точные оценки (Bitrix24).

   • Качество внутренней конструкции. Надёжнее структура данных, проще сопровождение (сравнения Боэма и Алави).

8. Принцип: модифицированные каскады

   Строгая линейность — крайняя точка спектра. В обзоре arXiv 2510.03894 перечислены двухпроходный вариант и варианты с обратной связью к соседней или любой прежней фазе. В конспекте MIT описан вариант инкрементной реализации: требования и проектирование делаются по каскаду, а при анализе выделяются полезные подмножества функций и интерфейсы для их последующего добавления. Части системы реализуются, тестируются и поставляются в разное время по приоритетам. Спиральная модель, по тому же конспекту, «включает все остальные модели», а радиус спирали отражает накопленные затраты. В литературе обсуждаются и гибриды с гибкими методами. Теохарис и соавторы (2015) спрашивают в заголовке статьи, стал ли реальностью «water-scrum-fall». Бхавсар и соавторы (2020) описывают «Scrumbanfall» — соединение Scrum и Kanban с каскадом.

9. Принцип: чем каскад отличается от Agile

   Основные различия сводятся к четырём осям. Каскад планирует всё заранее, Agile планирует итерациями. Каскад проверяет результат в конце, Agile — в каждом цикле. Каскад фиксирует требования, Agile ждёт их изменения. Каскад общается с заказчиком на входе и на приёмке, Agile — постоянно. BMC и Atlassian приводят 12 принципов Agile-манифеста как аргументы против каскада. Тезинг и соавторы предлагают выбирать подход по характеристикам проекта, а не по моде. Каскад больше подходит, когда требования стабильны, регулирование жёсткое, а результат фиксируется договором. Гибкие методы — когда неопределённость высока и нужна быстрая обратная связь от пользователя. Подробно итеративная альтернатива разобрана в методике Agile/Scrum Framework.

Ограничения, слепые зоны и критика: где каскадная модель ломается

Типовые ошибки при работе с каскадной моделью

1. Ошибка 1: каскад для проекта с нестабильными требованиями.

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

   Как избежать

   до старта оцените стабильность требований по характеристикам проекта, как в модели решения Тезинга и соавторов: насколько ясна цель, есть ли жёсткое регулирование, готов ли заказчик участвовать постоянно. При высокой неопределённости выбирайте итеративный подход или гибрид. Неясные части предварительно проверьте прототипом — см. быстрое прототипирование через MVP.

2. Ошибка 2: подпись вместо проверки.

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

   Как избежать

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

3. Ошибка 3: тестирование и производительность оставлены на конец.

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

   Как избежать

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

4. Ошибка 4: заказчик исчезает после подписи требований.

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

   Как избежать

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

5. Ошибка 5: ресурсы распределены без расчёта по фазам.

   Людей на проект выделили «в целом», без учёта того, что каждой фазе нужен свой состав и объём. Аналитиков не хватает на требования, тестировщики простаивают до последней фазы, а затем перегружены. По Бассилю, именно неверное распределение работников и ресурсов по фазам — главная причина задержек и перерасходов в каскаде.

   Как избежать

   декомпозируйте работы по фазам через иерархическую структуру работ (WBS) и разложите загрузку людей на диаграмме Ганта. Узкие места по ресурсам видны ещё до старта реализации.

6. Ошибка 6: запрет на возврат вместо управляемых изменений.

   Руководитель понимает «последовательность» буквально: подписанное не обсуждается. Изменения всё равно появляются, но идут в обход: неформальные просьбы, правки «по-тихому», расхождение кода и документации. К сопровождению документы уже не описывают реальную систему.

   Как избежать

   заведите процедуру изменений. Запрос регистрируется, оценивается влияние на подписанные артефакты, решение принимает ответственный, затем обновляются документы и повторно подписываются затронутые фазы. Модифицированные каскады с обратной связью — нормальная практика, а не отступление от модели. Риски изменений ведите в реестре — см. управление рисками проекта.

План внедрения: каскадная модель в проекте

Сроки ниже рассчитаны на проект продолжительностью полгода–год. Для меньшего проекта сожмите месяцы до недель, сохранив порядок.

1. Месяц 1: решение о модели и рамка проекта. Оцените стабильность требований: ясна ли цель, есть ли регуляторные рамки, готов ли заказчик зафиксировать объём. Если неопределённость высока, остановитесь и выберите итеративный подход или гибрид. Если каскад уместен, утвердите устав проекта, назначьте ответственных за подпись каждой фазы и запишите критерии выхода для всех шести фаз. В этот же месяц проведите предварительный анализ и технико-экономическое обоснование.

2. Месяц 2: требования и их подпись. Соберите требования через встречи с заказчиком и пользователями и оформите спецификацию: функции, ограничения, критерии приёмки, целевые показатели производительности. Для каждого требования проверьте, можно ли написать на него тест. Проведите ревью и только потом подписывайте. Подписанная спецификация становится договорной базой. Подготовьте процедуру изменений.

3. Месяц 3: проектирование. Переведите спецификацию в высокоуровневый и низкоуровневый проект: архитектура, модули, база данных, макеты интерфейса. Примите глобальные решения: хранение данных, распределённость, обработка ошибок. Покажите макеты заказчику. Декомпозируйте работы реализации и спланируйте загрузку людей по фазам. Подготовьте план тестирования. Подпись проекта открывает реализацию.

4. Месяцы 4–6: реализация. Пишите код по проектным документам, по модулям, с модульным тестированием каждого. Раз в две-три недели показывайте заказчику промежуточную сборку. Все отклонения от проекта проводите через процедуру изменений с обновлением документов.

5. Месяц 7: интеграция и тестирование. Соберите модули в систему и проверьте её по спецификации и критериям приёмки, включая показатели производительности. Отделите поиск дефектов от отладки: тестировщики находят, разработчики исправляют. Подпишите результаты тестирования.

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

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

   Хороший каскад — не тот, где не было ни одного возврата, а тот, где каждый возврат прошёл через процедуру и не разрушил документацию.

Как реализовать этот план с помощью фрейма «Каскадная модель (Waterfall Model)» в OrgDevTools

Фрейм — бесплатный тренажёр, который помогает держать дисциплину sign-off и видеть цену позднего обнаружения ошибки. Тот же фрейм привязан к инструменту «WATERFALL» («Каскадная модель — последовательные фазы без возврата») в разделе проектов и задач. Там он работает с записью конкретного проекта.

Фрейм состоит из трёх вкладок: «Фазы», «Визуализация», «Итоги». Текстовых полей нет, весь ввод — нажатия на карточки и точки.

Вкладка «Фазы». Шесть карточек слева направо со стрелками между ними: «Требования», «Проектирование», «Реализация», «Тестирование», «Внедрение», «Сопровождение». У каждой карточки три состояния:

• «ожидает sign-off» — фазу можно подтвердить;

• «заблокировано» — карточка приглушена, потому что предыдущая фаза не подтверждена;

• «✓ подтверждено» — карточка зелёная.

Нажатие подтверждает фазу, повторное снимает подтверждение. Подтвердить фазу, пока не подтверждена предыдущая, нельзя. Рядом с названием вкладки — счётчик «N/6», при всех шести подтверждениях он становится зелёным. По умолчанию ни одна фаза не подтверждена. Пользоваться вкладкой: в месяц 1 — договориться, кто нажимает кнопку по каждой фазе; затем в конце месяцев 2, 3, 6, 7 и 8 — фиксировать подпись фазы, когда её критерии выхода выполнены.

Вкладка «Визуализация». Кривая стоимости исправления ошибки в зависимости от фазы обнаружения. Множитель считается автоматически как 10 в степени номера фазы: «Требования» — ×1, «Проектирование» — ×10, и на каждой следующей фазе он ещё в десять раз больше. Фазу обнаружения выбирают нажатием на точку кривой или на подпись фазы под графиком. По умолчанию выбрана фаза «Требования». Под графиком крупно показан множитель для выбранной фазы с пояснением «относительно стоимости исправления на этапе требований» и значением для последней фазы. Вкладка нужна в месяц 1, чтобы объяснить заказчику и команде, почему ранние фазы получают столько времени. Позже — при разборе каждого найденного дефекта: на какой фазе ошибка возникла и на какой её нашли. Множитель — условная иллюстрация, а не расчёт вашего бюджета.

Вкладка «Итоги». Заголовок «Waterfall: sign-off и цена позднего обнаружения» и блок вердикта, который выбирается автоматически в таком порядке:

• ноль подтверждённых фаз — 💡 напоминание, что следующая фаза недоступна, пока не закрыта предыдущая;

• от одной до пяти — ⚠️ «Подтверждено N из 6 фаз» с множителем ×10 в степени N, то есть для первой неподтверждённой фазы;

• все шесть — ✅ сообщение о полном прохождении и множитель для фазы, выбранной на вкладке «Визуализация».

Внизу кнопка «Создать задачу →» создаёт задачу «Пройти следующий sign-off фазы Waterfall» с описанием «Подтверждено N из 6 фаз». Это шаг перехода между месяцами плана: закрыли фазу — поставили задачу на подпись следующей. В режиме только для чтения фрейм показывает состояние, но изменить его нельзя.

Книги по теме: каскадная модель

• Winston W. Royce — «Managing the Development of Large Software Systems» (1970). Статья, а не книга. Ей приписывают первую детальную диаграмму последовательного процесса, из которой выросла каскадная модель, хотя слова «waterfall» в ней нет.

• Connie U. Smith, Lloyd G. Williams — «Performance Solutions: A Practical Guide to Creating Responsive, Scalable Software» (2001). Противопоставление реактивного и проактивного управления производительностью и порядок шагов: оценка рисков, критичные сценарии, целевые показатели. Отсюда в методике требование закладывать производительность в спецификацию на первой фазе.