Das V-Modell ist ein Modell, das für ver­schie­de­ne Ent­wick­lungs­pro­zes­se genutzt wird, z. B. in der Soft­ware­ent­wick­lung. Es wurde in seiner ur­sprüng­li­chen Form in den 1990er Jahren ent­wi­ckelt, im Laufe der Zeit immer weiter ver­fei­nert und an moderne Ent­wick­lungs­me­tho­den angepasst. Die grund­le­gen­de Idee stammt al­ler­dings schon aus den 1970er Jahren und war als eine Art Wei­ter­ent­wick­lung des Was­ser­fall­mo­dells kon­zi­piert.

Zu­sätz­lich zu den je­wei­li­gen Ent­wick­lungs­pha­sen eines Projekts definiert das V-Modell parallel die be­glei­ten­den Vor­ge­hens­wei­sen zur Qua­li­täts­si­che­rung und be­schreibt, wie diese einzelnen Phasen mit­ein­an­der in­ter­agie­ren können. Seinen Namen verdankt das Vor­ge­hens­mo­dell seiner dem Buch­sta­ben V ähnelnden Struktur.

Die einzelnen Phasen des V-Modells

Zunächst definiert das V-Modell den Ablauf eines Projekts in einzelnen Phasen, die immer weiter ins Detail gehen:

  • Zu Beginn des Projekts sieht das Modell eine Analyse der all­ge­mei­nen An­for­de­run­gen an das geplante System vor.
  • Danach soll das Projekt mit funk­tio­na­len und nicht­funk­tio­na­len An­for­de­run­gen an die Sys­tem­ar­chi­tek­tur an­ge­rei­chert werden.
  • Darauf folgt der Sys­tem­ent­wurf, bei dem die Kom­po­nen­ten und Schnitt­stel­len des Systems geplant werden.
  • Sind diese Phasen ab­ge­schlos­sen, kann die Soft­ware­ar­chi­tek­tur im Detail kon­zi­piert werden.

Nun folgt die ei­gent­li­che Ent­wick­lung der Software gemäß diesen Plänen. An­schlie­ßend folgen die Phasen der Qua­li­täts­si­che­rung, die sich immer auf die Schritte der Ent­wick­lung beziehen. Das Modell sieht folgende Aufgaben vor:

  • Unit Tests
  • In­te­gra­ti­ons­tests
  • Sys­tem­in­te­gra­ti­on
  • Abnahme

Zu­sam­men­spiel von Kon­zi­pie­rung und Qua­li­täts­si­che­rung

Das „V“ entsteht deshalb, weil das Modell die Ent­wick­lungs­pha­sen den kor­re­spon­die­ren­den Qua­li­täts­si­che­rungs­pha­sen ge­gen­über­stellt. Der linke Arm des Buch­sta­ben V enthält die Aufgaben zur Kon­zi­pie­rung und Ent­wick­lung des Systems, der rechte Arm die zu­ge­hö­ri­gen Maßnahmen zur Qua­li­täts­si­che­rung. In der Mitte dieser beiden Arme, ein­ge­bet­tet zwischen den Ent­wick­lungs­pha­sen und den Qua­li­täts­si­che­rungs­pha­sen, liegt die Im­ple­men­tie­rung des Produkts. Im Fall eines Soft­ware­pro­jekts wäre dies die Pro­gram­mie­rung der Software.

Die korrekte Umsetzung der geplanten Soft­ware­ar­chi­tek­tur wird durch Unit Tests abgefragt. Hier wird im Detail geprüft, ob einzelne Module der Software exakt die ge­for­der­ten Funk­tio­nen erfüllen und auch wirklich die er­war­te­ten Er­geb­nis­se liefern. Idea­ler­wei­se finden diese Mo­dul­tests möglichst parallel zur Ent­wick­lung statt, um Fehler zu vermeiden.

