Ingenieurwissenschaften

Das V-Modell beschreibt einen Entwicklungsprozess für Produkte. Streng genommen handelt es sich hierbei um kein Modell, sondern um eine Kästchen & Pfeilchen Beschreibung. Denn aus der Sicht eines Ingenieurs oder Wissenschaftlers macht das V-Modell keine Vorhersagen und liefert auch keine zu überprüfenden Ergebnisse. Es ist in erster Linie ein Management-Tool und bietet Ansatzpunkte für die Organisation und Strukturierung eines Entwicklungsprozesses.

Das V-Modell soll den Ingenieur bei der Entwicklung eines Produkts unterstützen. Genauer gesagt soll es die Zusammenarbeit der Beteiligten und nicht den Einzelnen unterstützen. Da an einem Entwicklungsprozess in der Regel viele Personen beteiligt sind und das immer Abstimmungsprobleme und Interessenkonflikte bedeutet, besteht hierfür ein erhebliches Interesse. Es stellt sich allerdings die kritische Frage, ob der Ingenieur dabei auch wirklich eine Unterstützung erfährt oder ob es nur Bürokratie verursacht?

Wenn man sich über das V-Modell eine Meinung bilden will, kann man zwei verschiedene Sichtweisen einnehmen. Man kann das V-Modell aus Sicht des Ingenieurs und aus Sicht des Managers sehen. Entwickeln Ingenieure ein Produkt und nutzen zur erfolgreichen Vermarktung ein Management oder macht das Management ein Produkt  marktfähig, in dem es u.a. eine Entwicklungsabteilung beschäftigt? Überprüfen Sie einmal, wie Sie das ganze sehen? In welcher Unternehmenskultur fühlen Sie sich eher zuhause?

Wir betrachten einmal letztere Sichtweise. Hier bietet das V-Modell ein Führungsinstrument. Bei der Einführung des V-Modells geht es sinnbildlich um die Etablierung eines galeerenartigen Entwicklungsprozesses, der durch einen Mann am Steuerrad und viele, durch Trommeln abgestimmte Ruderer geradlinig ans Ziel gebracht werden soll.

Der Mann am Ruder ist der Manager. Er sieht nicht das Boot, in dem alle sitzen, als eine Einheit. Er wundert sich vielleicht, wenn er von einem Segelboot spielend überholt wird und will dann mit dem gleichen Denken ebenfalls ans Steuer eines solchen Boots. Im Herzen will er natürlich, um ehrlich zu sein, lieber ein Motorboot, also ohne die Notwendigkeit von Menschen, denn die bereiten immer Ärger. Ein Produkt, das sich selbst und ohne menschliche Beteiligung entwickelt, wäre natürlich für alle toll, liegt aber momentan außerhalb der Vorstellungskraft. Der Manager, von dem hier die Rede ist, ist kein Coach. Er würde ansonsten im Segelboot sitzen und sich über die Galeerentreiber und die Verfechter des V-Modells wundern.

Es geht nicht um einen agilen, segelbootartigen Entwicklungsprozess, in dem jeder eine Aufgabe erfüllt, die auch kurzfristig einmal wechseln kann und bei der man je nach Wind und Seegang mal mehr mal weniger zu tun hat, aber letztlich nur gemeinsam ankommt. Es geht nicht um einen Prozess, der Spaß machen darf, bei dem vielleicht der erfahrenste Kamerad der Skipper ist. Es geht nicht darum, elegant, sondern überhaupt ans Ziel zu kommen und es zur Not mit bloßer Gewalt termingerecht zu erreichen. Das „Können“ wird nach oben ans methodische Ruder  verlagert und die einzelnen Ruderer müssen dafür weniger „können“ und auch weniger teamorientiert sein.

Warum kommt man überhaupt auf die Idee, so etwas als Unternehmen zu wollen, wenn es doch auch agil gehen könnte? Die Antwort ist neben dem egoistischen Aspekt, die Kompetenz eines Unternehmens in den Kopf verlagern zu wollen, auch den aktuellen Märkten geschuldet, in denen zwar Produkte transparent angeboten, aber im Verborgenen entwickelt werden. Es ist kein Open Source Ansatz. Niemand überblickt alleine, wie komplexe Produkte konkret entwickelt werden.

