nmk

Лекція №2 (4 години). Традиційні методології управління: Waterfall, V-модель, PMI

План лекції

Еволюція підходів до управління IT-проєктами. Що таке “Традиційні методології”?
Каскадна модель (Waterfall): історія, структура фаз, переваги та недоліки.
V-модель (Validation & Verification): тестування як невіддільна частина розробки.
Ітеративні та інкрементальні моделі: проміжний крок між Waterfall та Agile.
Сфери застосування традиційних (Predictive) методологій у сучасному IT.
Вплив стандартів PMI на традиційне управління (PMBOK як класика Predictive-моделей).
Контракти Fixed-Price та їх зв’язок з каскадними моделями.

Перелік умовних скорочень

Waterfall — каскадна модель розробки;
V-Model — модель розробки через тестування (Validation and Verification);
PMI (Project Management Institute) — Інститут управління проєктами;
WBS (Work Breakdown Structure) — ієрархічна структура робіт;
SRS (Software Requirements Specification) — специфікація вимог до програмного забезпечення;
Fixed-Price — тип контракту з фіксованою вартістю;
UAT (User Acceptance Testing) — приймальне тестування користувачем;
Predictive Approach — прогнозований (плановий) підхід до управління.

Вступ

Сьогодні у світі IT домінує Agile, і може здатися, що традиційні підходи (такі як Waterfall) залишилися в минулому. Однак це ілюзія. Вважається, що близько 20-30% всіх світових IT-проєктів досі використовують суто каскадні або гібридні методології. Якщо ваш проєкт створює програмне забезпечення для кардіостимуляторів, системи управління авіатрафіком або банківського ядра, “швидкі помилки” (fail-fast), притаманні Agile, є неприйнятними.

У цій лекції ми розберемо класичні “важковагові” (Predictive) методології. Ви зрозумієте, чому їх називають “спрямованими на план” (Plan-Driven) та в яких випадках їх використання не лише виправдане, а й є єдино можливим для успішного релізу продукту.

1. Еволюція підходів до управління IT-проєктами

Перші IT-проєкти з’явилися в 1950–1960-х роках (створення ПЗ для ракет, корпоративних мейнфреймів IBM). Програмісти тих часів застосували до програмування ті ж методи управління, які працювали на заводах та в будівництві — прогнозовані (Predictive) підходи.

Основна філософія традиційних підходів:

Зрозуміти проблему на 100%.
Скласти ідеальний покроковий план її вирішення (з точністю до годин та центів).
Жорстко дотримуватись плану будь-якою ціною.
Тільки після закінчення всього процесу показати результат замовнику.

Ці методи чудово працювали для будівництва мосту (ви не можете передумати і додати ще одну смугу, коли міст наполовину готовий), але зазнавали труднощів в індустрії програмного забезпечення через високий ступінь мінливості вимог на ринку.

2. Каскадна модель (Waterfall)

Waterfall (Водоспадна або каскадна модель) — це методологія розробки, першим формальним описом якої вважається стаття Вінстона Ройса 1970 року (хоча сам він вказував на ризикованість цього підходу). Суть полягає у суворому послідовному виконанні етапів. Наступна фаза починається тільки тоді, коли повністю (!), на 100% завершена попередня.

Фази класичного Waterfall:

Збір та аналіз вимог (Requirements): Найбільша фаза. Бізнес-аналітики (BA) опитують клієнта, аналізують конкурентів і формують толмуди документації (SRS — Software Requirements Specification), яка може налічувати сотні сторінок. Наприкінці фази клієнт підписує документ кров’ю (заморожує вимоги).
Проєктування (Design): Системні архітектори беруть затверджену SRS і проєктують бази даних, API, вибирають стеки технологій (ER-діаграми, UML-моделі).
Реалізація (Implementation / Coding): Програмісти пишуть код. Найцікавіше: на цьому етапі вимоги вже не змінюються. Завдання дева — чітко закодити те, що написано в технічному завданні.
Тестування (Testing / Verification): Відділ QA отримує повністю готовий код усього проєкту і починає його тестувати. Тільки тут виявляються критичні архітектурні дефекти.
Розгортання (Deployment): Передача готового продукту клієнту. Встановлення на сервери, інтеграція з його інфраструктурою.
Підтримка (Maintenance): Виправлення тих багів, які не помітили QA, та випуск патчів безпеки.

