Die V-Struktur des Entwicklungsprozesses bildet dessen Symmetrie in seiner Einheit von Lösungsfindung (bzw. Analyse/Dekomposition, Top-Down-Vorgehen) und Montage/Lösungsverifizierung (bzw. Komposition, Bottom-Up-Vorgehen) ab. Dabei werden i.a. 3 Ebenen mit entsprechend paritätischen Aktivitäten unterschieden:

(1) Anforderungsebene (finale Ebene)
Als erster Schritt erfolgt die Analyse/Dekomposition der Aufgabe und Spezifizierung der Anforderungen; demgegenüber werden als letzter Schritt diese Anforderungen getestet. Die Validierung bzw. der Akzeptanztest entscheidet letztendlich über die Freigabe einer Entwicklung.

(2) Systemebene/Architektur
Ableitung der Lösungsstruktur (Systemarchitektur) aus den Anforderungen, die im Zusammenwirken, in der Komposition der Einzellösungen besteht. Definition der entsprechenden Schnittstellen. Die entsprechende Verifizierung erfolgt in Intergrationstests, also Tests von bereits geprüften Einzellösungen im Verbund.

(3) Modulebene (Design/Implementation)
Erarbeitung der detaillierten Lösungsdesigns der Einzellösungen/Module und Implementation auf das Zielsystem. Verifizierung dieses Schrittes in entsprechenden Modultests. Die eingangs betrachteten 2 Schritte des Software-Entwicklungsprozess (Entwurf,Implementation) bilden also nur die Lösungsfindung auf Modulebene ab.

Aspekte des Risikomanagements:
Hat die zu entwickelnde technische Lösung sicherheitsrelevante Funktionen zu erfüllen, ist der Entwicklungsprozess von einem Risikomanagement zu begleiten. Das bedeutet bei Vorgehen nach dem V-Modell entsprechende zusätzliche Aktivitäten in den einzelnen Ebenen; auf Anforderungsebene sind die anforderungsbedingten Risiken zu spezifizieren und abschließend zu validieren (Bestimmung und Bewertung des Restrisikos); auf Systemebene bedeutet das ggf. die Einführung von Schutz-Subsystemen als Systemkomponenten und ihre Verifizierung; für die Modulebene ggf. die Anwendung risikominmierender Maßnahmen (Begrenzung des Teilrisikos entsprechend Anforderung).

Um die Lösungsstruktur zu gewinnen, sollte der Teil, der Anforderungen, der die abstrakte Funktion der Lösung beschreibt, zweckmäßigerweise in folgende Form gebracht/ normiert werden:
{ [ Subjekt ]; [ Bedingung ]; [ auszuführende Aktion ]; [ Objekt ] }
(Objekt: im Sinne von Handlungsempfänger)

Eine solche Form gestattet eine einfache Ableitung von Handlungsszenarien aus den Anforderungen (Verhaltensmodelle). Die Darstellung kann in z.B. in UML-Sequence-Diagrammen erfolgen, die eine Aufstellung aller Handlungsträger (sowohl Ausführender als auch 'Empfänger') sowie die Aktionen ihrer Wechselwirkung und deren Bedingungen bzw. Triggerereignisse enthalten.

Bei der Spezifikation der Handlungen bzw. der Bedingungen/Trigger, die die Handlungen auslösen, ist oft festzustellen, dass sie an bestimmte Zustände des Handlungsausführenden gebunden sind. In diesen Fällen ist die Darstellung dieser Zustände und ihrer Übergänge in UML-Zustandsdiagrammen/State-Charts (parallele und serielle ereignisgekoppelte Zustandsautomaten) sinnvoll. Mit Hilfe der Zustandsdiagramm können ggf. auch fehlende Anforderungen gefunden werden.

Den Handlungsträgern dieser Szenarien werden Objekte, also Instanzen von Klassen (gleichartiger Objekte) zugeordnet. Die Aktionen ihrer Wechselwirkung finden sich in den Methoden der Klassen wieder. Auf diese Weise entstehen Strukturmodelle, die die Architektur der technischen Lösung abbilden. Zum Teil unterstützen UML-Werkzeuge (z.B. Sparks Enterprise Architect) die direkte Codegeneration aus den Struktur- bzw. Verhaltensmodellen.

