Montag, 12. November 2012

Das Leiden hat einen Namen: Java 7

Das V-Modell XT und seine Werkzeuge sind bei uns mehrmals die Woche im Einsatz. In der letzten Zeit gab es eine Reihe von System-Updates, die bei uns eingespielt wurden. Dazu gehören:

  • Windows 8
  • Ubuntu Linux
  • Mac OS X 10.8 (Mountain Lion)
  • diverses andere, z.B. Java 7
Nach diesen ganzen Updates haben wir einige Probleme mit den V-Modell XT Werkzeugen festgestellt, etwa dass der Projektassistent (Bund-Edition) mitten im Produktvorlagenexport den Dienst einstellte oder dass der Editor der Meinung war, Dateien für einen Merge nicht erstellen zu wollen, da die (temporäre) Datei korrupt sei - obwohl er das Modell selbst nur wenige Sekunden zuvor bearbeitet hatte...
Lange Rede kurzer Sinn - auf allen Betriebssystemen fanden wir eine Gemeinsamkeit: Java 7. Nachdem wir sowohl unter Windows 8 als auch unter Mac OS auf Java 6 zurückgegangen sind, haben sich alle Probleme in Luft aufgelöst...
Von daher möchte ich die Anregung an alle Anwender geben, sicherheitshalber auf Java 6 zu verbleiben.
Ebenso wäre es schön, wenn jemand diese Erfahrungen (Problem mit Java 7) überprüfen könnte - Reaktionen und Erfahrungen sind gerne willkommen.

Montag, 1. Oktober 2012

Migration organisationsspezifisches V-Modell 1.3 nach 1.4

Heute wird es etwas technischer. Wer eine organisationsspezifische Anpassung des V-Modell XT 1.3 vorgenommen hat, kann möglicherweise eine Hilfe für die Migration nach Version 1.4 gebrauchen. Für die Migration der XML-Dateien (Modell und Mustertexte) ist dieser Post gedacht.

Was wird gebraucht?

  • Alle Tools, die der Prozessingenieur normalerweise einsetzt (VMXT Editor, OpenOffice/LibreOffice, etc.),
  • das v1.3-to-v1.4 Migrationsskript,
  • Ein XSL 2.0-fähiger Interpreter (ich habe saxon9-1-0-7j verwendet, aber mit neueren Versionen wird es wohl auch gehen; SAXON auf Sourceforge),
  • ein Texteditor (sehr empfohlen: Notepad++),
  • Windows (das Skript liegt nur als Batch-Datei für Windows vor),
  • oder ein anderes Betriebssystem (dann muss aber das Skript entsprechend angepasst werden),
  • sowie das schrittweise Befolgen der unten stehenden Anleitung!

Warum ist eine Migration notwendig?

Mit Release 1.4 wurden einige Metamodellrelevante Änderungen vorgenommen, die eine Migration notwendig machen. Einige Prozessingenieure haben bereits die folgende leidvolle Erfahrung gemacht: das 1.3er Modell lässt sich nicht mit dem 1.4er Metamodell im Editor öffnen.
Welche Änderungen sind nun daran schuld?
  • Die schuldigste Änderung ist das Auslagern des XML-Elements "BeispielProduktgestaltung" aus Themen und Produkten hin in die Mustertexte. D.h. diese "Beispielhafte Produktgestaltung" ist nicht mehr Bestandteil der Prozessdokumentation, sondern wird seit Version 1.4 als Mustertexte direkt für die Produktvorlage angeboten.
    Warum? Dort sind diese Beispiele näher am Anwender. Wenn es nun in einem 1.3er Modell noch solche Elemente gibt, dann weigert sich der VMXT Editor, dieses Modell mit dem 1.4er Metamodell zu öffnen, denn dieses kennt diese Elemente nicht mehr. Wer kann es dem Editor verübeln?
  • Eine weitere Änderung ist das Hinzukommen des Knotens "Rollenkategorie" als Unterknoten von "Rolle". Dieser Knoten kann die Werte "Organisationsrolle" und "Projektrolle" annehmen. Das ist aber kein Hemmnis für den Editor. Dieser öffnet das Modell einfach und lässt diese nicht vorhandenen Knoten einfach weiterhin weg.
  • Externe Kopiervorlagen unterstützen nun für das Attribut "Standardauswahl" nicht mehr nur die Werte "Ja" und "Nein", sondern auch den Wert "Verpflichtend". Der Projektassistent 1.4 gestattet es Ihnen nicht mehr, solche Kopiervorlagen abzuwählen.
    Für die Migration ist das nicht kriegsentscheidend, aber vielleicht hilft diese Information Ihnen ja weiter.
  • Last but not least: Durch die Aufteilung aller Rollen in die Kategorien "Projektrolle" und "Organisationsrolle" wurde auch der Rollenindex überarbeitet. Auch dies ist kein Grund für den Editor, die Segel zu streichen, aber wer hier nicht aufpasst, der könnte einen (marginalem, aber merklichen) Datenverlust bekommen. Ein "Kapitel" kann nämlich das Attribut "GenerierterInhalt" in Version 1.3 mit dem Wert "Index:Rollen" belegen. Die Exporttemplates 1.3 interpretieren diesen Wert so, dass in diesem Kapitel eine Auflistung aller Rollen in die Dokumentation generiert werden soll. Mit Aufteilung der Rollenkategorien gibt es diesen Wert nicht mehr. Statt dessen heißt es nun "Index:Projektrollen" (mit dem alle Projektrollen aufgelistet werden) und "Index:Organisationsrollen" (mit dem...). Wer also ein Interesse an einem Rollenindex hat, sollte hier sorgfältig prüfen. (Details unten)

