VP-Model Learnings raminderpalsingh.com
Dr Raminderpal Singh

VP-Model Discussion

Section 01

The VP-Model: What It Is

The VP-model (Virtual Prototype model) is a derivative of the V-model, originating from German academic and industrial work — specifically the University of Karlsruhe, 1998: Code Generation for an Open Rapid Prototyping Environment Supporting Heterogeneous System Design.

It extends the standard V-model by adding prototyping at each layer of abstraction — not only at implementation, but at system, subsystem, and module design levels.

  • Three prototype loops exist, one at each abstraction tier, each feeding forward into the corresponding test tier on the right branch
  • Applied in both information systems and embedded systems — notably automotive and semiconductor domains in Germany
  • Predates Agile but is structurally compatible with iterative execution
Prototype Prototype Prototype Requirements Elicitation System Specification System Design Subsystem Design Module Design System Use System Delivery System Test Subsystem Test Module Test IMPLEMENTATION
Figure 1: VP-model  ·  Recreated from Karlsruhe (1998) reference
Section 02

Three-Layer Structure

Left Branch (Development)Prototype LoopRight Branch (Validation)
Requirements Elicitation / System SpecificationPrototype — System levelSystem Use / System Delivery
System Design / Subsystem DesignPrototype — Subsystem levelSystem Test / Subsystem Test
Module DesignPrototype — Module levelModule Test
Implementation(base of V)—

Each prototype is purpose-specific:

  • System-level: UI/UX focus — mock-ups for requirements validation
  • Subsystem-level: Architectural stubs — prove integration points, nothing executes yet
  • Module-level: Targeted at risky design decisions — performance, algorithm choice
Section 03

How Prototyping Works

At each layer, a prototype targets the specific risks of that layer, not a general demonstration of the product.

  • Prototypes at higher layers are stubs — they announce "I am here" but execute nothing
  • As modules are developed, stubs are replaced with real implementations — structure preserved, substance filled in incrementally
  • This defines a spike: targeted effort on the hardest or riskiest part of a given layer
Spike Principle Early sprints are requirements/architecture-heavy. Each spike targets layer-specific risk. Agile cadence applies, but the V-model layers define the scope of each spike — not arbitrary feature groupings.
Section 04

Relationship to Agile

The VP-model is not waterfall — it is applied iteratively: each sprint or increment passes through the V layers at the appropriate level of atomicity.

Correct Framing Take the principles of the VP-model (separation of concerns, layered abstraction, prototyping at each layer) and apply them with an agile cadence. Let the abstraction layers define what each spike targets — not arbitrary feature groupings.
  • Early sprints weight requirements and architecture; later sprints shift to implementation — natural, not contradictory
  • Each layer has its own prototype and test artefact, so iteration at one layer does not destabilise others
Section 05

Core Intellectual Position

"If you are using AI for coding, you must have software engineering discipline — or you are completely lost."
  1. The last 20 years over-emphasised coding and under-emphasised architecture, design, and modelling — Agile's "fail fast" ethos enabled this, but it was always wrong
  2. AI now does the coding. Coding is swap-in/swap-out. The AI will be better at it than humans
  3. Therefore, the human's value is now entirely in the upper branches of the V — requirements elicitation, architecture, separation of concerns, modelling
  4. Without upper-branch discipline, AI produces fast code with no structure, no testability, no maintainability — exponentially faster technical debt
  5. AI coding orchestration tools can enforce this discipline through mechanisms such as filesystem locks, cryptographic hash audits, and state machine constraints — making the process auditable and the output traceable
Section 06

On MBSE

Challenge: "Why aren't you using a model-based approach?"

  • A model-based approach lends itself naturally to the V-model — models are layered by definition; an architectural model is not the same as a design model
  • MBSE formalises the separation of concerns, it does not replace it
  • The formalism (UML, ArchiMate, SysML) can and should be delegated to AI — LLMs already generate Python; they can generate BPMN or UML
  • The human stays at the systems level: choosing what to model, what constraints to impose, what separations to enforce
Conclusion MBSE and this approach are not in conflict. Which formalism to use is an implementation detail — a candidate for AI delegation.
Section 07

The Human Role Going Forward

