SlideShare ist ein Scribd-Unternehmen logo
1 von 4
Downloaden Sie, um offline zu lesen
- 1 -
V-Modelle – sie sind mitten unter uns
Immer wieder finde ich mich in Beratungsprojekten als Bestandteil
einer Diskussion über das V-Modell wieder. Dabei geht es entweder
um die Glaubensfrage „V-Modell oder Scrum?“ oder um Unschärfen
im Verständnis darüber, was das V-Modell mit der eigenen Arbeit in
der Produktentwicklung zu tun hat. Grund genug, hier eine Lanze
für das V-Modell zu brechen – zumindest für das, was ich darunter
verstehe. Aus meiner Sicht folgt die Entwicklung immer einem V-
Modell. Die Frage, ob V-Modell und Scrum vereinbar sind, geht für
mich daher am Ziel vorbei. Vielmehr können Gedanken über das
eigene V-Modell dazu beitragen, die eigenen Engineering-Praktiken
auf eine neue, reifere Stufe zu heben.
Was ist das V-Modell?
Klären wir zunächst einmal, was
im üblichen Sprachgebrauch unter
„V-Modell“ verstanden wird. Meis-
tens steht dieses Verständnis näm-
lich im Widerspruch zu der Vielfalt
von V-Modellen und Definitionen,
die es dort draußen gibt. Falls Sie
sich für die Historie des V-Modells
interessieren, finden Sie dazu reich-
lich Informationen im Internet, ich
möchte diesen Aspekt hier bewusst
kurz halten.
Zum ersten Mal taucht ein V-Mo-
dell in den 1970er-Jahren in der
Softwareentwicklung auf. Darin
wurden verschiedene Tätigkeiten
des Software Engineerings in Zu-
sammenhang gesetzt, insbesondere
die Zerlegung eines Systems in Un-
terkomponenten, die anschließen-
de Integration der Komponenten
zu einem System sowie die Bezie-
hungen zwischen Definitions- und
Testtätigkeiten.
Darauf aufbauend definierte die
Bundesregierung in den 1980er-
Jahren einen Entwicklungsstandard
für Softwareprojekte, der für die
Auftragnehmer staatlicher Aufträge
verpflichtend wurde. Dies ist also
eine andere Definition des V-Mo-
dells: das – zumindest in Deutsch-
land – offizielle V-Modell (die Bun-
desrepublik Deutschland ist auch
Inhaberin der Marke „V-Modell“).
Das V-Modell der Bundesregierung
wurde in mehreren Stufen den neu-
en Erkenntnissen und Strömungen
im Engineering angepasst und exis-
tiert heute (2020) als V-Modell XT,
das auch agile Ansätze berücksich-
tigt.
Abseits der staatlichen Vorschrif-
ten ist der Ansatz des V-Modells
auch in verschiedene andere Nor-
men und Standards eingeflossen.
So nehmen zum Beispiel zwei in der
Automobilindustrie wichtige Stan-
dards – Automotive und ISO 26262
– ebenfalls Anleihen am V-Modell.
In diesem Dokument möchte
ich jedoch Prozessdefinitionen und
Normen beiseitelassen und mich
auf die Denkweise hinter dem V-
Modell konzentrieren.
Ein atomares V-Modell
Das V-Modell heißt so, weil die
Engineering-Tätigkeiten geomet-
risch in der Form eines V angeord-
net werden. Dadurch lassen sich die
Zusammenhänge zwischen den Tä-
tigkeiten leichter beschreiben. Ge-
nerell beschreibt der linke Schenkel
des V die Definition, die Spitze des
V den Bau und der rechte Schenkel
den Test eines Systems. Für mich
besteht ein generisches V-Modell
also aus den drei Aspekten „den-
ken“, „bauen“, und „testen“. Die-
ses Konzept ist universell und tritt
überall in unserem Alltag auf, egal
ob Sie sich etwas Leckeres zu essen
kochen, ich diesen Artikel schreibe
oder Sie Ihr Produkt entwickeln. Es
geht immer darum, sich etwas zu
überlegen, es umzusetzen und die
Ergebnisse zu begutachten.
Dieses generische V-Modell trifft
keine Aussage über Umfang und
Dokumentation dieser drei Schrit-
te. Ob beim Kochen, beim Schrei-
ben, bei der Produktentwicklung
oder bei einer anderen Tätigkeit:
Die Schritte „denken“ und „bauen“
können nach außen hin zwar gleich-
zeitig wirken, genau genommen ha-
ben Sie aber eine Sekunde, bevor
Sie das Ei in die Pfanne gehauen
haben, unbewusst eine Erwartungs-
haltung an das Endergebnis im
Kopf und Sie haben das Vorgehen
definiert. Auch ein Softwareent-
wickler, der einfach seinen Editor
öffnet und Code schreibt, folgt dem
Muster denken-bauen-testen.
Sie werden jetzt sagen: „In die-
ser Darstellung macht es sich Kol-
lege Pfeffer zu einfach, denn die
Aspekte der Dekomposition und
Integration werden hier nicht be-
rücksichtigt.“ Auch wenn die uns
bekannten Interpretationen des V-
Modells in der Software-und Sys-
tementwicklung eine solche Kom-
position vorsehen, bin ich dennoch
der Meinung, dass auch ein wie von
mir beschriebenes minimales V ein
Joachim Pfeffer
Menschen. Entwickeln. Produkte.
denken
bauen
testen
Bild 1: atomares V-Modell
- 2 -
V-Modell ist. Es zeigt bereits die
horizontale Verbindung zwischen
bauen und testen auf.
Dieser horizontale Zusammen-
hang zwischen linker und rechter
Seite des V ist nach meiner Erfah-
rung nicht allen Anwendern des
Modells bewusst: Wer sich ein tech-
nisches System, ein Spiegelei, oder
einen Blog-Artikel ausdenkt, trägt
damit automatisch die Verantwor-
tung, auch den Test und die Test-
barkeit des Vorhabens sicherzustel-
len. Dies mag im Rahmen meines
Beispiels mit dem Ei noch am ein-
fachsten sein. Doch schon beim
Blogartikel muss ich mir im Vorfeld
Gedanken machen, wie ich sicher-
stelle, dass er so aussieht, wie ich
mir das vorgestellt habe und auf al-
len Browsern läuft. Bei Ihrem tech-
nischen System müssen Sie noch
viel mehr Gedanken in Testkonzep-
te und die Testbarkeit der Anforde-
rungen investieren. Das sollten Sie
nicht erst beim Test machen, son-
dern schon während Sie die Anfor-
derung an das System festlegen.
Handelsübliche V-Modelle
Auch an dieser Zwischenüber-
schrift können Sie erkennen: Sofern
Sie nicht gerade ein Softwareprojekt
für die Bundesrepublik Deutsch-
land basteln, gibt es nicht das V-
Modell. Unter einem üblichen V-
Modell verstehe ich, dass sich die
oben erwähnte Dekomposition
eines Systems auch in der Beschrei-
bung und dem Zusammenhang der
Tätigkeiten widerspiegelt.
Dadurch besteht ein solches Mo-
dell aus mindestens zwei Ebenen.
Ganz oben steht – wie Sie wahr-
scheinlich schon vermutet haben
– das Gesamtsystem. Dieses zer-
fällt auf der zweiten Ebene in die
Hauptkomponenten der Systemar-
chitektur. Auch eine Hauptkompo-
nente könnte wieder in weitere Un-
terkomponenten zerfallen, dadurch
würde sich ein Modell mit drei Ebe-
nen ergeben. Sie könnten dies mit
beliebig vielen Ebenen fortsetzen,
um die Zusammenhänge zu be-
schreiben, erkläre ich hier jedoch
ein einfaches Modell, in dem die
Systemebene in lediglich eine weite-
re Komponentenebene zerfällt. Das
Interessante hierbei ist, dass in ei-
ner solchen Denkweise jede Ebene
nach demselben Muster aufgebaut
ist – das Modell ist also fraktal.
Auf der linken Seite des V, also
auf der Seite der Spezifikation und
der Dekomposition, werden für
jede Ebene Anforderungen erstellt.
Auf der Systemebene sind das die
Systemanforderungen, auf Kom-
ponentenebene sind dies Anforde-
rungen an die jeweilige Komponen-
te.
Anforderungen beschreiben im-
mer das „Was“. Sie beschreiben also
eine Blackbox-Sicht ohne Rücksicht
auf das Innenleben der jeweiligen
Ebene. Aus den Anforderungen
wird für jede Ebene ein techni-
sches Konzept abgeleitet. Das ist
die Whitebox-Sicht, die das „Wie“
beschreibt. Aus den Systemanfor-
derungen wird also eine System-
architektur abgeleitet, mit der die
Komponenten des Systems sowie
deren Interaktion definiert werden.
Die Systemarchitektur liefert damit
einen wesentlichen Anteil für die
Anforderungen an die Kompo-
nenten (wiederum Blackbox-Sicht).
Ebenso gibt es für jede Kompo-
nente wieder eine technische Be-
schreibung des Innenlebens, meist
als Komponentenarchitektur oder
Komponentendesign bezeichnet.
Damit bin ich in diesem Zwei-
Ebenen-Beispiel an der Spitze des
V angelangt, an der die Spezifikatio-
nen und Konzepte in ein Produkt
umgesetzt werden. Die Umsetzung
geschieht auf der niedrigsten spezi-
fizierten Ebene, in diesem Beispiel
werden also die einzelnen Archi-
tekturelemente der Komponenten
gebaut.
Sobald dies geschehen ist, ge-
winnt die rechte Seite des V-Mo-
dells an Bedeutung. Sie steht für
Integration und Test. Auf Kompo-
nentenebene werden nun die gefer-
tigten Einzelteile zu einer Kompo-
nente zusammengesetzt (integriert)
und danach wird jede Komponente
für sich getestet. Integration und
Test entsprechen dabei den links
gegenüberliegenden Ebenen „Ar-
chitektur“ und „Anforderungen“.
Beim Zusammenbau, also bei der
Integration, kann zum ersten Mal
getestet werden, ob die Interak-
tion der Einzelteile den Vorgaben
der Architektur entspricht (Whi-
tebox). Danach wird im Test der
Komponente sichergestellt, dass
die Komponente die an sie gestell-
ten Anforderungen erfüllt (Black-
box). Gemäß dem fraktalen Ansatz
wiederholt sich dieses Spiel auf der
darüber liegenden Systemebene: In
der Systemintegration wird die In-
teraktion der Systemkomponenten
getestet, das integrierte System wird
dann gegen die Systemanforderun-
gen getestet. Damit steht, egal auf
welcher Ebene, den Anforderungen
auf der linken Seite des V immer ein
Blackbox-Text auf der rechten Sei-
te gegenüber. Einem technischen
Konzept bzw. einer Architektur auf
der linken Seite stehen eine Integ-
ration und ein Integrationstest auf
der rechten Seite gegenüber.
System-
anforderungen
System-
architektur
Komponenten-
anforderungen
Komponenten-
design
Bau /
Beschaffung
Komponenten-
integra�onstest
SystemKomponenten
Komponenten-
test
System-
integra�onstest
Systemtest
Bild 2: V-Modell mit zwei Ebenen
- 3 -
Zusammenspiel der Aktivitäten
Ein V-Modell beschreibt also zu-
nächst Aktivitäten und Zusammen-
hänge. Es beschreibt nicht, ob diese
in definierten Prozessen abgearbei-
tet und schriftlich dokumentiert
werden, oder ob dies alles im Kopf
talentierter Entwickler geschieht.
Das Zusammenspiel der Aktivi-
täten ist für mich ein wesentlicher
Punkt: Gerade hier erlebe ich in der
Praxis oft eine unzureichende Inter-
pretation des V-Gedankens. Zum
einen möchte ich kurz auf das Prin-
zip der Traceability, also der Nach-
verfolgbarkeit von Anforderungen,
eingehen – zum anderen geht es
mir um das, was ich „horizontale
Verantwortung“ nenne.
Mit Ihrem Kunden reden Sie
auf der Ebene der Systemanforde-
rungen. Vielleicht war es auch Ihr
Kunde, der diese aufgestellt hat. In
Ihrem Entwicklungsablauf müs-
sen Sie für sich nachweisen, dass
alle Anforderungen umgesetzt und
auch getestet wurden. Diese Nach-
verfolgbarkeit wird als „Traceabili-
ty“ bezeichnet. Dabei gibt es zwei
Achsen: Die vertikale Traceability
weist nach, dass alle Anforderun-
gen in der Produktentwicklung be-
rücksichtigt wurden, also welche
Anforderungen durch welche Ar-
chitekturelemente, Komponenten
und Bauteile umgesetzt werden. Bei
Software zieht sich das von der Sys-
temebene bis auf die entsprechen-
de Code-Zeile. Die horizontale Tra-
ceability weist nach, ob es zu jeder
Anforderung auf der entsprechen-
den Ebene auch Testfälle gibt, um
die Umsetzung der Anforderung
verifizieren zu können.
Im zweiten Schritt müssen auch
die Ergebnisse durchgeführter
Tests (Testreports) mit den entspre-
chenden Testfällen in Beziehung
gesetzt werden. Damit weisen Sie
nach, dass jede Anforderung auch
wirklich getestet wurde. Die Ver-
waltung von Traceability ist in der
Regel nur mit entsprechenden Soft-
ware-Werkzeugen möglich. Da sich
alle Dokumente im Entwicklungs-
prozess regelmäßig ändern, ist es
nur so möglich, die Traceability
nachweisen zu können.
Der Grundgedanke in einem V-
Modell ist, dass auf der Achse der
horizontalen Traceability links die
Grundlagen für die jeweils gegen-
überliegende Aktivität auf der rech-
ten Seite geschaffen werden. Wer
Anforderungen aufschreibt, hat
auch die Verantwortung, dass diese
getestet werden können und dass
grundlegende Testkonzepte vorlie-
gen.
Ebenso haben die Architekten
links im V die Verantwortung, die
Reihenfolge für die Integration vor-
zuschlagen und die Grundlagen
für den Integrationstest zu legen.
Dies kann auch beinhalten, dass
die Architektur Elemente oder
Schnittstellen enthält, die nicht
der Erfüllung der Anforderungen,
sondern der Testbarkeit dienen
(z. B. zusätzliche Messpunkte oder
Schnittstellen). Jede Konzeptstu-
fe im V-Modell trägt also auch die
Verantwortung für die zugehörige
Teststufe rechts im V. Diese, wie ich
sie nenne, „horizontale Verantwor-
tung“ im V-Modell ist in der Praxis
nicht immer anzutreffen. Oft wer-
den die Aktivitäten auf den beiden
Seiten des V strikt getrennt.
Scrum im V-Modell
Jeder Sprint in Scrum entspricht
einem klassischen Projektdurchlauf
mit Planung, Review und Lessons
Learned. Am Ende jedes Sprints
steht ein fertig getestetes und do-
kumentiertes Produktinkrement. In
jedem Sprint wird also einmal das
entsprechende V der Produktent-
wicklung durchlaufen. Die Tätig-
keiten, die in einem V-Modell defi-
niert sind, können dabei beliebig oft
iteriert werden, interagieren oder
parallelisiert werden. Jedes Scrum
Team arbeitet also implizit mit ei-
nem V-Modell.
Die Frage, inwiefern Scrum und
V-Modell zusammenpassen, ent-
steht meistens durch die Existenz
starr definierter Prozesslandschaf-
ten, die auf dem V-Gedanken ba-
sieren. Diese sind darauf ausgelegt,
dass ein Durchlauf des V, also ein
Entwicklungszyklus, viele Monate
oder gar Jahre benötigt. Entspre-
chend umfangreich sind die im Pro-
zess hinterlegten Anforderungen an
die Dokumentation des Vorgehens.
Nicht selten entspringen diese dem
Teufelskreis der Produktentwick-
lung: „Management macht unrealis-
System-
anforderungen
System-
architektur
Komponenten-
anforderungen
Komponenten-
design
Bau /
Beschaffung
Komponenten-
integra�onstest
horizontale
Traceability
vertikale
Traceability
Komponenten-
test
System-
integra�onstest
Systemtest Testreports
Testreports
Testreports
Testreports
Bild 3: V-Modell mit Traceability
- 4 -
tische Vorgaben, Entwicklung ver-
sucht diese unter Qualitätseinbußen
zu erfüllen, Management macht
wegen der schlechten Qualität
mehr Vorgaben zu Dokumentation
und Kontrolle, Zeitvorgaben wer-
den wegen zusätzlichem Overhead
noch unrealistischer.“ Um solche
gewachsenen Monster-V-Prozess-
modelle mit Scrum vereinbar zu
machen, muss der Prozess Stück für
Stück entschlackt werden, Checklis-
ten müssen durch Vertrauen und
Wunschdenken durch Transparenz
ersetzt werden. Dazu müssen gro-
ße Anstrengungen unternommen
werden, um Aktivitäten auf beiden
Seiten des V-Modells maximal zu
automatisieren. Nur so kann das V
irgendwann in einen Sprint passen.
Sie werden nun einwenden, dass
es bei der Entwicklung von phy-
sischen Produkten – dem natürli-
chen Lebensraum von V-Modellen
– nicht immer möglich ist, einen
Durchlauf des V in einen Sprint
zu bekommen. Das ist richtig. In
einem solchen Fall haben Sie zwei
Möglichkeiten.
Die erste (und häufig angewende-
te) Möglichkeit ist, erst ab einer be-
stimmten Ebene mit agilen Sprints
zu beginnen. In diesem Fall haben
Sie einen nicht-agilen Vor- und
Nachspann im V-Durchlauf (oft
auch als Hybrider Ansatz bezeich-
net). Die agilen Korrekturmöglich-
keiten beziehen sich nur auf die
Umsetzung, nicht auf Spezifikation
und Test, und bleiben also in einem
überschaubaren Rahmen. Inwiefern
dies noch agil ist, müssen Sie selbst
beurteilen.
Die zweite und zugleich agile-
re Möglichkeit ist, die agile Lern-
schleife von Wochen auf Monaten
auszudehnen. Ein kompletter V-
Durchlauf in drei Monaten ist bei
vielen Systemen realistisch, wenn
die einschlägigen Impediments wie
Einkaufs-, QM- und Musterbau-
prozesse angegangen werden.
Vorschläge
Egal, was Sie entwickeln und wie
Sie es entwickeln: Stellen Sie sich die
Tätigkeiten in einem V vor. Schaf-
fen Sie auf der linken Seite im V die
Grundlagen für alle Schritte auf der
rechten Seite. Dies erhöht die Ge-
schwindigkeit und verringert das
Risiko bei Ihrem Entwicklungsvor-
haben. Falls Sie die Prozesse, Tem-
plates und Checklisten für Ihr V-
Modell definiert haben, prüfen Sie
diese auf Notwendigkeit und Sinn-
haftigkeit. Dies hilft Ihnen schnel-
ler durch das V zu kommen, wenn
Sie agile Ansätze verwenden. Er-
liegen Sie nicht der Versuchung der
hybriden Ansätze, nur weil das im
Moment einfacher erscheint. Wenn
Ihnen ein hybrider Ansatz plausibel
und nützlich erscheint, überlegen
Sie, ob agiles Arbeiten für Sie über-
haupt Vorteile bringt. Wenn Sie hin-
gegen agil arbeiten möchten, arbei-
ten Sie darauf hin, das V in einem
festen Takt von wenigen Monaten
durchlaufen zu können. Regelmäßi-
ge Durchläufe des Entwicklungs-Vs
und die ständige Verbesserung der
Organisation machen Agilität aus,
auch wenn die Durchläufe zu Be-
ginn der Veränderung noch Monate
dauern. Arbeitspakete hingegen in-
mitten eines starren Projektplans
mit unveränderten Prozessen im
Takt von zwei Wochen abzuarbei-
ten und mit Zetteln an der Wand zu
visualisieren, ist vielleicht nützlich,
aber nicht agil.
Autor
Joachim Pfeffer ist Experte in der agi-
len Produktentwicklung für physische
Produkte. Seit vielen Jahren berät er Un-
ternehmen in der Automobilindustrie und
im Maschinenbau, um mit ihnen schlag-
kräftige Entwicklungsabläufe in einer zu-
nehmend komplexen Welt zu entwerfen.
Dabei arbeitet er mit Scrum und Kanban,
angereichert mit Konzepten aus dem Lean
Development und der Engpasstheorie.
Veröffentlicht am 27.01.2020
auf joachim-pfeffer.com
JoachimPfeffer
Produktentwicklung
Lean&Agile
324Seiten
59,99€
ISBN:
978-3-446-45908-3
Mehr zu Scrum im V-Modell