Anleitung

  • Migrationsskript herunterladen und entpacken.
  • Das zu migrierende Modell (i.d.R. V-Modell-XT.xml) in dasselbe Verzeichnis zum Skript migrate_v1.3-to-v1.4.xsl legen. Dasselbe machen wir mit den Mustertexten (i.d.R. V-Modell-XT-Mustertexte.xml). Nennen Sie Ihre V-Modell-XML V-Modell-XT_v1.3.xml und Ihre Mustertexte-XML V-Modell-XT-Mustertexte_v1.3.xml. Tun Sie das wirklich, das wird Ihnen die folgenden Schritte einfacher machen und Fehlerquellen ausschließen. Sie könnten natürlich auch die Namen der Input-Dateien im Batch-File und im XSL-File anpassen, aber sagen Sie hinterher nicht, ich hätte Sie nicht gewarnt. ;)
  • Wegen des Wegfalls von "Index:Rollen": Das Migrationsskript übernimmt hier die Arbeit, aber je nachdem, wie Ihre organisationsspezifische Anpassung aussieht, könnte es sein, dass das Skript den zu migrierenden Knoten nicht finden kann. Öffnen Sie Ihr V-Modell-XML in einem Texteditor und suchen Sie Zeilen mit dem Text "Index:Rollen". Sehr wahrscheinlich ist das nur in dem Kapitel mit der ID 142aafbe855c566 der Fall. Dieses trägt den Namen "Rollenindex". Wenn dies so ist (sehr wahrscheinlich), dann können Sie mit den nächsten Schritt weitermachen. Wenn Sie gar keinen Rollenindex haben, dann können Sie auch weitermachen.
    Wenn die ID aber in Ihrem Fall nicht übereinstimmt, müssen Sie hier ggf. Anpassungen vornehmen. Das Skript sucht nach dem Knoten mit genannter ID und transformiert ihn. Wenn Ihr Rollenindex eine andere ID hat, dann würde ich empfehlen, im Skript migrate_v1.3-to-v1.4.xsl in Zeile 66 die ID anzupassen:

    <xsl:template match="Kapitel[@id='142aafbe855c566']" mode="vmxt_xml">
     
  • Ggf. Pfad zum XSL-Interpreter anpassen. Hierfür müssen Sie ggf. erst einen XSL-Interpreter heranschaffen. Im Skript migrate_v1.3-to-v1.4.bat ist die Voreinstellung (Zeile 4):

    SET XSL_INTERPRETER=java -jar %PFAD%\saxon9-1-0-7j\saxon9.jar

    Die Variable XSL_INTERPRETER enthält einen Java-Aufruf von SAXON und geht dabei davon aus, dass dieses im Verzeichnis des Aufrufs des Batch-Skriptes im Ordner saxon9-1-0-7j liegt. Klar, dass das angepasst werden muss, falls Sie einen anderen XSL-Interpreter benutzen oder dieser woanders liegt.
    Wichtig ist auch, dass Sie auf die Parametrisierung in den Zeilen 6 und 7 achten, sofern Sie einen anderen Interpreter (ggf. auch eine andere Version!) als SAXON 9.1.0.7j benutzen. SAXON erwartet die Angabe der Output-Datei nach dem Parameter "-o". Bei anderen Interpretern sieht das ggf. anders aus!
  • Modellmigration durch Aufruf von migrate-v1.3-to-v1.4.bat ausführen lassen. Was passiert jetzt? Es werden zwei neue Dateien erzeugt, eine für die V-Modell-XML (V-Modell-XT.xml), eine für die Mustertexte-XML (V-Modell-XT-Mustertexte.xml). Aus der V-Modell-XML werden alle Elemente "BeispielProduktgestaltung" gelöscht. In die Mustertexte-XML werden diese Beispieltexte jeweils als Mustertext für das jeweilige Thema ergänzt. Diese Beispieltexte werden in der Mustergruppe "Beispielhafte Produktgestaltungen" abgelegt.
  • Beide Erzeugnisse im V-Modell XT Editor öffnen, anschließend direkt speichern (wahrscheinlich müssen Sie zunächst irgendwo eine kleine Änderung vornehmen, die Sie direkt wieder rückgängig machen können). Hierzu können Sie die beiden erzeugten Dateien bequem in den Ordner Metamodell_v1.4 schieben. Falls Sie im Vorfeld meinen Vorschlag zur Dateibenennung nicht beachtet haben, könnte es sein, dass Sie ihre V-Modell-XML nun V-Modell-XT.xml nennen müssen, sonst könnte es sein, dass der Editor meckert, weil der Name der Datei in der Mustertexte-XML fest verdrahtet ist.
  • Jetzt sollte sich Ihr Modell im V-Modell XT Editor öffnen lassen. Möglicherweise (wenn Sie mit einem Erweiterungsmodell arbeiten) erhalten Sie folgende Fehlermeldung: "An include failed and there where no fallback element." In diesem Fall könnte es sein, dass in der Erweiterungsmodell-XML der Pfad zum Referenzmodell nicht richtig gesetzt ist. Schauen Sie in der XML-Datei in eine der letzten Zeilen:

    <xi:include href="../Modell/V-Modell-XT.xml"/>

    Die hier angegebene Datei muss einen gültigen relativen Pfad zur Referenzmodell-XML darstellen.
  • Damit die migrierten Rollen auch im Rollenindex angezeigt werden, müssen Sie allen Rollen in Ihrem Modell nun noch eine Rollenkategorie zuteilen. Orientieren können Sie sich am V-Modell XT 1.4, dort sind natürlich alle Rollen in Kategorien getrennt aufgeführt.
  • Falls Sie keine Beispieltexte in Ihrem Modell haben, dann können Sie in der Mustertexte-XML die Mustergruppe "Beispielhafte Produktgestaltung" löschen.
  • Das war die Pflicht um die XML-Datei herum. Zur Kür gehört jetzt natürlich auch die Anpassung aller anderen Assets des V-Modell XT, d.h. Bilder, Exporttemplates, etc. Hierfür habe ich keine Anleitung parat. Orientieren Sie sich an den Release Notes. Wenn Sie nicht alle Exporttemplates aus Version 1.4 komplett übernehmen sondern sich entscheiden, die Vorlage Kapitel-5_BeispielProduktgestaltung.odt händisch aus Ihren Exporttemplates zu entfernen (wird ja nicht mehr gebraucht), dann behalten Sie bitte im Hinterkopf, dass möglicherweise in anderen Templates darauf verwiesen wird. Diese Verweise müssen Sie natürlich auch entfernen, sonst bricht der Export ab mit der vielsagenden Meldung "Formatvorlage konnte nicht kompiliert werden". In Version 1.3 dürften sie nur in den Dateien Kapitel-5_Produkt.odt und Kapitel-5_Thema.odt gewesen sein (ohne Gewähr auf Vollständigkeit, vor allem da ich Ihre organisationsspezifische Anpassung nicht kenne!).

