Rund ums V-Modell XT

V-Modell XT – neues Release 2.2

2018-07-03T14:30:00.001+02:00

Seit Kurzem ist das neue Release 2.2 veröffentlicht (siehe http://www.v-modell-xt.de).

In der neuen Version wurden schwerpunktmäßig die im Modell enthaltenen Vorgaben zur Gewährleistung der Informationssicherheit überarbeitet. Darüber hinaus enthält die Version 2.2 Änderungen in den Bereichen Datenschutz und IT-Betrieb.

Alle Änderungen sind auch in den begleitenden Release Notes aufgeführt:
http://ftp.tu-clausthal.de/pub/institute/informatik/v-modell-xt/Releases/2.2/Release%20Notes/Release%20Notes.html

V-Modell XT ORG

2017-06-26T11:59:00.000+02:00

Mit der Version 2.1 wurde das im V-Modell XT enthaltene Verfahren für die Einführung und Pflege organisationsspezifischer Vorgehensmodelle entfernt und als eigenständiges Modell (V-Modell XT ORG) realisiert. Das V-Modell XT ORG beschreibt, wie ein organisationsspezifisches Vorgehensmodell eingeführt und kontinuierlich verbessert werden kann. Die Struktur des Modells sowie die Semantik der einzelnen Modellelemente entsprechen denen des V-Modell XT.

Zum Lieferumfang des V-Modell XT ORG gehören

§ die Modelldateien,

§ die Dokumentation im PDF- und HTML-Format,

§ die Werkzeuge V-Modell XT Projektassistent und V-Modell XT Editor sowie

§ die Produktvorlagen im ODT-Format.

Das V-Modell XT ORG wird als ZIP-Archiv bereitgestellt und kann unter nachfolgendem Link heruntergeladen werden:

http://ftp.tu-clausthal.de/pub/institute/informatik/v-modell-xt/Releases/2.1-Org/V-Modell_XT_ORG.zip

V-Modell XT – neues Release 2.1

2017-06-26T11:57:00.002+02:00

Seit Kurzem ist das neue Release 2.1 veröffentlicht (siehe http://www.v-modell-xt.de).

Alle Änderungen sind in den begleitenden Release Notes aufgeführt:
http://ftp.tu-clausthal.de/pub/institute/informatik/v-modell-xt/Releases/2.1/Release%20Notes/Release%20Notes.html

Neues Release 2.0 veröffentlicht

2015-08-26T12:18:00.002+02:00

Das V-Modell XT in Version 2.0 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?

Das V-Modell XT besitzt eine völlig neue Einleitung und die Struktur der Dokumentation wurde mehr am Bedarf des Anwenders orientiert.
Einige wichtige Strukturelemente (Disziplinen, Vorgehensbausteine, Produktabhängigkeiten) wurden im V-Modell XT besser integriert, so dass der Anwender deren Konzepte nicht verstehen muss, um bei der Anwendung einen Nutzen daraus zu ziehen.
Der Export wurde optisch schöner und technisch stabiler gemacht.
Außerdem wurden einige Problem- und Änderungsmeldungen umgesetzt, die das CCB des V-Modell XT gesammelt und priorisiert hat. 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

Weiterer Vorgeschmack

2014-09-12T12:43:00.001+02:00

Die Titelseite wird auch neu gestaltet und richtet sich im Layout an bestehenden V-Modell-Varianten (VMXT Bund, VMXT ZIVIT) aus.

VMXT Farbschema

2014-09-12T12:34:00.000+02:00

Es ist immer wieder aufwändig, die einzelnen im V-Modell verwendeten Farbwerte (RGB) aus den Visio-Dateien herauszusuchen. Deswegen hiermit endlich im Überblick (inkl. der Verwendung/Semantik):

VMXT 1.5/2.0 kommt...

2014-05-19T21:17:00.001+02:00

Letztes Jahr haben TU Clausthal, TU München, Siemens und die 4Soft im Auftrag des Weit e.V. einen großen Verbesserungsschritt für das V-Modell XT konzipiert. Zentrale Anforderung ist ein verbesserter Zugang des Modells, also insbesondere auch eine verbesserte Struktur und eine bessere Darstellung. Gerade läuft die Umsetzung auf Hochtouren - hier schonmal ein Vorgeschmack was kommt.

Achtung: Das Bild ist noch ohne Gewähr, praktisch frisch aus der Entwicklung.

Header in Produktvorlagen falsch

2014-04-25T11:09:00.001+02:00

Die mit dem V-Modell XT 1.4 ausgelieferte LibreOffice-Version hat(te) einen unschönen Bug: Beim Konvertieren ins DOC-Format wird die Kopfzeile der ersten Seite auch auf alle anderen Seiten angewendet. Dadurch werden beispielsweise die vom Projektassistenten generierten Produktvorlagen (DOC-Format) fürs V-Modell XT Bund nicht korrekt erzeugt.

Die Abbildung zeigt, wie das Dokument eigentlich aussehen sollte (links), wie es bei der Konvertierung durch LO ins DOC-Format erscheint (Mitte) und was passiert, wenn man eine erzeugte ODT-Datei direkt mit Word 2010 öffnet (rechts). Als Word-Nutzer ist das alles nicht so optimal... Der Bug ist aber mittlerweile behoben, wie folgende Abbildung zeigt; lediglich die Konvertierung des Tabellenformats scheint noch nicht so 100%ig zu funktionieren:

Als Lösung kann man also einfach die neueste LO-Version herunterladen und dem Projektassistenten beim Export den entsprechenden Pfad mitteilen. Eine Alternative als Word-Nutzer wäre es, sich ODT-Dateien generieren zu lassen und diese online zu konvertieren, z.B. hier.

Was ist zu tun, wenn ein neues Release herauskommt und ich nicht auf meiner alten organisationsspezifischen Anpassung sitzen bleiben will?

2013-12-02T10:41:00.000+01:00

Bei der Beantwortung dieser Frage haben sich nachfolgende Prozessschritte als hilfreich erwiesen:

1. Zunächst muss geprüft werden, inwieweit sich das Metamodell zur vorherigen Version verändert hat. In Release 1.4 sind beispielsweise Rollenkategorien im Metamodell eingeführt worden. Um Datenverluste zu vermeiden müssen auch organisationspezifische Rollen einer Rollenkategorie zugeordnet werden. Weitere Hinweise finden sich auch unter: http://vmxt.blogspot.de/2012/10/migration-organisationsspezifisches-v.html.

2. Im Vergleich zwischen Release x und Release x+1 sollten die Dateien identifiziert werden, die

geändert wurden
inzugefügt wurden
gelöscht wurden

Ein hilfreiches Softwarewerkzeug für den Vergleich der Modellordner ist z.B. KDiff3. Für jede dieser Dateien muss eine Überprüfung erfolgen, wenn sie im Ordner des Erweiterungsmodells enthalten ist.

Falls beispielsweise Bilder oder ODT Templates aus dem Standard in früheren Releases organisationsspezifisch angepasst wurden, muss überprüft werden, ob sich diese im Standardmodell verändert haben.

3. Editor:

Lässt sich das Modell mit dem V-Modell XT Editor öffnen?
Lässt sich das Modell exportieren?

Möglicherweise wurde nur ein Format bei der Bearbeitung geprüft. PDF und HTML sollten aber beide auf offensichtliche Fehler hin geprüft werden.

4. Projektassistent:

Lässt sich ein neues Projekt mit dem V-Modell XT Projektassistenten öffnen?
Sind alle Projekttypen, Projekttypvarianten und Projektmerkmale auswählbar?
Lässt sich das getailorte Projekt exportieren (alle Formate)?
Sind alle Vorlagen vorhanden?
Können die Vorlagen exportiert werden?
Lässt sich ein Projektplan erstellen?
Lässt sich der Projektplan exportieren und von der aktuellen Version von MS Project oder anderer in der Organisation verwendeten Tools öffnen?

5. Unter den Release Notes des Standardmodells findet sich eine Übersicht der Änderungen zum Vorgängerrelease. Alternativ können auch die konkreten Problem- und Änderungsmeldungen, die in einem konkreten Release umgesetzt wurden eingesehen werden unter:

https://vmod.rz-housing.tu-clausthal.de/ccb/

Man sollte nun überprüfen, ob die Änderungen auch für die organisationsspezifische Anpassung relevant sind. Falls dies der Fall ist, muss überprüft werden, ob diese Änderungen bereits integriert sind oder ob diese Änderungen manuell nachgezogen werden müssen.

6. Sichtprüfung: Man sollte sich die Zeit nehmen, einmal die Gesamte PDF Dokumentation in angebrachter Geschwindigkeit durch zu scrollen. Folgende Dinge sollten dabei überprüft werden:

Fehlen relevanten Seiten/Kapitel?
Sind die Bilder vernünftig dargestellt?
Gibt es sonstige Auffälligkeiten (z.B. fehlerhafte Referenzen, Abbildungsunterschriften ohne Abbildungen)
Der Rollenindex und der Produktindex der aktuellen migrierten Version sollten mit der organisationsspezifischen Vorgängerversion verglichen werden.
Bei der HTML Dokumentation sollten diese Fragen stichpunktartig ebenfalls überprüft werden.

Problem-/Änderungsmeldungen einsenden und ansehen

2013-11-04T16:35:00.002+01:00

Die Entwickler des V-Modell XT sind an den Vorschlägen und Wünschen der Anwender sehr interessiert. Die Änderungswünsche werden bewertet und in neue Versionen des V-Modell XT eingearbeitet. Aus diesem Grund haben die Anwender die Möglichkeit, selbst Änderungs- anträge zu formulieren und in den Entwicklungsprozess einzubringen. Dazu können Sie Änderungsvorschläge per E-Mail über die Änderungssteuerungsgruppe des WEIT e.V. an die Entwickler senden. Sie können Fehler melden, aber auch Verbesserungsvorschläge machen.

Eine wichtige Aufgabe des WEIT e.V. ist die kontinuierliche Weiterentwicklung und Pflege des V-Modells XT, um seine Aktualität, Akzeptanz und langfristige Werterhaltung und -steigerung zu garantieren. Deshalb werden Erfahrungen aus dem praktischen Einsatz des V-Modell XT und neue wissenschaftliche Erkenntnisse ständig in das V-Modell XT integriert. Dies wird durch die Definition und Umsetzung wirkungsvoller Prozesse für die Pflege und Weiterentwicklung erreicht. Diese Prozesse gewährleisten insbesondere folgende Punkte:

Aktualisierte V-Modell XT Versionen werden allen Anwendern kostenfrei bereitgestellt.
Die Änderungssteuerungsgruppe des WEIT e.V. kontrolliert inhaltlich die Weiterentwicklung und Pflege des V-Modell XT.

Die Kosten für die Pflege des V-Modells XT werden durch die Mitgliedsbeiträge des WEIT e.V. gedeckt.

Problem- und Änderungsmeldungen bitte senden an: ccb@v-modell-xt.de

ACHTUNG NEU!!!:

Einen aktuellen Stand der Problem- und Änderungsmeldungen des V-Modell XT können Sie hier nun einsehen:

https://vmod.rz-housing.tu-clausthal.de/ccb/

Das methodenneutrale V-Modell XT

2013-01-17T08:02:00.000+01:00

Im Rahmen einer Dissertation zum Thema "Wissensmanagement in der Softwareentwicklung" mit speziellem Fokus auf die Einbindung des V-Modell XT wurde uns folgende Frage gestellt:

Wird von Seiten des WEIT e.V. oder des IABG bereits (oder in Planung) an einem Wissensmanagementsystem für das V-Modell XT gearbeitet wird, oder ob nur eine entsprechende Schnittstelle für Wissensmanagementaktivitäten im V-Modell bereitgestellt wird?

Unsere Antwort ist folgende:

Das V-Modell XT beschreibt als Vorgehensmodell vornehmlich, WAS durch WEN in welcher Reihenfolge erstellt wird. Es handelt sich also um eine erzeugnis- und rollenzentrierte Vorgehensbeschreibung.

WIE die Erarbeitung der Erzeugnisse erfolgt, ist durch das V-Modell XT nur durch sog. "Aktivitäten" beschrieben. Diese Aktivitäten beschreiben aber letztlich auch nur, welche Tätigkeiten anfallen, aber nicht WIE diese durchzuführen sind.

So erhalten die Nutzer des V-Modell XT beispielsweise Hinweise darauf, dass eine Schätzung an geeigneter Stelle durchgeführt werden muss. Welche Verfahren (V-Modell-Begriff: welche Methoden) dazu eingesetzt werden, entscheiden die Nutzer.

Aus diesem Grund macht das V-Modell XT auch keine Vorgaben bezüglich Werkzeugen. Ob nun MS Project, Excel oder Pen&Paper für den Projektplan eingesetzt wird, bleibt den Nutzern überlassen. Wichtig ist, dass bei der Projektplanung die Aspekte berücksichtigt werden, die das V-Modell aufzeigt (z.B. Planung der Qualitätssicherung, planen von Schulungen etc.).

Vor dem Hintergrund ist der methodische Fundus, den das V-Modell mitbringt, natürlich sehr begrenzt. Der Lieferumfang des V-Modell XT enthält nur zwei Softwarewerkzeug: Den V-Modell XT Projektassistenten, der das Verfahren für das Tailoring des V-Modells implementiert und den V-Modell XT Editor zum Anpassen des V-Modells für Prozessingenieure.

Das V-Modell XT liefert also nur die nötigen Methoden und Werkzeuge an die Hand, um das V-Modell an die Bedürfnisse des Projekts anzupassen.

Genau so verhält es sich in Bezug auf das Wissensmanagement. Welche Systeme, Werkzeuge und Methoden für ein Entwicklungsprojekt benötigt werden, muss vom Projektleiter oder dem für Wissensmanagement verantwortlichen Projektmitarbeiter entschieden werden.

Da das V-Modell kein "Allroundpaket" ist, müssen bei der Anwendung des Modells Eigenleistungen getroffen werden. Die Auswahl der richtigen Werkzeuge (z.B. Wissensmanagementsystem) und der richtigen Methoden (z.B. welche Schätzmethoden setzen wir ein) ist stark projekt- und unternehmensspezifisch. Das V-Modell macht diesbezüglich keine Vorgaben, weil: was für ein Unternehmen passt, wird von einem anderen Unternehmen abgelehnt. Um hier für ALLE anwendbar zu bleiben, wurde bei der Entwicklung des V-Modells entschieden, "methodenneutral" zu bleiben.

Deshalb ist diesbezüglich auch nichts in Planung und wird es in absehbarer Zeit auch nicht sein. Derartige Bestrebungen (ein Vorgehensmodell mit vollintegrierter Systemlandschaft) spielen vom
Erstellungs- und Einführungsaufwand her in einer völlig anderen Liga (siehe z.B. IBM Rational Unified Process (RUP)).

Fourever auf Sourceforge umgestellt

2013-01-16T15:52:00.000+01:00

In dieser Woche wurde die Sourceforge-Seite des Foureverprojekts (V-Modell XT Projektassistent und Editor) erfolgreich auf die neue Allura Plattform umgestellt.

Es erschien uns sinnvoll, dass wir diesen Schritt selbst durchführen, da das alte Sourceforge in bekannter Form bald durch Allura vollständig abgelöst werden soll. Möglicherweise wäre die Umstellung zukünftig sonst erzwungen worden.

Im Zuge der Umstellung wurde das SVN Repository an eine andere Stelle verlagert. Das neue SVN Repository befindet sich nun unter:

svn://svn.code.sf.net/p/fourever/code/

Das CVS Repository bleibt wie gehabt.

Migrationserfahrung:
Am einfachsten und schnellsten ist ein SVN "Relocate" unter Angabe des neuen SVN Pfads.
Eine andere Möglichkeit ist das neu Auschecken des SVN Repositorys.

Einzige Unschönheit ist das es noch Layout Inkonsistenzen gibt:
Die Themen: Summary, Files, Reviews und Support werden noch im alten Sourceforge Layout dargestellt.
Alle anderen im neuen Layout.

Diese Unschönheit ist den Entwicklern von Allura bekannt:
https://sourceforge.net/p/allura/tickets/4945/
https://sourceforge.net/p/forge/site-support/1136/

Wir möchten gerne, dass diese Inkonsistenz möglichst bald behoben wird. Deshalb bitten wir alle unter dem ersten Ticket Link ein "up vote" zu vergeben, um ein schnelles debugging anzustoßen.

Das Leiden hat einen Namen: Java 7

2012-11-12T19:14:00.003+01:00

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.

Migration organisationsspezifisches V-Modell 1.3 nach 1.4

2012-10-01T14:11:00.000+02:00

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é

Abnahme des Pflichtenhefts durch den Auftraggeber?

2012-09-11T12:04:00.002+02:00

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:

Fachliches Pflichtenheft
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:

Anforderungen (Lastenheft) = Fachliches Pflichtenheft
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.

V-Modell XT 1.4

2012-05-16T14:19:00.000+02:00

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

V-Modell-Export mag keine Zeilenumbrüche

2012-02-26T23:10:00.001+01:00

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

Neue Excel-Vorlage für Risikoliste

2012-02-15T23:25:00.007+01:00

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

2012-02-15T16:42:00.002+01:00

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.

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

2012-01-09T11:52:00.003+01:00

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.

V-Modell XT Editor für Künstler

2010-09-05T11:00:00.004+02:00

Das V-Modell XT kommt bereits mit einigen Referenzwerkzeugen für die Bearbeitung des V-Modells und den Projektstart. Insbesondere die Bearbeitung des V-Modells ist nicht trivial. An der TU München gibt es seit einiger Zeit ein Projekt, das sich mit domänenspezifischen Sprachen und im Speziellen mit der Modellierung von Prozessmodellen auf dieser Basis befasst. Als erstes Ergebnis liegt das Process Development Environment (PDE) vor. Dieses ist zunächst eine generische Modellierungsplattform, das für die Entwicklung von editierbaren Metamodellen ausgelegt ist und die einfache Ableitung grafischer Editoren unterstützt. Als erste Referenzimplementierung wurde ein alternativer V-Modell XT Editor erzeugt.

Dieser Editor gestattet die Bearbeitung des V-Modells in gewohnter Weise, bietet darüber hinaus jedoch auch grafische Editoren (z.B. für das grafische Modellieren von Ablaufbausteinen) an:

Weiterhin bietet der Editor viele weitere Features, die über den Funktionsumfang der Standardwerkzeuge hinausgehen:

erweiterte Prüfmechanismen
Drag & Drop-Funktionen
Suche
...

So wird z.B. das Tailoring ebenfalls durch eine integrierte grafische Benutzerschnittstelle unterstützt, die alle relevanten Komponenten für das Tailoring erfasst und die Konsistenz der Auswahl prüft (z.B. ob für einen konfigurierten Ablaufbaustein auch die erforderliche Ablaufbausteinspezifikation eingebunden wurde:

Hinweis

PDE liegt in der ersten Version auf Codeplex (http://pde.codeplex.com) vor und ist noch im Status einer Entwicklungsversion. PDE ist noch nicht auf Geschwindigkeit und Effizienz optimiert. Jedoch ist die Software schon in der Erprobung (z.B. im Rahmen der Bearbeitung des V-Modell XT Bund oder bei weiteren (internen) Projekten).

Technisches

PDE ist vollständig in .NET auf Basis der Microsoft DSL-Tool Kits entworfen und implementiert. PDE liegt vollständig im Quelltext vor und steht unter der Apache 2.0 Lizenz.

Zur Ausführung des PDE-V-Modell-XT-Editors benötigen Sie:

Microsoft .NET 4.0 SDK/Framework
Visual Studio 2010 (optional, empfohlen)
Installierte V-Modell XT Referenzwerkzeuge (PDE benötigt diese für den Export)

Für die Entwicklung von PDE/PDE-Erweiterungen benötigen Sie:

Visual Studio 2010
DSL-Tool Kit
weitere SDKs (siehe PDE-Webseite)

PDE ist ein offenes und erweiterbares Framework. Die Mitarbeit ist herzlich willkommen.

V-Modell XT Bund steht vor der Tür

2010-03-08T20:25:00.001+01:00

Voraussichtlich noch in dieser Woche wird die Bundesstelle für Informationstechnik (BIT) das V-Modell XT Bund auf ihrer Webseite veröffentlichen. Dabei handelt es sich um eine behördenspezifische Erweiterung des V-Modell XT. Das V-Modell XT Bund bietet die Integration mit anderen Bundesstandards, behördentypische Rollen, Dokumente im Corporate Design des Bundes, Dokumentvorlagen mit vordefinierten Texten und die Abstimmung mit dem IT-Betrieb schon während der Entwicklung.

Auftraggeber der Entwicklung war die Beauftragte der Bundesregierung für Informationstechnik (kurz: Bundes-CIO). Das Projekt haben wir bei der 4Soft zusammen mit unseren Partnern MID und akquinet im Rahmen des 3-Partner-Modells durchgeführt.
Erste behördeninterne Reviews waren durchweg positiv. Als Projektleiter bin ich jetzt natürlich gespannt, wie das V-Modell XT Bund in der "breiten Öffentlichkeit" ankommt.

Ping-Prüfung bestanden!

2010-02-17T16:23:00.012+01:00

Letzte Woche kam die gute Nachricht: Prüfung bestanden!

Lieber Herr Lewitz,
Es freut mich Ihnen mitteilen zu dürfen, dass Sie die Prüfung bestanden haben. Sie haben insgesamt 92 Punkte erhalten.
Mit freundlichen Grüßen
Doris Rauh

Worum geht's?

Im Januar hatte ich die freudige Gelegenheit, bei Frau Rauh und drei weiteren Kollegen in den Räumen der 4Soft in München in die höheren Weihen der V-Modell XT Modellierung eingeführt zu werden. Ich bin jetzt zertifizierter V-Modell XT Prozessingenieur, ein sogenannter V-Modell XT Ping — und zwar einer der ersten.

Ping - das Zertifikat

Das Zertifikat V-ModellXT Ping (Zertifizierter V-ModellXT Prozessingenieur) bescheinigt das notwendige Wissen, um das V-Modell XT anzupassen, V-ModellXT Anpassungen bzgl. ihrer Konformität beurteilen und zertifizierte Ausbildungsschulungen V-Modell XT Pro(fis) durchführen zu können.

Klingt erstmal nicht so fürchterlich aufregend?

Das Vorgehensmodell

Das V-Modell XT ist ein allgemeiner Vorgehensstandard, der für die konkrete Anwendung angepasst werden kann und zumindest konkretisiert werden muss. Führt eine Organisation häufiger Projekte mit dem V-Modell XT durch, ist es sinnvoll, solche Änderungen nicht
in jedem Projekt von Neuem zu definieren, sondern gleich eine Anpassung für die gesamte Organisation vorzunehmen. Dabei stellt sich die Frage: Welche Anpassungen darf man vornehmen, wenn das Ergebnis noch als V-Modell XT erkennbar sein soll?

Die Verwendung des V-Modell XT wird insbesondere Auftragnehmern der öffentlichen Hand, z.B. bei Ausschreibungen, vorgeschrieben. Hat nun eine Firma bereits ein eigenes Vorgehensmodell, was sich vielleicht an einem anderen Standard als dem V-Modell XT orientiert, muss Sie dann in solchen Projekten ein anderes Vorgehen verwenden als das in der Firma bewährte und den Mitarbeitern bekannte? Dies würde die Qualität gefährden und die Kosten erhöhen. Wie kann also nun die Firma nachweisen, dass ihr eigenes Vorgehen den Ansprüchen des V-Modell XT genügt?

Diese Fragen beantwortet die V-Modell XT Konformitätsprüfung. Wie man eine solche durchführt und welche Kriterien dabei zu beachten und wie Vorgehensmodelle zu bewerten sind, war ein wesentlicher Teil der Schulung.

Frau Rauh und ihre Kollegin Marion Wittmann (beide von Siemens) brachten uns in zwei intensiven Tagen dieses an sich ja recht trockene Thema anschaulich näher. Sie haben es sogar geschafft, unsere Aufmerksamkeit für die vielen Details kontinuierlich aufrecht zu erhalten ;-).

Und wie verändert man das V-Modell XT?

Möchte eine Organisation das V-Modell XT an die eigenen Bedürfnisse anpassen, so steht dafür ein mit dem V-Modell XT geliefertes Open-Source-Toolset zur Verfügung. Der V-Modell XT Editor ermöglicht das vollständige Bearbeiten sämtlicher Inhalte des V-Modell XT.

Unabdingbare Voraussetzung für die Anpassung ist jedoch das Verständnis des Metamodells, in dem das V-Modell XT abgebildet ist. Hier gilt es viele Begriffe zu lernen: von Vorgehensbausteinen über Projekttypen und Projekttypvarianten bis zu Ablaufbaustein-spezifikationen und Produktabhängigkeitsbeziehungen... Die Länge der verwendeten Begriffe ist hier durchaus ein Indiz für die dahinter stehende Komplexität!

Jan Friedrich von 4Soft und Marco Kuhrmann von der TU München haben uns in der zweiten Hälfte des Kurses mit großer Begeisterung in diese Begriffs-Welt geführt und uns dabei auch die Bedienung des Editors nahegebracht. Ebenso wie bei Frau Rauh und Frau Wittmann war es sehr begeisternd, scheinbar unerschöpfliche Quellen des Wissens vor sich zu haben!

Praktisch hat mich an der Anpassung insbesondere die Möglichkeit fasziniert, über bestimmte vordefinierte Änderungs- und Erweiterungsoperationen das Modell nicht direkt bearbeiten zu müssen. Man kann die organisationsspezifischen Änderungen in einem eigenen Modell halten und diese mit Hilfe des Editors mit dem Standard-Modell zusammenführen. Das vereinfacht natürlich die Prüfung der Konformität und ermöglicht es theoretisch, seine Änderungen auch für zukünftige Versionen des V-Modell XT zu übernehmen. Ich hatte von dieser Idee schon gehört, sie aber vor dieser Schulung für graue Theorie ohne Praxisbezug gehalten — nun scheint sie mir tatsächlich sehr nützlich.

Praxisbezug

Kein Licht ohne Schatten: Bei allem Lob für die vier Lehrenden muss ich einige Kritikpunkte an der Methode und den durch den WEIT-Verein gegebenen Rahmenbedingungen anbringen:

Den für die Prüfung der Konformität gewählten Ansatz der Abbildung aller V-Modell XT Details auf Elemente des organisationsspezifischen Prozesses halte ich für nicht praxistauglich. Die Durchführung ist zu aufwändig, die Ergebnisse schwer vermittelbar. Der ganze Ansatz ist sehr akademisch — es handelt sich auch um eine reine Papier-Prüfung.
Es sind keine Möglichkeiten vorgesehen, organisationsspezifisch Teile des V-Modell XT wegzulassen, während das projektspezifisch (mit Begründung) durchaus erlaubt ist. Das widerspricht sämtlichen Bemühungen zur organisationsweiten Standardisierung. Wir haben in der Schulung einen Ausweg aus diesem Dilemma gefunden, für den aber noch eine Umsetzung erforderlich ist.
Es gibt für den Absolventen der Schulung (den Ping) noch keine Möglichkeit, die gewonnenen und geprüften Fähigkeiten in die Praxis umzusetzen. Theoretisch könnte ich jetzt V-Modell XT Pros ausbilden, dafür müsste aber meine Firma microTOOL noch eine höhere Weihe als Organisation bekommen. Das Verfahren dafür ist aber noch nicht definiert. Für die Prüfung der Konformität gilt ähnliches. Es ist, als hätte ich einen
Führerschein für eine neue Fahrzeugklasse erworben, deren Zulassungsverfahren aber noch nicht organisiert ist.
Die Tool-Unterstützung ist noch mangelhaft. Die Konformitätsprüfung ist mit Hilfe von Excel-Sheets durchzuführen, in die sämtliche Produkte, Themen, Abhängigkeiten und Entscheidungspunkte des V-Modell XT eingetippt werden müssten — diese müssen noch erarbeitet werden. Der V-Modell XT Editor ist ein gutes Experten-Tool, aber seine Usability z.B. in Sachen Konsistenzprüfung des eingegebenen Prozesses lässt stark zu wünschen übrig. Für jemanden, der nicht täglich V-Modell XT Prozesse bearbeitet, ist das eine große Herausforderung.

So ist das, wenn man zu den Ersten gehört - manches ist noch nicht ganz fertig. Ich glaube, die Prüfung der Konformität ist ein wichtiger Schritt, um einer allgemeineren Nutzung des V-Modell XT näher zu kommen. Und das Verteilen der Ausbildungsverantwortung für die V-Modell XT Pro(fis) auf mehrere Paar Schultern schafft den V-Modell XT Experten im WEIT-Verein hoffentlich etwas Luft, um das Modell für uns alle inhaltlich weiterzuentwickeln.

Fazit

Es war eine wunderbare, intensive Woche mit sehr guten Referenten und interessanten Teilnehmern. Wir haben alle viel Neues gelernt und Erfahrungen in der Prozessdefinition und -umsetzung ausgetauscht. Ein großes Lob an die 4Soft für Location und Catering und natürlich unseren vier „Lehrern": Doris Rauh, Marion Wittmann, Jan Friedrich und Marco Kuhrmann. Ich wünsche uns allen viel Erfolg beim Vertiefen der gewonnenen Einsichten!

SEE2010 Programm veröffentlicht

2010-01-27T13:00:00.005+01:00

Das Programm der SEE2010 ist fertig! Das Programmkomitee hat in den letzten Wochen eine überwältigende Anzahl von 79 Vorschlägen für Präsentationen gelesen und bewertet. Die hohe Qualität der Einreichungen hat die Organisatoren veranlasst, einen weiteren Track zu eröffnen, um noch mehr Vorträge ins Programm aufnehmen zu können. Das Ergebnis lässt sich sehen: in 42 Vorträgen berichten Experten aus allen Anwendungsgebieten über neue Trends, spannende Erfahrungen und Wissenswertes aus dem Systems Engineering. Ganz nach dem Motto "Erfolgreich mit Standards" berichten viele Sprecher über die Einführung, die Anwendung und die Umsetzung von organisationsweiten Vorgaben.

Mehr auf der Webseite zur Konferenz: www.see-conf.de

SEE 2010: Aufruf zur Teilnahme

2009-11-02T18:30:00.003+01:00

Der Startschuss für die SEE 2010 ist gefallen: am 3. und 4. Mai 2010 findet die größte deutschsprachige Konferenz zu Vorgehensmodellen, Methoden und Techniken in der Systementwicklung im Marriot Hotel in Köln statt. Natürlich wird es um das V-Modell XT gehen aber ebenso um andere Standards der Systementwicklung und Möglichkeiten, deren Einhaltung nachzuweisen. Das Motto im nächsten Jahr lautet daher "Erfolgreich mit Standards".

Wer einen eigenen Beitrag zur Konferenz leisten möchte, findet den "Call for Contribution" auf der Konferenzseite.