Weitere ähnliche Inhalte

Ähnlich wie V-Modelle - sie sind mitten unter uns

Metamodellierung und Validierung
Metamodellierung und ValidierungMetamodellierung und Validierung
Metamodellierung und Validierung
foobar2605
 
Sdv 0405 design-pattern_thc_jps_skript
Sdv 0405 design-pattern_thc_jps_skriptSdv 0405 design-pattern_thc_jps_skript
Sdv 0405 design-pattern_thc_jps_skript
Tomasz Waszczyk
 
Sdv 0405 design-pattern_thc_jps_skript
Sdv 0405 design-pattern_thc_jps_skriptSdv 0405 design-pattern_thc_jps_skript
Sdv 0405 design-pattern_thc_jps_skript
Tomasz Waszczyk
 
Artikel-ModelAudit-2016-05
Artikel-ModelAudit-2016-05Artikel-ModelAudit-2016-05
Artikel-ModelAudit-2016-05
Torsten Röhner
 
Pruefung iu k-2009
Pruefung iu k-2009Pruefung iu k-2009
Pruefung iu k-2009
skoller15
 
Flash cs3, ajax und php
Flash cs3, ajax und phpFlash cs3, ajax und php
Flash cs3, ajax und php
sameerpclab1
 
Sendung 17-11: News-Ausgabe
Sendung 17-11: News-AusgabeSendung 17-11: News-Ausgabe
Sendung 17-11: News-Ausgabe
Thomas Maier
 

