ANATOMYIT PRODUCT
МенеджментБудь-який рівень

Waterfall

Waterfall — це спосіб вести проєкт у фіксованому порядку, коли кожну фазу завершують і затверджують до початку наступної. Його зазвичай викладають як застаріле, що його замінив Agile, і це водночас несправедливо й некорисно: це правильний вибір щоразу, коли змінити рішення пізно коштує дорожче, ніж ретельно все описати зараз. Сторінка починається з усіх фаз на одному екрані — що кожна створює, який гейт її закриває і скільки коштує зміна на ній; далі — що насправді написав Ройс 1970 року, кожна фаза по черзі, V-модель, шість питань, що вирішують між предиктивним та ітеративним планом, гібриди, якими живуть реальні проєкти, пʼять задокументованих випадків і де все це вироджується.

Вперше намальований
Ройс, 1970 — як застереження
Назва в PMBOK
Предиктивний життєвий цикл
Зворотний звʼязок
На прийманні

Waterfall на одному екрані

Спершу — уся модель. Waterfall визначають не так фази, як те, що закриває кожну з них: документ, огляд і підпис. Таблиця проходить пʼять фаз по черзі — що кожна створює, що має бути правдою, перш ніж із неї дозволено вийти, і скільки коштує зміна, якщо її виявили саме тут.

ФазаЩо створюєГейт, що її закриваєЗміна, знайдена тут, коштує
1. ВимогиСпецифікація вимог: кожна функція, а ще — як швидко, скільки користувачів, що логується, які регуляції діють. Що до неї входить, перелічує ISO/IEC/IEEE 29148.Кожну вимогу можна перевірити тестом, і замовник підписує базову версію — у системній інженерії це System Requirements Review.Правка документа й новий підпис.
2. ПроєктуванняАрхітектура — компоненти й інтерфейси між ними — і детальний дизайн кожного компонента, з документами контролю інтерфейсів для всього спільного.Дизайн здатен виконати кожну вимогу, і це простежено рядок за рядком. В обороні й космосі це Preliminary і Critical Design Review, PDR і CDR.Проєктні документи нижче від зміни й повторний огляд.
3. РеалізаціяКод і модульні тести, збудовані під інтерфейси з дизайну, а не один під одного.Кожен модуль завершено, покрито модульними тестами й перевірено на відповідність дизайну.Переробка в кожному компоненті, що торкається зміненого інтерфейсу, плюс проєктні документи.
4. ВерифікаціяІнтегрована система, перевірена на інтеграційному, системному й приймальному рівнях, і звіт про тестування.Test Readiness Review перед початком тестування; підпис замовника про приймання — після.Усе, що вище, одночасно: хибна вимога знову відкриває дизайн і код у точці, де часу лишилося найменше.
5. СупровідСистема в експлуатації. Дефекти виправляють, а зміни вносять через формальні запити на зміну відносно базової версії.Кожен запит на зміну оцінюють за впливом, і рада з контролю змін схвалює його до початку робіт.Запит на зміну, аналіз впливу, регресійний прогін — і доповнення до контракту, якщо зсувається обсяг.

Чи брати цю модель узагалі, вирішує одне число — скільки вам коштує змінити рішення пізно, — і пʼятий розділ перетворює це число на шість питань, на які можна відповісти щодо власного проєкту.

Що насправді написав Ройс 1970 року

А тепер історія, яку варто знати, бо вона змінює те, як ви читатимете кожну схему цієї моделі, що вам колись трапиться.

Каскад походить зі статті, яку Вінстон Ройс, менеджер оборонного підрядника TRW, представив на конференції WESCON у серпні 1970 року: «Managing the Development of Large Software Systems». Його друга схема показує сім кроків у ряд — системні вимоги, вимоги до ПЗ, аналіз, проєктування програми, кодування, тестування, експлуатація. Слова «waterfall» у статті немає ніде. Приліпити до неї цю назву зазвичай приписують Томасу Беллу й Т. А. Теєру, 1976 року.