Disclaimer

Die Migration funktioniert wunderbar mit dem Standardmodell 1.3. Bei organisationsspezifischen Anpassungen kann man nie wissen, was alles geändert worden ist. Insofern kann ich nicht ausschließen, dass die Migration damit Probleme bereitet. 

Viel Erfolg!

Thomas Ternité

Dienstag, 11. September 2012

Abnahme des Pflichtenhefts durch den Auftraggeber?

Immer wieder kommt in der IT-Projektpraxis und in V-Modell XT Schulungen die Frage auf, ob der Auftraggeber eine Abnahme des Pflichtenhefts vornehmen sollte, oder nicht. In dem Buch "IT-Projektrecht" beschäftigt sich Frank A. Koch in Absatz 65 (S. 30) mit genau dieser Frage und gibt m.E. eine gute Antwort darauf, die aber durch eine etwas nachlässig vorgenommene Begriffsabgrenzung leicht falsch zu verstehen ist.

Kurz:

  • Der Auftraggeber sollte die Gesamtsystemspezifikation nicht abnehmen. 
Aber:
  • Falls der Auftragnehmer (oder ein anderer Dienstleister) bei der Erarbeitung des Lastenhefts beteiligt ist, ist eine Abnahme des Lastenhefts geboten.
Bevor ich das erläutere, muss ich eine kleine Begriffsabgrenzung vornehmen. Hr. Koch und viele IT-Projektleiter unterscheiden sinnvollerweise zwischen zwei verschiedenen Dokumenten:
  1. Fachliches Pflichtenheft
  2. IT-bezogenes Pflichtenheft