Dem Sys­tem­ent­wurf stehen die In­te­gra­ti­ons­tests gegenüber. Hier wird darauf geprüft, ob die einzelnen Kom­po­nen­ten so mit­ein­an­der zu­sam­men­ar­bei­ten, wie es geplant war – ob bei­spiels­wei­se alle Abläufe die er­war­te­ten Er­geb­nis­se liefern. Feh­ler­haf­te Er­geb­nis­se können an dieser Stelle u. a. auf Probleme mit Schnitt­stel­len hinweisen.

Der Sys­tem­test prüft, ob die all­ge­mei­nen An­for­de­run­gen an das System erfüllt wurden, die beim Kon­zi­pie­ren der Sys­tem­ar­chi­tek­tur fest­ge­legt wurden. Solche Tests finden in der Regel in einer Test­um­ge­bung statt, die die realen Be­din­gun­gen beim Kunden möglichst exakt nach­stellt.

Der An­for­de­rungs­ana­ly­se des Ge­samt­sys­tems steht am Ende des Projekts die Abnahme des fertigen Produkts gegenüber. Bei der End­ab­nah­me prüft der Kunde, ob die Vorgaben im laufenden Betrieb erfüllt werden. In der Regel wird hier nur das Verhalten der Software an der Ober­flä­che getestet – sprich: das, was der Auf­trag­ge­ber bei der täglichen Nutzung zu sehen bekommt. Man spricht dabei auch von einem Ak­zep­tanz­test.

V-Modell XT: Die Wei­ter­ent­wick­lung des V-Modells

Im Jahr 2006 wurde das V-Modell zuletzt über­ar­bei­tet, um neuere Prin­zi­pi­en wie agile Ent­wick­lung wie­der­ge­ben zu können. Das Ergebnis war das V-Modell XT. XT steht hierbei für Extreme Tailoring und be­schreibt die neue Mög­lich­keit, das Modell auf die je­wei­li­gen An­for­de­run­gen des Projekts zu­zu­schnei­den.

Ein grund­le­gen­der Gedanke hinter dieser Wei­ter­ent­wick­lung war, ein Modell be­reit­zu­stel­len, das sich flexibel an ver­schie­de­ne Pro­jekt­grö­ßen anpassen lässt. Gerade für kleinere Projekte war die ältere Methode häufig un­ver­hält­nis­mä­ßig aufwendig und daher in­ef­fi­zi­ent. Beim V-Modell XT hingegen ist es möglich, für kleine Projekte bestimmte Phasen zu streichen, die einen zu großen Mehr­auf­wand bedeuten würden.

Ferner wurden in das neuere Modell auch Auf­ga­ben­blö­cke mit­auf­ge­nom­men, die sich explizit auf den Auf­trag­ge­ber beziehen. Das alte Modell befasst sich allein mit der Ab­wick­lung des Projekts beim Auf­trag­neh­mer, bevor es zur End­ab­nah­me kommt. Im neuen Modell ist der Auf­trag­ge­ber stärker ein­ge­bun­den.

Das Modell wird weiterhin re­gel­mä­ßig ak­tua­li­siert, um Neue­run­gen im Soft­ware­ent­wick­lungs­pro­zess zu be­rück­sich­ti­gen und die Pra­xis­taug­lich­keit zu ver­bes­sern. Die ak­tu­ells­te Version des V-Modell XT ist die Version 2.3.

An­wen­dungs­ge­bie­te des V-Modells

Das V-Modell XT ist in der Industrie ein weit­ver­brei­te­tes Vor­ge­hens­mo­dell und gilt sogar für IT-Projekte der Bun­des­be­hör­den als of­fi­zi­el­ler Standard. Bei den meisten Aus­schrei­bun­gen öf­fent­li­cher Auf­trag­ge­ber für neue Soft­ware­pro­jek­te ist die Anwendung des V-Modells sogar ver­pflich­tend und spielt daher ins­be­son­de­re in Un­ter­neh­men, die Software für Behörden und Mi­nis­te­ri­en ent­wi­ckeln, eine große Rolle. Es kann für Soft­ware­pro­jek­te jeder Größe genutzt werden, egal ob in der Wirt­schaft, beim Militär oder bei der öf­fent­li­chen Hand. Es dient als Werkzeug, um die Or­ga­ni­sa­ti­on und Durch­füh­rung von Ent­wick­lung, In­stand­hal­tung und Wei­ter­ent­wick­lung ver­schie­dens­ter IT-Systeme zu er­leich­tern.