Сторінкою далі Ройс написав: «Я вірю в цю концепцію, але описана вище реалізація ризикована й запрошує до провалу». Його причина точна. Тестування — перший момент, коли час виконання, памʼять і введення-виведення не аналізують, а переживають насправді. Якщо вони не вкладаються в обмеження, доводиться змінювати дизайн, і тоді, за його словами, «процес розробки повернувся до початку, і можна очікувати перевитрати графіка та/або бюджету до 100 відсотків».

Решту статті він присвятив пʼятьом додаткам, які роблять послідовність живучою. Таблиця подає кожен під його власним заголовком — чого він вимагав і як та сама ідея називається сьогодні.

Крок РойсаЧого він вимагавЯк це звуть сьогодні
1. Program design comes first — спершу проєктування програмиПопередній дизайн — ще до аналізу, силами проєктувальників, які знають межі машини, — щоб проблеми з памʼяттю й часом виконання вилізли, поки вони ще дешеві.Архітектурний spike, walking skeleton
2. Document the design — задокументуйте дизайн«Досить багато» документації — він назвав це першим правилом керування розробкою: «безжальне дотримання вимог до документації».Проєктні документи й записи рішень — єдиний додаток, який індустрія зберегла, і навіть із надлишком
3. Do it twice — зробіть двічіЯкщо програму будують уперше, замовнику має дістатися друга версія. Для 30-місячного проєкту — скажімо, 10-місячна пілотна модель.Прототип, пілот, тонкий наскрізний зріз
4. Plan, control and monitor testing — плануйте, контролюйте й відстежуйте тестуванняТестування планують фахівці, які не писали код; кожен шматок аналізу й коду переглядає друга людина; кожен логічний шлях проходять щонайменше раз.Незалежне тестування, code review, покриття
5. Involve the customer — залучайте замовникаФормально й у визначених точках між вимогами й прийманням, бо те, що робитиме дизайн, «підлягає широкому тлумаченню навіть після попередньої згоди».Огляд чи демо наприкінці кожного інкременту
Ройс зберіг фази; один прохід викинув усе, що він поклав поверх них. Його план будує пілотну модель паралельно з вимогами й проєктуванням, тож щось запускається вже на 8-му місяці, а уроки з цього формують справжній проєкт, — і залучає замовника чотири рази, а не двічі. Версія, яку перейняла індустрія, зберегла послідовність і відкинула обидва додатки, тож уперше щось запускається на 21-му місяці, коли починається інтеграція, — і на те, щоб перетравити виявлене, лишається девʼять місяців.

Його син, Вокер Ройс, який згодом допомагав створювати Rational Unified Process, розповів Крейгові Ларману й Віктору Базілі, що батько «завжди був прихильником ітеративної, інкрементної, еволюційної розробки», а стаття описувала waterfall як найпростіший опис, що «не спрацює для будь-яких проєктів, крім найпрямолінійніших» (IEEE Computer, 2003).

Пʼять фаз по черзі

Пройдімо кожну фазу: що в ній відбувається, що вона створює і на яке питання треба відповісти, перш ніж дозволено рухатися далі.

Кожна фаза завершується й затверджується на гейті до початку наступної. У чистій моделі єдиний шлях назад — це пізній зворотний зв’язок від верифікації до вимог, і саме тому дефект, знайдений на прийманні, коштує так дорого.

1. Вимоги

Збирають і записують усе, що система має робити. Не лише функції, а й нефункціональні вимоги: як швидко, скільки користувачів одночасно, що має логуватися, які регуляції застосовуються.

Результат — специфікація, а питання гейта таке: чи всі ми згодні, що будується саме це? Підписи тут і роблять можливим усе подальше — і водночас перетворюють пізню зміну на контрактне питання, а не на розмову.

Одна перевірка відділяє придатну вимогу від побажання: чи може хтось записати, як її перевірять? «Система має бути швидкою» перевірити неможливо. «Пошук повертає результати за дві секунди для 95 відсотків запитів при 500 користувачах онлайн» — можна, і V-модель нижче робить цей тест частиною вимоги.

2. Проєктування

Специфікацію перетворюють на технічний план. Зазвичай це ділиться надвоє: високорівневий дизайн визначає компоненти й те, як вони спілкуються, а детальний — що відбувається всередині кожного.

