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

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

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

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

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.