mail 0667

Hallo V-Modell-Gemeinde,

die Herren Reinhold (CoCoo) und Kollischan (PRO DV) weisen
zurecht darauf hin, dass es - zumindest primär - nicht
darum gehen kann, einzelne XP-Praktiken dem V-Modell zuzuordnen
und in Projekte zu integrieren.

Es geht vielmehr um das Grundverständnis der Systementwicklung.

Dabei wird man feststellen, dass hinter den traditionellen
Vorgehensweisen (= schwer-gewichtige Prozesse; Monumentale
Prozesse) und den agilen Prozessen (leicht-gewichtige Prozesse)
unterschiedliche Leitbilder stehen und diese auch
unterschiedliche Rahmenbedingungen adressieren.

Diese unterschiedlichen Leitbilder und Rahmenbedingungen kann
man m.E. nicht einfach unter den Tisch kehren sondern muss
sie im Hinblick auf eine mögliche "Agilisierung" des V-Modells
beachten.
Ich habe daher nachfolgend einmal versucht, die Leitbilder
und Rahmenbedingungen für Monumentale Prozesse (MoPro) und
Agile Prozesse (AgiPro) zusammenzutragen:

MoPro:
Software-Entwicklung ist eine Ingenieurwissenschaft
(vorhersagbar, prozessorientiert)
AgiPro:
Software-Entwicklung ist ein Kommunikationsprozess
(adaptiv, menschen- und teamorientiert)

MoPro:
Kunde weiß grundsätzlich, was seine Anforderungen sind
(stabile Anforderungen)
AgiPro:
Kunde erkennt seine Anforderungen erst in Interaktion
mit der Software
(unsichere und vage Anforderungen)

MoPro:
Anforderungsanalyse
-> formal strukturiertes Pflichtenheft
AgiPro:
Ausgangspunkt:
informell beschriebene Szenarien

MoPro:
späte Überleitung in die Nutzung,
lange Entwicklungszyklen
AgiPro:
regelmäßige Überleitung in die Nutzung,
(sehr) kurze Entwicklungszyklen

MoPro:
Kunde will wenig mit der Entwicklung zu tun haben
AgiPro:
Kunde will in die Entwicklung einbezogen werden

MoPro:
Vertrauensbildung durch Zertifizierungen und formale Qualitätssicherungsprozesse
AgiPro:
Vertrauensbildung durch schnelle Umsetzung von
Kundenwünschen in lauffähige Software

MoPro:
auch bei schlecht qualifizierten und
unmotivierten Entwicklern möglich
AgiPro:
setzt verantwortungsvolle und motivierte Entwickler voraus

MoPro:
Teamgröße (auch) über 50
AgiPro:
Teamgröße kleiner 50  (< 20 (?))

MoPro:
Festpreisauftrag
AgiPro:
Auftrag nach Aufwand / Kontingentvereinbarung

MoPro:
Metapher:  Mondrakete
(Der Kurs steht bereits vor dem Start fest.)
AgiPro:
Metapher:  Autofahrt
(Der Kurs kann während der Fahrt jederzeit den
Begebenheiten angepasst werden.)

Eine "Agilisierung" des V-Modells bzw. der Anwendung
des V-Modell setzt auch voraus, dass von allen
Projektbeteiligten agile Prinzipien verinnerlicht
wurden und im Projekt gelebt werden.

Ulrich von Hagen

******************************************
* Ulrich von Hagen      LDS NRW
* E-Mail:  ulrich.von-hagen@lds.nrw.de
******************************************

