Das V‑Modell Darstellung und Verwendung

Manage­ment-Zusam­men­fas­sung die­ses Bei­trags:
Das V‑Modell (auch Vor­ge­hens­mo­dell, engl. V‑Model) beschreibt ein Vor­ge­hen bei der Ent­wick­lung von Soft­ware, Sys­te­men oder Pro­duk­ten, wel­ches sich gra­fisch ent­lang eines Vs visua­li­sie­ren lässt.
In die­sem Bei­trag wird das V‑Modell und des­sen Ein­satz in ver­schie­de­nen Kon­tex­ten wie dem Sys­tems oder → Requi­re­ments Engi­nee­ring beschrieben.

Das V‑Modell ver­wen­det ein V zur Visua­li­sie­rung der Rei­hen­fol­ge von Schrit­ten oder Pro­zes­sen. Die Beson­der­heit ist, dass die Schrit­te / Pro­zes­se im V‑Modell in zwei Hälf­ten (grü­ne und rote Recht­ecke in Abbil­dung 0.1) so ange­ord­net sind, dass einem Schritt auf der lin­ken Hälf­te ein Schritt auf der rech­ten Hälf­te zuge­ord­net wer­den kann.

Gene­rell kommt das V‑Modell aus der → Soft­ware­ent­wick­lung, ist aber inzwi­schen nicht mehr dar­auf beschränkt. Die Ein­satz­ge­bie­te sind:

Abbil­dung 0.1 zeigt ein ein­fa­ches V‑Modell zur Soft­ware­ent­wick­lung: Auf der lin­ken Hälf­te / auf dem lin­ken Zweig reprä­sen­tie­ren die grü­nen Recht­ecke die Pro­zes­se des Requi­re­ments und Soft­ware Engi­nee­rings. Die Umset­zung des ent­wi­ckel­ten Kom­po­nent­ende­signs erfolgt in der Kom­po­nen­ten­im­ple­men­tie­rung (blau­es Recht­eck). Kor­re­spon­die­rend zu den Pro­zes­sen des Requi­re­ments und Soft­ware Engi­nee­rings wer­den die → Test­pro­zes­se auf der rech­ten Hälf­te / auf dem rech­ten Zweig des Vs ange­ord­net (rote Recht­ecke). Wich­tig ist dabei ver­ti­ka­le Anord­nung: Die Tests auf einer ver­ti­ka­len Stu­fe (oder hori­zon­ta­len Linie) gehö­ren zu den ent­spre­chen­den Requi­re­ments- und Design-Pro­zes­sen und ‑Arte­fak­ten der glei­chen ver­ti­ka­len Stufe.

Ein einfaches V-Modell, (C) Peterjohann Consulting, 2020-2024

Abbil­dung 0.1: Ein ein­fa­ches V‑Modell

Auch wenn in die­sem Bei­trag und auch all­ge­mein von “dem V‑Modell” gespro­chen wird, so gibt es kein ein­deu­ti­ges V‑Modell, was als all­ge­mein­gül­tig bezeich­net wer­den kann. Rich­ti­ger wäre es von “einem V‑Modell” zu spre­chen, was für einen kon­kre­ten Ein­satz­fall ver­wen­det wird.

1. Einleitung und Grundlagen

In die­sem Kapi­tel wer­den zunächst eini­ge Defi­ni­tio­nen und Grund­la­gen zum V‑Modell geliefert.

1.1 Definitionen

In der Wiki­pe­dia steht /#Wiki-V-Modell/:
“Das V‑Modell ist ein Vor­ge­hens­mo­dell, wel­ches ursprüng­lich für die Soft­ware­ent­wick­lung kon­zi­piert wur­de. Ähn­lich dem → Was­ser­fall­mo­dell orga­ni­siert es den Soft­ware­ent­wick­lungs­pro­zess in Pha­sen. Zusätz­lich zu die­sen Ent­wick­lungs­pha­sen defi­niert das V‑Modell auch das Vor­ge­hen zur Qua­li­täts­si­che­rung (→ Tes­ten), indem den ein­zel­nen Ent­wick­lungs­pha­sen Test­pha­sen gegen­über gestellt wer­den. Auf der lin­ken Sei­te wird mit einer funktionalen/fachlichen Spe­zi­fi­ka­ti­on begon­nen, die immer tie­fer detail­liert zu einer tech­ni­schen Spe­zi­fi­ka­ti­on und Imple­men­tie­rungs­grund­la­ge aus­ge­baut wird. In der Spit­ze erfolgt die Imple­men­tie­rung, die anschlie­ßend auf der rech­ten Sei­te gegen die ent­spre­chen­den Spe­zi­fi­ka­tio­nen der lin­ken Sei­te getes­tet wird. So ent­steht bild­lich das namens­ge­ben­de “V”, wel­ches die ein­zel­nen Ent­wick­lungs­ebe­nen ihren jewei­li­gen Test­ebe­nen gegenüberstellt.”