Ähnlich wie V-Modelle - sie sind mitten unter uns (17)

Metamodellierung und Validierung
Metamodellierung und ValidierungMetamodellierung und Validierung
Metamodellierung und Validierung
 
Wie Sie durchgängige Produktdaten über den Prozess sicherstellen
Wie Sie durchgängige Produktdaten über den Prozess sicherstellenWie Sie durchgängige Produktdaten über den Prozess sicherstellen
Wie Sie durchgängige Produktdaten über den Prozess sicherstellen
 
Sdv 0405 design-pattern_thc_jps_skript
Sdv 0405 design-pattern_thc_jps_skriptSdv 0405 design-pattern_thc_jps_skript
Sdv 0405 design-pattern_thc_jps_skript
 
Sdv 0405 design-pattern_thc_jps_skript
Sdv 0405 design-pattern_thc_jps_skriptSdv 0405 design-pattern_thc_jps_skript
Sdv 0405 design-pattern_thc_jps_skript
 
Kooperative VR - Collaborative Virtual Engineering: VDC-Whitepaper
Kooperative VR - Collaborative Virtual Engineering: VDC-WhitepaperKooperative VR - Collaborative Virtual Engineering: VDC-Whitepaper
Kooperative VR - Collaborative Virtual Engineering: VDC-Whitepaper
 