Що відбувається, якщо клієнт хоче змінити вимоги?

У Waterfall змінити вимоги (наприклад, на 3-му етапі додати “вхід через Apple ID”) — це катастрофа. Процес вимагає формального запиту на зміну (Change Request). PM перераховує бюджет, нові строки, і якщо клієнт погоджується заплатити (наприклад, +20 000$), зміни повертаються на етап №1 (збір вимог), оновлюється SRS, потім оновлюється архітектурний дизайн (етап 2), і лише потім програмісти починають писати новий код (етап 3).

Переваги Waterfall:

Простота та прозорість: Інвестори та топ-менеджмент люблять водоспад. Їм одразу на старті дають діаграму Ганта з чіткою датою (реліз: 12 грудня) та точним бюджетом (1,5 млн доларів).
Еталонна документація: Якщо завтра вся команда ключових розробників звільниться, проєкт легко підхопить нова команда, просто прочитавши ідеальну 300-сторінкову SRS.
Ідеально для стабільних доменів: Якщо ви пишете ПЗ для медичного обладнання або податкову систему, вимоги не зміняться за пів року — їх диктує законодавство.

Недоліки Waterfall:

Ілюзія контролю: Люди погано оцінюють складні завдання на стадії ідеї. План майже завжди дає збій на етапі реалізації (кодери розуміють, що архітектурний дизайн був помилковим).
Запізніле виявлення помилок (Big Bang Integration): Оскільки тестування відбувається лише на етапі 4 (після написання всього коду проєкту), помилки, допущені на стадії “Вимоги” (етап 1), стають астрономічно дорогими для виправлення.
Клієнт бачить продукт в кінці: Замовник отримує першу версію програми через рік роботи. Величезний ризик того, що проєкт буде технічно ідеальним, але морально застарілим для ринку. Замовник скаже: “Це саме те, що я просив рік тому, але зараз мені це вже не потрібно”.

3. V-модель (Validation & Verification Model)

Розуміючи фатальну помилку Waterfall (запізніле тестування), інженери розробили удосконалену версію — V-модель.

Її філософія проста: Тестування повинно плануватися паралельно з розробкою кожної фази, а не в самому кінці проєкту. Модель схематично виглядає як літера “V”, де ліва гілка — це деталізація (розробка), а права — інтеграція (тестування). Між ними — фаза “Написання коду”.

Структура V-Моделі:

Ліва гілка (Verification - Проєктування зверху вниз):

Аналіз бізнес-вимог ➡️ (одночасно створюється план Приймального тестування (UAT) для клієнта).
Системне проєктування ➡️ (одночасно пишуться тест-кейси для Системного тестування).
Архітектурне проєктування ➡️ (одночасно пишуться тест-кейси для Інтеграційного тестування).
Дизайн модулів ➡️ (одночасно розробляються Unit-тести (Модульне тестування)).

(Точка перегину “Кодування”)

Права гілка (Validation - Тестування знизу вгору): 5. Розробник написав модуль -> одразу запускається Unit-тестування. 6. Модулі з’єднали -> запускається Інтеграційне тестування. 7. Система зібрана повністю -> запускається Системне тестування (QA команда перевіряє всю архітектуру). 8. UAT (User Acceptance Testing) -> Клієнт сідає за комп’ютер і за чек-листом перевіряє, чи виконує ПЗ його ключові бізнес-вимоги.

Переваги V-моделі над Waterfall:

Більш рання підготовка до тестування. Тестувальники не сидять без діла півроку: вони створюють тестові сценарії ще на стадії збору вимог.
Вищий рівень гарантії якості. Підходить для Safety-critical систем (ПЗ для авіації, медичних апаратів).

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

4. Ітеративні та інкрементальні моделі

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