> -----Ursprüngliche Nachricht-----
> Von: vm-d-l [mailto:vm-d-l@gmx.de]
> Gesendet: Mittwoch, 12. März 2003 21:32
> An: Multiple recipients of V-Modell-Mailingliste
> Betreff: Re: Extreme Programming und das V-Modell (666)
>
>
> Hallo V-Modeller,
>
> die Diskussion der letzten Wochen hat m. E. gezeigt, dass eine
> *Agilisierung des V-Modells* nicht schon durch eine Integration der
> elementaren XP-Praktiken (Pair Programming, etc.)  i. S. einer
> Methodenzuordnung erreicht werden kann - obgleich eine derartige
> Zuordnung prinzipiell möglich und von Fall zu Fall wohl auch sinnvoll
> ist.
>
> Wie kann ein agilisiertes VM erreicht werden?
> Als  wesentlich erachte ich immer noch die weichen Faktoren wie
> Kommunikation etc. und darüber gab es ja auch breiten
> Konsens. Wenn das
> organsisatorische Umfeld "stimmt", das V-Modell gut an die Belange des
> Unternehmens bzw. des Projekts angepasst und implementiert wurde,
> vermute ich - ohne es beweisen zu können -  dass dieses "gelebte"
> V-Modell auch agiler ist.
>
> Diese Punkte betreffen jedoch nicht so sehr das V-Modell "an
> sich" bzw.
> dessen Weiterentwicklung, sondern wie und unter welchen
> Randbedingungen
> es in einer Organisation eingesetzt wird.
>
> Was kann noch getan werden?
> Im OO-Spektrum Jan/Feb. 03 stellt Jens Coldewey vor dem Hintergrund
> iterativ-inkremneteller Entwicklung wesentliche Grundlagen
> für die agile
> Entwicklung dar: Um überhaupt agil sein zu können, gilt es, die beiden
> "gefährlichsten Gegner der Änderbarkeit" unter Kontrolle zu bringen,
> diese sind Codekomplexität und die Wahrscheinlichkeit durch Änderungen
> bereits existierende Code zu zerstören. Diese Kontrolle erreicht man
> durch klassische Techniken wie leistungsfähige Architekturen,
> verständliche Programmierung kombiniert mit Refactoring und
> automatischem Testen (gutes Bsp. für Integration von
> XP-Techniken). Ich
> möchte noch hinzufügen, dass ein leistungsfähiges Änderungs- und
> Konfigurationsmanagement unabdingbar ist.
> Durch diese Maßnahmen - unterstützt durch geeignete Tools - kann ein
> gehöriges Mass an Agilität erreicht werden.
> (Im "Manifesto" findet man übrigens "Humans over tools and
> processes" -
> aber dies ist wohl eher in dem Sinne zu verstehen, dass Prozesse und
> Tools nicht um ihrer selbst wegen exzessiv eingesetzt werden - wie Hr.
> Linnsen schreibt: XP und agile Methoden sind eine
> Gegenreaktion auf den
> Dokumentationswust, der in den USA bei der Softwareentwicklung für
> öffentliche AG anzufertigen ist - und wie jede Gegenreaktion sind sie
> eben auch etwas "extrem").
>
> Dazu musste man das V-Modell (als abstraktes Modell, nicht als
> "gelebtes") immer noch nicht ändern (außer dass "Refactoring" als
> Methode aufgenommen wurde).
>
> Weitere Möglichkeiten (das folgende hat ausgesprochen
> spekulativen Charakter!) könnten darin besteh
> en,
> dass man bestimmte V-Modell -Blöcke aus dem Masterprozess "auslagert"
> und möglichst agil abwickelt ...dies müsste aber im Detail untersucht
> werden.Vielleicht kann ein "agiles Szenario" in der
> Handbuchsammlung beschrieben werden.
> Hier liesse sich aber ggf. der Bogen schlagen zu der Frage,
> wie denn die
> ursprüngliche Zielsetzung des VM als Verbesserung der
> AG-Seite erreicht
> werden könne.
> Der AG verbindet ja im wesentlichen zwei Interessen mit dem VM:
> 1) Verfolgung des Projektfortschritts
> 2) Erhöhung der Erfolgswahrscheinlichkeit durch Vorgabe eines
> definierten Prozesses
>
> Falls der AG sich unter 2) ein XP-ähnliches Vorgehen wünschen
> sollte, oder aus anderen Gründen nich
> t an Details interessiert ist, könnte eine AG-Sicht auf das
> V-Modells definiert werden, die auch de
> r Vertragsgestaltung zugrundeliegt (hier habe ich eine Frage
> an die Experten: hat jmd. Erfahrung mi
> t der Vertragsgestaltung iterativ-inkrementeller Projekte?)
>
> Mal sehen, was mit unserem V-Modell noch so alles passiert!
>
> Mit freundlichen Grüßen
>   Karl Kollischan
>
> Dr. Karl Kollischan
> IT-Consultant
> PRO DV Software AG
> Mobil: 0170 6357210
> mailto:karl.kollischan@prodv.de
> http://www.prodv.de

Links to V-Model

not defined

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