Man muss sich als Ingenieur einmal in die Lage eines Nachwuchsmanagers hineinversetzen, der aus eigener Erfahrung nicht so recht versteht, wie ein Entwicklungsprozess (verborgen oder nicht) abläuft. Für ihn gibt es die Festlegung der Dinge, die ein Produkt können soll, dann folgt über eine viel zu lange Dauer eine viel zu teure, von Spezialisten erledigte Arbeit und dann ist das Produkt fertig. Es ist dann mehr oder weniger – meist weniger –  das Produkt, das der Vertrieb für den aktuellen Markt gerne hätte.

Der Entwicklungsprozess ist für einen solchen Manager eine Blackbox, in der Magie von Ingenieuren passiert, die diese aber irgendwo her gelernt haben müssen, sowie Fliesenverlegen vielleicht. Da es natürlich so etwas wie Magie nicht gibt, muss innerhalb dieser Black-Box etwas passieren, das man rational erklären und logisch verstehen kann. Und schon ist so ein Entwicklungsprozess von jemand verstanden, der selbst noch nie irgendetwas entwickelt hat und es auch gar nicht möchte. Man strebt dann nicht nach dem Prozess, sondern nur nach dem freudigen Ereignis des Marktstarts. Alle Entwicklungen sind vom Prinzip gleich.

Die Einführung eines V-Modells geht mit dem Versprechen einher, jeden Entwicklungsprozess zu verstehen und mit austauschbaren Ingenieuren kontrolliert zum Erfolg zu führen, ohne die jeweiligen Bedingungen und Voraussetzungen im Detail zu verstehen. Bzgl. Austauschbarkeit sollte noch angemerkt werden, dass der Manager, der den Entwicklungsprozess nach dem V-Modell organisiert, in dieser Denkweise ebenso austauschbar ist.

Schauen wir uns einmal einen Entwicklungsprozess an. 

Sagen wir zunächst einmal, der Entwicklungsprozess hat einen wohl definierten Anfang wie ein Kick-Off-Meeting und ein wohl definiertes Ende wie ein Projektreview. Das „V“ steht dann für den zeitlichen Pfad des Prozesses zwischen diesen beiden Punkten.

Dieser Pfad erfährt einen Knick bzw. eine Richtungsänderung. Wenn man bedenkt, dass die Zeit meist von links nach rechts aufgetragen wird, kommen alternativ nicht viele Buchstaben in Betracht, wenn man keinen Rückschritt oder Iterationsschleifen „modellieren“ will. Das „O“ würde z.B. eine Entwicklung repräsentieren, die dort aufhört, wo sie anfängt – ja, die Entwicklung in einem O-Modell hätte nicht einmal einen ausgewiesenen Anfang und Ende, das durchaus sogar Sinn machen kann, wenn man Produkte ständig weiterentwickelt.

Das „G“ repräsentiert vielleicht eine Entwicklung, die sich planetarisch dem Ziel annähert. Das „X“ steht vielleicht für zwei Entwicklungen, die sich kreuzen. Das „W“ kommt vielleicht schließlich noch in Frage. Und tatsächlich, es gibt neben dem V-Modell auch ein W-Modell. 

Die Grundidee ist also, den Entwicklungsprozess auf einem Zeitstrahl darzustellen. Das einfachste wäre vielleicht, „–> „Modell“zu schreiben. Aber das ist offensichtlich zu trivial. Wenn man sich nun vorstellt, dass man das „V“ in einem xy-Diagramm einträgt– nicht vergessen, hier wird aus Kästchen & Pfeilchen Denken Wissenschaft gemacht – muss man sich die Frage stellen, was denn nun auf der y-Achse steht.

Und nun kommt der wirklich tolle Gedanke: Man stelle sich vor, man zerlege das komplexe Produkt während der Entwicklung in immer kleinere Funktionen und Unterbaugruppen und baue es dann aus diesen Teilen wieder zusammen, nachdem man jede dieser Unterbaugruppen für sich genommen entwickelt, getestet und für „gut“ befunden hat. 

Jeder, der einmal etwas selbst programmiert hat, kennt das. Man programmiert etwas, aber insgesamt funktioniert es nicht so, wie es soll. Obwohl es läuft, ist es total verbuggt. Nach einigem Rumprobieren geht man dann hin und überprüft jede Funktion erst einmal für sich und dann erst das Zusammenspiel unter kontrollierten Bedingungen. Denn hier weiß man genau, was passieren soll. Und siehe da, man findet nach und nach alle Fehler.