Beides mit dem Namen "Pflichtenheft" zu bezeichnen ist aus offensichtlichen Gründen gewagt, zumindest aus dem Gesamtzusammenhang betrachtet. Ich übertrage deshalb in die Begriffswelt des V-Modell XT:
  1. Anforderungen (Lastenheft) = Fachliches Pflichtenheft
  2. Gesamtsystemspezifikation (Pflichtenheft) = IT-bezogenes Pflichtenheft
Ich werde im folgenden die Begriffe Lastenheft (für das fachliche Pflichtenheft) und Gesamtsystemspezifkation (für das IT-bezogene Pflichtenheft) verwenden, um hier eindeutig darin zu bleiben, welche Dokumente ich jeweils meine.

Kommen wir nun zur versprochenen Erläuterung.

Der Auftragnehmer hat in der Regel ein Interesse, dass der Auftraggeber die Gesamtsystemspezifikation abnimmt. Dadurch möchte er das Risiko minimieren, bei der IT-spezifischen Implementierung Mängel einzurichten, die den Anforderungen des Auftraggebers zuwider laufen, aber erst auffallen, wenn das System ausgeliefert werden kann.

Der Auftraggeber wird in den meisten Fällen aber mindestens eine Abneigung gegen eine formale Abnahme der Gesamtsystemspezifikation haben. Schließlich müsste er damit bestätigen, dass diese "Auflistung erst einzulösender IT-spezifischer Vorgaben" (Koch) seinen Anforderungen entspricht. Dies ist aber sehr schwer, weil er das genau genommen erst an der erstellten Software prüfen kann.

Häufig setzt sich in dieser Situation der Vertragspartner mit der größeren Erfahrung, dem besseren Verhandlungsgeschick oder einfach dem umfassenderen "Organisationsapparat" mit entsprechender Reputation durch. D.h. es kommen in der Praxis beide Fälle vor, nämlich sowohl dass der Auftraggeber die Gesamtsystemspezifikation abnimmt, als auch dass er dies unterlässt.

Losgelöst von den praktischen Fragen, denen sich Auftraggeber und Auftragnehmer stellen müssen, ist auch die weitere Bedeutung einer Abnahmeerklärung über die Gesamtsystemspezifikation zu beachten. Eine ergänzende Abnahme der Gesamtsystemspezifikation macht die Sache sehr viel komplizierter, falls das gelieferte System später nicht den Erwartungen entspricht. Denn welches Dokument ist im Zweifelsfall dann verbindlich? Das vertraglich vereinbarte Lastenheft oder die abgenommene, später entstandene und damit ggf. aktuellere Gesamtsystemspezifikation?

Was die Vorgehensweise betrifft (Abnahme ja oder nein?) ist das V-Modell XT hier eindeutig, auch wenn ich zugeben muss, dass der Sachverhalt nicht explizit erläutert wird. Er ergibt sich stattdessen aus der Projektdurchführungsstrategie des Auftraggebers. Diese sieht nämlich vor, dass zunächst ein Lastenheft erstellt wird, später wird ein Vertrag geschlossen und die nächste formale Hürde ist die Abnahmeerklärung nach der Lieferung eines ersten Inkrements oder des fertigen Systems. Es ist keine Abnahme der Gesamtsystemspezifikation vorgesehen. Natürlich lässt das V-Modell XT dem Projektleiter die Freiheit, derartige Abnahmen im projekt-spezifischen Kontext trotzdem einzurichten.