Beim VDI wird aus­ge­führt /#V‑Modell-VDI-2206/:
“Das V‑Modell, 1995 von Bröhl und Dröschel in der Soft­ware­ent­wick­lung auf­ge­bracht, beschreibt grund­sätz­lich eine sach­lo­gi­sche Ver­knüp­fung von Auf­ga­ben der inter­dis­zi­pli­nä­ren Produktentwicklung.”

1.2 Herleitung aus der Prozessdarstellung

Gene­rell kann das V‑Modell aus einer Pro­zess­dar­stel­lung gewon­nen wer­den. In Abbil­dung 1.1 ist die klas­si­sche Abfol­ge der Soft­ware­ent­wick­lung mit den fünf Pha­sen / Prozessschritten …

  • Ana­ly­se,
  • Design,
  • Imple­men­tie­rung,
  • Test und
  • Betrieb

dar­ge­stellt. Aus der rein linea­ren Abfol­ge (Punkt A) wird durch ein­fa­ches Umzeich­nen ein Was­ser­fall­mo­dell gewon­nen (Punkt B). Da Ana­ly­se und Betrieb sowie Design und Test “Gegen­stü­cke dar­stel­len”, kann ein V‑Modell dar­aus gene­riert wer­den (Punkt C).

Von der Prozessdarstellung zum V-Modell, (C) Peterjohann Consulting, 2022-2024

Abbil­dung 1.1: Von der Pro­zess­dar­stel­lung zum V‑Modell

Anmer­kun­gen:

  • Das V‑Modell wird teil­wei­se auch als “umge­klapp­tes Was­ser­fall­mo­dell” bezeichnet
  • Durch das Umzeich­nen kommt eine zusätz­li­che Seman­tik / Bedeu­tung in das Modell, da sich die Ele­men­te auf der glei­chen hori­zon­ta­len Ebe­ne ergänzen

1.3 Darstellungsmöglichkeiten

Die Dar­stel­lung des Vs erfolgt ent­we­der durch Recht­ecke oder Par­al­le­lo­gram­me (Abbil­dung 1.2). Bei­de Dar­stel­lungs­for­men sind gleichwertig.

Darstellungsformen des V-Modells (generell), (C) Peterjohann Consulting, 2020-2024

Abbil­dung 1.2: Dar­stel­lungs­for­men des V‑Modells (gene­rell)

1.4 Das V‑Modell XT

Das V‑Modell XT ist ein Vor­ge­hens­mo­dell für IT-Ent­wick­lungs­pro­jek­te der Behör­den und Ver­wal­tun­gen der Bun­des­re­pu­blik Deutsch­land /#Wiki-V-Modell/. Das V‑Modell XT beschreibt eben­falls ein Vor­ge­hen bei der Erstel­lung von Soft­ware­pro­duk­ten, ist aber eher Pro­jekt­ma­nage­ment-Vor­ge­hens­mo­dell mit vie­len Pro­jekt­ma­nage­ment-Vor­ga­ben. Der Schwer­punkt in die­sem Bei­trag liegt jedoch bei dem der Pro­dukt­ent­wick­lung und ‑erstel­lung, sodass das V‑Modell XT nur gestreift wird.
Zum V‑Modell XT exis­tie­ren umfang­rei­che und voll­stän­dig aus­ge­ar­bei­te­te Doku­men­ta­tio­nen, die unter /#V‑Modell-XT/ zu fin­den sind.

2. Der Einsatz in verschiedenen Themengebieten

Das V‑Modell kann in sehr vie­len Gebie­ten rund um die Pro­dukt­ent­ste­hung zum Ein­satz kom­men. In die­sem Kapi­tel sind eini­ge Bei­spie­le aufgeführt. 