Ітерування (Iterative) — перероблювання того самого:

Ми створюємо всього потроху.

Ітерація 1: Робимо чорно-білий ескіз сайту з голим текстом (прототип).
Ітерація 2: Додаємо кольори, стилі CSS.
Ітерація 3: Натягуємо на CMS-рушій і додаємо динаміку. Кожна ітерація завершується переглядом і уточненням вимог. Ідеально підходить, коли замовник не знає точно, якого дизайну чи UX (користувацького досвіду) він хоче.

Інкрементування (Incremental) — нарощування по шматках:

Проєкт відразу ділять на 100% готові блоки. Ми не робимо чорно-білий ескіз усього сайту.

Інкремент 1: Повністю готовий, з дизайном і бекендом модуль “Реєстрація/Авторизація”.
Інкремент 2: Повністю готовий модуль “Кошик товарів”. Так замовник може почати користуватися системою повільно, по частинах, не чекаючи завершення всього проєкту.

Спіральна модель (Боема): поєднує в собі ітеративність і глибокий акцент на аналізі ризиків. На кожному витку спіралі (аналіз, прототип, збірка, оцінка) PM зобов’язаний оцінити технічні та фінансові ризики. Якщо ризики занадто високі, проєкт можна “вбити” на ранній стадії з мінімальними збитками.

5. Сфери застосування традиційних (Predictive) методологій

Хоча Agile сьогодні захопив розробку веб- та мобільних застосунків, є цілі індустрії в IT, де використання Waterfall / V-моделі є галузевим стандартом:

Державні та оборонні замовлення. Держава завжди купує ПЗ через тендери. Тендер вимагає точної ціни до цента і точної специфікації (надання сотень сторінок ТЗ). Гнучкий підхід тут неможливий законодавчо.
Вбудовані системи (Embedded) і Hardware-IT проєкти. Якщо ваш проєкт — розробка прошивки для розумного холодильника, ви не можете випустити “бета-версію” холодильника на ринок, зібрати фідбек від користувачів і оновити корпус патчем (fail-fast тут коштуватиме мільйони на відкликання продукції). Апаратна архітектура вимагає жорсткого Waterfall.
Safety-Critical Systems. ПЗ для автомобілів (наприклад, система автопілота чи антиблокувальна система гальм). Тут використовують V-модель, оскільки кожен рядок коду має бути верифікований вимогами безпеки ISO.
Міграція величезних legacy-систем. Наприклад, перенесення всієї бази даних національного банку з локальних серверів (On-Premise) на AWS. Вимоги (архітектура таблиць, регламенти бекапів) тут відомі і фіксовані на 100%. Тут немає творчого пошуку “а давайте додамо кнопочку”. Процес є суто інженерним і прекрасно лягає на діаграму Ганта у Waterfall.

6. Вплив стандартів PMI на традиційне управління

Project Management Institute (PMI) протягом багатьох років був (і багато в чому залишається) головним амбасадором Plan-driven підходів (до появи 7-ї версії PMBOK, яка стала більш Agile-friendly).

У традиційному PMBOK (6-та версія і старіше), управління проєктом — це наука, побудована навколо розкладу (Schedule) та бюджету (Cost).

Роль PM у традиційних проєктах (за класикою PMI):

Створення WBS (Work Breakdown Structure). PM разом з техлідами розбиває великий проєкт (наприклад “створити інтернет-банкінг”) на сотні дрібних, оцінюваних задач (“зробити таблицю Users в БД”).
Оцінка.” Кожна задача з WBS оцінюється в годинах. Години множаться на зарплату фахівців (Rate). Так народжується бюджет долара-в-долар.
Управління базовими лініями (Baselines). PMBOK встановлює три “залізних” Базових Лінії: Scope Baseline (базовий обсяг робіт), Schedule Baseline (розклад) і Cost Baseline (бюджет). Будь-яке відхилення від базової лінії вважається проблемою і вимагає запуску процесу “Управління змінами” (Change Request Process).
Контроль за допомогою EVM (Earned Value Management). PMBOK пропонує математичну модель (EVM) для контролю того, чи не перевитрачаємо ми бюджет (Cost Variance) та чи встигаємо ми за строками (Schedule Variance). Це детально розбиратимемо у практичних роботах.

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