Питання гейта — чи цей дизайн справді здатен виконати специфікацію. Саме на цій фазі досвідчений архітектор виправдовує себе, бо структурна помилка, знайдена тут, коштує тиждень, а та сама помилка, знайдена під час тестування, — квартал.

3. Реалізація

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

Це найдовша фаза і, всупереч очікуванням, найспокійніша. Усе вже вирішено, робота полягає у виконанні. Це також фаза, де проєкт найчастіше тихо відстає, бо немає працюючої системи, за якою міряти прогрес, — лише відсотки виконання.

4. Верифікація

Частини інтегрують і тестують разом, а тоді передають замовнику на приймальне тестування. Це перший момент, коли хтось бачить, як поводиться система цілком.

І саме тут проявляється центральна слабкість моделі. Кожне припущення, зроблене на етапі вимог — девʼять місяців тому, людьми, які ніколи цим не користувалися, — перевіряється одночасно, у точці, де виправити будь-яке з них найдорожче.

5. Супровід

Система працює. Дефекти виправляють, дрібні зміни проводять через формальний процес запитів на зміну, і продукт живе, доки його не замінять.

Варто зазначити: у більшості waterfall-проєктів ця фаза довша за всі інші разом узяті, і саме її зазвичай ніхто не планує як слід.

V-модель: кожна фаза в парі зі своїм тестом

Є варіант, який варто знати, бо він виправляє найбільшу практичну проблему чистої моделі, і ви зустрінете його в регульованих галузях.

V-модель бере ті самі фази й згинає лінію у літеру V. Ліве плече йде вниз через вимоги, дизайн і детальний дизайн. Праве плече піднімається назад через відповідні рівні тестування. Кожна фаза ліворуч у парі з тим рівнем тестування, який її перевірятиме.

V-модель ставить у пару кожен рівень специфікації з тим рівнем тестування, що його перевірятиме, тож кожен тест проєктують тоді, коли пишуть його рівень, а не після збірки. У цьому її справжній виграш: вимогу, до якої ніхто не може написати приймальний тест, знаходять на першому місяці. Чого вона не змінює — коли щось запускається: кожен тест правого плеча все одно чекає на код. Нижні рівні верифікують, звіряючи збірку зі специфікацією; валідує лише приймальне тестування — питає, чи правильною була сама специфікація, — і йде воно останнім.
Ліве плече — будуємоПраве плече — перевіряємо
ВимогиПриймальне тестування
Високорівневий дизайнСистемне тестування
Детальний дизайнІнтеграційне тестування
РеалізаціяМодульне тестування

Практичний виграш у тому, що приймальні тести пишуться на фазі вимог, а не після побудови. Це рано змушує поставити корисне питання: як ми доведемо, що цю вимогу виконано? Вимога, до якої ніхто не може написати тест, — це вимога, якої ніхто не зрозумів, і V-модель виявляє такі на першому місяці, а не на девʼятому.

Ця форма має два незалежні джерела. У Німеччині V-Modell розробляла з 1986 року компанія IABG для Федерального міністерства оборони; 1992 року його перейняли цивільні федеральні відомства, а згодом переглянули як V-Modell 97 і далі як V-Modell XT, який німецькі федеральні ІТ-проєкти використовують досі. У США Кевін Форсберг і Гарольд Муз представили «Vee» для системної інженерії на першому симпозіумі NCOSE 1991 року.

Дві частини правого плеча відповідають на різні питання, і Беррі Бем дав їм стандартне формулювання 1981 року. Верифікація питає: «чи правильно ми будуємо продукт?» — чи відповідає збірка специфікації? Валідація питає: «чи той продукт ми будуємо?» — чи специфікація була тим, що потрібно користувачеві? Інтеграційне й системне тестування верифікують. Валідує лише приймальне.

Коли предиктивний план дешевший: шість питань

Приберіть культурну війну — і вибір між Waterfall і Agile зводиться до одного числа: скільки вам коштує змінити рішення пізно?