Der Auftraggeber kann also die Bewertung, ob die Gesamtsystemspezifikation den Anwenderanforderungen entspricht, erst vollständig prüfen, wenn die erstellte Software vorliegt. Daher lautet Herrn Kochs Empfehlung (entsprechend der Vorgehensweise des V-Modell XT): Die Gesamtsystemspezifikation sollte "als integraler Teil der Erstellungs- oder Anpassungsleistung des Anbieters und nicht als getrennt abzunehmende Teilleistung behandelt werden".

Herr Koch nimmt auch eine Relativierung vor. (Diese Relativierung ist zwar nötig, aber auch der Grund, warum ich oben angemerkt habe, dass seine Antwort leicht falsch verstanden werden kann.) Anhand der oben genannten Begriffsabgrenzung können wir sehen, dass Pflichtenheft nicht gleich Pflichtenheft ist. Wenn es sich nämlich um ein fachliches Pflichtenheft, d.h. um ein Lastenheft handelt, dann empfiehlt Herr Koch dringend eine Abnahme des Dokuments durch den Auftraggeber, falls (und hier ist der zur Verwirrung führende Knackpunkt) der Auftragnehmer "aus zusätzlicher Beauftragung" dieses Dokument ebenfalls erarbeitet.

Das V-Modell XT hält hier einen eleganten Mechanismus parat, mit dem genau diese Vorgehensweise sauber abgedeckt ist, völlig egal, ob der Auftragnehmer bei der Erstellung des Lastenhefts beteiligt ist oder nicht. Der Auftraggeber durchläuft nämlich immer den Entscheidungspunkt Anforderungen festgelegt, bevor ein Vertrag geschlossen wird. Der Lenkungsausschuss des Projekts muss dann entscheiden, ob das Lastenheft als Vertragsgrundlage dienen kann, oder ob qualitative Mängel vorliegen. Im Fall einer externen Beauftragung der Lastenhefterstellung wird der Auftragnehmer bei Bereitstellung des fertigen Lastenhefts auf eine (Teil-)Vergütung bestehen, die erst nach eingehender Prüfung des Lastenhefts und der oben angesprochenen Abnahmeerklärung durch den Auftraggeber fällig wird.

Um den Entscheidungspunkt zu durchlaufen, muss also das Lastenheft fertig sein. Das Lastenheft kann erst als fertig gestellt betrachtet werden, wenn die Abnahmeerklärung an den Auftragnehmer gegangen ist. Die Abnahme des Lastenhefts ist in dieser Konstellation also die zwingende Grundlage für den Vertragsschluss.

Fazit und meine Empfehlung: als Auftraggeber sollte man sich nicht auf eine formale Abnahme der Gesamtsystemspezifikation einlassen. Dies sollte auch vertraglich so geregelt sein. Dringend empfehle ich aber dem Auftraggeber, sich die Gesamtsystemspezifikation vom Auftragnehmer zur Prüfung vorlegen zu lassen, damit Änderungshinweise Berücksichtigung finden können. Aber eben ohne Abnahmeerklärung. Das ist in beiderseitigem Interesse. Der Auftraggeber kann (und sollte) sich nach der Lieferung auf den Vertrag und damit die Anwenderanforderungen berufen. Und der Auftragnehmer trägt zwar das Realisierungsrisiko, aber das ist auch in anderen Branchen völlig normal und durch eine intensive Beteiligung des Auftraggebers während der Erstellung der Gesamtsystemspezifikation lässt sich dieses Risiko effektiv verringern.

Viele Grüße
Thomas Ternité

Quelle: Koch, Frank A.: IT-Projektrecht - Vertragliche Gestaltung und Steuerung von IT-Projekten, Best Practices, Haftung der Geschäftsleitung, Springer, 2007.

Mittwoch, 16. Mai 2012

V-Modell XT 1.4

Das V-Modell XT in Version 1.4 ist da!

