Sind Entwicklungsprozesse nach dem V-Modell noch tauglich? Kann im V-Modell mit Scrum entwickelt werden? Wie hängen Anforderderungen und Tests zusammen?
V-Modelle: Eine Geschichte voller Missverständnisse.
Build Patterns - Patterns und Best Practices für den Build ProzessRalf Abramowitsch
Mein Vortrag auf der Konferenz "Continuous Lifecycle 2013" am 12.11.2013 in Karlsruhe: Build Patterns - Patterns und Best Practices für den Build Prozess.
Dabei wurden insgesamt 6 Buildpatterns vorgestellt: Build Script Injection, Build-Skelett, Ablagen-unabhängige Build-Skripte, Infrastruktur-unabhängige Build-Skripte, Kumulative Builds und Gated Commits. Alle Patterns basieren auf dem Buch "Beautiful Builds" von Roy Osherove.
Das Requirements Engineering ist die Innovationsbremse in der Systementwicklung. Hier wird der mögliche Lösungsraum kurz und schmerzlos auf ein Minimum reduziert. Es ist der Drang nach etwas Konkretem oder nach "Butter bei die Fische tun", wie wir in Hamburg sagen.
Hand aufs Herz: Sind Ihre Anforderungen wirklich lösungsfrei wie es die RE-Theorie fordert?
Anhand des Zick-Zack-Musters aus der SYSMOD-Methodik zeige ich Ihnen, dass Sie lösungsschwangere Anforderungen haben dürfen. Ich zeige Ihnen aber auch, wo die wirklich lösungsfreien Anforderungen hausen. Und wenn Sie diese Zusammenhänge kennen, wissen Sie auch wo der Hebel ist, um die Innovationsbremse im Requirements Engineering zu lösen.
In einem DeepDive zeigen euch Lars Heinrich und Peggy Reuter den Umgang mit Expression Blend für Silverlight, Windows Phone 7 und WPF. Damit ihr am Ende des Abends auch handfestes Wissen mit nach Hause nehmt, werden die beiden mit euch einige kleine Applikationen erarbeiten. Angedacht sind für den gemeinsamen Abend: eine Formular-Applikation, ein SketchFlow Prototyp und das Designen dessen, sowie ein kleines 3D-WPF-Projekt. Im Verlauf der drei kleinen Arbeiten werdet ihr die relevanten Features von Blend und den Basis-Umgang mit Blend erlernen. Die großen Neuerungen von Blend 4, sowie eine Windows Phone App werden wir, wenn Zeit bleibt, auch noch demonstrieren. Es wird ein codefreier Abend werden, da wir uns an diesem Abend vorwiegend auf der WYSIWYG-Oberfläche bewegen werden.
Build Patterns - Patterns und Best Practices für den Build ProzessRalf Abramowitsch
Mein Vortrag auf der Konferenz "Continuous Lifecycle 2013" am 12.11.2013 in Karlsruhe: Build Patterns - Patterns und Best Practices für den Build Prozess.
Dabei wurden insgesamt 6 Buildpatterns vorgestellt: Build Script Injection, Build-Skelett, Ablagen-unabhängige Build-Skripte, Infrastruktur-unabhängige Build-Skripte, Kumulative Builds und Gated Commits. Alle Patterns basieren auf dem Buch "Beautiful Builds" von Roy Osherove.
Das Requirements Engineering ist die Innovationsbremse in der Systementwicklung. Hier wird der mögliche Lösungsraum kurz und schmerzlos auf ein Minimum reduziert. Es ist der Drang nach etwas Konkretem oder nach "Butter bei die Fische tun", wie wir in Hamburg sagen.
Hand aufs Herz: Sind Ihre Anforderungen wirklich lösungsfrei wie es die RE-Theorie fordert?
Anhand des Zick-Zack-Musters aus der SYSMOD-Methodik zeige ich Ihnen, dass Sie lösungsschwangere Anforderungen haben dürfen. Ich zeige Ihnen aber auch, wo die wirklich lösungsfreien Anforderungen hausen. Und wenn Sie diese Zusammenhänge kennen, wissen Sie auch wo der Hebel ist, um die Innovationsbremse im Requirements Engineering zu lösen.
In einem DeepDive zeigen euch Lars Heinrich und Peggy Reuter den Umgang mit Expression Blend für Silverlight, Windows Phone 7 und WPF. Damit ihr am Ende des Abends auch handfestes Wissen mit nach Hause nehmt, werden die beiden mit euch einige kleine Applikationen erarbeiten. Angedacht sind für den gemeinsamen Abend: eine Formular-Applikation, ein SketchFlow Prototyp und das Designen dessen, sowie ein kleines 3D-WPF-Projekt. Im Verlauf der drei kleinen Arbeiten werdet ihr die relevanten Features von Blend und den Basis-Umgang mit Blend erlernen. Die großen Neuerungen von Blend 4, sowie eine Windows Phone App werden wir, wenn Zeit bleibt, auch noch demonstrieren. Es wird ein codefreier Abend werden, da wir uns an diesem Abend vorwiegend auf der WYSIWYG-Oberfläche bewegen werden.
Wie Sie durchgängige Produktdaten über den Prozess sicherstellenIntelliact AG
Die Anforderungen an durchgängige Produktstrukturen, ob im Engineering, in der Produktion oder im Service, werden primär durch den Produktlebenszyklus definiert. Was bedeutet dies für das Freigabe- und Änderungswesen? Und erreichen wir eine Rückverfolgbarkeit im Bereich Service und IoT? Weitere Informationen zum Thema auf: https://intelliact.ch/know-how/durchgaengige-produktstrukturen-sicherstellen
In dieser OpenHour zeigen wir die Zusammenhänge zwischen den Strukturen eBOM, mBOM und sBOM auf, und erörtern Transformationsmöglichkeiten für die Erreichung deren Durchgängigkeit.
****
Besuchen Sie die nächste PLM Open Hour! Mehr Informationen und Termine: https://intelliact.ch/events/plm-open-hours
****
Das Whitepaper „Collaborative Virtual Engineering“ gibt einen Überblick über verschiedene kooperative VR-Systeme, deren Nutzen sowie Einsatzszenarien. Grundsätzlich bestehen folgende vier technischen Möglichkeiten, Virtuelle und Erweiterte Realität für das Collaborative Engineering einzusetzen: Planungstische, Großdisplays, kollaborative Augmented Reality und verteilte Virtuelle Umgebungen. Die damit erzielbaren Kooperationsansätze sind grundlegend unterschiedlich. Genauso vielfältig sind auf der anderen Seite mögliche Einsatzszenarien. Die auszuwählenden Systeme sind also gut auf den Einsatzzweck abzustimmen. Die Vielzahl an Features erfordern eine sorgfältige Auswahl und Tests. Deren Einbindung in Entwicklungs-/Service-/Trainings-/Marketing-Abläufe ist vorzuzusehen. Das Whitepaper „Collaborative Virtual Engineering“ gibt einen Überblick über verschiedene Kooperationstechniken, deren Nutzen sowie Einsatzszenarien.
Wer die gleiche Aktion zwanzig Mal hintereinander fast identisch ausführt, mag als fleißig gelten. Mit „faul“ sind die Entwickler gemeint, die ab der zweiten Wiederholung innehalten und darüber nachdenken, wie sich die nächsten achtzehn Wiederholungen vermeiden oder zumindest effizienter durchführen lassen.
In solchen Situationen hat es sich bewährt, erstmal herauszufinden, wie man Dinge mit weniger Stress, weniger Energie und weniger Zeitaufwand lösen kann. Der Autor beispielsweise ist zu faul, etwas doppelt zu tun, sondern verbringt seine Entwicklungszeit lieber kreativ.
Vor allem ab Version 4 bietet SQL Developer jede Menge Möglichkeiten, die helfen, effizienter mit dem Tool umzugehen. Faule Entwickler nutzen diese.
TAG2015: ArchiteKultur – wie bekommen wir Architekturarbeit in den Alltag rei...Matthias Bohlen
Stellen Sie sich vor, Sie haben fähige Entwicklungsteams, Product Owner, Projektleiter und diverse Kunden für ein existierendes, lauffähiges System. Es könnte alles so schön sein. Doch das System ist „wie Kraut und Rüben“. Die Entwicklung folgt keinen klaren Strukturen. Die Software ist viel zu schwer änderbar.
Wie kriegen Sie nun diesen „Flohzirkus“ dazu, eine Kultur zu entwickeln, in der konsequent Architekturarbeit gemacht wird? Eine Kultur, in der es nicht egal ist, wie eine Komponente heißt, von welchen anderen sie abhängt und wie schnell und wie unabhängig man sie in Betrieb nehmen kann? Eben eine Kultur, in der Architektur etwas gilt und Velocity bzw. Durchsatz der Teams nicht das alleinige Ziel sind.
Matthias Bohlen zeigt eine Mischung aus Bildern, Philosophien, Methoden und Tools, mit der Sie solch eine ArchiteKultur anziehen können – destilliert aus seiner Erfahrung in realen Projekten.
http://the-architecture-gathering.de/
UPDATED USER GUIDE for the Final WeGov Toolbox 3.0: “Was ist WeGov?”(in German)WeGov project
This document consists the updated WeGov User Guide for the Final WeGov Toolbox 3.0 (Version 2.10.2012). The present user guide is in the German language.
Folien meiner Session über WYSIWYG-Editoren für Drupal 7 auf dem DrupalCamp Berlin 2011. Möglicherweise gibt es dazu in ein paar Wochen eine Artikelserie auf http://nicolaischwarz.de.
Das Virtual Dimension Center (VDC) und die Allianz Faserbasierte Werkstoffe (AFBW) präsentieren in der gemeinsamen Composite Simulation Roadmap die Ergebnisse einer Expertenbefragung zur Simulation von Verbundwerkstoffen. Die Roadmap greift den Stand der Technik auf und gibt einen Ausblick auf künftige Handlungsfelder und Bedarfe von Industrie und Forschung.
Die Zeit der Einheitsprodukte und Massenproduktion ist vorbei. Der Markt hat sich gedreht, der Kunde wird führend und fordert individualisierte Produkte. Für die Hersteller bedeutet es, dass sie zunehmend Varianten ihrer Produkte entwickeln und anbieten müssen.
Es ist schon eine Herausforderung, ein einzelnes komplexes System zu beschreiben. Variationen machen aus der Beschreibung eine multidimensionale Herausforderung, deren Komplexität schnell Grenzen erreicht und die Möglichkeiten der Entwicklung einschränkt.
Modellierung ist ein wirksames Werkzeug, um Komplexität beherrschen zu können. Ich zeige Ihnen, welche Möglichkeiten es heute gibt, Produktvarianten mit der SysML bzw. UML zu beschreiben. Sie erfahren etwas über die Konzepte der Variantenmodellierung und ihre Umsetzung mit SysML. Wir schauen auch gemeinsam auf die Grenzen der Modellierung und auf zukünftige Lösungsansätze.
Hier der gesamte Themenüberblick
Administration
- First Release wird umbenannt in Targeted Release
- Tipp: Welche Clouddienste laufen in meinem Unternehmen?
- Business Apps auch bei Enterprise freischalten: Bookings, Outlook Cutomer Manager, Invoicing, …
Delve & My Analytics
- Wurde meine Mail bearbeitet?
- My Analytics schlägt To-Dos aus den Mails vor
Office
- Sway bietet nun auch Export und Druck-Funktion
- Aufzeichnung in PowerPoint freischalten
- Lebenslaufassistent in Word (LinkedIn)
- Pick it & Pexels: Kostenlose Bilder
- Excel: CSV (UTF-8) Unterstützung
- Excel PowerPivot: Beziehungen bearbeiten
- Excel PowerPivot: Beziehungsansicht speichern
- Excel PowerQuery: Bedingte Spalten
- Excel PowerQuery: Extrahieren von Wochen, Tages und Monatsnamen sowie
- Excel PowerQuery: Spaltentypanzeiger in Spaltenüberschriften
- Excel PowerQuery: Präfix / Suffix in Textspalten
- Excel PowerQuery Konvertieren von Werten
- Excel PowerQuery: Abrufen und transformieren
- Excel PowerQuery: Connectoren
- Excel PowerQuery: Spalte teilen
- Excel PowerQuery: Erweiterte Filterfunktionen
- Excel PowerQuery: Erweiterte Filterfunktionen
- Neue Excel Funktionen: TEXTJOIN, TEXTKETTE, WENNS, SWITCH, MAXWENNS,
MINWENNS
- Verbessertes AutoVervollständigen
- Access: Aktualisiertes Aussehen für Vorlagen
- Access: Verknüpfte Datenquellen nach Excel exportieren
- Access: Sortierung des Eigenschaftenblatts
- Access: Wiederherstellungslogik für ODBC-Verbindung
- Access: dBASE Unterstützung wieder da
- Access: Unterstützung „Große Zahl“ (bigint)
OneDrive for Business
- OneDrive ist nicht gleich OneDrive: Übersichtsgrafik
Planner
- Aufgaben kopieren
- Kalender-Ansicht für Planner: Tages / Wochen / Monatsansicht
- Aufgaben können per Drag´n´Drop hinzugefügt werden.
- Planner per iCal in Outlook einbinden
Power BI
- Dashboards freigeben für kostenlose Nutzer
SharePoint
- Ausblick: Neue Webparts für SharePoint
- Seitenverwendungsbericht
- SharePoint Site eine Group hinzufügen
Skype for Business
- Skype for Business vs. Teams
- Telefonanlage adé: PSTN Calling in Deutschland verfügbar!
- Teams & Skype: Messaging Roadmap von Microsoft
Teams & Groups
- Maximale Anzahl der Teammitglieder steigt auf 2.500 von bisher 999
- Problemlösung: Gäste können auf das Team zugreifen, nicht aber auf Notizbuch und SharePoint
- Problemlösung: Gast-User wird als Mitglied anstatt als Gast angezeigt
- Teams PowerShell Cmdlet
Wie Sie durchgängige Produktdaten über den Prozess sicherstellenIntelliact AG
Die Anforderungen an durchgängige Produktstrukturen, ob im Engineering, in der Produktion oder im Service, werden primär durch den Produktlebenszyklus definiert. Was bedeutet dies für das Freigabe- und Änderungswesen? Und erreichen wir eine Rückverfolgbarkeit im Bereich Service und IoT? Weitere Informationen zum Thema auf: https://intelliact.ch/know-how/durchgaengige-produktstrukturen-sicherstellen
In dieser OpenHour zeigen wir die Zusammenhänge zwischen den Strukturen eBOM, mBOM und sBOM auf, und erörtern Transformationsmöglichkeiten für die Erreichung deren Durchgängigkeit.
****
Besuchen Sie die nächste PLM Open Hour! Mehr Informationen und Termine: https://intelliact.ch/events/plm-open-hours
****
Das Whitepaper „Collaborative Virtual Engineering“ gibt einen Überblick über verschiedene kooperative VR-Systeme, deren Nutzen sowie Einsatzszenarien. Grundsätzlich bestehen folgende vier technischen Möglichkeiten, Virtuelle und Erweiterte Realität für das Collaborative Engineering einzusetzen: Planungstische, Großdisplays, kollaborative Augmented Reality und verteilte Virtuelle Umgebungen. Die damit erzielbaren Kooperationsansätze sind grundlegend unterschiedlich. Genauso vielfältig sind auf der anderen Seite mögliche Einsatzszenarien. Die auszuwählenden Systeme sind also gut auf den Einsatzzweck abzustimmen. Die Vielzahl an Features erfordern eine sorgfältige Auswahl und Tests. Deren Einbindung in Entwicklungs-/Service-/Trainings-/Marketing-Abläufe ist vorzuzusehen. Das Whitepaper „Collaborative Virtual Engineering“ gibt einen Überblick über verschiedene Kooperationstechniken, deren Nutzen sowie Einsatzszenarien.
Wer die gleiche Aktion zwanzig Mal hintereinander fast identisch ausführt, mag als fleißig gelten. Mit „faul“ sind die Entwickler gemeint, die ab der zweiten Wiederholung innehalten und darüber nachdenken, wie sich die nächsten achtzehn Wiederholungen vermeiden oder zumindest effizienter durchführen lassen.
In solchen Situationen hat es sich bewährt, erstmal herauszufinden, wie man Dinge mit weniger Stress, weniger Energie und weniger Zeitaufwand lösen kann. Der Autor beispielsweise ist zu faul, etwas doppelt zu tun, sondern verbringt seine Entwicklungszeit lieber kreativ.
Vor allem ab Version 4 bietet SQL Developer jede Menge Möglichkeiten, die helfen, effizienter mit dem Tool umzugehen. Faule Entwickler nutzen diese.
TAG2015: ArchiteKultur – wie bekommen wir Architekturarbeit in den Alltag rei...Matthias Bohlen
Stellen Sie sich vor, Sie haben fähige Entwicklungsteams, Product Owner, Projektleiter und diverse Kunden für ein existierendes, lauffähiges System. Es könnte alles so schön sein. Doch das System ist „wie Kraut und Rüben“. Die Entwicklung folgt keinen klaren Strukturen. Die Software ist viel zu schwer änderbar.
Wie kriegen Sie nun diesen „Flohzirkus“ dazu, eine Kultur zu entwickeln, in der konsequent Architekturarbeit gemacht wird? Eine Kultur, in der es nicht egal ist, wie eine Komponente heißt, von welchen anderen sie abhängt und wie schnell und wie unabhängig man sie in Betrieb nehmen kann? Eben eine Kultur, in der Architektur etwas gilt und Velocity bzw. Durchsatz der Teams nicht das alleinige Ziel sind.
Matthias Bohlen zeigt eine Mischung aus Bildern, Philosophien, Methoden und Tools, mit der Sie solch eine ArchiteKultur anziehen können – destilliert aus seiner Erfahrung in realen Projekten.
http://the-architecture-gathering.de/
UPDATED USER GUIDE for the Final WeGov Toolbox 3.0: “Was ist WeGov?”(in German)WeGov project
This document consists the updated WeGov User Guide for the Final WeGov Toolbox 3.0 (Version 2.10.2012). The present user guide is in the German language.
Folien meiner Session über WYSIWYG-Editoren für Drupal 7 auf dem DrupalCamp Berlin 2011. Möglicherweise gibt es dazu in ein paar Wochen eine Artikelserie auf http://nicolaischwarz.de.
Das Virtual Dimension Center (VDC) und die Allianz Faserbasierte Werkstoffe (AFBW) präsentieren in der gemeinsamen Composite Simulation Roadmap die Ergebnisse einer Expertenbefragung zur Simulation von Verbundwerkstoffen. Die Roadmap greift den Stand der Technik auf und gibt einen Ausblick auf künftige Handlungsfelder und Bedarfe von Industrie und Forschung.
Die Zeit der Einheitsprodukte und Massenproduktion ist vorbei. Der Markt hat sich gedreht, der Kunde wird führend und fordert individualisierte Produkte. Für die Hersteller bedeutet es, dass sie zunehmend Varianten ihrer Produkte entwickeln und anbieten müssen.
Es ist schon eine Herausforderung, ein einzelnes komplexes System zu beschreiben. Variationen machen aus der Beschreibung eine multidimensionale Herausforderung, deren Komplexität schnell Grenzen erreicht und die Möglichkeiten der Entwicklung einschränkt.
Modellierung ist ein wirksames Werkzeug, um Komplexität beherrschen zu können. Ich zeige Ihnen, welche Möglichkeiten es heute gibt, Produktvarianten mit der SysML bzw. UML zu beschreiben. Sie erfahren etwas über die Konzepte der Variantenmodellierung und ihre Umsetzung mit SysML. Wir schauen auch gemeinsam auf die Grenzen der Modellierung und auf zukünftige Lösungsansätze.
Hier der gesamte Themenüberblick
Administration
- First Release wird umbenannt in Targeted Release
- Tipp: Welche Clouddienste laufen in meinem Unternehmen?
- Business Apps auch bei Enterprise freischalten: Bookings, Outlook Cutomer Manager, Invoicing, …
Delve & My Analytics
- Wurde meine Mail bearbeitet?
- My Analytics schlägt To-Dos aus den Mails vor
Office
- Sway bietet nun auch Export und Druck-Funktion
- Aufzeichnung in PowerPoint freischalten
- Lebenslaufassistent in Word (LinkedIn)
- Pick it & Pexels: Kostenlose Bilder
- Excel: CSV (UTF-8) Unterstützung
- Excel PowerPivot: Beziehungen bearbeiten
- Excel PowerPivot: Beziehungsansicht speichern
- Excel PowerQuery: Bedingte Spalten
- Excel PowerQuery: Extrahieren von Wochen, Tages und Monatsnamen sowie
- Excel PowerQuery: Spaltentypanzeiger in Spaltenüberschriften
- Excel PowerQuery: Präfix / Suffix in Textspalten
- Excel PowerQuery Konvertieren von Werten
- Excel PowerQuery: Abrufen und transformieren
- Excel PowerQuery: Connectoren
- Excel PowerQuery: Spalte teilen
- Excel PowerQuery: Erweiterte Filterfunktionen
- Excel PowerQuery: Erweiterte Filterfunktionen
- Neue Excel Funktionen: TEXTJOIN, TEXTKETTE, WENNS, SWITCH, MAXWENNS,
MINWENNS
- Verbessertes AutoVervollständigen
- Access: Aktualisiertes Aussehen für Vorlagen
- Access: Verknüpfte Datenquellen nach Excel exportieren
- Access: Sortierung des Eigenschaftenblatts
- Access: Wiederherstellungslogik für ODBC-Verbindung
- Access: dBASE Unterstützung wieder da
- Access: Unterstützung „Große Zahl“ (bigint)
OneDrive for Business
- OneDrive ist nicht gleich OneDrive: Übersichtsgrafik
Planner
- Aufgaben kopieren
- Kalender-Ansicht für Planner: Tages / Wochen / Monatsansicht
- Aufgaben können per Drag´n´Drop hinzugefügt werden.
- Planner per iCal in Outlook einbinden
Power BI
- Dashboards freigeben für kostenlose Nutzer
SharePoint
- Ausblick: Neue Webparts für SharePoint
- Seitenverwendungsbericht
- SharePoint Site eine Group hinzufügen
Skype for Business
- Skype for Business vs. Teams
- Telefonanlage adé: PSTN Calling in Deutschland verfügbar!
- Teams & Skype: Messaging Roadmap von Microsoft
Teams & Groups
- Maximale Anzahl der Teammitglieder steigt auf 2.500 von bisher 999
- Problemlösung: Gäste können auf das Team zugreifen, nicht aber auf Notizbuch und SharePoint
- Problemlösung: Gast-User wird als Mitglied anstatt als Gast angezeigt
- Teams PowerShell Cmdlet
Ähnlich wie V-Modelle - sie sind mitten unter uns (17)
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