Це число важко назвати напряму, тож тут воно розкладене на шість питань. Кожен рядок каже, яка відповідь веде до предиктивного плану, а яка — до ітеративного. Більшість проєктів відповідає частково так, частково інакше, і саме це поєднання — а не більшість — підказує, які частини планувати наперед, а які відкривати через побудову.

ПитанняВеде до предиктивного плануВеде до ітеративного
1. Скільки коштує зміна після релізу?Відкликання, повторна сертифікація, виїзд на обʼєкт, доповнення до контрактуПовторний деплой
2. Чи можна знати вимоги до побудови?Опублікований інтерфейс, текст регуляції, міграція до цілі, яку ви розумієтеКористувачі, які ще не бачили цієї речі
3. Чи будувала ця команда таке раніше?Кілька разів, на тій самій технологіїНовий стек, новий домен або обидва
4. Чи мусить хтось ззовні спершу затвердити специфікацію?Тендер із фіксованою ціною, safety case, замовник, що підписує на гейтахНікому поза командою не треба затверджувати план
5. Чи корисна частина сама по собі?Працює лише ціле: перемикання даних, супутник, містКожен зріз хтось може використовувати
6. Хто може відповідати на питання під час побудови?Замовник доступний на гейтах, а не між нимиЛюдина, яка може вирішувати, щотижня сидить із командою

Чому ці відповіді важливі, зводиться до того, коли знімається ризик. Ризик знято, коли щось запрацювало й довело припущення правильним чи хибним, — а не коли підписано документ, що це припущення описує. Один прохід знімає мало аж до інтеграції; ітеративний план знімає частину щоразу, коли щось працює перед кимось.

Ризик знімається тоді, коли щось запрацювало, а не коли підписано документ. Один прохід трохи знімає його на папері, а тоді зустрічає всі припущення одночасно, щойно починається інтеграція, — тому крива спершу росте, а вже потім падає, і тому чверть ризику лишається відкритою на момент поставки. Щомісячні ітерації знімають частину щомісяця, бо щомісяця щось працює перед кимось. Заштрихована площа — це ризик, який один прохід несе, не знаючи про нього. Форма ілюстративна, за профілями ризику, які Вокер Ройс намалював у книжці Software Project Management (1998), а не вимірювання.

  • Зміни дешеві → ітеруйте

    Вебсервіс з автотестами й безперервним деплоєм. Хибне рішення коштує передеплою. Відкладання рішень майже нічого не коштує, тож збирайте докази замість здогадок.

  • Зміни дорогі → специфікуйте

    Прошивка на залізі, яке вже в руках клієнтів. Сертифікований медичний пристрій. Інтеграція, де інтерфейс іншої сторони заморожено контрактом. Тут ретельне обдумування наперед — дешевший шлях.

Зверніть увагу: це властивість вашої ситуації, а не ваших переконань про розробку. Та сама команда може мати рацію, ітеруючи на вебфронтенді, і мати рацію, ретельно специфікуючи прошивку, — в одному й тому ж кварталі.

Waterfall

  • Обсяг фіксований; час і бюджет оцінюються під нього
  • Одна велика точка зворотного звʼязку — на прийманні
  • Документація є контрактним результатом
  • Надійний аудиторський слід; кожен гейт підписано

Agile

  • Час і команда фіксовані; обсяг гнучкий
  • Багато малих точок зворотного звʼязку, щоітерації
  • Документація пишеться там, де вона когось розблоковує
  • Аудиторський слід треба вибудовувати свідомо

Гібриди, якими живуть реальні проєкти

Дуже мало організацій використовують якусь із моделей у чистому вигляді. Типова реальна форма — предиктивна оболонка навколо ітеративного виконання: фіксований контрактний обсяг і план віх ззовні, а всередині команда працює спринтами.

Такий гібрид чесний, доки виконується одна умова: зовнішній план справді перезатверджують, коли внутрішня робота щось виявляє. Перезатвердити — означає погодити нову версію плану й відтоді міряти відносно неї, а не звітувати за старою, наче нічого не сталося.