2.1 Software Engineering

Im “klas­si­schen” Soft­ware Engi­nee­ring beschränkt sich das V‑Modell auf den Soft­ware­ent­wick­lungs­pro­zess von der → Anfor­de­rungs­er­mitt­lung bis zum → Abnah­me­test (Abbil­dung 2.1). Dabei wird schritt­wei­se (“von oben nach unten”) der Detail­lie­rungs­grad erhöht. Die zeit­li­che Abfol­ge der ein­zel­nen Vor­gän­ge ergibt sich, indem man ent­lang der bei­den schräg ein­ge­zeich­ne­ten Pfei­le die Vor­gän­ge, begin­nend mit dem → Anfor­de­rungs­ma­nage­ment und endend mit der Gesamt­ab­nah­me, bearbeitet. 

Die Schrit­te im Einzelnen:

  • Requi­re­ments / Anfor­de­run­gen bil­den die Basis für ein Soft­ware­sys­tem und müs­sen daher früh­zei­tig ermit­telt wer­den. Es müs­sen zumin­dest die Anfor­de­run­gen erfasst wer­den, die für die Abnah­me (im Abnah­me­test) not­wen­dig sind
  • Die Sys­tem­spe­zi­fi­ka­ti­on beschreibt das Sys­tem als Gan­zes und stellt ent­spre­chend die Anfor­de­run­gen eines Gesamt­sys­tems zusammen
  • Der Archi­tek­tur­ent­wurf ist eine tech­ni­sche Beschrei­bung, wie das Gesamt­sys­tem auf­ge­baut wer­den soll und defi­niert ins­be­son­de­re die Kom­po­nen­ten und die Schnitt­stel­len zwi­schen den Komponenten
  • Der Kom­po­nen­ten­ent­wurf ver­fei­nert die im Archi­tek­tur­ent­wurf fest­ge­leg­ten Kom­po­nen­ten und legt deren inne­re Struk­tur fest
  • Die Imple­men­tie­rung ist die tech­ni­sche Umset­zung der Soft­ware und kann daher auch als Pro­gram­mie­rung bezeich­net werden
  • Beim Kom­po­nen­ten­test (oder auch Modul- oder Unit-Test) wer­den die ein­zel­nen Kom­po­nen­ten anhand des Kom­po­nen­ten­ent­wurfs getestet
  • Der Inte­gra­ti­ons­test betrach­te­tet meh­re­re Kom­po­nen­ten und deren Zusam­men­spiel (über die fest­ge­leg­ten Schnittstellen)
  • Beim Sys­tem­test wird das Gesamt­sys­tem getestet
  • Beim Abnah­me­test (auch Abnah­me­vor­gang oder kurz Abnah­me) wer­den die Tests aus dem Sys­tem­test ver­wen­det und wei­te­re Tests zur Vali­die­rung hin­zu­ge­fügt, umso eine Gesamt­ab­nah­me durch­zu­füh­ren. In der Regel wer­den auch noch wei­te­re Arte­fak­te bei der Abnah­me über­prüft, so bei­spiels­wei­se Hand­bü­cher oder Qua­li­täts­pro­to­kol­le (wie aus der → FMEA)
Das V-Modell im Software Engineering, (C) Peterjohann Consulting, 2020-2024

Abbil­dung 2.1: Das V‑Modell im Soft­ware Engineering

Anmer­kun­gen:

  • In Abbil­dung 2.1 ist eine zeit­li­che Rei­hen­fol­ge ein­ge­zeich­net. Dies ist aber nicht als Vor­ga­be zu ver­ste­hen: Rück­sprün­ge sind in die­sem V‑Modell erlaubt
  • Statt Ent­wurf wer­den auch die Begrif­fe Design oder Spe­zi­fi­ka­ti­on ver­wen­det: Alle drei Begrif­fe sind (in die­sem Kon­text) syn­onym ein­setz­bar, wobei Spe­zi­fi­ka­ti­on ver­mie­den wer­den soll­te, um Miss­ver­ständ­nis­se zu vermeiden
  • Die in das V ein­ge­zeich­ne­ten Pfei­le reprä­sen­tie­ren auch die → Traces: Die durch­ge­zo­ge­nen Pfei­len sind ver­ti­ka­le, die gepunk­te­ten Pfei­le hori­zon­ta­le Traces
  • Das Tes­ten / der → Soft­ware­test wird unter­teilt in Vali­die­ren und → Veri­fi­zie­ren

