Previous Next V-Model Official Homepage by IABG  
Mail 0637  

1996-1997-1998-1999-2000-2001-2002-2003-2004

Contents  
  • Title
  • From
  • Date
  •  
  • History
  • Content
  • Links to V-Model
  • Title

    Re: Prüf-Grundsatz (637)

    From

    Midderhoff, R.

    Date

    Freitag, 31. Januar 2003 09:03

    History

    Mail 0629 PM 1.4 - Wer akzeptiert das Projekthandbuch?

    Mail 0630 Re: PM 1.4 - Wer akzeptiert das Projekthandbuch?

    Mail 0631 Re: PM 1.4 - Wer akzeptiert das Projekthandbuch?

    Mail 0632 Produktstatus Projekthandbuch

    Mail 0633 Prüf-Grundsatz (Was: PM 1.4 - Wer akzeptiert das Projekthandbuch)

    Mail 0634 Re: Prüf-Grundsatz

    Mail 0635 Re: Prüf-Grundsatz

    Mail 0636 Re: Prüf-Grundsatz

    Mail 0637 Re: Prüf-Grundsatz

    Mail 0638 Re: Prüf-Grundsatz

    Mail 0639 Re: Prüf-Grundsatz

    Mail 0640 YAGNI (Re: Prüf-Grundsatz)

    Mail 0641 Software für Händi;-) (Was: Re: Prüf-Grundsatz)

    Mail 0642 anders = besser?!? (Was: Re: Prüf-Grundsatz)

    Mail 0643 Re: Prüf-Grundsatz , XP etc.

    Mail 0644 Re: Prüf-Grundsatz , XP etc.

    Mail 0645 Re: Software für Händi;-)

    Mail 0646 Re: Prüf-Grundsatz , XP etc.

    Mail 0647 Re: Prüf-Grundsatz , XP etc.

    Mail 0648 Re: Prüf-Grundsatz , XP etc.

    Mail 0649 Re: Prüf-Grundsatz , XP etc.

    Mail 0650 Re: Prüf-Grundsatz , XP etc.

    Mail 0652 Agile Methoden versus V-Modell. (War: Re: Prüf-Grundsatz, XP etc:)

    Mail 0657 Agile Methoden im neuen V-Modell

    Mail 0658 Re: Agile Methoden im neuen V-Modell

    Mail 0659 Re: Agile Methoden im neuen V-Modell

    Mail 0660 Extreme Programming und das V-Modell

    Mail 0661 Re: Extreme Programming und das V-Modell

    Mail 0662 GI-Vortrag "Agile Prozesse" in München

    Mail 0663 Re: Extreme Programming und das V-Modell

    Mail 0664 V-Modell am Studienplan?

    Mail 0665 Re: Extreme Programming und das V-Modell

    Mail 0666 Re: Extreme Programming und das V-Modell

    Mail 0667 Re: Extreme Programming und das V-Modell

    Mail 0668 Re: Extreme Programming und das V-Modell

    Mail 0669 Re: Extreme Programming und das V-Modell

    Mail 0671 Re: Extreme Programming und das V-Modell

    Mail 0728 Re: Agile Methoden im neuen V-Modell

    Mail 0729 Re: Agile Methoden im neuen V-Modell

    Mail 0730 Re: Agile Methoden im neuen V-Modell

    Mail 0731 Re: Agile Methoden im neuen V-Modell

    Mail 0732 Re: Agile Methoden im neuen V-Modell

    Mail 0733 Re: Agile Methoden im neuen V-Modell

    Mail 0734 Re: Agile Methoden im neuen V-Modell

    Mail 0735 Re: Agile Methoden im neuen V-Modell

    Content

    Von:            	"Rainer Midderhoff" 
    
    Hallo,
    
    um die (kleine DIskussion) an dieser Stelle kurz zusammenzufassen:
    
    1. Einerseits könte eine Lösung des Problems durch den Einsatz von
    verbesserter Kommunikation, Abstimmung, angemessener QS-Planung und
    Risikomanagement erfolgen.
    
    2. Die Diskussion wird interessant, wo man vielleicht grundsätzliche -
    vielleich auch traditionelle - Paradigmen hinterfragt.
    
    
    Meine (nicht repräsentative und sicher subjektive) Erfahrung läßt mich zu
    dem Schluß kommen, dass die Probleme der traditionellen Vorgehensweise
    nicht mit den traditionellen Antworten gelöst werden können. Mein kleines
    Beispiel ist sicher ein bisschen überspitzt, aber trotzdem glaube ich
    nicht, das ein mehr an QS-Planung und ein mehr an Risikomanagement das
    Problem wirklich an der Wurzel packt. (Wohl denke ich - aber das ist
    vielleicht eine Binsenweisheit - dass ein mehr an Kommunikation und
    Abstimmung immer hilft.)
    
    Interessant finde ich folgende Aspekte, die auch im Beitrag von Herrn von
    Hagen anklingen:
    
    - wenn Änderungen erst durch einen nicht angemessenen Prozess teuer werden,
    könnte ein anderer Prozess dann Änderungen "verbilligen" und uns vor
    unnötigen Dokumentations- un Spezifikationsschritten bewahren ?
    
    - was wird aus der Idee des durch Phasen abgesicherten Vorgehens, wenn
    Änderungen einfach und sicher möglich wären - auch sehr spät im
    Entwicklungsprozess?
    
    - wo ist die Grenze zwischen "quick und dirty" und der XP-Idee des "you
    aint gonna need it" (YAGNI), die uns vor umfassenden, aber unnötigen
    Lösungen bewahren könnte ?
    
    Und zudem wäre - um das kleine Beispiel zu referenzieren - die Frage zu
    stellen, ob ein Anwender eine SE 3-Spezifikation sehen, lesen, verstehen
    und abnehmen sollte ... wenn ich ein Händi ;-) kaufe, interessiere ich mich
    auch nicht für die SW-Architektur der Software ... oder sollte ich ?
    
    Viele Grüße und die besten Wünsche für ein schönes Wochenende aus München
    
    Rainer Midderhoff

    Links to V-Model

    SE3 - SW-/HW-Anforderungsanalyse / SD3 - SW/HW Requirements Analysis

    Previous Next This page online  •  GDPA Online  •  Last Updated 28.Mar.2004 by C. Freericks