Außerdem kann das V-Modell auch in anderen Ent­wick­lungs­be­rei­chen genutzt werden, bei­spiels­wei­se für elek­tro­ni­sche oder me­cha­ni­sche Systeme in Forschung und Wis­sen­schaft. Für diese An­wen­dungs­ge­bie­te exis­tie­ren teils leicht an­ge­pass­te Varianten, die die typischen Vor­ge­hens­schrit­te der je­wei­li­gen Branche wi­der­spie­geln.

Vor- und Nachteile des V-Modells

Das Vor­ge­hens­mo­dell ist vor allem deshalb so weit ver­brei­tet, weil es für eine hohe Trans­pa­renz und sauber de­fi­nier­te, nach­voll­zieh­ba­re Abläufe sorgt. Im Folgenden finden Sie die wich­tigs­ten Vorteile und Kri­tik­punk­te im Überblick.

Die Vorteile des V-Modells

  • Op­ti­mie­rung der Kom­mu­ni­ka­ti­on zwischen den Be­tei­lig­ten durch fest de­fi­nier­te Begriffe und Zu­stän­dig­kei­ten
  • Mi­ni­mie­rung von Risiken und bessere Plan­bar­keit durch fest vor­ge­ge­be­ne Rollen, Struk­tu­ren und Er­geb­nis­se
  • Ver­bes­se­rung der Pro­dukt­qua­li­tät durch fest in­te­grier­te Maßnahmen zur Qua­li­täts­si­che­rung
  • Kos­ten­ein­spa­rung durch trans­pa­ren­te Auf­ar­bei­tung des gesamten Pro­dukt­le­bens­zy­klus

Insgesamt kann das Modell dabei helfen, Miss­ver­ständ­nis­se und unnötige Arbeiten zu vermeiden. Außerdem sorgt es dafür, dass alle Aufgaben zum richtigen Zeitpunkt und in sinn­vol­ler Rei­hen­fol­ge erledigt werden und dass möglichst keine Leer­lauf­zei­ten entstehen.

Die Nachteile des V-Modells

Das Vor­ge­hens­mo­dell ist teils zu simpel, um den Ent­wick­lungs­pro­zess aus Sicht der Ent­wick­ler voll­stän­dig ab­zu­bil­den. Der Fokus liegt verstärkt auf dem Pro­jekt­ma­nage­ment. Zudem erlaubt die relativ starre Struktur kaum, flexibel auf Än­de­run­gen während der Ent­wick­lung zu reagieren, und fördert somit einen ver­gleichs­wei­se linearen Pro­jekt­ver­lauf. Dennoch ist es möglich, mit dem V-Modell agile Ent­wick­lung zu betreiben, wenn das Modell richtig ver­stan­den und genutzt wird.

Al­ter­na­ti­ven zum V-Modell

In der Soft­ware­ent­wick­lung gibt es ver­schie­de­ne Vor­ge­hens­mo­del­le, die je nach Projekt und Team­struk­tur als Soft­ware­ent­wick­lungs­pro­zess in Frage kommen. Die Auswahl an Vor­ge­hens­mo­del­len ist relativ groß, wobei Modelle wie das Was­ser­fall­mo­dell oder das Spi­ral­mo­dell besonders weit ver­brei­tet sind. Das Was­ser­fall­mo­dell eignet sich etwa speziell für kleine, linear ab­lau­fen­de Projekte, während das Spi­ral­mo­dell gut für iterativ auf­ge­bau­te Projekte genutzt werden kann.

Zum Hauptmenü