2.2 Requirements Engineering

Das V‑Modell kann auch nur für die Requi­re­ments ein­ge­setzt wer­den. Dabei wer­den im lin­ken Zweig die Ver­fei­ne­rungs­stu­fen der Anfor­de­run­gen und im rech­ten Zweig die Soft­ware- oder Sys­tem­ent­wür­fe auf­ge­zeich­net (Abbil­dung 2.2). Als Basis die­nen die drei → Anfor­de­rungs­ty­pen “Busi­ness Requi­re­ments”, “→ Stake­hol­der Requi­re­ments” und “Solu­ti­on Requi­re­ments” (sie­he hier­zu “→ Die Klas­si­fi­ka­ti­on von Anfor­de­run­gen”), die um “Sys­tem Requi­re­ments” — die tech­ni­sche Imple­men­tie­run­gen beschrei­ben — ergänzt werden.

Ein V-Modell für das Requirements Engineering, (C) Peterjohann Consulting, 2021-2024

Abbil­dung 2.2: Ein V‑Modell für das Requi­re­ments Engineering

Anmer­kung:
Ein V‑Modell nur für das Requi­re­ments Engi­nee­ring ist in der Pra­xis sel­ten zu fin­den, da im All­ge­mei­nen nicht der Über­gang von den Requi­re­ments zum Ent­wurf im Vor­der­grund steht, son­dern das Abglei­chen von schrift­lich fixier­ten Anfor­de­run­gen und (in Lösun­gen) umge­setz­ten Anforderungen.

2.3 Systems Engineering

Das Sys­tems Engi­nee­ring bedient sich gene­rell des V‑Modells. In der mini­ma­len Fas­sung nach /GfSE19/ wer­den dabei drei Kom­po­nen­ten betrach­tet (Abbil­dung 2.3):

  1. Ziel­klä­rung: Es muss ein Ziel (für das zu ent­wi­ckeln­de Sys­tem) beschrie­ben werden
  2. Lösungs­su­che: Es wer­den Lösun­gen zur Errei­chung des Ziels gesucht und beschrieben
  3. Bewer­tung: Die Lösun­gen wer­den bewertet

Die drei Kom­po­nen­ten wer­den mehr­fach hin­ter­ein­an­der / “→ ite­ra­tiv” betrach­tet / durch­lau­fen, solan­ge bis eine abschlie­ßen­de Bewer­tung durch­ge­führt wird.

Das minimale V-Modell im Systems Engineering, (C) Peterjohann Consulting, 2020-2024

Abbil­dung 2.3: Das V‑Modell im Sys­tems Engi­nee­ring (mini­mal, nach /GfSE19/)

Auf Basis die­se V‑Modells kön­nen Ver­fei­ne­run­gen / Zer­glie­de­run­gen der drei Kom­po­nen­ten vor­ge­nom­men wer­den, die je nach The­men­schwer­punkt unter­schied­lich aus­fal­len können. 

2.4 Automotive Spice

Im Auto­mo­ti­ve-Spi­ce-Kon­text wird das V‑Modell “dop­pelt” ein­ge­setzt (Abbil­dung 2.4): Das ers­te V wird für das Sys­tem gene­rell (blaue Recht­ecke, obe­rer Bereich), das zwei­te V für das Soft­ware Engi­nee­ring (oran­ge Recht­ecke, unte­rer Bereich) verwendet.

Das V-Modell im Automotive Spice, (C) Peterjohann Consulting, 2020-2024

Abbil­dung 2.4: Das V‑Modell im Auto­mo­ti­ve Spice

Die Kopp­lung der bei­den Bestand­tei­le Sys­tem und Soft­ware Engi­nee­ring ist in Abbil­dung 2.5 wiedergegeben.

Die Kopplung der V-Modelle im Automotive Spice, (C) Peterjohann Consulting, 2022-2024

Abbil­dung 2.5: Die Kopp­lung der V‑Modelle im Auto­mo­ti­ve Spice

2.5 Mechatronische Systeme

