mail 0665

Sehr geehrte V-Modell-Gemeinde,

als ein Kollege, der an der Erstellung des V-Modell'97 im Bereich
Methodenzuordnung mitgewirkt hat und heute hauptsächlich im Kontext
V-Modell-Beratung tätig ist, möchte ich einige Anmerkungen zu den bisherigen
Mails, speziell Nr 662 (Hr. Strixner), machen:

1)
>Wie aus den Artikeln deutlich wird, besteht die Möglichkeit Elemente aus XP auf
>das V-Modell abzubilden. Also müsste es nur noch  Methodendefinitionen
>Methodenzuordnung. Dann wäre es möglich V-Modell konform XP zu
>betreiben.
Es erscheint mir sehr gefährlich, XP auf die Stufe von Elementarmethoden zu
stellen (zu reduzieren). Dies wäre wohl technisch "möglich", würde im
Ergebnis wohl kaum den Grundwerten von XP (bzw. der agilen
Software-Entwicklung) entsprechen. Die meisten Beteiligten nehmen von XP nur
die Techniken wahr. Dahinter steht jedoch eine bestimmte Philosophie. Das
erfolgversprechende an XP ist die Philosophie und nicht die Techniken.
(Siehe auch Mail Nr 652 Hr Linsen)

2)
>** FRAGE AN DIE EXPERTEN: Gibt es solche Bestrebungen? XP als Methodendefinitionen?
Halte ich nicht für den richtigen Weg. Wobei ich zugebe, das einzelne (!!)
Techniken durchaus gewinnbringend integriert werden könnten.
HINWEIS: Laut mehreren XP-Experten wird XP hauptsächlich durch EINE Technik
agil (Zitat Ende):
* Tuning Workshops
Tuning Workshops haben das Ziel, eine kontinuierlich Prozessverbesserung
bzw. Prozessdefinition zu erreichen. Hier wird nach jeder Iteration (max. 4
Wochen) eine Feedbackrunde mit allen Projektmitarbeitern durchgeführt und
der Prozess ggf. verändert / definiert. Wohlgemerkt es wird KEINE
Prozessüberprüfung im Sinne von QS 3 durchgeführt, ganz im Gegenteil.

3)
>** FRAGE AN DIE EXPERTEN: Steht das V-Modell mittlerweile auf dem
Studienprogramm der angehenden Informatiker in Deutschland? Oder eher RUP / XP?
Hm, in meinem Beratungsalltag treffe ich viele Kollegen und Kolleginen, die
Software oder Systeme entwickeln. Jeder/jede kann meist mehrere
Programmiersprachen (aus Studium oder berufl. Weiterbildung). Wenige kennen
jedoch Entwicklungsprozesse (egal welchen). Aber ich kann Ihnen meine
Vortrags-Erfahrung hierzu berichten. Da ich regelmäßig auf Konferenzen (z.B.
OOP) / Seminaren zu dem Thema "Entwicklungsprozesse" oder "V-Modell vs. RUP"
vortrage, habe ich festgestellt, das in der Gemeinde der Prozesskenner die
Anzahl der V-Modell-Anwender immer noch um den Faktor 2-3 grösser ist, als
die Anzahl der RUP-Anwender.

4)
>* Fazit aus der Diskussion
>- V-Modell und XP ist möglich 
So ohne weiteres nicht (nach meiner Meinung). Ein "agilisiertes" V-Modell
ist jedoch ein interessantes Denkmodell.
Hierzu wäre zuerste zu klären, an welcher Stelle die beiden
grundverschiedenen Philosophien eine Annäherung zulassen.

>- XP ist aber als Methode noch nicht im V-Modell definiert 
siehe Punkt 2

>- V-Modell hat durch Unwissenheit ein schlechtes Image, "Behördenstandard"
...leider wahr...

>- V-Modell alleine ist nicht die Lösung für alle Probleme im Projekt
...wird aber gerne als Entschuldigung für Probleme im Projekt angeführt...

>- XP ist nicht für alles die Lösung
...korrekt. Die Fokusierung auf das Ziel (und nicht auf den Weg) würde
jedoch so manchem "Heavy-Weight"-Projekt gut tun.

>- V-Modell Anpassung an neue Herausforderungen scheint notwendig.
Dies geschieht derzeit im Rahmen des V-Modell Weiterentwicklungsprojektes
WEIT (siehe Mail 651).
Mann darf jedoch nicht vergessen, das V-Modell'97 wurde mit Blick auf den
AuftragGEBER (Bund) erstellt.

Im Rahmen von WEIT wurde folgede interssante Frage gestellt:
Ausgangspunkt des V-Modells war, dass die IT-Projekte im militärischen und
behördlichen Umfeld durch den Auftraggeber nicht mehr kalkullierbar waren,
was die benötigte Zeit, die auftretenden Kosten und die erreichte Qualität
betraf. Vor diesem Hintergrund wollte man dem Auftraggeber ein Instrument - das
V-Modell - zur Verfügung stellen, mit dem IT-Projekte für den Auftragnehmer
beherrschbarer sind.

Diese sehr grobe Zielsetzung findet man auch in den einleitenden Absätzen,
der meisten Veröffentlichungen über das V-Modell, die sich mit der Historie
des V-Modells beschäftigen.
Betrachtet man nun das V-Modell 92 und 97 so stellt man fest, das im
V-Modell im Wesentlichen die Auftragnehmer-Seite geregelt wird, nur am Rande
die Schnittstelle zum Auftraggeber und die Auftraggeber- Seite, fast überhaupt nicht.

Nun stellt sich zu Recht die Frage, ob mit diesem Ansatz die ursprüngliche
Zielsetzung, die Verbesserung der Auftraggeber-Seite, erreicht werden kann? In
letzter Konsequenz würde das bedeuten, dass man alle Auftragnehmer internen
Themen nicht im V-Modell regeln sollte, somit würde beispielsweise das Submodul
Systemerstellung (SE) in nur sehr eingeschränktem Umfang im Regelungsteil des
V-Modells auftauchen!

Mit freundlichen Grüssen
Markus Reinhold
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
CoCOO
Competence Centre ObjectOrientation
Michael Haslbeckstr. 7a
D-85640 Putzbrunn
Germany

Tel. +49 89 462 89 930
Fax +49 89 462 89 931
Internet http://www.cocoo.de
email reinhold@cocoo.de
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Links to V-Model

not defined

This page online • GDPA Online • Last Updated 07.May.2004 by C. Freericks