ФормаЩо фіксованеЩо ітеруєЧесна, коли
Предиктивна оболонка, спринти всерединіКонтрактний обсяг і дати віхПоставка, спринт за спринтомЗовнішній план перезатверджують, коли спринти щось знаходять
Інкрементні збірки — MIL-STD-498, 1994Загальні вимоги й архітектураДизайн і код, збірка за збіркою; кожну збірку постачаютьПізніша збірка може змінити те, що припускала попередня
Stage-Gate — Роберт Купер, 1990Гейти та їхні критеріїУсе між двома гейтамиГейт може зупинити проєкт, а не лише схвалити його
Water-Scrum-Fall — Forrester, 2011Вимоги наперед, реліз наприкінціЛише розробкаРідко: зберігає обидва кінці Waterfall, а середину називає Agile

Stage-Gate заслуговує окремого речення, бо його часто плутають із Waterfall, а це інша річ. Його гейти — інвестиційні рішення: продовжити, змінити курс чи зупинити, — і ухвалюють їх люди, які контролюють гроші; портфель, у якому жоден проєкт ніколи не зупиняють на гейті, виконує церемонію, а не метод. Та сама ідея з боку планування — деталізувати найближче й лишати далеке грубим — називається , і про неї йдеться на сторінці про .

Пʼять задокументованих випадків — і контроль, який кожен перевірив

Історія Waterfall задокументована краще, ніж у більшості методів, бо чимало з неї написали уряди й комісії з розслідувань. Перші два випадки — про саму модель. Решта три — про те, що гейт може впіймати, а що ні.

ВипадокЩо сталосяКонтроль, який це перевірило
DOD-STD-2167, 1985–1994Оборонний стандарт США для ПЗ, виданий 1985 року, вимагав однопрохідної послідовності, керованої документами. 1987 року робоча група Defense Science Board під головуванням Фреда Брукса доповіла, що проєкт нової редакції «і далі закріплює саме той підхід "спершу специфікуй, потім будуй", керований документами, що лежить в основі стількох проблем ПЗ Міноборони». 2167A (лютий 1988) намагався бути нейтральним щодо методу; MIL-STD-498 (грудень 1994) замінив його інкрементними збірками. Головний автор стандарту згодом казав, що, коли писав його, не чув про ітеративну розробку й порадив би саме її.Припис. Один життєвий цикл для кожного проєкту, хоч би скільки коштувала пізня зміна, — хоча саме за цим питанням модель і треба обирати.
ПЗ Space Shuttle, 1977–1980Federal Systems Division компанії IBM збудувала основне бортове ПЗ шатла — хрестоматійний приклад суворої специфікації — за 17 ітерацій упродовж 31 місяця, приблизно по вісім тижнів кожна, бо вимоги до шатла постійно змінювалися. Команда описувала це як застосування «ідеального циклу до малих елементів загального пакета ПЗ на ітеративній основі» (Madden і Rone, Communications of the ACM, 1984).Суворість малими інкрементами. Гейти й документи зберегли; змінилося те, скільки охоплював кожен.
Міжнародний аеропорт Денвера, 1995Проєктування автоматизованої системи багажу на весь аеропорт почалося, коли будівництво вже йшло повним ходом. Фіксовані обсяг, графік і бюджет «унеможливили масштабне моделювання чи фізичне тестування повного дизайну» (кейс SEBoK). Аеропорт відкрився в лютому 1995 року, на шістнадцять місяців пізніше, а затримка коштувала близько 1,1 мільйона доларів на день; автоматизовану систему покинули в серпні 2005-го.Фіксований план без місця для верифікації. Обсяг прийшов пізно, план не перезатвердили, і поступитися довелося тестуванню.
Ariane 5, політ 501, 19964 червня 1996 року ракета розвалилася приблизно через 40 секунд після старту. ПЗ її інерціальної системи відліку перейшло з Ariane 4. Перетворення значення горизонтальної швидкості — на траєкторії Ariane 5 значно більшого — у 16-бітне ціле переповнилося й вимкнуло і сам блок, і його ідентичний резервний. Комісія встановила, що траєкторія Ariane 5 не входила до специфікації блока і що повну систему з нею не тестували (звіт Лайонса, липень 1996).Праве плече V. Вимогу успадкували, не перевіривши заново для нового застосування, а єдиний рівень тестування, що виявив би це, пропустили.
Mars Climate Orbiter, 1999Наземне ПЗ, передане навігаційній команді, видавало імпульс двигунів у фунт-сила-секундах, а специфікація інтерфейсу вимагала ньютон-секунд. Місяцями накопичувалися дрібні помилки траєкторії, і 23 вересня 1999 року апарат підійшов до Марса значно нижче, ніж планували, і був утрачений. Комісія назвала першопричиною те, що у файлі наземного ПЗ під назвою «Small Forces» не використали метричні одиниці (звіт фази I, листопад 1999).Підписаний інтерфейс — ще не перевірений. Специфікація існувала й казала правильне; ніхто не перевірив інтерфейс наскрізно через межу між двома організаціями.