Beim VDI (Ver­ein deut­scher Inge­nieu­re) wird ein V‑Modell zur Beschrei­bung der Ent­wick­lung von mecha­tro­ni­schen Sys­te­men als → Richt­li­nie defi­niert, wel­ches die “Ent­wick­lung mecha­tro­ni­scher und cyber-phy­si­schen Sys­te­men” umfasst /#V‑Modell-VDI-2206/.

3. Varianten und Ergänzungen des V‑Modells

Es gibt eine Rei­he von Vari­an­ten und Ergän­zun­gen des V‑Modells. Dabei wer­den wei­te­re Ele­men­te zur Ergän­zung der gra­fi­schen Dar­stel­lung hin­zu­ge­fügt, um bestimm­te Sach­ver­hal­te zu ver­deut­li­chen. Typi­sche Vari­an­ten sind in Abbil­dung 3.1 dargestellt.

Varianten und Ergänzungen des V-Modells, 2022-2024

Abbil­dung 3.1: Vari­an­ten und Ergän­zun­gen des V‑Modells

3.1 Ergänzung um Tätigkeiten und Rollen

In Abbil­dung 3.2 sind den ein­zel­nen Pro­zess­schrit­ten (gene­rel­le) Tätig­kei­ten im Soft­ware Engi­nee­ring (obe­re Rei­he) zuge­ord­net und farb­lich her­vor­ge­ho­ben. Es wer­den hier­bei die fünf Tätig­kei­ten / über­ge­ord­ne­ten Prozessschritte …

  • Ana­ly­se,
  • Design,
  • Imple­men­tie­rung,
  • Test und
  • Abnah­me

ver­wen­det und so unter­teilt, dass sich ein V‑Modell mit neun Ein­zel­tä­tig­kei­ten ergibt.

Das V-Modell im Software Engineering mit Zuordnung von Tätigkeiten, (C) Peterjohann Consulting, 2022-2024

Abbil­dung 3.2: Das V‑Modell im Soft­ware Engi­nee­ring mit Zuord­nung von Tätigkeiten

Anmer­kung:
Statt Abnah­me wird häu­fig der Begriff Betrieb ver­wen­det (sie­he auch Abbil­dung 1.1). Inhalt­lich ist es aber das glei­che: Die­ser Pro­zess­schritt kenn­zeich­net den Über­gang von der Ent­wick­lung in den Betrieb.

Durch Zuord­nung von Rol­len zu den ein­zel­nen Tätig­kei­ten ent­steht ein Gesamt­ein­druck eines Soft­ware­ent­wick­lungs­vor­ha­bens (Abbil­dung 3.3).

Das V-Modell im Software Engineering mit Zuordnung von Tätigkeiten und Rollen, (C) Peterjohann Consulting, 2022-2024

Abbil­dung 3.3: Das V‑Modell im Soft­ware Engi­nee­ring mit Zuord­nung von Tätig­kei­ten und Rollen

Wenn man den Rol­len aus Abbil­dung 3.3 noch → Auf­wän­de und → Dau­ern zuord­net, so kann man die Anzahl der benö­tig­ten Mit­ar­bei­ter (FTE — Full Time Equi­va­lent) in einem → Vor­ha­ben bestim­men (Abbil­dung 3.4).

Das V-Modell im Software Engineering mit Tätigkeiten, Rollen und Aufwänden, (C) Peterjohann Consulting, 2022-2024

Abbil­dung 3.4: Das V‑Modell im Soft­ware Engi­nee­ring mit Tätig­kei­ten, Rol­len und Aufwänden

3.2 Ergänzung um Einzeltätigkeiten

Möch­te man ein­zel­ne Tätig­kei­ten erfas­sen, die zur Unter­stüt­zung des Vor­ge­hens ent­lang eines V‑Modells durch­ge­führt wer­den sol­len, so kön­nen die­se in der V‑Mo­dell-Dar­stel­lung hin­zu­ge­fügt werden.

In Abbil­dung 3.5 sind bei­spiel­haft ergän­zen­de Tätig­kei­ten (aqua­ma­ri­ne Recht­ecke) dar­ge­stellt, die bei der Umset­zung eines Soft­ware­ent­wick­lungs­vor­ha­bens mit dem V‑Modell hilf­reich sind. 

Das V-Modell im Software Engineering mit ergänzenden Tätigkeiten, (C) Peterjohann Consulting, 2022-2024

Abbil­dung 3.5: Das V‑Modell im Soft­ware Engi­nee­ring mit ergän­zen­den Tätigkeiten

