mail 0732

Hallo Herr von Hagen,

dabei kann man sowohl evolutionär, wie auch inkrementell vorgehen.
Evolutionär heißt: Nur eine definierte Teilmenge der Anforderungen an das zu
entwickelnde Produkt werden erfasst und umgesetzt.
Inkrementell heißt: Anforderungen an das zu entwickelnde Produkt werden
möglichst vollständig erfasst. Aber nur ein Teil der Anforderungen wird
modelliert und implementiert.
(So unterscheidet das die Lehre.)

Sie sprechen hier - glaube ich - von der inkrementellen Variante. Die das
Kernsystems beschreibende Menge von Anforderungen muss dokumentiert werden
und wird dann Stück für Stück umgesetzt.

Da habe ich zwei Empfehlungen:
1. Auch hier können Sie nur mit Anforderungen in der Entwicklung arbeiten,
die den
Status [akzeptiert] haben. Jetzt haben Sie wohl das Problem, dass der ganze
Prozess steht, solange die Anforderungen nicht fertig sind. Als
Projektleiter würde ich zum Auftraggeber sagen, dass ich keine halbfertigen
Anforderungen in die Entwicklung übergeben wolle. Er müsse hier erst seinen
Pflichten nachkommen. Wenn sich jetzt nichts bewegt, liegt das Risiko auf
der Hand, welches Sie im Risikoinventar berücksichtigen, bewerten und auch
so zum Auftraggeber kommunizieren. Jetzt weiß er, dass es sich um Geld dreht
und er ggf. sein Budget erhöhen muss. Ausserdem: Damit sind sie exculpiert.
Sonst behauptet am Ende jemand, *Sie* hätten unfertige Zwischenprodukte als
Grundlage für den nächsten Arbeitsschritt verwendet. Für mich gilt: Bis zu
einem festgelegten Termin unfertige Anforderungen kommen nicht in das
nächste, sondern erst in das übernächste Release.

2. Bei großen Systemen kann ich die inkrementelle Vorgehensweise absolut
nicht empfehlen. Sie können für ein großes (=komplexes) System nicht die
gesamte Anforderungsanalyse durchführen. Wenn die ersten Features realisiert
sind, findet durch das einsetzende Feedback beim Anforderungsteller ein
Erkenntnisgewinnungsprozeß  statt. Er beginnt seine ursprünglichen
Anforderungen zu verwerfen. (Auf die nun initiierten Prozesse im KM-Bereich
gehe ich jetzt nicht ein) Das kann man nicht verbieten. Anforderungen sind
über einen längeren Zeitraum nie stabil. Gerade aus diesem Grund hatte XP ja
propagiert, die eigentliche Requirements Specification ersatzlos zu
streichen und durch eine laufende und sehr enge Zusammenarbeit zwischen
A.-steller und Entwickler zu ersetzen.

Das unangenehme an dem von Ihnen formulierten Problem ist, dass es sich
nicht durch ein Vorgehensmodell lösen läßt, wenn jemand seinen Pflichten
nicht nachkommt. Darüber könnten wir eine Menge erzählen ;-)

Ich hoffe trotzdem, Ihnen geholfen zu haben.

Oliver Linssen
______________________________________________________
Geschäftsführer Liantis GmbH & Co. KG
Mobil: +49 (0) 163/2469006
http://www.liantis.com

Free your work. Liantis.


-----Ursprüngliche Nachricht-----
Von: vm-d-l [mailto:vm-d-l@gmx.de]
Gesendet: Mittwoch, 17. März 2004 15:22
An: Multiple recipients of V-Modell-Mailingliste
Betreff: Re: Agile Methoden im neuen V-Modell (730)


Von:            	"von Hagen, Ulrich (LDS)" 


Hallo Herr Linssen,

Ihre Vorgehensweise kann ich mir im Hinblick auf Ausbaustufen gut
vorstellen.

Aber was mache ich, um zunächst einmal zu einem Kernsystem zu kommen, das
geeignet ist, ein vorhandenes System "auf einen Schlag" abzulösen?
[Aufgrund bestimmter technischer Rahmenbedingungen und spezifischer
Schnittstellenanforderungen kommt in unserem Fall eine sukzessive
Ablösung des Altsystems (d.h. ein Ersetzen von Teilen des Altsystems
durch Ergebnisse einzelner Arbeitspakete) nicht in Betracht.]

MfG
U. von Hagen - LDS NRW

Links to V-Model

not defined

This page online • GDPA Online • Last Updated 16.Nov.2006 by C. Freericks