SQL Developer 4.x - Tipps für "faule" Entwickler
SQL Developer 4.x - Tipps für "faule" EntwicklerSQL Developer 4.x - Tipps für "faule" Entwickler
SQL Developer 4.x - Tipps für "faule" Entwickler
 
TAG2015: ArchiteKultur – wie bekommen wir Architekturarbeit in den Alltag rei...
TAG2015: ArchiteKultur – wie bekommen wir Architekturarbeit in den Alltag rei...TAG2015: ArchiteKultur – wie bekommen wir Architekturarbeit in den Alltag rei...
TAG2015: ArchiteKultur – wie bekommen wir Architekturarbeit in den Alltag rei...
 
UPDATED USER GUIDE for the Final WeGov Toolbox 3.0: “Was ist WeGov?”(in German)
UPDATED USER GUIDE for the Final WeGov Toolbox 3.0: “Was ist WeGov?”(in German)UPDATED USER GUIDE for the Final WeGov Toolbox 3.0: “Was ist WeGov?”(in German)
UPDATED USER GUIDE for the Final WeGov Toolbox 3.0: “Was ist WeGov?”(in German)
 
WYSIWYG-Editoren (für Drupal 7)
WYSIWYG-Editoren (für Drupal 7)WYSIWYG-Editoren (für Drupal 7)
WYSIWYG-Editoren (für Drupal 7)
 