In Abbil­dung 3.6 sind die bei­den grund­sätz­li­chen Tätig­kei­ten mit ihren (ver­ti­ka­len) Wir­k­rich­tun­gen dargestellt:

  • Zer­le­gen und spezifizieren
  • Rea­li­sie­ren und integrieren
Das V-Modell mit Wirkrichtungen und Tätigkeiten, (C) Peterjohann Consulting, 2022-2024

Abbil­dung 3.6: Das V‑Modell mit Wir­k­rich­tun­gen und Tätigkeiten

Die gestri­chel­ten Pfei­le deu­ten die mög­li­chen Rück­sprün­ge zwi­schen den Pro­zess­schrit­ten an: Das V‑Modell muss kei­nes­falls line­ar durch­lau­fen wer­den, son­dern erlaubt ein Zurückspringen.

3.3 Ergänzung um Dokumente und Artefakte

Zur Ver­deut­li­chung, wel­che Doku­men­te beim Durch­lau­fen des V‑Modells ent­ste­hen sol­len, kön­nen der Dar­stel­lung ein­zel­ne Doku­men­te und Arte­fak­te gra­fisch hin­zu­ge­fügt werden.

In Abbil­dung 3.7 sind bei­spiel­haft Doku­men­te (grü­ne Recht­ecke mit Wel­len­kan­te) dar­ge­stellt, die sich bei der Umset­zung eines Soft­ware­ent­wick­lungs­vor­ha­bens mit dem V‑Modell erge­ben könnten.

Das V-Modell im Software Engineering mit ergänzenden Dokumenten, (C) Peterjohann Consulting, 2022-2024

Abbil­dung 3.7: Das V‑Modell im Soft­ware Engi­nee­ring mit ergän­zen­den Dokumenten

4. Stärken und Schwächen des Einsatzes eines V‑Modells

Als gene­rel­le Stär­ken und Schwä­chen des Ein­sat­zes eines V‑Modells kön­nen genannt werden:

Stär­ken:

  • Das V‑Modell kann — nach ent­spre­chen­der Erläu­te­rung — schnell zur Klä­rung von Abläu­fen her­an­ge­zo­gen werden
  • Das V‑Modell ist vie­len Per­so­nen bekannt
  • Das V‑Modell ist in eini­gen Nor­men und Stan­dards verankert
  • In regu­la­to­ri­schen Umfel­dern (wie der Medi­zin­tech­nik oder im Auto­mo­ti­ve-Kon­text) kann das V‑Modell zur Qua­li­täts­si­che­rung her­an­ge­zo­gen werden
  • Das V‑Modell ergänzt gut die “klas­si­schen” Pro­dukt­ent­ste­hungs­pro­zes­se (PEPs), die häu­fig im Maschi­nen­bau anzu­tref­fen sind
  • Die FMEA passt gut zum V‑Modell: Bei­de Ansät­ze betrach­ten Sys­te­me → Top-down und haben die → Qua­li­tät im Fokus

Schwä­chen:

  • Das V‑Modell unter­teilt rela­tiv starr ein Vor­ge­hen in ein­zel­ne Blöcke
  • Das V‑Modell wird von vie­len Per­so­nen abge­lehnt, da es als “Ein­stieg in die Büro­kra­tie” gese­hen wird
  • Wenn das V‑Modell nur als rein theo­re­ti­sche Betrach­tung gese­hen wird, ver­fehlt es sei­ne Wirkung

5. Häufige Fragen und Antworten zum V‑Modell