The human is a systems engineer, not a coder. Primary activities: requirements elicitation, option generation (diverge), option selection (converge), architecture and separation decisions.

AI is a cognitive assistant — it generates options, executes implementation, and flags trade-offs. Analogous to protein design pipelines generating 20,000 candidates then filtering — generative divergence followed by discriminative convergence.

Grady Booch's framing applies directly: "When AI writes the code, the architect is still accountable."

Section 08

Known Limitations

The VP-model is a well-grounded framework, but applying it to AI-assisted software development surfaces gaps that practitioners should be aware of. These are open problems, not reasons to abandon the approach.

Most AI coding tools implement the V-model's layer separation but do not yet implement the VP-model's defining feature: a running executable artefact at each abstraction tier before implementation begins. The gap between "interface contract on paper" and "running architectural stub" is consequential — it means integration risks are not surfaced until the build stage.

VP-Model FeatureCurrent State in AI-Assisted Workflows
Prototypes at each abstraction layerRarely implemented — most tools jump directly from architecture definition to implementation
Subsystem-level architectural stubsInterface contracts are documented but not executed — no running stubs to validate integration points early
Spike-driven development targeting layer-specific risksTask sequencing is typically linear, not risk-targeted — the hardest problems are not necessarily addressed first
System-level prototype (UX/UI mock-up)AI coding tools focus on implementation; user-level prototyping remains a manual, human-led activity
⚠ Where This Matters Most These gaps are most significant in systems with non-trivial subsystem boundaries, where integration failures are expensive to diagnose and fix. For straightforward conversions of well-understood POCs, the absence of running stubs is a tolerable trade-off. For complex scientific or safety-critical systems, it is not.
Section 09

Further Reading

The ideas on this page sit at the intersection of systems engineering, software architecture, and AI-assisted development. The following thinkers and sources provide useful grounding.

SourceRelevance
Karlsruhe (1998)Code Generation for an Open Rapid Prototyping Environment Supporting Heterogeneous System Design — the original VP-model paper. Provides the academic foundation for the three-tier prototype loop structure.
Gregor HohpeSoftware architect and author of Enterprise Integration Patterns. Writes clearly on the enduring importance of architecture in an era of automated implementation. Website and YouTube.
Grady BoochPioneer of object-oriented design and UML. His recent writing on AI and software architecture is directly relevant: "When AI writes the code, the architect is still accountable."
Forsberg & Mooz (1991)Original V-model formalisation in systems engineering — the foundation on which the VP-model builds. Referenced widely in aerospace and defence contexts.
Boehm & Turner (2004)Balancing Agility and Discipline — the definitive treatment of applying structured engineering disciplines within iterative development cycles.
Suggested Vocabulary If discussing these ideas with software engineers: use separation of concerns, abstraction layers, and spike-driven development. These are standard terms with precise meanings in the field and will be recognised by practitioners without further explanation.
Section 10

Common Objections

These ideas often meet resistance from developers and engineering managers who have not worked in systems engineering contexts. The objections are worth taking seriously rather than dismissing.

ObjectionResponse
"This is just waterfall with extra steps."The VP-model is applied iteratively — each sprint or increment passes through the relevant abstraction layers. The discipline is in maintaining layer separation within each cycle, not in sequencing all layers before any implementation begins.
"Good engineers already do this without a formal framework."They do, when given the time and authority to. The problem is that AI coding agents do not — left unconstrained, they collapse all layers into a single implementation pass. The framework is a guardrail on the agent, not on the human.
"Why does an AI coding workflow need systems engineering principles?"Because AI makes coding faster but does not make architectural decisions for you. Without explicit layer separation, faster code generation accelerates the accumulation of technical debt — it does not reduce it.
"The VP-model was designed for hardware/embedded systems, not software."The original 1998 paper addresses heterogeneous system design spanning hardware and software. The principles — prototyping at each abstraction layer, tests derived from specifications — transfer directly to software-only systems.
The Underlying Shift The practical consequence of AI-assisted coding is not that software engineers become redundant. It is that the value of engineering skill moves entirely up the abstraction stack — toward requirements, architecture, and separation of concerns — and away from implementation. The VP-model provides a concrete framework for operating at those levels deliberately.