Ich brauche diesen Heureka-Moment gar nicht weiter ausführen. Man erkennt einfach, dass es der einzig sinnvolle Weg ist, um der Komplexität Herr zu werden. 

Dieses Denken, alles in immer kleinere Teile zu zerlegen, die man einfacher untersuchen und verstehen kann, geht übrigens auf den Philosophen René Descartes im 17. Jahrhundert zurück und ist seitdem ein Grundpfeiler wissenschaftlichen Denkens. Aber philosophische Weisheiten werden ja alle paar Jahre neu entdeckt. So wie in dem Fall des V-Modells von dem Amerikaner Berry Boehm im Jahre 1979 in Bezug auf Softwareprogrammierung. 

Es war eine Zeit, in der anarchische Spaghetti Programmierung noch Standard war, in der Programme aber auch noch nicht so komplex waren, als dass nicht vollkommen auf der Hand liegt, dass Spaghetti Programmierung eine schlechte Methode ist. 

Auf der y-Achse des V-Modell-Diagramms wird nach dieser Idee der Detaillierungsgrad bzw. die Zerlegung in Unterfunktionen, Klassen und Methoden aufgetragen. Immer kleinere Bausteine stehen weiter unten. 

Der Gedanke der Entwicklung nach dem V-Modell ist nun, dass man zunächst jede Funktionalität am Reißbrett in immer kleinere Bestandteile zerlegt und dabei definiert, was diese im einzelnen können müssen, damit sie im Zusammenspiel funktionieren. Das macht man zeitlich gesehen bis zum Knick in dem „V“. Von da an entwickelt man diese wohldefinierten Bausteine und prüft sie gegen die Anforderungen. Das macht man von Integrationsebene zu Integrationsebene, bis man schließlich wieder oben bei der gesamten Funktionalität und damit am Ende der Entwicklung bzw. dem Ende des „V“ ist. 

In der Praxis funktioniert das aus vielen Gründen nicht. An erster Stelle ist das Problem zu benennen, dass jemand abstrakte Funktionalitäten definiert, aber keine Ahnung hat, wie das auf kleinster Ebene konkret umzusetzen ist. 

Für wirklich innovative Produkte taugt die Methode daher wenig, wohl aber für Entwicklungen, bei denen die Funktionalität weitgehend aus vorhanden Bausteinen und Bibliotheken adaptiert werden kann. 

Um die Grundidee des V-Modells, bzw. die lauwarme Umverpackung der wissenschaftlichen Grundsatzmethode nach Descartes marketingtechnisch aufzupolieren, gab es 2005 eine Überarbeitung durch eine kleine akademische Gruppe, in der das geschilderte Galeerendenken abgemildert werden sollte. 

Die Erweiterung kann man in etwa wie folgt zusammenfassen: Man hänge ein Segel namens XT für den Fall von Rückenwind an die Galeere namens V-Modell, als habe man verstanden, was das Prinzip vom Segeln ist. Und da man es verstand, hielt man es  auf 600 Seiten fest.

Ein solch aufgeblasener Organisationsapparat widerspricht natürlich dem modernen Lean Management Gedanken und dem Prinzip einer agilen Entwicklung und wirkt etwas aus der Zeit gefallen.

Das V-Modell wird in der Überarbeitung der VDI-Richtlinie 2021 auch nicht speziell aufgeführt und ist nur eine unter vielen Spielarten, wie ein Entwicklungsprozess beschrieben werden kann. Es ist keinesfalls eine neue Methodik mit dem V-Modell verbunden, als dass schlichtweg das wissenschaftliche Vorgehen an sich umverpackt und verkompliziert wird.

Bevor man nun stumpf das V-Modell einführt, vielleicht sogar dafür noch teure Berater engagiert, macht es also eher Sinn, sich zunächst mit Entwicklungsprozessen im Allgemeinen zu befassen. Man wird vielleicht feststellen, dass man auf ganz natürliche Weise bereits Descartes Strategie verfolgt. Dann optimieren Sie einfach diese Strategie ohne bürokratischen Aufwand und Sie haben ohne zu wissen, das V-Modell eingeführt. 

Aber eins dürfen Sie dabei nicht vergessen.

Die Descartes’sche Strukturierung vom Großen ins Kleine und zurück ist zwar durch und durch ein wissenschaftliches Ideal, funktioniert aber auch in der Wissenschaft niemals auf einem zielstrebigen Pfad, wie es ein kantiges „V“ vermittelt.

V-Modell
Bewerte den Beitrag

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.