Net@night asp.net mvc
Net@night asp.net mvcNet@night asp.net mvc
Net@night asp.net mvc
 
Composite Simulation Roadmap
Composite Simulation RoadmapComposite Simulation Roadmap
Composite Simulation Roadmap
 
Artikel-ModelAudit-2016-05
Artikel-ModelAudit-2016-05Artikel-ModelAudit-2016-05
Artikel-ModelAudit-2016-05
 
Produktvarianten mit SysML/UML modellieren
Produktvarianten mit SysML/UML modellierenProduktvarianten mit SysML/UML modellieren
Produktvarianten mit SysML/UML modellieren
 
Pruefung iu k-2009
Pruefung iu k-2009Pruefung iu k-2009
Pruefung iu k-2009
 
Flash cs3, ajax und php
Flash cs3, ajax und phpFlash cs3, ajax und php
Flash cs3, ajax und php
 
Was ist WeGov? Toolbox 3.0 Benutzungshandbuch
Was ist WeGov? Toolbox 3.0 BenutzungshandbuchWas ist WeGov? Toolbox 3.0 Benutzungshandbuch
Was ist WeGov? Toolbox 3.0 Benutzungshandbuch
 
Sendung 17-11: News-Ausgabe
Sendung 17-11: News-AusgabeSendung 17-11: News-Ausgabe
Sendung 17-11: News-Ausgabe
 

