Previous Next V-Model Official Homepage by IABG  
Mail 0635  

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

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

    Re: Prüf-Grundsatz (635)

    From

    Beckmann, M.

    Date

    Donnerstag, 30. Januar 2003 05:42

    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:            	Dr.Markus.Beckmann@t-online.de
    
    
    vm-d-l schrieb:
    > Von:            	"Rainer Midderhoff"
    > 
    >
    >
    > Hallo,
    >
    > ... im Zusammenhang mit Prüfungen, Auftraggeber, QS und
    > "Bananenprodukten" :-) folgende Frage:
    >
    > Situation:
    >
    > AN bearbeitet Projekt nach V-Modell und liefert (o Graus
    > !) nach ca. 6 Monaten intensiver Spezifikationarbeit gem.
    > SE 3 ca 2 Kartons "Technische Anforderungen". Die Doku-
    > mente sind alle prima formatiert, haben tolle Deckblätter
    > und Inhaltsverzeichnisse (es wurden die Produktmuster
    > verwendet) und sind gem. Zustandskennzeichnung beim AN
    > durch die Zustände "in Bearbeitung" - "vorgelegt" -
    > "akzeptiert" (natürlich nur von der QS des AN) gewandert.
    >
    > Der AG soll - bitteschön - diese gesammelten Werke
    > innerhalb von ca. 2 Wochen abnehmen - damit diese Phase
    > (hört hört !) abgeschlossen werden kann.
    >
    > Problem:
    >
    > AG versteht von den Inhalten der Dokumente *kein* Wort -
    > weil: ist ja alles auf Ebene SE 3 sehr technisch. Zeit
    > zum Lesen von mehreren tausend Seiten (keine Übertreibung,
    > kommt immer wieder vor) innerhalb weniger Arbeitstage
    > ist schlicht unmöglich - und: was bedeutet die Abnahme
    > durch den AG: hat er damit Verantwortung in bezug auf
    > die Tragfähigkeit der vorgeschlagenen technischen Lösung
    > übernommen ? Wenn nicht: wozu soll er abnehmen ...
    > Fragen über Fragen.
    >
    > Was meinen die Praktiker ? 
    
    Ob "Praktiker" oder "Theortiker" lasse ich jetz mal offen.
    Auf jeden Fall bin ich der Meinung, dass bei Eintreten
    dieser Situation schon vorher nahezu alles schief gelaufen
    ist, was schieflaufen kann:
    
    (1) Wenn erst mit Vorliegen der "Technischen Anforderungen"
        klar wird, dass man tausende Seiten zur Beschreibung
        benötigt, dann wurde die Komplexität nicht frühzeitig
        erkannt. D. h. es hat offenbar im Vorfeld keine aus-
        reichende Analyse der Aufgabe stattgefunden.
        Alternativ: Die technischen Anforderungen spezifizieren
        das zu erstellende System bis in die letzte "Schraube".
        Dann ist die Frage, ob die Darstellung der Aufgabe an-
        gemessen ist.
        In beiden Fällen hat es versäumt, sich frühzeitig Ge-
        danken über den Umfang der Dokumentation zu machen.
    
    (2) "nach ca. 6 Monaten intensiver Spezifikationarbeit": das
        klingt so, als ob AG und AN in der Zeit nicht miteinan-
        der geredet haben. D.h. der AG hat das AN-Management
        vernachlässigt, der AN hat seine projektbezogene "Kun-
        denpflege" vernachlässigt.
        Entweder wurden hier keine angemessenen Kommunikations-
        regeln festgelegt oder es hält sich keiner daran...
    
    (3) "AG versteht von den Inhalten der Dokumente *kein* Wort"
        - dann wurde entweder im Vorfeld vergessen festzulegen,
        wer was wann wie prüft oder der AG hat versäumt, quali-
        fizierte Prüfer "bereitzustellen". Ursache dafür könnte
        in beiden Fällen sein, dass sich AG (und AN?) nicht klar
        darüber war(en), was da auf sie zukommt.
    
    (4) "innerhalb von ca. 2 Wochen abnehmen": Hier ist zu fra-
        gen, wer die Angemessenheit des Zeitraums festgelegt
        hat. Besser wäre es, im Vorfeld zu klären, wer dafür
        zuständig ist, angemessene Fristen einzuplanen. Derje-
        nige sollte diese Planung dann auch überwachen und früh-
        zeitig Alarm schlagen, wenn sich Verzögerungen abzeich-
        nen.
    
    (5) "damit diese Phase abgeschlossen werden kann": Hat man
        sich vorher Gedanken darüber gemacht, ob ein "event-"
        oder ein "termin-gesteuerter" Phasenabschluss erreicht
        werden soll? "event-gesteuert" macht z.B. dann Sinn,
        wenn man mit den Anforderungen in eine Ausschreibung
        für die Realisierung geht oder die Planung der Reali-
        sierung erst jetzt stattfindet. Termingesteuerte Phasen-
        abschlüsse ermöglichen zwar eine bessere Planung. Die
        nutzt aber nix, wenn sie durch solche Vorkommnisse "den
        Bach runter geht".
        Eine Mixtur wie: "Wir müssen erstmal die Planung sinn-
        voll abschließen, überziehen den Zeitraum dafür um n
        Wochen, wollen aber trotzdem den Endtermin halten."
        führt früher oder später in die Katastrophe.
    
    (6) Wer hat ggf. den Zeitdruck zu verantworten? Der AG, in-
        dem er sagt: "Wir müssen aber unbedingt des Schlusster-
        min halten!" Dann muss er ggf. auch "Murks" freigeben
        und die Konsequenzen tragen.
        Oder der AN, der den AG "tot-papiert", mit dem Ziel, den
        AG zu überfahren und im Zeitdruck eigene Ideen durchzu-
        drücken, Probleme zu verschleiern o.ä.?
    
    (7) "hat er damit Verantwortung in bezug auf die Tragfähig-
        keit der vorgeschlagenen technischen Lösung übernommen"
        - auch hier wieder: Was war denn vereinbart: Übernimmt
        der AG diese Verantwortung - oder nimmt er nur die Do-
        kumentation "zur Kenntnis"? Wenn das mit der Verantwor-
        tung des AG so vereinbart war, muss er auch die Konse-
        quenzen tragen.
    
    (8) "Wenn nicht: wozu soll er abnehmen?" Genau das sollte
        vorher geklärt sein. Es wäre m.E. durchaus tragfähig
        zu sagen, der AG nimmt nur die Funktionalität ab, die
        Technik verantwortet allein der AN. Dann muss man sich
        frühzeitig ein paar Gedanken über die Konsequenzen ma-
        chen (etwa: Mache ich mich von diesem AN abhängig? Hat
        das technische Grundkonzept Zukunft? Gibt es Alternati-
        ven?)
    
    Nur gut, dass die o.g. Situation nicht wirklich zu Problemen
    führen kann, denn der AG (und der AN) hat ja zu Projekt-
    beginn ein Risikomanagement aufgesetzt. D.h. er schaut ein-
    fach nach, welche Maßnahme er für das Risiko "keine ausrei-
    chenden oder qualifizierten Ressourcen für die Abnahmen der
    T.A. verfügbar" geplant hatte, und setzt diese um. Das Ri-
    siko wird reduziert, das Projekt läuft weiter, alle sind er-
    folgreich!
    
    Der AG hat kein Risikomanagement aufgesetzt...?
    Hmm - dumm gelaufen!-)
    
    Der langen Rede kurzer Inhalt: Das o.g. Problem hat weniger
    mit dem Prüfvorgang selbst zu tun als vielmehr mit Planung,
    Kommunikation, Kooperation usw.
    
    Just my 2 EUR-Cent!-)
    Markus Beckmann
    
    
    > Grüße
    > Rainer Midderhoff

    Links to V-Model

    Technische Anforderungen / Technical Requirements

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