Wie bisher lässt sich das neueste Release über die Webseite der Beauftragten der Bundesregierung für Informationstechnik beziehen: www.v-modell-xt.de

Was ist neu?

  • Zuordnung aller Rollen zu den Kategorien „Projektrolle“ und „Organisationsrolle“. Ab jetzt soll es keine Zweifel mehr geben, ob eine Rolle dem Projektleiter untersteht oder ob es sich um jemand projektexternen aus der Organisation handelt!
  • Die Werkzeuge (Export) sind nun kompatibel mit LibreOffice. Bei der Umstellung wurden auch einige Verbesserungen in der Kommunikation des Exports mit OpenOffice/LibreOffice umgesetzt. Der Export sollte nun noch zuverlässiger laufen!
  • Für die Prozessingenieure unter uns: es gibt jetzt eine bessere Unterstützung für Prozessingenieure durch bereitgestellte Skripte für die Automatisierung von Exporten etc. Diese Skripte befinden sich in den Installationsverzeichnissen der Werkzeuge. 
  • Vieles an der Darstellung ist verbessert worden.
  • Viele kleine Bugfixes und Unschönheiten wurden beseitigt.
  • Wer Lust hat, kann sich eine lange Liste von Änderungen in den Release Notes ansehen.
Gibt's Änderungsvorschläge? Die offizielle Kontaktadresse hierfür lautet: ccb@v-modell-xt.de

Sonntag, 26. Februar 2012

V-Modell-Export mag keine Zeilenumbrüche

Im V-Modell XT (Version 1.3) gibt es keinen einzigen Zeilenumbruch: genauer gesagt wird im gesamten Modell kein einziger <br>-Tag verwendet, um einen einfachen Zeilenumbruch zu markieren; stattdessen werden immer Absatzwechsel mit <p>-Tags vorgenommen. Deshalb fällt auch nicht auf, dass der V-Modell-Export HTML-Inhalte mit <br>-Tags überhaupt nicht anzeigt. Grund dafür ist, dass der V-Modell-Editor <br>-Tags produziert, während der V-Modell-Export XHTML-konforme <br/>-Tags erwartet.

Bis dieser Fehler behoben ist, kann man sich aber durch einen Workaround behelfen. Hier finden sich zwei XSL-Templates, die man in die Datei global.xsl einfügen muss. Danach muss man alle Skriptinhalte in den Export-Templates, die folgendes Muster aufweisen

<reinterpret>
<xsl:value-of select="ElementXY"/>
</reinterpret>

durch dieses Muster ersetzen:

<reinterpret>
<xsl:call-template name="replace-br-tag">
<xsl:with-param name="string" select="ElementXY"/>
</xsl:call-template>
</reinterpret>

Das Template replace-br-tag ersetzt dabei alle <br>-Tags durch <br/>-Tags und der Export funktioniert korrekt.

Mittwoch, 15. Februar 2012

Neue Excel-Vorlage für Risikoliste

Wir haben die bewährte Excel-Vorlage weiterentwickelt. Die Einfärbung der Risiken ist jetzt leicht verändert und richtet sich nach den Vorschlägen des BMI zum Risikomanagement im Organisationshandbuch, die auch im V-Modell XT Bund verwandt wird.

Außerdem wird die Risikoverteilung grafisch in einer Risikomatrix angezeigt - gut geeignet, um sie beispielsweise in einen Projektstatusbericht zu kopieren:


Die Risikoliste gibt es hier.

V-Modell-Export hat Probleme mit Umlauten

Wenn beim Export der V-Modell-Dokumentation das hier


Ein Fehler ist aufgetreten:
(Beim Export ist ein Fehler aufgetreten:
Fehler bei der initialen OpenOffice-Transformation: Fehler bei der Auswertung der
Modelldaten: Die Formatvorlage konnte nicht kompiliert werden.(null))

erscheint, kann es u.U. dran liegen, dass sich Umlaute im Pfadnamen befinden. Als einfacher Workaround bietet es sich an, den Ablageort entsprechend zu ändern.

Montag, 9. Januar 2012

Vorschau auf das nächste V-Modell-XT-Release

Auf der Seite

http://www.weit-verein.de/next-release.html

befindet sich seit letzter Woche eine Vorschau auf das nächste
V-Modell-XT Release. Diese Vorschau wird natürlich kontinuierlich bis zur
Herausgabe des nächsten Releases gepflegt und ergänzt.