V-Modelle - sie sind mitten unter uns

  • 1. - 1 - V-Modelle – sie sind mitten unter uns Immer wieder finde ich mich in Beratungsprojekten als Bestandteil einer Diskussion über das V-Modell wieder. Dabei geht es entweder um die Glaubensfrage „V-Modell oder Scrum?“ oder um Unschärfen im Verständnis darüber, was das V-Modell mit der eigenen Arbeit in der Produktentwicklung zu tun hat. Grund genug, hier eine Lanze für das V-Modell zu brechen – zumindest für das, was ich darunter verstehe. Aus meiner Sicht folgt die Entwicklung immer einem V- Modell. Die Frage, ob V-Modell und Scrum vereinbar sind, geht für mich daher am Ziel vorbei. Vielmehr können Gedanken über das eigene V-Modell dazu beitragen, die eigenen Engineering-Praktiken auf eine neue, reifere Stufe zu heben. Was ist das V-Modell? Klären wir zunächst einmal, was im üblichen Sprachgebrauch unter „V-Modell“ verstanden wird. Meis- tens steht dieses Verständnis näm- lich im Widerspruch zu der Vielfalt von V-Modellen und Definitionen, die es dort draußen gibt. Falls Sie sich für die Historie des V-Modells interessieren, finden Sie dazu reich- lich Informationen im Internet, ich möchte diesen Aspekt hier bewusst kurz halten. Zum ersten Mal taucht ein V-Mo- dell in den 1970er-Jahren in der Softwareentwicklung auf. Darin wurden verschiedene Tätigkeiten des Software Engineerings in Zu- sammenhang gesetzt, insbesondere die Zerlegung eines Systems in Un- terkomponenten, die anschließen- de Integration der Komponenten zu einem System sowie die Bezie- hungen zwischen Definitions- und Testtätigkeiten. Darauf aufbauend definierte die Bundesregierung in den 1980er- Jahren einen Entwicklungsstandard für Softwareprojekte, der für die Auftragnehmer staatlicher Aufträge verpflichtend wurde. Dies ist also eine andere Definition des V-Mo- dells: das – zumindest in Deutsch- land – offizielle V-Modell (die Bun- desrepublik Deutschland ist auch Inhaberin der Marke „V-Modell“). Das V-Modell der Bundesregierung wurde in mehreren Stufen den neu- en Erkenntnissen und Strömungen im Engineering angepasst und exis- tiert heute (2020) als V-Modell XT, das auch agile Ansätze berücksich- tigt. Abseits der staatlichen Vorschrif- ten ist der Ansatz des V-Modells auch in verschiedene andere Nor- men und Standards eingeflossen. So nehmen zum Beispiel zwei in der Automobilindustrie wichtige Stan- dards – Automotive und ISO 26262 – ebenfalls Anleihen am V-Modell. In diesem Dokument möchte ich jedoch Prozessdefinitionen und Normen beiseitelassen und mich auf die Denkweise hinter dem V- Modell konzentrieren. Ein atomares V-Modell Das V-Modell heißt so, weil die Engineering-Tätigkeiten geomet- risch in der Form eines V angeord- net werden. Dadurch lassen sich die Zusammenhänge zwischen den Tä- tigkeiten leichter beschreiben. Ge- nerell beschreibt der linke Schenkel des V die Definition, die Spitze des V den Bau und der rechte Schenkel den Test eines Systems. Für mich besteht ein generisches V-Modell also aus den drei Aspekten „den- ken“, „bauen“, und „testen“. Die- ses Konzept ist universell und tritt überall in unserem Alltag auf, egal ob Sie sich etwas Leckeres zu essen kochen, ich diesen Artikel schreibe oder Sie Ihr Produkt entwickeln. Es geht immer darum, sich etwas zu überlegen, es umzusetzen und die Ergebnisse zu begutachten. Dieses generische V-Modell trifft keine Aussage über Umfang und Dokumentation dieser drei Schrit- te. Ob beim Kochen, beim Schrei- ben, bei der Produktentwicklung oder bei einer anderen Tätigkeit: Die Schritte „denken“ und „bauen“ können nach außen hin zwar gleich- zeitig wirken, genau genommen ha- ben Sie aber eine Sekunde, bevor Sie das Ei in die Pfanne gehauen haben, unbewusst eine Erwartungs- haltung an das Endergebnis im Kopf und Sie haben das Vorgehen definiert. Auch ein Softwareent- wickler, der einfach seinen Editor öffnet und Code schreibt, folgt dem Muster denken-bauen-testen. Sie werden jetzt sagen: „In die- ser Darstellung macht es sich Kol- lege Pfeffer zu einfach, denn die Aspekte der Dekomposition und Integration werden hier nicht be- rücksichtigt.“ Auch wenn die uns bekannten Interpretationen des V- Modells in der Software-und Sys- tementwicklung eine solche Kom- position vorsehen, bin ich dennoch der Meinung, dass auch ein wie von mir beschriebenes minimales V ein Joachim Pfeffer Menschen. Entwickeln. Produkte. denken bauen testen Bild 1: atomares V-Modell
  • 2. - 2 - V-Modell ist. Es zeigt bereits die horizontale Verbindung zwischen bauen und testen auf. Dieser horizontale Zusammen- hang zwischen linker und rechter Seite des V ist nach meiner Erfah- rung nicht allen Anwendern des Modells bewusst: Wer sich ein tech- nisches System, ein Spiegelei, oder einen Blog-Artikel ausdenkt, trägt damit automatisch die Verantwor- tung, auch den Test und die Test- barkeit des Vorhabens sicherzustel- len. Dies mag im Rahmen meines Beispiels mit dem Ei noch am ein- fachsten sein. Doch schon beim Blogartikel muss ich mir im Vorfeld Gedanken machen, wie ich sicher- stelle, dass er so aussieht, wie ich mir das vorgestellt habe und auf al- len Browsern läuft. Bei Ihrem tech- nischen System müssen Sie noch viel mehr Gedanken in Testkonzep- te und die Testbarkeit der Anforde- rungen investieren. Das sollten Sie nicht erst beim Test machen, son- dern schon während Sie die Anfor- derung an das System festlegen. Handelsübliche V-Modelle Auch an dieser Zwischenüber- schrift können Sie erkennen: Sofern Sie nicht gerade ein Softwareprojekt für die Bundesrepublik Deutsch- land basteln, gibt es nicht das V- Modell. Unter einem üblichen V- Modell verstehe ich, dass sich die oben erwähnte Dekomposition eines Systems auch in der Beschrei- bung und dem Zusammenhang der Tätigkeiten widerspiegelt. Dadurch besteht ein solches Mo- dell aus mindestens zwei Ebenen. Ganz oben steht – wie Sie wahr- scheinlich schon vermutet haben – das Gesamtsystem. Dieses zer- fällt auf der zweiten Ebene in die Hauptkomponenten der Systemar- chitektur. Auch eine Hauptkompo- nente könnte wieder in weitere Un- terkomponenten zerfallen, dadurch würde sich ein Modell mit drei Ebe- nen ergeben. Sie könnten dies mit beliebig vielen Ebenen fortsetzen, um die Zusammenhänge zu be- schreiben, erkläre ich hier jedoch ein einfaches Modell, in dem die Systemebene in lediglich eine weite- re Komponentenebene zerfällt. Das Interessante hierbei ist, dass in ei- ner solchen Denkweise jede Ebene nach demselben Muster aufgebaut ist – das Modell ist also fraktal. Auf der linken Seite des V, also auf der Seite der Spezifikation und der Dekomposition, werden für jede Ebene Anforderungen erstellt. Auf der Systemebene sind das die Systemanforderungen, auf Kom- ponentenebene sind dies Anforde- rungen an die jeweilige Komponen- te. Anforderungen beschreiben im- mer das „Was“. Sie beschreiben also eine Blackbox-Sicht ohne Rücksicht auf das Innenleben der jeweiligen Ebene. Aus den Anforderungen wird für jede Ebene ein techni- sches Konzept abgeleitet. Das ist die Whitebox-Sicht, die das „Wie“ beschreibt. Aus den Systemanfor- derungen wird also eine System- architektur abgeleitet, mit der die Komponenten des Systems sowie deren Interaktion definiert werden. Die Systemarchitektur liefert damit einen wesentlichen Anteil für die Anforderungen an die Kompo- nenten (wiederum Blackbox-Sicht). Ebenso gibt es für jede Kompo- nente wieder eine technische Be- schreibung des Innenlebens, meist als Komponentenarchitektur oder Komponentendesign bezeichnet. Damit bin ich in diesem Zwei- Ebenen-Beispiel an der Spitze des V angelangt, an der die Spezifikatio- nen und Konzepte in ein Produkt umgesetzt werden. Die Umsetzung geschieht auf der niedrigsten spezi- fizierten Ebene, in diesem Beispiel werden also die einzelnen Archi- tekturelemente der Komponenten gebaut. Sobald dies geschehen ist, ge- winnt die rechte Seite des V-Mo- dells an Bedeutung. Sie steht für Integration und Test. Auf Kompo- nentenebene werden nun die gefer- tigten Einzelteile zu einer Kompo- nente zusammengesetzt (integriert) und danach wird jede Komponente für sich getestet. Integration und Test entsprechen dabei den links gegenüberliegenden Ebenen „Ar- chitektur“ und „Anforderungen“. Beim Zusammenbau, also bei der Integration, kann zum ersten Mal getestet werden, ob die Interak- tion der Einzelteile den Vorgaben der Architektur entspricht (Whi- tebox). Danach wird im Test der Komponente sichergestellt, dass die Komponente die an sie gestell- ten Anforderungen erfüllt (Black- box). Gemäß dem fraktalen Ansatz wiederholt sich dieses Spiel auf der darüber liegenden Systemebene: In der Systemintegration wird die In- teraktion der Systemkomponenten getestet, das integrierte System wird dann gegen die Systemanforderun- gen getestet. Damit steht, egal auf welcher Ebene, den Anforderungen auf der linken Seite des V immer ein Blackbox-Text auf der rechten Sei- te gegenüber. Einem technischen Konzept bzw. einer Architektur auf der linken Seite stehen eine Integ- ration und ein Integrationstest auf der rechten Seite gegenüber. System- anforderungen System- architektur Komponenten- anforderungen Komponenten- design Bau / Beschaffung Komponenten- integra�onstest SystemKomponenten Komponenten- test System- integra�onstest Systemtest Bild 2: V-Modell mit zwei Ebenen
  • 3. - 3 - Zusammenspiel der Aktivitäten Ein V-Modell beschreibt also zu- nächst Aktivitäten und Zusammen- hänge. Es beschreibt nicht, ob diese in definierten Prozessen abgearbei- tet und schriftlich dokumentiert werden, oder ob dies alles im Kopf talentierter Entwickler geschieht. Das Zusammenspiel der Aktivi- täten ist für mich ein wesentlicher Punkt: Gerade hier erlebe ich in der Praxis oft eine unzureichende Inter- pretation des V-Gedankens. Zum einen möchte ich kurz auf das Prin- zip der Traceability, also der Nach- verfolgbarkeit von Anforderungen, eingehen – zum anderen geht es mir um das, was ich „horizontale Verantwortung“ nenne. Mit Ihrem Kunden reden Sie auf der Ebene der Systemanforde- rungen. Vielleicht war es auch Ihr Kunde, der diese aufgestellt hat. In Ihrem Entwicklungsablauf müs- sen Sie für sich nachweisen, dass alle Anforderungen umgesetzt und auch getestet wurden. Diese Nach- verfolgbarkeit wird als „Traceabili- ty“ bezeichnet. Dabei gibt es zwei Achsen: Die vertikale Traceability weist nach, dass alle Anforderun- gen in der Produktentwicklung be- rücksichtigt wurden, also welche Anforderungen durch welche Ar- chitekturelemente, Komponenten und Bauteile umgesetzt werden. Bei Software zieht sich das von der Sys- temebene bis auf die entsprechen- de Code-Zeile. Die horizontale Tra- ceability weist nach, ob es zu jeder Anforderung auf der entsprechen- den Ebene auch Testfälle gibt, um die Umsetzung der Anforderung verifizieren zu können. Im zweiten Schritt müssen auch die Ergebnisse durchgeführter Tests (Testreports) mit den entspre- chenden Testfällen in Beziehung gesetzt werden. Damit weisen Sie nach, dass jede Anforderung auch wirklich getestet wurde. Die Ver- waltung von Traceability ist in der Regel nur mit entsprechenden Soft- ware-Werkzeugen möglich. Da sich alle Dokumente im Entwicklungs- prozess regelmäßig ändern, ist es nur so möglich, die Traceability nachweisen zu können. Der Grundgedanke in einem V- Modell ist, dass auf der Achse der horizontalen Traceability links die Grundlagen für die jeweils gegen- überliegende Aktivität auf der rech- ten Seite geschaffen werden. Wer Anforderungen aufschreibt, hat auch die Verantwortung, dass diese getestet werden können und dass grundlegende Testkonzepte vorlie- gen. Ebenso haben die Architekten links im V die Verantwortung, die Reihenfolge für die Integration vor- zuschlagen und die Grundlagen für den Integrationstest zu legen. Dies kann auch beinhalten, dass die Architektur Elemente oder Schnittstellen enthält, die nicht der Erfüllung der Anforderungen, sondern der Testbarkeit dienen (z. B. zusätzliche Messpunkte oder Schnittstellen). Jede Konzeptstu- fe im V-Modell trägt also auch die Verantwortung für die zugehörige Teststufe rechts im V. Diese, wie ich sie nenne, „horizontale Verantwor- tung“ im V-Modell ist in der Praxis nicht immer anzutreffen. Oft wer- den die Aktivitäten auf den beiden Seiten des V strikt getrennt. Scrum im V-Modell Jeder Sprint in Scrum entspricht einem klassischen Projektdurchlauf mit Planung, Review und Lessons Learned. Am Ende jedes Sprints steht ein fertig getestetes und do- kumentiertes Produktinkrement. In jedem Sprint wird also einmal das entsprechende V der Produktent- wicklung durchlaufen. Die Tätig- keiten, die in einem V-Modell defi- niert sind, können dabei beliebig oft iteriert werden, interagieren oder parallelisiert werden. Jedes Scrum Team arbeitet also implizit mit ei- nem V-Modell. Die Frage, inwiefern Scrum und V-Modell zusammenpassen, ent- steht meistens durch die Existenz starr definierter Prozesslandschaf- ten, die auf dem V-Gedanken ba- sieren. Diese sind darauf ausgelegt, dass ein Durchlauf des V, also ein Entwicklungszyklus, viele Monate oder gar Jahre benötigt. Entspre- chend umfangreich sind die im Pro- zess hinterlegten Anforderungen an die Dokumentation des Vorgehens. Nicht selten entspringen diese dem Teufelskreis der Produktentwick- lung: „Management macht unrealis- System- anforderungen System- architektur Komponenten- anforderungen Komponenten- design Bau / Beschaffung Komponenten- integra�onstest horizontale Traceability vertikale Traceability Komponenten- test System- integra�onstest Systemtest Testreports Testreports Testreports Testreports Bild 3: V-Modell mit Traceability
  • 4. - 4 - tische Vorgaben, Entwicklung ver- sucht diese unter Qualitätseinbußen zu erfüllen, Management macht wegen der schlechten Qualität mehr Vorgaben zu Dokumentation und Kontrolle, Zeitvorgaben wer- den wegen zusätzlichem Overhead noch unrealistischer.“ Um solche gewachsenen Monster-V-Prozess- modelle mit Scrum vereinbar zu machen, muss der Prozess Stück für Stück entschlackt werden, Checklis- ten müssen durch Vertrauen und Wunschdenken durch Transparenz ersetzt werden. Dazu müssen gro- ße Anstrengungen unternommen werden, um Aktivitäten auf beiden Seiten des V-Modells maximal zu automatisieren. Nur so kann das V irgendwann in einen Sprint passen. Sie werden nun einwenden, dass es bei der Entwicklung von phy- sischen Produkten – dem natürli- chen Lebensraum von V-Modellen – nicht immer möglich ist, einen Durchlauf des V in einen Sprint zu bekommen. Das ist richtig. In einem solchen Fall haben Sie zwei Möglichkeiten. Die erste (und häufig angewende- te) Möglichkeit ist, erst ab einer be- stimmten Ebene mit agilen Sprints zu beginnen. In diesem Fall haben Sie einen nicht-agilen Vor- und Nachspann im V-Durchlauf (oft auch als Hybrider Ansatz bezeich- net). Die agilen Korrekturmöglich- keiten beziehen sich nur auf die Umsetzung, nicht auf Spezifikation und Test, und bleiben also in einem überschaubaren Rahmen. Inwiefern dies noch agil ist, müssen Sie selbst beurteilen. Die zweite und zugleich agile- re Möglichkeit ist, die agile Lern- schleife von Wochen auf Monaten auszudehnen. Ein kompletter V- Durchlauf in drei Monaten ist bei vielen Systemen realistisch, wenn die einschlägigen Impediments wie Einkaufs-, QM- und Musterbau- prozesse angegangen werden. Vorschläge Egal, was Sie entwickeln und wie Sie es entwickeln: Stellen Sie sich die Tätigkeiten in einem V vor. Schaf- fen Sie auf der linken Seite im V die Grundlagen für alle Schritte auf der rechten Seite. Dies erhöht die Ge- schwindigkeit und verringert das Risiko bei Ihrem Entwicklungsvor- haben. Falls Sie die Prozesse, Tem- plates und Checklisten für Ihr V- Modell definiert haben, prüfen Sie diese auf Notwendigkeit und Sinn- haftigkeit. Dies hilft Ihnen schnel- ler durch das V zu kommen, wenn Sie agile Ansätze verwenden. Er- liegen Sie nicht der Versuchung der hybriden Ansätze, nur weil das im Moment einfacher erscheint. Wenn Ihnen ein hybrider Ansatz plausibel und nützlich erscheint, überlegen Sie, ob agiles Arbeiten für Sie über- haupt Vorteile bringt. Wenn Sie hin- gegen agil arbeiten möchten, arbei- ten Sie darauf hin, das V in einem festen Takt von wenigen Monaten durchlaufen zu können. Regelmäßi- ge Durchläufe des Entwicklungs-Vs und die ständige Verbesserung der Organisation machen Agilität aus, auch wenn die Durchläufe zu Be- ginn der Veränderung noch Monate dauern. Arbeitspakete hingegen in- mitten eines starren Projektplans mit unveränderten Prozessen im Takt von zwei Wochen abzuarbei- ten und mit Zetteln an der Wand zu visualisieren, ist vielleicht nützlich, aber nicht agil. Autor Joachim Pfeffer ist Experte in der agi- len Produktentwicklung für physische Produkte. Seit vielen Jahren berät er Un- ternehmen in der Automobilindustrie und im Maschinenbau, um mit ihnen schlag- kräftige Entwicklungsabläufe in einer zu- nehmend komplexen Welt zu entwerfen. Dabei arbeitet er mit Scrum und Kanban, angereichert mit Konzepten aus dem Lean Development und der Engpasstheorie. Veröffentlicht am 27.01.2020 auf joachim-pfeffer.com JoachimPfeffer Produktentwicklung Lean&Agile 324Seiten 59,99€ ISBN: 978-3-446-45908-3 Mehr zu Scrum im V-Modell