Де він вироджується в театр

Спершу — чесна межа. Waterfall чесний щодо обсягу й дати і мовчить щодо знання. Він може бути лише настільки правильним, наскільки правильними були вимоги на першому місяці, і не має власного механізму, щоб дізнатися, що вони хибні, раніше за фазу верифікації. Там, де знання справді існує до побудови, — заморожений інтерфейс, відома ціль міграції, команда, що робить пʼяту версію того самого, — ця мовчанка нічого не коштує, а дисципліна моделі — чистий виграш.

Прихильники й критики згодні між собою більше, ніж визнають. Девід Парнас і Пол Клементс, які вірили в ідеал раціонального процесу «спершу специфікація», 1986 року опублікували статтю «A Rational Design Process: How and Why to Fake It»: насправді так працювати не може ніхто, доводили вони, але документи варто писати так, наче працювали. Фред Брукс висловив другу половину різкіше у своїй доповіді на International Conference on Software Engineering 1995 року: «Модель waterfall хибна!»

  • Вимоги затверджені тими, хто не користуватиметься системою, тож приймання стає першим справжнім оглядом.
  • Фаза верифікації, стиснена під дату, — це перетворює тестування на формальність.
  • Запити на зміни трактуються як провал, а не як інформація, тож план захищають довше, ніж він корисний.
  • Рада з контролю змін збирається щомісяця, тож кожна зміна — слушна чи ні — чекає місяць.
  • Матрицю простежуваності заповнюють після збірки — щоб пройти аудит, а не щоб знайти прогалину.
  • Огляд дизайну, на якому дивляться слайди, а не дизайн, — гейт стає зустріччю, а не перевіркою.
  • Приймальні тести пишуть після коду — V лишається на папері й утрачає свій єдиний виграш.
  • Спринти всередині плану, який ніколи не перезатверджують, — ітеративність лише на вигляд.
  • Прогрес у відсотках виконання — його неможливо перевірити, доки система не запрацює.
  • «Waterfall, бо так вимагає регулятор», хоча регулятор вимагає доказів, а не послідовності.

Коли це застосовувати

Застосовуйте, коли

  • Вимоги справді стабільні й добре зрозумілі до початку робіт.
  • Пізня зміна справді дорога — відвантажене залізо, фізичне розгортання, заморожені інтерфейси.
  • Команда вже будувала таку систему раніше, на тій самій технології.
  • Контракт фіксує обсяг і ціну, а замовнику потрібна дата для власного планування.

Уникайте, коли

  • Продукт новий, і користувачі ще не сказали вам, що їм потрібно.
  • Технологія незнайома, тож оцінки проєктування — це здогади у вигляді плану.
  • Ви можете релізити дешево й часто — тоді пізній зворотний звʼязок є витратою, яку ви обрали, а не успадкували.
  • План не перезатверджуватимуть при розходженні з реальністю — тоді гейти стають театром.

Джерела й метод

На чому стоїть ця стаття

  • 16 джерел
  • 3 задокументовані збої
  • Перевірено 13 жовтня 2026 р.

Практики й походження термінів

що написав Ройс, фази, V-модель і її словник

Дослідження з Claude. Пошук і звірку першоджерел зроблено з Claude (Anthropic). Відбір, текст і перевірку фактів — редакція Anatomy of IT Product.

Було корисно?

Поділіться з тим, хто працює над тією ж задачею.