Digital Polygraph was created to replace intuitive software planning with deterministic engineering calculation. Instead of relying on the feeling that “we can deliver it within a year,” the platform calculates whether the selected delivery target matches the selected scope, complexity, reuse level, and allocation of engineering resources.
Cases — the Method in Action
The cases in this section are not marketing stories and not illustrations of product features. They are examples of how the deterministic engineering method is applied. Each case follows the same procedure: a real project is translated into model parameters, the calculator performs the calculation, and the result becomes the basis for engineering planning.
Each case is reproducible. If you open the calculator and select the same functions, the same complexity characteristics, and the same delivery route, the result will be identical. This is not a marketing claim — it is a reproducible example of calculation by method.
The six cases cover six typical engineering-planning situations encountered in software development projects. All six are built within one domain — urban transport infrastructure. This is intentional: a common domain makes it possible to compare the cases with each other and see how changes in scale, complexity, or lifecycle-stage configuration affect the calculated result.
The calculator does not know what a tram or a funicular is. It knows functions, complexity, innovation, reuse, and lifecycle stages. The transport domain is only a wrapper. The method is universal.
Open Delivery Path
Surface Electric Transport Access Control System
The delivery path is open, but only if engineering resources are allocated properly across the stages. The calculator shows how the calculated duration changes when resource distribution by stage changes.
Closed Path
Unified Metropolitan Transit Management System
The labor intensity is so high that no distribution of engineering resources fits the target delivery window. This is not a forecast — it is a deterministic calculation based on fixed engineering parameters.
Prototype First
Real-Time Metro Control System Prototype
Technical feasibility has not yet been proven. A full commitment before prototype verification creates a high engineering risk. The calculator estimates the entry labor intensity up to the first checkpoint.
Shared Delivery
Bus and Trolleybus Access Control System — Fast Track
The customer provides the Technical Assignment (TA) and takes responsibility for Implementation (IM), while the vendor delivers the Technical Working Project (TWP). An 8-person Scrum team delivers the Release Candidate in 1.22 years.
Ready Specification
Rail Passenger Access System — Ready Specification
The Technical Assignment is provided by the customer. Skipping TA and PP reduces the calculated route by 350 person-days and almost one year. The first artifact appears in 0.77 years.
Delivery Route Matrix
Funicular Access Control System
One project, four delivery routes, one team. The calculator compares all configurations and turns the route-selection decision into measurable parameters.
Summary Table
| # | Project | Choice | Functions | Labor Intensity | Duration | Delivery Model | Verdict |
|---|---|---|---|---|---|---|---|
| 1 | Surface Electric Transport Access Control System | TA→PP→TP→WP→IM | 5 | 3,541 p-d | 3.36 yrs | Full contractor delivery | Open Path |
| 2 | Unified Metropolitan Transit Management System | TA→PP→TP→WP→IM | 11 | 10,639 p-d | 5.70 yrs | Full contractor delivery | Closed Path |
| 3 | Real-Time Metro Control System Prototype | TA→PP (target H1) | 5 | 1,678 p-d to H1 / 7,930 p-d full | 1.43 yrs to H1 | Full contractor delivery | Prototype First |
| 4 | Bus and Trolleybus Access Control System — Fast Track | TWP only | 6 | 2,287 p-d | 1.22 yrs | Vendor development scope | Shared Delivery |
| 5 | Rail Passenger Access System — Ready Specification | TA(0)→TP→WP→IM | 6 | 3,059 p-d | 2.66 yrs | Implementation partnership | Fast Entry |
| 6 | Funicular Access Control System | Comparison C1–C4 | 4 | 3,084–3,160 p-d | 3.46–4.23 yrs | Full contractor delivery | Route Matrix |
Glossary
The method is based on a one-to-one correspondence between engineering lifecycle stages in the waterfall model and product maturity stages in the modern development model. This correspondence is the core of the deterministic engineering method.
| Abbr. | Engineering Stage | Product Stage | Product Maturity | Engineering Meaning |
|---|---|---|---|---|
| TA | Technical Assignment | Discovery / Requirements Baseline | Requirements baseline | The scope is formally defined and ready for engineering planning. |
| PP | Preliminary Project | Prototype (conceptual) | Conceptual maturity | The first tangible artifact. The concept is verified. The first checkpoint. |
| TP | Technical Project | MVP (technical form) | Technical MVP maturity | The baseline architecture is proven. The engineering foundation is ready. |
| WP | Working Project | Release Candidate | Full engineering maturity | Functionally complete. Ready for acceptance testing. |
| TWP | Technical Working Project | Release Candidate (without MVP) | Combined implementation maturity | TP + WP are combined into one stage. Faster route, fewer artifacts. |
| IM | Implementation | Production Release | Operational maturity | The system is deployed and operational. |
| Total | Integral stage | All selected stages together | Full-cycle maturity | Total labor intensity and duration for the selected configuration. |
| p-d | person-days | — | — | A labor-intensity unit. 1 p-d = 1 developer working for 1 day. |
| FTE | Full-time equivalent | — | — | The number of full-time developers assigned to a stage. |
| Choice | Stage configuration | — | — | The selected combination of engineering stages for a specific project. |
The correspondence between engineering stages and product stages is established through the concept of product maturity level — a universal parameter at the core of the deterministic engineering method. Any known waterfall-based estimation algorithm, including COCOMO, GOST-based methods, or ISO/IEC 15504, can be applied to modern product or Agile models through this correspondence.