Eini­ge Fra­gen zum V‑Modell wer­den häu­fig gestellt – die­se wer­den hier wiedergegeben.

  • F: Müs­sen Lizenz­ge­büh­ren für die Ver­wen­dung des V‑Modells gezahlt wer­den?
    A: Nein. Die Nut­zung des V‑Modells ist kos­ten­frei — ins­be­son­de­re, da es kein all­ge­mei­nes V‑Modell gibt.
  • F: Ist das V‑Modell noch “zeit­ge­mäß” und hat noch eine Rele­vanz?
    A: Ja. Gera­de vor dem Hin­ter­grund der → Digi­ta­li­sie­rung und der Ver­bin­dung von Hard- und Soft­ware beim Inter­net of Things (IOT) kann das V‑Modell hel­fen, die Abläu­fe, Schnitt­stel­len und Ver­ant­wort­lich­kei­ten zu erken­nen und auszugestalten.
  • F: Ist das V‑Modell auch inter­na­tio­nal bekannt (und ein­setz­bar)?
    A: Ja und nein. Das V‑Modell ist im deutsch­spra­chi­gen Raum ver­brei­tet und wird bei vie­len Engi­nee­ring-Fir­men ein­ge­setzt. Inter­na­tio­nal sieht das durch­aus anders aus: Dort ist im Auto­mo­ti­ve-Umfeld das V‑Modell nach Auto­mo­ti­ve Spi­ce bekannt, dar­über hin­aus fin­det das V‑Modell eher sel­ten Anwendung.
  • F: Muss man bei agi­ler Vor­ge­hens­wei­se (Agi­les RE) das V‑Modell berück­sich­ti­gen?
    A: Es kommt dar­auf an. Um hohe Qua­li­tät bei der Umset­zung eines Sys­tems nach­zu­wei­sen, kommt man kaum am V‑Modell vorbei.

Haben Sie noch wei­te­re Fra­gen oder möch­ten Sie Ergän­zun­gen an der FAQ vor­neh­men? Am bes­ten schrei­ben Sie mir hier­zu eine E‑Mail an: kontakt@peterjohann-consulting.de.

A. Präsentationen, Literatur und Weblinks

Das V‑Modell ist eine Grund­la­ge für das Requi­re­ments Engi­nee­ring, wel­ches in der hier auf­ge­führ­ten Prä­sen­ta­ti­on beschrie­ben wird.

Inhalt Typ
Requi­re­ments Engi­nee­ring (und Busi­ness Ana­ly­sis) – Eine Ein­füh­rung (RE-Basis­prä­sen­ta­ti­on)
pdf

In fol­gen­den Büchern wird als Teil­aspekt das V‑Modell erläutert:

  • /Ebert19/ Chris­tof Ebert: Sys­te­ma­ti­sches Requi­re­ments Engi­nee­ring. Anfor­de­run­gen ermit­teln, doku­men­tie­ren, ana­ly­sie­ren und ver­wal­ten, dpunkt, Hei­del­berg 6. Auf­la­ge 2019, ISBN 978–3‑86490–562‑9
  • /Ebert22/ Chris­tof Ebert: Sys­te­ma­ti­sches Requi­re­ments Engi­nee­ring. Anfor­de­run­gen ermit­teln, doku­men­tie­ren, ana­ly­sie­ren und ver­wal­ten, dpunkt, Hei­del­berg 7. Auf­la­ge 2022, ISBN 978–3‑86490–919‑1
  • /GfSE19/ sie­he /Zuccaro19/
  • /Kuhrmann11/ Mar­co Kuhr­mann, Tho­mas Ter­ni­té, Jan Fried­rich: Das V‑Modell XT anpas­sen: Anpas­sung und Ein­füh­rung kom­pakt für V‑Modell XT Pro­zes­s­in­ge­nieu­re, Sprin­ger, Ber­lin 2011, ISBN 978–3‑642–01489‑5
  • /Pfeifer21/ Tilo Pfei­fer, Robert Schmitt: Masing Hand­buch → Qua­li­täts­ma­nage­ment, Han­ser, Mün­chen 7. Auf­la­ge 2021, ISBN 978–3‑446–46230‑4
  • /Zuccaro19/ Clau­dio Zuc­ca­ro, Jür­gen Ram­bo, Han­nes Hüf­fer, Johan­nes Fritz, Thad­dä­us Dorsch: GfSE SE-Hand­buch. Die Klam­mer in der tech­ni­schen Ent­wick­lung, GfSE – Gesell­schaft Für Sys­tems Engi­nee­ring, Bre­men 2017, ISBN 978–3‑9818805–6‑4

Auf fol­gen­de Web­links zum V‑Modell wird in die­sem Bei­trag Bezug genommen:

Legen­de zu den Weblinks
/ / Ver­weis auf eine Web­site (all­ge­mein)
/*/ Ver­weis auf eine Web­site, die als Ergän­zung zu einem Buch dient
/#/ Ver­weis auf ein ein­zel­nes The­ma auf einer Website
/#V/ Ver­weis auf ein Video auf einer Website