7. Контракти Fixed-Price та їх зв’язок з каскадними моделями

Традиційні методології є ідеальним (а часто єдиним) середовищем для укладення Fixed-Price контрактів (з фіксованою вартістю).

Схема Fixed-price: Клієнт приходить з ідеєю. Ви як IT-компанія збираєте вимоги, витрачаєте місяць на написання специфікації (SRS) і кажете: “Ми зробимо це за $100,000 і віддамо вам продукт 1 жовтня”.

Ризики підрядника: Якщо ваші кодери працюватимуть повільно, або якщо специфікація була складена погано і доведеться переписувати архітектуру — ви витратите більше бюджету (наприклад, $120,000), тобто компанія зазнає збитків (-$20,000). Замовник не доплатить ні копійки, адже контракт підписано.
Ризики клієнта: Якщо клієнт через місяць вирішить змінити вимоги (скажімо, зробити дизайн не сайту, а мобільного застосунку), договір доведеться розривати та перепідписувати з новими оцінками і новими штрафами.

Чому це працює тільки у Waterfall? Оскільки в контракті Fixed-price IT-компанія (vendor) несе всі фінансові ризики, їй ЖИТТЄВО НЕОБХІДНО “забетонувати” вимоги. Їй потрібен водоспадний підхід, щоб клієнт не міг додавати безкоштовні побажання “по ходу розробки” (Scope Creep).

Висновки

Традиційні (Predictive) методології базуються на філософії “спочатку ідеальний план, потім виконання”.
Waterfall — класичний послідовний підхід. Його головна вада — складна процедура внесення змін і занадто пізнє проведення тестування (Big Bang), що призводить до високої вартості виправлення помилок.
V-модель вдосконалила Waterfall, паралелізувавши етапи проєктування з підготовкою до відповідних етапів тестування. Вона ідеальна для проєктів з підвищеними вимогами до якості та безпеки.
Ітеративні (поступове уточнення) та інкрементальні (нарощування фіч по шматках) підходи стали мостом між строгими каскадними схемами та спритним (Agile) світом IT.
Застосування PMBOK 6-ї версії та діаграм Ганта, Fixed-price контракти і Waterfall є необхідними там, де ціна помилки дуже висока (Safety-critical), де ресурси вкрай обмежені, або де цього вимагають державні закупівлі.
В IT не існує “поганих” або “хороших” методологій. Вибір Waterfall замість популярного Agile для проєкту з розробки прошивки кардіостимулятора — це не “відсталість”, а професійна необхідність.

Джерела

Royce W.W. “Managing the Development of Large Software Systems” (1970).
Інститут управління проєктами (PMI). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Sixth Edition (для розуміння процесної архітектури).
McConnell, Steve. Software Estimation: Demystifying the Black Art. (Детально про проблеми планування у Waterfall).
Boehm, B.W. “A spiral model of software development and enhancement” (Про спіральну модель та ризики).

Запитання для самоперевірки

Поясніть принципову відмінність між ітеративним (Iterative) та інкрементальним (Incremental) підходами на прикладі розробки інтернет-магазину.
В якому випадку виявлена “архітектурна” помилка коштуватиме компанії найдорожче: при використанні класичного Waterfall чи V-моделі? Аргументуйте.
Чому IT-проєкти, що створюються для державного сектору (тендери), майже завжди використовують традиційні планувальні (Plan-driven) моделі?
Що таке Scope Creep (розповзання меж проєкту) і який механізм є захистом від нього у каскадній моделі розробки?
Чому контракти з фіксованою ціною (Fixed-price) спонукають розробників IT-компаній вимагати від клієнта 100% заморожування вимог (технічного завдання) на початку розробки?
На якому етапі V-моделі створюються тести для рівнів Unit (модульного) та System (системного) тестування відповідно?