Wichtig ist, dass die oben genannten Schritte bereits vor der ersten Designentscheidung, also auf Anforderungsniveau, der Ebene mit dem höchsten Abstraktionsniveau durchgeführt werden, es entsteht also eine Hülle oder ein Rahmen für die folgende Entwicklungsarbeit, die benannten Handlungsträger sind lediglich Platzhalter.

Jede technische Lösung bedeutet dann eine Ableitung von Kindklassen aus dem bisherigen 'Platzhalter-Modell', die den Kontext der Platzhalter ererben. Die Platzhalter werden mit den Designentscheidungen spezifiziert. Dadurch kommen Randbedingungen und ggf. weitere, spezifische Handlungsträger/Platzhalter dazu.
Bei Verwendung der Zustandsautomaten bedeutet das z.B. das Hinzukommen weiterer, entweder Sub-States bzw. State-Machines oder Parallelcharts.
Die Gültigkeit der Elternprozesse bleibt dabei erhalten (Gültigkeit der Anforderungen).

Dieses Vorgehen wird solange fortgesetzt, bis die Elemente, die die geforderte Funktion realisieren, fertig verfügbare Funktionselemente, also nicht mehr Bestandteil des aktuellen Entwicklungsprozesses sind. Dabei kann es sich um Zulieferprodukte, Infrastrukturelemente oder aber bereits bestehende oder parallel entwickelte Lösungen handeln, die hier wieder verwendet werden können.

Im Ergebnis entsteht eine Baumstruktur von Sätzen von Struktur- (und zugehörigen Verhaltens-)modellen, wobei jedem Ast dieser Baumstruktur eine technische Lösung auf einem bestimmten Abstraktionsniveau zugeordnet werden kann.
Dabei ist es möglich, parallel nach der gleichen Methode entwickelte (Teil-)Lösungen an der Stelle der Platzhalter auf dem richtigen Abstraktionsniveau in die bestehende Baumstruktur einzuhängen, s.o., bzw. bei Änderungen die entsprechenden Äste auszutauschen (weiterentwickelte Baukastenstruktur). Umgekehrt kann die zu entwickelnde Lösung später in anderen Kontexten wiederverwendet werden. Wichtig ist, dass die Schnittstellenanforderungen der Platzhalter aus dem jeweils übergeordneten Kontext erfüllt werden.
Dabei kann rückwirkend über die entstandene Architektur ggf. die Struktur der Anforderungen korrigiert werden.

Das beschriebene Vorgehen, die fortschreitende Spezifizierung der Handlungsträger, der Vererbungsbaum der Klassen sollte sich in den Entwicklungsdokumenten, vorzugsweise UML-Diagrammen, wiederfinden.

Mit den bisher genannten Beschreibungsmöglichkeiten lässt sich die Zustandslogik, aber nicht das dynamische Verhalten bzw. Wechselwirkung von Handlungsträgern, wie das bei Steuerungen und Regelungen der Fall ist, quantitativ beschreiben.
Für diese Aufgabe sind Signalflussdiagramme geeignet. Der Signalfluss der Wechselwirkung zwischen den Handlungsträgern kann aus den Modellbeschreibungen, insbesondere aus den Querverbindungen in den Sequence-Charts abgeleitet werden.
Mit entsprechenden Werkzeugen können dann die in ihrem Verhalten bekannten Einzelsysteme zu einem Gesamtsystemen zusammengesetzt werden (z.B. ein Regelungssystem aus Regler und Strecke), dessen Signalverhalten per Simulation berechnet werden und gegen die Anforderungen getestet werden kann (z.B. mit Mathworks Simulink) .

Mathematisch bildet das Gesamtsystem dabei ein Differential- bzw. Zustandsgleichungssystem, das in dieser Einheit integriert werden muss. Die Modulentwicklung würde in der Modellierung einzelner Blöcke (z.B. Strecke) bestehen während der Reglerentwurf natürlich nur auf Systemebene Sinn macht, obwohl er bezüglich der Entwicklungstätigkeit ebenso der Modulentwicklung zuzurechnen ist.

Praktisch stellt dieser Entwicklungsschritt einen eigenständigen V-Zyklus dar, bei dem das Ergebnis auf der Simulationsebene vorvalidiert wird. Die Tests auf Simulationsebene können dabei i.a. mit höherer Effektivität und Variantenabdeckung durchgeführt werden, müssen aber unabhängig davon nach der Implementation auf dem Zielsystem noch abschließend validiert werden.