Digital Polygraph створено для того, щоб замінити інтуїтивне планування ПЗ детерміністичним інженерним розрахунком. Замість відчуття «впораємось за рік», платформа розраховує, чи відповідає обрана ціль поставки обраному обсягу, складності, рівню повторного використання та розподілу інженерних ресурсів.
Кейси — метод у дії
Кейси в цьому розділі — це не маркетингові історії і не ілюстрації функцій продукту. Це приклади застосування детерміністичного інженерного методу. Кожен кейс побудований за однією процедурою: реальний проєкт перекладається в параметри моделі, калькулятор виконує розрахунок, а результат стає основою для інженерного планування.
Кожен кейс відтворюваний. Якщо відкрити калькулятор і обрати ті самі функції, ті самі характеристики складності та той самий маршрут — результат буде ідентичним. Це не маркетингове твердження — це відтворюваний приклад розрахунку за методом.
Шість кейсів охоплюють шість типових ситуацій інженерного планування, з якими стикаються проєкти з розробки ПЗ. Усі шість побудовані на єдиній предметній галузі — міській транспортній інфраструктурі. Це зроблено навмисно: єдина галузь дозволяє порівнювати кейси між собою і бачити, як зміни масштабу, складності або конфігурації стадій впливають на результат розрахунку.
Калькулятор не знає, що таке трамвай або фунікулер. Він знає функції, складність, інновацію, повторне використання та стадії життєвого циклу. Транспортна галузь — лише обгортка. Метод є універсальним.
Відкритий шлях поставки
Система контролю доступу до транзитної інфраструктури
Шлях поставки відкритий, але лише за умови необхідного розподілу інженерних ресурсів по стадіях. Калькулятор показує, як розрахована тривалість змінюється при зміні розподілу ресурсів по стадіях.
Закритий шлях
Єдина метрополітенська система управління транзитом
Трудомісткість така, що жоден розподіл інженерних ресурсів не вкладається у цільове вікно поставки. Це не прогноз — це детерміністичний розрахунок на основі фіксованих інженерних параметрів.
Спочатку прототип
Прототип системи управління метро в реальному часі
Технічна здійсненність не доведена. Повне зобов'язання до верифікації прототипу створює високий інженерний ризик. Калькулятор розраховує вхідну трудомісткість до контрольної точки.
Спільна поставка
Система контролю доступу для автобусів і тролейбусів — швидкий трек
Замовник надає Технічне завдання (ТЗ) і бере на себе Впровадження (ВП), а постачальник реалізує Техно-робочий проєкт (ТРП). Scrum-команда з 8 осіб поставляє Release Candidate за 1.22 р.
Готова специфікація
Система доступу залізничних пасажирів — готова специфікація
Технічне завдання надає замовник. Пропуск ТЗ та ЕП скорочує розрахований маршрут на 350 лд і майже на рік. Перший артефакт — через 0.77 р.
Матриця маршрутів поставки
Система контролю доступу до фунікулера
Один проєкт, чотири маршрути, одна команда. Калькулятор порівнює всі конфігурації і перетворює вибір маршруту поставки на вимірювані параметри.
Зведена таблиця
| # | Проєкт | Вибір | Функції | Трудомісткість | Тривалість | Модель поставки | Вердикт |
|---|---|---|---|---|---|---|---|
| 1 | Система контролю доступу до транзитної інфраструктури | ТЗ→ЕП→ТП→РП→ВП | 5 | 3 541 лд | 3.36 р. | Повний підряд | Відкритий шлях |
| 2 | Єдина метрополітенська система управління транзитом | ТЗ→ЕП→ТП→РП→ВП | 11 | 10 639 лд | 5.70 р. | Повний підряд | Закритий шлях |
| 3 | Прототип системи управління метро в реальному часі | ТЗ→ЕП (ціль H1) | 5 | 7 930 лд | 1.43 р. до H1 | Повний підряд | Спочатку прототип |
| 4 | Система контролю доступу для автобусів і тролейбусів — швидкий трек | Тільки ТРП | 6 | 2 287 лд | 1.22 р. | Обсяг вендорської розробки | Спільна поставка |
| 5 | Система доступу залізничних пасажирів — готова специфікація | ТЗ(0)→ТП→РП→ВП | 6 | 3 059 лд | 2.66 р. | Партнерство з впровадження | Швидкий вхід |
| 6 | Система контролю доступу до фунікулера | Порівняння В1–В4 | 4 | 3 084–3 160 лд | 3.46–4.23 р. | Повний підряд | Матриця маршрутів |
Глосарій
Метод базується на взаємно однозначній відповідності між стадіями інженерного життєвого циклу (модель водоспаду) та стадіями зрілості продукту (сучасна модель розробки). Ця відповідність є ядром детерміністичного інженерного методу.
| Скор. | Інженерна стадія | Продуктова стадія | Зрілість продукту | Інженерне значення |
|---|---|---|---|---|
| ТЗ | Технічне завдання | Discovery / Базис вимог | Базис вимог | Обсяг формально визначено та готово до інженерного планування. |
| ЕП | Ескізний проєкт | Прототип (концептуальний) | Концептуальна зрілість | Перший відчутний артефакт. Концепція верифікована. Перша контрольна точка. |
| ТП | Технічний проєкт | MVP (технічна форма) | Технічна зрілість MVP | Базова архітектура доведена. Інженерна основа готова. |
| РП | Робочий проєкт | Release Candidate | Повна інженерна зрілість | Функціонально завершений. Готовий до приймального тестування. |
| ТРП | Техно-робочий проєкт | Release Candidate (без MVP) | Суміщена зрілість реалізації | ТП + РП об'єднані в одну стадію. Швидший шлях, менше артефактів. |
| ВП | Впровадження | Production Release | Операційна зрілість | Система розгорнута та функціонує. |
| Підсумок | Інтегральна стадія | Всі обрані стадії разом | Зрілість повного циклу | Загальна трудомісткість і тривалість для обраної конфігурації (Вибір). |
| лд | людино-дні | — | — | Одиниця трудомісткості. 1 лд = 1 розробник працює 1 день. |
| FTE | Повний робочий еквівалент | — | — | Кількість розробників на повну ставку, призначених на стадію. |
| Вибір | Конфігурація стадій | — | — | Обрана комбінація інженерних стадій для конкретного проєкту. |
Відповідність між інженерними стадіями та стадіями продукту встановлюється через концепцію рівня зрілості продукту — універсального параметра, що є ядром детерміністичного інженерного методу. Будь-який відомий алгоритм оцінки за водоспадом (COCOMO, на основі ГОСТ, ISO/IEC 15504) може бути застосований до сучасних продуктових або Agile-моделей через цю відповідність.